7.1 The cluster cycle process model of framework development and adaptation

Object-oriented development techniques rely on the same activities as those described in conventional process models that is, analysis, specification, design, implementation, test, and maintenance. Unfortunately, methods such as the Unified Process (Jacobson et al. 1999) suggest slightly different but synonymous terms. In the following material, note that we deliberately use references dating back more than a decade to corroborate that the coarse-grained characteristics of reuse-centered development have been well known for some years.

Classical software development strategies do not focus on the reusability of software components. Meyer (1989) remarks that 'object-orientedness is not just a programming style but the implementation of a certain view of what software should be this view implies profound rethinking of the software process.' Thus, Meyer discerns two views or cultures:

The conventional culture is project-based: the classical software lifecycle or some of its variations, such as the waterfall model with certain possible iterations (Boehm, 1976), or a prototype-oriented software development methodology (Pomberger et al., 1991), have the aim of solving one particular problem. The recommended strategy, which is inherent in the usual software lifecycle models, is top-down. The primary question addressed in the analysis and design phases is 'What must the system do?', followed by a stepwise refinement of a system's functions. Henderson-Sellers and Edwards (1990) summarize the flaws of top-down system development 'Top-down decomposition does not promote reusability.' The data structure aspect is often neglected. Finally, top-down designed systems are too rigid and impede evolutionary change.
The preconditions of a new culture called product culture by Meyer (1989) are object-oriented development techniques. This culture produces not only software systems that solve one particular problem, but also reusable software components that are useful for a potentially large number of applications. So the lifecycle of a piece of software is generally extended.

The object-oriented, long term view implies a new activity in the software lifecycle, called generalization, and a modification of the specification activity:

The use of object-oriented languages does not automatically mean that the software produced is reusable; the additional lifecycle activity of generalization is necessary to achieve this goal. This activity is, in most cases, part of an iterative process since the need for more general software components is often not realized until they are reused.
A set of ready-made reusable/adaptable software components also influences the system specification. In contrast to the project-based culture, where a software system is developed to satisfy specific needs, good frameworks typically capture the existing 'best practices' in a domain. For example, the SAP system represents a framework that although developed with a non-object-oriented language standardizes significant portions of how companies conduct business covering areas such as accounting, human resource management, production planning, and manufacturing. The SAP framework can be adapted and fine tuned to the specific needs of companies. Nevertheless, several aspects cannot be changed.

In other words, instead of slavishly adhering to the user's or customer's requests in the realm of a conventional custom-made system construction process, the system specification inherent in a framework most likely provides a somewhat different functionality (for example, without some nice-to-have features) which can be created by means of existing framework components. The customer has the choice between a custom-made system implemented (almost) from scratch with significantly more effort and cost, and a system built out of ready-made components by adapting a framework. The framework has the additional advantage that the quality of the resulting system in terms of reliability will probably be higher than the custom-made system. This is particularly true if the framework has been thoroughly tested and/or has already been reused several times. Some offers might be hard to refuse.

Which process model captures the framework development and adaptation process? Though the answer to that question is controversial, we have found that the cluster model Meyer (1990) coined the term in the early 1990s describes the flavor of the process quite well on a coarse-grained level (see Figure 7.1). A cluster, in this context, is a group of related classes and/or interfaces. The design, development and adaptation of classes/interfaces belonging to one cluster constitutes one lifecycle. Note that the model also comprises the adaptation process of a framework. The following changes to the usual arrangement of the activities in the software lifecycle become necessary in this model.

Figure 7.1. Cluster model of the software lifecycle (adapted from Meyer, 1990)

Activities of the software lifecycle are not applied to the system as a whole. Instead, system development is split into several sub-lifecycles overlapping in time. A sub-lifecycle is associated with one cluster. The clusters are typically at different stages in the lifecycle, regardless of whether the framework is in the development or adaptation stage. This reflects the fact that the iterative design of abstract classes/interfaces requires that some subsystems be located in the implementation activity. If the implementation effort reveals that certain abstractions are not suitable, the redesign of the abstractions has to go on in parallel with the implementation of the particular subsystems.
Though Meyer (1990) merged design and implementation activities within one cluster, we suggest keeping them separate even though these activities might sometimes overlap within one cluster. The concept of implementation cases (introduced in Section 7.8) provides more fine-grained methodological insights into that aspect of framework development. In order to not clutter the cluster cycle model in Figure 7.1, it does not show lines between the activities within a cluster and between clusters. Analogous with enhanced waterfall cycle models, the cluster cycle model allows moving back and forth between the activities.

A framework adaptation also takes place in one or more clusters. The characteristics of an adaptation are that the importance of the specification and design activities is diminished while the focus shifts to the implementation and test activities. The implementation activity could involve black-box compositional configurations and/or white-box inheritance-based adaptations.
The additional activity of generalization is introduced with the aim of producing reusable software components. Meyer (1990) also merged that activity with the test activity. Nevertheless, we again regard generalization and testing as separate activities. Framework adaptations might lead to generalization activities in various clusters.

Regarding the sequencing of the cluster lifecycle, we recommend working first on the most general clusters (providing some utility features) and then proceeding to those that are application specific. The following sections discuss that aspect in more detail. The case study illustrates how the clusters manifest in a sample framework.