[소프트웨어공학] 11. Use Case Diagram
Use Case Diagram
use case diagram 을 그리는 목적은 크게 2가지가 있다.
1. 시스템의 functionality (functional requirement) 를 '사용자의 관점'에서 문서화하는 것
2. 사용자와 시스템 사이의 상호작용을 use case description을 사용해 문서화하는 것
이때 use case description 을 작성하면, 시스템 관점에서 어떤 기능을 개발해야 하는지 명료하게 정리된다.
그러면 이 내용을 기반으로 시스템을 설계하고 구현하면 끝이다.
use case diagram은 철저하게 '사용자의 관점' 에서 작성해야 한다.
사용자가 로그인 화면에서 아이디와 비밀번호를 입력하고 로그인 버튼을 클릭했을 때, 시스템이 사용자 정보를 DB에서 조회하고.. 하는 로직은 명시할 필요가 없다. DB는 '사용자 관점' 이 아니기 때문이다.
사용자 관점에서는 로그인 버튼을 클릭했을 때 정보가 맞다면 메인 화면으로 이동하고, 틀리다면 입력창 밑에 빨간 글씨로 에러 메세지를 보여주는 것과 같은 내용을 적어야 한다.
프로그램의 사용자 메뉴얼을 떠올리면 쉽다.
Use Case Diagram 에서 사용하는 기호의 notation은 위와 같다.
Actor
그림 왼쪽의 사람 모양 notation은 actor를 나타낸다.
액터 밑에는 이름을 적어주는데, 이때 액터는 사람 뿐만 아니라 다른 시스템이나 장치가 갖고 있는 역할을 나타낸다.
사람의 경우 소프트웨어를 사용하는 사람의 역할을 말한다.
쿠팡 사이트에 접속하는 사람을 생각해보면 시스템 관점에서 중요한 것은 그 사람의 '역할' 이다.
그 사람이 '고객 역할'이라면 물건을 구매할 것이고, '판매자 역할'이라면 물건을 등록하는 일을 수행할 것이다.
시스템의 경우 네이버에서 항공권을 구입하려고 할 때, 항공권 조회는 네이버에서 하지만, 실제로 항공권 예약을 위해 정보를 입력하고, 그 정보를 토대로 예약을 진행하는 것은 시스템 외부에 있는 실제 항공사 시스템이다.
이렇게 외부 시스템을 통해 현재 시스템의 특정 기능을 수행하는 경우에도 외부 시스템을 사람 형태의 actor 로 표현한다.
장치(device)의 경우, 기상청 시스템을 생각할 수 있다.
각종 기상 정보를 센서를 통해 수집한 뒤, 그 정보를 한 곳에 모아서 예보를 작성하는 시스템의 경우, 외부 센서가 시스템에 데이터를 보내야 한다. 이렇게 센서와 시스템이 소통할 때 센서 역시 사람 형태의 actor로 표현한다.
역할은 특정 use case 와 관련하여 communication 을 할 때의 역할을 말하며, 직책이나 사람 자체를 의미하지 않는다.
예를 들어 회사의 관리자 화면을 들어갈 수 있는 '어드민 유저' 를 액터로 표현할 때, 액터는 '어드민' 이지 부장, 차장, 과장과 같은 직책을 적지 않는다. 부장, 차장, 과장도 모두 시스템에서 어드민 역할을 수행할 수 있다.
즉, '어드민' 이라는 역할 하나는 현실에서 여러개의 job title을 가질 수 있고, 한 명의 사람도 여러 개의 역할을 가질 수 있다.
그리고 모든 액터는 하나 이상의 use case와 연결되어있다.
Use Case
그림에서 타원형으로 나타낸 것은 use case 이다.
타원형 속이나 밑에 이름을 적어주며, 액터에게 어떤 결과를 주기 위해 시스템에서 수행하는 액션들을 묘사한다.
(이때 액션들은 '우리 시스템' 에서 일어나는 일이어야 한다. 외부 시스템이나 시스템과 상관없는 액션들은 use case로 그리지 않는다.)
또한 그 액션을 어떻게 처리하는지는 필요없고, 그 액션의 결과가 어떻게 되는지만 표현해주면 된다.
자세한 내용은 나중에 use case description에 적는다.
Communication Associations
액터와 use case 사이에 긋는 선을 가리킨다.
어떤 액터가 어떤 use case 를 사용하는지 나타내며, 필요한 경우 어디에서 커뮤니케이션이 시작되는지 화살표로 나타낼 수 있다.
이때 화살표의 방향은 커뮤니케이션이 시작된 쪽에서부터 향하는 쪽으로 그려주면 된다.
대부분의 경우에는 actor 가 시작하지만, 결제 시스템같이 외부 시스템에 데이터를 보내는 경우 use case 에서 액터로 화살표가 갈 수도 있다.
Sub-System
직사각형으로 같은 sub system에 속한 use case 를 감싸서 표현한다.
(use case 만 감싸야하며 액터는 감싸지 않는다.)
보통 다른 서브 시스템에 속한 use case 를 그릴 때는 별도의 use case diagram 에 나눠서 그린다.
계층을 나눠서 하나의 다이어그램에 모든 것을 그리지 않고 디테일한 부분은 나눠서 그린다.
지금까지의 내용으로 회사의 인사 및 급여 관리 시스템을 use case diagram 으로 간단하게 그려볼 수 있다.
회계 직원이라는 역할을 가진 시스템 액터는 새로운 직원 추가 / 새로운 직급 추가 / 직급 별 보너스 비율 수정 / 직원 보너스 계산 기능을 수행할 수 있으며, 화살표를 통해 이 기능들은 모두 회계 직원 역할의 actor 로부터 시작되는 기능들임을 나타낸다.
그리고 이 use case 를 '직원 관리' 라는 서브 시스템으로 묶어서 표기할 수 있다.
use case 를 작성하다보면 use case 와 use case 사이에 의존 관계가 존재하기도 한다.
use case 간 관계는 크게 extend 관계와 include 관계가 있다.
use case 가 특정한 상황에서만 발생하는 경우에 사용할 수 있으며, << >> 기호를 사용하여 << extend >> 또는 << include >> 와 같이 표기한다.
Extend relationship
어떤 use case 가 '다른 use case를 필요로 할 수도 있는 추가적인 기능을 제공하는 경우'를 나타낸다.
즉, extend relationship 은 이 기능을 수행해도 되고 안해도 되는 option 기능을 표현하는데 사용한다.
필요한 경우 extension points 를 기술하기도 한다.
extension point 는 언제 이 extension이 발생하는지를 기술한 것으로, condition note 로 기술한다.
단, extension relationship 을 사용할 때는 어떤 기능의 실행 순서나 시스템 메뉴를 나타내는데 쓰지 않도록 주의해야 한다.
예를 들어 쇼핑몰을 이용할 때 로그인하고나서 상품조회/구매/구매내역 조회를 할 수 있다고 해서, 이 모든 기능을 로그인의 extend 로 두면 안된다. 이렇게 그리면 그냥 사이트맵이 될 뿐이다.
어떤 요구사항으로부터 use case 를 그릴 때는 '하나의 화면' 을 하나의 기능으로 만드는 것으로 생각하면 좋다.
예를 들어 홍보 담당자가 마케팅 예산을 확인하는 화면으로 들어가면 각 마케팅 별로 예산이 얼마가 책정되었고, 얼마가 쓰였고, 얼마가 남았는지 '한 화면'에서 조회할 수 있을 것이다.
그런데 그 화면에서 '프린트' 버튼을 클릭해서 예산 현황 요약 보고서를 출력하는 기능이 있다고 해보자.
마케팅 요약보고서를 출력하는 기능은 '하나의 화면' 이 아니다.
프린트 버튼을 클릭했을 때만 수행되는 부가적인 기능이다.
만약 유저가 예산 조회 화면에 들어왔는데 프린트 버튼을 클릭하지 않는다면 마케팅 요약 보고서 출력 기능은 수행하지 않는다.
따라서 이런 option 성격을 가진 use case 는 extend 관계로 표현한다.
말 그대로 주기능인 '마케팅 예산 조회' 기능을 확장시켜주는 것이다.
extend 관계를 표현할 때 화살표의 방향은 option -> 주 기능 방향으로 그린다.
또한 그림에서는 extension point 와 condition 을 기술했는데, 이 부분은 생략할 수 있다.
정리하면 extend 관계는 하나의 화면에서 여러 use case 가 있는데, 같은 화면에서 주요 use case 가 있고, option use case 가 있으면 option use case 를 주요 use case 와 extend 관계로 표현할 수 있다.
Include relationship
하나의 use case가 다른 use case에 항상 포함되는 경우 사용한다.
예를 들어 마케팅을 검색하는 화면이 있고, 마케팅에 직원을 할당하는 화면이 있다고 했을 때
마케팅에 직원을 할당하려면 어떤 마케팅에 할당할 지, 마케팅을 검색하는 화면을 항상 거쳐야만 한다.
이런 상황일 때 후행하는 use case 에서 선행하는 use case 쪽으로 화살표를 그어서 include 관계를 표시한다.
그런데 위 그림과 같은 include 관계에서 '마케팅에 직원을 할당하는 기능' 은 '마케팅 검색' 기능이 없어도 변하지 않는다.
include 관계는 마케팅 직원을 할당하는 기능을 수행할 때 검색 기능도 필요하다는 것을 부가적으로 알려주는 역할이다.
따라서 include 관계는 꼭 쓰지 않아도 괜찮다.
또한 include 관계는 (위에서 예시를 위해 하나만 그렸지만) '많은 use case' 가 공통적으로 선행해야 하는 경우에 사용한다.
따라서 하나의 기능만 관련이 있는 경우에는 include 관계를 사용할 수 없다.
그리고 시스템 기능의 계층 구조를 나타내는데 사용되어서도 안된다.
예를 들어 마케팅을 검색하는 기능 밑에 타이핑하는 기능이 포함된다는 식으로 쓰면 안된다.
오직 여러 use case 가 공통으로 하나의 use case 를 포함하고 있을 때만 사용한다.
(하지만 교수님이 include를 다들 잘 못쓴다고 시험과 과제에서 include 관계는 그냥 쓰지 말라고 하셨다.)
지금까지의 내용을 종합하면 위와 같이 use case diagram 을 그릴 수 있다.
홍보 담당자는 마케팅 직원 할당, 마케팅 광고처 추가, 예산 조회, 견적서 출력 기능을 수행할 수 있다.
이때 마케팅 예산 조회 화면을 통해서 예산 보고서와 견적서를 출력하는 기능을 수행할 수 있다.
(option 기능이라고 actor 와 연결될 수 없는 것은 아니다)
또한 직원할당, 광고처 추가, 예산 조회 기능을 수행할 때는 마케팅을 검색하는 기능을 거쳐야 한다.
마케팅 검색 화면은 유저가 직접 사용하고자 해서 사용하는 기능은 아니지만, 다른 기능을 수행할 때 공통적으로 사용하게 되는 화면이다.
Generalization
공통 기능이나 역할을 super use case 또는 super actor 로 묶어서 표현하는 것을 말한다.
예를 들어 마케팅 관리 시스템을 사용할 때 로그인이 필요하고, 홍보 담당자 이외의 역할들이 존재한다면, 모든 역할은 '로그인' 이라는 공통기능을 수행한다.
이를 위해 '회원' 이라는 모든 역할의 공통 역할을 빼고, 회원 역할이 로그인 기능을 수행하는 것으로 표현할 수 있다. (super actor)
(그림은 예시를 위해 sub class 가 1개인 것만 표현했지만, 실제로는 sub class가 여러 개 있어야 super actor를 만들 수 있다.)
만약 마케팅에 직원을 할당하는 기능으르 세부적으로 쪼개서 '개인 직원 할당' 과 '스태프 팀 할당' 으로 나눈다고 하면, 두 기능의 공통 기능인 '직원 할당' 기능을 super use case 로 표현할 수 있다.
generalization 표현도 사실 꼭 표현할 필요는 없다.
세부 기능은 충분히 잘 명시하고 있기 때문에 generalization 은 이해를 돕는 역할을 하기 때문이다.
물론 필요에 따라 super actor 는 표현하는 것이 좋을 때가 있지만, super use case 는 꼭 표현하지 않아도 괜찮다.
Use Case Description
use case 를 적을 때 굉장히 간단하게 적기 때문에, 각 use case 를 더 자세히 풀어서 적은 문장을 말한다.
예를 들어 '마케팅에 직원 할당' 이라는 use case 가 있었다고 해보자.
use case description 은 다음과 같이 적을 수 있다.
description
홍보 담당자가 특정 마케팅을 선택한다.
아직 해당 마케팅에 할당되지 않은 직원들이 리스트로 보인다.
그리고 해당 마케팅에 할당하고자 하는 직원을 선택한다.
intention
홍보 담당자는 어떤 스태프가 어떤 마케팅을 담당해서 일하고 있는지 기록하고 싶다.
이 정보는 근무 현황과 각 직원의 연간 보너스 급여를 계산할 때 활용된다.
또는 다음과 같이 단계에 따라 적을 수도 있다.
이렇게 표현하고 나면 우리가 개발해야 할 기능은 '시스템 응답' 에 해당하는 기능들만 개발하면 된다.
Use Case Diagram을 그리는 과정
1. Actor 와 Use case를 먼저 파악한다.
2. use case 의 우선순위를 결정한다.
3. 우선순위가 높은 use case 부터 시작하여 description 을 작성한다.
4. use case model 에 대해 generalization, include / extend relationship, subsystem 과 같은 부가적인 구조를 그려준다.