대부분의 경우 시퀀스 다이어그램을 사용하여 유스 케이스 실현을 예시, 즉 유스 케이스 모두 또는 부분의 작동을 수행하기 위해 오브젝트가 상호작용하는 방법을 표시합니다(중간 산출물: 유스 케이스 실현(realization) 참고). 하나 이상의 시퀀스 다이어그램은 유스 케이스를 규정하는
오브젝트 상호작용을 설명할 수 있습니다. 일반 조직의 경우 기본 이벤트 플로우에 대한 하나의 시퀀스 다이어그램 및 독립적인 유스 케이스의 각 서브플로우에 대한 하나의 시퀀스 다이어그램이 있습니다.
시퀀스 다이어그램은 플로우에서 오브젝트 역할을 명확히 하고 클래스 책임 및 인터페이스를 판별하는 경우 기본 입력을 제공하기 때문에 디자이너에게 특히 중요합니다.
커뮤니케이션 다이어그램과 달리 시퀀스 다이어그램은 연대순을 포함하지만 오브젝트 관계는 포함하지 않습니다. 시퀀스 다이어그램 및 커뮤니케이션 다이어그램은 유사한 정보를 표현하지만 표시하는 방법은 서로 다릅니다.
시퀀스 다이어그램은 메시지의 명시적 시퀀스를 표시하고 메시지의 시간 순서를 시각화하는 것이 중요한 경우 더 적합합니다. 상호작용에서 인스턴스 간 구조 관계에 관심이 있는 경우 커뮤니케이션 다이어그램을 사용하십시오.
자세한 정보는 기법:
커뮤니케이션 다이어그램을 참조하십시오.
시퀀스 다이어그램에는 오브젝트 및 액터 인스턴스와 함께 이들의 상호작용 방법을 설명하는 메시지가 있을 수 있습니다. 다이어그램에서는 오브젝트가 다른 오브젝트에 메시지를 송신하여 커뮤니케이션하는 방법 및 활동
측면에서 오브젝트 참가 시 나타나는 상황을 설명합니다. 유스 케이스의 이벤트 플로우가 변형될 때마다 시퀀스 다이어그램을 작성할 수 있습니다.
단순 전화 스위치에서 시내 전화 걸기 유스 케이스의 이벤트 플로우 파트를 설명하는 시퀀스 다이어그램입니다.
오브젝트는 "라이프라인"이라고 하는 세로 점선으로 표시됩니다. 라이프라인은 특정 시간에 오브젝트의 존재 여부를 표시합니다. 오브젝트 기호는 라이프라인 헤드에 그려지며 오브젝트 이름 및 밑줄 친 해당 클래스(콜론으로
구분됨)를 표시합니다.
objectname : classname
다음과 같은 방법으로 시퀀스 다이어그램의 오브젝트를 사용할 수 있습니다.
-
라이프라인은 오브젝트 또는 해당 클래스를 표시할 수 있습니다. 따라서 라이프라인을 사용하여 클래스 및 오브젝트 동작 모두를 모델링할 수 있습니다. 그러나 일반적으로 라이프라인은 특정 클래스의 모든 오브젝트를
표시합니다.
-
오브젝트 클래스를 지정할 수 없습니다. 보통 먼저 오브젝트를 포함하는 시퀀스 다이어그램을 작성하고 나중에 해당 클래스를 지정합니다.
-
오브젝트 이름을 지정할 수 없습니다. 그러나 동일한 클래스의 서로 다른 오브젝트를 구별하는 경우 이름을 지정해야 합니다.
-
동일한 다이어그램의 여러 라이프라인은 동일한 클래스의 서로 다른 오브젝트를 표시할 수 있습니다. 그러나 이전에 언급한 대로 두 오브젝트 사이를 구별할 수 있도록 오브젝트 이름을 지정해야 합니다.
-
클래스를 표시하는 라이프라인은 해당 클래스의 오브젝트를 표시하는 라이프라인과 병렬로 존재할 수 있습니다. 클래스를 표시하는 라이프라인의 오브젝트 이름을 클래스 이름으로 설정할 수 있습니다.
보통 액터 인스턴스는 시퀀스 다이어그램의 첫 번째(가장 왼쪽) 라이프라인에서 상호작용의 호출자로 나타납니다. 동일한 다이어그램에 액터 인스턴스가 여러 개인 경우 가장 왼쪽 또는 가장 오른쪽 라이프라인에서 액터를
유지하십시오.
메시지는 활동이 계속된다고 예상하는 경우 정보를 커뮤니케이션하는 오브젝트 사이의 커뮤니케이션입니다. 시퀀스 다이어그램에서 메시지는 한 오브젝트의 라이프라인부터 다른 오브젝트의 라이프라인까지 단색의 가로 화살표로
표시됩니다. 한 오브젝트에서 자체로 송신되는 메시지의 경우 화살표는 동일한 라이프라인에서 시작 및 종료될 수 있습니다. 메시지의 이름 및 매개변수가 화살표 레이블로 지정됩니다. 또한 전반적인 상호작용에서 메시지의
순서를 표시하도록 화살표 레이블에 시퀀스 번호가 지정될 수 있습니다. 종종 시퀀스 번호는 시퀀스 다이어그램에서 생략됩니다. 이때 화살표의 실제 위치는 상대적 시퀀스를 표시합니다.
메시지는 지정되지 않을 수 있습니다. 즉, 해당 이름이 전반적인 메시지 내용을 설명하는 임시 문자열이고 수신하는 오브젝트의 오퍼레이션 이름이 아님을 의미합니다. 메시지의 대상 오브젝트 오퍼레이션을 지정하여 나중에
메시지를 지정할 수 있습니다. 메시지 이름은 지정된 오퍼레이션으로 바뀝니다.
스크립트는 시퀀스 다이어그램의 이벤트 플로우를 텍스트 형식으로 설명합니다.
맨 위부터 맨 아래까지 전체 플로우를 읽을 수 있도록 라이프라인의 왼쪽에 스크립트를 배치해야 합니다(위 그림 참조). 특정 메시지에 스크립트를 첨부할 수 있습니다. 그러면 메시지와 함께 스크립트가 이동됩니다.
이벤트 플로우 또는 이벤트 플로우 파트의 중앙 제어는 소수의 오브젝트가 메시지를 송신하고 다른 오브젝트에서 메시지를 수신하여 플로우를 조종함을 의미합니다. 이 제어 오브젝트는 유스 케이스에서 기타
오브젝트를 활성화하는 순서를 결정합니다. 나머지 오브젝트에서의 상호작용은 매우 사소하거나 존재하지 않습니다.
예제
재활용품 수집기 시스템에서 매일 보고서 인쇄 유스 케이스는 나머지 항목에서 반품된 오브젝트의 수 및 유형을 추적하고 영수증에 품목을 기록합니다. 보고서 생성기 제어 오브젝트는
합계를 계산하고 기록하는 순서를 결정합니다.
매일 보고서 인쇄 유스 케이스의 동작 구조는 보고서 생성기 제어 오브젝트에서 중앙 처리됩니다.
위는 중앙 처리 동작에 대한 예제입니다. 이벤트 플로우의 서로 다른 서브이벤트 제어 단계는 서로 독립적이기 때문에 제어 구조는 주로 중앙 처리됩니다. 이 접근 방식의 주된 장점은 각 오브젝트가 다음 오브젝트의
품목을 추적하지 않아도 된다는 점입니다. 서브이벤트 단계의 순서를 변경하려면 단순히 제어 오브젝트를 변경하면 됩니다. 예를 들어 반품 항목의 새 유형이 포함된 경우 다른 서브이벤트 단계도 쉽게 추가할 수 있습니다.
이 구조의 또 다른 장점은 동작 순서가 오브젝트로 빌드되지 않았기 때문에 다른 유스 케이스에서 다양한 서브이벤트 단계를 쉽게 재사용할 수 있다는 점입니다.
참가 오브젝트가 하나 이상의 제어 오브젝트를 통하지 않고 다른 오브젝트와 직접 커뮤니케이션하는 경우 분산 제어가 발생합니다.
예제
편지 보내기 유스 케이스에서 우체국을 통해 다른 국가로 편지를 보내려고 합니다. 먼저 받는 사람의 국가로 편지를 보냅니다. 이 국가에서 특정 구/군/시로 편지를 보냅니다. 그러면 구/군/시에서 받는
사람의 집으로 편지를 보냅니다.
편지 보내기 유스 케이스의 동작 구조는 분산 처리되었습니다.
이 유스 케이스 동작은 분산된 이벤트 플로우에 해당합니다. 서브이벤트 단계는 함께 소속되어 있습니다. 편지를 보내는 사람은 "누군가에게 편지를 보낸다"고 말합니다. 국가 또는 구/군/시로 편지가 전달되는 방법에
대해 자세히 알 필요도 없고 알고 싶어하지도 않습니다. (동일한 국가에서 편지를 보내는 경우 이와 같은 모든 조치가 발생하지는 않습니다.)
사용하는 제어 유형은 응용프로그램에 따라 다릅니다. 일반적으로 독립적인 오브젝트를 달성해야 합니다. 즉, 다양한 타스크를 원래부터 해당 타스크를 수행하는 데 가장 적합한 오브젝트에 위임해야 합니다.
중앙 제어를 사용하는 이벤트 플로우는 "포크 모양"의 시퀀스 다이어그램으로 표시됩니다. 반면 "계단 모양"의 시퀀스 다이어그램은 참가 오브젝트에서 제어 구조가 분산되었음을 표시합니다.
이벤트 플로우에서 중앙 제어 구조는 "포크 모양"의 시퀀스 다이어그램을 생성합니다. 분산 제어 구조는 "계단 모양"의 시퀀스 다이어그램을 생성합니다.
유스 케이스 실현(realization)의 동작 구조는 대부분 중앙 및 분산 동작이 혼합되어 구성됩니다.
분산 구조는 다음 경우에 적합합니다.
-
서브이벤트 단계가 긴밀히 결합된 경우. 참가 오브젝트가 다음과 같은 경우에 해당합니다.
-
파트 또는 구성별 계층 구조로 구성되는 경우(예: 국가 - 도 - 구/군/시),
-
정보 계층 구조로 구성되는 경우(예: CEO - 과장 - 대리)
-
고정된 연대순 진행을 표시하는 경우(서브이벤트 단계의 시퀀스가 항상 동일한 순서로 수행됨)(예: 홍보 - 주문 - 송장 - 배달 - 지불) 또는
-
개념 상속 계층 구조로 구성되는 경우(예: 동물 - 포유류 - 고양이).
-
기능을 캡슐화하여 기능을 추상적으로 작성하는 경우. 동작 구조가 중앙 구조이면 쓸데없이 기능을 이해하기 어려울 수 있으므로 항상 전체 기능을 사용하려는 사람에게 적합합니다.
중앙 구조는 다음 경우에 적합합니다.
-
서브이벤트 단계 수행 순서가 변경될 가능성이 높은 경우
-
새 서브이벤트 단계를 삽입하려는 경우
-
기능 파트를 별도의 부분으로 재사용가능하게 유지하려는 경우
|