ISSN 2383-630X(Print) / ISSN 2383-6296(Online) Journal of KIISE, Vol. 44, No. 5, pp. 510-521, 2017. 5 https://doi.org/10.5626/jok.2017.44.5.510 OOPT: 소프트웨어공학교육을위한객체지향소프트웨어개발방법론 (OOPT: An Object-Oriented Development Methodology for Software Engineering Education) 정세진 이동아 김의섭 장천현 유준범 (Sejin Jung) (Dong-Ah Lee) (Eui-Sub Kim) (Chun-Hyon Chang) (Junbeom Yoo) 요약소프트웨어개발프로세스 (Software Development Process: SDP) 는소프트웨어공학교육에서가장기초적이며중심적인역할을한다. 모든소프트웨어는개발의시작부터마지막까지를모두포함하는특정 SDP 에기반해서개발된다. 따라서, SDP 교육은소프트웨어공학의제반기술에대한이해를도울수있다. 본논문은대학의소프트웨어공학수업에서활용할수있는소프트웨어개발방법론 ( 프로세스 ) 인 OOPT(Object Oriented Process with Traceability) 를소개한다. OOPT 는객체지향소프트웨어를개발하기위한방법론으로서, 각단계마다구체적인요구사항과산출물을정의하고있으며, 단위 / 시스템시험및추적성분석등의추가적인내용들도포함하고있다. 본논문은 OOPT 에대한적용사례로서다년간의건국대학교컴퓨터공학과소프트웨어공학관련수업들을소개하고있으며, 향후개선및발전방향을포함한다. 키워드 : OOPT, 소프트웨어공학교육, 객체지향개발방법론, 소프트웨어개발방법론 Abstract The software development process (SDP) plays an important basic role in software engineering education. Every software is developed in accordance with a specific SDP which contains all phases of software development. SDP education helps students to understand the overall techniques and the process of software engineering. This paper introduces a software development methodology (i.e., process) - OOPT (Object Oriented Process with Traceability), which was proposed for use in university software engineering classes. The OOPT is based on object-oriented software development, and it defines concrete requirements as well as outputs of each process/phases. It also contains the unit/system testing and a traceability analysis. We have used the OOPT in software engineering classes at Konkuk university for eight years. This paper conveys our experience as well as future extension and improvement plans. Keywords: software engineering education, object-oriented software development, software development process/methodology, OOPT 학생회원 : 건국대학교컴퓨터정보통신공학과 jsjj0728@konkuk.ac.kr ldalove@konkuk.ac.kr atang34@naver.com 종신회원 : 건국대학교컴퓨터공학부교수 chchang@konkuk.ac.kr 정회원 : 건국대학교컴퓨터공학부교수 (Konkuk Univ.) jbyoo@konkuk.ac.kr (Corresponding author 임 ) 논문접수 : 2017년 1월 12일 (Received 12 January 2017) 논문수정 : 2017년 2월 6일 (Revised 6 February 2017) 심사완료 : 2017년 2월 19일 (Accepted 19 February 2017) CopyrightC2017 한국정보과학회ː 개인목적이나교육목적인경우, 이저작물의전체또는일부에대한복사본혹은디지털사본의제작을허가합니다. 이때, 사본은상업적수단으로사용할수없으며첫페이지에본문구와출처를반드시명시해야합니다. 이외의목적으로복제, 배포, 출판, 전송등모든유형의사용행위를하는경우에대하여는사전에허가를얻고비용을지불해야합니다. 정보과학회논문지제44권제5호 (2017. 5)
OOPT: 소프트웨어공학교육을위한객체지향소프트웨어개발방법론 511 1. 서론소프트웨어개발프로세스 (Software Development Process) 는 1960년대의소프트웨어위기 (Software Crisis) [1] 현상을극복하기위해제안된기법으로서, 소프트웨어공학의시작점이되는근본기술이다. 고성능컴퓨터의등장과함께더많은 / 복잡한기능을수행하는소프트웨어를성공적으로개발하기위해서는, 다수의개발자가정해진순서에따라협업하는것이필수적이라는관찰을통해, 최초의소프트웨어개발프로세스인폭포수모델 (Waterfall Model)[2] 이제안된이후로나선형모델 (Spiral Model), 반복적모델 (Iterative Model), 점진적모델 (Incremental Model) 등다양한모델 [3] 이제안되었다. 현재는이런모델을기반으로소프트웨어개발에필요한구체적인사항들과도구, 표기법등을추가한것을소프트웨어개발방법론으로통칭하는데, 크게구조적방법론 (SASD: Structured Analysis and Structured Design) [4] 과객체지향방법론 (OOAD: Object-Oriented Analysis and Design)[5] 으로분류할수있다. 구조적방법론은데이터흐름을기반으로시스템을 top-down으로분석하면서소프트웨어시스템을개발하는방법이며, C언어와같은절차지향프로그래밍언어 (procedural programming language) 에적합하다. 반면, 객체지향방법론은객체 (Object Classes) 사이의통신을통해시스템의행위를구현하는방법론으로서, C++, Java와같은객체지향언어에적합한방법론이며, UML(Unified Modeling Language) 을사용한다. 다양한응용대상에따라다양한객체지향소프트웨어개발방법론 [6-9] 이제안되었는데, 래셔널통합프로세스 (RUP: Rational Unified Process)[10,11] 를현재 SI(System Integration) 산업계에서가장널리사용되는방법론으로꼽을수있다. 기업에서는래셔널통합프로세스를각상황에맞게수정 (Tailoring) 해서사용하고있다. 하지만, 래셔널통합프로세스를교육과정에그대로적용하는것은교육에다소불필요한내용들이포함될수있다. 이에본논문은래셔널통합프로세스와유사하지만대학의소프트웨어공학수업에서실습할수있는수준으로간결화된, 교육용객체지향소프트웨어개발방법론인 OOPT(Object Oriented Process with Traceability) 를소개한다. OOPT는대학의소프트웨어공학교육에서필요한다양한요소들을포함하고있는데, 단위시험, 시스템시험, GUI, 추적성분석등이그예이다. OOPT를소프트웨어공학수업에활용함으로써, 학생들은소프트웨어공학의필요성과효과등을직접체험할수있다. 또한, 다양한소프트웨어공학기술들을직접 사용하고적용함으로써, 소프트웨어공학이이론이아닌실제적인 / 현장의학문임을직접체험할수있다. OOPT 는건국대학교컴퓨터공학과의소프트웨어공학관련수업에서 2008년부터지속적으로활용되고개선되어왔다. 또한본논문은 OOPT의추가적인개선및발전방향을제시하고그동안의경험을공유함으로써, 여러대학에서소프트웨어공학교육이보다효과적으로수행되기를기대한다. 본논문의구성은다음과같다. 2장은소프트웨어개발프로세스와대표적인객체지향소프트웨어개발방법론들을소개한다. 3장은 OOPT를자세히소개하고, 4 장은건국대학교소프트웨어공학관련수업에서 2008년이후 OOPT를이용하여수행한다양한프로젝트들중 clone checker 예제를중점적으로소개한다. OOPT의구체적인개선 / 발전방향도함께정리하였다. 마지막으로 5장은본논문을마무리한다. 2. 소프트웨어개발프로세스 2.1 소프트웨어개발모델소프트웨어개발모델은소프트웨어개발시적용하는모델로폭포수모델, 나선형모델등다양한종류가있다. 폭포수모델은전통적인소프트웨어개발모델로구조적이고, 순차적인접근방법을취한다 [3]. 즉앞단계의작업이완료된후다음단계의작업이진행되는과정으로구성되며, 각단계는요구사항정의, 디자인, 개발, 테스팅등으로이루어져있다. 폭포수모델은주로요구사항이명확히정의되어다음단계로넘어갈수있는경우에적합한모델이며, 요구사항이정해지지않거나, 변경되는경우에는반복및수정에어려움이있다. 또한다음단계로넘어가기위해서는다른작업의끝까지기다려야하는상태가발생할수있다. 나선형모델은위험을최소화하기위해위험분석을포함한개발단계를점진적으로반복하여개발하는모델로 1988년제안되었다 [9]. 폭포수모델과달리반복적인작업을통한개발이필요한경우에효율적인모델이다. 나선형모델은목표설정, 위험분석, 구현및테스트, 평가및다음단계진행으로구성되며, 각과정은지속적이고순차적으로반복된다. 이처럼여러프로세스를반복적으로진행하여개발을수행하고위험분석을통해개발을완성해나가는모델이다. 나선형모델에서위험분석은요구사항의변경등예측되는위험사항을확인하고대처방안을수립하는단계이다. 다음그림 1 은나선형모델프로세스에대한그림이다. 2.2 객체지향소프트웨어개발방법론객체지향소프트웨어개발방법론은다양한소프트웨어개발의필요성증가에맞추어실세계의구조를정확
512 정보과학회논문지제 44 권제 5 호 (2017. 5) 그림 1 나선형모델프로세스 [3] Fig. 1 Development process of a spiral model[3] 그림 2 OOSE 프로세스 [7] Fig. 2 The development process of OOSE[7] 하게반영할수있고, 재사용을통해생산성을향상시킬수있다는점으로인해제안되고발전되었다. 초기에제안된개발방법론등으로는 OMT(Object Modeling Technique)[6], OOSE(Object-Oriented Software Engineering)[7], Fusion Methodology[8] 등이있으며, 각각의자체적인표기방법을통해디자인, 모델링등의과정을구성하고있다. 추후표기방법의표준화를위해 UML(Unified Modeling Language) 이사용되었으며, UML을사용한소프트웨어개발방법론으로는래셔널통합프로세스등이있다. OMT는소프트웨어개발을위해객체모델링방법을취하는방법론으로, OMT의모델링방법은 UML의이전버전이라할수있을만큼 UML과유사한모델링방법을가지고있다. OMT 방법론은객체모델 (object model), 동적모델 (dynamic model), 기능모델 (functional model) 3가지종류의모델을만드는방식으로진행되며각모델을검증하고, 연결하는형태로마무리된다. 객체모델은클래스다이어그램과유사한형태의클래스들을모델로작성한것이고, 동적모델은시스템의동작을상태다이어그램형태로표현한모델이다. OOSE는유스케이스를기반으로한개발방법론으로요구사항, 분석, 디자인, 구현, 테스트를진행하는방법론이다. OMT와마찬가지로 UML의초기버전에가까운다이어그램을사용하고있다. OOSE의프로세스는시스템과사용자를표현한유스케이스다이어그램을작성하고, 이를바탕으로요구사항정의및디자인, 개발을진행하는순서로구성되어있다. 다음그림 2는유스케이스를기반으로한 OOSE 프로세스에대한그림이다. 2.3 래셔널통합프로세스 (Rational Unified Process) 래셔널통합프로세스는 Rational에서제안한 UML 기반의객체지향개발방법론이다 [10,11]. 래셔널통합 그림 3 래셔널통합프로세스각단계및순서 [11] Fig. 3 RUP phases and disciplines[11] 프로세스는유스케이스를기반으로사용자의요구사항을기본으로반복적이고점진적인개발프로세스를통해시스템을개발하는 UP(Unified Process) 프로세스기반의프레임워크이며개발조직, 소프트웨어프로젝트팀등이필요에따라프로세스의요소들을선택하여사용할수있도록설계되어있다. 그림 3에나타난바와같이래셔널통합프로세스는요구사항분석, 디자인, 구현, 테스팅, 배치 (deployment) 의다양한프로세스로구성되어있으며, 이를시작 (inspection), 계획 (elaboration), 구현 (construction), 전달 (transition) 페이즈에거쳐반복하며필요에따라프로세스의요소들을조정하여개발프로세스를구성할수있다. 2.4 관련연구기존의대학등에서소프트웨어공학교육을위해교육용개발프로세스를제안하거나, 기존의프로세스들을사용한사례들이있다. [12,13] 과같이통합프로세스 (Unified Process) 의기초적인구조를교육에사용하는방법을제안한것과 [14,15] 와같이새로운교육용개발
OOPT: 소프트웨어공학교육을위한객체지향소프트웨어개발방법론 513 프로세스를제안하는사례들이있다. 이외에도다양한개발방법론들을이용하거나제안하는리포트들이존재한다 [16,17]. [12,13,18] 에서는각각통합프로세스 (unified process) 기반의방법을이용하여소프트웨어공학교육에적용한사례에대해제시하고있다. [12] 에서는통합프로세스의각페이즈에따라디자인, 테스팅등의팀을구성하고, 페이즈에따라프로젝트를진행하는방법을취하고있다. [18] 에서는소프트웨어공학교육에래셔널통합프로세스를사용하는방법에대해제안하고, 그경험을설명하고있다. [18] 에서는래셔널통합프로세스를수정하는가이드라인및과정을포함한개발프로세스를사용하여교육을진행하였다. 위와같은사례들은기존의통합프로세스를그대로사용하고있다. 하지만통합프로세스를교육과정에그대로적용하는것은교육목적에불필요한내용들이있을수있다 [15]. [15] 에서는교육용소프트웨어개발프로세스를개발시필요한요구사항들에대해정의하고, [13] 에서는 [15] 를기반으로기존의상업용개발프로세스에서적절한수준의개정을거친교육용소프트웨어개발프로세스인 Praxis 를제안하고있다. Praxis 의프로세스는디자인, 구현, 배치로구성되어있으며, 각각의프로세스는래셔널통합프로세스등기존의프로세스에서제안하는요구사항분석, 설계, 디자인, 구현등의내용을요약해제안하고있다. 하지만 Praxis 는유저인터페이스에대한고려가부족한점이있고, 설계단계에서상세한내용및방법제공에대해서학생들의재량에맞추도록하는등의부족한점이있다. 이처럼소프트웨어공학교육을위한개발프로세스또는프로세스적용방법을제안하는기존의여러연구들이존재한다. 본논문에서제안하는 OOPT는해당논문들과는프로젝트의주제를직접정의하는점과, 요구사항분석부터테스팅까지의추적성확보, 객체지향프로그래밍에서 GUI에대한직접적인고려가포함되는등의차이점을가지고있다. 그림 4 OOPT 프로세스 Fig. 4 The development process of OOPT 변경등에대처하고피드백을반영하기위하여반복적 (Iterative) 이고점진적 (Incremental) 으로소프트웨어를개발할수있도록구성되어있으며, 크게다음의 3개의 stage로진행된다. 그림 4는 OOPT의가장상위레벨의프로세스에대한그림이다. Stage 1000 Plan and elaboration에서는프로젝트의요구사항정의와같은전반적인계획에대하여진행하고, Stage 2000 Build 단계에서는실질적인디자인및구현을, Stage 3000 Deployment 단계에서는전체시스템구축에대해진행하며, 각단계별혹은전체프로세스별반복하여진행된다. 3.1 Stage 1000: Plan and Elaboration Stage 1000은소프트웨어개발프로젝트를기획하는것으로서, 요구사항을도출하고프로젝트계획서를완성하는것을목표로한다. 일반적으로대학의소프트웨어공학수업에서실시하는프로젝트들은보통미리제시된요구사항을만족하는소프트웨어를개발하는것을목표로하는반면에, OOPT는 OOO 그림판, OOO 엘리베이터컨트롤러, 등과같이, 추상적으로주어진주제에대해구체적인프로젝트계획서와요구사항 ( 명세 ) 을직접개발하는것부터시작하는장점이있다. 즉, 주어진주제를구현하는것이아니라, 주제를직접정하고계획하는단계부터프로젝트를시작하게된다. Stage 1000은그림 5에나타난 10 단계의 activity 들로구성되며, 각각의상세한내용및주요한산출물은표 1에나타나있다. Stage 1000에서학생들은각단계의 activity 들을통해최종적으로 프로젝트개발계획서 를완성하게된다. Activity 1001에서는먼저기본적인내용들이포함된프로젝트개발계획서를만든다. 3. Object Oriented Process with Traceability (OOPT) 본논문에서제안하는 OOPT는래셔널통합프로세스를대학소프트웨어공학수업에활용가능하도록수정한객체지향소프트웨어개발방법론이다. 직접적인소프트웨어개발외에도다양한소프트웨어공학이론과기술들을습득할수있도록추적성분석, 테스팅등소프트웨어공학교육에필요한내용들이포함및추가되어있으며, 수업의주제에따라지속적으로개선가능하다. OOPT는개발도중요구사항변경, 프로젝트환경의 그림 5 OOPT 의 stage 1000 activities Fig. 5 Stage 1000 activities of OOPT
514 정보과학회논문지제 44 권제 5 호 (2017. 5) 표 1 Stage 1000 activity 들의명세 Table 1 Description of stage 1000 activities Step Activity description Principal Output 1001. 1002. 1003. 1004. 1005. 1006. 1007. 1008. 1009. 1010. Write a draft plan (e.g. schedule, budget, etc.) Write an investigation report (alternatives, needs, risk, etc.) Write a requirement specification Dictionary of terms and any associated information Develop a prototype system (optional) Write the business use cases Identify business concept in the target domain Construct a rough preliminary system architecture Define test case of the system Refine the draft project plan Draft project plan Investigation report Requirement specification Term dictionary Prototype product Business use case diagram, description Business concept model A draft system architecture System Test Cases Refined project report Activity 1002는우리 ( 학생팀 ) 가왜이소프트웨어를직접개발해야하는가에대한당위성을비즈니스관점에서분석해보는단계로서, 보통의소프트웨어개발프로젝트에서는다루지못한내용을다수포함한다. Activity 1003에서는기능 / 비기능요구사항들을도출해내며, 필요한경우프로토타입을가볍게개발해볼수도있다 (1005). Activity 1007은 1003에서개발한요구사항들을상위수준의유스케이스와매핑하는단계로서, OOPT에서가장중요한시작점이된다. OOPT는각요구사항과유스케이스가 1:1 관계를이루도록하며, 유스케이스를구체적으로자세히개발하지않고시스템요구사항수준으로만한정한다. 현재단계의유스케이스들은시스템을표현하는상위수준의유스케이스로써이후과정을진행하면서상세히정의하고, 작성하는과정을거쳐디자인에사용된다. 시스템시험 (1009) 계획서도 Stage 1000에서도출되어야하는중요한산출물중의하나이다. 요구사항분석이막완료되어서개발자가개발할시스템의요구사항에대해잘기억하고있는이시점에서시스템테스트케이스 ( 및계획서 ) 를개발하는것이중요하다. 1010 단계를거쳐서최종적으로 프로젝트개발계획서 가완성되며, 이문서를기반으로 보스 를설득하기위한 발표자료 를만들게된다. 실제수업에서는기술적인내용을전달하는 technical presentation이아닌, 상대방 을기술적으로설득하는 business presentation을하도록지도한다. 이를통해졸업후입사했을때, 주어진업무만을수행하면되는일반사원이아닌새로운과제를만들어내야하는관리자 (Manager) 가갖추어야할덕목들을미리체험해볼수있게하는것이이단계의중요한목적중의하나이다. 3.2 Stage 2000: Build 프로젝트개발계획서 가완성되고, ( 가상의 ) 보스로부터과제승인을성공적으로획득했다면, 이제구체적으로소프트웨어개발을시작할수있다. Stage 2000 Build 는다음과같이여러사이클로구성될수있으며, 각사이클은온전한 6개의페이즈로구성된다. 다음표 2와그림 6은 stage 2000의각 cycle 항목에대한설명및그림이다. 반복은각단계들이페이즈별로반복되어진행된다. 표 2 Stage 2000 cycle 들의명세 Table 2 Description of stage 2000 activities Step Activity description Principal Output 2010 Refine or modify the plan Revised plan 2020 Synchronize the plan activity synchronized plan 2030 Analyze the system Sequence diagram, etc. 2040 Design the system Class diagram 2050 2060 Construct the class, method, GUI etc. Execution the tests of each activities Implementation Testing reports 그림 6 OOPT 의 stage 2000 cycle Fig. 6 Stage 2000 activities of OOPT Stage 2010 Revise plan과 2020 Synchronize Artifacts는이전사이클을완료한후, 수정이필요한내용이확인되면, 이를각단계의내용들에게일괄적으로반영하는단계이다. 실제적인개발은 2030 Analyze부터시작하여 2040 Design, 2050 Construct 및 2060 Test 단계로폭포수모델과같이순차적으로분석, 디자인, 구현, 테스팅이진행된다. 각단계는보다구체적인 Activity 들로구성된다. 3.2.1 Stage 2030: Analyze 실제적인개발의첫단계인 Stage 2030 Analyze는 9 개의순차적인 Activity로구성되어있다. 대부분의전산
OOPT: 소프트웨어공학교육을위한객체지향소프트웨어개발방법론 515 그림 7 OOPT 의 stage 2030 activities Fig. 7 Stage 2030 activities of OOPT 표 3 Stage 2030 activity 들의명세 Table 3 Description of stage 2030 activities Step Activity description Principal Output 2031 2032 Add event flows to business use case Validate and modify the use case diagram Essential use cases Refined use case diagram A conceptual class 2033 Define domain concept model diagram 2034 List and refines all the terms A refined dictionary 2035 2036 2037 2038 2039 Illustrates events from actors to systems Define contracts for system operations A sequence diagram Operation contracts Describes all possible states of the system, use cases, or A state diagram objects Refine system test plan and case Analysis the connection of results in 2030 step Refined system test plan Traceability analysis results 학과소프트웨어개발수업 / 프로젝트는이단계에서부터시작하거나이단계결과물의많은부분을제공한후시작하는경향이있다. 해당페이즈는대상시스템 ( 프로그램 ) 과사용자간의상호작용의관계에대한동작을포함하여시스템의기초적인동작이나, 구성에대해분석하는단계이다. 그림 7과표 3은 stage 2030의 Activity 및명세에대한그림과표이다. 먼저 2031 Define Essential Use Case부터시작하여기존의 1007에서개발했던 Business Use Cases를보다많은정보를담고있는 Essential Use Case로확장한다. Class Diagram의원형을개발 (2033) 한후에는, 가장중요한작업인 System Sequence Diagram (SSD) 을정의하게된다 (2035). SSD는시스템수준으로작성된 Sequence Diagram으로서, 개발할소프트웨어시스템은블랙박스로간주한후, 이의입출력만을활용하여외부액터와개발할시스템간의 event sequence를찾는작업이다. SSD는 2031의 Essential Use Case 별로작성되며, 최종완성된 System Sequence를모아서, 개발할시스템이제공해야할 system operations으로정의한다 (2036). Activity 2039는각요구사항부터유스케이스, 시스템동작등의도출 / 연결관계를모두분석해서시각적으로표현하는단계이다. 이와같은추적성분석은개발이완료되는테스팅단계 (2060) 까지지속적으로반복해서수행된다. 추적성분석을통해요구사항부터테스팅까지시각적으로구현되는관계를파악해수정사항혹은문제점발생시이를쉽게파악하고수정하는데도움이될수있다는장점이있다. 3.2.2 Stage 2040: Design 2040 Design 단계에서는 2030 Analyze에서분석한내용들을보다구체화하여, 구현을시작하는데필요한모든정보를완성 / 준비하는것을목표로한다. Stage 2040 단계에대한구성은그림 8과표 4에나타나있다. 먼저개발할소프트웨어의 GUI/UI를고려하여 2031의 Essential Use Case를 Real Use Case로확장 (2041) 한후, 다양한 UML Diagram을활용하여클래스다이어그램을온전하게완성한다. Sequence Diagram, Collaboration 그림 8 OOPT stage 2040 activities Fig. 8 Stage 2040 activities of OOPT 표 4 Stage 2040 activity 들의명세 Table 4 Description of stage 2040 activities Step Activity description Principal Output 2041 Define Real Use Cases Real use cases 2042 2043 2044 2045 2046 2047 Design UI component and storyboards Refine draft system architecture UI concept Package diagram Illustrate how objects interaction diagram interactions via messages Describes details in conceptual class diagram Analyze the connection the results of 2040 steps Design database, table, and records Class diagram Traceability analysis result A database schema
516 정보과학회논문지제 44 권제 5 호 (2017. 5) Diagram 및 Statecharts Diagram 등은모두클래스다이어그램의내용들을채우기위해사용되는것으로서, 유스케이스당다수개의다이어그램을그림으로써 ( 분석함으로써 ), 정의된오브젝트 ( 클래스 ) 간에어떤커뮤니케이션과데이터가필요한지확인하고, 또필요한정의를추가하게된다. 2040 Design 단계에서는 GUI에대한충분한고려를통해, 2050 Construct( 개발 ) 단계에서있을수있는디자인-구현간의 Semantic Gap을최소화해야한다. JAVA나 Visual C++ 등을통해개발하는소프트웨어는 GUI를포함하는것이일반적이며, 그래픽관련부분은 2030 Analyze 단계에서고려되지않는다. 따라서, 2040을통해컨트롤러나 main GUI 등의 Interface/Abstract 클래스를가상으로구성한후, 실제구현에서는실사용한라이브러리함수와연결시켜주는작업이추가적으로요구된다. 이는 2044에서정의하는 Sequence Diagram을통해분석되며, 최종적으로 2045 Design Class Diagram에반영된다. 필요에따라서 data-flow diagram이나 flow-chart 등을이용해추가적인명세를하는것이디자인에유리할수있다. Activity 2046에서는이전 stage들과마찬가지로추적성분석을수행한다. 2040 stage에서수행하는추적성분석은이전과정을거치며분석한내용들이클래스다이어그램으로연결되는관계를분석해서시각적으로표현하는작업을수행한다. 3.2.3 Stage 2050: Construct 2050 Construct 단계는 2040의최종산출물인 Class Diagram을기반으로실제프로그램코드를작성하는단계로실제로구현할클래스와 method 정보를이용해단위시험테스트케이스작성하는과정까지포함된다. 다른단계에비해적용되는기술 / 기법이없는데, 이는프로그램개발 ( 코딩 ) 은개발자의능력에크게의존하는특성에기인한다. 중요한점은, 2040 Design 단계의다양한산출물들을활용하여, 다른개발자가독립적으로문제없이구현을완료할수있어야한다는점이다. 개발자가클래스다이어그램을구성하는함수들의실제내용을구성할때, 2041 Real Use Case와 2044 Interaction Diagram 등을참고하며, 이들에구현에필요한충분한내용이포함되어있어야한다. 표 5와그림 9는 OOPT 2050 stage의활동들에대해설명한그림이다. 2051 단계는클래스를구성하는함수들을구현할때, 함수의동작원리 / 내용 / 알고리즘등을포함하는간략한명세서를포함하도록하고있으며, 이는 2055 Unit Testing 용테스트케이스를개발할때, 유닛에대한명세서로서활용될수있다. 2052 단계는이전단계에서작성한 UI story board를기반으로하여 GUI를통한사용자와시스템간의실제상호작용에대해정의하고, 클래스및 표 5 Stage 2050 activity 들의명세 Table 5 Description of stage 2050 activities Step Activity description Principal Output 2051 2052 2053 Implement class & Class & Methods methods by class diagram description Define relations between GUI and operation Refined and implement the reports again GUI implements results and description, refined class diagram Analysis, design step reports 2054 Implement DB Schema DB scheme 2055 Writing test code for unit testing Unit test code 그림 9 OOPT stage 2050 activities Fig. 9 Stage 2050 activities of OOPT method를연결하는작업이다. 2052 activity의작업을통해서 UI 구성에대한명세서를작성하게된다. 2050 단계에서는이전단계들의결과를통해구현하는단계로따로추적성분석을수행하지않는다. 3.2.4 Stage 2060: Testing Stage 2060 단계에서는앞에서준비한각테스팅계획서에의거해서해당수준의테스팅을진행한다. Stage 2060 단계에서진행되는테스팅종류는총 6 가지로구성되어있지만, 대학수업에서는일반적으로단위시험 (Unit Testing) 과시스템시험 (System Testing) 이사용된다. 이외의다른테스팅은생략되는것이일반적이다. 다음그림 10 및표 6은 OOPT의 2060 stage의활동들에대한설명이다. 단위시험은이전 stage에서작성한단위시험코드 (Unit Testing Code) 를이용하여수행한다 (2061). 시스템시험은이전단계들에서정의한시스템시험계획 (System Testing Plan) 에실질적으로테스팅을수행하기위한테스트데이터 (Test Data) 를생성하고, 수행하게된다 (2063). 특이한점은, 최종적으로 2067 Testing Traceability Analysis를수행하는것이다. 요구사항명세서의요구사항과유스케이스부터시작해서, 해당되는 Code/Class 및해당되는단위 / 시스템테스트케이스를모두연결하여시각적으로보여주는작업이다. 이작업을통해, 전방 / 후방의추적성분석을충분히수행할수있다.
OOPT: 소프트웨어공학교육을위한객체지향소프트웨어개발방법론 517 그림 10 OOPT Stage 2060 Fig. 10 Stage 2060 activities of OOPT 3.3 Stage 3000: Deployment Stage 2000 Build에서다수의 ( 보통대학수업에서는 3회정도 ) cycle을수행한후에는최종적으로 Stage 3000 Deployment를수행한다. 이는개발한프로그램을고객의특성에맞게부분수정한후개발을완료하는것을의미한다. 예를들면, 국내핸드폰개발사에서새모델을개발한경우, 기본적인기능은같지만, SKT, KT 등의 표 6 Stage 2060 activity 들의명세 Table 6 Description of stage 2050 activities Step Activity description Principal Output 2061 Unit Testing Unit testing reports 2062 Integration Testing Integration testing reports 2063 System Testing System testing reports 2064 Performance Testing Performance testing reports 2065 Acceptance Testing Acceptance testing reports 2066 Documentation Testing Testing reports 2067 Testing Traceability Analysis Traceability reports 통신사에맞게로고나화면, 음악, 통신사전용프로그램등을추가적으로설치해야하는데, 이작업은 Deployment 에해당된다. 따라서, 대학수업에서는이단계를수행하지않는다. 4. 사례연구 아래의표 7은건국대학교컴퓨터공학과의소프트웨어공학관련수업 ( 소프트웨어모델링및분석 ) 수업에서 Year Subject Description 2010 2011 2012 System for service OOO coffee maker OOO data management system 2013 OOO Painter 2014 2015 2016 OOO elevator simulator OOO child English learning program OOO Clone Checker 표 7 OOPT 를이용해진행한프로젝트명세 Table 7 Description of projects with OOPT Develop the system for services. Develop the coffee maker system. Develop the specific data management system. Develop the specific-verifiable painter program. Develop the simulator which is able to show operation (control) of the elevator. Develop the English learning program which is able to show characteristics of each team for children. Read 40 programs written in the C language and find the replication programs (This project does not use compiler techniques). Team Subject (selected by each team) - Safety web mail system - Smart DJ coffee maker - Customized coffee maker, Etc. - Selectable parking navigation system - ASSIO data management system, Etc. - Children education paint - VAT paint, Etc. - RE-ason Elevator Control simulator - No Wait ECS, Etc. - TALKIDS - English education for kids (Sound), Etc. - Pleasant Clone Checker - One More Chance, Etc. Specification OOPT had lack of the process about considering of GUI, while the focus of the project was GUI. We modify the OOPT process to consider GUI implementation. This project made confusion between elevator operation algorithm and elevator simulation. Educating the importance of requirements analysis was possible. GUI was still difficult to design in OOPT. Opinions that writing document needs too many effort existed. This project did not fit the OOAD because clone checking algorithm is the main issues.
518 정보과학회논문지제 44 권제 5 호 (2017. 5) OOPT를활용하여진행한팀프로젝트를소개한다. 다양한주제로진행되어왔으며, OOAD 방법론인 OOPT 에적합한주제도있었으나, 적합하지않은주제들도수행하였다. 표 7에나타난바와같이해당수업을통해 coffee maker system 부터 clone checker 까지매년주제를변경해가면서프로젝트수업을진행하였다. 2013년도에진행한 OOO Painter 프로젝트는학생팀별로특정한내용을갖는그림판을 OOPT를통해개발하는프로젝트이었다. 이경우그림판에대해분석, 디자인, 개발하는데 GUI가중심이되어야하는점에반해 OOPT가상대적으로 GUI 표현이약한점을파악하게되어보완할수있는기회가되었다. 2014년도에수행했던 OOO elevator simulator 프로젝트는엘리베이터컨트롤러를시뮬레이션할수있는프로그램개발을목표로진행을하였는데, 많은학생들이요구사항을명확히분석하지않아구현단계에서많은어려움을겪는등요구사항분석의중요성을학생들에게전달할수있는프로젝트였다. 이처럼다양한주제를변경해가며프로젝트를진행하고, 학생들의의견을수렴하면서 OOPT에대해보완작업을진행하고사례연구를수행하였다. 4.1 사례연구 : OOO Clone Checker 2016년에진행했던 OOO Clone Checker 는 C 언어코드를입력으로받아서유사도를검사하는프로그램을개발하는프로젝트로 OOPT를활용해진행하였다. 각팀별로유사도를검사하는알고리즘, 시각화하기위한방법등에대해주제를정해수행하였다. 프로젝트의진행은총 6번의결과보고서제출및발표를거쳐진행되었다. 진행순서는 OOPT의 Stage 1000, 2030, 2040, 2050/60 및 2 nd cycle, 3 rd cycle 순으로진행하여 OOPT의개발과정을거치고반복적 (iteration) 으로진행하는특징을경험할수있도록진행되었다. 그중하나에대해설명하면다음과같다. 해당팀은 쾌적한 을주제로 쾌적한 Clone Checker 를목표로프로젝트를수행하였다. 쾌적한 의정의는기능 / 비기능요구사항에대한정의가모두포함되어 비교작업과결과출력의쾌적함으로 정의하고, 몇초이내의비교시간및여러개의파일의결과를디스플레이를통해쾌적하게보여주는것을목표로하였다. 해당프로젝트팀은반복적인 cycle을진행하는 OOPT 에따라각 stage를여러번반복하여진행하였다. Stage 1000단계는 7번, 2030 분석단계는 5번, 2040 디자인단계는 4번마지막 2050, 2060 단계는총 3번의반복을진행하였으며, 이는일정이진행되면서다음단계를수행하고, 다시반복하는과정을거쳐진행하였다. OOPT stage 1000을거치며 22개의 functional requirements와 4개의 non-functional requirements를개발하고 이에맞추어 use-case diagram을작성한것을확인할수있다. 또한 stage 2030, 2040을거치며 essential use case, real use case 정의및 system sequence diagram, interaction diagram등을통해최종적으로 class diagram 을개발한것을확인할수있다. 그림 11은각 stage의주요결과물들중일부에대한화면으로각각위에서부터유스케이스다이어그램, 추적성분석결과이다. Stage 2050, 2060 은각각구현및테스팅에관련된 stage 들로써최종적으로테스팅을거쳐구현이완료된다. 그림 12는 2050, 2060 단계를거쳐작성한테스트케이스및최종적으로구현된프로젝트의화면이다. 하지만 OOO Clone Checker 프로젝트의경우에는프로젝트의주된이슈가 clone checking이기때문에내부알고리즘디자인, 데이터흐름, 기능흐름등을정의할수있는 activity가있으면더좋을것같다는의견이있었다. 각 stage들간의연관성을고려해문서작업을효율적으로할수있으면좋을것같다는의견도확인할수있었다. 또한학생들의프로젝트결과에서추적성분석이시스템의흐름, 연결관계를효과적으로파악하는데도움이되지만, 시스템이복잡해지고프로세스가진행되면서많은데이터가추가되는경우시각적인분석이쉽지않게된다는문제도확인할수있었다. 4.2 OOPT 개선방향에대한고찰소프트웨어공학수업을위해개발된교육용개발방법론인 OOPT는해당수업에서강조하는내용 / 기법에따라다양한 branch를만들어활용할수있다. 그림 13은소프트웨어개발생명주기에따라 OOPT를통해개선하거나변경시켜적용할수있는방법들에대한예제이다. 개선및변경을위해디자인 / 구현에집중하여디자인시구조를강조하거나, GUI 혹은알고리즘에집중할수있는사항들에대해추가적인프로세스를도입하는등의방법을생각해볼수있다. 또는 V-모델을고려하여테스팅을강조하는방향이나전체적인추적성을강조하는방향도생각해볼수있다. 또한개발생명주기전체적으로생각해서오픈소스를활용하거나, 오픈소스프로젝트기반, 오픈소스개발기반혹은전반적인 co-operation 을고려하는방향으로도개선및확장을생각해볼수있다. 이처럼각수업의주제에맞도록여러방향으로개선된프로세스를통해다양한주제의소프트웨어공학교육을할수있을것으로생각된다. 5. 결론및향후연구본논문에서는건국대학교컴퓨터공학과에서소프트웨어공학관련수업에서사용중인객체지향소프트웨어개발방법론인 OOPT를자세히소개하고, 지난 10년동안 OOPT를활용해수행한프로젝트들을소개및분석
OOPT: 소프트웨어공학교육을위한객체지향소프트웨어개발방법론 519 그림 11 각 stage 별활동의주요결과화면 ( 유스케이스, 추적성분석결과 ) Fig. 11 Screen dumps on results of OOPT stages (use case diagram, traceability analysis) 그림 12 쾌적한 clone checker 테스트케이스및최종산출물 Fig. 12 A screen dump of the test case and the clone checker s final output
520 정보과학회논문지제 44 권제 5 호 (2017. 5) 그림 13 소프트웨어생명주기별 OOPT 개선방향및방법예제 Fig. 13 Example of OOPT improvement methods in accordance with the software lifecycle 하였다. OOPT는다양한단계와 cycle을갖도록구성되며, 소프트웨어공학관련교육을위해요구사항정의부터다양한내용이포함되어있다. 또한수업을통해진행한프로젝트들을바탕으로교육에도움이될수있는개선및활용방안에대한분석도개진하였다. OOPT 또는다양한객체지향소프트웨어개발방법론이발전 / 개발되어, 소프트웨어공학교육에효과적으로사용되기를기대한다. 향후본논문에서소개한여러개선방향들을이용해 OOPT를학부 / 대학원수업등을통해지속적으로보완할계획이다. 또한추적성분석과관련해효과적인시각화및적용방법에대한연구와프로세스를진행하며수행되는여러작업들의문서화에대해노력을줄일수있는방법을보완할계획이다. References [1] P. Naur, B. Randell, "Software Engineering: A Report on a Conference Sponsored by NATO science Committee," NATO, 1969. [2] Winston W Royce, "Managing the development of large software systems," Proceedings of IEEE WESCON, Vol. 26, No. 8, pp. 328-338, 1970. [3] Ian Sommerville, "Software Engineering," Addison- Wesely, Boston, 2007. [4] FA Masoud, MU Shaikh, SH Mustafa, "SASD methodology from a practical point of view problems and suggestions for improvement," WIT Transactions on Information and Communication Technologies, Vol. 17, pp. 93-102, 1997. [5] Grady Booch, "Object-oriented Analysis and Design with Applications 3rd edition," Addison-Wesley, Boston, 2007. [6] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen, "Object- Oriented Modeling and Design," Prentice Hall, New Jersey, 1990. [7] L. Jacobson, "Object-Oriented Software Engineering: A Use Case Driven Approach," Pearson Education, India, 1993. [8] Derek Coleman, Patrick Arnold, Stephanie Bodoff, Chris Dollin, Helena Gilchrist, Fiona Hayes, Paul Jeremaes, "Object-oriented development: the fusion method," Prentice-Hall, Inc, 1994. [9] Boehm B, "A Spiral Model of Software Development and Enhancement," IEEE Computer, Vol. 21, No. 5, pp. 61-72, 1988. [10] Per Kroll, Philippe Kruchten, Grady Booch, "The Rational Unified Process Made Easy a Practitioner s Guide to the RUP," Addison-Wesley, Boston, 2003. [11] Philippe Kruchten, "The rational unified process: an introduction," Addison-Wesley Professional, Boston, 2004. [12] Michael Halling, Wolfgang Zuser, Monika Kohle, Stefan Biffl, "Teaching the Unified Process to Undergraduate Students," IEEE 15th Conference on Software Engineering Education and Training, pp. 148-159, 2002. [13] Jiang Li, "Teaching unified process in software design and development courses - A case study," Journal of Computing Sciences in Colleges, Vol. 24, No. 5, pp. 5-11, 2009. [14] Wilson P. Paula Filho, "An Educational Software Development Process," Proc. of the International Conference on Computer Science, Software Engineering, Information Technology, E-Business and Applications, 2002. [15] Wilson P. Paula Filho, "Requirements for an Educational Software Development Process," ACM SIGCSE Bulletin, Vol. 33, No. 3, pp. 65-68, 2001. [16] P. Runeson, "Experience from teaching PSP for freshman," Proc. of the 14th conference on Software Engineering Educational and Training, pp. 98-107, 2001. [17] N. Davis, J. Mullaney, "The Team Software Process(TSP) in Practice: A Summary of Recent Results," Technical Report CMU/SEI-2003-TR-014, Software Engineering Institute, 2003. [18] G. Kelecic, Z. Car, "Teaching Software Process: An Experience in Implementing RUP in a Student Project," Proc. of the 8th International Conference on Telecommunications, pp. 479-484, 2005.
OOPT: 소프트웨어공학교육을위한객체지향소프트웨어개발방법론 521 정세진 2015년건국대학교컴퓨터공학과졸업 ( 학사 ). 2016년건국대학교컴퓨터정보통신공학과졸업 ( 석사 ). 2016년~현재건국대학교컴퓨터정보통신공학과박사과정. 관심분야는소프트웨어공학, 위해도 / 안전성분석 이동아 2010년건국대학교컴퓨터공학과졸업 ( 학사 ). 2012년건국대학교컴퓨터정보통신공학과졸업 ( 석사 ). 2012년~현재건국대학교컴퓨터정보통신공학과박사과정. 관심분야는정형검증, 소프트웨어확인및분석, 위해도분석 김의섭 2012년건국대학교컴퓨터공학과졸업 ( 학사 ). 2015년건국대학교컴퓨터정보통신공학과졸업 ( 석사 ). 2015년~현재건국대학교컴퓨터정보통신공학과박사과정. 관심분야는소프트웨어공학, 정형검증 장천현 1979년 KAIST 전산학전공졸업 ( 석사 ) 1988년 KAIST 전산학전공졸업 ( 박사 ) 1984년~현재건국대학교컴퓨터공학부교수. 관심분야는프로그래밍언어, 컴파일러, 객체지향, 실시간처리 유준범 2005년 KAIST 전자전산학과전산학전공졸업 ( 박사 ). 2008년삼성전자주식회사통신연구소책임연구원. 2008년~현재건국대학교컴퓨터공학부부교수. 관심분야는소프트웨어공학, 안전성분석, 정형기법