Crafting Clear Connections: Mastering Use Case Diagrams for Effective System Design
I’m not a prodigy. I didn’t start at 13. I learned the hard way — error by error, late night by late night. I still Google basic stuff, still mess up, still doubt myself. But I show up daily, build real things, and document the process without filters. No polished aesthetics. No fake “10x dev” talk. Just one guy trying to master his craft — publicly, consistently, and without shortcuts. If you relate to the grind more than the glory, welcome to my corner of the internet.
A Use case diagram in Unified Modelling language is a diagram that shows the interaction between actors and the system. It is a visual representation of functional requirements and how the user will interact with our system. It is a high-level diagram that helps stakeholders (clients) or any nontechnical person to understand how our system will respond from the user’s perspective.
Why draw the use case diagram?
Understand Requirements: When you need to clarify the requirements of a system, the use case diagram is very useful because it helps in understanding the system's use cases.
Identify Boundary: Use Case Diagram helps in understanding a boundary because it helps to distinguish between what is in the system and what is out of the system by drawing a system boundary.
System Design: It aids in designing the system by clarifying features, allowing us to outline and plan them effectively, ensuring that the product aligns with user needs.
Components of the Use Case Diagram
The use case diagram provides a visual language that helps software developers, architects, designers, and stakeholders document and communicate system design consistently.
There are three components of a Use Case diagram: Actors, Use Cases, and Relationships.
Actors
These are external entities that interact with the system. These can be humans or external systems. They initiate use cases and receive some outcome for it.
There are two types of actors:
Primary Actor: The one who initiates the use case to achieve a goal. Usually, it’s a human user or an external system that benefits from the system. Example: In an online shopping system, the Customer is a primary actor because they start actions like “Place Order.”
Examples: In project management system. “Project Manager,” “Team Member,” etc., are the Primary actors because they initiate use cases like “Add a Task” and “Complete a Task.”
Secondary Actor: The one that the system interacts with to complete the use case but does not initiate it. It supports the primary actor. Example: In the same system, Payment Gateway or Inventory System is a secondary actor because the system uses them to process the order, but they don’t start the process.
Examples: In a project management system, “SMT service” and “Notification service” are the Secondary Actors because they complete use cases like “sending email” and “sending notification,” but they do not actually initiate a use case.
Use Cases
These are the actions that are performed by the primary actors on the system. These are actions that the system can perform. Basically, these are the functional requirements of our system.
Examples: In a project management system, “Add a Task,” “Create a project” , etc., are the use cases because they are initiated by primary actors, and these are functional requirements of the system.
System Boundary
It is the visual representation that identifies the boundary of the system. It identifies the elements that are part of the system and what are external to it.
Relationships in the use-case diagram
In Use Case Diagrams , relationships are crucial in identifying the interactions between the actor of the system and the system itself. It provides a detailed view of the system’s functionality.
Association relationship:
In an association relationship, it shows the involvement of an actor in the use case . It is a line that connects the actor to the use case, illustrating the interaction between them. It is a simple line connecting the actor to the use case.
Example:
Actor: Project Manager
Use Case: Create project
Relationship: The line connected from the project manager to “Create project” shows an associate relationship. It shows that the project manager is involved in the “Create project” use case.
Include Relationship
In an Include relationship, a use case incorporating characteristics from another implies that if use case "Y" is incomplete, use case "X" will also be incomplete. That is why it is mandatory.
Example:
Use Cases: Create Task, Validate Task details
Relationship: This relationship shows that Usecase 1, “Create Task,” includes the functionality of Usecase 2, “Validate Task.” It means that without validating task details, task cannot be created
Extend Relationship
This relationship is also similar to the “include relationship.” But it is used to represent optional behavior. In this, even if the “Y” use case is not completed, the “X” use case is still considered to be completed.
Example:
Use Cases: Create Tasks; Notify Stakeholders or Clients
Relationship: This relationship shows that Usecase 1, “Create Task,”includes the functionality of Use case 2, “notify stakeholders” . It means that even if we do not notify stakeholders on task creation, the task can still be created successfully.
“Is a” Relationship
In this relationship, a use case inherits the characteristics of other relationships, showing that it is a specialized form of that particular use case.
Example:
Use Cases: “Manage Task,” “Create Task,” “Update Task,” “Delete Task”
Relationship:
This diagram correctly illustrates a Generalization relationship in the UML use case diagram. The arrows, with their hollow triangle heads, point from the specific "child" use cases to the more general "parent" use case. This arrow notation signifies an "is a" relationship. Therefore, this diagram shows that "Create Task" is a type of "Manage Task," "Update Task" is a type of "Manage Task," and "Delete Task" is a type of "Manage Task." "Manage Task" is the general concept, and the other three are the specific, concrete ways to perform that action.
Steps to Draw Use Case Diagram
Here are 7 steps to draw a use case diagram:
Step 1: Pinpoint Actors:
First, identify everyone and everything that interacts with your system. These "actors" can be human users, other software systems, or external hardware.
Step 2: Define Use Cases
List the main goals that actors want to achieve with the system. Each distinct goal or function (like "Log in" or "Create Task") becomes a "use case."
Step 3: Link Actors to Use Cases
Draw simple lines (called associations) connecting each actor to the specific use cases they interact with.
Step 4: Draw the System Boundary
Enclose all the use cases within a large rectangle. This box defines the scope of your system, separating its internal functions from the external actors.
Step 5: Specify Relationships
Examine your use cases for connections. Use standard notations (like
<<include>>, or generalization arrows) to show if one use case is required by, optional for, or a specific type of another.Step 6: Review and Improve
Take a critical look at your diagram. Does it clearly and accurately show how the system works? Tidy up the layout and make any necessary corrections for logical flow.
Step 7: Confirm with Stakeholders
Please share the diagram with clients, users, or managers. Obtain their feedback to ensure your diagram matches their expectations and requirements for the system's functionality.
Real-life example of Use Case diagram
To understand Use case diagram, i decided to draw use case diagram for authentication system
Here is my explanation of the diagram and how i followed 7 steps to draw the diagram:
Step 1: Identify Actors
First, I identified all the actors who will interact with my system. I've grouped them into:
Primary Actors (Users):
Unauthenticated user
authenticated user
project member
project manager
admin
stakeholders
Secondary Actors (Systems):
<<system>>OAuth Service<<system>>SMTP service
Step 2: Identify Use Cases
Next, I determined the main functionalities the system needs to perform. These are all the use cases I've placed inside the system box:
register account
login
reset password
log out
change password
Manage project
manage account status
Manage sessions
Update profile
Step 3: Connect Actors and Use Cases
In this step, I drew lines to show who does what:
I've shown that an Unauthenticated user can only "register account," "login," and "reset password."
An authenticated user has a different set of actions: "logout," "change password," "Manage project," "manage account status," "Manage sessions," and "Update profile."
I also showed that my "login" use case must connect to the external "OAuth Service," and the "reset password" use case connects to the "SMTP service" (to send the email).
Step 4: Add System Boundary
To define the scope of my project, I drew the large rectangle and labeled it "Authentication and Authorization system". This makes it clear which functions are inside my system and which (like the actors) are outside.
Step 5: Define Relationships
This is a key part of my diagram. I used the Generalization ("is a") relationship.
I have arrows from "project member," "project manager," "admin," and "stakeholders" all pointing to the "authenticated user."
This means, in my design, a "project member" is a type of "authenticated user." The same is true for "admin" and the others.
This allows them to inherit all the standard functions of an "authenticated user" (like "logout" and "Update profile") while still being distinct roles.
Step 6: Review and Refine
As I reviewed my own diagram, I confirmed that it shows a logical flow.
I've clearly split the system's functions based on whether a user is logged in or not.
The "Unauthenticated user" has a very limited set of actions, as they should.
Once logged in, the user becomes an "authenticated user" and gains access to the system's core features.
My use of Generalization clearly models the different user roles.
Step 7: Validate
Finally, I use this diagram to validate the design with my stakeholders.
It confirms for them that I have a clear separation between public (unauthenticated) and private (authenticated) functions.
It shows how I plan to handle user access with a role-based model.
It also clearly communicates my system's external dependencies, flagging that we will need to integrate with an OAuth Service and an SMTP service.
Conclusion:
In conclusion, use case diagrams are a vital tool in the realm of system design, offering a clear and structured way to visualize the interactions between users and systems. By delineating actors, use cases, and their relationships, these diagrams provide a comprehensive overview of functional requirements, aiding in both the design and communication processes. Whether you're a developer, designer, or stakeholder, understanding and utilizing use case diagrams can significantly enhance the clarity and effectiveness of system development projects. As demonstrated through practical examples and step-by-step guidance, mastering this tool can lead to more efficient and user-aligned system designs.
