가이드라인: 순서 다이어그램
주제
대부분의 경우에서 유스 케이스 실현(결과물: 유스 케이스 실현 참조)을
설명하기 위해, 즉, 객체가 상호 작용하여 유스 케이스 전부 또는 일부분의 작동을 수행하는 방법을 표시하기 위해
순서 다이어그램을 사용합니다. 하나 이상의 순서 다이어그램에서 유스 케이스를 재현하는 객체 상호 작용을
나타낼 수 있습니다. 일반적인 구성에서는 기본 이벤트 플로우와 각각의 독립적인 유스 케이스 서브플로우에 대해
순서 다이어그램이 하나씩 있습니다.
순서 다이어그램은 객체 역할을 플로우로 명확하게 설명하여 클래스 책임과 인터페이스를
판별하는 데 필요한 기본 입력을 제공하므로 설계자에게 매우 중요합니다.
의사소통 다이어그램과 달리 순서 다이어그램에는 연대순 순서가 포함되지만 객체 관계는
포함되지 않습니다. 순서 다이어그램과 의사소통 다이어그램은 유사한 정보를 표현하지만
다른 방법으로 해당 정보를 표시합니다. 순서 다이어그램은 메시지의 명시적 순서를 표시하며
메시지의 시간적 순서를 가시화해야 하는 경우에 적합니다. 한 상호 작용에서 인스턴스 간 구조적 관계에
관심이 있다면 의사소통 다이어그램을 사용하십시오. 자세한 정보는 가이드라인:
의사소통 다이어그램을 참조하십시오.
순서 다이어그램에는 상호 작용 방법을 설명하는 메시지와 함께 객체 및 액터 인스턴스가
있을 수 있습니다. 이 다이어그램은 활성화에 관하여 관련 객체에서 발생하는 내용과 객체가 상호 간에 메시지를 보냄으로써
의사소통하는 방법을 설명합니다. 여러 가지 유스 케이스의 이벤트 플로우 각각에 대해 순서 다이어그램을
작성할 수 있습니다.

간단한 전화 교환에서 시내 전화걸기 유스 케이스의 이벤트 플로우 파트를
설명하는 순서 다이어그램.
객체는 "생명선"이라는 수직 파선으로 표시됩니다.
생명선은 특정 시간에서 객체의 존재를 나타냅니다. 객체 기호는 생명선의 위쪽에 나타나며
다음과 같이 밑줄로 표시되고 콜론으로 분리된 객체 및 클래스의 이름을 보여줍니다.
객체 이름 : 클래스 이름
다음과 같은 방법으로 순서 다이어그램에서 객체를 사용할 수 있습니다.
- 생명선은 객체 또는 해당 클래스를 나타낼 수 있습니다. 따라서 생명선을 사용하여
클래스 및 객체 작동을 모델링할 수 있습니다. 그러나 생명선은 보통 특정 클래스의 모든 객체를 나타냅니다.
- 객체의 클래스는 지정할 수 없습니다. 일반적으로 먼저 객체를 사용하여 순서 다이어그램을 작성하고
나중에 해당 클래스를 지정합니다.
- 객체에는 이름을 지정할 수 없지만 같은 클래스의 다른 객체를 구별할 경우에는 이름을 지정해야 합니다.
- 동일한 다이어그램에 있는 여러 생명선은 동일한 클래스의 다른 객체를 나타낼 수 있지만 앞에서 설명한 대로
이름을 지정해야 두 객체를 식별할 수 있습니다.
- 한 클래스를 나타내는 생명선은 해당 클래스의 객체를 나타내는 생명선과 동시에 존재할
수 있습니다. 클래스를 나타내는 생명선의 객체 이름은 해당 클래스의 이름으로 설정할 수 있습니다.
일반적으로 액터 인스턴스는 상호 작용의 호출자로서 순서 다이어그램의 첫 번째(왼쪽 끝) 생명선으로
나타냅니다. 동일한 다이어그램에 여러 개의 액터 인스턴스가 있으면 왼쪽 끝 또는 오른쪽 끝의 생명선을
유지하도록 하십시오.
메시지는 활동이 계속될 것이라는 예상과 함께 정보를 전달하는 객체 간 의사소통입니다. 순서 다이어그램에서
메시지는 한 객체의 생명선에서 다른 객체의 생명선까지 가로 직선의 화살표로 표시합니다. 한 객체에서
객체 자신으로 메시지를 전달하는 경우 화살표는 같은 생명선에서 시작하여 끝날 수 있습니다. 화살표에는
메시지의 이름과 해당 매개변수로 레이블이 지정됩니다. 또한 전체 상호 작용에서 메시지 순서를 보여주기
위해 순번으로 레이블이 지정될 수 있습니다. 순서 다이어그램에서 순번은 종종 생략되지만 화살표의
실제 위치가 상대적인 순서를 표시합니다.
메시지 이름이 메시지의 전체적인 의미를 설명하고 수신하는 객체의 조작 이름이 아닌 임시 문자열이라는
의미에서 메시지를 지정하지 않을 수 있습니다. 나중에 메시지의 대상 객체 조작을 지정하여 메시지를
지정할 수 있습니다. 그러면 지정된 조작에서 메시지의 이름이 바뀌게 됩니다.
스크립트는 순서 다이어그램에서 이벤트 플로우를 텍스트로 설명합니다.
스크립트는 맨 위에서 맨 아래까지 전체 플로우를 판독할 수 있도록 생명선의 왼쪽에 두어야
합니다(위 그림 참조). 스크립트를 특정 메시지에 첨부할 수 있으므로 스크립트가 메시지와 함께 이동할 수 있습니다.
이벤트 플로우 또는 이벤트 플로우 일부분의 중앙 집중식 제어는 소수의 객체가 다른 객체로 메시지를
보내고 이 객체로부터 메시지를 받으면서 플로우를 진행한다는 것을 의미합니다. 이러한 객체 제어를 통해 유스 케이스에서
활성화될 다른 객체의 순서를 결정합니다. 나머지 객체 간 상호 작용은 매우 적거나 존재하지 않습니다.
예
재활용 기계 시스템에서 일일 보고서 인쇄 유스 케이스는 다른 객체 중에서
리턴되는 객체의 수와 유형을 트랙하여 계산 단위 마지막 수(tally)를 영수증에 기록합니다. 보고서 생성기
제어 객체는 합계를 추출하여 기록될 순서를 결정합니다.

일일 보고서 인쇄 유스 케이스의 작동 구조는 보고서 생성기 제어 객체에서
중앙 집중식으로 되어 있습니다.
이는 중앙 집중식 작동의 한 예입니다. 이벤트 플로우에서 다양한 서브이벤트 단계가 서로 종속되지
않기 때문에 제어 구조는 주로 중앙 집중식으로 되어 있습니다. 이 접근 방법의 주요 장점은 각 객체에서
다음 객체의 계산 단위 마지막 수(tally)를 트랙할 필요가 없다는 것입니다. 서브이벤트 단계의 순서를
변경하려면 제어 객체에서 순서를 변경하기만 하면 됩니다. 또한 예를 들어, 새 유형의 리턴 항목이
포함되는 경우 또다른 서브이벤트 단계도 계속하여 쉽게 추가할 수 있습니다. 작동 순서가 객체에 빌드되지
않기 때문에 다른 유스 케이스에서 다양한 서브이벤트 단계를 쉽게 재사용할 수 있다는 것이 이 구조의
또다른 장점입니다.
관련 객체가 하나 이상의 제어 객체를 통해서가 아니라 서로 직접 의사소통하는 경우
분산형 제어가 발생합니다.
예
편지 보내기 유스 케이스에서 어떤 개인이 우체국을 통해 다른 국가로
편지를 발송합니다. 먼저 수취인의 국가로 편지를 보냅니다. 이 국가에서는 특정 도시로 편지를
보냅니다. 그 다음으로 해당 도시에서는 수취인의 집으로 편지를 보냅니다.

편지 보내기 유스 케이스의 작동 구조는 분산형 구조입니다.
유스 케이스 작동은 분산형 이벤트 플로우입니다. 서브이벤트 단계는 함께
이루어집니다. 편지를 보내는 개인은 "누군가에게 편지를 보내는 중"이라고 말하며,
국가 또는 도시에서 편지를 보내는 방법에 대해 세부적으로 알 필요도 없고 알려고도 하지
않습니다. (국내에서 편지를 보내는 경우 이러한 조치가 모두 발생하는 것은 아닙니다.)
사용되는 제어 유형은 어플리케이션에 따라 달라집니다. 일반적으로 독립적인 객체를 얻도록 해야합니다. 즉, 다양한
타스크 수행에 가장 적합한 객체에 해당 타스크를 위임하도록 해야 합니다.
중앙 집중식 제어를 사용하는 이벤트 플로우에는 "포크 모양"의 순서 다이어그램이
있습니다. 한편, "계단 모양"의 순서 다이어그램은 관련 객체에 대해 분산형 제어 구조라는 것을
설명합니다.

이벤트 플로우에서 중앙 집중식 제어 구조는 "포크 모양"의 순서 다이어그램을
생성합니다. 분산형 제어 구조는 "계단 모양"의 순서 다이어그램을 생성합니다.
유스 케이스 실현의 작동 구조는 아주 흔히 중앙 집중식 및 분산형 작동의 결합으로 구성됩니다.
분산형 구조가 적합한 경우는 다음과 같습니다.
- 서브이벤트 단계가 긴밀하게 결합되어 있는 경우입니다. 관련 객체에서 다음을 수행하는 경우입니다.
- 계층의 일부분을 형성하거나 계층으로 구성됩니다(예: 국가 - 주 - 시).
- 정보 계층을 형성합니다(예: CEO - 사업부장 - 과장).
- 서브이벤트 단계의 순서가 항상 동일 순서로 수행되는 고정 연대순 진행을
나타냅니다(예: 광고 - 주문 - 송장 - 납품 - 지급).
- 개념적인 상속 계층을 형성합니다(동물 - 포유류 - 고양이).
- 캡슐화하려는 경우 이와 관련된 기능을 추상화하십시오. 중앙 집중식 작동 구조인 경우
기능을 이해하기가 어려워질 수 있기 때문에 이 방식은 항상 전체 기능을 사용할 개인에게 유용합니다.
중앙 집중식 구조가 적합한 경우는 다음과 같습니다.
- 서브이벤트 단계를 수행하는 순서가 변경되기 쉬운 경우.
- 새 서브이벤트 단계를 삽입할 것으로 예상되는 경우.
- 기능의 일부분을 별도의 항목으로 재사용할 수 있게 보관할 경우.
|