Transcript UseCases소개

Use Cases
컴포넌트비젼(주) 이경원
email: [email protected]
ComponentVision Inc.
1
소프트웨어 개발 과정
요구사항 수집(Requirements gathering)
분석(Analysis)
설계(Design)
구현(Construction)
검사(Testing)
배포(Deployment)
유지보수(Maintenance)
ComponentVision Inc.
2
소프트웨어 개발 과정
요구사항 수집(Requirements gathering)  우리의 관심사!!
분석(Analysis)
설계(Design)
구현(Construction)
검사(Testing)
배포(Deployment)
유지보수(Maintenance)
ComponentVision Inc.
3
전통적으로 요구사항 수집은…
오래 걸리는
잘못된 것을 기록하는
발생하지 않을 일을 추측하는
시간에 맞춰 끝나기는 하지만 급변하는 비즈니스 환경 덕에 재작업이 필요
하게 되는
경향이 있다
ComponentVision Inc.
4
요구사항이 어쨌는데?
ComponentVision Inc.
5
요구사항이란 무엇인가?
컴퓨터 어플리케이션이 사용자에게 제공해야 하는 어떤 것
요구사항들이 소프트웨어 개발 프로젝트의 범위(Scope)가 된다.
시스템이 사용자에게 어떤 응답을 해야 하는가를 제시한다.
요구사항은 ‘어떻게’가 아니라 ‘무엇을’에 관한 사항이다.
요구사항은 대게 추상적이거나 불분명하다.
개발자의 두뇌 안에 요구사항과 디자인이 늘어 붙는 경향이 있다.
요구사항과 디자인을 분리시키는 것이 매우 중요하다.
ComponentVision Inc.
6
요구사항 구성요소
기능적 요구사항
시스템이 사용자를 위해 해 줬으면 하는 일들에 대한 요구사항.
비 기능적 요구사항
사용자에게 중요하지만 일반적으로 감춰져서 잘 깨닫지 못하는 요구사항.
ComponentVision Inc.
7
비 기능적 요구사항
정의
Availability
Rate of hardware and software component failure (mean time between failures)
Cost of ownership
Overall operating costs to the organization after the system is in production
Maintainability
Ability of the support programming staff to keep the system in a steady running state,
including enhancements
Data integrity
Tolerance for loss, corruption, or duplication of data
Development cost
Overall cost of development
Extensibility
Ability to accommodate increased functionality
Flexibility
Ability to handle requirement changes
Functionality
Number, variety, and breadth of user-oriented features
Installability
Ease of system installation on all necessary platforms
Leverageability/Reuse
Ability to leverage common components across multiple products
Operability
Ease of everyday operation; level of support requirements
Performance
Ability to meet real-time constraints in batch and online
Porability
Ability to move the application to different platforms or operating systems
Quality
Reduced number of severe defects
Robustness
Ability to handle error and boundary conditions while running
Scalability
Ability to handle a wide variety of system configuration sizes
ComponentVision Inc.
8
요구사항 정의 견본
요구사항 리스트
Requirement
Definition
6.7.1.4.2
The system must provide the capability to capture all of the customer
transactions for the fiscal year.
6.7.1.4.3
The system will provide restricted remote inquiry access(via dial-in)
to view images and data separately or simultaneously.
6.7.1.4.4
The system will barcode documents automatically prior to distribution.
At a minimum, the codes will be used to identify to which work queue
the documents should be routed within the organization when they are
returned.
6.7.1.4.5
When a workflow is initiated, the system must be able to prefetch the
documents that are in electronic image format by document type or
grouping of documents by process.
6.7.1.4.6
The system must create an entry in the journal file whenever a letter
is created.
…
이런게 100페이지 이상 …
ComponentVision Inc.
9
요구사항 정의가 산으로 가네?…
요구사항 수집 활동이 비 생산적인 경로를 거치기 때문.
요구사항 수집이 무시되는 경향이 있다.
개발팀은 시스템이 어떻게 작동해야 하는지에 대한 가정을 기반으로 해서 곧
바로 솔루션 작성에 들어간다.
요구사항 수집에만 매달리는 수도 있다.
수백 장에 달하는 ‘요구사항’들이 수집되고, 문서화 되고, 상호참조 되고, 뿌려
져서 결국 ‘Analysis Paralysis’가 되고 프로젝트는 취소된다.
요구사항을 한 사람이 결정한다.
시스템 오너나 고위급 경영자만을 위한 시스템이 만들어 진다.
전산인들이 요구사항에 대해 헛 짚는 전형적인 사례
디자인에 대한 생각이 개입
애매 모호 한 듯 하면서 분명치 않은 것 같은
전산인들만의 은어 사용
ComponentVision Inc.
10
기능 요구사항을 표현하는 전통적인 방법
Requirements specifications
“시스템은 ~~해야 한다”식의 나열.
요구사항이 중복되거나 상충되기 쉽다. 좀더 구조화된 먼가가 필요
Data-flow diagrams (DFDs)
시스템 내부 동작에 초점을 둠.
사용자와 별 연관 없는 자료 흐름이 상세화 된다. 요구사항에는 부적절
Entity-relationship diagrams (ERDs)
데이터의 논리적인 모델과 데이터베이스의 구조를 보여줌.
동적인 상호작용을 보여주지 못한다.
자료 모델링에 적합
Prototypes
시스템의 기능을 보여주는 시제품.
사용자 인터페이스가 강조되는 경향이 있다.
ComponentVision Inc.
11
유스케이스 등장~
1960년대 후반 Ivar jacobson 박사에 의해 개념이 만들어짐
1980년대 후반 요구사항 정립의 수단으로 OOP 커뮤니티에서 각광을 받음
1990년대 중반 Ivar jacobson 박사가 Rational에 합류하면서 유스케이스
가 UML에 편입
현재 UML1.4와 RUP의 핵심적인 개념으로 사랑 받고 있음.
ComponentVision Inc.
12
유스케이스가 어쨌는데?
ComponentVision Inc.
13
유스케이스란 무엇인가?
요구사항을 뽑아내는 수단.
기능적 요구사항을 정의하는 것의 기반.
어플리케이션을 가늠해 보는 것을 수월하게 한
다.
시스템의 범위를 정하는 것을 돕는다.
최종사용자 혹은 고객과의 의사소통 수단.
시스템의 동적인 black-box view를 제공한다.
객체 도출의 기반
요구사항의 흔적을 찾을 수 있는 수단.
사용자 인터페이스나 경험 설계의 기반.
기능적 요구사항에서 객체/컴포넌트 구조로 되
는 것을 수월하게 한다.
기능을 객체/컴포넌트에 할당하는 것의 기반.
객체의 인터페이스와 상호작용을 정의하는 메
커니즘
ComponentVision Inc.
데이터베이스에 접근하는 패턴을 정의한다.
프로세서 용량을 재는 것을 도와준다.
통합 테스팅의 기반.
테스트 케이스를 정의한다.
점증적 개발의 기반.
프로젝트 규모와 필요한 자원의 예측하는 것을
돕는다.
사용자 문서와 매뉴얼의 기반을 제공한다.
프로젝트 관리의 도구.
개발 과정을 조정한다.
비즈니스 프로세스를 표현하는 표준 방법.
리엔지니어링 과정에서 레가시 시스템을 설명
하는데 사용됨.
e-비즈니스 기업이 되기 위해 리엔지니어링을
할 때 사용됨.
…
대신에 Snake oil이나 Silver bullet은 아니다.
14
그래서 유스케이스란 무엇인가?
요구사항을 뽑아내는 수단.
시스템의 범위를 정하는 것을 돕는다.
최종사용자 혹은 고객과의 의사소통 수단.
유스케이스 다이어그램과 유스케이스 기술서로 구성되어 있다.
ComponentVision Inc.
15
유스케이스 다이어그램
나 유스케이스
나 액터
<<include>>
나도 유스케이스
ComponentVision Inc.
<<extend>>
내도 유스케~이스
난 쓰임새
16
액터 (Actor)
특정 작업을 완수할 목적으로 시스템과 상호 작용하는 사람이나 사물의
역할.
액터 사례
사람 - 텔레마케터
외부시스템 - 청구시스템
장치 - 열 감지 센서
외부조직 - 금융감독원
이벤트 발생시점 - 매일 밤 2시
Primary 액터, Secondary 액터 - [Ivar Jacobson]
ComponentVision Inc.
17
액터 (Actor)
액터의 성격에 따른 분류
Initiator – 유스케이스를 시작시킨다.
External server – 유스케이스 내에서 시스템에 서비스를 제공한다.
Receiver – 유스케이스로부터 정보를 전달 받는다
Facilitator (proxy) – 다른 액터와 시스템간의 상호작용을 돕는다.
고객
initiator
ComponentVision Inc.
창구직원
예약등록
Facilitator
18
유스케이스 (Use Case)
시스템이 액터에게 주목할 만한 결과를 내놓기 위해 수행하는 여러 작업들
의 집합 – [Booch 1999]
유스케이스는 하나의 목표와 사용자가 목표에 달성하기 위해 수행하는 시
도에 따라 발생하는 모든 가능한 사항을 기술한다.
유스케이스 사례
대출을 신청한다. 대출 현황을 점검한다.
유스케이스의 분화
비즈니스 유스케이스 (business use case)
시스템 유스케이스 (system use case)
체인지 케이스 (change case)
테스트 케이스 (test case)
비즈니스 케이스 (business case)
ComponentVision Inc.
19
포함 (include) 관계
유스케이스의 이벤트 흐름 안에 다른 유스케이스의 행동을 포함하는 것.
유스케이스 간에 공통 발생 부분을 뽑아내서 참조하게 한다.
Including유스케이스는 included유스케이스 없이는 제구실을 못한다.
including
<<include>>
included
ComponentVision Inc.
20
확장 (extend) 관계
한 유스케이스의 인스턴스가 다른 유스케이스의 기능에 의해 확장되는 것.
확장시키는 유스케이스를 별도로 해서 관리를 용이하게 한다.
확장되는 유스케이스의 수정 없이 기능 추가를 할 수 있다.
Extended유스케이스는 extending유스케이스 없이도 제구실을 한다.
extended
<<extend>>
extending
Extension point~!
ComponentVision Inc.
21
유스케이스 기술서
유스케이스는 시스템의 기능에 대한 서술 표현
이름과 서술부분으로 구성되어 있다.
다양한 종류의 유스케이스 서술법이 존재한다.
워드 파일
노츠
위키위키
ComponentVision Inc.
22
유스케이스 기술서의 구성요소
이름 (Name)
반복 (Iteration)
액터 (Actor)
범위 (Scope)
수준 (Level)
요약 (Summary, Brief Description)
주 사건 흐름 (Main flow of event)
대안 흐름 (Alternative flow)
예외 흐름 (Exception flow)
사전조건 (Pre-condition)
사후조건 (Post-condition)
비즈니스 룰 (Business Rule)
사용자 화면 (User Interface)
작성자 (Author)
작성일 (Date)
…
ComponentVision Inc.
23
유스케이스 기술서 양식
<the name should be the goal as a short active verb phrase>
Context of Use: <a longer statement of the goal, if needed, its normal occurrence conditions>
Scope:<design scope, what system is being considered black-box under design>
Level:<one of: summary, user-goal, subfunction>
Primary Actor:<a role name for the primary actor or description>
Stakeholders and Interests: <list of stakeholders and key interests in the use case>
Precondition:<what we expect is already the state of the world>
Minimal Guarantees:<how the interests are protected under all exits>
Success Guarantees:<the state of the world if goal succeeds>
Trigger:<what starts the use case, may be time event>
Main Success Scenario:
<put here the steps of the scenario from trigger to goal delivery and any cleanup after>
<step #> < action description>
Extensions:
<put here there extensions, one at a time, each referring to the step of the main scenario>
<step altered><condition>:<action or sub use case>
<step altered><condition>:<action or sub use case>
Technology & Data Variations List:
<put here the variations that will cause eventual bifurcation in the scenario>
<step or variation #><list of variations>
<step or variation #><list of variations>
Related Information:
<whatever your project needs for additional information>
ComponentVision Inc.
24
유스케이스 기술서 양식
Use Case 25
Actually Login
Primary Actor: User
Scope: Application
Level: Subfunction
Upon presenting themselves, the user is asked to enter a username and password.
The system verifies that a submitter exists for that username and that the password corresponds to
that submitter. The user is then given access to all the other submitter commands.
If the username corresponds to a submitter that is marked as an administrator, then the user is given
access to all the submitter and administrator commands. If the username does not exist, or if the
password does not match the username, then the user is rejected
ComponentVision Inc.
25
유스케이스 기술서 양식
Use Case #
<the name is the goal as a short active verb phrase>
Context of use
<a longer statement of the context of use if needed>
Scope
<what system is being considered black box under design>
Level
<one of summary, primary task, subfunction>
Primary actor
<a role name for the primary actor, or a description>
Stakeholder and interests
stakeholder
Interest
<stakeholder name>
<put here the interest of the stakeholder>
<stakeholder name>
<put here the interest of the stakeholder>
Preconditions
<what we expect is already the state of the world>
Minimal guarantees
<the interests as protected on any exit>
Success guarantees
<the interests as satisfied on a successful ending>
Trigger
<the action upon the system that starts the use case>
Description
step
Action
1
<put here the steps of the scenario from trigger to goal delivery and any cleanup
after>
2
<…>
3
Extensions
Step
Branching Action
1a
<condition causing branching>:<action or name of sub use case>
1
<list of variations>
Technology and data variations
ComponentVision Inc.
26
유스케이스 기술서 양식
Customer
System
Enters order number
Detects that the order number matches the winning number of the
month.
Registers the user and order number as this month’s winner.
Sends an e-mail to the sales manager.
Congratulates the customer and gives her instructions on how to collect
the prize.
Exits the system
ComponentVision Inc.
27
유스케이스 기술서 양식
1. Use Case Name
1.1. Brief Description
…text…
1.2. Actors
…text…
1.3. triggers
…text…
2. Flow of events
2.1. Basic flow
…text…
2.2. Alternative flows
2.2.1. Condition 1
…text…
2.2.2. Condition 2
…text…
2.2.3. …
3. Special Requirements
3.1. platform
…text…
3.2. …
4. Preconditions
…text…
5. Postconditions
…text…
6. Extension Points
…text…
ComponentVision Inc.
28
유스케이스 어떻게 만드나?
ComponentVision Inc.
29
코번의 12단계
시스템의 범위와 경계 설정
시스템에 관계된 모든 액터 찾기
사용자가 시스템을 통해 얻으려고 하는 것(use case)들 찾기
각 액터에 대한 최 외각 유스케이스(summary use case) 설정.
최 외각 유스케이스들에 대한 정제 작업(시스템 범위의 재확인)
상세 작업을 할 유스케이스 선택
이해 관계자와 그들의 이(利), 선행조건, 후행조건 등을 뽑아냄
주 성공 흐름 작성
대안 흐름과 예외 흐름 찾기.
대안 흐름과 예외 흐름 작성.
복잡한 스텝을 하위 유스케이스로, 자잘한 스텝들은 모아서 하나로
유스케이스 조절작업(읽기는 쉬운지, 구색은 갖췄는지, 이해관계자는 만족
하는지)
ComponentVision Inc.
30
Advanced Use Case Modeling Framework
•스테이크 홀더 분석 수행
•유스케이스 프레임웍 선택과 맞춤작업
•개발 툴, 템플릿, 개발 표준 선택
•교육과 컨설팅 필요성에 대한 결정
•컨텍스트 다이어그램 작성
•주요 액터를 찾는 작업
•개념적 시스템 유스케이스를 찾는 작업
•초기 유스케이스 다이어그램 작성
•개념적 비즈니스 객체 결정
•기본 유스케이스 설명 작성
•기본 유스케이스 설명 갈고 다듬기 작업
•유스케이스간의 관계 작성
•유스케이스와 객체 모델간의 연관관계 작성
•유스케이스 시나리오 작성
Prepare for
use case
modeling
Perform initial
use case
modeling
•테스트 전략 작성
•테스트 계획 작성
•테스트 케이스 작성
•사용자 도큐먼트 작성
•비즈니스 기능적 패키지 작성
•유스케이스 의존 관계 찾는 작업
•스테이크 홀더의 입장에서 유스케이스 조직화
•유스케이스 모델 리팩토링
Expand on
the use case
model
Create test
cases and
documentation
Organize
the
use cases
Ongoing use case management
*Advanced use case modeling 발췌
ComponentVision Inc.
31
좀 추려서 정리하면…
시스템의 범위를 결정하고
액터를 찾고
유스케이스의 이름 정도를 찾고
유스케이스의 주 성공 흐름을 작성하고
유스케이스의 대안/예외 흐름을 작성하고
적절히 패키징 해서 정리한다.
ComponentVision Inc.
32
반복을 통해 상세함을 더한다
Initial
이름 :
액터 :
요약 :
ComponentVision Inc.
Base
이름 :
액터 :
요약 :
선행조건 :
사건 흐름 :
사후조건 :
Elaborated
이름 :
액터 :
요약 :
선행조건 :
사건 흐름 :
사후조건 :
대안흐름 :
예외흐름 :
33
자주 논의되는 사항들
ComponentVision Inc.
34
적절한 Use-Case의 크기는?
ComponentVision Inc.
35
Use Case Level
Overall Project
Advertise
Set Up
Promotion
Order
Reference
Promotion
Identify
Promotion
ComponentVision Inc.
Monitor
Promotion
Register
User
Summary
Goals
Invoice
Place
Order
Identify
Product
Create
Invoice
Send
Invoice
Identify
Customer
User
Goals
Subfunction
36
왜? 어떻게?
Summary
Goals
User
Goals
Subfunction
ComponentVision Inc.
37
적절한 레벨을 찾아라
유스케이스에 적절한 골 레벨을 표시 : summary, user, subfunction
내 ‘goal’들 중에서 user goal레벨이 어디인지를 점검
한사람이 한자리에 앉아서 한번(2분~20분)에 끝낼 수 있는 정도
종료되었을 때 액터가 자리를 뜨는데 어려움이 없는 정도
대부분의 유스케이스는 주요 이번트 흐름이 3~9단계. 만약 9단계가 넘는다
면 다음과 같은 스텝들을 하나로 합쳐라.
같은 액터가 여러 스텝을 점유
액터가 사용자 인터페이스를 사용하는 부분에 대한 상세한 스텝들
두 액터들간의 간단한 주고 받는 스텝들
“왜 액터가 이 스텝을 밟고 있나?” 에 대한 대답이 바로 다음 상위 레벨이
된다.
Subordinate use case vs. Sub use case
ComponentVision Inc.
38
Use Case 는 Functional decompositon이다!
ComponentVision Inc.
39
대가들의 대답
기능 분할이 문제 해결 구조의 밑바탕으로 사용되지 않는 한 문제 영역을
기능분할 하는 것에 문제될 것은 없다. – Robert C. Martin
시스템의 내부 구조가 외부 구조(Use cases)처럼 보여야 할 필요는 없다.
– Martin Fowler
ComponentVision Inc.
40
CRUD는 어떻게 처리하나?
ComponentVision Inc.
41
CRUD use case
Create, Retrieve, Update, Delete VS. Manage
각각의 목적이 다르기 때문에 나누어야 한다. VS. 유스케이스가 세배 이
상이 되므로 하나로 합쳐야 한다.
코번
초반에는 유스케이스의 숫자를 적게 하기 위해 manage로 처리한다.
유스케이스가 점점 복잡해지면 새로운 하위 레벨로 유스케이스를 뽑아낸다.
Summary 레벨의 Manage와 서브 레벨의 CRUD를 모두 보유.
ComponentVision Inc.
42
어떤게 잘 못된 유스케이스인가?
ComponentVision Inc.
43
전통적인 실수들
액터가 없는 유스케이스, 시스템이 없는 유스케이스
사용자 인터페이스의 내용을 너무 상세히 담고 있는 유스케이스
너무 낮은 레벨의 유스케이스
전산인의 언어를 사용한 유스케이스
어플리케이션 관점의 유스케이스
스타일을 변환한다. 스타일을 적용한다. 다른 문서의 스타일을 가져온다.
문서내의 양식을 일정하게 한다. 문서가 다른 문서와 비슷하게 보이게 한다.
…
ComponentVision Inc.
44
Reference
Writing Effective Use Cases – Alistair Cockburn
Advanced Use Case Modeling software systems – Frank Armour,
Granville Miller
Use Cases requirements in context – Daryl Kulak, Eamonn Guiney
Applying Use Cases, Second Edition a practical guide – Geri
Schneider, Jason P. Winters
Etc …
ComponentVision Inc.
45
Happy Modeling !!
감사합니다.
ComponentVision Inc.
46