The document explains the use case model, which captures the functional requirements of a system through use case diagrams, narratives, and activity diagrams. It details the elements involved, such as actors, use cases, dependencies, and generalizations, while providing a structured approach to constructing a use case model, exemplified by a coffee vending machine case study. Additionally, it discusses the construction of use case narratives and activity diagrams to illustrate user interactions with the system.

1. 1
Session
Use Case Model
Checklist
 Introduction to Use Case Model
 Explain Use Case Model notations
 Construct Use Case Models for Case
Study

2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 18
Figure 11 Coffee Machine Activity Diagram

19. 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. 20
Figure 12 Coffee Machine Partition

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