Transcript Use Cases - Gadjah Mada University

Use Case Diagrams
Use Cases, slide no. 1
Use Cases Were Introduced by Ivar
Jacobson in the Beginnig of the 1990s.
“A use case is a specific way of using the
system by performing some part of the
functionality. Each use case constitutes a
complete course of events initiated by an
actor, and it specifies the interaction that takes
place between an actor and the system…...
The collected use cases specify all the
existing ways of using the system.”
Use Cases, slide no. 2
Grady Booch et al.:
If you design a new house and you are
reasoning about how you and your family
will use it, this is use case-based analysis.
You consider the various ways in which
you‘ll use the house, and these use cases
drive the design.
Use Cases, slide no. 3
Use Case Diagram - a Part of UML
Use case diagrams are often drawn in collaboration with users of
the system. In essence use case diagrams will show, from an external
point of view, how the system will be used by the various users - how the
dialog between users and the system will be.
Use case diagrams are often the kind of diagrams one starts out with,
they may be part of the requirements modeling. Users of the system can
easily identify with the diagrams, after all the diagrams identify
interactions that users have with the system when they wants to achieve
some goal. If use cases are used extensively they can drive the whole
development process.
So the focus is: what functionality is involved and who will ask for
the provided services. How the services are carried out by the system is
not addressed.
With users we don’t necessarily mean humans, external systems which
interacts with the system under consideration will also be modeled as a
user (actor).
Use Cases, slide no. 4
Purpose of Use Cases
• Capture the requirements of a system
• Validating systems, a correct design allows
all use cases to be carried out (each use case
is realized)
• Specify the context of a system
• Drive implementation and generate test
cases
Use Cases, slide no. 5
Use Cases and
Requirements
• A use case describes a unit of behavior.
• A requirement describes a law that governs
behavior.
• A use case can satisfy one or more
functional requirements.
• A functional requirement may be satisfied
by one or more use cases.
Use Cases, slide no. 6
A Use Case Is Often Described
in Clear Text
• Example: Student register for course
– Main flow of event: The use case starts when the
student brows the course register page, inserts the student
card in the card reader and issues the right pin code.
The system presents all possible courses for this student.
The student select course and commits the entry by
pressing the Enter button.
– Exceptional flow of events: The student can cancel a
registration by pressing the Cancel button.
Use Cases, slide no. 7
Often a Use Case Is Followed by a More
Detailed Description of How the Functionality
of the Use Case Is Accomplished
• Precondition
• Main or exceptional flows of events
expressed as a:
– written list of actions
or as
– an activity diagram
student brows the course
register page
student inserts the card
in the card reader
• Postcondition
Use Cases, slide no. 8
“Use Case Form” from Together
(Together is a modeling tool)
Use Cases, slide no. 9
Use Case Refinement and Some
Limitations
• It is possible to work top down, first specifying use
cases at a high level and then proceed with more elaborated
use case diagrams (use case refinement).
• Some limitations:
– The interactions between objects inside the
system are not modeled.
– You can not model concurrency.
Use Cases, slide no. 10
Graphical Notation
– An actor is a user role, a kind of stereotype. The actor is symbolized
with a “stick man” figure with the name of the actor below the figure.
– A use case is shown as an ellipse, with a name inside identifying the
use case.
– When an actor is involved in a use case, a line is drawn from the actor
to the use case. We say that the actor communicates with the use
case. Who is initiating the communication can be indicated by an
arrowhead.
use case
actor
Both actor and use case
can initiate the communication.
use case
actor
The actor initiate the
communication.
use case
actor
The use case initiate
the communication.
Use Cases, slide no. 11
The Actor
[2] ”The total set of actors within a use
case model reflects everything that needs to
exchange information with the system.”
Use Cases, slide no. 12
How To State A Use Case [2]
• ”A use case is most effectively stated from the
perspective of the user as a present-tense verb
phrase in active voice, that are precise and clear.”
• ”When it comes to writing text for use cases,
expansive is much preferable to terse.”
• ”An alternate course of action can represent an
infrequently used path through the scenario, an
exception, or an error condition.”
Use Cases, slide no. 13
Use Case Examples
register as student
register for course
adm
register for exam
student
instructor
works with course
lab
System Boundary
make/edit course
lecturer
Use Cases, slide no. 14
System Boundary
• It is possible to define the boundary of the system.
• This is particular useful if you have a complex
system and split it up into sub system. Specifying
the boundaries of each subsystem can make the
separation between the subsystem clear.
Use Cases, slide no. 15
Use Case Scenario
• A use case is similar to a class, it represent a set of
possible interactions. Different (concrete) actors may be
involved, different flows of events are possible!
• A scenario is a possible interaction between the system an
some actor(s).
• A scenario can be seen as an instance of a use case, in the
same way as an object is seen as an instance of a class.
• Even if the scenarios are different, they should all attemt
to solve the same task!
Use Cases, slide no. 16
Relationships Between
Use Cases
• You have three types of relationships:
– Generalization
– Include
– extends
• Use of these features will typically make a use case
diagram more complex to read, so they should be
used with caution.
• There is not full agreement on how to use these features, e.g.
UML 1.1 and UML 1.3 differs on these matters.
Use Cases, slide no. 17
Stereotypes in UML
• Extends and includes is represented with dependency arrow. The
dependency arrow is already used, because of this extends and include
must be stereotypes. In UML stereotype names are included in << and >>.
• The following definition can be found in “UML Notation Guide” from
Rational Software:
“A stereotype is, in effect, a new class of modeling element that is
introduced at modeling time. It represents a subclass of an existing
modeling element with the same form (attributes and relationships) but with
a different intent.”
Use Cases, slide no. 18
1
Types of Relationships Between
Use Cases: Include
Validate
student
“include”
Register for
course
base
• The include relationship indicates that the base use case
incorporates the behavior of the other use case.
• The base use case is dependent of the included use case but
not the opposite way.
• Functionality shared between two use cases can in this way be
extracted out and described in a separate use case.
Use Cases, slide no. 19
Specifying an Inclusion Point
• Student register for course, main flow of
event:
– The use case starts when the student brows the course
register page.
– The user write user name and password.
– Inclusion point: Validate student
– The system presents all possible courses for this student.
– The student select course and commits the entry by
pressing the Enter button.
Use Cases, slide no. 20
Refinement of:
register as student
Use Case “register as student”:
This use case is started by the student (which at this point is not a student),
which request to be registered as a student. A person from the
administration updates the student register.
make student
profile
validate student
for study
“include”
“include”
register
as
student
student
“include”
enter student in
“student register”
adm
Use Cases, slide no. 21
More On Include
• Include is used to define functionality that is
common to several use cases, a modularization
technique.
• If we see that a component can be used, we can
model this by a separate use case describing the
component.
• A scenario that is an instance of the base use case
will typically contain a sub scenario from the
included one.
Use Cases, slide no. 22
2
Types of Relationships Between
Use Cases: Extend
• If a use case incorporates two ore more clearly different
scenarios - some condition dictates which - this can be
modeled by an extend relation.
• So the extend relationship can be used to model behavior that
the user sees as optional or as an exception on normal
behavior. The base use case can incorporate the extended
behavior under certain conditions otherwise stand alone.
Use Cases, slide no. 23
Extend - The Notation
Issue Diploma
Extension points
exams not completed
“extend”
(exams not complete)
Issue Incomplete
Diploma
base
• You should specify:
– The condition under which the extended use applies
– At which point the condition is tested and the behavior
may diverge; This point is called the extension point.
Use Cases, slide no. 24
Use Case from Booch et al.
Place order
Extension points
set priority
“extend”
(set priority)
Place
rush order
“include”
Track
order
“include”
Validate
user
Check
password
Use Cases, slide no. 25
3
Types of Relationships Between
Use Cases: Generalization
Validate
student
Validate student
with pin code
parent
child
• The generalization relationship indicates that the child will
inherits the behavior and meaning from the parent use case.
The child can alter or/and extend the behavior of the parent,
but it should be possible to substitute the child for the parent
every place the parent is used.
Use Cases, slide no. 26
Extend and Generalization
• This relations are very similar, some claim that UML
would be better with only one oft them!
• How to select one of them:
– Extend: if you wants to describe extra behavior that is to
be used under certain condition; a condition that is tested
at run time.
– Generalization: if you have a specialization of a whole use
case.
Use Cases, slide no. 27
Use Case Driven
Development
• The focus will be on the user requirements (the use cases).
• The use cases are the most important aspect of the design
process.
• Use cases are used through the whole development
process, to track changes and define iterations.
• Some see the examination of use cases as the main method
of finding classes and objects in the system, other
recommend an approach where use cases and conceptual
class diagrams are developed in parallel.
Use Cases, slide no. 28
Some Possible
Problems
• Use cases are not inherently object oriented, so we
can end up with a non-object-oriented system.
• We might mistake design for requirements, e.g.
specifying a sequence of interactions which in fact
is only one of many sequence candidate to achieve
the goal .
Use Cases, slide no. 29
Actors and Class
• It is common to have a class representing a special
type of actors (e.g. Student) inside the system.
• If you have a class representing a set of actors,
you can mark this class with the stereotype ”actor”.
”actor”
Student
Use Cases, slide no. 30
Use Case Example [1] Use Case: 5
Buy Goods
CHARACTERISTIC INFORMATION
Goal in Context: Buyer issues request directly to our company, expects
goods shipped and to be billed.
Preconditions: We know Buyer, their address, etc.
Success End Condition: Buyer has goods, we have money for the goods.
Failed End Condition: We have not sent the goods, Buyer has
Company is out of one
not spent the money.
of the items
Primary Actor: Buyer, any agent (or computer) acting for
the customer
«extend»
Trigger: purchase request
Buyer pays directly
comes in.
Buy Goods
«extend»
Stimuli
with credit card
Buyer
«extend»
Buyer returns goods
Use Cases, slide no. 31
Use Case: 5
Buy Goods
Each step take the form ”A does X”, where A is
---------------------------------------an actor and X is an action. If a use case is
MAIN SUCCESS SCENARIO
included you will find a step that has the form
1. Buyer calls in with a purchase request.
”include U”, where U is another use case.
2. Company captures buyer’s name,
Extension 3a is execute instead of 3 if condition:
address, requested goods, etc.
”Company is out of one of the ordered items” is
3. Company gives buyer information on
fulfilled!
goods, prices, delivery dates, etc.
Company is out of one
of the items
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
«extend»
6. Company ships invoice to buyer.
Buyer pays directly
7. Buyers pays invoice.
Buy Goods
with credit card
«extend»
---------------------EXTENSIONS
Buyer
3a. Company is out of one of the ordered items:
«extend»
3a1. Renegotiate order.
Buyer returns goods
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case
44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
Use Cases, slide no. 32
More On Use Cases
• A use case either reach it’s goal or fail; if only a main
success scenario is given, then success is assumed!
• Each extension can be seen as a new use case, a sort of
specialization of the base use case (so this is almost the same as
specialization/generalisation).
• [1] The last step in a extension can take one of the
following forms:
– Fail - use case is terminated and goal is not achived
– Stop - use case is terminated and goal is achived
– Resume N - execution should continue at step N in main success
scenario.
– If the last step is not one of the above, continue at main scenario.
Use Cases, slide no. 33
One More Example
Initiator ReservationMaker
Goal
Reserve room(s) at a hotel
Main Success Scenario
1. ReservationMaker asks to make a reservation
2. ReservationMaker selects, in any order, hotel, dates and room type.
3. System provides price to ReservationMaker.
4. ReservationMaker asks for reservation.
5. ReservationMaker provides name, e-mail…
6. System makes reservation and allocates tag to reservation.
7. System reveals tag to ReservationMaker.
8. System creates and sends confirmation by e-mail.
Extensions
3. Room not available.
a. System offers alternatives.
b. ReservationMaker selects from alternatives.
3b. ReservationMaker rejects alternatives.
a. Fail
4. ReservationMaker rejects offer
a. Fail
5. Customer already on file
Use Cases, slide no. 34
a. Resume 6
Another relationship
between use cases
• [2]”You use precedes to indicate that one
use case precedes another within a logical
Company is out of one
sequence.”
of the items
«extend»
Buy Goods
«extend»
Buyer pays directly
with credit card
Buyer
«extend»
Buyer returns goods
Use Cases, slide no. 35
References
[1] Alistair Cockburn : http://members.aol.com/acockburn/
2001, Feb.
[2] Doug Rosenberg and Kendall Scott: Use Case Driven Object Modeling with UML:
A Practical Approach
Addison-Wesley
- Ivar Jacobson: Object-Oriented Software Engineering: A Use Case Driven Approach.
Addison-Wesley, 1994
- Martin Fowler with Kendall Scott: UML Distilled.
Addison-Wesley, 1997
- Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language User
Guide.Addison-Wesley, 1999
- Terry Quatrani: Visual Modeling with Rational Rose and UML.
Addison-Wesley, 1998
- Daniel Tkach, Walter Fang and Andrew So: Visual Modeling Technique, 1996
- Alistair Cockburn’s Web: http://members.aol.com/acockburn
- Rational software: http://www.rational.com/uml/documentation.html
Use Cases, slide no. 36