Practical – 4

AIM: Prepare the user’s view analysis: Describe different scenarios and Draw Use case
diagrams using UML

• Objectives:
1. To write different scenarios of the system’s execution.
2. To explore various UML use case diagram components to draw USECASE diagram.

• Theory:
o A use case diagram is used to represent the dynamic behavior of a system. It
encapsulates the system's functionality by incorporating use cases, actors, and their
relationships. It models the tasks, services, and functions required by a
system/subsystem of an application. It depicts the high-level functionality of a system
and also tells how the user handles a system.
o Purpose of Use Case Diagrams
▪ The main purpose of a use case diagram is to portray the dynamic aspect of a
system. It accumulates the system's requirement, which includes both internal
as well as external influences. It invokes persons, use cases, and several things
that invoke the actors and elements accountable for the implementation of use
case diagrams. It represents how an entity from the external environment can
interact with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.
o In a use-case diagram, an actor is a user of the system (i.e. Something external to
the system; can be human or non-human) acting in a particular role.
o A use-case is a task which the actor needs to perform with the help of the system,
e.g., find details of a book or print a copy of a receipt in a bookshop.
o We can draw a box (with a label) around a set of use cases to denote the system
boundary, as on the previous slide (“library system”).

Inheritance can be used between actors to show that all use cases of one actor are
available to the other:
If several use cases include, as part of their functionality, another use case, we have a
special way to show this in a use-case diagram with an <<include>> relation.
If a use-case has two or more significantly different outcomes, we can show this by
extending the use case to a main use case and one or more subsidiary cases.

• Background / Preparation:
 How to draw a Use Case diagram?
It is essential to analyze the whole system before starting with drawing a use case diagram, and
then the system's functionalities are found. And once every single functionality is identified,
they are then transformed into the use cases to be used in the use case diagram.
After that, we will enlist the actors that will interact with the system. The actors are the person
or a thing that invokes the functionality of a system. It may be a system or a private entity, such
that it requires an entity to be pertinent to the functionalities of the system to which it is going
to interact.
Once both the actors and use cases are enlisted, the relation between the actor and use case/
system is inspected. It identifies the no of times an actor communicates with the system.
Basically, an actor can interact multiple times with a use case or system at a particular instance
of time.
Following are some rules that must be followed while drawing a use case diagram:
1. A pertinent and meaningful name should be assigned to the actor or a use case of a
system.
2. The communication of an actor with a use case must be defined in an understandable
way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of
interactions between the use case and actors.

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 interacting among the requirements are actors.

Scenarios
• Scenarios are real-life examples of how a system can be used.
• They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;

A description of the states when the scenario finishes.

• Tools / Material Needed:

o Hardware:
1. Development Workstations:
• CPU: Intel Core i5 or AMD Ryzen 5 (or higher)
• RAM: 8 GB (minimum), 16 GB (recommended)
 •Storage: 256 GB SSD (minimum), for fast access to development tools and files
• Network: Stable internet connection for accessing repositories and remote servers
2. Server Hardware:
• CPU: Multi-core processor (Intel Xeon or AMD EPYC)
• RAM: 16 GB to 32 GB (depending on user load)
• Storage: SSD or NVMe with 1 TB (to store application files and logs)
• Network: High-speed internet connection with redundancy options

o Software :
3. Development Tools:
• Integrated Development Environment (IDE): VS Code, JetBrains, or Sublime Text
• Version Control: Git and GitHub/GitLab/Bitbucket for managing source code
• Frontend Framework: React.js, Vue.js, or Angular
• Backend Framework: Node.js (Express), Django, or Ruby on Rails
• Database Management System (DBMS): MySQL, PostgreSQL, or MongoDB
• Testing Tools: Jest, Mocha, Selenium for automated testing
• Package Managers: npm (Node.js), pip (Python)
4. Production Environment:
• Web Server: Apache, Nginx, or Microsoft IIS
• Database Server: MySQL or PostgreSQL
• Operating System: Linux (Ubuntu, CentOS) or Windows Server for server hosting

• Procedure / Steps:
o Developing Use Cases:
o Step One – Define the set of actors that will be involved in the story
▪ Actors are people, devices, or other systems that use the system or product
within the context of the function and behavior that is to be described
▪ Actors are anything that communicate with the system or product and that are
external to the system itself
o Step Two – Develop use cases, where each one answers a set of questions
Actor: Student
Precondition: The student must be logged into the system.
Postcondition: The student successfully registers for an event and receives confirmation.

Main Flow:

1. Student accesses the "Upcoming Events" page.

2. The system displays a list of events.

3. The student selects an event from the list.

4. The system displays the event details, including the date, location, and registration
option.
 5. Student clicks on the "Register" button.

6. The system asks for confirmation.

7. Student confirms the registration.

8. The system stores the registration in the database and sends a notification.

9. Student receives a confirmation of successful registration.

Alternate Flow:

• Event Full:

1. If the event is fully booked, the system displays an error message.

2. The student is unable to register.

• Event Cancelled:

1. If the event is cancelled after registration, the system sends a notification to

the student.

2. The event is removed from the student's registered events list.

Use Case: Post an Event

Actor: Faculty
Precondition: The faculty member is logged in.
Postcondition: The event is posted successfully and becomes visible to students.

Main Flow:

1. Faculty accesses the "Post New Event" section.

2. The system prompts for event details (name, date, time, location, description).

3. Faculty enters the event details.

4. Faculty clicks "Submit" to post the event.

5. The system validates the input and checks for conflicts.

6. The event is saved to the database and listed under "Upcoming Events."

7. Students can now view and register for the event.

Alternate Flow:

• Incomplete Information:

1. If required details are missing, the system prompts the faculty to complete the
missing fields.

2. The process returns to step 3 once all fields are completed.

Use Case Scenario: Post and Answer a Question

Use Case: Participate in Q&A Session

Actor: Student
Precondition: The actor must be logged into the system.
Postcondition: The actor successfully posts a question or provides an answer, which
becomes visible to other users.

Main Flow (Posting a Question):

1. Actor accesses the "Q&A" section from the main dashboard.

2. The system displays a list of questions.

3. Actor clicks "Post New Question."

4. The system prompts the actor to enter a question title and description, along with
relevant tags (e.g., event-related or subject-specific).

5. Actor enters the required information and clicks "Submit."

6. The system validates the input and stores the question in the database.

7. The question is now visible to other users for answers.

Main Flow (Answering a Question):

1. Actor accesses the "Q&A" section and views the list of questions.

2. Actor selects a question to answer.

3. The system displays the question details along with any previous answers.

4. Actor clicks "Answer" and enters a response in the text field.

5. Actor submits the answer.

6. The system validates the input and stores the answer in the database.
Alternate Flow (Editing or Deleting an Answer):

1. Actor can view their previous answers under the question.

2. Actor clicks "Edit" to modify their answer or "Delete" to remove it.

3. The system updates the database accordingly and refreshes the Q&A display.

Main Flow (Voting on an Answer):

1. Actor views a question with multiple answers.

2. The system provides "Upvote" and "Downvote" buttons for each answer.

3. Actor clicks "Upvote" or "Downvote" based on the quality of the answer.

4. The system updates the answer's score and refreshes the display.
Quiz:

1. What is use case diagram?

A Use Case Diagram visually represents the interactions between actors (users or external
systems) and the system, showing the system's functionalities (use cases) from the user's
perspective.

2. List relationship used in use case.

• Association: Interaction between actors and use cases.
• Include: Mandatory inclusion of a use case within another.
• Extend: Optional extension of a use case under specific conditions.
• Generalization: Inheritance between actors or use cases.

3. What Tests Can Help Find Useful Use Cases?

• User Goal Test
• Essential Use Case Test
• System Boundary Test
• Real-World Scenario Test
• Stakeholder Test
Suggested Reference:

1) Use Case Diagrams.

2) Unified Modeling Language, Superstructure, V2.1.2.
Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem Problem Problem Problem

analysis analysis analysis analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& &
understanding understanding

Correct answer
to all questions

Signature of Faculty: