Software Design 2E

Total Page:16

File Type:pdf, Size:1020Kb

Software Design 2E ppc_234x172budgen3 9/18/07 12:24 PM Page 1 Software Engineering second second edition edition Software design is a multi-disciplinary Since the first edition, much progress activity that develops tools through effective has been made in the area of software DESIGN SOFTWARE David Budgen communication of ideas and the use of design, with the major changes to the engineering practices. This text provides an new edition being: overview and perspective of software design within the context of software • A much stronger recognition of the development and also of more general role played by the concept of thinking about design issues. It examines architectural style in helping to the nature of design activities, as well as structure ideas about design. This is their applications within software used to provide an underpinning development, providing the reader with: framework throughout the second edition. • a non-proprietary view of design issues • The inclusion of new forms of • an overview of design representation software and of new approaches to forms design, ranging from agile methods • a concise review of design practices and design patterns through to the based on the more widely used component concept and the use of the design methods Unified Modeling Language (UML). • a strong architectural framework • An improved formalism to support the analysis of the processes A particular feature is the strong embodied in design methods. evidence-based approach used in the analysis and assessment of these issues. SOFTWARE DESIGN Software Design provides a balanced view of the many and varied software design David Budgen strategies most widely used by practitioners. By being aware of the strengths and limitations of each one, a student is better able to judge which to adopt when working in the field. The book is also valuable for software engineers and project managers who need an objective guide to the state of the art in this area. David Budgen is Professor of Software Engineering at Keele University, UK. A long- term student of software design, he has worked closely with the Software Engineering Institute in Pittsburgh to develop tutorial modules, as well as publishing many research papers on software design topics. Budgen SOFTWARE DESIGN SOFTWARE second edition www.pearsoneduc.com SDA01 9/18/07 10:32 AM Page i Software Design SDA01 9/18/07 10:32 AM Page ii INTERNATIONAL COMPUTER SCIENCE SERIES Consulting Editor A D McGettrick University of Strathclyde SELECTED TITLES IN THE SERIES Operating Systems J Bacon and T Harris Programming Language Essentials H E Bal and D Grune Programming in Ada 95 (2nd edn) J G P Barnes Java Gently (3rd edn) J Bishop Concurrent Programming A Burns and G Davies Real-Time Systems and Programming Languages: Ada 95, Real-Time Java and Real- Time POSIX (3rd edn) A Burns and A Wellings Comparative Programming Languages (3rd edn) L B Wilson and R G Clark, updated by R G Clark Database Systems (3rd edn) T M Connolly and C Begg Distributed Systems: Concepts and Design (3rd edn) G Coulouris, J Dollimore and T Kindberg Principles of Object-Oriented Software Development (2nd edn) A Eliëns Fortran 90 Programming T M R Ellis, I R Philips and T M Lahey Program Verification N Francez Introduction to Programming using SML M Hansen and H Rischel Functional C P Hartel and H Muller Algorithms and Data Structures: Design, Correctness, Analysis (2nd edn) J Kingston Introductory Logic and Sets for Computer Scientists N Nissanke Human–Computer Interaction J Preece et al. Algorithms: A Functional Programming Approach F Rabhi and G Lapalme Ada 95 From the Beginning (3rd edn) J Skansholm Java From the Beginning J Skansholm Software Engineering (6th edn) I Sommerville Object-Oriented Programming in Eiffel (2nd edn) P Thomas and R Weedon Miranda: The Craft of Functional Programming S Thompson Haskell: The Craft of Functional Programming (2nd edn) S Thompson Discrete Mathematics for Computer Scientists (2nd edn) J K Truss Compiler Design R Wilhelm and D Maurer Discover Delphi: Programming Principles Explained S Williams and S Walmsley Software Engineering with B J B Wordsworth SDA01 9/18/07 10:32 AM Page iii Software Design David Budgen SDA01 9/18/07 10:32 AM Page iv Pearson Education Limited Edinburgh Gate Harlow Essex CM20 2JE England and Associated Companies throughout the world Visit us on the World Wide Web at: www.pearsoned.co.uk First published 1993 Second edition 2003 © Addison-Wesley Publishers Limited 1993 © Pearson Education Limited 2003 The right of David Budgen to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without either the prior written permission of the publisher or a licence permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP. The programs in this book have been included for their instructional value. They have been tested with care but are not guaranteed for any particular purpose. The publisher does not offer any warranties or representations nor does it accept any liabilities with respect to the programs. All trademarks used herein are the property of their respective owners. The use of any trademark in this text does not vest in the author or publisher any trademark ownership rights in such trademarks, nor does the use of such trademarks imply any affiliation with or endorsement of this book by such owners. ISBN 0 201 72219 4 British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library Library of Congress Cataloging-in-Publication Data Budgen, D. (David) Software design / David Budgen.—2nd ed. p. cm. Includes bibliographical references and index. ISBN 0–201–72219–4 (alk. paper) 1. Computer software—Development. I. Title. QA76.76.D47B83 2003 005.1′2—dc21 2003041859 10987654321 08 07 06 05 04 03 Typeset in 10/12pt Sabon by 35 Printed and bound in Great Britain by Biddles Ltd., Guildford and King’s Lynn The publisher’s policy is to use paper manufactured from sustainable forests. SDA01 9/18/07 10:32 AM Page v v Contents Preface to the Second Edition ix Preface to the First Edition xii Publisher’s Acknowledgements xvi Part 1 The Role of Software Design 1 Chapter 1 The Nature of the Design Process 3 1.1 What is design? 4 1.2 The role of the design activity 14 1.3 Design as a problem-solving process 18 1.4 Design as a ‘wicked’ problem 19 Chapter 2 The Software Design Process 25 2.1 What is software? 26 2.2 Building models 27 2.3 Transferring design knowledge 32 2.4 Constraints upon the design process and product 37 2.5 Recording design decisions 38 2.6 Designing with others 40 Chapter 3 Design in the Software Development Process 45 3.1 A context for design 46 3.2 Linear development processes 50 3.3 Incremental development processes 51 3.4 Economic factors 55 3.5 The longer term 57 SDA01 9/18/07 10:32 AM Page vi vi Chapter 4 Design Qualities 63 4.1 The quality concept 64 Contents 4.2 Assessing design quality 65 4.3 Quality attributes of the design product 75 4.4 Assessing the design process 82 Part 2 Transferring Design Knowledge 87 Chapter 5 Describing a Design Solution 89 5.1 Representing abstract ideas 90 5.2 Design viewpoints for software 94 5.3 Forms of notation 98 Chapter 6 Transferring Design Knowledge 105 6.1 The need to share knowledge 106 6.2 The architecture concept 109 6.3 Design methods 118 6.4 Design patterns 120 6.5 A unified interpretation? 122 Chapter 7 Some Design Representations 127 7.1 A problem of selection 128 7.2 Black box notations 129 7.3 White box notations 158 7.4 Developing a diagram 168 Chapter 8 The Rationale for Method 175 8.1 What is a software design method? 176 8.2 The support that design methods provide 180 8.3 Why methods don’t work miracles 185 8.4 Problem domains and their influence 187 Chapter 9 Design Processes and Design Strategies 193 9.1 The role of strategy in methods 194 9.2 Describing the design process – the D-Matrix 200 9.3 Design by top-down decomposition 205 9.4 Design by composition 207 9.5 Organizational influences upon design 209 SDA01 9/18/07 10:32 AM Page vii Chapter 10 Design Patterns 213 vii 10.1 Design by template and design reuse 214 Contents 10.2 The design pattern 216 10.3 Designing with patterns 225 10.4 Patterns in the wider design context 227 Part 3 Design Practices 231 Chapter 11 Stepwise Refinement 233 11.1 The historical role of stepwise refinement 234 11.2 Architectural consequences 235 11.3 Strengths and weaknesses of the stepwise strategy 237 Chapter 12 Incremental Design 241 12.1 Black box to white box in stages 242 12.2 Prototyping 245 12.3 An example – DSDM 247 Chapter 13 Structured Systems Analysis and Structured Design 257 13.1 Origins, development and philosophy 258 13.2 Representation forms for SSA/SD 259 13.3 The SSA/SD process 263 13.4 The role of heuristics in SSA/SD 273 13.5 Extended forms of SSA/SD 275 13.6 SSA/SD: an outline example 275 Chapter 14 Jackson Structured Programming (JSP) 289 14.1 Some background to JSP 290 14.2 JSP representation forms 291 14.3 The JSP process 293 14.4 Some JSP heuristics 301 Chapter 15 Jackson System Development (JSD) 315 15.1 The JSD model 316 15.2 JSD representation forms 318 15.3 The JSD process 322 15.4 JSD heuristics 336 SDA01 9/18/07 10:32 AM Page viii viii Chapter 16 Designing
Recommended publications
  • Roundabout Planning, Design, and Operations Manual
    Roundabout Planning, Design, and Operations Manual December 2015 Alabama Department of Transportation ROUNDABOUT PLANNING, DESIGN, AND OPERATIONS MANUAL December 2015 Prepared by: The University Transportation Center for of Alabama Steven L. Jones, Ph.D. Abdulai Abdul Majeed Steering Committee Tim Barnett, P.E., ALDOT Office of Safety Operations Stuart Manson, P.E., ALDOT Office of Safety Operations Sonya Baker, ALDOT Office of Safety Operations Stacey Glass, P.E., ALDOT Maintenance Stan Biddick, ALDOT Design Bryan Fair, ALDOT Planning Steve Walker, P.E., ALDOT R.O.W. Vince Calametti, P.E., ALDOT 9th Division James Brown, P.E., ALDOT 2nd Division James Foster, P.E., Mobile County Clint Andrews, Federal Highway Administration Blair Perry, P.E., Gresham Smith & Partners Howard McCulloch, P.E., NE Roundabouts DISCLAIMER This manual provides guidelines and recommended practices for planning and designing roundabouts in the State of Alabama. This manual cannot address or anticipate all possible field conditions that will affect a roundabout design. It remains the ultimate responsibility of the design engineer to ensure that a design is appropriate for prevailing traffic and field conditions. TABLE OF CONTENTS 1. Introduction 1.1. Purpose ...................................................................................................... 1-5 1.2. Scope and Organization ............................................................................... 1-7 1.3. Limitations ...................................................................................................
    [Show full text]
  • Budgen, Software Design Methods
    David Budgen The Loyal Opposition Software Design Methods: Life Belt or Leg Iron? o software design methods have a correctly means “study of method.”) To address, but future? In introducing the January- not necessarily answer, this question, I’ll first consider D February 1998 issue of IEEE Software,Al what designing involves in a wider context, then com- Davis spoke of the hazards implicit in pare this with what we do, and finally consider what “method abuse,”manifested by a desire this might imply for the future. to “play safe.”(If things go well, you can take the credit, but if they go wrong, the organization’s choice of method can take the blame.) As Davis argues, such a THE DESIGN PROCESS policy will almost certainly lead to our becoming builders of what he terms “cookie-cutter, low-risk, low- Developing solutions to problems is a distinguish- payoff, mediocre systems.” ing human activity that occurs in many spheres of life. The issue I’ll explore in this column is slightly dif- So, although the properties of software-based systems ferent, although it’s also concerned with the problems offer some specific problems to the designer (such as that the use of design methods can present. It can be software’s invisibility and its mix of static and dynamic expressed as a question: Will the adoption of a design properties), as individual design characteristics, these method help the software development process (the properties are by no means unique. Indeed, while “life belt” role), or is there significant risk that its use largely ignored by software engineers, the study of the will lead to suboptimum solutions (the “leg iron”role)? nature of design activities has long been established Robert L.
    [Show full text]
  • Software Design Document 1
    SOFTWARE DESIGN DOCUMENT 1. Introduction The following subsections of the Software Design Document (SDD) should provide an overview of the entire SDD. 1.1 Purpose This subsection should explain the purpose of the SDD and specify the intended audience for it. The SDD described the software structure, software components, interfaces and data necessary for the implementation phase. Each requirement in the SRS should be traceable to one or more design entities in the SDD. 1.2 Scope This subsection should relate the design document to the SRS and to the software to be developed. 1.3 Definitions, Acronyms and Abbreviations This subsection should provide the definitions of all terms, acronyms and abbreviations that are used in the SDD. 2. References This subsection should provide a complete list of all documents referenced in the SDD. It should identify these references by title, report number, date and publishing organization. It should also specify the sources from which these references are available. 3. Attributes of Design Entities There are some attributes common to all entities, regardless of the approach utilized, whether procedural or object-oriented. These are used in subsections 4 and later. 3.1 Identification The name of the entity should be specified. Two entities should not have the same name. 3.2 Type The type attribute should describe the nature of the entity. It may simply name the kind of entity, such as subprogram, module, procedure, process, data item, object etc. Alternatively, design entities can be grouped, in order to assist in locating an entity dealing with a particular type of information.
    [Show full text]
  • Software Design Document (SDD) Template
    Software Design Document (SDD) Template Software design is a process by which the software requirements are translated into a representation of software components, interfaces, and data necessary for the implementation phase. The SDD shows how the software system will be structured to satisfy the requirements. It is the primary reference for code development and, therefore, it must contain all the information required by a programmer to write code. The SDD is performed in two stages. The first is a preliminary design in which the overall system architecture and data architecture is defined. In the second stage, i.e. the detailed design stage, more detailed data structures are defined and algorithms are developed for the defined architecture. This template is an annotated outline for a software design document adapted from the IEEE Recommended Practice for Software Design Descriptions. The IEEE Recommended Practice for Software Design Descriptions have been reduced in order to simplify this assignment while still retaining the main components and providing a general idea of a project definition report. For your own information, please refer to IEEE Std 1016­1998 1 for the full IEEE Recommended Practice for Software Design Descriptions. 1 http://www.cs.concordia.ca/~ormandj/comp354/2003/Project/ieee­SDD.pdf Downloaded from http://www.tidyforms.com (Team Name) (Project Title) Software Design Document Name (s): Lab Section: Workstation: Date: (mm/dd/yyyy) Downloaded from http://www.tidyforms.com Software Design Document TABLE OF CONTENTS 1. INTRODUCTION 2 1.1 Purpose 2 1.2 Scope 2 1.3 Overview 2 1.4 Reference Material 2 1.5 Definitions and Acronyms 2 2.
    [Show full text]
  • Principles of Design
    Principles of Design Balance Proportion/Scale Emphasis Rhythm Introduction The principles of design are essential to the development and production of clothing used by individuals and families around the world. Each principle has a specific role in creating an aesthetically pleasing garment or ensemble. The principles of design consist of: balance, proportion (also referred to as scale), emphasis, and rhythm. When a garment or ensemble uses the elements and principles of design to create a visual unity, harmony is achieved. Garments often integrate more than one principle, while drawing from the elements of design to create a cohesive look. The following discussion will present background information on each of the principles of design and applications to clothing design and construction. Balance According to Wolfe (2011) balance implies that there is an equilibrium or uniformity among the parts of a design (p. 205). To achieve balance, a garment or ensemble should have equal visual weight throughout the design. The use of structural features, added embellishments, or decorations to a garment contribute to the appearance of a garment or ensemble being balanced or not. A clothing designer can utilize surface designs on fabric to construct a garment creating visual balance. Further, color, line, and texture can impact the balance of a design. For example, cool and light colors have less visual weight than dark, warm colors. If an individual is wearing a small amount of a dark, warm color it can be balanced out with a larger amount of cool, light colors. Balance used in clothing design can be categorized into two groups: Formal and Informal Balance.
    [Show full text]
  • Software Reliability and Dependability: a Roadmap Bev Littlewood & Lorenzo Strigini
    Software Reliability and Dependability: a Roadmap Bev Littlewood & Lorenzo Strigini Key Research Pointers Shifting the focus from software reliability to user-centred measures of dependability in complete software-based systems. Influencing design practice to facilitate dependability assessment. Propagating awareness of dependability issues and the use of existing, useful methods. Injecting some rigour in the use of process-related evidence for dependability assessment. Better understanding issues of diversity and variation as drivers of dependability. The Authors Bev Littlewood is founder-Director of the Centre for Software Reliability, and Professor of Software Engineering at City University, London. Prof Littlewood has worked for many years on problems associated with the modelling and evaluation of the dependability of software-based systems; he has published many papers in international journals and conference proceedings and has edited several books. Much of this work has been carried out in collaborative projects, including the successful EC-funded projects SHIP, PDCS, PDCS2, DeVa. He has been employed as a consultant to industrial companies in France, Germany, Italy, the USA and the UK. He is a member of the UK Nuclear Safety Advisory Committee, of IFIPWorking Group 10.4 on Dependable Computing and Fault Tolerance, and of the BCS Safety-Critical Systems Task Force. He is on the editorial boards of several international scientific journals. 175 Lorenzo Strigini is Professor of Systems Engineering in the Centre for Software Reliability at City University, London, which he joined in 1995. In 1985-1995 he was a researcher with the Institute for Information Processing of the National Research Council of Italy (IEI-CNR), Pisa, Italy, and spent several periods as a research visitor with the Computer Science Department at the University of California, Los Angeles, and the Bell Communication Research laboratories in Morristown, New Jersey.
    [Show full text]
  • Design by Contract: the Lessons of Ariane
    . Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] several hours (at least in earlier versions of Ariane), it was better to let the computa- tion proceed than to stop it and then have Design by to restart it if liftoff was delayed. So the SRI computation continues for 50 seconds after the start of flight mode—well into the flight period. After takeoff, of course, this com- Contract: putation is useless. In the Ariane 5 flight, Object Technology however, it caused an exception, which was not caught and—boom. The exception was due to a floating- point error during a conversion from a 64- The Lessons bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer: In other words, the value that was converted was greater than what of Ariane can be represented as a 16-bit signed inte- ger. There was no explicit exception han- dler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the onboard computers, hence the mission. This is the kind of trivial error that we Jean-Marc Jézéquel, IRISA/CNRS are all familiar with (raise your hand if you Bertrand Meyer, EiffelSoft have never done anything of this sort), although fortunately the consequences are usually less expensive. How in the world everal contributions to this made up of respected experts from major department have emphasized the European countries, which produced a How in the world could importance of design by contract report in hardly more than a month.
    [Show full text]
  • Improving Software Reliability Using Software Engineering Approach- a Review
    International Journal of Computer Applications (0975 – 8887) Volume 10– No.5, November 2010 Improving Software Reliability using Software Engineering Approach- A Review Aasia Quyoum Mehraj – Ud - Din Dar S. M. K. Quadri Research Scholar Director, IT & SS Director Computer Sciences University of Kashmir (India) University of Kashmir (India) University of Kashmir (India) ABSTRACT Randomness means that the failure can‟t be predicted accurately. Software Reliability is an important facet of software quality. The randomness of the failure occurrence is necessary for Software reliability is the probability of the failure free operation reliability modeling. In [MIO87], it is suggested that reliability of a computer program for a specified period of time in a specified modeling should be applied to systems larger than 5000 LOC. environment. Software Reliability is dynamic and stochastic. It differs from the hardware reliability in that it reflects design 3. RELIABILITY PROCESS perfection, rather than manufacturing perfection. This article The reliability process in generic terms is a model of the provides an overview of Software Reliability which can be reliability-oriented aspects of software development, operations categorized into: modeling, measurement and improvement, and and maintenance. The set of life cycle activities and artifacts, then examines different modeling technique and metrics for together with their attributes and interrelationships that are software reliability, however, there is no single model that is related to reliability comprise the reliability process. The artifacts universal to all the situations. The article will also provide an of the software life cycle include documents, reports, manuals, overview of improving software reliability and then provides plans, code configuration data and test data.
    [Show full text]
  • Theoretically Comparing Design Thinking to Design Methods for Large- Scale Infrastructure Systems
    The Fifth International Conference on Design Creativity (ICDC2018) Bath, UK, January 31st – February 2nd 2018 THEORETICALLY COMPARING DESIGN THINKING TO DESIGN METHODS FOR LARGE- SCALE INFRASTRUCTURE SYSTEMS M.A. Guerra1 and T. Shealy1 1Civil Engineering, Virginia Tech, Blacksburg, USA Abstract: Design of new and re-design of existing infrastructure systems will require creative ways of thinking in order to meet increasingly high demand for services. Both the theory and practice of design thinking helps to exploit opposing ideas for creativity, and also provides an approach to balance stakeholder needs, technical feasibility, and resource constraints. This study compares the intent and function of five current design strategies for infrastructure with the theory and practice of design thinking. The evidence suggests the function and purpose of the later phases of design thinking, prototyping and testing, are missing from current design strategies for infrastructure. This is a critical oversight in design because designers gain much needed information about the performance of the system amid user behaviour. Those who design infrastructure need to explore new ways to incorporate feedback mechanisms gained from prototyping and testing. The use of physical prototypes for infrastructure may not be feasible due to scale and complexity. Future research should explore the use of prototyping and testing, in particular, how virtual prototypes could substitute the experience of real world installments and how this influences design cognition among designers and stakeholders. Keywords: Design thinking, design of infrastructure systems 1. Introduction Infrastructure systems account for the vast majority of energy use and associated carbon emissions in the United States (US EPA, 2014).
    [Show full text]
  • Combining Design by Contract and Inference Rules of Programming Logic Towards Software Reliability
    Combining Design by Contract and Inference Rules of Programming Logic towards Software Reliability Nuha Aldausari*, Cui Zhang and Jun Dai Department of Computer Science, California State University, Sacramento, CA 95819, U.S.A. Keywords: Software Security, Software Reliability, Program Specifications, Error Detection, Design by Contract, Programming Logic. Abstract: Detecting errors in software products is very important to software reliability because many security vulnerabilities are caused by the defects in software. Design by contract (DBC) is an effective methodology that dynamically checks whether a program meets its specifications, which are also called design contracts, and whether there are errors in the program. The contracts for object-oriented programs are defined in terms of preconditions and postconditions for methods as well as invariants for classes. However, if there is an error in a large piece of code that has a design contract, it is still difficult to identify the exact location of that error. To address this issue, a tool named Subcontractor has been developed. Subcontractor is implemented in Eclipse environment using libraries such as Java Development Tools (JDT), Plugin Development Environment (PDE), and JFace. The tool Subcontractor is built upon an open source DBC tool, OpenJML Runtime Assertion Checking (RAC), which is a tool that verifies specifications at runtime. Subcontractor combines this DBC tool with inference rules of program logic for if-statements and loop- statements to automatically generate subcontracts for programs. When the programs, with subcontracts automatically generated and inserted by Subcontractor, are verified using OpenJML Runtime Assertion Checking (RAC), identification of errors in the code can be facilitated. 1 INTRODUCTION (University of Oldenburg, 2001), and Contracts for Java (C4J) (Bergström, 2012).
    [Show full text]
  • New Product Development Methods: a Study of Open Design
    New Product Development Methods: a study of open design by Ariadne G. Smith S.B. Mechanical Engineering Massachusetts Institute of Technology, 2010 SUBMITTED TO THE DEPARTMENT OF ENGINEERING SYSTEMS DEVISION AND THE DEPARTMENT OF MECHANICAL ENGINEERING IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREES OF MASTER OF SCIENCE IN TECHNOLOGY AND POLICY AND MASTER OF SCIENCE IN MECHANICAL ENGINEERING A; SW AT THE <iA.Hu§TTmrrE4 MASSACHUSETTS INSTITUTE OF TECHNOLOGY H 2 INSTI' SEPTEMBER 2012 @ 2012 Massachusetts Institute of Technology. All rights reserved. Signature of Author: Department of Engineering Systems Division Department of Mechanical Engineering Certified by: LI David R. Wallace Professor of Mechanical Engineering and Engineering Systems Thesis Supervisor Certified by: Joel P. Clark P sor of Materials Systems and Engineering Systems Acting Director, Te iology and Policy Program Certified by: David E. Hardt Ralph E. and Eloise F. Cross Professor of Mechanical Engineering Chairman, Committee on Graduate Students New Product Development Methods: a study of open design by Ariadne G. Smith Submitted to the Departments of Engineering Systems Division and Mechanical Engineering on August 10, 2012 in Partial Fulfillment of the Requirements for the Degree of Master of Science in Technology and Policy and Master of Science in Mechanical Engineering ABSTRACT This thesis explores the application of open design to the process of developing physical products. Open design is a type of decentralized innovation that is derived from applying principles of open source software and crowdsourcing to product development. Crowdsourcing has gained popularity in the last decade, ranging from translation services, to marketing concepts, and new product funding.
    [Show full text]
  • 3. Design by Contract
    3. Design by Contract Oscar Nierstrasz Design by Contract Bertrand Meyer, Touch of Class — Learning to Program Well with Objects and Contracts, Springer, 2009. 2 Bertrand Meyer is a French computer scientist who was a Professor at ETH Zürich (successor of Niklaus Wirth) from 2001-2015. He is best known as the inventor of “Design by Contract”, and as the designer of the Eiffel programming language, which provides built-in for DbC. DbC was first described in a technical report by Meyer in 1986: https://en.wikipedia.org/wiki/Design_by_contract Who’s to blame? The components fit but the system does not work. Who’s to blame? The component developer or the system integrator? 3 DbC makes clear the “contract” between a supplier (an object or “component”) and its client. When something goes wrong, the contract states whose fault it is. This simplifies both design and debugging. Why DbC? > Design by Contract —documents assumptions (what do objects expect?) —simplifies code (no special actions for failure) —aids debugging (identifies who’s to blame) 4 As we shall see, DbC improves your OO design in several ways. First, contracts make explicit the assumptions under which an object (supplier) will work correctly. Second, they simplify your code, since no special action is required when things go wrong — the exception handling framework provides the necessary tools. Third, contracts help in debugging since errors are caught earlier, when contracts are violated, not when your program crashes because of an invalid state, and it is clear where to lay the blame for the violation (i.e., in the object or its client).
    [Show full text]