[UML] Sequence Diagram 에 대해 알아보자

개발할 것도 많은데.. 그려야 할 UML 들이 참 많은 것 같다. 하지만 그만큼 중요한 영역이니, SW 설계의 UML 중 가장 중요한 Diagram 중 하나인 Sequence Diagram 에 대해 더 알아보자.

 

 

불타버려라

 

 

Interaction Diagram 에는 4가지 종류가 있는데, Sequence Diagram, Timing Diagram, Communication Diagram, Interaction Overview Diagram 이 있다. 사용하고자 하는 Interaction Diagram 은 Functional Requirement(Use Case) 별로 하나씩 그리게 된다.

 

 

(Class Diagram 이 관계에 집중했다면, Interaction Diagram 은 Class 간 Communication 에 집중한다) 

 

 

 

Sequence Diagram vs Communication Diagram 

 

 

우선 Sequence 에 대해 자세히 들어가기 전에, Interaction Diagram 중 또 다른 하나인 Communication Diagram 과의 차이를 살펴보자. 둘은 굉장히 유사하면서도 표현 방식에서만 차이를 두고 있다고 생각하면 된다. 둘은 표현하고자 하는 것은 동일하기 때문에 동일한 Expressive Power 를 가지고 있지만, Diagram 자체의 복잡성 / 직관성에서 차이를 두고 있다. 다음과 같은 상황이 있다고 생각해보자. 

 

 

public class A {

    private B b;
    
    // ...
    
    public void doOne(){
        
        b.doTwo();
        b.doThree();
    }
    
    // ...
}

 

 

1) Sequence Diagram

 

 

sequence diagram

 

 

Sequence Diagram 은 위와 같이 맨 위에 논리적인 Role 을 중심으로 (Object : Class 긴 하지만, 같은 Object 여도 Use Case 에 따라 Role 이 다를 수도 있다) 행위의 대상들을 나열한 후, 객체들이 주고 받는 communication 을 순서 중심으로 나열한다. 만약 한 Use Case 에 참여하는 객체들이 많다면 그만큼 Sequence Diagram 은 커지게 된다.

 

 

참고로, doOne() 처럼 현재 경계구역 밖에서 들어와서 이 Use Case 를 Trigger 하는 동작을 System Operation (External Operation) 이라고 한다. 

 

 

2) Communication Digarm

 

 

communication diagram

 

 

Communication Diagram 은 Sequence Diagram 과 유사한 방식으로 동작하지만, 한 Diagram 안에서 번호를 나열함으로써 동작 순서를 나열한다. 따라서 참여 Object 들이 많아지거나 communication 이 많아져도 Seq Diagram 만큼 커지진 않는다. 다만, 직관성은 Seq Diagram 이 훨씬 좋아서 더 중요하게 여겨진다. 이 정도로만 알면 되고, 이제 Sequence Diagram 에 대해 집중적으로 알아보자. 

 

 

 

Sequence Diagram 

 

 

1) Lifeline Box (Role Box) 

 

 

위에서 말했던 Role 중심의 객체이다. 해당 Use Case 에 대한 참여 객체들 (Object) 을 중심으로 나열하게 된다. 참고로 상황에 맞춰서 Lifeline Box 안에 명시하게 되는데, 다음과 같다.

 

 

Lifeline Box 내 명시

 

 

1 - 아직 뭔가를 구체적으로 지칭하는게 어렵다

2- object :Class 형태로, 가장 기본적인 형태이다

3 - MetaClass 로, abstract class 처럼 구현된 instance 가 없는 Role 의 경우이다

4 - 여러개의 Object 일 경우 Collection 형태로 넣어준다

5 - 4번 내에서 특정 Object 를 index 를 통해 지칭하는 경우이다

6 - interface 를 넣는 경우이다

 

 

2) Message 들이 진행되는 순서

 

 

message 들의 순서

 

 

1 - 한 Line 에서는 무조건 위에서 아래로 순서가 내려오며, 화살표가 가르키는 객체가 그 동작을 수행한다

2- 서로 다른 Line 들이 연결되어 있지 않다면, a 와 c 는 random 한 순서로 수행된다 (그린 사람의 의도와 무관) 

3- 서로 다른 Line 들이 서로 연결되어 있다면, 1번과 동일하게 위에서 아래로 순서가 내려오며 진행한다

 

 

Message 들이 진행되는 순서는 다소 헷갈릴 수 있다. 참여하는 Role Object 들이 많아질 수록 서로 떨어진 Object 들끼리 순서를 고려해야 하는지, 아니면 안해도 되는지 판단하는 것이 개발시 중요하다. 다음과 같은 예제를 살펴보자. 

 

 

 

 

위 Sequence Diagram 에서는, 크게 (A <-> B), (C <-> D) 의 관계가 있는 것을 알 수 있다. 이 때, a, b, c, d 는 두 시스템 상에서 서로 Communication 을 하는 관계가 아니므로, c --> d 순서만 지켜진다면 어떤 순서로 진행되든 상관이 없다. 

 

 

a -> b -> c -> d , b -> a -> c -> d, c -> d -> b -> a, ... 모두 가능한 case 이다

 

 

하지만 e 가 들어온 이후로는 상황이 바뀐다. e 를 중심으로 두 시스템은 Communication 을 한 이후가 되므로, e 이전과 이후는 명확하게 구분될 필요가 있는 것이다 (e 를 통해 생성된 variable 을 사용해야 할 수도 있기 때문). 즉, 위에 나열된 case 마지막에 [-> e] 가 되도록 지켜진다면, 모두 가능한 case 이다. 

 

 

c -> d -> e -> a -> b 같은 case 는 불가능한 case 이다. e 가 호출된 이후로부터는 위로 올라갈 수 없다. 

 

 

3) Message 종류와 형태

 

 

3-1) Synchronous Message

 

 

Synchronous Message 의 표기

 

 

Message 를 호출하여 보낸 객체가 Message 를 수행하는 객체로부터의 응답을 기다린 이후에 진행한다(동기 방식). 계속 언급했듯이 화살표가 가르키는 객체가 해당 행동을 수행한다. 타 Thread 를 생성하여 만드는 SW 를 제외하고는 SW 는 모두 Synchronous Message 이다. 

 

 

3-2) Asynchronous Message

 

 

Asynchronous Message 의 표기

 

 

비동기 방식으로, 3-1 과 다르게 Message 호출 객체는 응답을 기다리지 않고 후속을 진행한다 (타 쓰레드를 만들어서 요청을 진행하는 행위). Thread 를 통해 만들어진 요청은 Context Switching 으로 때문에 언제 응답이 올지 모르기 때문에 후속을 진행하게 되는 것이다. 

 

 

3-3) Response Message

 

 

Response Message 의 표기

 

 

 

호출에 대한 응답이 표기된다. 만약 굳이 필요될 필요가 없다고 판단된다면 복잡성을 줄이기 위해 생략되기도 한다.

 

 

3-4) Message 의 형태

 

 

return = message (parameter : parameterType) : returnType

 

해당 형태 중 명시가 반드시 필요한 부분들을 취해서 Message Syntax 에 넣어주게 된다. 예를 들어, d1 = getDate 만 적혀있다면 d1 은 이 행위의 결과로 만들어지며, getDate 함수가 수행됨을 알 수 있다. 단, 3-3 과 같은 Response Message 를 명시한다면, 굳이 d1 을 요청 Message 에 적지 않고 Response Message 에 적는걸 권장한다. 

 

 

4) Instance Creation

 

 

새로운 Instance 생성을 표현해줄 수 있다

 

 

Sequence Diagram 이 진행되는 도중 새로운 Role (Object) 가 생성되어 참여하는 과정을 그려줄 수 있다. Creation 에 대한 규칙은 다음과 같다

 

 

1 - 점선으로 create(Params ..) 를 명시한다

2 - Create 을 수행하는 객체가 위에 있고 생성되는 객체가 아래 있어야 한다

3 - 반대로 Destruction 같은 경우는 잘 표현해 줄 일은 없으나, close 되거나 처리되어야 한다면 행위 line 끝에 X 를 표시하고 destroy 를 반환하도록 UML 을 작성한다

 

 

지금까지는 Sequence Diagram 의 기본적인 Notation 들을 확인할 수 있었다. 하지만 Use Case 에는 정상 동작 Case 만 정의되어 있는 것이 아니라, 훨씬 많은 Alternative, Exceptional Case 들이 정의되어 있는 것을 기억할 것이다. 이 모든 것들을 명시해주기 위해 하나씩 그려야 한다면 엄청나게 많은 Sequence Diagram 을 그려야 한다. 이를 압축시켜서 그릴 수 있도록 사용하는 장치가 바로 Combined Framgent & Operator 이다. 

 

 

 

Combined Framgents and Operators

 

 

Sequence Diagram UML 에서 보통 사용하는 대표적인 4가지 Operator, [Alt, Opt, Loop, Break] 의 Fragment Operator 에 대해서 살펴보자. 

 

 

1) Alternative Fragment (switch) 

 

 

Fragment 가 추가된 Sequnce Diagram

 

 

위 Sequence Diagram 은 Alternative Fragment 를 중심으로 3가지 Case 에 대한 분기를 진행하고 있음을 알 수 있다. 즉, 응답 받은 status 를 중심으로 OK, FREE, ERROR 일 경우에 대한 처리를 모두 정의해준다. 

 

 

2) Optional Framgent (if) 

 

 

if 문과 똑같이, 해당 상황에서 있을 수 있는 상황을 branch 로 빼서 추가적인 Sequence 를 진행하게 된다. 이 때, else 처리는 없으며, 다른 방식으로의 처리를 위해서 1) 을 같이 사용해줘야 할 수도 있다. 

 

 

3) Loop Framgent (for / while) 

 

 

loop fragment 가 추가되는 방식

 

 

동일한 Sequence 가 반복적으로 수행되어야 할 때 사용한다 (가령, unique 한 별명을 만드는 시도를 5번 진행한다). Loop Fragment 를 명시할 때는 [loop(a, b)] 과 같은 조건을 추가해주는데, 이는 looping 의 최소 최대 범위를 지정하는 것이며, Fragment 내부에 Guarding Condition 을 명세하여 탈출 조건을 따로 적어준다. 예시를 들면 다음과 같다. 

 

 

loop(3,8) > 최소 3번, 그리고 최대 8번까지 돌 수 있음 (4번부터는 Guarding Condition 을 확인하며 돈다)

loop(8,8) > 8 번 돌게 된다 

loop = loop(*) = loop(0,*) > 탈출을 Guarding Condition 에만 맡긴다 (없으면 안된다)

 

 

4) Break Fragment

 

 

일반적인 break 와 똑같다. break fragment 가 아닌 다른 둘러싸고 있는 fragment 가 필수적으로 필요하며, 제시한 Guarding Condition 을 만족한다면 break 가 아닌 더 큰 fragment 를 탈출하게 된다. 아니면 이하를 그대로 수행한다. Loop 와 Break Fragment 를 활용한 예제를 살펴보자.

 

 

Fragment 들이 적용된 예시이다

 

 

위 Sequence Diagram 은 check(name, pw) 의 결과가 incorrect 할 시 3 번까지 재시도 할 것임을 요구한다. 3 번 수행한 이후에도 여전히 incorrect 할 시 error message 를 내보내도록 설계가 되었다. 하지만 위 상황과 같이 break 문을 감싸고 있는 Fragment 가 없는데 break fragment 가 사용된 경우는 전체 시나리오를 종료한다는 설계이다.

 

 

5) Interaction Reference 

 

 

Interaction reference 의 예시

 

 

Interaction Reference 란 이미 적용된 다이어그램을 그대로 사용한다는 뜻이다. 이미 다른 곳에 Sequence Diagram 이 생성되어 있다면, 해당 Diagram 을 그대로 수행할 수 있도록 Ref 라는 표기와 함께 명시해주게 된다. 중복되는 사용을 줄일 수 있도록 설계측에서도 돕는 것이라 보면 되고, 종종 유용하게 사용된다고 한다. 

 

 

 

정리하며

 

 

1인 개발이나 프로젝트성 개발을 많이 해본 사람들은 일반적으로 Diagram 까지는 잘 그려가지 않는다. 코딩 외에 하는 일은 전체 일의 양을 증가시킨다고 생각하는 경향이 있기 때문이다. 하지만 SW 는 내가 지금까지 느꼈을 때 그냥 코딩을 한다고 전체 속도가 빨라지는게 절대 아니다. 여러 상황을 생각해 놓지 않은채 개발하기 때문에 결국 고쳐야 하는 시간이 오래걸리기 때문이다. 

 

 

이렇게 Use Case Diagram, Sequence Diagram, Class Diagram 순서대로의 설계는 조금 필수적으로 함께 만들어 나간다고 생각하는게 좋을 것 같다. 개발도 문서가 필요하고, 이 순서를 거치면서 Diagram 들을 수정해 나가는게 훨씬 낫기 때문이다. 나도 많이 안했는데, 앞으로 진행하는 프로젝트들은 꼭 해보도록 해보자. 

 

 

 

 

* 출처) 

 

 

건국대학교 유준범 교수님 OOP / UML / OOAD 수업