P a g e 2 Context A. Brief Information : 전반적인정보 1. Introduction 3 2. UML 의정의와간략한역사, 그리고특징 3 3. UML 구조에대한간략한기술 5 B. Digging Deeper : UML 의각구성요소에대한설명 4.

Software Modeling & Analysis Assignment #1 A Compact Report on UML & Tools Due 14th MAR 2014 기세파 201013760 강태호 201013275 이인구 200913215

P a g e 2 Context A. Brief Information : 전반적인정보 1. Introduction 3 2. UML 의정의와간략한역사, 그리고특징 3 3. UML 구조에대한간략한기술 5 B. Digging Deeper : UML 의각구성요소에대한설명 4. 공용메커니즘 (Shared Mechanism) 8 5. 유스케이스 (Use Case) 14 6. 콜라보레이션 (Collaboration) 16 7. 인터렉션 (Interaction) 21 8. 액션 & 액티비티 (Action) 28 9. 역할명세 32 10. 객체 & 클래스 (Objects & Classes) 35 11. 관계 (Relation) 39 12. 상태 (State) 45 13. 개발 (Deployment) 46 C. End of the Line : 실제적용방법과현행 UML 툴 14. 실제적용프로세스 47 15. Reference 48

P a g e 3 A. Brief Information : 전반적인정보 1. Introduction 소프트웨어개발을바라보는시각은무척다양하다. 먼저고객과개발자의관점은확연하게 차이가있다. 개발자의경우에는시스템의기능이나기술에관심이많지만, 반면에고객은풍부한 기능보다는소프트웨어가자신의업무에얼마나유용한지를더생각할것이다. 또한, 고객의 입장에서는어떠한기술이사용되었는지는사실상크게중요하지않을수있다.. 2. UML (Unified Modeling Language) 먼저 UML 이란, 소프트웨어개발과정에서산출되는산출물들을명시, 개발, 문서화하기위해 만들어진마크업모델링언어라한다. UML 은 Rational 사의 Grady Booch, James Rumbaugh 에 의해 1994 년 10 월에처음개발에착수되었다. 이후 1995 년 10 월에 Unified Method 0.8 의 명칭으로 OOPSLA '95 에서발표되었으며, 이후 Ivar Jacobson 이 UML 개발에함께협력하면서 1996 년에버전 0.9 를발표하였고, 1997 년 11 월에는 UML 1.1 이 OMG 에의해표준으로정식 채택되었다. Figure 1 UML Version history

P a g e 4 UML 2.0 은 2005 년에 OMG 에의해채택되었으며, 그로부터 7 년후 2012 년 10 월에 비공식적으로 UML 2.5 까지보정되있는상태다. UML 2.X 의형식은 4 가지파트로나뉜다 : 1) 다이어그램과모델내구성요소들을정의하는기호들로이루어진 Superstructure 2) Superstructure 의기반이되는메타모델을정의하는인프라스트럭쳐 3) 규칙과구성요소들을정의하는 Object Constraint Language(OCL) 4) UML2 의다이어그램레이아웃의교환을정의하는 UML Diagram Interchange Figure 2. UML 형식구조 사실 UML 은모델링언어일뿐수단 (method) 은아니다. 메소드는프로세스에대한정의와각각의 업무들에대한지침과, 업무들간의순서들을명시해야하는반면, UML 과같은모델링언어는 표기법 ( 또는다이어그램 ) 들만을제시하는것에그칠뿐이다. 따라서 UML 은소프트웨어개발에 사용하기위한여러다이어그램들을정의하고있으며, 또다이어그램들의의미들에대해 정의하고있다. UML 에서가장중요한요소는다이어그램이라해도과언이아니다. UML 은여러가지다이어그램들을제시함으로써소프트웨어개발과정의산출물들을시각화 형태로제공하고, 개발자들과고객또는개발자들간의의사소통을원활하게할수있도록 도와준다. UML 은시스템을모델링할수있는다양한도구들을제공하기때문에, 도메인을

P a g e 5 모델링하기가훨씬용이할뿐만아니라모델링한결과를쉽게파악할수있게된다. 또한산업계 표준으로채택되었기때문에 UML 을적용한시스템은신뢰성있는시스템이라정의할수있다. UML 의특징을정리해보자면다음과같다 : - 각개발공정에다양하고일관성있는표현방법을제공하며확장성이우월하다. - 규모에관계없이소형부터대형프로젝트까지모두적용이용이하다. - CASE 도구및 Unified Process 를지원호환한다. - 특정한개의개발 / 방법론에얽매이지않는개방적, 독립적인표기체계이다. - 별도의비용이필요없는공개표준모델링기준이다. - 개발자간의의사소통을원활화시켜주는반복 / 점진적과정이ㅏ. - 사용자에게간단하고표현이풍부한시각화언어를제공해준다. 3. UML 의구성 UML 은다양한모델링도구로서의다이어그램들을통일시킨것이다. UML 2.2 를기준으로, UML 을이루는꽃인다이어그램들은두카테고리로나누어총 14 가지로정의할수있다.

P a g e 6 Figure 3. UML Diagram Structure 위의그림을참조하면알수있듯이 UML 다이어그램은크게 Structure Diagram 과 Behavior Diagram 으로나뉜다. 각다이어그램에대한세부내용은 Section B 에서다룰것이므로간단한 정의만적고넘어가고자한다. Structure Diagram - 클래스다이어그램, Class Diagram 시스템의클래스와그변수, 그리고다른클래스들과의관계를통해시스템구조를표현 - 컴포넌트다이어그램, Component Diagram 시스템이어떤컴포넌트들로갈라져있는지, 그리고각컴포넌트들의 ( 요구기반 )dependency 는무엇인지표현 - Composite Structure Diagram 클래스내의구조와콜라보레이션들을표현 - 개발다이어그램, Deployment Diagram 시스템개발에사용될하드웨어사양과실행환경, 사항등을표현 - 객체다이어그램, Object Diagram 특정상태에서의예시시스템모델의구조를완전히혹은일부만표현 - 패키지다이어그램, Package Diagram 시스템의구조를패키지로표현 - 프로파일다이어그램, Profile Diagram 위 UML 의구조에서언급한 metamodel 수준에서 <<stereotype>> 나 <<profile>> 등을 표현 Behavior Diagram - 액티비티다이어그램, Activity Diagram

P a g e 7 모델링의기반이된사업 / 프로젝트와그시스템내부의작업들을단계별로표현. 소위 Flow of control 을표현한다할수있다. - 상태다이어그램, UML State Diagram 시스템내의상태와상태변화를표현한다. - 유스케이스다이어그램, Use Case Diagram 시스템이제공하는기능을액터 (Actor), 목표, 그리고 dependency 등을통해표현 - 커뮤니케이션다이어그램, Communication Diagram 시스템내객체나부품간의상호작용을표현. - 인터랙션다이어그램, Interaction Overview Diagram 커뮤니케이션다이어그램들을대변하는노드들을통한전체적인요약적표현 - 순서다이어그램, Sequence Diagram 순차적메시지를통해객체가어떻게서로소통하는지를표현. - 타이밍다이어그램, Timing Diagram 시간적제약을주로염두에둔인터랙션다이어그램의일종. The UML User Guide 에의하면모델링을통해우리는다음과같은 4 가지목적을얻을수 있다고한다. 모델은시스템을현재또는원하는모습으로가시화하도록도와준다. 모델은시스템의구조와행동을명세화할수있게한다. 모델은시스템을구축하는틀을제공한다. 모델은우리가결정한것을문서화한다. 즉, 복합한시스템에대해모델을만드는이유는그시스템을전체적으로이해할수없기 때문이다. UML 은앞에서언급한 4 가지목적에적절히부합하기때문에소프트웨어를개발함에 있어모델링언어로 UML 을사용하게되는것이다..

P a g e 8 모델 (model) : 유스케이스모델, 분석모델, 설계모델과같이다른산출물을포함하는형태를 갖는산출물 모델요소 (model element) : 다른산출물내부에포함되어있는산출물로예를들면 유스케이스모델안의유스케이스, 액터와설계모델내부의설계클래스, 설계서브시스템등과 같은산출물 문서 (document) : 문서로존재하는산출물로비즈니스케이스, 소프트웨어아키텍처문서등과 같은산출물 B. Digging Deeper : UML 내요소 ( 다이어그램 ) 4. 공용매커니즘 1. 분류자 (Classifier) 시스템은추상적인개념들에의해서가아닌실체에의해운영된다. 그리고시스템을운영을위해 요구되는실체들은매우방대하기때문에이들을개별적으로정의하는것은불가능하다. 그래서 현실에서는설계도를만들게된다. 이러한설계도에는제품의형태와기능에대한특징이정확히 기술되어야한다. UML 에서설계도를통해만들어진실체들을인스턴스라고하고실체들을 분류한다는의미에서설계도를분류자라고한다. 즉분류자 (Classifier) 는구조적특징과행위적 특징을기술하는메커니즘이다. 1.1 분류자의표현

P a g e 9 Figure 4. Classifiers 분류자는왼쪽그림과같이구조적특징과행위적특징을나열할수있는사각형기호로 표현한다. 분류자의종류는이름부분에분류자를나타내는키워드로표현된다. 키워드는 << >> 내에표현된다. 1.2 분류자의특징 분류자의구조적특징을속성이라고하고, 행위적특징을오퍼레이션 (Operation) 이라고한다. 분류자의인스턴스는다른분류자의인스턴스와연결될수있고, 이때분류자의인스턴스는 자신과연결된인스턴스들에대한참조를갖게된다. 분류자는속성과자신의인스턴스에 연결되는인스턴스들에대한참조자에대한명세를합쳐특성 (property) 라고한다. 1.2.1 가시성 (visibility) 가시성은분리자의특징을다른분류자가접근할수있는지여부를표현하는것이다. 가시성의 종류는 public, protected, private, package 가있다. 1.2.2 파생특성 (Derive Properties) 파생특성은다른특성값으로부터자신의값을얻을수있는것으로, 특성이름앞에 / 기호로 나타낸다. 1.2.3 다중성 (Multiplicity) 분류자의특성은일반적으로한개를갖지만, 여러개를가지는것도있기때문에특성이가질 수있는값의범위를규정해야한다. UML 에서는이를다중성이라고한다. 다중서의표기는 [ 최소값.. 최대값 ] 의형식으로작성된다. 최대값에제한이없을경우는 * 기호를사용한다. 1.2.4 타입 (Type) 과기본값 (Default Value)

P a g e 10 타입에는속성의타입에대한분류자를작성한다. 기본값은특정값을설정하지않는경우 인스턴스가생성될때기본적으로설정되는값이다. 1.2.5 특성문자열 (Property String) 특성문자열은분류자의특성에대해추가적인제약을작성하는것이다. 특성문자역은중괄호 안에제약을나타내는키워드를작성해서표현한다 (ex/ {readonly}, {union}) 1.2.6 적용범위 (Scope) 적용범위는분류자의속성값또는오퍼레이션이분류자의범위에서모든인스턴스에동일하게 적용될것인지, 개개인스턴스마다특성값을설정할것인지를결정하는것이다. 이는속성의 이름에밑줄을그음으로써표현된다. 2. 일반화 분류자는개념들을추상화수준에따라계층화한다는개념도가지고있다. 추상화는어떤대상에 대해서특별한목적을위해필요로하는핵식저긴특징만을나타내는것이고, 인스턴스들은 공통된특징에의해같은종류의개념으로분리된다. 따라서같은추상화수준에속하는같은 종류의인스턴스라는것은인스턴스들이같은수의공통된특징을갖는것을의미한다. 개념들의 추상화수준을높이는것을일반화한다고하고, 추상화수준을낮추는것을구체화한다고한다. 개념이추상화수준이높아질수록 ( 일반화할수록 ) 더많은인스턴스들을동일한개념으로묶을수 있다. 2.1 상속 (Inheritance)

P a g e 11 Figure 5. Inheritance 추상화수준에따라계층화된분류자들에서하위수준분류자가상위수준분류자의공통된 특징을가지게된다. 다라서추상화수준마다공통된특징을기술하는것은중복작업을 발생시킨다. 이러한반복기술문제를해결하기위해상속이라는개념을만들었다. 상속관계를 갖는개념은하위개념이상위개념의구조적특징과행위적특징을모두물려받는다. 그러나 상속관계대신일반화관계라는용어를사용하며, 이관계는속이빈삼각형모양화살표로 표현된다. 2.2 추상 (Abstraction) 개념을지속적으로추상화에의해일반화시키게되면, 인스턴스를만들어내는역할보다, 단지 계층을분류하는역할만하는분류자들이쓰이게된다. 이러한분류자를추상분류자라고한다. 또한상위분류자에정의한행위수행내용은하위분류자들의행위이부로서불완전한형태이기 때문에실행은할수없다. 이러한행위를추상오퍼레이션이라고한다. 추상분류자와 추상오퍼레이션같이불완전전하여인스턴스화될수없는것을통틀어추상이라고하며추상은 이름앞이나뒤에 {Abstract} 키워드를사용하거나이탤릭체로표현할수있다. 2.3 파워타입 (Power Type)

P a g e 12 복잡한계층에의해추상화된분류자들은그분류기준을명시하는것이중요하다. 이러한 분류기준을파워타입이라고한다. 파워타입은분류되는상위타입과연관관계를갖고, 분류 기준에따르는하위타입들을묶는 : 파워타입 형식의이름을갖는점선으로표시된다. 3. 패키지 (Package) Figure 6. Package UML 에서는구성요소그룹을패키지로표현하고패키지에포함되는구성요소들은멤버라고 부른다. 패키지는이름을기재하는작은사각형과패키지멤버들을표현하기위한큰사각형 기호를사용해서표현한다. 패키지의멤버들은다른패키지의멤버로부터불려질때, 동일이름을 갖는다른요소들과구별하기위해자신을포함하는패키지이름을포함해서불려진다. 이때 불리는것이네임스페이스로네임스페이스와멤버의구분은 :: 로표현한다. 3.1 패키지관계 패키지멤버가다른패키지멤버에접근하기위해서는패키지들간에관계가형성되어야한다. 이들관계는의존관계기호로표현한다. 의존관계에는패키지임포트관계와머지관계라는특수한 의존관계가존재한다. 3.1.1 패키지임포트관계 패키지임포트관계는 <<import>> 와 <<access>> 라는두가지키워드를통해표현된다. <<import>> 는다른패키지의멤버를자신의멤버처럼사용하기위해서다른패키지모델요소 이름을자신의네임스페이스로안으로가져온다는의미를가진다.

P a g e 13 <<access>> 는다른패키지의멤버에접근만한다는것을의미한다. 3.1.2 패키지머지관계 패키지머지관계는 <<merge>> 키워드를이용하여직접적으로다른패키지에명세되어있는 멤버들을이용해새로운패키지를재구성하기위해사용하는관계이다. 4. 스테레오타입 (stereotype) 스테레오타입은기존의모델요소와유사하나정확히같은의미를가지지않을때기존의모델 요소를기반으로 UML 의어휘를확장하는방법이다. 스테레오타입은 << >> 안에확장하려는 어휘를작성하는방법으로표현된다. 5. 제약사항 제약사항은모델요소에추가적인규칙을부여할때사용하며, 중괄호안에제약사항을 작성해서표현한다. 제약사항은일반적으로노트안에작성된다. 제약사항은일반적인언어로 기술할수도있고, 객체제약언어를사용할수도있다. 6. 태그를갖는값 UML 명세는객체관리그룹에서관리하고있고, UML 새로운버전은산업계에의해갱신되기 때문에아무나명세를바꿀수는없다. 태그를갖는값은 UML 모델요소에새로운속성을 추가하는것으로 UML 모델요소에명세되지않은속성을추가할때사용할수있다. 7. 프로파일 이전에정의해서사용하던스테레오타입들이나태그를갖는값들을재사용할필요가있다. 확장 매커니즘을통해 UML 모델요소들을재사용하기위해서는, 재사용되는것을하나의그룹으로 묶고확장모델요소가어떤모델요소를어떻게확장한것인지를설명해야한다. 스테레오 타입에의한확장은의미적으로일반화관계로표현되는상속의의미와같다. 그러므로

P a g e 14 확장관계는속이채워진상속기호로표현한다. 프로파일은확장모델요소들을그룹화하는 것으로패키지에 <<profile>> 을추가함으로써표현한다. 5. 유스케이스, Use Case 1. 액터 (Actor) Figure 7. Actor 액터 (Actor) 는시스템과상호작용해야하는사람또는어떤것이다. 액터는시스템외부에 존재하며, 사람뿐만이아니라시스템외의다른시스템, 외부장치등시스템을직접적으로 사용하는대상이액터이다. 액터는자신의문제를해결하려시스템을사용하기때문에, 시스템은 액터의욕구를만족시키기위한구조를지녀야한다. 액터는일반적으로뒤에 언급할 유스케이스 (Use case) 와관계를가진다. 유스케이스에는여러액터가관련될수있다. 즉특정 목적을달성하기위하여역할수행을하는액터들이존재한다. 자신의목적을달성하기위해 시스템사용을하는액터를 1 차액터 (Primary Actor) 라고하고, 1 차액터의목적달성을위해 시스템사용을하는액터를 2 차액터 (Secondary Actor) 라고한다. 2. 유스케이스 (Use case) 유스케이스 (Use case) 란개발될시스템의개개액터가시스템사용목적을잘달성할수있도록 개발될시스템이제공해야하는서비스이다. 이러한서비스는일련의 트랜스액션 (TransAction) 으로구성된다. 어떠한유스케이스를제공할지결정한이후에는

P a g e 15 유스케이스를어떻게효율적으로제공할지고려해야한다. 즉액터가시스템을사용하면서 일어나게될상황을시나리오화해야한다. 액터의시스템사용시나리오를잘작성하기 위해서는액터와시스템의역할과책임에대해아는것이필수적이다 액터의책임 1. 시스템에게서비스수행을시작하도록요청 2. 시스템이요구하는정보를제공 3. 시스템과의상호작용과관련된의사결정을함. 시스템의책임 1. 액터로부터제공받은정보나시스템의서비스수행상태틀기록 2. 서비스를시작하거나시스템이요청한행위를수행하는데액터가필요로하는정보를제공 3. 서비스를제공하여야함. 3. 관계 Figure 8. Relationship

P a g e 16 3.1 액터와유스케이스관계 액터와유스케이스관계는양방향연관관계기호로표현한다. 3.2 액터와액터관계 액터들사이에서는단지일반화관계만이존재한다 3.3 유스케이스와유스케이스의관계 유스케이스간의관계는포함관계와확장관계가있다포함관계는 <<include>> 키워드를, 확장관계는 <<extend>> 키워드를사용하여표현한다. 또한일반화관계도존재하는데, 액터의 일반화같이하위유스케이스가상위유스케이스의모든역할과책임을상속받는것을의미한다. 이런유스케이스들의시스템의행위적인면을모델링하는다이어그램을유스케이스 다이어그램이라고한다. Figure 9. Use Case Diagram 6. 콜라보레이션

P a g e 17 Figure 10. Collaboration 시스템의서비스제공이라는목적은시스템의책임들을그룹화한역할들을실현하는구성 요소들에의해달성된다. 만약구성요소가복잡한구조로이루어져있어좀더작은구성 요소들을부분으로가진다면, 구성요소가수행하는책임은좀더작은책임들로기술될것이고, 그룹화되어역할을갖게될것이다. 따라서구성요소의책임은좀더작은구성요소들이 협력하여수행하게된다. UML 에서는협력의목적을기준으로협력하는역할들과그들의관계를 표현하는것을컬레보레이션이라고한다. 1. 역할 역할이란특별한컨텍스트에서참여하는실체 (entity) 의행위또는관련된책임들의집합이다. 역할을정의하는 2 가지관점이있는데, 완성된시스템의관점에서구성요소를역할정의의 중심에두는방법이있고, 개발될시스템의관점에서시스템의책임을역할정의의중심에두는 방법이있다. 1.1 역할의분류

P a g e 18 시스템의책임을역할에할당할때에 RUP 에서사용하는바운더리 (Boundery), 컨트롤 (Control), 엔티티 (Entity) 로시스템에필요한역할을분류하는것이가장일반적이다. 1.1.1 바운더리 액터와의상호작용을지원하는역할이바운더리이다. 마치인터페이스와같은역할을하게된다. 시스템의외부에있는액터와연결을수행하며시스템의가장바깥에위치하기때문에 바운더리라고불린다. 바운더리는시스템외부의변화와시스템을분리시키는역할을한다. 바운더리는액터가누구냐에따라그종류가달라진다. 예를들면액터가사람인경우 GUI 의 형태를가진다. 1.1.2 컨트롤 컨트롤은시스템이특정액터에게특정서비스를제공하기위해필요로하는모든과정의수행을 책임진다. 컨트롤은액터에게최종적으로완성된서비스를제공하기위해서최종서비스가어떻게 완성되는지를알아야한다. 유스케이스의이벤트플로어를제어하기때문에컨트롤이라고 불리운다. 1.1.3 엔티티 실제시스템이처리해야하는역할이엔티티이다. 시스템의주된처리내용이정보관리이기 때문에, 엔티티는정보와관련된행위를표현한다. 1.1.4 역할이름 역할은인터페이스로표현되기때문에역할이름에인터페이스를의미하는 I 를붙여서작성한다. 또는능력중심으로작성하는방법으로이름끝에 -able 을붙혀서작성한다. 1.2 구성요소 역할은단지어떤책임을갖고어떤일을할수있는가에대한선언적인명세로실제역할의 수행은시스템내부구성요소들이한다. 구성요소들이역할을수행하는것을실현이라고한다. 1.3 역할의제약조건

P a g e 19 협력이란내가할수없는일을잘할수있는구성요소에게요청하고, 내가잘할수있는일은 다른구성요소를대신해서수행하는것이다. 구성요소들상호간에서비스를요청하고제공하기 위해서는서로이해할수있는공통의규약이필요하고, 이는계약으로표현된다. 서비스를 제공하기이전에만족되어야하는상태를선행조건 (Precondition), 서비스가수행되고난이후에 만족되어야하는상태를후행조건 (Precondition), 서비스수행에의해보정되는결과에대한 조건을실행조건 (Body condition) 이라고한다. 이러한서비스에대한제약족건은객체제약 언어 (Object Constraint Language) 로명세한다. 역할들은명세이기때문에역할들의 커뮤니케이션을가능하게하는수단또한명세이다. 역할들의커뮤니케이션을가능하게하는 역할들간의연결을영어로커넥터 (Connector) 라고한다. 커넥터는역할과역할을연결하는 직선기호로표현된다. 2. 컬레보레이션 컬레보레이션이란역할들의협력을필요로하는일에대한명세이다. 역할들의상호작용은 인터렉션에의해명세된다. 컬레보레이션은점선으로된타원기호를사용하여표현한다. 2.1 컬레보레이션어커런스 컬레보레이션에대한특별한상황에대한적용을컬레보레이션어커런스 (Collaboration Occurrence) 라고한다. 컬레보레이션어커런스는특수한상황에서의협력을나타낼수있기 때문에컬레보레이션이될수있다. 컬레보레이션은여러가지구체적인상황에서발생하는 협력들을추상화한것으로행위의재사용을위한매우중요한요소이다. 컬레보레이션을정확히 표현하기위해서는구조적인부분과행위적인부분을모두표현해야한다. 어떤요소들이 협력하는지는구조적인부분으로, 협력을위해어떻게상호작용하는지는행위적인부분으로 표현되어야한다. 일반적으로컬레보레이션의구조적인부분은컴포지트스트럭처

P a g e 20 다이어그램으로행위적인부분은시퀀스다이어그램이나커뮤니케이션다이어그램과같은 인터렉션다이어그램들로표현한다. 2.2 컬레보레이션의사용 시스템은많은액터들을가지고있으며이들의시스템사용목적은유스케이스에의해달성된다. 유스케이스는시스템구성요소들의여러역할들에의해실현된다. 하나의역할은작은역할로 분할할수있고부분이되는역할은협력하여전체역할을수행할수있다. 구성요소 ( 객체 ) 들은 구조적특징 ( 속성 ) 과행위적인특징 ( 오퍼레이션 ) 을가지고있으며구성요소의역할수행은 구조적특징과행위적인특징이협력하여이루어진다. 행위적인특징인오퍼레이션은매개변서, 리턴값, 오퍼레이션내부에서사용하는로컬변수들과객체들의협력에으히ㅐ실현된다. 시스템 개발에있어컬레보레이션은세스템부터오퍼레이션까지시스템개발전반에사용되기때문에, 시스템개발을연속적인컬레보레이션이라고볼수도있다. 컬레보레이션을사용하는일반적인 경우는유스케이스, 오퍼레이션메커니즘, 패턴이다. 2.2.1 유스케이스실현 유스케이스는시스템의외부적인관점에서작성되기때문에시스템내부에서어떠한구성 요소들에의해서처리되는지를나타내지않는다. 따라서시스템내부의구성요소들로 유스케이스를실체화하여야하는데이를유스케이스실현이라고한다. 유스케이스실현이란 좀더큰기능인유스케이스의행위를좀더작은기능을갖고있는내부구성요소들의협력으로 나타낸것으로컬레보레이션으로표현할수있다. 실현관계는속이빈삼각형을갖는점선 화살표기호로표현한다. 2.2.2 오퍼레이션실현 오퍼레이션에컬레보레이션을사용하는것은드물게일어난다. 오퍼레이션이매우복잡해서 코딩을작성하기힘든경우에컬레보레이션을사용한다. UML 2.0 부터는컬레보레이션어커런스를 사용해서컬레보레이션과컬레보레이션의대상이되는모델요소와직접적인관계를갖지않도록

P a g e 21 하여컬레보레이션의독립성을보장한다. 컬레보레이션의대상과컬레보레이션의사이에는 <<represent>> 키워드를갖는의존관계가작성된다. 2.2.3 메커니즘 메커니즘이란시스템아키텍처의개념적인덩어리들을나타내는설계패턴, 또는클래스들의 사회에적용되는설계패턴의다른이름이다. 시스템에있어, 행위에대한의사결정들의집합을 표현하는것을유스케이스, 형태에대한의사결정의집합을표현하는것을아키텍처라고한다. 2.2.4 패턴 다음에발생될수있는문제에대한해결책을본보기로만들어놓고차후에참고할수있는것을 패턴이라고한다. 7. 인터렉션 1. 메시지 구성요소들간에서비스를요청하고제공하기위해서는서로이해할수있는공통의규약이 필요하고, 이는계약으로표현한다. 또한서비스를요청하는구성요소는서비스를제공하는구성 요소에게무엇을요청하는것인지에대한정보를제공해야한다.. 메시지란행위전달되는정보에 대응하는행위가일어날것을기대하면서정보를전달하는객체들사이의커뮤니케이션에대한 명세이다. 서비스를요청하기위해메시지를보내는구성요소를송신자 (Sender) 라고하고, 서비스를제공하기위해메시지를받는구성요소를수신자 (Receiver) 라고한다. 송신자와수신자 사이에이루어지는메시지전달을통해정보를주고받는일을커뮤니케이션이라고한다. 구성 요소들사이에커뮤니케이션이가능하도록구성요소들을연결하는수단을 커넥터 (Connector) 라고한다. 또한송신자로부터메시지가떠날때발생하는이벤트를송신 이벤트 (Send event) 라고하고, 수신자에게메시지가도착했을때발생하는이벤트를수신

P a g e 22 이벤트 (Receive event) 라한다. 메시지가오퍼레이션인경우송신자가메시지를보내는행동은 호출액션 (Call Action) 이라고하고, 메시지가시그널인경우송신액션 (Send Action) 이라고한다. 1.1 메시지표현 메시지는서비스와관련된구성요소들사이의계약으로구성요소들사이의서비스에대한 책임과권한의내용을담아야한다. 서비스를요청하는메시지에는서비스요청자가서비스를 제공받기위해서지켜야하는최소의책임과그러한책임을지켰을때의결과를포함해야한다. 메시지는정보이기때문에이러한책임과권한또한정보의형태로작성되어야한다. 일반적으로 서비스요청자에의한책임을입력정보로, 서비스수행에대한결과를출력정보로나타냅니다. 따라서서비스요청메시지는 메시지이름 ( 입출력매개변수들 ) 과같은형태로작성된다. 메시지이름은서비스요청내용을, 입출력매개변수들은책임들과권한들로작성한다. 1.2 메시지분류 메시지가전달하는서비스요청은제어방식에따라동기적인방법과비동기적인방법으로 나누고, 요청방식에따라오퍼레이션 (Operation) 호출과시그널 (Signal) 송신으로나눈다. 1.2.1 동기메시지와비동기메시지 동기적인방법에서는서비스요청자가서비스를요청하고나면제어가서비스제공자로넘어간다. 그리고서비스제공자가서비스수행을완료한후에야다시제어가서비스요청자에게넘어와서 다음작업을수행하게된다. 비동기적인방법으로는서비스요청자가서비스를요청하고난후에 서비스제공자의서비스수행여부에상관없이제어권을잃지않고바로다음작업을수행할수 있다. 동기적인방법에서요청된결과가있을때결과를넘겨주는메시지를응답메시지 (Reply Message) 라고한다. 동기메시지는머리부분이채워진화살표로, 비동기메시지는머리부분이 열려있는화살표로, 응답메시지는머리부분이열려있는점선화살표로표현한다. 1.2.2 오퍼레이션과시그널 오퍼레이션호출은서비스요청자가직접적으로서비스제공자에게서비스를요청하는것이고, 시그널송신은서비스요청자가특정한신호를보내어간접적으로서비스를요청하는것이다.

P a g e 23 일반적으로오퍼레이션호출은동기적인방식으로, 시그널송신은비동기적방식으로된다. 기술적인면에서는오퍼레이션호출의비동기화는쓰레드와큐에의해서구현된다. 1.2.3 응답메시지 인터렉션에서구성요소들의상호작용은모두메시지의형태로전달되기때문에서비스 제공자가서비스요청자에게요구한결과를보내줄때에도메시지의형태로전달되어야합니다. 이러한메시지를요청에대한응답메시지라고한다. 제공되는결과는 메시지이름 ( 입출력 인수들 ): 리턴값 의형태로작성된다. 1.2.4 구성요소의생성과소멸메시지 하나의시나리오를완성하는과정에서많은구성요소가생성되고소멸된다. 구성요소를 생성하는메시지를생성메시지, 구성요소를소멸시키는메시지를소멸메시지라고한다. 생성 메시지는머리부분이열려있는점선화살표를생성하는구성요소의머리부분을향하도록 표현한다. 소멸은구성요소의수명을나타내는점선으로수직선위에 X 로표현한다. 1.2.5 Complete Message, Lost Message, Found Message 메시지는보낸이벤트와받은이벤트가알려졌는지여부에따라 Complete Message, Lost Message, Found Message 로구분된다. Complete Message 는보낸이벤트와받는이벤트모두 알려진경우, Lost Message 는보낸이벤트는알려져있으나받는이벤트는알려지지않은경우, Found Message 는받는이벤트는알려졌으나보낸이벤트가알려지지않은경우이다. Lost Message 는메시지가목적지에도착되지않았다는것을의미하고, Found Message 는메시지의 시작이메시지를기술하는범위밖에있다는것을의미한다. Lost Message 는열린화살표가속이 채워진원으로향하게표현되고, Found Message 는속이채워진원에서열린화살표가 뻗어나오는것으로표현한다.

P a g e 24 2. 생명선 (Life Line) 인터렉션에서송신자와수신자는머리부분이되는사각형과참여자의수명을나타내는점선으로 된수직선으로표현한다. UML 에서송신자와수신자같은인터렉션에참여하는구성요소를 표현하는모델요소를생면선이라고한다. 생명선은인터렉션에참여하는하나의실체 ( 구성 요소 ) 를나타낸다. 인터렉션의참여자로는구성요소들이외에구조적특징이나구성요소는여러 부분들로구성된경우부분들이참여자가될수있다. 구조적틍징이나부분들은하나의구성 요소에대해서여러개존재할수있기때문에다수성을표현해야한다. 다수성이 2 이상이라는 것은컬렉션임을의미하고, 컬렉션에서특정한한부분을찾는표현식을셀렉터 (Selector) 라고한다. 2.1 시퀀스다이어그램

P a g e 25 Figure 11. Sequence Diagram 시퀀스다이어그램은 sd 키워드에인터렉션이름과사용되는인자들로표현된다. 하나의시퀀스 다이어그램은다른시퀀스다이어그램에의해참조도리수있다. 참조는게이트 (Gate) 에의해 연결된다. 게이트는시퀀스다이어그램의경계로부터보내지거나시퀀스다이어그램의경계를 향하도록표현된다. 서비스에대한표현에는시작시간과종료시간이포함되며, 이들의차이가 서비스수행시간이된다. 서비스실행은참여자의수명을나타내는점선으로도니수직선위에 폼이좁은사각형으로표현된다. UML 에서는행위가실행되고있다는의므로실행발생 (Execution Occurrence) 이라고한다. 3. 인터렉션 (Interactions)

P a g e 26 인터렉션이란특정목적을달성하기위한컨텍스트안에서객체들사이에교환되는메시지들의 집합으로구성된행위이다. 협력은특정목적을달성하기위해이루어지고, 협력을위해구성 요소들사이에는많은메시지들이전달된다. 즉구성요소들이사이에전달되는메시지들이 집합이특정목적을달성하기위한행위로서작용한다는것이고이를인터렉션이라고한다. 인터렉션은시나리오를기반으로작성된다. 3.1 연산자 시나리오안에서, 구성요소들의상호작용은매우복잡한로직을가질수있다. 반복이나조건 선택또는병행처리와관련된상호작용들은하나의그룹으로처리되야한다. UML 에서는반복, 조건선택, 병행처리와같은구성요소들의상호작용방식을결정하는것을연산자 (Operator) 라 하고, 연선자에따라결정되는상호작용부분들을피연산자 (Operand) 라고한다. 3.1.1 조건선택연산자 opt, alt 조건에따른선택이하나인경우네는 opt 연산자를사용하고, 다수인경우는 alt 연산자를 사용한다. 3.1.2 반복연산자 loop 반복조건은대괄호안에작성하고, 반복횟순ㄴ정수인최소값과최대값으로나타내며, 최소 값과최대값은콤마로분리한다. 무제한으로반복될경우는최대값에 * 를사용한다. 3.1.3 병행처리 par, critical 여러작업을동시에처리하고자할때사용하는오퍼레이션이 par 연산자입니다. 병행처리를할 때다른작업과번갈아처리해서는안되는경우도있는데, 그럴때는 critical 연산자를사용한다. 3.1.4 메시지선택 ignore, consider 구성요소들이하나의시나리오에따라상호작용할때시나리오에서특정부분을강조또는 무시할때사용한다. 이때메시지들은중괄호안에작성된다. 3.1.5 테스트 assert

P a g e 27 인터렉션이시나리오에따라제대로일을수행하고자하는지파악하기위해중요값을검증해야 할때사용한다. 3.1.6 메시지전달순서 seq, strict 시나리오가수행되는동안에메시지전달순서를엄격하게표기할때사용하는연산자이다. 3.1.7 시나리오흐름제어 break 프로그래밍언어에서조건이나반복안에서제어를빠져나갈때사용하는 break 문과같은 의미이다. 3.1.8 발생해서안되는상황작성 neg 시나리오에서절대발생해서는안되는상황을인터렉션에작성할경우 neg 를사용한다. 3.2 인터렉션다이어그램 시나리오는인터렉션다이어그램으로표현되며, 인터렉션은표현하고자하는목적에따라다양한 다이어그램을사용한다. 모든인터렉션다이어그램은시퀀스다이어그램과같이 sd 라는키워드를 갖는다이어그램으로작성된다. 3.2.1 커뮤니케이션다이어그램 커뮤니케이션다이어그램은구성요소들이어떻게관계를맺고서로상호작용하는지에중점을 둔다이어그램이다. 3.2.2 인터렉션오버뷰다이어그램 시퀀스다이어그램은시나리오제어흐름을표현하기가어려웠고, 이것을잘하는다이어그램은 액티비티다이어그램인데이둘의장점을취합한것이인터렉션오버뷰다이어그램이다. 3.2.3 타이밍다이어그램 타이밍다이어그램은리얼타임시스템과같이시간에대한제약이중요하게다루어져야할때 사용되는다이어그램이다.

P a g e 28 8. 액션과액티비티 Figure 12. Activity 1. 액션 액션이란액티비티안에서실행가능한기본단위이다. UML 명세에서사용되는 behavior 는 요소의행위를전체적으로설명하기위해서사용하는용어이고, activity 는수행에있어어느정도 시간을요구하는행위를설명하기위해서사용하는용어이며, action 은수행하는데시간을 요구하지않는행위의최소단위를설명하기위해사용하는용어이다. 1.1 액션의종류 UML 에서는객체지향프로그래밍에맞추어서액션들을정의한다. 이러한액션들중에서서비스를 요청하고제공하기위한메시지전달은실세계에동일하게적용될수있다. 속성값을설정하거나 링크를만드는행위를읽기액션이라고하고, 속성값을변경하거나링크를삭제하는행위를 쓰기액션이락한다. 객체들이메시지를보내거나받는행위를커뮤니케이션액션이라고하고, 기본함수를수행하는행위를기본함수수행액션, 예외상황에서예외를발생시키는행위를 예외발생액션이라고한다. 1.1.1 커뮤니케이션액션

P a g e 29 메시지를보내는것이나받는것은하나의액션이다. 서비스를제공받기위해서다른역할에게 메시지를보내는액션을오퍼레이션호출액션 (Call Operation Action) 또는시그널송신액션 (Send Signal Action) 이라고한다. 메시지를받는액션은메시지의종류와상관없이서비스수행을 요청받는것이기때문에모두호출수용액션 (Accept Call Action) 이라고한다. 호출이벤트를 제외한이벤트들에대응하는액션을이벤트수용액션 (Accept Event Action) 이라고한다. 1.1.1.1 오퍼레이션호출액션 (call Operation Action), 행위호출액션 (Call Behavior Action) 오퍼레이션호출액션은오퍼레이션이름과해당오퍼레이션클래스의이름을추가적으로 작성한다. 행위호출액션은여러액션으로구성된액티비티의실행을의미하기때문에액션의 오른쪽밑부분에갈퀴기호를사용한다. 1.1.1.2 시그널송신액션 (Send Signal Action) 시그널송신액션은시그널을수신자에게보내는행위이다. 1.1.1.3 이벤트수용액션 (Accept Event Action) 이벤트수용액션은한쪽면이오목한사각형으로표현한다. 이는시그널송신액션과결합할수 있도록대응한다. 1.1.2 기본함수수행액션 계산과정들중에산술계산과같이입력값만으로직접적인계산을처리할수있어단일 액션으로고려될수있는최소단위의함수를기본함수 (Primitive functions) 라고한다. 1.1.3 예외발생 액티비티내부에서예외적인상황이일어날때적합한예외를발생시키는액션을예외발생 액션이라고한다. 예외발생액션이수행되면예외가발생된지점에서액티비티수행을 즉각적으로멈추고예외를처리할수있는예외처리자를찾는다. 2. 액티비티

P a g e 30 액티비티란일련의액션들로구성된매개변수화된행위명세이다. 서비스를제공하는행위인 액티비티도한액션과마찬가지로계약의원리를따른다. 매개변수화되었다는의미는바로 입력과출력을갖는다는것을의미한다. 액티비티는왼쪽상단에이름을갖는모서리가둥근 사각형기호를사용한다. 사각형내부에는액션들과흐름들이작성되며, 매개변수들은사각형의 경계위에작성되고, 매개변수의타입은액티비티이름밑에작성된다. 또한액티비티는 <<activity>> 키워드를갖는분류자로도표현될수있다. 2.1 제어흐름 서비스는메시지송신자의서비스요청을받고선행조건이만족되면메시지수신자에의해 시작된다. 서비스가시작되면, 서비스는제어흐름에따라서비스실행의여러단계를거치게된다. 서비스는종료후후행조건을만족해야하며, 실행과정에서외부이벤트, 에러, 내부이벤트에의해 중단될수있다. 액티비티는일반적으로유스케이스와같이기술서를먼저작성하고 다이어그램으로나타낸다. 2.1.1 시작점과종료점 시작점은속이채워진원으로나타내고시작액션의앞에연결된다. 종료점은속이채워진원과 그원을둘러싼원이합쳐진기호로나타내며, 종료액션뒤에연결된다. 2.1.2 조건선택 서빗를실행하는과정에서는여러가지액션들중에어떤액션을수행해야할지를결정해야할 경우가있다. 여러액션중에하나의액션을선택해야하는지점을의사결정점 (Decision Points) 라고하고마름모로표현한다. 선택의기준은 가드 (Guard) 라불리우고선택의조건이되는 기준은대괄호안에기재한다. 2.1.3 제어흐름종료점제어흐름종료점은해당하는제어흐름만이종료되는것을의미하며, 원안에 X 표시가된기호가있는것으로표현한다. 2.1.4 병행처리

P a g e 31 병행처리는수직또는수평막대기로표현한다. 한작업에서여러작업이분기되는점을 갈래점 (Fork) 이라고하고, 여러작업에서한작업으로합쳐지는것을결합점 (Join) 이라고한다. 2.1.5 병합점 병합점은의사결정점에서분기되는전이들을합쳐주는역할을한다. 이는다시한번의사 결정점을그림으로표현한다. 2.2 객체흐름 액티비티다이어그램에서객체는이름을갖는사각형기호로표현한다. 객체타입이시그널인 경우에는왼쪽부분이안으로들어간육각형기호로표현한다. 액션의입출력은작은사각형으로 작성되어서액션기호에첨부된다. 입력은왼쪽 ( 위쪽 ) 에, 출력은오른쪽 ( 아래쪽 ) 에작성된다. 입출력을화살표를이용하여나타낼수있다. 2.3 전이 (Transition) 제어가이동되는것을전이라고하고화살표로표현한다. 이름은일반적으로이벤트이름으로 작성되며, 대부분의경우생략된다. 2.3 단일실행 (Single Execution) 액티비티를실행할때에는하나의액티비티실행이모든실행요구를다룰것인지, 하나의실행 요구만을다룰것인지를결정해야한다. 단일실행에대한표현은 <<singleexecution>> 이라는 키워드를사용한다. 2.4 서비스실행과정에서는어떤컬랙션의모든요소들에대하여여러액션들이수행되어야하는 경우가있다. 이액션들을하나의그룹으로묶은것을확장영역이라고한다. 이는컬랙션임을 표현하기위해여러개의입출력기호들을합쳐놓은듯한기호를사용한다. 2.5 중단가능한영역 (Interruptible Region) 서비스실행과정의어떤단계들은동이한이벤트에대해서실행을중단하기도한다. 2.6 매개변수집합 (Parameter Set)

P a g e 32 액티비티는일부매개변수들의값이입력되고나면수행할수도있고, 이러한경웨사용되는 모델요소가매개변수집합이다. 이는액티비티를수행할수있는입력들의집합을나타내기 위해입력기호와입력기호를포함하는사각형을나타낸다. 2.7 예외 액티비티수행중예외가발생하면예외발생액션에의해서예외가발생한다. 예외를다룰 핸들러가정의되있지않은경우액티비티수행을중단한다. 예외는반드시모델요소에게 보내져처리되도록해야하며, 즉이는예외가출력되어야함을의미한다. 출력된매개변수가 예외임을밝히기위해삼각형출력매개변수위에작성한다. 3. 액티비티다이어그램 (Activity Diagram) 액티비티다이어그램은비즈니스프로세스공학에서의조직모델링과워크플로어를명세하기 위해가장많이사용된다. 워크플로어나시스템수준프로세스에는다양한역할들이참여하기 때문에역할별로수행하는액션들을그룹화할필요가있다. 역할별로구획된한부분을 스윔레인 (Swimlane) 이라고한다. 9. 역할명세 1. 유용한도구들 역할명세에있어가장어려운작업은시스템책임을정제하고책임들을그룹화하여역할을찾는 것이다. 역할들의상호작용과역할의서비스를명세하는것은정제된시스템책임과찾아진 역할들을기준으로쉽게작성할수있다. 1.1 시스템책임정제 시스템이해야할일들액터로부터제공받은정보나시스템의서비스수행상태를기록해야 하고, 액터가서비스를시작하거나시스템이요청한행위를수행하기위해서필요로하는

P a g e 33 정보들을제공해야하며, 액터에게서비스를제공해야하고서비스제공과정에서필요로하는 계산이나의사결정등을해야한다. 1.1.1 시작조건구성 시작조건은사용자가시스템의서비스를시작하기위한조건으로, 시스템은시작조건이만족될 수있도록환경을구성해야한다. 1.1.2 선행조건과후행조건평가 선행조건이만족되지않으면서비스제공을시작하더라도진행을계속할수없기때문에, 서비스를시작하기전에평가되어야하며, 반대로후행조건은평가할필요가없다. 1.2 역할분류에따라역할찾기 유스케이스실현에대한컬레보레이션의역할은역할분류인바운더리, 컨트롤, 엔티티에따라 이름붙힌다. 바운더리유형에해당하는역할들은스토리보드의구성요소들로부터찾는다 따라서바운더리유형들은유스케이스이름에 UI 또는 스토리보드 라는접미어를사용해서 이름을작성한다. 인터페이스의경우에는앞에 I 또는 인터페이스 라는접미어를사용해서작성할 수있다. 컨트롤유형에해당하는역할들은액터에게서비스를제공하기위하여유스케이스 흐름을제어하는것으로, 유스케이스하나에하나의컨트롤을찾고그이름또한유스케이스 이름에 관리자 접미어를사용한다. 엔티티타입에해당하는역할들은실제시스템책임을 수행하는것이다. 시스템의주요책임이정보를관리하는것이기때문에엔티티타입은주로 시스템에서사용되는정보들의역할로찾는다. 1.3 컬레보레이션으로역할찾기 하나의역할이다른역할들과협력하면서자신의역할을제대로수행하기위해서는자신이 협력하는범위는어디이고, 자신과협력하는역할들은어떤것들이며, 그들이협력안해서 수행하는역할은무엇인지를이해해야한다. 역할이름이협력하는범위야협력하는다른 역할들에대한이해를반영하기위해서뿐만이아니라시스템구성요소들이역할을갖는것은 협력에참여하기때문이라는점에서컬레보레이션을기준으로역할들을찾아야한다.

P a g e 34 1.4 개념화하기 개념화한다는것은어떤현상에대해일반화하는것을말하며쉽게용어를정의하는것이라고 생각할수있다. 개념은구체적인사실들에서귀납되어형성되기때문에, 완료된사실을기준으로 해야한다. 컬레보레이션의개념화과정은역할들을나타내는원과사각형기호를사용합니다. 사각형기호는행위가수행되기전에는없던역할이행위수행후만들어지는역할을나타내위해 사용한다. 개념화과정에서수행되는행위는행위수행자쪽에서행위를당하는대상쪽으로 향하는속이찬닫힌화살표로표현한다. 개개역할이나역할들의그룹을나타내는리스트를 구성하는조건을가리키기위해그룹의경계에열린화살표로표현한다. 1.5 역할의서비스제약사항 서비스의제약사항은서비스가수행되기이전에만족되어야하는조건에해당하는선행조건, 서비스가수행되고난이후에만족되어야하는조건에해당하는후행조건, 서비스가완료되고 서비스요청자에게제공되어야하는것에대한실행조건이있다. 2. GoF 디자인패턴에적용 GoF 패턴은생성 (5 개 ), 구조 (7 개 ), 행위 (11 개 ) 로패턴들을구분하고있다. 생성패턴은객체의 생성에관련된문제들에대한해결책을, 구조패턴은클래스나객체의합성과관련된문제들에 대한해결책을, 행위패턴은클래스나객체들이상호작용하는방법과책임을분산과관련된 문제들에대한해결책을제시한다.GoF 패턴적용은다음과같은절차에따른다. 1. 문제가발생하는상황을설명한다. 2. 문제를해결하고자하는욕구를설명한다. 3. 문제에대한해결책을제시한다. 4. 문제를해결하기위해협력하는역할들과역할들사이의관계를찾아컬레보레이션으로 작성한다디자인패턴은컬레보레이션템플릿으로작성될수있으나이절에서는역할을수행하는 객체의클래스가식별되지않기때문에컬레보레이션으로만작성된다. 5. 역할들간의상호작용을시퀀스다이어그램으로작성한다.

P a g e 35 6. 역할들의서비스를액티비티다이어그램으로작성한다. 2.1 시나리오정제 유스케이스기술서에작성된액터와시스템의상호작용을액터와시스템구성요소들의상호 작용으로정제한다. 액터부분은변화가없기대무에액터의책임부분은변하지않는다. 달라지는것은액터아상호작용하는것이시스템에서바운더리역할을수행하는구성요소로 바뀐다는것뿐이다. 시나리오정제작업은다음과같은절차로수행된다. 1. 시작조건과선행조건에서수행해야하는책임을바운더리또는컨트롤유형의역할에 할당한다. 2. 액터의책임부분에서암시적으로작성된대화상대인시스템부분을바운더리유형의역할 이름으로바꾼다. 3. 바운더리유형의역할책임을컨트롤유형의역할책임으로위임한다. 4. 컨트롤유형의역할책임을엔티티유형의역할책임들로위임한다. 2.2 역할의서비스명세 시퀀스다이어그램에서작성된메시지들을사용해서역할들의서비스를찾을수있다. 역할의 서비스들에해당하는메시지는서비스를요청하는입장에서작성되었기때문에역할의서비스 이름을명명하기위해서는서비스를제공하는입장에서메시지를변경해야한다. 10. 객체와클래스 Figure 13. Object Diagram

P a g e 36 1. 객체 객체지향방법론은객체를이용하여실세계를모방, 실세계에대한 dlgomf 높이고시스템구현에 대한실제적인기반을제공하는것이다. UML 에서객체의정의는문제영역 ( 실세계 ) 과해결 영역 ( 시스템 ) 모두를만족시킨다. 1.1 객체정의 객체란실세계에서존재하거나또는개념적으로존재하는실체에대한표현이다객체는조의 트럭또는나의컴퓨터와같은구체적인것을나타낼수도있고화학작용같은개념적인것을 나타낼수도있다. 객체는잘정의된경계와적용상의의미를가지는개념, 추상도는사물이다. 시스템내부의각각의객체는상태, 행위, 정체성과같은세가지특성을가지고있다. UML 에서는 클래스에대한인스턴스명세가객체인데, 인스턴스명세란모델링되는시스템내부의실체의 존재를명세하고완벽하게또는부분적으로그실체를기술한다. 기술내용에는실체의 분류자 (Classifier), 인스턴스의종류, 구조적특성값들을포함한다. 1.2 링크 (Links) 링크란객체들사이의개념적또는물리적연결이다. 수학적으로링크는튜플 (Tuple) 로서 정의된다. 즉순서를갖는객체리스트이다. 링크는연관의인스턴스이다. 링크는연결되는객체들사이에직선으로작성된다. 링크의끝에는연결된상대객체에대한 자신의역할을작성할수있다. 1.3 스냅샷 (Snapshot) 순간적인순간에객체들과그들사이의연결관계들을스냅샷이란개념을사용하여작성할수있고, UML 에서는객체다이어그램 (Object Diagram) 으로작성한다. 스냅샷을연속적으로돌리게되면 객체의전체생애주기동안의행동에대해알수있는동적모델을작성할수있다. 객체의동적 모델은상태머신 (State machine) 에의해작성된다. 1.4 객체다이어그램 (Object Diagram)

P a g e 37 객체다이어그램은객체들사이의링크를가지고어떠한순간에객체에대해알려진것이 무엇인가를표현하는다이어그램이다. 객체다이어그램은스냅샷이라는용어로사용할수있다. 2. 클래스 (Classes) 클래스란공통의속성들오퍼레이션들, 관계들, 의미들을공유하는객체들의집합에대한 기술 (description) 이다. 클래스는어떻게객체를생성하고, 어떻게성장시키며어떻게소멸시킬것에 대한객체의생애동안필요한모든법칙을규정해야한다. 또한클래스의모든객체들은이 법칙에따라야한다. 클래스는분류자기호를이용하여표시한다. 2.1 속성 (Attributes) 속성이란클래스의구조적특성에이름을붙인것으로구조적특성에해당하는인스턴스가 보유할수있는값의범위를기술한다. 2.2 오퍼레이션 (Operations) 오퍼레이션이란이름, 타입, 매개변수들과연관된행위를호출하는데요구되는제약사항들을 명세하는클래스의행위적특징이다. 오퍼레이션은서비스에대한명세로실제적인구현내용을 담고있지는않는다. 오퍼레이션의구현은메소드 (Method) 에의해서수행된다. 3. 데이터타입 (Data Types) 데이터타입이란오퍼레이션이모두순수함수 (pure function) 로되어있는분류자이다. 데이터 타입은분류자로서속성과오퍼레이션을가지나, 인스턴스로서의객체가아닌데이터값만을 가진다. 데이터타입은 <<data type>> 이라는키워드를갖는분류자기호로표현한다. 3.1 기본형 (Primitive Type) 기본형은미리정의된데이터타입으로내부구조가없다. 기본형은 <<primitive>> 키워드를갖는 분류자로표현하며, 내부구조가없기때문에속성과오퍼레이션부분은포현할필요가없다. 3.2 열거형 (Enumeration)

P a g e 38 열거형은열거된값들중하나의값만을취할수있는데이터타입이다. 열거형은 <<enumeration>> 키워드를갖는분류자기호로표현한다. 오퍼레이션부분은표현할필요가 없다. 4. 인터페이스 인터페이스는역할을표현하는 UML 모델요소로서객체들에의해실현되어야한다. 역할이 제공해야하는서비스들은속성과오퍼레이션으로작성된다. 서비스가속성으로작성될때의 의미는복잡한행위수행없이단순히숙속으로표현된정보의값을서비스요청자에게제공하는 것이다. 인터페이스는 <<interface>> 키워드를갖는클래스기호로표현된다. 4.1 구현 (Implementation) 구현은분류자와인터페이스사이의특수한형태의실현관계이다. 구현관계는속이빈삼각형 머리를갖는점선화살표에의해표시된다. 5. 포트 (Port) 시스템에있어, 객체들은클래스로부터만들어지기때문에시스템비용은클래스를만드는데 드는비용이대부분이다. 따라서시스템개발생산성을높이기위해한번만들어진클래스들이 여러인터렉션들에서재사용될수있어야한다. 그러기위해서는, 특정클래스들의상호작용이 아닌역할들의상호작용으로명세하고클래스들이그역할을실현도록해야한다. 재사용을 극대화하기위해서는클래스의재사용을넘어서인터렉션에작성된역할들의상호작용을 재사용해야한다. 포트는분리된상호작용을명세하는모델요소이다. 포트란클래스와클래스의 외부환경또는클래스와클래스의내부부분들사이의개별적인상호작용을명세하는클래스의 구조적특징이다. 6. 합성구조 (Composoite Structure) 부품을가지고완제품을만다는방식을합성으로하고이와같은방식으로만들어지는구조를 합성구조라고한다. 부품이되는것을부분이라고하고완제품이되는것을전체라고한다.

P a g e 39 부분들은전체의일부로사용되기때문에, 어떤전체에포함되는부분들은다른전체에사용될 수없다. 7. 컴포넌트 컴포넌트란내부를캡슐화하고컴포넌트의외부환경안에서전체적으로대체가능한시스템의 모듈이다. 컴포넌트는내부구조를캡슐화하고다른모델요소를포함할수있는특수한형태의 클래스이다. 컴포넌트기반개발은이미만들어진컴포넌트를 조립 하여개발하는것이다. 컴포넌트기반개발의장점은재사용이다. 기존부품을재사용함으로써개반기간과개발비용을 줄일수있다. 컴포넌트는개발주기모든단계에서동일하게컴포넌트라는용어를사용하기 때문에개발주기에따라명시적으로구분하는게좋으며, 명세단계에서는명세컴포넌트, 설계 단계에서는설계컴포넌트같은용어를사용한다. 컴포넌트외부와컴포넌트내부를연결하는 커넥터를위임커넥터 (Delegate Connector) 라고한다. 화살표의방향은제공인터페이스포트의 경우에는포트에서실현클래스로, 요청인터페이스의경우에는실현클래스에서포트로향하게 한다. 컴포넌트와컴포넌트를직접적으로연결하는커넥터를어셈블리커텍터 (Assembly Connector) 라고한다. UML 에서는어셈블리커넥터를제공인터페이스와요청인터페이스의 결합으로표현하고, 의미적으로거기에커넥터가있다고생각하도록한다. 11. 관계 1. 모델요소들사이의관계 관계는모델요소들사이의연결을의미한다. 관계는방향성이있는관계와없는관계가있다. 관계의출발점이되는요소들을일반적으로소스 (Source) 또는클라이언트 (Client) 라고하고,, 관계의목표점이되는모델요소들을타깃 (Tartget) 또는서플라이어 (Supplier) 라고한다. UML 에서는연관관계를제외한모든관계들이명시적으로방향성으로나타내야한다. 1.1 의존관계

P a g e 40 의존관계란하나이상의모델요소들이그들의명세와구현을위해다른모델요소들을요구하는 관계이다. 이것은의존요소들의의미가완벽해지기위해서공급자요소에의미적으로또는 구조적으로의존한다는것을의미한다. 의존관계는의존하는쪽에서의존되는쪽으로향하는 점선으로된화살표기호로서표현한다. 1,1,1 사용 (Usage) 관계 사용관계는일반적인의존관계의의미를나타내는것으로, 의존하는모델요소의명세나 구현을위해의존되는모델요소를사용하는관계로나타낸다. <<use>> 키워드를사용해서 표현한다. 1.1.2 추상 (Abstract) 시스템은매우복잡하기위해하나의추상수준과하나의관점으로표현해서이해하기는어렵다. 따라서시스템개발에있어좀더추상적인수준에서점점구체화하는방법을사용하고, 다양한 사용자에따라다른관점들을사용한다. 또한시스템개발단계를거쳐가는과정에서같은 개념을서로다는추상수준이나서로다른관점에서표현해야한다. 이러한상황에서, 추상관계란같은개념에대해서로다른추상수준들또는서로다른관점들에서작성된둘 이상의모델요소들을연결하는관계이다. 추상관계는 <<abstraction>> 키워드를갖는의존관계로 표현한다. 1.1.3 대체 (Subsitution) 대체는런타임시상속이아닌인터ㅔ이스를구현하거나동일타입의포트를가지고소스 인스턴스들이타깃인스턴스들을대체할수있는관계이다. 대체관계는 <<substitude>> 키워드를갖는의존으로표현한다. 1.1.4 허용 (Permission) 허용관계는타깃이소스에게자신이포함하고잇는모델요소에접근할수있도록허용하는 관계를나타낸다허용관계는 <<permit>> 키워드를갖는의존관계로표현한다. 1.2 연관 (Association) 관계

P a g e 41 연관이란인스턴스들사이의구조적관계이다. 연관은인스턴스들참조하는값을가진 튜플 (tuple) 의집합을기술한다. 하나의링크는연관된타입들의개개인스턴스들의값으로 구성된하나의튜플이다. 인스턴스들사이의연결을링크라고한다. 연관은인스턴스들사이에서 링크의생성과소멸에대한법칙을담고잇는설계도역할을한다. 연관은일반적으로두개의 분류자를연결하는데이러한연관을이중연관 (binary association) 이라고한다. 하나의분류자만을 연결하는연관은재귀 (Reflexive) 연관이라고하고, 세개이상의분류자와연관을다중 (n-ary) 연관이라고한다. 다중연관은다이아몬드기호를사용한다. 연관관계에방향성을표현할수 있는데, 한쪽방향만이표현된것을일방향연관이라고하고, 양쪽방향모두표현된것을양방향 연관이라고한다. 방향성이없다는것을명시적으로표현하기위해서는연관지점에 x 기호를 표현한다. 부분과전체의관계도연관관계를통해포현할수있는데이는전체에해당하는연관 지점에작은마름모기호를사용해서표현한다. 어그리게이션관계와컴포지션관계는연관 관계의특수한형태중하나이다. 2. 클래스관계 UML 에서클래스관계를나타내기위한대표적인관계는의존관계, 연관관계, 일반화관계이다. 클래스들사이에관계를만들고관계의의미를알기위해서는관계가만들어지는범위 (Context) 를 알아야한다. 2.1 시스템객체들의관계 의존관계와일반화관계는클래스범위로, 연관관계는객체범위로적용된다. 클래스범위에 적용된다는의미가해당클래스의모든객체들에동일하게적용되기때문에관계의의미를 설명하기위해서객체들의관계를표현할필요가없다는것이다. 클래스의관계에표현되는사용 관계는의존하는클래스의명세나구현을위해의존되는클래스를사용하는관계를나타낸다. 클래스의명세는속성이나오퍼레이션을명세하는것이고, 구현을오퍼레이션의구현에해당하는 메소드를정의하는것이다. 연관관계는객체들사이의링크들에대한명세이다. 객체지향에있어 링크를유지하는방법은일방향연관의경우상대객체에접근할수있는객체가상대객체에

P a g e 42 대한참조자를속성값으로갖고, 양방향연관의경우링크되는객체들각자가상대에대한 참조자를갖는것이다. 속성이구조적특징이기때문에, 연관관계는구조적관계라고불린다. 연관관계와의존관계의차이는의존관계는클래스범위로적용되고, 연관관계는객체범우로 적용된다는것이다. 2.1.1 의존관계검증방법 의존관계를작성한후에의존되는클래스를감추고도의존되는클래스를완벽하게설명할수 있다면이관계는잘못된것이라고할수잇다. 2.1.2 의존관계찾는방법 클래스오퍼레이션의매개변수타입이나리턴타입, 또는오퍼레이션의메소드정의부분에 사용되는클래스들은의존관계후보이다. 속성타입이나이들중속성에참조값으로연결된 객체가특정행위수행을위해일시적으로필요하다면의존이된다. 즉, 반드시연결된객체가 사용되어야만하는것이아니라의존되는타입의어떤객체라도사용될수있으면의존관계이다. 2.1.3 연관관계 연관관계는구현언어의특성에의해구조적으로연결된다는것을의미한다. 연관관계는구조적 관계라고불리운다. 컴포지션관계와어그리게이션관계는전체와부분의관계를나타낸 관계이다. 이는부분에해당하는클래스가이미존재해야함을의미하며, 이는의존관계와의미가 같다. 2.1.4 연관관계를갖는객체들의존재의미 독립적으로존재하는객체들은 특정컨텍스트에서관계를맺게되는데이러한관계를연관 관계라고한다. 객체들은두객체들사이에어떤행위가수행되기전까지서로에대해 독립적으로존재한다. 2.1.5 어그리게이션관계를갖는객체들의존재의미

P a g e 43 어그리게이션관게는특수한연관관계이기때문에연관의존재의미를계승한다. 어그리게이션은 부분을가지고전체를구성하거나부분을포함하는두가지경우다사용하기때문에이둘을 분리해서생각해야한다. 2.1.5.1 부분의합이전체일때의어그리게이션관계 의존의의미에따라의존되는객체는의존하는객체의존재에영향을받지않는다. 어그리게이션 관계는전체가부분에의존하기때문에부분에해당하는객체들은관계를갖기전까지 독립적으로존재할수있다. 2.1.5.2 전체가부분을포함할때의어그리게이션관계 전체가부분을포함한다는것은부분의존재와는상관없이전체가존재하면서단지부분들에 해당하는객체들의참조자를포함하는것을나타낸다. 어떤객체가부분으로서전체에 포함된다는것은전체를통해서만접근할수있다는것을의미한다. 2.1.6 컴포지션관계를갖는존재의미 컴포지션관계는어그리게이션관게와마찬가지로연관존재의미를계승하며, 부분을가지고 전체를구성하는것과부분을포함하는두가지경우를분리하여생각한다. 2.1.6.1 부분의합이전체일때의컴포지션관계 컴포지션관계는전체가부분들을값으로포함함으로써형성되는관계이다. 값으로포함한다는 것은실제그객체를부분으로포함한다는것이다. 컴포지션관계에서는, 전체와부분이동시에 존재하게할수있으며, 부분들이다른전체에서사용되다가새로운전체의부분으로사용될수 없다. 또한앞의이유로부분들이전체가생성될때같이만들어진다. 2.1.6.2 전체가부분을포함할때의컴포지션관계 전체가부분을포함하는어그리게이션관계의의미와동일하게적용된다. 단지부분들이값에 의해포함되기때문에저체가소멸될경우같이소멸된다는점이다르다. 2.1.7 연관관계들의다중성

P a g e 44 각각의관계특성에대해일반적으로적용할수있는다중성을생각해볼수있다. 어그리게이션 관계는부분객체들에해당되는클래스가하나일때, 다중성의최소값이 0 을가지면잘못된 것이고, 컴포지션관계에서는전체부분의다중성의최대값이 1 이상으로작성되었다면잘못된 것이다 2.1.8 클래스의일반화계층과공통된속성의수와의관계 개념을일반화할수록공통된속성의수는줄어들고, 구체화할수록공통된속성의수는 늘어난다. 2.2 연관클래스 (Association Classes) 하나의객체의속성값으로가아니라객체들을연결하는링크에서다루어져야하는정보는튜플로 작성될수있다. 이러한속성은클래스의구조적특성이기때문에연관관계가클래스역할을할 수있다. 이는연관관계에점선으로연결하여표현한다. 2.3 한정자 (Qualifier) 한쪽연관지점의객체를사용해서다른쪽연관지점을객체나객체집합을어떻게찾을 것인가에대한방법중하나이다. 한정자는링크에객체들을찾을수있는속성값을갖고 있도록하는방법이다. 한정자는연관지점의작은사각형안에 한정자이름 : 타입 형식으로 표현된다. 한정자는여러개존재할수있다.

P a g e 45 12. 상태 (UML State Diagram) Figure 14. State Diagram UML의상태다이어그램은특정클래스소속객체의모든상태변화와이에영향을주고받는이벤트들의동작을표현한다. 대부분의소프트웨어시스템은이벤트를중심으로동작하며, 이는곧시스템이상시적으로특정이벤트의발동을감지하고자대기하고있음을뜻한다. 이벤트는어떤메세지가될수도있고, 시간의흐름, 특정조건, 또는오류등무언가반응을야기할수있는동작이라보면된다. 상태다이어그램내의구성요소들은보면다음과같다. 먼저최초상태를보여주는색이칠해진원이있고, 반면에제일마지막에있는빈원은최종상태를뜻한다. 다음으로둥그스름한사각형들은상태를표기한것으로, 사각형의상단에상태의이름이명시되어있다. 상태사각형중중간에줄이그어져있는경우는그상태에서일어날수있는액티비티를아래에추가로명시한경우이다.

P a g e 46 13. 개발 (Deployment) Figure 15. Deployment Diagram 1 개발다이어그램은시스템내물리적컴포넌트들의위상을시각화시켜주는다이어그램이다. 따라서개발환경을도식화시켜준다고할수있고, 이다이어그램은주로노드들과그들간의관계의표현으로나타나게된다. 여기서의각노드는시스템을적용하게되는각하드웨어를표현시켜준다고보면된다. 예를들어위의그림에서의경우, 각노드는웹서버, DB서버, 메인프레임, 어플리케이션서버등시스템의각컴포넌트가상주하게되는하드웨어를보여준다. 개발다이어그램은시스템의성능, 호환성, 유지보수성, 그리고확장성을조절하는데있어서큰역할을하므로소프트웨어공학에있어서매우중요하다. 개발다이어그램을그리기위해선노드로삼을하드웨어들과, 그노드들, 그러니까하드웨어들간의관계를파악하고있어야한다.

P a g e 47 C. End of the Line : 실제적용방법과현행 UML 툴 14. 실제적용프로세스 그렇다면 UML 을실제로이용하여개발하려면어떤과정을거쳐야할까? 간략히정리해보면다음 과같은절차를밟게된다. 기억해야할점은단체나상황에따라세부적인절차등은차이가있 을수있으나, 위에서언급한다이어그램들을전반적으로각각비슷한상황에적용한다는것이다. 1. 비즈니스절차 (Business Process) 의모델을딴다. 비즈니스절차모델은그프로젝트에있어 서의전반적인내용을커버하게되며, 이는곧이후에 Use Case Model 의기반을형성하고 프로젝트의틀을잡아주게된다. 2. Use Case Model 을작성한다. 앞에서작성한비즈니스절차모델을반영하여실제사용을하 게될사용자의입장에서필요로할어떤기능들을제공할것인지미리계산하도록한다. 각 Use Case 는사용하게될절차를표현하기위해서로연결을지어놓게된다. 3. Use Case 를수정하고보완한다. Requirements, 제약사항, 복잡성, 시나리오, 그리고비고사항 등을모두반영하도록한다. 4. 비즈니스절차모델에서의 input/output들과 Use case 에서의세부사항을이용하여도메인모델을작성하고, 절차 (Sequence) 다이어그램, 콜라보레이션다이어그램, 그리고인터페이스모델을틀을잡아준다. 이작업은시스템내의 물체 / 객체 들을정의해주고, 이들이어떻게서로상호작용할것인지, 그리고사용자가이들을가용하기위해사용할인터페이스에대해기술할수있도록해준다. 5. 위의도메인모델, 콜라보레이션, 절차다이어그램, 인터페이스모델을통해 Class 다이어그 램을따도록한다. 클래스다이어그램은위에서언급햇듯시스템의정확한구조를잡아주게 되고, 자료와변수, 행동, 작업등을모두세부적으로기술해주게된다. 6. Class 다이어그램을통한클래스모델링이완수되면이제이모델을좀더세분화하여패키 지와컴포넌트로나눌차례이다. 여기에서컴포넌트다이어그램과패키지다이어그램을제작 하게된다.

P a g e 48 7. 현재까지의작업이된단계에서아마초기의비즈니스절차모델과유스케이스모델에서반 영하지못한추가적인요구사항들이나타나고제시되었을것이다. 이들을이후에반영하기 위해정리해놓도록한다. 8. 이제개발다이어그램을이용하여개발모델링을할차례이다. 본격개발에있어바로전단계로서하드웨어사양, 운영체제, 네트워크사항, 인터페이스, 부가소프트웨어등을모두기술하게되고, 어디에어떻게 implement 할것인지, 안정성보장을위해무엇을할것인지등이나타나게된다. 9. 개발을한다. 10. 테스팅, 디버깅등으로개발된시스템을보완하고출시전까지수정하도록한다. 15. Reference 1. 생각하며배우는 UML 2.0, 김현남, 2004 2. Sparx UML Tutorials. http://www.sparxsystems.com/uml-tutorial.html http://www.sparxsystems.com/resources/tutorial/uml_tutorial2.html 3. IBM UML Introductions http://www.ibm.com/developerworks/rational/library/769.html 4. Wikipedia Articles http://en.wikipedia.org/wiki/unified_modeling_language http://en.wikipedia.org/wiki/class_diagram 5. OMG UML Specifications http://www.omg.org/spec/