Learning UML

Dependencies

A model may have many use cases, so how do we organize the use cases that define what a system should do? And how do we use this information about use cases to determine how best to execute a project while considering how use cases are related to one another, including what some use cases might have in common, and also taking into account use cases that are options of other use cases? Specialized types of dependencies, called include and extend dependencies, address these questions; dependencies are discussed in Chapter 3. The next few sections discuss these specialized types of dependencies.

Include Dependencies

Perhaps we wish to log the activities of project managers, resources managers, and system administrators as they interact with the project management system. Figure 4-5 elaborates on the use cases in Figure 4-4 to show that the activities of the project manager, resource managers, and system administrators are logged when they are performing the use cases shown in the diagram. Thus, logging activities are common to these three use cases. We can use an include dependency to address this type of situation by factoring out and reusing common behavior from multiple use cases.

Figure 4-5. Use cases with common behavior

An include dependency from one use case (called the base use case) to another use case (called the inclusion use case) indicates that the base use case will include or call the inclusion use case. A use case may include multiple use cases, and it may be included in multiple use cases. An include dependency is shown as a dashed arrow from the base use case to the inclusion use case marked with the include keyword. The base use case is responsible for identifying where in its behavior sequence or at which step to include the inclusion use case. This identification is not done in the UML diagram, but rather in the textual description of the base use case.

Figure 4-6 refines Figure 4-5 using include dependencies. The Log Activity use case is common to the Manage Project, Manage Resource, and Administer System use cases, so it is factored out and included by these use cases.

Figure 4-6. Include dependencies

You can use an include dependency when a use case may be common to multiple other use cases and is therefore factored out of the different use cases so that it may be reused. The Log Activity use case in Figure 4-6 is included in the Manage Project, Manage Resource, and Administer System use cases. Consequently, you must analyze and develop that use case before you develop the three use cases that depend on it.

Extend Dependencies

Projects are made of activities, and activities are made of tasks. Figure 4-7 elaborates the Manage Project use case in Figure 4-4, and shows that a project manager may manage projects by maintaining the project itself, its activities, or its tasks. Thus, maintaining the project, its activities, and its tasks are options of managing a project. You can use an extend dependency to address this situation by factoring out optional behavior from a use case.

Figure 4-7. Use cases with optional behavior

An extend dependency from one use case (called the extension use case) to another use case (called the base use case) indicates that the extension use case will extend (or be inserted into) and augment the base use case. A use case may extend multiple use cases, and a use case may be extended by multiple use cases. An extend dependency is shown as a dashed arrow from the extension use case to the base use case marked with the extend keyword. The base use case is responsible for identifying at which steps in its behavior sequence the extending use cases may be inserted.

Figure 4-8 refines Figure 4-7 using extend dependencies. The Maintain Project, Maintain Activity, and Maintain Task use cases are options of the Manage Project use case, so Manage Project is factored out and extends those three use cases.

Figure 4-8. Simple extend dependencies

The location in a base use case at which another behavior sequence may be inserted is called an extension point. Extension points for a use case may be listed in a compartment labeled “Extension Points” where each extension point is shown inside the compartment with an extension-point name followed by a colon followed by a suitable description of the location of the extension point in the use case’s behavior sequence. Locations may be described as being before, after, or in-the-place-of a step in the base use case’s behavior sequence. For example, the Manage Project use case may have a behavior sequence for finding a project on which to work followed by an extension point named Project Selected followed by another behavior. The Project Selected extension point may be described as occurring after a project is found but before it is actually worked on.

An extend dependency is responsible for defining when an extension use case is inserted into the base use case by specifying a condition that must be satisfied for the insertion to occur. The condition may be shown following the extend keyword enclosed within square brackets followed by the extension point name enclosed in parentheses. For example, other use cases may be inserted into the Project Selected extension point just described for the Manage Project use case. Such behavior sequences may include reviewing and updating project information, or selecting a specific version of a project before managing the details of the project in the succeeding behavior sequences.

Figure 4-9 elaborates on the Administer System use case in Figure 4-4 using extend dependencies. It shows that a system administrator is offered two options — starting up the system or shutting down the system — at the extension point named Administration Functions, which is described as being available on the administration menu of the user interface. Figure 4-9 further shows the following:

Figure 4-9. Extension points and extend dependencies

• The Startup System use case is available as an option at the Administration Functions extension point of the Administer System use case. The Startup System use case has two extension points named Before and After. The Before extension point is described as occurring before the startup functionality is performed by the system, and the After extension point is described as occurring after the startup functionality is performed by the system. These extension points are used as follows:

  • The Restore Data use case is available as an option at the Before extension point of the Startup System use case. Before starting up the system, the system administrator may restore data from the backup system to the project management system’s database that was previously archived.

  • There are no options described for the After extension point of the Startup System use case.

• The Shutdown System use case is available as an option at the Administration Functions extension point of the Administer System use case. The Shutdown System use case has two extension points, named Before and After. The Before extension point is described as occurring before the shutdown functionality is performed by the system, and the After extension point is described as occurring after the shutdown functionality is performed by the system. These extension points are used as follows:

  • The Backup Data use case is available as an option at the After extension point of the Shutdown System use case. After shutting down the system, the system administrator may back up data from the project management system’s database to the backup system for later retrieval.

  • There are no options described for the Before extension point of the Shutdown System use case.

The extension points just described allow us to insert behavior into the Startup System and Shutdown System use cases before or after they perform startup or shutdown processing for the project management system. The extend dependencies reference these extension points to indicate where use cases may be inserted inside one another, and also to indicate the conditions that must be satisfied for such an insertion to occur. Naturally, data is restored before the system is started up and data is backed up after the system is shut down.

Use an extend dependency when a use case is optional to another use case. Because the Maintain Project, Maintain Activity, and Maintain Task use cases extend the Manage Project use case, the Manage Project use case must be developed before the others; otherwise, the other use cases won’t have a use case to extend. Likewise, the Administer System use case must be developed before the Startup System and Shutdown System use cases, Startup System must be developed before Restore Data, and Shutdown System must be developed before Backup Data. However, once Administer System is developed, Startup System and Shutdown System may be developed in parallel or concurrently, because they are not directly related.