Creative Commons License

Software Dev

프로그래밍기본
객체지향
프로젝트관리
알고리즘
데이타베이스

소프트웨어 개발에 필수적이고 필요한 주제에 대한 강의 및 공유

.

객체지향

객체재향 프로그래밍 패러다임과 각종 기법 및 방법론에 대해 다룹니다

[UML] Sequence

작성자 : 박종명
최초 작성일 : 2008-05-14 (수요일)
최종 수정일 : 2008-05-14 (수요일)
조회 수 : 4641

 

Key Word

Sequence Diagram

객체간의 상호작용(교류),시계열적, 2차원(시간,객체), 메시지, 유스케이스 실현,시스템 내부 동작

 

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

시퀀스 다이어그램은 실제 개발자에게 더욱 친밀하다.

앞서 유스케이스 다이어그램은 사용자 참여에 중점인 반면 시퀀스 다이어그램은 실제 시스템을 프로그래밍 언어로
구현할 개발자에게 보다 더 유용하게 사용되며 해석될 수 있다.

 

유스케이스 : 사용자의 입장에서 본 시스템의 행동

시퀀스     : 개발자의 입장에서 본 시스템의 행동

 

 

1.1 시퀀스(Sequence)

시퀀스를(Sequence)는 사전적으로 연속,계속,순서의 뜻을 가지고 있다

UML 에서의 시퀀스는 시간에 흐름에 따른 시스템 내부 동작에 대한 표준적인 표기법이라 할 수 있다.

 

1.2 시퀀스 다이어그램 정의

유스케이스 다이어그램에서는 시스템이 어떤 기능을 제공하는지에 대한 것에 초점이 있는 반면, 시퀀스 다이어그램
은 그 기능들이 시스템 내부적으로 어떤식으로 구현(실현)되는지에 초점을 맞춘다.
객체지향 시스템에서는 하나의 
기능을 구현(실현)하기 위해서는 객체들간의 교류로 이루어 지는 경우가 많다.
즉 클래스로부터 생성된 객체들이
다른 객체에 메시지를 전달하며 연산을 호출함으로써 기능(Use Case) 을 실현하게 된다.

 

정의>> 시퀀스 다이어그램이란?

특정 기능 수행을 위해 시스템 내의 한 객체가 다른 객체와 어떻게 교류(상호작용)하는 지를 시간의 흐름에 걸쳐 명세화 한 다이어그램

 

결국 시퀀스 다이어그램의 핵심은 객체들간의 상호작용을 시계열적으로 표현하는 것이며 시스템 내부 이벤트의 흐름을 기술하는 용도로 사용된다.

 

1.3 유스케이스의 실현

시퀀스 다이어그램은 유스케이스 다이어그램에 기술된 기능(Use Case)들의 실세 시스템 실현을 명시한다. 따라서
시퀀스 다이어그램은 각 유스케이스 별로 작성하라고 권고하기도 한다.
그러나 여전히 강조하지만 모든 유스케이스
를 전부 시퀀스 다이어그램으로 구체화할 필요가 있는지는 조심스럽게 접근해야 할 것이다.

   

 

2. 시퀀스 다이어그램의 구성요소  

객체들은 시간의 흐름에 따라 메시지를 주고 받으며 서로 교류(상호작용) 한다.

시퀀스 다이어그램은 객체(Object),생명선(Lifeline),실행(activation),메시지,시간등의 구성요소로 이루어진다.

아래는 시퀀스 다이어그램의 샘플이다. 맨 왼쪽에 있는 Actor 는 익명의 Actor 로써 기능의 출발,시작을 위해 표시하
였지만, 시퀀스다이어그램의 구성요소는 아니다.




2.1 객체(Object)


시퀀스 다이어그램은 객체들의 교류에 대해 기술한다. 객체는 위쪽에 표시되며 아래로 생명선을 가진다.
객체는 사각형 박스안에 밑줄 친 이름으로 명시한다. (클래스는 밑줄없이 표시한다)


√ 흐름 중 객체 생성하기
객체 지향 시스템에서는 이벤트 흐름 중 객체가 생성되고 소멸되는 과정이 많이 일어난다.
시퀀스 다이어그램에서 특정 오페레이션 수행 과정중에 객체가 생성될 수 있는데 이는 다음과 같이 표현할 수 있다.



Object1 객체가 오퍼레이션 수행 중 Object2 객체를 생성하는 예제이다.

 

 

2.2 생명선(Lifeline)


객체로부터 뻗어 나가는 쇄선을 생명선이라고 한다.

실제 시간이 흐름에 따라 객체의 생명주기 동안 발생하는 이벤트를 명시한다.


√ 흐름 중 객체 소멸하기



생명선인 쇄선의 끝에 X 표시가 되면 그 객체가 소멸한다는 의미이다


2.3 실행(activation)


직사각형으로 표현되는 실행(activation)은 어떠한 호출로 인해 객체의 오퍼레이션이 실행되고 있음을 나타낸다.

활성화 상자(activation box) 로 해석되는 이 직사각형은 오퍼레이션(함수라고 생각하자)이 실행되는 시간을 의미한다. 직사각형이 길어질수록 오퍼레이션 수행시간이 길다는 의미가 된다.

참고>>

활성화 상자를 반드시 그려야 할 필요는 없다.

보통 서로 다른 시스템 간의 이벤트 흐름중의 상호작용과 같은 보다 상위수준의 시퀀스 다이어그램에서는
상호작용과 흐름을 정의하는 것이 목적이기 때문에 활성화 상자를 제외하기도 한다.
반면, 특정 한 시스템 내의 세부 알고리즘을 기술할 때 특정 오퍼레이션의 수행에 초점이 맞춰져 있다면 활성화 상자는 충분한 의미가 있을 수 있다

 

 

2.4 메시지


객체간의 상호작용은 메시지 교환으로 이루어 진다.

한 객체에서 다른 객체로의 또는 자기자신으로 메시지를 전달하여 전달받은 객체의 오퍼레이션을 수행하도록 한다.

(메시지에 전달할 파라메타가 있다면 메시지 뒤, 괄호안에 기입하면 된다 : Do(param) )


Recursion


물론 메시지가 반드시 다른 객체로만 연결되라는 법칙은 없다. 객체가 자기자신을 호출하는 경우를 Recursion 이라고 한다. 왼쪽 그림처럼 Do 라는 오퍼레이션은 자기자신을 호출하는 구조이다.

√ 메시지의 종류

객체간 주고받는 메시지에는 크게 3가지의 종류가 있다 
 

종류

설명

UML 표기

단순 메시지
(Simple)

한 객체에서 다른 객체로 제어 흐름의 이동

동기 메시지
(Synchronous)

동기 호출

메시지를 보낸 객체는 응답이 올때까지 기다림.

비동기 메시지
(Asynchronous)

비동기 호출

메시지를 보낸 객체는 응답여부와 상관없이

자신의 작업을 계속 진행함

 

참고>>

위의 UML 표기를 보면 단순/동기/비동기의 화살촉의 모양이 다르다.

실제로 UML 2.0 의 경우 위의 표기법과 조금 다르다.

어떤 표기법을 사용하느냐에 대한 정답은 없다. 프로젝트 참여자들이 표준적으로 이해할 수 있는 표기법을 사용하도록 하자

 

 

2.5 시간



시퀀스 다이어그램은 시계열적인 특성을 가진다. 즉 시간이라는 차원이 존재한다.

시퀀스 다이어그램은 2차원 그래프의 형태를 가지는데 x축은 시간의 흐름, y 축은 객체들의 배열로 해석할 수 있겠다. 시간은 위에서 아래로 흐른다



3. 시퀀스 다이어그램 치장하기  

유명한 소프트웨어 전문가 스티브 맥코넬 은 그의 저서 ‘RAPID Development’ 에서 요구사항 치장하기’, ‘개발자 치장등과 같이 치장하기라는 말을 자주 언급한다. 요구에 맞는 수준을 오버하여 꼭 필요하지도 않는 요소를 치장하지 말라는 의미를 담고 있다.  

시퀀스 다이어그램은 지금까지 알아본 구성요소 이외에 고급기법을 몇가지 더 정의하고 있다. 프로그램 작성에 반드시 나오는 조건에 의한 분기 , 반복 이 그것이다. 시퀀스 다이어그램은 이와 같이 조건’,’반복을 표현하는 스펙도 가지고 있다. , 시퀀스 다이어그램으로 특정 오퍼레이션이 수행되는 전 과정을 세세히 기술할 수 있다는 것이다.

 

 

3.1 조건

마치 Activity 다이어그램에서 특정 조건에 따라 흐름이 분기되듯이 시퀀스 다이어그램으로도 조건에 대한 표기법을 포함하고 있다. 아래 표기법 처럼 조건을 대괄호 안에다 기입한 후 메시지 화살표 위에 위치시킨다.

 

[ 조건식 ]

 

아래 그림은 투케더에서 조건을 명시한 메시지 모습이다.



3.2
반복

특정 조건에 의해 특정 구간이 반복되는 것도 표현할 수 있다.

아래 표기법 처럼 반복 조건을 대괄호 안에 기입하고 왼쪽에 별표(*) 를 붙인다.

 

*[ 반복 조건식 ]

 

아래 그림은 투게더에서 반복을 명시한 메시지 모습이다



3.3
기타

조건과 반복 이외에도 멀티 쓰레드를 위한 쓰레드 식별자, 시간이 걸리는 메시지 등 실제 프로그래밍적인 요소 대부분을 시퀀스 다이어그램에 표현할 수 있다.  

이쯤에서 ‘UML 실전에서는 이것만 쓴다의 저자 로버트 C. 마틴의 다음 글을 음미해 보자

 

사실 알고리즘을 시퀀스 다이어그램으로 나타내려고 노력하는 것은 그다지 현명하지 않다.

시퀀스 다이어그램은 객체 사이의 연결을 드러내기 위해 사용해야지, 알고리즘의 세부사항을 자세하게 보여주기 위해 사용해서는 안된다.”

복잡한 알고리즘을 설명하기 위해서 라면 코드를 직접 보여주는 편이 나을수 도 있다

 

결국 모든 것은 그때 그때 달라요의 법칙에 따라 필요할때와 필요치 않을 때를 구분하여 설계를 해야 할 것이다.

 

 

 

4. 결론

 

시퀀스 다이어그램은 비즈니스 도메인을 이해하고 요구사항을 수집하여 클래스를 도출하고 요구사항을 분석하고 난 뒤 행해지는 설계단계의 행위이다. 이것은 액티비티 다이어그램과 더불어 실제 시스템의 논리적인 기능 수행을 일목요연하게 표현할 수 있는 좋은 표기법이다.

 

또한 시퀀스 다이어그램은 개발 과정 중에 가장 많은 정제의 과정을 거치는 다이어그램 중 하나이다. 요구사항은 하나로 고정되어도 그 요구사항을 실현하는 개발적 요소는 상황에 따라 많은 부분 변화할 수 있기 때문이다.

그리고 시퀀스 다이어그램은 실제 코딩을 하기 위한 가이드 라인이 되기도 하지만 이미 구축된 시스템의 연동구조 및 이벤트 흐름을 이해하는 용도로도 훌륭하다. 업무 인수인계에서도 강한 힘을 발휘한다.

(업무를 새로 파악하는 입장에서 복잡한 처리 과정을 담은 모든 코드를 일일이 보며 파악하기란 쉽지 않은 일이다)

 

시퀀스 다이어그램 역시 어디까지를 만들어야 하는 범위의 문제가 논의 대상이기도 하다.

이것에 대한 정답이라는 것은 없다.

단지 현재 요구되는 시스템 개발 스펙,환경,상황에 따라 유연하게 범위를 잡아야 한다. 모든 기능에 대한 시퀀스 다이어그램이 꼭 필요한 것은 아니며 또한 특정 기능에 대한 아주 상세한 다이어그램이 꼭 필요한 것도 아니다. (반대로 꼭 필요할 경우도 있다 --;) 기억할 것은 UML 치장을 하지 않는 것이다.

시퀀스 다이어그램이야 말로 아주 세세히 복잡하게 만들면 그 어떤 다이어그램 보다 어려운 결과물이 나올 것이다.

필요한 것 만큼만 쓰도록 하자.


이름
비밀번호
홈페이지
EQ <- 왼쪽의 문자를 오른쪽 박스에 똑같이 입력해 주세요