Standards:
Formal <<subsystem>>
|
A subsystem that has been modeled formally. See <<subsystem>> for background
and details. |
Related Information: |
|
Topics
Introduction
Structuring a system into subsystems helps reduce
complexity, promote reuse and enable parallel development.
A logical subsystem (the design of a component system) exports only a subset of its
types, classes and other work products to re-users. The remaining work products are
hidden. This separation insulates a re-user from the specific details of how a component
system is implemented, and allows internal changes without necessarily impacting the
re-user.
If the subsystem is modeled formally then this separation of interface from
implementation is modeled using separate facade and implementation packages.
The facades thus encapsulate the internals of the subsystem in order to minimize
dependencies, and rippling change, as the subsystem evolves. Each façade acts as a kind
of public interface to the subsystem.
The façade is the re-user's view of the subsystem. It simplifies the job for
re-users who wish to use the subsystem (and therefore the components) presented by the
façade.
The formal modeling of subsystems is used when:
- There are many dependencies between clients and the implementation classes of an
abstraction. Facades are introduced to de-couple the subsystem from clients, and
other subsystems, thereby promoting subsystem independence and portability.
- You want to layer your subsystems. Use a façade to define an entry point to each
subsystem level. If subsystems are dependent, then you can simplify the dependencies
between them by making them communicate with each other solely through their facades.
The formal modeling of subsystems offers the following benefits:
- It shields clients from the implementation details of subsystems/components, thereby
reducing the number of objects that clients deal with and making the subsystem easier to
use
- It provides a simple, intuitive way of modeling subsystems and their implementations.
- It promotes weak coupling between the subsystem and its clients. Often the components in
a subsystem are strongly coupled. Weak coupling lets you vary the components of the
subsystem without affecting the clients.
- It helps layer a system and manage the dependencies between objects. This can be
an important consequence when the client and the subsystems are implemented independently.
- When modeling the subsystem's clients only the Façade needs to be loaded into the
client model.
When a subsystem is defined formally then the subsystem's interface is defined in a
different package to the implementation of the subsystem. The interface is defined
in a <<facade>> package (see Standards: Facade Package)
and the implementation of the subsystem is defined in an <<implementation>>
package (see Standards: Implementation Package).
When this pattern is adopted the consumer of the subsystem only needs to import the
<<facade>> package and any other packages upon which the
<<facade>> package is dependent. The implementation packages are not
required when designing and documenting the client systems.
Naming Standard
The general package naming standards apply to <<subsystem>> packages
(See Standards: Package Overview).
Diagramming Standards
When subsystems are modeled formally the following diagramming standards are applied
to the subsystem package itself. See Standards: Facade
Package and Standards: Implementation Package for details of
the diagramming standards to applied to the facade and implementation packages.
Diagram |
Purpose |
Use |
Comment |
Main |
A class diagram showing the facade and
implementation packages that define and implement the subsystem. |
Mandatory |
All of the illustrative diagrams in the Applying the Pattern / Examples section below are
examples of subsystem Main diagrams.Note:
You should never attempt to combine this diagram with any other diagrams. |
Dependencies |
A class diagram showing which other packages
the subsystem is dependent on. |
Optional |
This diagram can be used to show the other
subsystems the subsystem is dependent on. This can be useful to position the
subsystem in the context of the other parts of the system.This diagram is not mandatory as the dependencies will be defined by the
subsystem's facade and implementation packages. |
Welcome |
A class diagram presenting the purpose of the
interface. |
Optional |
An explanatory diagram welcoming users to the
interface. |
Constraints
A formally defined subsystem can only contain facade
and implementation packages.
Applying the
Pattern
Inside the subsystem will be the façade, defining the subsystems interface, and the
implementation, containing the internal design of the subsystem:
A subsystem can offer multiple facades:
A subsystem may have many implementations:
For the full modeling, and documentation, standards for the facade and implementation
packages see Standards: Facade Package and Standards:
Implementation Package.
Examples
The Database Services subsystem has been modeled formally. The subsystem is
shown below with its Main diagram displayed.
This quite clearly shows that there are two implementations of the Database Access
facade.
The Dependencies diagram is also of interest as
this shows where the Database Services subsystem fits into the network of subsystems:
Background
This definition of the façade pattern is a specialization of the definitions presented
by the Unified Modeling Language [UML] and the classic Design Patterns
book [DP].
The UML definition of <<façade>> (stereotype of package) is:
A stereotyped package containing nothing but references to model elements owned by
another package. It is used to provide a public view of some of the contents of a package.
A façade does not contain any model elements of its own i.e. a package that is only a
view on some other package.
The Design Patterns definition of the façade pattern is:
The façade pattern provides a uniform interface to a set of interfaces in a subsystem.
Façade defines a higher-level interface that makes the subsystem easier to use.
The only real difference between the UML definition and the definition used here is
that in this definition the façade is used to define the interface of a subsystem and can
contain, as well as import, the model items making up the interface.
This definition of the Façade pattern draws upon the following references:
Software Reuse: Architecture, Process and Organization for Business Success - Ivar
Jacobson, Martin Griss and Patrik Jonsson
The Unified Modeling Language User Guide - Grady Booch, James Rumbaugh and Ivar
Jacobson
The Unified Modeling Language Reference Manual - James Rumbaugh, Ivar
Jacobson and Grady Booch
Analysis Patterns: Reusable Object Models - Martin Fowler
Pattern-Oriented Software Architecture: A System of Patterns - Frank Buschmann, Regine
Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal
Design Patterns: Elements of Reusable Object-Oriented Software - Erich
Gamma, Richard Helm, Ralph Johnson, John Vlissides
Rose Architect: Modeling Large Systems - Magnus Christerson and Nils Unden
|