Prathmesh Gaikwad

TUS3F202128 C37

PART A

Experiment No.04

A.1 Aim:

Identify scenarios & develop UML Use case for the selected mini project

A.2 Prerequisite:
1. Preliminary requirements

2. Knowledge different process models

A.3 Outcome:
After successful completion of this experiment students will be able to

 Refine requirements from a set of preliminary requirements and able to identify actors and
possible use cases.
 Able to model requirements using UML

A.4 Theory:
Use case diagrams

Use case diagrams belong to the category of behavioural diagram of UML diagrams. Use case
diagrams aim to present a graphical overview of the functionality provided by the system. It
consists of a set of actions (referred to as use cases) that the concerned system can perform,
one or more actors, and dependencies among them.

Actor

An actor can be defined asan object or set of objects, external to the system, which interacts
with the system to get some meaningful work done. Actors could be human, devices, or even
other systems.

For example, consider the case where a customer withdraws cash from an ATM. Here,
customer is a human actor.

Actors can be classified as below:

Prathmesh Gaikwad
TUS3F202128 C37

 Primary actor: They are principal users of the system, who fulfill their goal by availing some
service from the system. For example, a customer uses an ATM to withdraw cash when he
needs it. A customer is the primary actor here.

 Supporting actor: They render some kind of service to the system. "Bank representatives",
who replenishes the stock of cash, is such an example. It may be noted that replenishing
stock of cash in an ATM is not the prime functionality of an ATM.

In a use case diagram primary actors are usually drawn on the top left side of the diagram.

Use Case

A use case is simply a functionality provided by a system.

Continuing with the example of the ATM, withdraw cash is a functionality that the ATM
provides. Therefore, this is a use case. Other possible use cases includes, check balance, change
PIN, and so on.

Use cases include both successful and unsuccessful scenarios of user interactions with the
system. For example, authentication of a customer by the ATM would fail if he enters wrong
PIN. In such case, an error message is displayed on the screen of the ATM.

Subject

Subject is simply the system under consideration. Use cases apply to a subject. For example, an
ATM is a subject, having multiple use cases, and multiple actors interact with it. However, one
should be careful of external systems interacting with the subject as actors.

Graphical Representation

An actor is represented by a stick figure and name of the actor is written below it. A use case is
depicted by an ellipse and name of the use case is written inside it. The subject is shown by
drawing a rectangle. Label for the system could be put inside it. Use cases are drawn inside the
rectangle, and actors are drawn outside the rectangle, as shown in fig.

Figure - 01: A use case diagram for a book store

Association between Actors and Use Cases

Prathmesh Gaikwad
TUS3F202128 C37

A use case is triggered by an actor. Actors and use cases are connected through binary
associations indicating that the two communicates through message passing.

An actor must be associated with at least one use case. Similarly, a given use case must be
associated with at least one actor. Association among the actors are usually not shown.
However, one can depict the class hierarchy among actors.

Use Case Relationships

Three types of relationships exist among use cases:

 Include relationship

 Extend relationship

 Use case generalization

Include Relationship

Include relationships are used to depict common behaviour that are shared by multiple use
cases. This could be considered analogous to writing functions in a program in order to avoid
repetition of writing the same code. Such a function would be called from different points
within the program.

Example

For example, consider an email application. A user can send a new mail, reply to an email he
has received, or forward an email. However, in each of these three cases, the user must be
logged in to perform those actions. Thus, we could have a login use case, which is included
by compose mail, reply, and forward email use cases. The relationship is shown in figure - 02.

Figure - 02: Include relationship between use cases

Notation

Include relationship is depicted by a dashed arrow with a «include» stereotype from the
including use case to the included use case.

Extend Relationship
Prathmesh Gaikwad
TUS3F202128 C37

Use case extensions are used used to depict any variation to an existing use case. They are used
to the specify the changes required when any assumption made by the existing use case
becomes false.

Example

Let's consider an online bookstore. The system allows an authenticated user to buy selected
book(s). While the order is being placed, the system also allows to specify any special shipping
instructions, for example, call the customer before delivery. This Shipping Instructions step is
optional, and not a part of the main Place Order use case. Figure - 03 depicts such relationship.

Figure - 03: Extend relationship between use cases

Notation

Extend relationship is depicted by a dashed arrow with a «extend» stereotype from the
extending use case to the extended use case.

Generalization Relationship

Generalization relationship are used to represent the inheritance between use cases. A derived
use case specializes some functionality it has already inherited from the base use case.

Example

To illustrate this, consider a graphical application that allows users to draw polygons. We could
have a use case draw polygon. Now, rectangle is a particular instance of polygon having four
sides at right angles to each other. So, the use case draw rectangle inherits the properties of
the use case draw polygon and overrides it's drawing method. This is an example of
generalization relationship. Similarly, a generalization relationship exists between draw
rectangle and draw square use cases. The relationship has been illustrated in figure - 04.
Prathmesh Gaikwad
TUS3F202128 C37

Figure - 04: Generalization relationship among use cases

Notation

Generalization relationship is depicted by a solid arrow from the specialized (derived) use case
to the more generalized (base) use case.

Identifying Actors

Given a problem statement, the actors could be identified by asking the following questions:

 Who gets most of the benefits from the system? (The answer would lead to the
identification of the primary actor)

 Who keeps the system working? (This will help to identify a list of potential users)

 What other software / hardware does the system interact with?

 Any interface (interaction) between the concerned system and any other system?

Identifying Use cases

Once the primary and secondary actors have been identified, we have to find out their goals
i.e. what are the functionality they can obtain from the system. Any use case name should start
with a verb like, "Check balance".

Guidelines for drawing Use Case diagrams

Following general guidelines could be kept in mind while trying to draw a use case diagram:

 Determine the system boundary

 Ensure that individual actors have well-defined purpose

 Use cases identified should let some meaningful work done by the actors
Prathmesh Gaikwad
TUS3F202128 C37

 Associate the actors and use cases -- there shouldn't be any actor or use case floating
without any connection

 Use include relationship to encapsulate common behaviour among use cases , if any

 Example: Library Management system

Prathmesh Gaikwad
TUS3F202128 C37

PART B
(PART B: TO BE COMPLETED BY STUDENTS)

Roll No: C37 Name: Prathmesh Krishna Gaikwad

Class: TE-C Batch: C2

Date of Experiment: 12/08/2022 Date of Submission: 12/08/2022

Grade:

B.1 Draw Use case Diagram for selected mini project

Prathmesh Gaikwad
TUS3F202128 C37

B.2 Conclusion:
Hence, we successfully learned & implement Use Case Diagram for our selected Mini-
Project of Vehicle Rental System.

B.3 Question of Curiosity

Q1: What do you mean by functional requirements? How to model functional requirements?
Ans: A Functional Requirement (FR) is a description of the service that the software must offer.
It describes a software system or its component. A function is nothing but inputs to the
software system, its behavior, and outputs. It can be a calculation, data manipulation, business
process, user interaction, or any other specific functionality which defines what function a
system is likely to perform. Functional Requirements in Software Engineering are also
called Functional Specification.

Functional Requirements of a system should include the following things:

1. Details of operations conducted in every screen

2. Data handling logic should be entered into the system
3. It should have descriptions of system reports or other outputs
4. Complete information about the workflows performed by the system
5. It should clearly define who will be allowed to create/modify/delete the data in the system.
6. How the system will fulfill applicable regulatory and compliance needs should be captured
in the functional document.

Q2: List of various elements of use case diagram and specify there graphical notation.
Ans: Use case diagram components:
Common components include:
1. Actors: The users that interact with a system. An actor can be a person, an organization, or
an outside system that interacts with your application or system. They must be external objects
that produce or consume data.
2. System: A specific sequence of actions and interactions between actors and the system. A
system may also be referred to as a scenario.
3. Goals: The end result of most use cases. A successful diagram should describe the activities
and variants used to reach the goal.
Prathmesh Gaikwad
TUS3F202128 C37

Use case diagram symbols and notation:

The notation for a use case diagram is pretty straightforward and doesn't involve as many types
of symbols as other UML diagrams. You can use this guide to learn how to draw a use case
diagram if you need a refresher. Here are all the shapes you will be able to find in Lucidchart:
1. Use cases: Horizontally shaped ovals that represent the different uses that a user might
have.
2. Actors: Stick figures that represent the people actually employing the use cases.
3. Associations: A line between actors and use cases. In complex diagrams, it is important to
know which actors are associated with which use cases.
4. System boundary boxes: A box that sets a system scope to use cases. All use cases outside
the box would be considered outside the scope of that system. For example, Psycho Killer is
outside the scope of occupations in the chainsaw example found below.
5. Packages: A UML shape that allows you to put different elements into groups. Just as with
component diagrams, these groupings are represented as file folders.
Prathmesh Gaikwad
TUS3F202128 C37

Q3: What are various types of relationships use in UML use case diagram? Explain.
Ans:
There can be 5 relationship types in a use case diagram.

 Association between actor and use case

 Generalization of an actor
 Extend between two use cases
 Include between two use cases
 Generalization of a use case
Let’s take a look at these relationships in detail.
Association Between Actor and Use Case
This one is straightforward and present in every use case diagram. Few things to note.

 An actor must be associated with at least one use case.

 An actor can be associated with multiple use cases.
 Multiple actors can be associated with a single use case.

Different ways association relationship appears in use case diagrams

Check out the use case diagram guidelines for other things to consider when adding an actor.

Generalization of an Actor: Generalization of an actor means that one actor can inherit the
role of the other actor. The descendant inherits all the use cases of the ancestor. The
descendant has one or more use cases that are specific to that role. Let’s expand the previous
use case diagram to show the generalization of an actor.
Prathmesh Gaikwad
TUS3F202128 C37

A generalized actor in an use case diagram

Extend Relationship Between Two Use Cases
Many people confuse the extend relationship in use cases. As the name implies it extends the
base use case and adds more functionality to the system. Here are a few things to consider
when using the <<extend>> relationship.

 The extending use case is dependent on the extended (base) use case. In the below
diagram the “Calculate Bonus” use case doesn’t make much sense without the “Deposit
Funds” use case.
 The extending use case is usually optional and can be triggered conditionally. In the
diagram, you can see that the extending use case is triggered only for deposits over
10,000 or when the age is over 55.
 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.
Lets expand our current example to show the <<extend>> relationship.
Prathmesh Gaikwad
TUS3F202128 C37

Extend relationship in use case diagrams

Although extending use case is optional most of the time it is not a must. An extending use
case can have non-optional behavior as well. This mostly happens when your modeling
complex behaviors.

For example, in an accounting system, one use case might be “Add Account Ledger Entry”. This
might have extending use cases “Add Tax Ledger Entry” and “Add Payment Ledger Entry”.
These are not optional but depend on the account ledger entry. Also, they have their own
specific behavior to be modeled as a separate use case.

Include Relationship Between Two Use Cases

Include relationship show that the behavior of the included use case is part of the including
(base) use case. The main reason for this is to reuse common actions across multiple use cases.
In some situations, this is done to simplify complex behaviors. Few things to consider when
using the <<include>> relationship.

 The base use case is incomplete without the included use case.
 The included use case is mandatory and not optional.
Lest expand our banking system use case diagram to show include relationships as well.
Prathmesh Gaikwad
TUS3F202128 C37

Includes is usually used to model common behavior

For some further reading regarding the difference between extend and include relationships
in use case diagrams check this StackOverflow link.

Generalization of a Use Case:

This is similar to the generalization of an actor. The behavior of the ancestor is inherited by the
descendant. This is used when there is common behavior between two use cases and also
specialized behavior specific to each use case.
For example, in the previous banking example, there might be a use case called “Pay Bills”. This
can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.
I hope you found this article about use case relationships helpful and useful. You can use
our diagramming tool to easily create use case diagrams online. As always if you have any
questions don’t hesitate to ask them in the comments section.

************************