Use Case Diagram Creation Tips
Let’s look at some creation tips for use case diagrams. The first tip is that when you define a use case, use a name that communicates purpose.
It should be clear what the use case refers to by just looking at the name of the use case. Second tip is to define one atomic behavior per use case. So try not to put more than one specific scenario into a use case. Why? Because these will make the use cases easier to understand and better suited for their roles that we just discussed to define test cases, to do planning, to define an architecture and so on and so forth. Define the flow of events clearly.
So again, do it from the perspective of an outsider. An outsider should be able to read the description of the flow of events and understand exactly how the system works or how that specific piece of functionality works. As we suggested for the class diagram, provide only essential details So there is no need to provide all the nitty gritty details about the use case, just provide enough details so that the use case is complete and understandable. And finally, even though we didn’t cover that, there is a way to factor common behaviors and factor variants when defining use cases.
So I will encourage you to look at how to do that. For example, by looking at the additional UML documentation and to try to factor out this common behaviors and variants. Typical example would be a system that requires login, like the one that we just discussed, will probably require an initial login step for each use case. It is possible that instead of describing the same steps, or same sub-steps, for each use case, you can factor that out. And create a use case that you should then include in your own use cases.
As I said, we didn’t cover this for simplicity, but feel free to further read about UML and to see how you can actually factor out behaviors and factor variants. Which can be very useful in practice.