Example: Variability Forms
This example presents three cases that illustrate forms of variability.
Relationships
Main Description

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.