What dependencies are and why knowing about them is
important
When an element contained by a subsystem uses some behavior of an element contained by another subsystem, a
dependency is created between the enclosing subsystems. Subsystem dependencies can have substantial impact on project
execution. For example:
- Knowing about dependencies helps establish the required order of construction.
- The subsystems that you depend on must be available before you can complete
the construction of your own subsystem. If it is likely that a required
subsystem will not be available during the timeframe of the current project,
mitigators must by defined and acted upon.
What causes dependencies
- The previously mentioned use of behavior of an element
contained by another subsystem.
- The use of data elements that are managed by services
that are contained by another subsystem.
- Temporal dependencies, when the capabilities of multiple
subsystems are involved in realizing a process that is managed externally
to any of the subsystems. These include:
-
- Precondition dependency: An interface operation of another subsystem
must have executed successfully before the current invocation can begin
execution.
- Processing dependency: Another subsystem's operation is required
to complete the successful execution of the current operation.
- Post-condition dependency: This occurs when a subsystem
operation requires invoking another subsystem operation after its
execution.
How to express dependencies
To improve reuse and reduce maintenance dependencies, express this in terms
of a dependency on a particular Interface of the subsystem, not upon the subsystem
itself, nor on the element contained in the subsystem.
The reason for this is two-fold:
- You need to be able to substitute one model element (including subsystems)
for another as long as the two offer the same behavior. You specify the
required behavior in terms of interfaces, so any behavioral requirements one
model element has on another needs to be expressed in terms of interfaces.
- You need to give the designer total freedom in designing the internal
behavior of the subsystem, as long as it provides the correct external behavior.
If a model element in one subsystem references a model element in another
subsystem, the designer is no longer free to remove that model element or
redistribute the behavior of that model element to other elements. As a result,
the system is more brittle.
In creating dependencies, ensure that there are no direct dependencies or
associations between model elements contained by the subsystem and model elements
contained by other subsystems. Also ensure that there are no circular dependencies
between subsystems and interfaces; a subsystem cannot both realize an interface
and be dependent on it, as well.
How to model subsystems and their dependencies
The concepts that were used to describe the service
model apply equally well to modeling subsystems. In this case, we might
make some model element substitutions, such as these:
- Use a component stereotyped as <<subsystem>>
rather than a component stereotyped as <<Participant>>.
- Use an unstereotyped port, rather than a port stereotyped as <<Service
Point>> or <<Request
Point>>.
- Type the port with UML interfaces and classes, rather than interfaces and
classes that are stereotyped as <<Service
Interface>>.
|