LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Lab 03

Introduction to UML
(Use Case Diagram)

SE4th FICT BUITEMS

AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

LAB No 3__________________________________________________13/04/2023

1 Objectives:

After completing this lab, Students will be able to;

 Introduction to use case diagram.
 Introduction to visual modeling using UML.
 Perform user view and behavior analysis using Use case diagram.
 Analyze user requirements.
 Prepare Use Case Diagrams by using StarUML
 Visual modeling.
 Use Case Diagram: discovering actors and use cases.

2 Corresponding CLO and PLO:

 CLO 1, PLO 3
3 Theory:
Introduction:
To model a system the most important aspect is to capture the dynamic behavior. To clarify a
bit in detail, dynamic behavior means the behavior of the system when it is running /operating. In
UML there are five diagrams available to model dynamic nature and the use case diagram is one of
them. The use case diagram is dynamic in nature there should be some internal or external factors for
making the interaction.
These internal and external agents are known as actors. So, use case diagrams are consists of
actors, use cases and their relationships. The diagram is used to model the system/subsystem of an
application. A single use case diagram captures a particular functionality of a system.
These diagrams are used at a very high level of design. Then this high-level design is refined
again and again to get a complete and practical picture of the system.

Definition:
A use case diagram at its simplest is a representation of a user's interaction with the system
and depicting the specifications of a use case. A use case diagram can portray the different types of
users of a system and the various ways that they interact with the system.
Use case diagrams specify the events of a system and their flows. But use case diagram never
describes how they are implemented. Use case diagram can be imagined as a black box where only
the input, output and the function of the black box is known.

Purpose:
The purpose of use case diagram is to capture the dynamic aspect of a system. Use case
diagrams are used to gather the requirements of a system including internal and external influences.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

These requirements are mostly design requirements. So, when a system is analyzed to gather its
functionalities use cases are prepared and actors are identified.

The purposes of use case diagrams can be as follows:

 Used to gather requirements of a system.
 Used to get an outside view of a system.
 Identify external and internal factors influencing the system.
 Show the interaction among the use cases(function) and actors(entities).

Use Case Diagram components:

Use cases:

A use case describes a function/action that a system performs to achieve the user’s goal. A use case
must yield an observable result that is of value to the user of the system.

Use cases contain detailed information about the system, the system’s users, relationships between the
system and the users, and the required behavior of the system. Use cases do not describe the details of
how the system is implemented.

Each use case describes a particular goal for the user and how the user interacts with the system to
achieve that goal. The use case describes all possible ways that the system can achieve, or fail to
achieve, the goal of the user.

You can use use cases for the following purposes:

 Determine the requirements of the system

 Describe what the system should do

 Provide a basis for testing to ensure that the system works as intended

Actor:
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

An actor represents a role of a user that interacts with the system that you are modelling. The user can
be a human, an organization, a machine, or another external system.
You can represent multiple users with a single actor and a single user can have the role of multiple
actors. Actors are external to the system. They can initiate the behavior described in the use case or be
acted upon by the use case.
Actors are classified into two types:
Primary Actor:
Actor that stimulates the system and the initiator of the events.
Secondary actor:
Actor that only receive stimuli from systems.
Note that actor represents a role that a user can play but not a specific user. So, in a hospital
information system, you may have doctor and patient as actors but not Dr. John, Mrs. Brown as
actors.
System boundary:
A system boundary is a rectangle that you can draw in a use-case diagram to separate the use cases
that are internal to a system from the actors that are external to the system. A system boundary is
an optional visual aid in the diagram; it does not add semantic value to the model.

Association Relationship:
In UML models, an association is a relationship between two classifiers, such as classes or use cases,
that describes the reasons for the relationship and the rules that govern the relationship.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Generalization:
A generalization relationship is used to represent inheritance relationship between model elements of
same type. 
In UML modeling, a generalization relationship is a relationship in which one model element (the child)
is based on another model element (the parent). Generalization relationships are used in class,
component, deployment, and use-case diagrams to indicate that the child receives all of the attributes,
operations, and relationships that are defined in the parent.
For example, suppose the ATM system can be used to pay bills. Pay bills has two child use cases; Pay
Credit card bill and Pay utility bill. The children of the same use cases(parent) has all the attributes of
parent plus their own.

Include relationship:
In UML modeling, an include relationship is a relationship in which one use case (the base use case)
includes the functionality of another use case (the inclusion use case). The include relationship
supports the reuse of functionality in a use-case model.
 The base use case is incomplete without the included use case.
 The included use case is mandatory and not optional.
For example: Customer Authentication use case is required for every ATM transaction, so we show it
as include relationship
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Extend relationship:
In UML modeling, you can use an extend relationship to specify that one use case (extension) extends
the behavior of another use case (base). This type of relationship reveals details about a system or
application that are typically hidden in a use case.

 The extending use case is dependent on the extended (base) use case.
 The extending use case is usually optional and can be triggered conditionally.
 The extended (base) use case must be meaningful on its own. This means it should be
independent and must not rely on the behavior of the extending use case.

For example, In the ATM Transaction use case is extended via extension point  by the ATM Help use
case 

4 Equipment’s:
StarUML:
StarUML is an open-source software modelling tool that supports the UML (Unified Modelling
Language) framework for system and software modelling. It is based on UML provides eleven
different types of diagram and notation.
5 Procedure:
Use case diagrams are considered for high level requirement analysis of a system. So when the
requirements of a system are analyzed the functionalities are captured in use cases.
The uses cases are nothing, but it is the system functionalities written in an organized manner.
The second thing which are relevant to the use cases are the actors. Actors can be defined as
something that interacts with the system. The actors can be human user, some internal applications or
may be some external applications.
The use case diagram should have the following items identified.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

 Functionalities to be represented as a use case

 Actors
 Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. So, after identifying the
above items follow the following guidelines to draw an efficient use case diagram.
 The name of a use case is very important. So, the name should be chosen in such a way so that it
can identify the functionalities performed.
 Give a suitable name for actors.
 Show relationships and dependencies clearly in the diagram.
 Do not try to include all types of relationships. Because the main purpose of the diagram is to
identify requirements.
 Use note whenever required to clarify some important points.

Although the use cases are not a good candidate for forward and reverse engineering but still,
they are used in a slightly different way to make forward and reverse engineering.
6 Observations:
[ Please write your observation after conducting this lab, you have to write in few lines, what
did you learn in this lab ]

7 Lab Tasks/Assignment:

Task 1:
Design a Use Case Diagram for Banking App to specify system requirement.
Define actor of the System and their related use cases, create relationship among them
using Association, Extend, include and generalization.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Task 2:
Design a Use Case Diagram for Hotel Management System to specify system
requirement. Define actor of the System and their related use cases, create relationship
among them using Association, Extend, include and generalization.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Task 3:
Design a Use Case Diagram for your system. Identify actor of the System and
their related use cases, create relationship among them using Association, Extend,
include and generalization.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE