This document discusses key aspects of use case modeling including actors, associations, specifications, and common mistakes. It describes actors as entities that trigger use cases and notes they must receive value. Use case associations like include and extend are discussed along with exception and alternative paths. The use case specification template is outlined containing elements like name, description, basic course of events, and references. Finally, common mistakes in use case modeling are listed such as writing functional requirements instead of usage scenarios.

1. 1
Use Case Actors, Associations,
and
Use Case Specifications
Use Case Book (Chapter 2)

2. 2
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, giving a signal to start…

3. 3
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 (later).

4. 4
extending Use Case
(inserted behaviors)
(extended) Use Case
Included Use Case
(Particularly good for reuse!)
Use Case
(Primary use case)
(Primary use case)

5. 5
Exception and Alternative Paths
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 y 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.
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.

6. 6
The Use Case Specification

7. 2
Introduction
 We:
 Know that Use Cases represent / can capture
the functional requirements of an application.
 Know that there are ‘levels of maturity’ or
‘granularity’ of Use Cases.
 Know about Façade Use Cases and
 Know about the use of a template.
 Know different organizations will likely
require different formats, attributes…
7

8. 3
Use Case Number:
Use Case Name:
Actor (s):
Maturity:
(Façade/Focused/…
Summary:
Basic Course of Events: Actor Action System Response
Alternative Paths:
Recall the format
in wide use –
but not the only
format.
8

9. 4
Extension Points:
Triggers:
Assumptions:
Preconditions:
Post Conditions:
Reference: Business Rules:
Reference: Risks
Author(s):
Date:
9

10. 5
Façade Use Cases
 Also recall facts about Façade Use Cases:
 Identify the Use Cases
 Placeholders
 Help to establish a framework for further
maturity development
 Help to establish application boundary
 Contain a number of attributes, but no basic
course of events is included.
 Often Features may map one to one to a use
case if feature is general (abstract) enough.
10

11. 11
Use Case Number: UC-03
Use Case Name: Edit Member Profile
Actor (s): Buyer, Seller
Maturity: Focused
Summary / Story: 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)
3. The Actor updates their member
profile.
6. The Actor confirms that the
information is correct.
{Profile Change}
8. This use case concludes when the
Actor receives visual confirmation of
the update.
System Response
2. The System displays the
Actor’s member profile and prompts the
Actor to update it.
4. The System validates the information
entered by the Actor.
{Validate Information}
5. The System prompts the Actor for
confirmation.
7. The System updates the
Actor’s member profile to the member
repository and informs the Actor that the
information was updated successfully.

12. 12
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-11
Continuing….

13. 13
Use Case Attributes
Use Case Attributes
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
–at bottom; original date for each version: façade, filled, focused etc.

14. 14
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.

15. 15
The Use Case Specification -2
We have also indicated the need for an Index of Use
Cases. Designate each use case as UC1, …, UCn.
Included again as next slide
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.
Sometimes considered a ‘user story’

16. Use Case
Number
Use Case Name Description Actors Level Date of Update
1 Upload Document Customer will be able to upload documents for
translation
Customers,
Database
Focused 11/13/2006
2 Translate Document The System verifies that payment has been
received from the billing company and proceeds
to translate the source document. The language
consultant reads and corrects errors in the virtual
document.
Billing Company,
Language
Consultant,
Database
Focused 11/13/2006
3 Ship Document System administrator arranges for shipments to
customers. Shipping company ships final product
hard copies and reports the status of shipments to
the system administrator.
Customer, Shipping
company, System
Administrator
Focused 11/13/2006
4 Maintain Database Administrator corrects errors and updates all
system databases.
System
Administrator,
Database
Focused 11/13/2006
5 Update Profile The customer is able to change their personal
information.
Customer, Database Focused 11/13/2006
6 Change Order The customer is able to change their order
attributes.
Customer, Database Focused 11/13/2006
7 Retrieve Document Customer retrieves target documents. Customer, Database Focused 11/13/2006
8 Print Document System directs customers to Printing
company. Printing company provides printing
options to customers and the information is
directed back to the System Administrator.
Customer, Printing
company, System
Administrator
Focused 11/13/2006

17. 17
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.)
– This is the ‘typical’ or ‘most likely’ scenario
– Sometimes difficult to pick the ‘most likely’

18. Use Case Specifications - 4
 Alternative Paths
– Other paths (may be less common; sometimes equally likely)
– Each alternative and exception (below) should indicate WHERE
in the basic course of events the alternative / exception
emanates from. Starting point. And Return point to use case
flow – unless terminated within alternative flow
– Techniques:
• cite the step number;
• labels in the basic course of events (preferred). Discuss.
 Exception Paths
– Like alternatives but typically shown for errors.
– Similar formatting rules as Alternatives – simply used for exceptions.

19. 19
The Use Case Specification -5
 Difference between <extends> and extension points.
 <extends> Refers to another extending use case.
– 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)
– 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
–Extension Points
– “Extension point” in the flow of events shows step name (in braces) or
step number from which the extending use case extends. (more later)

20. 20
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)

21. 21
Paths and Scenarios -2
Definition #2 – the “Instance,” where the scenario is a realization
of a use case (one possible path) with included data.
This is our preferred definition.
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.
– In driving design (nouns, verbs, behaviors, …)
Scenarios, then, are instances, of use cases (complete with
production data) that effectively test one path through a use
case.

22. 22
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)

23. 23
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…
 Once again, note that a system will have other
requirements besides ‘functional,’ such as
performance, maintainability, scalability, reliability…
that don’t map easily to use cases….
–Non-functional requirements tend to ‘thread themselves
through Use Cases.’
–Some will readily be captured via the software architecture
(later in course).

24. 24
More – very important!
 At end of use case modeling, you are ready to
embark upon the creation of an Analysis
Model (or preliminary design)
 Generally entering a second iteration within Elaboration
Phase in the UP
– This will involve very careful and highly iterative
analysis of use cases and all their scenarios.
– Undertake prototyping user interface, preliminary
db design, developing analysis classes and
interactions (behaviors), preliminary test design,
and more.
– This can only take place after the full Use Case
Model is ‘completed.’

25. 25
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.