UML 두 번째: Sequence Diagram

개요

UML의 여러 Diagram들 중 이전에 살펴본, Class Diagram은 정적인 모델을 보여 주는 Structure Diagram의 일종이다. 즉, Snapshot이나 건물의 설계도와 같은 스틸 사진과 같은 모습을 보여 준다. 즉, 동작 보다는 전체적으로 어떤 Class들이 있고, 어떻게 연관되어 있는지를 보여 준다. 반면, 어떻게 동작하는지는 파악하기 어렵다. 이를 담당하는 것을 Behavior Diagram이라고 한다. 이 중에서 System Model들의 상호 연동(Interaction)을 보여 주는 Diagram이 Interaction Diagram이다. [1]

그런데, 왜 Structure Model만으로는 충분하지 못하고 Behavior Diagram을 사용해야 할까? 이는 시스템이 필요로 하는 요구 사항 중 기능을 어떻게 수행하는지 보이기 위해서이다. 반대로, Behavior Diagram으로만 시스템을 보여 주면 안될까? 이 또한 몇가지 동작 만으로 시스템을 보여 주기 어렵기 때문에 정적 모델로 전체 모습을 보여 주기도 해야 한다. 

Behavior Diagram 중에서 시스템의 Model의 상호 연동에 대해서 설명하는 Diagram에는 Sequence Diagram, Timing Diagram, Communication Diagram, Interaction Overview Diagram이 있다. 여기서 무엇 보다도 Sequence Diagram이 가장 일반적으로 많이 쓰인다. 

기본 개념

Sequence Diagram은 Class의 Instance들이 어떻게 연동하여 원하는 기능을 수행하는지 보여 준다. 그렇기 때문에 Diagram별 수행하는 기능이 정해 져 있다. 보통은 Use Case나 Scenario가 그에 해당한다. Class의 Instance에 해당하는 것이 Lifeline이고 연동하는 방식이 Message이다. 여기서는 이 두 가지를 살펴 본다.

Lifeline은 아래와 같이 Box에 수직 점선으로 되어 있다. 아래 그림과 같이 여러 종류가 있다.[2] 특히 (a)는 Role로 Class의 Instance로 표시할 수 있다. (b)는 Professor Class의 이름을 붙이지 않은 Anonymous instance로 보면 된다. (c)는 이 둘을 합친 모습으로 보면 된다. 

Message는 화살표가 끝나는 쪽의 Method에 해당한다. 3가지 혹은 5가지 종류가 있다고 한다.[2][3] 3가지 종류에는 Synchronous Message와 Asynchronous Message가 있다. 그리고, 이에 대한 응답에 해당하는 Return Message혹은 Response Message가 있다. Synchronous는 Message 호출 후, 결과가 처리되고 바로 Return되는 형식이다. Asynchronous의 경우는 우선 Message의 수신은 끝나고 처리 결과가 이후에 전달되는 경우이다. 5가지로 분류 될 때에는 Lifeline을 생성(Create)하거나 종료(Terminate)하는 경우의 Message를 포함한다.

이야기 한데로, Message는 Method에 대응되기 때문에 화살표 쓰는 Syntax는 다음과 같다. [2] 결국 Name이 Message의 이름이고 Parameter는 처리를 위해서 전달되는 인자들이다. 처리가 완료 된 후에 돌아오는 반환값의 종류는 Return Value가 되고 이를 저장하는 변수(Variable)이 앞에 위치하게 된다.

몇가지 예를 들어 보자.

initialize(code)

initialize

d = getProductDescription(id)

d = getProductDescription(di:ItemID)

d = getProductDescription(id:ItemID) : ProductDescription

Message의 처리 순서

Sequence Chart의 기본적인 처리 순서에 대한 개념을 설명한다. 3가지 규칙이 있다. [2] 첫 번째로 (a)에서 설명하는 것과 같이 같은 Lifeline에서 발생하는 것은 순서가 위에서 아래로 결정된다. 즉, a가 먼저 수행되고 c가 수행된다. (b)와 같이 다른 lifeline인 경우는, a, b 순서와 b, a의 순서가 모두 가능하다. (c)와 같은 경우는 복합적이다. 하지만, 다른 쪽에서 들어온 경우는, 같은 Lifeline에서는 순서가 정해진다. 즉, (a)의 규칙까지 적용하여 a, b, c의 순서만 가능한 것이다. 

Combined Fragments: Branch와 Loop

Combined Fragments는 Sequence Chart에 Frame을 표시하고 연산자를 적용하여 다양한 Control을 표시할 수 있게 해준다. Frame들은 내부에 다른 Frame을 포함할 수 있다. 이를 Nested 가능하다고 한다. 아래 그림은 Combined Fragment의 일반적인 구조를 보여 준다.

Operator에는 아래와 같은 종류가 있다[2]. 여기서는 Branches and loops에 대해서 살펴 본다.

Combined Fragments의 Branches와 Loop관련 항목은 아래와 같다. alt는 우리가 알고 있는switch와 유사하다. [...]가 guard condition으로 이 조건이 만족하면 해당하는Operand 부분이 수행된다. alt는 여러 옵션들이 있으므로 해당 guard condition에 따라서 수행되는 부분이 다르다. opt는 if문과 같다. 

loop의 경우는 operator에 반복 횟수를 (min, max) 혹은 (min..max)의 syntax로 적는다. guard condition에 loop를 돌아야 하는 조건을 기술한다. break문은 guard condition이 참인 경우 해당 내용을 수행하고 현재 위치한 Fragment를 빠져 나간다. 

Combined Fragment는 책에 있는 예제를 많이 살펴 봐야 이해도를 높일 수 있으니 많이 봐야 한다. 또한, 필요한 경우에 작성하는 것도 도움이 많이 된다.

Combined Fragments: Concurrency와 처리 순서

seq fragment의 경우는 일반적인 처리를 지칭한다. 이는 strict fragment와 대비되는 것으로 보면된다. strict의 경우는 그려진 순서를 무조건 따른다. 즉, 기본적인 message의 순서(order)를 따르지 않고 그려진데로만 수핸된다고보면 된다. par fragment의 경우는 operand들이 나뉘어 진데로 병렬 수행한다고 보면 된다. critical은 다른 message들이 중간에 끼어 드리 않고 atomic하게 수행된다고 보면 된다.

돌아보며... : Sequence Diagram의 활용

재미있는 것 중에 하나는 Open Source들의 경우 Class Diagram은 쉽게 찾을 수 있지만, Sequence Diagram은 찾기가 쉽지 않다. 왜 일까? 내 개인적인 생각은 Code가 있기 때문이다. 반대로 이야기 하면, 잘 그려진 Sequence Diagram이 있으면 Code까지 만들어 내는 도구가 있다.

Code는 Pseudo Code가 아니면 말할려고 하는 부분을 추상화 (Abstraction)하여 설명하기가 쉽지 않다.  즉, 설명하고 싶은 것만 넣고, 빼고 싶은 것만 빼기는 쉽지 않다. 즉, Sequence Diagram은 내가 넣고 싶은 것만 넣고 보여 줄 수 있다. 그렇기 때문에 다음 용도로도 사용할 수 있다.

1. 커뮤니케이션 도구이다.

다시 말하자면, 코드를 전체적으로 주거나 정리해서 주지 않고, 설명할 수 있는 좋은 방법이다. 동작에 대해서 명확하게 소통하기 위해서는 이를 사용하는 것이 좋다.

2. 설계 도구이다.

요구 사항 특히 동작 요구 사항을 분석하고 설계하는데, Sequence Diagram을 많이 사용한다.

Sequence Chart는 꼭 UML 도구로만 그리는 것이 이니다. Java의 IDE의 도구들을 추가 설치하면 함수를 분석하여 Sequence Chart를 그려 주는 도구도 많다.

References

[1] Unified Modeling Language, https://en.wikipedia.org/wiki/Unified_Modeling_Language#Interaction_diagrams

[2] Martina Seidl, Marion Scholz, Christian Huemer, Gerti Kappel, "UML@Classroom An Introduction to Object-Oriented Modeling," 2015 Springer

[3] Russ Miles, Kim Hamilton, "Learning UML 2.0," 2006, O'reailly