لطفا منتظر باشید ...
4.5 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.
4.5.1 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.
4.5.2 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.
