Use Case Diagrams: Examples

A Use Case Diagram is a visual representation of the interactions between users (actors) and a
system to achieve specific goals or tasks (use cases). It helps to identify the functionality
provided by the system from the perspective of users.

Sure! Below is an explanation of a Use Case Template composed of six fields:

Use Case Template (6 Fields)

This template is commonly used in software design to provide a detailed description of a use
case. It helps define the steps and conditions necessary for the use case to operate effectively.
The six fields in the template are:

1. Use Case Name

2. Participating Actors
3. Flow of Events
4. Entry Conditions
5. Exit Conditions
6. Quality Requirements

1. Use Case Name

The Use Case Name provides a brief description of the specific task or functionality being
described. It should be descriptive enough to convey the purpose of the use case, typically in
terms of what the user or actor will achieve.

Example:

 Use Case Name: Register a New User

2. Participating Actors

Actors are the entities (people, systems, or external devices) that interact with the system. Each
actor performs a role in achieving the goal of the use case.

 Primary Actors: The main entities that interact directly with the system to achieve the
goal.
 Secondary Actors: Supporting entities that assist the primary actor in completing the
task, or are involved in the background processing.

Example:
  Primary Actor: New User (who wishes to register for the system)
 Secondary Actor: System (the underlying system that processes the registration)

3. Flow of Events

The Flow of Events outlines the steps that occur in the use case, describing the sequence of
actions taken by the actor(s) and the system. It typically includes:

 Basic Flow: The standard, successful sequence of events.

 Alternative Flow: Alternative sequences for situations where things deviate from the
norm (e.g., invalid input or system errors).
 Exception Flow: The steps that occur if there is an error or failure in the system.

Example:

 Basic Flow:
1. The user navigates to the "Register" page.
2. The user enters their personal details (name, email, password).
3. The system validates the input data.
4. The system stores the new user information in the database.
5. The system sends a confirmation email to the user.
6. The user clicks on the verification link in the email.
7. The system activates the user account.
 Alternative Flow: 3.1. If the email address is already registered, the system displays an
error message and prompts the user to enter a different email.

4. Entry Conditions

Entry Conditions describe the state of the system before the use case begins. These are the
conditions that must be met or assumptions that must be true for the use case to be executed.

Example:

 The user is not already registered in the system.

 The user has internet access to fill out the registration form.

5. Exit Conditions

Exit Conditions describe the state of the system after the use case has been completed. These
conditions indicate what happens once the use case is finished successfully or unsuccessfully.
Example:

 The user account is successfully created and activated.

 The user is redirected to the login page to enter their credentials.
 If registration failed (e.g., email is already used), the user is notified of the error.

6. Quality Requirements

Quality Requirements (also known as Non-Functional Requirements) specify the

performance standards and conditions under which the system must operate. These include
aspects such as response time, security, availability, scalability, and usability. Quality
requirements ensure the system meets user expectations and performs reliably under various
conditions.

Example:

 Performance: The system should complete the registration process within 5 seconds.
 Usability: The registration page should be intuitive and easy to navigate.
 Security: All passwords must be stored securely using encryption.
 Availability: The system must be available 99.9% of the time for registration.

Complete Use Case Example:

1. Use Case Name:

Register a New User

2. Participating Actors:

 Primary Actor: New User (who wants to create a new account)

 Secondary Actor: System (the software that processes the registration)

3. Flow of Events:

 Basic Flow:
1. The user navigates to the "Register" page.
2. The user enters their personal details (name, email, password, etc.).
3. The system validates the input data (e.g., email format, password strength).
4. The system stores the new user information in the database.
5. The system sends a confirmation email to the user.
6. The user clicks on the verification link in the email.
7. The system activates the user account.
  Alternative Flow: 3.1. If the email address is already registered, the system displays an
error message and asks the user to enter a different email.
 Exception Flow: 3.2. If the system fails to store the user information in the database due
to a server error, the user is shown an error message and asked to try again later.

4. Entry Conditions:

 The user is not already registered in the system.

 The user has a valid email address and internet access.

5. Exit Conditions:

 The new user account is created and activated.

 The user is redirected to the login page to log in to their account.
 If there is a failure, the user is notified about the issue (e.g., "Email already in use").

6. Quality Requirements:

 Performance: The registration process must complete in under 5 seconds.

 Usability: The registration form should be user-friendly, with clear instructions and error
messages.
 Security: Passwords must be encrypted in the database.
 Availability: The registration page should be available 99.9% of the time, ensuring users
can register without issues.

Conclusion

The Use Case Template with the six fields helps provide a structured and detailed approach to
documenting use cases, ensuring that all necessary conditions, flows, and requirements are
captured. By defining entry and exit conditions along with clear quality requirements, the system
can ensure that the use case is properly implemented and meets both functional and non-
functional expectations.
Here are a few examples of use case diagrams for different systems and scenarios:

1. Online Shopping System

In an online shopping system, the actors are Customer, Admin, and the system itself. The use
cases represent tasks like browsing items, adding items to the cart, placing orders, etc.

Actors:

 Customer: A person who browses and buys items.

 Admin: A person responsible for managing the inventory and handling customer orders.
 System: The underlying software that manages the interactions.

Use Cases:

 Browse products
 Add products to cart
 Make a payment
 Place an order
 View order history
 Manage inventory (admin)
 View orders (admin)
 Handle customer queries (admin)

Use Case Diagram:

+-------------------------+
| Online Shopping System |
+-------------------------+
^
|
+-------------------+
| Customer |
+-------------------+
/ | \
[Browse] [Add to Cart] [Place Order]
\ | /
+---------------------------+
| System |
+---------------------------+
+-------------------+
| Admin |
+-------------------+
/ | \
[Manage Inventory] [View Orders] [Handle Queries]
2. Library Management System

In a library management system, the actors could be a Librarian, Member (User), and the
System. The use cases represent actions such as borrowing books, managing book inventory, and
viewing borrowed items.

Actors:

 Librarian: Manages books, registers users, and handles returns.

 Member: A library member who borrows and returns books.
 System: The software that runs the operations.

Use Cases:

 Register a member (librarian)

 Borrow a book (member)
 Return a book (member)
 Search for a book (member)
 Add/Remove books (librarian)
 Issue a fine (librarian)
 View borrowed books (member)

Use Case Diagram:

+----------------------------+
| Library Management System |
+----------------------------+
^
|
+-------------------+
| Librarian |
+-------------------+
/ | \
[Register Member] [Add/Remove Books] [Issue Fine]
\ | /
+-----------------------------+
| System |
+-----------------------------+
+-------------------+
| Member |
+-------------------+
/ | \
[Borrow Book] [Return Book] [Search Books]

3. ATM System

An ATM system involves a Customer, a Bank (acting as an intermediary), and the ATM
Machine. The system allows customers to withdraw, deposit money, check balance, etc.
Actors:

 Customer: A person using the ATM to perform banking tasks.

 ATM: The physical machine through which the customer interacts.
 Bank: The backend service that validates transactions.

Use Cases:

 Check balance (customer)

 Withdraw money (customer)
 Deposit money (customer)
 Change PIN (customer)
 Print receipt (customer)
 Validate transaction (bank)
 Update account (bank)

Use Case Diagram:

+----------------------------+
| ATM System |
+----------------------------+
^
|
+-------------------+
| Customer |
+-------------------+
/ | \
[Check Balance] [Withdraw Money] [Deposit Money]
\ | /
+---------------------------+
| ATM Machine |
+---------------------------+
/ | \
[Change PIN] [Print Receipt] [System Validation]
|
+------------------+
| Bank |
+------------------+
/ | \
[Validate Transaction] [Update Account] [Process Payments]

4. Online Banking System

In an online banking system, the actors can be Customer, Bank Server, and Administrator.
The use cases involve tasks such as transferring money, checking balances, and managing
accounts.

Actors:
  Customer: A user who accesses their account to perform banking activities.
 Bank Server: The backend system that processes transactions.
 Administrator: Manages accounts, resolves disputes, and oversees system maintenance.

Use Cases:

 Check balance (customer)

 Transfer money (customer)
 View transaction history (customer)
 Pay bills (customer)
 Block account (admin)
 Resolve disputes (admin)
 Process transaction (bank server)

Use Case Diagram:

+-----------------------------+
| Online Banking System |
+-----------------------------+
^
|
+-------------------+
| Customer |
+-------------------+
/ | \
[Check Balance] [Transfer Money] [Pay Bills]
\ | /
+-----------------------------+
| Bank Server |
+-----------------------------+
/ | \
[Process Transaction] [Validate Payment] [Check History]
|
+-------------------+
| Administrator |
+-------------------+
/ | \
[Block Account] [Resolve Disputes] [Manage System]

5. Online Learning Platform

In an online learning platform, the actors can be Student, Instructor, and Admin. The use
cases represent actions like enrolling in a course, viewing lectures, managing courses, etc.

Actors:

 Student: A learner who views lectures and interacts with the content.
 Instructor: A teacher who creates and manages courses.
 Admin: Manages users, handles system maintenance, and updates course information.
Use Cases:

 Enroll in a course (student)

 View lecture videos (student)
 Take quizzes (student)
 Submit assignments (student)
 Create course (instructor)
 Grade assignments (instructor)
 Manage users (admin)
 Approve courses (admin)

Use Case Diagram:

+------------------------------+
| Online Learning Platform |
+------------------------------+
^
|
+-------------------+
| Student |
+-------------------+
/ | \
[Enroll in Course] [View Lectures] [Submit Assignment]
\ | /
+-----------------------------+
| Instructor |
+-----------------------------+
/ | \
[Create Course] [Grade Assignment] [Manage Course]
|
+-------------------+
| Admin |
+-------------------+
/ | \
[Manage Users] [Approve Courses] [System Updates]

Conclusion

Use case diagrams are a powerful tool to model the functional requirements of a system. They
help in identifying key actors and the interactions they have with the system. These diagrams are
useful in the early stages of system design, providing a clear understanding of system
functionality and user needs.