Use Cases: When to use Includes, Generalization and Extending

Use Cases: When to use Includes, Generalization and Extending

I often find unsure when I have to decide if I must use a <> or <> in my UML Use Case Diagram. Here are a couple of quidelines taken from UML For Dummies by Michael Jesse Chonoles and James A. Schardt (ISBN: 0-7645-2614-6)

Linking Use Cases with «include» (sometimes referred to a <>)

You’ll often run into déjà vu as you document your use cases—especially when several of them show an identical sequence of events exchanged between an actor and the system. This is more than coincidence; multiple use cases often have common subsequences. Usually (for example), some common setups or prerequisites must be established before work even begins—and common subgoals have to be reached on the way to accomplishing the actor’s goals.

Recognizing this commonality is good—because if you don’t recognize it, you can end up doing your use-case work twice. Doing the same thing over again is bad enough, but the consequences to your project can be worse. If you document your use cases twice, you’ll likely document them differently—which leads to designing, implementing, and testing them differently. Such systems are also costly because such a lack of reuse adds complexity—and your users may easily get lost in a system that shows no cohesion. They’ll have to learn and remember different techniques to accomplish the same goals in different contexts.

To save everyone some hassle, it’s worth looking for opportunities to reuse common pieces of use-case interactions between an actor and the system

Documenting included use cases

You may have one difficulty when you attempt to document the included use case: How do you identify the primary actor? After all, three different actors are involved with the Guarantee Reservation use case—and at least two of them are potential primary actors. In fact, you should consider both Potential Guest and Event Organizer as primary actors (yes, there can be more than one). Any primary actor for any base use case is also a primary actor for the included use case. You must document the included use case in a way that allows any primary tor to interact with the system being built. 

Using Generalization with Use Cases

• Differing mechanisms for the same goal: If there’s more than one alternative technique or approach that the system uses to help the actors get their goals accomplished, they may share only a little implementation in common. If they meet the same goal, however, then the approaches will be still be sharing quite a bit: requirements, business rules, and data validations. With generalization, we can make this sharing explicit and save on duplications, by putting the common stuff in a single use case.

• Differing agents for the same goal: If there is more than one actor trying to accomplish the same goal, you may be able to generalize the actors as we explain in the section above on generalizing actors in included use cases, However, you will find that often the actors have separate privileges, capabilities, or user interface. This is especially common when one actor acts as an agent or intermediary for the other. Generalizing the actors might still help, but now we want to explain how the use case works differently for each type of actor. Instead of generalizing the actors, generalize the use cases, placing in the generalized use case the common documentation, requirements, business rules, data validations, and perhaps implementation that they share. Using generalization will help you corral this common stuff and put it in its place (in a separate single use case).

Extending Use Cases

Your use-case diagrams can convey lots of information packed into a simple form—but most information developed in the analysis stage ends up inside the use case, serving as its specifications In practice, use-case flows get much of their true complexity from the entanglement of multiple alternate courses and paths.

When you draw use-case diagrams, you’re practicing the good object-oriented principles of abstraction and information hiding  to simplify the tangle—communicating the essence without the distraction of suppressible details.

Hiding complexity is generally good, but sometimes you have to expose some details to gain clarity somewhere else. With UML, you can depict important alternate flows graphically by making them into their own use cases. Then you can connect these new use cases to their base use cases by establishing an «extend» relationship. Thus, you can emphasize otherwise-hidden information when the reviewers of your use-case diagram want to see it. Some reasons this might be desirable are as follows:

• Changed capability: If you have changed a use case significantly— perhaps because of a later release—you may find it useful (and perhaps politic) to emphasize that the change has occurred, rather than burying it in the use-case specification.

• Major variation: If you have a major alternative path in the use case, and it’s complex enough to have its own alternative paths, then placing it on your diagram will honestly expose the complexity—which is helpful in costing, assignment, and scheduling.

• Optional subgoal: If you have parts of the use case that would be optional to implement (or even optional to execute) to meet the actor’s goals, put those parts into their own use case. Doing so clarifies the relationships between actors and their goals. It also emphasizes that you may deliver these optional goals in later releases.