$3.1 FIVE CRITERIA 43 use "preprocessors"that accept an extended syntax as input and map it into the standard form of the language.Typical preprocessors for Fortran and C support graphical primitives,extended control structures or database operations.Usually, however,such extensions are not compatible;then you cannot combine two of the preprocessors,leading to such dilemmas as whether to use graphics or databases. The figure illustrat- Composability is independent of decomposability.In fact,these criteria are often at ing top-downdesign odds.Top-down design,for example,which we saw as a technique favoring was on page 41. decomposability,tends to produce modules that are not easy to combine with modules com ing from other sources.This is because the method suggests developing each module to fulfill a specific requirement,corresponding to a subproblem obtained at some point in the refinement process.Such modules tend to be closely linked to the immediate context that led to their development,and unfit for adaptation to other contexts.The method provides neither hints towards making modules more general than immediately required, nor any incentives to do so;it helps neither avoid nor even just detect commonalities or redundancies between modules obtained in different parts of the hierarchy That composability and decomposability are both part of the requirements for a modular method reflects the inevitable mix of top-down and bottom-up reasoning -a complementarity that Rene Descartes had already noted almost four centuries ago,as shown by the contrasting two paragraphs of the Discourse extract at the beginning of part B. Modular understandability A method favors Modular Understandability if it helps produce software in which a human reader can understand each module without having to know the others,or,at worst,by having to examine only a few of the others. See“ABOUT The importance of this criterion follows from its influence on the maintenance process. SOFTWARE MAIN-Most maintenance activities,whether of the noble or not-so-noble category,involve TENANCE”,I.3, having to dig into existing software elements.A method can hardly be called modular if a page 17. reader of the software is unable to understand its elements separately. Understan- dability§3.1 FIVE CRITERIA 43 use “preprocessors” that accept an extended syntax as input and map it into the standard form of the language. Typical preprocessors for Fortran and C support graphical primitives, extended control structures or database operations. Usually, however, such extensions are not compatible; then you cannot combine two of the preprocessors, leading to such dilemmas as whether to use graphics or databases. Composability is independent of decomposability. In fact, these criteria are often at odds. Top-down design, for example, which we saw as a technique favoring decomposability, tends to produce modules that are not easy to combine with modules coming from other sources. This is because the method suggests developing each module to fulfill a specific requirement, corresponding to a subproblem obtained at some point in the refinement process. Such modules tend to be closely linked to the immediate context that led to their development, and unfit for adaptation to other contexts. The method provides neither hints towards making modules more general than immediately required, nor any incentives to do so; it helps neither avoid nor even just detect commonalities or redundancies between modules obtained in different parts of the hierarchy. That composability and decomposability are both part of the requirements for a modular method reflects the inevitable mix of top-down and bottom-up reasoning — a complementarity that René Descartes had already noted almost four centuries ago, as shown by the contrasting two paragraphs of the Discourse extract at the beginning of part B. Modular understandability The importance of this criterion follows from its influence on the maintenance process. Most maintenance activities, whether of the noble or not-so-noble category, involve having to dig into existing software elements. A method can hardly be called modular if a reader of the software is unable to understand its elements separately. A method favors Modular Understandability if it helps produce software in which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others. The figure illustrat￾ing top-down design was on page 41. See “ABOUT SOFTWARE MAIN￾TENANCE”, 1.3, page 17. Understan￾dability