38_[db]유스케이스 모델링
유스케이스 모델링
- 이벤트 및 반응 방식 시스템 개발에 효율적인 기능적 모델링 방법(블랙박스 모델링 방법 중 하나) ▶️ 동적(행위) 다이어그램
- 시스템 기능을 사용하는 사용자와 시스템 간 교류를 표현한 것
- 사용자 관점에서 시스템의 요구사항(행동)을 설계하는 것
- 초기 요구사항 분석부터 마지막 시험, 배치 등 전 공정에서 사용할 수 있는 수단
- 시스템이 해야할 일(Use Case)와 그 행동을 해야 하는 사용자(Actor)를 함께 표현
- 액터와 유스케이스, 관계로 구성
(예시- source: https://www.edrawmax.com/article/use-case-diagram-examples.html)
🌺 액터 Actor 🌺
위의 유스케이스 예시에서 졸라맨(? 사람?) 모형이 바로 “액터”!!
- 시스템과 상호작용을 하는 시스템 외부 존재
- 개발 대상에 따라 달라질 수 있고, 시스템 관점에서 바라본 사용자의 역할을 의미해야 함!(예: 회원, 비회원)
- 시스템 외부에 존재해야 함
🌟 상자모양은 “시스템(System Boundary)”을 의미하는데, 이 상자를 안그리는 경우가 있는데, 꼭!! 그려야 한다!(액터와의 경계를 표시하기 위함)
🌺 유스케이스 Use Case 🌺
- 개발 대상이 되는 시스템이 제공하는 개별적인 기능
- 시스템 동작 하나의 사용자가 인지할 수 있는(눈에 보이는) 하나의 기능 단위 ▶️ 사용자가 인지할 수 없는 기능은 그리지 말것!!
- 동그란 타원형태로 그려짐!
예) 도서 대출 신청, 신착 도서 등록
- 구체적이어야 함!(따라서 입출금과 이체라는 유스케이스가 있다면, 입금 출금 이체 의 3 개의 유스케이스로 보다 구체화해야 할 필요성이 있음!)
- 그렇다고 다양항 세부상황을 모두 그릴 필요는 없다!( 예: 엘리베이터 사용자는 위 혹은 아래로 이동할 수 있는데 이를 ‘위쪽 엘리베이터 요청’, ‘아래쪽 엘리베이터 요청’으로 유스케이스를 구체적으로 적을 필요는 🚫
[이 경우, 엘리베이터 사용자 ▶️ 엘리베이터 요청 이 보다 적절]
그리고 이를 클래스 다이어그램에서도 연결시키면, 여러 유스케이스와 연결되는 어떤 유스케이스가 있다면 관계를 표시하지 않고 따로 독립적으로 두는 것이 보다 나은 경우도 있다!
🌟 단순히 액터와 유스케이스간에만 관계가 국한되지 않고, 유스케이스와 유스케이스 간에도 관계가 형성될 수 있다!!
🌺 유스케이스 다이어그램의 관계 종류 🌺
- 유스케이스에서도 시간의 흐름이 존재할 수 있음
- 기능분류 혹은 주요 필수 기능에 따라 독립적인 유스케이스로도 분리 가능
- 유스케이스 하나는 항상 동일한 기능을 제시해야 함!(예: 관리자의 회원관리는 정보수정 등으로 같은 흐름이지만, 회원 등록은 외부에서 등록하는 것이기 때문에 관리자의 회원관리 기능이 아니라고 보는 것이 보다 적합하다!
-액터와 제품조회, 제품주문, 주문결제 유스케이스가 있는데, 유스케이스 나열을 “제품조회” “제품주문” “주문결제” 순으로 나열한 경우
- 연관 관계 - 꼭! 액터와 유스관계간에서만 그려져야 한다!!
- 유스케이스와 액터 간 상호작용을 의미
- 실선으로 표시되며, 방향성을 가짐
🌻 연관 관계의 방향성 🌻
- 연관 관계의 방향성은 화살표의 끝(end)가 액터를 가리키는지 , 유스케이스를 가리키는지에 따라 크게는 2개 타입, 세분화하면 3개 타입으로 나눌 수 있다
- 액터 ➡️ 유스케이스
- 화살표의 끝이 유스케이스에 닿는 방향성을 “활성화” 방향성이라 명명할 수 있다!!(화살표의 start=액터)
- 유스케이스 ➡️ 액터
- 화살표의 끝이 액터에 닿는 방향성을 “수행결과 통보”, “외부 서비스 요청” 방향성 이라하는데 액터 입장에서 “수동적”이지 않은가?(화살표의 start=유스케이스)
- 수행결과 통보 : 유스케이스 결과가 액터에게 통보됨
- 외부 서비스 요청 : 외부 시스템에 서비스 실행을 요청
- 포함관계 - 반드시 해야 하는 관계(포인트는 화살표의 start 가 어떻게 되는지!! ▶️ 확장관계에서도 start!! UML은 start!)
- 화살표의 end와 start에 따라 필요조건같은 관계가 요구되는, 선택-필수 관계가 존재하는 관계!
- 화살표의 start 부분은 end가 반드시 필요한 필수 관계(기본 유스케이스)
- 화살표의 end부분은 굳이 start가 필요없는 선택 관계(포함 유스케이스)
UML-유스케이스 포함관계
🌟 관계를 이을 때에는 , 점선과 함께 include 라는 스테레오 타입이 필요하다!
🌟 포함 유스케이스가 여러 유스케이스에서도 재사용된다면 그 효율성이 증가될 것!
- 확장 관계 - 선택적으로 할 수 있는 관계
- Extension Points: 사용자가 어떤 선택을 하는지를 나타냄(생략하고 나타내기도 함!)
- «extend» 스테레오타입과 점선을 이용
UML 유스케이스 - 확장관계
역시, 이 부분에서도 start입장을 봐야하는데, 파일업로드의 입장에서 end인 게시판등록을 하는데에 꼭 필수적인 것이 아니기 때문에 선택적인 관계인 “확장관계”에 해당된다!
- 일반화 관계
- 유사한 유스케이스들 또는 액터들을 추상화한 하나의 유스케이스로 그룹핑하여 이해도를 높인 관계
UML 유스케이스 - 일반화 관계
상속관계같기도 하다!
(예) <결제 관련="" 업무="" 기술서="">
- 상품 결제 시 카드 결제를 통해 할 수 있다
- 상품 결제 시 온라인 송금을 통해 결제할 수 있다
- 상품 결제 시 휴대폰 결제를 통해 결제할 수 있다
▶️ 상품 결제 ⊃ 카드결제, 온라인 송금, 휴대폰 결제
그렇기 때문에 카드렬제와 온라인 송금, 휴대폰 결제를 묶어서 상품 결제에 상속받도록 할 수 있다!
🌟 유스케이스 다이어그램 수업 실습
1) 액터 식별
2) 유스케이스 식별
3) 유스케이스 다이어그램 작성
🌟 유스케이스 시나리오
🌺 이벤트 흐름 🌺
- 기본흐름
- 아무것도 잘못된 것이 없다는 가정 하에 사용자의 자극에 시스템이 어떤식으로 동작할 지 기술
- 대안 흐름
- 세부 상황 중 일부가 잘못되었을 경우를 고려한 흐름
- 선택흐름 : 사용자 혹은 시스템에 의해 선택적으로 수행되는 흐름
- 예외흐름: 시스템에서 발생하는 에러 등을 처리하기 위해 수행되는 흐름
유스케이스 설계 후 유스케이스 시나리오를 작성해야 한다!!