The UML Profile for Framework Architectures

7.8 eXtreme Design (XD), with implementation cases

As already mentioned, class families, class teams, and framelets help tackle the complexity inherent in the framework development process. The kind of complexity that they address is quantitative, namely the result of the large number of artifacts classes, variation points, design patterns that go into the construction of a framework. Framework complexity has another, qualitative, aspect that stems from its high level of abstraction. A framework must model an entire domain and is therefore qualitatively more complex than an individual application that only models a single point within this domain. Implementation cases are proposed as a means of addressing this second type of framework complexity.

The AOCS case study has shown so far how the framework design process begins by identifying domain abstractions and variation points, and progresses through successive refinements of design solutions to implement them. These design solutions are typically localized, in that they address individual variation points (or small clusters of related variation points). After several such solutions have been devised, the need naturally arises to test their effectiveness and, above all, their mutual compatibility. The need to verify the adequacy of design abstractions arises also in the context of single-product development but it is especially acute in the case of frameworks where the gap between design and code is much wider and where there is a correspondingly greater risk of mistaken or suboptimal design choices.

The simple, if not simplistic, approach of addressing this need is to wait until the design is implemented in code perhaps in a prototype and then test its suitability directly. This approach may work when developing single applications but it would be too time consuming in developing frameworks because testing a framework means using it to instantiate several applications in the framework domain and then separately testing the applications thus instantiated for their correctness. A more direct means of testing the design, as opposed to testing the code, is needed. So-called 'implementation cases' answer this need precisely.

A framework is a tool to help developers build an application rapidly within a framework domain. An implementation case describes an aspect of this application instantiation process by specifying how a component, an architectural feature, or a functionality for an application in the framework domain can be implemented using the constructs offered by the framework.

An example may help illustrate this definition in relation to the design solution for the controller functionality in the AOCS framework. Among other aspects, the proposed solution addresses the problem of the dependency of the attitude control algorithms on a satellite's operational conditions. In a typical situation, an AOCS application might have two control algorithms: a low accuracy algorithm, and one for high accuracy adjustments. An implementation case could then be formulated whereby a controller could be built that switches between high and low accuracy control depending on the size of the control error. This implementation case can then be worked out by showing how the constructs offered by the framework can be combined to achieve this effect. This would probably be done by developing a skeleton controller mode manager that has access to the control error and supplies the appropriate control algorithm to the controller manager depending on the size of the control error.

Implementation cases define an objective for a localized adaptation action. They are said to be 'worked out' when they are accompanied by a description of how their adaptation objective can be achieved using the framework. Implementation cases address the qualitative aspect of framework complexity because they force designers to think about the reification of the abstractions they are creating, while at the same time giving them the opportunity to test the adequacy of these abstractions.

The term 'implementation case' was coined by analogy with the term 'use case' as employed by some methodologies for application development. A use case describes the way an application is intended to be used. Use cases cannot be defined for a framework because a framework is not a working application, and it is not used in the same sense in which an application is used. An implementation case is its equivalent in the sense that a framework is a tool to help implement applications, and implementation cases describe how a feature of an application can be implemented.

In the AOCS framework project, implementation cases were defined early in the design phase and were then gradually worked out as the design advanced. Typically, whenever a new major construct was introduced, its effectiveness was tested by working out an implementation case that used it. When necessary, new implementation cases were introduced to cover the functionalities introduced by the newly defined construct. Initially, implementation cases were defined at a very high level by simply describing the objective of the adaptation action they represented. They were then periodically revisited and progressively refined to reflect the advancing state of the framework definition. At the end of the architectural design phase, they can be described at the pseudocode level. Typically, the pseudocode is intended to demonstrate how predefined framework constructs, components, interfaces, and design patterns could be used to achieve the objective prescribed by the implementation case. It is worth stressing that this process of refinement of implementation cases was the single most important source of changes in the AOCS framelet design, and it is believed that it replaced at least one iteration cycle in the framework design.

7.8.1 Implementation cases as a vehicle for framework specification

Implementation cases were introduced as a way of continually monitoring the adequacy of a framework design during a design process. However, they can serve at least two other purposes. Like use cases for single applications, implementation cases can be used as a specification vehicle for frameworks. A sufficient number of them can cover all the functionalities of a framework and can thus be used as a way of specifying it.

The acceptance test for the framework then becomes its ability to implement all the components and architectural features described in the implementation cases. The ease with which this can be done is a measure of the quality of the framework a well-designed framework should offer abstractions and components that let users quickly and naturally implement the constructs required by the implementation cases.

7.8.2 From implementation cases to cookbook recipes

Implementation cases can play a third role. At the end of the framework development process, they are a kind of commented pseudocode. They could thus be included in the framework user manual, where they can represent cookbook recipes showing how framework constructs can be used to develop small applications or fragments of applications. (See Chapters 5 and 6 for further discussion of cookbooks and cookbook recipes.)

How many implementation cases should be generated for a given framework? The discussion in the previous sections of this chapter should have made clear that the primary entities making up a framework are: the domain abstractions; the variation points and their associated design patterns; and the class families and class teams, possibly grouped together in subsystems. A useful heuristic is that each one of these entities should participate in two or three implementation cases. In a formal project setting, traceability matrices can be used to measure coverage. However, this is just a rule of thumb. The question asked above has no straightforward answer and the experience of the designer will be paramount, as in so many other software engineering issues.

Because of the novelty of the concept, no more concise formalism has yet been defined to represent and model implementation cases. In the AOCS project, implementation cases are mostly described in a mixture of informal language, pseudocode, and UML-F. It is recommended that implementation cases be described in an informal but systematic manner. For each implementation case, the following information should be provided:

• implementation case objective

• objective description

• framelets involved in the implementation case

• framework constructs involved in the implementation case

• description of how the implementation case is worked out.

Note that, in the approach proposed here, implementation cases are defined incrementally during the design process. Hence, the information items listed above are not all supplied at the same time. Initially, only the objective and its description are provided. Other fields are filled in gradually as the framework design is refined. The implementation description section, in particular, is expanded and made more detailed as the constructs for working out the implementation case become available. Eventually, the implementation description section will probably contain commented pseudocode showing how the implementation case objective can be met by combining and adapting framework components. The degree of maturity of the implementation case descriptions and their stability can thus be used as a measure of the maturity of the framework design.

As a concrete example, let us consider again the implementation case presented at the beginning of this section. As defined in Table 7.2, the implementation case corresponds to the beginning of the design definition phase. As the design progresses, more details can be provided as to how the control algorithms are to be encapsulated, how the control error is to be monitored, how the controller is to be loaded into the controller mode manager, etc. After the transition to the architectural phase, the implementation description is gradually translated into pseudocode until, at the end of the framework development process, the implementation case has become a cookbook recipe.

As indicated by the section title, a connection may also be established between implementation cases and eXtreme Programming (XP) (Beck, 1999). The framework approach is obviously alien to the philosophy of XP with its rejection of reuse as a legitimate objective of the software development process, and its minimalist attitude to design. However, adoption of implementation cases furthers some of the key principles advocated by XP, such as rapid feedback (since they allow very short turnaround times between design and implementation), and concrete experiments (since they make design experiments possible at an early stage in the development process). To the extent that implementation cases resemble minimal self-contained implementations, their use promotes practices such as small releases and continuous integration that are key to XP paradigms. Finally and again in line with the XP philosophy implementation cases shift the emphasis from design to testing (or, more precisely, to the testing of the design).

The relationship between implementation cases and the XP style is, however, analogous only because XP is concerned with the rapid prototyping of applications, whereas implementation cases are concerned with the rapid design of frameworks. One could perhaps describe implementation cases as an 'eXtreme Design (XD)' approach to framework development.