한국산학기술학회논문지 Vol. 10, No. 6, pp. 1265-1274, 2009 동일한경량컨테이너구조환경에서스프링프레임워크 2.0 과 2.5 의개발생산성비교연구 이명호 1* 1 세명대학교전자상거래학과 A Study on Comparison of Development Productivity of Spring Framework 2.0 and 2.5 with Lightweight Container Architecture Myeong-Ho Lee 1* 1 Department of ecommerce, Semyung University 요약본논문은스프링프레임워크 2.0과 2.5와연관된객체지향소프트웨어개발생산성에대한지침과평가지표를제공하는데목적이있다. 스프링프레임워크는경량컨테이너아키텍처로성공적인오픈소스표준모델로알려져있다. 그러나동일한플랫폼상에서스프링프레임워크 2.0과 2,5에대한성능평가연구는부족하였다. 또한정량적분석도일부분의 LoC(Line of Code) 분석만시도함에따라새로운사양이발표됨에도구체적인평가지표와지침이부족하여소프트웨어생산성의평가와프로젝트의새로운시도에제한이있었다. 따라서본연구에서는동일한플랫폼상에서스프링프레임워크의새로운버전의개발생산성평가하기위한특정지침을제시하고, 이전의사양과의객관적인소프트웨어개발생산성지침을제공하고자한다. Abstract This paper proposes an object-oriented software development guidance and an evaluation inde for the productivity related to Spring Framework 2.0 and 2.5. Spring Framework is a known successful open source standard model for lightweight container architecture. However, there is no comparison research about the performance of Spring Framework 2.0 and 2.5 with same identical platform. Quantitative analysis is supported as a part of LoC(Line of Code) analysis. There is a limit to develop the updated software with no the specific evaluating inde for the productivity of the software. This work proposes an specific inde for evaluating the productivity of new version Spring Framework on a platform. Base on the result, the specific guidance of the developing software is obtained. Key Words : Spring Framework 2.0 and 2.5, Lightweight Container Architecture, LoC 1. 서론 디지털컨버전스시대에서의컴퓨터아키텍처는인터넷의주도아래근본적인거대한변화의시대를맞이하고있다. 또한웹이진화하면서데이터뿐만아니라응용애플리케이션프로그램까지데스크톱에서해방되어외부데이터센터에저장해놓고사용할수있는클라우드컴 퓨팅 (Cloud Computing) 환경의시대를예고하고있다 [4]. 따라서운영환경통합은온-디멘드로, 기반구조의통합은그리드나유틸리티로, 개발통합은통합개발환경으로, 데이터베이스통합은데이터허브나 EAI로, 사용자인터페이스통합은 RIA로통합화및표준화가진화되고있다 [2,3]. 이러한엔터프라이즈환경에서는이기종컴퓨터들간에프로그램을분산시켜부하를줄여시스템의성능 * 교신저자 : 이명호 (mhlee@semyung.ac.kr) 접수일 09 년 05 월 01 일수정일 09 년 06 월 10 일게재확정일 09 년 06 월 17 일 1265
한국산학기술학회논문지제 10 권제 6 호, 2009 저하와네트워크병목현상을줄일수있는분산객체구조가필요하게되었다. 또한복잡한시스템요구조건을신속히구현하기를원하는유비쿼터스정보화시대에서는다양한객체지향및분산객체개발방법론을거쳐현재는컴포넌트기반개발방법에이르게되었다 [6]. 컴포넌트는고유한기능을수행하는독립적인소프트웨어의단위를말하며, 인터페이스와구현의분리를통해캡슐화를통하여컴포넌트제공자와사용자사이에서독립성을확보하여소프트웨어의재사용성을높일수있게하는방법론이다. 컴포넌트모델은컴포넌트설계와구현단계에서표준규약을통하여컴포넌트에대한일관성있는관리를지원하며, 컴포넌트패키징, 분산, 트랜잭션관리, 통신, 보안등의서비스가포함된다. 그러나이러한컴포넌트모델의분산응용프로그램을운영하기위하여 CORBA, DCOM, RMI 등이개발되었지만지속성있는데이터를표현하기위한표준화된방법이없었고, 트랜잭션, 보안, 멀티쓰레딩등의서비스를위하여개발자들이직접코드를작성해야하였다. 이러한문제점들을해결하기위하여현재인정되고있는컴포넌트모델의표준은 MS사의 COM+, OMG의 CCM(CORBA Component Model), SUN사의 EJB(Enterprise JavaBeans) 등이있지만, 이중에서대용량분산객체의가장성공모델로알려진것이 EJB이다. EJB는자바프로그램처럼단독으로실행되는것이아니라 EJB 컨테이너라는소프트웨어에설치되어야실행될수있으며, EJB 컨테이너는 EJB 서버에포함되어있다. 그러나 EJB의단점은분산환경을지원하기위하여객체를직렬화하는과정때문에실행속도의저하가발생하며, 개발주기가소스수정, 빌드, 배포, 테스트와같은복잡한과정을거치기때문에개발생산성의저하가일어나며, 테스트의어려움으로제품의품질저하, 변형된패턴들로인한객체지향적으로개발하는데제약사항도발생하며, 대형벤더사들의 EJB 컨테이너사이의이식성저하등이발생한다 [8]. Non EJB와 EJB 아키텍처가가지고있는문제점을해결하고장점들을지원하기위하여새롭게등장한아키텍처가경량컨테이너아키텍처이다. 이와같이경량컨테이너아키텍처의가장중요한 6가지기본핵심가치로는아키텍처리팩토링에의해서확장할수있는단순한아키텍처구성, 소프트웨어개발생산성확보, 객체지향중심적, 비즈니스요구사항의중요성, 기술과아키텍처의검증과정의중요성, 그리고테스트가능성등의지향점을추구하기위한결과물로등장한것이스프링프레임워크이다. 현재까지플랫폼의변화에따른개발생산성에대한비교연구는 2가지의애플리케이션에대하여다른 J2EE 플랫폼에서의개발생산성을비교한연구였으며 [11], 동일한플랫폼상에서 EJB 2.0과 EJB 3.0 사양에대하여정량적인평가지표에따른개발생산성연구는있었다 [3]. 그러나스프링프레임워크 2.0과 2.5에대하여같은플랫폼상에서소프트웨어개발생산성비교에대한연구가미비하였으며, 정량적분석도일부분의 LoC(Line of Code) 분석만시도함에따라새로운사양이발표됨에도구체적인평가지표와지침이부족하여소프트웨어생산성의평가와프로젝트의새로운시도에제한이있었다. 따라서본연구에서는 Non EJB와 EJB 아키텍처가가지고있는문제점을해결하고장점들을지원하기위하여개발된같은플랫폼상에서스프링프레임워크 2.0과 2.5 사양에대하여정량적인평가지표를제시하여, 새로운스프링프레임워크사양에대한정량적인분석을통하여객관적인소프트웨어개발생산성연구에대한지침을제공하고자한다. 2. 스프링프레임워크의기본개념 2.1 스프링프레임워크의고찰 현재까지경량컨테이너아키텍처의가장잘알려진구조로는스프링프레임워크이며, 첫번째버전은 2002 년 10월 Rod Johnson이 Wro 출판사에서출간한 Epert One-on-One J2EE Design and Development" 에서처음소개되었으며, 프레임워크는 2003년 6월에 Apache 2.0 라이센스로릴리즈되었다. 2004년 3월에첫번째스프링프레임워크 1.0 마일스톤이릴리즈되었고, 2006년스프링프레임워크 2.0이릴리즈되었다. 2007년 11월에스프링프레임워크 2.5가릴리즈되었으며. 2008년 12월스프링프레임워크 3.0 M1이발표되었고, 2009년 1월스프링프레임워크 3.0 M2가발표되었다. 그러나스프링프레임워크 2.5에서기존 2.0 버전과비교하여새로운특징의변화가있었다. 가장큰특징으로는애노테이션 (Annotation) 을이용한의존성삽입 (DI : Dependency Injection) 의도입이다. 또한현재까지스프링프레임워크 3.0에서도 2.5의기능에애노테이션설정이좀유연하고폭넓게사용할수있도록조금발전한것뿐이다 [2,8]. 따라서본연구에서는가장큰특징과변화를가지고있으며안정된스프링프레임워크 2.5를기반으로파일럿시스템을설계하여구현하도록한다. 2.2 스프링프레임워크의구성 1266
동일한경량컨테이너구조환경에서스프링프레임워크 2.0 과 2.5 의개발생산성비교연구 스프링프레임워크 2.0과달리 2.5의가장큰특징은애노테이션을이용한의존성삽입이다. 스프링이시작한의존성삽입기술은피코콘테이너, EJB3.0, SEAM, Google Guice 등의다양한프레임워크와기술스펙으로발전해왔다 [5]. 의존성삽입기술은스프링 1.0부터 2.0 까지계속발전해오고있는기술이다. 의존성삽입은 Constructor Injection, Setter Injection, Interface Injection 등의크게 3가지유형을가진다 [1,8,10]. Constructor Injection은생성자를이용해서의존성을설정해주는방법이고, Setter Injection은 Setter 메서드를이용하여의존성을설정해주는방법이다. 스프링은자바빈규칙을이용한 Setter Injection을주로사용한다. 또한 Factory Bean 기능이추가되어빈의생성방식이유연하게만들수있는길을열어주었다. 스프링프레임워크 2.0에서는이러한의존성삽입의범위를스프링이직접관리하지않는객체에게로확대하는기능이추가되었으며, 스프링프레임워크 2.5에서는단지기존의 XML 설정기능을그대로애노테이션으로적용한수준이아니라애노테이션방식의특징을최대한살리면서다른의존성삽입기술에서제공하고있는편리한설정방식을대폭도입하게되었다 [5]. 따라서본연구에서동일한경량컨테이너아키텍처환경에서스프링프레임워크 2.0과 2.5 사양으로파일럿시스템을구현한구성도를살펴보면그림 1과같다. 하여각항목별평가지표를이용하여사양별정량적으로개발생산성을비교하도록한다. [ 표 1] 스프링프레임워크 2.0 과 2.5 의개발환경 항목 Spring 2.0 Spring 2.5 OS Windows XP Professional Windows XP Professional Platform JDK 1.6 JDK 1.6 WAS JBOSS-4.2.3GA JBOSS-4.2.3GA DB Oracle 10g Oracle 10g IDE MyEclipse 6.0 MyEclipse 6.0 CASE Rational Rose 2003 Rational Rose 2003 따라서본연구에서사용한정량적소프트웨어개발생산성평가로는스프링프레임워크 2.0과 2.5에서의 Controller와 ~ManageImpl에서의서비스코드설정평가지표로사양별파일개수및 LoC의평가와사양별 XML 의비교평가등을선정하여분석한다. 3.2 데이터베이스스키마 동일한경량컨테이너주조환경에서소프트웨어생산성비교를위하여개발될파일럿시스템의데이터베이스스키마는스프링프레임워크 2.0과 2.5 사양에서그림 2 와같이동일한데이터베이스스키마를이용하여비교분석한다. [ 그림 1] 스프링프레임워크의구성도 3. 개발생산성비교방안 3.1 테스트환경본연구에서는스프링프레임워크 2.0과 2.5 사양을기반으로하는소프트웨어개발생산성을비교분석하기위한방안으로표 1과같은동일한개발환경과데이터베이스스키마를이용하여스프링프레임워크 2.0과 2.5 환경에서의파일럿프로그램을개발한후, 이프로그램통 [ 그림 2] 데이터베이스스키마구조 데이터베이스스키마구조에서각엔티티의기능을요약하면표 2와같다. 1267
한국산학기술학회논문지제 10 권제 6 호, 2009 [ 표 2] 엔티티의기능 엔티티명 Admin Member Reservation Reserinfo Roominfo ipcode 설명 시스템을관리하는관리자정보 시스템에가입된회원의정보 회원이예약한예약정보 예약자와실제투숙자구별을위한예약자정보 객실의변동사항을관리하는정보 전국의우편번호정보 [ 그림 4] 스프링 MVC 2.5 의동작패턴 3.3 스프링 MVC 의동작패턴웹애플리케이션을개발하기위하여초기개발속도및쉬운접근성으로요청의최초진입점을 JSP로시작하는모델 1 방식과요구사항에대한대응속도의느림과유지보수의어려움, 정교한사용자인터페이스개발의어려움의문제점을극복한요청의최초진입점이컨트롤러인서블릿으로진입하는대안인모델 2 방식있다. 모델 2 방식의근간이되는개념이 MVC이다 [1]. 스프링 MVC 에서모델은사용자인터페이스티어및비즈니스티어사이에서주고받는데이터를말한다. 다음그림 3과그림 4는스프링 MVC 2.0과 2.5의동작패턴을도식화한그림이다. 3.4 유스케이스다이어그램파이럿시스템의예약관리에대한요구사항정의활동에서파악된액터와유스케이스를유스케이스다이어그램으로표현해보면그림 5와같은예약관리의유스케이스모델이된다. 예약관리의유스케이스모델에기술된유스케이스이름만으로는유스케이스가나타내려고하는기능을명확하게정의될수없기때문에이에대한보다자세한정보를기술한문서산출물인유스케이스명세서를기술해보면표 3과같다. [ 그림 5] 예약관리의유스케이스다이어그램 [ 그림 3] 스프링 MVC 2.0 의동작패턴 유스케이스명세서에기술된이벤트흐름은유스케이스가나타내는시스템의기능이액터와시스템간의상호작용으로진행되는과정을보여준다. 1268
동일한경량컨테이너구조환경에서스프링프레임워크 2.0 과 2.5 의개발생산성비교연구 예약관리유스케이스명세서개요회원은호텔에투숙하기위해예약한다. 관련액터회원우선순위상선행조건시스템에로그인되어있어야한다. 이벤트흐름 [ 표 3] 예약관리유스케이서명세서 기본흐름 1메인화면에서예약을클릭한다. 2시스템은예약정보입력페이지를보여준다. 3양식에따라예약날짜, 체크인날짜, 체크아웃날짜, 요청사항등을입력한후확인을누른후예약자정보입력페이지로이동한다. 4회원은예약자정보를입력 ( 예약자, 투숙객, 성별, 휴대폰, e-mail, 주소, 요청사항등 ) 후확인버튼을클릭한다. 5입력이완료되면예약완료화면예약번호를보여준다. 6회원이완료버튼을누르면회원전용메인화면으로돌아간다. 대안흐름 A1) 예약정보및예약자정보입력 : 필수입력사항을누락하였을경우. 1 필수입력사항누락시 누락되었습니다. 라는메시지를뿌려주고 3으로돌아간다. 2 사용자는 3부터다시수행한다. 후행조건예약정보와예약자정보가입력된다. 기타요구사항없음 다음표 4는파일럿시스템중예약관리에대한클래스정의를요약한표이다. 클래스명타입설명 IReservation Manage Reservation ManageImpl Reservation RowMapper Reservation Controller MultiAction Controller Reservation [ 표 4] 예약관리에대한클래스정의 interface class class class class class 3.6 시퀀스다이어그램 예약관리에필요한유스케이스를실현하는오퍼레이션을모아놓은인터페이스 IReservationManage에모여진오퍼레이션이실제수행되는클래스오퍼레이션의실행결과를임시저장하는클래스클라이언트의호출을받아오퍼레이션의수행을조절하는클래스 ReservationController의 Spring Controller 설정을위한클래스 Reservation 정보를가지고있는객체클래스 설계유스케이스실현모델은파악된설게클래스들이어떻게메시지를주고받으면서시스템의요구사항을제공할수있는지를표현한시퀀스다이어그램이다. 그림 7 은본연구의파일럿시스템에서중요한예약관리의설계유스케이스실현모델인시퀀스다이어그램을도식화한것이다. 3.5 클래스다이어그램비기능적인요구사항과플랫폼을고려한후, 설계활동을통한분석클래스를구체화하여설계클래스를도출한다. 따라서본연구의파일럿시스템에서중요한예약관리의설계객체모델인클래스다이어그램은그림 6 과같다. [ 그림 7] 예약관리클래스다이어그램 [ 그림 6] 예약관리클래스다이어그램 3.7 파일럿시스템의구현경량컨테이너아키텍처환경에서스프링프레임워크 2.0과 2.5의파일럿시스템은각유스케이스에사용되는화면간의전환을화면흐름모델로설계함으로써명시적으로분석하였다. 다음그림 8은회원가입관련화면흐름모델과관련된사례로써예약관리유스케이스의사 1269
한국산학기술학회논문지 제10권 제6호, 2009 용자 인터페이스를 위하여 사용되는 화면 흐름 관계를 4. 스프링 프레임워크의 평가 나타낸다. 4.1 XML의 평가 스프링에서는 스프링 MVC의 DispatcherServlet에서 컨트롤러를 사용하여 클라이언트의 요청을 처리한다. 스 프링 MVC는 1개 이상의 DispatcherServlet을 설정할 수 있으며, 이것은 기본적으로 웹 애플리케이션의 /WEB-INF/ 디렉터리에 위치한 [서블릿이름]-servlet.ml 파일로부터 스프링의 정보를 읽어온다. 서로 다른 DispatcherServlet 이 공통 빈을 필요로 하는 경우에는 ContetLoaderListener를 사용하여 공통으로 사용될 빈을 설정할 수 있다. [그림 8] 회원가입을 위한 화면 흐름도 ContetLoaderListener는 contet ConfigLocation 컨텍스 트 파리미터를 명시하지 않으면 /WEB-INF/application 이상과 같은 데이터베이스 스키마를 기반으로 분석 및 -Contet.ml을 설정 파일로 사용한다[7]. 따라서 본 연구 설계를 통하여 동일한 플랫폼 개발 환경에서 스프링 프 에서 스프링 프레임워크 2.0과 2.5에서 개발된 파일럿 시 레임워크 2.0과 2.5의 파일럿 시스템을 구현하기 위한 메 인 화면은 그림 9와 그림 10과 같다. 스템의 중요한 XML 현황은 표 5와 같다. [표 5] 스프링 프레임워크의 XML 현황 스프링 프레임워크 버전 항목 XML Dispatcher Servlet 2.0 사용 여부 Component-Scan 설정 항목 Application Contet LoC 사용 여부 LoC 1 Handler Mapping 2 - Controller Bean 설정 35 - Schema Type (DTD) 3 Total(단위 : Line) [그림 9] 스프링 프레임워크 2.0의 파일럿 시스템 2.5 8 (추가확 (2.5) 장기능) 40 9 5 35 X - 4 (2.5) 8-1 Component-Scan - Resource설정 및 Bean 등록 Schema Type (2.0) Annotation Config Total(단위 : Line) 39 14 표 5에서 보는 봐와 같이 스프링 프레임워크 2.5가 2.0 에 비하여 DispatcheServlet에서는 77.5%의 LoC 감소가 보이며, ApplicationContet에서는 64.1%의 LoC 감소가 나타났다. (1) servlet.ml 설정 방식 스프링 프레임워크 2.0의 servlet.ml XML 문서 타입 [그림 10] 스프링 프레임워크 2.5의 파일럿 시스템 은 DTD 방식으로 다음과 같다. 1270
동일한경량컨테이너구조환경에서스프링프레임워크 2.0 과 2.5 의개발생산성비교연구 <?ml version="1.0" encoding="utf-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd" > 스프링프레임워크 2.5의 servlet.ml XML 문서타입은스키마방식으로다음과같다. <beans mlns="http://www.springframework.org/schema/beans" mlns:contet="http://www.springframework.org/schema/contet" mlns:p="http://www.springframework.org/schema/p" mlns:si="http://www.w3.org/2001/xmlschema-instance" si:schemalocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.sd http://www.springframework.org/schema/contet http://www.springframework.org/schema/contet/spring-contet-2.5.sd"> HandlerMapping 설정을살펴보면, BeanNameUrl, SimpleUrl, AbstractUrl, AbstractBeanNameUrl Mapping, DefaultAnnotation Handler Mapping 방식중한가지를설정한다. 스프링프레임워크 2.0에서 BeanNameUrl Handler Mapping 방식사용예를보면다음과같다. <bean id="handlermapping" class="org.springframework.web.servlet.handler.beannameurlhandlermappin g" /> 스프링프레임워크 2.5는애노테이션선언과컴포넌트스캔을사용하기때문에디폴트애노테이션방식을사용한다. 따라서애노테이션선언과 Component-Scan을사용하기때문에 DefaultAnnotationHandler Mapping 방식을사용한다. <bean class= org.springframework.web.servlet.mvc.annotation.defaultannotationhandlerm apping p:alwaysusefullpath="true" /> 스프링프레임워크 2.0에서의컨트롤러빈의설정은각컨트롤러마다설정해주어야하며사용예는다음과같다. <bean id="membercontroller" name="/member.spring" class="controller.membercontroller"> <property name="methodnameresolver" ref="paramresolver" /> <property name="member"> <ref bean="membermanage" /> </property> </bean> 스프링프레임워크 2.5에서의컴포넌트스캔설정을살펴보면, controller 패키지를스캔범위로지정해줌으로써컴포넌트선언컨트롤러빈을자동등록되게한다. <contet:component-scan base-package="controller" /> (2) applicationcontet.ml 설정방식스프링프레임워크 2.0의 applicationcontet.ml 설정에서 XML 문서타입인스키마방식은다음과같다. <?ml version="1.0" encoding="utf-8"?> <beans mlns="http://www.springframework.org/schema/beans" mlns:si="http://www.w3.org/2001/xmlschema-instance" si:schemalocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.sd"> 스프링프레임워크 2.5에서의 applicationcontet.ml 스키마방식은다음과같다. <beans mlns="http://www.springframework.org/schema/beans" mlns:contet="http://www.springframework.org/schema/contet" mlns:p="http://www.springframework.org/schema/p" mlns:si="http://www.w3.org/2001/xmlschema-instance" si:schemalocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.sd http://www.springframework.org/schema/contet http://www.springframework.org/schema/contet/spring-contet-2.5.sd"> 스프링프레임워크 2.0에서리소스설정및빈등록사용예를보면다음과같다. <bean id="membermanage" class="member.membermanageimpl" abstract="false" lazy-init="default" autowire="default dependency-check="default"> <property name="datasource"> <ref bean="datasource" /> </property> </bean> 또한스프링프레임워크 2.5에서의컴포넌트스캔설정을살펴보면, 서비스패키지를스캔범위로지정해줌으로써컴포넌트선언서비스빈의자동등록및리소스설정을하도록한다. 1271
한국산학기술학회논문지제 10 권제 6 호, 2009 <contet:component-scan base-package= member /> <contet:component-scan base-package= reservation /> [ 표 7] 2.0 에서의 Controller 의설정내용 이상과같이스프링프레임워크 2.5에서 2.0 이전버전들보다 XML 스키마형의변화로인한설정의간소화와 Component-Scan으로인한빈설정의편리성, 그리고 Controller, Service, Resource, Handler-Mapping 등의선언을자동으로등록가능함에따라컴포넌트추가확장시효율성이증가등의장점이있다. 그러나스키마형을확장할수록코드의라인수가증가하는단점도있다. 4.2 서비스코드의평가 (1) Controller 부분의설정평가일반적으로소프트웨어개발생산성을평가할때 LoC 평가방법을자주사용한다. 따라서본연구에서도스프링프레임워크 2.0과 2.5 사양에서의패키지에대한 Controller 서비스코드에대한설정사항에대한평가를보면표 6과같다. [ 표 8] 2.5 에서의 Controller 의설정내용 [ 표 6] Controller 의서비스코드설정의평가 버전 2.0 2.5 Package 명설정사항 LoC 설정사항 LoC Member X 242 Reservation X 178 ReservInfo X 163 Roominfo X 59 Admin X 179 Auto-Wired, Component Controller 선언, Request-Mapping Auto-Wired, Component Controller 선언, Request-Mapping Auto-Wired, Component Controller 선언, Request-Mapping Auto-Wired, Component Controller 선언, Request-Mapping Auto-Wired, Component Controller 선언, Request-Mapping 243 195 173 68 192 Total ( 단위 : Line) 811 871 스프링프레임워크의 Controller 부분의서비스코드에서는표 7과표 8에서와같이스프링프레임워크 2.0에서는빈등록을위한설정과 Mapping 설정을직접 XML에서하지만, 스프링프레임워크 2.5에서는소스코드에직접선언하기때문에 XML의설정이간소화와의존관계의자동설정으로인한편리성이증가되지만소스코드의직접선언으로복잡성이야기될수있다. (2) ~ManageImpl 부분의설정평가 스프링프레임워크 2.0과 2.5 사양에서의패키지에대 한 ~ManageImpl 부분의서비스코드에대한설정사항에 대한평가를보면표 9와같다. [ 표 9] ~ManageImpl의서비스코드설정의평가 버전 2.0 2.5 Package명 설정사항 LoC 설정사항 LoC Member X 139 Component Resource, Service 144 Reservation X 105 Component Resource, Service 110 ReservInfo X 95 Component Resource, Service 103 Roominfo X 58 Component Resource, Service 66 Admin X 100 Component Resource, Service 114 Total ( 단위 : Line) 497 537 스프링프레임워크의 ~ManageImpl 부분의서비스코 드에서는표 10과표 11에서와같이스프링프레임워크 2.0에서는리소스를빈으로등록하여 XML에설정을해 야하지만, 스프링프레임워크 2.5에서는리소스와서비 스의직접선언으로 XML의설정이필요없어진다. 1272
동일한경량컨테이너구조환경에서스프링프레임워크 2.0 과 2.5 의개발생산성비교연구 [ 표 10] 2.0에서의 ~ManageImpl의설정내용 [ 표 11] 2.5에서의 ~ManageImpl의설정내용이상과같이스프링프레임워크 2.0에서보다스프링프레임워크 2.5에서의서비스코드설정시의장점으로는소스코드와함께설정을할수있고, Field, Multi ActionController의메서드등의편리한설정방식을지원한다. 소스코드와함께있기에리팩토링시편리하다. 소스코드의직접설정으로인한 XML의설정의간소화하며, 의존관계의자동설정으로인한편의성이증가한다. 또한 Controller 인터페이스를구현하지않은클래스도애노테이션을이용하여 Controller로사용이가능하다. 그러나직접선언으로인한코드의복잡성을야기시킬수있으며, 형으로빈을찾아서설정하는문제도있다. 이것은같은타입의빈이여러개존재할경우 Autowiring 작업의실패원인이되기도한다. RequestMapping을클래스에적용하게되면해당클래스는지정한 URL만을처리하게되기때문에메서드에적용되는 RequestMapping 애노테이션은더이상 URL을명시할수없는단점도존재한다. 5. 결론 프로젝트를실패로만들지않기위하여가장먼저생각할것은단순성, 생산성, 객체지향성, 고객이원하는핵심요구사항에중요성, 실증적인방법으로기술을도입 가능성, 그리고테스트가능성등의핵심가치이다 [9]. 이러한지향점들을추구하기위하여등장한것이스프링프레임워크이다. 스프링프레임워크에서는특정한인터페이스에종속되지않는빈과같은클래스인 POJO를관리하는스프링컨테이너에게제어역행화를통한제어권을넘겨서 EJB 컨테이너에서지원하던매력적인기능들을지원하고있다. 그리고 POJO 기반이기때문에특정환경구축을위한클래스를이입하지않으며, 애노테이션사용으로인한개발편의성이증가되는장점이있다. 그러나설정이바뀔때마다컴파일이필요하며, 각티어간연결이인터페이스를통해이루어지기때문에인터페이스의생성이필요로하는단점도있다. 그러나현재까지경량컨테이너아키텍처의성공모델로알려진스프링프레임워크 2.0과 2.5 사양의정량적인성과지표개발및사례의부족으로이전사양으로운영중인실무프로젝트의업그레이드나새로운기술사양의적용이미비하였다. 그이유는기본적인스프링프레임워크의기술변화의속도가빠르고표준사양의복잡도가높음에따라쉽게새로운사양들을현업에적용하지못한것이다. 또한스프링프레임워크의소프트웨어개발생산성비교에대한연구도부족한상태이며, 스프링프레임워크의새로운사양이발표됨에도현재까지구체적인분석및설계기반에따른구현지침이부족하여소프트웨어생산성의평가와프로젝트의새로운시도에제한이있었다. 따라서본연구에서는대용량분산객체시스템처리를위하여동일환경의스프링프레임워크 2.0과 2.5를기반으로파일럿프로젝트의분석및설계를통하여구현지침을제시하였으며, 또한스프링프레임워크 2.0과 2.5에대한성능평가기반으로정량적인분석을통하여객관적인소프트웨어개발생산성연구에대한지침을제시하였다. 향후에는 AOP나 ORM 기반구조로스프링을사용한연구와동일한데이터스키마를이용하여 EJB 3.0 과스프링프레임워크 3.0의소프트웨어생산성분석연구가지속되어야할것이다. 참고문헌 [1] 박재성, Spring 프레임워크워크북, 한빛미디어, pp. 26-377, 1월, 2006. [2] 이명호, EJB 3.0 표준을기반으로대용량분산객체처리의설계및구현, 대한설비관리학회지, 제13권제2호, pp. 45-51, 6월, 2008. [3] 이명호, EJB2.0과 EJB3.0의소프트웨어개발생산성비교연구, 한국산업경영시스템학회지, 제31권제3 1273
한국산학기술학회논문지제 10 권제 6 호, 2009 호, pp. 1-7, 9월, 2008. [4] 이명호, 경량컨테이너구조환경의스프링프레임워크 2.5를기반으로호텔예약시스템의설계및구현, 한국산학기술학회논문지, 제10권제3호, pp. 589-595, 3월, 2009. [5] 이일민, 자바기술의미래를비추는거울스프링프레임워크 2.5, 마이크로소프트웨어, pp. 136-143, 1 월, 2008. [6] 채흥석, 객체지향 CBD 개발 Bible, 한빛미디어, pp. 35-76, 8월, 2005. [7] 최범균, 웹개발자를위한스프링 2.5 프로그래밍, 가메출판사, pp. 24-440, 3월, 2008. [8] R. Johnson, Epert One-on-One J2EE Design and Development, Wro, pp. 441-673, October, 2002. [9] R. Johnson, and J. Hoeller, Epert One-on-One J2EE Development without EJB, Wro, pp. 1-141, June, 2004. [10] R. Johnson, et al., Professional Java Development with the Spring Framework, Wro, pp. 1-303, July, 2005. [11] J. Steams, R. Chinnici, and Sahoo, An Introduction to the Java EE 5 Platform, "http://java.sun.com/developer /technicalarticles/j2ee/intro_ee5/inde.html, 2006. 이명호 (Myeong-Ho Lee) [ 종신회원 ] 1984 년 2 월 : 아주대학교산업공학과 ( 공학사 ) 1986 년 2 월 : 아주대학교대학원산업공학과 ( 공학석사 ) 2001 년 2 월 : 아주대학교대학원산업공학과 ( 공학박사 ) 2002 년 3 월 ~ 현재 : 세명대학교전자상거래학과부교수 < 관심분야 > 물류정보시스템, WAS 프로그래밍, 모니터링시스템 1274