[UML] 시퀀스 다이어그램(Sequence Diagram) 기초 정복

1. 시퀀스 다이어그램(Sequence Diagram) 이란?

---

 시퀀스 다이어그램이란 객체 지향의 소프트웨어 표준 설계 방법인 'UML(통일 모델링 언어)'의 하나로, 프로그램의 처리의 개요나 흐름을 설계할 때 사용한다. 사양서가 없는 기존 시스템의 분석에 사용하는 경우도 있다. UML에서는 '상호작용 다이어그램'의 1개로 인식된다. 

 객체 지향의 소프투에어 설계에 있어서, 시퀀스 다이어그램을 작성하는 것은 글로벌 스탠드라고 해도 과언이 아닐 정도로 중요하다. 따라서 시퀀스 다이어그램의 기초를 익히도록 하자.

 

2. 시퀀스 다이어그램(Sequence Diagram) 의 기본 규칙

---

 시퀀스 다이어그램은 "라이프 라인(life line)"이나 "메시지"라고 불리는 구성요소와 "객체의 연결"이나 "처리 내용"을 표현하는 복합 프래그먼트를 이용해 작성된다.

 여기서는 구성요소와 복합 프래그먼트의 규칙(종류)에 대해서 설명하도록 하겠다. 시퀀스 다이어그램의 기본 규칙은 세계 공통이므로 확실히 알아두도록 하자.

 아래의 그림은 점원（店員）이 상품（商品）을 검색하고 상품의 상세 정보를 참고하는 시퀀스 다이어그램의 예이다.

1) 구성요소

구성요소는 라이프라인, 실행 사양, 중시, 메시지 크게 네 가지가 있다. 각가의 요소의 이미는 아래와 같다.

(1) 라이프 라인

 객체나 클래스를 표시할 때 사용한다. 박스 안에는 '객체 이름 : 클래스'라는 작성 규칙이 있다. 객체 이름이나 클래스 명 하나 밖에 없는 경우는 한쪽만 표시하는 것도 가능하다.

(2) 실행 사양

 라이프 라인에서 처리가 샐행되고 있는 것을 의미한다. 실행 사양은 '제어 포커스'라고 불리기도 한다. 라이프 라인 상에 배치된다.

(3) 정지

 라이프 라인의 소멸을 의미한다. 처리가 끝난 라이프 라인을 파기할 때에 사용한다.

(4) 동기 메시지

객체에 대해 처리명령(메시지의 기동명령)을 의미한다. '동기 메시지'는 이 메시지의 처리가 끝날 때까지 다음 메시지를 기동하지 않는 사양을 작성할 때 사용한다. 실행처의 라이프 라인은 이 메시지가 끝날 때 까지 대기한다. 메시지 명 뒤에는 괄호를 붙여 인수를 기재한다.

(5) 비동기 메시지

 객체에 대해 처리 명령(메시지의 기동명령)을 의미한다. '동기 메시지'와 다른점은 실행한 처리의 완료까지 대기하지 않고 다음 메시지를 기동한다는 것이다. 병렬 처리 등에 사용한다. 메시지 명 뒤에는 괄호를 붙여 인수를 기재한다.

(6) 응답 메시지

 실행한 처리의 리턴 값을 의미한다. 'reply 메시지'라고 불리기도 한다. 메시지명 뒤에 괄호를 붙여 인수를 기재한다.

 

2) 복합 프래그먼트

 복합 프래그먼트란 객체의 처리 내용을 표시하기 위한 것이다. 프로그램 코드내에 적혀있는 조건 분기문이나 병렬 처리, 루프 처리 등을 시각화하기 위해 사용한다.

 시퀀스 다이어그램상에 표현할 때는 기호(약명)을 이용해 기재한다. 기호는 대문자로 쓰일 때도 있고, 소문자로 쓰일 때도 있다. 대문자 작성이나 소문자 작성에 대한 별도의 특별한 의미는 없으므로 회사 규약에 따라 작성하면 되겠다.

명칭	기호	처리내용
Alternatives	alt	조건에 의한 분기 처리(if else)
Assertion	assert	절대 처리(정의된 로직이 반드시 성립되는 처리)
Parallel	par	병렬처리
Consider	consider	중심이 되는 중요한 처리
Option	opt	조건이 만족될 때만 실행되는 처리 (if)
Reference	ref	다른 시퀀스 다이어그램의 참고
Loop	loop	루프 처리
Break	break	조건이 만족되는 시점에 중단되는 처리
Negative	neg	부정 처리(보통 발생하지 않는 처리)
Critival Region	critical	인터럽트와 중단을 허용하지 않는 배타처리
Ignore	ignore	실행시에 무시하는 처리 이 시퀀스 다이어그램 중에서는 관계없다는 것을 명시적으로 표시할 때에 사용

 

3. 시퀀스 다이어그램 작성법

---

 이번 장에서는 시퀀스 다이어그램의 작성법을 이해할 수 있도록 케이스 별로 예를 살펴보자.

1) 조건 분기(Alternative)

 조건 분기를 표시할 때는 'alt' 복합 프래그먼트를 사용하여 표시한다. 분기의 조건은 [] (가드라고 불리는 괄호) 내에 기재하고 각 처리를 점선에 나눠서 작성한다.

 아래의 그림은 작은 점포에서 쿠폰 이용시 판매 금액의 계산 처리를 표시하는 예이다.   

2) 어서션(Assertion)

 어서션을 표시할 때는 'assert' 복합 프래그먼트를 사용하여 표시한다. 어서션 내용(성립할 수 밖에 없는 결과)는 {} 내에 기재한다. 

 아래의 그림은 작은 상점에서 재고의 갱신처리를 하는 예이다. 판매 확정시에 판매한 수량을 반드시 재고에 반영되어야 한다. 즉 '재고 수 = 재고수 - 판매수' 가 성립될 필요가 있다.

3) 병렬 처리 (Parallel)

 병렬처리는 'par' 복합 프래그먼트를 사용하여 표현한다. 병렬으로 실행된 처리는 점선으로 구분한다. 아래의 그림은 작은 상점에서 점포 재고의 갱신을 표시하는 예이다. 판매 확정시에 결제 트랜스와 재고 마이너스가 동시에 갱신되어야 한다.

4) 중요처리 (Consider)

 중요처리는 'Consider'이라는 복합 프래그먼트를 사용해 표현한다. '유효처리'라고 표시되는  경우도 있다. Consider{메시지 명1, 메시지 명2...}과 같이 작성된다.

 아래의 그림은 작은 가게에서 점포 재고의 갱신처리는 표시한 예이다. 판매확정시에 결제 트랜스와 재고 테이블을 반드시 갱신해야하는 처리를 표시하고 있다.

5) 조건 지정(Option)

 조건이 만족된 때만 살행되는 처리는 'opt'이라는 복합 프래그먼트를 사용하여 표시한다. 실행 조건은 [] (가드라고 불리는 괄호)내에 기재된다.

 아래의 그림은 면세점에서의 면세 대응을 표시한 예이다. 구매자가 외국인인 경우 점원은 POS 레지 상에 면제 버튼을 눌러 면세 시스템을 연결한다. POS 레지와 면세 시스템의 연동은 POS 레지에서 면제 버튼을 눌렀을 경우에만 적용된다.

 

6) 외부 참고(Reference)

 외부 참고는 'ref' 복합 프래그먼트를 사용하여 표현한다. ref로 감싼 부분을 처리하는 것은 다른 시컨스 다이어그램을 참고해주세요라는 의미가 된다.

 아래의 그램은 면세점의 면세대상을 표시한 예이다. POS레지와 면세 시스템의 연동 처리는 복잡하므로 다른 시퀀스 다이어 그램에서 상세히 표시하고 있다는 것을 알려주고 있다.

7) 루프 처리 (Loop)

 루프 처리(반복 처리)는 'loop'라는 복합 프래그먼트로 표현한다. 루프의 횟수는 [시작 조건, 종료 조건]이라는 형식으로 기재된다.

 아래의 그림은 작은 가게에서 레지 처리를 표시한 예이다. 상품 수가 1개 이상 있는 경우, 상품 수만 처리를 반복한다. 

8) 중단 처리(break)

 중단 처리는 'break'라는 복합 프래그먼트로 표시한다. 중단조건은 가드라는 [] 괄호 안에 기재한다. 

 아래의 그림은 출하 처리를 표시한 예이다. 출하하고자 한 상품의 재고가 없는 경우에 처리를 중단하고 메시지를 표시한다.

9) 부정처리 (negative)

 부정처리는 'neg'라는 복합 프래그먼트로 표현한다. 부정 처리(negative)는 보통 발생하지 않는 처리 (원래 실행되지 않는 처리)를 의미한다.

 아래의 그림은 판매 확정시의 결제 트랜스와 재고 마스크의 갱신 처리를 표시한 예이다. 재고 마스크는 '재고 수 = 재고 수 - 판매수'라는 로직으로 갱신되지만, 무언가 문제가 발생하여 정합성을 얻을 수 없어 갱신되지 않을 때에 정합성 에어 처리를 실시한다.

10) 베타처리(critical)

 베타처리는 'critical'이라는 복합 프래그먼트로 표현된다.

 아래의 그림은 출하 지시 등록시에의 재고 마스트와 출하시정 테이블의 갱신 처리이다. 데이터의 정합성을 담보하기 위해서 재고 마스크와 출하 지정 테이블의 갱신 대상 레코드에 베타 처리를 실행한다.

 

4. 시퀀스 다이어그램 작성시의 주의점

---

1) 반드시 시나리오를 명확히한 후에 작성하자.

 시퀀스 다이어그램을 작성하기 전에, use case 다이어그램이나 업무 흐름을 만들어 유저가 어떤 시나리오에서 시스템을 사용할지를 정리하자. 시나오리가 명확하지 않은 상황에서 시퀀스 다이어그램을 작성한다면 정밀도가 낮은 시퀀스 다이어그램이 되어버리거나 시나리오에 맞지 않는 사양이 될지도 모른다.

2) 시퀀스 다이어 그램 1개 당 하나의 시나리오가 기본이다.

 1개의 시퀀스 다이어그램마다 1개의 시나리오를 표현하는 것이 기본이다. 시퀀스 다이어그램에 분기 등을 넣어 1개의 시퀀스 다이어그램에 복수의 시나리오를 표현하는 것은 가능하지만, 가독성의 시점에서 볼 때 1개 시퀀스 다이어 그램에 1개 시나리오를 작성하는 것이 일반적이다.

 시나리오의 수만큼 시퀀스 다이어그램을 작성하는 것은 힘들지만, '사양을 명확화한다', '사양 버그를 줄인다', '사양 오독을 없앤다'라는 커다란 메리트가 있다. 즉, 코딩 후의 문서 작업에서 노동이 줄어든다. 

3) 길어질것 같은 시퀀스 다이어그램은 분리하자.

  시나리오에 따라는 시퀀스 다이어 그램이 옆으로 위로 길어져 버리는 경우가 있다. 1개의 시퀀스 다이어그램 1개의 시나리오를 지키고 있음에도 발생하는 경우가 있다. 이러한 경우에는 'ref'등을 사용하 시퀀스 다이어그램을 분리하자.

 A3용지에 담을 수 없느 길이가 된 경우에 분리를 검토하는 것이 좋다.

4) 메시지의 작성법을 정의해두자.

 메시지를 받는 쪽의 관점에서 작성할 것인가, 송신하는 쪽의 시점에서 작성할 것인가를 정의해두자. 메시지의 작성법을 명확히 작성하지 않으면 시퀀스 다이어그램에 따라 수신 쪽의 관점인가 송신쪽의 관점인가 혼동이 와서, 개발자(코딩 담장자)가 혼란스럽게 된다. 일반적으로 받는 쪽의 시점에서 작성하는 경우가 많다.

송신의 관점의 경우 '등록 버튼을 누름', 수신의 관점에서 '등록 처리를 개시'

5) 어디까지 자세히 적을지 미리 정의해두자.

 시퀀스 다이어그램을 상세히 작성하고자 한다면 변수에의 대입이나 메소드에 전달되는 구체적인 인수등 엄청 나게 자세히 적을 수 있다. 설계자나 개발자 (코딩 담장) 가 같은 경우라면 괜찮겠지만, 커다란 프로젝트의 경우 그렇지 않다. 

 설계 공정일이나 후 공정 품질에도 연결되므로 작성할 시퀀스 다이어그램의 품질의 책임자로 정의해두자. 

---

참고자료

it-koala.com/sequence_diagram-1775#i-10