Step-By-Step Use Case Diagram Drawing Tutorial
Use case diagrams are a common way to communicate the major functions of a software system. This UML use case tutorial is designed to help business analysts get up to speed by using UML 2.0 to author a use case diagram.
Lucidchart is perfect for creating attractive, functional diagrams. Use the application to edit, collaborate on, and publish use case diagrams—all from the web.Try it now Sign up free
CHOOSE A MEDIUM
It’s important to pick a flexible UML tool for your project. Simple UML diagrams can be sketched out with pen and paper or a whiteboard, but any serious diagrams are created with computer software. Some programs are more complicated or expensive than others, so choose wisely.
For the purposes of this guide, we’ll proceed as though you’re using Lucidchart. Our program is easy to use and comes with a full set of UML 2.0 symbols.
Create a new document in Lucidchart and click "More Shapes" to customize which shape libraries are displayed. Turn on the UML shape library, then find the UML use case shapes. Begin by dragging a rectangle container into the document and labeling it with the name of your system. Then grab the actor shape (the stick figure) and drag it outside the system rectangle. Finish by labeling the actor.
Hover over the customer stick figure and grab one of the handles. Drag a line from that point into the system rectangle. When you release the mouse, a dialog will appear, allowing you to choose the next shape you want to use. Lucidchart's ability to chain together shapes and arrows is a significant timesaver when compared to other diagramming applications.
Change the arrow type by selecting the arrow and altering the end points in the properties bar at the top of the editor.
INCLUDE AND EXTEND
As you develop use cases diagrams, you will quickly discover that some functionality is repeated across several use cases. For example, many use cases include a check roles use case to validate that a user has necessary permissions to perform a certain action. In UML, this is known as an include relationship and it is shown by drawing a dashed line with an arrow pointing to the use case that is included.
If you're familiar with object-oriented programming, you may think that the extend relationship is similar to the concept ofinheritance in Java or C++. However, the authors of UML did not intend to convey an inheritance meaning to the extend relationship. In the context of UML, "extend" refers to an optional condition. For example, the Withdraw Cash use case likely includes a step to print a receipt. What happens if the ATM runs out of paper and cannot print receipts? In this condition, you may want to include an optional use case for Send Error Condition Notification. In UML, this relationship is shown by drawing a dashed line with an arrow pointing to the use main use case.
ASK HIGH-LEVEL QUESTIONS
When authoring a use case, it’s sometimes difficult to know how much detail should be captured. Here are some questions to consider:
What goals does the user have when using the system?
You may be tempted to include more detailed processes underlying each use case, but these are better left to the text-based use case description. For example, a UML use case for an ATM would include a use case for depositing a check, making a withdrawal, and transferring money. In this case, the process of choosing a checking account and entering the amount to withdraw is too detailed to be captured in a use case diagram.
What view will the admin see?
Most systems have at least two interfaces: an interface for end users and another interface for the administrators who need to create, update, and delete accounts, along with other tasks. It’s common for the administrator interfaces to require even more development time than the end user views.
Are there non-human users of the system?
In UML, the users of a system are known as actors, and they can include non-human users. Returning to the ATM example, a bank would likely have the means to determine the status of any ATM from a remote location. A good rule of thumb is that actors cannot be changed as part of the scope of your project.
What makes a good use case diagram?
Every use case should have measurable output. Put yourself in the place of a tester who is evaluating your system on the sole basis of your use case diagram. It should be possible to give a pass or fail grade to each use case. Was a customer able to withdraw cash or deposit a check, or did the use case fail?
Lucidchart can help you create UML diagrams for work or school. Our software is platform-agnostic, so users can work from any device or location. Try it and see for yourself!