사용사례 (Use Case)

2

Objectives

• 유스케이스 식별과 정의

• 목표와 기본 비즈니스 프로세스에 유스케이스 연관 짓기

• 작성 형식

• 반복적 개발에서의 유스케이스

3

소개

• 유스케이스는?

– 시스템을 사용하는 줄거리 (story)

– 유스케이스 텍스트 vs. 유스케이스 다이어그램

• 요구사항 수집 및 정의 단계에서 널리 사용 됨

– 특히 시스템의 기능과 환경을 살펴보는데 좋다

4

UC 와 UP 산출물과의 관계

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. ...

5

1 유스케이스 예제

• 유스케이스는 프로젝트의 목표를 달성하기 위한 시스템의 사용 줄거리이다.

• 약식 형식의 UC

UC1 - Process Sale (판매): 고객이 구매를 위해 계산대에 물품을 갖고 온다. 직원은 POS 시스템을 사용하여 각 물품을 기록한다. 시스템은 각 물품의 상세 내역과 합계를 보여준다. 고객은 지불 정보를 입력하고, 시스템은 유효성을 확인한 후에 기록한다. 시스템은 재고 목록을 갱신한다. 고객은 시스템으로부터 영수증을 받은 후, 물품을 갖고 떠난다.

•유스케이스는 다이어그램이 아니라 텍스트이다.

6

Background

• 1986년 Ivar Jacobson에 의해 소개.

• 간결성과 유효성이 널리 입증 됨.

• 이후 수많은 사람들에 의해서 연구되고 있다.

7

2 정의: 액터,시나리오,유스케이스

• 액터

– 사람, 시스템, 조직 등 행위(behavior)를 갖고 있는 어떤 것.

– 3가지 형태

• 주요액터: SuD (System Under Development) 의 서비스를 사용한다.

• 지원액터: SuD에 서비스를 제공한다. 외부 시스템이나 사람.

• 숨겨진 액터: 유스케이스의 행위에서 이해관계를 갖는 사람. 세무서 등. 간접적인 액터 (주요액터나 지원액터는 아니다)

• 시나리오

– 액터와 시스템 사이에서 발생하는 상호작용과 행동들의 특정 절차.

– 유스케이스의 한 인스턴스

• 유스케이스

– 액터가 목표를 달성하기 위한 시스템 사용 시나리오들의 집합

8

UC 예제 (계속)

• 자유 형식(casual format)의 UC 예제

• 요구사항 분석은 어떻게 시스템이 값어치를 갖을 수 있으며 목표에 만족할 수 있는지에 초점을 맞추어야 한다.

UC2 Handle Return (반품처리) 주요 성공 시나리오: •고객은 반품을 위해 물품을 들고 계산대로 찾아온다. 직원은 반품된 물품을 POS 시스템에 기록한다 … 대안 시나리오: •만일 고객의 신용 인증이 거부되었을 경우에는, 고객에게 이를 알려주고 다른 지불 수단을 물어본다. •만일 시스템에서 물품의 식별자를 찾지 못한다면, 이를 직원에게 알리고 식별 코드를 수동으로 입력하도록 한다. •만일 시스템이 세금계산기 같은 외부 시스템과 통신하는데 실패한다면, …

•유스케이스 모델링은 다이어그램을 그리는 것이 아니라 주로 텍스트를 작성하는 활동이다.

* 그밖의 요구사항: 보충명세서, 용어집, 비젼, 비즈니스 규칙 (p. 133)

* UML 유스케이스 다이어그램 (컨텍스트 다이어그램) p. 120

9

유스케이스 및 모델

• 유스케이스는 주로 시스템이 수행해야 할 기능적 요구사항을 나타낸다. (FRUPS+ 에서 F)

• 문서의 형태로 존재한다. 다이어그램은 단지 유스케이스와 액터의 이름과 관계만을 보여준다.

• 유스케이스는 보통 블랙박스 형태로 기술된다.

• 시스템이 무엇(what)을 수행해야 하는지에 대한 책임(responsibility)을 분석(analysis)한다.

• 설계(design)단계에서 우리는 어떻게(how) 수행할 지에 대해서 정의한다.

10

유스케이스 작성 형식

• 유스케이스는 블랙박스 혹은 화이트박스의 형태로 기술될 수 있다.

• 유스케이스 작성 유형

– 약식 Brief : 간략한 한 단락정도의 요약, 주요 성공 시나리오 기술

– 자유 Casual : 여러 단락으로 다양한 시나리오 기술

– 정식 fully dressed : 모든 스텝과 변이를 자세히 기술

11

8 완전 형식 예제: Process Sale

• fully dressed 형식은 보다 자세하고 구조화된 형태를 띈다.

• 목표, 작업, 요구사항을 상세히 이해할 수 있도록 도와준다.

• http://www.usecases.org or http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases) 에는 유스케이스 작성 템플릿을 제공해준다.

12

완전형식 예제: Process Sale(계속)

유스케이스 UC1: 판매

주요 액터: 출납원

프로젝트 관계자와 관심:

• 출납원: 금액이 맞지 않을 경우에 자신의 월급에서 공제되기 때문에, 오류가 없이 정확하고 신속한 돈 계산을 원한다.

• …

사전조건: 출납원은 인증받은 사용자이다.

성공보증(사후조건): 판매 정보가 저장된다. …

주요 성공 시나리오(또는 기본 흐름):

1. 고객이 상품을 구매하기 위해 POS 계산대에 온다.

2. 출납원은 판매를 시작한다.

3. 출납원은 상품 식별자를 입력한다.

4. 시스템은 각 상품을 기록한 후, 상품 정보, 가격, 그리고 총액을 보여준다.

가격은 가격규칙에 의해서 계산된다.

출납원은 상품별로 3~4 스텝을 반복한다.

…

확장(또는 대안 흐름):

*a. 언제든 시스템이 다운된다면: 시스템 복구와 올바른 회계 처리를 위하여, …

3a. …

특수한 요구사항:

• 화면의 글자는 1미터 거리에서도 보여야 한다.

기술과 데이터 변이 목록:

3a. 상품 식별자는 바코드 또는 키보드로 입력된다.

3b. …

사용 빈도: 거의 끊임없이 사용될 것이다.

주요 이슈:

세금과 관련한 법률이 변경되지는 않았는가?

13

완전형식 예제 : Process Sale(계속)

두개의 컬럼 : 액터와 시스템의 상호작용을 강조. Rebecca Wirfs-Brock가 처음 제안함

…

주요 성공 시나리오(또는 기본 흐름):

액터 행위 시스템 책임

1. 고객이 상품을 구매하기 위해 POS 계산대에

온다.

2. 출납원은 판매를 시작한다.

3. 출납원은 상품 식별자를 입력한다.

4. 시스템은 각 상품을 기록한 후, 상품 정보, 가격, 그 리고 총액을 보여준다.

가격은 가격규칙에 의해서 계산된다.

출납원은 상품별로 3~4 스텝을 반복한다. 5. 시스템은 세금을 포함하여 총액을 보여준다.

…

14

완전형식 예제 : Process Sale(계속)

• 무엇이 좋은 포맷인가?

• Cockburn의 생각 – 이것은 나의 습관일 뿐이지, 권고사항은 아니다. 몇 년 동안 나는 두개의 컬럼을 사용하였다. 이러한 형식은 액터와 시스템 사이의 상호작용을 분리하여 시각적으로 보여주었다. 하지만 두개의 컬럼을 사용함으로써 얻을 수 있는 미미한 장점보다는 하나의 컬럼을 사용하면 더욱 간결하고 쉬운 형식을 있기 때문에 최근 one-column style로 바꾸었다. 나는 또한 one-column을 사용하여도 액터와 시스템 사이의 상호작용을 분리하여 보여줄 수 있다는 것을 알았다.

• Me too!

15

Explaining the Sections(1/4)

• 서두 부분 – 주요 성공시나리오 전에 읽어야 할 중요 사항만 적는다.

– 주요 액터 : 목적 달성을 위해 시스템 서비스를 호출하는 주된 액터

• 프로젝트 관계자와 관심사항 – “이 유스케이스에서 무엇을 해야만 하는가?”

– “프로젝트 관계자의 관심사항을 만족시키는 것”

– 매우 중요, 실용적

• 전제조건과 성공 보장(사후조건) – 전제조건

• 시나리오 시작 전 항상 참이어야 하는 것

– 성공보장(사후조건) • 유스케이스 성공 후에 반드시 참이어야 하는 것

• 프로젝트 관계자의 관심사항을 만족시켜야 한다.

16

Explaining the Sections(2/4)

• 주요 성공 시나리오 및 스텝(기본 흐름) – 프로젝트 관계자의 이익을 만족시키는 “Happy Path”

– 스텝

1. 액터 간의 작용

2. 시스템에 의한 인증

3. 시스템에 의한 상태 변화(쓰기, 수정하기…)

<<추천>> 모든 조건이나 분기문은 확장(대안 흐름)에 넣어라

17

Explaining the Sections(3/4)

• 확장(대안 흐름)

– 나머지 시나리오와 분기문들

– 라벨 : 관련된 기본 흐름 스텝 표시

– 조건과 처리로 구성

• 조건 : 시스템 또는 액터에 의해 발견된 조건 예) 5a. 시스템이 외부 세금 계산 시스템 접속에 실패했을 때

• 처리 : 하나 이상의 스텝

– 어느 스텝에서나 일어날 수 있는 조건

예) *a. 언제든 시스템이 다운된다면:

확장(또는 대안 흐름):

3a. 틀린 식별자일 때

1. 시스템은 에러를 표시하고 입력실패를 알린다.

3b. 같은 아이템 카테고리의 상품이 여러개이고 개별 상품 식별이 중요하지 않을 때

1. 출납원은 아이템 카테고리 식별자와 개수를 입력한다.

18

Explaining the Sections(4/4)

• 특수한 요구사항

– 비기능적 요구사항, 품질 특성, 유스케이스 관련한 제한 등

• 기술과 데이터 변이 목록

– 프로젝트 관계자에 의해 요구된 사항 반영

특수한 요구사항

- 평면 패널의 터치 스크린 UI, 1m거리에서도 보이는 텍스트

- 신용인증은 30초 이내

- 다양한 언어 텍스트 표현 가능

- 2, 6단계에 호환성있는 비즈니스 룰 추가 가능 …

기술과 데이터 변이 목록

3a. 아이템 식별자는 레이져 스캐너 또는 키보드로 입력

3b. 아이템 식별자는 UPC, EAN, JAN, SKU 코딩 스키마 등이 될 수 있다.

<<추천>> 경우마다 다른 스텝을 넣지 마라. 필요하면 확장(대안 흐름)에 넣어라

19

Goals and Scope of a Use Case(1/2)

• 단위 비즈니스 프로세스 (EBP)를 위한 유스케이스 – “애플리케이션 요구사항 분석과정에서 유스케이스의 유용한 레벨은 어느 정도인가?”

– 단위 비즈니스 프로세스Elementary Business Process(EBP)에 집중

• EBP – 어떤 비즈니스 사건에 대해, 한 사람에 의해 한 장소에서 한 번에 수행되는 작업으로 비즈니스 가치를 추가하거나 자료를 일관성 있게 만드는 작업

• 예외 – 여러 유스케이스에서 반복되는 서브 작업 또는 확장

<<주의>> 유스케이스를 너무 상세한 레벨로 작성하지 마라

20

Goals and Scope of a Use Case(2/2)

• 유스케이스와 목적 – 사용자 목적-레벨 유스케이스

1. 사용자 목적을 찾는다.

2. 각각에 대해 유스케이스를 정의한다.

– 부기능 목적 및 유스케이스 – 유스케이스의 수와 크기가 요구사항을 이해, 유지보수, 관리하는 데 드는 어려움과 드는 시간을 결정.

– 목적과 유스케이스는 합성 가능

시스템 분석가 : POS시스템을 사용할 때 당신의 목적은 뭐죠?

출납원 : 일단은 빨리 로그인 하는 거구요, 또 판매를 기록하는 거죠.

시스템 분석가: 로그인하게 되는 좀더 높은 레벨의 목적은요?

출납원 : 시스템이 제 자신을 식별할 수 있도록 하고 시스템이 인증하면 전 판매나 기타 다른 일을 위해 시스템을 사용할 수 있게 되는 거지요.

시스템 분석가 : 그것보다 좀더 높은 레벨은?

출납원 : 도둑이나, 자료가 깨지는 거, 회사 기밀이 누출되는 걸 막는거지요.

21

Finding Primary Actors, Goals, and Use Cases(1/3)

• 유스케이스 정의 절차

1. 시스템 경계를 선택

– 외부의 주요액터 및 지원 액터 찾기

– “무엇이 외부에 있는가?”

2. 주요 액터 식별

3. 주요 액터별 사용자 목적 식별

EBP 가이드라인을 만족하는 가장 높은 사용자 목적 레벨

4. 사용자 목적을 만족하는 유스케이스 정의

단계 1: 시스템 경계를 선택 • 외 부의 주요액터 및 지원 액터 찾기 • “무엇이 외부에 있는가?”

22

Finding Primary Actors, Goals, and Use Cases(2/3)

단계2와 3: 주요 액터 및 목적 찾기

• 액터와 목적을 찾기 위한 질문

• 주요 액터와 지원 액터 – 주요액터 : 시스템의 서비스를 이용해 목적 달성

– 지원액터 : 시스템에 서비스를 제공

– 주요액터를 찾을 것!

– 주요 액터는 시스템 경계에 따라 다르다.

누가 이 시스템을 시작하고 끝내는가? 누가 사용자관리 및 보안관리를 하는가? 시스템이 다운되면 재시작하는 감시 프로

세스가 있는가? 어떻게 SW 업데이트를 처리하는가? (push or Pull)

누가 이 시스템을 관리하는가? 시간이 액터인가? (어떤 시간 사건 때문에

시스템이 무슨 일을 하는가?) 누가 시스템 활동과 성능을 측정하는가? 누가 로그를 측정하는가? 원격으로 검색이

되는가?

23

Finding Primary Actors, Goals, and Use Cases(3/3)

• 액터-목적 리스트

액터 목적 액터 목적

출납원 판매 처리

렌탈 처리

반환 처리

현금 입금

현금 출금..

시스템 관리자 사용자 추가

사용자 수정

사용자 삭제

보안 관리

…

관리자 시스템 시작

시스템 끝내기

판매 활동 시스템 판매 및 성능 자료 분석

… … … …

24

유스케이스는 작성되었다

• 단계 4. 유스케이스 정의

– 각 사용자 목적에 대해 하나의 EBP-레벨 유스케이스 정의

– 동사 사용

– CRUD Manage 로 묶기

EBP 테스트 기본 비즈니스 프로세스 (EBP: elementary business process) -일관된 상태로 데이터를 남기는 비즈니스 업무로서 한 번에 한 장소에서 한 사람에 의해 수행되는 업무이다. -예) 신용을 승인하다. 판매를 하다. 판매현황을 조회하다.

-크기 테스트 O 계약 협상을 하다. (too large) O 반품 처리하다. (Good) O 로그인하다. (too small) O 게임판의 말을 옮기다. (글쎄?)

25

Write Use Cases in an Essential UI-Free Style

• 추가/개선 사항 : 지문 입력기? – “로그인”

– “내 자신을 식별하고 인증 얻기”

– “도둑 방지”

• 필수 스타일essential style로 적기(요구사항분석시점)

– 사용자 인터페이스는 제외, 의도에 초점

– 필수 스타일 - 구체화 스타일

… 1. 관리자가 자신을 식별한다. 2. 시스템은 식별을 인증한다. …

… 1. 관리자가 ID와 패스워드를 입력한다. 2. 시스템은 관리자를 인증한다. 3. 시스템은 사용자 수정 윈도우를 나타

낸다...

26

Actors

• 개발하고 있는 시스템System under Development (SuD)에 포함될 어떤 행위를 하는 액터

• 주요 액터 – SuD의 서비스를 이용, 사용자 목적을 만족

– 사용자 목적 찾기

• 지원 액터 – SuD에 서비스를 제공

– 외부 인터페이스와 프로토콜 명확화

• 무대 뒤의 액터 – 유스케이스에 이해 관련이 있되 주요도 지원도 아닌 액터

– 모든 이해를 식별하고 만족시키기 위해

27

Use Case Diagrams

• 유스케이스 다이어그램과 유스케이스 간 관계

– 부수적 유스케이스 작업

– 유스케이스는 텍스트 문서

– 간결하게 표현

– 왼쪽에 주요 액터, 오른쪽에 지원 액터

<<추천>>

액터-목적에 맞게 단순한 유스케이스 다이어그램을 그리라

28

유스케이스 다이어그램

NextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

첺ctorTax Calculator

첺ctorAccounting

System

alternatenotation for a computer system actor

첺ctorHR System

Cash In

첺ctorSales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns

29

다이어그램 그리기

NextGen

Process Sale

. . .Cashier

Show computer system actors with an alternate notation to human actors.

primary actors on the left

supporting actors on the right

For a use case context diagram, limit the use cases to user-goal level use cases.

첺ctorPayment

AuthorizationService

<<actor>>

30

유스케이스 분석 환경

31

32

Requirements in Context and Low-Level Feature Lists

• 상세 수준의 기능 리스트를 유스케이스로 대체

• 고수준의 기능 리스트는 OK!

! Use Cases Are Not Object-Oriented

33

Use Cases Within the UP(1/2)

• 유스케이스-기반 개발

– 요구사항은 기본적으로 유스케이스로 기록

– 반복 계획의 주요한 부분

– 유스케이스 실현이 설계

– 유스케이스가 사용자 매뉴얼 구성에 영향을 미친다.

• 시스템 유스케이스, 비즈니스 유스케이스

34

Use Cases Within the UP(2/2)

• 반복을 통한 유스케이스와 요구사항 분석

– 모든 요구사항 분석이 다 되기 전에 개발 시작

• Inception 단계에서의 유스케이스

– 10~20% 핵심적 유스케이스 : 상세하게 기술

• Elaboration 단계에서의 유스케이스

– 위험, 높은 가치, 아키텍쳐적으로 중요한 부분 : 요구사항의 주요부분 식별 및 명확화

• Construction 단계에서의 유스케이스

– 시스템 완성에 초점

35

Case Study: Use Cases in the NextGen Inception Phase

완전 자유 간략

판매 처리

반환 처리

렌탈 처리

판매 분석

보안 관리

…

현금 입금

현금 출금

사용자 관리

시스템시작

시스템 끝내기

시스템 테이블 관리

..

36

Further Readings

• Writing Effective Use Cases, Cockburn, 2001

• Structuring Use Cases with Goals, Cockburn, 1997

• Use Cases:Requirements in Context, Guiney, Kulak, 2000

• Applying Use Cases: A Practical Guide, Schneider, Winters, 1998

• www.usecases.org