Professor Seung-Hoon Choi

Ch06. 유스케이스

2

유스케이스는

요구 사항을 발견하고 기록하기 위해 널리 사용되는

텍스트로 작성된 스토리이다.

주로 FURPS+ 모델에서 F를 표현한다.

유스케이스 다이어그램은

한 응용 프로그램의 전체 기능을 보여주는데 유용하다.

유스케이스는 객체 지향과는 아무런 관련이 없다.

3

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

Fig 6.1 Use Cases within the UP

(출처: UML과 패턴의 적용, Craig Larman 저, Pearson Education)

4

간단히 말하면, 유스케이스는

목적을 달성하기 위해 액터가 시스템을 사용하는 텍스트 형식의

스토리이다.

약식으로 표현된 간단한 예제: Process Sale(판매 처리하기)

고객이 구입할 상품들을 가지고 계산대에 온다. 출납원은 구매된 각

품목을 기록하기 위해 POS 시스템을 사용한다. 시스템은 구매된 품목들의

총액과 각 품목의 세부 내역을 보여준다. 고객은 시스템이 검증하고

기록할 지불 정보를 입력한다. 시스템은 재고를 갱신한다. 고객은

시스템으로부터 영수증을 받은 후 구매한 상품들을 가지고 나간다.

유스케이스는

요구 사항 분석 시 의사 소통 도구로 유용하게 사용된다.

5

Actor

사람, 컴퓨터 시스템, 조직과 같이 행위를 갖는 어떤 것

예: 출납원, 게임 플레이어

Scenario (또는 유스케이스 인스턴스)

액터와 시스템 사이의 활동 및 상호 작용에 대한 명확한 순서

시스템을 사용하는데 있어서 하나의 특정 스토리

유스케이스 내를 흘러가는 하나의 경로

Use case

액터가 목적을 달성하기 위해 시스템을 사용할 때 발생 가능한 성공

시나리오들과 실패 시나리오들의 집합

6

유스케이스 모델

유스케이스들

유스케이스 다이어그램

7

유스케이스는 요구 사항을 표현한다.

주로 기능적 또는 행위적 요구 사항을 표현함

FURPS+ 모델에서 F에 중점을 둔다.

그러나, 다른 유형의 요구 사항도 포함할 수 있다.

8

액터(Actor)

주요 액터(Primary actor)

SuD(System under Discussion)을 사용하여 사용자의 목적을 수행한다.

예: 출납원

지원 액터(Supporting actor)

SuD에 (정보와 같은) 서비스를 지원한다.

예: 지불 인증 시스템

숨겨진 액터(Offstage actor)

주요 액터나 지원 액터가 아니면서, 유스케이스 행위에서 이해관계를

갖는다.

예: 세무서

9

유스케이스 형식들

약식(brief)

일반적으로 주요 성공 시나리오를 표현하는 간결한 하나의 문단

자유형(casual)

비공식적인 문단 형식

여러 가지 시나리오를 다루는 여러 개의 문단으로 구성됨

완전 명세(fully dressed)

모든 단계와 변형이 상세하게 작성됨

사전조건, 성공보장 등의 여러 가지 항목들로 구성됨

10

Template(양식)

Use Case Section Comment유스케이스 이름 동사로 시작

범위 설계 중인 시스템

수준 “사용자-목적” 또는 “세부 기능”

주요 액터 서비스를 위해 시스템을 호출

관련자 및 관심사항 누가 이 유스케이스를 중요하게 생각하고 원하는 것은무엇인가?

사전조건(Preconditions) 유스케이스가 시작할 때 만족해야 하는 조건은무엇인가?

성공보증(Success Guarantee) 유스케이스가 성공적으로 끝났을 때 만족해야 하는조건은 무엇인가?

11

Template(양식) (계속)

Use Case Section Comment주요 성공 시나리오(Main Success Scenario)

전형적인 성공 시나리오

확장(Extensions) 또 다른 경로의 성공 또는 실패 시나리오

특수 요구 사항 관련된 비기능적 요구 사항

기술 및 데이터 변동 리스트 다양한 입출력 방법 및 데이터 형식

발생 빈도 조사, 테스트 및 구현 시점에 영향을 줌

기타 해결되지 않은 문제 등

12

예제 유스케이스 UC1: Process Sale

교재 98~103 페이지 참조

학사 인트라넷 첨부 자료 참조(06_01_Use_Case_Process_Sale.doc)

13

범위(Scope)

개발하는 시스템의 경계

수준(Level)

사용자-목적 수준(user-goal level) 유스케이스

주요 액터가 어떤 목적을 수행하기 위한 시나리오를 설명하는

일반적인 유스케이스

세부 기능 수준(subfunction-level) 유스게이스

사용자의 목적을 지원하는데 필요한 세부 단계를 기술하는

유스케이스

14

주요 액터(Primary Actor)

목적을 수행하기 위해 시스템의 서비스를 호출하는 주된 액터

관련자 및 관심사항 리스트(Stakeholders and Interests List)

응용 프로그램과 모든 관련자들 사이의 약정 중 기능적인 부분들을

상세하게 기술함

현재 유스케이스에서 관련자들이 무엇을 원하는지에 초점을 둔다.

15

사전 조건(Preconditions)

유스케이스 내의 시나리오가 시작되기 전에 항상 참이어야 하는 조건

성공 보증(Success Guarantees) 또는 사후조건(Postconditions)

유스케이스 내의 주요 성공 시나리오나 다른 대안 경로의 성공적인 완료

후에 참이어야 하는 조건

16

주요 성공 시나리오(Main Success Scenario) 또는 기본 흐름(Basic

Flow)

관련자의 관심 사항을 충족시키는 일반적인 성공 경로

17

확장(Extensions) 또는 대안 흐름(Alternate Flows) :

유스케이스의 대부분을 차지하는 중요한 부분임

주요 성공 시나리오 이외의 모든 시나리오를 나타냄(성공 또는 실패)

주요 성공 시나리오로부터의 분기를 나타냄

숫자 매기기

예를 들어, 주요 성공 시나리오의 Step 3에서, 입력이 잘못되었거나

시스템에 미리 등록이 안 된 경우 유효하지 않은 물건 ID가 발생될 수

있다.

3a: 첫 번째 유효하지 않는 물건 ID 발생 조건 + 대응 활동

3b: 두 번째 유효하지 않는 물건 ID 발생 조건 + 대응 활동

3-6a: step 3에서 6 사이에서 일어날 수 있는 조건에 대해 기술할 때

*a, *b: 시스템 사용 중 언제든지 일어날 수 있는 조건에 대해 기술할 때

18

특수 요구 사항(Special Requirements)

주로 비기능적 요구 사항(non-functional requirements)을 기술함

현재 유스케이스에서, 성능, 신뢰성, 사용성과 같은 품질에 관련된 요구

사항을 기술함

예

게임 서버와의 연결은 최대 5초 안에 이루어져야 한다.

카드 인증의 90%는 30초 이내에 응답되어야 한다.

19

기술 및 데이터 변동 리스트(Technology and Data Variations List)

기술적인 변화나 데이터 구조의 변동 등을 기술함

일반적인 예

입출력 시의 기술적 제약 사항

POS 시스템은 카드입력기나 키보드를 이용하여 신용카드 계정 정보의

입력을 지원해야 한다.

데이터 구조의 변동

바코드로 기호화된 품목 식별자로서 UPC나 EAN, JAN을 지원해야 한다.

20

유스케이스를 액터와 시스템 사이의 대화로 표현함

Main Success Scenario:

Actor Action (or Intention) System Responsibility

1. Customer arrives at a POS checkout with goods and/or services to purchase.

2. Cashier starts a new sale3. Cashier enters item identifier.

4. Records each sale line item,presentsitem description and running total.

Cashier repeats steps 3-4 until indicates done.

5.Presents total with taxes calculated.6.Cashier tells Customer the total, and asks for payment.

7.Customer pays.8.Handles payment.9…

21

이 단계에서 UI 관련한 상세한 부분들은 언급하지 않는 것이

중요하다.

A UI-free 유스케이스

간단하고 짧다.

액터의 목적에 더 집중할 수 있다.

짧지만 완벽한 유스케이스를 작성하도록 노력하라!

22

유스케이스는 시스템의 책임을 상세히 기술해야 한다.

‘what’ the system should do 를 기술한다.

‘how’ the system will implement the solution 의 기술은 피해야 한다.

‘the system records the sale’ 과 같이 작성하도록 한다.

다음과 같은 구현 관련 부분은 피한다.

“시스템은 데이터베이스에 판매를 기록한다” (bad)

“시스템은 판매에 대한 INSERT SQL 문을 생성한다” (worse)

23

유스케이스 다이어그램(use case diagram)

유스케이스과 액터의 이름 및 그들 간의 관계를 표현함

시스템 컨텍스트를 제공함

시스템의 경계가 어디인지

시스템 외부에 무엇이 있는지 보여줌

시스템과 액터들의 행동을 요약해서 보여줌으로써 좋은 의사 소통

도구가 된다.

24

NextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

첺 ctor?Tax Calculator

첺 ctor?Accounting

System

alternatenotation for a computer system actor

첺 ctor?HR System

Cash In

첺 ctor?Sales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns

<<actor>><<actor>>

<<actor>>

<<actor>>

Figure 6.3: Partial Use Case Context Diagram(출처: UML과 패턴의 적용, Craig Larman 저, Pearson Education)

25

유스케이스 사이의 관계를 이용하여 유스케이스들을 구조화할 수 있다.

유스케이스 사이의 관계 일반화(generalization) 클래스 상속과 비슷한 개념 자식 유스케이스는 부모 유스케이스의 행동과 의미를 상속받음 부모가 나오는 곳마다 자식으로 대체할 수 있음

포함(include) 다른 유스케이스를 자신의 일부분으로 포함하는 관계 포함되는 유스케이스는 독자적인 인스턴스를 만들 지 못함(다른 유스케이스의

부분으로만 존재함)

확장(extend) 다른 유스케이스를 만드는데 있어서 기본 구조를 제공하는 관계

26

ValidateUserCheckPassword

RetinalScan(홍채 인식)

Transfer

<<include>>

TransferBetweenDifferentBanks

<<extend>>

확장관계 -> 당행이체 유스케이스를 확장하여 타행이체 유스케이스를 구현한다

일반화 관계 -> 사용자 인증은 비밀번호검사 또는 홍채인식 중 하나로 대체 가능

하다.

포함 관계 -> 이체하기는항상 사용자검증 단계를 포

함한다.