Collaboration Diagram

컬레버레이션 다이어그램은 객체 간 동적 협력 관계를 정의한 다이어그램입니다. 즉, 하나의 유즈케이스를 실현하기 위해서 어떤 객체가 참여해야 하고, 그 객체 간에 어떤 순서로 상호 협력해야 하는지를 정의한 모델입니다. UML에서는 컬레버레이션 다이어그램과 시퀀스 다이어그램을 합쳐서 Interaction Diagram이라고 부릅니다. 두 다이어그램은 용도가 같습니다. 모델링하는 방식만 약간 다를 뿐입니다. 컬레버레이션 다이어그램은 객체간 상호작용을 정의하는데 대한 공간적 제한이 없기 때문에 구조적 측면을 더 중시한다고 할 수 있습니다. 자, 그럼 컬레버레이션 다이어그램에 대한 학습을 시작해 볼까요 ?

 

1. 개요

 

UML의 Interaction Diagram은 객체와 객체 사이의 동적 상호관계를 모델링하는 것을 정의하고 있는데 그 종류로는 컬레버레이션 다이어그램과 시퀀스 다이어그램이 있습니다.

컬레버레이션 다이어그램은 "해결해야 할 문제가 주어진 상황에서 그 문제를 해결하기 위해 필요한 객체를 정의하고, 객체간의 동적인 상호관계를 순서에 따라 정의함으로써 주어진 문제를 해결하는 모델"입니다. 특히 모델링하는 공간이 자유롭기 때문에 같은 유형의 객체를 모아 놓을 수 있고, 따라서 구조적인 측면을 중시하여 모델링 할 수 있습니다.

 

컬레버레이션 다이어그램과 시퀀스 다이어그램은 같은 목적과 용도로 가지고 있지만, 표기법은 다른 다이어그램입니다.그래서 대부분의 CASE 도구에서는 두 다이어그램 상호간 자동 변환할 수 있는 기능을 제공합니다. 컬레버레이션 다이어그램을 작성하는 목적은 다음과 같습니다. 객체 간의 동적 상호작용을 구조적 측면을 중시하여 모델링 합니다. 객체지향은 객체가 할 수 있는 일이 제한되어 있기 때문에 객체간 긴밀한 상호작용을 통해 주어진 문제를 해결하는 방식입니다. 이를 위해 주어진 문제를 해결하기 위해 어떤 객체가 참여하고 어떻게 상호작용 하는지를 정의해야 합니다. 컬레버레이션 다이어그램은 시퀀스 다이어그램과 달리 다이어그램 평면을 자유롭게 사용할 수 있기 때문에 객체간 상호작용을 구조적인 관점에서 정의하는데 유용합니다. 객체 간 상호작용을 정의하는 과정에서 객체를 더욱 상세하게 정의합니다. 시퀀스 다이어그램과 마찬가지로 객체간 상호작용을 정의하는 과정에서 객체들이 가져야 하는 오퍼레이션과 속성을 구체적으로 정의할 수 있습니다. 객체간 상호작용을 정밀하게 정의함으로써 객체간에 분담해야 하는 책임이 더욱 상세하게 정해집니다. 객체의 책임은 오퍼레이션으로 구현됩니다. 또한 이 행위를 위해 필요한 객체의 속성도 정의되어야 합니다. 유즈케이스를 실현(Realization)합니다. 프로젝트 초기에 정의된 유즈케이스는 프로그램으로 의해 구현되기 전에 컬레버레이션 다이어그램 등으로 설계되어야 합니다. 유즈케이스 별로 컬레버레이션 다이어그램이 작성됩니다. 유즈케이스에 필요한 객체가 주인공으로 등장하고, 객체간의 메시지를 통해서 유즈케이스의 기능이 실현 됩니다. 프로그래밍 사양을 정의합니다. 상세화된 컬레버레이션 다이어그램은 곧바로 프로그래밍될 수 있는 수준으로 정의되어야 합니다. 이렇게 정의된 컬레버레이션 다이어그램은 훌륭한 프로그램 사양이 됩니다.

컬레버레이션 다이어그램을 작성하는 시기는 유즈케이스 다이어그램이 정의된 후부터 프로그램 코딩을 하기 전까지로 시퀀스 다이어그램과 동일합니다. 역시 컬레버레이션 다이어그램도 다른 다이어그램처럼 여러 번에 걸쳐 정제되는 과정을 거칩니다. 분석 단계에서는 비즈니스 관점에서의 객체가 등장하지만, 설계 단계에서는 구현 관점의 객체들이 등장합니다. 그리고 컬레버레이션 다이어그램을 작성하기 위한 준비물 및 선행과정이 있어야 하는데,그것은 유즈케이스 다이어그램이 작성되어야 한다는 것입니다.

  2. 구성요소

 

컬레버레이션 다이어그램은 액터, 객체, 메시지, 링크 등으로 구성되어 있는데, 다음 그림을 보며 자세히 살펴봅시다. Things : 액터(Actor), 객체(Object) Relationships : 메시지(Massage), 링크(Link)

액터의 표기 액터는 사람 모양의 그림입니다. 작대기로 만든 사람이라는 의미로 "스틱맨"이라는 애칭으로 부르며, 이것은 클래스의 일종입니다. 그리고 스틱맨의 아래에 액터의 이름을 명사로 표시합니다. 액터의 정의 액터는 시스템의 외부에 존재하면서 시스템과 교류 혹은 상호작용(interaction)하는 것입니다. 자신에 대해 시스템이 서비스를 해주기를 요청하는 존재들이자, 시스템이 정보를 제공하는 대상이기도 합니다. 그리고 시스템의 일부가 아니라 외부에 독립적으로 존재합니다. 이것은 또한 시퀀스 다이어그램을 시작하게 하는 역할을 하고, 유즈케이스 다이어그램에서 액터와 유즈케이스 간의 communicates 관계는 시퀀스 다이어그램에서 객체에 다수의 메시지를 보내는 형태로 상세화됩니다. 액터의 예

객체의 표기 다음 표기 예들을 살펴보면, 객체는 사각형 모양으로 표기한다는 것을 알 수 있습니다. 표기 예 의미 홍길동:사원 : 사원 클래스의 객체중 홍길동을 의미 홍길동 : 홍길동 객체 (클래스는 아직 정의되지 않았음) :사원 : 사원 클래스의 일반객체 (일반적인 객체를 지칭) 홍길동:사원 사번=16009 이름=홍길동 급여=4000 성별=남 직위=과장 : 사원 클래스의 홍길동 객체 (객체 속성을 모두 표현) 객체의 정의 객체는 클래스의 인스턴스이며, 시스템에서는 해당 클래스 타입으로 선언된 변수의 형태로 존재합니다. 그 예와 해설은 다음과 같습니다. 예 Class 사원 홍길동; 해설 사원 클래스의 객체로서 홍길동이 선언되었습니다. 그리고 객체는 생성되고 소멸되기까지의 생명주기 동안 다양한 상태의 변화를 겪습니다. 객체의 예 객체의 예는 다음과 같습니다. 사과 : 과일 헬리콥터 : 운송수단 계약자 : 고객

메시지는 객체지향 패러다임에서 객체와 객체가 통신하는 유일한 수단입니다. 객체지향에서 필수적인 객체간 협력작업이 가능하기 위해서는 객체들은 서로 메시지를 통해서 상호작용을 해야 합니다. 이러한 메시지는 다양한 종류로 존재합니다. 그리고 메시지는 향후 클래스의 오퍼레이션으로 구현됩니다. 메시지의 종류는 다음과 같습니다. Flat flow of control 가장 일반적인 메시지 형태로, 객체에 메시지를 연결할 때 사용하며, 열린 화살표가 한쪽에 붙은 실선으로 표기합니다. Nested flow of control procedural call과 같은 의미로 사용되며 메시지가 중첩(nested)되는 경우에는 내부 메시지의 결과가 모두 돌아와야 가장 처음 시작한 메시지의 결과가 되돌려지게 됩니다. 메시지의 결과가 돌려지게 될때까지 다음 처리를 진행하지 않는 Synchronous 메시지입니다. 그리고 닫힌 화살표가 한쪽에 붙은 실선으로 표기합니다. Asynchronous flow of control 객체가 보낸 메시지의 결과를 기다리지 않고 다음 처리를 진행할 경우에 사용하며, 위쪽의 반쪽 화살표가 붙은 실선으로 표기합니다. Return flow 메시지를 처리한 결과(return)를 의미하며, 꼭 필요한 경우에 표현합니다. 그리고 화살표가 달린 점선으로 표기합니다.

링크는 객체와 객체간의 연관관계를 나타냅니다. 그러면 링크의 표기와 정의에 대하여 알아보겠습니다. 링크의 표기 객체와 객체사이를 연결한 것으로 화살표가 붙지 않은 실선으로 표기합니다. 링크의 정의 링크는 객체와 객체간의 양방향 연관관계(Association)를 의미합니다. 객체간에 서로 통신을 하기 위해서는 link로 연결되어 있어야 합니다. Message는 link를 따라 움직인다고 표현합니다. 링크에는 이름을 붙일 수 있습니다.

다음은 어느 음식점의 요리주문에 대한 컬레버레이션 다이어그램의 간단한 사례입니다. 이 컬레버레이션 다이어그램을 보고, 다이어그램의 각 부분이 의미하는 바를 해석하여 보세요.

	이 기능은 세 액터가 사용합니다.
	손님이 메뉴판을 보고 메뉴를 고릅니다. 손님이 웨이터에게 메뉴를 정해 알려줍니다. 웨이터는 주문된 요리를 입력합니다. 주방장이 요리예약을 조회합니다. 주방장이 요리를 제작합니다.

 

다음의 컬레버레이션 다이어그램은 "사원정보 등록"이라는 유즈케이스에 대한 것입니다. 이 다이어그램을 본 후 문제를 해결하여 봅시다.

SW설계 관점에서 Boundary 클래스(인사기본정보 From)와 Control 클래스
(사원 Manager)가 추가되었음을 알 수 있습니다.

 

실제 현실에서 경험할 수 있는 사례를 가지고 모델링을 수행한 결과를 살펴보도록 하겠습니다. 아래에 기술된 문제영역은 모델링의 대상이 되는 주제와 이것과 관련된 주변정보를 제공합니다. 이 문제영역을 분석하여 컬레보레이션 다이어그램을 작성해 보세요. 그런 다음, 다이어그램 보기 버튼을 클릭하여 컬레보레이션 다이어그램과 비교해 보시기 바랍니다. A병원은 이번 기회에 SW 시스템을 구축하여 업무의 일부를 자동화 하기를 원합니다. A병원에는 기존시스템으로 병원의 수입과 지출을 관리하는 "회계시스템"이 운영되고 있습니다. 이 시스템과 연계하면서 병원정보, 환자의 병력 및 진료정보, 의료진 정보의 각종 정보관리와 진료예약 처리 및 수납 지원을 수행하는 신규 시스템을 구축하기를 원하고 있으며, 병원의 각 관계자는 시스템을 통해 아래와 같은 기능을 수행하기를 원합니다. 진료비는 진료정보를 입력하면 자동 산정됩니다. 환자는 직접 진료예약을 하고, 환자의 과거병력과 진료정보는 관리됩니다. 일반사용자는 병원 정보와 의료진 정보를 조회하고 상담 및 문의를 할 수 있습니다. 의료진은 자신의 진료스케쥴을 자동 생성하고, 진료 내역을 관리하고, 환자 정보를 조회하기를 원합니다. 원무과 직원은 이 시스템을 통해 진료비 청구서를 조회,발행하고, 진료예약을 확정하기를 원합니다. 본 진료시스템의 유즈케이스 중 하나는 진료예약입니다. 진료예약에 대해 생각해 보고 그 결과를 바탕으로 시퀀스 다이어그램을 작성해 보십시오.(위 문제영역 설명에서 제시되지 않은 구체적인 상황은 각자 일반적 병원 상황을 상상하며 설정해 보시기 바랍니다.)

	아래 다이어그램에서는 여러분의 이해를 돕기 위해 한글로 클래스 명과 메시지 명을 정의하였습니다. 실제로 설계할 경우에는 상세 설계에서는 모든 명칭이 영문으로 정의됩니다. 왜냐하면 프로그램으로 쉽게 구현할 수 있기 때문입니다. 그리고 상세 설계에서는 실제 구현할 로직을 머릿속에 그리면서 최대한 자세한 메시지가 나타나도록 정의해야 합니다

 

  4. 작성단계 및 유의사항

 

먼저, 컬레버레이션 다이어그램의 작성순서를 알아보겠습니다.

작성 대상을 선정합니다. 유즈케이스 다이어그램을 이용하여 컬레버레이션 다이어그램의 작성대상을 선정한 후, 하나의 유즈케이스를 선택하고, 유즈케이스 정의서를 분석합니다. 유즈케이스의 액터을 파악하여 컬레버레이션 다이어그램에 위치시킵니다. 액터가 둘 이상일 경우라도 모두 좌측부터 액터를 위치시켜야 합니다. 순서는 중요하지 않습니다만, 메시지 선이 적게 교차하도록 배치시키는 것이 좋습니다. 유즈케이스를 실현하기 위해 참여할 클래스(객체)들을 정해 컬레버레이션 다이어그램에 위치시킵니다. 정의된 클래스 중에 유즈케이스의 처리에 참여하는 것들을 식별하고 컬레버레이션 다이어그램에 위치시켜야 하지만 순서는 중요하지 않습니다. 시간 순서를 감안하여 객체간 메시지를 정의해 나갑니다. 유즈케이스를 실현하기 위해 필요한 객체들 간의 메시지를 정의하되, 시간 순서에 유의하도록 합니다. (시간흐름은 위에서 아래로) 필요한 객체를 추가로 정의합니다. 요구된 처리를 위해 필요하지만 아직 정의되지 않은 객체를 새로 정의하여 컬레버레이션 다이어그램에 추가해 나갑니다. 또 이렇게 추가된 객체 사이의 메시지도 정의하여 추가합니다.

다음은 컬레버레이션 다이어그램 작성 시 주의사항입니다. 컬레버레이션 다이어그램은 유즈케이스별로 하나씩 작성합니다. 경우에 따라서 하나의 유즈케이스를 여러 개의 컬레버레이션 다이어그램으로, 또는 여러 유즈케이스에서 공통으로 사용하는 상호작용을 하나의 컬레버레이션 다이어그램으로 작성할 수도 있지만 다음과 같은 사항을 고려하여 작성합니다. 동일한 상호작용을 여러 컬레버레이션 다이어그램에서 중복되게 작성하는 것을 피합니다. 중복을 취소화 시키기 위해서, UI별 컬레버레이션 다이어그램을 작성해도 됩니다. 컬레버레이션 다이어그램의 가독성이 좋도록 적당한 코멘트(comment)를 사용하여야 합니다. 컬레버레이션 다이어그램상에서 메시지의 흐름은 액터로부터 시작되게 작성합니다. 클래스 다이어그램에 표기된 클래스 명과 매핑 가능하도록 객체 이름을 표기하여야 합니다. 즉, 컬레버레이션 다이어그램에 나타나는 객체는 클래스 다이어그램에서 정의된 클래스와 매핑이 가능해야 합니다.