We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byDraven Beckman
Modified about 1 year ago
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.
Ranga Rodrigo. The purpose of software engineering is to find ways of building quality software.
Vladimir Misic: Design111:43:34 AM Software design.
PRINCIPLES OF GOOD DESIGN 12/7/ Assignment 4 – Deadline 28 Nov. Read an article placed in generalshare course folder Point: Design Patterns.
Chair of Software Engineering ATOT - Lecture 3, 7 April Advanced Topics in Object Technology Bertrand Meyer.
Chapter 10 Software quality. This chapter discusses n Some important properties we want our system to have, specifically correctness and maintainability.
Ceg860 (Prasad)L6MR1 Modularity Extendibility Reusability.
CSE 303 – Software Design and Architecture LECTURE 03.
1/19 Component Design On-demand Learning Series Software Engineering of Web Application - Principles of Good Component Design Hunan University, Software.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
MADALINA CROITORU Software Engineering week 4 Madalina Croitoru IUT Montpellier.
Ceg860 (Prasad)L1SQ1 Software Quality Object-Oriented Programming Paradigm.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Thanks for Coming l WEB. Principles of Good Design SEI, SJTU WEB APPS and SERVICES.
Software Engineering CSE470: Systems Engineering 35 Computer System Engineering Computer System Engineering is a problem-solving activity. Itemize desired.
Design Phase Design Phase What’s design? What’s design? the process of applying various techniques and principles for the purpose of defining a device,
Dr. Awais Majeed Software Design Process CSE-874 Software System Design & Architecture.
Lecture 2 Quality as the motivation for Software Design References:Braude, Chapters 0 and 1 My 2001 lecture notes on Quality Budgen Software Design Meyer.
SOFTWARE DESIGN. What is? It’s a meaningful engineering representation of something that is to be built. There are four major concerns for design. They.
CSE 303 – Software Design and Architecture LECTURE 4.
Object-Oriented Design Concepts University of Sunderland.
Data Structures and Programming. John Edgar2.
Design Concepts and Principles Instructor: Dr. Jerry Gao.
Software Engineering Software Design Slide 1 Software Engineering Software Design.
CS 1120: Computer Science II Software Life Cycle Slides courtesy of: Prof. Ajay Gupta and Prof. James Yang (format and other minor modifications by by.
Ch:8 Design Concepts S.W Design should have following quality attribute: –Functionality –Usability –Reliability –Performance –Supportability (extensibility,
©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart 18-1 Accounting Information Systems 9 th Edition Marshall.
Software Design Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
Software Qualities. Unique Properties of Software (Teams: What are the properties of software that make it unique from other engineering disciplines?)
Drexel University CS 451 Software Engineering Winter Yuanfang Cai Room 104, University Crossings
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall A.1.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 11 Slide 1 Design.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
NJIT More GRASP Patterns Chapter 22 Applying UML and Patterns Craig Larman Prepared By: Krishnendu Banerjee.
Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 1: Modularity.
Software project management (intro) Quality assurance.
6 Chapter 6 Database Design Database Systems: Design, Implementation, and Management, Fifth Edition, Rob and Coronel.
Software Design Fundamentals Introduction Design Principles SEN-261 : Software Engineering Tazeen Muzammil.
Design Concepts and Principles1 Design Phase Design Concepts and Principles “Good judgement is the result of experience … Experience is the result of bad.
N-Tier Architecture. reference /N-Tier-Architecture-and-Tips /N-Tier-Architecture-and-Tips.
1.3 Operating system services An operating system provide services to programs and to the users of the program. It provides an environment for the execution.
Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy (anpassad för PUMA)
© 2017 SlidePlayer.com Inc. All rights reserved.