유스케이스 다이어그램(use case diagram)
소프트웨어 개발 생명주기을 기억하는가?
바로, 계획 → 요구 분석 → 설계 → 구현 → 테스트 → 사용 및 유지보수 이다.
잊었다면, 반복을 통해 필히 암기하자.
오늘은 이중에서 요구 분석 파트의 유스케이스 다이어그램에 대해 살펴보고자 한다.
유스케이스(use case)를 한국말로 직역하면 '사용 사례'이다. 말 그대로 시스템의 동작을 사용 사례를 기반하여 그림으로 표현하는 것이다.
아직 무슨 말인지 잘 와닿지 않을 것이다. 예를 들어, 은행 업무와 관련된 소프트웨어를 개발하기 위해 요구 사항을 작성해야 한다고 가정하자. 머리로는 괜찮은 아이디어가 있더라도 무작정 글이나 말로 설명하는 것은 쉽지 않으며 타인이 온전히 그 내용을 이해하는 것 또한 쉽지 않다. 하지만 시중 은행의 여러 어플리케이션을 파악하고 고객, 은행의 입장(시스템 외부)에서 내부 시스템을 바라보며 각 사용자별로 기능을 연결하면 차후 설계 단계에서 훨씬 수월할 것인데 그 역할을 해주는 것이 바로 유스케이스 다이어그램이다. 즉, 시스템의 기능을 나타낼 때 외부에서 보는 내부 시스템의 동작(기능)에 초점을 두고 그리면 쉽기 때문에 유스케이스 다이어그램을 작성하는 것이다.
유스케이스를 분석하는 작업은 아래의 3단계로 이루어진다.
- 액터 찾기
- 유스케이스 찾기
- 유스케이스 사이의 관계 찾기
위 과정에 의한 최종 산출물이 유스케이스 다이어그램과 유스케이스의 명세이다.
유스케이스 다이어그램(use case diagram)
유스케이스 다이어그램은 위 그림과 같이 생겼으며, 아래의 4가지의 요소로 구성된다.
- 시스템(Systems)
- 액터(Actors)
- 유스케이스(Use Cases)
- 관계(Relationships)
유스케이스 다이어그램이 시스템의 기능을 나타내기 위하여 사용자의 요구를 추출하고 분석하는데 사용하는 그림이므로 시스템은 쉽게 와닿는다. 하지만 액터, 유스케이스, 관계는 처음 보면 잘 와닿지 않으니 하나씩 살펴보자.
액터(Actors)
액터는 시스템 내부가 아닌 시스템 밖에 있는 요소이다. 시스템 밖에 있기 때문에 유스케이스 다이어그램을 살펴봐도 시스템을 뜻하는 큰 네모 박스 밖에 액터(사람 모양)가 위치하는 것을 확인할 수 있다.
액터는 사람이 될 수도 있고 외부 시스템이 될 수도 있다. 가령 은행 시스템이라고 가정한다면, 고객과 관리자, 은행 시스템이 액터가 될 수 있을 것이다. 은행 시스템이 액터가 될 수 있다는 점에서 꼭 사람일 필요는 없다는 것 또한 알 수 있다. 그리고 은행의 관리자이면서 그 은행의 고객이 될 수도 있을텐데 같은 사람이더라도 다른 기능을 수행하므로 이는 다른 액터로 표시해야 한다.
자, 이제 한 가지 질문을 해보겠다. 유스케이스 다이어그램을 작성할 때 액터가 없는 경우가 있을까?
답은 "무조건 액터는 존재한다."가 맞다. 왜냐하면 시스템의 기능을 그림으로 나타내는 것이 유스케이스 다이어그램인데 시스템을 사용하는 사용자는 반드시 존재하므로 적어도 1개 이상의 액터가 존재한다.
앞서 설명한 유스케이스를 분석하는 순서 중에서 가장 첫 번째 단계도 액터를 찾는 것인 것을 보면 액터를 파악하는 것이 중요하다는 것을 알 수 있다. 액터를 찾을 때는 아래와 같은 질문들을 활용해 보면 쉽게 찾을 수 있다.
- 어떤 사용자들이 작업을 수행하기 위하여 시스템의 지원을 받는가?
- 어떤 사용자들이 시스템의 주요 기능을 사용하는가?
- 어떤 사용자 그룹이 유지 보수와 관리 등의 부수적인 기능을 사용하는가?
- 시스템이 어떤 외부 하드웨어나 소프트웨어 시스템과 동작하는가?
유스케이스(Use Cases)
유스케이스는 액터에게 보이는 시스템의 기능을 나타낸다. 기능과 비슷한 다른 말로는 역할이 있는데 액터가 사용하거나 필요한 것들이다.
즉, 시스템이 실행하는 하나의 동작으로 유스케이스 다이어그램에 작성한 특정 액터가 관찰할 수 있는 실행 결과를 제공하는 것이다.
예를 들면 바로 이해할 수 있을 것이다. 은행 시스템에서 고객 액터가 있다면, 고객이 ATM 기기를 사용한다고 해보자. 그러면 고객은 ATM기의 디스플레이에 송금, 출금, 이체, 조회 등의 기능을 확인할 수 있다. 이러한 각각의 기능이 유스케이스이다. 또한 이를 위해 비밀번호를 인증해야 하므로 인증 또한 유스케이스이다. 참고로 유스케이스는 개발자 관점이 아니라 사용자(actors) 관점에서 작성해야 하기 때문에 개발자와 사용자가 함께 작성한다.
앞서 설명한 유스케이스를 분석하는 순서 중에서 두 번째 단계가 바로 유스케이스를 찾는 것이다.
유스케이스를 찾아낼 때는 아래의 질문들을 활용하면 쉽게 찾을 수 있다.
- 찾아낸 각 액터에 대해 시스템과 관련된 작업은 무엇인가?
- 시스템에서 발생되는 특정 사건에 대하여 액터에게 알려야 하나?
- 액터가 갑작스런 외부 변화에 대해 시스템에 알려야 할 것인가?
- 시스템이 비즈니스에 정확한 동작을 제공하나?
- 찾아낸 유스케이스로 모든 기능을 수행할 수 있는가?
- 어떤 유스케이스가 시스템을 지원하고 유지보수하나?
- 시스템에서 어떤 정보를 수정하거나 만들어야 하나?
관계(Relationships)
이때까지 여러 차례 은행 시스템을 예시로 설명했는데, 관계를 설명하기 전에 온라인 은행 시스템에 대해 유스케이스 다이어그램을 작성된 예시를 살펴보면서 지금까지 학습한 내용을 상기해보자.
먼저 시스템은 직사각형으로 그려지고 가장 상단 중간에 시스템명을 작성한다. 따라서 위 그림에서 직사각형의 중앙 상단을 보면 'Banking System'이라고 되어 있는 것을 확인할 수 있다. 다음으로, 액터를 찾는데 위 예시에서는 고객, 직원, 은행, 관리자를 액터로 두었다. 다음으로 유스케이스를 찾아 각각을 시스템 내부에 타원을 활용해 작성하였다는 것을 확인할 수 있다.
자, 이제 관계에 대해 알아보자.
위 그림에서 Add Account(계좌 추가), Check Balance(잔액 조회), Transfer(이체) 등은 Customer(고객)와 연결되어 있다. 즉, 기본적으로 사용자와 관련된 기능은 실선으로 연결하고 이를 연관 관계라고 한다.
이제 그림을 조금 더 유심히 살펴보자.
점선 화살표로 연결되어 있으며 <<include>> 또는 반대 방향으로 연결되어 있으면서 <<extend>>라고 적힌 것들을 찾아볼 수 있다.
<<include>>는 포함 관계를 나타내는 화살표이고 <<extend>>는 확장 관계를 나타내는 화살표이다.
모양도 흡사하고 이름도 어려워서 잘 와닿지 않을 것이다. 아래 예시를 한번 보자.
인터넷뱅킹 사용자 액터는 즉시 이체 그리고 자동 이체와 연관 관계를 갖고 있다.
그리고 즉시 이체를 실행하는 경우 이체를 하기 전, 잔고에 돈이 있는지 잔고 및 한도를 조회해야 하므로 각각에 대해서 포함 관계가 있다. 즉 잔고 조회 유스케이스와 한도 조회 유스케이스는 포함 관계의 대상이 된다.
즉시 이체는 반드시 있어야 하는 기능이지만 추가 이체는 선택 사항인데, 이 경우 즉시 이체를 확장한 개념이므로 즉시 이체와 추가 이체는 확장 관계이다.
포함 관계(include relationships)와 확장 관계(extend relationships)를 비교하는 아주 좋은 설명이 있어 추가로 살펴보자.
위 유스케이스 다이어그램은 재채기(Sneeze)를 하는 상황을 가정한 것이다.
재채기를 하면 반드시 눈을 감는데(Close eyes) 이는 포함 관계이다. 그리고 때에 따라서 실례합니다(Say "Excuse me")를 하는데 이는 반드시 일어나는 상황이 아니라 주변에 사람이 있는 경우에 선택적으로 하는 상황이므로 확장 관계이다.
이제 차이를 알겠는가? 반드시 필요한 관계는 포함 관계, 때에 따라 선택적으로 필요한 관계는 확장 관계이다.
지금 내용까지 잘 따라왔다면 유스케이스 다이어그램을 그리는데 어려움이 없을 것이다.
하지만 유스케이스 다이어그램에서 각각의 유스케이스는 시스템의 기능만을 간단하게 명시한 것으로 1개의 유스케이스에는 반드시 1개의 유스케이스 명세가 필요하다. 유스케이스 명세는 각 유스케이스에 대해 시간이 흐르는 순서에 따라 상세하게 글로 작성하는 것이다.
유스케이스 명세에는 다음과 같은 내용이 포함된다.
- 시나리오가 시작될 때 외부 시스템이나 사용자가 기대하는 것
- 시나리오에서 일어나는 사건에 대한 기본 흐름
- 문제가 발생되는 비정상적인 사건에 대한 대안 흐름
- 동시에 병행으로 일어나는 다른 활동에 관한 정보
- 시나리오가 종료되었을 때 시스템의 상태에 대한 정보
은행 시스템에서 이체(transfer)라는 유스케이스가 있다고 가정하고 이 유스케이스에 대해 유스케이스 명세서를 작성해보면 아래와 같다.
| 시스템 제목 | 은행 시스템 |
| 유스케이스 이름 | 이체 |
| 액터 | 고객, 은행 시스템 |
| 시작 조건 | 1. 고객은 시스템에 로그인해야 한다. 2. 송금하는 고객의 계좌에는 충분한 잔액이 있어야 한다. |
| 기본 흐름 | 1. 고객이 시스템에 로그인한다. 2. 고객은 "이체" 옵션을 선택한다. 3. 고객은 다음 정보를 입력한다: - 송금 계좌 번호 - 수취 계좌 번호 - 이체 금액 - 송금자명 (선택 사항) 4. 고객은 "확인" 버튼을 클릭하여 이체 정보를 검토한다. 5. 이체 정보가 올바르다면, 고객은 "전송" 버튼을 클릭한다. 6. 시스템은 이체를 처리하고, 처리 결과를 화면에 표시한다. 7. 이체가 성공하면, 송금 및 수취 계좌의 잔액이 업데이트된다. 8. 이체 거래 정보는 거래 내역에 기록된다. |
| 대안 흐름 | 6a - 이체 과정 중에 오류가 발생할 경우, 시스템은 오류 메시지를 표시하고 고객에게 오류 해결을 돕는 안내를 제공한다. - 송금 계좌에 충분한 잔액이 없을 경우, 시스템은 이체를 거부하고 관련된 메시지를 표시한다. |
| 종료 조건 | 이체가 성공하면, 송금 계좌의 잔액은 감소하고, 수취 계좌의 잔액은 증가한다. 이체 거래 정보는 고객 및 시스템의 거래 내역에 기록된다. |
주의할 점은 정상적인 흐름만이 아니라 오류, 예외 케이스에 대한 대안 흐름도 작성해야 한다는 것을 잊지 말자.
이제 유스케이스 다이어그램, 유스케이스 명세를 작성하는 방법까지 모두 알아 보았으니 준비는 끝났다.
종이와 펜만으로도 작성할 수 있지만 유스케이스 다이어그램을 PC를 활용한다면 더 쉽게 그릴 수 있는데 유용한 도구로 루시드 차트를 소개한다.
루시드 차트(lucid chart): https://www.lucidchart.com/
Intelligent Diagramming | Lucidchart
Lucidchart is your solution for visual communication and cross-platform collaboration.
www.lucidchart.com
아래 유튜브를 참고하면 쉽게 활용할 수 있을 것이다.
https://www.youtube.com/watch?v=zid-MVo7M-E
'Software Engineering' 카테고리의 다른 글
| [Software Engineering] 객체지향 원리 (1) | 2023.10.31 |
|---|---|
| [애자일 방법론] 스크럼 기법(Scrum) (1) | 2023.10.05 |
| [소프트웨어 공학] 프로토타이핑 모델(Prototyping Model) (0) | 2023.09.24 |
| [소프트웨어 공학] 폭포수 모델(Waterfall Model) (0) | 2023.09.24 |
| [소프트웨어 공학] 주먹구구식 개발로 인한 소프트웨어 위기, 소프트웨어 공학의 시작 (0) | 2023.09.21 |