[객체지향개발론] 04 Use Case

Inception

Inception Phase

• 프로젝트 시작 전 거쳐야 하는 비교적 짧은 단계.
• high-level goal 찾기.
• 이 프로젝트의 비전과 비즈니스 사례는 무엇인가?
• Feasible? 가능할까?
• Buy and/or build?
• estimate of cost
• should we proceed or stop?
• Evision the product scope, vision and business case
• Inception 단계가 끝났을 때 : 이해당사자가 다음 비전에 대해 기본적인 합의를 하고 있는지? 프로젝트, 조사에 투자할 가치가 있는지? 를 판단해야 함.

Artifact

• Functional requirement

• Non-functional requirement (technical constraints/business constraints)

  • Qualify attribute/requirements

Use Case

• 디벨로퍼는 무엇을 구현해야하는지, 클라이언트는 무엇이 구현되는지 정확히 알아야 한다.
• 요구사항 분석을 위한 tool 이 필요하다. → use-case 사용

... in Inception

• 요구사항이 무엇인지 분석하는 단계이다.
• 따라서 primary actor 가 필요하다. (시스템 외부의 누군가가 우리의 시스템을 필요로 하는지)
• 그리고 actor 와 어떤 interaction 을 사용하여 어떤 scenario 로 해당 목표 goal 을 달성할지 알아야 하는 것이 목적이다.

Goals and Stories

• use case 란 시스템이 goal 을 달성하기 위한 하나의 스토리와 같다.
  = 목적 달성을 위해서 일어나는 일련의 Interaction 을 시작과 끝이 있는 리스트로 작성한 것이다.

Actors

• SuD(System under Design)과 직접적인 interact를 하지 않는 SuD 밖의 것을 말한다.

Extended

• SuD를 포함해서, 다른 actor 에게 서비스를 요청하는 행동을 하는 것을 말한다.

• 이름은 Role-name 으로 부여한다. (eg. 철수 영희가 아닌, 계산원)
  

• Type

  • Primary actors
    • goal 달성을 위해 시스템을 사용하는 주체.
    • Why identify❓ user goal 을 찾기 위해 설정해야 한다.
  • Supporting actors
    • SuD 에게 서비스를 제공해주는 것.
    • Why identify❓ interface, protocol 을 명확히하기 위해서이다.

      • Offstage actors

    • 시스템과 직접적 Interaction 은 하지 않지만, 시스템 동작의 이해관계에 관련되는 것.
    • Why identify❓ 모든 이해관계를 만족시키는 것을 보장하기 위해서이다.

<중간 정리>

• use-case 란 : actor 와 system 사이에서 일어나는 action, interaction 을 기술한 것이다.
• (확장) : 직접적인 Interaction 을 가지고 있진 않지만, 시스템의 동작에 이해관계를 가지고 있는 것들도 actor 로 보아야하고, 이 actor 들의 이해관계를 보장하기 위한 action, interaction 을 기술한 것이다.

Scenarios

• use case 의 instance. (하나의 Path 로 볼 수도 있다.)
• actor, SuD 사이의 common goal 을 달성하기 위한 action, interaction 의 순서를 뜻한다.

Use Case

• common goal 달성을 위해 actor 가 system 을 사용하는 scenario 를 모아놓은 것.

• name 은 active verb 로 시작한다.
  

• 한 쪽은 성공 시나리오, 다른 쪽은 실패 시나리오를 모은 바지와도 같다. (그림)

• user의 관점 : 시스템에 대한 behavior document 이다.

  • 서로 goal 을 가지고 있는 actor 사이에 일어나는 action, interaction 을 기술한 것.

• 하나의 관점에서만 보게 되면, offstage actor 의 이해관계를 보장하는 것을 까먹을 수 있음. 따라서 다른 관점 (stakeholders with interest) 에서도 봐야한다.

  • 모든 stakeholders 의 이해관계를 만족하도록 action, interaction 을 기술한 것.

use case 에 들어가야 하는 3가지 형태의 action step, 문장

1. An interacction betwwen two actors : goal 을 위해
2. A validation : 한 stakeholder 의 이해관계 보호
3. An internal state change : 직접적 interaction 은 아니지만, 이해관계를 만족시키기 위한 행동들

Business UC vs. System UC

• Business Usecase : business 에 대한 operation 을 기술해놓은것.
• System Usecase : SuD 를 위한 functional requirement 를 기술해놓은 것.

Black-Box vs. White-Box UCs

• Black-Box Use Case

  • system 이 어떻게 동작하는지는 기술하지 않음.
    → 분석단계에서는 black-box 를 사용하는 것이 당연. '무엇을 달성하고자 하는가' 에 대해 초점을 둔다.

• White-Box Use Case

  • system 안의 행동을 기술.

Formats

Brief format

Casual format

---

▲ Fully dressed format

• Primary Actor
  : Sud 와 상호작용을 시작하거나 목표를 달성하기 위해 시스템 서비스를 요청하는 이해관계자.

• Stakeholders and interests
  : 모든 이해관계자들의 이익을 만족시키는 것.

• Preconditions
  : 시나리오를 시작하기 전 선행되어야 할 조건.

• Success Guarantee (Postcondition)
  : 시나리오 종료 후 성공적으로 완료되어야 할 것.

• Main Success Scenario (Basic Flow)
  : 이해당사자들의 이익을 만족시키는 전형적인 성공 경로.

• Extensions (Alternative Flow)
  : 시나리오 또는 분기를 표시한다.

  • 모든 action step 하나하나는 use-case 가 될 수 있는 가능성을 지님.

• Special Requiremenets
  : buisness rule 이 시스템에 dependency 를 지니지 않게 하기 위해, non-functional requirement, QA 를 미리 알아놓아야 함.

• Technology and Data Variations List
  : technical variation, data scheme 를 기록한다.

  • 다양한 동작을 표현하는 여러 단계가 포함되서는 안됨.

Use case 의 sentence 에 모두 포함해야 할 4 concept

1. Level : goal 에 대해

• EBP(elementary business processes)
  : 비즈니스 이벤트에 대응하여, 한 사람이 한 번에 한 곳에서 수행하는 작업.
• 다음과 같은 과정을 반복하여 sentence 지정.
  

2. Scope : system boundary 의미

3. Detail : intent, detail

4. Primary Actor : goal 을 가진 사람

UC Basic Proceduer

1 : Choose the System Boundary

2, 3 : Finding Primary Actors and Goals

• find actors
  

• find goals

  • Actor-based : 시스템, 조직과 관련된 행위자를 식별
  • Event-based : 시스템이 응답해야하는 이벤트를 식별
    

• Ranking Use Cases

  • 핵심 아키텍쳐에 영향을 미치는 정도, risk 가 큰 정도일수록 랭킹이 높다.
    → wide & shallow 할수록(=여러군데 영향을 미칠수록) 더 랭킹이 높다. (narrow & deeper 과 반대)

4 : Define Use Cases

• EBP-level 을 지정한다.
• CRUD 개별 목표를, 사용 사례로 축소한다. (ex. Manage : 너무 세분화하지 않도록)
• active verb 사용해 use case name 을 지정.

How to do it : For each use case

(1) Write the simple case : main success scenario 를 작성한다.
→ 시스템 기능에 대한 설명서가 생성됨.
(2) Write failure conditions as extensions
→ alternate scenarios 의 리스트가 생성됨.
(3) Follow the failure till it ends or rejoins
→ use case 생성 완료.

Essential vs. Concrete Use Cases

• Essential use cases : 의도 중심
• Concrete use cases : 수단까지 언급한다.
  → use case 는 한 번만 작성하는 것이 아니라, 여러 형식, 스타일로 여러번 작성된다.
  → iterative 하게 작성됨 (incremental 아님)
  

Use Case Diagram

: use case, actor 의 관계를 표시한 diagram

Use Cases 의 사용 이유

• 고객과 개발자 간의 합의 근거
• 모호한 요구사항을 확실하게 만드는 도구
• 객체 분석 소스
• 사용 설명서의 첫 번째 버전
• 시스템 테스트의 기초