Design Subsystems are used to encapsulate behavior inside a
"package" which is provides explicit and formal interfaces, and which
(by convention) does not expose any of its internal contents. It is used as a
unit of behavior in the system, which provides the ability to completely
encapsulate the interactions of a number of class and/or subsystems. The
'encapsulation' ability of design subsystems is contrasted by that of the Artifact:
Design Package, which does not realize interfaces, and may expose contents
which are marked 'public'. Packages are used primarily for configuration
management and model organization, where subsystems provide additional
name of the subsystem
short description of the role and purpose, or the "theme" of the
to realized interfaces
associations to contained model elements
associations to interfaces or packages on which the subsystem depends
diagrams local to the subsystem, such as class diagrams or statechart
by an enclosing package, via the aggregation "owns".
The Design Subsystem is created during Elaboration Phase, as major
functionality is partitioned into 'chunks' which can be developed.
A Designer is responsible for the
integrity of the design subsystem, ensuring that:
- The subsystem encapsulates its contents, only exposing contained behavior
through interfaces it realizes.
- The operations of the interfaces the Subsystem realizes are distributed to
contained classes or subsystems.
- The subsystem properly implements its interfaces.
Design subsystems are useful in several contexts:
- To model large-grained structures in the design model. These subsystems
will typically be decomposed into other subsystems, and eventually classes,
and represent large subsystems or systems which are used to compose the
system. A small system will not tend to use subsystems in this way.
- To model components in the design model. These subsystems generally have a
1:1 mapping to an executable component in the Implementation Model. Here you
are modeling something at design time which you intend to be a separately
constructed thinga componentat implementation time. This separately
constructed thing will itself be built from several classes (or subsystems).
Contrast this with the first case, where, in the implementation model, the
design subsystem may become simply a notional boundary around a collection
of classes (which become components in the implementation model).
© 1987 - 2001 Rational Software Corporation