일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Util
- Kotlin
- Network
- postman
- OOAD
- Scheduling
- Crawling
- docker
- sequelize
- DATABASE
- MongoDB
- S3
- typeorm
- mysql
- algorithm
- macos
- TypeScript
- HTML
- node.js
- linux
- React
- Express
- python
- Android
- ubuntu
- OS
- mongoose
- AWS
- wireshark
- css
- Today
- Total
Seongwon Lim
[UML] 유스케이스 다이어그램(Usecase Diagram) 완벽 정리 본문
서론
객체 지향 프로그래밍(OOP) 개발에서 가장 중요한 요소 중 하나는 산출물의 명세화, 시각화, 문서화이다.
우리는 위의 3가지 것들을 수행할 때 모델링 기술과 방법론을 통합하여 만든 표준화된 모델링 언어인 UML(Unified Modeling Language)을 사용하여 설계를 한다.
'모델링 언어'라는 단어만 보고 UML을 프로그래밍 언어로 오해하는 사람들이 있지만, UML은 프로그래밍 언어가 아니라 기호, 도식, 도형 등을 통해서 표현하는 것임을 기억해야 한다.
또한, UML은 사물(Things), 관계(Relationships), 다이어그램(Diagrams) 3개의 구성요소로 이루어져 있다.
구성요소 | 내용 |
사물 | - 추상적인 개념, 주제를 나타내는 요소 - 단어 관점에서 '명사' 또는 '동사'를 의미 |
관계 | - 사물의 의미를 확장하고 명확히 하는 요소 - 사물과 사물을 연결하여 관계를 표현하는 요소 - 단어 관점에서 '형용사' 또는 '부사'를 의미 |
다이어그램 | - 사물과 관계를 모아 그림으로 표현한 형태 - 형식과 목적에 따라 9가지로 정의 |
이번 글에서는 UML의 구성요소 중 객체 지향 프로그래밍을 설계할 때 자주 사용되는 UML 다이어그램 중 하나인 유스케이스 다이어그램(Usecase Diagram)에 대한 개념을 알아보고 예제를 통해서 해당 다이어그램의 이해를 돕고자 한다.
유스케이스 다이어그램 (Usecase Diagram)
유스케이스 다이어그램은 시스템이 제공하는 기능, 기능과 관련된 외부 요소를 사용자의 관점에서 표현한 다이어그램이다.
따라서, 실제 비즈니스 로직을 표현하는 것이 아니라 사용자(Actor)가 수행하는 기능이 무엇인지를 파악하고자 할 때 해당 다이어그램을 이용하여 작성한다.
유스케이스 다이어그램은 유스케이스(Usecase), 액터(Actor), 시스템(System), 시나리오(Scenario), 이벤트 흐름(Event flow) 등의 구성요소로 이루어져 있다.
구성요소 | 의미 | 표기법 |
유스케이스 | - 시스템이 제공해야 하는 서비스나 기능 - 액터가 시스템을 통해 수행하는 일련의 행위를 의미 |
|
액터 | - 사용자가 시스템에 대해 수행하는 역할 - 시스템과 상호작용하는 사람 또는 사물 - 이벤트 흐름을 시작하게 하는 객체 |
|
시스템 | - 전체 시스템의 영역을 표현 - 시스템 제공 기능 범위를 나타냄 |
|
시나리오 | - 발생되는 이벤트의 흐름 | - |
이벤트 흐름 | - 사람, 시스템, 하드웨어, 시간의 흐름에 의해 시작 | - |
유스케이스 다이어그램의 관계
관계는 액터-유스케이스, 유스케이스-유스케이스 사이에서 나타날 수 있으며, 관계의 종류는 포함(Include), 확장(Extend), 일반화(Generalization) 3가지 관계가 존재한다.
관계 | 설명 | 사례 |
포함(Include) 관계 | - 유스케이스를 수행할 때 다른 유스케이스가 반드시 수행되어야 하는 관계 - <<include>> 형태로 표현 - 여러 유스케이스에서 공통적으로 발견되는 기능을 표현 |
도서 대출을 위해서는 학생 신원을 확인할 수 있는 학생증을 인식하는 것이 반드시 필요 |
확장(Extend) 관계 | - 포함 관계와 달리 특정 조건에서 한 유스케이스로만 확장되는 관계 - 확장 유스케이스는 특정 조건이 만족되는 상황에서만 확장 유스케이스의 이벤트 흐름이 수행됨 - <<extend>> 형태로 표현 |
도서를 대출하고 난 뒤, 대출한 도서 목록을 확인하기 위한 확인증은 출력을 해도 되고 안해도 상관 없음 즉, 필수적인 것이 아니며 특정 조건을 만족할 때(확인증 출력 버튼을 누름)만 수행됨 |
일반화(Generalization) 관계 | - 추상적인 액터와 좀 더 구체적인 액터 사이에 맺어주는 관계 - 일반화 관계를 사용하면 액터들의 의미를 좀 더 명확하게 표현 가능 - 하위 액터, 유스케이스에서 상위 액터, 유스케이스 쪽으로 속이 빈 삼각형 화살표를 실선으로 연결하여 표현 |
유스케이스 명세서 (Usecase Description)
유스케이스 다이어그램만으로는 해당 유스케이스를 완벽하게 설명할 수 없다. 유스케이스 명세서(기술서)는 유스케이스가 어떻게 목적을 달성할 수 있는지, 시스템과 상호작용 하는 과정을 글로써 기술하는 문서로 유스케이스를 구체화 하는데 도움을 준다.
유스케이스 명세서에 포함되는 항목들은 다음과 같은 것들이 올 수 있다.
- 유스케이스 이름
- 액터명
- 유스케이스 개요 및 설명
- 사전조건, 사후조건
- 이벤트 흐름 - 정상 흐름, 대체 흐름
예를 들어, 무인도서 시스템에서 도서 대출하기 라는 유스케이스가 있다고 한다면 다음과 같이 유스케이스 명세서를 작성할 수 있다.
Use case name (유스케이스 이름) |
도서 대출하기 | |
Scenario | 학생은 대출하고자 하는 책을 스캐너에 인식한다. | |
Triggering event | 학생은 스캐너를 통해서 대출하고자 하는 책에 대한 정보들을 입력하고자 한다. | |
Brief description (개요 및 설명) |
대출을 하기 위해 학생은 학생증의 바코드 혹은 모바일 학생증에 있는 QR 코드를 스캔한 뒤 대출하고자 하는 책들을 스캐너에 넣어 스캔한다. 그리고 화면에 대출할 도서 정보가 맞는지 확인한다. | |
Actors (액터명) | 학생 | |
Related use cases | 확인증 출력하기(extend) | |
Stakeholders | 사서 | |
Preconditions (사전조건) |
대출하고자 하는 도서가 대출 가능한 상태여야 한다. | |
Post conditions (사후조건) |
대출한 도서가 대출 불가능한 상태로 변경되어야 한다. | |
Flow of activities (정상 흐름) |
Actor (학생 관점) | System (무인도서기 관점) |
1. 무인 도서기에 학생증 또는 QR 코드를 스캔한다. 2. 대출하고자 하는 도서들을 무인 도서 스캐너에 넣는다. |
1.1. 스캔한 학생증의 정보를 확인한다. 2.1. 스캐너가 도서에 있는 바코드를 읽고 화면에 대출 권 수, 도서 정보와 반납일, 대출 가능 권수를 보여준다. |
|
Exception conditions (대체 흐름) |
1.1.학생증 바코드 또는 모바일 QR 코드가 올바르지 않은 경우 에러 메시지를 출력하고 첫 화면으로 돌아간다. 2.1.인식된 도서가 대출이 불가능한 경우 에러 메시지를 출력한다. |
유스케이스 명세서의 이벤트 흐름을 작성할 때 액터가 2개 이상이라면 각 액터의 관점에서 이벤트 흐름을 전부 작성하는 것이 좋다.
위에서는 액터를 학생, 무인도서기로 설정했기 때문에 정상 흐름(Flow of activities)을 작성할 때 학생, 무인도서기 2가지 관점에서 모두 작성한 것을 확인할 수 있다.
유스케이스 다이어그램 예제
해당 예제는 무인도서 대출 반납 시스템 예제로 액터는 학생, 무인도서기 2개의 요소로 이루어져 있다.
학생의 관점에서 보면 유스케이스를 크게 3가지로 나눌 수 있다.
- 도서 대출하기, 도서 반납하기, 대출 정보 확인하기
1. 도서 대출하기
학생이 도서를 대출하기 위해서는 학생 신분을 증명해야 한다. 따라서 학생증 또는 QR코드 인식 이라는 유스케이스가 포함 관계(include)로 연결되어 있는 것을 확인할 수 있다. 해당 유스케이스의 목적이 달성되어야만 학생은 도서 대출을 수행할 수 있다.
또한, 확인증 출력 유스케이스의 경우는 도서 대출을 완료한 뒤 학생이 빌린 도서 목록과 정보를 확인증으로 출력할지를 묻는 유스케이스이다. 학생 입장에서는 확인증을 반드시 출력할 필요가 없기 때문에 해당 유스케이스는 확장 관계(extend)로 연결된 것을 확인할 수 있다.
마지막으로 스캐너에 도서 인식 이라는 유스케이스는 학생이 대출할 도서를 스캐너에 인식하기 위한 유스케이스이다. 해당 시스템은 무인도서 시스템이므로 책을 사서를 통해 대출할 수 없다. 따라서, 도서를 대출하기 위해서는 해당 도서를 스캐너기에 반드시 인식해야 하기 때문에 해당 유스케이스는 도서 대출하기와 포함 관계(include)로 연결된 것이다.
2. 도서 반납하기
도서 반납의 경우에는 여러 시스템이 그렇듯 별도의 신분을 확인하지 않는 경우가 많다. 따라서 학생증 또는 QR코드 인식 유스케이스와 연결되지 않은 것을 확인할 수 있다.
그러나 확인증 출력 유스케이스는 학생이 반납한 도서 목록을 출력할 수 있기 때문에 확장 관계(extend)로 연결된 것을 확인할 수 있다.
마지막으로 스캐너에 도서 인식 유스케이스는 반납할 도서를 스캐너에 인식하여 어떤 도서가 반납될 것인지를 알아야 하기 때문에 도서 반납하기 유스케이스와 해당 유스케이스는 포함 관계(include)로 연결을 했다.
3. 대출 정보 확인하기
대출 정보를 확인하기 위해서는 학생 신분 증명이 필요하다. 따라서 학생증 또는 QR코드 인식 이라는 유스케이스가 포함 관계(include)로 연결되어 있어야 한다.
확인증 출력 유스케이스는 대출 정보를 확인하고 본인의 대출 목록을 출력하고 싶은 경우에 확장되어 사용할 수 있는 유스케이스이므로, 대출 정보 확인하기와 해당 유스케이스는 확장 관계(extend)로 연결된 것을 확인할 수 있다.
스캐너에 도서 인식 유스케이스는 대출 정보를 확인할 때에는 사용되지 않는 유스케이스 이므로 해당 유스케이스는 어떠한 연결 관계도 없는 것을 확인할 수 있다.
'OOAD' 카테고리의 다른 글
[OOP] 객체지향 설계 원칙 SOLID - OCP(개방 폐쇄 원칙) 이란? (0) | 2022.09.05 |
---|---|
[OOP] 객체지향 설계 원칙 SOLID - SRP(단일 책임 원칙) 이란? (0) | 2022.09.02 |
[OOAD] 결합도(Coupling) & 응집도(Cohesion) (0) | 2022.07.03 |
[Design Pattern] GoF 디자인 패턴이란? (0) | 2022.06.05 |
[OOAD] GRASP Pattern이란? (0) | 2022.05.24 |