Object-Oriented Software Construction Bertrand Meyer 2nd ed., Prentice Hall, 1997

© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice Hall). Included here by permission of ISE, for the benefit of IDC students. Other uses, duplication or distribution require permission from ISE. For more material see

© Bertrand Meyer and Yishai Feldman Factors for Software Quality

© Bertrand Meyer and Yishai Feldman Correctness Correctness is the ability of software products to perform their exact tasks, as defined by their specification.

© Bertrand Meyer and Yishai Feldman Robustness Robustness is the ability of software systems to react appropriately to abnormal conditions.

© Bertrand Meyer and Yishai Feldman Extendibility Extendibility is the ease of adapting software products to changes of specification.

© Bertrand Meyer and Yishai Feldman Reusability Reusability is the ability of software elements to serve for the construction of many different applications.

© Bertrand Meyer and Yishai Feldman Compatibility Compatibility is the ease of combining software elements with others.

© Bertrand Meyer and Yishai Feldman Efficiency Efficiency is the ability of a software system to place as few demands as possible on hardware resources, such as processor time, space occupied in internal and external memories, bandwidth used in communication devices.

© Bertrand Meyer and Yishai Feldman Portability Portability is the ease of transferring software products to various hardware and software environments.

© Bertrand Meyer and Yishai Feldman Ease of Use Ease of use is the ease with which people of various backgrounds and qualifications can learn to use software products and apply them to solve problems. It also covers the ease of installation, operation and monitoring.

© Bertrand Meyer and Yishai Feldman User Interface Design Principle Do not pretend you know the user; you don’t.

© Bertrand Meyer and Yishai Feldman Functionality Functionality is the extent of possibilities provided by a system.

© Bertrand Meyer and Yishai Feldman Timeliness Timeliness is the ability of a software system to be released when or before its users want it.

© Bertrand Meyer and Yishai Feldman Economy Economy, the companion of timeliness, is the ability of a system to be completed on or below its assigned budget.

© Bertrand Meyer and Yishai Feldman Verifiability Verifiability is the ease of preparing acceptance procedures, especially test data, and procedures for detecting failures and tracing them to errors during the validation and operation phases.

© Bertrand Meyer and Yishai Feldman Integrity Integrity is the ability of software systems to protect their various components (programs, data) against unauthorized access and modification.

© Bertrand Meyer and Yishai Feldman Reparability Reparability is the ability to facilitate the repair of defects.

© Bertrand Meyer and Yishai Feldman Criteria for Modularity u Decomposability u Composability u Understandability u Continuity u Protection

© Bertrand Meyer and Yishai Feldman Modular Decomposability A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex subproblems, connected by a simple structure, and independent enough to allow further work to proceed separately on each of them

© Bertrand Meyer and Yishai Feldman Top-Down Design

© Bertrand Meyer and Yishai Feldman Modular Composability A method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

© Bertrand Meyer and Yishai Feldman 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.

© Bertrand Meyer and Yishai Feldman Modular Continuity A method satisfies Modular Continuity if, in the software architectures that it yields, a small change in a problem specification will trigger a change of just one module, or a small number of modules.

© Bertrand Meyer and Yishai Feldman Modular Protection A method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

© Bertrand Meyer and Yishai Feldman Rules for Modularity u Direct Mapping u Few Interfaces u Small Interfaces (weak coupling) u Explicit Interfaces u Information Hiding

© Bertrand Meyer and Yishai Feldman Direct Mapping The modular structure devised in the process of building a software system should remain compatible with any modular structure devised in the process of modeling the problem domain.

© Bertrand Meyer and Yishai Feldman Few Interfaces Every module should communicate with as few others as possible.

© Bertrand Meyer and Yishai Feldman Small Interfaces If two modules communicate, they should exchange as little information as possible

© Bertrand Meyer and Yishai Feldman Explicit Interfaces Whenever two modules A and B communicate, this must be obvious from the text of A or B or both.

© Bertrand Meyer and Yishai Feldman Information Hiding The designer of every module must select a subset of the module’s properties as the official information about the module, to be made available to authors of client modules.

© Bertrand Meyer and Yishai Feldman Principles for Modularity u Linguistic Modular Units u Self Documentation u Uniform Access u Open-Closed u Single Choice

© Bertrand Meyer and Yishai Feldman Linguistic Modular Units Principle Modules must correspond to syntactic units in the language used.

© Bertrand Meyer and Yishai Feldman Self-Documentation Principle The designer of a module should strive to make all information about the module part of the module itself.

© Bertrand Meyer and Yishai Feldman Uniform Access Principle All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.

© Bertrand Meyer and Yishai Feldman Open-Closed Principle Modules should be both open and closed.

© Bertrand Meyer and Yishai Feldman Hint: Open-Closed Principle Achieved by Inheritance

© Bertrand Meyer and Yishai Feldman Single Choice Principle Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.