UML에 대하여

오늘은 UML에 대해 정리하는 글을 써보려 한다. 사실 개발자들이 개발자-개발자 혹은 개발자-고객 사이의 상호작용을 원활하게 하기 위해 사용하는 것으로 알려져 있고 나 역시 소프트웨어공학 시간에서 배운 거지만, 기획자-개발자의 소통에서도 가끔 쓰이기에 시험 공부하는 겸 정리하면 좋을 것 같다는 생각이 들었다.
 

UML이란?

UML이란 Unified Modeling Language의 약자로, 시스템 개발 과정 중 상호 간의 원활한 의사소통을 위한 표준화된 객체지향 모델링 언어이다. 종류가 무척이나 다양한데, 일부 자주 쓰이는 다이어그램 종류들에 대해 정리해보려 한다.
 

UML의 종류

1. Use Case UML

 

위 사진은 NextGen POS 시스의 Use Case UML이다. Use Case UML의 경우, 현실의 사용자가 누구와 어떤 행동을 하는지, 그 과정에서 누가, 어떤 결과를 가져오느지, 사람, 역할을 중심으로 전체 서비스를 보여준다.
 
Use Case Relationship에는 세 가지 방법이 있다.
 
1. Include (포함): 유스케이스가 다른 유스케이스를 포함하는 관계이다. 여러 유스케이스에서 공통으로 중복되는 시나리오가 있다면 이 시나리오를 따로 분리하여 새로운 유스케이스로 만들고, 새로 만든 유스케이스를 각 유스케이스마다 포함시키면 된다.

 

 

이런 식으로 점선으로 된 연결선에 <<include>>를 붙인다.
 
 
2. Extend (확장): 유스케이스와 그 유스케이스를 확장하는 관계로, 유스케이스 시나리오에서 어떤 조건에 따라 다른 유스케이스를 확장하는 것이다.

 

 

include와 유사하게 두 유스케이스 사이를 점선으로 잇되, 기본 유스케이스 쪽에 화살표 머리를 두고 <<extend>>를 붙인다. 윗 그림에서는 정상적인 흐름에서는 Place Order 기본 유스케이스가 실행되지만 확장점(Extension point)의 조건을 만족한다면 Request Catalog 확장 유스케이스가 실행된다.
 
 
3. Generalization (일반화): 유스케이스를 상속하는 것을 의미한다. 자식 유스케이스는 부모 유스케이스의 모든 행동과 의미를 물려받으며, 여기에 자신만의 행동을 추가할 수 있다.

 

 
위와 같이 표현된다. 
 
 

2. Class UML

 

 

Class UML은 서비스에 들어가는 중요한 정보를 박스로 만들어 연결시킨 것으로, 클래스들과 그들의 관계를 표시하는 다이어그램이다. 클래스는 임의의 유사한 객체들을 명세하기 위한 스펙으로 사용된다. 클래스를 추출하는 팁은 다음과 같다.
 
- 하나의 주제를 갖고 있어야 한다.
- 클래스 이름은 추상화를 가장 특징화하는 하나의 명사이어야 한다.
- 의뢰인과의 대화(분석 도출 과정)에서 명사는 클래스 이름이 될 가능성이 높고, 동사는 클래스의 Operation (method)가 될 가능성이 높다.
- 고객, 사용자와의 상담(시나리오) + 문제 도메인 지식+ 기술적 경험+ 일반적 상식에서 추출한다.
 
 

3. Sequence UML

 
Sequence UML은 시간 경과에 따라 객체 상호간 교류 과정을 표현한 다이어그램이다. 위의 그림은 소비자가 자판기의 음료수를 사는 것에 대한 시나리오를 담고 있다. 데이터가 어떻게 흘러가고, 최종적으로 어디에서 어떤 결과가 나오는지를 알려준다. 
 
이 외에도 정말 많은 UML 다이어그램들이 있지만, 실무에서 가장 많이 쓰이는 3개를 다뤄보았다. UML을 그리는 과정에서 지켜야 하는 규칙이 많은데, 그 중 하나가 화살표이다. 화살표에는 각각의 의미가 있다고 한다.
 

 
 

UML을 이론적으로 공부했으나 아직 직접 그려본 적은 없어서 나중에 기회가 된다면 우리 서비스의 UML을 그려봐야겠다. ( draw.io (diagrams.net) 에서 그릴 수 있다고 한다.)
 
사실 지금 팀플이 모두 합쳐서 6~7개 정도인데다가 시험기간에 과제까지 있는 관계로,, 이번 글은 수업 내용 복습 겸으로 쓰게 되었지만, 기획자가 이를 알면 분명히 도움 되리라 생각한다. 개발자와 잘 소통할 수 있는 기획자가 되자!