Here are the Use Case Diagram Guidelines You Need to Know
When it comes to analyzing the requirement of a system, use case diagrams are second to none. They are visual and usually very easy to understand. The following use case diagram guidelines will help you to create better use cases that are appreciated by your clients and peers alike.
A use case diagram mainly consists of actors, use cases and relationships. More complex larger diagrams can include systems and boundaries. We’ll discuss the guidelines based on objects.
It is important to remember that these are guidelines and not rules. It’s alright to deviate if it improves the overall quality of the diagram. To get a deep understanding of use case diagrams, check out our use case diagram tutorial.
Actors
- Give meaningful business relevant names for actors — For example if your use case interacts with an outside organization, it’s much better to name it with the function rather than with the organization’s name. (Eg: Airline Company is better than PanAir)
- Primary actors should be to the left side of the diagram — This enables you to quickly highlight the important roles in the system.
- Actors model roles (not positions) — In a hotel, both the front office executive and shift manager can make reservations. So something like “Reservation Agent” should be used for actor name to highlight the role.
- External systems are actors — If your use case is send email and if it interacts with the email management software, then the software is an actor to that particular use case.
- Actors don’t interact with other actors — In case actors interact within a system, you need to create a new use case diagram with the system in the previous diagram represented as an actor.
- Place inheriting actors below the parent actor — This is to make it more readable and to quickly highlight the use cases specific for that actor.
Use Cases
- Names begin with a verb — A use case models an action, so the name should begin with a verb.
- Make the name descriptive — This is to give more information to others who are looking at the diagram. For example “Print Invoice” is better than “Print”.
- Highlight the logical order — For example, if you’re analyzing a bank customer, typical use cases include open account, deposit and withdraw. Showing them in the logical order makes more sense.
- Place included use cases to the right of the invoking use case — This is done to improve readability and add clarity.
- Place inheriting use case below parent use case — Again this is done to improve the readability of the diagram.
Relationships
- Arrow points to the base use case when using <<extend>>
- <<extend>> can have optional extension conditions
- Arrow points to the included use case when using <<include>>
- Both <<extend>> and <<include>> are shown as dashed arrows.
- Actor and use case relationship don’t show arrows.
Check out the link to learn more about use case diagram relationships.
Systems / Packages
- Use them sparingly and only when necessary
- Give meaningful and descriptive names to these objects
More Use Case Diagram Guidelines
I have covered some of the most common guidelines you should follow when creating use case diagrams. However, there could be plenty more depending on the circumstance. For example, you might have a company standard for naming objects. Do take those into consideration when creating your use case diagram.
Of course, if you think I’ve missed a critical point or a commonly followed standard, make sure to mention it in the comments. It’s a good place to ask questions too.
This article was originally published in the Creately blog and has been slightly modified to meet Medium guidelines. Click the link below to view the original article;
http://creately.com/blog/diagrams/use-case-diagram-guidelines/
.
