Distinguishing between Internal and External

Taken together, the use cases of your system cover all the services that your system offers to the totally of actors. Every service, every behavior, every interaction with the outside world must be covered. You may enclose all the system’s use cases in a box (representing the entire system) if you want to emphasize that your system is what’s offering these services. Label this box with the name of the system under construction (refer to Figures 8-4 and 8-5). Of course, this box is optional—and not all tools support this kind of notation—but it will help make the ownership of use cases clearer (at least it helps when the use cases can fit in the box).

Documenting use-case levels

Though it’s (technically) optional to do so, you should also stereotype the box in which you’re offering the use cases as «system». Other entities (such as subsystems or even classes) can offer use cases within UML, so using the stereotypes can help the reader understand who is offering these use cases as services.

We also recommend the use of «business» or «enterprise» when you want your use cases to be offered by the entire business, whether they’re automated or not. Depending on your methodology—and the size of the system you’re building—you may need «business», «system», «subsystem», «class», and even «component» stereotypes to identify different levels of use-case diagrams. Doing so helps you understand, explore, develop, and document your system—one iteration at a time.

When you do document your use cases at the «business» level, don’t consider the internal workers of your system as actors. Instead, consider them internal parts of your business system—essentially transparent. You ignore the workers at the business level because your model should assume they’re internal entities—under your complete control, like a database or other internal subsystem. (You can read more about this approach in the section on “Defining a good use case,” earlier in this chapter.) Similarly, when you’re diagramming at a business level you should ignore “transparent” devices (discussed earlier); instead, indicate the ultimate actors that use those devices.

For that matter, ignore all internal subsystems when you’re showing use cases at the «system» level. You can—provided you’re building a large enough system—decompose the system into several interacting subsystems. Then you can find use cases for each subsystem, each with its own use-case diagram (focused on itself). From the point of view of the subsystem, its actors are the other interactive subsystems of the system—including (if the subsystem interacts with the outside world) one or more actors of the system as a whole. Figure 8-6 shows an example of use-case levels.

Figure 8-6: Use-case diagram levels.

Treating people as design elements

If you model the Hotel as a Business, the registration clerks and other employees show up in the model as internal design elements. Perhaps you could automate their jobs completely. Consider the recent trends in libraries and supermarkets; it’s now possible to check out your own books and check out your own groceries. From the model’s point of view, clerks or cashiers are designable elements, not actors; in effect, the business doesn’t exist for the employees; the employees exist for the system.