Guideline: Variability Analysis
Variability analysis creates a model that separates the changing from the more stable aspects of the domain model. This allows the externalization of anticipated types of changes and their corresponding rules, allowing future non-intrusive introduction of changes to the existing design.
Relationships
Main Description

Many systems are built with very little foresight for incorporating changes resulting from new requirements. Commonality and Variability Analysis creates a resilient design that is far more adaptive to change. This is achieved by avoiding the hard-coding or hard-designing of aspects of the domain that are anticipated to change through the process of externalization: separating out the more rapidly changing aspects of the functional and structural aspects of the domain from the more stable, non-changing aspects. This technique enables the system's design to evolve and grow due to new requirements without intrusive alterations. During analysis, commonalities and variabilities are modeled in terms of Type Hierarchies. Each point of variability is identified and externalized. For example, the instances of variation such as Organizational Customer and Individual Customer can be modeled as two realizations of a Customer Type that can then be expanded as needed. The externalized type (for example, Customer Type) is associated with Customer Rules that span all customers and enable refinements and extensions to be made through specific Rule Types for each type of Customer.

The first step in the analysis is identifying dependencies on Type from both functional (static) and process (dynamic) perspectives. Identifying types of processes that rely on types of entities (functional) is a good heuristic for the design refactoring:

  • Identify common elements of function and process (such as, Reservation business process).
  • Separate changing from less changing aspects. Identify key types related to function and process that are anticipated to change or are dependent (Reservation Type varies based on Customer Type -- if Customer Type changes, Reservation Type might change as a result).
  • Externalize the variations and create type hierarchies with known instances (Frequency Type is Preferred or Regular, Party is Organizational or Individual).

These variability points are a key part of building systems that are resilient and adaptive. By externalizing variability points, we can modify them without impacting the rest of the design. Thus, the ripple effect of change is contained and constrained by the variability points. A UML class diagram showing this hierarchy provides a roadmap for detailed design and ultimately, implementation.

The basic principles of commonality and variability design are therefore:

  1. Separate changing from non-changing aspects of a domain
  2. Separate the interface from implementation
  3. Reify what changes. If some element of the domain is in constant flux, then it might be warranted to reify that element into a class (or higher layer of reuse).
  4. Build assets at each reuse level. The Reuse Levels are: base class, inheritance hierarchy, aggregation hierarchy, cluster, framework, component, pattern, generic architecture.
  5. Each reuse element has its own rules of behavior in addition to the meta-data necessary to reflectively and adaptively self-describe the Reuse Element for run-time queries for service capabilities
More Information