UML

UML

• UML(Unified Modeling Language)은 프로그램 모델에 대한 규격화된 표현 방식이다.
• 복잡한 시스템, 여러가지 데이터 흐름, 관계와 동작 등을 잘 나타내기 위해서 사용한다.
• 다양한 방식의 프로그램들이 존재했지만, 규격화된 표현 방식이 없어 한눈에 알아보기 힘들었다.
• UML은 이러한 프로그램을 특정한 방식으로 나타내기 위한 언어이다.
• UML은 프로그램이 어느 정도 커지면 대부분 만들지만, 특히 이런 곳에서 자주 사용한다.
  • Data Modeling
  • Business Modeling
  • Object Modeling
  • Component Modeling
• 특히 OOAD(Object-Oriented Analysis and Design)에서 중요하게 사용한다.

Semantic

• 대부분의 프로그래밍 언어의 정의는 다음과 같이 이루어진다.

  • 기존에 있던 언어가 있다.
  • 새로 만들어진 언어의 어떤 부분은 기존에 있던 언어의 어떤 부분과 동일하게 작동한다.
  • 이런것들을 모아서 언어를 만들고 기능을 형성한다.

• UML은 특이하게 기존에 있던 언어로 자신을 정의하는 것이 아닌, 자기 자신으로 자신을 정의한다.

• 뭔 말이냐면, 재귀적으로 정의하였다는 의미이다.

  이게 가능한가..?

• 이게 가능한 이유는 UML이 Formal Language (C, Java등)가 아닌, Semi-Formal Language이기 때문이며, 그냥 그렇다 치고 넘어갔다.

• UML은 4단계로 구성된다.

  instance → model → meta model → meta-meta model

  • Layer M3 : Meta-meta model layer : Framework같은 것
  • Layer M2 : Meta model layer : 오브젝트
  • Layer M1 : Model layer : 우리가 만드는 UML
  • Layer M0 : Information layer : 정보들

• 우리가 지금부터 알아볼 UML의 종류이다. 천천히 알아보자.

Structure Diagram

• Structure Diagram은 구조를 기반으로 작성하는 UML의 방식이다.
• 전체적인 구조가 어떻게 되어있는지를 파악한다.
• 하나하나의 요소가 무슨 속성을 가지고 있고, 어떻게 상호작용하는지를 잘 보여준다.

Use Case Diagram

• Use Case Diagram은 Structure Diagram에서 제일 많이 쓰이는 형식이다.
• Use Case는 밖에서 시스템을 사용하는 방식, Case를 적어놓은 것이다.
• "Use Case들에 따라 시스템이 어떻게 작동할 것인가?"에 대한 관계와 진행을 적어놓은 것이 Use Case Diagram이다.
  
• 특정한 방식이 없이 그냥 진행될 상황들을 적어놓았으므로, 간단하지만 한편으로는 굉장히 중요하다.

Class Diagram

• Class Diagram은 시스템을 Class로 나눈다.
• 각각의 Class는 이름(name)과 속성(attribute), 그리고 작동(operation)을 가지고 있다.
• 이러한 Class들은 여러개가 있으며, 이들간의 관계를 나타낸 것이 바로 Class Diagram이다.
  

Object Diagram

• 특정한 시점을 가정하고, 그 상황에 각각의 요소가 어떻게 작동하는지를 나타내는 방식이다.
• Class Diagram는 관계만을 나타내기 때문에, 실제 값이 어떻게 되어 있는지 잘 모른다.
• 그러나 Object Diagram은 실제 값을 나타내어 주므로, 어떤 상황에 어떻게 구성되는지를 더 잘 알 수 있다.
  

Package Diagram

• Package는 Class와 비슷하다.
• 차이점은 Class는 논리적인 관점에서 정의가 되었다면, Package는 실제로 Class 파일이 나온 것을 의미한다.
• 그래서 Package Diagram은 개발 초기에는 잘 나오지 않으며 어느정도 개발이 진행되고 파일들이 나오면 만들게 된다.
• 개발 앞쪽에서 만들수록 Class Diagram과 비슷하게 논리적인 UML이 되며, 개발 뒤쪽에서 만들수록 실제 파일과 비슷한 물리적인 UML이 된다.
  

Component Diagram

• Component는 개발을 하는 논리적인 단위이다. 독립적인 인터페이스이기도 하다.
• Component 하나 또는 여러개를 합치면 Diagram이 된다.
• Component 하나는 독립적으로 특정한 역할을 수행한다.
• Component 안에는 여러가지 Class가 들어간다.
  

Composite Structure Diagram

• Component는 안에 여러개의 Component를 가질 수 있다.
• 계층적인 구조로 나타내면 Component Diagram이지만, 포함 구조로 나타내면 Composite Structure Diagram이다.
  

Deployment Diagram

• 각각의 Component들에 대해서 소프트웨어나 하드웨어를 정확히 표현하면 Deployment Diagram이다.
• 실제 파일들의 포함 관계, 상호작용 관계들을 나타낸다.
  

Behavior Diagram

• Behavior Diagram은 행동이나 수행하는 기능을 기반으로 작성한 UML이다.
• Structure Diagram은 전체 구조를 중요시하는 것에 비해, Behavior Diagram은 구조보다는 상호작용과 요청, 관계를 중요시한다.

Sequence Diagram

• Sequence Diagram은 Behavior Diagram에서 제일 많이 쓰이는 형식이다.
• Sequence Diagram은 어떤 일(Use case)을 수행할 때, 시간의 흐름에 따라 벌어지는 일들을 나타낸 것이다.
  

Communication Diagram

• Communication Diagram은 Sequence Diagram과 거의 동일하다.
• 어떤 일을 요청하면 주는 정보와 받는 정보들이 존재한다.
• 이러한 주는 정보와 받는 정보를 잘 나타낸 것이다.
• Sequence Diagram보다 주는 정보가 부족하지만 간단하게 나타낼 수 있따.
  

Timing Diagram

• Timing Diagram은 Sequence Diagram에서 정보들보단 시간의 흐름을 중요시 한 UML이다.
• Sequence Diagram은 시간이 얼마나 걸리나에 상관 없이 순서를 더 중요시했다.
• Timing Digram은 생략된 시간정보를 상세히 표현하여 순서와 시간정보를 잘 알려준다.
  

Interaction Overview Diagram

• Sequence Diagram 여러개를 흐름에 따라 적어놓은 것을 의미한다.
• 보통 TestCase를 만들어낼 때 많이 사용한다.
  

State(Statechart) Diagram

• State Diagram은 진행할 때 들어가게 되는 상태들을 기준으로 설명하기 위해 만드는 UML이다.
• 여러 상태(State)들이 화살표(Arrow)로 이어져있다.
• 주어진 상황을 따라가면 현재 상태가 어떤 상태인지 확인하기 쉽다.
• 일을 하면서 다른 상태로 넘어간다.
  

Activity Diagram

• State Diagram와 비슷한 Diagram이다.
• 여러 상태(State)들이 화살표(Arrow)로 이어져있다.
• State Diagram은 상태를 이동하면서 일을 수행하는 것과 달리, Activity Diagram은 상태 안에서 일을 수행한다.