부록 a UML with StarUML
부록 a - UML a.1 UML (Unified Modeling Language) 계획 (planning)-분석(analysis)- 설계 (design)-구현(implement)- 테스트 (test)-유지보수 (maintenance) 로시스템개발절차가수행되는시스템개발생명주기 (SDLC, System Development Life Cycle) 는어떠한시스템을제작하더라도일반적으로적용될수있는절차이다. 건축물을구축하는절차도 SDLC를적용한다. 건축계획을세우고설계를한다음실제공사를진행하는구현절차가진행된다. 건축물을계획하고분석하며설계하는과정에서설계도라는산출물을만들어낸다. 건축물의설계도란외관을나타내는설계도, 평면도, 토목설계도, 설비설계도, 전기설계도등의다양한설계도면으로구현하고자하는건축물의형태를정의한다. 소프트웨어시스템의설계도이와같다. 객체지향방법론으로구현하고자하는현실세계의시스템을분석하고, 이를설계도로나타내는데일반적으로통합모델링언어 (UML, Unified Modeling Language) 를사용하여소프트웨어시스템에대한다양한관점의설계도를산출한다. UML (unified modeling language) UML(unified modeling language) 이란객체지향방법론을적용하여개발하는정보시스템에대한 SDLC를적용해나가며그결과를모델또는설계도로나타내기위한모델링언어를말한다. 1980년대중반부터활발히연구되었던객체지향방법론은그래디부치 (Grady Booch), 제임스럼바 (James Rumbaugh), 이바야콥슨 (Ivar Jacobson) 등의선구자에의해 OOD/Booch, OMT, OOAD, RDD, GOOD, HOOD, OOSD, OOJD 등과같은다양한방법론과표기법이 50여개이상존재하였다. 이중에서 Booch의방법론과 Jacobson의 Objectory 및 Rumbaugh의 OMT가가장주목을받았으며, 이들의방법론을통합하여현존하는객체지향분석및설계방법론을완성하고, 이를 Rational Unified Process(RUP) 또는 Unified Software Development Process(USDP) 라고호칭하였다. RUP 등은 1997년에 Object Management Group(OMG, www.omg.org) 에의해통합되어 UML로명명되고 version 1.0이발표되었고, version 2.0까지발표되었다. UML은객체지향개념이나철학또는절차를명시하는객체지향방법론이아닌단지객체지향방법론의결과로산출되는정보시스템을모델링하는도구또는언어이다. 따라서인간세상의언어가그러하듯표준화가상당히중요한과제이기에 OMG에의해범세계적인표준을유지하고있다. 또한백문이불여일견 ( 百聞이不如一見 ) 이기에 UML의표기법은그래픽 (graphic) 중심으로나타낸다. UML은 OMG에의해지금도진화가되고있다. 즉, 건축기술이발달함에따라설계도
에나타내는표현법이계속추가되듯이소프트웨어시스템의설계도를나타내는 UML도발전적진화를계속하며변화되고있다. 현재 OMG에서발행한 UML 매뉴얼은거의 600여페이지가넘는다. 직업적인전문가가되기이전에이를모두다습득한다고하는것은어려운일이다. 이는마치한국어나영어가수십만단어로구성되어있지만, 현실세계의우리는수백또는수천의단어로도훌륭히의사소통이가능한것과마찬가지이다. 이러한진화와변경의과정에서도이제까지제시되었던핵심적인개념과표현법은변화되지않고다만추가적인, 세분화된표현법이지속적으로개발되고추가되고있다. 따라서지엽적인, 보다세부적인 UML 표현법을모두본교재에서다루기는힘들기에핵심적이고본질적인표현법을다루기로한다. UML의작성절차 UML의작성과정은객체지향방법론이그러하듯밀러의법칙 (Miller's law) 에기반을둔반복과점증 (iterative and increment) 의원칙을따른다. UML의작성은처음부터완벽한버전을만들려고하기보다는초기버전은시스템에대한최초인식을바탕으로최적의 UML을생성한후, 실세계에대한좀더세밀한분석을통해더많은지식을추출하고, 이를바탕으로좀더정확하고 (accurate, iteration) 확장된 (extend, increment) 버전을만들어간다. 즉, 모든것을한번에, 동시에생각하는것보다밀러의법칙에기초하여한번에예닐곱개 (magic number seven plus minus two) 의영역 (chunk) 으로문제를구분하고분석하여 UML을작성한다음, 다음단계에서각각의영역에대한분석을통해더많은지식을습득하고이를 UML에반영하여수정하는단계별세분화 (stepwise refinement) 과정으로진행하는것이 UML 개발을쉽게할수있는방법이다. StarUML < 그림 a1-1> StarUML 로고 본교재에서는 UML의작성도구로서소스가공개된 StartUML(www.starUML.com) 을사용한다. StartUML 은 Win32 플랫폼에서운영되는공개된무료패키지로서, OMG의 UML 2.0을지원하는 UML/MDA(Model Driven Architecture) 플랫폼을지원하여 UML을보다쉽게작성할수있는도구이다. StartUML 의통합개발환경 (IDE, integrated development environment) 은 < 그림 a1-2> 의모델탐색기에서나타낸바와같이객체지향 < 그림 a1-2> 모델탐색기방법론에의한정보시스템개발제단계에서나타내는각종모델을지원한다. 객체지향소프트웨어는사용사례지향 (use-case driven) 또는모델지향구조 (model driven architecture) 이기에 StarUML 도이들의절차를지원한다. 즉, 사용자가인식또는기대하는시스템의
부록 a - UML 서비스를파악하는 <<use case model>> 의작성을시작으로, <<analysis model>>, <<design model>> 및 <<implementation model>> 을작성하여시스템을설계및구현하고, 이를서버에배포하여실현하는 <<deployment model>> 의작성을지원한다. 이를다시 StartUML 을이용하여객체지향분석과설계절차에서산출되는다이어그램을다이어그램탐색기로구분하면 < 그림 a1-3> 과같다. 객체지향요구분석모델 (object-oriented requirement analysis model) 정보시스템으로구축하고자하는문제영역 (problem domain) 에대한객체지향방법론의관점은실세계를 협업하는객체들이지원하는사용사례의집합 (a set of use cases that are supported by a set of collaborating objects) 으로정의된 < 그림 a1-3> 다이어그램탐색기다. 이를개념화하면 < 그림 a1-4> 와같다. 좌측은복잡한제품의생산프로세스를나타내는그림이며, 이를객체지향방법론에서는중앙의그림과같이상호협력하는객체들로나타낸다. UML 모델이란 < 그림 a1-4> 의우측그림처럼협업하는객체들을객체들의구조적인면 (object structure) 과객체들의행위적인면 (object behavior) 으로설계하되, 기업모델링 (enterprise modeling)- 비즈니스영역분석 (business area analysis)- 시스템디자인 (system design)- 구축 (construction) 등으로하향식 (topdwon) 으로세분화하는것이라할수있다. < 그림 a1-4> 객체지향요구분석모델개념도 < 그림 a1-3> 에서예시된각각의다양한다이어그램이 < 그림 a1-4> 의개념도와같이 정보시스템의구조와행위를체계적으로나타내도록활용되는관계는 < 그림 a1-5> 와같다.
< 그림 a1-5> UML 산출물의관계도 객체지향요구분석모델 (object-orient requirement analysis model) 은구축하고자하는문제영역 (problem area), 즉실세계 (real world) 에대해기능적모델 (function model), 구조적모델 (structural model) 및행위모델 (behavioral model) 등과같이 3 가지관점에서모델링한다. 개발될시스템에대한사용자가기대또는요구하는기능을나타내는기능적모델은사용사례다이어그램 (use case diagram) 로나타내며, 이는외부의사용자에의해발생되는이벤트 (event) 에기반을둔다. 문제영역에서발견되는클래스들의정적인구조 (static structure of classes) 를나타내는구조적모델은클래스다이어그램 (class diagram) 으로나타낸다. 기능모델과구조모델을기반으로세분화하여구현을위한행위모델을개발한다. 행위모델이란사용사례를지원하기위한클래스들의동적인행위와오퍼레이션 (dynamic behavior and operation) 을나타내는상호작용다이어그램 (interaction diagram) 또는순서다이어그램 (sequence diagram) 로모델링한다. 이들다이어그램간의관계가 < 그림 a1-5> 에예시되어있다. 이벤트 (events) 로부터개발한사용사례다이어그램과사물 (things) 에서부터출발한클래스다이어그램은프로그램코드를개발할수있는기반인순서도를개발하기위해필요한보조적다이어그램을개발한다. 다이어그램를구체화하기위해각다이어그램에대한구체적인수행절차를개발하기위해사용사례기술서 (use case description) 또는활동다이어그램 (activity diagram) 를개발한다. 또한주요한클래스의상태변화를살펴보기위해상태다이어그램 (statechart diagram 또는 state machine diagram) 을작성한다. 이들보조다이어그램들은순서다이어그램을개발하기위해중간단계로개발하는것이다.
부록 a - UML a.2 사용사례다이어그램 (use case diagram) 개발될시스템에대한사용자의기대또는요구하는기능을나타내는사용사례다이어그램 (use case diagram) 은정보시스템의기능적모델을나타낸다. 행위자 (actor) 와사용사례 (use case) 가주요구성요소인사용사례다이어그램은다음과같은두가지관점을나타낸다. o 사람이관여하고 (person involved) o 그사람이시스템을사용한다 (the person uses the system). 즉, 사용사례다이어그램은사용자의다양한역할과역할에따라시스템을어떻게사용할것인가를나타낸다. 달리설명하면시스템이어떻게사용될것인지를규명하고, 이를모델링하는것이다. 복잡한시스템은사용사례다이어그램을하나로구성할수없다. 이경우, 행위자별로또는하위시스템 (subsystem) 별로사용사례다이어그램을별도로작성한다. 사용사례도의기본구성사용사례다이어그램은정보시스템과정보시스템을이용하는사용자 (users) 간의상호작용 (interaction) 을나타낸다. 사용사례다이어그램의최소한의기본구성은 < 그림 a2-1> 과같이행위자 (actor), 사용사례 (use case) 및관계 (association) 를나타내는그래픽개체로나타낸다. < 그림 a2-1> 은현금인출기 (ATM, automatic teller machine) 에대한사용사례도의예이다. 즉, 시스템을사용하는외부행위자인고객 (customer) 은 ATM 에대해거래내역확인 (retrieveaccountdetails), 출금 (withdrawcash), 입금 (depositcash) 및송금 (transfercash) 을행할수있기를기대하며, ATM은이러한요구사항을충족할수있는기능을보유한시스템으로제작되어야함을나타낸다. < 그림 a2-1> ATM 에대한사용사례도의예 n 행위자 (actor) 행위자 (actor) 는시스템외부존재하는개체로서사용자 (user) 또는시스템을시작시키는발기인 (initiator) 의역할 (role) 을담당하며, 다음과같은역할을한다. - 행위자는시스템에대해한가지이상의역할을담당할수있다. < 그림 a2-2> 은고객입장에서바라본은행 (bank) 에대한사용사례도의예이다. 이경우,
은행의고객 (customer) 은예금자 (depositor) 의역할도하며또한대출자 (borrower) 의역할도 담당한다. - 행위자는복수개의사용사 례와상호작용할수있다. < 그림 a2-2> 은행의사용사례도의예 즉, 고객은거래내역확인사용사례 (retrieveaccountdetails use case) 부터이자납입 (payinterestonload use case) 에대해상호작용한다. - 행위자는항상사람일필요는없다. 해당시스템의서비스를사용하는다른시스템이될수도있다. - 행위자는일반화 (generalization) 될수있다. < 그림 a2-2> 에서예금자 (depositor) 와대출자 (borrower) 는모두은행에대한고객이기에보다일반화된개념인고객 (customer) 으로일반화될수있다. 실세계의은행시스템이 < 그림 a2-2> 와같이단순하지않고수백, 수천가지의서비스를제공해야하는것은고객만이행위자가아니라은행에대한모든이해관계자 (stakeholder) 를역할별로구분하여그들이요구하는모든서비스를제공해야하기때문이다. n 사용사례 (use case) 사용사례 (use case) 는시스템의행위를나타내는것으로서타원에행위를나타내는사용사례이름과함께표현된다. 각각의사용사례는서로독립적인한가지사례를나타내기에사용사례이름을구체적인행위를나타내는동사 (verb) 와그행위가행해질구체적인대상체 (object) 를나타낼수있도록 verb+object 로나타내야한다. n 관계 (association) 사용사례다이어그램을구성하는행위자 (actor) 는다른행위자와관계 (association) 가있을수있으며, 사용사례 (use case) 는다른사용사례와관계가있을수있다. 또한행위자와사용사례사이에도관계가있을수있다. 관계는보다직접적으로유도관계 (directed association) 와일반화 (generalization) 로구체화할수있다. < 그림 a2-2> 에서예금자와대출자는고객과일반화관계를형성하고있다. 사용사례의확장 가장기본적인사용사례다이어그램 (use case diagram) 은행위자 (actor) 와그행위자와직접
부록 a - UML 관련있는사용사례 (use case) 를추출하는것이다. 이러한사용사례다이어그램은문제영역에대한이해를심층적으로함에따라기본적으로추출된사용사례와관계가있는추가적인사용사례를 < 그림 a2-3> 과같이추출할수있다. 기본적인사용사례가항상사용하는사용사례는포함관계 (include association) 에있다고하며, 기본적인사용사례가선택적으로사용하는사용사례는확장관계 (extend association) 에있다고한다. < 그림 a2-3> 사용사례에대한포함및확장관계의예 n <<include>> 관계 포함관계 (include association) 는하나의사용사례가다른사용사례의서비스를활용할때표현된다. 즉, 어떤사용사례가다른사용사례의행위를포함할때이들두사용사례간에는포함관계가형성되며, 도구상자의로나타낸다. 일반적으로포함관계에있는사용사례는복수개의사용사례에의해공통으로재사용되는경우가많다. < 그림 a2-3> 에서사용자 (customer) 가주문을하거나 (createorder), 주문을수정할때 (updateorder) 항상고객을확인하고 (validatecustomeraccount) 재고를확인하는 (checkitemavailability) 서비스가필요하다. 그러나주문을조회할때에는 (inquireorder) 고객확인서비스만필요할것이다. 이경우 checkitemavailability 및 validatecustomeraccount 는이들의서비스를사용하는사용사례에대해포함관계에있다고한다. n <<extend>> 관계 확장관계 (extend association) 는어떤사용사례가추가적인행위가필요할경우두사용사례간에는확장관계가형성되며, 도구상자의을이용하여나타낸다. 일반적으로확장관계는어떤특정조건에의해수행되는선택적행위를나타낼때활용된다.
< 그림 a2-3> 의예에서고객이주문을행할때 (createorder) 기존고객을확인하고 (validatecustomeraccount), 만약등록안된고객일경우신규고객등록 (createnewcustomer) 서비스를이용하여고객등록을행하여야할것이다. 이경우, 신규고객등록 (createnewcustomer) 서비스는주문 (createorder) 서비스에대해확장관계에있다고한다.
부록 a - UML a.3 활동다이어그램 (activity diagram) 활동다이어그램 (activity diagram) 은각각의사용사례 (use case) 또는사용사례기술서 (use case description 또는 use case scenario) 에대한비즈니스프로세스워크플로우 (workflow of business process) 를문서화하는데활용되는표준 UML2.0 다이어그램이다. 활동다이어그램은분석단계에서하나의사용사례에대한구체적인처리흐름을표현하기위해사용된다. 설계단계에서클래스의내부오퍼레이션을나타내는메서드의알고리즘이나구체적인로직을나타내는데도활용된다. 또한활동다이어그램은분석가또는디자이너가업무의흐름을분석하거나화면의흐름을디자인할때유용이활용된다. 정보시스템이란인간이행하는행동또는기업이나조직이행하는비즈니스활동을모델링하여소프트웨어시스템으로개발하는것이라고간략히정의할수있다. 이경우, 활동 (activity) 이란일련의구체적인활동또는행위 (action) 들로세분화가될수있는절차를말한다. 행위 (action) 란더이상분할될수없는 (non-decomposable) 원자성 (atomic) 을나타내는절차로정의된다. 따라서활동다이어그램이란인간의행동또는기업이나조직의비즈니스활동을행위로세분화하는데활용되는도구라할수있다. 활동과전이 (activity/action and transition) < 그림 a3-1> 은가장기본적인활동다이어그램의구조를예시한것이다. 모든처리절차에 는시작과끝이존재한다. 시작은시작점 (initialstate, 점 (finalstate, ) 으로나타낸다. 시작과종료사이에각각의처리절차를나타내는활동 (activity, ) 를표시한다. 만약선택적인활동이있다 면선택 (decision, ) 을이용하여표시한다. < 그림 a3-3> 은 Activity1 을수행한다음만약특정조건이 true 이면 Activity2 를, false 이면 Activity4 를수행한다. 마지막으 로 Activity4 를수행한다. 라고해석된다. ) 으로나타내고끝은종료 < 그림 a3-1> 활동다이어그램의예 활동들의수행되는순서는전이 (transition, 시한다. ) 로표 활동다이어그램의확장과세분화밀러의법칙이란인간이한순간에생각할수있는인지의범위가약예닐곱개라는것이다. 기본적으로활동다이어그램은사용사례다이어그램의한가지사용사례를구체적으로나타내는기능을담당하지만사용사례의한가지사용사례라는것자체가상당히추상적인개념이다.
활동다이어그램을개발하는대상이포괄적인사용사례라면수십또는수백가지의활동으로세분화될것이고, 그대상이구체적인사용사례라면몇개의활동으로표현할수있을것이다. 따라서반복과점증의원칙에따라활동다이어그램도단계별세분화 (stepwise refinement) 방식으로개발되어야한다. 즉, 초기버전의활동다이어그램은각 ActionState 가활동 (Activity) 을표현하면서시작점부터종료점까지의전체적흐름을먼저개발한이후, 각각의활동을세분화하여더이상분할 (decomposition) 할수없는행위 (Action) 로표현하는것이행위다이어그램을개발하는올바른절차이다. 활동다이어그램은개발하고자하는대상이얼마나포괄적이냐에따라물리적인크기가달라져몇페이지로개발될수도있으며, 일반적인처리절차가그러하듯반복적인루프 (loop) 도나타날수있다. 이경우, 을이용하여페이지를연결하거나, 반복점을표현할수있다. 또한수영경기장의레인을구분하듯이특정흐름에대해구분하는것이필요하다면을이용하여구획면을표시하기도한다. 어떤 ActionState 가내장된주요한하위행위를포함하고있다면이를을이용하여나타낸다. 또한조건에맞을때까지자신의행위를반복적으로수행할경우는을이용하여표시한다. 또한동시에수행할 ActionState 가있다면즉, 동기화는으로나타낸다. 프로세스가외부로부터입력장치를통해입력을받아야한다면 표현하고, 반대로외부로신호를보내는절차는으로나타낸다. 으로 활동다이어그램의사례 < 그림 a3-2> 는현금인출기 (ATM) 의입금 (deposit) 사용사례에대한활동다이어그램의예 를예시한것이다. < 그림 a3-2> ATM 의입금 (deposit) 사용사례에대한활동다이어그램의예
부록 a - UML a.2 순서도 (sequence diagram) 클래스다이어그램 (class diagram) 은객체지향애플리케이션의구조 (structure) 를나타낸 다. 즉, 애플리케이션영역에서발견되는클래스들과이들간의관계 (association) 를표현한 다. a.1 클래스다이어그램 (class diagram) 클래스다이어그램 (class diagram) 은객체지향애플리케이션을형성하고있는클래스들 의구조 (structure) 를나타낸다. 즉, 애플리케이션영역에서발견되는클래스들과이들간의 관계 (association) 를표현한다. 클래스 (class) 클래스 (class) 는 의 사각형으로표현한다. 을이용하여 < 그림 a1-1> 과같이 추상적인것에서부터시작하여구체화해가는하향식 (top-dwon) 원칙에따라최초에는 가 ) 와같이클래스이름만파악하여기술한다. 애플리케이션영역의분석과디자인이좀더 구체화되면서나 ) 와같이메서드가추가되고다 ) 와같이속성이추가된다. < 그림 a1-1> 클래스의 3 가지표현의예 클래스에다음의 3가지정보를정의한다. o 클래스이름 o 클래스의속성 (attribute) 또는데이터멤버 (data member) o 클래스의행동을나타내는메서드 (method) < 그림 a1-2> 속성과메서드의추가 클래스에속성또는메서드를추가하려면해당클래스를 선택하고오른쪽마우스를클릭하면팝업메뉴가나타난다. add attribute 또는 add operation 을선택하여속성또는메서드를클래스에추가한다.
UML 모델에구성되어있는클래스등의자원에대한상세내역을조회하려면 < 그림 a1-3> 과같이 의 <<design model>> 을확장하면확인할수있다. < 그림 a1-3> Model Explorer 창 클래스, 속성및메서드의상세내역을설정하 거나조회하려면 < 그림 a1-4> 와같이 창을이용하면된다. < 그림 a1-4> Class, Operation 및 Attribute 의상세내역을설정하는 Properties 창 접근한정자 (access modifier) 클래스는캡슐화한다. 즉, 자바실행환경 (runtime environment) 은프로그래머가달리지정하지않는한클래스내부구조를외부에노출되지않는것을보장한다. 따라서프로그래머는클래스의속성또는메서드에접근할수있는권한을다음과같은접근제한자 (access modifier) 를이용하여알맞게설정하여야한다. o public: (+) 기호로표시된다. 누구든지접근가능 모든객체가접근가능하도록하려면속성, 데이터또는메서드를 public으로선언한다. public 으로선언한다는것은캡슐밖으로노출시켜어떤객체라도자유롭게사용하도록만든다는의미이다. o private: (-) 기호로표시된다. 이클래스로부터만들어진객체들만접근가능 속성, 데이터또는메서드를 private 으로선언하면캡슐내로은닉한다는의미이다. 즉, private 으로선언되면오직이클래스로부터생성된객체들만접근할수있음을의미한다. 정보은닉 (information hiding) 원칙에따라노출해야만하는메서드만 public으로선언하고그이외는 private 으로선언해야한다. o protected: (#) 기호로표시된다. 이클래스의객체들과파생클래스들만이접근가능 protect 로선언되는속성, 데이터및메서드는오직이클래스와이클래스로부터파생된클래스들의객체즉, 동일상속체계에있는후손객체들만접근가능하다는의미이다.
부록 a - UML 클래스의해당데이터나메서드를더블클릭하면 < 그림 a-5> 와같이접근한정자를선택하여설정할수있다. < 그림 a-5> 접근제한자 관계 (association) 객체지향세상이란관련또는연관 (association) 있는객체들이상호작용 (interact) 또는협업 (collaboration) 하는애플리케이션공간이다. 클래스다이어그램은애플리케이션공간에존재하는클래스를나타낼뿐만아니라서로관련이있는클래스들을파악하여이들의관계를나타낸다. 관계 (relation) 란서로다른두개의클래스가서로관련이있을경우 두클래스는상호간에관계가있다 라고한다. 수십억인구가살아가는현실세계에서 나 와전혀관계없는사람들도있지만 나 와가족관계, 선후배관계, 동호회회원관계등의직접적인연관이있거나, 같은한국사람으로서동일한국적관계, 같은성별로서동일한성별관계등의훨씬더포괄적이고추상적인관계까지도있다. 그러나객체지향모델에서는포괄적, 추상적관계는배제하고직접적인관련또는연관관계만을모델링한다. 또한모든관계는양방향이다. 나 와가족관계이거나선후배관계이거나또는동호회회원관계에있는클래스는그클래스에서 나 는가족관계이거나선후배관계이거나또는동호회회원관계이다. 그러나클래스다이어그램에서는관계를양방향으로표현하지않고주요관심사인클래스를중심으로한방향으로나타내는것이일반적이다. 연관관계 (association relation) 는 2개의클래스가상호관련있을경우 의을이용하여표현한다. 연관관계는업무영역에대한분석이진행됨에따라구체적인연관관계인상속관계, 복합연관관계, 집합연관관계, 의존관계등으로세 < 그림 a1-6 연관관계 > 분화또는구체화된다. < 그림 a1-6> 은 4개의클래스로구성된클래스들의연관관계를나타낸사례이다. 교수 (Professor) 클래스와학생 (Student) 클래스는서로지도하고지도받는관계이며, 학생과그행생의아버지 (FatherOfStudent) 는부모- 자식관계이다. 또한학생은등 하교를스쿠터를이용하기에학생과스쿠터 (Scooter) 클래스는의존관계이다. 이렇듯연관관계는항상상호적으로양방향에서나타난다. 필요할경우관계이름 (name) 을화살표에표기하기도한다. 교수와학생의관계는강의담당교수와수강생의관계또는지도교수와지도학생과의관계등다양하기에 < 그림 a1-6> 에서는지도교수와지도학생의관계를이름짓고, 표기하였다. 상속관계는항상부모- 자식관계이기에관계이름의명기를일반적으로생략한다. 그러나학생과스쿠터관계는학생이스쿠터를이용하고, 스쿠터는학생에게이용당하지만, 이용하는관계가중요하기에 Student 클래스에서 Scooter 클래스의일방향으로만관계를명시
한다. 상속 (inheritance, IsA) 관계 클래스간의상속관계는 의을이용하여표현한다. 공통관점으로분류될수있는클래스는일반화하여계층구조로표현한다. 원 (Circle), 삼각형 (Triangle) 및사각형 (Square) 은도형 (shape) 으로일반화할수있기에 < 그림 a1-7> 과같이상속관계 (inherit relation) 로나타낸다. 상속관계는 IsA' 관계라고도한다. 즉, ~ 이다 로설명되는관계로서 사각형은도형이다 라는설명이참 (true) 이면 shape 클래스와상속관계가성립하는것이다. 상속관계는일반화 (generalization) 관계라고도한다. < 그림 a1-7> 상속관계상속관계의상위클래스 (super class) 는추상클래스 (abstract class) 이며, 하위클래스 (sub class) 는구상클래스 (concrete class) 라고한다. < 그림 a1-7> 에서 Shape 클래스는상위클래스이다. 따라서 Shape 클래스는객체를직접생성할수없는추상클래스이며, 기울임글자체로추상클래스임을나타낸다. 원, 삼각형및사각형의길이를구하는 getwidth() 메서드는모든도형에동일하게적용될수있기에 Shape 클래스에구현코드가작성되는구상메서드 (concrete method) 로나타냈다. 그러나도형을출력하는 display() 메서드는원, 삼각형및사각형이각각다른모양으로출력해야하기때문에 Shape 클래스의 display() 메서드는구현할수가없다. 다만 Shape 클래스에서각하위클래스인 Circle, Triangle 및 Square 클래스의출력행동통일 ( 메서드이름통일 ) 을위해구현코드가없이메서드헤더만정의하는추상메서드 (abstract method) 로표현하였고기울임글자체로표시된다. 그리고 Shape 클래스에정의된 display() 메서드의각각의행위 ( 출력모양 ) 를구현하기위해각하위클래스에구상메서드인 display() 를표현하였다. 집합연관 (aggregation, HasA) 관계 클래스간의집합연관관계는 의을이용하여표현한다. 집합연관관계 (aggregate relation) 는두객체간의관계로 ~ 에있다 또는 ~ 를가지고있다 라고표현되기에 HasA' 관계라고도한다. < 그림 a1-8> 집합연관관계 공항 (AirPort) 에는비행기 (Aircraft) 가있다 라는의미의클래스간의관계는집합연관관계로 < 그림 a1-8> 과같이표현한다. 여객기와헬리콥터는일종의비행기이기에 Aircraft 클래스의하위클래스로구성하여상속관계를나타내었다. 복합연관 (composition, APartOf) 관계
부록 a - UML 복합연관관계는 의을이용하여표현한다. 복합연관관계 (composite relation) 는두객체간의관계가 ~ 으로구성되어있다 로설명되어질때존재하며이를 APartOF 관계라고도한다. 자동차 (Car) 는타이어 (Tire) 와엔진 (Engine) 으로구성되어있다 라는의미의복합연관관계가 < 그림 a1-9> 에예시되어있다. 복합연관관계는그관계를해지할때각각의클래스단독으로는애플리케이션에서의미가없는경우에표현된다. < 그림 a1-9> 복합연관관계이와반하여집합연관관계는 < 그림 a1-8> 의사례와같이공항이아닌곳에서도여객기와헬리콥터는독립적으로충분히의미가있는경우에표현된다. 의존또는사용 (dependency 또는 use) 관계 의존또는사용관계는 class 도구상자 의을이용하여표현한다. 클래스또는객체는상호협업 (collaboration) 또는작용 (interaction) 을한다. 즉, 서비스를요청하는클래스또는객체는서비스를제공하는클래스또는객체에의존관계 (dependent relation) 또는사용관계 (use relation) 에있다고말한다. 의존관계또는사용관계는 ~ 을이용한다. 또는 ~ 의서비스에의존한다. 라는의미를가진다. < 그림 a1-9> 에서운전자인 Driver 클래스는자동차인 Car 클래스를이용하고있음을나타낸다. 애플리케이션이실제객체지향언어로구현될때의존관계는해당객체의메서드를호출하여제공하는서비스를이용하는형태로나타난다. a.2 협업도 (sequence diagram) 클래스다이어그램 (class diagram) 은객체지향애플리케이션의구조 (structure) 를나타낸 다. 즉, 애플리케이션영역에서발견되는클래스들과이들간의관계 (association) 를표현한 다. a.2 순서도 (sequence diagram) 클래스다이어그램 (class diagram) 은객체지향애플리케이션의구조 (structure) 를나타낸 다. 즉, 애플리케이션영역에서발견되는클래스들과이들간의관계 (association) 를표현한 다.
클래스 (class) 사각 클래스 (class) 는 의 을이용하여 < 그림 a-1> 과같이