لطفا منتظر باشید ...
3.4 Generalizations, Realizations, and Dependencies
While it is common to use types during analysis activities,
interfaces during analysis activities and design activities,
undifferentiated classes during design activities, and implementation
classes during the later part of design and during implementation
activities, how are all these elements related? Generalizations,
realizations, and dependencies, called specialized
relationships, address
the
question of how
undifferentiated and differentiated classes are related. The next few
sections discuss these relationships.
3.4.1 Generalizations
A generalization between a more general
element and
a more specific element of the same kind indicates that the more
specific element receives the attributes, associations and other
relationships, operations, and methods from the more general element.
The two elements must be of the same kind. For example, a
generalization relationship can be between two types but not between
a type and an interface. Generalization relationships may exist for
the following kinds of elements:
Types
Undifferentiated classes
Implementation classes
Interfaces
A generalization is shown as a solid-line path from the more specific
element to the more general element, with a large hollow triangle at
the end of the path connected to the more general element.
You'll see examples of this as I discuss each
specific type of generalization in the following sections.
3.4.1.1 Types
The project manager, human resource,
and
system administrator types shown earlier in Figure 3-25 are specific types of human resources. You can
model a generalization of these three types to factor out structure
and behavior common to all. A generalization between types allows us
to reuse a type's attributes, associations, and
operations to define a new type. Figure 3-30 shows
that the THumanResource type is a generalization
of TProjectManager,
TSystemAdministrator, and
TResourceManager.
Figure 3-30. Generalizations between types
Because a generalization between a more general type and a more
specific type indicates that the more specific type is a specialized
form of the more general type, those classes that may play the roles
of the more specific type may also play the roles of the more general
type. Therefore, Figure 3-30 shows that those
objects that play the specific roles of project manager, resource
manager, and system administrator may also each play the more general
role of a human resource.
3.4.1.2 Undifferentiated classes
The Worker class shown in Figure 3-26 may
have a more specialized
undifferentiated class of human resource, which itself has more
specialized undifferentiated classes, including project managers,
resource managers, and system administrators. You can nest
generalization relationships for undifferentiated classes as well as
types, interfaces, and differentiated classes. For example, project
managers, resource managers, and system administrators all could be
specializations of a human resource. A human resource, on the other
hand, could be a specialization of a worker, or a worker could be a
generalization of a human resource. A generalization between
undifferentiated classes allows us to reuse a
class's attributes, associations, operations, and
methods to define a new undifferentiated class. The relationships
among the undifferentiated classes just mentioned are shown in Figure 3-31.
Figure 3-31. Generalizations between classes
Figure 3-30 shows three generalization paths, while
Figure 3-31 combines three generalization paths from
the ProjectManager,
ResourceManager, and
SystemAdministrator classes into one path that
connects to the HumanResource class. Whenever
several paths of the same kind connect to a single element, the UML
allows you to combine those paths into a single path as shown in this
figure. Also, when paths cross but do not connect, the UML allows you
to show this with a small, semicircular jog by one of the paths, as
shown for the associations between the Worker
class and the UnitOfWork and
WorkProduct classes. The jog indicates that the
line with the jog does not connect in any way with the other line
passing through the jog.Given a specific class, any immediately more
general classes
are called parents or
super-classes. Any immediately more specific
classes are called children or
subclasses. General classes that are not parents
(i.e., not immediately more general) are called ancestors.
More specific
classes
that are not children (i.e., not immediately more specific)
are
called
descendants. Therefore, Figure 3-31 shows that the Worker class
is the parent of the HumanResource class, and the
ProjectManager,
ResourceManager, and
SystemAdministrator classes are the children of
the HumanResource class. It also shows that the
Worker class is an ancestor of the
ProjectManager,
ResourceManager, and
SystemAdministrator classes, and that these
classes are descendants of the Worker class.Because a generalization between two undifferentiated classes
indicates that objects of the more specific undifferentiated class
are more specialized objects of the more general undifferentiated
class, objects of the more specific undifferentiated class may be
substituted for objects of the more general undifferentiated class.
Therefore, Figure 3-31 shows that project manager,
resource manager, and system administrator objects may be substituted
for human resource objects.
3.4.1.3 Implementation classes
A generalization
between
implementation classes allows us to reuse an implementation
class's attributes, associations, operations, and
methods to define a new implementation class. Earlier, I raised the
possibility of implementing the classes shown in Figure 3-27 as database tables. In such a case, the three
implementation classes in Figure 3-27 could all be
specialized classes of a database table class. Figure 3-32 shows this by making
Employee, WorkOrder, and
Artifact into specializations of a more general
DatabaseTable class.
Figure 3-32. Generalizations between implementation classes
Because a generalization between a more general implementation class
and a more specific implementation class indicates that objects of
the more specific implementation class are specialized objects of the
general implementation class, objects of the specific implementation
class may be substituted for objects of the general implementation
class. Therefore, Figure 3-32 shows that employee,
work order, and artifact objects may be substituted for database
table objects.
3.4.1.4 Interfaces
The project manager,
human
resource, and system administrator interfaces shown in Figure 3-28 are more specific versions of the human
resource interface. A generalization between interfaces allows us to
reuse an interface's operations to define a new
interface. The relationships among the interfaces just mentioned are
shown in Figure 3-33.
Figure 3-33. Generalizations between interfaces
Because a generalization between a more general interface and a more
specific interface indicates that the more specific interface is a
specialized form of the more general interface, those classes that
provide the service defined by the more specific interface may also
provide the service defined by the more general interface. Therefore,
Figure 3-33 shows that those objects that provide
the project manager, human resource, and system administrator
interfaces also provide the human resource interface.
3.4.2 Realizations
A realization from a
source
element (called the
realization element) to a target element (called
the specification element) indicates that the
source element supports at least all the operations of the target
element without necessarily having to support any attributes or
associations of the target element. For example, an undifferentiated
class or implementation class may play the role defined by a type and
may provide the service defined by an interface, if the class
supports the operations defined by the type and interface. A
realization allows us to reuse the operations of types and interfaces
where a realization element is said to realize
its specification elements.A realization is shown as a dashed-line path from the source element
to the target element, with a large hollow triangle at the end of the
path connected to the target element. When the target element is an
interface shown as a small circle, the realization is shown as a
solid-line path connecting the source and interface.
3.4.2.1 Undifferentiated classes
Figure 3-29 shows a list of types
and
interfaces that the Worker class supports. Based
on Figure 3-29, Figure 3-34 shows
that the Worker class realizes those types and
interfaces. The source element is the Worker
class, and the other elements are the targets. Figure 3-29 shows how interfaces and types are used in the
various associations between the Worker class and
other classes, while Figure 3-34 shows that the
Worker class explicitly realizes these interfaces
and types independent of how they are used in relationships.
Figure 3-34. Realizations for the Worker class
Based on Figure 3-29, Figure 3-35
shows the interfaces work products realize. The source element is the
WorkProduct class and the other elements are the
targets.
Figure 3-35. Realizations for the WorkProduct class
Because a realization from a source class to a target element
indicates that objects of the source class support all the operations
of the target element, objects of the source class may be substituted
for objects of other classes that also realize the same target
element. Therefore, Figure 3-34 shows that a worker
object may be substituted for objects of other classes that realize
the same types and interfaces as the worker object, and objects of
other classes that realize the same types and interfaces as the
worker object may be substituted for worker objects. That is, if two
objects realize the same type or interface, they may be substituted
for one another. Figure 3-35 illustrates this.
3.4.2.2 Implementation classes
Based on Figure 3-27, Figure 3-36
shows
that
the Worker class may be implemented as an employee
table, the WorkProduct class may be implemented as
an artifact table, and the UnitOfWork class may be
implemented as work order table, if you are to implement your classes
in a database management system. This is indicated with the
realization relationships between the Employee
implementation class realizing the Worker class,
the WorkOrder implementation class realizing the
UnitOfWork class, and the
Artifact implementation class realizing the
WorkProduct class.
Figure 3-36. Realizations of undifferentiated classes by implementation classes
When an implementation class realizes an undifferentiated class, it
must also realize the types and interfaces that the undifferentiated
class realizes; otherwise, it could not play the roles defined by the
undifferentiated class's types and provide the
services defined by the undifferentiated class's
interfaces.Based on Figure 3-36 and Figure 3-34, Figure 3-37 shows the types
and interfaces the Employee implementation class
realizes.
Figure 3-37. Realizations for the Employee implementation class
Based on Figure 3-36 and Figure 3-35, Figure 3-38 shows the
interfaces the Artifact implementation class
realizes.
Figure 3-38. Realizations for the Artifact implementation class
Because a realization from a source class to a target element
indicates that objects of the source class support all the operations
of the target element, objects of the source class may be substituted
for objects of other classes that also realize the same target
element. Therefore, Figure 3-37 shows that an
employee object may be substituted for objects of other classes that
realize the same types and interfaces as the employee object, and
objects of other classes that realize the same types and interfaces
as the employee object may be substituted for employee objects. Figure 3-38 shows the same for an artifact object.
3.4.3 Dependencies
A dependency from a source element
(
called
the client) to a target element (called the
supplier) indicates that the source element uses
or depends on the target element; if the target element changes, the
source element may require a change. For example, a
UnitOfWork uses the IConsumable
interface as a consumer and uses the IProducible
interface as a producer; if either interface changes, the
UnitOfWork may require a change. Figure 3-29 shows the interfaces used by
UnitOfWork.A dependency is shown as a dashed-line path from the source element
to the target element. The dependency may be marked with the
use keyword; however, the keyword is often omitted
because the meaning is evident from how the dependency is used. Also,
notice that a dependency does not have a large hollow triangle at the
end of the path, but has an open arrow.Based on Figure 3-29, Figure 3-39
shows the dependencies between units of work and work products.
Notice that a realization may be shown as a dependency marked with
the realize keyword, as shown in Figure 3-39 between the WorkProduct
class and the IProducible interface.
Figure 3-39. Realizations and dependencies
Figure 3-40 shows the dependencies between the
interfaces discussed in this chapter and the parameter and return
types for their operations. For example,
IProjectManager must depend on
Project, because many of its operations take a
Project object as a parameter.
Figure 3-40. Dependencies between interfaces and return types
