7.4 Identification of a framework s variation points

7.4 Identification of a framework's variation points

What makes a 'good' framework? Actually, this provocative and probably oversimplified question cannot be answered without understanding the relevant domain and its inherent flexibility requirements. In other words, striving for flexibility for flexibility's sake, achieved by incorporating as many design patterns as possible, does not result in a good framework. On the contrary, unnecessary flexibility leads to significantly more complexity. Frameworks must be adaptable in an adequate way depending on domain-specific requirements.

Overall, flexibility has to be injected into a framework in appropriate doses.^[2] As the quality of a framework depends directly on the appropriateness of its variation points,^[3] the identification of those variation points must be an explicit activity in the framework development process. Means of documenting variation points and of communicating them among domain experts and software developers become crucial.

^[2] Parnas (1976) and Coplien (1999) discuss this issue in general, using the terms 'software family' and 'commonality/variability analysis'.

^[3] Pree (1995) uses the term 'hot-spot' as a synonym for variation point. As the term hot-spot has recently been used in the different context of an optimization technique for the execution of Java, we prefer to use variation point. Furthermore, the term 'variation point' triggers an association to the commonality/variability analysis originally proposed by Parnas (1976). In fact, the concepts of commonality/variability analysis and variation points are closely related.

This section first sketches a variation point driven framework development process and shows how that fits into the cluster cycle model. So-called variation point cards, as described by Pree (1995), represent another variant of CRC cards. They capture flexibility requirements. Variation point cards form the basis of transforming an object model into a domain-specific framework. They also correspond to domain-specific design patterns. Variation point cards are analogous to CRC cards, which help to define an initial object model. They document the flexibility requirements and form the basis of framework (re)design, whereas CRC cards comprise the principal entities of an object-oriented design and form the basis of a class design.

7.4.1 Variation point driven framework development

The pain of designing a framework is described by Wirfs-Brock and Johnson (1990): 'Good frameworks are usually the result of many design iterations and a lot of hard work.' So don't expect a panacea, for no framework will be ideal from the beginning. More realistically, there should be a means of reducing the number of design iterations. Figure 7.4 gives an overview of the variation point driven framework development process, which includes the identification of flexibility requirements as an explicit activity. One simple but effective means of documenting and communicating variation points are variation point cards.

Figure 7.4. Variation point driven framework development process

7.4.2 Definition of a specific object model

State of the art object-oriented analysis and design (OOAD) methodologies support the initial identification of objects/classes, and thus a modularization of an overall software system. As mentioned earlier, CRC cards are commonly used during an initial design. Overall, object modeling is as challenging as any software development. Methodologies can only provide vague guidelines object modeling requires primarily domain-specific knowledge.

Software engineers assist domain experts in this activity. The distinction between a domain expert and a software engineer is a rather hypothetical one. It should just express the kind of knowledge needed. Of course, software developers will also acquire deep domain knowledge the longer they work in a particular domain.

Modeling a specific solution is itself a complex and iterative activity in which object models must be refined until they meet the domain-specific requirements. This comprises object/class identification and probably the complete development of a specific, custom-made software system. Before starting the framework development cycle, it would, of course, help considerably to have two or more object models of similar applications at hand identifying commonalities would be easier. Unfortunately, this is often not the case.

Note that the actual framework development process builds on top of a specific yet mature object model. Based on the identification of the key abstractions (see Section 7.2), the object model is split into clusters. The variation point driven development process takes place around the cluster cycle model. That is, the incorporation of flexibility requirements affects one or several clusters.

7.4.3 Variation point identification

The main problem of variation point identification is that domain experts are not used to generalizing or abstracting from a specific system. They usually lack an understanding of object-oriented concepts such as classes, objects, inheritance, design patterns, and frameworks. As a consequence, the communication between domain experts and software engineers should be reduced to a common denominator. That common denominator is functionality, not in which class/interface the functionality is placed. Variation point cards (Pree, 1995) represent one possibly suitable communication vehicle. They were inspired by the few essential construction principles of frameworks.

A variation point card captures the following information: a one line description of the functionality that has to be kept flexible; whether runtime adaptation is required; a brief description of the functionality; and at least two examples of its variability. The case study in Section 7.5 provides examples of variation points and how they manifest themselves in the framework design. In general, software developers transform variation point cards into a framework design by defining a hook for the variation point described on each card. Depending on the requirement to change the variation point at runtime, the Unification or Separation construction principle is applied to place the hook. Software engineers also determine where to place the hooks based on the existing class hierarchy.

7.4.4 Framework (re)design

After domain experts have initially identified and documented the variation points, software engineers have to modify the object model in order to gain the desired flexibility expressed in the variation point cards. After this activity, UML-F and the associated framework construction principles and patterns presented in the previous chapters assist the software engineer. In other words, patterns describing how to achieve more flexibility in a framework do not lead to satisfactory frameworks if software engineers do not know where flexibility is actually required. Variation point identification is a precondition for exploiting the full potential of framework construction principles and patterns.

7.4.5 Framework usage

A framework needs to be specialized several times in order to detect its weaknesses that is, any inappropriate or missing variation points. The cycle in Figure 7.4 expresses the framework evolution process. Explicit variation point identification, as supported by UML-F, can contribute to a significant reduction of the number of iteration cycles.