How to Engineer Software

IEEE Press445 Hoes Lane

Piscataway, NJ 08854

IEEE Press Editorial BoardEkram Hossain, Editor in Chief

David Alan Grier Andreas Molisch Diomidis SpinellisDonald Heirman Saeid Nahavandi Sarah SpurgeonElya B. Joffe Ray Perez Ahmet Murat TekalpXiaoou Li Jeffrey Reed

About IEEE Computer SocietyIEEE Computer Society is the world’s leading computing membership organizationand the trusted information and career-development source for a global workforceof technology leaders including: professors, researchers, software engineers, ITprofessionals, employers, and students. The unmatched source for technologyinformation, inspiration, and collaboration, the IEEE Computer Society is thesource that computing professionals trust to provide high-quality, state-of-the-artinformation on an on-demand basis. The Computer Society provides a wide rangeof forums for top minds to come together, including technical conferences,publications, and a comprehensive digital library, unique training webinars,professional training, and the TechLeader Training Partner Program to helporganizations increase their staff ’s technical knowledge and expertise, as well asthe personalized information tool myComputer. To find out more about thecommunity for technology leaders, visit http://www.computer.org.

IEEE/Wiley PartnershipThe IEEE Computer Society and Wiley partnership allows the CS Press authoredbook program to produce a number of exciting new titles in areas of computerscience, computing, and networking with a special focus on software engineering.IEEE Computer Society members receive a 35% discount on Wiley titles by usingtheir member discount code. Please contact IEEE Press for details.

To submit questions about the program or send proposals, please contact MaryHatcher, Editor, Wiley-IEEE Press: Email: mhatcher@wiley.com, Telephone: 201-748-6903, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774.

How to Engineer Software

A Model-Based Approach

Steve Tockey

© 2019 the IEEE Computer Society, Inc.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey.Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in anyform or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise,except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, withouteither the prior written permission of the Publisher, or authorization through payment of theappropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers,MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests tothe Publisher for permission should be addressed to the Permissions Department, John Wiley &Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online athttp://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of WarrantyWhile the publisher and author have used their best efforts in preparing this book, they make norepresentations or warranties with respect to the accuracy or completeness of the contents of thisbook and specifically disclaim any implied warranties of merchantability or fitness for a particularpurpose. No warranty may be created or extended by sales representatives or written sales materials.The advice and strategies contained herein may not be suitable for your situation. You shouldconsult with a professional where appropriate. Neither the publisher nor author shall be liable forany loss of profit or any other commercial damages, including but not limited to special, incidental,consequential, or other damages.

For general information on our other products and services or for technical support, please contactour Customer Care Department within the United States at (800) 762-2974, outside the UnitedStates at (317) 572-3993 or fax (317) 572-4002.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in printmay not be available in electronic formats. Formore information aboutWiley products, visit our website at www.wiley.com.

Library of Congress Cataloging-in-Publication Data is available.

hardback: 9781119546627

Set in 10/12pt Warnock by SPi Global, Pondicherry, India

Printed in the United States of America.

10 9 8 7 6 5 4 3 2 1

For Deanne

Contents

Foreword xiPreface xviiAcknowledgments xxvOnline Resources xxvii

Part I Introduction and Foundations 1

1 Introduction 3

2 The Nature of Code 39

3 Fundamental Principles 67

4 Functional and Nonfunctional Requirements 91

5 UML Overview 115

6 Partitioning Systems into Domains 125

Part II Semantic Modeling: Model-Based Functional Requirements 151

7 Use Case Diagrams: Scope and Context 153

8 Class Models: Policies to Enforce 183

9 Interaction Diagrams: Process at a Mid-Level 237

10 State Models: Process at a Fine-Grained Level 261

vii

11 Partitioning Domains into Subdomains 305

12 Wrapping Up Semantic Modeling 323

Part III Model-Based Design and Code 369

13 Introduction to Design and Code 371

14 Designing Interfaces: Specifying Real-World Interaction 379

15 High-Level Design: Classes and Operations 407

16 High-Level Design: Contracts and Signatures 447

17 Detailed Design and Code 503

18 Formal Disciplines of Design and Code 539

19 Optimization 583

20 Model Compilation 633

21 Advanced Open Model Compilation 675

22 Wrapping Up Model-Based Design and Code 705

Part IV Related Topics 723

23 Estimation 725

24 Development and Maintenance Processes 759

25 Economics of Error Handling 787

26 Arguments Against Model-Based Software Engineering 815

Part V Summary 827

27 Closing Remarks 829

viii Contents

Part VI Appendices 843

Appendix A: Documentation Principles 845

Appendix B: WebBooks 2.0 Background 849

Appendix C: WebBooks 2.0 Domains 853

Appendix D: Semantic Model for Order fulfillment 857

Appendix E: (Pro Forma) Order fulfillment Design 885

Appendix F: Semantic Model for Payment 905

Appendix G: (Pro Forma) Payment Design 927

Appendix H: Semantic Model for Scalability 943

Appendix I: (Pro Forma) Scalability Design 969

Appendix J: Semantic Model for High availability 985

Appendix K: (Pro Forma) High availability Design 1001

Appendix L: Semantics of Semantic Modeling 1011

Appendix M: Sample Production Rules 1049

Appendix N: Software Structural Complexity Metrics 1061

References 1081

Index 1091

Contents ix

Foreword

Meilir Page-Jones

People often ask me:

“Would you say that software development is more an art or a science?”

I reply,

“Neither. It’s a branch of the fashion industry.”

Every couple of years the software industry is gripped by one hot fad oranother. We’ve had “structured stuff,” “relational stuff,” “agile stuff,” “RADstuff,” “Kanban stuff,” “DevOps stuff,” “cloud stuff,” and so on. Each fad attractsits fanatical adherents, as well as its outraged opponents. Then, after a few yearsof heated passion, the fires die down on that particular fad. It becomes “old hat”and the fad’s remaining adherents are called dinosaurs. (How’s that for a mixedmetaphor?) Then it’s time to move on to the next craze.I’mnot saying that these fads are bad or useless. Most are effective in the right

contexts. The problem is sociological. Software can never become a true engi-neering discipline if techniques are hailed as game changing at one timeand decried as antiquated the next—for no reason other than that the fashionchanged.So it is with modeling. For the most part, software modeling arrived during the

1970s. It included (loosely speaking) approaches such as data flow diagrams, con-trol flow diagrams, entity-relationship diagrams, state-transition diagrams, andcode-structure diagrams. These diagrams were made more robust by standar-dized textual definitions of their components. Some were aimed at the elicitationof software requirements, and others more at the sound construction of code.

xi

This was a healthy trend for a field that was supposedly seeking to become anengineering discipline. After all, other engineering disciplines (such as civil,mechanical, industrial, and electrical engineering) depend on diagrams ofcomponents with their relationships and specifications.When software modeling arrived, three things happened. The first was that

people found it intellectually more difficult than the code-and-fix approach.The second (stemming from the first) was that many people gave up before theymastered it. The third was that—in shops that persevered with modeling—software productivity, quality, and manageability all increased markedly—inother words, a mixed landscape where some made great advances throughmodeling … and unfortunately others did not.It didn’t help that in the 1970s software modeling was an experimental craft,

which only a few dedicated early adopters could take to its full potential. It wasimmature and lacked solid standards and support tools. But the situationgradually improved so that by the mid-1980s software modeling was matureenough to be called mainstream.Well, sort of. There was indeed a deeper understanding of modeling techni-

ques, more conferences and seminars about it, further standardization, andsome tool support. But there were still enough gaps to keep modeling frombeing universal in the software industry. Nevertheless, I naively thought thatthe progress would continue: modeling would remain mainstream and becomemore widely adopted, more sophisticated, and better supported by automatedtools. The trend was certainly in that direction.But I’d reckoned without the Forces of Fashion. By the 1990s, and definitely

into the 2000s, software modeling had been dubbed “antiquated and only for theTriassic reptiles of the 1980s.” More than once I heard comments such as:

“That modeling crap is just for structured stuff. We’re an object-orientedshop.”

It was into this world of the 1990s that the Unified Modeling Language (UML)entered. UML synthesized some of the modeling approaches of the 1970sand 1980s, along with object-oriented constructs and a couple of techniquesfrom electrical engineering. UML both standardized modeling notation andembraced object-oriented concepts. Though not perfect, UML was a major stepforward and also ushered in a new generation of robust and sophisticatedmodeling tools.It was ironic timing. The fashion pendulum was already swinging against

modeling. In the 2000s the agile movement pushed the pendulum furtheragainst modeling by—perhaps deliberately, perhaps inadvertently—decryingdocumentation, which apparently included models. (I have more to say aboutthat below.)

xii Foreword

Currently, we’re in the bizarre situation where, in what should be a golden agefor software modeling with stable notation and mature tools, fewer softwareengineers by proportion are practicing modeling than in the 1980s. Softwaremodeling is in danger of becoming lost knowledge.The previous paragraph makes a mockery of the term “software engineering.”

Do you know any serious branch of real engineering that does not use rigorous“talking”models of whatever they plan to build? (“Talking model” is my term fora predictive model—one that can answer within acceptable tolerance qualitativeor quantitative questions about the subject to be built and maintained. Forexample, “What overall load and local pressure can this new bridge support?”)At this point, enters Steve Tockey. Because software modeling is probably

now at its most retrograde phase, it’s poised to swing back into favor. So Steve’sbook on software engineering comes at just the right time to give modeling ahefty shove in the right direction.Steve, whom I’ve known for over 30 years, is also just the right person to

write this book. He’s an adept programmer and a remarkable teacher. Moregermanely, he’s about the best modeler of the business world and of softwaresystems that I know. And, to top it all, he’s a fan of Bert Weedon.1

This book represents the confluence of all Steve’s talents. He brings to bearhis teaching ability, as well as his vast experience on all kinds of systems: largeand small, embedded and business, noncritical and safety-critical. Some of thatexperience was as a programmer. Some was as an analyst. Most of it was as amodeler.I have voluntarily and happily flown in planes whose test software was devel-

oped from models that Steve produced. I can’t think of anyone better placedthan Steve to write a comprehensive book on software modeling.But why should you bother to read this book? Didn’t I just say that software

modeling is out of fashion? Maybe so, but from your perspective, that’s not thepoint. If you’re a true engineer, fashion doesn’t matter. When I first learnedmodeling as a developer, the quality and quantity of my code took an immediatejump for the better. That’s a very typical experience, by the way. I adoptedthis motto:

“I’m a software engineer. I don’t need anyone else’s permission to domodeling. I don’t even care whether it’s fashionable or not. It works.”

This is even more true today: half a day’s salary can buy you your own state-of-the-art (not a toy) software modeling tool. You really don’t need anyone else’s

1 Bert Weedon was a guitar legend of the 1950s, who inspired many people to take up theinstrument, including Eric Clapton, Brian May, Jimmy Page, John Lennon, and Pete Townshend.

Foreword xiii

permission. So I expect that software modeling will swing back into fashionbefore long. Quietly, some of the top companies are already doing it—for severalgood reasons.Modeling promotes better communication among teams well before code is

written. After the code has been written is a bit late! Software modeling alsoembodies true engineering tenets. You’ll find a lot of them in this book, butlet me just call out one in particular, which is probably the best-kept secretin software engineering: domain separation (Chapter 6). Here’s an illustrationof what it means.On the desk in front of me is a lamp with domain separation. Without that

separation, in order to change the bulb, I’d need to unsolder the wires fromthe old bulb and resolder them on to the new bulb. But the domain of transport-ing electricity to my desk (including wires) is cleanly separated from the domainthat turns electricity into light (the bulb). The screw-in socket is the well-definedbridge between the two domains.That’s just a small illustration; Steve will take you more deeply into how it

applies to software. Without domain separation in software, code gets “solderedtogether” in ugly ways that degrade portability, optimization, debugging, andeven team organization. In fact, modeling itself becomes difficult.OK, domain separation is not very useful for tiny systems. But it’s vital for the

medium and large systems that most of us encounter now in commerce, indus-try, science, and the military. I know of several large-system efforts that pro-duced unmaintainable code or collapsed altogether because they’d failed toappreciate domain separation.I won’t take any more space in this foreword to promote arguments for

modeling—or the arguments against not modeling—because Steve himselfmakes those arguments so well in this book. But I’d better mention the “A”wordagain or you’ll think I’m not agile enough for prime time. (You think I’m notAgile? Oh, the shame of it!)A powerful myth has arisen that if you do any modeling at all then you’re not

agile. But it is just a myth. In fact, modeling is highly compatible with Agile. I’vebeen on four significant agile projects. One was very successful, two turned outreasonably well, and one was a disaster.The most successful one made heavy use of both requirements and design

modeling. It was very productive, kept up a good agile rhythm, and deliveredhigh quality, very usable, and useful software. In that project, the business ana-lysts, database designers, developers, user interface (UI) designers, and testersall used portions of the same models, which enhanced both team communica-tion and consistency. User stories were treated as brief commands to go forthand refine, enhance, or augment some portion of the requirements model (orother model, as the case may be). I won’t get into the details of the models thatwe used, because you’ll be reading all about them in this very book. But I will

xiv Foreword

remark that all our modeling was done with a robust modeling tool and storedwithin its repository.(Incidentally, the disaster project was a management circus. It started agile

and well organized enough, but it rapidly descended into such chaos that itbecame agile in name only. It used no modeling—but frankly, modeling prob-ably wouldn’t have saved this project anyway.)Steve has packed a lot of software modeling into this book. But don’t let that

intimidate you. Don’t think that you have to learn all of modeling in a singlewaterfall, big-bang, death-march weekend. Approach it incrementally. Startwith just one kind of model—whichever model will best clarify the projectyou’re working on now.Perhaps you’re a business analyst, trying to capture the states of a customer-

order-item. In that case, learn about state modeling first (Chapter 10). Ormaybeyou’re a developer trying to design a robust handshaking protocol between twomachines. In that case, knowing interaction diagrams would be very helpful(Chapter 9).But my personal favorite is the class model (Chapter 8). So much within the

other models depends on the focus and understanding that the class modelgives you. It’s also versatile. As a business analyst, you can capture the heartand soul of a company with a class diagram, which can be as sketchy or asdetailed as you choose. If you’re a developer, with a class diagram, you can lit-erally illustrate the classes in your code and how they interrelate.If you’re a student who’s studying software modeling in an academic course,

such as a bachelor’s degree in software engineering, the sequence of models youneed to work on will be outlined in your course curriculum. Actually, the organ-ization of chapters in this book is about right for a good sequence of coursetopics. (In reality, the complete contents of this book will probably need severalcourses to navigate through.)Whatever your situation, I wish you all the best in mastering the software

engineering that Steve’s book explains. Modeling and reasoning about softwarebefore you build it might seem alien and difficult at first. But then suddenlyyou’ll get it. Just like Eric Clapton did. And then you’ll wonder how you evermanaged without modeling.

Foreword xv

Preface

Software can be engineered. Software should be engineered. But trueengineering—in the sense of civil engineering, chemical engineering, mechan-ical engineering, aeronautical engineering, industrial engineering, etc.—ofsoftware requires more than just claiming “software engineer” as a job title:

• Engineering requires application of scientific and mathematical knowledge—Some software professionals have computer science or mathematics back-grounds, while many do not. Set manipulation and finite automata arerecurring themes in software. Proper reasoning about code behavior requiresapplication of propositional calculus. How can reliable software be builtwithout understanding these basic topics?

• Engineering requires application of a body of practice—Many softwareprofessionals don’t even know, let alone know how to apply, key practices likeabstraction, encapsulation, Design by Contract™, cohesion, coupling, designto invariants, design for change, programming by intent, software proof ofcorrectness, design patterns, test coverage criteria, and so on.

• Engineering requires economic decision-making—The vast majority ofsoftware professionals have no idea how to factor economic analysis intotechnical decision-making. Important decisions are usually based on“What would look good on my resume?” rather than what makes the mostfinancial sense for the organization. This has been facetiously referred toas “Resume Driven Development.”

In many jurisdictions it is illegal to call yourself an engineer if you are notlicensed or chartered by a government body. Licensing usually also carriespersonal liability for damage caused by errors in an engineer’s work. If youare a practicing software professional, would you be willing to take on personalliability for the software you develop and maintain? Read any typical SoftwareEnd User License Agreement to see how much liability today’s developers arewilling to take on.This book brings true engineering discipline to software development

and maintenance, resulting in software for which you should be willing totake on personal liability.

xvii

Why This Book?

Said another way, “Why should software be engineered?” This is explained fullyin Chapters 1–3, and 27. In brief

•Mainstream software projects are chronically late and over budget, the code isriddled with defects, and long-termmaintenance is costly and labor intensive.

• There are clear reasons why: poor requirements, overdependence on testing,and code not being self-documenting. Woven into this is an essentiallycomplete disregard of software semantics along with unmanaged complexity.

• The model-based software engineering approach in this book has been usedon many projects across a wide variety of industry verticals and has shownconsistent success. These projects are on time or early, are on budget orunder budget, deliver all intended scope or more, and amaze users with highquality.

• This approach is different from others, and these differences are critical insolving the software industry’s problems. These differences are presentedin Chapter 1 and explain why this approach to model-based software engi-neering is true engineering and also why projects using it are so successful.

Who Is This Book for?

This book is aimed at the software development and maintenance technicalcommunity such as developers, development leads, architects, and so on withintent to prepare them to be true software engineers. In some organizations, busi-ness analysts will do semantic modeling. User experience professionals can baseUI design on semantic models. Software testers/QA professionals can deriveverification test cases from semantic models. Project managers need a high-levelunderstanding of work being done on the project but tend to be most interestedin estimation and software process.Table P.1 defines a set of comprehension levels used in Table P.2. Table P.2

recommends comprehension levels for each chapter based on software proj-ect role.

History of the Author and of This Approach

I first learned programming in the fall of 1975: my senior year of high school.1

I started my first paid programming job in June 1977 when I developed softwarefor radiationmonitoring at nuclear power plants around the world. Concurrently,

1 Thanks, Ken, I owe you big time for getting me started down this lifelong path.

xviii Preface

Table P.1 Comprehension levels used in Table P.2.

Level Meaning

H This reader should read this chapter very carefully to get complete, detailedunderstanding and be able to fully apply it on projects

M This reader should understand most of the chapter, but it’s not necessary to be ableto apply everything on projects

L This reader should gain a broad understanding of chapter content, but it’s notnecessary to go beyond

— The reader does not need anything from this chapter, it is to safe skip

Table P.2 Recommended comprehension levels, by project role.

Chapter Developer Business analyst User experience Tester Project manager

1 H H H H H

2 H M or L M or L M or L M or L

3 H M M or L L or – L or –

4 H H M M or L L or –

5 M M or L L or – L or – L or –

6 H H M or L M M or L

7 H H M M or L L or –

8 H H M or L M or L L or –

9 H H M or L M or L L or –

10 H H M M or L L or –

11 H H M or L M or L L or –

12 H H M or L M or L L or –

13 H L M or L L or - L or –

14 H or M H or M H or M M or L L or –

15 H L or – — L or – L or –

16 H L or – — L or – L or –

17 H L or – — L or – L or –

18 H L or – — L or – L or –

19 H L or – — L or – L or –

(Continued)

Preface xix

I spent two years in the aeronautical engineering degree program at San Jose StateUniversity before transferring to University of California, Berkeley. I finished aLetters & Science Computer Science degree in 1981 and was two classes shortof a minor in economics.In August 1984 I joined Lawrence Livermore National Laboratory (LLNL) to

work in the Laser Isotope Separation2 program. This is where I was introducedto model-based software development using Ward and Mellor Real-TimeStructured Analysis and Design.3 Two model-based projects at LLNL were:

• Vapor rate monitor—By measuring absorption of a frequency-scanned laserbeam shone through a vapor stream, compute vapor density.

• Engineering demonstration system—Production-scale software and hard-ware to demonstrate Laser Isotope Separation technology at factory pro-duction rates. Steve Mellor was a consultant on this project.

My next career move was to Boeing Computer Services in the Seattle area inOctober 1987 where the goal was to unify real-time structured analysisapproaches4 with logical data modeling.5 This was where, on 13 November1987, Mark K. Smith and I created the core of the object-oriented approachin this book.6 While at Boeing I completed a Masters of Software Engineeringdegree at Seattle University. From 1994 to 1997 I taught as an adjunct professorin that same master’s degree program, presenting requirements, design, pro-gramming methods, Smalltalk programming, and engineering economics.

Table P.2 (Continued)

Chapter Developer Business analyst User experience Tester Project manager

20 H L or – — L or – L or –

21 H or M L or – — L or – L or –

22 H L or – — L or – L or –

23 H or M M or L L or – L or – H

24 H or M M or L L or – L or – H

25 H H or M H or M L or – L or –

26 M or L M or L M or L M or L M or L

27 H H H H H

2 See, for example, [Zare77].3 See [Ward86a], [Ward86b], and [Ward86c].4 Specifically, [Ward86a], [Ward86b], [Ward86c], and [Hatley88].5 For example, [Flavin81].6 First published as [Smith88].

xx Preface

I was Boeing’s representative to the Object Management Group7 (OMG) from1993 to 1997.Model-based software engineering was used on several Boeing projects:

• Airport traffic capacity simulator—Discrete event simulation model of airtraffic into and out of civilian airports. This is used to study the effects ofreconfiguring airport facilities, changing air traffic load, or modifying FederalAviation Administration (FAA)/European Union Aviation Safety Agency(EASA) “Separation rules.”

• Data center trouble tracking—Track problems reported by users at theBoeing Wichita data center and manage those problems to closure.

• Advanced Graphics Production System—Allow aeronautical engineers tovisualize input to, and output from, computational fluid dynamics code.

• Airplane Flight Manual/Digital Pilot’s Interface—A nontrivial proof ofconcept for putting an electronic flight manual into a cockpit, replacingtraditional paper. The code is a mathematical simulation that uses flight testdata and physics first principles8 to calculate the V1 speed9 for a commercialairplane.

• Integrated Network Management System—A voice and data network man-agement system covering network engineering (installation, configuration,performance monitoring, troubleshooting, etc.) and network operations(billing, trouble ticketing, service ordering, etc.)

• 767 Engine Simulator Automated Test Equipment (ATE)—Prior to 767Engine Sim ATE, all automated airplane tests were C implementations fromEnglish language specifications written by airplane test engineers. Thisproject developed a Simplified English Test Language (SETL) that is inter-preted and executed, allowing airplane test engineers to write executabletests directly.

• 777 Automated Test Equipment—An interpreter that supports the fullsystem functional test suite for the entire 777 airplane, fromAC/DC power onthrough avionics and flight controls.

• COMBASE—Re-implementation of the corporate employee recordssystem.

• DCAC/MRM10 Application Integration—A large-scale business processreengineering effort to revamp how Boeing designs, builds, sells, and sup-ports commercial airplanes. The Application Integration layer allows themore than 800 separate computing systems in DCAC/MRM to talk toeach other.

7 See www.omg.org8 For example, F = MA.9 The speed at which the airplane can no longer stop safely in the remaining runway; they arecommitted to fly.10 See, for example, http://www.boeing.com/news/frontiers/archive/2003/december/i_ca2.html

Preface xxi

• Flight Effects Test System—Make an airplane think it is flying while it is stillon the ground: read cockpit commands from airplane communication buses,compute the airplane’s reaction based on flight test data, and then injectsimulated responses back onto airplane communication buses.

Concurrent with Boeing, model-based software engineering was applied to theprobe placement subsystem for an automated silicon wafer tester at KLA. Thissubsystem loads new, untested etched wafers into the tester and sequentiallylocates chip-level test probes onto each etched chip. Another subsystem teststhe chip. This subsystem then marks that chip with color-coded paint to signifypass/fail. After testing all chips on a wafer, the next wafer is loaded and theprocess repeats until no more wafers are in the tester.My next career move was to Rockwell-Collins Avionics in Cedar Rapids,

Iowa, in July 1996. I brought Rockwell-Collins Avionics into the OMG andwas the corporate representative. Two Rockwell-Collins Avionics projects usedmodel-based software engineering:

• Distributed Rodentia—Allow users to access adjacent monitor screens frommultiple mice all at the same time.

• TCP/IP in Java—Rockwell-Collins Avionics built the first hardware Javavirtual machine (the hardware directly executes JVM byte codes; there is nosoftware virtual machine interpreter as in most Java environments) andwanted to demonstrate OMG’s CORBA on this hardware. All existing TCP/IPimplementations were either in C or C++, which the hardware JVM can’texecute. This project developed a Java implementation of TCP/IP.

UML was released to the public in 1997. The model-based software engineeringapproach was converted to UML notation shortly after that. The original mod-eling notation was unique.I began working for Construx Software back in the Seattle area in November

1998. Model-based software engineering projects that I have been directly orindirectly involved in since then include:

• Peopleware at Peopleware, Inc.—A conference planning and manage-ment tool.

• Altair and Oso at Los Alamos National Laboratory—Front-end and back-endvisualization of input to, and output from, computational fluid dynam-ics code.

• 777 ATE ARINC-629 Driver replacement at Boeing—The FAA prohibitstesting a commercial airplane using equipment that has been obsoleted by itsmanufacturer. The original ARINC-629 interface hardware used in 777 ATEwas about to be obsoleted. The new hardware is different enough that itrequired a new driver. Based on the size of the original driver code, the mostcredible estimate was that replacement would take four people about one

xxii Preface

year. By evolving from the original models of the driver, code was successfullyreplaced in under six weeks.

• Facilities management at Nordstroms—Allow the corporate facilitiesdepartment to plan and manage facilities and facilities changes.

• 787 Automated Test Equipment at Boeing—An interpreter that supports thefull system functional test suite for the entire 787 airplane, from AC/DCpower on through avionics and flight controls.

• P-811 Mission Systems at Boeing—The fly-the-airplane avionics are essen-tially stock 737 equipment. This project developed the back-end “in-the-tube”software that manages coastal defense mission planning and execution,identify-friend-or-foe, secure communication, weapons stores managementand deployment, etc.

• Pelican Well Placement Engineering upgrade at Schlumberger—Oil wells arerarely drilled entirely vertically. Most often, the optimum path has significanthorizontal components. Thus, the drill bit that is boring the well has to besteered. Pelican allows the drill operator to know the location of the drill bit in3D space and steer it to follow a preplanned optimum path. This projectadded critical functionality.

• Comprehensive cost estimation—A complex and highly proprietary tool forestimating the cost of building very large chemical plants for a multinationalcorporation. Two previous attempts used mainstream development and hadboth failed miserably.

Model-based software engineering was successful in all cases:

• Not one of these projects was late; some were early.

• Not one of these projects was over budget; most were under budget.

• Every project delivered at least the agreed-on functionality; some deliv-ered more.

• Users were consistently amazed how few defects were delivered, despitehaving far fewer testers than on equivalent mainstream software projects.

Most of this book explains howmodel-based software engineering works—howto apply it on real-world software development and maintenance projectsunder both waterfall and agile development lifecycles. Chapters 1, 2, 12, 22,and 27 explain why it works. There is a direct correlation between theproblems facing the software industry and critical elements of model-basedsoftware engineering that address those problems.

Steve Tockey

11 See, for example, https://en.wikipedia.org/wiki/Boeing_P-8_Poseidon

Preface xxiii

Acknowledgments

First, this approach builds on contributions of many,1 in particular:

•Mark K. Smith

• Steve McMenamin and John Palmer

• Sally Shlaer and Steve Mellor

•Meilir Page-Jones

• OMG’s Analysis and Design Task Force

•ModelDriven.org

• Dr. Sid Dijkstra

Second, thanks to all who reviewed and commented on manuscript drafts.I have tried hard to ensure everything in the book is correct. Nevertheless, manyerrors inevitably remain. Errors that remain are entirely my fault. Manuscriptcomments were provided by (in alphabetical order):

• Fumihiro Besso

• J. David Blaine

• Les Chambers

• Kristof Claeskens

• Brian Cohen

•Melina Costa

• Joachim Cruetz

•Marisette Edwards

• Ben Erickson

• C. Ross Eskridge

• Rik Essenius

• Dan George

• Regis George

• David Harold

• A. Lathif Masood

1 Stand, as they say, on the shoulders of giants.

xxv

• Alberto Melacini

• Eric Rimbey

• Ken Rose

• Hugo Sanchez

• Jeff Schroeder

• Arthur Sehn

•Michael Tempest

• Brian Wren

•Wu YongWei

• Zhang JianYang

• Theo Zimmerman

Warmest and sincerest thanks to Rik Essenius, Wu Yongwei, Eric Rimbey,Michael Tempest, and Zhang JianYang for their extensive and invaluablefeedback.

xxvi Acknowledgments

Online Resources

Online resources related to this book are available on a companion website:

http://www.construx.com/howtoengrsw/

This includes a free demonstration semantic model editor and open modelcompiler.

xxvii