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:
-
Separate changing from non-changing aspects of a domain
-
Separate the interface from implementation
-
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).
-
Build assets at each reuse level. The Reuse Levels are: base class, inheritance hierarchy, aggregation hierarchy,
cluster, framework, component, pattern, generic architecture.
-
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
|