SE 430
Object Oriented Modeling
Dennis Mumaugh, Instructor
dmumaugh@cdm.depaul.edu
Office: CDM, Room 432
Office Hours: Thursday, 4:00 – 5:30
September 24, 2015
SE 430: Lecture 3
1 of 94
Administrivia
 Comments and/or Feedback
 Email – make sure your email address on campus
connection is correct! At least one student has an email that
bounces!
 For documents to be submitted: be sure any embedded
figures are JPEG.
 Assignments:


You may use the solutions from the previous assignment(s) as a
basis for work on your next assignment
Solutions for assignments will be posted the next day (evening) after
they are due.
September 24, 2015
SE 430: Lecture 3
2 of 94
Assignment 2
Assignment 2 (Due October 1)
Visitor Information Subsystem: Subsystem Use Cases and Use-case
supplemental diagram.
 Produce the use-case model for the Visitor Information subsystem
 Deliverables:
 Cover page
 List of all actors, their goals and objectives
 Identification of use cases
 Brief descriptions of all use cases – see template
 Ranking of use cases and basis of ranking
 Use case diagram (all use cases – together).
 Detailed use case: (Fully dressed or expanded) description of major
use case
 Use-Case Supplemental Diagram (system sequence diagram)
 Glossary
 Forms that you may elect to use are on the reading list page.
September 24, 2015
SE 430: Lecture 3
3 of 94
Term Project
 Team Project Preliminary Description discusses the first deliverable.
Due (Due October 22)
 Preliminary project description – Team Project – Preliminary
Description.doc
http://condor.depaul.edu/dmumaugh/se430/assignments/Team
Project – Preliminary Description.doc
 List of primary use cases
 Team Project
 Due (Due November 19)
 http://condor.depaul.edu/dmumaugh/se430/assignments/TeamProje
ct.doc
 See the course documents page
 Team assignments are on the course documents page on D2L.

September 24, 2015
SE 430: Lecture 3
4 of 94
Projects
 Some sort of personal productivity enhancer

Smart phone or iPad application
 StarTrek™ Tri-corder

Field work support: GPS, pictures, documents, portable science lab
 Smart shopper device
 UPS delivery tracking or OTR Truck dispatch
 Guide for the blind
September 24, 2015
SE 430: Lecture 3
5 of 94
Project
Format of document
 Make sure each page is numbered and has name of project
and submission info
 Use standard “business” report formats
 Proofread your documents!
 Check that the submission contains all that is asked for and
in the correct (logical) order.
 Maximum size of submission is 25 pages or less, preferably
less!
September 24, 2015
SE 430: Lecture 3
6 of 94
Project Hints
 Get organized ASAP and have some meetings. You have three weeks




to decide on a project, develop requirements, use-cases and write-it up.
If possible, have some face to face meetings
There are collaboration groups for each team.
 Email list for each team
 Project collaboration site
Group drop outs:
 Reduce scope of project.
 Cover less use cases: max (<groupSize>-1, 2)
 Notify me ASAP if a team member is not working or seems to have
dropped out.
How (not) to lose in SE 430
 Read the paper and follow it. (Not!)
 Make a schedule and follow it. Try to pace yourselves and keep
making progress.
September 24, 2015
SE 430: Lecture 3
7 of 94
Project: Working in groups
 Rotate responsibilities
 Have a moderator and a recorder at each meeting


Moderator keeps meeting on track, keeps track of action items
Recorder keeps good notes
 Allow contributions from all members



Project is a learning process as well as just a job
Need to make sure all are on board
Use the Amerindian tradition of the "Talking Stick"
 Be careful not to overwhelm people.
 Tell people if you feel you are


Being ignored
Not given enough work or too simple work.
 Make a schedule of work and action items (deliverables, both
internal and external)

Keep communicating. Answer your mail promptly.
September 24, 2015
SE 430: Lecture 3
8 of 94
SE 430 – Class 3
Topic: Use-Case Model
 Concepts and Background
 The Use-Case Model in the Unified Process
» High level use cases
 Use-Case Workflow
 Use-Case Tasks and Artifacts
» Use Case Diagrams
» Ranking Use Cases
» Detailed Use Cases
 System Sequence Diagrams
Reading:
Arlow & Neustadt: Ch’s 4 & 5
Class reading list
September 24, 2015
SE 430: Lecture 3
9 of 94
Thought for the Day
"Never ask users what they want, or they'll tell
you."
September 24, 2015
SE 430: Lecture 3
10 of 94
Last Time
Topics:
 Requirements Analysis



Defining Requirements
Problem Statement or Project Charter or Vision
Requirements Document
» Formal list of what the product will do
 Business and Domain Rules
 Activity Diagrams
September 24, 2015
SE 430: Lecture 3
11 of 94
Big Picture
Today
September 24, 2015
SE 430: Lecture 3
12 of 94
Object-Oriented Modeling
September 24, 2015
SE 430: Lecture 3
13 of 94
What is a model?
 A model is an abstraction which strips away unnecessary details, and
views an entity from a particular perspective

This is another application of the just right principle: include just what you
need for the problem at hand, no more, no less
 Models allow us to:



Focus on the important parts of the entity
Ignore parts of the entity that are irrelevant
Hypothesize and reason about the entity
Paraphrased from Software Measurement and Estimation: A Practical Approach, L.M. Laird & M.C. Brennan,
2006
September 24, 2015
SE 430: Lecture 3
14 of 94
A fundamental modeling principle
“Models are not right or wrong, they are more
or less useful.”
- Martin Fowler
September 24, 2015
SE 430: Lecture 3
15 of 94
Types of object-oriented analysis models
 Requirements capture the needs and wants of various stakeholders and
formalize them as user stories
 Requirements represent a collective mental model of the system
viewed from the stakeholders' perspective
‣ Everyday mental model example: Thermostats of different sorts
 The use-case model—use cases and system sequence diagrams—
models the dynamic/behavioral/process-oriented aspects of the system
 However, the use case diagram is a static diagram that models the
static relationships among actors and use cases
 The domain model—diagram and glossary—models the
static/structural/logical aspects of the system
 Domain processes are modeled in both the use case model and in the
domain model
September 24, 2015
SE 430: Lecture 3
16 of 94
Domain processes: static and dynamic representations
Domain processes are modeled
statically in the domain model
and dynamically in use cases
September 24, 2015
SE 430: Lecture 3
17 of 94
Visualizing O-O model relationships
September 24, 2015
SE 430: Lecture 3
18 of 94
Modeling system behavior
September 24, 2015
SE 430: Lecture 3
19 of 94
Modeling system behavior
Typical ways of modeling system behavior
 Scenarios or story boards
 Use cases or user stories
 (System) Sequence diagram: way of drawing a picture of a
scenario
 (Object) Interaction diagrams


Message sequence charts
Communication (Collaboration) Diagrams
September 24, 2015
SE 430: Lecture 3
20 of 94
Scenarios
 A scenario is a little story
 it is an outline of some
expected sequence of
events
 A scenario is used to convey
the fundamentals of “how
things work”
 It usually includes at least
one actor
 Each actor can make
requests of the system or
respond to system activity
I would like a
book of stamps,
please.
OK. Will
that be all?
Yes.
That will be
$9.90.
Here is $10.
Thanks. Here are
your stamps and
your change.
September 24, 2015
SE 430: Lecture 3
21 of 94
High-level system view
 If we look at the system as a
“black box”, we can identify
some of the external users of
the system (either humans or
other computer systems)
 The simplest “black box”
diagram is a system
diagram, which shows the
outside actors
 The use case diagram is
more elaborate: it also
shows the connections
between “use cases” and
actors
September 24, 2015
System diagram
Student
My system
Administrator
Instructor
Use case diagram
Student
My system
register
Administrator
create new
course
Instructor
SE 430: Lecture 3
delete
offering
22 of 94
Sequence diagram
 A sequence diagram is a way of drawing a picture of a scenario
 Sequence diagrams are also sometimes called event trace diagrams,
ladder diagrams, interaction diagrams, or fence post diagrams
 Each vertical line describes an “actor” or a “system” in the
scenario
 The vertical axis represents time: time flows down the page
Customer
Postal clerk
Ask for book of stamps
Do you want anything else?
No
Respond with price
Give money
Give stamps and change
September 24, 2015
SE 430: Lecture 3
23 of 94
Iterative Development
Use Cases
 Decide and describe the functional requirements of the
system
 Bring agreement between the customer and software
developer
 Give a clear and consistent description of what the system
should do.
 Provide a basis for performing tests that verify the system
delivers the functionality stated.
 Trace the functional requirements into actual classes and
operations in the system.
September 24, 2015
SE 430: Lecture 3
24 of 94
Use-Case Model I
Concepts and Background
 The Use-Case Model in the Unified Process
 Use-Case Workflow
 Use-Case Tasks and Artifacts

September 24, 2015
SE 430: Lecture 3
25 of 94
Concepts and Background
September 24, 2015
SE 430: Lecture 3
26 of 94
Use Cases
 A use case tells a story of actors using a system.


“Rent Videos”
A use-case is a sequence of actions a system performs that yields
an observable result of value to a particular actor.
 One artifact to express (especially) functional requirements.
 Emphasizes thinking about the valuable objectivesoriented viewpoint of the users.
September 24, 2015
SE 430: Lecture 3
27 of 94
What is a use case?
 Documents a set of interactions between a user (or actor) and a




computer system.
Can be viewed as a necessary (but not sufficient) collection of
requirements for those interactions.
Use cases:
 Help to focus on achieving well-defined user goals.
 Vary widely in their level of detail.
Capture use cases by:
 Interviewing users.
 Discussing their use of the system.
 Naming (a form of abstraction) and describing each use of system.
Hint: Domain processes and events from the system context description
are good sources for use cases. Also functional requirements.
September 24, 2015
SE 430: Lecture 3
28 of 94
Use cases
 A use case is a concept that is related to scenarios:



A use case is a description of all the possible sequences of
interactions among the system and one or more actors in response
to some initial stimulus by one of the actors. (Rumbaugh)
A use case is a collection of possible sequences of interactions
between the system under discussion and its external actors, related
to a particular goal. (Cockburn)
In a use case, the system is considered as a black box
September 24, 2015
SE 430: Lecture 3
29 of 94
Use cases
 Each actor is an external thing that interacts with the
system


An actor can represent either a human user or another system
Actors have goals; they want to accomplish something
 Use cases are often documented by drawing some
scenarios

Use case analysis often considers both “sunny-day scenarios” and
exceptional cases
September 24, 2015
SE 430: Lecture 3
30 of 94
User goals and system interactions
 Recall: User goals are specific,
but not detailed, descriptions of
what user wants the system to
do
 A system interaction occurs
when a user attempts to do
something to achieve a goal
 A single user goal may lead to
several system interactions
Interaction
1.1:
Create new
artifact description
User goal 1:
Enter new
artifact into museum
collection catalog
Interaction
1.4:
Save new
artifact
description
September 24, 2015
SE 430: Lecture 3
Interaction
1.2:
Enter physical
description
Interaction
1.3:
Enter
physical care
requirements
31 of 94
Use cases and scenarios
 The use case describes a set of interactions between the user and the






system, possibly with several different outcomes.
A scenario describes a specific path through, and outcome of, a use
case.
A use case represents a collection of scenarios: primary, plus zero or
more alternates.
The primary scenario corresponds to the main system interactions,
usually the ‘success’ scenario.
Alternate scenarios correspond to less frequent interactions and
exceptions.
Different scenarios are analogous to alternatives in switch..case
constructs.
The term interaction can refer to a single interaction or a set. Typically
an actor has a set of interactions with the system.
September 24, 2015
SE 430: Lecture 3
32 of 94
From user goals to scenarios
Goal/requirement space
Interaction
2.1
User goal 2
Interaction
2.2
Interaction
1.2:
Enter physical
description
Interaction
1.1:
Create new
artifact description
User goal 1:
Enter new
artifact
Interaction
1.3:
Enter
physical care
requirements
Interaction
1.4:
Save new
artifact
description
User goal 3
Interaction
3.1
Envelope of
system behavior
System behavior space
Scenario
2.1
Scenario
1.1:
Physical care
available
maps to
Scenario
1.2:
Physical care
unavailable
Use case 1:
Enter physical
care
requirements
Scenario
5.1
Scenario
2.2
Use case
3
Scenario
3.1
Interaction
4.2
User goal 4
Use case
2
Use case
5
Use case Scenario
4
4.1
Interaction
4.1
September 24, 2015
SE 430: Lecture 3
33 of 94
Another view
…
…
User Goal
maps to
Use case 2
Scenario 1
Interaction 1
September 24, 2015
Scenario 2
Interaction 2
yields
…
…
SE 430: Lecture 3
Scenario n
composed of
Interaction n
34 of 94
Use case format
 Start with a simple use-case format and add additional features, if
needed.
 For each use case, provide:
 Identification. short identification tag, e.g. UC001
 Name. Provide a (short) title
 Description. brief description in a few sentences. Short narrative (23 sentences) describing use case and objectives
 Actors. List the actors that interact with this use case.
 Goals. What the actor wants to achieve.
 Preconditions. Specify what conditions must be true before the use
case starts.
 Postconditions. Specify what conditions must be true when the use
case ends.
 Event Flow. Use a sequentially-numbered list of brief statements
describing the steps of the use case. Start with “This use case
begins when…” and end with “This use case ends when…”.
September 24, 2015
SE 430: Lecture 3
35 of 94
High-level use case: primary scenario
Identification: UC003
Name: Artifact physical care requirements entry
Description: Enter physical care requirements for a new artifact into the Artifact
Tracking System (ATS)
Actors: Artifact Tracking (AT) staff member (user); climate, fire, and security
control subsystems
Trigger: AT staff member wishes to enter all the climate, fire, and security control
physical care requirements for a new artifact into the ATS
Goals: see Trigger above
Preconditions:
1.
AT staff member must be logged into the ATS.
2.
AT staff member must have entered the unique identification code
assigned to the artifact.
Incoming information: Climate, fire control, and security requirements for artifact
Results: Artifact physical care requirements are entered into ATS
Postconditions:
1.
ATS (in collaboration with appropriate subsystems) confirms Museum can
provide appropriate physical care for artifact.
September 24, 2015
SE 430: Lecture 3
36 of 94
High-level use case – basic form
Event Flow:
1. This use case begins when the user selects ‘ArtifactPhysical Care’
from the ATS menus.
2. System displays a blank entry form for the artifact's climate control
requirements.
3. User enters the artifact's climate control requirements into the form.
4. User selects ‘Continue’ to end climate control requirements entry.
5. System displays a blank entry form for the artifact's fire control
requirements.
6. User enters the artifact's fire control requirements into the form.
7. User selects ‘Continue’ to end fire control requirements entry.
8. System displays a blank entry form for the artifact's security
requirements.
9. User enters the artifact's security requirements into the form.
10. User selects ‘Continue’ to end security requirements entry.
September 24, 2015
SE 430: Lecture 3
37 of 94
High-level use case—basic form
Event Flow:
11. User selects ‘Continue’ to end physical care requirements entry.
12. System presents the artifact's physical care requirements to the user
for review.
13. This use case ends when the user selects ‘Accept’ for the displayed
information.
September 24, 2015
SE 430: Lecture 3
38 of 94
Alternate event flow form with ‘repeat’
Event Flow:
1. This use case begins when the user selects ‘ArtifactPhysical Care’
from the ATS menus.
2. For each specific physical care requirement (climate, fire, security)
repeat steps 3-5:
3. System displays a blank entry form for the artifact's specific physical
care requirements.
4. User enters the artifact's specific physical care requirements into the
form.
5. User selects ‘Continue’ to end specific physical care requirements
entry.
6. User selects ‘Continue’ again to end all physical care requirements
entry.
7. System presents the artifact's physical care requirements to the user for
review.
8. This use case ends when the user selects ‘Accept’ for the displayed
information.
September 24, 2015
SE 430: Lecture 3
39 of 94
Use case evolution
 Storyboards represent an early form of use case.
 Use cases were formalized in Ivar Jacobson's Objectory process
and later popularized in Object-Oriented Software Engineering: A
Use Case Driven Approach (1992).
 Use cases were incorporated in UML at the very earliest stages:
sometime around v. 0.9 or 1.0.
 Use cases have been part of the Unified Process – “a use-casedriven process” – from its inception.
 Schneider & Winters (Applying Use Cases: A Practical Guide),
Cockburn (Writing Effective Use Cases), and others have helped
make use cases more accessible.
September 24, 2015
SE 430: Lecture 3
40 of 94
Use cases in the software life cycle
 First iteration of Elaboration:

About 80% of use cases captured.

About 10% detailed.

Why just 10%? About 10% of project use cases will be identified
as highest-risk.
 Subsequent iterations:

Most use cases captured.

About 80% detailed by end.

Why only 80%? About 20% of use cases will be minor variations
on others or will be trivial.
 Construction:

Use cases added or extended by recycling to Inception phase.
September 24, 2015
SE 430: Lecture 3
41 of 94
Use Case Workflow
September 24, 2015
SE 430: Lecture 3
42 of 94
Idealized use case workflow
Find
Actors
September 24, 2015
Find
Use
Cases
Describe
Use
Case
Model
Prioritize
Use
Cases
SE 430: Lecture 3
Detail
Use
Cases
Structure
Use
Case
Model
43 of 94
UC workflow techniques and artifacts
Actor list
High-level use
case
descriptions
Use-case
diagram &
glossary
Find & describe
actors
Find & briefly
describe use
cases
Describe use
case model
Structure use
cases
Detail use
cases
Prioritize use
cases
Use cases with
scenarios
Detailed use
case
descriptions
Proritized usecase list
September 24, 2015
SE 430: Lecture 3
Start
44 of 94
Use Case Tasks & Artifacts
September 24, 2015
SE 430: Lecture 3
45 of 94
Find actors
 Identifying actors is the most critical element in constructing




the use-case model.
A use-case actor interacts with the system in a specific role
Candidate actors can come from several sources.
System context description can be a rich source of
candidate actors.
Actors may take on more than one role, depending upon
specific interaction.
September 24, 2015
SE 430: Lecture 3
46 of 94
Find actors
 Minimize overlap of roles that different use-case actors play:


Combine overlapping roles into a single role for one actor
» Example: Assign ‘Security Profile Administrator’ role and
‘Access Privileges Manager’ roles to a single Security Profile
Manager actor, unless there is a good reason to keep them
separate
Assign one or more overlapping roles to separate actors.
» Example: A Museum Administrator may act in both system
management and end user roles. Assign these very different roles
to two different actors: System Manager and End User
September 24, 2015
SE 430: Lecture 3
47 of 94
Types of actors
 Primary actors
The source of user goals.
 Have goals satisfied through interactions with the system.
 Example: ATS staff member has goals satisfied by ATS.
 Supporting actors
 Provide a service to the system.
 Have interfacing requirements with the system.
 Example: Climate, security, and fire control systems are supporting
actors to the ATS, providing ATS with information.
 Offstage actors
 Have secondary (or more-removed) interaction with the system.
 May have needs that the system satisfies.
 Example: Visitor Information system is an off-stage actor to the
ATS. ATS provides information to Visitor Information system.

September 24, 2015
SE 430: Lecture 3
48 of 94
Find use cases
 There is no cookbook formula for finding use cases.
 Good starting points for finding use cases:





Interviews with users.
Domain processes and events from system context description.
Interactions associated with various type of actors.
Functional Requirements.
Any other requirements.
September 24, 2015
SE 430: Lecture 3
49 of 94
Exercise: Identifying use cases
 Suppose we want to develop an Automated Teller Machine.
List some of the use cases for such a system:



September 24, 2015
SE 430: Lecture 3
50 of 94
Exercise: Identifying use cases
 Suppose we want to develop an Automated Teller Machine.
List some of the use cases for such a system:





Get instant cash
Transfer money
Get money from checking
Balance check
Deposit cash or checks
September 24, 2015
SE 430: Lecture 3
51 of 94
Use case formats
 Brief


Same as high-level with no steps, but a two to three sentence
description.
See sample form (see notes).
 High-level




Very terse summary—perhaps 5-6 steps in event flow. Usually two
or three sentences describing the objective.
Covers only the primary scenario with minimal detail.
Roughly equivalent to the Agile‘stories.’
See sample form (see notes).
 Casual



More detailed format—perhaps 10-20 steps in event flow.
Include actors and possibly pre- and post-conditions.
May cover important scenarios other than primary.
September 24, 2015
SE 430: Lecture 3
52 of 94
Use case formats
 Fully-dressed (detailed) or expanded or extended
Lengthy and detailed—perhaps > 15-20 steps in event flow.
 Covers most scenarios.
 Can be trimmed to suit phase and priority of use case.
 Or, see my sample forms:
http://condor.depaul.edu/dmumaugh/readings/SE430readings.html
[Project Forms and Documents]

September 24, 2015
SE 430: Lecture 3
53 of 94
Variations on a Theme
 Many different use case formats. Cockburn had over 37
variations.
 Use whatever provides the most information at the level of
detail appropriate
 The reading list has a couple of forms that might be useful.
September 24, 2015
SE 430: Lecture 3
54 of 94
Describing the Use-case Model As a Whole
 We need some way to summarize and track the various
actors and use cases and their relationships
 Full use-case model consists of:
1.
Use-case (prose) descriptions, at various appropriate levels of
detail
2.
Glossary which contains definitions and descriptions of items in
the use-case model
3.
Visual model in the form of a use-case diagram
4.
Select system sequence diagrams
September 24, 2015
SE 430: Lecture 3
55 of 94
Glossary
A glossary is part of the use-case model
 Consists of all the terms and phrases listed in the
requirements document
 List of actors and their goals
 List of use-cases (name and description)
 Any new terms and phrases introduced
September 24, 2015
SE 430: Lecture 3
56 of 94
Use-case diagram
 Static, summary illustration of






use-case structure.
Stick-people icons are actors
that use the system, linked to
particular use case(s).
Rectangles represent external
system actors that interact
with the use case.
Ellipses indicate use cases
themselves.
«extends» link » specialization
«uses» link » aggregation
«include» is same as «uses»
September 24, 2015
Use case 1
«extends»
System
boundary
Use case 2
«uses»
Actor
SE 430: Lecture 3
Use case 3
«actor»
Computer system
actor
Use case 4
57 of 94
ATS sample use-case diagram
Create new
artifact
description
Enter artifact
physical
description
<< actor>>
Climate Control
Subsystem
ATS Staff
Member
Enter artifact
physical care
requirements
Save and publish
new artifact
description
September 24, 2015
SE 430: Lecture 3
<< actor>>
Fire Control
Subsystem
<< actor >>
Security Control
Subsystem
58 of 94
Sidebar: Identifying the system boundary
 Like most analysis and design concepts, system and system boundary
may vary with the level of abstraction.
 The system represents the software and hardware elements which are
the current focus of attention.
 Example: In the Museum Automation Problem, each individual
subsystem—climate, security, Visitor Information—can be
considered ‘the system’ during its analysis and design.
 The system boundary represents the division between the system itself,
including software and hardware, and the actors: primary, supporting,
and off-stage.
 Defining the scope of the system during the requirements effort can
help delineate the system boundary.
September 24, 2015
SE 430: Lecture 3
59 of 94
Detailed use cases
 Highest-priority use cases require early attention to detail.
 Identify the use cases scheduled for the first iteration of
development, generally about 10% of total.
 For each first-iteration use case, write a detailed (fullydressed) use case.
 Because these use cases are being detailed at an early
stage, they may require refinement in later iterations.
 Avoid getting involved in detailed UI design issues at this
stage: write use cases in an essential (mostly UI-free) style.
September 24, 2015
SE 430: Lecture 3
60 of 94
Sidebar: essential style
 Keep UI specifics out of the use cases and focus on the
actor’s intent during the interaction
 The UI is a part of the system that is expected to change
substantially over the course of development
 Early specification of UI details can solidify issues that are
best left flexible at this point
 So:



Postpone specific UI descriptions and interactions until later in
design and even then, confine them to a ‘look & feel’ artifact
It’s OK to use general UI terminology and user actions: displays,
menus, buttons; selects, enters, confirms
Avoid specific UI widgets (e.g. radio buttons, pop-up menu, dropdown menu) or user interaction descriptions (scrolls, highlights,
drags)
September 24, 2015
SE 430: Lecture 3
61 of 94
Detailed use-case format
 Start with a simple use-case format and add additional features, if
needed.
 Suggested detailed use-case elements:
 Identification – use-case ID (Number)
 Name
 Narrative description (two to three sentences)
 Actors (primary, supporting, off-stage), goals and roles.
 Preconditions and postconditions.
 Main (primary) scenario event flow.
 Extensions (alternate scenarios) event flows.
 Special requirements (attributes and constraints identified in
requirements document).
 Technology and data variations list (from supplementary, nonfunctional requirements).
 Frequency of occurrence of use case
 Open issues related to the use case
September 24, 2015
SE 430: Lecture 3
62 of 94
Structuring the use-case
 Follow a consistent structure for all detailed use cases.
 Always use “This use case begins when…” and “This use case ends




when…” stylistic ‘bookends’.
The primary scenario should be the one most readily traced through
the use case.
Defer exceptional conditions and branches to alternative scenarios.
Alternative scenarios (a.k.a. extensions) should follow the primary
scenario in the text.
Alternative scenarios are identified by the step number in the primary
scenario plus a letter.
 Example: Three alternative scenarios that begin at step 6 in a
primary scenario would be labeled 6a, 6b, and 6c.
September 24, 2015
SE 430: Lecture 3
63 of 94
Detailed use case example: header
Identification: UC003
Name: Artifact physical care requirements entry
Description: Enter physical care requirements for a new artifact into the Artifact
Tracking System (ATS)
Actors: Artifact Tracking (AT) staff member (user); climate, fire, and security
control subsystems
Trigger: AT staff member wishes to enter all the climate, fire, and security control
physical care requirements for a new artifact into the ATS
Goals: see Trigger above
Preconditions:
1.
AT staff member must be logged into the ATS.
2.
AT staff member must have entered the unique identification code
assigned to the artifact.
Incoming information: Climate, fire control, and security requirements for artifact
Results: Artifact physical care requirements are entered into ATS
Postconditions:
1.
ATS (in collaboration with appropriate subsystems) confirms Museum can
provide appropriate physical care for artifact.
September 24, 2015
SE 430: Lecture 3
64 of 94
Use case example with alternate scenario
Event Flow:
1.
This use case begins when the user selects ‘ArtifactPhysical Care’
from the ATS menus.
2.
System displays a blank entry form for the artifact's climate requirements.
3.
User enters the artifact’s climate requirements.
4.
User selects ‘Continue’ to end climate requirements entry.
5.
System displays a blank entry form for the artifact's fire requirements.
6.
…
5a. Museum facilities cannot support climate requirements of artifact:
1. System informs user that Museum cannot support climate
requirements of artifact.
2. System specifies requirement(s) that cannot be met.
3. System displays climate control system modification request form.
4. User enters the climate requirements for the artifact.
5. User selects ‘Submit’ to submit modification request to facilities
staff.
6. Continue event flow with step 5.
September 24, 2015
SE 430: Lecture 3
65 of 94
Example: additional elements
Special requirements: All entered physical care requirements
must be verified against minimal generic requirements for
the type of artifact
Technology and data variations list: System must support
both artifacts that are part of the Museum's permanent
collection and those that are on temporary loan from other
sources
Frequency of occurrence: Variable. Very high during initial
set-up; high during arrival of visiting exhibitions; low
otherwise
Open issues: Must identify minimal lists of requirements for
each of the areas (climate, fire, and security)
September 24, 2015
SE 430: Lecture 3
66 of 94
Prioritize use cases
 Planning in an iterative and incremental process is risk-




driven.
Schedule analysis, design, and implementation of use
cases representing core system (required vs. desirable or
optional) functionality and high-risk use cases for early
iterations
Conversely, schedule development of non-corefunctionality and low-risk use cases for later iterations.
Need to balance risk and functionality factors.
At this stage, consider priority based on:


Proportion of contribution to overall system functionality.
Technological, skills, and dependency risks.
September 24, 2015
SE 430: Lecture 3
67 of 94
Risk factors
 Requirements risks
Have you properly identified requirements for system?
 Have you reviewed project scope?
 Can you effectively set functional requirements priorities?
 Technological risks
 Are you using a new, untested technology?
 Dependency risks
 Are you depending on a third-party product?
 Skills risks
 Are you planning to do something with which you are completely
unfamiliar?
 Do you have the right staff with the necessary skills?

September 24, 2015
SE 430: Lecture 3
68 of 94
Ranking (or Prioritizing) Use Cases
Project managers use use case versions for development
cycles
 Time-box development cycles have a fixed time frame.
 Complex use cases may require multiple development
cycles to be fully implemented.
 Create simplified versions of the complex use case that
can be developed within each subsequent time-box.
September 24, 2015
SE 430: Lecture 3
69 of 94
Ranking Use Cases
Setting Priorities – Rank Order use cases
 Many factors may be need to be considered when ranking
or prioritizing use cases:
A.
Impact on the architectural design
B.
Information and insight regarding the design
Risky, time-critical, or complex functions
New or risky technology.
Represent line-of-business processes
Directly support increased revenue or decreased costs.
C.
D.
E.
F.
September 24, 2015
SE 430: Lecture 3
70 of 94
Ranking Use Cases
Use Case
Buy Items
Add New Users
A B C D E F Sum
5 3 2 0 5 3 18
3 3 2 0 2 2 12
Start Up
3
September 24, 2015
2 2 0 2 2 11
SE 430: Lecture 3
71 of 94
Ranking Use Cases
It is also possible to do simpler classifications – high, medium,
low
Rank
Use Case
Justification
High
Buy Items
Scores on most increased ranking
criteria
Medium
Add New Users
Log In
Refund Items
Affects Security Domain
Affects Security Domain
Important process affects Accounting
Low
Cash Out
Start Up
Shut Down
Minimal effect on architecture
Definition is dependent on other use
cases
Minimal effect on architecture
September 24, 2015
SE 430: Lecture 3
72 of 94
Practical tips
 Pick a set of use cases that maximizes system coverage

write two or three of the most common simple transactions first; most
common or “sunny day”

it is easy to get carried away generating too many use cases, so try
to create more “abstract” scenarios when three or more scenarios
look very similar
 Keep a list of Actors/Roles/Goals/Use Cases
 After all use cases are developed, refactor for common
elements
September 24, 2015
SE 430: Lecture 3
73 of 94
Practical tips
 Beware of analysis paralysis


inability to write any scenarios, or
creating too many detailed scenarios
 Techniques to get out of analysis paralysis:




write two or three of the most common simple transactions first
it is easy to get carried away generating too many use cases, so
try to create more “abstract” scenarios when three or more
scenarios look very similar
be cautious of generating more than 30 use cases to cover the
fundamental system actions
additional use cases for unusual events should be chosen with
care and kept to a manageable number
September 24, 2015
SE 430: Lecture 3
74 of 94
Concepts
 In writing use cases, start to identify potential classes,
objects, and sub-systems
 Use cases are used to generate the conceptual (domain)
model


Nouns become “concepts” or classes/objects
Verbs become “actions” or methods
 Start each use case name with a verb.
 Start sentence 1 with “<Actor> does <event>”
 All systems have a Start Up and Shut Down use case
(perhaps trivial).
September 24, 2015
SE 430: Lecture 3
75 of 94
System testing
 One big reason for writing use cases: they really help
when it is time to test the entire system


both sunny day cases and exception behavior can be extracted
from the use case descriptions
the use cases define what behavior is inside the system and what
behavior depends on the external actors
 Since use cases treat the system as a black box, there is
a great deal of design freedom, but the external behavior
must be correct
September 24, 2015
SE 430: Lecture 3
76 of 94
Use Case Diagram
 A way to conceive and
illustrate the use cases.
 Usually created during the
initial use case analysis.
September 24, 2015
SE 430: Lecture 3
77 of 94
Diagram of Sample Use Case
September 24, 2015
SE 430: Lecture 3
78 of 94
Use-Case Model II
Use case workflow tasks and artifacts
System Sequence Diagrams
September 24, 2015
SE 430: Lecture 3
79 of 94
Use case workflow tasks and artifacts
Actor list
High-level use
case
descriptions
Use-case
diagram &
glossary
Find & describe
actors
Find & briefly
describe use
cases
Describe use
case model
Structure use
cases
Detail use
cases
Prioritize use
cases
Use cases with
scenarios
Detailed use
case
descriptions
Proritized usecase list
Next
September 24, 2015
SE 430: Lecture 3
80 of 94
Additional techniques and artifacts
System
sequence
diagrams
Next
Detail use
cases
Detailed use
case
descriptions
Structure use
cases
Use cases with
scenarios
Detail actor/
system
interactions
Detail eventdriven
sequencing
Use-case
statecharts
September 24, 2015
SE 430: Lecture 3
Statecharts
discussed in
context of
object
behavior.
81 of 94
System Sequence Diagrams
September 24, 2015
SE 430: Lecture 3
82 of 94
Use Cases and System Sequence Diagrams
 A use case is a prose description of an actor/system
interaction.
 Use case diagram is a visual summary of:



All significant use cases.
All significant actors.
Relations among actors and use cases.
 A System sequence diagram (SSD) is a visual summary of
the individual use cases.
 For ease of understanding, each use-case scenario
corresponds to a separate system sequence diagram.
September 24, 2015
SE 430: Lecture 3
83 of 94
Characteristics of System Sequence Diagrams
 System sequence diagrams are a special case of the





more-general UML sequence diagram.
Captures the sequencing of messages and data
exchanged between an actor and the system.
Provides about the same level of detail as use-case prose
description.
Usually deals with primary actors and system, but can
include other actors as well.
Provides a more formal notation for expressing the
interaction.
Concerned only with external behavior: the system is
treated as a black box.
September 24, 2015
SE 430: Lecture 3
84 of 94
System Sequence Diagram
September 24, 2015
SE 430: Lecture 3
85 of 94
System Sequence Diagram Notation
Actor
«actor»
These are
participants in the
interaction.
System
External
System
Message
Lifeline
This is a
non-human
actor
operation(parameter, ...)
loop
[iteration condition]
operation(parameter, ...)
operation(parameter, ...)
Draw rectangle
enclosing groups of
iterated messages
Time
operation(parameter, ...)
operation(parameter,...)
Iteration
Return
return entity, ...
.
return entity, ...
Note that software
participants cannot
perform operations on
human24,
actors!
September
2015
SE 430: Lecture 3
86 of 94
Sequence Diagrams
Messages are indicated by a solid line with an arrow.
Arrow
Meaning
Arrow head
style UML 2.0
Synchronous Transfer control and wait for answer.
(sequential operations)
Return
September 24, 2015
Returns a value to the caller (optional)
SE 430: Lecture 3
87 of 94
Artifact Tracking use case
Name: Artifact physical care requirements entry
Description: Enter physical care requirements for a new artifact into the
Artifact Tracking System (ATS)
Actors: Artifact Tracking (AT) staff member (user); climate, fire, and
security control subsystems
Trigger: AT staff member wishes to enter all the climate, fire, and security
control physical care requirements for a new artifact into the ATS
Preconditions:
1.
AT staff member must be logged into the ATS.
2.
AT staff member must have entered the unique identification code
assigned to the artifact.
Incoming information: Climate, fire control, and security requirements for
artifact
Results: Artifact physical care requirements are entered into ATS
Postconditions:
1.
ATS (in collaboration with appropriate subsystems) confirms
Museum can provide appropriate physical care for artifact.
September 24, 2015
SE 430: Lecture 3
88 of 94
Artifact Tracking use case
Event Flow:
1.
The use case begins when the user selects to begin the ‘Physical
care entry’ process for an artifact in ATS.
2.
For each specific physical care requirement (climate, fire, security)
repeat steps 3-5:
3.
System displays a blank entry form for the artifact's specific
physical care requirements.
4.
User enters the artifact's specific physical care requirements into
the form.
5.
User selects ‘Continue’ to end specific physical care
requirements entry.
6.
User selects ‘Continue’ again to end all physical care
requirements entry.
7.
System presents the artifact's physical care requirements to the
user for review.
8.
The use case ends when the user selects ‘Accept’ for the
displayed information.
September 24, 2015
SE 430: Lecture 3
89 of 94
Use-case system sequence diagram
<<actor>>
Control
Subsystem
ATS
User
select('Physical Care Entry')
loop
[for each physical care category]
physicalCareRequirementsEntryForm
enter(physicalCareRequirements)
select('Continue')
confirm(specific requirement)
confirmation
requirementsConfirmationForm
select('Accept')
September 24, 2015
SE 430: Lecture 3
90 of 94
SSD – With Use Case
September 24, 2015
SE 430: Lecture 3
91 of 94
Summary
 OO analysis starts with the following “requirementsoriented” data:



problem statement
list of text inputs
set of use cases
 A Use-case is a major distinct, complete, end-to-end
process of using a system.

Not usually one step, but a complete story.
 Use cases tell a story of actors using a system.
Examples
» Rent Videos
» Return Videos
» Pay Fines
A use-case is a sequence of actions a system performs that yields an
observable result of value to a particular actor.

September 24, 2015
SE 430: Lecture 3
92 of 94
Summary
 A use-case is one artifact to express (especially) functional






requirements.
Use-cases emphasize thinking about the valuable, objectives-oriented
viewpoint of the users.
They illustrate functional requirements, by the stories they tell.
Use-cases are valuable for:
 providing a good overview of the system to be developed
 defining the system boundary
 helping to generate the test suites
Complementary with a feature requirement list.
Choose use-cases carefully since they are the requirements for the
entire system and the foundation for the OO analysis process
Forms a contract (see Design by Contract)
September 24, 2015
SE 430: Lecture 3
93 of 94
Next Class
Topic:
Static Structure: Requirements Traceability; Building a Beginning
Conceptual Model: Class Diagram; CRC Cards; Domain model
basic principles; Domain model associations; Domain model
attributes; System Glossary.
Reading:
Arlow & Neustadt: Ch’s 6-9
Driving Design: The Problem Domain
Tracing Your Design
Using CRC Cards
Assignment – October 1, 2015
September 24, 2015
SE 430: Lecture 3
94 of 94