05. Use Case Diagram

2.3.3 Use Cases Diagram

• Use Cases : 외부 엑터가 Use Case 텍스트 기반의 시나리오를 어떻게 사용하는지 텍스트로 보이는것을 말함
  • 요구사항을 캡처링하고 분석하는 메커니즘으로 많이 사용함(OOAD 외에도 SASD에서도 FR(Functional Requirement)로 사용함. ex. 절차지향 C에서도 요구사항 파악을 위해 사용함)
• Use Case 형태는 3가지가 있음
  • Brief : 위 슬라이드에 나와있는 내용
  • Casual : Main/Alternative/Exceptional Scenario, Precondition/Post Condition을 더 디테일한 레벨로 적어놓은 텍스트를 말하며 구현전에 작성하는 것을 말함
  • Fully Dressed : Casual 포맷과 동일하나 구현하는 단계에서 작성하는 것을 말함

• Use Case Diagram은 2가지를 대표적으로 설명함
  • 1. System Context : 시스템 바운더리를 설명함
       • 디자인하는 시스템의 바운더리를 설정하며, Actor들의 관계(Primary/Secondary/supporting/off stage)도 정의할수 있음
         • primary actor : 시스템에 직접적으로 접근하는 액터
         • secondary actor : 시스템에 직접 접근 안하고 primary측에 요청하는 actor
         • supporting actor : 비자 카드 도난 방지를 확인하는 VISA 회사
         • off stage actor : 가끔씩 이용되는 국세청 액터들
  • 1. use cases summary : 전체 시스템의 유즈 케이스를 보임
       • 다이어 그램의 액터랑 연결된 동그라미를 선택하면 텍스트 기반의 description을 확인할 수 있음
  • UML 가이드에 아래와 같이 사용하라고 권고되긴 하나 꼭 지킬 필요는 없음(원활한 커뮤니케이션만 되면 됨)
    • 왼쪽 Actor(Primary actor)/오른쪽 Actor(supporying actor / off stage actor) => 그냥 아무데나 표기해도 됨
    • Supporting / off stage actor 는 네모 칸에 스테레오 타입으로 <<Actor>>와 같이 표기 => 그냥 사람으로 다 표기해보 됨

• 포맷의 경우 각 아래 단계에 따라 구분해서 사용
  • Iteration에 item으로 잡기 전 : Brief ( 간략하게 한 문단으로 작성 )
  • OOA : Casual ( Main(-) / Alternative(∧) / Exceptioanl Scenario(／))
  • OOD/OOI : Fully Dressed (Casual + Precondition/postcondition(success gurantee))

• 위 Use Cases에 보인 Brief Process Sale 예시를 fully dressed로 작성시 예시를 보임

• main / Exceptional Scenario를 보임

• 이를 보면 Use Case는 Functional Requirement를 대체할수 있음을 확인 가능

2.3.3.1 Brief Format Use Case 작성 가이드

• Use Case Brief를 작성 시 Essential style 로 작성하는게 좋다고 함.
  • Essential Style : 아주 디테일하고 구체적인거 말고 UI 없이 아주 flexible하게 수정 가능하게 적는 것을 말함
    • Essential Style로 적으면 꼭 ID/password/dialog를 통한 유저 관리가 아니라 홍채 인식/ID&PASSWD 등 여러 방법으로 구현하시는 분들이 구현할수 있으로 HW/SW에 dependency 없이 free하게 Implementation detail을 적지 않는 것을 권고함

• Use Case를 작성 시 Black-box style로도 작성하는 것을 권고함
  • black-box(not describe the internal working)로 작성 시 위와 마찬가지로 레코딩 하는 방식은 구현하시는 분들이 자유롭게 구현 가능한 장점이 있음

• Use Case는 Functional Requirement로 생각하면 되며,
• 요구사항 명세서(SRS, software requirement specification)에 기능/비기능(Functional, Non-Functional)이 있을때 F=Use Case를 적고 N-F에는 그외에 것들을 싹다 적어나감

---

Quiz

Answer 3.

Answer 1.

3-Fully-Dressed 포맷은 워터폴 방식 4-Inseption/Elaboration/Construction/Transition 로 UP의 4단계가 있는데, Elaboration 단계까지만 수정이 가능함. 이 그후 계속 수정을 하면 안됨

---

HomeWork

• 5가지의 Functional Requirement를 반영하여 use case를 그려보자

Ans 첫번쨰 시스템 바운더리를 액터로 바꿔 두번쨰 그림처럼 나오게 됨(네모칸이 사람이 됨)

• 식당 관리 use case에 대하여 Casual UC를 작성해보기 (방문 부터 시작)
• 숫자 갯수는 상관 없음

---