7.1. Use CasesUse cases represent distinct pieces of functionality for a system, a component, or even a class. Each use case must have a name that is typically a few words describing the required functionality, such as View Error Log. UML provides two ways to draw a use case. The first is an oval with the name of the use case in the center. Figure 7-1 shows a basic use case. Figure 7-1. A simple use caseYou can divide a use case's oval into compartments to provide more detail about the use case, such as extension points (see "Use Case Extension"), included use cases (see "Use Case Inclusion"), or the modeling of specific constraints. Figure 7-2 shows a use case oval with a compartment listing extension points. However, the oval representation of use cases doesn't hold up well with detailed compartments. UML recommends you use the classifier notation if you want to provide details about a use case. Show the use case as a rectangle, with the use case oval in the top-right corner. Now, place the name of the use case in the top, in bold. You can then divide the classifier into compartments as needed. Typical Figure 7-2. Use case with a compartment showing extension pointscompartment names are extension points and included use cases. Figure 7-3 shows the same use case as in Figure 7-2, but in classifier notation. Figure 7-3. Use case in classifier notationUML makes a clear distinction that the term use case strictly applies to the UML element and its name. Full documentation of a use case is considered an instantiation of the use case. This is a subtle distinction, but it allows you to document a use case whatever way best captures the use case's functionality. You can document a use case in a text document, state machine, interaction diagram, activity diagram, or anything else that conveys the details of the functionality in a meaningful way to your reader. |