Otherwise the scenarios get very muddled and you loose tack of the user's goal.
We are not trying to write a program full of selections and loops (yet). We
just need to separate out the various steps the user takes and link them
to the systems visible response.
When we analyze a use case as part of design we use
a UML sequence diagram that has "columns". One for the System and one
for each actor taking part. We have tools to draw these diagrams.
They are called SSDs. If your process includes SSDs you don't need
a two column use case format.
SSD::="Systems Sequence Diagram", Shows the sequence of messages betweeen external actors
and the system to achieve a scenario in a use case.
In this class I require you to use SSDs for use cases.
Can you clarify the differences between primary, supporting and offstage actors in relation to the system under design?
I tend to call supporting actors secondary actors.
All these actors are stakeholders in the system.
start the use case, secondary actors are accessed by the
play a more passive roll. The primary actor
plays the active roll getting the ball rolling. The secondary or
supporting actors get sucked into the use case.
Classic examples are a Data Base Management System or a LDAP server.
To large extent the name of the use case mentions the primary actors goal.
All use cases must have a primary actor and their goal --- or else they
are not use cases.
is a stake-holder who has an interest in the use case but doesn't
take part in it. Some body who does not take part but is effected by the out come.
Example: the dept chair is not taking part in this class, but
he has an interest in it being taught on time, in the right place, and with
some level of competence. He/she is off-stage but a stake holder.
In ham and eggs, the primary actor is eating breakfast, the pig is a secondary actor,
and the hen is an off-stage actor.
I have known use case as diagram and text, but the book wrote in bold "use
cases are not diagrams, they are text" can you elaborate more on what the
The diagram shows a collection of use cases and so is not a use case. This
is like the fact that a bottle of water is not the same as a vending machine
full of bottles of water.
A use case defines a sequences of actions by a user and the system that
gives the user some tangible outcome. A use case diagram
does not show the sequences. It omits important information. But it
summarizes the relation between many use cases and actors instead.
A use case diagram is like a bag of hard candy -- you can't
get the benefit without extracting a candy and unwrapping it.
Put it another way: don't waste time on an elaborate diagram because
you can get more value out of describing an interesting use case in detail.
Why use-case modeling is primarily an act of writing text, not drawing
diagrams? I think I prefer reading diagrams than long text.
My sympathies. I agree.... but use cases are meant to be read
(indeed written) by non-computer
people and so diagrams get in the way.
When using use-cases, when do we know to use diagrams or/and text to
describe the scenario?
Scenarios should always be text -- and inside a use case.
The use cases fit inside a diagram.
During Systems Analysis or Business Modeling
you can use diagrams (DFDs, Activity diagrams)
to discover use cases. But not in Requirements.
Analyzing a very complex use case might need an activity diagram, but if
it does then I'll bet that the a human will get lost trying to use it, So
it is a bad idea already. Exception -- mapping out the interaction between a
computer primary actor and the system under design. Protocols....
I have a question about the clarity of use-cases. In a software company
are they meant to be presented and thoroughly explained to the developers,
lets say in a meeting room, or is the use-case printed and handed to each
development team to read over and ask questions later?
This is an important process question. In many organizations the
requirements are "thrown over the wall" to the developers. Many
people think that this is a mistake. Either the developers should work
stakeholders to develop use cases in special "Requirements Workshops"
or the developers draft them and get the stakeholders to
review them (not as good)
Out of the 3 common use case formats (brief, casual, fully dressed) What is
the most popular format to use and why?
Every body likes the short ones. In practice use cases should grow as the
project moves forward. Each starts as just a name, then becomes brief,
then casual, and finally fully dressed... just before working
out how to realize it.
What type of common use case format do you want us to use, Brief, Casual or
All of them. You need practice at all styles. Also in a real project,
you should, most of the time, have use cases with all levels of detail.
Not until the end will most of them be fully dressed. Initially just
1 out of 10 might be fully dressed. See
[ w2.html ]
for work that involves all formats.
By the way -- using the fully dressed one with a good template
is not as hard as you might think. It is the thinking
that takes time not the format. And the thinking is what improves your
software. The format lets you share your thoughts.
What is the importance of Stakeholders holder's interest in the use cases?
They are paying for it!!!
More -- much software fails because it fails to meet the stakeholder's
When the book says "Stakeholder's Interests" it does not mean things
like "Going to movies". It means things like:
"Needs UC17 to complete within 3 seconds" and
"Will loose job if unable to access data base."
Is the "Happy Path" the most likely case of a use case senario or just an example
of a use case? Can you put into perspective the "Happy Path"?
It is not the frequency that makes a path "happy" but the happiness of
the primary actor getting what they want in the simplest way possible.
Joke: Murphy's law makes sure that the Happy Path happens alternative
An extension is an alternative flow.
another scenario by adding conditions and options to steps.
If complicated an extension may be
described as a separate use case. This notation and technique will be covered
later in this class.
How come the basic flow does not include any conditions or branching? If it did
have conditions and branching, would it be called a Alternate flow?
This is to keep the main flow clean and uncluttered. And even alternate flows should be
kept as simple sequences if at all possible.
This discipline helps!
We hide the
conditions at the start of the alternate flows.
That way we
can design programs that handle the main flow nicely with out getting
distracted. Then the extensions/alternatives can be added to the clean,
simple (but fragile) prototype.
I think of the alternate flows as exception handlers. The main
flow 'throws' the exception automatically to the alternate flow. But
we don't have to write that.
This is very nice when the alternate flow is triggered in many different
steps. The use case is much shorter and simpler when the main flow
has few conditions.
However -- we often have simple loops and could have a simple pair of
branches in the main flow -- as long as you can write the step as a single
- Repeat steps 2 through 5 until exhausted.
- If user likes tea then the user selects tea else user chooses coffee.
In regards to the number of extensions is there a rule of thumb? How deep
into an extension do you go? How many extensions do you do?
There is no ideal number of extensions. You add to them throughout the
first three phases (and maybe even in transition). Start with none.
End with many.
You should stop when adding an extension gives no value to the
When a actor faces two or more cases to complete a transaction; for example
to purchase a car the dealer has to verify his credit record, driven
record, being a citizen or resident and must have a current job.
So, my question is:
We should develop a single class diagram to show the entire process with
their respective Use case or is better to do it separate using single Use
One use case diagram per medium sized project. One for a simple project. Many diagrams
only in big projects -- and put them in packages...
NO CLASSES in a use case diagram.
You should treat this as one use case that has several steps in its scenarios.
So ONE BUBBLE on the use case diagram. Expand the details like this:
- UC1: Purchase car
- Prime Actor: Customer
- Other Actors: Dealer, Credit agency, DMV, DHS,...
- Main Scenario:
- Purchaser expresses interest in car.
- Dealer verifies credit record.
- Dealer checks residence and driving record.
If, AND ONLY IF, I discover the same steps appearing in other use case
would I separate out these steps as a separate (secondary) use case. We may look at
later in the course.
What is a boss test? Is it just finding out if your boss is happy?
I think it means: would the boss be happy to see you doing it all day.
- Salesman makes a sale.
(YES) -- useful use case
- Salesman twiddles fingers
(NO) -- not a useful use case
- Salesman downloads porn.
(NO) -- abuse case -- not useful.
[ Use_Case ]
[ Basic_use_case_template ]
(Alistair Cockburn's templates),
[ UseCaseTemplate.html ]
(Complex fully dressed template in HTML from MIT), and
[ fullydressed.html ]
A handheld, wireless device that helps shoppers buy the items that they want. A shopper has a list of items that they want. They are sold at different stores. The device keeps an up-to-date list of wanted items as the user shops.
The shopper inputs a list of wanted items and the system displays stores where they can be found. The shopper goes from store to store looking for the products that match their list. They buy a product at the first store where they find it, mark it as bought and the system updates their list or items and stores.
. . . . . . . . . ( end of section Example of a Simple system) <<Contents | End>>
[ 04q.html ]
[ 04r.html ]
[ example2010.html ]
(Exercises): Write a Use Case for...
[ 04x.html ]
Prepare by reading
[ 05.html ]
and the assigned readings on that page. Do as many review questions
[ 05r.html ]
as you have time for.
Submit one review question+answer
The deliverable artifacts and presentation are in
[ w1.html ]
and they are due at start of class 05.