[UML] UML의 정의와 Diagram

UML은 Unified Modelling Language의 약자로서 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용합니다. 시스템의 구조적인 청사진을 그리기 위해 많이 사용되며 그외에도 매우 다양한 용도에 맞게 사용할 수 있습니다. 

많이 착각하시는 것 중 하나가 UML을 OOAD 개발 프로세스라고 생각하시는데 그 부분은 잘못된 부분입니다. UML은 소프트웨어를 개발하기 위한 방법이 아니기 때문입니다. 그리고 UML은 여러분 에게 Object-Oriented 한 사고를 가르쳐주지 않습니다. 어떻게 Operation과 Data를 가진 Object 구조를 그릴 수 있는가, 여러분이 디자인한 내용이 잘된것인가는 UML이 알려주지 않는다는 것이죠. 그럼 UML에 대해 조금씩 알아보겠습니다.

UML Semantics은 4개의 layer 구조(Instance -> model -> meta model -> meta-meta model)를 가집니다.

 - Layer M0 (Instance) : Application 영역, 즉 코드 레벨

 - Layer M1(model) :  UML model layer에 해당됩니다. 각 class간 관계등을 정의해 놓은 Layer. 실제 모델링하는 Layer

 - Layer M2(meta model) : 해당 요소가 class인지 abstract class인지 attribute인지 등등을 정의해놓은 Layer

 - Layer M3(meta-meta model) : Layer M2를 정의하는 meta data가 존재하는 Layer.

위 4가지를 이용해서 UML에서 semantic을 정의하게 됩니다.

UML을 적용하기 위한 3가지 방법이 있습니다. Sketch, Blueprint, Programming Language로 3가지 입니다. 보통은 Sketch, Blueprint에서 많이 사용합니다. Sketch는 Concept 측면에서 단순하게 Solution을 다른 사람과 공유하기 위한 방법으로 많이 사용되며, Blueprint는 명세서 수준으로 자세하게 작성하기 위한 용도입니다. Blueprint는 개발자가 코드로 작성하기 위한 바로 전 단계로서 정말 자세하게 작성하는게 좋습니다. Programming language 용도는 잘 사용되지 않기 때문에 패스하겠습니다 :-)

UML Diagram에 대해 하나씩 살펴봅시다. RML Diagram은 크게 structure diagram과 Behavior Diagram으로 나눠져 있으며 구조와 행위에 대해 어느 것을 강조하여 Diagram을 그릴 것 인가에 따라 선택하면 됩니다.

먼저, Structure Diagram에 속하는 Diagram을 알아봅시다.

Use Case Diagram

모든 Diagram의 시작이라고 할 수 있는 Use-Case diagram은 사용자가 시스템을 사용하는 경우에 대해 시나리오 형태로 명세해 놓은 diagram입니다. 즉 시스템 내부의 구현은 전혀 모르고 어떻게 사용할지, 어떻게 반응할지에 대해 사용자가 만족할 수 있도록 시나리오를 작성하는 것입니다. 사용자의 요구사항에 따라 정리 될 수 있습니다. 여기서 사용자는 개발하려는 시스템과 상호작용하는 사람, 기관, 다른 시스템 등이 될 수 있습니다. 

Class diagram

Class diagram은 시스템을 구성하는 Class들의 구조를 명세해 놓은 diagram입니다. class간의 관계, class의 상태(attributes)와 행위(operations)을 작성해 놓은 것입니다. 여러분들이 자주 보시는 Diagram일 것이니 추가적인 설명은 생략하겠습니다.

Object Diagram

Object diagram은 특정 시점의 class들의 Instance를 보여주는 diagram입니다. 즉 시스템이 동작하는 중간의 Snapshot이라고 할 수 있죠. 지금 Object의 attributes가 어떠한 값을 가지고 있는지 등을 나타내는데 사용하는 Diagram입니다.

Package Diagram

Package diagram은 class의 그룹을 명세해 놓은 diagram입니다. 복잡하지 않고 오직 Package와 그 내부의 class를 나타내고 있는 간단한 diagram입니다. Package 내부에는 또 다른 Sub package가 존재할 수 있습니다. 

Component Diagram

Component diagram은 Package가 class들의 모음이라면 package는 런타임에 Component에 포함됩니다. 즉 package들이 모음을 명세해놓은 diagram이라고 봐도 될 것 같습니다. 복잡하고 큰 시스템에서 내부 의존성과 구조를 나타낼 수 있습니다.

Composite Structure Diagram

큰 시스템에서 Component들의 관계를 명세해놓은 Composite Structure Diagram입니다. Component Diagram을 좀 더 상세하게 그려놓은 diagram으로 data의 상호 통신(inter-communication) 등을 표현할 수 있습니다.

Deployment Diagram

Composite Structure Diagram 등을 작성하였다면 특정 시스템에서 실제로 동작하기 위해 하드웨어와 연결시켜 명세해 놓은 diagram입니다. 하드웨어의 OS나 어떠한 모델, 크게는 자동차, 선박, PC등으로 나뉘어서 나타내는 diagram입니다. DB 서버는 어떠한 프로그램을 사용하는지 등도 나타냅니다.

다음은 Behavior diagram에 속하는 Diagram들을 살펴보죠.

Sequence Diagram

Sequence diagram은 시간 흐름을 기반으로 object 간의 상호작용을 명세해 놓은 diagram입니다. Use-case에 대해 어떻게 sequence적으로 동작하는지 설명해 놓습니다. Object간 Operation 요청과 그에 맞는 return 등을 나타냅니다.

Communication Diagram

Sequence diagram과 유사하지만 Class diagram에서 attribute와 operation을 지운 Class들만 배치한 후 object간 Operation들을 순차적으로 넘버링하여 작성 및 나타냅니다. Sequence Diagram 보다 명세하기 훨씬 편하나 Sequence만큼 명확하게 나타내기는 어렵습니다.

State Diagram

State Diagram은 State Machine, State Chart Diagram으로도 불리며, 여기서 State는 말 그대로 상태를 나타냅니다. 상태의 변화에 따른 다양한 이벤트를 나타내는 Diagram으로 시스템이 상태에 따라 동작하게 된다면 이 Diagram으로 나타내면 좋습니다. 흔히 알고계신 유한상태머신이라고 생각하시면 됩니다.

Timing Diagram 

Timing을 보여주는 Diagram으로 어떤 시점에 object의 operation들이 동작해야 하는지를 나타낼 수 있습니다. 

Activity Diagram

선택, 반복 및 동시성을 지원하는 단계별 활동 및 동작의 워크 플로를 그래픽으로 표현한 것입니다. Flow-chart나 Data flow를 명세할 때 많이 사용합니다. 

Interaction Overview Diagram

Object간 상호작용의 흐름을 명세한 Diagram입니다. 

이상 UML Diagram의 종류들을 살펴보았습니다. 살펴본 많은 Diagram은 여러분들이 필요 시 선택하여 시스템을 명세하면 됩니다. 각 Diagram의 자세한 내용은 별도로 학습을 하며 UML을 그려나가시면 좀 더 빠르게 익히시고 그 차이를 알 수 있을 것 같습니다. 

긴 글 읽어주셔서 감사합니다.