Use Cases, slide no. 1 Use Case Diagrams. Use Cases, slide no. 2 Use Cases Were Introduced by Ivar...

Use Cases, slide no. 1

Use Case DiagramsUse Case Diagrams


Use CaseUse Casess Were Introduced by IvarWere Introduced by Ivar JacobsonJacobson in the Beginnig of the 1990s. 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.”


Grady Booch et al.: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 Case Diagram - a Part of UMLUse 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).


Purpose of Use CasesPurpose 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 and Use Cases and RequirementsRequirements

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


A Use Case Is Often Described A Use Case Is Often Described in Clear Text 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.


Often a Use Case Is Followed by a More Often a Use Case Is Followed by a More Detailed Description of How the Functionality Detailed Description of How the Functionality

of the Use Case Is Accomplishedof 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 courseregister page

student inserts the cardin the card reader

• Postcondition


““Use Case Form” from TogetherUse Case Form” from Together (Together is a modeling tool)(Together is a modeling tool)


Use Case Refinement and Some Use Case Refinement and Some LimitationsLimitations

• It is possible to work top downpossible 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 modeledinteractions between objects inside the system are not modeled .

– You can not model concurrencycan not model concurrency.


Graphical NotationGraphical 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.

actor

use case

Both actor and use case can initiate the communication.

actor

use case

The actor initiate thecommunication.

actor

use case

The use case initiatethe communication.

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


[2] ”The total set of actors within a use case model reflects everything that needs to exchange information with the system.”

The ActorThe Actor


How To State A Use Case [2]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 Case ExamplesUse Case ExamplesUse Case ExamplesUse Case Examples

student

register for courseregister for course

works with course

lecturer

adm

lab

instructor

make/edit course

register for examregister for exam

register as studentregister as student

System Boundary


System BoundarySystem 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 Case ScenarioUse 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!


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

Relationships Between Relationships Between Use CasesUse Cases


Stereotypes in UMLStereotypes 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.”


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

Types of Relationships Between Types of Relationships Between Use Cases: Use Cases: IncludeInclude

Validatestudent

Register forcourse

“include”

base

11


Specifying an Inclusion Point 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.


student

validate studentfor study

registeras

student

enter student in “student register”

adm

make studentprofile

register as studentregister 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.

Refinement of:Refinement of:

“include”“include”

“include”


More On IncludeMore 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.


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

Types of Relationships Between Types of Relationships Between Use Cases: Use Cases: ExtendExtend22


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

ExtendExtend - The Notation - The Notation

Issue DiplomaExtension points

exams not completed

Issue IncompleteDiploma

“extend”(exams not complete)

base


Use Case from Booch et al.Use Case from Booch et al.Use Case from Booch et al.Use Case from Booch et al.

Place orderExtension points

set priority

Place orderExtension points

set priority

Placerush order

Validateuser

TrackorderTrackorder

Checkpassword

Checkpassword

“include”

“include”

“extend”(set priority)


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

Types of Relationships Between Types of Relationships Between Use Cases: Use Cases: GeneralizationGeneralization

Validatestudent

Validate studentwith pin code

parent child

33


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

Extend and GeneralizationExtend and Generalization


Use Case Driven Use Case Driven DevelopmentDevelopment

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


Some Possible Some Possible ProblemsProblems

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


Actors and ClassActors 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 Case Example [1] -Use Case Example [1] -Use Case: 5Use Case: 5 Buy GoodsBuy 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

not spent the money.

Primary Actor: Buyer, any agent (or computer) acting for

the customer

Trigger: purchase request

comes in.

Buyer

Buy Goods

Company is out of oneof the items

Buyer pays directlywith credit card

Buyer returns goods

«extend»

«extend»

«extend»Stimuli


Buyer

Buy Goods



Buyer returns goods

«extend»

«extend»

«extend»

Use Case: 5 Buy Goods

----------------------------------------

MAIN SUCCESS SCENARIO

1. Buyer calls in with a purchase request.

2. Company captures buyer’s name,

address, requested goods, etc.

3. Company gives buyer information on

goods, prices, delivery dates, etc.

4. Buyer signs for order.

5. Company creates order, ships order to buyer.

6. Company ships invoice to buyer.

7. Buyers pays invoice.

----------------------

EXTENSIONS

3a. Company is out of one of the ordered items:

3a1. Renegotiate order.

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)

Each step take the form ”A does X”, where A is an actor and X is an action. If a use case is included you will find a step that has the form ”include U”, where U is another use case.Extension 3a is execute instead of 3 if condition: ”Company is out of one of the ordered items” is fulfilled!


More On Use CasesMore 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 thefollowing 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.


Initiator ReservationMaker

Goal Reserve room(s) at a hotel

Main Success Scenario1. ReservationMaker asks to make a reservation2. 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.

Extensions3. Room not available.

a. System offers alternatives.b. ReservationMaker selects from alternatives.

3b. ReservationMaker rejects alternatives.a. Fail

4. ReservationMaker rejects offera. Fail

5. Customer already on filea. Resume 6

One More ExampleOne More Example


Another relationship Another relationship between use casesbetween use cases

• [2]”You use precedes to indicate that one use case precedes another within a logical sequence.”

Buyer

Buy Goods



Buyer returns goods

«extend»

«extend»

«extend»


ReferencesReferences[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. 1 Use Case Diagrams. Use Cases, slide no. 2 Use Cases Were Introduced by Ivar...

Documents

Transcript of Use Cases, slide no. 1 Use Case Diagrams. Use Cases, slide no. 2 Use Cases Were Introduced by Ivar...