Introduction

The service designer must be aware that in forming a Artifact: Service Specification they have to balance two competing forces;

• Specialization; the need to ensure that a service does what is required of it, fulfilling the function identified during the Activity: Existing Asset Analysis.
• Generalization; the need to ensure that a service is as reusable as possible, in that future requirements do not require major redesign of existing services.

To this end, the designer may employ techniques commonly termed "Commonality and Variability" analysis. These techniques have been known and documented for some time, predominantly in the area of pattern formulation [Coplien, Gabriel] and software product line engineering [GBS, JGBS01, JB02, MRR04, Parnas, SBM01]. These are areas where the designer is also balancing these same forces in patterns - the need to capture the variability as parameters for the pattern, to allow for the pattern's applicability in different situations.

In the literature on patterns [Coplien] describes commonality as "the essence of an abstraction", and variability as "the spice of life" while [Gabriel] more concretely describes the relationship between commonality and abstraction -- a good abstraction needs to capture the common aspects across the solution while specifying the variabilities of individual elements.

Abstraction in programming is the process of identifying common patterns that have systematic variations; an abstraction represents the common pattern and provides a means for specifying which variation to use.

In similar terms [Parnas] defines a family of programs (we would tend to describe in terms of software product lines today) based on the common properties of the set and the special properties of the individual members:

We consider a set of programs to constitute a family, whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members

Capturing Variability

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 done 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 allows 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 variabilityis 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 (e.g., Customer Type) is associated with Customer Rules that span all customers and allow refinements and extensions to be made through specific Rule Types for each type of Customer.

The first step in the analysis is the identification of 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 (e.g. 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 may 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.

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 may 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

References

[Arsanjani]    A. Arsanjani. Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules. Washington University Technical Report number:  wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

[Coplien]    J. O. Coplien. Multi-Paradigm Design for C++. Addison-Wesley Professional; 1st edition, 1998.

[Gabriel]    R. P. Gabriel. Patterns of Software: Tales from the Software Community. Oxford University Press, 1998.

[GBS]    J. van Gurp, J. Bosch and M. Svahnberg. Managing Variability in Software Product Lines. http://citeseer.ist.psu.edu/568368.html

[GHJV]    E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns. Addision-Wesley 1994.

[JGBS01]    J. van Gurp, J. Bosch, and M. Svahnberg. On the notion of variability in software product lines. In Proceedings 2nd Working IEEE / IFIP Conference on Software Architecture (WICSA), pages 45--54. IEEE Computer Society, 2001. http://citeseer.ist.psu.edu/vangurp01notion.html

[JB02]    M. Jaring, J. Bosch, Representing Variability in Software Product Lines: A Case Study, to appear in the Second Product Line Conference (SPLC-2), San Diego CA, August 19-22, 2002. http://citeseer.ist.psu.edu/jaring02representing.html

[MRR04]    Jurgen Meister, Ralf Reussner, and Martin Rohde. Managing Product Line Variability by Patterns. http://se.informatik.uni-oldenburg.de/pubdb_files/pdf/ManagingProductLineVariabilityByPatterns-Final.pdf

[Parnas]    D. L. Parnas. On the Design and Development of Program Families. IEEE Transactions on Software Engineering, SE-2(1):1--9, 1976.

[SBM01]    A. Stephenson, D. Buttle and J. McDermid. Extending Commonality Analysis for Embedded Control System Families. Lecture Notes in Computer Science, Volume 1951, 2001. http://citeseer.ist.psu.edu/stephenson51extending.html

[SGB01]    M. Svahnberg, J. van Gurp, J. Bosch, A Taxonomy of Variability Realization Techniques, submitted June 2001. http://citeseer.ist.psu.edu/svahnberg01taxonomy.html