Learning UML

Generalizations

Actors may be similar in how they use a system; for example, project managers, resource managers, and system administrators may log in and out of our project management system. Use cases may be similar in the functionality provided to users; for example, a project manager may publish a project’s status in two ways: by generating a report to a printer or by generating a web site on a project web server.

Given that there may be similarities between actors and use cases, how do we organize the use cases that define what a system should do? And how do we use the information about similarities between actors and use cases to determine how best to execute a project? Specialized types of generalizations, called actor and use case generalizations, address these questions. Generalizations are introduced and discussed in Chapter 3. The next two sections discuss these specialized types of generalizations.

Actor Generalizations

Figure 4-10 shows that project managers, resource managers, and system administrators may log in and out of the project management system. Thus, logging in and out is common to these actors. Actor generalizations address such situations by factoring out and reusing similarities between actors.

Figure 4-10. Similar actors

An actor generalization from a more specific, or specialized, actor to a more general, or generalized, actor indicates that instances of the more specific actor may be substituted for instances of the more general actor. An actor may specialize multiple actors, and an actor may be specialized by multiple actors. An actor generalization between actors is shown as a solid-line path from the more specific actor to the more general actor, with a large hollow triangle at the end of the path connected to the more general actor.

Figure 4-11 refines Figure 4-10 using actor generalizations between actors. A human resource initiates the Login and Logout use cases. Project managers, resource managers, and system administrators are human resources.

Figure 4-11. Actor generalizations

Use an actor generalization between actors when one actor is similar to another, but has specific interactions in which it participates or initiates. For example, any human resource may log in and out, but project managers, resources managers, and system administrators make more specialized use of the project management system. Because the Project Manager, Resource Manager, and System Administrator actors are specialized Human Resource actors, they benefit from the use cases in which the Human Resource actor is involved. Therefore, by developing the Login and Logout use cases, we provide the functionality described by those use cases for all the actors of our system.

Use-Case Generalizations

Figure 4-12 shows that a project manager may publish a project’s status in two ways: by generating a report to a printer or by generating a web site on a project web server. Thus, publishing a project’s status and all the processing involved in collecting and preparing the data for publication is common to these use cases. You can use a use-case generalization to address this situation by factoring out and reusing similar behavior from multiple use cases.

Figure 4-12. Similar use cases

A use-case generalization from a more specific, or specialized, use case to a more general, or generalized, use case indicates that the more specific use case receives or inherits the actors, behavior sequences, and extension points of the more general use case, and that instances of the more specific use case may be substituted for instances of the more general use case. The specific use case may include other actors, define new behavior sequences and extension points, and modify or specialize the behavior sequences it receives or inherits. A use case may specialize multiple use cases, and a use case may be specialized by multiple use cases. A use-case generalization between use cases is shown as a solid-line path from the more specific use case to the more general use case, with a large hollow triangle at the end of the path connected to the more general use case.

Figure 4-13 refines Figure 4-12 using use-case generalization between use cases. The Generate Report and Generate Website use cases receive the Project Manager actor, behavior sequences, and extension points of the Publish Status use case.

Figure 4-13. Use-case generalizations

You can use a use-case generalization between use cases when a more specific use case is similar to a more general use case but involves other actors or has specialized behavior. For example, a project manager may publish a project’s status using a report or a web site, but a printer is involved only if a report is generated, and a project web server is involved only if a web site is generated. Because the Generate Report and Generate Website use cases specialize the Publish Status use case, Publish Status must be developed before the other use cases; otherwise, the other use cases won’t have a use case to specialize.

It is important to understand the difference between include and extend dependencies and use-case generalization. An inclusion use case does not have knowledge of the base use case that includes it, an extension use case does not have knowledge of the base use case that it extends, and the Maintain Activity use case in Figure 4-8 has no knowledge of the use cases that it extends, so they can’t involve the actors of the base use case in their behavior sequences. For example, the Log Activity use case in Figure 4-6 has no knowledge of the use cases that include it. However, a more specific use case receives or inherits the actors, behavior sequences, and extension points of its more general use case, so it can involve the actors of the more general use case in its behavior sequence. For example, the Generate Report use case in Figure 4-13 has knowledge of the Publish Status use case and may involve the Project Manager actor in its behavior sequence. An inclusion use case must be developed before its base use cases, an extension use case must be developed after its base use cases, and a more specific use case must be developed after its more general use cases.