7.7 Framelets as an aid to framework design

Before introducing the concept of framelets, it is useful to make a distinction between architecture and design. There is general agreement in the software engineering community that an architecture is a description of the set of objects in a software system in terms of their external signatures (usually, their interfaces) and their mutual relationships (Bass et al., 1998). There is less agreement over what constitutes a design. Sometimes design is simply seen as the process that results in an architecture; sometimes it is regarded as identical to the architecture. Here, we will use the term 'design' to signify the organization of the software at the purely abstract level, where the focus of attention is on finding abstract solutions that offer the degree of adaptability required by the variation points, rather than on defining objects and their relationships.

The difference between design and architecture is the same as the difference between a design pattern and its instantiation. An example may help clarify this distinction. Consider the Factory Method pattern for instance. By itself, the pattern represents a pure design solution to a design problem. Pattern instantiation takes place when the pattern is applied to a concrete architectural situation and results in the classes of the pattern being mapped to specific classes and in other non-essential changes for instance, having more than one factory method. At this point, the design pattern is instantiated and it represents an architectural solution.

A similar distinction between design and architecture can apply to an entire system. Indeed, analysis of the thought processes that result in the definition of an architecture shows that the designer passes through a design stage before arriving at the architectural stage. The design stage becomes especially evident in the case of frameworks whose architecture is often considerably more sophisticated than that of individual applications and where designers make a correspondingly larger investment in its definition.

The solutions presented in the previous section for the AOCS framework case study are clearly at the design level. There are at least three characteristic features of the design level that can be evinced from them.

First, the abstract interfaces and classes are defined in an incomplete manner. Consider for instance, the Telemeterable interface. It features only one method (writeToTm) but a realistic implementation has to include other methods to control the telemetry format (telemetry data usually have several formats), or to ask an object to give the size of its telemetry image (and this is important to verify compatibility with the capacity of the telemetry stream channel). These methods are not important at the design level, where the emphasis is on identifying a solution to the abstract problem of flexibly collecting housekeeping data from the AOCS objects; but they definitely need to be defined at the architectural level where, by definition, all interfaces must be fully specified.

Second, no effort is made at the design level to integrate solutions to different design problems. Our case study addresses the problem of telemetry data management and controller management, but nothing is said about their mutual interaction for instance, the question of whether controller objects should be telemeterable is not even considered. This type of interaction is obviously important at the architectural level, where a map of all the objects in the framework with their base classes is provided.

The third characteristic feature of the design level is its emphasis on design patterns. The search for solutions at this level is essentially a search for design patterns to model the variation points identified during the domain analysis. This search may start from standard patterns but it normally progresses to the definition of new patterns that are optimized for the particular domain of interest. In the case study, the solutions to the controller and telemetry problems can be seen as AOCS-specific design patterns. The Manager pattern provides a generalized version of these two patterns.

It is possible to argue that what we call 'design stage' is no more than what others see as the first iteration in the architectural definition phase. Nevertheless, we believe that the explicit identification of a design stage is worthwhile because it draws attention to the multistage character of the process through which a software architecture is constructed. When dealing with project-oriented development, this character is not strongly in evidence because the various iterations in the architectural definition phase are conceptually similar they are all aimed at identifying objects and their relationships, and successive iterations differ merely in the degree of granularity of the description they offer. In the case of product-oriented development, however, the development process clearly breaks up into separate phases. The task of identifying variation points and their matching design patterns is conceptually different from that of defining object architectures hence the value of giving different names to the associated development stages.

In the case of a large framework, the design process can be quite complex. For instance, AOCS applications are not large, typically consisting of between 10,000 and 20,000 lines of compact code. Yet, their domain analysis led to the recognition of 23 major variation points. In such cases, it is clearly desirable to have some means of simplifying the design process. Framelets were introduced in response to this need.

Framelets simplify the framework design process by applying to it the traditional 'divide and conquer' approach. At design level, the framework consists chiefly of a set of variation points and design patterns. Framelets partition this set into smaller subsets of related variation points and design patterns that are then handled, as far as possible, separately from each other.

Object-based methodologies conceptualize a software system as a set of objects. They accordingly recommend that simplification be achieved by breaking up this set of objects into smaller subsets of objects that are tightly integrated with each other but only loosely coupled with those of other subsets. Framelets transpose this approach to the case of frameworks. The only difference is that attention is focused not on objects, but on the variation points and design patterns used in the design of the framework. Hence, partitioning is performed not on the set of objects that make up a system, but on the set of variation points and design patterns used in the design of the framework. Figure 7.16 illustrates the difference.

Figure 7.16. Framelets and object subsets

It is worth noting that framelets do not partition the space of concrete classes in a system, because the same class may be involved in different design patterns. The telemeterable interface is a case in point. Although it is proposed as part of a design pattern to address the telemetry problem, it may be implemented by objects, such as the controller objects, that participate in other design patterns and that are introduced to address completely different design problems. Thus the question 'To which framelet do the controller objects belong?' does not really make sense. The questions that do make sense are 'To what framelet does the controller design pattern belong?', and 'To what framelet does the controller mode variation point belong?'

The AOCS framework was designed as a set of framelets. The initial domain analysis led to the definition of 23 variation points. These were then divided into 13 framelets that happened to contain between one and three related variation points. The controller and telemetry functionalities described in the previous section, for instance, gave rise to two dedicated framelets. Design solutions were then developed for each framelet by developing design patterns that could address the adaptability and flexibility requirements intrinsic to the variation points. At a later stage, this multiplicity of design solutions gave way to a single architecture in which all classes both concrete and abstract were fully defined, together with their mutual interactions.

What then is the relationship between the class family and class team concepts, and the framelet concept? The two are closely linked, but they exist at different levels of abstraction. Framelets are useful at the design level, where they simplify the design process by breaking it up into smaller and independent design units. Framelets are no longer very useful after the transition to the architectural phase because, at that stage, the attention shifts to concrete classes and cannot be mapped onto framelets. At this stage, simplification is best achieved by organizing the system along class families and class teams. Note that sometimes framelets and class families/class teams can be homologous. This is the case, for instance, in the controller framelet where, even at the design stage, it is possible to distinguish class families and class teams. However, this is by no means always the case, as shown by the telemetry example where it turns out to be impossible at the design stage to associate a well-defined class family to the Telemeterable interface. The telemeterable class family only emerges at the architectural level, when all the framelets are merged together. Framelets, class families, and class teams, therefore, are means of simplifying the software development process by subdividing the framework into simpler units. In this sense, they realize the cluster-based lifecycle.

The relationship between framelets and class families, and the distinction between the design and architectural levels is graphically illustrated in Figure 7.17 for the case of the AOCS framework case study. The top half of the figure shows the framework design level containing the telemetry and controller framelets. The framelets are essentially made up of the respective design patterns without showing the variation points. The bottom half of the figure shows the framework architectural level populated with the class families that are generated by the base classes and abstract interfaces induced by the design patterns. Note how the class families do not partition the space of framework classes, because some classes implement multiple interfaces from several framelets.

Figure 7.17. Design level versus architectural level

Before concluding this section, it is perhaps useful to summarize its main points:

A distinction should be made between design and architecture.
This distinction is especially important in the case of software frameworks, where the distance between analysis and architectural definition is much greater than for single applications and where, consequently, there is a greater need for the recognition of an intermediate stage.
At design level, the focus of attention is on variation points and design patterns; at architectural level, it is on classes and objects.
At design level, simplification is best achieved by partitioning the set of design patterns and variation points into subsets called framelets; at architectural level, simplification is best achieved by organizing the set of classes in the framework into class families and class teams.