The service designer must be aware that in forming a ServiceInterface they have to balance two competing forces;
-
Specialization; the need to ensure that a service does what is required of it.
-
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 might 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 [ARS00, COP98, GAB98] and software product line engineering [GBS00, GBS01, JB02, MRR04, PRN76, 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 enable the pattern's
applicability in different situations.
In the literature on patterns, [COP98] describes commonality as "the essence of an abstraction", and
variability as "the spice of life" while [GAB98] 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 [PRN76] 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
|