Figure 1 demonstrates the notion of variability by role, where we have a new collaboration "Sale" which denotes the
relationship between a seller and purchaser as parties to a contract. In UML it is then possible to create a
Collaboration Use which binds the roles "purchaser" and "seller" to actual model elements.
Figure 1. Variability by collaboration role, to be realized using Collaboration Uses
As an alternative, the next example examines the process of sale using an escrow service. We capture the
required capabilities of any escrow service as an interface, with a set of operations corresponding to the
responsibilities we expect the escrow service to perform. With this we create a templated collaboration where we use
the escrow interface as the type of the template parameter. Now it is possible to instantiate the template providing
any class or component that realizes the IEscrowService interface. This approach is illustrated in Figure 2.
Figure 2. Representing variability using a parameterized template
Finally, we might more simply use a component (or class) to contain our common elements and have it require the
IEscrowService interface using the UML 2.0 <<use>> relationship as shown in the diagram below. This
approach is certainly valuable at a design level as it is also a common programming approach in Component-Based
Development or even just in languages such as Java. Figure 3 illustrates how to model this approach.
Figure 3. Representing implementation variability with a <<used>> interface
The choice of technique will, as usual, depend on the situation including considerations such as:
-
The kind of variability being expressed, as we have seen above.
-
Whether the elements are parts of an analysis, design or implementation model.
-
The skills and expectations of the stakeholders in the model.
|