ptg www.it-ebooks.info ptg Model-Based Development www.it-ebooks.info ptg This page intentionally left blank www.it-ebooks.info ptg Model-Based Development Applications H.S. Lahman Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City www.it-ebooks.info ptg Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or spe- cial sales, which may include electronic versions and/or custom covers and content particular to your busi- ness, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 corpsales@pearsontechgroup.com For sales outside the United States please contact: International Sales international@pearson.com Visit us on the Web: informit.com/aw Library of Congress Cataloging-in-Publication Data Lahman, H.S. Model-based development : applications / H.S. Lahman.—1st ed. p. cm. Includes index. ISBN 0-321-77407-8 (hardcover : alk. paper) 1. Model-driven software architecture. 2. Application software—Development. I. Title. QA76.76.D47L33 2011 005.1—dc23 2011012733 Copyright © 2011 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc. Rights and Contracts Department 501 Boylston Street, Suite 900 Boston, MA 02116 Fax: (617) 671-3447 ISBN-13: 978-0-321-77407-1 ISBN-10: 0-321-77407-8 Text printed in the United States on recycled paper at Courier in Westford, Massachusetts. First printing, June 2011 www.it-ebooks.info ptg v Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix About the Author. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Part I: The Roots of Object-Oriented Development . . . . . 1 Chapter 1: Historical Perspective. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Structured Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Functional Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Lessons Hard Won . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Global Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Elephantine Program Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Software Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Lack of Cohesion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Coupling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Technical Innovation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 The Turing Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Languages and Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Sets and Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Normal Form (NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Chapter 2: Object Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Basic Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Problem Space Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 OOA, OOD, and OOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 www.it-ebooks.info ptg vi CONTENTS Subject Matter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Separation of Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Levels of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Problem Space Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Cohesion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Logical Indivisibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Communication Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Breadth-First Processing (aka Peer-to-Peer Collaboration). . . . . . . . . . . . .44 Elaboration versus Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 The Message Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Object Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Chapter 3: Generalization, Inheritance, Genericity, and Polymorphism. . . . . . . . .53 Generalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Polymorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Inclusion (or Inherent) Polymorphism. . . . . . . . . . . . . . . . . . . . . . . . . . 60 Genericity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Chapter 4: MBD Road Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Problem Space versus Computing Space . . . . . . . . . . . . . . . . . . . . . . . . . .63 Problem Space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Computing Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Domain Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Modeling Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Partitioning the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 A Static View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 A Dynamic View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 Chapter 5: Modeling Invariants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 So Just What Is Modeling Invariants? . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 The Invariant Side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 The Data Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 The Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Bank ATM Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84 Hardware Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 www.it-ebooks.info ptg CONTENTS vii Depreciation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Remote POS Entry Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Chapter 6: Application Partitioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Why Do We Care? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Basic Concepts of Application Partitioning . . . . . . . . . . . . . . . . . . . . . . . 107 Subject Matter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Client/Service Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Levels of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Identifying Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 When abstracting the same entities as other subsystems, does the subsystem in hand have a different view of them? . . . . . . . . . . . . . 119 Is there a client/service relationship? . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Is the service more detailed than the client?. . . . . . . . . . . . . . . . . . . . . 120 Is knowledge shared with other subsystems?. . . . . . . . . . . . . . . . . . . . 120 Is behavior shared with other subsystems? . . . . . . . . . . . . . . . . . . . . . 120 Is the subject matter cohesive? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Is the boundary clearly defined? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Could it be reused as-is? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Is it bounded by a network in a distributed environment?. . . . . . . . . . 121 Is it a different problem space? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Bridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 The Message Paradigm, Yet Again . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 The Bridge Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Describing Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Subsystem Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Relationship Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Requirements Allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 An Example: Pet Care Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Legacy Replacement: A Practical Example . . . . . . . . . . . . . . . . . . . . . 147 Part II: The Static Model . . . . . . . . . . . . . . . . . . . . . . . 151 Chapter 7: Road Map to Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 What Is the Static Model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 www.it-ebooks.info ptg viii CONTENTS Knowledge versus Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Practical Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158 Chapter 8: Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Abstract Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Model of Something Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162 Local to a Subsystem or Component. . . . . . . . . . . . . . . . . . . . . . . . . . 164 Logical Indivisibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Delegation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165 Class Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Identifying Classes and Their Responsibilities . . . . . . . . . . . . . . . . . . . . .169 Object Blitz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169 Use Case Variant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 The Legendary Bank ATM Controller. . . . . . . . . . . . . . . . . . . . . . . . . 173 Pet Care Center: Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Using Sequence and Collaboration Diagrams . . . . . . . . . . . . . . . . . . . . . 186 Chapter 9: Class Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Attributes: What the Objects of a Class Should Know. . . . . . . . . . . . . . .191 Definitions and Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191 Not the Same as Data Storing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194 Abstract Data Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Operations and Methods: What an Object Must Do . . . . . . . . . . . . . . . .197 Definitions and Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199 Identifying Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Anthropomorphizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 ATM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209 Pet Care Center: Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222 Chapter 10: Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Definitions and Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239 The Nature of Logical Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . .242 Navigating to Knowledge versus Navigating to Behavior . . . . . . . . . . 244 www.it-ebooks.info ptg CONTENTS ix Association Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Association Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Conditionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Multiplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Replacing a Problem Space “One-or-More” with a Model “One” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Supplementing a Problem Space Association with a Second Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Selection versus Participation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Association Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Reification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Identifying Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 The ATM Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Pet Care Center: Disposition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Chapter 11: Referential and Knowledge Integrity . . . . . . . . . . . . . . . . . . . . . . . . 279 Knowledge Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Timeliness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Consistency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Snapshots versus Immediate Access. . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Dependent Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Normalization of Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Referential Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Identity and Referential Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Association Loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Relational versus OO Paradigms: Worlds Apart . . . . . . . . . . . . . . . . . 295 Chapter 12: Generalization Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Subclassing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Notation and Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Generalization and Specialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Categorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Inclusion Polymorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Why {disjoint, complete} Subsets?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Multi-directional Subclassing, Multiple Inheritance, and Composition . . 317 Liskov Substitution Principle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 www.it-ebooks.info [...]... software development As one might expect for something so utterly new, it wasn’t a panacea, and by the late ’70s some warts were beginning to show up Understanding what those warts were is critical to understanding why and how object-oriented development evolved in the ’80s www.it-ebooks.info Part I The Roots of ObjectOriented Development The Model-Based Development (MBD) approach to software development. .. need to go at software development in an organized and systematic way Because of this there is a lot of lip service paid to software engineering in today’s industry rags Alas, we are probably a long way from respectability as an engineering discipline Software development is still an art, although it is more bilious green than black The art lies in cobbling together a coherent development system that... self-correcting To achieve such understanding it is necessary to describe how traditional (pre-OO) approaches to software development failed in some ways and how the OO paradigm addressed those shortcomings While Structured Development brought substantial order to the chaos of pre-1970 software development, it was not a panacea, and by the ’80s it became clear that software still had serious maintainability... development The original idea here was to start with high-level, abstract user requirements and gradually refine them into more specific requirements that became more detailed and more specifically related to the computing environment Top-down development also happened to map very nicely into functional decomposition, which we’ll get to in a moment • Emergence of analysis and design SD identified development. .. that the reader has some software development experience, on the order of a couple of class projects in C It assumes that the level of experience includes a general knowledge of computers and programming, essentially enough to be familiar with common acronyms like KISS.4 A secondary audience is the large number of converts to the OO paradigm from traditional procedural development environments Many of... economics, operations research, and computing For the next three decades he developed software in MIS, scientific, and R-T/E environments He became an advocate of OO development in 1982 In the ’90s he became an advocate of improved software quality and development processes xxi www.it-ebooks.info This page intentionally left blank www.it-ebooks.info Introduction History is a nightmare from which I am trying... the point where security is probably more of a competitive issue www.it-ebooks.info xxv xxvi I NTRODUCTION Reliability Ease of use Availability Features Figure I-1 Trade-offs for conflicting development priorities development the question becomes: What tools are available to reduce the costs of filling the various buckets? We have a variety of software tools to help us, such as version control systems... process framework that is highly tailorable to local development environments 8 The Capability Maturity Model (CMM) is a true process framework in that it describes only what capabilities must be in place to produce good software, not how they should be implemented Thus compliance with the CMM is a necessary but not sufficient condition for good software development www.it-ebooks.info I NTRODUCTION lots... computing One of those was the Object-Oriented (OO) paradigm, with the primary goal of ensuring that large applications are maintainable over time as requirements inevitably change during the software product’s life cycle This book is about practicing a particular software design methodology, ModelBased Development (MBD), which is strongly based upon Shlaer-Mellor.1 Employing 1 The methodology is named for... framework and lots of alternatives to drape on it Selecting the right alternatives and gluing them together correctly for the particular development environment is left as an exercise for the student.” What Works Nonetheless, the reality is that the state of the art of software development has improved significantly over the past half century The same number of people routinely develop much bigger programs . ptg www.it-ebooks.info ptg Model-Based Development www.it-ebooks.info ptg This page intentionally left blank www.it-ebooks.info ptg Model-Based Development Applications H.S. Lahman Upper. Web: informit.com/aw Library of Congress Cataloging-in-Publication Data Lahman, H.S. Model-based development : applications / H.S. Lahman.—1st ed. p. cm. Includes index. ISBN 0-321-77407-8 (hardcover. software development failed in some ways and how the OO paradigm addressed those shortcomings. While Structured Development brought substantial order to the chaos of pre-1970 software development,