Pattern 10: Keep Architectural Elements Decoupled
Reduce dependencies between Participants by enforcing local ownership of operation parameters, enumerations, messages, and provided service specifications.
Relationships
Main Description

Context

Rational Unified Process provides the following definition for coupling:

The degree to which components depend on one another. There are two types of coupling, tight and loose. Loose coupling is desirable to support an extensible software architecture, but tight coupling might be necessary for maximum performance. Coupling is increased when the data exchanged between components becomes larger or more complex.

Component, as it is used in this definition, is a piece of software that is encapsulated and forms a unit of independent deployment and versioning.

When components share artifacts it increases the coupling between them.

The specification of a component is made up of those artifacts that describe it from a black-box point of view.
Included in this are the following:

  • Service specification
  • Parameter types

Even if the implementations of a set of components are totally decoupled, if any of the components share parts of their specification then this increases coupling.

Problem

Sharing specification artifacts between Participants has some problematic side effects.

Forces

  • Changes to these shared specification artifacts affect multiple Participants.
  • Where specialized versions of parameter types are required, there is a mixture of shared parameter types and specialized "local" parameter types, which is slightly more complex than just having local parameter types.
  •  The size of the shared service specification artifacts library quickly grows in size. Factoring these out into separate libraries based on some factoring rule itself becomes quite complex.

Solution

Each Participant needs to own its:

Each Participant also needs to own its info types as well, but this is by definition as info types are used to model data ownership (see Pattern 08: Model Data Control Points).

In this way the specification of the Participant is totally decoupled from other specifications. The only resources shared between Participants are primitive types.

For composite business application services, where a Participant both provides and requests services, there is some coupling between the composite business application service and the Participant providing the services that it requires. You can break this coupling by introducing a local copy of the required service specification.

Although it seems like substantial additional work to maintain separate copies of certain specification artifacts (where they look the same across multiple service providers), this can be reduced (or even negated in some cases) by using Rational Software Architect transformations-for example from domain types to parameter types.

Rationale

Not sharing specification artifacts prevents dependency issues as follows:

  • Changes to the specification artifacts mentioned above have only localized impact.
  • It is more clear as to where specification artifacts come from when they are used, as they are all local-in other words, there is no combination of local and shared specification artifacts in use in a Participant specification.
  • No rules are required for when to factor a specification artifact out as a shared artifact.

Note

In this pattern, we talk about keeping architectural elements decoupled, where the architectural elements are the specification-level modeling elements from the service model. Keeping these architectural elements decoupled does not imply that the realization or implementation of these elements (for example, the code) will be decoupled as well.


More Information