Tutorial Material

BISM7255
Business Information Systems Analysis
and Design
















Tutorial 1 –
Use Case Diagrams

BISM 7255 -- Business Information Systems Analysis and Design Page 1
Knowledge Sheet for Use Case Diagrams

1 Definition
Use Case Diagrams capture use cases and relationships among actors and the system;
they describes the functional requirements of the system, the manner in which external
operators interact at the system boundary, and the response of the system.

(Source: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case-
diagram/)

2 Model Notations
2.1 System (System Boundary)
System can be understood as the context of the use case in which the use cases of
specific actions are executed. System can be a class or a component which represents
the entire application. The system is represented by one or more system frames (system
boundaries), shown as a rectangle with its name and a set of Use Cases visually located
inside this rectangle.


Figure 1 Example of System Boundary
(Source: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case-
diagram/)
2.2 Actor
An Actor is defined as a role outside of the corresponding use case system, and which
interacts with the system within the context of the use case.

The Actor represents roles, which may include human users who use the system,
machines, external hardware, other systems or subsystems that access the system. For
example, the role “Customer” represents any person being a customer of the bank.

Figure 2 shows two different notations of an actor. An actor is usually drawn as a named
stick figure, or alternatively as a class rectangle with the «actor» keyword.
BISM 7255 -- Business Information Systems Analysis and Design Page 2

Figure 2 Example of an Actor
Generalization: A generalization is a taxonomic relationship between a more general
classifier and a more specific classifier. The specific classifier (e.g., actor) inherits the
features of the more general classifier (e.g., super actor).

Actors can generalize other actors as shown in Figure 3.


Figure 3 Example of an Actor and a Specialized Actor
(Source:
https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case-diagram/
https://sparxsystems.com/resources/tutorials/uml2/use-case-diagram.html)
2.3 Use Case
A Use Case is a UML modeling element that describes how a user of the proposed
system interacts with the system to perform a discrete unit of work.

A use case is illustrated as an ellipse containing the name of the use case. The name of
the use case is typically formed by a verb and noun(s) whereby the object to be
manipulated and the activity to be carried out are described in a clear and concise
manner.

Figure 4 Example of a Use Case
(Source: https://sparxsystems.com/resources/user-guides/15.0/model-domains/uml-models.pdf
https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case-diagram/
https://www.sparxsystems.com/resources/tutorials/uml2/use-case-diagram.html )
BISM 7255 -- Business Information Systems Analysis and Design Page 3
2.4 Use Case Relationships
Use cases can also be reliant on one another. There are two types of relationships
between different use cases – “Include” relationship and “Extend” relationship.

2.4.1 Include Relationship
An “Include” relationship reflects that one Use Case includes the behavior of another.
It represents a compulsory relationship and is therefore often referred to as “must-
relationship”. Use cases may contain the functionality of another use case as part of
their normal processing. It is assumed that any included use cases will be called every
time the basic path is run.

An “Include” relationship is illustrated by a dashed arrow with open point in the
direction of the use case to be included. The key word <> is noted for the
arrow. An actor must NOT necessarily be linked to the included use case.

An example of this is to have the execution of the included use case Language> to be run as part of an including use case , as shown in
Figure 5.


Figure 4 Example of a Include Relationship
(Source: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case-
diagram/)

2.4.2 Extend Relationship
An “Extend” relationship specifies that the behavior of a Use Case may be extended by
the behavior of another (usually supplementary) Use Case; this is typically used in
exceptional circumstances. An “Extend” relationship is indicated by connecting the use
cases with a dashed arrow pointing from an extending Use Case towards the extended
Use Case, at a specific point in the behavior flow identified within the element by an
extension point. The arrow is labeled with the «extend» stereotype.

Condition (mandatory): A use case is extended by another under a specific condition.
The condition of the “Extend” is shown in a Note symbol attached to the corresponding
arrow. Note that the condition MUST be specified in an <> relationship.

Extension point (optional): The extension point is represented by a text string and
shown in a Note symbol attached to the corresponding arrow, such as ‘on startup’ or
‘before connection is established’.

BISM 7255 -- Business Information Systems Analysis and Design Page 4

Figure 6 Example of an Extend Relationship
(Source:
https://www.sparxsystems.com/resources/tutorials/uml2/use-case-diagram.html
https://sparxsystems.com/resources/user-guides/15.0/model-domains/uml-models.pdf
https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case-diagram/)

3 Model Creation Procedure
1) Identify actors, use cases, and relationships from a given business scenario.

2) Create a new project in Enterprise Architect.

3) Model the use case diagram in Enterprise Architect.
• Create Actors (role of users) of the system.
• Create use cases for each functional requirement identified.
• Structure the use cases. Determine the relationships between Actors and Use
Cases.
• Determine any “Extend” and “Include” relationships.

4 Example of Use Case Diagram
A customer wishes to withdraw money from an automatic teller with a bank card. The
actor named customer plays this role and is the generalization for the own bank
customer and third-party bank customer. The specialized actors communicate via the
role of the customer with the identify card use case which proceeds equally for both
types of customer. This use case contains the use case validate account and PIN,
whereby the right of the customer to use the card is assessed. If an incorrect PIN has
been repeatedly entered, the card is withdrawn. To model this, the use case identify
card is extended by the use case impound card. This is executed only under the
condition that the customer repeatedly entered the incorrect PIN.

Both actors, own bank customers and third-party bank customers, communicate
directly (and not via the role of customer) with the use case pay cash. This procedure
varies between these two types of customer; i.e. the highest withdrawal amount and/or
fees per transaction can vary.

BISM 7255 -- Business Information Systems Analysis and Design Page 5
5 Modeling of the Example Step by Step
Step Action
1 Identify actors, use cases and relationships from the case description.
2 Create a new project and a use case diagram in EA:
1) Start Enterprise Architect.
2) Click on the icon in the upper-left corner, and click on the
‘New Project’ option.
3) Locate a suitable folder (H: drive) for your project, and give a
distinctive name in the ‘File name’ field.
4) Click on the icon in the Browser window toolbar. When the
Model Wizard window displays, you click on the ‘Diagram’ tab.
5) In the left hand column header, select ‘UML Behavioral’ and scroll
down to ‘Use Case Diagrams’.
6) Select ‘Use Case’ à Tick ‘Create Package’ à Click on the ‘Create
Diagram’ button.
3 Model Actors, System Boundary, Use Cases and the relationships among
the Use Cases based on the example case description.
Note: For detailed steps of creating a Use Case Diagram, please find the video in
Blackboard ‘Tutorial 1 – Use Case Diagram Example Video’.
6 Final Example Model

Figure 7 Example Model
BISM 7255 -- Business Information Systems Analysis and Design Page 6
7 Tips and Tricks
• A use case captures a functionality of the system, for example, “Place Order”
indicates that the actor uses the system to place order(s). Note that “Eat Food” is
NOT a use case because it is not a function of the system.
• The use case must be named in ‘verb–noun’ form. For the name of any actors and
use cases, the first letter of each word should be capitalised, e.g., Place Order.
• A use case can be used by more than one actors.
• The actor represents roles, this means that it cannot be a person’s name.
• The automation boundary is compulsory as well as its name. The first letter of each
word in the system name must be capitalized.
• In an “Extend” relationship, the condition MUST be specified in a Note symbol
attached to the arrow.
• No order of appearance of described activities/services is shown.

8 In-Class Exercises
1) The Healthy Life Clinic, a provider of medical check-ups for Australia visa
applicants, is automating their patient information system. The would-be system is
expected to improve the Clinic’s service to customers. The business processes to be
captured by the system are as follows. It is your task to create a Use Case diagram
to document these functions.

Patients are entered into the system by the front desk personnel. For first-time
patients, the front desk personnel will collect and enter insurance and basic
demographic information. For the regular patients, the front desk personnel will
verify if the patients’ information is correct and update it if a change is required.
The front desk staff then ensures that the patient has a chart in the electronic medical
record system; and if not, a new medical record is created. The patient is then
entered into a queue by the front desk staff to wait for a nurse who will collect a
health story, weight, height, temperature, blood pressure, and any other relevant
medical information, then update the patient’s medical record. Next, the patient is
placed into the queue by the nurse to see a doctor. The first available doctor sees
the patient, does the required medical check-up and update patient details if need it,
and sends the patient to the checkout. The person at the checkout counter collects
and records the payment for the services and provides a printed receipt for the
service provided.

2) When a customer places a delivery order, a restaurant employee records the order
in the system. The employee captures details such as customer name, address,
phone number, and items ordered. After the order is recorded the customer can track
its status. The employee needs to send the order information to different people with
the option to print them. The order information is sent to the kitchen and the status
is updated when the order is ready for delivery. When the order is prepared, the
delivery person updates the status, delivers the order to the customer and collects
payment. Upon arriving at the restaurant, the delivery person updates the order
status and gives the payment to the restaurant manager. Each evening the restaurant
manager reconciles the order tickets with the delivery payments. Then, he/she uses
the data to update the goods sold and inventory files.
BISM 7255 -- Business Information Systems Analysis and Design Page 7
3) Customers place orders to the nursery by call. A sales representative takes the order,
verifies the customer’s credit standing, determines whether the items are in stock,
informs the customer if any special discounts are in effect, and communicates the
total payment due. If the customer meets the credit requirement and he/she is
satisfied with the availability of the item(s) and discounts, the order is entered into
the system. If the customer is first-time customer, a new customer account is
created. If a regular customer, the customer’s account is then updated, product
inventory is adjusted, and ordered items are pulled from stock. If the items are not
in stock, the salesperson updates sale item as on back order. Ordered items are then
packed and shipped to the customer. Once a month, a billing statement is generated
and sent to the customer. The customer has thirty days to remit the payment in full;
otherwise, a 15% penalty is applied to the customer’s account.

9 References
1) https://www.sparxsystems.com/resources/tutorials/uml2/use-case-diagram.html
2) https://sparxsystems.com/resources/user-guides/15.0/model-domains/uml-
models.pdf
3) https://www.sparxsystems.eu/resources/project-development-with-uml-and-
ea/use-case-diagram/
4) https://www.omg.org/spec/UML/2.5.1/PDF