Use Case Diagrams
Use Case Descriptions
Use Case Book (Chapter 2)
and
Visual Modeling Book
1
Use Case Diagrams…
Withdraw Money
Transfer Money
Simply actors and use cases
Can, of course, be much more detailed. Often the
relationships are ‘tagged.’
2
Extending the UML with Stereotyping
Know we have ‘Change’ in everything.
 But very few graphics in UML.
 Need to communicate special cases:

–
–
–
–
–

special classes
special kinds of use cases…
Extend UML for new ‘types’
New types of model elements?
We often need customization of models for some projects.
Extend UML? No! Ability to stereotype is built in.
3
Extending the UML with Stereotyping

Enter: Stereotyping.
– Allow us to ‘refine’ / ‘reclassify’ ‘re-specify’ all model
elements into a more specialized form rather than create
additional symbols!
– We might specify a Use Case as a <<mission critical>> or
class name with the stereotype: <<boundary>> or
<<control>> etc.
– Indicate that the symbol is still a Use Case – but a ‘special
one’ perhaps in a ‘special context.’


Most common UML stereotyped element is the class.
Stereotyping makes these different model elements!!!
– (Incidentally, additional icons can be added, if wanted…)
4
Examples
A ‘special’ kind of class with special behaviors – a boundary class.
A ‘special’ kind of Association – indicates a use case that supports a
more fundamental use case – one that is more significant.
Choices
<boundary>
(attributes)
<included>
(methods)
Authenticate User
5
Stereotypes in Modeling:
Built-ins and User-Defined

Stereotypes can be used to ‘increase relevance’ of model
elements, such as use cases in requirements gathering.
– (Much controversy on ‘extend use cases’ and ‘include use cases’
Much more later: stereotypes: <<includes>> and <<extends>>

Use Cases are quite commonly stereotyped
– A <mission critical> use case ‘may’ be specified in a separate
document addressing all stereotypes
– “Stereotyped element” implies that there are ‘special’ criteria.
– e.g. A use case that is “mission critical” => must be processed
within five seconds.

Classes may also very often stereotyped:
– <boundary>, <control>, <entity> (as found in Analysis Modeling)
• A boundary class is a special kind of class that interacts directly with
an actor…

Any UML modeling element may be stereotyped….
6
Use Case Template
(Be aware there are many many formats. Format is not
critical. Content is.)
One of many different
kind of formats…
Will discuss others in
next lecture.
7
Use Cases

Use Cases – a great tool that helps us to express
interactions between system (application) and
actors.

We can see the behaviors of the system.

Meaningful to customer who is concerned with the
‘whats’ of the system to see how system and actor
interact with each other.

Successful development of Use Cases requires an
understanding of the goals of each of the use cases,
which, in turn, is developed from identified, required
functionality – namely Features.
8
Goals of Use Cases

Interactions must present a value to actor.
– actor may be an accounting system; general ledger
system; person; customer; a relay; or thermostat…
• person, device, external system/database/file.
• Actors are external to the system.

Use Cases are black box representations
– Do not show implementation-specific language
– Do not want to imply how use case will be realized.
– Do not include language such as: people, interface
widgets (buttons, menus…), IFTHENELSE statements,
pseudo-code, more…
– Are written in language of the application domain.
– Are ‘abstractions’ of detailed interactions.
– Capture stories addressing functional
9
requirements…
Goals: Use Cases capture ‘Whats’
 “Context-free” use (that is, no design constraints)

Excellent for requirements gathering / modeling;
analyzing and capturing desired user interactions

 Numbers of Use Cases?
– 70-80 for very large system?
– Medium sized – 20 to 50;
– Small systems – fewer. Often 6 to 8 may be sufficient.

 Smaller number forces abstraction. Desirable.

There is no ‘one size / number’ fits all. But there are
guidelines in their development! (Coming)
10
Use Case Diagrams and Relationships
11
Actors

Actors trigger the start of a use case.
– people, computer systems, date/time, relay, device...
– Actors must receive value from the system
– Systems that are actors generally supplying data or services to
your system and vice versa.
• May be a legacy RDBMS or a legacy VSAM file…
• Pressure and temperature may be actors (triggers), as well as a
device, such as a conveyer belt, given a signal to start…

Secondary actors (surrogate actors) (next slide)
– actor/role providing system inputs/outputs from another
actor/role.
– First (outside) actor/role is ‘secondary actor’ and should be
shown if its actions affect system reaction.
12
Secondary Actors
<communicates>
Desk Clerk
Register Guest
(inheritance arrow)
Customer
13
Associations: Generalization in Actors
(next slide)

Generalization: Abstract the commonalities.
– two sub-actors generalized into a super-actor
– Have both behavior and attributes in common
– described under the super-actor.
– Super-actor should interact with use cases
when ALL of its sub-actors interact the same
way;
– Sub-actors should interact with use cases
when their individual interactions differ from
that of the super-actor.
14
Some use case
Different use case
15
Actors and Classes

Actors may influence how classes are built
because they will be using the services of the
objects of those classes.
 Actors may themselves be classes –

Customer
– often an Actor – external to the system.
– often a Class (this is NOT an actor)
• Probably: Customer exists in the domain model
and is likely a business ‘entity.’

Makes sense to take care in creating the right
actor to interact with the use cases.”
16
Actors and Associations

Not customary to label association lines between actor &
use case.
– Default is <<communicates>>
• But there are others…

Role names. Actors have ‘role names’ – useful if
‘association’ needs information beyond the fact that they
simply interact.
– Actor: Professor. role: student;
– Actor: Professor. role: assessing another’s teaching; …

Associations exist in many forms and among many model
elements…
–
–
–
–
between classes
between use cases
between design entities (subsystems, packages, etc.)
between analysis classes, etc .
17
Use Case Associations
Extend/Include Stereotypes

Stereotyped associations indicate a special kind of
association. (good pix – Chap 2, Use Cases, Fig 2.12)
– Extending (blunt side) is a special use case that extends the
original use case (sharp)
• “Extending use case” would not exist without the use case it is
extending (the extended use case);
• Used for special cases; exceptional behaviors. Inserted behaviors
• Arrow points toward the base use case that is being extended…
– Include stereotype allows use case designers to avoid
duplicating steps across multiple use cases (a reuse strategy).
• Arrow extends away from the owning parent use case.
• e.g. Authenticate User
– Note: controversial;
– Many Use Case authors do not like these and include the steps
within the use case itself or use some other kind of sub-flow
18
(later).
(Primary use case)
(extended) Use Case
extending Use Case
(inserted behaviors)
(Primary use case)
Use Case
Included Use Case
(Particularly good for reuse!)
19
Compute Pay
Primary Use Case
Compute Pay
Use Case
Compute Pro Pay
extending Use Case
(inserted behaviors)
Authenticate User
Included Use Case
(Particularly good for reuse!)
20
Exception and Alternative Paths

Last look:

Exceptions are generally errors that may occur.
– Interactions thus contain steps to be executed.

Alternatives may / may not be close to basic course of events – just not
the most likely course of events.
–
–
–
–
No errors- but some authors treat these to document error conditions.
Alternatives may be just as important as the basic course…Often the case.
Some authors treat alternatives as MUCH less likely to occur. I don’t.
(Clearly, in some contexts, treating alternatives as those scenarios that are
much less likely to occur may be appropriate)

Alternate Paths: very important to capture them (with full interactions in
most cases, too).


Exception paths should be kept separate from alternative paths.
All have a home with their use-case.
21
The Use Case Specification
22
Use Case Number:
UC-03
Use Case Name:
Edit Member Profile
Actor (s):
Buyer, Seller
Maturity:
Focused
Summary:
This use case is started by a Buyer or a Seller. It provides the capability for one of
these actors to edit their member profile.
Basic Course of Events:
Actor Action
1. This use case is started when a
Buyer or Seller elects to edit their
member profile.
Perform S1-Login (subflow – later)
System Response
2. The System displays the
Actor’s member profile and prompts the
Actor to update it.
3. The Actor updates their member
profile.
4. The System validates the information
entered by the Actor.
{Validate Information}
5. The System prompts the Actor for
confirmation.
6. The Actor confirms that the
information is correct.
{Profile Change}
7. The System updates the
Actor’s member profile to the member
repository and informs the Actor that the
information was updated successfully.
8. This use case concludes when the
Actor receives visual confirmation of
the update.
23
Continuing….
Alternate Paths:
A1 Change Member Profile
At {Profile Change} the Member indicates that he/she entered incorrect
information.
The System immediately returns to the step 2.
Exception Paths:
E1 Handle Invalid Information
At {Validate Information} if any fields are entered incorrectly.
the System indicates the fields that were entered incorrectly and prompts the Buyer
or Seller to make the necessary corrections.
If errors, the flow of events is resumed at Basic Flow Step 2.
Extension Points:
{Change Profile }, {Validate Information}
Triggers:
The Buyer or Seller would like to edit their member profile.
Assumptions:
The Buyer or Seller is aware of the steps required to edit their member profile.
Preconditions:
The System is functioning properly.
Actor already has a Profile stored in the Profile Database???
Post Conditions:
The member profile was successfully updated to the member repository. Actor
sent email to confirm changes?
Reference - Business
Rules:
See Business Rules section: 2.3.1 and 2.3.5.
Reference - Risks:
See Risks List sections: 2.1 and 2.4.
Author (s):
Team3
Date:
11-04-12
24
The Use Case Specification

A page or two of text; corresponds to a rounded oval
in the Use Case diagram. Relate horror stories!!
 Definitely need some kind of a standard template.

Most organizations using Use Cases develop their own
template format. Consistency is critical.

In all, the Use Case Specification should contain most
of the following attributes:
– Name, iteration name/number; author, description, basic
course of events; alternative paths, exception paths, triggers,
assumptions; preconditions; post-conditions; references to
related business rules; risks lists, and more.

All seem important.
25
The Use Case Specification -2

We have also indicated the need for an Index of Use
Cases. Designate each use case as UC1, …, UCn.

Have already discussed the UC name: verb -> object

Iteration = the ‘maturity’ of the use case – and hence
the maturity of our understanding of the functional
requirements. (façade, filled, focused … many name variations…)

Descriptions –sentences describing the interaction.
26
The Use Case Specification -3

Basic Course of Events – (NOT in Façade)
– actor always takes first step (trigger)
– always have a ‘happy path’
• Simple path; Most likely path)
– Can include a picture, if helpful. (screen shot, etc.)

Alternative Paths
– Other paths (may be less common)
– Each alternative and exception (below) should
indicate WHERE in the basic course of events the
alternative / exception emanates from. Starting point.
– Techniques:
•  cite the step number;
•  labels in the basic course of events (preferred). Discuss.
27
The Use Case Specification -4

Exception Paths
– Like alternatives but typically shown for errors.

Extension Points
– The <<extends>> relationship exists between use cases when
one use case provides an optional sequence of events that is
inserted in the other use case. (See pg. 42, Use Case text)
– “Extension point” in the flow of events shows step name (in
braces) or step number from which the extending use case
extends. (more later)
– Note: the extending use case points to the extended use case.
• Again, this implies ‘inserted’ behaviors.
– Extending use case has ‘no life’ without the extended use case
28
The Use Case Specification -5

Triggers - entry points for a use case

Assumptions –
– document things assumed to be true (but might not be true) (Critical
section.)

Preconditions –
– Things that must be in place before an interaction may occur. (part of
contract between use case and outside world)

Post Condition –
– part of contract between use case and outside world; specify outcomes;
independent of alternative path. e.g. transaction successfully posted.

Related Business Rules
– - Reference to business rules Related Risks addressed by this Use
Case.
– Include a reference to the Risk List document

Author and Date
29
– at bottom; original date for each version: façade, filled, focused etc.
Paths and Scenarios

Use Cases – abstractions
– Really need detailed interactions – scenarios.
– Scenarios can provide details of the interactions!
–  Scenarios are instantiations of Use Cases:
• Use Cases with data

Book provides three definitions for scenarios:
– 1: merely an alternate path;
– 2: an instantiation of the use case with a specific
path plus relevant data;
– 3: same as a use case (synonyms)
30
Paths and Scenarios -2

 Definition #2 – the “Instance,” where the scenario is
a realization of a use case (one possible path) with
included data.

Scenarios can be used
– during requirements capture for feedback to users and
analysts that the use cases accurately reflect user needs, and
– in testing to test whether the system reflects the requirements.

Scenarios, then, are instances, of use cases
(complete with production data) that effectively test
one path through a use case.
31
Use Case Packages

A package (looks like a folder) is a general grouping of
related model elements such as classes, use cases, or
Actors.

 Very desirable to group use cases into packages
primarily because these packages can be used to form
logical boundaries for dividing work among sub-teams.

A good rule of thumb – each package may correspond to
a chapter or at least a major section in the user manual.
– A division of functionality, responsibilities, etc……

Package Diagrams may contain use cases that are
related….These go to functionality (architecture later)
32
More – very important tidbits here.

The relationship between requirements and use
cases is subject of much discussion.
– A use case describes a unit of behavior
– A requirement describes a law that governs behavior
– A use case can capture/satisfy/describe one or more
functional requirements
– A functional requirement may be satisfied by one or more
use cases…

Note that a system will have other requirements
besides ‘functional,’ such as performance,
maintainability, scalability, reliability… that don’t map
easily to use cases….
– These tend to ‘thread themselves through Use Cases.’
– Non-functional requirements
– Some will readily be captured via the software architecture
(later in course).
33
More – very important!

At end of use case modeling, you are ready
to embark upon preliminary design, or – as it
is sometimes called in the RUP, Analysis
Modelling.
 Generally takes place in a second iteration
within Elaboration Phase.
– This will involve very careful and highly iterative
analysis of use cases and all their scenarios.
– This can only take place after the full Use Case
Model is ‘completed.’
34
Prototyping
Provides Basic Flow and More

Prototyping can be used to demonstrate ‘proof of
concept.’

Can write a rough Users Manual from the prototype
and use case descriptions.
– (as if the prototype were a fully functioning system)

Prototyping normally ‘show’ the Basic Courses of
events as well as alternative courses of events..

Necessary in order to fully capture the user
expectation (and hence, functionality).
35
Prototyping Provides Basic Flow and More

Prototype can contain simple windows containing radio
buttons or generic icons – only to show functionality..

Should have a window navigation diagram within the
prototype.

Whether you build a prototype, draw mockups, or use
some other technique to address the visual aspects of
your system, it is very useful to link your screen
designs to your use cases.
– (Can do this manually or via a visual modeling tool.)

Always have a consistent Back or Return or Cancel.
Always have this button in same place and called the
same thing, etc.
36
Prototyping Provides Basic Flow and More

Use Case text should be relatively free of presentation
details.
– Data names often match up directly with attribute names
in domain model (classes; entities).
– Use terms from domain!
– Many nouns / actors are classes in domain model
– Interactions will be ‘control’ later…

 Some controversy:
Important to do prototyping, mockups, etc. before you start
writing use cases or
in conjunction with your use cases…Otherwise, you may
spend lots of extra time trying to pin down your user
expectations….


37
Common Mistakes




10. Write functional requirements instead of usage scenario text
9. Describe attributes and methods in too much detail rather
than usage
8. Write the use cases too tersely (won’t do much good!)
7. Divorce yourself completely from the user interface
– Big mistake!!!






6. Avoid explicit names for your boundary objects. (more later)
5. Write using a perspective other than the user’s, and doing
so in passive voice.
4. Describe only user interactions; ignore system responses.
3. Omit text and references for alternative courses of action
2. Focus on something other than what’s ‘inside’ a use case,
such as how you get there (precondition) or what happens
afterward (post-condition).
1. Spend a month deciding whether to use <<include>> or
<<extend>> associations.
38

Read
– Use Cases for Inquiry-only systems,
– Use Cases for Requests For Proposals,
etc.

DO READ THESE.
39
Remaining Slides are
Rosenberg’s Views:

Good to see complementary treatment.

Read remaining slides on your own.

========= End Lecture ===========
40
Summary Points on Use Cases - from
Use Case Driven Modeling by Rosenberg

Essence of use case model is to capture user
requirements of a new system or based on an existing
system.

We need to Detail all scenarios users will be performing

Use Case Model is at conceptual center of the process.
– Developed in cooperation with domain model
– Precedes any Analysis modeling

Use Cases – sequence of actions that an actor, often a
person (role), but perhaps some other kind of external
entity, such as another system, performs within a system
to achieve a particular goal.
41
Summary Points on Use Cases - from
Use Case Driven Modeling by Rosenberg

A complete and unambiguous use case describes one
aspect of usage of the system without presuming any
specific design or implementation.

Result of UC Modeling: all required system
functionality is described in the use cases!! (Recall,
however, that these evolve…)

Note: that the Façade Use Cases constitute an overview
or umbrella look at the functionality; identification
(without elaboration) of basic use cases – no basic
course of events and many attributes not included.
42
More on Basic Course of Events…
 ‘Basic course of action’ is the main ‘start to finish
path’ the user will follow.
– Alternate course of actions represent other used paths

Goal is NOT to build an elegant use case –

Goal is to ACCOUNT for everything user might do!

The more well-defined the system behavior is
(modeled from the interactions in use case and other
design drawings later), the easier it will be to build the
system.

Developing Use Cases is sometimes referred to as a
‘behavioral approach’ to capturing requirements.
Actually, this is correct.
43
Factoring out Commonality in Usage


Generalization - …
Includes – involves making one use case take full
use of another use case. (more later) See page 42
for illustration)
– Goes to ‘reuse’ = a prime objective of use case modeling.
– Example I like: login or authentication use case may be
‘included.’ (factored out – not decomposition)

Association is defined as a stereotype. Put
<<includes>> on arrow.

Extends – allows a modeler to insert one use case
into another use case thus ‘extending’ the second
use case. (use <<extends>> on arrow)
– Can show ‘optional system behavior’ or behavior that is
executed only under certain circumstances. (The ‘extends’)
– Defined as a stereotype Put <<extends>> on association
arrow.
44
– <<extends>> points to use case that is extended (from
extending use case)
More on Extends and Includes

We normally do not generalize use cases, because
generalization is most useful for building elaborate
structures dominated by abstract use cases….(But
some people do…)

Don’t spend lots of time worrying to use includes,
extends …..

Don’t spend lots of time with long, involved use case
templates.

(I like the <<extend>> and <<include>> associations
to assist in factoring functionality associated with Use
Cases…)
45