学步园

2
Objectives
 Identify and write use cases.
 Relate use cases to user goals and elementary
business processes.
 Use the brief, casual, and fully dressed formats, in
an essential style.
 Relate use case work to iterative development.
3
Use case = “Story”
 Writing use cases—stories of using a system—is
an excellent technique to understand and
describe requirements.
4
What is use case?
 Use Cases are to discover and record functional
requirements.
 A use case captures a contract between the
stakeholders of a system about its behavior
ilftraesbdou .
 The use case describes the system’s behavior
under various conditions as it responds to a
request from one of the stakeholders, called the
primary actor
p r i m ar y act o r
.
 A Use Case is a collection of related success and
failure scenarios that describe actors using a
system to fulfill (or support) a goal.
 A scenario is a specific sequence of actions and
interactions between actors and the system under
discussion.
5
Major Concepts in Use-Case Modeling
 An actor represents anything that interacts with
the system.
 A use case is a sequence of actions a system
performs that yields an observable result of
value to a particular actor.
Use Case
Actor
6
Use Case
 The name of a Use Case should be the main goal
of the Use Case.
 Use cases are fundamentally a text form
,
although they can be written using graphic form.
 In UML use-case diagrams, a use case is
rendered as an ellipse.
Process Loan
7
Use Cases
 Use cases document system behavior from point
of view of the user
 A user
means anything that is
 external to the system under development and
which interacts with the system
8
Use Cases and Functional Requirements
 Use cases are requirements (not all requirements).
 Primarily they are functional requirements that
indicate what the system will do. Use cases define
a promise or contract of how a system will behave.
 Use cases provide a structured way to help with
requirements capture
 Identify the actors
 Find out what actors need from the system
 Find out any other interactions the actors expect
to have with the system
9
Use Cases Basics
 An actor
is something with behavior, such as a person
(identified by role
), computer system, or organization; for
example, a cashier
 The actor
initiates an interaction with the system to accomplish
some goal. The system responds, protecting the interests of all
the stakeholders.
 A scenario
is a specific sequence of actions and interactions
between actors and the system under discussion. It is one
particular story of using a system, or one path through the use
case;
 A use case
is a collection of related success and failure
scenarios that describe actors using a system to support a goal
10
Example of UC
Example of POS Use Case – Handle Returns
Handle Returns
Main Success Scenario:
M a i n S u c e s S c e n a r i o :
A customer arrives at a checkout with
items to return. The cashier uses the POS system to record each
returned item ...
Alternate Scenarios:
A l t e r n a t e S c e n a r i o s :
If the credit authorization is reject, inform the customer and ask for an
alternate payment method.
If the item identifier is not found in the system, notify the Cashier and
suggest manual entry of the identifier code (perhaps it is corrupted). If
the system detects failure to communicate with the external tax
calculator system, ...
11
Actors
 An actor is anything with behavior, including the
system under discussion itself when it calls upon
the services of other systems.
 Primary and supporting actors will appear in the
action steps of the use case text.
 Actors are not only roles played by people, but
organizations, software, and machines.
12
Type of Actors
 Primary actor
irayoPm has user goals fulfilled through
using services of the system.
 For example, the cashier.
 Supporting actor
itragnopuSct
provides a service (for example,
information) to the system. Often a computer
system, but could be an organization or person.
 For example, the automated payment authorization
service
 Offstage actor
fraesoO has an interest in the behavior of
the use case, but is not primary or supporting
 For example, a government tax agency.
13
UC Names
 Every use case must have a name that distinguishes it
from other use cases.
 Rules of naming Use Case:
Verb + Noun
Place Order
leradPOc
Validate User
14
Goals and Brief Format Use Cases
 Customers and end users have goals
(needs/requirements) and want
computer systems to help meet them. The goals are primarily the
starting point of finding out use case
 Brief format Use cases are a mechanism to help keep it simple and
understandable for all stakeholders.
 Informally, they are stories of using a system to meet goals.
Here is an example brief format use case:
Process Sale:
A customer arrives at a checkout with items to purchase.
The cashier uses the POS system to record each purchased item. The
system presents a running total and line-item details. The customer
enters payment information, which the system validates and records.
The system updates inventory. The customer receives a receipt from
the system and then leaves with the items.
15
Notation
 Use cases are text documents, not diagrams
, and use-case modeling is
primarily an act of writing text, not drawing. However, the UML defines a use
case diagram to illustrate the names of use cases and actors, and their
relationships.
A Video Clerk who wants to rent a video to a customer
will communicate with the use case Rent A Video.
Rent A Video
Video Clerk
Actor:
human user
Actor:
external hardware, machine or system
Use Case
Association:
c ommunication between Actors and Use Cases
Association:
e xtends or u ses relationships between Use Cases
inheritance relationships between Actors.
Symbol Meaning / Usage
<actor name>
<actor name>
<use case name>
<association name>
16
Browse
Browser
Librarian
Update
Catalog
Reserve book
Borrow copy
of book
Return copy of
book
Borrow
Journal
Return
Journal
Extend loan
Use Case Diagram (a Library System)
Book
Borrower
Journal
Borrower
17
What Is a Use-Case Model?
 A model that describes a system’s functional
requirements in terms of use cases
 A model of the system’s intended functionality
(use cases) and its environment (actors)
View Report Card
Student
Register for Courses
Login
18
Use Case Model
The Use Case Model is described by the following constructs:
 Actors (name, description, status, subclass, superclass, and
associations)
 Use cases (number, subject area, business event, name, overview,
preconditions, description, associations, inputs, outputs, traceable to,
usability index, and notes)
 Communication-associations between actors and uses cases
 Relationships between use cases (same as use case associations)
 Termination outcomes
 Conditions affecting termination outcomes
 Termination outcomes decision table
 Use case scenarios (number, termination outcome, description, and
notes)
 Problem domain concept definitions
 System steps decision table
 Flow of events table
 System sequence diagram
19
Use Case model(2)
Use Case
Number:
Subject Area:
Business Event:
Name:
Overview:
Preconditions:
Description:
Associations:
Traceable To:
Usability Index:
Inputs:
Outputs:
Notes:
Actor
Name:
Description:
Status:
Subclass:
Superclass:
Associations:
Termination Outcome:
Conditions Affecting:
Flow of Events System Sequence Diagram
STEP A/S ACTION DATA VALIDATION NOTES
xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx
xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx
xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx
xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx
xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx
T
F
F
T
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
F
F
F
T
T
T
Decision Table
T
F
F
T
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
F
F
F
T
T
T
Decision Table
Problem
Domain
Concepts
Scenario Number
Use Case Number
Termination Outcome
Scenario Notes
Scenario Describption
20
UC Formality Types
 Use cases are written in different formats, depending on
need. Use cases are written in varying degrees of formality:
 Brief
- terse one-paragraph summary, usually of the main
success scenario. (The prior Process Sale example was
brief.)
 Casual
- informal paragraph format. Multiple paragraphs
that cover various scenarios. (The prior Handle Returns
example was casual.)
 Fully dressed
- the most elaborate. All steps and
variations are written in detail, and there are supporting
sections, such as preconditions and success guarantees.
21
Use-Case Specifications
 Name
 Brief description
 Flow of Events
 Relationships
 Activity diagrams
 Use-Case diagrams
 Special
requirements
 Pre-conditions
 Post-conditions
 Other diagrams Use-Case Specifications
...
Use-Case Model
Actors
Use Cases
22
Use-Case Flow of Events
 Has one normal, basic flow
 Several alternative flows
 Regular variants
 Odd cases
 Exceptional flows
for
handling error situations
23
What Is a Scenario?
 A scenario is an instance of a use case.
24
Case Study: Use Case - Process Sale
 See appendix for details
25
My Recommendation: The Two-Column Format
Actor Action (or Intention)
1. Customer arrives at a POS checkout
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier..
Cashier repeats steps 3-4 until
indicates
done.
6. Cashier tells Customer the total, and
asks for payment.
7. Customer pays.
System Responsibility
4. Records each sale line item and presents
item description and running total.
5. System presents total with taxes
calculated.
8. Handles payment
9. Logs the completed sale and sends
information to the external accounting
and inventory systems (to update inventory).
System presents receipt.
Main Success Scenario:
26
Extensions (or Alternate Flows)
 Extensions are very important. They indicate all the other
scenarios or branches, both success and failure.
 Extension scenarios are branches from the main success
scenario, and so can be notated with respect to it. For
example,
Extensions:
3a. Invalid identifier:
1. System signals error and rejects entry.
7b. Paying by credit:
1. Customer enters their credit account information.
2. System requests payment validation from external Payment
Authorization Service System.
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
3. ...
27
Use Case Template
Use Case
{ name }
Identifier
{ id }
Summary
{ Brief text summary of the use case. }
Actors
{ Names of actors involved in the use case. }
Description
{ Te
xt description of the use case. }
Preconditions
{ Things that must be true for the use case to be executed, i.e. start state S
0
.}
Normal Paths
1.
First step of the use case.
2.
S
econd step of the use case.
.
. { includes extension points, inclusions, etc. }
.
n. Last step of the use case.
Postconditions
{ Things that will be true after the use case has executed, i.e. final states S
f
. }
Exceptions
{ Any known exceptions that may interrupt normal flow of events. }
Alternate Paths
{ Alternative paths through the case
–
should include responses to exceptions. }
Requirements
{ Trace back to requirements
realized by this use case. }
Outstanding Issues
{ Text description of any issues concerning this use case needing resolution.
Should include identity of responsible party.}
28
USE CASE #X
<Use Case Name: An active verb phrase ( or gerund phrase) that describes the particular usage of the
system. See criteria governing use case granularity for cross-referring nouns used in the use case
name.>
Subject Area
<A grouping mechanism, used to group use cases>
Business Event
< Business events are triggers that stimulate activity within the business. They are the stimuli that
prompt the business to act. Many business events occur at the interface point between the business and
one of the external entities that it interacts with. Other business events are internal triggers based on
conditions or predefined time intervals. Business events must be atomic ( cannot be decomposed into
two or more events) and detectable (observable). Furthermore, it is not possible for a business event to
have partially happen.>
Actor(s)
<The actor initiating this use case. See criteria governing use case granularity when using more than
one actor.>
Use case
Overview
<Brief description -- one or two sentences -- that describes in a declarative style the overall scope and
content of the use case. Does not describe the flow of events, business or data validation rules. See
criteria governing use case granularity for cross-referring nouns used in the use case overview.>
Precond
i
tions
<Constraints that must be met for the use case to be executed. The system may have to be in a certain
state before the initiation of the use case is enabled. This may include required sequencing of use
cases; for instance, one or more other use cases may have to have been executed successfully for this
use case to begin.>
Termination Outcome
Condition Affecting Termination Outcome
<Alternative ways that the use
case may terminate. Sometimes
this means successful and
unsuccessful and sometimes there
are multiple successful ways in
which the use case can end.>
< The condition or conditions under which the corresponding termination outcome
occurs. Many times there is a straight one-to-one correspondence between
termination outcomes and conditions. However, often there are multiple conditions
and/or Boolean logic operators needed to express the right conditions. In these
instances, a decision table is often useful for communicating the termination
outcomes and the conditions under which they can occur.>
<termination outcome #2> <condition(s) for termination outcome #2>
Use Case
Description
<A simple, brief description of the series of events (conversation) of the most likely to occur termination
outcome (a/k/a main course). Should be expressed in terms of what the actor does and how system
responds. Should not be complicated by too many conditionals. In addition, should not include looping .>
Use Case
Associations
<A list of other use cases that this use case is extended by or is used by .>
Traceability
To:
<Other related work products, models, or documents that this use case is traceable to. This may include
business rules, data validation rules, a traditional functional requirements document, business objectives,
GUI sketches/mockups/screens/prototypes, use case s cenarios, etc….>
Inputs
Summary
<Summary level listing of data input by the actor. Can be all inclusive but doesn’t have to be .>
Output
Summary
<Summary level listing of data output by the system. Can be all inclusive but doesn’t have to be .>
Usability
Index
<How the use case ranked in terms of satisfaction, importance and frequency .>
Use Case
Notes
<Information that is not directly part of the use case but arises while working
on the use case. For example, questions, actions-items, design notes .>
29
How to Find Use Cases
 1. Choose the system boundary
. Is it just a software
application, the hardware and application as a unit, that
plus a person using it, or an entire organization?
 2. Identify the primary actors
. Those that have user
goals fulfilled through using services of the system.
 3. For each, identify their user goals
. Raise them to the
highest user goal level that satisfies the EBP guideline.
 4. Define use cases that satisfy user goals
; name them
according to their goal. Usually, user goal-level use cases
will be one-to-one with user goals, but there is at least one
exception, as will be examined.
30
Identifying Actors
 When developing a use case model, identify the
different roles played by the potential human users
of the system
 People play different roles at different times
 E.g. A person can play the role of book borrower,
librarian, browser or journal borrower at different times
 Any person who interacts with the system will be
represented by at least one actor in use case model
 Typical Actors:
 Roles that people play
 Computer systems
 Electrical or mechanical devices
31
Identifying Non–Human Actors
 Which external systems or devices that interact
with the system should be shown on a use case
diagram?
 These external systems or devices can either be
shown:
 at all times,
 when the other system or device initiates contact, or
 when the other system or device gets value from the
contact
32
Identifying Use Cases
 Actor-Based Approach:
 Identify actors related to a system or organization
 Then, for each actor, identify the process they initiate or
participate in
 Event-Based Approach:
 Identify external events that a system must respond to
 Relate events to actors and use cases
 Yet Another approach:
 Express business processes in terms of specific
scenarios, then generalize
33
A Common Mistake
 Representing individual steps, operations, or
transactions as use cases
 Question: In POS system, is there a use case
called “printing receipt”?
 Tip:
 Use case is relatively large end-to-end process
description that typically includes many steps or
transactions
34
Case Study: Writing Use Case - Step 1: Choosing the System Boundary
 For this case study, the POS system itself is the
system under design; everything outside of it is
outside the system boundary,
including the
cashier, payment authorization service, and so on.
 If it is not clear, defining the boundary of the
system under design can be clarified by defining
what is outside the external primary and
supporting actors.
 Once the external actors are identified, the
boundary becomes clearer.
35
Continue
Goal: Process sales
Cashier
Customer
POS System
Checkout Service
Goal: Buy item s
Enterprise Selling Things
Sales T ax
Agency
Goal: Collect
taxes on sales Sales Activity
S yste m
Goal: Analyze sales
and performance data
36
Steps 2 and 3: Finding Primary Actors and Goals
 Primary actors have user goals fulfilled through using services of
the system
. (Supporting actors provide services to the system under
design)
 Brainstorm
the primary actors! The primary actor is the framework for
further investigation.
 Think of goals
of the system
 Be suspicious if no primary actors are external computer systems.
 Reminder Questions to Find Actors and Goals:
Who starts and stops the system?
Who does system administration?
Who does user and security management?
Is "time" an actor because the system does something in response to a time event?
Is there a monitoring process that restarts the system if it fails?
Who evaluates system activity or performance?
How are software updates handled? Push or pull update?
Who evaluates logs?
Are they remotely retrieved?
37
(Continue) Work out The Actor-Goal List
Actor
Goal
Actor
Goal
Cashier process sales System add users
process rentals Administrator modify users
handle returns delete users
cash in manage security
cash out
Manager start up shut down Sales Activity
System analyze sales and
performance data
38
Step 4: Define Use Cases
 Name the use case similar to the user goal
(name use cases starting with a verb
).
 For example, Goal: process a sale; Use Case:
Process Sale
P r o cess S al e
39
Steps to write a use case (Important)
 Step 1: Find the boundaries of the system
(Context diagram, In/out list).
 Step 2: Brainstorm and list the primary actors.
(Actor List)
 Step 3: Brainstorm and list the primary actors'
goals against the system. (Actor-Goal List)
 Step 4: Write the outermost summary level use
cases covering all the above.
 Step 5: Reconsider & revise the strategic use
cases. Add, subtract, merge goals.
 Step 6: Pick a use case to expand or write a
narrative to get acquainted with the material.
40
Steps to write a use case (Continue)
 Step 7: Fill in the stakeholders, interests,
preconditions and guarantees. Double check them.
 Step 8: Write the main success scenario. Check it
against the interests and the guarantees.
 Step 9: Brainstorm and list possible failure
conditions and alternate success conditions.
 Step 10: Write how the actors and system should
behave in each extension.
 Step 11: Break out any sub use case that needs
its own space.
 Step 12: Start from the top and readjust the use
cases. Add, subtract, merge. Double check for
completeness, readability, failure conditions.
41
Use Case Diagrams
 The UML provides
use case diagram
notation to illustrate
the names of use
cases, actors, and
the relationships
between them
N extGen
Manage Users
. . .
Cashier
S yste m
Administrator
actor
use case
system boundary communication
Handle Returns Payment
Authorization
S e rvice
«actor»
Tax Calculator
«actor»
Accounting
S yste m
alternate
notation for
a computer
system actor
Process Rental
«actor»
H R System
C ash In
Process Sale
«actor»
Sales Activity
S yste m
Manage Security
Analyze Activity
42
Discussion of UCD
 A common sign of a novice (or academic) usecase
modeler is a preoccupation with use case
diagrams and use case relationships, rather than
writing text.
 Suggestion: Draw a simple use case diagram in
conjunction with an actor-goal list.
 A use case diagram is an excellent picture of the
system context; it makes a good context diagram,
that is, showing the boundary of a system, what
lies outside of it, and how it gets used.
43
UC Diagram Suggestions
N extGen
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.
«actor»
Payment
Authorization
S ervice
The class box style can be
used for any actor, computer or
human. Using it for computer
actors provides visual
distinction.
44
Splitting Use Cases
 Write major steps or branching activities of a use
case as a separate one when:
 They are duplicated in other use cases
 They are complex and long and separating them helps
factor the use cases into manageable pieces
45
UML: Include Relationship
Buy Items
Cashier Customer
Pay By Credit
POST
Pay By Cash Pay By Check
<<include>> <<include>> <<include>>
• A include relationship from use case A to use case B
indicates that A will also include the behavior as specified by
B•
similar behavior across use cases is identified after the use
cases are specified
46
Another Example
Withdraw Case
Deposit Case
Use ATM
Transfer Account
47
UML: Extend Relationship
 sometimes use cases are complex because they
have many steps
 Used when a second use case story follows the
story of a prior use case
 Extending a use case is, effectively, an alternate
taenltr
course of base use case
 Introduce an extending use case whenever logic
for an alternate course of action is at a complexity
level similar to that of your basic course of action
48
(Continue)
 An extends relationship from use case A to use case B
indicates that an instance of B may include (subject to
specific conditions) the behavior specified by A
Enroll In
University
Perform Security
Check
University Enrolment System
Enroll Family
Member in
University
Enroll in
Seminar
Registrar
Student
International
Student
Applicant
<<include>>
<<extend>>
49
Another Example
Enter Text
Check Spelling
Change Template
Find Word
<<extend>>
<<extend>>
<<extend>>
50
Requirements Considerations
 The use case
idea is the consideration and organization of
requirements in the context of the goals and scenarios
of using a system
 Use cases capture detailed, low-level system feature
 Use Cases are not Object-Oriented
 Use cases are not the only necessary requirements artifact.
Some non-functional requirements, domain rules and
context, and other hard-to-place elements are better
captured in the Supplementary Specification
 It is useful to summarize system functionality with a highlevel
feature list called system features
in a Vision
document.
51
Use Cases through Development
 Planning:
 List all the use cases for the system
 Have a good idea of what each means
 Understand who wants each and how much
 Know which use cases carry the most risk
 Plan which should take to implement
 Determine the order of implementation of the use
cases, and which ones belong in which iteration of
the system
52
Use-case Driven Development
 Requirements are primarily recorded in use cases (the
Use-Case Model); other requirements techniques (such as
functions lists) are secondary
 Use cases are an important part of iterative planning. The
work of an iteration is defined by choosing some use case
scenarios, or entire use cases. And use cases are a key
input to estimation
 Use case realizations drive the design. That is, the team
designs collaborating objects and subsystems in order to
perform or realize the use cases
 Use cases often influence the organization of user
manuals
53
Business Use Case
 Business use cases
are less commonly written. If done,
they are created in the Business Modeling
discipline as
part of a large-scale business process reengineering effort,
or to help understand the context of a new system in the
business.
 Business use case describes a sequence of actions of a
business
as a whole to fulfill a goal of a business actor
(an
actor in the business environment, such as a customer or
supplier).
For example, in a restaurant, one business use case is
Serve a Meal.
54
Problems with Use Cases (1 of 2)
 Use case modeling should be used with caution
 Danger of building a non-object oriented system
 To lessen this danger, carefully manage the beginning of each
iteration
 Do not add any new functionality if the previous iteration was
unsatisfactory
 Danger of mistaking design for requirements
 Design can involve different sequences of interactions which
achieve the same goal but may be “new” to the users
 Requirements can be met in many different ways through design
variations
55
Problems with Use Cases (2 of 2)
 Danger of missing requirements
 Relying too heavily on process of finding actors first,
then finding use cases each needs
 Lessen this danger by doing use case analysis and
conceptual class modeling in parallel
56
Use Case Traps
 Too many use cases
 Highly complex use cases
 GUI-containing use cases
 Data definitions or algorithms in use cases
 Use cases users don’t understand
 New business processes
57
Case Study - Use Case: Body shop free estimate
 The dealership's body shop offers free estimates.
In this Use Case, the body shop estimator
provides an estimate of parts, labor, and schedule
for a customer with a damaged vehicle.
 The primary actor is the body shop employee
performing the estimate (the "estimator").
58
Sample brief Use Case
Body Shop Free Estimate
A customer shows up at the body shop with a
damaged vehicle. The estimator enters the
customer's information and the vehicle
identification (VIN, license, etc). He then enters
each damaged part or labor task into the system,
which accumulates them. When he is finished
entering data, the system creates and stores the
estimate. A copy of the estimate is printed for the
customer.
59
Stakeholders
Estimator -- Wants software support to generate an accurate
estimate.
Customer -- Wants to know how much it will cost him to fix his
car, and when the work will be completed.
Parts department -- Wants advanced notice of long-lead-time
parts.
Body shop -- May need to schedule this job.
Paint shop -- May need to schedule this job.
Service department -- May need to schedule this job.
Accounting & payroll -- May need to charge the estimator's time
to a different account.
Insurance company -- Keeps tabs on estimates generated.
Rental organization -- Is a loaner vehicle available? What is
pricing for this customer?
Sales organization -- May be an opportunity to sell another car.
60
Preconditions
 System is preloaded with parts lists and
diagrams for all major makes and models of
cars.
 System is preloaded with the dealership's
database of labor and shop time charges.
61
Postconditions
Estimate is generated.
Estimate is retained for use when/if customer
chooses to have work performed.
62
Main scenario
1. Customer arrives with damaged car (or it is towed in).
2. Estimator enters customer identification into system.
3. Estimator enters vehicle information (make, model, year, VIN,
etc) into system.
4. Estimator enters into system either a part for repair/replacement
or a labor item (e.g., "paint front fender").
5. System accumulates cost of replacement part and/or labor
associated.
Repeat steps 4-5 for all damaged or missing parts or shop tasks.
6. Estimator indicates end of parts & labor data entry.
7. System generates estimate (parts list, labor total, and estimated
completion date). Estimate is saved (for comparison with actual
work, in case of dispute with customer, and for statistics).
8. System prints estimate for customer.
63
Alternate flows
 5b. System has no record of the specified part or labor item.
 5b1. System notifies estimator that database contains no
record for this item.
 5b2. Estimator enters manual estimate for that item.
 5b3. System accumulates manual estimate and notes this
line item as such.
 5b4. System files this manual estimate for later review and
'official' entry into database.
 8a. Customer chooses to have work performed.
 8a1. See Use Case BS2, "Body Shop Open Repair Order"
64
What Is an Activity Diagram?
 An activity diagram in the Use-Case Model can be used to
capture the activities in a use case.
 It is essentially a flow chart, showing flow of control from
one activity or action to another.
Flow of Events
This use case starts when the Registrar requests that
the system close registration.
1. The system checks to see if registration is in
progress. If it is, then a message is displayed to the
Registrar and the use case terminates. The Close
Registration processing cannot be performed if
registration is in progress.
2. For each course offering, the system checks if a
professor has signed up to teach the course offering
and at least three students have registered. If so, the
system commits the course offering for each schedule
that contains it.
Activity1 Activity3
Activity2
65
Example: Activity Diagram
Activity/Action
Synchronization
Bar (Fork)
Guard
Condition
Synchronization
Bar (Join)
Decision
Concurrent
Threads
Transition
Select Course
[ add course ]
Check
Schedule
Check
Pre-requisites
Assign to
Course
Resolve
Conflicts
Update
Schedule
Delete Course
[ checks completed ] [ checks failed ]
[ delete course ]
66
Partitions
Determine
Need
Take Order
Setup Payment
Deliver Order
Fill Order
Fulfillment
Sales
67
Summary: SW Development Artifacts and Use Case Model
V isio n Supplementary
Specification
Softw are
Architecture Doc.
Glossary
D om ain
Model
Requirements
Project
Management
Business
M ode ling
D e s ign
Partial artifacts,
refined in each
iteration.
Test
T est
P la n
Softw are
D ev. Plan
Design Model
* *
U se-C ase
Model
Environment
Development
C a se
68
Case Study: Course Registration System Use-Case Model
 Investigate Course Registration
Requirements artifacts:
 Problem statement
 Glossary
 Supplementary Specification
 And now how do we produce:
 Use-Case Model main diagram
 Write use cases
69
Solution
70
Exercise 1: Payroll System Use-Case Model
 Given the following Payroll Requirements
artifacts:
 Problem statement
 Glossary
 Supplementary Specification
 Produce the following:
 Use-Case Model main diagram
 Write any of three use cases 

Use-case model: drawing system sequence
diagrams
2
Objectives
 Identify system events.
 Create system sequence diagrams for use cases.
3
Moving on to Iteration 1
What have we done?
 Some light requirements work
was done in inception
to help
decide if the project was worth more serious investigation
.
 Planning for the first iteration
has been completed
 We have decided to tackle a simple cash-only success
scenario
of Process Sale
o f P r o c e s S a l e
(with no remote collaborations), with
the goal of starting a "wide and shallow" design and
implementation that touches on many major architectural
elements of the new system.
 In the first iteration, many tasks related to establishing the
environment (tools, people, process, and setting) occur
Our focuses from now on are:
 Understand what problems are (Analysis
), rather than how to
solve problems (Design
)
 Analysis - use case and domain modeling analysis.
4
Introduction – System Sequence Diagram
 A system sequence diagram
is a fast and easily
created artifact that illustrates input and output
events related to the systems under discussion
 Before proceeding to a logical design of how a
software application will work, we should
investigate and define the system behavior as a
"black box
laxbock
“.
5
System Event and Response
 Use cases describe how external actors interact
with the software system.
 During this interaction an actor generates events
to a system, usually requesting some operation in
response.
For example, when a cashier enters an item's ID, the
cashier is requesting the POS system to record
that item's sale. That request event initiates an
operation upon the system.
6
System sequence diagram
 A system sequence diagram
(SSD) is a picture
that shows, for a particular scenario of a use case,
the events that external actors generate, their
order, and inter-system events.
 The emphasis of the diagram is events that cross the
system boundary from actors to systems.
 An SSD should be done for the main success scenario
of the use case, and frequent or complex alternative
scenarios.
 An SSD is generated from inspection of a use case
Suggestion:
 One SSD – one Use Case
7
Case Study: How to do SSD in the POS Project
 Simple cash-only
Process Sale
P r o c e s S a l e
scenario:
1. Customer arrives at a POS checkout with goods and/or
services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item
description, price, and running total.
Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
...
8
Step 1: Define System Events and the System Boundary
enterItem(itemID, quantity)
: Cashier
endSale()
makePayment(amount)
system boundary
:S yste m
makeNewSale()
the system boundary is usually chosen to be the software system itself;
in this context, a system event is an external event that directly
stimulates the software
9
Step 2: Naming System Events and Operations
enterItem(itemID, quantity)
scan(itemID, quantity)
: Cashier
worse name
better name
:S yste m
10
Step 3: show Use Case
 Simple cash-only
Process Sale
P r o c e s S a l e
scenario:
1. Customer arrives at a POS checkout with goods and/or
services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item
description, price, and running total.
Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
...
11
Step 4: Do SSD
: Cashier :S yste m
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and
presents item description, price, and
running total.
Cashier repeats steps 3-4 until indicates
done.
5. System presents total with taxes
calculated.
6. Cashier tells Customer the total, and
asks for payment.
7. Customer pays and System handles
payment.
...
enterItem(itemID, quantity)
endSale()
makePayment(amount)
description, total
total with taxes
change due, receipt
* [more items]
makeNewSale()
12
SSD of UC - Process Sale
enterItem(itemID, quantity)
: Cashier :S yste m
endSale()
makePayment(amount)
box may enlose an
iteration area
the * [...] is an iteration
marker and clause
indicating the box is for
iteration
external actor to
s y s te m
Process Sale Scenario
system as black box
the name could be "NextGenPOS" but "System" keeps it
sim p le
the ":" and underline imply an instance, and are explained in a
later chapter on sequence diagram notation in the UML
a message with
parameters
it is an abstraction
representing the
system event of
entering the
payment data by
som e m echanism
description, total
total with taxes
change due, receipt
* [more items]
makeNewSale()
13
Relationships of SSDs to other artifacts