لطفا منتظر باشید ...
3.5 Packages and Subsystems
As a model may have
hundreds (if not
thousands) of model elements, how do you organize the elements that
make up a system and their relationships? And how do you use this
information to determine how best to develop the system while
considering technical trade-offs concerning the system, including
which elements may be developed in parallel, which elements may be
purchased rather than built, and which elements may be reused?
Packages and
subsystems,
called model management elements, address these
questions.
3.5.1 Packages
A package is a grouping
and organizing
element in which other elements reside, which must be uniquely named.
In the UML, packages are used in a manner similar to the way
directories and folders in an operating system group and organize
files. For example, the project management system may be decomposed
into a collection of classes organized into packages as follows:
Utility
Date, time, and other
utility
classes
Workers
The Worker class and
any
other worker-related classes in which the Worker
class is contained inside of a package named
Generic
Generic
Generic classes such as
the
Worker class and any other worker-related classes
Work Units
The UnitOfWork class and
any other work-related classes
Work Products
The WorkProduct class and
any other work product-related classes
User Interface
A package housing classes
responsible for providing a user
interface through which users may interact with the system
Business Processing
A package housing classes
responsible for implementing
business functionality
Data
A package housing classes
responsible
for implementing data storage functionality
Packages allow us to partition our system into logical groups and
then to relate these logical groups; otherwise, it could become
overwhelming to work with every class and its relationship at once. A
package is shown as a large rectangle with a small rectangle or
"tab" attached to its top, left
side. The packages in the previous list, together with their
relationships, are shown in Figure 3-41.
Figure 3-41. Packages
You can show the name of a package inside of its large rectangle when
the package contents are not shown; otherwise, when the package
contents are shown in the large rectangle, you should show the name
of a package inside its tab. In Figure 3-41, you see
that the User Interface,
Utility, and Business
Processing packages don't show
their contents, while all the other packages do show some of their
contents. Thus, the User
Interface, Utility, and
Business Processing packages
have their package names within the large rectangle, whereas the
other packages have their names in their respective tabs. Each
element inside a package may have a visibility symbol indicating
whether the element is accessible from outside its package (i.e., is
public). Figure 3-41 shows that the
Worker, UnitOfWork, and
WorkProduct classes are public. The
Generic package located inside of the
Workers package is also public.A dependency from a source
package
to a target package indicates that the contents of the source package
use the contents of the target package. Figure 3-41
shows that the Data package uses the
Workers, Work
Units, and Work
Products packages. It also shows that the
User Interface,
Business Processing, and
Data packages use the Utility
package, while the User
Interface package uses the
Business Processing package,
which in turn uses the Data package.A package defines a namespace, a
part
of a model in which a name must be unique. An element shown in a
package is most likely defined in that package if it is simply named.
For example, the Work Units package in Figure 3-41 defines one public class named
UnitOfWork. You can show the
UnitOfWork class in other packages to indicate
that those packages use the class, in which case you qualify the
class name with the path to the package in which the class is
defined. Such a fully qualified name is referred to as a pathname.
The pathname of an element
is
a sequence of package names linked together and separated by double
colons (::), followed by the name of the element.
The sequence of package names starts from the outermost package level
and works its way down to the package containing the element in
question. Figure 3-41 shows that the
Data package uses the following:
Workers::Generic::Worker
The Worker class located inside the
Generic package, which is nested inside the
Workers package
Work Units::UnitOfWork
The UnitOfWork class located inside the
Work Units package
Work Products::WorkProduct
The WorkProduct class located inside the
Work Products package
3.5.2 Subsystems
Recall that a system is an organized collection
of elements that may be recursively decomposed into smaller
subsystems and eventually into nondecomposable primitive elements.
For example, the project management system may be decomposed into the
following:
A user interface subsystem responsible for providing a user interface
through which users may interact with the system
A business processing subsystem responsible for implementing business
functionality
A data subsystem responsible for implementing data storage
functionality
The primitive elements would be the various classes that are used in
these subsystems and ultimately in the whole system. While a package
simply groups elements, a subsystem groups elements that together
provide services such that other elements may access only those
services and none of the elements themselves. And while packages
allow us to partition our system into logical groups and relate these
logical groups, subsystems allow us to consider what services these
logical groups provide to one another.A subsystem is shown as a package
marked
with the subsystem keyword. The large package
rectangle may have three standard compartments shown by dividing the
rectangle with a vertical line and then dividing the area to the left
of this line into two compartments with a horizontal line. Figure 3-42 shows how a Data subsystem
for our project management system might look. The
subsystem's operations, specification elements, and
interfaces describe the services the subsystem provides, and are the
only services accessible by other elements outside the subsystem.
Figure 3-42. A subsystem's representation in the UML
The upper-left compartment shows a list of operations that the
subsystem realizes. The lower-left compartment may be labeled
"Specification Elements" and shows
specification elements that the subsystem realizes. For example, any
use cases that the subsystem provides are specification elements that
the subsystem must realize. The right compartment may be labeled
"Realization Elements" and shows
elements inside the subsystem that realize the
subsystem's operations and specification elements as
well as any interfaces that the subsystem provides. You can modify
this general notation by rearranging compartments, combining
compartments, or completely suppressing one or more compartments. Any
element may be used as a specification or realization element,
because a realization simply indicates that the realization element
supports at least all the operations of the specification element
without necessarily having to support any attributes or associations
of the specification element.Figure 3-43 uses subsystems to refine Figure 3-41. The Business Processing
and Data packages from Figure 3-41 are now subsystems. The Business
Processing subsystem provides an interface that is used by
the User Interface package. The
Business Processing subsystem
itself uses the Data subsystem and the
IProducible interface provided by the
Data subsystem. The Data
subsystem realizes the IProducible interface,
which is outside the subsystem itself, various operations, and the
Manage Project use case that
was discussed in Chapter 2. The use case is the
oval in the specification element's compartment. The
realization elements of the Data subsystem realize
the read, destroy, and
doWork operations, the use case, and the
operations of the IProducible interface.
Figure 3-43. Subsystems
Notice in Figure 3-43 that the
User Interface package does not
use the Business Processing
package as shown in Figure 3-41, but instead uses
the IBusinessProcessing interface provided by the
Business Processing subsystem.
This use of an interface allows us to focus on the service that the
User Interface package uses rather than on the
package providing the service. If you focus on the fact that the
User Interface package uses the
Business Processing package,
you are unaware of the exact operations the User
Interface package requires from the
Business Processing package; if
there is a change to the Business
Processing package, you would have to expend
significant effort to determine whether the change requires modifying
the User Interface package. By
focusing on the service that the User
Interface package uses rather than the package
providing the service, you are aware of the exact operations used
from the package providing the service; only if there is a change to
the service or to those operations do you have to expend effort to
determine whether the change requires modifying the
User Interface package. Rather
than having to consider all the operations available inside the
Business Processing package to
determine whether changes to that package impact the
User Interface package, you
need only look at a subset of those operations: the subset defined by
the IBusinessProcess interface. Similarly, notice
how the Business Processing
package uses the Data package in Figure 3-41, but the Business
Processing subsystem uses the operations,
specification elements, and IProducible interface
provided by the Data subsystem in Figure 3-43.Figure 3-43 shows the major elements that make up
the project management system and the relationships between them.
Using packages, subsystems, interfaces, and their relationships, you
can more readily consider which elements may be developed in
parallel, which elements may be purchased rather than built, and
which elements may be reused. It is possible to address these issues
with classes and their relationships, but because a system may have
many classes, it can easily become overwhelming to work with such
granularity. You could also address these issues by using packages
and their dependencies, but packages don't offer
services. Packages simply capture the major elements that make up a
system and not the services that are being used from a package. Thus,
you must focus on all the contents of a package rather than on the
services used by elements that depend on the package. However, by
using packages, subsystems, interfaces, and their relationships, you
can more readily address the issues listed earlier, because you
capture the major elements making up the system, as well as the
services that are provided and required for these elements to work
together to provide the functionality of the system.Because a subsystem's operations, specification
elements, and interfaces describe the services the subsystem
provides, which are the only services accessible by other elements
outside the subsystem, any collection of subsystems may be developed
in parallel, because any interdependencies between them rely only on
their services. For example, you may develop the
Data subsystem and Business
Processing subsystem in parallel, because any elements that
use these subsystems always use the defined services.Because a subsystem's services are fully specified,
you can attempt to search for and purchase (rather than build) a
subsystem that provides the same services. For example, you may not
have enough funding to build the Data subsystem,
but because you know the services of the subsystem, you can attempt
to search and purchase a similar subsystem that offers the same
services.Because a subsystem's services are fully specified,
you can reuse the subsystem whenever you require similar services.
For example, whenever you require services defined by the
IBusinessProcessing interface, you can reuse any
subsystem that provides the interface; whenever you require services
defined by the IProducible interface, the
read operation, the destroy
operation, the doWork operation, or the
Manage Project use case, you
can reuse any subsystem that provides any of these services.
