[UML] 유스케이스 다이어그램 (Usecase Diagram) 기초 및 그리는 방법

Usecase Diagram

시스템에서 제공해야 하는 기능이나 서비스를 명세한 다이어그램이다.
사용자와 시스템 사이의 상호작용에 집중하는 것이 특징이다.

외부에서 본 시스템의 기능을 표현하기 때문에, 실제 내부의 비즈니스 로직이 아닌, 사용자가 수행하는 기능을 파악하고 싶을 때 작성한다.

 

Usecase Diagram을 그리는 시기

 

유스케이스 다이어그램은 각종 액터가 프로그램의 기능과 상호작용을 하는 것을 표현하는 것이 메인 컨텐츠이기 때문에 요구사항을 추출하는 분야에 특화되어있다.

그러므로 보통 프로젝트를 시작하고, 제품의 요구사항 명세서를 작성하는 요구분석 단계에서 그려야 한다.

프로젝트의 개발 범위를 정하거나, 사용자의 요구사항을 정의하고, 이 프로그램에 수행해야 하는 기능의 명세를 알아야 할 때 그리게 된다.

Usecase Diagram의 구성요소

1. scope

네모난 상자로 표현되며, 시스템이 제공하는 기능의 범위를 나타낼 때 쓰인다. 

2. useCase

시스템이 제공해주는 서비스와 기능을 나타내며, 사용자의 요구사항을 구조화한 것이다. 

3. actor

액터는 구현 대상이 아닌 시스템 외부에서 시스템과 상호작용 하는 존재다.
무조건 사람일 필요는 없으며, 사람 뿐만 아니라 외부 시스템도 액터로 표현될 수 있다.

 

그리고 액터끼리는 서로 상속되고, 일반화될 수 있다.

- primary actor
시스템을 사용하는 액터, 사람이다.

- secondary actor
시스템과 상호작용하는 외부 시스템, 사람이 아니며, <<actor>>라고 명시해줘야된다.

4. relationship

관계는 액터와 유즈케이스, 유즈케이스와 유즈케이스 사이에 나타나고, 총 4가지 종류가 있다.
4가지 종류가 있음

- association
useCase와 actor의 관계를 표현할 때 쓰인다.
actor는 정보를 통보받거나 요구하고, useCase는 정보를 제공한다.

쉽게 말해서 액터가 유즈케이스를 사용하는 것을 표현한다.

- include
기능을 위한 기능에 사용한다. 

한 useCase가 다른useCase의 수행을 요청할때 쓰이고, 위의 예시에서 찾아보자면

게시글 작성, 게시글 투표 기능은 로그인 기능을 필수적으로 요구하기 때문에,

이해의 편의와 유지보수성을 위해서 로그인 기능을 액터와 association으로 연결하지 않고,

게시글 작성과 게시글 투표에 include관계로 연결시켰다.

 

일반적으로 여러 기능에서 공통으로 사용해야 하는 모듈같은 기능에 추가되는 키워드다.

너무 남발하면 오히려 기능을 파악하는데 역효과가 나기 때문에 적절하게 사용해야 한다.


- generalization
말 그대로 일반화 관계이다.
게시글 투표는 추천 투표, 비추천 투표를 추상화한 기능이므로, 위의 예시처럼 일반화 관계를 설정할 수 있다.

- extended
특정 조건이 만족되는 경우에만 실행되는 기능이다.

위의 예시에서 살펴보자면 사용자는 게시글을 작성할 때 동영상을 첨부 할 수도있고, 첨부하지 않을 수도 있다. 이처럼 기능을 수행할 때, 특정 조건에서만 동작하는 기능은 extend로 표현하면 효과적으로 다이어그램을 작성할 수 있다.

그리는 순서

1. actor 식별 
- 모든 사용자 역할 식별 
- 상호작용하는 외부 시스템 식별 

2. useCase 식별 
- actor가 요구하는 서비스 식별 
- actor가 시스템과 상호작용하는 행위를 식별 

3. relation 정의 
- actor와 actor 관계 
- actor와 useCase 관계 
- useCase와 useCase 관계 

4. useCase 구조화 
- 두 개 이상의 유즈케이스에 존재하는 공통 서비스 추출 
- 특정 조건에서 활성화되는 유즈케이스 추출 

 

주의사항

usecase diagram은 흐름도 아니므로, 기능의 순서대로 그리면 안된다.

모든 기능은 액터가 수행할 수 있는 개별 기능으로 봐야하고, 순서는 꼭 필요한 경우만 include, extend의 용법에 맞춰서 사용해야 한다.


include를 문어발처럼 사용하면 안된다.
include된 유즈케이스도 기능이다. 즉, 액터에서 뻗어나가는 기능으로도 표현할 수 있다는 뜻이다.
여러 유즈케이스에서 사용하는 공통적인 기능이 아니고,

액터에서 뻗어나가는 것이 가장 이상적이다.

유즈케이스 기술서

 

다이어그램 만으로는 상세한 설명을 할 수 없으니, 유즈케이스의 목적을 달성하기 위해서 시스템과 상호작용하는 과정을 기술하는 문서이다.
모든 유즈케이스에 대한 기술서를 작성해야한다.

-유즈케이스 이름
다이어그램에서 쓴 유즈케이스 이름이다. 달성할 목적을 명료하게 표현하면 된다.

- 액터 이름
실제 사람 이름이나 시스템이 아닌 유즈케이스의 시스템에서 수행하는 역할을 중심으로 작성한다.

-개요
유즈케이스 대략적으로 설명하면 된다. 

-사전*사후 조건
기본 흐름이 올바르게 동작되기 위해 사전에 충족되어야 하는 조건
유즈케이스가 종료된 후 만족해야 하는 조건

-기본 흐름
시스템과 액터 사이의 모든 상호작용 흐름을 기술한다.
예외, 오류가 발생한 상황은 취급하지 않으며, 모든것이 정상적으로 작동한다고 가정해서 기술.
항상 기본 흐름의 첫 단계는 해당 유즈케이스를 시작하는 사건을 기술.(Trigger라고 부른다.)
차례대로 순서를 붙여 구조적으로 작성하면  더 깔끔하게 작성할 수 있다.

-대체흐름
기본 흐름으로부터 선택적으로 실행되는 흐름이다.
또는 오류, 예외 등등 정상적이지 않은 흐름도 대체흐름에 기술한다.