Software Engineers Notebook

Software Engineering notes to myself that you may find useful too

View on GitHub
18 September 2018

Commonality Variability Analysis

by Martyn Butterworth

A principle of good software design is to separate things that change from those that do not. Commonality variability analysis is a way of achieving this.


Commonality variability analysis helps us to focus on interfaces and stop us from looking at implementation too soon. It leads us to hide the implementation by focussing on the abstractions first. It encourages us to look at the high and low level aspects of design, but separately. It helps us to design by contract, thus creating an architecture that is more testable.

Commonality Analysis

This is the search for common elements that help us understand how members are the same. They are:

The commonalities define the basic concepts in a problem domain. Avoid thinking just in terms of data or function, for example, a pen and a book may be classed as common because they are used for teaching/communication, or are both portable.

Varibility Analysis

This is the next step after deciding on a commonality. It should be done within the context of the commonality by asking, how do these things vary. Using an example of different kinds of pen, if the commonality is “writing instrument”, then the variabilities might be what they can write on and line thickness etc. However, if the commonality is “plastic things”, then the previous variabilities don’t apply and instead we should have variabilities like type of plastic and amount of plastic.

In the case of the “writing instrument” commonality, a (traditional) pencil would plug in to this model. However it would not plug in to the “plastic things” commonality. Therefore if you know that you want to extend your commonality to include pencils, then “plastic things” is probably not the correct commonality.


You are looking for the “is-a” relationships. Other relationships such as “uses”, “contains”, “builds” or “knows-of”, and grouping things just because they go together are not a part of commonality variability analysis. These are what design patterns are concerned with, so these relationships should be dealt with later to avoid prematurely coupling objects.

Not all commonalities are useful, so don’t be afraid to discard some.