4 분 소요

이번 포스트는 Use Case와 Use Case Diagram 에 대해 다룬다.

  • 개발 프로세스의 “추상화 수준”과 “역할”에 따라 구분
  1. 기획 단계 : Use Case Diagram, Domain Model
    • 사용자/ 비즈니스 관점 중심으로 무엇을 할 것인가에 집중
  2. 설계 단계 : Class Diagram, Sequence Diagram
    • 개발자 중심으로 어떻게 구현할 것인가에 집중
    • 구체적인 코드 설계의 기반

Class Diagram과 Sequence Diagram에 대해서는 다뤘고, 이번에는 기획 단계에 사용되는 부분에 대해 다룬다.

Use Case

Use Case

  • 정의 : 사용자(actor)가 시스템(system)을 사용하여 목표(goal)을 달성하는 과정을 텍스트 기반으로 기술한 것
  • 요구사항(주로 기능 요구사항)을 포착하기 위한 주요 수단
  • 사용자 중심의 시나리오로 시스템 동작을 설명
  • 사용 이유
    • 사용자의 목표를 쉽게 표현할 수 있음. (도메인 전문가나 요구사항 제공자가 이해하기 쉬움)
    • 기능보다는 목표(goal) 중심)
  • 즉, Use Case는 실제로는 요구사항이다.
    • FURPS+ 에서 F에 해당

Actor, Scenario, Use Case

1. Actor

  • 시스템과 상호작용하는 사람 또는 다른 시스템

2. Scenario

  • Use Case 수행 시 일어나는 절차의 흐름
  • 특정한 일련의 상호작용

3. Use Case

  • 성공과 실패 시나리오들의 집합

    • Main Success Scenario, Alternate Scenarios

  • 목표 달성을 위한 흐름 표현

Use-Case Model

  • 시스템의 기능성과 환경을 표현한 모델
  • 시스템의 외부세계와 어떻게 상호작용하는지를 보여줌

Actor

  1. Primary Actor
    • 시스템을 사용해서 어떤 목표를 이루고자하는 주체
    • 예시) 고객, 직원, 관리자 등
  2. Supporting Actor
    • 시스템이 정상적으로 동작하기 위해 도와주는 외부 시스템 또는 사람
    • 예시) 결제 승인 시스템, 데이터베이스
  3. Offstage Actor
    • 직접 참여하지는 않지만, 시스템 동작에 영향을 받거나 요구사항에 이해관계가 있는 주체
    • 예시) 정부 기관, 회계 감사인

Use Case Foramt

  1. Brief : 한 문단, 핵심 시나리오 요약

  2. Casual : 비공식적 서술형으로 여러 시나리오를 포함

  3. Fully Dressed : 모든 요소를 포함

    • 완전히 상세하게 작성한 형식
    • 개발자, 기획자, 분석가, 테스터 모두가 이해하고 활용할 수 있게 모든 요소를 명확히 기술한 문서
    항목 설명
    Use Case Name 유스케이스 이름 (예: “책 주문하기”)
    Scope 시스템의 이름 또는 범위 (예: 온라인 서점 시스템)
    Level 사용자 목표 수준 (user-goal level 등)
    Primary Actor 이 유스케이스를 시작하는 주체
    Supporting Actors 시스템 수행에 필요한 외부 시스템 등
    Stakeholders & Interests 이해관계자 및 기대 효과
    Preconditions 유스케이스가 실행되기 전에 충족되어야 하는 조건
    Postconditions (Success Guarantees) 성공적으로 수행된 후 보장되는 상태
    Minimal Guarantees (Failure case) 실패하더라도 반드시 유지되어야 하는 조건
    Trigger 유스케이스 실행을 유발하는 사건 또는 조건
    Main Success Scenario 사용자와 시스템 간 정상 시나리오 (step by step)
    Extensions (Alternate Flows) 예외적 흐름 또는 대체 시나리오
    Special Requirements 성능, 보안, 품질 등 비기능 요구사항
    Technology and Data Variations 구현 방식이나 데이터의 다양한 처리 조건
  • Preconditions and Postconditions(Success Guarantees)

당연하지는 않지만 중요한 조건을 명확히 기술하는 것이 핵심

  1. Preconditions : 실행 전에 만족해야 하는 조건 (Use Case 시작 전)
    • Use Case를 시작할 수 있는 조건을 제한
  2. Postconditions : 실행 후에 보장되어야 하는 결과 상태 (Use Case 완료 후)
    • 성공적으로 끝났을 때 결과가 어떤 상태임을 명시
  • Extensions (or Alternate Flows)

Main Success scenario + extensions = 거의 기대효과를 만족함.

Non-functional requirements 는 Supplementary Specification에 해당

Use Case 작성 방법

  • UI-free style : 사용자 의도와 시스템 책임만 기술하고, UI 동작은 피하기
  • Terse : 짧고 명확하게
  • Black-box : 내부 구현 기술은 배제 (How보다는 What에 초점) : analysis
  • Actor-Goal : 상황에 맞는 사용자의 목표와 결과에 집중

Test for Useful Use Case

1. The Boss Test

  • 상사가 뭐했냐고 물어볼 때, Use Case 이름으로 대답이 가능해야함.
  • 명확하고 가치 있는 사용자 행동을 표현하고 있는지를 검토
  • 결과가 비즈니스적 가치가 있는가?

2. The EBP Test

  • EBP : Elementary Business Process
  • 이 Use case가 사용자에게 비즈니스적으로 의미 있는 결과를 제공하는가?
  • 하나의 완결된 사용자 목적을 다루고 있는지 확인
  • 한 장소에 하나의 사람이 실행할 수 있는 일관된 업무인가?

3. The Size Test

  • 하나의 Use Case가 너무 많은 세부 기능을 포함하거나 반대로 너무 작아서 쓸모없을 정도로 단순한 경우를 피함
  • 너무 작거나 단일 단계는 아닌가?

작거나 중간 단계여도, 여러 Use Case에서 반복되거나 기술적으로 복잡하다면, 별도 Use Case로 관리할 수 있다.

  • [Paying by Credit] : 하위 단계에 해당 -> 별도의 Use Case로 뽑아서 재사용하는 것이 더 좋음.
  • [Authenticate User] : Boss test 실패지만, 인증 기능은 복잡도나 보안 요구상 매우 중요한 기능일 수 있음.

Use Case 작성 시기

Phase 활동
Inception 유스케이스 이름과 간단 요약 (2일 워크숍)
Elaboration 10% → 30% → 50% → 80~90% 점진적 상세화
Construction 남은 유스케이스 구현 진행

Use Case Diagram

Use Case Diagram

  • 텍스트 중심이지만 간단한 다이어그램은 시스템 경계를 시각화함.
  • Actor와 Use Case의 관계를 시각적으로 표현
  • 시스템 기능에 대한 고객/이해관계자의 기대를 표현하여 기능 요구사항 중심의 시각화 도구로 사용
  • 너무 복잡한 다이어그램은 지양

Use Case

Use Case Diagram 구성 요소

1. System

  • 어떤 시스템을 다루는가?
  • 큰 네모박스 안 제일 상단에 적혀 있는 이름이 시스템

2. Actor

  • 시스템과 상호작용을 함 (Use Case를 사용하거나, 사용당하는)

  • 역할을 나타냄 (특정 사용자가 여러 역할을 수행이 가능함)
  • 시스템 외부에 존재함
  • 사람 또는 비인간(예 : 서버) 로 구성

3. Use Case

  • 시스템이 제공해야 할 기능을 사용자의 관점에서 표현한 것
  • 사용자가 시스템을 통해 달성하고자 하는 목표나 기능
  • 표기법
    • 타원을 사용, 사각형 안의 타원

Use Case Diagram 특징

  • Actor는 시스템 외적인 것으로 개발하는 범위에 해당되지 않음.
  • System box는 optional (표기해도 되고 안해도 됨)
  • 모든 Actor는 적어도 한 개 이상의 Use Case에 연관되어 있어야 한다.
  • 모든 Use Case는 적어도 한 개 이상의 Actor에 연관되어 있어야 한다.
  • Multiplicities도 있을 수 있다.

관계는 실선으로 표기

Use Case간 관계

1. <<include>>

  • 공통 기능을 다른 Use Case에서 반드시 포함해서 호출하는 관계, 항상 실행된다.
  • 공통 코드, 재사용
  • included use case에서 실행이 끝나면 다시 base use case로 돌아온다.
  • 포함되는 Use Case는 독립적으로 실행이 가능하다

2. <<extend>>

  • 기본 Use Case 흐름에 선택적으로 확장되는 흐름을 분리
  • 조건부로 기능이 확장되어, 확장 포인트(extension point)에서 실행
  • 조건적으로, 선택적 흐름으로, 예외처리하기에 좋음
    • 기본 흐름에 영향을 주지 않는 부가 기능

3. Generalization

  • 상속 관계로 한 Use Case가 다른 Use Case의 행동을 상속받고, 일부를 재정의하거나 확장함
  • 상속, 다형성, 공통 기반
  • 자식은 부모의 모든 행동 및 관계를 상속하며, 일부를 변경 또는 확장이 가능하다.
  • abstract을 사용 가능함.
  • AND, OR 표기에 대해서 협업에서는 막 쓰는 경우가 있음. Abstract 키워드 사용이 좋음.

Use Case Diagram에서의 실수

  1. Use Case Diagram으로 프로세스를 모델
    • 프로세스는 Activity Diagram에서 표현
  2. Actor를 시스템 내부에 위치
    • Actor는 항상 시스템 바깥에 위치함.
  3. 단순 기능 분할로 너무 많은 Use Case를 생성
    • 유사 목적은 그룹화
    • 대표적 예시 : CRUD
  4. Use Case 내부 단계들을 각각의 Use Case로 모델링
    • 하나의 Use Case안에서 표현을 해야함.

참고

Concurrency, Locks

8 분 소요

이번 포스트는 OS의 Concurrency와 Locks에 대해 다룬다.