Discovering Variability

How do you figure out where the variability is?

With any of these approaches my aim would always be to do it in an extractive and reactive way — you already have some software implemented, a new customer comes along, you see how it fits in to what assets you already have.

With CVA

Commonality and variability analysis identifies a conceptual view (the commonalities) and an implementation view (each particular variation.)

  • Use CVA to identify the concepts (commonalities, or in OVM terms variation points) and concrete implementations (variabilities, or variants) that are present in the problem domain
  • After the concept for the functionality has been identified
    • specify the interface for the abstraction that encapsulates this
    • derive this interface by considering how the concrete implementations derived from this abstraction will be used

One approach to CVA is to identify any two items in the problem domain and ask the following questions:

  • is one of these a variation of the other?
  • are both of these a variation of something else?

Another approach is to look at the problem and identify the major concepts.

Commonalities should be based on one issue per commonality.

The first step is representing the concepts. The next step involves determining how the concepts relate to each other. Both of these steps together can be represented in a conceptual class diagram. From here the concepts can be ordered into patterns.

  1. Identify commonalities first
  2. Create abstractions from these
  3. Identify derivations with the variations of the commonalities
  4. See how the commonalities relate to each other


Pick 2 objects in the domain and brainstorm the things they have in common. Ask the questions: what do we want to be open-closed to? Where do we want to allow for extension? When looking at commonalities, try not to be too ‘data-centric’ (e.g. focusing on things like dimensions, weight, size, etc.) or too ‘function-centric’ either. From this collection, pick out the relevant commonalities for a given application. Not all of them may be relevant. For example: if we’re comparing two objects from our domain, a pen and a pencil, we may not care about the fact that they are both cylindrical, but we may well be interested in the fact they are both writing implements.

CVA is is-a relationships. Design to interfaces.


Variability only makes sense in the context of a given commonality. For example, if we are interested in the WritingImplement commonality, we may be interested to notice as a writing implement one can be erased whereas the other can’t. Within the scope of a given commonality, not all variabilities may be of interest.

Some commonalities/variabilities are about when things apply. Some are about how things apply. Some are about state.


To the index!