[UML] UML 기초

rin·2020년 9월 8일

UML이란

📌 Unified Modeling Language

프로그램 설계를 표현하기 위해 사용하는 표기법
요구분석, 시스템 설계, 시스템 구현 등의 시스템 개발 과정에서 개발자간의 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어.
소프트웨어 시스템, 업무 모델링, 시스템의 산출물을 규정하고 시각화, 문서화하는 언어이다.
프로그램언어가 아닌 기호와 도식을 이용하여 표현하는 방법을 정의한다.
모델링 언어 ⭕️ 방법론 ❌ 프로그래밍 언어 ❌
작성 목적 👉 객체 지향 시스템을 가시화, 명세화, 문서화한다.

🤔 unified?
UML 등장 이전에 Booch, OMT, OOSE 등 다양한 객체 모델링 방법이 공존하였다. 따라서 서로 다른 방법을 사용한 조직 간의 정보를 공유하려면 다른 표현 방식을 익혀야했다.

이런 불편함을 해소하기 위해 위해 다음과 같은 목표로 통합하게 되었다.

객체지향 개념을 이용하여 소프트웨어 영역뿐만 아니라 시스템 영역도 모델링 할 수 있게 한다.
실행 가능하거나 개념적인 산출물들을 명확하게 결합할 수 있게 한다.
사람과 기계에 모두 유용한 모델링 언어를 만든다.

✔️ 목표

사용자들이 의미있는 모델을 만들고 공유할 수 있도록 사용하기 쉬우면서도 표현이 풍부한 시각적 모형화 언어를 제공한다. (즉, 문서의 직관성을 높인다.)
핵심 개념을 확장하기 위한 메커니즘을 제공한다.
특정 프로그래밍 언어나 개발 공정에 종속되지 않아야 한다. (통합성을 중요시한다.)
모델링 언어를 이해하기 위한 공식적 기준을 제공한다.
객체지향 도구 시장의 성장을 장려해야 한다.
협동, 프레임워크, 패턴, 컴포넌트 등의 고수준의 개발 개념들을 지원한다.
산업계의 검증된 최상의 경험들을 통합한다.

UML의 특징

가시화 언어

소프트웨어의 개념 모델을 시각적인 그래픽 형태로 작성한다. 표기법에 있어서는 Symbol에 명확한 정의가 존재하므로 개발자들 사이에서 원활한 의사소통이 가능하다.

명세화 언어

명세화란 정확하고 명백하며, 완전한 모델을 만드는 것을 의미한다. UML은 소프트웨어 개발과정인 분석, 설계, 구현 단계의 각과정에서 필요한 모델을 명세화 할 수 있는 언어이다. 개발 단계 초기부터 어떤 input값이 들어갈 것인지, 어떤 Process를 통해서 output이 나올 것인지를 모두 확실하게 모델링하여 개발 단계에 들어갔을 때 이 명세서를 따라 그대로 개발 할 수 있도록 한다.

구축 언어

UML로 명세화된 설계모델은 Java, C++, VB 등 다양한 언어의 소스코드로 변환하여 구축할 수 있다. 반대로 구축되어 있는 소스코드를 UML로 변환하여 분석하는 Reverse도 가능하다. 가시화, 명세화 된 모델을 실제로 동작하는 소스코드로 변환하여 구축하는 것이다.

문서화 언어

시스템 아키텍처와 이에 대한 모든 상세 내역에 대한 문서화를 다루며, 요구사항을 표현하고 시스템을 테스트하는 언어도 제공한다. 일련의 과정을 문서로 남겨 계속 유지 보수한다.

UML의 요소

https://onecellboy.tistory.com/334

Thing

Structual Thing

Behavioral Thing

Grouping Thing

Annotation Thing

Relationships

Dependency Relationship

Generalization Relationship

Association Relationship

Aggregation Relationship

Composition Relationship

Realization Relationship

Diagrams

Class Diagram

Object Diagram

Use Case Diagram

Sequence Diagram

Collaboration Diagram

State Diagram

Activity Diagram

Component Diagram

Deployment Diagram

Thing

추상적인 개념으로써 UML을 이용한 모델링의 기본요소이다.

Structural Thing(구조 사물)

UML 모델의 명사형(예. 클래스, 노드, 서버, 사용자...)
모델의 정적인 부분이며 개념적이거나 물리적인 요소

Behavioral Thing(행동 사물)

UML 모델의 동사형
모델의 동적인 부분이며 시간과 공간에 따른 행위 요소를 표현

Grouping Thing(그룹 사물)

모델을 그룹화하여 요소 표현(패키지, 라이브러리, 네임스페이스..)

Annotation Thing(주석 사물)

UML 모델 요소를 설명하거나 메모하거나 명확히 하는 표현방법(주석, 메모..)

Relationships

구성 요소들간의 연관성을 표현 (주로 클래스들간의 관계 표현시 사용된다.)

Dependency Relationship(의존 관계)

한 클래스가 다른 클래스를 사용하는 사용관계
(프로그래밍에서는 인스턴스 변수없이 어떤 클래스의 정적 메소드를 사용할 경우나, 메소드내에서만 생성되었다 사라지거나 하는 경우. 예를 들어 Math 클래스 사용시 인스턴스를 생성하지 않고 Math 클래스의 정적 메소드(Math.sin()) 을 사용하는 경우이다. )

Generalization Relationship(일반화 관계)

일반화(generalization), 특수화(명세 specialization) 관계
객체 지향에서의 상속 관계
예) 인간, 원숭이의 일반화(Generalization)는 포유류이다. 포유류 중 특수화(specialization)는 인간이다.
실선에 화살표로 표현

Association Relationship(연관 관계)

클래스로부터 생성된 객체간의 일반적 협력관계
연관 관계는 실선혹은 양방향화살선으로 표현한다.

Aggregation Relationship(집합 관계)

두 클래스간의 전체-부분관계(Whole-part)
각 클래스가 독립적인 생명 주기를 갖는다.
예) 자동차의 경우 자동차가 사라진다고 바퀴, 엔진이 사라지는 것은 아니다. 자동차와 바퀴, 엔진의 생명주기는 다르다. 역으로 바퀴가 사라진다고 자동차도 사라지는 것은 아니다.
하나의 클래스가 여러개의 컴포넌트 클래스로 구성

Composition Relationship(구성 관계)

두 클래스간의 부분-전체관계(Part-Whole)
부분의 생명주기가 전체의 영향을 받는다.
하나의 클래스가 여러개의 컴포넌트 클래스로 구성
다른 말로 강한 집합관계

Realization Relationship(실체화, 실현 관계)

인터페이스와 실제 구현된 클래스간의 관계
generaization Relationship과 비슷하다 다르다. generalization은 존재하는 객체(속성,행동)에 대한 추가구현(오버라이딩)이고 Realization 은 존재하는 행동에 대한 구현이다.

Diagram

구성요소를 표현하기 위한 구조적 다이어그램과 행위를 표현하기 위한 행위 다이어그램으로 나눌 수 있다.

✔️ 구조적 다이어그램 (Structure UML Diagrams)

클래스 다이어그램 (Class Diagram) : 클래스 명세와 클래스 간의 관계를 표현
객체 다이어그램 (Object Diagram) : 인스턴스 간의 연관 관계를 표현
패키지 다이어그램 (Package Diagram) : 패키지 간의 연관 관계를 표현
컴포넌트 다이어그램 (Component Diagram) : 파일과 데이터베이스, 프로세스와 스레드 등의 소프트웨어 구조를 표현
복합 구조 다이어그램 (Composite Structure Diagram) : 전체-부분 구조를 가진 클래스를 실행할 때의 구조를 표현
배치 다이어그램 (Deployment Diagram) : 하드웨어와 네트워크 등 시스템의 물리 구조를 표현
프로필 다이어그램 (Profile Diagram) : 말그대로 프로필만 간단하게 구성된 다이어그램

✔️ 행위 다이어그램 (Behavioral UML Diagrams)

유스케이스 다이어그램 (UseCase Diagram) : 시스템이 제공하는 기능과 이용자의 관계를 표현
액티비티 다이어그램 (Activity Diagram) : 일련의 처리에 있어 제어의 흐름을 표현
시퀀스(순차) 다이어그램 (Sequence Diagram) : 인스턴스 간의 상호 작용을 시계열로 표현
커뮤니케이션 다이어그램 (Communication Diagram) : 인스턴스 간의 상호 작용을 구조 중심으로 표현
상호작용 개요 다이어그램 (Interaction Overview Diagram) : 조건에 따라 다르게 동작하는 시퀀스 다이어그램을 액티비티 다이어그램안에 포함하여 표현
타이밍 다이어그램 (Timing Diagram) : 인스턴스 간의 상태 전이와 상호 작용을 시간 제약으로 표현
상태 머신 다이어그램 (State Machine Diagram) : 인스턴스의 상태 변화를 표현

UseCase Diagram

정의 : 시스템의 사용에 대한 시나리오의 집합. 즉, 시스템과 사용자간의 상호작용을 다이어그램으로 표현한 것으로 사용자의 관점에서 시스템의 서비스 혹은 기능 및 그와 관련한 외부 요소를 보여주는 것

목적 : 사용자 관점에서 시스템을 모델링하기 위함. 즉, 사용자가 시스템에 대하여 바라는 바를 표현함으로써 사용자의 시점을 빨리 이해하고 쓸모있고(Useful) 쓸 수 있는(Useable) 시스템을 만들 수 있도록 함

UseCase 분석의 필요성

프로젝트 초기 단계에서 목표 시스템을 정확히 이해하고 세부 기능을 파악해야 한다. → 사용자와의 의견 차이를 좁히고 변경의 여지를 줄이는 과정
유스케이스 분석의 결과는 유스케이스 다이어그램과 유스케이스 명세로 표현된다. → 1) 작업을 유스케이스로 구분하여 팀에 할당할 수 있다. 2) 시스템의 기능에 관한 시나리오를 이해하면 관리에 도움을 준다. 3) 테스트 케이스 작성을 위한 기준을 제시한다.

📌 기본개념

시스템(프로그램 전체)
액터(시스템과 상호작용하는 사람
유스케이스(가능)
관계
- 연관 Association : 액터와 상호작용 하는 기능을 실선으로 표기한다.
- 의존 Dependency : 포함과 확장으로 구분
  include - 기능을 수행하기 전에 수행해야하는 기능 (예 => 글을 등록한다 ---> 로그인한다)
  extend - 기능에 추가되는 기능 (예 => 글을 등록한다 ---> 파일을 첨부한다)
- 일반화 Generalization : 유사한 기능을 모아 그룹을 만듬 (이해도를 높임)

Use-case Diagram의 구성요소

Actor

시스템과 상호작용하는 사용자나 다른 시스템
사람 모양
'사용자', '시스템' 등의 명사로 표현된다.
액터 찾기
- 시스템과 상호작용하나 그 자체에 대한 분석이 필요없는 개체
- 사용자 외에도 관리자, 유지보수자, 시스템과 관련 있는 모든 사람이나 시스템이 고려 대상임

UseCase

시스템이 수행하는 작업
대게 타원으료 표현
'아이디 검색', '실명 인증' 등의 동사로 표현된다.
일련의 사건의 흐름으로 표현된다.
성공적 유스케이스만을 의미하는 것은 아니다.
유사 기능을 표현하는 모든 시나리오를 포함하여 일반화하고 구조화시킨 것

Relation

Actor와 UseCase 사이의 의미있는 관계를 나타낸다.
연관 관계 (Association) : UseCase와 Actor간에 상호작용이 있음을 표현. UseCase와 Actor를 실선으로 연결한다.
포함 관계 (Include) : 하나의 UseCase가 다른 UseCase의 실행을 전제로 할 때 형성되는 관계. 포함되는 UseCase(화살표가 향하는 쪽)는 포함하는 UseCase(화살표가 시작되는 쪽)를 실행하기 위해 반드시 실행되어야 하는 경우에 적용한다. 포함하는 UseCase에서 포함되는 UseCase 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기한다.
확장 관계 (Extend) : 확장 대상 UseCase(화살표가 향하는 쪽)를 수행할 때 특정 조건에 따라 확장 기능 UseCase(화살표가 시작되는 쪽)를 수행하는 경우에 적용한다. 확장 기능 UseCase에서 확장 대상 UseCase 방향으로 화살표를 점선으로 연결하고 <<exclude>>라고 표기한다.
일반화 관계 (Generalization) : 이해도를 높이기 위해 유사한 UseCase 또는 Actor를 모아 추상화한 UseCase 또는 Actor와 연결시켜 그룹을 만드는 것이다. 구체적인 유스케이스에서 추상적인 유스케이스 방향으로 끝부분이 삼각형으로 표현된 화살표를 실선으로 연결하여 표현한다.

❗️ NOTE

System

만들고자하는 프로그램

UseCase를 둘러싸는 사각형으로 표현

Actor는 대게 시스템 외부에 있는 반면, UseCase는 시스템 내부에 존재한다.

UseCase 분석을 통해 시스템과 외부 세계와의 경계를 효과적으로 보여줄 수 있다.

예를 들어, "음료수 출력"이라는 UseCase를 수행하기 위해선 "음료 선택"과 "동전 투입"을 사용해야하므로(필수 조건) Include 관계이며 "거스름 돈 반환"(확장 기능)은 반환해야 할 거스름돈이 있을 경우(특정 조건)에만 동작하므로 "음료수 출력"(확장 대상)을 확장하는 extends 관계이다.

Use-case Diagram 작성 과정

1️⃣ 시스템 상황 분석 (문제기술서 작성)

2️⃣ 액터 식별
주 사용자와 관리자 그리고 그 외에 시스템에 접근하는 사물에 대해서 정의한다.
시스템 외부에 존재하는 타 시스템이나 데이터베이스 서버 등을 표현하기도 한다.

모든 사용자 역할 식별
상호 작용하는 타 시스템 식별

3️⃣ 유즈케이스 식별
사용자가 시스템을 통해 얻으려는 기능을 유스케이스 단위로 식별한다.

Actor가 요구하는 서비스 식별
Actor가 요구하는 정보 식별
Actor가 시스템과 상호 작용하는 행위를 식별

특정 Actor 관점에서 시스템을 사용할 때 필요한 기능들을 생각한다.

4️⃣ 유즈케이스 다이어그램 작성
Actor와 UseCase간 관계와 UseCase 간 관계를 설정한다.

관계 정의
- Actor 간 관계 정의
- Actor와 UseCase 간 관계 분석/정의
UseCase 구조화
- 두 개 이상의 UseCase에 존재하는 공통서비스 추출
- 추출된 서비스를 UseCase에 정의
- 조건에 따른 서비스 수행부분 분석하여 추출
- 추출된 서비스를 사용하는 UseCase와 관계 정의

❗️ NOTE

액터에게 의미있는 기능을 수행하는데 필요한 시작에서 종료까지의 일련을 작업을 모아 하나의 유스케이스로 본다.

유스케이스 크기는 너무 세분화되지 않도록 비즈니스 요건을 포함하지 않는 단순 관리 목적의 CRUD는 하나의 유스케이스로 추출하도록 한다.

Actor 관점에서 1) 완결성이 있는 작업이면서 2) 일정 시간 간격으로 반복되는 유스케이스라면 별도의 분리된 유스케이스로 추출한다.

5️⃣ 유즈케이스 명세서 작성
유스케이스명과 액터명 및 개요를 기술하고 사전 및 사후 조건과 제약사항들을 식별한다. 작업 흐름과 시나리오는 동시에 도출하며 유스케이스를 포함 또는 확장 유스케이스로 구조화한다.

유스케이스명 : 액터가 시스템을 통해 달성할 목적을 명확하게 문장으로 표현
액터명 : 시스템에서 수행하는 역할 이름정도 사용하면 됨
개요 : 유스케이스를 수행하는 개요를 기술
사전조건 : 유스케이스의 기본흐름이 올바르게 동작되기 위해 사전에 충족되어야 하는 조건 기술
사후조건 : 유스케이스가 실행된 후 만족해야 하는 조건 기술
기본흐름 : 시스템과 액터 사이에 목적을 달성하기 위한 기본적인 상호작용 흐름을 기술.
기본 흐름을 수행할 때 어떤 오류나 예외가 발생하지 않고 모든 것이 완전히 수행되는 것을 전제로 함.
기본 흐름의 첫 번째 단계를 해당 유스케이스를 시작하는 사건을 기술하며 이를 트리거 라고 함.
대체흐름 : 기본 흐름으로부터 경우에 따라 선택적으로 실행되고 다시 기본흐름으로 돌아오는 흐름이나 오류 예외가 발생한 경우 이를 처리하는 흐름을 기술함.