ObjectOriented Software Construction Bertrand Meyer 2 nd ed

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

Notice Some of the material is taken from Object-Oriented Software Construction, 2 nd 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 <info@eiffel. com>. For more material see http: //eiffel. com ©Bertrand Meyer and Yishai Feldman

Factors for Software Quality ©Bertrand Meyer and Yishai Feldman

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

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

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

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

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

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 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 is the extent of possibilities provided by a system. ©Bertrand Meyer and Yishai Feldman

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

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 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 is the ability of software systems to protect their various components (programs, data) against unauthorized access and modification. ©Bertrand Meyer and Yishai Feldman

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