1

Session

Use Case Model

Checklist

Introduction to Use Case Model

Explain Use Case Model notations

Construct Use Case Models for Case Study

2

Use Case Model

Use Case Model is used to capture the functional requirement of a system. Use Case Model

helps us to understand how system behaves with respect to user interaction. The users can be

people, devices or other systems. Use case model has three subdivisions

Figure 1: Use Case model subdivision

Use Case Diagram

Use Case diagram consist very small number of graphical notations to provide a high-level view

of relation between the system and the outside world. It is similar to a black box view of the

system.

3

Let us consider the use case diagram of a coffee vending machine represented below.

Figure 2: Use Case Diagram Coffee Vending Machine

Elements of Use Case Diagram

Six modeling elements make up the Use Case diagram: systems, actors, use cases, associations,

dependencies, and generalizations.

System

Sets the boundary of the system in relation to the actors who use it (outside the system) and

the features it must provide (inside the system). It provides an encapsulation to use cases and

the relationship between them. It is optional. Figure 3 shows two notations for representing a

system. In our example our system is Coffee Vending Machine.

4

Figure 3: System - Use Case Element

Actor

A role played by a person, system, or device

that has a stake in the successful operation

of the system. An external entity which

interacts with the system. Actors can be a

person or another system. In our example it

could be either a person or a Remote

control device.

Use Case

Use Case refers to a key feature of the system. Without

these features, the system will not fulfill the user/actor

requirements. Each Use Case expresses a goal that the

system must achieve.

Figure 5: Use Case - Use Case Element

Figure 4: Actor - Use Case Element

5

Association

Figure 6: Association - Use Case Element

A line connecting an actor to a Use Case represents an association, as shown in Figure 6.

The association represents the fact that the actor communicates with the Use Case. This

is the only relationship that exists between an actor and a Use Case.

You may specify a directionality arrow on either end of the association line to denote

the direction of the communication. Some associations are unidirectional (for example,

the actor specifies information to the Use Case). Most associations are bidirectional

(that is, the actor accesses the Use Case, and the Use Case provides functionality to the

actor). For bidirectional associations, you may either place an arrowhead on both ends

of the association line, or simply show no arrowheads at all.

Dependency

Dependencies identify the relationship between two Use Cases. There are three type of

dependency notation used.

I. <<include>> dependency

Figure 7: <<include>> dependency

6

In some cases one use case may require help from other use case to perform

functionality.

This relationship is realized by using dashed arrow from the use case which requires

help to the use case which provides help.

In our example Handle User Inputs requires the help from Make Coffee use case to

make coffee and service the user as shown in Figure 7.

II. <<extend>> dependency

Figure 8: <<extend>> dependency

The <<extend>> dependency says that one Use Case might need help from another Use

Case. In contrast, the <<include>> dependency says that one Use Case will always call

the other Use Case. Somewhere in the logic of the Use Case that needs the help is an

7

extension point, a condition test that determines whether or not the call should be

made. There is no such condition in an include dependency.

The other contrast between the two dependency stereotypes is the direction of the

dependency arrow. The <<include>> dependency arrow points from the main Use Case

(the one currently executing) to the one that it needs help from. The <<extend>>

dependency arrow points from the extension Use Case (the one providing the extra

help) to the main Use Case that it is helping (see Figure 8).

III. <<stereotype>> dependency

The stereotype notation is used throughout Unified Modeling Language. It is used to

denote additional information about role of each element. These are designer defined

and are used with respect to context of the project. Stereotypes are denoted inside

guillemets (<<classifier>>) and the name which designer uses is known as classifier.

Generalization

Inheritance in object oriented programming is

expressed as generalization in modeling. It is

represented by a line with a filled arrow.

Direction of arrow is from the inherited class to

the base class.

Figure 9: Generalization: Use Case Element

8

Constructing Use Case Diagram for our Case Study

Step 1: Identify the Actors

Customer is the only person in involved in our system. Since we are making an automation tool!...

Step 2: Identify the features

Look for the actions that our system requires to complete the process. We need critical inputs, critical outputs and rules for designing our system. Let us ask ourselves three questions

1. What does the system produce for the user [critical outputs]? Service Order; It provides the customer with the items he ordered

2. What does the actor help the system do [critical inputs]? Place Order; User has to select his item and quantity

3. What does the system help the actor(s) do [rules]? Process Order; User has to select valid items and should have paid for the items. Payment can be made by Cash or Credit Inventory; The items customer ordered must be in our stock

9

Step 3: Identify association

Customer can place an order and gets an invoice when the order is processed.

Step 4: Identify <<include>> dependencies

Place Order use case must always check with inventory to freeze the item Also when our customer has finished his selection he must be directed towards payment. So Place Order has <<include>> dependencies to Inventors and Process Order

Step 5: Identify <<extends>> dependencies

Service Order requires a confirmation from Process Order was successful to print the invoice to the customer

10

Step 6: Identify generalizations

Customer can pay for the order via Cash or Credit Card. Payment by credit card requires different set of action then by cash.

This is how our Order Processing Use Case diagram looks like:

Figure 10: Order Processing System Use Case Diagram

11

Use Case Narrative

Use Case Narrative provides a convenient view of the main feature of a system. It describes a

feature in a textual format. It is used to get a clear picture of the positive and negative cases. It

also stands as a base for drawing Activity diagram which I will cover next. However use case

narrative requires lot of effort and paper work which makes it difficult for a complex system.

Anyway UML provides with bunch of other diagrams to help you out.

Elements of Use Case Narrative

As with use case diagrams, use case narratives also have 6 elements. They don’t need a detail

explanation and these elements functionality is self explanatory. They are

Assumption

Pre-conditions

Use Case Initiation

Process or Dialog

Use Case termination

Post-conditions

Constructing Use Case Narrative for Order Processing System

Let us consider Process Order for writing the Use Case Narrative. I will explain each element as we

proceed with our Process Order use case.

Audit Fields

Audit fields are used as an informatory part about what the use case is about, who is

responsible for and when did the last change happens. Although this is simple I prefer version

control system to audit fields.

Table 1 Process Order Use Case Narrative: Audit Fields

Field Name

Field Description

Name Place Order

Author Sriee Gowthem Raaj

Last Revision Date 14th April 2015

12

Element 1: Assumption

Assumption helps when one use case precedes other use case. In our case Process Order use

case function begins when customer has placed a correct order.

Table 2 Process Order Use Case Narrative: Assumption

Field Name

Field Description

Assumption One customer has placed an order available in the inventory

Element 2: Pre-condition

The condition you will check and proceed with the use case. In our case customer should have

selected an item available in stock and specify the quantity for each item.

Table 3 Process Order Use Case Narrative: Pre-condition

Field Name

Field Description

Pre-condition Placed order item available in stock Specified quantity for each item

Element 3: Use Case Initiation

This element is used to describe how the use case is started. In other words “Who is responsible

for initiating the use case?” It could be actors, system or other use cases. In our case place

order use will trigger Process order.

Table 4 Process Order Use Case Narrative: Use Case Initiation

Field Name

Field Description

Use Case Initiation Place Order use case

Element 4: Process

Dialog between use cases, actor and use case are explained here. Success scenario is explained

first and then comes the failure cases. Failure cases are represented under Extension tab.

13

Table 5 Process Order Use Case Narrative: Process

Field Name

Field Description

Process: Main Success Scenario

1. Status of order is “Confirm Order” 2. Check for the mode of payment 3. If payment by cash

3.1 If denominations are correct and gross pay is paid 3.2 Status of order is “Order Processed”

4. If payment by credit 4.1 If customer name matches credit card name 4.2 If credit card expiry date exceeded two weeks the

current date 4.3 If credit limit is greater than gross pay for the order 4.4 Status of order is “Order Processed”

Process: Extension 1a: If status of order is not “Confirm Order” .1: Status of order is “Error”

4.1a: If customer does not match credit card name .1: Status of order is “Error in Credit Card Name”

4.2a: If credit card expiry date did not match the time period .1: Status of order is “Error in Credit Card Expiry Date”

4.3a: If credit limit is low .1: Status of order is “Error in Credit limit”

This is not a comprehensive list of the entire dialog that happens in a use case but this helps to

identify missing logics. We can also list possibilities of time-out while payment is going on, pin

error, network error etc. you get the idea. Process is the main element in our use case

narrative. Using the dialogs we could draw activity diagrams. This step helps us to identify if

there are any gaps in gathering requirements too.

14

Element 5: Use Case – Termination

Scenarios where the use case could end are described here. There might be many but I am

listing only a handful of them.

Table 6 Process Order Use Case Narrative: Use Case Termination

Field Name

Field Description

Use Case Termination Customer may cancel the order Cash is less than Gross pay Customer credit card name is different Customer credit card expiry date does not exceed two weeks from current date Credit limit is low Payment Gateway is timed out Error in network connectivity while paying

Element 6: Post-condition

Steps should be taken after the use case has finished its functionality. “What should I do next?”

In our case state of the order should be updated properly so that other use cases like place

order or service order could work on them. Outcomes can be categorized as normal

termination or cancelled termination for further clarity.

Table 7 Process Order Use Case Narrative: Post Condition

Field Name

Field Description

Post Condition Normal Termination: Status of order is saved

Cancelled Termination: Status of order changed to “Error” Status of order changed to “Error in Credit Card Name” Status of order changed to “Error in Credit Card Expiry Date” Status of order changed to “Error in Credit limit”

Your final use case narrative will look like the below table

15

Table 8 Place Order Use Case Narrative

Field Name

Field Description

Name Place Order

Author Sriee Gowthem Raaj

Last Revision Date 14th April 2015

Assumption

One customer has placed an order available in the inventory

Pre-condition

Placed order item available in stock Specified quantity for each item

Use Case Initiation

Place Order use case

Process: Main Success Scenario

1. Status of order is “Confirm Order” 2. Check for the mode of payment 3. If payment by cash

3.3 If denominations are correct and gross pay is paid

3.4 Status of order is “Order Processed” 4. If payment by credit

4.5 If customer name matches credit card name 4.6 If credit card expiry date exceeded two

weeks the current date 4.7 If credit limit is greater than gross pay for the

order 4.8 Status of order is “Order Processed”

Process: Extension

1a: If status of order is not “Confirm Order”

.1: Status of order is “Error”

4.1a: If customer does not match credit card name

.1: Status of order is “Error in Credit Card Name”

16

4.2a: If credit card expiry date did not match the time period

.1: Status of order is “Error in Credit Card Expiry Date”

4.3a: If credit limit is low

.1: Status of order is “Error in Credit limit”

Use Case Termination

Customer may cancel the order

Cash is less than Gross pay

Customer credit card name is different

Customer credit card expiry date does not exceed two weeks from current date

Credit limit is low

Payment Gateway is timed out

Error in network connectivity while paying

Post Condition

Normal Termination: Status of order is saved

Cancelled Termination:

Status of order changed to “Error”

Status of order changed to “Error in Credit Card Name”

Status of order changed to “Error in Credit Card Expiry Date”

Status of order changed to “Error in Credit limit”

17

Use Case Scenario

Scenario refers to sequence of steps describing the interaction between user and a system. Let

us consider a coffee machine for our example.

User can select their type of coffee and the coffee machine servers them a hot cup of

coffee with the use selected flavor.

This scenario is termed as success scenario where the user goal is achieved. In our case user got

the coffee with his selected flavor. But there are other possible scenarios; May be machine did

not serve coffee because of an empty water tank. These are known as extensions to the main

scenario. Use case scenarios are realized using Activity diagrams. Activity diagrams are similar

to flowchart but activity diagram have some extensions.

Elements of Use Case Scenario

Elements of use case scenario can be explained with the following categories.

Basic Functions

Partition

Pins and Tranformation

Signals

Decomposing the action

Basic Functions

There are certain fundamental elements which are used to build activity diagram. Figure 11

shows an activity diagram for a user using coffee machine to get coffee.

18

Figure 11 Coffee Machine Activity Diagram

19

Initial Node Starting place of activity diagram

Activity Refers to particular action. Each activity has series of actions to perform to satisfy the goal of a use case scenario.

Fork Concurrency is represented in activity diagram using fork. With fork parallel actions can take place. In our case coffee machine displays text to the user while it is preparing coffee.

Join Outgoing flow is converged with join. Outgoing flow is taken only when all the incoming flow has arrived at the join.

Decision Conditional behavior is delineated by branches. A branch can have a single incoming flow and several outgoing flow. A decision is based on [guard] condition. Each time you reach a decision you can take the outbound flow based on your [guard] condition. In our case, if the customer wants a printed receipt for his coffee the outbound flow goes through Print receipt action.

Activity Final Notation which represents that final state of the activity has been reached.

Partition

Activity diagram tells you what happens, but they donot tell you who does what. It does not

tell which class or business unit is responsible for a series of actions. If you want to show that

we can use partitions as shown in Figure 12. Partitions are also known as swim lines.

In our coffee vending machine example there are two partitions – Order fullfillment and

Acknowledge Customer. Order fullfillment is focused on processing the customer order which

in our case is preparing coffee. Acknowledge customer is responsible for the system to interact

with its user. For example Display Order will display text “Coffee is being prepared!..” which

gives an acknowledgement to the user. You can also take series of action and divide them the

rows and columns hierarchically.

20

Figure 12 Coffee Machine Partition

21

Decomposing an action

When you want to include several sub modules that have separate set of actions, it can be

made possible using fork like icon represented in Make Coffee action.

Pins and Transformation

Pins are used to represent parameter that is being exchanged from one activity to the other.

Pins are represented with small boxes in an activity.

Transformation is used to represent any change in the parameter count from one activity to the

other.

Signals

Signals are similar to interrupts; whenever interrupts arrive at signal activity they perform their

functionality. There are three notations used for representing signals, they are send signal,

receive signal and timer signal.

Send Signal – Activity which is listening to event changes in the system. In our example Send

[Water/Tank/Milk] Tank Status are send signal activities which send the tank status to Tank

Manager.

Receive Signal – Activity which receives the signals are represented by receive signal notation.

In our example Tank Manager is the receive signal which receives the tank status.

Timer signal – Timer signals wait for external event from outside process to get triggered. If the

customer is fine with waiting for his coffee he has to “Wait till the tank is filled”.

Decomposing an action, pins, transformation and signals are realized in Figure 13.

22

Figure 13 Make Coffee Sub-activity

Constructing Activity for Order Processing System

I am not going in detail on how to construct activity diagram step by step. Activity diagram for

Order Processing system can be constructed using our Use Case scenario: Process element

[Table 5].

23

Review

Use Case Model captures functional requirements of a system

Use Case model consists of three primary resources: Use Case

Diagram, Use case Narrative and Activity Diagram

Use Case Diagram provides a high level interaction between

system and user

Elements of Use Case diagram: System, Actor, Use Case, Association,

Dependency and Generalization

Use Case Narrative views the functionality in textual format.

Elements of Use Case Narrative: Assumption, Pre-conditions,

Use Case Initiation, Process or Dialog, Use Case termination and

Post-conditions

Use Case Scenario deals with sequence of steps describing

interaction between system and user.

Elements of use case scenario Activity, Start Flow, End Flow,

Decision, Fork, Join, Guard condition, Partition, Pins, Transformation,

Signals and sub activity