시퀀스 다이어그램이란?



http://5dol.tistory.com/128


기초

시퀀스 다이어그램의 주요 목적어떤 결과를 만들어내는 이벤트 시퀀스를 정의하는 것이다. 메시지 보다는 메시지가 발생하는 순서에 초점이 더 맞춰진다. 대부분 시퀀스 다이어그램은 system 객체들 간 어떤 메시지들이 보내지는지, 그리고 어떤 순서로 발생하는지를 나타낸다. 다이어그램은 이 정보를 수직적 측면과 수평적 측면으로 전달한다. 수직 측면에서는 탑다운(top down) 방식으로 메시지/호출이 발생한 시간 순서를 나타내고, 수평 측면에서는 왼쪽에서 오른쪽으로 메시지가 보내진 객체 인스턴스를 보여준다.

 

Lifelines

시퀀스 다이어그램을 그릴 때 Lifeline 표기법 엘리먼트는 다이어그램 상단에 놓인다. Lifeline은 모델링되는 시퀀스에 개입된 역할 또는 개게 인스턴스들을 나타낸다.

1 Lifeline은 박스의 아래쪽 중심에서 대시(dash)[점선] 라인을 그리며 내려간다. (그림 3). 이 Lifeline의 이름은 박스 내부에 있다


해당 클래스를 통해서 만들어진 객체의 존재 선. 그래서 라이프라인인듯 하다. 




그림 3: 인스턴스 이름이 freshman인 Student 클래스 예제



Lifeline의 UML의 네이밍 표준은 다음 포맷은 따른다.

Instance Name : Class Name

(실제 객체 : 클래스)



그림 3의 예제에서, Lifeline은 Student 클래스의 인스턴스를 나타낸다. 이것의 인스턴스 이름은 freshman이다. Lifeline 이름 밑에 그어진 밑줄에 주목하라. 밑줄이 사용될 때는 Lifeline이 한 시퀀스 다이어그램에서 클래스의 특정 인스턴스를 나타낸다는 것을 의미한다. 특정 종류의 인스턴스(예를 들어, '역할')가 아니다. 구조 모델링에 대해서도 살펴볼 것이다. 지금까지 누가(Bill과 Fred) 그 역할을 수행하는지를 지정하지 않은 시퀀스 다이어그램에는 buyerseller 등의 역할이 포함되어 있다는 것을 알 수 있다. 이런 경우 다이어그램은 다른 정황에서도 재사용된다. 시퀀스 다이어그램에 역할 이름이 아닌 인스턴스 이름에 밑줄을 긋는다.

그림 3의 Lifeline 예제는 네임드 객체이다. 하지만 모든 Lifeline이 네임드 객체를 나타내는 것은 아니다. 대신 익명 또는 이름없는 인스턴스를 나타내는데도 Lifeline이 사용될 수 있다. 시퀀스 다이어그램에 이름없는 인스턴스를 모델링 할 때, Lifeline의 이름은 네임드 인스턴스와 같은 패턴을 따른다. 그러나 인스턴스 이름을 주는 대신에, Lifeline의 이름의 부분이 공백으로 된다. 그림 3을 다시 보자. 만약 이 Lifeline이 Student 클래스의 익명 인스턴스를 나타낸다면, Lifeline은 " Student." 이다. 또한 시퀀스 다이어그램은 프로젝트의 디자인 단계에서 사용되기 때문에 유형이 지정되지 않은 객체를 갖고 있는 것이 맞다. 예를 들어 "freshman."이 바로 그것이다.

 

메시지

시퀀스 다이어그램의 첫 번째 메시지는 언제나 상단에서 시작하고 다이어그램의 왼쪽에 위치한다. 뒤따르는 메시지들은 이전 메시지보다 약간 낮게 다이어그램에 추가된다.

메시지를 또 다른 객체에 보내는 객체(lifeline)를 나타내기 위해서 수신 객체에 실선 화살표(동기식 호출일 경우)를 긋는다. 또는 (비동기식일 경우) 막대 화살표를 긋는다. 메시지/메소드 이름은 화살표 위에 놓인다. 수신 객체로 보내지는 메시지는 수신 객체의 클래스가 구현하는 작동/메소드를 나타낸다. 그림 4의 예제에서, analyst 객체는 ReportingSystem 클래스의 인스턴스인 system 객체를 호출한다. analyst 객체는 system 객체의 getAvailableReports 메소드를 호출한다. system 객체는 secSystem 객체에 userId의 인자와 함께 getSecurityClearance 메소드를 호출한다. 이것이 바로 SecuritySystem 클래스 유형이다.




그림 4: 객체들 간 보내지는 메시지 예제

 

시퀀스 다이어그램에 대한 메시지 호출을 보여주는 것 외에도 그림 4 다이어그램에는 리턴 메시지가 포함되어 있다. 이 리턴 메시지들은 필수요소는 아니다. 리턴 메시지는 원래 lifeline을 향하도록 점선 화살표로 그려지고 그 위에 리턴 값을 배치한다. 그림 4에서, getSecurityClearance 메소드가 호출될 때 secSystem 객체는 system 객체에 userClearance를 리턴한다. 이 system 객체는 getAvailableReports 메소드가 호출되면 availableReports를 리턴한다.

다시 말하지만, 리턴 메시지는 시퀀스 다이어그램의 선택 사항이다. 리턴 메시지의 사용 여부는 모델링되는 것의 상세함 정도에 달려있다. 리턴 메시지는 보다 상세한 것을 원할 때 유용하다. 하지만 호출 메시지로도 충분하다. 개인적으로는 값이 리턴될 때마다 리턴 메시지를 삽입한다.

시퀀스 다이어그램을 모델링 할 때, 객체가 자신에게 메시지를 보내야 할 때가 있다. 언제 객체가 자기자신을 호출할까? 순수주의자들은 객체는 메시지를 객체 자신에게 보내서는 안된다고 주장한다. 하지만 자신에게 메시지를 보내는 객체를 모델링 하는 것도 어떤 경우에는 유용하다. 그림 5는 그림 4를 개선한 것이다. 그림 5는 determineAvailableReports 메소드를 호출하는 system 객체를 보여준다. 그 system 객체에 "determineAvailableReports," 메시지를 보여줌으로써 모델은 이 프로세스가 system 객체에서 발생한다는 사실에 주목할 수 있다.

자기자신을 호출하는 객체를 그리기 위해서는 정상적인 방법으로 메시지를 그리되 또 다른 객체로 연결하는 대신, 메시지를 다시 객체 자신으로 연결한다.



그림 5: determineAvailableReports 메소드를 호출하는 system 객체

 

그림 5의 예제 메시지는 동기식 메시지이다. 하지만 시퀀스 다이어그램에서는 비동기식 메시지도 모델링 할 수 있다. 비동기식 메시지는 동기식 메시지와 비슷하게 그려지지만 메시지 라인은 막대 화살표로 표시된다. (그림 6)




동기는 굵은 화살표로 , 비 동기는 얇은 선 화살표다.


그림 6: instance2로 보내지는 비동기식 메시지를 나타내는 시퀀스 다이어그램

 

가드(guard)

객체 인터랙션(interaction - 상호작용)을 모델링 할 때 객체로 보내지는 메시지 조건이 부합해야 할 때도 있다. 가드(guard)는 흐름을 제어하는 UML 다이어그램에서 쓰인다. UML 1.x 와 UML 2.0 모두 가드를 언급했다. UML 1.x에서 보호는 하나의 메시지에만 할당될 수 있었다. UML 1.x의 시퀀스 다이어그램에 가드를 그리려면 보호되고 있는 메시지 라인 위, 메시지 이름 앞에 guard 엘리먼트를 둔다. 그림 7은 메시지 addStudent 메소드에 대한 가드가 있는 시퀀스 다이어그램이다




그림 7: 가드가 포함된 addStudent 메시지

 

그림 7에서 가드는 텍스트 "[pastDueBalance = 0]" 이다. 이 메시지에 가드가 있기 때문에 addStudent 메시지는 시스템 계정이 [pastDueBalance = 0]을 리턴할 경우에만 보내진다.

[Boolean Test]

 

예를 들어,

[pastDueBalance = 0]

 

Combined fragments (대안, 옵션, 루프)

대부분의 시퀀스 다이어그램에서 UML 1.x "in-line" 가드는 모델링 되는 시퀀스에 필요한 로직을 핸들하기엔 조금 부족했다. 그러한 기능이 부족하다는 점이 UML 1.x에서 문제가 되었다. UML 2는 "in-line" 가드를 없애고, Combined FFragment라고 하는 표기법 엘리먼트를 추가하여 이러한 문제를 다루고 있다. Combined Fragment는 시퀀스 다이어그램에서 조건의 흐름을 보여주기 위해 메시지들을 하나로 그룹핑하는데 사용된다. UML 2 스팩은 Combined Fragment에 11 개의 인터랙션 유형을 정의하고 있다.

 

대안

대안은 두 개 이상의 메시지 시퀀스들간 상호 배타적인 선택을 나타낼 때 사용된다.

대안은 전통적인 "if then else" 직 (만일 내가 세 개의 아이템을 구매하면 구매금액의 20%를 할인 받는다; 그 외에는 10%의 할인을 받는다.)의 모델링이 가능하다.

그림 8에서 보듯, 대안 엘리먼트는 프레임을 사용하여 그려진다. "alt" 라는 단어는 이 프레임의 네임박스 안에 놓인다. 더 큰 직사각형은 피연산함수로 나누어진다.

4피연산 함수는 대시(dash) 라인으로 분리된다. 각 피연산 함수에는 가드가 주어지고 이 가드는 lifeline 상단에 피연산 함수의 왼쪽 상단 부분을 향해 배치된다.

5피연산함수의 가드가 "true,"로 되면 그 피연산함수를 따라야 한다.




그림 8: 대안 Combined Fragment를 포함하고 있는 시퀀스 다이어그램

 

대안이 어떻게 읽혀지는지를 보여주는 예제로서 그림 8은 상단에서 시작하는 시퀀스를 보여준다. check amount와 account의 balance 정보가 있는 bank 객체가 있다. 이 부분에서 대안이 사용된다. 가드 "[balance >= amount]" 때문에 account의 balance이 보다 크거나 같을 때 시퀀스는 addDebitTransaction과 storePhotoOfCheck 메시지를 account 객체로 보내는 bank 객체를 사용하여 시퀀스를 지속시킨다. 하지만 balance가 amount 보다 작을 때 시퀀스는 addInsuffientFundFee와 noteReturnedCheck 메시지를 account 객체로 보내고, returnCheck 메시지를 자기 자신에게 보내는 bank 객체로 처리한다. "[else]" 가드 때문에 balance가 amount 보다 작거나 같을 때 두 번째 시퀀스가 호출된다. 대안을 사용하면 "[else]" 가드가 필요 없다. 하지만 피연산함수가 이것에 대한 명확한 가드를 갖고 있지 않다면 "[else]" 가드가 필요하다.

대안은 "if then else"에만 국한되지 않는다. 필요한 만큼 대안 경로를 취할 수 있다. 더 많은 대안이 필요하면 시퀀스의 가드와 메시지를 포함한 직사각형에 피연산함수를 추가하면 된다.

 

옵션

옵션 Combined Fragment는 특정 상황에서 발생하는 시퀀스를 모델링 할 때 사용된다. 다른 경우, 이 시퀀스는 발생하지 않는다. 이 옵션은 간단한 "if then"문장을 모델링 하는데 쓰인다. (찬장에 5개 미만의 도넛이 있다면 24개 이상의 도넛을 만든다.)

옵션 표기법은 대안과 비슷하다. 단 한 개의 피연산 함수를 가져야 하고, "else" 가드가 전혀 없다는 것을 제외하고는 말이다. 옵션을 그리려면 프레임을 그려야 한다. "opt" 텍스트가 이 프레임의 네임박스 안에 배치되고, 이 프레임의 콘텐트 영역에 옵션의 가드가 lifeline의 상단에, 왼쪽 상단 코너를 향해 배치된다. 그런 다음 옵션의 메시지 시퀀스가 나머지 영역에 배치된다. (그림 9)



그림 9: 옵션 Combined Fragment

 

옵션 Combined Fragment는 읽기 쉽다. 그림 9는 그림 7의 시퀀스 다이어그램을 재구성 한 것이다. 하지만 여기에서는 student의 과거 해당 balance가 0일 경우 보내져야 하는 메시지가 더 많기 때문에 옵션을 사용한다. 그림 9의 시퀀스 다이어그램을 보면, student의 과거 balance가 0 이면 addStudent, getCostOfClass, chargeForClass 메시지들이 보내진다. student의 과거 balance가 0이 아니라면 시퀀스는 어떤 메시지도 보내지 않는다.

그림 9의 시퀀스 다이어그램에는 이 옵션용 가드가 포함되어 있다. 하지만 이 가드는 필수 엘리먼트는 아니다. 추상 시퀀스 다이어그램에서는 이 옵션의 조건을 지정한다. 이것이 옵션 fragment 라는 것을 가리키면 된다.

 

루프(loop)

가끔 반복적인 시퀀스를 모델링 해야 할 때도 있다. UML 2에서 반복되는 시퀀스의 모델에 루프 Combined Fragment를 사용한다.

루프는 외형상 옵션과 매우 흡사하다. 프레임을 그리고 그 프레임의 네임박스에 "loop"라고 쓴다. 프레임의 콘텐트 영역 안에서 루프의 가드는

6 lifeline의 상단에, 왼쪽 상단 코너 쪽을 향하여 놓인다. 그런 다음 루프의 메시지 시퀀스는 프레임의 나머지 콘텐트 영역에 배치된다. 루프에서 가드는 두 가지 특별한 조건을 가질 수 있다. 이 특별 가드 조건들은 "minint = [the number]" ("minint = 1")라고 하는 최소 반복과 and maximum iterations written as "maxint = [the number]" ("maxint = 5")라고 하는 최대 반복이다. 최소 반복 가드를 사용하여, 루프는 지정된 최소한의 수만큼 실행해야 하고 최대 또한 마찬가지이다.



그림 10: loop Combined Fragment

 

그림 10(

크게 보기)에서, 루프는 reportsEnu 객체의 hasAnotherReport 메시지가 false를 리턴할 때까지 실행된다. 이 시퀀스 다이어그램의 루프는 루프 시퀀스가 실행되는지를 확인할 때 부울 테스트를 사용한다. 이 다이어그램은 위에서부터 읽어 내려간다. 루프에 다다르면 hasAnotherReport 값이 true 인지를 확인하기 위해 테스트가 실행된다. HasAnotherReport 값이 true 면 시퀀스는 루프로 간다.

 


여기까지가

http://5dol.tistory.com/128

에서 소개되는 기초 내용이다. 이후의 내용도 저 안에 있다.


Posted by GENESIS8

댓글을 달아 주세요

  1. BBingStory 2018.12.09 16:56 신고  댓글주소  수정/삭제  댓글쓰기

    글을 되게 잘 정리해 놓으셨네요 ㅜㅜ
    기말고사 공부중인데 잘 봤습니다 감사합니다 !!