UML 사용보고서 소프트웨어모델링및분석레포트 201011334 박진성 201011338 송병우 201013759 근량 1
1. UML 1.1. 의미 1.2. 기능 1.3. 구조 1.4. Structure Diagram 1.5. Behaviour Diagram 2. Collaboration Diagram Index 2.1. Semantics 2.2. Notation 2.2.1. Collaboration Instance 2.2.2. Collaboration 2.3. Example 2.4. Mapping 3. Activity Diagrams 3.1. Semantics 3.2. Notation 3.3. Example 3.4. Mapping 4. 활동상태 (Action State) 4.1. Semantics 4.2. Notation 4.3. Presentation options 4.4. Example 4.5. Mapping 5. 하위상태 5.1. Semantics 5.2. Notation 5.3. Example 6. 컴포넌트 6.1. 인터페이스 6.2. 컴포넌트다이어그램작성방법 6.2.1. 포트생성 6.2.2. 제공인터페이스 (Provided Interface) 작성 6.2.3. 요청인터페이스 (Required Interface) 작성 6.3. 컴포넌트모델과 UML 과의대응관계 6.4. 컴포넌트사이의연결관계및구현관계 2
7. Use Case Diagram 7.1. Use Case와 Actor 그리고이들간의관계표현 7.2. 구성요소 7.2.1. Actor 7.2.2. Use Case 7.2.3. Actor와 Use Case의관계 7.2.4. Use Case와 Use Case 관계 7.3. Use Case Specification 7.3.1. Actor와 Use Case 간의상호작용에대한기술문서 7.3.2. 구성요소 7.3.3. Use Case 이름 7.3.4. Use Case 간략한설명 7.3.5. Event 흐름 7.3.6. 특별한요구사항 7.3.7. 사전조건 7.3.8. 사후조건 7.3.9. 확장점 7.3.10. System 관련그룹 7.4. Use Case Diagram 7.4.1. include 7.4.2. exclude 7.4.3. Generalization 7.5. Use Case의사례 8. Class Diagram 8.1. 의미 8.2. 구성 8.3. 연결 8.4. Object diagram과의차이 8.5. Classifier 8.6. Class 8.6.1. 의미 8.6.2. 표현명 8.6.3. 용법 8.7. 사용예 9. Deployment Diagram 9.1. 구성요소 9.1.1. Graphical node 9.1.1.1. artifact 9.1.1.2. node 9.1.1.3. deployment 3
9.1.2. Graphical path 9.2. 용법 9.3. 사용예 10. Sequence Diagram 10.1. 구성요소 10.1.1. Object Lifeline 10.2. 용법 10.3. 사용예 4
1. UML 1.1. 의미 객체지향소프트웨어를모델링하는표준그래픽언어 1980 년대말부터 1990 년대초에객체지향으로모델링하는과정과모델링언어출현설계와표현방법의급증으로혼란을초래 1994 년 Verdix 사에합병된 Rational 사에서 Ada 와 C++ 로개발되어있던환경을 Verdix 사의코드생성기와런타임으로병합. 1995 년 Rational 사의세명의객체지향전문가가서로의일을통합하기위해 UML 을개발했다. 1.0 버젼이 Object Management Group(OMG) 에제출되었고, 후속개발이추진되었다. 1997 년 OMG 가 UML 표준화를추진하였고 2005 년 ISO/IEC 에 1.4.2 버젼이채택되어국제표준으로제정되었다. 1.2. 기능 자세한의미 (semantic) 표현확장메커니즘관련텍스트언어 Object Constraint Language(OCL) UML 의목적은소프트웨어설계방법론이아니라표현을도와주는것이다. 5
1.3. 구조 (v2.2) 1.4. Structure Diagram 시스템의설계에서꼭존재해야만하는것을강조하여표현한다. 구조를표현하므로 SA 에서주로사용된다. 1.5. Behaviour Diagram 설계된시스템에서어떤일을해야만하는가를강조하여표현한다. 시스템의기능을표현해야할때에따로사용된다. 아래에서는 ISO 표준에의해전통적으로주요하게사용되는다이어그램을설명한다. 2. Collaboration Diagram 2.1. Semantics Collaboration diagram 은인스턴스 (Instance) 들의수행되어지는역할과특정한상황속에서요구하는관계들의집합이포함된 Collaboration 의한측면을표현하거나인스턴스 (Instance) 들과그것들의관계의집합과함께 CollaborationInstanceSet 을표현한다. 그다이어그램은원하는결과를달성하기위한역할을수행하는인스턴스들사이에서특정한메세지 (Stmuli) 들의집합을정의하는 InteractionInstanceSet 을표현하기도한다. 하나의 Collaboration 은해당작동 (Operation) 이나특성 (Classifier) 의구현 (realization) 설명을위해사용되어진다. Use case 와같이, 하나의특성 (Classifier) 을설명하는 Collaboration 은대개특성 (Classifier) 들과관계 (Association) 들을참조한다. 반면에, 작동 (Operation) 을설명하는 Collaboration 은해당작동 (Operation) 의인자 (Argument) 들과지역변수 (local variable) 들을포함하고보통관계 (Association) 들은그작동 (Operation) 이갖고있는특성 (Classifier) 을연결한다. 6
2.2. Notation 어떤 collaboration diagram 은서로연결되어진인스턴스 (Instance), 특성역할 (Classifier Role), 관계역할 (Association Role) 의한측면을그래프로보여준다. 이러한것은상호작용 (Interation) 또는상호작용집합 (InterationInstanceSet) 에의해서정해진커뮤니케이션을포함할수있다. 왜냐하면 collaboration diagram 은때때로프로시저 (Procedure) 들을설계하는데에도움을주기위해사용되어진다. 그것들은흔히링크 (Links) 또는관계역할 (Association Roles) 들을표현하는데화살표를이용해서방향을보여준다.( 링크또는관계역할을나타내는박스들사이에한방향을가리키는하나의화살표.) 상호작용 (Interation) 의순서는보통 1 로시작하는일련의숫자와함께설명된다. 하나의절차적인작동흐름을위해서, 하위커뮤니케이션숫자들을중첩호출과함께중첩된다. 동시에여러인스턴스 (Instance) 들의상호작용을하는비절차적배열을위해, 모든해당일련의숫자들은같은레벨에있다 ( 이숫자들은중첩되지않는다 ). 어떠한상호작용도갖지않는 Collaboration diagram 은상호작용들이발생할수있는상황을보여준다. 또, Single Operation 이나모든클래스 (Class) 또는클래스들의그룹을위한상황조차도보여줄수있다. 이표준은아래조건의실시하에인스턴스, 링크의생성과파괴의여부를보여주는데사용될수있다. 인스턴스 (Instance) 와링크 (Link) 들은 { new } 로설계될수있는것이실행되는동안만들어진다. 인스턴스 (Instance) 와링크 (Link) 들은 { destroyed } 로설게될수있는것이실행되는동안파괴된다. 인스턴스 (Instance) 와링크 (Link) 들은 { transient } 로설계될수있는실행되고파괴되는동안만들어진다. 이러한것들은인스턴스 (Instance) 들간의상세한상호작용으로부터끌어낼수있는생명의상태에한해서변경한다. 그것들은기호의편의가제공된다. 2.2.1. Collaboration Instance 인스턴스레벨에서주어지는하나의 collaboration diagram 은한 CollaborationInstanceSet 을보여준다. CollaborationInstanceSet 이란, 각기인스턴스와링크이오브젝트박스와선으로매핑되는컬렉션을뜻한다. 이러한인스턴스들은해당 CollaborationInstanceSet 의 Collaboration 의특성역할 (Classifier Role) 과관계역할 (Association Role) 들을맞게한다. 또한, 해당다이어그램은링크 (Link) 를통해전달되어지는자극 (Stimuli) 과일치하는선들을연결하는화살표를포함한다. 그다이어그램은성능에간접적으로영향을미치거나접근하는인스턴스 (Instance) 들이포함하는어떤동작 (Operation) 또는특성 (Classifier) 의구현과관련된인스턴스 (Instances) 들을보여준다. 그다이어그램은인스턴스 (Instance) 들간의링크 (Link) 들을프로시저의인자들, 지역변수들, 자기자신의링크들을표현하는것을일시적으로포함하여보여준다. 개개의속성값들은보통명시적으로보여지지않는다. 만약자극 (Stimuli) 가속성값들에게보내져야만한다면, 그속성 (Attribute) 들은관계 7
대신사용할수있도록설계되어야만한다. 2.2.2. Collaboration 특정레벨에주어진어떤 collaboration diagram 은 collaboration 속에역할들이정의된하나의 Collaboration 을보여준다. 함께, 이러한역할들은해당 Collaboration 의동작 (Operation) 또는특성 (Classifier) 가붙여진구현 (realization) 의형태를이룬다. 그다이어그램은 Collaboration 안에특성역할 (ClassifierRole) 과관계역할 (AssociationRole) 들에해당하는클래스박스들과라인들의집합을포함한다. 이러한경우에해당화살표들은메세지 (Message) 들이매핑된라인들에연결되어있다. 2.3. Example 8
2.4. Mapping Collaboration diagram 은가능한한상호작용 (Interation), CollaborationInstanceSet, InterationInstanceSet 과함께한관점을매핑한다. 3. Activity Diagrams 3.1. Semantics Activity graph 는 State machine 의변화이다. 해당상태들은하위상태 (Subactivity state) 나활동상태 (Action state) 들의성능을표현하고해당상태의전이 (Transition) 들은하위상태 (Subactivity state) 나활동상태 (Action state) 들이완료됨에따라일으켜진다. 9
이것은자기자신절차의 State machine 을표현한다. 3.2. Notation Activity diagram 은모든 ( 또는적어도대부분 ) 상태들이활동상태 (Action state) 나하위상태 (Subactivity state) 들로이루어져있고원본상태 (Source state) 에서모든전이 (Transtion) 들은하위상태 (Subactivity state) 나활동상태 (Action state) 의완료에일으켜지는 state diagram 의특별한경우이다. 그전체 activity diagram 은 use case, package, operation 의구현과같이모델을통해서특성 (classifier) 이연결된다. 이다이어그램의목적은 ( 외부적인이벤트와반대되는 ) 내부적인프로세싱에의해서주도되는절차에집중하는것이다. 대부분 ( 모든 ) 이벤트들이발생하는상황에서액티비티다이어그램의사용방법은내부적으로생성되는액션 ( 절차적인컨트롤플로우 ) 들의완성을표현한다. 이벤트들이비동기적으로발생하는상황에서정식 state 다이어그램을사용한다. 3.3. Example 10
3.4. Mapping Activity 다이어그램은 Activity Graph 와연결된다. 4. 활동상태 (Action State) 4.1. Semantics 활동상태 (Action state) 는하나의 entry 활동과적어도한개의암묵적인완료이벤트 ( 방어조건을가질수있다면여러같은전이 (transition) 들이있을수있다 ) 를포함하는 outgoing 전이 (transition) 를가지는상태 (state) 의줄임말이다. 활동상태들은내부적인전이 (transition), 명시적인이벤트를기반으로하는 outgoing 전이또는종료액션 (action) 들을갖지못한다. 이러한것에는 normal 상태들을사용해라. 하나의액션상태에의해나가는전이들은어떠한이벤트신호도포함하지못한다. 같은전이들은상태에서의액션에의해암묵적으로일으켜진다. 이런전이 (transition) 들은보호조건과액션을포함하지않을수있다. 활동상태 (action state) 의정식용도는알고리즘 ( 프로시져 ) 또는워크플로우프로세스의실행에가담하는모델이다. 4.2. Notation 활동상태 (Action state) 는위와아래는스트레이트, 양쪽은볼록한모양으로보여진다. 활동식 (action expression) 은그모양 (symbol) 안에놓여진다. 활동식은 diagram 내에서유일할필요가없다. 4.3. Presentation options 활동 (Action) 은인간의언어, 수도코드또는프로그래밍언어로묘사될수있다. 이것은오브젝트소유의속성들과링크들만사용할수있다. 주의하라, 활동상태 (action state) 표기는일반상태다이어그램에서도사용될수있다. 그러나, 그것들은 activity daigram 과함께대부분공통으로사용되어진다. 4.4. Example 4.5. Mapping 활동상태 (Action state) 의표시는 entry action 상태와매핑되어지는 action expression 에서 ActionState 와연결된다. 이런상태는일반적으로쓰인다. 11
5. 하위상태 (Subactivity state) 5.1. Semantics 하위상태 (Subactivity state) 는액티비티그래프를호출한다. 하위상태가들어갈때, 일반액티비티그래프로써실행될수있는 중첩된 " 액티비티그래프이다. 하위상태는중첩된그래프의마지막상태에도달하거나, 하위상태의바깥으로나가는전이 (transition) 가일어날때까지끝나지않는다. 액티비티그래프 (activity graph) 안에서상태들은일반적으로어떤이벤트들도발생시키지않는다면, 하위상태 (subactivity states) 는중첩된그래프가끝날때, 일반적으로종료되게된다. 단일액티비티그래프 (activity graph) 는많은하위상태 (subactivity graph) 들에의해호출되어질수있다. 5.2. Notation 하위상태 (subactivity state) 는일반활동상태 (action state) 에서오른쪽아래에중첩액티비티다이어그램 (activity diagram) 이묘사된아이콘이추가된형태로보여진다. 이표기는중첩된구조를지원하는어떤 UML 에서도적용할수있다. 아이콘은반드시중첩된구조의형태를암시해야한다. 5.3. Example 6. 컴포넌트 컴포넌트 (conponent) 스테레오타입이있는클래스타입혹은아이콘형태로표현. 컴포넌트는인공물 ( 시스템사용이나생성에관한정보의조각 ) 로구분될수있는컴퓨터시스템모듈러이다. 컴포넌트는소프트웨어시스템의기능을정의한다. 컴포넌트는다른컴포넌트가접근할수있도록인터페이스를제공한다. 접근하고있는컴포넌트에서는필수의인터페이스를사용한다. 컴포넌트모델은 M = ( S, V, E, I, P, N, T ) 로정의한다. S : (T) X (T) : 컴포넌트상태 (state) 들의집합. V : N X VT : 변수 (Variable) 들의집합. E : 이벤트 (event) 들의집합. I : (E) : 인터페이스 (interface) 들의집합 P : N X N X I X PT : 포트 (Port) 들의집합. N : 컴포넌트이름, 변수이름, 인터페이스이름들의집합. T : S X G X P X E X (A) X S : 상태전이 (Transition) 들의집합. G : Boolean 식으로표현가능한수행조건 (guard condition) 의집합 A : 행위식 (Expression) 들의집합. 12
6.1. 인터페이스인터페이스를나타내는방법에는두가지가있다. 첫번째는인터페이스의정보를가지고있는사각형을텅빈삼각형머리를한점선으로컴포넌트에연결하는방법이고, 두번째는작은원을실선으로컴포넌트에연결하는방법이다. UML2.0 에서는인터페에스가컴포넌트에의해제공되며, 다른컴포넌트에는필수적으로필요하다는것을공과소켓표기법으로도표현할수도있다. 공의모양은이미알고있듯이작은원모양이고, 소켓은다른컴포넌트에실선으로연결된작은반원 ( 열려있는 ) 모양이다. 공은제공되는인터페이스를의미하고, 소켓은필수의인터페이스를의미한다. 6.2. 컴포넌트다이어그램작성방법 6.2.1. 포트생성컴포넌트를선택하고, 오른쪽마우스버튼으로팝업메뉴를디스플레이한다. Add Port 메뉴항목을선택하고, 세부항목으로포트를작성할위치를선택한다. 6.2.2. 제공인터페이스 (Provided Interface) 작성컴포넌트를선택하고, 오른쪽마우스버튼으로팝업메뉴를디스플레이한다. Add Provided Interface 메뉴항목을선택한다. 제공인터페이스는컴포넌트의왼쪽에생성된다. 6.2.3. 요청인터페이스 (Required Interface) 작성컴포넌트를선택하고, 오른쪽마우스버튼으로팝업메뉴를디스플레이다. Add Required Interface 메뉴항목을선택한다. 제공인터페이스는컴포넌트의오른쪽에생성된다. 6.3. 컴포넌트모델과 UML 과의대응관계컴포넌트모델은 UML 에서크게구조모델과행위모델로나누어지며, 구조모델은 UML 13
Class Diagram, 행위모델은 UML Statechart 로표현한다. 컴포넌트의구조모델을 UML 모델로표현하기위해서컴포넌트는하나의 UML Class 로대응하고, 컴포넌트의포트부분은 Class 의 Port 로대응한다. 반원형포트는 use 포트를, 원형포트는 provide 포트를의미한다. 포트의인터페이스는포트아래에표시한다. 변수는 Class 내부에표기되며 private 와 public 을구분해서표기한다. 컴포넌트의행위모델은의 UML state diagram 와같이표현된다. 행위모델은초기상태에서부터출발하며 / 를기준으로앞쪽에서는선행조건이, 뒤쪽에서는전이가되면서취하는행위가표기된다. 상태전이의표기방법은 로트리거이벤트에서포트와이벤트의구분을 _ 기호로표현하고수행조건이트리거이벤트앞에위치하는세부적인내용이외에는 3.1 장의표기방법을그대로따른다. UML state diagram 에서의기본적인표기법을따르나 multiple region, sub state 등은현재지원하지않는다. 6.4. 컴포넌트사이의연결관계및구현관계 14
컴포넌트사이에서시그널전송, 함수호출등의서비스요청및응대는포트를통해이루어지며, 포트의인터페이스에정의되어있는이벤트로만소통할수있다. 또한동일한인터페이스를가진포트들만을연결할수있다. 포트의종류는요청을받고결과를외부로제공되는 provide 와요청을보내고결과를제공받는 use 로나누어지며, 컴포넌트사이에서포트간의연결관계는 <connected> 와 <bind> 로표현된다. <connected> 연결관계는컴포넌트모델 M2 의인터페이스를제공하는컴포넌트모델 M1 에서 M1 에인터페이스를사용하는컴포넌트모델 M2 로의방향성그래프이다. <connected> 연결관계집합 Cr 은 Cr M1 X M2 와같이표현한다. <connected> 연결관계는 provide 포트에서 use 포트로방향성을가지고연결되며, provide 포트에서 use 포트로인터페이스에정의된이벤트를제공함을의미한다. 요청 / 응대한다. <connected> 연결관계는 one to one 연결만을지원한다. <bind> 연결관계는인터페이스가같은컴포넌트모델 M1 과 M2 사이의방향성그래프이다. <connected> 연결관계집합 Br 은 Br M1 X M2 와같이표현한다. <bind> 연결관계는 provide 포트에서 provide 포트로방향성을가지고연결되며, 연결의방향기준에서목표 (target) 컴포넌트쪽에서비스요청이들어왔을때, 해당서비스요청을실제로는근원 (source) 컴포넌트쪽에서응대함을의미한다. <realization> 연결관계는구현대상인컴포넌트모델 M1 과구현에필요한컴포넌트모델 M2 간의방향성그래프이다. 구체화관계집합 Rr 은 Rr M1 X M2 와같이표현한다. 컴포넌트간의 <realization> 관계는근원컴포넌트의구현을위해서목표컴포넌트가필요하다는것을나타내는표기방법이다. 예를들어 TargetCompA 는 porta 에서받은서비스의요청을모두 <bind> 연결관계에있는 TargetCompC 로다시요청하며, 15
TargetCompA 자체의행위모델은정의되어있지않다. 따라서 TargetCompA 를실질적으로구현하기위해서는 TargetCompC 가반드시필요하며이러한필요성을 <realization> 으로표기한다. <realization> 관계는추후에본연구에서컴포넌트구조를분석하고조합대상컴포넌트를선별하는과정에활용되며, cyclic 한의존관계를가지지않는다. 컴포넌트의상태 (state) 는진입상태전이 (incoming transition) 들의멱집합과퇴출상태전이 (outgoing transition) 의멱집합의조합으로상태는진입상태전이들과퇴출상태전이들을기억한다. 변수 (variable) 는이름과변수타입 VT = {public, 10private} 의조합으로변수의종류는외부에공개되는 public 과공개되지않는내부변수 private 로나누어진다. 이벤트 (event) 는시그널혹은함수호출등의종류가있으며, 인터페이스 (interface) 는이벤트의멱집합의조합으로표현된다. 포트는근원컴포넌트이름, 포트이름과인터페이스, 포트타입 PT = {provide, use} 의조합으로포트의종류는요청을받고결과를외부로제공되는 provide 와요청을보내고결과를제공받는 use 로나누어진다. 상태전이 (Transition) 은근원상태, 수행조건, 이벤트를수신하는포트, 수신대상이벤트, 행위식들의집합, 도달상태로표시되며표현양식은아래와같다. 상태전이는수행조건을만족하며, 인터페이스와이벤트로표현되는트리거이벤트 (Trigger Event) 가발생할때수행되며, 상태가전이되는시점에서함수호출, 시그널전송, 변수값전송등의행위를수행한다. 7. Use Case Diagram 7.1. Use Case 와 Actor 그리고이들간의관계표현 System 주요기능들과이들과관계하는관련당사자들에대한내용을한눈에알아볼수있도록전체적인 View 를제공 7.2. 구성요소 Actor Use Case Actor 와 Use Case 의관계 7.2.1. Actor Use Case 와상호작용을하는, System 사용 (System 에어떤 Action 을취한다 ) 의주체적인존재 사람, 사물, 시스템 Actor 명은역할로표현 Actor 구분 Primary Actor Use Case 기동 Actor 관계의화살표방향이 Actor 로부터 Use Case 를향하고있는모습 16
Supporting Actor 주로외부연동하는 System System 에대한설계진행시점에주로식별 특정 System 의제어권외부에존재하며특정 System 에요구사항부과 대상이되는 System 을사용하는사람이나외부 System 항목을나열후, 나열된 Actor 후보가하는역할을이해하기쉬운용어로표현 7.2.2. Use Case System, Sub System 에의해서제공되는상호연관성이높은기능성을표현 System 과 Actor 간에발생하는상호작용을일련의메시지로표현 ( 목적어 + 동사의명사형 ) 표현 Use Case 크기 Use Case 크기크고개수는적게 유지및관리대상이적으므로편의성증대 각 Use Case 처리의복잡도증가 Diagram 이간단하여전체적인이해의수준이낮아짐 Use Case 크기작고개수는많게 Use Case 처리 Logic 이단순하고명쾌 유지및관리대상의증가로인해유지 / 관리부담증가 7.2.3. Actor 와 Use Case 의관계 모든 Use Case 는 Actor 로시작 관계의종류 Actor Use Case 양방향단방향 Actor Actor 일반화 Use Case Use Case 일반화 포함 <<include>> 확장 <<exclude>> Actor Use Case: Association, Communicates Association Actor Actor: Generalization( 상속 ) 7.2.4. Use Case 와 Use Case 관계 Include: 최소한 2 개이상의 Use Case 들이동일한흐름을가진하나의업무기능을공유할때 Exclude: 화살표의방향은포함관계의방향과반대, 확장 Use Case 는 17
기본 Use Case 에서특정조건이나 Actor 의선택에따라기동 7.3. Use Case Specification 7.3.1. Actor 와 Use Case 간의상호작용에대한기술문서 Diagram 에표현되어있는 Actor 와 Use Case 가어떤상호작용을하는지, 어떤요청과응답을주고받는지, 즉 Event 에대한기술문서. 7.3.2. 구성요소 Use Case 이름 Use Case 간략한설명 Event 흐름 ( 기본흐름, 대체흐름 ) 특별한요구사항 사전 / 사후조건 확장점 7.3.3. Use Case 이름 Actor 의관점에서의미있는이름 7.3.4. Use Case 간략한설명 Use Case 의역할과목적 7.3.5. Event 흐름 ( 기본흐름, 대체흐름 ) System 흐름에대한윤곽 : System 이무엇을해야하는가. 개발자, 사용자, 고객, 실무자등이이해할수있는용어 기본흐름 대체흐름 정상적이고일반적인흐름 기본흐름을진행하는동안발생하는여러가지비정상적이거나선택적인행위를설명 7.3.6. 특별한요구사항 Event 흐름에표현되지않은비기능요구사항 제약사항이될수있는특정 Use Case 에해당되는내용기술 하나혹은여러 Use Case 에적용가능 7.3.7. 사전조건 Use Case 시작전에 System 이가지고있어야할상태 기본흐름으로부터대체흐름을식별한후확장하는시점에사전조건과의중복여부판단 7.3.8. 사후조건 Use Case 가종료된후 System 의제약사항기술 성공 / 실패의경우모두고려 7.3.9. 확장점특정조건을만나면특정 Use Case 로확장되는지점 7.3.10. System 관련그룹 개발자 System 분석, 설계, 구현 18
Tester 교육담당자 지원담당 System 의도목적달성여부검증 사용자들에게 System 사용방법설명 System 가동에대한책임및유지보수 7.4. Use Case Diagram Use case 는사용자관점에서의시스템수행기능이다. Use case diagram 을그릴때, 시스템내의어떤특정기능이 Use case 인지아닌지의기준은사용자와시스템간의시스템수행기능인지를확인하면된다. 예를들어, 어떠한웹사이트에서회원가입시입력정보를 DB 에저장하는기능과같은사용자의눈에보이지않는내부적인수행기능은사용자관점에서의시스템기능이아니기때문에 Use case 로그리지않는다. 관계는 Generalization, Include, Exclude 이렇게세가지면충분하다. 간혹 Use case diagram 을보면다양한관계를사용하는것을많이볼수있는데, 오히려혼란을초래할수있다. 일반적으로 Use case diagram 에서는 Generalization, Include, Exclude 이렇게세가지관계만사용한다. 관계를사용하는목적과의미에대해생각해보자. Use case diagram 에서의관계는사용자에게기능을좀더쉽게보여주고설계에대한방향을이끌어낸다는관점으로접근해야한다. 7.4.1. include Include 를사용하는목적은크게두가지이다. 하나는추상적이고복잡한하나의 Use case 를논리적인행동단위의작은 Use case 들로분리함으로써해당 Use case 를의미적으로좀더간소화한다는것이고, 다른하나는아래와같이두개이상의 Use case 들이가지고있는공통된행동을추출하여모듈화하는데에그목적을두고있다. 아래는그사용예를보여준다. 7.4.2. exclude 보조적이고선택적인하나의 Use case 가다른하나의 Use case 안에언제어떻게추가되는지를정의한다. 따라서 Extension Point 가중요하며, 그 Extension Point 에는확장하는 Use case 가언제, 어떻게선택적으로추가되는지에대한조건이정의되어야한다. 7.4.3. Generalization 클래스들사이의일반화와유사하다. 자식 Use case 는부모 Use case 의 property 들과 behavior 들을상속하고또한 behavior 들을 override 할수있다. 7.5. Use Case 의사례 7.5.1. ATM 현금출금이벤트흐름 << 기본흐름 >> 이 Use Case 는고객이 ATM 에서현금인출을하기위해행동하면서시작한다. 19
1. 고객이 ATM 에서현금인출을시작한다. 1.1. 고객이화면에서메뉴를선택하는경우 : A01 1.2. 고객이현금 / 신용카드를넣는경우 : A02 2. 고객인증처리 1 2.1. System 은 Card 에저장된개인정보 ( 은행번호, 계좌번호등 ) 를읽는다. 2.2. System 이카드판독이불가능한경우 : E01 2.3. System 은고객에게비밀번호입력을요구하고, 입력한비밀번호가맞는지확인한다. Input : 고객비밀번호 (6 자리 ) 2.4. 입력한비밀번호가다를경우 : A03 2.5. 입력한비밀번호가맞는경우 : A04 3. 현금인출메뉴제공 3.1. System 은고객이선택한현금인출메뉴를제공한다. 3.2. System 은인출금액입력을요구한다. 4. 고객은인출금액을입력한다. 5. 인출금액확인 5.1. System 은입력금액의범위를확인한다.( 최하 / 최대금액 ) 5.1.1. 입력금액범위를벗어난경우 : E02 5.2. System 은 ATM 에고객이요청한금액이있는지확인한다. 5.2.1. ATM 에요청금액이부족한경우 : E03 5.3. System 은고객의계좌에요청한금액인출여부를확인한다. 5.3.1. 은행접속이불가능한경우 : E04 5.3.2. 잔액이부족한경우 : E05 6. 현금인출 6.1. System 은거래내용을기록한다. Input: 거래일시, ATM 위치, 고객계좌번호, 거래유형, 거래금액, 거래번호등 6.2. System 은고객에게현금을지급한다. 6.3. System 은영수증과카드를고객에게제공한다. 7. 고객은현금, 카드, 영수증을확인한다. 8. Use Case 를종료한다. 8. Class Diagram 유사한구조를가지는구조체와구조체간의정적인연결을표현하는정적구조체도식이다. 또한인터페이스, 패키지, 연결, 인스턴스, 객체와링크까지도포함하기도한다. 정적구조체다이어그램의짧은표현으로보는것이좋다. 8.1. 의미정적인상태의시스템구조체를시각적으로표현하는모델이다. 각클래스다이어그램은기반모델의분할을표현하지않는다. 8.2. 구성 20
정적으로선언되는원소들인클래스, 인터페이스, 그상호관계를서로와서로의내용물과연결되는그래프로표현한다. 기반모델이나여러기반모델의패키지들로이루어지는각패키지형태로구성한다. 8.3. 연결구성요소는하나이상의요소와결합할수있다. 한패키지는하나이상의클래스다이어그램으로도표시될수있다. 여러다이어그램으로나누는것은표현상의효율을위한것이지모델자체가나누어져있음을의미하지않는다. 다이어그램의내용물들은정적의미모델의각요소로연결된다. 어떤다이어그램이패키지의일부분이면, 그내용물은해당패키지의내부로연결된다. 8.4. Object diagram 과의차이 Class diagram 이객체 (Object) 를포함할수는있지만 Object diagram 은클래스 (Class) 를포함하지않는다. 이두가지용어를구분하면사용용도가구별되므로편리하다. 8.5. Classifier 클래스, 자료형, 인터페이스의상위모델이다. 이세가지는서로비슷한구문으로표현되므로모두직사각형으로표시하고필요한경우형명을표시한다. 일반적으로다이어그램에서가장많은것이클래스이므로아무형명이없는직사각형으로표시하고나머지자료형과인터페이스는앞에형명을표시하는방법을주로사용한다. 아래클래스에관한내용은자료형과인터페이스에도일정부분적용가능한내용이다. 8.6. Class 8.6.1. 의미설계하는시스템을구성하는개념을표현한다. 자료구조를가지고다른요소에특정동작이나연관을갖는다. 패키지내부의한정범위에서만선언되며그이름은다른클래스이름과달라야한다. 8.6.2. 표현형 구분 표현 클래스 21
속성이있는클래스 속성값이있는클래스 8.6.3. 용법외곽선을실선으로그리며, 내부에세개로나뉜공간을갖는다. 맨위의이름부분에는클래스이름과 { } 내부에일반속성을기입한다. 가운데는속성, 아래는작동이들어간다. 패키지내부의클래스는 패키지명 :: 클래스명 형태로기입한다. 패키지내부의패키지인경우 패키지명 :: 패키지명 ::...:: 클래스명 형태로절대적형태를표현할수있다. 8.7. 사용예 8.7.1. 클래스사용예 22
8.7.2. 학교 (v2.0) 8.7.3. Erubis J 23
9. Deployment Diagram 시스템의노드와컴포넌트및그관계를묘사하는정적구조체도식이다. 즉, 시스템의하드웨어와소프트웨어, 원격의다른시스템과연결시켜주는미들웨어를보여준다. 따라서여러장치에서작동하는어플리케이션을표현하기에좋다. 9.1. 구성요소 (v2.1 기준 ) artifact, node, deployment 의세가지노드와연결선을이용하여작성한다. 9.1.1. graphical node : 노드 a. artifact 개발의과정을통해서나온결과물을총칭한다. 시스템의개발, 배포, 운영에필요한정보의물리적인부분을명세한다. type artifact 속성이있는 artifact 24
artifact b. node artifact 가실행되는장치또는실행환경을의미한다. 각 node 간의연결선은통신연결을의미한다. type node artifact 가탑재된 node node c. deployment artifact 를특정 node 에서작동하기위한모든활동을의미한다. 소프트웨어 artifact 가어떻게장치및실행환경과설치또는할당되어있는지를나타낸다. type deployment 속성이있는 deployment 속성의값이있는 deployment deployment 9.1.2. graphical path : 연결선 type 연관의존일반화 path type deploy 선언 path 9.2. 용법 node 는입체정육면체로나타내고, 윗부분에이름을표시한다. 노드이름에는밑줄을 25
그으며, 이름 : 노드타입명 형태로나타낸다. artifact 에는 << 타입명 >> 을이용해어떤형태에기반하는지를표현할수있다. node 간, 혹은 artifact 간에 <<become>> 이붙는의존관계가있을수있는데, 이는전체수행시간중적은시간동안만해당 node 혹은 artifact 에상주한다는것을의미한다. 9.3. 사용예 9.3.1. 온라인비디오대여서비스 9.3.2. 종합대학정보시스템 (v2.1) 26
9.3.3. 위종합대학정보시스템의보다간결한실용적표현 27
10. Sequence Diagram 가장일반적인형태의상호작용을나타내기위한행위도식이다. 여러상호작용요소간의메시지교환을중점적으로묘사한다. 대부분은다이어그램의시간순서만이중요하지만, 실시간어플리케이션의경우는시간축이실제시간의절대값과같은단위이기도하다. 10.1. 구성요소다음과같은구성요소이며이는 Collaboration diagram 과같다. 10.1.1. 객체생명선 (Object Lifeline) 수직점선으로객체인스턴스의생명선을나타낸다. 이시간동안인스턴스가존재함을의미한다. 객체이름은생명선의최상단에표시한다. 인스턴스가실행중간에생성되면활성화화살표로생성주체와연결하고, 중간에소멸되면커다란 X 표시를소멸시키는주체인스턴스와의연결이나자멸의경우에는해당인스턴스로들어오는마지막화살표에한다. 상호작용이전부터존재하는인스턴스는생명선을최초상호작용화살표보다위에서다이어그램맨위까지닿도록그리고, 마지막상호작용이후에도남아있는인스턴스는최후상호작용화살표이후로부터다이어그램맨아래까지그린다. 28
Diagram 1 Diagram 2 왼쪽의다이어그램이오른쪽다이어그램으로연결된다. 구분표현설명 통신 절차실행, 제어 비동기통신 하위절차가모두완료되어야외부과정이계속된다. 제어는다른객체의인스턴스에신호를보내고그모든하위절차의종료를대기한다. 절차제어가없다. 바로다음으로넘어간다. 10.2. 용법수직방향은시간의흐름을의미하고수평방향은각각의인스턴스를의미한다. 일반적으로는페이지의아래방향이시간의흐름과같은방향이다. 평행축은순서가관계없다. 모든실행화살표가한방향으로정렬되기도하지만, 이는항상가능하지는않고정렬된순서가의미를가지지는않는다. 시간수치나활성화되는활동의설명이변화나활성화화살표에표지로붙기도한다. 일반적으로는페이지의아래방향이시간의흐름과같은방향이고오른쪽방향이서로다른객체이지만, 거꾸로배치하기도한다. 대부분은다이어그램의시간순서만이중요하지만, 실시간어플리케이션의경우는시간축이실제시간의절대값과같은단위이기도하다. 평행축은순서가관계없다. 29
모든실행화살표가한방향으로정렬되기도하지만, 이는항상가능하지는않고정렬된순서가의미를가지지는않는다. 시간값이나활성화되는활동의설명이변화나활성화화살표에표지로붙기도한다. 시간값은시간단위로표현될수도이고, 활성화화살표의이름으로붙기도한다. 활성화화살표이름에 sendtime, recceivetime 함수를적용하여실제시간을구해야하는경우도있다. 시간함수는사용자가상황에맞게 elapsedtime, executionstarttime, queuedtime, handledtime 등으로수정하여사용할수있도록열려있다. 설계도에있는생성표시는연결이활성화되는시간간격을표현한다. 이표현방법은시각적으로효과적이지만, 화살표가평행인경우보내는시간과받는시간이구분되지않을수있다. 이럴경우대부분은전송시간이서로같은경우가많기때문에괜찮기도하지만, 소프트웨어툴에서는이렇게혼동되지않도록메시지와활성화이름을표시해야한다. 툴은시간함수이름을따로관리하여활성화이름과연동되도록하여 "b.receivetime a.sendtime < 1 sec" 와같은표현의이용이가능해야할것이다. 물론이런표현은의미모델과도연동되어야할것이다. 10.3. 사용예 10.3.1. 병렬실행형객체 ( 굵은사각형 ) 의간단한 Sequence diagram 10.3.2. 제어, 조건, 재귀, 생성, 소멸에대한 Sequence diagram 30
31