EXPERIMENT NO.

2
A.1 AIM: - Modeling UML Use Case diagrams and capturing Use Case scenarios.
A.2 Prerequisite
1. Concepts of Actor, Use Case and Relationships
A.3 Outcome
After successful completion of this experiment students will be able to
Design solution using unified modeling language.

A.4 Theory
Use case diagrams
Use case diagrams belong to the category of behavioral 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 as an 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 :
 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 below figure:

Association between Actors and Use Cases

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
bycompose mail, reply, and forward email use cases. The relationship is shown in below
figure.

Extend Relationship
Use case extensions are used used to depict any variation to an existing use case. They are
used to 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
Instructionsstep is optional, and not a part of the main Place Order use case. Below figure
depicts such relationship.
 Place Order

<<extends>>

Shipping
Instruction

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.
A.5 Task:
For the problem statement, complete use case modelling in StarUML.
 PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: E019 Name: Nisarg Khodke

Class: E Batch: B1
Date of Experiment: Date of Submission:
Grade:
B.1 Actors and specification:
1. Factory Manager:
• Description: The Factory Manager is a primary user of
the system who oversees the operations of the incense
factory. They are responsible for managing vendors,
products, raw materials, and overseeing the generation
of bills.
• Specifications:
• Ability to add, edit, and delete vendor details.
• Ability to add, edit, and delete product details including
name, description, and price.
• Access to raw material tracking to monitor the usage of
materials in production.
• Generation of bills with calculated price, tax, and
relevant details.
• View reports and analytics related to inventory, sales,
and production.
2. Database:
• Description: The Database is not a human actor but
represents the data storage system that holds all the
information related to vendors, products, raw materials,
bills, and other relevant data for the inventory
management system.
• Specifications:
• Store and manage vendor details including contact
information, products supplied, and pricing agreements.
• Store and manage product details including name,
description, price, and inventory levels.
• Track raw material inventory and usage in production.
• Store bill details including items purchased, quantities,
prices, taxes, and total amounts.
• Ensure data security, integrity, and reliability to
maintain the accuracy of the information.

B.2 Use cases:

B.3 Use Case diagrams:

1. Enter Home:
o Description: This use case represents the action of entering the home page of
the inventory management website.
o Actors: Factory Manager
o Flow of Events:
1. The Factory Manager navigates to the website's URL.
2. The system displays the home page with options to access various
features.
2. View Inventory:
 o Description: This use case allows the Factory Manager to view the inventory of
products available in the factory.
o Actors: Factory Manager
o Flow of Events:
1. The Factory Manager selects the "View Inventory" option from the home
page.
2. The system retrieves and displays a list of available products with their
details.
3. View Raw Material:
o Description: This use case enables the Factory Manager to view the raw
materials available in the factory.
o Actors: Factory Manager
o Flow of Events:
1. The Factory Manager selects the "View Raw Material" option from the
home page.
2. The system retrieves and displays a list of raw materials with their
details.
4. View Aggarbatti:
o Description: This use case allows the Factory Manager to view details specific
to aggarbatti products.
o Actors: Factory Manager
o Flow of Events:
1. The Factory Manager selects the "View Aggarbatti" option from the
home page.
2. The system retrieves and displays a list of aggarbatti products with their
details.
5. Generate Bill Page:
o Description: This use case represents the action of navigating to the bill
generation page.
o Actors: Factory Manager
o Flow of Events:
1. The Factory Manager selects the "Generate Bill" option from the home
page.
2. The system navigates the user to the bill generation page.
6. Select Vendor:
o Description: This use case allows the Factory Manager to select a vendor for
creating a bill.
o Actors: Factory Manager
o Flow of Events:
1. The Factory Manager selects the "Select Vendor" option from the bill
generation page.
2. The system presents a list of available vendors for selection.
7. Generate Bill:
o Description: This use case represents the action of generating a bill for a
purchase.
o Actors: Factory Manager
o Flow of Events:
1. The Factory Manager selects items to be included in the bill.
2. The system calculates the total price, taxes, and generates the bill.
8. Print PDF:
o Description: This use case allows the Factory Manager to print the generated
bill as a PDF document.
o Actors: Factory Manager
o Flow of Events:
 1. The Factory Manager selects the "Print PDF" option after generating the
bill.
2. The system generates a PDF document of the bill for printing.
9. View Vendor:
o Description: This use case allows the Factory Manager to view a list of all
vendors.
o Actors: Factory Manager
o Flow of Events:
1. The Factory Manager selects the "View Vendor" option from the home
page.
2. The system retrieves and displays a list of all vendors with their details.
10. View a Particular Vendor:

 Description: This use case enables the Factory Manager to view the details of a
particular vendor.
 Actors: Factory Manager
 Flow of Events:
1. The Factory Manager selects a specific vendor from the list of vendors.
2. The system displays the details of the selected vendor.

11. Edit Vendor:

 Description: This use case allows the Factory Manager to edit the details of a vendor.
 Actors: Factory Manager
 Flow of Events:
1. The Factory Manager selects the "Edit" option next to a vendor's details.
2. The system allows the Factory Manager to modify the vendor's details and saves
the changes.
B.4 Conclusion
In conclusion, the use case diagram for a course recommendation system provides a
comprehensive overview of the interactions between the key actors, namely the User and
the System. The User, representing individuals seeking course recommendations, engages
with the System, an intelligent software application, to receive personalized suggestions
based on preferences and academic backgrounds. The diagram highlights crucial
functionalities such as input gathering, recommendation generation, and database
management within the System. This visual representation offers a clear and concise
understanding of the course recommendation process, facilitating effective communication
and collaboration among stakeholders involved in the development and use of the system.

B.5 Questions of Curiosity:

Q1. What does a use case diagram represent?

a. A set of actions
b. Time sequence of statements executed
c. How to use a particular module
d. Don’t know

Answer: a. A set of actions

A use case diagram represents a set of actions or interactions between actors (users or external systems)
and a system. It provides a high-level view of the functionalities or features that a system offers to its
users.

Q.2 Generalization relationship exists between two use cases when

a. A use case derives from a base use case.

b. A use case derives from a base use case and specializes some of its inherited
functionality.
c. A use case include functionality of some other use case.
d. No two use cases can be related.

Answer: b. A use case derives from a base use case and specializes some of its inherited
functionality.
In the context of use case diagrams, a generalization relationship exists between two use cases
when a use case (the specialized or derived use case) inherits some or all of the functionality of
another use case (the base use case) and may add or modify specific behaviors. This
relationship is often depicted with an arrow pointing from the specialized use case to the base
use case, indicating that the specialized use case is a more specific version of the base use
case.