for Goals this Lecture
Lecture 9: Use Cases
Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2003 Define Use Cases Review UML Notation for Use Cases Look at a variety of Use Case examples
from the books
Writing Effective Use Cases
by Alistair Cockburn ISBN: 0-201-70225-8
Patterns for Effective Use Cases
by Steve Adolph and Paul Bramble ISBN 0-201-72184-8
February 11, 2003 University of Colorado, 2003 2
Use Case Terminology
Use Case Model
consists of actors and use cases
Use Case Terminology
Use Cases
An actor can carry out many different operations on the system
Each operation or task is a separate use case
Actors
entities which interact with a system Actors are different from users
An actor represents a role that a user can play Actors are classes; Users are instances Actors are unlike other objects in that their behavior is non-deterministic
February 11, 2003 University of Colorado, 2003 3
Use cases participate in relationships with other use cases
They might use or include another use case They might extend another use case They might generalize or specialize another use case
February 11, 2003
University of Colorado, 2003
4
Use Cases as Requirements
The set of use case descriptions specifies the complete functional requirements of a system Things to remember
Use cases are requirements; They are not all of the requirements
Not good for specifying user interfaces, data formats, business rules, non-functional requirements
More on Use Cases
A use case captures a contract between the stakeholders of a system about its behavior
The use case is initiated by the primary actor; secondary actors may come into play while the use case is executing Note: actors are not restricted to human beings, other computer systems may serve as secondary actors
The primary actor is trying to achieve a goal
Many things may happen; the goal can be achieved (in more than one way) or the use case may fail (also, in more than one way) A use case captures all of these possible scenarios
They are not easy to write!
But there are techniques to make your job easier Analogy: A good story is easy to read, but writing a good story is hard!
February 11, 2003 University of Colorado, 2003 5
February 11, 2003
University of Colorado, 2003
6
More on Use Cases
Use Cases are primarily a textual object
We shall review a graphical notation for use cases in a moment; this notation is useful for specifying relationships between use cases and actors
It is completely inappropriate, however, for specifying the details of a use case
Parts of a Use Case
A use case can be as simple as
a paragraph of informal text
to
template-based forms that remind developers what information to include as well as supported by more formal notations
Writing good use cases is thus a question of style; some writing styles are more effective than others
February 11, 2003 University of Colorado, 2003 7
What to use depends on the ceremony level of the project
high ceremony projects will tend towards formal templates mid ceremony projects will use forms with some or all of the recommended fields low ceremony projects will get by with paragraphs of text
February 11, 2003 University of Colorado, 2003 8
Parts of a Use Case
Primary Actor Scope Stakeholders and Interests Minimal Guarantees Trigger Extensions Priority Response Time Channel to Primary Actor Channels to Secondary Actor
February 11, 2003
As recommended by Alistair Cockburn
Goal in Context Level Precondition Success Guarantees Main Success Scenario Technology and Data Variations List Releases Frequency of Use Secondary Actors Open Issues
9
Highlights from Parts List
Primary Actor
Actor that initiated use case
Goal Level
Can be one of very high summary, summary, user goal, subfunction, and too low Rule of thumb
a user goal is one that can be completed in one sitting at a computer a summary goal is one that cannot be completed in one sitting, and may require multiple people, organizations, and systems interacting to achieve the goal
February 11, 2003 University of Colorado, 2003 10
University of Colorado, 2003
Highlights from Parts List
Main Success Scenario
How is the goal accomplished successfully
Lets look at some examples
From Alistair Cockburns book
pages 4-6 and 9-11 page 18 Screen shots of these examples are available on the class website in the Related Materials section
Extensions
How might the main success scenario be altered and
1) still succeed
or
2) fail
February 11, 2003 University of Colorado, 2003 11 February 11, 2003 University of Colorado, 2003 12
Graphical Notation
Relationships
A use case can include another use case within it
The included use case is typically referenced by name and underlined in a particular action step The association is stereotyped include See pages 191-193 of Adolph and Bramble
Also on class website
Once the included use case is finished, the original use case proceeds as normal
February 11, 2003
University of Colorado, 2003
13
February 11, 2003
University of Colorado, 2003
14
Relationships, continued
A use case can extend another use case
This typically occurs when an extension has gotten to big for a particular use case An extension interrupts the base use case when a condition comes true The association is stereotyped extend See pages 194-195 of Adolph and Bramble
Also on class website
Relationships, continued
Use cases can declare that they can be extended using extension points See pages 188-189 of Adolph and Bramble for an example of the graphical notation for extension points and how they can be used textually
Also on class website
The extending use case has the option of terminating the original use case; otherwise, the original use case proceeds as normal
February 11, 2003 University of Colorado, 2003 15
February 11, 2003
University of Colorado, 2003
16
Relationships, continued
The UML also allows for inheritance relationships on actors and use cases
There are a lot of pitfalls associated with this; so be careful Example of proper use and some of the pitfalls are shown on pages 239-241 of Cockburn
Also on class website
Two Models of Use Cases
Cockburn has developed two models for understanding use cases
Actors and Goals Stakeholders and Interests
These models can help clarify how to think about and write use cases
February 11, 2003
University of Colorado, 2003
17
February 11, 2003
University of Colorado, 2003
18
Stakeholders With Interests
A use case can be viewed as a contract between stakeholders with interests
This model identifies what to include in a use case and what to exclude
Stakeholders/Interests Continued
Ways to uphold stakeholder interests
Gather Information
What information do off-stage actors require to understand the actions of the primary actor
Running Validation Checks
Is the primary actor entering valid information
Not all stakeholders are present during the operation of the system; when a primary actor interacts with a system, the system must uphold the interests of the off-stage actors
February 11, 2003 University of Colorado, 2003 19
Updating Logs
When did the primary actor perform his actions
Modeling stakeholder interests gives us a rule of thumb: a use cases contains all and only the behaviors related to satisfying stakeholder interests
February 11, 2003 University of Colorado, 2003 20
Using the model
In writing use cases, this model recommends
List all Stakeholders Name their interests with respect to the use case State what it means to each stakeholder that the use case completes successfully List what guarantees each stakeholder wants from the system
Actors and Goals
An actor has goals
To achieve a goal an actor has to take actions Achieving a goal may require subgoals accomplishing Achieving sub-goals may require the support and collaboration of secondary actors An action may call upon the responsibilities of a secondary actor; this sets up an interaction where the calling actor must wait for the secondary actor to achieve the goals associated with that responsibility
February 11, 2003 University of Colorado, 2003 22
Now, we can write actions steps
This brings us to the Actors and Goals model
February 11, 2003 University of Colorado, 2003 21
Actors and Goals Illustrated
Primary Actor System Secondary Actor
Discussion
Goals have sub-goals
avoid having too many sub-goals however
Goals can fail
Responsibility Goal 1 Goal 2 Action 1 Action 2
Interaction
We must specify how to respond to failure conditions using extensions
Actions capture Interactions
Responsibility Goal 1 Action 1
University of Colorado, 2003
Writing Action Steps is critical to writing good use cases
Responsibility
23 February 11, 2003 University of Colorado, 2003 24
February 11, 2003
Writing Action Steps
Action Steps are written in one grammatical form
a simple action in which one actor either
accomplishes a task or passes information to another actor
Action Step Guidelines
#1: Use Simple Grammar
Subjectverbdirect objectprepositional phrase
The subject is important, see guideline 2
The systemdeductsthe amountfrom the account
Examples
User enters name and address At any time, user can request the money back The system verifies that the name and account are current
February 11, 2003 University of Colorado, 2003 25
Bad writing makes the story hard to follow Complex writing makes it hard to extend an action step
e.g. if a step does three things, then if you extend that step, which thing does it extend?
February 11, 2003 University of Colorado, 2003 26
Action Step Guidelines
#2: Show Clearly Who Has the Ball
For each step, who is performing it?
Think of friends kicking a soccer ball
You can pass it to yourself You can pass it to a friend You can do something with the ball (e.g. perform a trick)
Action Step Guidelines
#3: Write From a Birds Eye View
Developers tend to write action steps from the systems perspective rather than a users external perspective
e.g. Get ATM Card and PIN -- bad rather The customer inserts the card and The customer enters the PIN
The person with the ball represents the actor The ball represents a message or information being passed between actors
You can manipulate the information or pass it on
Alternative Style
Customer: Inserts the Card Customer: Enters the PIN
At the end of the step, who has the ball?
The answer should always be clear in the writing
February 11, 2003 University of Colorado, 2003 27
February 11, 2003
University of Colorado, 2003
28
Action Step Guidelines
#4: Show the Process Moving Forward
The amount of progress made in one action step varies according to the level of the use case
In a summary use case, each step might satisfy a goal In a subfunction use case, each step may correspond to a computation by the system or data entry by the user
Action Step Guidelines
#5: Show the Actors Intent, Not the Movements
Before
System asks for name; User enters name System prompts for address; User enters address User clicks OK System presents users profile
If a use case has 17 or more steps, it may indicate that the scope of each step is too small
Not User hits tab key but User enters Name
After
User enters name and address System presents users profile
To find a slightly larger scope for a step, ask Why is the actor doing this? The answer is probably the scope you are looking for
February 11, 2003 University of Colorado, 2003 29
Otherwise you end up with longer, brittle, and overconstrained use cases; why?
February 11, 2003 University of Colorado, 2003 30
Action Step Guidelines
#6: Include a Reasonable Set of Actions
Ivar Jacobsons notion of a transaction
Actor sends request and data to system System validates the request and data System alters its internal state System responds to actor with result
Action Step Guidelines
#7: Validate Do not Check Whether
Before
The system checks whether the password is correct If it is, the system presents the available actions for the user
After
The system validates the password is correct The system presents the available actions for the user
An action step can contain all four; or start with some in one step and end with the others in the subsequent step
See examples in lecture (page 94 of Cockburn)
February 11, 2003 University of Colorado, 2003 31
With Checks you always have to say If true or If false in the next stepnot good; with validates you choose th...