Transcript Software Engineering - CS Division

Use Case Modeling
CEN 5016: Software Engineering
© Dr. David A. Workman
School of EE and Computer Science
University of Central Florida
February 1, 2005
(Revised February 14, 2006)
Requirements Capture
•
Input
Client approaches Developer with a problem and or product concept. This may be
expressed verbally or in the form of a document (Statement of Work (SOW))
(Request for Proposal (RFP))
•
Activities
Developer interacts with Client and Users to elicit product requirements. This
involves face-to-face meetings and possibly the exchange of technical documents.
The Developer must determine as completely and precisely as possible the
following information:
– cost and time constraints
– target system platform and operational environment
– user groups
– functional capabilities
– non-functional constraints: quality and performance
– Client and User's needs (as opposed to "wants")
•
Outputs
A complete understanding of the problem the Client and Users need to have solved.
Client should be in agreement with the Developer’s assessment of the problem. This
shared view of the system is captured in the form of a UML Use Case Model.
September 28, 2005
(c) Dr. David A. Workman
2
Use Case Model
•
Definitions1
A Use Case is a sequence of actions that the system performs to offer some
results of value to a User.
– Use cases drive the whole development process. “They offer a systematic and
intuitive means of capturing functional requirements from the user’s perspective.”
– A system has many types of users. Each type of user is define by an actor. Actors
may be people or external systems. Actors interact with the product via one or
more Use Cases. An actor role is defined by a particular set of use cases performed
by that actor to accomplish a particular goal or objective.
– “All actors and uses cases make up a Use Case Model.”
– A good collection of use cases is central to understanding what your users want.
Use Cases also present a good vehicle for project planning, because they control
iterative development, … it gives regular feedback to users about where the
software is going.
– Use cases provide the basis of communication between the client and the
developers in planning the project.
1The
Unified Software Development Process, by Rumbaugh, Jacobson, and Booch,
Addison-Wesley, 1999, 0-201-57169-2.
September 28, 2005
(c) Dr. David A. Workman
3
Use Case Model
•
Definition2 (Fowler)
A Use Case captures a typical interaction between a user and a computer system.
– A use case captures some user-visible function.
– A use case may be small or large.
– A use case achieves a discrete objective for the user.
In its simplest usage, you capture a use case by talking to typical users and
discussing the various things they might want to do with the system.
Take each discrete task or action they want to do, give it a name, and
write up a short description.
During the Elaboration phase, this is all you need to do to get started.
2UML
Distilled, by Scott & Fowler
September 28, 2005
(c) Dr. David A. Workman
4
Use Case Modeling Process
Inputs:
Problem Statement (SOW)
Requirements Document
Initial Customer/User Mtngs
Analyze RQ For
Noun phrases
1.1
Classify Data as
Inputs/Outputs
1.2
List of
Noun Phrases
List of
Input Data
List of
Output Data
September 28, 2005
Produce
Use Case Model
1.0
Analyze RQ For
Use Cases & Actors
1.3
List of
Use Cases
Next
Review With
Customer/Users
1.6
Allocate
Inputs/Outputs/Actors
to Use Cases
1.4
Actor/Use Case
Relationships
Revise
Work Products
1.7
Determine
Relations Among
Use Cases
1.5
List of
Actors
Use Case
Relationships
(c) Dr. David A. Workman
5
Use Case Modeling Process
Produce
Use Case Model
1.0
Produce System
Use Case Diagram
1.8
Allocate
Use Case Inputs/Outputs
To Actors
1.9
Revise Use Case
Inputs/Outputs
1.10
Use Case
Diagram
List of Actor
Inputs to
Use Case
Next
Produce
Class/Object Diagram
1.12
Determine Data
Relationships
1.11
List of Classes
Objects and
Data members
Review With
Customer/Users
1.13
Revise
Work Products
1.14
Class
Diagram
List of Use Case
Outputs to Actor
September 28, 2005
(c) Dr. David A. Workman
6
Use Case Modeling Process
Produce
Use Case Model
1.0
Model Use Case
Interface
1.15
Define System
Boundary Objects
For Use Case
1.16
Use Case
Interface
Model
List of
Use Case
Interaction
Objects
September 28, 2005
Define Use Case
Interaction Scenario
1.17
Produce Use Case
Communication
Diagram
1.18
Next
Produce
Use Case Spec
1.19
Use Case
Interaction
Flows
Review With
Customer/Users
1.20
Revise
Use Case
1.21
Use Case
Spec
Use Case
Communication
Diagram
(c) Dr. David A. Workman
7
Use Case Modeling Process
Produce
Use Case Model
1.0
Complete
Use Case Model
1.20
Review With
Customer/Users
1.21
Use Case
Model
September 28, 2005
Revise
Use Case Model
1.22
Review by
SQA
1.23
Use Case
Model
(c) Dr. David A. Workman
Final
Revision of
UCM
1.24
Place Under
Config. Mgmt.
1.25
Release
UCM
1.26
Use Case
Model
Use Case
Model
8
Use Case Model Outline
Title (System Name, Author Name, Assignment, Course, Pub. Date)
–
–
TOC
List of Figures (optional for small documents)
1. System Summary
–
–
–
Overview of System Purpose and Context
Business Case ( business need and how this system will address this need )
System Operation
•
•
–
Use Case Diagram
Supporting Narrative (explains diagram: operational flow, actor roles )
System Interfaces ( External Interfaces with Actors )
2. Use Case Specifications
1. Purpose ( function from user’s perspective )
•
•
2.
3.
4.
5.
6.
Collaboration diagram (flow of interactions between actors and interface objects )
Narrative summary of use case purpose or function
Precondition (system states & triggering events )
Flow of Events (nominal flow of interaction events between actor and interface objects)
Alternative Paths (error processing flows; special case flows )
Post Condition (system states & completion events )
Special Requirements (non-functional : performance and quality )
3. Requirements Traceability
4. Glossary
September 28, 2005
(c) Dr. David A. Workman
9
Use Case Model: Detail
Title Page and Format
Document type, System Title, Author, Publication Date, Course, Assignment
Table of Contents (TOC)
Table of Figures (optional)
1. System Summary
1. Scope and purpose of document ( Document content, Intended audience )
2. Business case: motivation for building the system; how it meets needs of users
and organization
3. Concept of Operation
•
•
Use Case Diagram
Narrative explaining flow of use cases and their relationships. Identifies all actors
(and perhaps key internal agents) and introduces their roles with respect to the use
case(s) they engage in. Should also identify all major problem data elements
consumed, manipulated, or produced by the system.
4. System Interfaces (See Next Slide)
•
•
For each interface: identify the actors and use cases that exercise that interface, the
problem data content, flow direction, medium and/or mechanism.
For each interface: supporting diagrams illustrating actor interface (optional)
September 28, 2005
(c) Dr. David A. Workman
10
Use Case Model: System Interfaces
Actor
UseCase
Actor
Inputs
System Outputs
System
Interface
Mechanism
Vehicle at
Toll Booth
Pay Toll
with Cash
Money
(Coins | Bills)
Transaction Receipt
& Access Arm Raised
[& Change]
Interacts with
Toll Clerk and
Lane Access
Arm
On-Line
Transaction
System
Pay Toll
with Cash
Transaction
Accepted
Cash Transaction
(Amount Paid, Change,
Date)
TCP/IP
…
…
…
…
September 28, 2005
(c) Dr. David A. Workman
11
Use Case Model: Detail
2. Use Case Specifications
This section should include a subsection (2.xx) for each use case identified in section 1.3. Each
use case should have the following format and organization. An introductory section should
be included giving a diagram and narrative describing system states and their transitions.
1. Purpose: Specify the purpose of the use case – what it accomplishes from the view of the
actors involved and the service the system provides these actors. Support with a collaboration
diagram .
2. Preconditions: Specify the system states that must hold before the use case is defined or can
begin, AND the triggering event(s) that mark the beginning of the use case.
3. Interaction Scenario: In conjunction with collaboration and state diagrams , present the
primary or normal flow of interaction events that accomplish the purpose of the use case.
The collaboration diagram identifies the analysis classes involved in the scenario.
4. Alternative Scenarios: In conjunction with collaboration and state diagrams , present
possible alternative flows of interaction events. This subsection can be used to describe error
handling scenarios and/or alternative sub-use cases.
5. Post conditions: Specify the system states that result after the use case has completed, AND
the event(s) that mark the end of the use case.
6. Other Requirements: resource constraints, other qualify factors (e.g. reliability).
September 28, 2005
(c) Dr. David A. Workman
12
Use Case Modeling: Activity Diagram
Initial
Accept
Payment
Of Next
Motorist
[exact Amt]
??
Produce
Receipt
Release
Vehicle
[over payment]
Return
Change
September 28, 2005
(c) Dr. David A. Workman
13
Use Case Modeling: Communication Diagram
Toll Clerk
1: Pay Cash
2a: Return Change
2b: Return Receipt
3: Raise Access Arm
4: Leave Gate
Toll Arm
NOTE: Communication Diagram is UML 2.0 terminology.
In earlier versions of UML, these were called Collaboration Diagrams.
September 28, 2005
(c) Dr. David A. Workman
14
Use Case Model: Detail
3. Requirements Traceability
In this section you identify the sources of requirements and enumerate all
requirements statements. A source must be associated with each requirement.
This is best presented in the form of a table.
1.
List all sources of requirements statements. A source can be a document, an
interview with some individual (customer or user or expert), or a web site, etc.
Each source should be uniquely identified (by number or acronym ).
Ref[1] Customer Requirements for Jiffy Stop Simulation System
Ref[2] Personal interview with Dr. David Workman, CEO of CEN 5016..
2.
A Table should be constructed, such as the one shown below, where a statement
of the requirement is given (“shall” statement) and a reference to the
source containing or implying the requirement statement.
Requirements Statments
Requirements
Source
“The system shall simulate a convenience store customer engaged in the activity
of purchasing gasoline from the time the customer leaves the automobile to the
time the customer returns to the automobile upon completing the scenario.”
Ref[1] pp12, line 4.
“The pay-by-credit scenario shall support credit cards only – no debit cards.”
September 28, 2005
(c) Dr. David A. Workman
Ref[2].
15
Use Case Model: Detail
4. Glossary
The Glossary presents an organized list of problem space terms and their definitions
as elicited from the client and system users. This provides the common
vocabulary by which all system stake holders communicate. All common
synonyms should be included, but the most common synonym should be used
consistently through the rest of the document. For example, “clerk” is the most
preferred term for the person that processes purchases and interacts with the
customer to collect payment for gasoline purchased – this term should be used in
the body of the document. However, one should list acceptable synonyms in a
format as shown below.
Clerk: the convenience store agent (store employee) who processes each cash
transaction for gasoline; configures the gas pump to dispense the appropriate
fuel amount, and to produce a sales receipt of the transaction. Synonyms:
cashier.
The Glossary should capture all terms that denote problem objects and system
operations or use cases. It should capture all actors that externally interact with
the system and the terms that pertain to actor interfaces. The Glossary should be
used as a central repository of all information that is known about a particular
term.
September 28, 2005
(c) Dr. David A. Workman
16
Use Case Diagram
The system to be developed.
**
Select
Catalog
Actor1
**
Pay by
Credit Card
<extends>
<specializes>
Actor3
Place Order
<include>
<include>
**
Arrange
Payment
**
Order
Product
Actor2
Actor4
See
notes
•
•
•
Actors: perform user roles
Actions: identify use cases
Connectors: identify actors
that participate in an action.
September 28, 2005
(c) Dr. David A. Workman
association
extends
includes
specialization/
generalization
17
Use Case Model
Actors
An actor is a role that a user plays with respect to the system. An actor is a role that
requires the system to perform some function or task on its behalf, and not the
converse.
Since a user may play more than one role at different times, it is important to focus
on roles, rather than users (job titles ).
Actors carry out Use Cases; conversley, a Use Case may have several actors
performing it.
– For large systems, it is easier to identify the actors first and then define the Use
Cases each actor would perform.
– Actors do not have to be human, they could be external systems that must
interface with the system in question.
– User groups can be characterized or profiled in terms of the actor roles they play.
– Different actors may share some set of Use Cases. This may suggest a need for
assigning priorities to actors and/or defining some type of security mechanism to
resolve access conflicts; the system may therefore need a mechanism for
identifying a particular actor with which it is interacting.
– Actors generally receive value from a Use Case.
September 28, 2005
(c) Dr. David A. Workman
18
Use Case Diagrams
Connector: Association
**
Pay by
Credit Card
Bank
Customer
« initiates »
**
**
Order
Product
Manager
« initiates »
Association defines a communication link between actors and the use cases they participate in,
or between two or more use cases that have to interact (or share data) to accomplish their task.
Associations are not directional, suggesting that interactions are generally bi-directional.
However, UML does permit an “initiates” annotation to identify the actor or use case
that initiates the interaction. Association is the default relationship when others do not apply.
September 28, 2005
(c) Dr. David A. Workman
19
Use Case Diagrams
Connector: Includes
Arrange
Payment
**
« includes »
**
« initiates »
Buy
Product
Bank
« includes »
« includes »
Order
Product
Customer
Browse
Catalog
**
Manager
Includes is analogous to “whole-part” relationship between objects. One use case
(the “whole”) may require several subordinate processing actions or steps (the “parts”).
The subordinate actions are generally use cases themselves, but need not be. The Includes
relation should always be used if the subordinate action defines a necessary step to ensure
success of the superior use case, or if the superior use case has sole responsibility for
ensuring that the subordinate action is performed.
September 28, 2005
(c) Dr. David A. Workman
20
Use Case Diagrams
**
Connector: Extends
Casino System
**
« initiates »
Play
Black Jack
Exchange
Money
In-house
Dealer
In-house
Gamblers
« extends »
**
Play Card
Games
Electronically
**
« initiates »
Financial
Institutions
Remote
Gamblers
See Notes
Extends implies that one use case is a functional extension of the capabilities of
another use case. If A extends B, then A does everything B does and more.
Extension usually suggests extending either the potential user base, or extending
the functional capability to an existing client base – offering more services – or both.
September 28, 2005
(c) Dr. David A. Workman
21
Use Case Diagrams
See Notes
Connector: Generalizes/Specializes
Mail Boxes, Etc.
**
Ship by
US Mail
US Mail
System
**
« generalizes »
« initiates »
Customer
Ship
Package
« specializes »
Ship by
UPS
**
United
Parcel
Service
Generalization is analogous to the superclass – subclass relationship among
object classes. A generalizes B if B is a special case of A.
Specialization is the converse of generalizes, B specializes A.
NOTE: the arrow dictates how the relation should be read.
September 28, 2005
(c) Dr. David A. Workman
22
Use Case Diagrams
Connector: Uses
**
Buy
Stock
**
NYSE
« uses »
Establish
Telecomm
Link
« initiates »
« uses »
Customer
e-Pay
Bills
**
Bank
Uses defines a relationship where two or more use cases (or actions) share a common
function or action. Shared actions need not be use cases per se, but denote significant
system-level operations that can be factored to improve system performance. Also,
uses should be used to relate a major use case and an optional minor system action or
sub- use case.
September 28, 2005
(c) Dr. David A. Workman
23