UML 다이어그램 (구조6,행위7)

UML 다이어그램 (구조6,행위7)

다이어그램은 사물과 관계를 도형으로 표현

만약 여러분이 큰 돈이 오고 가는 대규모 프로젝트를 진행한다고 했을 때, 설계도 하지 않은 채 개발을 시작하게 된다면 어떨까요? 개발 하다가 오류가 생길 수도 있고, 프로그램 구조도 바꿀 수도 있으며 오류에 헤매게 됩니다.

그렇게 된다면 시간은 줄어들고 개발을 하면 할수록 엉망이 됩니다. 또한 고객의 요구사항을 담지 않은 엉뚱한 걸 만들 수도 있고 코드가 엉망이라 유지보수 또한 힘들어집니다. 이러면 진행하고 있는 프로젝트를 날리는 상황이 생기겠죠.

개발은 사람이 하는 것이기 때문에 설계 없이 무작정 개발에 들어가면 위와 같이 프로젝트를 실패할 확률이 높습니다. 이러한 설계에 쓰이는 게 UML 다이어그램입니다.

UML 다이어그램

UML은 Unified Modeling Language의 약자로 시스템 분석가, 의뢰인, 프로그래머 등 개발 과정에 참여한 모든 사람들이 각자의 시점에서 이해할 수 있는 다방면의 설계도를 그릴 수 있는 표준과 시스템을 여러가지 시각에서 볼 수 있는 뷰를 제공합니다. UM은 프로그램을 단순화 시켜 표현하여 의사소통 하기 좋고 대규모 프로젝트 구조의 로드맵을 만들거나 개발하기 위한 시스템 구축에 기본을 마련합니다.

UML 다이어그램은 13가지로 다양합니다.

각각의 UML 다이어그램은 나타낼 시스템을 하나로 보여줄 수 있는 수단을 제공해야 하는데요. 각자가 만드는 시스템이 다르듯이 원하는 것도 각자 다르기 때문에 모든 참여자를 만족 시키기 위해서 종류가 많습니다.

클래스 다이어그램

시스템을 구성하는 클래스들 간의 관계를 나타낸 다이어그램입니다. 클래스들 간의 존재하는 정적인 관계를 다양한 방식으로 표현하는데요. 객체 지향 시스템 모델링에서 가장 공통적으로 많이 쓰이는 다이어그램이며 바로 프로그램 코드로 변환 가능하다는 장점이 있습니다.

클래스 다이어그램은 위와 같이 표현합니다. 클래스의 고유한 이름을 나타내는 클래스 이름, 클래스의 데이터를 나타내는 특성 및 속성, 클래스의 행위적 특징을 나타내는 메소드로 구성되어 있습니다.

객체 다이어그램(object diagram)은 

통합 모델링 언어(UML)에서 특정 시간에 모델링된 시스템의 구조를 부분적으로나 전체적으로 보여주는 다이어그램이다.

객체 다이어그램과 클래스 다이어그램을 서로 밀접한 관련이 있으며 거의 유사한 노테이션을 사용한다. 이 두 다이어그램 모두 시스템의 정적인 구조를 시각화하기 위해 사용된다. 클래스 다이어그램이 클래스를 보여주는 반면 객체 다이어그램은 클래스의 인스턴스를 표시한다. 객체 다이어그램은 클래스 다이어그램보다 더 구체적이다.

UML에서 오브젝트 다이어그램은 인스턴스 간의 관계 및 시스템의 인스턴스 스냅샷을 제공합니다. 클래스 다이어그램의 모델 요소를 인스턴스화해서 현재 시스템의 동작을 탐색할 수 있습니다.

오브젝트 다이어그램은 모델의 클래스류 인스턴스를 표시하는 UML 구조적 다이어그램입니다. 오브젝트 다이어그램은 클래스 다이어그램에 사용된 것과 유사한 표기법을 사용합니다. 그러나 클래스 다이어그램이 시스템의 실제 클래스류 및 관계를 표시하는 반면, 오브젝트 다이어그램은 현재 인스턴스 간의 링크 및 클래스류의 특정 인스턴스를 표시합니다. 클래스, 배치, 컴포넌트 및 유스 케이스 다이어그램의 클래스류를 인스턴스화해서 오브젝트 다이어그램을 작성할 수 있습니다.

다음 그림은 연관으로 연결된 두 개의 클래스로 구성되는 단순 클래스 다이어그램을 보여줍니다.

다음 그림은 링크 관계로 연결된 두 개의 인스턴스 스펙으로 이루어진 해당 오브젝트 다이어그램을 보여줍니다.

오브젝트 다이어그램은 다음 경우에 유용합니다.

  • 프로젝트의 분석 단계(phase) 중 클래스 다이어그램을 작성하여 시스템의 구조를 설명한 다음 오브젝트 다이어그램 세트를 테스트 케이스로 작성하여 클래스 다이어그램의 정확성과 완성도를 확인할 수 있습니다.
  • 클래스 다이어그램을 작성하기 전에 오브젝트 다이어그램을 작성하여 특정 모델 요소와 링크에 대한 사실을 발견하거나 필요한 특정 클래스류 예제를 설명할 수 있습니다.

다음 주제는 오브젝트 다이어그램의 요소에 대해 설명합니다.

  • UML의 인스턴스 스펙
    UML 모델에서 인스턴스 스펙은 모델링된 시스템의 인스턴스를 나타내는 요소입니다. 모델에서 클래스류를 인스턴스화할 때 작성하는 인스턴스 스펙은 엔티티의 스냅샷과 유사하게 현재 모델링된 시스템의 엔티티를 나타냅니다. 각 스냅샷에 하나씩, 여러 인스턴스 스펙을 작성해서 시간에 따른 엔티티 변경사항을 모델링할 수 있습니다.
  • UML의 링크 관계
    UML에서 링크 관계는 연관 또는 통신 경로의 인스턴스입니다. 연관이 두 클래스류 간의 관계인 반면, 링크는 클래스류나 노드의 인스턴스 또는 오브젝트 간 관계입니다.
  • 종속 관계
    UML에서 종속 관계는 한 요소인 클라이언트가 다른 요소인 공급자를 사용하거나 이에 의존하는 관계입니다. 클래스 다이어그램, 컴포넌트 다이어그램, 배치 다이어그램 및 유스 케이스 다이어그램에서 종속 관계를 사용하여 공급자를 변경하려면 클라이언트를 변경해야 함을 표시할 수 있습니다.
  • 배치 관계
    UML에서 배치 관계는 특정 노드 유형이 아티팩트 유형의 배치를 지원함을 지정합니다.

UML에서 오브젝트 다이어그램은 현재 인스턴스 간의 관계 및 시스템의 클래스류 인스턴스를 모델링합니다. 오브젝트 다이어그램을 사용하여 동작 시나리오를 탐색하거나, 오브젝트의 샘플 구성을 설명하거나, 클래스 다이어그램을 테스트해서 규칙과 정의를 확인할 수 있습니다.

  • 오브젝트 다이어그램 작성
    UML 모델에 존재하는 클래스류를 인스턴스화해서 오브젝트 다이어그램을 작성하거나, 새 오브젝트 다이어그램을 작성한 다음 필요한 인스턴스를 추가할 수 있습니다. 오브젝트 다이어그램에 인스턴스화할 수 있는 UML 요소를 추가할 수 있습니다.
  • 오브젝트 다이어그램의 슬롯에 값 추가
    오브젝트 다이어그램에서 인스턴스 스펙의 슬롯에 대한 특정 값을 정의할 수 있습니다. 각 슬롯은 인스턴스화되는 클래스류의 속성이나 기능으로 맵핑됩니다.
  • 오브젝트 다이어그램 작성
    UML 모델에 존재하는 클래스류를 인스턴스화해서 오브젝트 다이어그램을 작성하거나, 새 오브젝트 다이어그램을 작성한 다음 필요한 인스턴스를 추가할 수 있습니다. 오브젝트 다이어그램에 인스턴스화할 수 있는 UML 요소를 추가할 수 있습니다.
  • 오브젝트 다이어그램의 슬롯에 값 추가
    오브젝트 다이어그램에서 인스턴스 스펙의 슬롯에 대한 특정 값을 정의할 수 있습니다. 각 슬롯은 인스턴스화되는 클래스류의 속성이나 기능으로 맵핑됩니다.

컴포넌트 다이어그램

(component diagram)은 어떻게 컴포넌트들이 서로 선으로 연결되어 더 큰 컴포넌트나 소프트웨어 시스템을 구성하는지를 보여준다. 복잡한 시스템 구조를 묘사하기 위해 사용된다.

컴포넌트는 “component”라는 키워드가 있는 직사각형이나 상단 오른쪽 모퉁이에 별도 표기하여 표현된다.

배치(배포)다이어그램

구성하는 HW 자원 간의 연결 관계를 표현하고,HW 자원에 대한 SW 컴포넌트의 배치 상태를 표현한 다이어그램.배치 다이어그램은 시스템의 설계 단계의 ‘마지막’에 작성된다.즉, 모든 설계가 거의 마무리되어 SW 컴포넌트가 정의되고,시스템의 HW 사양도 확정된 후 배치 다이어그램이 작성된다.(항상 그런 것은 아니고 상황에 따라 변경 될 수 있다.)

결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현한다.
노드와 의사소통(통신) 경로로 표현한다.
구현단계에서 사용되는 다이어그램이다.

복합체구조 다이어그램

클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현한다.

통합 모델링 언어(UML)에서 컴포넌트 다이어그램(component diagram)은 어떻게 컴포넌트들이 서로 선으로 연결되어 더 큰 컴포넌트나 소프트웨어 시스템을 구성하는지를 보여준다. 복잡한 시스템 구조를 묘사하기 위해 사용된다.

컴포넌트는 “component”라는 키워드가 있는 직사각형이나 상단 오른쪽 모퉁이에 별도 표기하여 표현된다

패키지 다이어그램

UML 에서 패키지는 어떤 구성요소라도 더 높은 수준의 단위로 묶을 수 있도록 해주는 구조이다. 각각의 패키지는 네임스페이스를 나타내는데, 이는 모든 클래스가 자신이 속한 패키지내에서 유일해야 한다는 소리이다. 어떤 클래스가 어디에 속하는지를 완벽하게 알기 위해서는 완전한 이름(fully qualified name)을 사용해야 한다. UML 에서 패키지 이름을 나타낼때에는 :: 을 사용한다. Date는 System::Date 와 같이 될 것이다.


– 패키지와 의존

규모가 큰 시스템에서는 패키지 다이어그램을 보아야 그 시스템의 구조를 제어할 수 있다. 패키지 다이어그램은 패키지간의 의존을 보여준다. A 패키지안의 어떤 클래스가 B 패키지의 어떤 클래스에 의존한다면, A는 B 에 의존을 가지고 있는 것이다.

위의 다이어그램은 의존의 흐름이 명확하다고 할 수 있다. 보통은 모든 의존이 한 방향으로 흐를 때에 명확하다고 생각할 수 있다. 사실 좀 모호한 표현이다. 책에서는 여기까지 말하며 자세한 얘기는 하지 않는다. 사실 위에 불안정성 I 값은 책에 나오지는 않고 내가 계산한것인데, 왜 이게 좋은 패키지 의존인지 로버트 C.마틴의 클린아키텍처를 근거로 생각해보면 아래와 같은 이유일것이다.

클래스레벨에서는 객체 지향 설계의 5대 원칙 – SOLID, 더 높은 수준의 컴포넌트 레벨에서는 ADP, SDP, SAP 원칙이 있다. 위의 다이어그램을 컴포넌트 설계원칙에서 생각해보면 사이클이 없으며(ADP), 불안정성 I 의 값이 항상 높은값에서 낮은 값에 의존하고(SDP), 시스템의 업무규칙인 도메인은 불안정성 I가 낮으므로 안정된 정도 만큼 추상화 된 컴포넌트이기 때문에(SAP) 좋은 패키지구조라고 얘기하고 있다고 생각한다.

위에서 얘기한 의존성에 관심이 있다면 ADP(ocwokocw.tistory.com/36), SDP(ocwokocw.tistory.com/37), SAP(ocwokocw.tistory.com/38) 를 참조하면 더 자세한 내용을 알 수 있다. 


– <<global>>

만약 어떤 패키지가 너무 많은 곳에서 쓰이고 있어서 의존을 표시할 경우 패키지 다이어그램을 보기가 힘들어진다면, 이런 경우에는 해당 패키지에 아래와 같이 <<global>> 키워드를 붙인다. StarUML 에서는 패키지에 global 스테레오타입을 지원하고 있지 않으니 그냥 global 쓰면 되겠다.


– 패키지를 바라보는 시각

위에서 나타낸 임대, 자산 관련 패키지 다이어그램을 살펴보면 도메인과 계층의 2가지 측면으로 바라볼 수 있다. 도메인 측면에서는 임대와 자산관련으로 나눌 수 있고, 계층의 측면에서는 프리젠테이션, 도메인, 데이터 매퍼, 데이터베이스로 나눌 수 있다.

위 다이어그램은 측면에 따라 나눈 것이기 때문에 진짜 패키지는 아니다. 이런 표기방식은 UML 다이어그램의 표준은 아니지만 프로젝트 구조를 이해하는데 매우 편리하다.

-상태 기계 다이어그램(State Machine Diagrams)

상태 기계 다이어그램은 시스템의 행동을 기술한다. 객체 지향 접근법에서 단일 객체가 활성인 시간동안 어떤 행동을 하는지 나타내기 위해서 단일 클래스에 대해 그리는 다이어그램이다. 아래와 같은 시나리오에 대해 해보자.

금고 자물쇠를 보려면 비밀 양초를 촛대에서 옮겨야 한다. 그리고 문이 닫혀있어야만 자물쇠가 나타난다. 일단 자물쇠가 나타나면 금고를 열기 위해서 열쇠를 꽂는다. 추가적인 안전장치로, 양초를 다시 그 자리에 놓아야만 금고를 열 수가 있다. 만약 도둑이 이 경고를 무시하면 괴물을 풀어서 도둑을 잡아먹도록 한다.

각 문장 단위로 이해하기에는 큰 어려움이 없으나, 어떤 이벤트가 일어났을 때 어떤 상태가 되는지 전체적인 상황이 한눈에 그려지지가 않는다. 혹시 머리가 좋은 사람이라면 가능할지라도, 그렇지 않은 다른 사람을 위해서라도 도식화된 형태가 필요할것이다. 이때 상태 기계 다이어그램이 필요하다.

상태 기계 다이어그램의 기본적인 구성요소에는 아래와 같은 것들이 있다.

  • 초기 의사 상태(initial pseudostate): 초기의 상태
  • 전이(transition): 한 상태에서 다른 상태로의 이동. 트리거-서명 [가드] / 액티비티 3 부분의 레이블로 구성되어있다.
  • 트리거-서명(trigger-signature): 상태 변화를 유발하는 이벤트
  • 가드(guard): 전이가 이루어지기 위한 Boolean 조건
  • 액티비티(activity): 전이 동안 수행되는 어떤 행동

상태 기계 다이어그램에 익숙하다면 시나리오만 보고 젤 밑에 그림처럼 그릴 수 있을지 모르겠지만, 나는 초보자라서 시나리오를 문장으로 나눈 뒤, 각 문장에서 트리거-서명, 가드, 액티비티를 추출하여 아래 다이어그램을 그렸다.

  1. 금고 자물쇠를 보려면 비밀 양초를 촛대에서 옮겨야 한다.
  2. 그리고 문이 닫혀있어야만 자물쇠가 나타난다.
  3. 일단 자물쇠가 나타나면 금고를 열기 위해서 열쇠를 꽂는다.
  4. 추가적인 안전장치로, 양초를 다시 그 자리에 놓아야만 금고를 열 수가 있다.
  5. 만약 도둑이 이 경고를 무시하면 괴물을 풀어서 도둑을 잡아먹도록 한다.

1번과 2번 문장에서 “비밀 양초를 촛대에서 옮긴다.”는 어떤 목적을 위한 이벤트(트리거)이다. “자물쇠가 나타난다.” 는 이벤트를 하면 수행되는 어떤 행동이(액티비티)이다. 그리고 “문이 닫혀있어야만”은 이에 대한 조건(가드)이다.

3번과 4번 문장에서 “열쇠를 꽂는다.” 는 금고를 열기 위한 이벤트(트리거)이다. “금고가 열린다.” 는 건 수행되는 행동(액티비티)이며, “양초를 다시 그 자리에 놓아야만”은 이에 대한 조건(가드)이다.

5번에서 “도둑이 이 경고를 무시하면”은 하나의 문장 같지만 사실 내포된 의미를 해석해야 한다. “열쇠를 꽂는다.” 의 이벤트(트리거)를 수행하는데 “양초를 그 자리에 놓지 않았다.” 인 조건(가드)하에서 수행된 결과 수행된 행동(액티비티)이 “괴물을 풀어서” 인것이다.

이를 트리거, 가드, 액티비티 목록으로 정리해보면 아래와 같다.

위의 트리거, 가드, 액티비티 목록을 기반으로 상태 기계 다이어그램으로 그리면 아래와 같다. 최종상태는 상태 기계가 끝난것이며, 컨트롤러 객체가 삭제되었다고 할수도 있다.

순차(시퀸스:sequence) 다이어그램

시퀸스 다이어그램이라고도 불리는 순차 다이어그램은 객체들끼리 주고 받는 메세지의 순서를 시간의 흐름에 따라 보여주는 다이어그램입니다. 일반적으로 화면 요구사항과 클래스 다이어그램 기반으로 작성됩니다.

순차 다이어그램의 특징은 아래와 같습니다.

  • 객체 간의 관계, 메시지의 시간적 순서 강조 표현
  • usecase 시나리오를 시간과 순서에 따라서 묘사 및 도식화
  • 복잡한 시나리오나 실시간 명세 표현, 메시지의 명시적인 순서 표현

순차 다이어그램은 이렇게 구성되어 있습니다.

메세지를 송수신하는 객체, 상호 작용에 참여하는 오브젝트인 라이프라인, 객체가 동작하고 있음을 표현하는 활성 박스와 서로 다른 객체 간의 상호 작용 혹은 의사소통을 정의하는 요소인 메세지로 표현됩니다.

유스케이스 다이어그램

다이어그램 중에서도 실제 프로젝트에 많이 사용되는 유스케이스는 시스템과 사용자의 상호작용을 다이어그램으로 표현한 것으로 사용자의 관점에서 시스템 서비스 혹은 기능 및 그와 관련한 외부 요소를 보여주는 다이어그램입니다. 사용자가 시스템 내부에 있는 기능 중에서 어떤 기능을 사용할 수 있는지 나타낼 수 있고 유스케이스 다이어그램을 사용함으로써 고객과 개발자가 요구사항에 대한 의견을 조율할 수 있습니다.

유스케이스는 시스템, 액터, 유스케이스, 관계로 이루어져 있습니다.

실제 제가 프로젝트에 사용했던 다이어그램 중 일부분인데요. 시스템은 만들고자 하는 프로그램으로 유스케이스들을 둘러싼 큰 사각형을 의미합니다. 액터는 시스템 외부에 있고 시스템과 상호작용하는 사람으로 원과 선으로 이루어진 사람 모양입니다. 유스케이스는 사용자 입장에서 바라본 시스템의 기능으로 타원으로 표시합니다. 유스케이스들을 연결한 선들은 관계를 뜻하며 액터와 유스케이스 사이의 의미있는 관계를 나타냅니다.

관계에는 액터와 유스케이스 간에 상호작용이 있을 때 표시하는 연관 관계, 포함 관계, 확장 관계, 일반화 관계가 있습니다.

통신 다이어그램

시퀸스 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데 메시지뿐만 아니라 객체들 간의 연관까지 표현한다.

UML 통신 다이어그램의 예제입니다.

활동(액티비티:activity) 다이어그램

액티비티 다이어 그램은 순차로직, 업무절차, 워크 플로우를 기술하는 방법이다. 플로우차트와 비슷하지만 액티비티 다이어그램은 병렬 행동을 지원한다.

액티비티 다이어그램은 위의 그림처럼 생겼다. 위에서 아래의 방향으로 차례차례 요소들을 살펴보자.

‘초기노드’ 액션에서 시작하여 주문 접수 액션을 수행한다. 초기노드액션은 시작점이 되며 액션은 액티비티 다이어그램의 아주 기본적인 요소이다.

주문접수 액션 수행 후 ‘포크’라는 것을 만난다. 포크는 이름에서 유추할 수 있듯이 하나의 들어오는 플로우와 여러개의 나가는 플로우로 이어져있다. 포크에서 나가는 플로우가 만나는 주문서 작성과 주문발송 액션간에는 순서없이 병렬로 수행가능함을 의미한다. 예를 들어 주문서 작성 -> 송장발송 -> 대금수령 -> 일반배송의 순으로 액션이 수행될수도 있고, 송장발송 -> 주문서 작성 -> 일반배송 -> 대금수령의 순으로 액션이 이루어질수도 있다.

주문종결전 ‘조인’ 액션이라는 것이 있다. 조인 액션으로 들어오는 여러 개의 플로우가 모두 완료되어야 그 다음 액션이 수행될 수 있음을 나타낸다. 배송이 먼저 끝났다면 대금 수령이 완료될때까지 주문 종결 액션을 수행할 수 없다.

‘결정’은 분기에 해당하는 로직이다. 결정에서 나가는 여러개의 플로우에 []로 표시된 부분은 boolean 조건으로 표시되는 가드이다. 결정은 여러개의 플로우중 하나만 선택될 수 있다. 예를 들어 긴급 주문이면 익일 배송을 하거나 그게 아니라면 일반 배송을 한다. 익일 배송과 일반 배송을 둘 다 수행할 수 없다. ‘병합’은 결정으로 시작된 플로우의 끝을 나타낸다. 조인과 달리 하나의 플로우만 들어오면 다음 단계로 수행 된다.

‘끝’은 이름 그대로 액티비티가 종료됨을 나타내는 액션이다.

상호작용개요(interaction overview) 다이어그램

상호작용 다이어그램은 오브젝트간에 주고받는 메시지의 교환을 모델화하는 것입니다.

이러한 상호작용 다이어그램은 2개의 다이어그램을 포함하는데, 시퀀스 다이어그램과 협력 다이어그램입니다.

2개의 다이어그램의 외형은 다르나 기본적인 기술방법은 같습니다.

실제로 몇몇 UML툴에서는 상호 다이어그램이 컨버팅 가능하도록 기능을 제공합니다.

<<시퀀스 다이어 그램>>

<<협력다이어그램>>

구성요소

오브젝트

“오브젝트:클래스명” 이라고 표기하며 오브젝트 다이어그램에서 사용되는 표기와 동일합니다.

메시지

어떤 오브젝트가 갖고 있는 메소드의 실행명령을 의미합니다. 메세지 포맷은 아래와 같습니다.

시퀀스번호[가드조건]*[반복조건] : 리턴값 리스트 := 메시지명(파라미터 리스트)

메시지 예 : [a==b] method(“hello”, 5)

메시지는 화살표로 표현하며, 화살표 끝부분이 꽉차있으면 동기통신,

화살표 끝부분이 비어있는 단순 선으로 그려져 있으면 비동기통신을 의미합니다.

시퀀스번호

메세지의 순서를 나타내는 번호

가드조건

메시지를 송신하기 위한 조건. 즉 가드조건이 성립할때 메세지가 송신됩니다.

링크

메시지가 교환되는 오브젝트들을 연결하는 것으로 협력 다이어그램만 그립니다.

리턴

메시지가 종료한 것을 나타내며 시퀀스 다이어그램만 그립니다.

필수 표기는 아니며 리턴값을 명시하고 싶을때 사용합니다.

라이프라인

오브젝트의 생존기간을 나타냅니다. 즉 라이프라인이 설정되어 있으면 오브젝트는 메모리에 존재하는 것입니다.

활성구간

“제어 포커스”라고 부르며 오브젝트가 활동하고 있는 것을 나타냅니다.

활성구간은 겹칠 수 있습니다.

상호작용 다이어그램의 사용처

오브젝트를 추출할때

구조를 나타내는 모델이 없을 경우 상호작용 다이어그램을 만든다는 것은 오브젝트를 자유롭게 만들어 나간다는 의미입니다.

이러한 상호작용 다이어그램을 구현하고자 하는 모든 시나리오에 적용하면 필요한 오브젝트를 모두 열거할 수 있습니다.

이런경우 상호작용 다이어그램 중에서 협력다이어그램을 사용하는 것이 좋습니다.

로직 확인할때

상호작용 다이어그램을 사용하면 1개의 시나리오의 구현과 로직을 한눈에 보기에 좋습니다.

클래스 다이어그램을 확인할때

이미 구조적 모델, 특히 클래스 다이어그램이 있을 경우 상호작용 다이어그램을 통해

해당 클래스 다이어그램이 시스템의 요구사항을 제대로 만족시키는지 확인 할 수 있습니다.

책무 밸런스를 확인할때

클래스 다이어그램에서도 알 수 있지만 보다 알기 쉬운 것은 상호작용 다이어그램을 사용하여 확인하는 것입니다.

혹시 책무가 특정 클래스에 집중되는지를 확인하여 균형있게 배치되도록 수정할 수  있도록 도와줍니다.

주의사항

시나리오를 분명히 한다.

시나리오 없이 머릿속의 생각만으로 그리면 무엇을 만족하는 다이어그램이 완성되는지 명확하지 않습니다.

그래서 반드시 시나리오를 준비해야 합니다.

1다이어그램 1시나리오

상호작용 다이어그램은 1개의 다이어그램이 1개의 시나리오에 대응하는 것이 기본입니다.

긴 시나리오는 다이어그램을 분할한다.

시나리오가 길 경우 시퀀스 다이어그램을 분할해서 그리는 편이 이해가기 쉽습니다.

메시지명은 받는 측의 관점에서 붙인다.

메시지명은 받는 측의 관점에서 붙이는 것을 권장합니다.

사실 그다지 이상할 것은 없으나 클래스 다이어그램을 만들어 보면 어느 쪽이 나은지는 알 수 있습니다.

모르는 오브젝트에 메시지를 보내지 않는다.

오브젝트간의 상호작용을 구현할 때 메시지를 보내려면 메시지를 보내기 전에

보내는 측 오브젝트는 받는 측 오브젝트를 어떠한 방법으로든 알고 있어야 합니다.

생성과 소멸을 의식한다.

오브젝트의 생성/소멸을 의식하지 않고 그리면 실제 코드 구현시 메시지를 보냈는데 오브젝트가 미생성이든가

혹은 이미 소멸했거나 또는 소멸해야하는 오브젝트가 남아 메모리 부족이 일어나는 등 문제가 발생할 수 있습니다.

상호작용에 참가하지 않는 오브젝트는 그리지 않는다.

협력 다이어그램을 그리기 전에 오브젝트 다이어그램을 만들었다면 자기도 모르는 사이에

상호작용에 참여하지 않는 오브젝트를 그리게 되는 경우가 있습니다.

오브젝트명을 붙인다.

오브젝트에 제대로 이름을 붙이는 습관을 갖는 것이 중요합니다.

오브젝트명으로 역할명을 붙이거나 리턴값명과 오브젝트명을 붙이면 식별하기가 쉽습니다.

파라미터도 쓴다.

메시지명만 쓰고 파라미터 쓰는 것을 잊어버리기 쉽습니다.

파라미터를 제대로 써 놓으면 데이터가 어떻게 전달되는지 알 수 있고, 메시지의 의미도 보다 알기 쉽기 때문에

가능하면 메시지에 파라미터도 추가하는 것이 좋습니다.

레이아웃을 고안한다.

협력 다이어그램을 그릴때 주의사항입니다.

클래스 다이어그램과 비교할 경우가 많기 때문에 클래스 다이어그램의 레이아웃과 비슷하게 배치하면 비교하기가 쉽습니다.

상세함에 주의한다.

상호작용 다이어그램은 아주 상세하게 그릴 수 있는 다이어그램입니다.

따라서 작성자가 어디까지 요구하고 있는지를 이해하고 있어야 합니다.

타이밍 다이어그램

객체 상태 변화와 시간 제약을 명시적으로 표현한다.

타이밍 다이어그램

->UML 2.0의 타이밍 다이어그램에서 이러한 시간을 다루기 위해 사용한다. 한 상태에서 객체가 얼마나 오랜 시간을 지체하는지를 명시한다.

Start typing and press Enter to search

Shopping Cart