لطفا منتظر باشید ...
3.3 Types, Implementation Classes, and Interfaces
The kinds of classes discussed
thus far are known as
undifferentiated classes, and are commonly used
during design activities within a development process. You can also
differentiate between three different kinds of classes, called
differentiated classes. These include:
Types
Implementation classes
Interfaces
These differentiated classes closely relate to different activities
in the development process. The next few sections discuss these
differentiated classes.
3.3.1 Types
A type is a class that may have
attributes,
associations, and operations, but does not have any methods. A type
defines a role an object may play relative to other objects, similar
to how a rolename indicates the role a class plays relative to other
classes in an association. For example, a Worker
object may play the role of a project manager, resource manager,
human resource, or system administrator. A type is shown as a class
marked with the type keyword. These types of
workers are shown in Figure 3-25.
Figure 3-25. Types
Types are commonly used during analysis activities within a
development process to identify the kinds of objects a system may
require. You can think of types as conceptual classes, because they
are ideas for possible classes. Also, because types do not have
methods and represent roles only, they do not have instances.Types may be used with
binary and
n-ary association and link ends. A comma-separated list of one or
more type names may be placed following a rolename to indicate the
roles a class or object plays in the relationship. Separate the
rolename from the list of types using a colon. If no rolename is
used, the type names are placed following a colon.Figure 3-13. It
shows the various roles a worker may play relative to work products
and units of work. A worker may be a project manager, resource
manager, human resource, and system administrator.
Figure 3-26. Types with association ends
3.3.2 Implementation Classes
An implementation class is
a class that may have attributes,
associations, operations, and methods. An implementation class
defines the physical implementation of objects of a class. For
example, if you were to implement our classes in a database
management system, the Worker class might be
implemented as an employee table, the WorkProduct
class might be implemented as an artifact table, and the
UnitOfWork class might be implemented as work
order table. An implementation class is shown as a class marked with
the
implementationClass keyword. The three
implementation classes just mentioned are shown in Figure 3-27.
Figure 3-27. Implementation classes
Implementation classes are commonly used during the later part of
design and during implementation activities within a development
process to identify how objects are implemented for a system. You can
think about implementation classes as physical
"code" classes because, they are
physical implementations of classes.
3.3.3 Interfaces
An interface is a class that may
have operations
but may not have attributes, associations, or methods. An interface
defines a service or contract as a collection of public operations.
For example, a project manager must be able to initiate and terminate
a project, plan and manage a project while leading a team, and so
forth. A resource manager must be able to assign and unassign human
resources to and from a team. A work product must be producible and
consumable; it is produced by being created or written, and consumed
by being read or destroyed. Interfaces can be used to define these
collections of operations.An interface is shown as a class marked with the
interface keyword, and because interfaces
don't have attributes, the second compartment is
always empty and, therefore, not shown. An interface also may be
shown as a small circle with the interface name placed near the
symbol and the operations of the interface not shown. Examples of
both interface representations are shown in Figure 3-28.
Figure 3-28. Interfaces
Interfaces are commonly used during analysis and design activities
within a development process to identify services that classes and
their objects provide. You can think of interfaces as
application
programming interfaces (APIs), because they define a collection of
operations that are commonly used together and thus define a more
general service. Because interfaces do not have methods but merely
represent services, they do not have instances.Interfaces may be used with
binary and
n-ary association and link ends to indicate the services (or
interfaces) that a class provides in the relationship. Begin with a
rolename followed by a colon, then add a comma-separated list of one
or more interface names, as shown in Figure 3-29.Figure 3-29 uses the interfaces from Figure 3-28 to update Figure 3-26. It
shows the various services a work product provides to units of work,
including an interface for consumption of the work product and an
interface for production of the work product. It also shows the
various interfaces a worker provides in association with work
products and units of work. Interfaces and types may be listed
together, but types are more commonly used during analysis
activities, while interfaces are more commonly used during analysis
and design activities. Because both interfaces and types may be used
during analysis and design, it is very important to have a standard
naming convention. For example, one convention is to prefix
interfaces with an I and to prefix types with a
T.
Figure 3-29. Interfaces with association ends
