UML 2 For Dummies
Context diagrams are popular because they can show the entire picture at one shot. In complicated systems, you couldn’t show all use cases on one diagram anyway. Therefore, what you want to do is to produce a use-case diagram for each initiating (primary) actor. If you make the actor names on the context diagram into hyperlinks, then your context diagram becomes a graphic table-of-contents that refers to a set of use-case diagrams.
This organizational structure is probably the most efficient for you anyway. If you produce artifacts based on the use-case structure, you’ll want to organize them actor-by-actor so the actor community can review the diagrams more easily. The real-world actors (supervisory personnel, for example) can give you focused feedback and input if they can narrow their view—which means looking only at their own sections. This approach works for identifying requirements, as well as for the stages of analysis, design, implementation, and delivery.
When you use this approach to structure part of your system, you put your initiating actor and its use cases in a separate package. (You can find more about using packages in Chapter 7.) A use-case package has an optional, special icon (a tabbed folder with an oval in the center) that you might want to use (as shown in Figure 8-8). Although use cases themselves are behaviors—which you name with verb phrases—use-case packages are things, so you name them with noun phrases. We recommend creating a package called Actor Uses for each primary actor you can name. If you find that you have too many use cases within a single package, you can make lower-level packages. In fact, you may need several levels of packages if you’re planning a large system.