Previous | Table of Contents | Next |
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.
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 orafter a certain stageshipped 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.
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 Engineerings (ISEs) 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 systems 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 errorsoften 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 assertionsexplained in section 9.8to 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.
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 products intended coverage becomes available. The only questionfor 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 Eiffels 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 |