Including Use Cases in Other Use Cases

As the use cases are refined and elaborated, it is likely that the team will discover that certain patterns of user and system behavior reoccur in a variety of places. Indeed, it's possible that some significant percentage of the functionality of the system occurs in multiple use cases. Examples include entering a password for user validation, performing a system status check before proceeding with a transaction that commits a change to data, selecting separate items from a table in a user interface, and so on. As this develops, the team members will find that they are creating redundant documentation in multiple use cases. Besides the volume problem, a worse problem happens when the common behavior changes since the change must be reflected in every use case that uses the common behavior. Those locations may not be obvious, and the process of making all necessary changes may be tedious and error prone.

This problem is addressed by the include ^[2] relationship. While it may seem complicated on the surface, the relationship is quite easy for the development team to grasp since it is analogous to a subroutine or include function in software. When the basic flow of events reaches the point of inclusion of the included use case, control switches directly to the flow of events in the included use case. When that flow is included, flow returns directly to the included use case at the next logical step past the include indicator, as illustrated in Figure 21-6.

^[2] [UML 1.3] An include relationship is a directed relationship between use cases, implying that the behavior in the additional use case is inserted into the behavior of the base use case.

Figure 21-6. The flow of an included use case

When used properly, the include relationship can simplify the development and maintenance activities. Your team members should apply this construct as soon as they have mastered the basic use-case techniques.