Use case diagram: how to create one
Easyprojecthub is really pleased to be able to share some great content from a dynamic, outgoing consultant based in the United States. We love all of the blog posts Mohamed Elgendy writes. He’s articulate and explains things really clearly step-by-step. You can also find more of Mohamed’s posts on his own blog http://mohamedelgendy.com/blog/.
We hope you enjoy his post on the Use Case Diagram.
What is a Use Case Diagram?
Use case diagrams represent a graphical overview of the functionality provided by the system in terms of actors, their goals, and dependencies between them.
Why create a use case?
- A great way to show how the functionality works
- To represent how the system responds to the end user interactions by illustrating the interaction between the end user and the system from the user’s perspective
- Very easy to understand by non-technical stakeholders
Let’s take a look at a food ordering app (e.g. a service like GrubHub or Seamless) example below:
In the above example, you can see some actors and functions (use cases)connected by a bunch of relationships (associations) to define the interactions between them. Before we get into the use case components, let’s understand the system described in the above example:
- The system will be used by three types of actors: Waiters, Customers and a Cook
- Customers will place their order. Customers can also order a drink
- Customers will enter their information and pay for food
- Waiters will recieve the order and send it to the Cook
- The Cook will prepare the food and send a notification to the Waiter
- Waiters will finalize the order and deliver it to the Customer’s address
What are the components of a use case?
Use Cases contain two main deliverables: use case diagram and a use case document. Some organizations require both from the BA and others require just one of them. This depends on the project nature, your audience and the organization’s PMO methodologies. In this post, I’ll cover the use case diagram.
- Actors are not part of the system; they represent any person or system that interacts with the application
- The actor represents a specific role – not all users playing that role. In the above example, you can have more than one waiter but they are all represented by one actor
- We do not have control over actors – actors are free to do what they want, we can only control our system
2. Use cases
- A use case typically represents a complete functionality that the actor can use in a system
- A use case must deliver something of value to an actor
- A group of use cases (functions) for a system defines the ways the system can be used.
Ask the following questions to identify the system’s use cases:
- What are the goals of each actor?
- How can each actor achieve their goal?
- Will any actor create, store, modify, delete, or read information from the system?
- Does any actor need to be notified about certain occurrences in the system?
Once you have identified your actors and their goals, you have now created your initial list of high level use cases. Remember, effective use cases must have understandable actors and goals.
3. Use case relationship (associations)
- Indicate the communication between an actor and a use case
- Can flow in both directions – actor to use case and use case to actor
- Represented with a solid line connecting the two parties and in some cases with an arrowhead
There are THREE types of use case associations:
3.1 Generalization Relationship
“A taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus the specific classifier indirectly has features of the more general classifier.” ~ UML2.0
- In a generalization relationship, think of the general use case as a “parent” use case
- Specific use cases inherit the behavior of the general use case
3.2 Include relationship
Include relationships describe a required (non-optional) behavior included in the base use case. It is a relationship created between a use case (base) that “uses” the functionality of another use case (included). Generally, it is assumed that the included use case will be called every time the basic path is run.
- The base use case “uses” the included uses case
- A base use case cannot function until it gets information from the included use case
3.3 Extend relationship
In this relationship, an extension use case is created to extend the behavior of the extended (base) use case when exceptional circumstances are encountered. An extend relationship is used to represent an optional or exceptional behavior.
- If you are still confused about the different types of relationships, please see the comments – I’ve added another example from Mohamed that will make things more clear.
4. System boundary
The system boundary box is a rectangular shape drawn around the concerned use case to represent the system’s scope. Only the use cases contained within that boundary box are considered to be in-scope, and anything outside is considered out-of-scope.
Step-by-step guide to creating a use case
- Define your actors
- Define their goals
- Define the system’s use cases (you can use the actors’ goals as high level use cases)
- Define the relationship between:
– Actors and actors
– Use cases and use cases
– Actors and use cases
- Create the use case diagram
Tools to create a use case
There are several tools that can be used to develop UML diagrams. Depending on the organization you are working for, they may use any of the following tools:
- Rational Rose: it comes with the Rational Suite (created by IBM). Rational Rose is the most respected in the business, but it is only used for huge projects because its license is very expensive
- Ms Visio: it is the most common used by many organizations (Microsoft Product)
- Visual Paradigm: it is very similar to Ms Visio for Macintosh users
- The best of all – Draw.io: is a FREE web app that is very similar to MS Visio
Easyprojecthub top tip
Easyprojecthub find use case diagrams really good where there are many people using a system in different ways, and in particular where there are many end users that interact with the system. A great example would be if you were designing an app or website. It can really drive a great USER EXPERIENCE (UX) which is often what it’s all about today.
We love to hear your comments and really appreciate it if you share posts on your favourite social media platform (you’ll find the links if you scroll up or down).
You can also get a FREE pdf summary of this blog post and all our other posts by clicking the button below.