pps - use case

8/2/2019 PPS - Use Case

1/26

Romi Fadillah Rahmat, B.Comp.Sc, M.Sc


2/26

Use case is a pattern behavior.

Focus on what not how

A higher level view of the system

Interaction between user (Actor) and system.

Each use case consist of one or more

scenario/transaction/dialogue between actor

and the system.

Symbol : Ellipse


3/26

The use cases may be decomposed into

other use cases.

It is best to express your use case

title/label in a few words (generally nomore than five words).

These few words must begin with a

present-tense verb phrase in active voice,

stating the action that must take place

(notice: Draw Card and Switch Turn).


4/26

A scenario is a sequence of actions that

illustrates behavior. A scenario may be used

to illustrate an interaction or the execution

of a use case instance. You will get your scenario from your

requirement (direct interview and so on)


5/26

Monopoly game (one use case): Player 1 lands on Blue 3. This house is owned by

Player 2, and the rent is $25. Player 1 gives Player 2$25.

Use case title : Paying rent

Monopoly game (two scenario in one use case) : A player is in Jail. The player clicks the Get out ofJail button. $50is decremented from their money.The player can then roll the dice and continue withthe game.

A player is in Jail. The player clicks the Get out ofJail button. The playerhas less than $50. The playerbecomes bankrupt and all the tradable cells he or sheowns becomes available in the game. The player isout of the game.

Use case title : Get out of Jail


6/26

An actor is an entity that interacts withthe system and/or needs to exchangeinformation with the system

Actor is always external to the system.They are never be a part of the system tobe developed.

An actor could be other systems or some

other form of external input into thesystem

One actor should be associated with oneor more use case/s.


7/26

How to determine an actor? Who uses the system?

Who installs the system?

Who Starts up the system?

What other systems use this system?

Who gets the information from the system?

Who provides information to the system?

Actors represent roles not individuals

Do not confuse actors with people and/orjob titles.


8/26

An actor is always a noun in the scenario.

4-Categories of an actor: Principle : Who uses the main system

functions.

Secondary : Who takes care of administration &maintenance. External h/w : The h/w devices which are part of

application domain and must be used. Other system: The other system with which the

system must interact. An actor may input information to the system. receive information from the system. input to and out from the system.


9/26

The following questions can be asked toidentify use cases, once your actors havebeen identified What functions will the actor want from the

system? Does the system store information? What actors

will create, read, update or delete thisinformation?

Does the system need to notify an actor aboutchances in the internal state?

Are there any external events the system mustknow about? What actor informs the system ofthose events?


10/26

It is important to clearly define the boundary

of your system. Things inside the boundary of

the system are things you need to worry

about creating. Symbol : Rectangle

The boundary of the system can be

seperated into several sub-system.


11/26

Associations between actors and use cases are

indicated in use case diagrams by solid lines.

An association exists whenever an actor is

involved with an interaction described by a use

case.

Associations are modeled as lines connecting use

cases and actors to one another, with an optional

arrowhead on one end of the line.

The arrowhead is often used to indicating the

direction of the initial invocation of the

relationship or to indicate the primary actor

within the use case.


12/26

Use case flow of events / use case

description

A textual description of the sequence of

transactions of a use case is also needed forus to understand what really happens in a

use case

The flow-of-events is written in terms of

what the system should do, not howthesystem does it.


13/26

X Flow-of-Events for the Use Case X.1 Preconditions. What needs to happen (in another

use case) before this use case can start? What statemust the system be in before the use case?

X.2 Main Flow. The main flow is a series of

declarative steps. X.3 Sub-flows. Sub-flows break down the main flow

and other sub-flows to improve documentreadability.

X.4 Alternative Flows. The alternative flows defineexceptional behavior that can interrupt the normal

flow. Often alternative flows indicate what is to bedone under error conditions. To determinealternative flows, ask yourself, What could possibly

go wrong? for each of the actions in the main flowand the sub-flows.

Note: X is a unique identifier for each use case.


14/26

UC8 Flow of Events for the Buy House Use Case 8.1 Preconditions:

1. It is the players turn.

2. The player has not rolled the dice.

3. The player has monopoly on one or more color groups.

8.2 Main Flow:

When a player has all the tradable cells in a color group, this player is saidto have monopoly on the color group. A player may build house(s) in theproperty cells in the color groups the player has monopoly on by pressingthe Buy House button before he or she rolls the dice [S1] [E1 E2]. Theprice of the house is determined by the cell. After buying the house(s), thestatus of the player is updated and displayed on the game board [UC13].

8.3 Subflows:

[S1] When the Buy House button is clicked, the Buy House dialog shows up.The player selects the monopoly color group and the number of houses from

that dialog. After clicking on OK in the dialog box, the player pays the fee,and the houses are created. All the property cells in the selected colorgroup have the same number of houses.

8.4 Alternative Flows / Postconditions:

[E1] Nothing happens if the player does not have enough money.

[E2] The player can build at most five houses in a cell.


15/26

Generic format for documenting the use case:

Pre condition : if any

Use case : Name of the case.

Actors : List of actors(external agents), indicating who

initiates the use case. Purpose : Intention of the use case.

Overview : Description.

Type : primary / secondary.

Post condition: If any


16/26

The following use case describes the process of

opening a new account in the bank.

Use case :Open new account

Actors :Customer, Cashier, Manager

Purpose :Like to have new saving account.

Description :A customer arrives in the bank to openthe new account. Customer requests for the new

account form, fill the same and submits, along with the

minimal deposit. At the end of complete successfulprocess customer receives the passbook.

Type :Primary use case.


17/26

The use caseprecondition indicates that before the use case canbegin, it must be the player (who wants to buy a house)s turn.The player has not rolled the dice, and the player must have amonopoly by owning all properties in a color group.

The main flowlists the sequence of events. When a main flow or sub-flow has an event marked such as [Sx], this

indicates that a sub-flow of this use case must be run. When thatsubflow completes, control is passed back. For example, the buyhouse dialog shows up [S1]. Once the dialog box is clicked, control ispassed back to the main use case and the house is purchased.

When a main flow or sub-flow has an event marked such as [Ex], thisindicates that an exceptional condition might occur. If it does occur,the appropriate alternative flow explains how the situation should behandled. For example, if the player does not have enough money or

has more than five houses [E1-E2], the buy house dialog will not showup.

When a main flow or sub-flow has an event marked such as [UCx], thisindicates that another use case must be run. When that use casecompletes, control is passed back to this use case. For example,once the house purchase is complete, the status of the player isupdated and displayed. [UC13]


18/26

The sub-flows list individual sequences of themain flow. Sub-flows can also handle the

calling of other use cases, other sub-flows,

and alternative flows similarly to the main flow.

Alternative flows list individual sequences ofhow exceptional situations should be handled.

All sub-flows and all alternative flows must be

called from the main flow or from sub-flows(s)

by an indication such as [Sx] or [Ex]. If they arenot called, they have no purpose because they

can never be executed.


19/26

The include relationship signifies that one use class isincluded in anothers functionality.

You use the include relationship when a chunk ofbehavior is similar across more than one use case andyou dont want to keep copying the description ofthat behavior

For example, suppose many actions of a systemrequire the user to log into the system before thefunctionality can be performed.

These use cases would include the Login use case.Heres a hint. You should not break out a use case tobe included by other use cases unless more than oneother use case will include it (i.e. in a case diagramthere should be more than one arrow coming intothe included use case).


20/26

The include relationship is not the default

relationship.

Therefore, in a use case diagram, the arrow

is labeled with include when one use casemakes full use of another use case


21/26

The Draw Card and the Buy House both use theView Information functionality. Whenever a usecase includes functionality of another use case,

the use case flow-of-events will call theincluded use case.

In the example Buy House flow-of events in thelast section, the View Information [UC13] usecase was called from the main flow.


22/26

You use the extendrelationship when you aredescribing a variation on normal behavior or

behavior that is only executed under certain,

stated conditions.

The extend relationship is similar to the

alternative flows of a use case. However, the

extend relationship is used when the

alternative flow is fairly complex and/ormulti-stepped, possibly with sub-flows and

alternative flows.


23/26

Scenario :A player moves on the boardbecause he or she has to go to jail.

This scenario involves a player moving.

However, sometimes a player has to dealwith exceptional situations rather than

just moving to a new property cell.

Therefore, we can extend the Move use case

with the Go to Jail


24/26

Frequently, software developers are confused as towhether to use the include relationship or the extendrelationship. Consider the following distinctionsbetween the two: Use Case X includes Use Case Y:

X has a multi-step subtask Y. In the course of doing Xor a subtask of X, Y will always be completed. Use Case X extends Use Case Y:

Y performs a sub-task and X is a similar but morespecialized way of accomplishing that subtask (e.g.going to jail is a sub-task of Y; X provides an

alternate means of moving).X only happens in anexception situation. Y can complete without X everhappening.

In general, the extend relationship makes use casesdifficult to understand. It is suggested thatdevelopers use this relationship sparingly.


25/26

A misuse case is a use case from the point of

view of an actor hostile to the system; the

actor is a hacker deliberately threatening the

security of the system and/or the privacy of

the users of the system


26/26

Identify all the actors of the system.

Think about all the functionality that the actorswant from the system.

Consider what the various functions the actors

are asking have in common. Abstract these asinclude use cases.

Avoid the extend relationship because it canmake the use cases overly complex.

A picture is worth a thousand words. Use case

diagrams help to visualize what the system hasto do. But, more importantly, the use case flow-of-events gets much more specific about whatthe customer wants the variations and theexceptions.

pps - use case

Documents