Now, as we did for the class diagram, 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.