-Now, as we did for the class diagram, let's look at - -2
-some creation tips for use case diagrams. The first tip is that - -3
-when you define a use case, use a name that communicates purpose. - -4
-It should be clear what the use case refers to by just - -5
-looking at the name of the use case. Second tip is - -6
-to define one atomic behavior per use case. So try not to - -7
-put more than one specific scenario into a use case. Why? Because - -8
-these will make the use cases easier to understand and better suited - -9
-for their roles that we just discussed to define test cases, - -10
-to do planning, to define an architecture and so on and - -11
-so forth. Define the flow of events clearly. So again, do - -12
-it from the perspective of an outsider. An outsider should be able - -13
-to read the description of the flow of events and understand - -14
-exactly how the system works or how that specific piece of - -15
-functionality works. As we suggested for the class diagram, provide only - -16
-essential details. So there is no need to provide all the nitty - -17
-gritty details about the use case, just provide enough details so - -18
-that the use case is complete and understandable. And finally, even - -19
-though we didn't cover that, there is a way to factor - -20
-common behaviors and factor variants when defining use cases. So I will - -21
-encourage you to look at how to do that. For example, - -22
-by looking at the additional UML documentation and to try to - -23
-factor out this common behaviors and variants. Typical example would be - -24
-a system that requires login, like the one that we just discussed, - -25
-will probably require an initial login step for each use - -26
-case. It is possible that instead of describing the same steps, - -27
-or same sub-steps, for each use case, you can factor - -28
-that out. And create a use case that you should then - -29
-include in your own use cases. As I said, we - -30
-didn't cover this for simplicity, but feel free to further read - -31
-about UML and to see how you can actually factor out - -32
-behaviors and factor variants. Which can be very useful in practice. -- cgit 1.4.1