3 minute read

유스케이스 모델링

  • 이벤트 및 반응 방식 시스템 개발에 효율적인 기능적 모델링 방법(블랙박스 모델링 방법 중 하나) ▶️ 동적(행위) 다이어그램
  • 시스템 기능을 사용하는 사용자와 시스템 간 교류를 표현한 것
  • 사용자 관점에서 시스템의 요구사항(행동)을 설계하는 것
  • 초기 요구사항 분석부터 마지막 시험, 배치 등 전 공정에서 사용할 수 있는 수단
  • 시스템이 해야할 일(Use Case)와 그 행동을 해야 하는 사용자(Actor)를 함께 표현
  • 액터와 유스케이스, 관계로 구성

(예시- source: https://www.edrawmax.com/article/use-case-diagram-examples.html)

https://images.edrawmax.com/examples/use-case-diagram-examples/example2.jpg

🌺 액터 Actor 🌺

위의 유스케이스 예시에서 졸라맨(? 사람?) 모형이 바로 “액터”!!

  • 시스템과 상호작용을 하는 시스템 외부 존재
  • 개발 대상에 따라 달라질 수 있고, 시스템 관점에서 바라본 사용자의 역할을 의미해야 함!(예: 회원, 비회원)
  • 시스템 외부에 존재해야 함

🌟 상자모양은 “시스템(System Boundary)”을 의미하는데, 이 상자를 안그리는 경우가 있는데, 꼭!! 그려야 한다!(액터와의 경계를 표시하기 위함)

🌺 유스케이스 Use Case 🌺

  • 개발 대상이 되는 시스템이 제공하는 개별적인 기능
  • 시스템 동작 하나의 사용자가 인지할 수 있는(눈에 보이는) 하나의 기능 단위 ▶️ 사용자가 인지할 수 없는 기능은 그리지 말것!!
  • 동그란 타원형태로 그려짐!

예) 도서 대출 신청, 신착 도서 등록

  • 구체적이어야 함!(따라서 입출금과 이체라는 유스케이스가 있다면, 입금 출금 이체 의 3 개의 유스케이스로 보다 구체화해야 할 필요성이 있음!)
  • 그렇다고 다양항 세부상황을 모두 그릴 필요는 없다!( 예: 엘리베이터 사용자는 위 혹은 아래로 이동할 수 있는데 이를 ‘위쪽 엘리베이터 요청’, ‘아래쪽 엘리베이터 요청’으로 유스케이스를 구체적으로 적을 필요는 🚫

[이 경우, 엘리베이터 사용자 ▶️ 엘리베이터 요청 이 보다 적절]

그리고 이를 클래스 다이어그램에서도 연결시키면, 여러 유스케이스와 연결되는 어떤 유스케이스가 있다면 관계를 표시하지 않고 따로 독립적으로 두는 것이 보다 나은 경우도 있다!

🌟 단순히 액터와 유스케이스간에만 관계가 국한되지 않고, 유스케이스와 유스케이스 간에도 관계가 형성될 수 있다!!

🌺 유스케이스 다이어그램의 관계 종류 🌺

  • 유스케이스에서도 시간의 흐름이 존재할 수 있음
  • 기능분류 혹은 주요 필수 기능에 따라 독립적인 유스케이스로도 분리 가능
  • 유스케이스 하나는 항상 동일한 기능을 제시해야 함!(예: 관리자의 회원관리는 정보수정 등으로 같은 흐름이지만, 회원 등록은 외부에서 등록하는 것이기 때문에 관리자의 회원관리 기능이 아니라고 보는 것이 보다 적합하다!

-액터와 제품조회, 제품주문, 주문결제 유스케이스가 있는데, 유스케이스 나열을 “제품조회” “제품주문” “주문결제” 순으로 나열한 경우

  1. 연관 관계 - 꼭! 액터와 유스관계간에서만 그려져야 한다!!
    • 유스케이스와 액터 간 상호작용을 의미
    • 실선으로 표시되며, 방향성을 가짐

🌻 연관 관계의 방향성 🌻

  • 연관 관계의 방향성은 화살표의 끝(end)가 액터를 가리키는지 , 유스케이스를 가리키는지에 따라 크게는 2개 타입, 세분화하면 3개 타입으로 나눌 수 있다
  1. 액터 ➡️ 유스케이스
    • 화살표의 끝이 유스케이스에 닿는 방향성을 “활성화” 방향성이라 명명할 수 있다!!(화살표의 start=액터)
  2. 유스케이스 ➡️ 액터
  • 화살표의 끝이 액터에 닿는 방향성을 “수행결과 통보”, “외부 서비스 요청” 방향성 이라하는데 액터 입장에서 “수동적”이지 않은가?(화살표의 start=유스케이스)
  • 수행결과 통보 : 유스케이스 결과가 액터에게 통보됨
  • 외부 서비스 요청 : 외부 시스템에 서비스 실행을 요청

  1. 포함관계 - 반드시 해야 하는 관계(포인트는 화살표의 start 가 어떻게 되는지!! ▶️ 확장관계에서도 start!! UML은 start!)
  • 화살표의 end와 start에 따라 필요조건같은 관계가 요구되는, 선택-필수 관계가 존재하는 관계!
  • 화살표의 start 부분은 end가 반드시 필요한 필수 관계(기본 유스케이스)
  • 화살표의 end부분은 굳이 start가 필요없는 선택 관계(포함 유스케이스)

https://github.com/hy6219/TIL-Today-I-Learned-/blob/main/Database/Oracle/Basic/Design/UML/%EC%9C%A0%EC%8A%A4%EC%BC%80%EC%9D%B4%EC%8A%A4-%ED%8F%AC%ED%95%A8%EA%B4%80%EA%B3%84.png?raw=true

UML-유스케이스 포함관계

🌟 관계를 이을 때에는 , 점선과 함께 include 라는 스테레오 타입이 필요하다!

🌟 포함 유스케이스가 여러 유스케이스에서도 재사용된다면 그 효율성이 증가될 것!

  1. 확장 관계 - 선택적으로 할 수 있는 관계
  • Extension Points: 사용자가 어떤 선택을 하는지를 나타냄(생략하고 나타내기도 함!)
  • «extend» 스테레오타입과 점선을 이용

https://github.com/hy6219/TIL-Today-I-Learned-/blob/main/Database/Oracle/Basic/Design/UML/%EC%9C%A0%EC%8A%A4%EC%BC%80%EC%9D%B4%EC%8A%A4-%ED%99%95%EC%9E%A5%EA%B4%80%EA%B3%84.png?raw=true

UML 유스케이스 - 확장관계

역시, 이 부분에서도 start입장을 봐야하는데, 파일업로드의 입장에서 end인 게시판등록을 하는데에 꼭 필수적인 것이 아니기 때문에 선택적인 관계인 “확장관계”에 해당된다!

  1. 일반화 관계
  • 유사한 유스케이스들 또는 액터들을 추상화한 하나의 유스케이스로 그룹핑하여 이해도를 높인 관계

https://github.com/hy6219/TIL-Today-I-Learned-/blob/main/Database/Oracle/Basic/Design/UML/%EC%9C%A0%EC%8A%A4%EC%BC%80%EC%9D%B4%EC%8A%A4-%EC%9D%BC%EB%B0%98%ED%99%94%EA%B4%80%EA%B3%84.png?raw=true

UML 유스케이스 - 일반화 관계

상속관계같기도 하다!

(예) <결제 관련="" 업무="" 기술서="">

  • 상품 결제 시 카드 결제를 통해 할 수 있다
  • 상품 결제 시 온라인 송금을 통해 결제할 수 있다
  • 상품 결제 시 휴대폰 결제를 통해 결제할 수 있다

▶️ 상품 결제 ⊃ 카드결제, 온라인 송금, 휴대폰 결제

그렇기 때문에 카드렬제와 온라인 송금, 휴대폰 결제를 묶어서 상품 결제에 상속받도록 할 수 있다!

🌟 유스케이스 다이어그램 수업 실습

1) 액터 식별

2) 유스케이스 식별

3) 유스케이스 다이어그램 작성

🌟 유스케이스 시나리오

🌺 이벤트 흐름 🌺

  1. 기본흐름
    • 아무것도 잘못된 것이 없다는 가정 하에 사용자의 자극에 시스템이 어떤식으로 동작할 지 기술
  2. 대안 흐름
  • 세부 상황 중 일부가 잘못되었을 경우를 고려한 흐름
  • 선택흐름 : 사용자 혹은 시스템에 의해 선택적으로 수행되는 흐름
  • 예외흐름: 시스템에서 발생하는 에러 등을 처리하기 위해 수행되는 흐름

유스케이스 설계 후 유스케이스 시나리오를 작성해야 한다!!

Updated: