Experiment 6

Name: Roll No: 55

Subject: SDU Class/Batch: SY CSBS/B-3

Date of Completion: Date of Submission:

AIM

Use case Diagram for Car Service Center Management System

Theory/Procedure/Algorithm

Theory: For Use case Diagram

1) Introduction :- What is Use case Diagram.

A use case diagram is a visual representation of the functional requirements of a system,
focusing on how users (or other systems) interact with the system. It illustrates the
relationships between various actors (users or external systems) and the system's use cases
(specific functions or processes the system performs). Use case diagrams are essential tools
in object-oriented modeling and software development, as they help stakeholders understand
the system’s capabilities and the interactions required for its operation. By providing a clear
and concise overview, use case diagrams serve as a communication tool that aids in the
analysis, design, and documentation of systems, ensuring that all necessary functionalities are
captured and well-understood.
 2) Symbols used in Use case Diagram:-

In a Use Case Diagram, various symbols are used to represent actors, use cases, and the
relationships between them. Here’s a brief explanation of the key symbols used in such
diagrams:

1) Use Case Diagram Elements for Car Service Center Management System (CSCMS)

1. Actors (Stick Figures or Rectangles)

• Symbol: A stick figure (or sometimes a rectangle with a label for non-human actors) represents an actor.
• Explanation: An actor is any entity that interacts with the system, typically representing users (e.g., Admin,
Customer, Mechanic) or external systems. It can be a human or another system.

2. Use Cases (Ovals)

• Symbol: An oval shape that contains the name of the use case.
• Explanation: A use case represents a specific functionality or action that the system performs. For example,
Login, Manage Car, Make Payment. It defines what the system does in response to an actor’s interaction.
3. System Boundary (Rectangle)

• Symbol: A large rectangle that encloses the use cases, usually labeled with the system name (e.g., Car
Service Center Management System).
• Explanation: The system boundary defines the scope of the system, separating what is part of the system
from what is external to it. The use cases are placed inside the boundary, while actors are placed outside.

4. Associations (Solid Lines)

• Symbol: A solid line connecting an actor to a use case.

• Explanation: An association represents a relationship between an actor and a use case. It shows which actor
interacts with which use case. The line indicates that the actor initiates or participates in that specific use case.

5. Include (Dotted Line with Arrow)

• Symbol: A dotted line with an arrow pointing to the included use case.
• Explanation: The include relationship shows that a use case always includes the behavior of another use
case. This means the included use case is always invoked as part of the larger use case.

6. Extend (Dotted Line with Arrow and Condition)

• Symbol: A dotted line with an arrow pointing to the extended use case, often accompanied by a condition.
• Explanation: The extend relationship shows that a use case can optionally extend another use case's
behavior under certain conditions. It represents additional functionality that can be triggered during the
execution of the base use case.

7. Generalization (Solid Line with a Hollow Triangle)

• Symbol: A solid line with a hollow triangle pointing to the generalized use case or actor.
• Explanation: The generalization symbol shows inheritance, where a specialized actor or use case inherits
behavior from a more general one.

8. Notes (Rectangular Boxes with a Folded Corner)

• Symbol: A rectangle with a folded corner, containing a description or comment.

• Explanation: Notes provide additional information or clarification. They do not affect the structure or
behavior of the diagram but offer context or explanations for the use cases, actors, or relationships.
 Example of Use Case Diagram:

• Actors: Admin, Customer, Mechanic & System User

• Use Cases: Login, Manage Car, Service Request, Make Payment, Add Parts

Relationships:

 Admin → Manage Car (association)

 Customer → Make Payment (association)
 Mechanic → Add Parts (association)
 System User → Manage Customer (association)

3) Use case diagram and its attributes with relation and cardinality used in Car Service Center
Management System (CSCMS)

A Use Case Diagram for a Car Service Center Management System provides a high-level visual representation
of how Admins, Customers, System Users, and Mechanics (actors) interact with CSCMS (use cases). The
actors typically represent different roles in the service process, while the use cases represent the system's
actions or processes. Below is a detailed explanation of the use case diagram, its attributes, relationships, and
cardinality in the context of a Car Service Center Management System.

Actors:

1. Admin: A person who manages users, cars, bookings, and overall application functions.
2. Customer: A person who requests services, views invoices, and makes payments.
3. Mechanic: A technician who repairs cars, adds parts, and creates issues or service reports.
4. System User: A user responsible for supporting admin tasks like managing customers, bookings, and car
repairs.

Use Cases:

1. Login: Allows users (Admin, Customer, Mechanic) to securely log in to the system.
2. Manage Car: Enables Admin to manage vehicle-related data.
3. Manage Booking: Facilitates booking management of service appointments.
4. Service Request: Allows Customers to raise service requests.
5. Make Payment: Lets Customers make payments for completed services.
6. Add Parts: Enables Mechanics to add required spare parts during repairs.
7. Create Issues: Mechanics can report vehicle problems found during service.
8. View Invoice: Allows Customers to check and download their service bills.
9. Manage Customer: Admin and System User can manage customer profiles and history.
10. Repair Car: Mechanics perform actual service or repairs on the vehicles.
 Relationships:

1. Customer → Login (Association):

• Cardinality: 1 customer to 1 login (1..1)
• Each customer logs in to access their profile and request service.
2. Customer → Make Payment (Association):
• Cardinality: 1 customer to 1 payment per service (1..1)
• Every service ends with a payment made by the customer.
3. Mechanic → Repair Car (Association):
• Cardinality: 1 mechanic to many repair tasks (1..*)
• A mechanic may handle several car repairs.
4. Mechanic → Create Issues (Association):
• Cardinality: 1 mechanic to many issues (1..*)
• A mechanic may document multiple problems for a single vehicle.
5. Admin → Manage Booking (Association):
• Cardinality: 1 admin to many bookings (1..*)
• The admin manages multiple appointments in the system.
6. System User → Manage Customer (Association):
• Cardinality: 1 system user to many customer records (1..*)
• A user can update and manage several customers' information.
7. Admin → Manage Car (Association):
• Cardinality: 1 admin to many car records (1..*)
• The admin maintains data of all customer vehicles.
8. Mechanic → Add Parts (Association):
• Cardinality: 1 mechanic to many parts (1..*)
• Mechanics can log multiple parts during the service process.

4) Use case diagram:-

A Use Case Diagram for a Car Service Center Management System visually represents the interactions
between users (actors) and the system’s functionalities (use cases). Key actors in the system typically include
Admin, Customer, Mechanic, and System User. Use cases represent the different tasks or services that the
system offers, such as Manage Car, Make Payment, Add Parts, Repair Car, Service Request, and Login.
The diagram shows the relationships between the actors and the use cases, demonstrating how each actor
interacts with the system to perform specific functions. This helps in understanding the user requirements,
system behavior, and identifying the key functionalities required for the Car Service Center Management
System.
 Conclusion

In conclusion, a Use Case Diagram for a Voting Management System effectively captures the
key interactions between users (actors) and the system’s core functionalities (use cases). It
provides a clear, high-level view of the processes involved, such as voter login, casting votes,
monitoring elections, and result declaration, as well as the roles of different actors, including
voters, candidates, the election commission, and system administrators. By defining relationships
and cardinalities, the diagram helps visualize how users interact with the system and ensures that
all necessary operations are accounted for. This diagram is crucial for understanding user
requirements, system behaviour, and the workflow of the voting process, making it an essential
tool for system design, development, and analysis.

Assessment

Timely Submission Presentation Understanding Total

Sign
(7) (06) (12) (25)