Guideline: Considerations for Identifying Subsystem Dependencies
Subsystem dependencies arise from many causes. Several of these are discussed here, as are ways to document the dependencies graphically.
Main Description

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:

  1. 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.
  2. 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>>.
More Information
Concepts