Previous Table of Contents Next


9.3.3. Generalization and Reuse

The latest part of the cluster lifecycles, generalization, is unheard of in traditional models. It is meant to prepare the results of a cluster for reuse across projects by looking for elements of general applicability and transform them for inclusion in libraries.

Of course, not all companies using the method will be ready to include this phase in their lifecycles. But those who do will see the reusability of their software greatly improved.

9.3.4. Constant Availability

Complementing the preceding principles is the idea that, in the cluster lifecycle, the development team (under the responsibility of the project leader) should at all times maintain a current working demo that, although covering only a part of the final system, works well and can be demonstrated or—after a certain stage—shipped as an early release. It is not a prototype in the sense of a mockup meant to be thrown away, but an initial iteration toward the final product; the successive iterations progress continuously until they become that final product.

9.3.5. Compilation Technology

The preceding goals benefit from the ability to check frequently that the current iteration is correct and robust. Eiffel compiler writers have developed considerable effort to supporting efficient compilation mechanisms, such as Interactive Software Engineering’s (ISE’s) Melting Ice Technology, which ensures immediate recompilation after a change. The recompilation time is a function of the size of the changes, never of the system’s overall size. Even for a system of several thousand classes and several hundred thousand lines, the time until restarting after a change to a few classes is a few seconds on a typical modern computer.

Such a “quick melt” (recompilation) immediately catches (along with any syntax errors) the type errors—often the symptoms of conceptual errors that, if left undetected, could cause grave damage later in the process or even during operation. Once the type errors are corrected, the developers should start testing the new functionalities, relying on the power of assertions—explained in section 9.8—to kill the bugs while they are still larvae. Such extensive unit and system testing, constantly interleaved with development, plays an important part in making sure that the current demo is trustworthy and eventually yields a correct and robust product.

9.3.6. Quality and Functionality

Throughout the process, the method suggests maintaining a constant quality level: Apply all the style rules, put in all the assertions, handle erroneous cases (rather than the all too common practice of thinking that one will make the product robust later), and enforce the proper architecture. This applies to all the quality factors except possibly reusability (because one might not know ahead of time how best to generalize a component, and trying to make everything fully general may conflict with solving the specific problem at hand quickly). All that varies is functionality: As the project progresses and clusters come into place, more and more of the final product’s intended coverage becomes available. The only question—for example, to answer the more practical one “Can we ship something yet?”—is “Do we cover enough?” and never “Is it good enough?” (as in “Will it not crash?”).

Of course, not everyone using Eiffel can, any more than in another approach, guarantee that the ideal just presented will always hold, but it is the theoretical scheme to which the method tends. It explains Eiffel’s emphasis on getting everything right: the grandiose and the mundane, the structure and the details. Regarding the details, the Eiffel books cited in the bibliography include many rules, some petty at first sight, about such low-level aspects as the choice of names for classes and features (including their grammatical categories), the indentation of software texts, the style for comments (including the presence or absence of a final period), and the use of spaces. Applying these rules does not, of course, guarantee quality, but they are part of a quality-oriented process, along with the more ambitious principles of design. In addition, they are particularly important for the construction of quality libraries, one of the central goals of Eiffel.

Whenever they are compatible with the space constraints, the present chapter applies these rules in its Eiffel examples.


Previous Table of Contents Next