[Software Engineering] 7. UML Overview

수업 듣기 전까지는 UML = Class Diagram 이라고만 생각했었다.

 

이전에 C++ 개발을 하던 입장에서는 Class Diagram 말고는 접할 기회가 없어서 그랬었나....

 

아무튼 Class Diagram은 UML의 극히 일부이고, 이번 게시물에서는 UML이라는 큰 숲을 보는 시각에서 게시물을 다뤄보려한다. 

 

◉ UML 이란? 

 

프로그래밍 언어가 아니다! 

 - Object Oriented 시스템의 다양한 디자인 방법들을 통합하기 위해 등장한 모델링 언어이다. 

 - 다양한 소프트웨어 개발 방법(프로세스)를 표현할 수 있는 모델링 언어

 - 시각화가 쉬운 모델링 언어

 - 소프트웨어 시스템 개발 모델링에 필요한 구성요소를 제시하고 이를 이용한 추상화 방법과 산출물들을 프로젝트 참여자들이 쉽게 이해할 수 있도록 개발된 객체지향개발 표준통합 모델링 언어

 

 => 즉, 객체 지향 시스템의 개발에서, 참여자들 누구나 쉽게 이해하고, 이를 바탕으로 쉬운 의사소통을 할 수 있게 하는 것이 목표이다,

 

 

 

◉ UML이 왜 필요할까 ? 

 

 시간이 지날 수록, 시장의 요구에 맞는 소프트웨어의 복잡도는 천문학적으로 증가한다. 소프트웨어의 복잡도가 증가할 수록, 소프트웨어 설계 방법의 중요성도 커진다. 흔한 소프트웨어 설계 실패호는, over schedule, over budget 등이 있다. 

 

 설계 없이 막무가내로 소프트웨어를 개발하면, 당연히도 망하게 되는데, 소프트웨어 개발 실패요인을 찾아보면 아래와 같다. 

소프트웨어 개발 실패의 요인

 

 그리고, 이 모든 요인들은 "Require modeling" , 즉, 요구사항 모델링으로 대부분 커버가 된다. 이것이 요구공학이 등장한 배경이고, 이것이 중요한 만큼 방법도 굉장히 어렵다.

 

- 정확한 Requirement의 분석은 Domain Expertise 가 필요하다, 하지만 Domain 전문가들은 희귀한 인력이고, 바쁘다.

 

- Requirement Document는 일반적으로 직장 상사나 고객이 요구해야지만 그제서야 쓰인다.

 

- Programmer과 User 간의 Gap 이 너무나도 크다.

 

✤ 그!래!서! 우리는 User, Programmer, Domain 전문가, 직장상사, 고객 등등이 의견차이 없이 명확한 아이디어 전달이 가능하고  한눈에 보기 쉽도록 하기위해 UML을 사용한다.  ✤

 

 

 

◉ UML의 종류

 

UML 의 종류

 

크게 Structural / Dynamic 으로 나눌 수 있는데, 

 

말 그대로 UML 문서의 중점을 동작에 두느냐, 구조에 두느냐의 차이이다. 예를들어, 실제 Case들의 입력부터 출력 까지를 보고 싶으면, Dynamic 카테고리에 있는 UML을 참고해야 하고, 소프트웨어의 구조를 보고싶으면 Structural 카테고리에 있는 UML을 보는것이 낫다.

 

 

◉ ATM 소프트웨어 개발에서의 예시

 

개발 과정에서 UML이 어떻게 사용되는지 한번 보자,

 

 ❖ UseCase 

 유즈케이스는 시스템의 동작을 User 입장에서 표현한 시나리오이며, 개발하려는 소프트웨어에 관련된 Requirements를 알아내는 과정이다. 소프트웨어 개발 프로세스 중 개발을 위한 소프트웨어의 기능을 대략 설명가능하기도 한다. 

 

일종의 사용자 시나리오에서, Use Case를 추출한다.대체로 needs가 usecase가 된다. 

 

 

ATM Usecases

 

그리고 개별 UseCase에서, Requirement 분석을 실행한다.

 

Usecase Analysis

 

이때, Usecase는 다양한 Class들로 나뉘는데, 

 

위 그림에서 Dispenser 처럼 생긴 'ㅣ-O' 모양을 Boundary Classes 라고 하며, User 및 외부와 Interface가 있는 부분이다.

 

Withdrawal 같이 'O' 생긴 모양은 Control Class로, Usecase를 수행하는 개별 로직 클래스이며,

 

Account 같은 '으'  모양은 Usecase에 필요한 Information을 저장하는 클래스이다.

 

 

 

[Validation - Collaborative Diagram]

시스템의 Dynamic 을 분석하기 위해서, Usecase analysis 를 토대로 validation 을 실행하는데, 아래는 Collaborative Diagram이다.

 

Collaborative Diagram

User 과 제작한 Object과의 Dynamic Interaction을 보여주는 UML이다.

 

 

 

 

[Analysis Class Diagram]

 

Usecase model을 바탕으로 만든 SW 의 구조를 분석하기에는 Class Diagram이 가장 편하다. 개발자들 사이에서 가장 유명한 UML이 아닐까 싶다. 하지만 Analysis Class diagram 은 Design Class Diagram 은 다르다. 하지만 생긴건 비슷하다

Analysis Class Diagram

 

 

[Interaction - Sequence Diagram]

 

 각 소프트웨어 요소들이 각기 다른 시나리오에서 수행할 동작들을 확인하기에는 Sequence Diagram이 가장 적합하다.

 

Sequence Diagram

 

[Subsystem check (Implementation) - Component Diagram]

 

메인 시스템이 다른 시스템을 implement할때, 각 시스템간의 관계를 보여주기에는 Component Diagram이 적합하다.

 

Component Digram

 

위와 같이 UML에는 정말 많은 Diagram들이 있다.

 

 

그래서 각기 다른 활용 용도에 맞게 UML 을 제작/사용하면 된다.

 

예를들어, 

1.  소프트웨어를 사용하는 사용자들이 누구고, 그들은 무엇을 하려고 하는가?

=> Use Cases

2. 소프트웨어의 객체들이 각 Use case에 따라 어떻게 상호작용 하는가? 

=> Interaction Sequence Diagram

3. 실시간 다양한 이슈들이 소프트웨어에서 어떻게 처리될 것인가?

=> State Diagram