다이어그램의 종류
1. UML이란
통합 모델링 언어(UML, Unified Modeling Language)는 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어이다. 이 표준은 UML을 고안한 객체 관리 그룹에서 관리하고 있다.
객체 지향 프로그래밍 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용한다.
2. 다이어그램의 종류
다이어그램의 종류는 많지만 보통 개발 업무에서는 9가지를 보고 있다.
1) 클래스 다이어그램 (Class Diagram)
클래스 다이어그램의 경우 시스템 내부에 존재하는 클래스들을 선별하여 나타내고 각 클래스의 속성(Attribute)과 행위(Behavior)를 기재한다. 여기서 클래스들 사이에 여러 가지 관계(Relationship)를 맺을 수 있다.
예를 들어 연관관계(Association)는 클래스와 클래스가 어떠한 연관이 있음을 나타내고 여기서 세부적으로 복합연관(Composition)과 집합 연관관계 (Aggregation) 등으로 나누어질 수 있다. 이외에 상속관계(Generalization), 의존관계(Dependency)가 나타날 수 있다.
클래스 다이어그램을 그리고자 할 때 항상 추상화 단계를 고려하여서 그리도록 하여야 할 것이다. 추상화의 단계가 높은 경우 대충의 속성과 행위를 기재하고 대충의 관계를 기재하여도 충분할 것이다.
이 단계에서 너무 상세한 내용을 찾고 기재하다 보면 클래스 다이어그램 내부에서 구현의 단계에서 이루어져야 할 일이 이루어지는 오류를 범하게 된다. 이러한 오류는 실제 구현 단계에서 커다란 위험의 요소를 내재하게 된다.
2) 시퀸스 다이어그램 (Sequence Diagram)
시퀸스 다이어그램은 콜라보레이션 다이어그램과 함께 시스템의 동적인 면을 나타내는 대표적인 다이어그램이다. 시스템이 실행 시 생성되고 소멸하는 객체를 표기하고 객체들 사이에 주고받는 메시지를 나타내게 된다.
콜라보레이션 다이어그램 또한 메시지의 흐름을 나타내지만 시퀸스 다이어그램만의 특징이라면 가로축을 시간 축으로 하여 시간의 흐름을 나타내어 메시지의 순서에 역점을 두고 있다.
3) 콜라보레이션 다이어그램 (Collaboration Diagram)
콜라보레이션 다이어그램 또한 시퀸스 다이어그램과 함께 메시지의 흐름을 나타낸다. 하지만 콜라보레이션 다어그램은 객체와 객체들 사이의 관계 또한 표기하게 된다. 실제 UML에서 클래스의 인스턴스인 객체를 표기하는 다이어그램이 명시적으로 존재하지 않는다.
이러한 객체들 사이의 관계를 나타내기 위해 별도로 오브젝트 다이어그램(Object Diagram)을 사용하여도 되지만 오브젝트 다이어그램은 클래스 다이어그램과 크게 차이점이 없는 관계로 UML의 표준에는 포함되어있지 않다.
갑자기 이러한 오브젝트 다이어그램을 여기서 언급하는 이유는 객체들 사이의 관계를 표기하기 위해 클래스 다이어그램과 거의 같은 오브젝트 다이어그램을 그리기보다는 특별히 클래스 다이어그램과 차이점이 되는 부분을 여기 콜라보레이션 다이어그램에 기재하는 것이 좋을 것이다.
4) 유스케이스 다이어그램 (Usecase Diagram)
유스케이스 다이어그램은 유스케이스를 그려놓은 다이어그램이다. 여기서 유스케이스란 말 그대로 컴퓨터 시스템과 사용자가 상호작용을 하는 하나의 경우이다.
예를 들어 보험처리 프로그램의 경우에 “고객이 보험증권에 sign 한다. 판매원이 판매 통계량을 종합한다.” 등이 use case가 된다. 이러한 유스케이스 다이어그램은 시스템 구축의 초기에 이 시스템이 어떠한 일을 하는지에 대한 부분을 사용자 관점에서 이해할 수 있을 정도로 기술하여야 한다.
이러한 유스케이스 다이어그램은 사용자와의 대화 수단으로 그리고 앞으로 구축해 나갈 때의 밑바탕이 되는 것이다.
5) 상태 다이어그램 (Statechart Diagram)
상태 다이어그램은 한 객체의 상태 변화를 다이어그램으로 나타낸 것이다. 시스템의 실행 시 객체의 상태는 메시지를 주고받음으로써 또한 어떠한 이벤트를 받음으로써 많은 변화가 있을 수 있다.
실제 시스템에서 실행 시 많은 객체가 생성되고 소멸한다. 이렇게 무수한 객체의 상태 전부를 모두 다이어그램으로 나타내는 것은 불가능하다. 결국 상태 다이어그램은 특별히 관심을 가져야 할 객체에 관하여 그리고 특정 조건에 만족하는 기간의 상태를 표시하여야 한다.
6) 액티비티 다이어그램 (Activity Diagram)
액티비티 다이어그램은 플로우 차트가 UML에 접목되었다면 가장 이해가 빠를 것이다. 시스템 내부에 존재하는 여러 가지 행위들 그리고 각 행위의 분기, 분기되는 조건 등을 모두 포함 하게 된다.
이러한 액티비티 다이어그램에서 기존 플로우 차트와 다른 점은 어떠한 행위에 따라 객체의 상태를 표기할 수 있다는 것이다. 이러한 점을 제외하고 기존 플로우 차트와 표기법과 의미가 약간씩 달라질 뿐 크게 다르지 않다고 보아도 좋다.
7) 컴포넌트 다이어그램 (Component Diagram)
컴포넌트 다이어그램(Component Diagram)은 소프트웨어 컴포넌트 사이의 의존관계를 묘사한다. 소프트웨어 컴포넌트를 구성하는 요소들과 그것들을 구현하는 요소들도 모두 표현될 수 있다.
컴포넌트는 기존의 함수, 클래스 등에 비하여 더욱 큰 규모이므로 재사용을 하는 경우 재사용의 효과가 더욱 크게 된다. 그리고 매우 강한 수준의 정보 은닉 개념을 지원한다. 기존 컴포넌트를 수정하는 대신에 아예 새로운 컴포넌트로 기존 컴포넌트를 대체하는 것도 가능하다.
8) 디플로이먼트 다이어그램 (Deployment Diagram)
실행 상황에서 노드들의 구성을 보여주고 소프트웨어 요소들이 실제로 어떤 하드웨어에 배치되어 실행되는지를 보여준다.
컴포넌트 다이어그램과 같이 실세계의 개체를 다루며 컴포넌트 다이어그램이 소프트웨어 컴포넌트였다면 배포 다이어그램은 하드웨어에 중점을 둔 다이어그램이다.
다시 말해 배포 다이어그램은 컴퓨터를 기반으로 하는 시스템의 물리적 구조를 나타낸다. 컴퓨터와 부가장치, 그리고 각각의 연결 관계뿐만 아니라 각각의 기계에 설치된 소프트웨어까지 표시한다.
9) 객체 다이어그램 (Object Diagram)
객체 다이어그램과 클래스 다이어그램을 서로 밀접한 관련이 있으며 거의 유사한 노테이션을 사용한다. 이 두 다이어그램 모두 시스템의 정적인 구조를 시각화하기 위해 사용된다.
클래스 다이어그램이 클래스를 보여주지만 객체 다이어그램은 클래스의 인스턴스를 표시한다. 객체 다이어그램은 클래스 다이어그램보다 더 구체적이다.
