CMPE 131

Vice President and Editorial Director, ECS: Marcia J. H orton Executive Editor:1tacy Dunkelberger Assistant Editor: Melinda H asgerty Director of Team-B ased Project Management: Vince O'Brien Senior Managing Editor: Scott Disanno Production Liaison: Jane Bonnell Production Editor: Pavithra Jayapaul, TexTech Senior Operations Specialist: Alan Fischer Operations Specialist: Lisa McDowell M arketing Manager: Erin D avis M arketing Assistant: Mack Patterson Art Director: Kenny Beck Cover Designer: Kristine Carney Cover Image: [credit to come] Art Editor: Greg Dulles Media Editor: Dani.el Sandin Me dia Project Manager: John M. Cassar Composition/Full-Service Project Management:Tex'Tuch International Pvt. Ltd.

Copyright © 2010, 2006, 2001, 1998 by Peiu son Higher Education. Upp er SaddJe Rh•er, New J ersey 07458. All rights reserved. Manufactured in the United States of America. lbis publication is protected by Copy- 1ight and permission should 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, mechanicaJ,photocopying, record- ing, or likewise. To obtain permission(s) to use materials from this work, please submit a w!'.itten request to Pearson Higher Education, Permissions Department, 1 Lake Street, Upper Saddle R iver, NJ 07458.

The author and publisher of this book have used their best efforts in preparing this book. These efforts include the development, research, and testing of the theories and programs to dete!'.mine their etrectiveness. The author and publisher make no warranty of any kind, expressed or implied, with regard to these programs or the documentation contained in this book. The author and publisher shall not be liable in any event for incidental or consequential damages in connection \vi th, or arising out o:f, the furnishing, performance, or use of these programs.

Library of Congress Cataloging-In-Publication Data Pfteeger. Shari Law:rence.

Software engineering: theory and practice I Shari Lawrence Pfleeger, Joanne M. Atlee. -4th ed. p.cm.

Includes bibliographical references an.d index. ISBN-13: 978-0-13-606169-4 (alk. paper) ISBN-10: 0.13-606169-9 (a.lk. paper)

1. Software engineering. I. Atlee, Joanne M. II. Title. QA76.758.P492010 005.l-<lc22 2008051400

Prentice Hall is an imprint of

PEARSON www.pe ar:sonhighered .com

10 9 8 7 6 5 4 3 2 1

ISB N-13: 978-0-13-606169-4

lSB N-10: 0.13-606169-9

" From so much loving and journeying, books emerge." Pablo Neruda

To Florence Rogart for providing the spark; to Norma Mertz fo r helping to keep the flame bu ming.

S.L.P.

To John Gannon, posthumously, fo r his integrity, inspiration, encouragement, friendship, and the legacy he has left to all of

us in software engineering. J.M.A.

Pref ace

BRIDGING THE GAP BETWEEN RESEARCH AND PRACTK E

Software engineering has come a long way since ]968, when the term was first used at a NATO conference. And softwa re itself has en tere d our lives in ways that few had anti- cipated, even a decade ago. So a fir m grounding in software e ngineering theory and practice is essential for understanding how to build good software and for evaluating the risks and opportunities that software presents in o ur everyday lives. This text repre- sents the ble nding o f the two current softwa re engineering worlds: that of the practi- tione r, whose main focus is to build high-q lllality products that pe rform useful functions, a nd that o f the resea rche r, who strives to find ways to improve the quality of productts a nd the productivity of those who build them. Edsga r Dykstra continually reminded us tha t rigor in research and practice tests o ur understanding o f software e nginee ring and helps us to improve our thinking, ou r approaches, and ultimately our productts.

It is in this spi rit that we have e nhanced our book, buildin g an unde rlying frame- wo rk for this questioning and improvement. In particular, this fo urth edition contains e xte nsive material abo ut bow to a bstract a nd model a p roblem, and how to use models, design p rinciples, design pau erns, and design strategies to create appropriate solutio ns. Softwa re engineers are more than programme rs fo llowing instructio ns, much as chefs are mor e than cooks following recipes. There is an a rt to building good software, an d the art is embodied in unde rstanding how to abstract and model the essential elements of a problem and then use those abstractions to design a solutio n. We often hear good devel- opers talk about "elegant" solutions, meaning that the solution addresses the hea rt of the proble m, such tha t not o nly does the software solve the problem in its current form but it ca n also be modified as the p roblem evolves over time. In this way, students learn to ble nd resea rch with practice and art with science, to build solid software.

The science is always grounded in reality. D esigned for an undergraduate soft- wa re e ngineering curriculum, this book paints a pragmatic pictu re of software e ngi- neering resea rch and practices so tha t students can apply what they lea rn directly to the rea l-world problems they are trying to solve. Examples speak to a student's limited experie nce but illustrate clea rly how large software develo pme nt projects progress from need to idea to reality. The examples represent the many situations that reade rs are like ly to experience: large p rojects and small, "agile" methods a nd highly structured o nes, object-orie nted a nd procedura l a pp roaches. rea l-ti me and tra nsaction processing, develo pment and mainte nance situatio ns.

The book is a lso suitable fo r a gradua te course offering a n introductio n to soft- ware e ngi neering concepts and practices, or for p ractitioners wishing to expand their

xiii

xiv Preface

knowle dge of the subj ect. Io particular, Chapters 12, 13, and 14 present thought- provo king mate rial designed to inte rest graduate stude nts in curre nt research topics.

KEY FEATURES.

This text h as many key features that distinguish it from other books.

• U nlike o ther software e ngineering books that consider measurement and mo del- ing as separate issues, this book blends measureme nt and modeLing with the m ore gene ral discussion of software engineering. That is, measureme nt and mode ling are conside red as an integral part of softwa re engineering strategies, rather than as separate discipLines. Thus, stude nts learn how to abstract and model, and how to invo lve quantita tive assessment and improvement in their daily activities. They can use their mode ls to unde rstand the imp ortant elements o f the proble ms t hey are solving as we ll as the solution alternatives; they ca n use measure men t to e val- uate their progress on an individual, team, and project basis.

• Similarly, concepts such as reuse, risk management, and quaLity e ngineering are embedded in the software engineering activities that are affected by them, inste ad of being tre ated as separate issues.

• The curre nt edition addresses the use of agile methods, including e xtreme program- ming. It describes the benefits and risks of giving developers more autonomy and contrasts this agil ity with more tradition al approaches to software development.

• Each chapter a pplies its concepts to two common examples: o ne that represents a ty pical information system, and anothe r that represents a real-time system. Both examples are based on actual projects. The inform ation system e xample describes the software neede d to de termine the price of advertising time for a large British te levision company. The real-time system is the control software for the Ariane -5 rocke t; we look at the problems reported , and explore bo w software engineering techniques could h ave he lped to locate and avoid some of them. Students can fo Uo w the progr ess of two typical project s, seeing how the va rious pract.ices described in the book are merged into the technologies used to build systems.

• At the end of every chapter, the results are expressed in three ways: what the con- te nt o f the chapter me ans for developme nt teams, what it means for individual deve lo pers, and what it means for researche rs. The student can easily review the highlights of each chapte r, and can see the chapter's relevan ce to both research and practice.

• The Companio n Web site can be found at www.prenhalJ.com/pfteeger. It contains curre nt examples from the lite rature and exampl es of real artifacts from reaJ projects. It also includes Links to We b pages fo r re levant tool and method ve ndo rs. It is here that students can find re al require ments documents, designs, code, test plans, and more. Stude nts seeking additional , in-depth information are pointed to re putable, accessible publicatio ns and Web s.ites. Tue We b pages are updated regu- la rly to keep the mate rial in the textbook current, and include a facility for feed- back to the autho r and the pubLisher.

• A Student Study G uide is available from your loca l Pearson Sales Representative.

Preface xv

• Po werPoint slides and a full solutions manual are available on the lnstructor Resource Ce nter. Pl ease contact your local Pe arson Sales Representative fo r access information.

• The book is re ple te with case studies and e xamples from the literature. Many of tbe one-page case studies sbowo as sidebars in tbe book are e xpanded on tbe Web page. The student c an see bow tbe book 's theoretical concepts are applied to r eal- life situations.

• Each chapter e nds with thought-provoking questions abo ut p olicy, legal, and e th- ical issues in software e ngineering. Stude nts see softwa re engineering in its social and po litical contexts. As with other sciences, software engineering decisions must be vie wed in te rms of the people their consequences will affect.

• E ve ry chapte r addresses both procedura l a nd o bject-orienrted developmen t. In addition, Chapte r 6 on design explains the steps of an o bject-orie nted develop- ment process. We discuss several design principles and use o bject-ori ented e xamples to show bow designs can be improved to incorpo rate these principles.

• The book has an anno tated bibliography that points to many o f the seminal pape rs in software en gineering. Io addition , the Web page points to anno tated bibliogr aphies and discussio n groups for specialized areas, su ch as softwa re relia- biJity, fault to lerance, computer security, and more.

• Each chapter includes a description of a term proj ect, involving d eve lopment of software fo r a mortgage processing system. The instructor may use this term project, o r a variatio n o f it, in class assignme nts.

• Each chapter e nds with a list o f key refe re nces for the concepts in the chapte r, e nabling stude nts to find in-depth informati on about particular tools and methods discussed in the chapter.

• This edition includes examples highlighting computer security. In particular, we e mphasize designing security in, instead of a dding it during coding or testing.

CONTENTS AND ORGANIZATION

This text is o rganized in three parts. The first part motivates the re ader, explaining why kno wle dge o f so ftware e nginee ring is important t o practitione rs and researche rs alike. Part I a lso discu sses the need for unde rstanding process issues, for making decisions about the degree o f " agility" develope rs will have, and for doing c are ful project plan- ning. Pa rt II walks through the majo r steps o f de velopment and maintenance, regard- less o f the process mode l used to build the software : e liciting, mo deling, and checking the requireme nts; design ing a solutio n to the pro blem; writing and testing the code; and turning it ove r to the custome r. P art III foc uses on evaluatio n and improvement. It looks at bo w we can assess the quality of our processes and products, and how to take steps to improve the m.

Chapter 1: Why Software Engineering?

In this cbapte r we address our track record , mo tivating the read er and highlighting whe re in later chapte rs certain key issues a re examined. Io particular, we look a t

xvi Preface

Wasserman's key factors that help de fine softwa re engineering: abstraction , analysis and design methods an d notati ons, modularity and architecture, software life cycle and process, re use, measurem ent, tools and integra ted enviro nments, and user interface and prototyping. We discuss the difference be tween computer scie nce and software en gi- neering, explaining some of the majo r types o f problems that can be encountered , and laying the groundwork for the rest of the book. We also e xplore the need to take a sys- tems approach to buiJding software, a nd we introduce the two common examples that wiU be used in every ch apter. It is he re that we introduce the context fo r the te rm project.

Chapter 2: Modeling the Process and Life Cycle

Io this chapte r, we prese nt a n overview o f diffe rent types o f process and life-cycle mod- e ls, including the waterfalJ model, the V-mod el, the spiral mode l, and various protort:yp- ing mod els. We address the need for agile method s, where deve lopers are given a great d eal of auto nomy, and contrast them with mo re traditio nal software deve lopment pro- cesses. We also describe several mo de ling techniques and tools, including syste ms d ynamics a nd othe r corrunonJy-used approaches. E ach o f the two common examples is modele d in part with some of the techniques intro duced here.

Chapter 3: Planning and M an.aging the Project

H e re, we look at project planning and scheduJing . We introduce notions such as activi- ties and milestones, wo rk breakdown structure, a ctivity graphs, risk management, and costs and cost estimation . Estimatio n models are used to estimate the cost and schedule o f the two common exam ples. We focus o n actua l case studies, including management o f software developme nt for the F-16 airplane and for Digital 's alpha AXP programs.

Chapter 4: Capturing the R equirem ents

T his cha pte r emphasizes the critical roles of abstracti on and mode ling in good software e ngineering. In p articuJa r, we use mo dels to tease out misunde rstandings and mi ssing d etails in provided requirements, as we ll as to communicate require ments to othe rs. We e xplore a number o f di ffe rent modeling paradigms, study example notations fo r e ach paradigm, discu ss when to u se each paradigm, a nd provide advice about how to make particular modeling and abstractio n decisio ns. We discuss diffe rent sources and differ- e nt types o f requirements (functional requireme10 ts vs. quality requirements vs. design constrai nts), explain how to write testable require ments, and describe bow to resolve conflicts. O ther topics di scussed include requirements e licitatio n, require ments docu - me ntatio n, require ments reviews, require ments q ua lity and how to measure it, a nd an e xampl e o f bow to select a specifica tion method. The chapter e nds with application of some of the methods to the two commo n examples.

Chapter 5: Designing the Architecture

This cha pte r on software architecture bas been completely revised for the fourth edition . It begins by describing the role of architecture in the software design process and in the

Preface xvii

larger d eve lopment process. We examine the steps involved in producing the a rchitec- ture, including mod eling, analysis, docume ntatio n, a nd re view, resulting in the creatio n of a Software Architecture Document that can be used by program designers in describing modules and interfaces. We discuss bow to decompose a problem into parts, and bow to use diffe re nl views to exa mine the severa l aspeccs o f the pro blem so as to find a suitable solution. Next, we focus o n modeling the solution ·using o ne o r more architectural styles, including pipe-and-filter, peer-to -peer, client-serve r, pu blish-subscribe, re posito ries, and laye ring. We look at combining styles and using them to achieve quality goals, such as modifia bilil y, pe rformance, securil y, re lia bilil y, robustness, and usability.

Once we have an initial architecture, we e valuate and refine it. In this chapter , we show ho w to measure design quality and to use evaluatio n techniques in safe ty ana lysis, security ana lysis, trad e-off ana lysis, and cost-bene fit analysis to selecl the best archi lec- ture for the custo me r's needs. We stress the importance of documenting the d esign ratio nale, validating and ve rifying that the design matches the re quireme nts, and er.eat- ing an architecture that suits the custo mer's product needs. Towards the end o f the chapter, we e xamine ho w to build a product-line architecture that aUo ws a software provide r to re use the design across a family o f similar products. The chapter e nds with an arcltitectural analysis o f o ur info rmatio n system and real-time e xamples.

Chapter 6: Desig ning the M odules

Chapter 6, substantially revised in this edition, investigates how to move from a descrip- tio n o f the system architeclure to descriptions o f the design's individual modules. We begin with a discussion of the design process and the n introduce six key design prin- ciples to guide us in fashio ning mod ules from th e architecture : mo dularity, inte rfaces, info rma tio n hiding, incre me ntal deve lopment, abs tractio n, and gene rality. Next, we take an in-de pth look at o bject-oriented design and how it supports our s ix principles. Using a variety o f no tations from the Unifie d Modeling Language, we sho w how to represent multiple aspects of module functio nality and inte raction , so that we can build a rob ust and mainta inable design. We also describe a collectio n o f design patte rns, each with a pa rticul!a r purpose, and d e mo nstrate ho w they can be used to re info rce the design prin- ciples. Next, we discuss glo bal issues such as data managemen t, e xceptio n handling, user interfaces, and framewor ks; we see how consiste ncy and clarity o f approach can le ad to mo re e ffective designs.

Taking a careful look at o bject-oriented measure ment, we app ly some o f the com- mon o bject-o riented me trics to a service sta tion example. We no te how changes in met- rics values, due to changes in the design, can help us decide bow Ito aUocate resources a nd sea rch fo r faults. Fina ll y, we apply o bject-orie nted concepts to o ur info rma tio n sys- tems and rea l-time examples.

Chapter 7: Writing the Programs

In this chapte r, we address code-level design decisio ns and the issu es invo lved in imple- menting a design to produce high-quali ty code. We discuss standa rds and procedures, and suggest some simple programming guide lines. Examples are provided in a varie ty o f languages, including both o bject-oriented and procedural. We discuss the need. for

xvi ii Preface

program documentatiom and an error-handling strategy. The chapter ends by applying some of the concepts to the two common examples.

Chapter 8: Testing the Programs

lo th.is chapte r, we explo re several asp ects of test:ing programs. We distingui sh conven- tional testing approaches from the cleanroom me thod , and we look at h ow to test a variety of systems. We present definitio ns and categories of software problems, and we discuss how o rthogonal defect classificatio n ca m make data collection and analysis more effective. We then explain the diffe rence between unit testing and integration testing. After introducing seve ral automated test tools and techniques, we explain the need for a testing life cycle and how the tools can be integrated into it. F111ally, the chap- te r applies these concepts to the two common e xa mples.

Chapter 9: Testing the System

We begin with principles of system testing, including reuse of test suites and data , and the need fo r careful configuration management. Concepts introduce d include function test- ing, performance testing, acceptance testing and installa tio n testing. We look at the spe- cial needs o f testing object-oriented systems. Several test tools are described, and the roles of test team members are discussed. Next, we introduce the reader to software re lia- bility modeling, and we explore issues o f reliability, maintainability, and availability. The reader learns how to use the results of testing to estimate the likely characteristics of the delivered product. The several types of test documentation are introduced, too, and the chapter ends by describing test strategies for the two common examples.

Chapter 10: Delivering the System

This chapter discusses tbe need for training and documentatio n, and presents several e xampl es of training and docume nts that could accompany the information system and real-time examples.

Chapter 11: Main taining the System

ln this chapter, we address the results of system change. We explain how changes can occur during the system's life cycle, and how system design, code, test process, and documenta- tion must accommodate t hem. Typical maintenance problems are discussed, as well as the need for careful configuration management. There is a thorough discus.sion of the use of measurement to predict likely changes, and to evaluate the effects of change. We look at ree ngineering and restructuring in the overall context of rejuve nating legacy syste ms. Finally, the two common examples are evaluated ill! terms of the like Li hood of change.

Chapter 12: Eva luating Products, Processes, and Resources

Since many software engineering decisions involve the incorporatjon and integration of existing components, this ch apter add resses ways to evaluate processes and products. It discusses the need for empirical evaluatio n and gives several examples to show how measure me nt can be used to establish a baseline fo r quality and productivity We look at

Preface xix

seve ral quality models, !bow to evaluate systems for reusa bility, how to perform post- morte ms, and how to understand return on investme nt in information technology. These concepts are applied to the two common examples.

Chapter 13: Improving Predictions, Products, Processes, and J<esources

This ch.apter builds on Chapter 11 by showing bow prediction, product, process, and resource improvement c an be accomplished. It co ntains several in-depth case studies to show ho w predictio n mo dels, inspection techniques, and o the r aspects of software e ngi- neering can be understood and improved using a variety of investigative techniques. This chapter ends with a set of guidelines for e valuating current situations and identify- ing opportunHies fo r imiProvement.

Chapter 14: The Fwure of Software Engineering

In this final chapter, we look at several open issues in software e ngineerin g. We revisit Wasserman's concepts to see bow well we are do ing as a discipline. We examine sev,eral issues in technology transfer and decision-making, to de termine if we do a good job at moving important ideas from research to practice. Fina lly, we examine controversial issues, such as licensing of software e ngineers as professional e ngineers and the trend towa rds more domain-specific solutio ns and me thods.

ACKNOWLEDGMENTS

Books are written as fri,ends and fa mil y provide technical and e motional suppo rt. It is impossi ble to list here all those who he lped to sustai n us during the writing and revising, and we apologize in advance fo r any o missions. Many thanks to the readers of earlie r editions, whose careful scrutiny of the text generated excellent su ggestions for correc- tion and clarification. As far as we know, all such suggestions have been incorporated into this edition. We continue to appreciate feedback from readers, positive or negative.

Carolyn Seaman (Uni versity of Maryland-Baltimore Campus) was a terrific reviewer of the first edition, suggesting ways to clarify and simplify, leading to a tighter, more understandable text. She also prepared most of the soluti ons to the exercises, and he lped to set up an earl y version o f the book's Web site. I am gra te:ful for he r friendship and assistance. Yiqing Liang and Carla Valle update d the We b site and added sub- stantial new material for the second e dition; Patsy Ann Zimmer (University of Water- loo) revised the Web site for the third editio n, particularly with respect to mode ling no tations and agile meth ods.

We owe a huge thank-you to Fo rrest Shull (Fraunhofe r Center-Maryland) and Roseanne Tesoriero (Washington College), who developed the initial study guide for this book; to Maria Vieira Nelson (Ca tholic Unive rsity o f Minas Gerais, Brazil), who revised the study guide and the solutio ns manual for the third editio n; and to Eduardo S. Barrenechea (University of Waterloo) fo r updating the materials for the fo urth edition. Thanks., too, to H ossein Saiedian (University o f Kansas) fo r preparing the PowerPo int presentation for the four th editio n. We are also particularly inde bted to Guilherme Travassos (Federal U niversity of Rio de Janeiro) for the use o f mate ri al that he developed

xx Preface

with Pfleeger at the University of Maryland-College Park, and that he enriched and e xpanded conside rably for use in subseque nt classes.

Helpful and thoughtful reviewers for all four editions included Barbara Kitcben- ham (Keele University, UK), Bernard Woolfolk (Lucent Technologies), Ana Regina Cavakanti da Rocha (Fe deral University of Rio de Janeiro), Frances Uku (University of Cali fornia at Be rkeley), Lee Scou Ehrhart (MITRE), Laurie Werth (University of Texas), Vickie Almstrum (University ofTexas), Lio nel Briand (S imula Research, Nor- way), Steve Thibaut (University of Flo rida), Lee Wittenberg (Kean College of New Jer- sey), Philip Johnson (University o f Hawaii), Daniel Berry (University of Waterloo, Canada), Nancy Day (University o f Wate rloo), Jianwei Niu (University of Wate rloo), C hris Gorringe (University of East Anglia , UK), Ivan Aaen (Aalborg University), Damla Turget (University of Central Florida), Lamie Williams (North Carolina State University), Ernest Sibert (Syracuse University),Allen HoUiday (California State Uni- ve rsity, Fullerto n) David Rine (George Mason Un ive rsity), Antho ny Sullivan (U niver- sity of 1exas, Dallas) , D avid Chesney (University of Michigan, Ann Arbor), Ye Duan (Missouri University) , Rammohan K. Ragade (Kentucky University), and several anonymous reviewers provided by Prenti ce Ha ll. Discussions with G reg Hislop (Drexel University), John Favaro ( lntecs Sisterni, Italy), Filippo Lanubile (Universita di Bari, Italy), John d ' Ambra (University of New South Wales, Australia), Chuck H ow- e ll (MITRE), Tim Yieregge (U.S. Army Compu ter Emergency R esponse Team) and James and Suzanne Robertson (Atlantic Syste ms Guild, UK) led to many improve- ments and e nhancements.

Thanks to Toni Holm and A lan Apt, who made the third e dition of the book's production interesting and relatively painless. Thanks, too, to James and Suzanne Ro bertson for tbe use of tbe Piccadilly example, and to Norman Fenton for the us e of mate rial from our software me trics book. We are grate ful to Tracy Dunkelberger for e ncouraging us in producing this fourth editio n; we appreciate both he r patience and he r professionalism. Thanks, too, to Jane Bonne ll! and Pavithra Jayapaul for seamless production.

Many thanks to the publishers o f several of the figures and examples for granting p ermission to reproduce them he re. The material from Complete Systems Analysis (Robe rtson and Ro bertson 1994) and Mastering the Requirements Process (Robe rtson and Robe rtson 1999) is drawn from and used with permission from Dorset House Pub- Lishing, at www.dorsethouse.com; au rights reserved. The article in Exercise 1.1 is repro- duced fro m the Washington Post with permission from the Associated Press. Figures 2.15 and 2.16 are reproduced from Barghouti et a l. (1995) by permission of John Wiley and Soos Limited. Figures 12.14 and 12.15 are reproduced from Rout (1995) by permis- sion o f John Wiley and Sons Limited.

Figures and tables in Chapters 2, 3, 4, 5, 9, 11, 12, and 14 that are noted with an IEEE copyright are reprinted with permissio n of the Institute of Electrical and Elec- tronics Engineers. Similarly, the three tables in Chapter 14 that are noted with an ACM copyright are reprinted with permissio n of the A ssociation of Computing Machinery. Table 2.1 and Figure 2.11 from Lai (1991) ar e re produce d with perrnis.sion from the Software Productivity Consortium. Figures 8.16 and 8.17 from Graham (1996a) are re printe d with permissio n from Dorothy R. Graham. Figure 12.11 and Table 12.2 are adapted from Liebman (1994) with permis.sion fro m the Cente r for Science in the

Preface xxi

Public Interest, 1875 Connecticut Avenue NW, Washington DC. Tables 8.2, 8.3, 8.5, and 8.6 are reproduced with permission of The McGraw-Hill Companies. Figures and examples from Shaw aod Garlan (1996), Card aod Glass (1990), Grady (1997), aod Lee and Tepfenhart (1997) are reproduced with permission from Prentice Hall.

Tab les 9.3, 9.4, 9.6, 9.7, 13.1, 13.2, 13.3, and 13.4, as well as Figu res 1.15, 9. 7. 9.8, 9.9, 9.14, 13.1, 13.2, 13.3, 13.4, 13.5, 13.6, and 13.7 are reproduced or adapted fro m Fenton and Ptleeger (1997) in whole or in part with permjssion from Norman Fenton. Figures 3.16, 5.19, a nd 5 .20 are reproduced or adapted from Norman Fe nton's course notes, with rus kind perntission.

We especiall y appreciate our e mployers, the RAND Corporation and the Univer- sity of Waterloo, respective ly, for their encouragement. 1 And we thank our friends and family, who offered their kfadness, support, and patience as the book-writing sto le time orrunarily spent with the m. In particular, Shari Lawrence Plleeger is gra te ful to Manny Lawrence, the manager of the real Royal Service Station , and to his bookkeepe r, Bea Lawrence, not o nly for working with he r and her students on the specification of the R oyal system, but a lso for their affection and guidance in their other job: as her parents. Jo Atlee gives special thanks to her pare nts, Nancy and Gary Atlee, who have sup- ported and encouraged her in everytlting she bas done (and attempted); and to her col- leagues and students, who gracio usly took on more than their share of work during the majo r writing periods. And, most especially, we thank Charles Pfteeger andl Ken Salem, who we re consta nt and much-appreciated sources of suppo rt, e ncouragement, and good humor.

Shari Lawre nce Ptleeger Joa rtne M. AtJee

1Please note tbat tbis book is not a product of t he RAND Corporation and bas not undergone RAND 's quality assurance process. The work represents us as authors, not as employees of our respective institutions.

About the Authors

Sha ri Lawre nce POeeger (Ph.D., Information Technology and Engineering, George Mason University; M.S. , Planning, Pennsylvania State Unive rsity; M.A., Mathe matics, Pe nnsy lvania State University; B.A., Mathematics, Ha rpur College) is a seniio r info rma- tion scientist at the RAND Corporation. He r current research focuses o n policy and decision-making issues that help organizatio ns and government agencies unde rstand whether and how information techno logy supports the ir missions and goals. Her work at RAND has involved assisting cLients in creating software measurement programs, supporting gove rnme nt age ncies in defining information assurance po Licies, and sup- porting decisio ns abo ut cybe r security and homeland security.

Prio r to joining RAND, she was the president of Systems/Software, Ille., a consul- tancy specializing in software engineering and technology. She bas been a visiting pro- fessor at City University (London) and the Unive rsity of Maryland a nd was the founder and direc tor o f H oward Unive rsity's Center for R esearch in Evaluating Soft- ware Techno logy. The author of many textbooks on software e ngineering and computer security, Pfleeger is we lJ known for her work in empirical studies o f so ftwa re enginee r- ing and for he r muJtjdiscipLinary approach to solving informatio n techno logy problems. She has been associate edito r-in-chi e f of IEEE Software, associa te editor o f IEEE Transactions on Soflware Engineering, associate editor of IEEE Security and Privacy, a nd a member of the IEEE Computer Society Technical Council o n Software Engi- nee ring. A frequent spea ke r at confe rences and workshops, Pfleeger has been named repeatedly by the Journal of Systems and Software as one o f the world 's top so ftware e nginee ring researchers.

Joanne M. Atlee (Ph.D. and M.S., Compute r Science, University o f Maryland; B.S., Compute r Scie nce a nd Physics, ColJege of WilJiam and Ma ry; P. Eng.) is a n Associate P rofessor in the School of Computer Scie nce at the University of Wa terloo. Her research focuses on software modeling, documentation, and analysis. She is best known fo r he r wo rk on mode l checkin g software requirements specificatio ns. Other research interests include mode l-based software engi neering, modular software d evelopment, feature in te ractio ns, and cost-be nefit ana lysis o f formal software development tech- niques. Atlee serves o n the editorial boards for IEEE Transactions on Software Engi- neering, Software and Systems M odeling, and the Requi.rements Engineering Journal a nd is Vice Chair of the Internation al Federation for Information Processing (IFIP) Wo rking G roup 2.9, an inte rnati o nal group o f resea rchers. wo rking o n advances in so ft- ware requireme nts engineering. She is Program Co-Chair for the 31st International Confe re nce o n Software E ngineering (I CSE'09).

Atlee also has strong inte rests in software engineering educa tion. She was the founding Direc to r o f Water loo's Bachelor's program in Software Engineeri ng. She

xx iii

xxiv About the Authors

served as a membe r of the Steering Committee for the ACMJIBEE-CS Computing Curricula-So ftwa re E nginee ring (CCSE) vo lwne, wh.ich provides curricular guide- lines for unde rgraduate programs in software engineering. She also served on a Cana- d ia n Engineering Q uali fications Board committee whose mandate is to set a software e ngineering syllabus, to offer guidance to provincial engineering associations on what constitutes acceptable academic quaLifications for Licensed Professional Engineers who practice software e ngineering.

SOFTWARE ENGINEERING

1

In this chapter, we look at • what we mean by software

engineering • software engineering's track record • what we mean by good software • why a systems approach is important • how software engineering has

changed since the 1970s

Software pe rvades o ur world, and we sometimes take for granted its ro le in making our Lives more comfortable, efficient, and effective. For e xample, consider the simple tasks involved in prep aring toast for breakfast. The code in the toaste r controls how brown the bread wiU get and when the finished product pops up. Programs control and regu- late the delivery of electricity to the house, and software biUs us for our energy usage. In fact, we may use a utomated programs to pay the electricity bill, to orde r mo re gro- ce ries, and eve n to buy a ne w toaste r! Today, softwar e is wo rking bo th e xplicitly and behind the scenes in virtua lly all aspects of our Jives, including the critical s ystems that affect our health and well -being. For thi s reason , software engineering is mo re impor- tan t than ever. Good software e ngineering practices must e nsure that softwa re makes a positive contribution to bow we lead our Lives.

This book highlights the key issues in software engineering, d escribing what we know about techniques and tools, and how they affect the resulting products we build a nd use. We will look at both t heory and practice: what we know and ho w it is applied in a typical software development or maintenance project. We will also exa mine what we do not yet know, but what would be he lpful in making our products mo re re liable, safe, useful, and accessible .

We begin by looking at bow we analyze problems and deve lop solutio ns. Then we investigate the d ifferences between computer science problems and engineering on es. O ur ultimate goal is to produce solutions incorporating high-quality software, and we conside r characteristics that contri bute to the quality.

2 Chapter 1 Why Software Engineering?

We also look at how successful we have been as develope rs of software syste ms. By examining seve ral examples o f software fa ilure, we see how far we have come and ho w much farther we must go in mastering the art of quality software de velopment.

Next, we look at the people involved in software d evelopment. After describing tbe ro les and responsibilities o f custo mers, users, and develo pers, we turn to a study of the system itself. We see that a system can be viewe d as a group of o bjects relate d to a set of activities and e nclosed by a bo undary. Alternatively, we look at a system with an e ngineer's eye; a system ca n be de ve loped much as a ho use is built. Having de fined the ste ps in building a system , we discuss the roles o f the de ve lopme nt te am at each step.

Finally, we discuss some of the changes that have affected the way we practice software e ngineering. We present Wasserman's eight ide as to ti e together our practices into a cohe re nt whole.

1.1 WHATIS SOFTWARE ENGINEERING?

As software engineers, we use our knowledge o f computers and computing to b elp solve proble ms. Often the proble m with whi ch we are dealing is re lated to a computer o r an existing computer system, but sometimes tbe difficulties underlying the pro blem have no thing to do with computers. Therefore, it is essential that we first understa nd the nature of the problem. [ n particula r, we must be ve ry care ful no t to impose computing machin ery or techniques o n eve ry proble m that comes our way. We must solve the proble m first. Then, if n eed be, we can use techno logy as a tool to imple ment our solu- tion. For the re mainder o f this book, we assume that o ur analysis has sho wn that some kind of computer system is necessary or desirable Ito solve a particular problem at hand.

Solving Problems

Most proble ms are large and some times trick y to handle, especiaUy if they represent some thing new that bas ne ve r been solved before. So we must begin investigating a pro blem by an al yzing it, that is, by breaking it into pi eces that we can understand and try to d eal with. We can thus describe the larger p roblem as a coUection o f small prob- lems a nd their interrelatio nships. Figure 1.1 iUustrates how analysis works. It is impor- tant to re member that the relatio nships (the arrows in the figure, and the re lative positions o f the subprob lems) are as essentia l as the subprobl e ms themselves. Som e- times, it is the relationships that hold the clue to how to solve the larger problem, rather than simply the nature of the subproblems.

Once we have anal yzed the problem, we mu.st construct our solutio n from compo- ne nts that address the problem's vario us aspects. Fi gure 1.2 illustra tes th.is reverse pro- cess: Synthesis is the putting togethe r of a large structure from sma ll building blocks. A s with analysis, the compositio n of the individual soluti ons may be a s challenging as the process. of finding the solutions. To see why, consider the process of writing a novel. The dictio nary contains all the words that you might want to use in your writing. But the most di.fficult part of writing is deciding ho w to organize and compose the words into sentences, and likewise th e sentences into paragraphs and chapters to form the complete book. Thus, any problem -solving technique must have two parts: analyzing the problem to dete rmine its nature, and then synthesizing a solution based on o ur analysis.

Section 1.1 What Is Software Engineering? 3

PROBLEM

Q

.__________.I D I

~--~II I Q

Subproblem 4 Subproblem 1 Subproblem 2 I~~.-~

~--~~----~11~~-~-~-~~31~~~~ FIGURE 1.1 The process of analysis.

11

Solution 4

~S-olu-tion_i_~~S-olu-tio-n2---~~-~~~~~~ _ . _ II Solution 31_

Q .-----------.I D

I II I

Q SOLUTION

FIGURE 1.2 The process of synthesis.

4 Chapter 1 Why Software Engineering?

To he lp us solve a proble m, we employ a variety of methods, tools, procedures, and paradigms. A me thod or technique is a formal procedure for producing some result. For example, a chef may prepare a sauce using a sequence of ingredients com- bined in a carefully time d and ordere d way so that the sauce thicke ns but does not cur- dle or separate . The procedure fo r pre paring the sauce involves timing and ingredie nts but may not dep end on the type o f cooking eq uipment used.

A tool is an instrume nt or auto mated syste m for accomplishing something in a bette r way. This " better way" can mean that the tool makes us more accurate, more e ffi- cie nt, o r more producti ve o r that it e nhances the quality of the resulting product. For e xample, we use a type writer or a keyboard and printe r to write letters because the resulting docume nts are easier to re ad than o ur handwriting. Or we use a pair of scis- sors as a tool beca use we can cut fas ter and stra£gbte r than if we were te aring a page. H owever, a tool is not always necessary fo r ma king some thing well. Fo r example, a coo king technique can make a sauce bette r, no t tbe pot or spoon used by the chef.

A procedure is IJk e a recipe: a combinatio n o f tools and techniques tbat, in con- cert, produce a particular product. Fo r instance, as we wiU see in late r chapters, our test plans d escribe our test procedures; they tell us which tools will be used on which data se ts under which circumstances so we can de te rmine whe ther our software meets its require me nts.

FinaUy, a paradigm is like a cooking style; it represents a particular approach or philoso phy for building software. Just as we can distinguish French cooking from Chi- nese cooking, so too do we distinguish pa radigms IJke o bject-oriented development from procedural ones. O ne is not be tte r than ano ther; each has its advantages and dis- advantages, and there may be situations when one is more appropriate than anothe r.

So ftware enginee rs use tools, techniques, procedures, and paradigms to enhance the qua lJty o f their software products. Their aim is to use e fficient and productive approaches to gene rate e ffective solutions to proble ms. In the chapters that follow, we wiU highlight particular approaches that suppo rt the developme nt and mainte nance activities we describe. An up-to-date set o f pointe rs to tools and techniques is liste d in this book's associated ho me page on the Wo rld Wide Web.

Whe re Does the Software Enginee r Fit In?

To unde rstand how a software engineer fits into tlile computer scien ce wo rld, let us look to anothe r discipline for an example. Conside r the study of che mistry and its use to solve proble ms. The che mist investigates che micals: the ir structure, their interactions, and the theory behind the ir behavior. Chemica l e ngineers apply the results of the che mist 's studies to a var iety of pro ble ms. C he mistry as vi ewed by chemists is the o bject o f study. On the othe r h and, for a che mical e ngineer, chemistry is a tool to be used to address a gene ral proble m (which may no t even be "chemical" in nature).

We can view computing in a similar light. We can concentrate on the computers and programming languages, or we can view them as tools to be used in designing and implementing a so lution to a problem. So ftware engineering takes the latter view, as shown in Figure 1.3. Instead o f in vestiga ting ha rdware design or proving theore ms abo ut h ow algoritluns wo rk, a software engineer focuses on the compute r as a pro blem- solving tool. We will see la ter in this ch apter that a software e ngineer wo rks with the

COMPUTER SCIENCE

ENGINEERING

Tools and Tec~niques to Sol~e Problem

Section 1.2

CUSTOMER

Problem

How Successful Have We Been? 5

FIGURE 1.3 The relationship be twee n computer science a nd softwa re engineering.

functio ns o f a computer as part of a gene ral solutio n, rathe r than with the structure o r theory o f the compute r ~tse lf.

1.2 HOW SUCCESSFUL HAVE WE BEEN?

Writing software is a n art as we ll as a scie nce, and it is impo rtant for you as a stude n t of computer science to unde rstand why. Compute r scientists and software engineering researchers study compute r mechanisms and the o rize about how to make the m mo re product ive o r e fficient. Howe ve r, they also desig n compute r syste ms and write p ro- grams lo pe rform tasks o n those systems, a prac tice tha t invo lves a gre at deal of art, ingenuity, a nd skill. The re may be man y ways to pe rform a particular task o n a particu- lar syste m, but some are be tte r than o thers. One way may be mo re e fficient, mo re pre- cise, easier to modify, ea sie r to use, o r easier to understand. Any hacker can write code to make something wo rk, but it takes the skill and unde rstanding o f a professio nal soft- wa re engineer to prodll!ce code that is robust, easy to understand and maintain, and does its jo b in the most e fficient and effecti ve way possible. Consequently, software e ngineering is a bout des.igning and develo ping hig h-q uality softwa re.

Be fore we e xamine what is need ed to produce quality software syste ms, let us look back to see ho w success:ful we have been. A re users happy with their existing soft ware systems? Yes and no. Software has enabled us to perform tasks more quickly and effec- tively !Jl.an e ver before. Consider life before word processing, spreadsheets, electronic mail , or sophisticated tele phony, for example. And so ftware has supported life-sustaining o r Life-saving advances in medicine, agriculture, transpo rtatio n, and most o the r indus- tries. In addition, softwar e has e nabled us to do things that we re never imagined in the past: microsurgery, multimed ia education, ro bo tics, and mo re.

6 Chapter 1 Why Software Engineering?

H owever, software is not without its problems. Often systems function , but not exactly as expected. We all have hea rd stories of systems that just barely work. And we aU have writte n faulty programs: code that contains mistakes, but is good enough for a passing grade o r for dem on strating tbe feasibility of a n approach. Clearly, sucb behav- ior is no t acceptable when developing a system for delivery to a customer.

There is an enormous difference between an error in a class project and one in a large software system. In fact, software faults a nd the difficulty in producing faul t-free software are frequently discussed in tbe literature and in the ha llways. Some faults are me rely annoying; othe rs cost a great dea l of time and mo ney. Still others are ltife- tbreatening. Sideba r 1.1 explains the re lationships among faults, e rrors, and failures. Let us look at a fe w examples of fai lures to see wbat is going wrong and why.

SIDEBAR 1.1 TERMINOLOGY FOR DESCRIBING BUGS

Often, we talk about " bugs" in software, meaning many things that depend on the context. A "bug" can be a mistake in interpreting a requirement, a syntax error in a piece of code, o r the (as-yet-Wlknown) cause of a system crash. Th e Institute of E lectrical and E lectronics

Engineers (IEEE) has suggested a standard terminology (in IEEE Standard 729) for d escrib- ing " bugs" in our software products (IEEE 1983).

A fault occurs when a human makes a mistake, called an error, in performing some soft-

ware activity. For example, a designer may misWlderstand a requirement and create a design that does not match the actual intent of the requireme nts analyst and the user. This de.~ign fa1U lt

is an encoding of the error, and it can lead to other fallllts, such as incorrect code and an incor-

rect descriptio n in a user manual. Thus, a single error can generate many faults, and a fault can reside in any development or maintenance product.

A failure is a departure from the system's required behavior. It can be discovered before or after system delivery, during testing, or during operation and mainte nance. As we will see

in Chapter 4, the requirements documents can contain faults. So a failure may indicate that

the system is not performing as required , even though it may be performing as specified

Thus, a fault is an inside view of the system, as seen by the eyes of the developers, whereas a failure is an outside view: a problem that the user sees. Not ev,ery fault corresponds

to a failure; for example, if faulty code is never executed or a particular state is never e nte re d, then the fault will never cause the code to fail. Figure 1.4 shows the genesis of a fail ure.

..... 15' ..... ?I ean lead to ean lead lo • •

human error fault failure

FIGURE 1.4 How human error causes a failure.

Section 1.2 How Successful Have We Been? 7

Io the early 1980s, the United States Internal Revenue Service (IRS) hired Sperry Corpo ratio n to build an automated federal income tax form processing system. Accord- ing to the Wash ington Post, the "system . . . proved inadequate to the workload, cost nearly twice what was expected and must be replaced soon " (Sawyer 1985). lo 1985, an e xtra $90 million was needed to enhance the o riginal $103 mi llion worth o f Sperry equip- ment. In addition , because tbe pro blem prevented the IRS from re turning refunds to ta x- payers by tbe de adline, the IRS was forced to pay $40.2 million in inte rest and $22.3 million in overtime wages for its e mployees who were trying to catch up. In 1996, the situ- a tio n had not improved. The Los Angeles Times reporte d on March 29 that there was s tiU no master plan for the modernization of IRS compute rs,onJy a 6000-page technical docu- ment. Congressman Jim Lightfoo t called tbe project " a $4-billion fiasco that is flounder- ing because of inadequate p lanning" (Yartabedian 1996).

Situations such as these still occur. In the United States, the Federa l Bureau of Investigatio n's (FBI's) Tril ogy project attempted to upgrade the FBI's computer systems. The results were devastating: "Afte r more than four years o f hard work and half a billio n dollars spent, ho wever, Trilogy has had little impact on the FBI's antiquated case-man- agement syste m, which today re mains a morass of mainframe green screens and vast sto res o f paper records" (Kno rr 2005). Similarly, in the United Kingdom, the cost of ove r- ha uling the National Health Service's information systems was do uble tbe o riginal esti- mate (Ballard 2006). We will see in Chapter 2 why project planning is essential to the productio n of quality software.

Fo r many years, the public accepted tbe infusio n of software in their daily lives with little question . But President Reagan 's proposed Strategic De fense Initiative (SDI) heightene d the publi c's aware ness of the di[flculty of producing a fa u lt-rree so ft- ware system. Po pular newspape r and magazine repo rts (such as Jacky 1985; Pa rnas 1985, Rensburger 1985) expressed skepticism in the computer science community. And no w, ye ars la te r, when the U.S. Congress is asked to all ocate funds to build a simila r sys- tem, man y compute r scientists and software engineers continue to believe there is no way to write and test the software to guarantee adequate reliability.

For exampl e, many software engineers think that an anliballis lic-rnis.sile system wo uld require at least 10 milLion Lines of code; some estimates range as high as one hun- dred million. By comparison , the software supporting the Ame rican space shuttle consists o f 3 million lines o f code, including computers on the ground controlling the launch and the flight; the re we re 100,000 lines of code in the shuttle itself in 1985 (Rensburger 1985). Thus, an antimissile software syste m would require the testing o f an e no rmol!lS amount of code. Mo reover , the reliability constraints would be impossible to test. To s.ee why, con- sider the notion of safety-critical software. Typically, we say that some thing that is safety- critical (i.e., some thing whose failure poses a threat to li fe o r health) sho uld have a relia bi(jty o f at least 10-9. A s we shall see in Chapte r 9, thi s terminology means that the syste m ca n fail no more o ften th an once in 109 hours of ope ratio n. To o bserve this degree o f reLiability, we would have to run the system for at least 109 ho urs to verify that it does not fail. But 109 ho urs is ove r 114,000 years-far too long as a testing interval!

We will also see in Chapte r 9 that helpful technology can become d eadly when software is improperly designed or programmed. For example, the medical community was aghast whe n the Therac-25, a r adi ati on therapy and X -ray machine, ma lfunctio ned and killed sever al patients. The software desig ners bad not anticipa ted the use of several

8 Chapter 1 Why Software Engineering?

arrow keys in nonstandard ways; as a conseq uen ce, the software retained its high set- tings and issued a highl y concentrated dose o f radiatio n whe n low levels were inte nded (Leveson and Turne r 1993).

Similar examples of unanticipated use and its dangerous consequences are easy to find. Fo r e xample, recent efforts to use off-the-she lf compo nents (as a cost savings mea- sure instead of custom-crafting of software) result in designs that use compone nts in ways not intended by the original d evelope rs. Many licensing agreements explicitl y point to the risks of unanticipated use: " Because each end-user syste m is customized and diffe rs from utilized testing platforms and because a user or application designe r may use the software in combination with o the r products in a manne r not evaluated or con- templated by [the vendor] o r its supplie rs, the use r or application d esigner is ultimately respo nsible for verifying and validating the [software]" (Loo ko ut Direct n.d.).

U nanticipated use of the system should be considered throughout software design activities. These uses can be handled in at least two ways: by stretching your imagination to think of h ow the system can be abused (as well as used properly), and by assuming that the system will be abused and d!esigning the software to handle the abuses. We discuss these approaches in Chapte r 8.

Although many vendors strive fo r zero-defect software, in fact most software products are not fault-free. Market forces enco ruage software d evelopers to detiver products quickly, with lilttle time to test thoroughly. Typically, the test team will be able to test only those functions most like ly to be used, o r those tha t are most like ly to e ndanger or irritate users. For this reason, many users are wary of installing the first version of code, knowing th at the bugs will no t be worked out until the second ve rsion. Furthe rmore, the modifications need ed to fix known faults are sometimes so difficuat. to make that it is e asie r to rewrite a who le syste m t han to chan ge existing code. We will investigate the issues involved in software mainte nance in C hapter 11.

In spite of some sp ectacular successes and the ove rall acceptance of software as a fact of life, there is still much room for improvement in the quality of the software we produce. For example, lack of quality can be costly; the lo nger a fault goes undetecte d, the mor e e xpensive it is to correct. In particula r, the cost o f co rrecting an e rror made during the initial an alysis of a project is estim ated to be o nly one-te nth the cost of cor- recting a similar error afte r the syste m has been turned ove r to the customer. Unfo rtu- nately, we do not catch most of tbe e rrors early on. Half o f the cost of correcting faults found during testing and maintenance comes l:ro m e rrors made muc h e arlier in the life of a system. In Chapters 12 and 13, we wi ll look at ways to evaluate the effectiveness o f our development activities and improve the processes to catch mistakes as early as possibl e.

One of tbe simple but powerfuJ techniques we will propose is the use of re view and insp ectio n. Many stude nts are accusto med to deve lo ping and testing software on their own. But their testing may be less e ffecti ve than tbey think. Fo r example, Fagan studied the way faults were detected. He discove red that testing a program by running it with test data revea led only a bout a fifth of the faults located during systems develop- ment. However, peer review, the process whereby coUeagues examine and comme nt on each o ther's designs and code, uncovered the remaining four out o f five faults found (Fagan 1986). Thus, the ,q uality of your software can be increased dramatically just by having your coUeagues review your wo rk. We will le arn more in later chapters about ho w the review and insp ection processes can be· used afte r each major development

Section 1.3 What Is Good Software? 9

step to find and fix faults as early as possible. And we wiU see in Chapter 13 how to improve the inspection process itself.

1.3 WHAT IS GOOD SOFTWARE?

Just as manufacturers look for ways to ensure the quality of the products they produce, so too must software engineers find methods to ensure that their products are of acceptable quality and utility. Thus, good software engineering must always include a st rategy for pro- ducing quality software. But before we can devise a strategy, we must understand what we mean by quality software. Sidebar 1.2 shows us how perspective inftuences what we mean by "quality." In this section, we examine what distinguishes good software from bad.

SIDEBAR 1.2 PERSPECTIVES ON QUALITY

G all'Vin (1984) discusses about how different people perceive q uality. H e describes quality from five different perspectives: • the transcendental view, whe re quality is something we can recognize but not d efine

• the user view, whe re quality is fitness for purpose

• the manufacturing view, whe re q uality is conformance to specification

• the product view, where q uality is tied to inhe rent product c haracteristics

• the value-based view, where quality depends o n the a mount the c ustomer is willing to pay for it

The transcendental view is much like Plato's description of the ideal or Aristotle's con-

cept o f form. In other words, just as every actual table is an approximation of an ideal table,

we can think of software quality as an ideal toward which we s trive; however, we may never

be able to implement it comple tely. The transcendental view is ethereal, in contrast to the more concrete view of the user.

We take a user view when we measure product characteristics, such as defect density o r relia-

bility, in order to understand the overall produc t quality.

The ma nufacturing view looks at quality during production and after delivery. In partic-

ular, it examines whether the product was built right the fi rst time, avoiding costly rework to

fix delivered faults. Thus, the manufacturing view is a process view, advocating conformance to good process. However, there is little evidence that conforma nce to process actually results

in products with fewe r faults a nd failu res; process may indeed lead to h igh-quality products,

but it may possibly institutionalize the production of mediocre products. We exa mine some of

these issues in Chapter 12.

The user and man ufacturing views look at the pr oduct from the o utside, b ut the product

view peers inside and evaluates a product's inherent ch aracte ristics. This view is the one oft.e n

advocated by software m etrics experts; they assume that good internal quality indicators will

lead to good external ones, s uch as reliability a nd maintainability. However, more research is

10 Chapter 1 Why Software Engineering?

needed to verify these assumptions and to determine which aspects of quality affect the prod-

uct's actual use. We may have to develop models that link the product view to the user view. Customers or marketers often take a user view of quality. Researchers sometimes hold a

product view, and the development te am has a manufacturing view. if th e differences in vie w-

points are not made explicit, then confusion and misunderstanding can lead to bad d ecisions and poor products. The value-based view can link these disparate pictures of quality. By

equating quality to what the custome r is willing to pay, we can look at trade-offs between cost

and quality, and we can manage conflicts when they arise. Similarly, purchasers compare product costs with potential benefits, thinking of quality as value for money.

Kitchen.ham and Pfteeger (1996) investi gate d the answe r to this question in their introducti on to a special issue of IE EE Software o n quaJity. They n ote that the conte xt helps to de te rmine the answe r. FauJts tolerated in word processing software may not be acceptable in safety-critical or mission-critical systems. Thus, we must consider qua lity in a t least three ways: the quality of the product, lhe quality of the process that resuJ t.s in the pro duct, and the qua lity o f the product in the context of the business en vironmen t in which the product wiU be used.

The Quality of the Product

We can ask people to name the characteristics of software that contribute to its overalJ quality, but we are likely to get different answe rs from e ach p erson we ask. Thjs differ- e nce occurs because the impo rtance o f the characteristi cs depends on who is ana lyzing the software. Users judge software to be of high quality if it does wha t they want in a way that is easy to le arn and e asy to use. However , some times quality and functio nali ty are inte rtwined; if some thing is hard to learn or use but its functionality is worth the trouble, then it is stiU conside red to have high quality.

We try to measure so ftware quality so that we can compare one product with ano ther. To do so, we ide ntify those aspects of the system that contribute to its overall quality. Thus, when measuring software quality, users assess such exte rnal characte ristics as the number o f failures and type of failures. For example, they may de fine faiJures as minor, majo r, a nd catastrophic, and hope that any failures that occur are onJ y minor ones.

The software must also be judged by those who are designing and writing the code and by those who must maintain the programs after they are written. These practi- tione rs tend to look at internal characte ristics o f the products, som etimes even before the pro duct is deli ve red to the user. In particul ar , practitioners often look at numbers and typ es o f fa ults fo r evide nce o f a product's quality (or lack of it) . For exam ple, d evel- o pe rs track the numbe r o f faults found in requirements, design, and code inspectio ns and use the m as indicators of the like ly quaJity of the final product.

Fo r this reason, we often build models to r elate the use r's exte rnal view to the d eve lope r's inte rnal vie w of the software . Figure 1.5 is an example of an early qua lity model built by McCaU and bis colleagues to show how external quality factors (on the le ft-hand side) re la te to product quality criteria (on the right-hand side). McCaU associ- ated each right-band criterion with a measureme nt to indicate the degree to which an

Section 1.3 What Is Good Software? 11

Correctneu

Rel iabilily

lnte rit

Usability

Mainhinabilily

Testabilitf

I nteropmbil itr

FIGURE 1.5 McCall's quality model.

e le ment o f quality was a ddressed (McCall, Richards, and Walte rs 1977). We will exam- ine several product quality models in Chapter 12.

The Quality of the Process

The re are maoy activities that affect the ultima te product quality; if aoy of the activities go awry, tbe product quality may suffer. Fo r this reason, many software engineers feel that the quality of the development and mainte nance process is as important as prod- uct quality. One of the advantages o f modeling the process is that we can examine it and look for ways to improve it. For example, we can ask questions suc h as:

• Where and when are we likely to find a particular kiod of fault? • How cao we fiod faults earlier in the develop ment process?

• How can we build io fault to le rance so that we minimize the like Lihood that a fault wiU become a failure?

• H ow cao we design secure, high-quality systems? • Are the re alternative activities that can make our process mo re effective or effi-

cient at e nsuriog quality?

These questioos can be applied to the whole deve lopment process or to a subprocess, such as configuration management, reuse, or testing; we will investigate these processes in late r chapters.

In the 1990s, there was a well-publicized focus o n process modeling and process improveme nt in software e ngineering. Inspired by the work of Deming and Juran , and implemented by companies such as IBM, process guidelines such as tbe Capability

12 Chapter 1 Why Software Engineering?

Maturity Mode l (CMM), ISO 9000, and Software Process Improvement and Capability dEte rminatio n (SPICE ) suggested that by improving the software d evelopment process, we can improve the quality of the resulting products. In Chapter 2, we will see how to iden- tify relevant process activities and m odel their effects on intermediate and final products. C hapte rs 12 and 13 will examine process models an.d improvement frameworks in depth.

Quality in the Context of the Business Environment

When the focus of quality assessme nt is on products and processes, we us ually measure quality with mathematical expressions involving faults, failures, and timing. Rarely is the scope broadened to include a business perspective, where qualjty is viewed in terms of the products and services being provided by the business in which the software is e mbedded. That is, we Look at the technical value of our products, rather than more broadly at their business value, and we make decisions based only on the resulting products' technical quality. In other words, we assume that improving technical quality will automaticaJly translate into business value.

SeveraJ resea rchers have taken a close look at the relationships between business value and technical value . For example, Simmon s inte rviewed many Australian busi- nesses to de termine ho w they make their information technology-related business d ecisions. She proposes a framework for understanding what companies mean by " business vaJue" (Simmons 1996). In a repo rt by Favaro and Pfteeger (1997), Steve Andrioie, chief information officer fo r C igna Corporati on, a large U.S. insurance com- pany, described how his company distinguishes technical value from business value:

We measure the quality [of our software] by the obvious metrics: up versus down time, maintenance costs, costs connected with modifications, and the like. In other words, we manage development based on operational performance within cost parameters. H OW the vendor provides cost-effective performance is less of a concern than the results of the effort. ... The issue of business versus technical value is near and dear to our heart ... and one [on] which we focus a great deal of attention. I guess I am surprised to learn that com- panies would contract with companies for their technical value, at the relative expense of business value. If anything, we err on the other side! If there is not clear (expected) busi- ness value (expressed quantitatively: number of claims processed, etc.) then we can't launch a systems project. We take very seriously the "purposeful" requirement phase of the project, when we ask: "why do we want this system?" and "why do we care?"

There have bee n several atte mpts to re late technical value and business value in a quantitative and mea nin gful way. Fo r example, Humphrey, Snyder, and Willis (1991) note that by improving its developme nt process according to the CMM " maturity" sca le ( to be discussed in Chapter 12), Hughes Aircraft improved its productivity by 4 to 1 and saved millions of dollars. Similarly, Dion (1993) reported tha t Raytheon's twofold increase in productivity was accompanied by a $7.70 re turn on every dollar invested in process improve ment. And pe rsonne l at Tmker Air Force Base in Okla homa noted a productivity improve me nt of 6.35 to 1 (Lipke and Butler 1992).

H owever, Brodman and Johnson (1995) took a closer look at the business value of process improve me nt. They surveyed 33 companies that perfo rmed some kind of process improve me nt activities, and examined several key issues. Among othe r things, Brodman

Section 1.3 What Is Good Softwa re? 13

and Johnson asked companies how they defined return on investment (ROI), a concept that is clearly de fined in the business community. They note tha t the textboo k definition of return on investment, derived from the financial community, describes the investment in terms of what is given up for other purposes. That is, tbe " investment must not only return the o riginal capital but en ough more to at least equal what the funds wo uld have earned elsewher e, plus an allowance for risk" (Putnam and Myers 1992). Usually, the business community uses one of three models to assess RO I: a payback mode l, an accounting rate-of-return model, and a discounted cash flow model.

However, Brodman and Johnson (1995) found that the U.S. government and U.S. industry interpret ROI in very different ways, each diffe re nt from the othe r, and both dif- ferent from the standard business school approaches. The government views ROI in terms of dollars, looking at reducing operating costs, predicting do llJar savings, and calculating the cost of employing ne w technologies. Government investments are also expressed in dol- lars, such as the cost of introducing new technologies or process improvement initiatives.

On the other band, industry viewed investment in terms o f effor t, rather than cost or dollars. That is, companies were interested in saving time or using fewer people, and their de finition of re turn o n investment re flected this focus on decreasing effort. Amo ng the companies surveyed , return on investmen t included such ite ms as

• training • schedule

• risk • quality • productivity • process • customer • costs • business

"The cost issues included in the d efinition involve meeting cost predictions, improving cost performance, and stayi ng within budget, rathe r than reducing operating costs or streamlining the proj ect or organization. Figure 1.6 summarizes the frequency with which many organizations include d an investment ite m in their definitio n o f RO I. Fo r e xample, about 5 percent of those inte rviewed included a quality group's e ffort in the ROI effort calculation, and approximately 35 perce nt included soflware costs when conside ring numbe r o f dollars invested.

The diffe rence in views is disturbing, because it means that calculations of RO I cannot be compared across o rga nizations. But there are good reasons for these diffe r- ing views. Do llar savings from re duced schedule, highe r quality, and increased produc- tivity are re turned to the government rather than the contractor. On the other hand, contractors are usuaUy looking for a competitive edge and increased work capacity as weU as greater profit; thus, the contractor's ROI is more effort- than cost-based. In par- ticular, more accurate cost and schedule estimation can me an customer satilsfaction and re peat business. And decreased time to market as well as improved produc t quality are pe rceive d as offering business value, too.

14 Chapter 1

:! ...

Why Software Engineering?

Facilities E===~----------------1

Soltwue costs:

Har~ware costs J:=====:::I Materia ls

General _,_ _________ _

Assessments i----.. SCE costs

Internal R&D Process .,. _______ _.

Doeumantation1 Quality group'

Software process groupJ:=====::J

Genera I ~;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;~J

0% 10% 20 % 30 % 40 % SO% 6 0 % 70%

Percent of lnterwlewees

FIGURE 1.6 Terms included in indust ry definition o f return on investment.

Even tho ugh the diffe rent ROI calculatio ns can be justi fied for each o rganizatio n, it is wo rrying that softwa re techno logy return o n investment is no t the same as financial RO I. At some point, program success must be r eported to highe r levels o f manage- me nt, many o f which are re lated no t to softwa re but to the main compa ny business, such as telecommunications or banking. Much confusion will result from the use of the same te rminology to me an vastly different things.. Thus, our success crite ria must make sense no t only for software projects and processes, but also fo r the mo re general busi- ness practices they support. We will e xamine this issue in mo re de tail in Chapte r 12 and look at using se ve ral common measures o f business value to choose among techno logy options,.

1.4 WHO DOES SOFTWARE ENGINEERING?

A key compo nent o f software d eve lopment is communica tion be tween custo me r a nd d eve loper; if that fa ils, so too wiU the system. We must understand wha t the custome r wants and needs before we can build a system to help solve the cus to mer 's proble m. To do this, let us turn o ur a ttentio n to the people invo lved in soft ware develo pment.

The number of people wo rking on software develo pme nt de pends on the project's size and degree o f difficulty. However, no ma tte r how many people a re involved , the roles played thro ughout the Life of the project can be distjnguished. Thus, for a large project, one pe rson or a group may be assigned to each o f the roles ide nti- fied; on a smaU project, o ne person o r group may take o n several ro les at o nce.

Usua lly, the participa nts in a project fall into o ne o f three categories: custo mer, use r, o r de ve lo pe r. The custome r is the company, o rganizatio n, or pe rson who is paying for the so fl wa re syste m to be de veloped. The develo per is the company, o rganizalio o , o r pe rso n who is building tlhe soft wa re syste m for the custo me r. This ca tegory includes a ny

USER

Section 1.4 Who Does Software Engineering? 15

CUSTOMER Sponsors system development

Needs

Software system

FIGURE 1.7 Participants in software development.

manage rs neede d to coordinate and guide the programme rs and testers. The user is the pe rson o r people who wiU actua Uy use the system: the ones who sit at the te rminal o r submit the data or read the output. Although for some projects the custo me r, user, and developer are the same person or group, often these are different sets of people. Figure 1. 7 shows the basic relationships among the three types of participants.

The customer, being in control of the funds, usuall y negotiates the contract and signs the acceptance papers. H oweve r, sometimes the custo me r is no t a user. For example, suppose Wittenberg Water Works signs a contract with Gentle Systems, Inc., to build a compute rized accounting system for the company. The president of Witten- be rg may describe to the re prese ntatives of Gentle Systems exactly what is needed , and she will sign the contract. Howe ver, the president wiU not use the accounting system directly; the users will be the bookkeepers and accounting c lerks. Thus, it is important that the developers understand exact! y what both the custome r and users want and need.

On the otber band, suppose Wittenbe rg Wate r Wo rks is so large that it bas its own computer syste ms development division. The di vision ma y decide that it ne:eds an auto- mated tool to keep track of its own project costs and schedules. By build ing the tool itse lf, the divisio n is at the same time the user, custo me r, and developer.

In recent yea rs, the simple distinctions among customer, user, and deve lope r have become mo re complex. Customers and users have bee n invo lved in the d evelo pment process in a variety of ways. The custo me r may decide to purchase Comme rcial Off-The- Sbelf (COTS) software to be incorporated in the final product that the deve loper will supply and support. When this happens, the custome r is involved in system archi tecture decisions, and there are many more constraints on development. Similarly, tbe developer may choose to use additional developers, caUed subcontractors, who build a subsystem a nd de live r it to the develo pers to be included in the final product. The subcontracto rs may work side by side with the primary developers, o r they may wo rk al a di[fere nt site,

16 Chapter 1 Why Software Engineering?

coordinating their work with the primary developers and delivering the subsystem late in the develo pment process. The subsystem may be a t urnkey system , where the cod e is incorporated whole (withou t additional code for integration), or it may require a sepa- rate integration process for building the links from tbe major syste m to the subsyste m (s).

Thus, the notio n of ·•system" is important in software engi neering, not onJy for understanding the problem analysis and solutio n synthesis, but also for organizing the development process and for assigning appropria tte roles to the participants. In the next section, we look at the ro le of a systems approach :in good software e ngineering practice.

1.5 A SYSTEMS APPROACH

The proj ects we develop do not exist in a vacuum .. Ofte n, the hardware and softwa re we put togethe r must interact with users, with o ther software tasks, with other pieces of hardware, with exi sting databases (i.e., with care fully defined se ts o f data and data re la- tions hips), o r even with o the r computer systems. Therefore, it is important to provide a context for any proj ect by knowing the boundaries of the proj ect: what is included in the project and what is not. For exam ple, suppose you a re asked by your supervisor to write a program to print p aychecks for the people in your office. You must know whethe r your program simply reads ho urs worked fro m another system and prints the results or whe the r you must also calculate the pay informati on. SimiJarly, you must know whe ther the program is to ca lcuJate taxes, pensions, and be nefits or whether a re port of these ite ms is to be provided with each paycheck. What you are really asking is: Where does the project begin and end? The same question app lies to any system. A syste m is a collection of objects and activities, plus a description of the relatio nships that tie the objects and activities together. Typically, ou r system de finitio n includes, for each activity, a list o f inputs required , actions take n, and outputs produced. Thus, to b egin, we must know whether any o bject o r activity is included in the system or not.

The Ele ments of a System

We describe a system by naming its parts and then identifying ho w the component parts are related to one anothe r. This ide ntification is the first ste p in analyzing the problem presented to us.

Activities and O bj ects. First, we distinguis h between activities and objects. An activity is something tha t happens in a system. U sually described as an event initiated by a trigge r, the activity transforms o ne thing to ano the r by chang i-ng a characte ristic. This tra nsformati on can mean that a data e le ment is moved from one locatio n to another , is changed from one value to another, or is combined with o ther data to suppl y input for yet another activity. Fo r example, an ite m of data can be moved from one file to another. In this case, tbe characte ristic changed is the location. Or the value of the data ite m can be increme nted. Finally, the address of the data item can be included in a list o f parame ters with the addresses o f several o ther data ite ms so that another routine can be caUed to handle a ll the data at o nce.

The e le ments involved in the activiti es a re caUed objects or entities. Usually, these objects are re lated to each o the r in so me way. For insta nce, the objects can be

Section 1.5 A Systems Approach 17

a rranged in a table o r matrix. O fte n, objects a re grouped as records, wbe re each record is a rranged in a prescribed forma t. An employee history record, for example, may con- tain o bj ects (called fields) for each emp loyee, such as the following:

First name Middle na me Last na me Street address City State

Postal code SaJ ary per hour Benefits per hour Vacation ho urs accrued Sick leave accmed

Not o nly is e ach fie ld in the record defined , but the size and rela tio nsltip o f each fie ld to the o the rs a re n amed. Thus, the record description states the data type of each fie ld, the starting locatio n in the record, and the length of the field. In turn, since there is a record fo r each employee, the records a re combined into a file, and file characte ris tics (such as maximum numbe r o f records) may be specifie d.

Some times, the o bjects are defined sligh tly di ffe re ntly. Instead of considering each ite m as a fie ld in a larger r ecord, the object is viewed as being independent. The o bject description contains a Listing of the characte ristics of each object, as we ll as a list of au the actio ns that can take place using th e object or affecting the object. For e xa mple, conside r the o bj ect "p o lygon." An o bject descriptio n may say that this obj ect bas characteristics such as number of sides and length o f each side. The actions may include calcula tio n of the area o r of the perimeter. The re may even be a ch aracteristic ca lled "po lygon. type,'' so that each instantiation of ·'polygon" is ide ntified! when it is a " rhombus" or " rectangle," for instance. A type may itself have an object description; " rectangle" may be composed of types "square" and " not square," fo r exampl e. We will e xplo re these concepts in Chapte r 4 when we investigate require ments ana lysis, and in de pth in C hapte r 6 when we discuss obj ect-orie nted d evelopme nt.

Relationships and the System Boundary. Once entities and activities are de fined , we match the e ntities with their activiti es. The re lationships amo ng entities and activi - ties are clearly and ca refully defined. An entity definition includes a description of where the e ntity origina tes. Some ite ms reside in files that already exist; o the rs a re cre- a ted during som e activity. The e ntity's destin ation is impo rtant, too. Some items are used by o nly o ne activity, b ut ot!hers are destined to be in put to othe r syste ms. Tha t is, some ite ms fro m one system are used by activities outside the scope o f the syste m being exa mine d. Thus, we can think o f the system a t which we are looking as having a bo rde r o r bounda ry. Some ite ms cross the boundary to enter our syste m, and o the rs are p rod- ucts of our syste m and trave l out fo r an other system's use.

Using these concepts, we can define a system as a collection of things: a se t of e ntities, a se t o f activities, a description of il:he relationships among entities and activities, and a def- inition o f the bo undary of the system. This definition of a system applies no t only to com- puter syste ms but to anything in which objects interact in some way with o the r o bjects.

Examples of Systems. To see how system definition works, consider the pa rts of you that a llow you to take in oxygen and excrete carbo n d ioxid e a nd water: yoru respi- ratory syste m. You can define its boundary easily: If you name a p articular organ of

18 Chapter 1 Why Software Engineering?

FIGURE 1.8 Respiratory system.

ENTITIES: Particulate matter Oxygen Carbon dioxide Water Nitrogen Nose Mouth Trachea Bronchial tubes Lungs Alveoli

ACTIVITIES: Inhale , ans Filter gases T ransler molecules

to/from bl ocd Exhale , ans

your bo dy, you can say whether or not it is p art of your respirato ry system. Molecules of oxyge n and ca rbon dioxide are entities or objects mo ving thro ugh the system in ways that are clearly defined. We can also describe the a ctivities in the system in te rms o f the inte racti ons o f the entities. If necessary, we can imustrate the syste m by showing wha t enters and leaves it; we can also supply tables to describe all entities and the activities in which they are involved . Fi gure 1.8 illustrates the respiratory system. Note that each activity involves the entiti es and can be defined by describing whjch e ntities ac t as input, how they are processed , and what is produced (output).

We must describe our compute r systems clearly, too. We wo rk with p rospec tive users to de fine the bo undary o f the system: Whe re does our work sta rt and sto p? In addition, we need to know what is on the boundary o f the system and thus determine the o rig ins of the input and destinations of the o utput. For example, in a system that prints paychecks, pay informati on may come from the compan y's payroll syste m. The syste m o utput may be a set of paychecks sent to the m ail room to be de livered to the appropriate recipie nts. In the system shown in Figure 1.9, we can see the boundary a nd can unde rstand the e ntities, the activities, and their relati onships.

Interre la t e d Systems

The conce pt o f bo undary is important, because very few syste ms are inde pendent of o the r syste ms. For example, the respiratory system must inte ract with the digestive sys- te m, the circulatory syste m, the ne rvo us system, and others. The respirato ry system could no t function witbout the nervous system; neithe r could the circulatory system function without the respirato ry system. The interdependen cies may be complex. (Indeed, many o f o ur environmental problems arise and are intensifie d because we do not appreciate the comple xity of our ecosyste m.) However, once the boundary o f a syste m is described, it is easier for us to see what is within and without and what crosses t he bo undary.

In turn, it is possibl e fo r one syste m to exist inside ano the r syste m. Whe n we d escribe a compute r system, we often concentrate on a small piece o f wh at is really a

l[I I ~ Computer i~ ~

D1te ulidation

~ System bound1ry

Section 1.5

M•H•u•ijJ

~ Printin9

A Systems Approach 19

FIGURE 1.9 System definition of paycheck production.

much larger system. Such a focus allows us to define and b uild a much less complex sys- tem than the e nveloping one. If we a re careful in docume nting the interactions among a nd be tween syste ms affecting o urs, we lose nothing by concentrating o n this s ma ller piece of a larger system.

Let us look at an example of bow this ca n be done. Suppose we are developing a wate r-mo nito ring system where data are gathe red at many points through.out a river val- ley. At the collection sites, several calculations are done, and the results are co mmunicated to a central location for compreh ensive reporting. Such a system may be implemented with a computer at the central site communicating with several dozen smalle r computers at the remo te locations. Many system activities must be considered, including the way the water data a re ga thered, the calculations perfo rmed at the remo te locations,. the commu- nication o f information to the ce ntral site, the storage of the communicated data in a data- base or s hared data file, and the creation of rep orts from the data. We can view this system as a coUection of systems, e ach wi th a special purpose. In particula r, we can conside r only the communications aspect of the larger syste m and develop a communications system to transmit data fro m a set of remo te sites to a central one. If we ca re fully define the bound- ary between the communications and the larger system, the design and development of the communications system can be done inde pendently of the larger system.

The complexity of the entire water-monitoring system is much greate r than the com- plexity of the communications system, so our trea tment of separate, smalle r pieces makes o ur jo b much simple r. If the boundary definitions are detailed a nd correct, building the large r syste m from the smaller ones is relatively easy. We can describe the bui lding pro- cess by considering the larger system in layers, as illustrated in Figure 1.10 fo r our water- monito ring example. A layer is a system by itself, but each layer and those it contains also form a sys tem. The circles of the figure represent the boundaries o f the respective systems, a nd the entire set of circles incorporates the entire water-mo nito ring syste m.

20 Chapter 1 Why Software Engineering?

FIG URE 1.1 O Layers of a water-monitoring system.

Recognizing that one system contains another is important, because it reflects the fact that an object o r activity in on e system is part of every system re presented by the o ute r layers. Since mo re complexity is introduced witb each layer, understanding any o ne object o r activity becomes more difficult with each more encompassing syste m. Thus, we maximize simplicity and our consequ ent understanding of the system by focusing o n tbe smallest syste m possible at first.

We use thi s idea when building a system to replace an older version, either man- u al o r a uto mated. We want to understand as mucb as possible about bow bo tb the o ld and ne w systems work. Ofte n, the greater the diffe re nce be tween the two systems, the mo re difficult the design and development. This difficulty occurs not only because people tend to resist chan ge, but also because the difference makes learning difficul t. In building or synthesizing our grand system, it helps dramatically to construct a new sys- te m as an incre men tat series o f intermediate syste ms. Rathe r than going from system A to syste m B, we may be able to go fro m A to A' to A" to B. For example, suppose A is a manual syste m consisting of three major functions, and Bis to be an automated vers ion of A We can define system A ' to be a new system with function 1 automated but func- tions 2 and 3 still manual. Then A" has automated functions 1 and 2 , but 3 is still manual. Finally, B has aU three automa ted functions. B y dividing the "distance" from A to B in thirds, we have a se ries o f small problems that may be e asier to ha ndle than the who le.

In our example, the two systems are very similar; the functions. are the same, but the style in which they are imple me nted diffe rs. However, the target system is often vastly differe nt from the existing one. lo particular, it is u suaUy desirable that the target be free of constraints imposed by existing h ardware o r software. An incremental del'clopment

Sectio n 1.6 An Engi neering Approach 21

a pproach may incorpo rate a series of stages, each o f which frees the p revious system from a no the r such constraint. For example, stage 1 may add a new piece of hardwa re, stage 2 may rep lace the softwa re pe rforming a pa rticular set of functions, and so on. The system is slowly d rawn away from old software and hardware until it reflects the new system design.

Thus, system de venopment ca n fi rst in corporate a set of changes to an actual sys- te m a nd the n add a series o f changes to gene ra te a comple te design sche me, rather than trying to j ump from presen t to future in o ne mo ve. With such an approach, we must view th e syste m in two d iffe rent ways simultaneously: statically and dynamically. The static view tells us how tlhe syste m is wo rking to da y, whe reas the dynamic view shows us bo w the system is cha nging into what it wiU eventuall y become. O ne view is not com- plete without the o the r.

1.6 AN ENGINEERING APPROACH

Once we unde rstand the system 's nature, we are r eady to begin its construction. At this poin t, the "engineering" pa rt o f so ftwa re engineering becomes re levant and comple- ments what we have do n e so fa r. Recall that we began this cha pte r by acknowle dg ing that wrtitin g softwa re is an art as we ll as a science. Tue art o f producing syste ms involves the craft o f software productio n. As artists, we develop techniq ues and tools that have prove n helpful in p ro duc ing useful, high-quality products. For instance, we may use an optimizing compile r as a tool to gene rate programs that run fast o n the machines we are using. O r we can includ e specia l sort o r search routines as techniques for saving time or space in our system. These software-based techniques are used just as tech- niques a nd tools are used in crafting a fine piece of furniture o r in building a ho use. Indeed, a po pu lar co llectio n o f programmi ng tools is ca lled the P rogramme r's Wo rk- be nch, because programmers rely o n the m as a ca.rpenter relies on a wo rkbench.

Because building a syste m is similar to building a ho use, we can look to h o use building for o the r examp les o f why the "artistic" approach to software develo pment is impo rta nt.

Building a House

Suppose Chuck and Betsy H owell hire someone to build a ho use fo r the m. Because of its size a nd co mplexity, a house usually requires mo re than o ne pe rson on the construc- tio n team; consequently, the Howells hire McMullen Construction Company. The first e ve nt invo lved in the house building is a confe re nce between the Howells and McMulJen so the Howe lls can e xplain what they want. lhis confere nce explores not o nly what the Ho wells wa nt the house to look like, but also what featu res are to be incl uded. Then McMull en d raws up floor plans and an architect's rende ring o f the ho use. After the H owells discuss the d etails with McMullen, changes are made. O nce the Howe lls give their ap p roval to McMuUen, con struction begins.

During the construction process, the Howells a re lik ely to in sp ect the constructio n site, thin king of changes they would like. Severa l such changes may occur during con- structio n, but eventually the house is completed. During construc tion a nd before the H oweUs mo ve in, several components o f the ho use are tested. For e xample, electriciians

22 Chapter 1 Why Software Engineering?

test the wiring circuits, plumbers make sure that p~pes do not leak, and carpenters adjust for variation in wood so that the floors are smooth and leve l. Finally, the H owells move in. If the re is something tha t is not constructed properly, McMulle n may be called in to fix it, but eventually the Howells become full y responsible for the house.

Le t us look more closely at what is in volved in thi s process. First, since many people are working on the h ouse at the same time, docume ntation is essential. No t o nly are floor plans and the architect's drawings necessary, but de tails must be written down so that specialists such as plumbers and e lectricians can fit the ir products togethe r as the ho use becomes a whole.

Second, it is unreasonable to expect the H owells to describe their house at the beginning o f the process and walk away until the ho use is complete d. Instead, the How- e lls may modify the house design several times during construction. These modi fica- tions may result fro m a number of situatio ns:

• Mate rials that were specified initially are no lo nger available. For example, certain kinds o f roof tiles may no lo nger be manufactured.

• The H owells may !h ave new ide as as they see the house take shape. For example, the H owells might realize tha t they can add a skylight to the kitche n for Liittle additio nal cost.

• Availa bility or financial constraints may require the Howells to change require- ments in order to meet their schedule o r budget. For example, the special windows that the Howells wanted to o rde r will no t be read y in time to complete the ho use by winte r, so stock windows ma y be subsliluled.

• Ite ms or designs initially thought possible might tum out to be infeasible . For example, soil percolatio n tests may reveal tha t the land surro unding the house can- not support the number of bathrooms that the Ho wells bad o riginally requested.

McMullen may also reoommend some chan ges after constructio n has begun, pe rhaps because of a bette r ide a or because a key mem be r of the construction cre w is unavail- able. And both McMulle n and the Howells may change their minds about a featur e of the ho use even after the feature is comple ted.

Third, McMullen must provide blueprints, wiring and plumbing diagrams, instrnc- tion manuals for the appliances, and any other d ocumentati on that would enabl e the H owelJ s to make modifications or re pairs afte r they move in.

We can summarize this construction p rocess in the following way:

• de termiJting and analyzing the requirements • producing and docume nting the overall design of the house • producing detailed specifica tions o f the ho use • identifying and designing the components • building e ach component of the ho use • testing each compo nent of the ho use • integrating the compo nents and making final modifications after the reside nts

ha ve moved in

• continuing mainten ance by the residents of the ho use

Section 1.6 An Engineering Approach 23

We have seen how the participants must re main flexible and allow changes in the origi- nal speci fications at various points during construction .

It is important to remember tha t the house is built within the context of the social, econo mic, and governmental structure in which it is to reside. Just as the wate r- monitoring system in Figure 1.10 de picted the d ependencies o f s ubsystems, we must th.ink of the ho use as a subsystem in a larger sch eme. For example, construction of a ho use is done in the context of the city or county building codes and regulations. The McMullen e mp loyees are lice nsed by the city o r county, and they are expected to pe r- form according to building sta ndards. The construction site is visited by building inspec- tors, who make sure thatt the standards are being followed. A nd the building inspectors set standards for qu ality, wi th the inspections se rving as quality assurance checkpoints for the b uilding project. The re may also be social o r customary constraints that suggest commo n or acceptable behavio r; for example, it is no t customary to have the front d oor open directly to the kitchen or bedroom.

At the same time, we must recognize that we canno t prescribe the activities of build- ing a house exactly; we must leave room for decisions based o n experience, to deal with unexpected or no nstandard situations. Fo r example, many houses are fashioned from p re- e xisting components; doors are supplied already in the frame, bathrooms use pre-m ade sho wer stalls, and so on. But the s tandard house-building process may have to be alte red to accommodate an unus ual feature o r request. Suppose that the framing is done, the dry- wall is up, the subfloor is laid, and the next step is pllltting down tile on the bathroom floor. The builders find, much to their dismay, that the walls and floor are not exactly square. This proble m may not be the result of a poo r process; houses are built from parts that l1ave some natmal or manufacturing variation, so proble ms o f inexactitud e can occur.The ftoor tile, being composed of s mall squares, wi ll highlight the inexactitude if laid the standard way. It is he re that art and expertise come to play. The builder is lik e ly to re move the ll:iles from the ir backing, and lay them o ne at a time, making small adjustments with each o ne so tha t the overall variation is imperceptible to all but the most discerning eyes.

Thus, house building is a comple x task with many opportunities for ch ange in pro- cesses, p ro ducts, o r reso urces a long the way, tempe red by a healthy dose of art and e xpertise. The house- building process can be standardized , but the re is always need for e xpert judgment and cre ativity.

Building a System

Soft ware projects progress in a way similar to the house-building process. The Howells were the customers and users, and McMullen was the developer i n o ur example. H ad the Howells asked McMulle n to build the house fo r Mr. H owell's pa rents to live in , the users, customers, and de velope r would have been distinct. In the same way, software de velopment involves U1sers, customers, and d evelopers. If we are asked to develop a software system fo r a cus to me r, the first step is meeting with the custome r to d etermine the requi re ments. These require ments describe the syste m, as we saw before. Witho ut knowing the boundary, the e ntities, and the activities, it is impossible to describe the software and how it will interact with its environment.

Once require ments a re d efined , we create a system design lo meet the specified requireme nts. As we will see in Chapte r 5, tbe system design shows the custo mer what

24 Chapter 1 Why Software Engineering?

the system will loo k like from the customer 's pe rspective. Thus, just as the Howells looked at floor plans and architect's drawings, we present the customer with pictures of the video display screens that will be used, the re ports that will be generated, and any other d escriptions that will explain how users willl inte ract with the completed system. H the system has manual backup o r ove rride procedures, those a re described as we ll. At fust, the H owells we re inte rested o nly in the appearance and functionality of their ho use; it was not until late r that they had to decide on such items as copper or plastic pipes. Likewise, the system design (also called a rchitectural) phase of a software project describes onJy appearance and functionality.

Tue design is then reviewed by the customer. When approved, the overall system design is used to ge nera lte the designs o f the indi vidual programs involved. Note that it is not until this step that programs are mentioned. Until functionality and appearance are dete rmined, it often makes no sense to consider coding. In o ur house example, we would n ow be ready to discuss types of pipe or quality of electrical wiring. We can decide on plastic or coppe r pipes because now we know where water needs to flow in the structure. Likewise, when the system design is approved by all, we are ready to di s- cuss programs. The basis fo r our discussion is a well-defined description o f the software project as a system; the system design includes a complete description of the functions and inte ractions involve d.

Whe n the programs have been wri tten, they are tested as individual pieces of code before they can be linked togethe r. This first phase of testing is calJed module or unit testing. Once we are convinced that the pieces work as desired , we put them togethe r and make sure that they work prope rly whe n jo ined with others. This sec·ond testing phase is often re ferred to as integratio n testing, as we build our syste m by adding one piece to the next until the entire syste m is o pe rational. The final tes ting phase, called system teslting, involves a test o f the whole system to make sure that the functions and interactions specified initially have been impleme nted prope rly. In this phase, the system is compare d with the specified requirements; the developer, cus- to me r, and users check that the system serves its inte nded purpose.

At last, the final product is delivered. As it is used , discre panc ies and problems are uncovered. If ours is a turnkey system, the customer assumes responsibility for the sys- tem afte r delivery. Many systems a re not turnkey syste ms, though, and the develope r or other o rganizati on provides mainte nance if anything goes wrong or if needs and requirem e nts change.

Thus, development o f software includes the fo llo wing activities:

• re quire ments analysis and de finitio n • syste m design • program design • writing the programs (program impleme ntation) • unit testing

• integration testing • syste m testing • system de livery • mainte nance

Section 1.7 Members of the Development Team 25

In an ideal situatio n, the activities are performed o ne at a time; when you re ach the end o f the List, you have a comple ted software project. However, i_n reali ty, man y o f the s tep s are re peated. Fo r exa mple, in reviewing the system design, you and the cus- tome r may discove r that some requiremen ts have yet to be docume nted. You may work with the custo mer to adcl require ments a nd possibly redesign the system. Simila rly, when writing and testing code, you may find tha t a device does no t function as described by its documentatio n. Yo u may have to red esign the code, reconsider the sys- te m design , o r eve n re tu rn to a discussio n with the custo mer about how to meet the requireme nts. Fo r this reason, we define a software development process as any desc riptio n o f softwa re developme nt that contains some of the nine activities Lis ted before, organized so that together they produce tested code. Io Ch apter 2, we will explore several of the diffe rent d evelo pment processes tha t a re used in building software. Subse- quent chapters will examine each o f the s ubprocesses and their activities, from require- ments a nalysis through mainte nance. But be fore we do, let us look at who develops software and ho w the cha llenge o f software develo pment has changed over the years.

1.7 MEMBERS OF THE DEVELOPMENTTEAM

Earlie r in this chapte r, we saw that custo mers, users, and de velo pers play major roles in the definitio n and crea ti on o f the new p roduct. The develo pe rs are software engineers, but each engineer may s pecialize in a pa rticular aspect of development. Let us look in mo re de ta il a t the role o f the membe rs o f the d evelopme nt team.

The fir st step in any development process is finding out what the custom er wants and documenting the require me nts. As we have seen, analysis is the process o f bre aking things into their component pa rts so tha t we can unde rstand them better. Thus, the de ve lo pment team includes o ne o r mo re requirem ents analysts to work with the c us- tome r, breaking down what the custo mer wants into discrete requiremen ts.

Once the req uirements are kno wn and docume nted , analysts wo rk with designers to ge nerate a system-le vel descriptio n o f what the system is to do. In turn , the designers wo rk with programmers to describe the syste m in such a way tha t programmers can write Lines o f code tha t im ple ment what the requireme nts specify.

Afte r the code is generated , it must be tested. O ften, the first testing is do ne by the programme rs themselves; some times, additio na l testers are also used to he lp ca tch fa ults that the programmers o verlook. When units o f code a re integrated into function- ing groups, a team o f teste rs wo rks wit h the imple mentation team to verify that as the syste m is b uilt up by combining pieces, it works properl y and according to speciiicatio n.

When the deve lo pment team is comfo rtable with the functio nality and quality of the system, attentio n turns to the custom er. The test tea m a nd customer wo rk together to ve rify that the comple te system is what the custo me r wants; they do this by compar- ing bow the system wo rks wit h the in itial set o f require me nts. Then , trainers s how users how to u se the system.

Fo r ma ny so ftwa re syste ms, accepta nce by the custo mer does no t mean the e nd of the develo pe r's jo b. If faults are discovered a ft.er the system has been accepted, a maintenance team fixes them. Mo reove r, the custome r's req uirements may change as time passes, and correspo nding cha nges to the system must be mad e. Thus, maintenance

26 Chapter 1 Why Software Engineering?

can invo lve analysts who de te rmine what require ments are added or changed , design- e rs to d ete rmine where in the system design the change should be made, programme rs to imple me nt the changes, testers to make sure that the changed system still runs prop- e rly, and trainers to explain to users h ow the ch ange affects the use of the system. Figure 1.11 illustrates ho w the roles o f the develo pment tea m correspond to the steps o f deve lopment.

Stude nts ofte n work by themselves o r in smaU groups as a de ve lo pment team for class projects. The documentation requeste d by the instructor is minimal; students. are usually no t required to write a user manual o r training documents. Moreove r, the assignment is re lative ly stable; the requireme nts do not change over the life of the project. FinaUy, stude nt-built systems are likely to be discarded at the end of the course; their purpose is to de mo nstra te abili ty but no t necessarily to solve a pro blem for a real custo me r. Thus, program size, system complexity, n eed for documentatio n, and need for maintainability are relatively small for class projects.

Howeve r, for a real customer, the syste m size and compl exity may be large and the need for docume ntati on and maintainability great. For a project involving many tho usands o f lines of co de and much interactio n among members of the developme nt team , contro l o f the various aspects o f the project may be difficult. To support everyone o n the d eve lopmen t team, seve ral people may become involved with the system at the beginning o f develo pme nt and remain involved throughout.

Librarians prepare and store documents that are used during the life of the sys- tem, including require ments specifications, design descriptions, progra m documen ta - tion, training manuals, test data , schedules, and more. Working with the librarians are

REQUIREMENTS ANALYSIS AND DEFINITION I

SYSTEM DESIGN J I

PROGRAM DESIGN

I PROGRAM

_A ANALYST

. ~· DESIGNER

.A PROGRAMMER IMPLEMENTATION

UNIT I TESTING

I INTEGRATION TESTING l

_A TESTER

SYSTEM TESTING J

SYSTEM -DELIVERY J I - I I MAINTENANCE

~ TR.AIMER

FIGURE 1.11 The roles of the development terun.

Section 1.8 How Has Software Engineering Changed? 27

the membe rs of a configuration m anagem ent tearn . Configuration management invo lves maintaining a co rrespo ndence among the requirements, the design , the implementa tion, and the tests. This cross- reference tells d evelopers what program to alter if a change in requirements is needed , or what parts of a program will be affe cted if an alteration of some kind is proposed. Configuratio n manageme nt sta ff a lso coordinate the diffe re nt ve rsions o f a syste m tha.t may be built and suppo rted. For example, a softwa re system may be hosted on di ffere nt platforms or may be d elivered in a ser ies of releases. Con- figuration management ensu res that the fu nctionality is consiste nt from o ne platfo rm to ano ther, and that it doesn 't degrade with a ne w release.

The de velopme nt roles can be assumed b y one person o r several. For smaU projects, two or th ree p eop le may share a ll roles. However, for larger projects, the de ve lo pment team is often separa ted into distioct groups based on their function in de velo pment. Some times, those who maintain the syste m are diffe rent from those who design or write the system initially. Fo r a very large d eve lo pment project, the customer ca n eve n !Lire one company to do the initial deve lopme nt and ano ther to do the main- te nance . As we discuss the d eve lopmen t and mainten ance activities in late r chapte rs, we will look at wha t ski lls are need ed by each type o f d evelo pme nt role.

1.8 HOW HAS SOFTWARE ENGINEERING CHANGED?

We have compa red the building o f so ftware to the buil ding o f a ho use. Each year, lmn- dreds of ho uses a re built across the country, and satisfie d custo mers move in. Each year, hundred s of soflware products are built by develo pe rs, but customers are too o!ten unhappy with the result. Why is the re a diCfe ren ce? If it is so ea sy to e nume rate the steps ill! the deve lo pment o f a syste m, why are we as software e ng ineers having suc h a difficult time producing quality software?

Think back to o ur house-building example. Durin g the building process, the H ow- e lls continually reviewed the plans. They also had many o ppo rtunities to change their minds about what they wanted . In the same way, software deve lo pment aUows the cus- tome r to re view the plans at e ve ry ste p and to make changes in the design. Afte r all , if the deve lo per produces a marvelo us p roduct that does no t meet the customer's needs, the resultant system will have wasted eve ryone's time and effo rt.

For this reason, it is essential that o ur software e ngineerin g tools and techniques be used with an eye toward f:le xibility. In the pas t, we as develo pe rs assumed that our custo me rs knew from the sta rt what they wanted. llrnt stability is not usually the case. As the vario us stages o f a project unfold, constraints arise that we re not anticipate d at the beginning. For insta nce, afte r having chosen hardwa re and software to use for a project, we may find tha t a cha nge in the custo mer require ments makes it difficult to use a pa rlicula r database manage ment system to p roduce menus exactly as pro mised to the custo me r. O r we ma y find tha t ano the r system with which ou rs is to inte rface has changed its procedure or the format of the expected data. We ma y even find that hard- ware or so ftware does not work quite as the vendor's documentation had promised. Thus, we must remember tha t each project is unique and that tools and techniques must be chosen that re f:lect the constraints placed o n the individual p roject.

We must also ackno wledge that most syste ms do no t stand by themselves. They inte rface with o the r systems, either to receive o r to pro vide informatio n. De ve loping

28 Chapter 1 Why Software Engineering?

such systems is complex simply because they re quire a great de al of coordinatio n with the systems with which they communicate. This complexity is especially true of syste ms tha t are being develo pe d concurrently. In the past, developers bad difficulty ensuring the accuracy and comple teness of the documentation of inte rfaces among syste ms. In subseque nt cha pte rs, we will address the issue of controlling the interface pro ble m.

The Nature of the Change

These pro ble ms are amo ng many th at a ffect the su ccess of our software developme nt projects. Whatever approach we take, we must look both backward and fo rward. Tha t is, we must loo k back at previous development projects to see what we ha ve learned , no t only abo ut en surin g software quality, but also a bo ut the effectiveness of o ur techniques and tools. And we must look ah ead to the way software developmen t and the use o f software products are Likely to change our practices in the future. Wasse rman (1995) points out that the changes since the 1970s h ave been dramatic. Fo r example, early a pplications we re intended to run on a single processor, usuaUy a mainfra me. The input was Linear, usually a deck of cards or an input tape, and the o utput was alphanume ric. The syste m was desig ned in one of two basic ways: as a transformation, where input was converted to output, or as a transaction , where input d ete rmined which function would be pe rformed. Today's software -based systems are far diffe re nt and more complex. Typicall y, they run on multiple syste ms, sometimes config ure d in a clie nt-server architecture with distributed functionality. Software performs not only the primary functio ns that the user needs, but also ne two rk contro l, security, use r-iDte rface prese ntation and processi ng, a nd data o r object management. The traditio nal "wate rfall " approach to deve lo pment, which assumes a linear progres- sion o f d e ve lo pme nt activities, where one begins o nly when its pre decessor is comp lete (and which we will study in C hapte r 2), is no lo nger Hexible o r sui table for to da y's systems.

In his Stevens lecture, Wasserman (1996) summarized these changes by identify- ing seve n key facto rs that have altered software engineering p ractice, illustrated in Figure 1.12:

1. criticality o f time-to-marke t for commercial products 2. shifts in the economics o f computing: lowe r hardware costs and greater develop -

me nt and mainte nance costs 3. availability o f powe rful desktop computing 4. exte nsive local- and wide-a rea networking 5. availability and ad optio n of object-oriente d technology 6. graphical user interfaces using windows, icons, me nus, and po inte rs 7. unpredicta bility of the wate rfall model o f software development

Fo r example, the pressures o f the marketplace mean that businesses must read y their new products and services before their compe titors do; otherwise, the viability of the business itself may be at stake. So traditional techniques for review and testing cannot be used if they require la rge investme nts of time that a re not recol.!lped as reduced fa ul t o r failure rates. Similarly, time previously spent in optimizing code to improve speed o r

Section 1.8 How Has Software Engineering Changed? 29

Problemt with 111aterlall

I ~ CHANCES IN ~ SOFTWARE / Time to m~r~at

ENCINEER INC

/ t g

Shifts in economics );;_•l User interfaces

FIGURE 1. 12 The key factors that have changed software development.

reduce space may no longer be a wise investment; an additional disk or memory card may be a far che aper solutio n to the problem.

Moreove r, desktop computing puts developme nt power in the hands of users, who now use their systems to develop spreadshee t and database applications, smaU programs, and even specialized user interfaces and simulations. This shift of develop- ment responsibility means that we, as software e ngi neers, are likely to be building more complex syste ms than before . Similarly, the vast ne tworking capabilities avail able to most users and developers make it easier for users to find information without special applications. For instance, searching the World Wide Web is quick, easy, and effective; the user no lo nger needs to write a database application to find what he o r she needs.

Develo pers now find the ir jobs enhanced, too. Object-o riented technology, coupled with ne tworks and reuse repositori es, makes available to develope rs a large collection of reusable modules for immediate and speedy inclusion in new applications. A nd graphical use r inte rfaces, often developed with a specialized tool, he lp put a frie nd ly face on co mplicated applications. Because we have become sophisticated in the way we analyze problems, we can now partition a system so we develop its subsys- tems in paraUel, requiring a development process very diffe re nt from the waterfaU mode l. We will -see in Chapter 2 that we have many choices for this process, including some that aUow us to build prototy pes (to verify with customers and users that the requirements are correct, and to assess the feasibilit y of designs) and ite rate among activities. These steps h elp us to ensure that our requirements and designs are as fault- free as possible before we instantiate them in code.

30 Chapter 1 Why Software Engineering?

Wasserman's Discipline of Software Enginee ring

Wasserman (1996) points o ut that any one of the seven technological changes would have a significant e ffect on the software developmen t process. But taken together, they ht1ve trnnsformed the w11y we work. Jn his present.atio ns, De Marco descrihes this ra di - cal shjfrt: by saying lhal we solved the easy probl ems first- which means that the set of pro blems left to be solve d is much harder n ow than it was before. Wasserman addresses this challe nge by sugges ting that the re are eight fundamental notions in software en gi- neering that form the basis fo r an e ffective discipline o f software engineerin g. We intro- duce them brie fly here, and we return to them in later chapters to see where and h ow they apply to what we do.

A bstraction. Sometimes, looki ng at a pro blem in its " natural state" (i.e., as expressed by the customer or user) is a daunting task. We cannot see an obvious way to tackle the problem in an e ffective or even feasibl e way. An a bstraction is a description of the problem at some level of generalization that allows us to concentrate on the key aspects of the proble m without getting mired in the details. This notion is different from a transformation, where we translate the proble m to anothe r e nvironment that we unde rstand better; transformation is often used to move a problem from the re al world to tbe mathematical world, so we can manipulate numbers to solve the problem.

Typicall y, abstraction invo lves identifying classes of objects that allow us to gro up items togethe r; this way, we can deal with fewer things and concentrate on the com- monalities of the ite ms in each class. We can talk o f the properties or attributes of the ite ms in a class and examine tile relationships among prope rties and classes. Fo r exampl e, suppose we are asked to build an environme ntal monitoring system for a large and complex river. The monitoring equipme nt may involve se nsors for air quality, water quality, te mpe rature, speed, and othe r characteristics of the environment. But, fo r our purposes, we may choose to define a class called "sensor"; each item in the class bas certain properties, regardless of the characteristic it is monito ring: h eight, weig ht, e lectrical require ments, maintenance schedule, and so o n. We can deal with the class, rathe r than its elements, in learning about the pro blem context, and in devising a solu- tion. In this wa y, the classes help us to simplify the problem statem eat and focus on the essential ele me nts or characte risti cs of the proble m.

We can fo rm hiera rchies o f abstracti ons, too. Fo r instance, a sensor is a type of e lectrical de vice, and we may have two types of sensors: water se nsors and air sensors.

Thus, we can form the simple hie rarchy illustrated in Figure 1.13. By hiding some of the d etails, we caa concentrate on the essential nature of the o bj ects with which we must de al and de rive soEutio ns that are simple and e legant. We will take a closer look at abstraction and info rma tion hiding in Chapte rs 5, 6, and 7.

Analysis and Design Methods and Notations. When you design a program as a class assignment, you usually work on your own. The d ocumentation that you produce is a formal descriptio n of your notes to yourse lf about why you chose a particular approach , what the variable names mean, and which algorithm you implemented. But whe n you work with a team, you must commurucate with many other participants in the developme nt process. Most e ngineers, no matter what kind of enginee ring they do,

I

Wiler sensor

Section 1.8

Electric1I device

I Sensor

I I

Air sensor

How Has Software Engineering Changed? 31

FIGURE 1.13 Simple hierarchy for monitoring equipment.

use a sta nda rd no tatio n to belp the m communicate, and to document decisions. For e xample, an a rchitect draws a diagram or blueprint that an y other archi tect can unde r- stand. Mo re impo rtantly, the commo n notatio n all ows the building contractor to unde r- stand the architect's intent and ide as. As we will see in Ch apters 4, 5, 6, and 7, the re are few similar standards in software engineering, and the mi sinte rpretation that results is o ne o f the key pro ble ms of software e ngineering today.

Analysis and design metho ds offe r us more than a communication medium. They allow us to build mode ls and check them for comple te ness and consiste ncy. Moreover, we can mo re readily reuse requirements and design compo nen ts from previous proj ects, increasing our productivity and quality with relative e ase.

But the re are many ope n questions to be resolved be fo re we can settle on a co m- mon set of meth ods and tools. A s we will see in later chapte rs, different tools and tech- niques address diffe rent aspects of a proble m, and we need to ide ntify the mod eLing primitives that will allo w us to c apture all the impo rtant aspects of a problem with a single technique . Or we need to de ve lop a representation technique that can be used with a ll me thod s, possibly tailore d in some way.

User Interface Prototyping. Prototyping means building a sma ll v ersion o f a system, usually with limited functionality, tha t can be used to

• he lp the user or custo mer identify the key requireme nts of a system

• de monstra te the fcasibiLity of a design o r approach

Often, the proto typing process is iterative: We build a proto type, eva luate it (with user and custome r feedback), conside r h ow changes might improve the product o r d esign, and then build ano ther prototype . The iterati on ends whe n we and o ur custome rs think we have a satisfactory solution to the problem at band.

Proto typin g is o ften u sed to design a good user interface: the part of the system with which the u ser inte racts. However, there are other opportunities for using proto- types, even in e mbedded systems (i.e., in systems where the software functio ns are not e xplicitly visible to the use r). The p rototype can show the user what functio ns wiU be available, regardless o f whe ther they are implemente d in softwa re or hardware. Since the use r interface is, in a sense, a bridge between the application d omain and the software

32 Chapter 1 Why Software Engineering?

d eve lopment te am, prototyping can bring to the surface issues and assumptions that may not have been clear using other approaches t o requirements analysis. We will con- sider the role of use r interface prototyping in Chapters 4 and 5.

Software Ar chitecture. The overa ll architecture of a system is important not only to the ease of implementing and testing it, but also Ito the speed and effectiveness of main- taining and changing it. The quality of the arcbiltecture can make or break a system; indeed, Shaw and Garlan (1996) present architecture as a discipline o n its own whose effects are felt thro ughout the entire development process. The arcbiitectural structure of a system should reflect the principles of good design that we will study in Chapters 5 and 7.

A system's architecture describes the system. in terms of a set o f architectural units, and a map of how the units relate to one another. The more independent the units, the mo re modular the architecture and the mo re easily we can design and develop the pieces separate ly. Wasserman (1996) points out that there are at least five ways tha t we can partitio n the system into units:

1. modular decomposition: based on assigning functions to modules

2. data-oriented decomposition: based on external data structures 3. eve nt-orie nted decomposition: based on events that the system must handle 4. outside -in design: based on user inputs to the system

5. object-o rie nted design: based o n identifying classes of objects and their interrela- tionships

These approaches are not mutuall y exclusive. For example, we can design a user inter- face with eve nt-orie nte d decomposition, while we design the database using obj ect- o riented o r data-orie nte d design. We will examine these techniques in further detail in late r chapters. The importance of these approaches is the ir capture of o ur design expe- rience, e nabling us to capitalize on our past projects by re using botlh what we have done and what we learned by doing it.

Softwa re Process. Since the late 1980s, many software engineers h ave paid ca re- ful attention to the process of developing software, as well as to the products that result. The organiza tion and discipline in the activities have been acknowledged to contribute to the quality of the so ftware and to the speed with which it is developed. However, Wasse rman no tes that

the great variations among application types and organizational cultures make it impos- sible to be prescriptive about the process itselt: Thus, it appears that the software process is no t fundamental to software engineering in the same way as are abstraction and modular- izatio n. (Wasse rman 1996)

lnstead , he suggests that diffe rent types of software need different processes. In partic- ular, Wasserman suggests that enterprisewide applications need a great deal of control, whereas individual and d epartmental applications can take advantage of rapid applica- tion developme nt, as we illustrate in Figure 1.14.

By using today's tools, many small and medium-sized systems can be built by one o r two d eve lope rs, each of who m must take on multiple roles. The tools may include a

Openmirrors.com

Controll•d davalopment

Rapid appl ieation development

Section 1.8 How Has Software Engineering Changed? 33

Departmental appl ieations

S in!le-um, desktop productivity tools

• M ission -critieal • Maltiuser • Multiplatform • 2 · to 3-tier development·

• Limited scope/vision • Low/medium risk • Single/multiplatform • 1 • to 2-tiar development

• Packages/minimal development • Low cost/low risk • Single platform

FIG URE 1. 14 Differences in development (Wasserman 1996).

text edito r, programming environme nt, testing support, and p erhaps a small d ata base to capture ke y data ele ments about the products and processes. Because t he project's risk is re latively low, little management support or revi ew is needed.

Howeve r, large, complex syste ms need more structure, checks, and balances. These systems ofte n involve many custome rs and users, and development con tinues ove r a long pe riod of time. More ove r, the develope rs do not always have control ove r the entire deve lopment, as some critical subsystems ma y be supplied by others o r be imple mented in hardware. Th.is type of high-risk system requires analysis and d esign tools, project management, configurati on management, mo re sophisticated testing tools, and a mo re rigorous system of re view and causal analysis. la C hapte r 2, we wiU take a care ful look at several process alte rnatives to see bo w va rying the process addre sses different goals. Then, in Chapters 12 and 13, we e valuate the e ffective ness of some processes and look at ways to improve them.

Reuse. In software de velopment and maintenance, we often take advantage of the commo nalities across applications by re using ite ms from previous develo pment. For example, we use the same o perating syste m o r database manageme nt system fro m o ne de ve lo pment project to the next, rathe r than buildjng a new one each time. Simi- larly, we reuse sets o f require me nts, parts of designs, a nd groups of test scripts o r data when we build systems that are similar to but not the same as what we have done be fore. Barnes and Bollinge r (1991) point out that re use is n ot a ne w idea, and they provide many inte resting examples of how we reuse much mo re than just code.

Prie to-Dfaz (1991) introduced the notion of reusable components a s a business asse t. Companjes and organizations invest in items that are re usable and the n gain quantifiable ben efit whe n those items are used again in subsequent projects. Howeve r,

34 Chapter 1 Why Software Engineering?

estabLisbing a long-te rm , effective reuse program can be difficult, because there are sev- e ral barrie rs:

• It is sometimes faster to build a small compone nt than to search for one iin a repository of reusahle componen ts.

• It may take extra time to make a component gene ral enough to be reusa ble easily by other deve lopers in the fut ure.

• It is difficult to docume nt the degree o f qlllality assurance and testin g that have been done, so that a potential re user can feel comfortable about the quality o f the component.

• It is not clear who is responsible if a reused component fails or needs to be updated. • It can be costly and time-consuming to und!e rstand and re use a component writ-

ten by someone else. • There is often a conflict between generality and specificity.

We will look at reuse in more detail in Chapte r 12, exa mining several examples o f suc- cessful reuse.

Measurement. Improvement is a driving force in software e ngineering research: improving our processes, resources, a nd me thods so that we produce and maintain !bet- te r products. But sometimes we express improvement goals generaUy, with no quantita- Live description of where we are and where we would like to go. For this reason, software measureme nt has become a key aspect of good software e ngineering practice. By quan- tifying whe re we can and what we can , we d escribe our actions and their outcomes in a common mathematical language tha t allows us to evaluate our progress. In addition, a quantitative approach p ermits us to compare progress across dis parate projects. For e xampl e, when John Young was CEO of Hewlett-Packard, he se t goals of"lOX," a ten- fold improvement in quality and p roductivity, for every proj ect at He wlett-Packard, rega rdless of application type or domain (Grady and CasweU 1987).

At a lower level of abstraction, measurement can he lp to make speci fic character- istics o f our processes and products more visible. It is ofte n useful to transform our unde rstanding of the real, empi rical world to elements and relatio nships in the formal, mathematical world, where we can manipulate them to gain furthe r understanding. As illustrated in Figure 1.15, we can use mathematics and statistics to solve a problem, look for trends, or characterize a situatio n (such as with means and standard deviatio ns). This new information can then be mapped back to the real world and applied as part of a solution to the empirical problem we are trying to solve. Throughout this book, we wiU see examples of how measurement is used to s upport analysis and decision making.

Tools and Integrated E nvironme nts. For many years, vendors touted CASE (Compute r-Aided Software Engineering) tools, where standardized, integrated devel- opment environments would e nhance softwa re development. However, we have seen how differe nt developers use different processes, methods, and resources, so a unifying approach is e asie r said th an done.

On the other hand, researchers have proposed several frameworks that aUow us to compare and contrast both existing and p ro posed e nviro nments. These frameworks

Openmirrors.com

Sectio n 1.9 Information Systems Example 35

REAL, EMPIR ICAL WORLD FORMAL, MATHEMATICAL WORLD

Empirica l relational sys I om

enbtio~ lmplem or s olulion

Empirica l, relevant results

' ' Measurement Formal relational - system

Mathemati es, statist ies

I nterp~etalion

' Numeric results ' ' ' . I

FIGURE 1.15 Using measurement to help find a solut ion.

permit us to examiae the services provided by ea.ch software engineering environment and to decide which e nvironme nt is best for a given problem o r application development.

One of the majo r di[ficulties in comparing tools is that vendo rs rare ly address the e ntire deve lopme nt Life cycle. Instead , they focus o n a small set of acti vities, such as design o r testing, a nd it is up to the user to integra te the selected tools in to a comple te de ve lo pment environme nt. Wassennan (1990) has ide ntified five issues that must be addressed in an y too l integratio n:

1. platform integration: the ability o f tools to inte rope rate on a heterogeneous ne two rk 2. presentation integra tion: commonality o f user interface 3. process integ ra tion: Linkage between the tools and the develo pme nt process

4. da ta integra tio n: the way too ls sha re data 5. control integra tion: the a bility fo r o ae tool to notify and initia te action in aa other

In each o f the subseque nt cha pte rs o f this book, we will examine tools that support the activities and concepts we describe in the chapte r.

Yo u can think o f the eight concepts described he re as e ight threads woven thro ugh the fabric o f thiis book, tying together the d ispara te activities we call software e agineering. As we learn mo re a bout software e ngineering, we will revisit these ide as to see how they unify and e levate so ftwa re engineering as a scienlific discipline.

1.9 INFORMATION SYSTEMS EXAMPLE

Througho ut this book, we will end each chapte r with two examples, o ne o f an info rma- tio n sys te m and the othe r of a real-time system. We wiU apply the concepts described in the cha pte r to some aspect of each example, so tha t you can see what the concepts mean io practice, ao t j us.t in theory.

36 Chapter 1 Why Software Engineering?

FIGURE 1.16 PiccadillyTelevision franchise area.

Pieeadillv Tele~ision

Our information system examp le is drawn (with permission) from Complete Sys- Lenis Analysis: The Workbook, the Textbook, the Answers, by James and Suzanne Robertson (Robertson and Robertson 1994). It involves the deve lopment of a system to sell advertising time for Piccadilly Television, the holde r of a regional British televi- sion franchise. Figure 1.16 ilJust rates the PiccadilJy Television vie wing area. As we shalJ see, the constraints on the price o f televisio n time· are many and varied , so the problem is both inte resting and difficult In this book, we highlight aspects of the problem and its solution; the Robertsons' book shows you detailed me thods fo r capturing and analyz- ing the system requirements.

In Britain, the broadcasti ng board issues an eight-year franchi se to a commercial television company, giving it exclusive rights to broadcast its programs in a carefully de fined region of the country. In re turn, the franchisee must broadcast a prescribed bal- ance of drama, comedy, sports, children's and other programs. M oreover, there are restrictions o n which programs can be broadcast at which ti.mes, as well as rules about the content of program s and commercial advertising.

A commercial advertiser has several choices to reach the Midlands audience: Pic- cadilly, the cable channe ls, and the satelJite chafllllels. H owever, Piccadilly attracts most of the audience. Thus, Piccadilly must set its rates to attract a portion of an advertiser's natio nal budget. One of the ways to attract an advertiser's attention is with audience ratings that re Hect the number and type o f viewers at different times of the day. The rat- ings are reported in terms of program type, audience type, time of day, televisio n com- pany, and mo re. But the advertising rate depends on mo re than just the ratings. For exampl e, the rate pe r ho ur may be cheaper if the advertiser buys a large numbe r of hours. Moreover, the re are restrictions on the type of advertising at certain times and for certain programs. For example,

• Advertisements for alcoho l may be shown o nly after 9 P.M. • If an actor is in a show, then an advertiseme nt with that actor may not be broad-

cast within 45 minutes of the show.

Openmirrors.com

Aiw tising A9encies

Section 1.10

n Spot

Copy Requiremen1s Selected

T ransmiu ion Spots Instructions

Program Transmission ----,,r

Schedu le

Commerei~S 1

/ C a es

0 PY. T uget Revenue Reeord1n1 . Reports

\ lnslruet1on1 ,.......... __ ........,

Production Companies

Piccadilly Mana5ement

Broaicastin5 Board

Real-Time Example 37

Bunaas

Program

Program Suppliers

FIGURE 1.17 Piccadilly context diagram showing system boundary (Robertson and Robertson 1994).

• If an adve rtiseme 111t fo r a class o f producl (such as an auto mobile) is scheduled for a particular comme rcial break , then no othe r advertiseme nt for something in t ha t class may be shown du ring that brea k.

As we e xplo re this example in more detail, we will no te the additional rules and regula- tio ns about advertising and its cost. The syste m context diagram in Figure 1.17 sho ws us the system bo undary and how it relates to these rules. The shaded oval is the Picca dilly syste m tha t concerns us as ou.r info rmatio n syste m e xample; the system boundary is simply the pe rimete r of the oval. The arro ws and boxes display the items that can affect the wo rking of the Piccadilly syste m, but we consider them only as a collection of inp uts and o utputs, with their sources and destinations, respective ly.

In late r chapte rs, we will ma ke visible th·e activities and e leme nts inside the shaded ova l (i.e., within the syste m boundary). We will e xamine the design and devel- o pment o f this syste m using the software engineering techniques t hat are described in each chapte r.

1.10 REAL-TIME EXAMPLE

O u.r real-time example is based on the embedded softwa re in the A.riane-5, a space rocket belo nging to the Europea n Space Agency (ESA) . On June 4, 1996, o n its maiden flight, the A riane-5 was launched and pe rformed perfectly fo r approximately 40 seconds. Then, it began to veer off course. At the direction o f an A.riane ground contro Ue r, the rocket was d estroyed by remo te contro l. The d estruction of the urnin- sured rocke t was a loss no t only o f the rocket itself, but also of the fo ur satellites it

38 Chapter 1 Why Software Engineering?

contained; the total cost of t he disaster was $500 million (Lions e t al. 1996; Newsbytes ho me p age 1996).

Softwa re is involved in almost all aspects of th e syste m, from the guidance of the rock e t to t he inte rnal wo rkings of its compo ne nt parts. The failure of the rocket and its s ubseque n t destruction raise many q uestions a bo ut software qua lity. As we will see in late r ch apte rs, the inquiry board that invest igated the cause of t he proble m focused on softwa re quaLity and its assurance. In t his chapte r, we look at quaLity in te rms o f the bus iness value of the rocket.

The re were m a ny o rganizations with a stake in the s uccess of Aria ne -5: the ESA , the Centre N a tion al d 'E tudes Spatiales (CNE S, the Fre nch s pace agency in overalJ command o f the Ariane program), a nd 12 othe r E u.ropean countries. The rocke t's loss was a nothe r in a series of delays a nd proble ms to affect the Aria ne progr am , includ ing a nitrogen leak during e ngine testing in 1995 tha t kilJed two e ngineers. H owever, the June 1996 incident was t he first whose cause was directly a ttribute d to software failure.

The business impact of the incide nt went well beyond the $500 million in equipme nt. In 1996, the Ariane-4 rocket and previous va ria nts held more than half of the world 's la unc h contracts, ahead of Ame rican , R ussia n, and C hinese launchers. Thus, the credibility of the program was at stake, as well as the potentiall business from tutu.re Ariane rockets

The fu ture business was based in part o n the new rocket's a bili ty to carry heavie r payloads into orbit than p revious launchers could. Ariane-5 was desi gned to carry a single sa tellite up to 6.8 tons or two satellites with a combined weight of 5.9 tons. Furthe r d evel- opme nt work hoped to add an extra ton to the la unc h capacity by 2002. This increased car- rying capacity has clear business advan tages; o fte n, operators reduce their costs by sh aring la unches, so Ariane can offer to host several companies' payloads at the same time.

Conside r what quality mea ns in t he context o f this example . The destructi on of Aria ne-5 turned ou t to be t he result o f a require m ent tha t was misspecified by the c us- to me r. In this case, the developer might claim that the syste m is s till high qua Lity; it was just built to the wrong specification. I ndeed, t he inquiry board formed to investiga te the cause and c ure of t he disaster noted that

The Boa rd's findings are based on thorough and ope n presentations fro m the Ariane-5 project teams, and on documenta tion which has demonstrated the high quality of the Ariane-5 programme as regards e ngineering wor k in general and completeness and trace- ability of documents. (Lions et al. 1996)

But from the user's an d custo me r's point o f view, the specification process s ho uld h ave been good e nough to identify t he specificatio n flaw a nd fo rce the custom er to cor- rect the specification before damage was do ne. The inquiry board acknowledged that

The supplier of the SRI (the subsystem in which the cause of the problem was eventually located] was only foll owing the specification given to it, which stipulated that in the event of any detected exception the processor was to be stopped. The exception which occurred was not due to random failure but a design er ror . .The e xception was detected, but ina ppro- priately handled because the view bad been ta ke n that software should be considered cor- rect until it is shown to be at fa ult. The Board has reason to believe that this view is also accepted in other areas of Ariane-5 soft ware design. The Board is in favour of the opposite view, that software should be assumed to be faulty until applying the currently accepted best practice methods can demonstrate that it is correct. ( Lions e t al. 1996)

Openmirrors.com

Section 1. 11 What This Chapter Means for You 39

In later chapters, we will investigate this example in more d etail, looking at the design, testing, and mai.1!1tenance implications of the developers' and customers' deci- sions. We will see how poor systems e ngineering at the beginning of development led to a series of poor decisions that led in turn to disaster. On the other hand, the openness of a ll concerned, including ESA and the inquiry boa rd, cou pled with high -quality docu- mentatnon and an earnest desire to get a t the truth quickly, resulted in quick resolution of the immediate proble m and an effective plan to prevent such problems in the future.

A systems view allowed the inquiry boa rd , in cooperation with the de velopers, to view the Ariane-5 as a collectio n of subsystems. This collection reflects the analysis of the proble m, as we described in this chapter, so that diffe rent developers can work o n separate subsystems with distinctly different functions. Fo r example:

The attitude of the la uncher and its movements in space a re measured by an Inertial R ef- ere nce System (SRI). It has its own internal computer, in which angles and velocities are calculated on the basis of information fro m a " strap-down" inertial platform, with laser gyros and accelerometers. The data from the SR I are transmitted through the databus to the On-Board Computer (OBC), which executes the flight program and controls the noz- zles of the solid boosters and the Vulcain cryogenic engine, via servovalves and hydraulic actuators. (Lions et al. 1996)

But the synthesis of the solutio n must include an overview of au the component parts, where the pa rts are viewed together to determine if the "glue" that ho lds them togethe r is sufficient and appropriate. lo the case o f Ariane-5, the inq uiry board sug- gested t hat the customers and developers sho uld have worked together to find the c rit- ical softwa re and make su re that it could handle not only a nticipa ted but also unanticipated behavior.

This means that critical software-in the sense th at failure of the software puts the mis.5ion at risk-must be identified at a very detailed level, that exceptional behaviour must be con- fined. and that a reasonable back-up policy m ust take software failures into account. (Lions et al. 19<J6)

1.11 WHAT THIS CHAPTER MEANS FOR YOU

This chapter has introduced many concepts that are essential to good software en gi- neering resea rch and practice. Yo u, as an individual softwa re deve loper, ca n use these conceptts in the following ways:

• When you are given a problem to solve (whether or not the solution involves soft- ware), you can analyze the problem by breaking it into its component parts, and the relationships among the parts. Then , you can synthesize a solution by solving the individual subproblems and me rging them to form a unified whole.

• Yo u must unde rsta nd that the requireme nts may change, e ve n as you are analyz- ing the proble m and building a solutio n. So you r solution s ho uld be well-docu- mented and flexible, and you should document your assumptions and the algo rithms you use (so that they a re easy to change late r).

• Yo u must view quality from several diffe rent pe rspectives., unde rstanding that technical quality and business quality may be ve ry diffe rent.

40 Chapter 1 Why Software Engineering?

• You cao use abstractioo aod measurement to belp identify th e essential aspects of the proble m and solution.

• You cao keep the system boundary in mindl, so that your solution does no t over- lap with the related systems that interact with the o oe you are building.

1.12 WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM

Much of your work wiJI be done as a member of a larger developme nt team. As we have seen in this chapter, developme nt iovolves requirements analysis, design, implementa- tion, testing, configuration maoageme nt, quaJity assuraoce, and more . Some of the people o n your team may wear muJtiple bats, as may you, a nd the success o:f the project depeods in large measure on the communica tion and coordination among the te am members. We have seen in this chapter that you can aid the success of your project by selectiog

• a d evelopment process that is appropriate to your te am size, risk leve l, and appli- cation domain

• tools that are well -in tegrated and support the type o f communica ti on your project demands

• measurements and supporting tools to give you as much vi sibility and under- standing as possible

1.13 WHAT THIS CHAPTER MEANS FOR RESEARCHERS

Many o f the issues discussed in this cha pter a re good subjects fo r furthe r research. We have no ted some of the ope n issues in softwa re engineering, including the need to find

• the right levels of abstraction to make the proble m easy to solve • the right me asurements to make the essential nature of the problem and solution

visible and he lpful

• an appropriate problem decomposition, where each subproble m is solvable • a common framework or nota tion to allow easy and e ffective tool integrati on,

and to maximize communicatio n among project participants

In late r chapte rs, we will describe many techniques. Some have been used and are we ll-proven software development practices, whereas o thers are proposed and h ave b ee n demonstrated only on small, " toy," o r student projec ts. We hope to show you h ow to improve what you are doing now and at Lbe same time to inspire you to be crea tive and tho ughtful about trying new techniques a nd p rocesses in the future.

1.14 TERM PROJECT

It is impossible to learn software e ngineering witho ut partjcipating in developing a soft- ware project with your colle agues. Fo r this reason , each chapter of this book will present info nna tion about a term project tba l you can pe rfonn with a team of classmates. The project, based on a rea l system in a real organization, will allow you to address some of

Openmirrors.com

Sectio n 1. 14 Term Proj ect 41

the very rea l cha Uenges of analysis, design, impl ementation , testing, and m aintenance. In additio n, because you will be wo rking with a team , you will deal with issues of team dive rsity and project management.

The term project involves the kinds of loans you might negotiate with a bank when you want to buy a ho use. Banks generate income in many ways, often by borrowing money from their depositors at a low interest rate and then lending that same money back at a higher interest rate in the form of bank loans. H owever, long-term property loans, such as mortgages, typically have terms of up to 15, 25, or even 30 years. That is, you have 15, 25, or 30 years to repay the loan: the principal (the money you origi nally borrowed) plus interest a t the specified rate. Although the income from interest on these loans is lucrative, the loans tie up money for a long time, preventing the banks from using t heir mo ney for other transactions. Consequently, the banks often sell their loans to consolida ting o rganizations, taking less lo ng-term profit in exchange for freeing the capital for use in other ways.

The appLicat io n fo r your te rm proj ect is called the Loan A rranger. It is fashioned o n ways in which a (mythical) Financial Consolida ti on O rganizatio n ( FC O) handles the loans it buys from banks. The consolidatio n organizatio n makes mone y by purchas- ing loans from banks and se lling the m to investors. The ban k se lls the loan to FCO, ge t- ting the principa l i.n return. Then, as we shall see, FC O sells the loa n to investors who are wiJLing to wait longer than the bank to get their return.

To see bo w the transactions work, consider how you get a loan (caUed a " mort- gage") for a house. You m ay purchase a $150,000 house b y paying $50,000 as an initial paym ent (called the " down payment") and taking a loan for the remaining $100,000. 1l1e "terms" of your loan from the First Natio nal Bank may be fo r 30 years at 5% inte r- est. This te rminology means that tbe First National Bank gives you 30 years (the te rm o f the loan) to pay back the amount you borrowed (the " principal") plus interest o n whatever you d o not pay back right away. For example, you ca n pay the $100,000 by making a payme nt once a month for 30 years (that is, 360 " installments" or "monthl y payme nts "), with inte rest o n the unpaid balance. If the initial balance is $100,000, the bank calculates your monthly payment using the amount of principal, the i nte rest rate, the am ount of time you have to pay off the loan , and the assumption that all mo nthl y payme nts sho uld be the same amount.

Fo r instance, suppose the bank tells you that your mo nthly paym ent is to be $536.82. The firs t m onth's inte rest is (1112) x (.05) x ($100,000), or $416.67. The rest of the payment ($536.82 -416.67) pays for re ducing the principal: $120.15. For the second mo nth, you now owe $100,000 minus the $120.15, so the interest is reduced to (1/12) x (.05) x ($100,000 - 120.15), o r $416.17. Thus, during the second month, o nly $416.17 of the monthly payment is interest, and the remainder, $120.65, is applied to the re maining principal. Over time, you pay less inte rest and more toward reducing t he remaining ba l- ance of principal , until you have paid off the entire principal and own your prope rty free and clea r of any encumbran ce by the bank.

Firs t Natio nal Ba nk may sell your loan to FCO some time during the period when you are making payme nts. First National negotiates a pr ice with FCO. In turn , F CO may sell your loan to ABC Investment Corpo ration. You still make your mortgage pay- ments each mo nth, but your payment goes to ABC, n ot First National. Usually, F CO sells its loans in " bundles," not individual loa ns, so that an investor buys a coUection of loans based on risk , principal involved, and expected rate of return. In other words, an

42 Chapter 1 Why Software Engineering?

investor such as ABC c an contact FCO and specify how much money it wishes to invest, for how long, how much risk it is wiJ Ling to take (based o n the histo ry o f the people or organizations paying back the lo an), a nd how much profit is expecte d.

The Loan Arranger is an apptica tion that allows an FCO analyst to select a bun- dle o f lo ans to match an investo r's desired investment characte ris tics. The applicati on accesses info rmation about Joans purchased by FCO from a varie ty of le nding institu- tions. When an investor specifies investment criteria, the system selects tbe o ptimal bundle of loans that satisfies the crite ria. While the system will all ow some advan ced o ptimiz ations, such as se lecting the best bundle o f loans fro m a subset of those avail able (for instance, from all lo ans in Massachusetts, rather than from au the lo ans available), the syste m will still allow an analyst to manually select loans in a bundle for the client. Io additio n to bundle selection, the system also a utomates info rmation management activities, such as updating bank informa tion, updating Joan in formatio n, and adding ne w lo ans when banks p rovide that info rmatio n e ach mo nth.

We can summarize this informatio n by saying that the Lo an Arranger system allo ws a Joan analyst to access information abo ut mo rtgages (ho me Joans, described here simply as " Jo ans") purchased by FCO fro m multiple le nding instituti ons with the inte ntio n o f repack aging the Joa ns to sell to o the r investo rs. The Joans purchased by FCO for investment and resale are collectively kno wn as the Joan portfolio. The L oan Arranger system tracks these portfolio loans in itts repository o f lo an information. The Joan analyst may add, view, update, or de lete loan information about lenders and the se t o f Joans in the portfolio. Additio nally, the system allows the loan analyst to create " bundles" o f Joans for sale to investo rs. A user o f Loan Arranger is a loan analyst who tracks the mortgages purchased by FCO.

In late r chapte rs, we will explo re the syste m's require ments in more depth. Fo r n ow, if you need to brush up on your unde rstanding o f principal and inte rest, you can review your o ld math books or look at htlp://www.inte rest.com/hugb/calc/formula.html.

1.1 5 KEY REFERENCES

You can find o ut about software fa ults and failures by looking in the Risks Forum, mod er- ated by Pe ter Neumann. A paper copy of some o f the Risks is printed in each issue of Software Engineering No tes, published by the Associatio n fo r Computer Machinery's Spe- cial Inte rest Group on Software Engineering (S IGSOFf). The Risks archives are avail- able on ftp.sri.com, cd risks. The Risks Forum newsgroup is avail able online at comp.risks, o r you can subscribe vi a the automated list serve r a t [email protected].

You can find out more about the Ari ane-5 project from the European Spa ce Agency's We b site: http://www.esrin.esa.it/htdocs/esa/ariane. A copy o f the joint ESA/CNES press release describing the mission failure (in English) is at http://www. esrin.esa.it/htdocs/tidc/Press/Press96/pressl9.htmJ. A Fre nch ve rsion of the press re le ase is at http://www.c nes.fr/Acces_EspaceNo 1_50x.html. An e lectronic copy o f the Aria ne-5 Flight 501 Fa ilure Repo rt is at http ://www.esrin.esa.it/htdocs/tidc/Press/ Press96/ariane5rep.html.

Le veson and Turne r (1993) describe the The rac software design and testing prob- lems in ca re ful detaiJ.

Openmirrors.com

Section 1. 16 Exercises 43

The January 1996 issue of IEEE Software is devoted to software quality. In partic- ula r, t he introductory article by Kit cbenham and Pfleeger (1996) describes and cri- tiques several quality frameworks, and the article by D romey (1996) discusses how to d e fine quality in a measurable way.

Fo r m o re informatio n about the Piccadilly Te levis io n exa mple, you may consu lt (Robertson and Robe rtson 1994) o r explo re th e R obertsons' approach to require- me nts at www.systemsguild.com.

1.16 EXERCISES

1. The following article appeared in the Washington Post (Associated Press 1996):

PILOT'S COMPUTER ERROR CITED IN PLANE CRASH. AMERICAN AIRLINES SAYS ONE-LETTER CODE WAS REASON

JET HIT MOUNTAIN IN COLOMBIA.

Dallas,, Aug. 23-The captain of an American A irlines je t that crashed in Colombia last December entered an incorrect one-letter compute r command that sent the plane into a mountain, the airline said today.

The crash killed all but four of the 163 people aboard. American's investigators concluded that the captain of the Boeing 757 apparently

thought he had entered the coordinates for the inte nded destination, Cali. But on most South American aeronautical cha rts, the one-letter code for Cali is the same

as the one for Bogota, 132 miles in the opposite direction. The coordinates for Bogota directed the plane toward the mountain, according to a le t-

ter by Cecil Ewell, American's chief pilot and vice president for flight The codes for Bogota and Cali are different in most computer databases, Ewell said.

American spokesman John Hotard confirmed that Ewell's letter, first reported in the Dallas Morning News, is b eing delivered this week to all of the airline's pilots to warn them of the coding problem.

American's discovery also prompted the Federal Aviation Adminis tration to issue a bul- letin to all airlines, waroiing them of inconsistencies between some computer databases and aeronautical charts, the newspaper said .

The computer e rror is not the final word on what caused the crash. The Colombian gov- e rnment is investigating and is expected to release its findings by October.

Pat Cariseo, spokesman for the National Transportation Safety Board, said Colombian investigators a lso are examining factors such as flight crew training and a ir traffic control.

The compute r mistake was found by investigators fo r American when they compa17ed data from the jet's navigation compute r with informa tion from the wreckage, Ewell said.

The data showed the mistake went undetected for 66 seconds while t he crew scrambled to follow an a ir traffic controller's orders to take a more direct approach to the Cali airport.

Three minutes la ter, while the plane still was descending and the crew trying to fi gure o ut why the plane had tumed, it crashed.

44 Chapter 1 Why Software Engineering?

Ewe ll said the crash presented two important lessons for pilots. "First of all, no matte r how many times you go t o South America or any other place-the

Rocky Mountains-you can neve r, never, never assume anything," he told the newspaper. Second, he said, pilots must unde rstand they can 't let automation take over responsibility for flying the airplane.

Is this article evidence that we have a software crisis? H ow is aviation better off because of software engineering? What issues should be addressed during software development so that problems like this will be prevented in the future?

2. Give an example of problem analysis where the problem components are relatively simple, but the difficulty in solving the problem lies in the interconnections among sub- problem componen ts.

3. Explain the difference between errors, faults, and fa ilures. Give an example of an e rror that leads to a fault in the requirements; the design; the code. Give an example of a fault in the requireme nts that leads to a failure; a fault in the design that le ads to a failure; a fault in the test data that leads to a failure.

4. Why can a count of faults be a misleading measure of product quality? 5. Many developers equate technical quality with overall product quality. Give an example

of a product with high technical quality that is not considered high quality by the cus- tomer. Are the re ethical issues involved in narrowing the view of quality to consider o nly technical quality? Use the Therac-25 example to illustrate your point.

6. Many organizations buy commercial software, t hinking it is cheaper than developing and maintaining software in-house. D escribe the pros and cons of using COTS software. Fo r example, what happens if the COTS products a re no longer supported by their vend.ors? What must the cust ome r, user, and developer anticipate when designing a product that uses COTS software in a large system?

7. What are the legal and e thical implications of using COTS software? Of using subcon- tractors? For example, who is responsible for fixing the problem when the major system fails as a result of a fault in COTS software? Wh o is liable when such a failure causes h arm to the users, directly (as when the automatic brakes fail in a car) or indirectly (as when the wrong information is supplied to another system, as we saw in Exercise 1). What checks and balances are needed to ensure the quality of COTS software before it is integrated into a larger system?

8. The Piccadill y Television example, as illustrated in Figure 1.17, 'contains a great many rules and constraints. Discuss three of them and explain the pros and cons of keeping them outside the system boundary.

9. When the Ariane-5 rocket was destroyed, the n ews made headlines in France and e lse- where. Liberation, a French newspaper, called it "A 37-billion-franc fireworks display" on the front page. In fact, the explosion was front-page news in almost all European news- papers and headed the main evening news bulle tins o n most E uro pean TV networks. By contrast, the invasion by a hacker of Panix, a New York-based Internet provider, forced the Panix system to close down for several hours. News of this event appeared only on the front page of the business section of the Washington Post. What is t he responsibility olf the press when re porting softwa re-based incide nts? How sh ould the potential impact of soft- ware failures be assessed and reported?

Openmirrors.com

2

In this chapter, we look at • what we mean by a "process" • software development products,

processes, and resources • several models of the software

development process • tools and techniques for process

modeling

We saw in Chapter 1 that e nginee ring software is both a creative and a step-by-step process., often involving many people producing many different kinds of products. ln this chapter, we examine the steps in more detail, Iookfog at ways to organize our activi- ties, so that we can coordinate what we do and when we do it. We begin the chapter by defining what we mean by a process, so that we understand what must be included when we model software deve lopment. Next, we examine several types of software process mode ls. Once we kno w the type of model we wish to use, we take a close loo k at two types of modeling techniques: static and dynamic. Finally, we apply several of these techniques to our information systems and real-time examples.

2.1 THE MEANING OF PROCESS

When we provide a service or create a product, whether it be developing software, writing a re port, o r taking a business trip, we always follow a sequence of steps to accomplish a se t of tasks. The tasks are usually pe rformed in the same o rde r each time; fo r example, you do not usually put up the drywall before the wiring for a ho use is installed or bake a cake b efore all the ingredie nts are mixed together. We can think of a set of ordered task s as a process: a series of steps involving activities, constraints, and resources that produce a n intended o utput of some kind.

45

46 Chapter 2 Modeling the Process and Life Cycle

A process usuaUy involves a se t of tools and techniques, as we defined them in C hapte r l. Any process has the following characte ristics:

• The process prescribes aU of the major process activities. • The process uses resources, subj ect to a set of constraints (such as a schedule), and

produces inte rmedi ate a nd final products. • The process may be composed of subprocesses that are linked in some wa y. The

process may be de fined as a hie rarchy of processes, organized so that each sub- process has its own process model.

• Each process activity has entry and exit crite ria , so that we know when the activ- ity begins and e nds.

• The activities a re o rganized in a sequence, so tha t it is clea r when one activit y is pe rformed relative to the o the r activities.

• Every process has a set o f guiding principles that explain the goals o f each activity. • Constraints o r controls may apply to an activity, resource, o r product. For

example, the budget or schedule may constrain the length of time an acti vity may take or a tool may limit the way in which a r esource may be used .

When the p rocess involves the building of some p roduct, we som etimes refer to the process as a life cycle. Thus, the software development process is sometimes calle d the software life cycle, because it describes the life o f a software prod uct from its concep- tion to its imple me ntatio n, de Livery, use, and maintenance.

Processes are impo rtant because they impose consiste ncy and structure o n a set o f activities. These characteristics are useful when we know how to do some th1ng well and we want to e nsure that o the rs do it the same wa y. For example, if Sam is a good bricklaye r, he may write do wn a description o f the bricklaying process he uses so ll:bat Sara can le arn how to do it as well. H e may take into account the diffe rences in the way p eople prefer to do things; for instance, be may write his instructions so that Sara can lay bric ks whe ther she is right- or le ft-banded. Similarly, a softwa re development p ro- cess can be described in fle xible ways that allow people to design and build software using prefe rred techniques and tools; a process model may require d esign to occur be fo re coding, but may a llow many different design techniques to ibe used. For this rea - son, the process he lps to maintain a level of consistency and quali t y in products o r ser- vices that are p roduced by many differe nt people.

A process is mo re than a procedure. We saw in Chapter 1 that a procedure is Like a recipe : a structured way o f combining tools and techniques to produce a product. A process is a co llectio n of procedures, organized so that we build pro ducts to satisfy a set o f goals or sta ndards. In fa ct, the process may suggest th at we choose fro m several p ro- cedures, as lo ng as the goal we are addressing is me l. For instan ce, the process may require tha t we check our design compone nts before coding begins. The checking can be done using informal re views or formal inspections, e ach an activity with its own p ro- cedure, but bo th addressing the same goal.

The process structure guides our acti ons by allowing us to e xamine, understand , control, and improve the activities that comprise the process. To see how, conside r the process o f making chocolate cake with chocolate icing. The process may contain several procedures, such as buying the ingr edients and finding the appropriate cooking uten sils.

Openmirrors.com

Section 2. 1 The Meaning of Process 47

The recipe describes the procedure for actuaUy mixing and baking the cake. The recipe contains activities (such as " beat the egg before mixing with othe r ingredients"), con- straints (such as the temperature requirement in " heat the chocolate to the melting point before combining with the sugar "), and resources (such as sugar, fl.our, eggs, and chocolate). Suppose Chuck bakes a ch ocolate cake according to this recipe. Whe n the cake is done, he tastes a sample and decides that the cake is too sweet. He looks at the recipe to see which ingredient contributes to the sweetness: sugar. The n, he bakes another cake, but this time he reduces the amount of sugar in the new recipe. Again he tastes the cake, but now it does not have enough chocolate flavor. He adds a measure of cocoa powde r to his second revision and tries again. After several ite rations, each time changing an ingredie nt or an activity (such as baking tbe cake longer, o r letting the chocolate mixture cool before combining with the egg mixture), Chuck arrives at a cake to his liking. Witho ut the recipe to document this part of the process, Chuck would not have bee n able to make changes easily and evaluate the results.

Processes are also important for enabling us to capture o ur expe rie nces and pass them along to o the rs. Just as master chefs pass on their favorite recipes to their coUeagues and frie nds, maste r craftspeople can pass along documented processes and procedures. Indeed, the notions of appre nticeship and mentoring are based on the idea that we share o ur experience so we can pass down our skills from senior people to junior ones.

Io the same way, we want to learn from our past development projects, document the practices that wo rk best to produce high-quality software, and folJow a so ftware de velopment process so we can understand, control, and improve what happens as we build products (or our custome rs. We saw in C hapter 1 that software development usu- aUy involves the fo llo wing stages:

• requireme nts ana lysis and definiti on • system design • program d esign • writing the programs ( program implementation)

• unit testin g • integration testing • syste m testing • system deli ve ry

• maintenance

Each stage is itself a process (or coll ection of processes) that can be described as a se t of activities. And e ach activity involves constraints, outputs, and resources. For exa mple, the require me nts analysis and definitions stage need as initial input a state- ment of desired funct ions a nd features that the user expresses in some way. The fina l o utput from this stage is a set of re quire ments, but the re may be intermediate products as the dialog be tween user and developer resuJts in cha nges and alternatives. We have constraints, too, such as a budget and scheduJe for producing the requirements docu- ment, and standards about the kinds of requirements to include and pe rha ps the no ta- tion used to express them.

Each of these stages is addressed in this book. For each one, we will take a close look at the processes, resources, activiUes, and outputs that are involved, and we will learn how

48 Chapter 2 Modeling the Process and Life Cycle

they contribute to the quality of the final product: u seful software. There are many ways to address each stage of development; each configuration o f activities, resources, and outputs constitutes a process, and a collection of processes describes what happens at each stage. Fo r instance, design can involve a prototyping process, where many of the design decisions are explored so that developers ca n choose an a ppro priate approach, and a reuse process, where previously generarted design components a re included in the current design.

Each process can be d escribed in a variety o f ways, using text, pictures, or a com- bination. Software e ngineering researche rs have suggeste d a varie ty of formats fo r such descripti ons, usually organized as a model tha t contains key process features. For the re mainde r of this chapte r, we examine a variety of software deve lopment process mod- e ls, to see how organizing process activities can make development more effective.

2.2 SOFTWARE PROCESS MODELS

Many process models are described in the software engineering literature. Some are prescriptions for the way software develo pme nt should progress, and others are descriplions of the way software development is done in actuality. In theory, the two kinds of models sh ould be similar o r the same, but in practice, they are no t. Building a process mode l and discussing its subprocesses help the tea m understand the gap between what should be and what is.

There a re several o the r reasons for mode ling a process:

• Whe n a group writes down a descriptio n of its deve lopme nt process, it forms a commo n understanding of the activities, resources, and constraints involved in software development.

• C reatin g a process model helps the development team find inconsiste ncies, re dundancies, and omissions in the process and in its constituent parts. As these problems are noted and corrected, the process becomes more e ffective and focused on building the final product.

• The model should reflect the goa ls o f deve lo pment, such as building high -quality software, finding fa ults ea rl y in development, and meeting required budget and schedule constraints. A s the mo de l is built, the deve lopme nt team evaluates can- didate activities for the ir appropriateness io addressing these goa ls. Fo r example, the team may include require me nts reviews, so that proble ms with the require- ments can be found an d fixed before design begins.

• Every process sho!Uld be tailored for the special situation in which it will be used. Building a process model helps the development team understand wbere that tai- loring is to occur.

Every software development process mod el includes system requirements as input and a delivered product as o utput. Many su ch mode ls have been proposed over the years. Let us look at seve ral o f the most p opular models to unde rstand their com- monalities and diffe rences.

Waterfall Model

One of the first mode ls to be proposed is the waterfall model, illustrated in Figure 2.1, whe re the stages are de picted as cascading fro m one to anothe r (Royce 1970). As the

Openmirrors.com

REQUIREMENTS: ANALYSIS

SYSTEM DESIGN

Section 2.2

PROGRAM DESIGN

CODING

UNIT&INTE- GRATION TESTING

SYSTEM TESTING

ACCEPTANCE TESTING

Software Process Models 49

OPERATION & MAINTENANCE

FIGURE 2.1 The waterfall model.

figure implies, o ne development stage should be comple ted before the next begins. Thus, whe n a u o f the requirem ents are e licited from the customer, a nalyzed for complete ness and consisten cy, and documented in a requireme nts docume nt, then the de velo pme nt team can go o n to system design activities. T lhe waterfall mo de l prese nts a ve ry high-level view of what goes on during development, and it suggests to develope rs the seque nce o f events they should expect to encounte r.

The waterfall model bas been used to prescribe software de ve lopme nt activities in a varie ty o f conte xts. For example, it was tbe basis fo r software development d eliver- ables in U.S. De partme nt o f Defe nse contracts for many years, defined in D epartment o f De fense Standard 2167-A. Associated with each process activity were mi lesto nes a nd deliverables, so that project m anagers could use the mo del to gauge bow close the proj ect was to comple tion at a given point in time. Fo r instance, " unit and integratio n testing" in the wate rfaU ends with the milestone "code mo dules written , tested , and integrated"; the interme diate de live rable is a copy o f the tested code. Next, the code can be turned o ve r to the syste m teste rs so it can be merged with other system compo - ne nts (hardware o r so ftware) and tested as a larger whole ..

The wa te rfall model can be ve ry useful in helping develope rs lay o ut what they need to do. Its simplicity makes it easy to e xplain to custo me rs who are no t familiar with so ftware d eve lo pment; it mak es explicit which inte rmediate products are neces- sary in o rde r to begin the next stage o f developme nt. Many o ther, mo re compl ex

50 Chapter 2 Modeling the Process and Life Cycle

models are reaUy just e mbe llishments of the waterfa U, incorporating feedback loops and extra activities.

Many problems with the waterfaU model have been discusse d in the literature, and two of the m are summarized in Side bar 2.1. The biggest proble m with the waterfall mode l is that it does not re flect the way code is really developed. Except for very well- unde rstood problems, software is usually developed with a great deal of ite ration. Often, software is used in a so lution to a problem that has never before been solved or whose solution must be upgraded to re flect some change in business climate o r operat- ing e nv ironme nt. For example, an a irplane manufacturer may re quire software for a new airframe that wiU be bigger or faster than existing models, so there are new chal- le nges to address, even though the software developers have a gre at deal of expe rie nce in bui lding aeronautical softwa re. Neithe r the users n or the developers know au the key factors that affect the desire d outcome, and much of the time spent during require- me nts a na lysis, as we wiU see in Chapte r 4, may be devoted to understanding the items and processes affected by the system and its software, as well as the relationship between the system and the e nvironment in which it will operate. Thus, the actual soft- ware development process, if uncontroUed , may look like Figure 2.2; d evelopers may

SIDEBAR 2.1 DRAWBACKS OF THE WATERFALL MODEL

Ever since the waterfall model was introduced, it has had many critics. For example, McCracken and Jackson (1981) pointed out that the model imposes a project manage- me nt structure on system development. "To contend that any life cycle scheme, even w:ith

variations, can be applied to a ll system development is either to Hy in the face of reality or to

assume a life cycle so rudimentary as to be vacuous."

Notice that the waterfall model shows how each major phase of development te rminates

in the production of some artifact (such as requireme nts, design , or code). The re is no insight into how each activity transforms one artifact to another, such as requirements to design.

Thus, the model provides no guidance to managers and developers on how to handle changes

to products and activities that are likely to occur during development. For instance, when require ments change during coding activities, the subseque nt changes to design and code a re

no t addressed by the wate rfall model.

Curtis, Krasner, Shen, and Iscoe (1987) note that the waterfall model 's major short.coming is its failure to treat software as a problem-solving process. The waterfall model was derived from

the hardware world, presenting a manufacturing view of software development. But manufactur-

ing produces a particular item and reproduces it many times. Software is not developed like that; rather, it evolves as the problem becomes understood and the alternatives are evaluated Th.us,

softwa:re is a creation process, not a manufacturing process. The waterfaU model tells us nothing

about the typical back-and-forth activities that lead to creating a final product. In particular, cre-

a tio n usually involves trying a little of this or that, developing and evaluatiing prototypes, assess- ing the feasibility of requirements, contrasting several designs, learning from failure, and

eventually settling on a satisfactory solution to the problem at hand

Openmirrors.com

0 -----~

0 DELIVERY

0 ~--.__--.II

SYSTEM TESTING

Section 2.2 Software Process Models 51

SYSTEM DESIGN

0 PROGRAM

DESIGN

0

0 FIGURE 2.2 The software development process in reality.

thrash from one activity to the ne xt and then back again, as they strive to ga ther knowl- edge about the problem and how the proposed solution addresses it.

The software deve lopment process can help to control the thrashing by including activities and subprocesses that enhance understanding . Proto typing is such a sub- process; a prototype is a partiaUy deve loped product that e na bles customers aod deve l- opers to exami ne some aspect of the proposed system and decide if it is suitable or appropriate for the finished product. For example, developers may build a syste m to imple ment a smaU portion of so me key requirements to e nsure that the re quirements are co nsistent, feasible, and practical; if not, revisions are made at the require ments stage rather than at the more costly testing stage. Similarly, parts of the design may be prototyped, as shown in Figure 2.3. Design prototyping he lps d evelopers assess alterna- tive design strategies and decide which is best for a particular project. As we will see in Chapter 5, the designe rs may address the requirements with several radically diffe rent designs to see which has the best prope rties. For instance, a ne twork may be built as a ring in one prototype and a star in anothe r, and pe rformance characteristics evaluated to see which structure is be tte r at mee ting p erformance goals or constra ints.

Ofte n, the use r interface is built and tested as a prototype, so that lbe use rs can understand what the ne w system will be like, and the designe rs get a bette r sense o f how the users like to inte ract with the system. Thus, majo r kinks in the requirements are addressed and fixed well before the requirements are officially validated during system testing; validation e nsures that the system has implemented all of the re quirements, so that each system function can be traced back to a particular require ment in the specification. Syste m testing also verifies the requirements; verification ensures that each function works correcUy. That is, validation makes sure thall the develope r is building the

52 Chapter 2 Modeling the Process and Life Cycle

REQUIREMENTS ANALYSIS

................ ~alidate

· .... .. Verify "· "· ····... .

·..... "· .. """11""';===---. "· ......

' i PROTOTYPING !_. -. -·-. -·-. -~ -· -~ _,;

...... \ . ..... ....

c•::;;,~ •,~~;:;, \\ SYSTEM TESTING

ACCEPTANCE TESTING OPERATION ~ & MAINTENANCE

FIGURE 2.3 The waterfall model with prototyping.

right product (according to the specification), and verification checks the quality of the implementation. Prototyping is useful fo r verifica tion a nd validation , but these activities can occur during other parts of tbe developmen t process, as we will see in later chapte rs.

VModel

The V m odel is a variation of the wate rfaU mod el that demonstrates how the tes ting activities are relate d to ana lysis and design (Ge rman Ministry of Defe nse 1992). A s sho wn in Figure 2.4, coding forms the po int o f the V, with analys is and design on the le ft, tes ting and maintenance on the right. Unit and integration testing addresses the correctness of programs, as we shall see in late r chapte rs. The V model suggests that unit and integrati on testing can also be used to veri fy the program design. That is, dur- ing unit and integration testing, the coders and test team members should ensure that all aspects o f the program design have been impleme nted correctly in the code. Simi- la rly, syste m testing should ve rify the system d esig n, making sure that au system design aspects are correctly im r lemented. Acceptance testing, which is conducted by the cus- to me r rathe r than the d eve lope r, validates the require me nts by associatin g a tes ting ste p with each eleme nt of the specificatio n; this type o f testing c hecks to see that all requirem e nts have been full y implemented be fore the syste m is accepted and paid for.

The model's Linkage of the le ft side wi th the right side of the V impLies that if problems are found during ve rificatio n and validation, then the le ft side of the V can be reexecuted to fix and improve the requireme nts, design, a nd code before the tes ting ste ps o n the right side are reenacted . In o ther wo rds, the V mode l makes rnore expLicit sorne oI the ite ratio n and rework that are bidden in the waterfaU depictio n. Whe reas

Openmirrors.com

Section 2.2 Software Process Models 53

Validate reqijirements OPERATION

REQUIREMENTS ANALYSIS ·-------- - - -.... & MAINTENANCE

SYSTEM DESIGN

PROGRAM DESIGN

----- ---

Verily dui!n

SYSTEM TESTI NG

<1----- UNIT & INTE - GRATION TESTING

FIGURE 2.4 The V model.

ACCEPTANCE TESTING

the focus o f the wate rfaU is o ften docume nts and arti facts, the focus of the V model is activity and correctness.

Prot ot yp ing Mo del

We have see n how the waterfall model can be amended with p rototypin g activities to improve unde rstanding. But prototyping need not be solely an adjunct of a waterfall; it ca n itself be the basis fo r an e ffective process model, shown in Figure 2.5. Since the

LIST OF REVISIONS

1-<1 - -

revise user/

prototype eutomar review

PROTOTYPE

r REQUIREMENTS SYSTEM

REQU I REMENTS (sometimes iniormal

or incomplete)

-

LIST OF <I -

LIST OF REVISIONS REVISIONS

'

PROTOTYPE - PROTOTYPE DESIGN SYSTEM

FIGURE 2.5 TI1e prototyping model.

- TEST - t

DELIVERED SYSTEM

54 Chapter 2 Modeling the Process and Life Cycle

prototyping model allows aU or part of a system to be constructed quickly to under- stand or clarify issues, it has the same objective as an engineering prototype, whe re requirements or design require repeated investigation to ensure that the developer, use r, and customer have a common understanding both of what is needed and what is pro posed. One or more of the loops for prototyping requirements, design , or the sys te m may be eliminated, de pe nding on the goals of the prototyping. However, the overaU goal remains tbe same: reducing risk and uncertainty in developme nt.

Fo r e xample, syste m development may begin with a nominal set o f requireme nts supplied by the customers and users. Then , alternatives are explo red by having inter- ested parties look at possible screens, tables, reports, and other system o utput that are used directly by the customers and users. As the users and customers d ecide on what they want , the require me nts are revised. Once the re is common agreement on what the requirem e nts should be, the develop ers move on to design. Again, alte rnative designs are exp lored, often with consultati on with customers and use rs.

The initial design is revised until the develope rs, users, and customers are happy with the result. Indeed , considering design alte rnatives sometimes reve als a proble m with the requirements, and the developers drop back to the requirements activities to reconsider and change the requirements specification. EventuaUy, the system is coded and alte rnatives are discussed , with p ossible iteration through re quireme nts and design again.

Operational Specificatio n

For many systems, uncertainty about the requirements leads to changes and proble ms later in deve lopment. Zave (1984) suggests a process model that allows the deve lopers and custo me rs to examine the requirements and their implications e arly in the development process, where they can discuss and resolve some of the uncertainty. In the o perational s pecification model , the system requirements are evaluated or executed in a way that demonstrates the behavior of tbe system. That is, once the requirements are specified, they ca n be enacted using a software package, so their implications ca111 be assessed before design begins. For example, if the specification requires the pro posed system to handle 24 users, an executable form of the specification can help analysts determine whether that number of users puts too much of a performance burden on the system.

This type of process is very diffe rent from traditional models such as the waterfall mode l. 111e waterfaU model separates the functionality of the system from the design (i.e., what the system is to do is separated from h ow the system does it), intending to keep th e customer needs apart from tbe implementation. However, an operational speci- fication aUows the functionality and tbe design to be me rged . Figure 2.6 iJJustrates how an o perational specifica tion. works. Notice that the ope ratio nal specifica tion is simi lar to pro- totyping; the process e nables use r and developer to exa mjne require me nts early on.

Transformatio na l Model

Balzer's transfonnational mode l tries to reduce the opportunity for error by eliminat- ing seve ral major deve lopment steps. Using automate d support, t he transformatio nal process applies a se ries of transformations to change a specification into a delive rable system (Balzer 1981a).

Openmirrors.com

Execute 1n• ~evise

OPERATI ONAL SPEC IFICATION

(prob I em-oriente4)

SYSTEM REQUIRE MENTS

(sometimes inlorm1I or incomplete)

Section 2.2

TRANSFORMED SPECIFICATIGN (imple111enhtion-

orient1d)

Software Process Models 55

TEST

DELIVERED SYSTEM

FIGURE 2.6 The operational specification model.

Sample tra nsformations can include

• changing the data r epresentations

• selecting algorithms • optimizing

• compiling

Because many paths can be taken from the specification to the delivered system, the seque nce of transformations and the decisions they re flect are kept as a formal devel- opment record.

The transformational approach bolds great promise. However, a major imped i- ment to its use is the need for a formal specificatio n expressed precisely so the transfor- mations can operate om it, as shown in Figure 2.7. A s formal specification meth ods become more popuJar, the transformational mode l may gain wider acceptance.

Phased Development: Increments and Iterations

In the ea rly yea rs of software development, customers were wiUirug to wait a lo ng time for software systems to be ready. Sometimes years would pass between the time the requirements documents were written and the time tbe system was delive red , caUed the cyde time. However , today's business environment no lo nge r tole rates lo ng delays. Software helps to distinguish products in the ma rke tplace, and custome rs a re a lways looking fo r new quality and functionality. For exa mple, in 1996, 80 percent o f Hewle tt- Packard 's revenues were derived from products introduced in the previous two years. Consequently, new process models were deve loped to he lp reduce cycle time.

One way to re duce cycle time is to use phased development, as shown in Figure 2.8. The sys tem is designed so that it can be delivered in pieces, enabling the users to have some functionality while the rest is being developed. Thus, there are usuaUy two systems functioning in parallel: the production syste m and the deve lo pment system. The

56 Chapter 2 Modeling the Process and Life Cycle

Compare with requirements;

update as needed FORMAL DEVELOPMENT RECORD

Sequence of transformations plus rationale for them

FORMAL SPECIFICATION

:SYSTEM REQUIREMENTS

(sometimes informal or incomplete)

TRANSFORM N

TRANSFORM 2

TRANSFORM I

FIGURE 2.7 The transfonn:ational model.

TEST

DELIVERED SYSTEM

operational o r production system is the one curre ntly being used by the custome r and use r; the developme nt system is the next version that is being prepared to replace the c ur- rent production system. Ofte n, we refer to the syste ms in te rms of their release numbers: the de ve lopers build Re lease 1, Lesl it, and Lum il o ver lo the users as Lhe first operatio nal release. Then, as the users use Release 1, the developers are buiJding Release 2. Thus, the d eve lopers a re a lways wo rking on Release n + 1 while Rele ase n. is o pera tiona l.

There are many ways for the developers to decide how to organize development into rele ases. The two most popular approaches are incremental de velopment and ite ra- tive develo pme nt. In incremental deve lopment, the system as spedfied in the require- ments d ocuments is partitioned into subsystems by functionality. The releases are d efined by beginning with one small , functi onal sulbsyste m and then adding functio nality

-

Development systems

Build Re lem t Buil~ Release 2 Build Release 3

Use Relme 1 Uu Release 2

Production systems

FIGURE 2.8 The phased-development model.

Openmirrors.com

Time .. Ute Release 3

Section 2.2 Software Process Models 57

INCREMENTAL DEVELOPMENT

ITERATIVE DEVELOPMENT

FIGURE 2.9 The incremental and iterat ive models.

with each new re le ase. The top of Figure 2.9 sh ows bow increme ntal deve lopment slowly builds up to fuJJ functio naJity with each new rele ase.

Howeve r, iterative development delive rs a fuU system at the very beginning and then changes the functionality of each subsystem with each new release. The bottom of Figure 2.9 iUustrates three re leases in an ite rative developme nt.

To unde rstand the diffe ren ce between increme ntal and ite rative d evelopment, conside r a word processing pack age. Suppose the pack age is to deliver three types of functio nality: crea ting text, o rganizing text (i.e., cutting and pasting), and forma tting text (such as using different type sizes and styles). To buUd such a syste m using incre- menta l develo pment, we might provide only the creati on functio ns in Release 1, then bo th cre ation and o rganization in Re lease 2, and finall y creatio n , o rganiza tion, and fo r- matting in Rele ase 3. H oweve r, using ite rative develo pme nt, we would provide primi- tive fo rms of all three types of functionality in Release 1. Fo r example, we can create text and then cut and paste it, but the cutting and pasting functions migh t be clumsy or slo w. So in the next iteration, R ele ase 2, we h ave the s ame functio nality, but have e nhan ced the quality; now cutting and pasting are easy and quick. E ach release improves on the previous ones in some way.

In reality, many o rganjzati ons use a combination of iterative and incremental deve lo pment. A ne w re le ase may include new functio nality, but existing functio na lity fro m the curre nt re lease may have been enhanced. These fo rms o f phased develo pment are desirable for seve ral reasons:

1. Training can begin on an e arly release, even if some functions are missing. The training process aUows developers to observe bo w certain functio ns a re executed , suggesting enhanceme nts for later rele ases. In this way, the d evelo pers can be ve ry respo nsive to the users.

2. Ma rke ts can be created early fo r functionality that has never before been offered.

3. Freque nt releases aUo w developers to fix unanticipated problems globaUy and quickJy, as they are re porte d from the operationaJ system.

4. The deve lopme nt team ca n foc us on different areas of expertise with di ffe rent re leases. F or instance, o ne r elease can ch ange the system from a comma nd-drive n

58 Chapter 2 Modeling the Process and Life Cycle

on e to a point-and-click interface, using the expe rtise of tbe user-interface spe- cialists; anothe r release ca n focus o n improv ing system pe rformance.

Spiral Model

Boehm (1988) viewed tbe software development process in Light of the risks involved, suggesting that a spiral m odel could combine de ve lopment activities with risk manage- ment to minimize and control risk. The spiral mo del, shown in Figure 2.10, is in some sense like the ite rative d evelopme nt shown in Fig ure 2.9. Beginnfog with the require- ments and an initial plan for develo pment (includ ing a budget, constraints, and alterna- tives fo r staffing, design , and development enviro nment), the process inserts a step to evaluate risks and prototype alternatives before a "concept o f oper ations" docwnent is produced to describe at a high level how the system sho uld wo rk. Fro m that document, a set o f re quirements is sp ecified and scrutinized to ensure that the requirements are as complet e and consistent as possible. Thus, the concept o f o peratio ns is the product of the first iteratio n, and the requirements a re the principal product of the second. In the third ite ration , system development produces the design, and the fourth e nables testing.

With each iteration , the risk analysis weighs di ffe re nt alternatives in light o f the require ments and constr aints, and prototyping verifies feasibility o r desira bility before a particular alternative is chosen. When risks are mdentified, the project man agers must decide how to eliminate or minimize the risk. For example, designers may not be sure whe the r users will prefer o ne type of inte rface o ver ano ther. To minimize the risk of choosing an interface that wilJ prevent productive use of the new system, the designers can proto type e ach inte rface and run tests to see which is pre fe rre d , o r eve n choose to incl.ude

HTERMINE GOALS, ALTERNATIVE$, CONSTRAINTS

PLAN lmplem.ntation

plan

FIGURE 2. 10 The spir:aJ model.

Openmirrors.com

EVALUATE ALTERNATIVES AND RISKS

HVELOP AND TEST

Sectio n 2.2 Software Process Models 59

two differe nt interfaces in the design, so the users can select an interface when they log on. Constraints such as budget and schedule help to de termine which ris k-management strat- egy is ch osen. We will discuss risk management in more detail in C hapter 3.

Agile Methods

Many o f the software developme nt processes pro posed and used from the 1970s thro ugh the 1990s tried to impose some fo rm o f rigor on the way in which software is conceived, docume nted, developed, a nd tested. In the late 1990s, some developers who bad resjsted this rigor formul ated the ir own principles, trying to highlight the roles t hat flexibility could play in producing software quic kly and capably. They codified t!beir thinking in an "agile manifesto" tha t focuses o n four tene ts of a n alte rnative way of thinking about software development (Agile Alliance 2001):

• They value individ uals and in teractio ns ove r processes and tools. This philosophy includes supplying develope rs with the resources they need and then trus ting them to do the ir j o bs well. Teams o rganize themse lves and communicate thro ugh face-to-face interaction rather t han thro ugh documentatio n.

• They prefer to invest time in producing workmg software rather than in p ro- ducing comprehensive documenta tion. That is, the primary measure of success is the degree to which the software works prope rly.

• They focus on cus tom er colla boratio n ra the r than contract negotiation , thereby involvin g the customer in key aspects o f the development process.

• TI1ey concentrate on responding to change rathe r than o n creating a plan and then foll owing it, because they believe that it is impossible to anticipate alJ re quire ments at the beginning o f develo pme nt.

The overalJ goal of agile development is to satisfy the customer by "early and continuous delivery of valuable softwa re" (A gile Alliance 2001). Many cu sto mers have business needs that change over time, reflecting no t only newly discovered needs but also the n eed to respo nd to changes in the marke tplace. For example, as software is being designe d and constructed, a competitor m ay re lease a new product tha t requires a chan ge in the soft- wa re 's planned functionali ty. Similarly, a government agency or standards body may impose a regulation or s tandard tha t affects the software's design o r requirements. It is tho ught that by building flexibility into the deve lopment process, agile methods can enable cus to mers to add or change requirements la te in the deve lo pment cycle.

There are many e xamples of agile processes in the curre nt Lite rature. Each is based o n a set of p rinciples that implemen t t he te:nets of the agile m anifesto. Exam p les include the fo llowing.

• E'xtrcmc programming (XP), described in d etail be low, is a set of techniques fo r leveraging the crea tivit y of develope rs and minimjzing the amount of administra - tive ove rhead.

• Crystal is a colJection of approaches based o n the no tion that every project n eeds a diffe rent set of policies, conventions, and me thodologies. Cockburn (2002), the cr ea to r of Crystal, believes that people have a majo r influe nce on software qual - ity, and thus the qu ality of projects and processes improves as the quality of the

60 Chapter 2 Modeling the Process and Life Cycle

people involved improves. Productivity increases through be tter communication and freque nt deli very, because the re is less need fo r iote rrne diate work products.

• Scrum was created at Object Technology io 1994 and was subsequently commer- cialized by Scbwaber and Beedle (2002). It uses iterative d evelopment, where each 30-day iteration is called a "sprint," to implement the product's backJog of prio ritized re quire men ts. Multiple self-o rganiziog a od auton omous te ams imple- ment product incre me nts io paralle l. Coordinatio n is done a t a brief daily status mee ting call ed a "scrum " (as in rugby).

• Adaptive software development (ASD) has six basic principles. There is a mission that acts as a guide line, setting out the destinatio n but not prescribing h ow to get there. Features are viewe d as the crux o f custome r value, so the p roject is orga- nized a round building components to provide the features. Iteratio n is important, so redoing is as critical is doing; cba oge is e mbraced , so that a change is viewed no t as a correction but as ao adjustment to the re aliti es of software developm eot. Fixed de livery times force develope rs to scope down the require ments essential for each version produced. At the same time, risk is e mbraced, so that the d evel- opers tackle the ha rdest problems first.

Often, the phrase "extre me programming" is used to describe the mo re general con- cept of agile me thods. In fact, XP is a particular fo rm of agile process, with guiding prin- ciples that reflect the more gene ral tene ts o f the agi le manifesto. Proponents o f XP e mphasize four ch aracteristics of agility: communication, simplicity, courage, and feed- back. Communication involves the continual inte rchange be tween customers and develope rs. S implicity e ncourages develo pers to select the simpl est design or imple- me ntation to address the needs of their custome rs. Courage is desc ribe d by XP cre ators as commitme nt to deli vering functio nality ea rly and o ften. Feedback loops are built into the various activities during the de ve lo pmen t process. For example, programmers work toge ther to give each o ther feedback on the best way to implement a design , and custo me rs work with deve lo pers to perform pla nning e xercises.

These characteristics are embedded in wha t are kno wn as the twelve [acets o f XP

• Th e planning game: ln this aspect of XP, the customer, who is on-site, defines what is meant by " value," so that each requireme nt can be assessed according to h ow much value is added by implementing it. The users write st ories a bout ho w the syste m should work , and the develo pers the n estimate the resources necessary to re alize the stories. The stories describe the a ctors and actio ns involved , much like the use cases we de fine in more detail in Chapters 4 and 6. Each story relates one re quire ment; two o r three sentences are all that is needed to expl ain the value of the requirement in sufficient detail fo r the d evelo per to specify test cases and esti- mate resources for impleme nting the re quirement. Once the stories are written, the prospective users prioritize require ments, splitting a nd merging them until consensus is re ached o n what is needed , what is testable, and what can be d one with the resources available. The planne rs the n generate a map of each release, documenting what the re lease includes and when it will be de live red.

• Sma ff releases: The system is designed so tha t functio nality can be delive red as soon as possible. Functions are decomposed into small parts, so tha t some functionality

Openmirrors.com

Section 2.2 Software Process Models 61

can be delive red e arly and the n improved or expanded o n in later rele ases. The sma ll re leases require a phased-de ve lopme nt approach, with incremental or ite ra - tive cycles.

• Metaphor: Tue d evelopment te am agrees on a common vision of how the syste m will operate. To support its vis ion, the te am chooses common names and agrees on a common way o f add ressing key issues.

• Simple design: D esign is kept simple by addressing only current needs. This approach reflects the phllosophy that anticipating future needs can lead to unnecessary func- tionality. U a particular portion o f a system is very complex, the team may build a spike-a quick and narrow implementation- to help it decide how to proceed.

• Writing tests first: To ensure that the customer's needs are the driving fo rce behind deve lopment, test cases are writte n first, as a way of forcing customers to specify require ments. that ca n be tested and verified once the software is built. Two kinds of tests are use d in XP: fun clional tests that a re specifie d by the custome r and exe- cuted by both develope rs and users, and unit tests tha t a re written and run by deve lope rs. In XP, functional tests are automated and, ideally, run daily. The func- tional tests are considered to be part of the syste m sp ecificatio n. Unit tests are written both !before and a fter coding, to verif-y that each modular portion of the impleme ntati on works as designed. Both functional and. unit testing are d escribed in more detaiJ in C hapte r 8.

• R efactoring: A s the system is built, it is Likely that re quirements wiU change. Because a major characteristic of XP philosophy is to design only to curre nt require ments1 it is o ften the case that new requirements force the developers to reconsider their existing design. Refactoring refers to revisiting the requireme nts and design, reformulating the m to match new and e xisting needs. Sometimes refacto ring addresses ways to restructure design and code without perturbing the system's exte rnal behavio r. Tue refactoring is done in small steps, supported by unit tests and pair programming, with simplicity guiding the effort. We wiJl discuss the difficulties o f refacto ring in Chapter 5.

• Pair programming: As noted in C hapter 1, there is a tension be twee n viewing software engineering as an art and as a science. Pair program.ming attempts to address the artistic side of software developme nt, acknowledging that the apprentice-master metaphor can be useful in teaching novice software develop- e rs how to deve lop the instincts o f maste rs. Using o ne keyboard, two paired pro- grammers develop a syste m from the speciJications and design. One person has responsibility for finishing the code, but the pairing is flexible : a developer may have more than one partne r on a given day. We will see in Chapter 7 how pair pro- gramming compares with the more traditional approach o f individuals working separately until the ir modules have been unit-tested.

• Collective ownership: In XP, any de ve lope r can make a change to any pa rt of the syste m as il is being develo ped. In Chapte r 11, we will address the difficulties in managing change, including the errors introduced when two people try to change the same module simultaneously.

• Continuous integration: D elive ring functio nality quickly mea ns that wo rking sys- tems can be promised to the customer daily and sometimes even hourly. The

62 Chapter 2 Modeling the Process and Life Cycle

emphasis is on smaU increments or improvements ra ther than on grand le aps from o ne revision to the next.

• Sustainable pace: XP's emphasis on people includes acknowledging that fatigue can produce e rrors. So proponents of XP suggest a goal of 40 hours for each work week; pushing deve lopers to devote he roic amounts of time t o meeting deadlines is a signal that the deadlines are unre aso nable or that there are insufficien t resources for meeting them.

• On-site custom er: Ide ally, a custome r should be present on -s.ite, wo rking with the deve lopers to determine require me nts and providing feedback about bow to test them.

• Coding standards: Many observe rs think of X P and other agile methods as pro vid- ing an unconstrained environment where anything goes. But in fact XP advocates clear de fi nition of coding standards, to encourage teams to b e able to understand and change each othe r's work. These stand ards support othe r practices, such as testing and refactoring. The result should be a body of code that appears to have bee n written by on e person, and is consisten t in its approach and expression.

Extreme programming and agile methods are relative ly new. The !body of e vidence for its effective ness is small but growing. We wiU re visit many agile metho ds and concepts, and their e mpirical evaluation, in later chapters, as we discuss their related activities.

The process models presented in this chapte r are onl y a few of those that are used or discussed. Other process models can be defined and tailored to the needs of the user, custome r, and deve loper.As Side bar 2.3 notes, we should really capture the development process as a collection of process models, rather than focusing on a single model or view.

SIDEBAR 2.2 WHEN IS EXTREME TOO EXTREME?

As with most software development approaches, agile methods are not without their cr it-ics. For example, Stephens and R osenberg (2003) point out that many of extreme pro- gramming's practices are interdependent, a vulnerability if one of them is modified. To see

why, suppose some people are uncomfortable with pair programming. More coordinatio n a nd documentation may be required to address the shared vision that is missing when people

work on the ir own. Simi1arly, many developers prefer to do some design before they write

code. Scrum addresses this preference by organizing around monthly sprints. E lssamadissy and Schalliol (2002) note that, in extreme programming, requireme nts are expressed as a set

of test cases that must be passed by the software. This approach may cause customer represen-

ta tives to focus on the test cases instead of the requ irements. Because the test cases a re a detailed expression of the requirements and may be solution oriented, the emphasis on test

cases can distract the representatives from the project 's underlying goals and can lead to a s it-

uation where the system passes all the tests but is not what the customers thought they were paying fo r.As we will see in Chapter 5, refactoring may be the Achilles h eel of agile me thods;

it is difficult to rework a software system without degr ading its architectu re.

Openmirrors.com

Section 2.3 Tools and Techniques for Process Modeling 63

SIDEBAR 2.3 COLLECTIONS OF PROCESS MODELS

W e saw in Sidebar 2.1 that the development process is a problem-solving activity, but few of the popular process models include problem solving. Curtis, Krasner, and Iscoe (1988) performed a field study of 17 large projects, to determine which problem-solving fac- tors should be captured in process models to aid our understanding of software developme nt.

In particular, they looked at the behavioral and organizational factors that affe ct project out-

comes. Their results suggest a layered behavioral model of software development, including five key perspectives: the business milieu, the company, the project, the team, and the individ-

ual. The individual vie w provides information about cognition and motivation , and project and team vie ws tell us about group dynamics. The company and business milieu provide infor-

mation about organizational behavior that can affect both productivity and quality. This

model does not replace traditional process models; rather, it is orthogonal, supplementing t he traditional models with information on how behavior affects the creation and production

activities.

A s the developers and customers learn about t!be problem, they integrate their knowl- edge of domains, technology, and business to produce an appropriate solution. By viewing

development as a collection of coordinating processes, we can see the effects of learning, tech-

nical communication, customer interaction, and requirements negotiation. Current mod.els that prescribe a series of development tasks " provide no help in analyzing how much ne w

information must be learned by the project staf~ how discrepant requirements should be nego-

tiated, how a design team can resolve architectural conflicts, and how these and similar factors contribute to a project's inherent uncertainty and risk" (Curtis, Krasner, and Iscoe 1988). How-

ever, when we include models of cognitive, social , and organizational processes, we begin to see

the causes of bottlenecks and inefficiency. It is this insight that enables managers to understand and control the development process. And by aggregating behavior across layers of models, we

can see how each model contributes to or compounds the effects of another mcxlel's factors.

No matte r what process model is used , many activities are commo n to a ll. A s we investigate software e ngineering in later chapters, we wiU examine each develo pment activity to see what it involves and to find out what tools and techniques make us more e ffective and productive.

2.3 TOOLS AND TECHNIQUE S FOR PROCESS MODELING

There are many choices for modeling tools and t,echniques, once you decide what you want to capture in your process model; we have seen several modeling approaches in our model depictions in the preceding section. The appropriate technique for yo u de pends on your goals and your preferred work sty le. Io particular, your choice for no tation de pends on what yo u want to capture in your model. The n otatio ns range from te xtual ones that express processes as functions, to graphical ones that depict processes

64 Chapter 2 Modeling the Process and Life Cycle

as hie rarchies of boxes and arrows, to combinations o f pictures and text that link the g raphical depiction to tabl es and functi ons e labo rating on the high-level illustratio n. Many o f the mode ling n otations can also be used for representing requireme nts and d esigns; we examine some of them in later chapte rs.

In tbis chapte r, the no tatio n is secondary to the type of model, and we focus o n two major categories, sta tic and dynamic. A static model depicts the process, showing that the inputs are transfo rmed to outputs. A dyn amic model enacts the process, so the user can see how inte rmediate and final products are transformed ove r time.

Sta tic Modeling: La i Nota tion

There a re many ways to mode l a process statica Uy. In the early 1990s, Lai (1991) d evel- o ped a compre hensive process notatio n that is intended to ena bl'e someone to model any process at any leve l o f de tail. It builds on a p aradigm where people perform roles while resources pe rform activities, le ading to the production of a rtifacts. The process model shows the relation ships among the rol es, activities, and artifacts, and state tab les sho w info rmation a bout the completeness o f each artifact at a given time .

In pa rt icular, the eleme nts of a process are viewe d in terms of seven types:

1. Activity: Some thing that wiU happen in a prncess. lllis ele me nt can be re lated to what happens be fore and after, what resources are neede d, what triggers the activity's start, what rules govern the activity, how to describe the algorithms and lessons lea rned , and how to relate the activity to the project team.

2. Sequence: The o rder o f activities. The sequence can be described using triggers, prog ramming constructs, transformati ons, ordering, or satisfaction of conditions.

3. Process model: A view of inte rest abo ut tbe system. Thus, parts of tbe p rocess may be represente d as a separate mode l, either to predict process behavio r o r to examine certain characte ristics.

4. R esource: A necessary item, tool, or person. Resources can include equipment, time, o ffice space, people, techniques, and so on. The process model identi fies h ow mucb of each resource is needed fo r each activity.

5. Control: An exte rnal influence over process enactment. The controls may be manual or auto matic, human or mechanical.

6. Policy: A guiding principle . This higb-level p rocess constraint influen ces p rocess enactme nt. It may include a prescribed development process, a tool that must be used , or a mandatory management style.

7. O rganization: The hie rarchical structure of process agents, wiith physical grouping correspo nding to logical grouping and relate d roles. The mapping from physi- cal to logical grouping should be flexible e nough to reflect changes in physical environment.

The process description itself has seve ral levels o f abstractio n, including the software d eve lopment process that directs certain resources to be used in constructing specific modules, as we ll as gene ric models that may resemble the spiral or waterfall models. La i's notatio n includes seve ra l templates, such as an Artifact DefinHion Te mpla te, which records info rmatio n about particular artifa cts.

Openmirrors.com

Sectio n 2.3 Tools and Techniq ues fo r Process Mo deli ng 65

Lai's approach can be applie d to modeling software development processes; later in this ch apter, we use it to model the risk involved in developmen t. However, to demonstrate its use and its ability to capture many facets of a comp lex activity, we apply it to a re la tive ly simp le but familiar process, driving an automobile. Table 2.1 con- ta ins a description of the key resource in this process, a car.

Other templates define rel ations, process states, operations, analysis, actions, and roles. Graphical diagrams re present the relationships between elements, capturing the main relatio nships and secondary on es. For exa mple, Figure 2.11 illustra tes the process of starting a car. The " initiate" b ox represents the en trance conditions, and the " pa rk" box represents a n exit condition. The left-hand column of a condition box Lists ar tifacts, a nd the right-hand column is the artifact state.

TABLE 2.1 Artifact Definition Form for Artifact "CAR" (Lai 1991)

N ame Car

Synopsis This is the artifact that represents a class of cars.

Complexity type Composite

Data type (car c, user-defined)

Artifact-state list

parked ((state of(car.engine) = off) (state of(car.gear) = park) (state=of(car.speed) = stand))

Car is not moving and engine is not nmning

initiated ((state of(car.engine) = on) (state o f (car.key h ole) = has-key) (state-of(car-driVer(car.)) = in-car ) state of(car.gear ) = d rive) (state_of(car.sp eed ) = stand))

Car is not movin& but the engine is r111111i11g.

movi11g ((state of(car.engi11e) = on) Car is moving forward or backward. (state of(car.keyhole) = has-k ey) (stale-of(car-driver(car.)) = driving) ((state of(car.gear) = drive) or (state of(car.gear) = reverse)) ((state of(car.speed) = stand) or (state_of(car.speed) = slow) or (state of(car.speed) = m edium ) or (state_of(car.sp eed ) = high ))

Subartifact list

doors Thefo11rdoors of a car

engine The engine of a car

keyhole The ignition keyhole of a car

gear The gear of a car

speed The speed of a car

Relations list

car-key This is the relation between a car and a key.

car-driver This is the relatio11 between a car a11d a driver.

66 Chapter 2 Modeling the Process and Life Cycle

m.en,lne l 1lee_on m .eulne off 1lee_o1r driver. ~ut_m !0 01 m.englne~ - eir.11•lne 01 tm_oll of( by. ln_poeklt opu d010r ln_m driver. - - driver. ln_m get_ off out_ett drtnr. - Ikey. ln_puru c Iott- doot I dtlYI Cll.,Hr car.,ear

,,,v. rudy_to_p1rll ark car.,111 -

- e11.~11r Plrli lock - stind 111.tpeed ear.speed stand open_ door st1nd m.tpeed m.1pud tllnd 11l1m_ uy park clot1_door

lnltl~te put_key_l1 uke_uw_out dtlff tu1n_by_ln_to_l11t .....-::::::::

~ unlock ---~

~~ ratdy_lor_~w ~

~ hck forw11d 1pMll

on drive

drlm. l1_ett 1pted_1p

ln_etr drlm. ett.9u1 dtlve dtlve ctr.gear

1low_down ett.tpted mnd

open_door lllld car.OHd ~

drive clo11_door lock qiloek

FIGURE 2. 11 The process of starting a car(Lai 1991).

Transition diagrams supplement the process model by showin g bow the states are re lated to one another. For example, Figure 2.12 iatustrates the transitions for a car.

La.i 's notation is a good example of how multiple structures and strategies can be used to capture a great deal of information about the software development process. But it is also useful in organizing and depicting process information about user require- me nts, as the car example de monstrates.

FIGURE 2. 12 Transition diagram for a car (Lai 1991).

PARKED

initiy

~-out ---- '4 stop

90

MOVING

Openmirrors.com

Section 2.3 Tools and Techniques for Process Modeling 67

Dynamic Modeling: System Dynamics

A d esirable property of a process model is the ability to enact the process, so that we can wattcb what happens to resources and artifacts as activities occur. In oth er wo rds, we want to descrihe a mode l of the process a nd then watch as software shows us how resources flo w thro ugh activities to become o utputs. This dynamic process view enables us to simulate the process and make changes before the resources are actuaLiy e xpended. Fo r example, we can use a dynamic process model to he lp us decide how many teste rs we need or whe n we must initiate testing in o rde r to finish on sched ule. Similarly, we ca n incl ude or exclude activities to see the ir effects on effo rt and schedule. Fo r instan ce, we can add a code -re view activity, making assumptions about how many fa ults we will find during the review, and de te rmine whethe r revie wing shorte ns test time significantly.

There are severa l ways to build dynamic process models. The systems d ynamics approach, introduced by Forreste r in the 1950s, has been useful for simulating dive rse processes, including eoological, econo mic, and political systems (Forreste r 1991). Abdel-Ha miel and Madnick have applied system d ynamics to software development, e na bling project manage rs to " test o ut" their process choices befor e imposing them oo de velo pe rs (Abdel-Hamid 1989; Abdel-Hamid and Madnick 1991).

To see how system dynamics works, conside r how the software development pro- cess affects productivity. We ca n build a descriptive mo del of the various activities that involve developers' time and then look at bow changes in the model increase or decre ase the time it takes to design, write, and test the code. First, we must determine wrucb factors affect ove rall productiviity. Figure 2.13 depicts Abdel-Hamid 's unde rstanding of these

Fmtlon of stafr experienced Percent of

Experienced staff no111lnal potential productivity j New staff nollllnal project eio111pleted

poteftllal producth11ty I ~ A

1 1 Learning 111ultlpller

vera9e no111 na

Actual fraction of person-day

/ on project

Over/under work tolrnnees

potential productivity ~ .....__ Potential ~

productivity

+ S6ft11m development

productivity

~ Motivation and co111111unlca~lon ...__ Com111unlca1lon

lonu overhead

Schedule pressure t Suff tile

FIGURE 2.13 Model of factors contributing to productivity (Abdel-Hamid 1996).

68 Chapter 2 Modeling the Process and Life Cycle

factors. The arrows indicate ho w changes in one factor affect ch anges in another. Fo r e xample, if the fraction of experienced staff increases fro m one-quar te r to one-half of the people assigned to the project, then we would expect the average p otential productivity to incre ase, too. Similarly, the larger the staff (reflected in staff size), the more time is d evoted to communicatio n among project members (communicati on overhead).

The fig ure sho ws us that average nominal p otential productivity is affected by three things: the productivity of the experienced staff, the fraction o f experienced staff, and the productivity o f the new staff. At the same time, new staff must learn about the project; as more o f the project is complete d, the m ore the n ew staff must learn before they can become productive members o f the team.

Other issues a ffect the overall development productivity. First, we must conside r the fractio n of e ach d ay tha t each de ve lope r ca n devo te to the project. Schedule pres- sures affect this fractio n, as do the develop ers' tolerances fo r wo rkload. Staff size affects productivity, too, but the more staff, the mo re likely it is thall: time will be needed just to communicate informatio n among team members. Communication and motivation, co mbine d with the potential productivity represe nted in the uppe r half of Figure 2 .13, suggest a gene ral software development productivity relationship.

Thus, the first ste p in using syste m dynamics is to identify these relationships, based o n a combina tion of e mpirical e vidence, research reports, arnd intuition. The next step is to quantify the re latio nships. The quantificati on can invo lve direct re lationsh ips, such as that be tween s taff size and communication. We kno w t hat if n peopl e are assigned to a project, the n there are n(n - 1)/2 po tentia l pairs o f people who must com- munica te and coordinate with one anothe r. For some relationships, especially those that involve resources that change over time, we must assign distribution s that describe the building up and diminishing of the resource. Fo r example, it is rare for everyone on a project to begin wo rk o n the fLrst day. The systems analysts begin, and coders jo in the proje ct o nce the significant re quire ments and design components are documented. Thus, the distribution describes the rise and fall (or even the fluctuation , such as avail- ability around ho lidays or summer vacations) o f the resources.

A system dynami cs mode l can be exte nsive and comple x. Fo r example, A b del- H amid's softwa re develo pment mode l contains more than 100 causal links; Figure 2.14 sho ws an overvie w o f the re lationships he define d. He defined four maj or areas llhat affect productivity: so ftw are production, human resource management, planning, and control. Productio n includes issues o f quality assura nce, learning, and developme nt rate. Human resources address hiring, turnove r, and experience. Planning concerns scheduJes and the pressures they cause, and control addresses progress measure men t and the e ffort required to finish the project.

Beca use the numbe r o f links can be quite la rge, system d ynamics mode ls are sup- po rte d b y software that captures both the links and their quanlitallive descriptio ns and the n simulates the ove rall process or some subprocess.

The po we r of syste m dynamics is impressive, but this method sho uld be used with caution. The simula ted results depend o n the quantified relationships, which are often heuristic or vague, not clearly based on empirical research. Ho we ver, as we will see in late r chapte rs, a histori cal database of me asure ment informatio n about the various aspects of deve lopme nt can help us ga in confiden ce in our understanding of rela tion- ships, and thus in the results o f dynamic mode ls.

Openmirrors.com

Section 2.3

SOFTWARE PRODUCTION

Seledule pruture

t M1dul1d

ForeC11t1d

Tools and Techniql.lles for Process Modeling

MUMAN RESOURCE MANAGEMENT

., Perceived , profotlilty ,

Project tuh / Workforce co111pletlon

level d1t1 p1rulv1d ' H

0111plellon , d1te

pmelnd co111plete - -- iuuracr I 11 111111urln! mded T f

Adjurt111ent1 to worllrorce and scl edule

I PLANNING

t prosm• ·' Effort percelv1d P1rulnd

still needed .........._ project

CONTROL

FIGURE 2.14 Structm e of software development (Abdel-H amid 1996).

SIDEBAR 2.4 PROCESS PROGRAMMING

69

In the mid-1980s, Osterweil (1987) proposed that software engineering processes be specified using algorithmic descriptions. That is, if a process is well-und erstood, we should be able to write a program to describe the process, and then run the program to enact the p rocess. The goal of process programming is to eliminate uncertainty, both by having enough ·understand- ing to write software to capture its essence, and by turning the process into a d eterministic solution to the problem.

Were process programming possible, we could have management visibility into all pro- cess activities, automate all activities, and coordinate and change all activities with ease. Thus, process programs could form the basis of an automated environment to produce softwar e.

However, Curtis, Krasner, Shen, and Iscoe (1987) point o ut that Osterweil's analogy to computer programming does not capture the inherent variability of the underlying develop- ment process. When a computer program is written, the programme r assumes tha t the imple- mentation e nvironme nt works properly; the operating system, database manager , and

hardware are re liable and correct, so there is little variability in the computer 's response to an inst ruction. But when a process program issues an instruction to a member o f the project team, the re is great variability in the way the task is executed a nd in the results produced. As

70 Chapter 2 Modeling the Process and Life Cycle

we will see in Chapter 3, differences in skill, experience, work habits, understanding the cus-

tomer' s needs, and a host of other factors can increase variability dramatically. Curtis and his

colleagues suggest that process programming be restricted only to th~ situations with min- imal variability.Moreove r, they point out that Osterweil 's examples provide in formation on ly

about the sequencing of tasks; the process program does not help to wam managers o f

impending problems. "The coordination of a web of creative intellectual tasks does not appear to be improved greatly by current implementations of process programming, because

the most important source of coordination is to ensure that all of the interacting agents share the same mental model of how the system should operate" (Curtis et al. 1987).

2.4 PRACTICAL PROCESS MODELING

Process mode ling has long been a focus of software e ngineering research. But how practical is it? Se ve ral rese arche rs re port that, used properl y, p rocess mode Ling offers grea t be ne fits fo r unde rs tanding processes and re vealing inconsistencies. For exa mple, B argbo uti, Rosenblum, Belanger, and AJliegro (1995) conducted two case studies to d ete rm.lne the feasibility, utility, and limitatio ns o f using process m odels in large orga- nizations. In this section, we examine what they did and what they found.

Marvel Case Studies

In both studies, the researche rs used MSL, the Marvel Specification Language, to de fine the process, and the n gen erated a Marvel process ,enactment environment for it (Kaiser, Feile r, and Popovich 1988; Barghouti and Kaiser 1991 ). MSL uses three main constructs-- classes, rules, and tool e nvelo pes-to produce a three -part process descripti on:

1. a rule- based s pecification of process behavior

2. a n o bject-orie nted definitio n of the model's info rm ati on process 3. a set of envelopes to inte rface between Ma rvel and external software tools used

to execute the process.

The first case study invo lved an AT&T call -p rocessing n etwo rk that ca rried pho ne calls, and a se parate signaling ne two rk resp onsible for routing the caUs and bal- ancing the ne twork 's load. Marvel was used to describe the Signaling Fault Resolution process that is respo nsible for detecting, servicing, and resolving problems with the sig- naling ne twork. Workcenter 1 monitored the ne twork, detected failllts, and re ferred the fault to one of the two other workcenters. Workcente r 2 handled software o r human faults that required detailed analysis, and Wo rkcenter 3 dealt with hardware failwes. Figure 2 .15 de picts this process. D ouble dashe d lines indi cate which activity uses the tool o r database re prese nted by an oval. A rectangle is a task or activity, and a diam ond is a decision. Arrows indicate the flow of control. A s you can see, the figure provides an o vervie w but is not de tajjed e nough to capture essential process elements.

Consequently, each o f the entities and workcenters is mode le d using MSL. Figure 2.16 illustrates ho w that is done. The uppe r half of the figure defines the class

Openmirrors.com

Section 2.4 Practical Process Mo deling

WORKCEMTER I SUBPROCESS

WORKCEMTER 2 SUBPROCESS

~ -------~

Initiate process

.___c_r_n_te~tic_k_ei _ __. ::~

R•ler lo Workcenter 3

Workcenter 3: Fix equipment problem

Refer to Workcenter 2

Clm ticket

·, Cr.ate ticket

Diagnou

yes

Close ticket

FIGURE 2.15 Signaling Fault Resolution process (Bargbouti et al 1995).

TICKET:: uperelus ENTITY status: (Initial, open, relerred_out, relernl_do11,

dia9nostics '•~el description referreCto referrals proeeu

end

cloud, fiud) = initial; (termini !, non_terminal, none)= none; Integer; text; I ink WORKCENTER; n t_ol link TICKET; I ink PROC_I NST;

diagme [7t: TICKED : (oists PROC_INST 7p m~t~at (linkto [7t.proeess ?p])J

(an d (?I.status= ep11}(?t.dia9nostics =none)) (TICKET_ UTIL dla9nm ?t. Name} (and (7t.dla9nestiei = terminal)

(7p.lut_tuk = dia9me) (7p.uxt_lask = refer_te_ WC3));

(11d (7t.dia9ustics = •H_tar•iaal) (?p.lut_task = diagme) (?p.uxt_task = reFer_to_WC2));

Class defhititn for trouble tickets

Ihle for dia9usin9 ticket

FIGURE 2.16 Examples of Marvel commands ( B<trghuuli el al. 1995).

71

72 Chapter 2 Modeling the Process and Life Cycle

TICKET, where a ticket represents the trouble ticket (or problem report) written when- ever a failure occurs. As we will see in the chapters o n testing, trouble tickets are use d to track a problem from its occurrence to its resolutio n. The entire ne two rk was represented with 22 such MSL classes; all info rmatio n created or required by a process was included.

Ne xt, Che mo de l addressed be ha vio ral aspeccs of the Signaling Fa ult Resoluttion process, The lowe r half of Figure 2.16 is an MSL rule that corresponds loosely to the box of Figure 2.15 labe led " Diagnose." Thus, the MSL describes th e rule for diagnosing o pen pro ble ms; it is fired fo r each o pen ticke t. When the process mo del was done, there we re 21 MSL rules need ed to describe the system.

The second case study addressed part o f the software maintenance process for AT&T\s 5ESS switchin g software. Un like the first case study, whe re the goal was p ro- cess improvement, the second study aimed o nly to d ocument tbe process steps and interactio ns by ca pturing them in MSL. The mo de l contained 25 classes and 26 rules.

Fo r each model, the MSL process descriptions were used to gen erate "process enact- ment environments," resulting in a database po pulated with instanoes o f the information mode l's classes. The n, researche rs simulated several scenarios to verify that the models pe rformed as expected. During the simulation, they collected timing and resource utiliza- tion dana, pro viding the basis for analyzing likely process performance. By ch anging the rules and executing a scenario re peatedly, the timings were compared and contrasted , leading to significant process improve ment without majo r investment in resources.

The mo de ling and simulatio n e xe rcises were useful for earl y problem identifica- tion and resolutio n. Fo r example, the software m aintenan ce process d efinition uncov- e red three types o f problems with the existing p rocess docume n tatio n: m1ssing t ask inputs a nd ou tputs, ambiguo us input and o utput crite ria, and ine fficiency in the process d efinitio n. The signaling fault mo del simulation d iscove red ine ffic iencies in the sepa- rate descriptio ns o f the workcenters.

Bargho uti and his colleagues no te the impo rtance of dividing the process mo del- ing problem into two pieces: mo deling the information and mo deling the beh avio r. By separating these concerns, the resulting mode l is clear and concise. They also point out that compute r-inte nsive activities are mo re easil y modeled than human-inte nsive o nes, a lesson no ted by C urtis and bis colle agues, too.

Desirable Properties of Process Modeling Tools and Techniques

There a re many process mo deling tools a nd techniques, and researchers continue to wo rk to de te rmine which ones are most appropriate for a given situ atio n. But there are some characteristics that are helpful, regardless o f technique. Curtis, Kellner, a nd Over (1992) h ave ide ntified five categories of desira ble properties:

1. Facilitates human understand ing and communication. The techn ique should be a ble to re present t he process in a fo rm tha t most custo me rs and d evelo pers ca n unde rstand, e ncouraging communication about the process and agreement on its form and improve ments. The technique sho uld include su fficient info rmation to allow one o r mo re people to actually perform the process. And the model o r !tool should form a basis fo r training.

2. Supports process improvement. The technique sho uld identify the essen tial compo- ne nts of a develo pment or maintenance process. It should allo w reuse of processes

Openmirrors.com

Section 2.5 Information Systems Example 73

or subprocesses o n subsequent projects, compare alternatives, and estimate the impact o f changes before the process is actuallly put into practice. Similarly, tbe tech- nique should assist in selecting tools and techniques for the process, in encouraging organizational learning, and in supporting continuing evolution of the process.

3. Supports process managem ent. The technique should alJow the process to be project-specific. Then, de ve lopers and custo mers should be a ble to reason abo ut attributes o f software creation o r e volution. The technique should also support planning and fo recasting, monito ring and managing the process, and measuring key process characteristics.

4. Provides automated guidance in. perfo rmin g the process. The technique should de fine all or part o f the software development environmen t, provide guidance and suggestions, and re tain reusa ble process representatio ns for later use.

5. Su pports automated process execution. The technique should auto ma te all o r part o f the process, suppo rt coope rative wo rk, capture relevant measure ment d ata, and enfo rce rules to ensure process integrity.

These characte ristics can act as useful guide lines for selecting a p rocess mode ling technique fo r your deve lopme nt project. Item 4 is especially impo rtant if your organi- za tion is atte mpting to st andardize its process; tools ca n help prompt develop ers abo ut what to do next and provide gateways and checkpoints to assure that an artifact meets ce rtain standards b efore the next ste ps are take n. For example, a tool can check a set of code compone nts, evaluating their size and structure. If size or strncture exceeds pre- de fined limits, the deve lope rs can be notified before testing begins, and some compo- ne nts may be revie wed and perhaps redesigned.

2.5 INFORMATION SYSTEMS EXAMPLE

Let us con side r which de velopment process to use for supporting our informatio n sys- te m exa mple, the Piccadilly Te levision advertising program. Recall that there are m any constraints on what kinds of advertising can be sold when , and that the regul atio ns may change with rulings by the Adve rtising Standards Autho rity and o ther regulatory bodies. 'fhus, we want to build a software system that is easil y maintaine d and changed. There is even a p ossibility that th e constraints may chan ge as we are building the system.

The wa te rfall mod e l may be too rigid for o ur system, since it permits little flexi- bility afte r the requirements analysis stage is complete . Prototyping may be useful for building the user inte rface, so we may want to include some kind o f prototyping in our mode l. But most of tbe uncertainty Lies in the adv,ertising regula tions and business con - stra ints.. We want to use a process model th at can be used and reused as the system e vo lves. A vari ati o n o f the spira l mode l may be a good candida te for building the Pic- cadilly syste m, because it e ncourages us to revisit our assumption s, ana lyze our risks, and proto type vario us syste m characte ristics. The repeated evaluation o f alternatives, sh own in the uppe r-left-hand quadrant of the spiral, helps us build flexibility into our requirem e nts and design.

Boe hm's representatio n of the spiral is high -level, without en ough detail to direct the actio ns o f analysts, d esigners, code rs, and testers. H owe ver, tlbere are many tech- niques a nd tools fo r re presenting the process mod el at fi ner levels of detail. The cho ice

74 Chapter 2 Modeling the Process and Life Cycle

of technique or tool depends in part o n personal preference and experience, and in part o n suitability for the type of process being re presented. Let us see how Lai 's notation might b e used to represent part of the Piccadilly system 's development process.

Because we want to use the spiral model to he lp us manage risk , we must include a characte rization of "risk" in our process model. That is, risk is an artifact that we must describe, so we can me asure and track risk in each iteration of our spiral. Each pote ntial problem has an associated risk, and we can think of the risk in terms of two facets: prob- ability and severity. Probability is the like lihood that a particular problem will occur, and severity is the impact it will have o n the system. For example, suppose we are con- sidering the proble m of insufficient training in the development method being used to build the Piccadilly system. We may decide to use an object-oriented approach , but we may find that the develope rs assigned to the project have littJe or no experie nce in object o rientation. This problem may have a low probabiLity of occurring, since all new e mployees are sent to an in tensive, four-week course on object-oriented development. On the other hand, should the problem actually occur, it would have a severe impac!L on the ability of the development team to finish the software within the assigned schedule. Thus, the probability of occurrence is low, but the severity is large.

We can represent these risk situations in a Lai artifact table, shown in Table 2.2. H e re, risk is the artifact, with subartifacts probability and severity. For simplicity, we

TABLE 2.2 Artifact D efinition Form for Artifact " Risk "

Name Risk ( ProblemX)

Synopsis process This is the anifacl that represents tire risk that problem X will occur and have a negative a/feel on some aspect of tire development process.

Complexity type Composite

Data type (risk_s, user_defined)

Artifact-state list

low ((state of(probability.x) '"' low) Probability of problem is low, severity (stau_of(severity.x) -- small) problem impact is small.

lriglr-medi11m. ((stare of(probability.x) = low) Probability of problem is low, severity (stau_of (severity.x) -- large)) problem impact is large.

low-111edi.11m ((State of(probabilily.x) = high) Probability of problem is high, severity (stau_of(severily.x) = small)) problem impact is small.

high ((state of(probability.x) = high ) Probability of problem is high, severity (staJe_of(severily.x) = large)) problem impact is large.

Subartifact list

probability.x Tire probability that problem X will occur.

severity.x Tire severity of tire impact slro11/d problem X occ.11r on the project.

Openmirrors.com

Section 2.6 Real-Time Example 75

bave chosen only two states for each subartifact: low and high for probability, and srnaU and large for seve rity. I n fact, each of the subartifacts can have a large range of states (sucb as extremely small, very small, somewhat small, medium, somewhat higb, very high , extremely high), leading to many different states for the artifact itself.

In the same way, we can define the other aspects of our development process and use diagrams to iUustrate the activities and their interconnections. Modeling the pro- cess in this way has ma ny advantages, not the Least of which is buiJding a common unde rstanding of what d eve lopment will entail. If use rs, customers, and developers p ar- tkipate in de fining and de picting Piccadilly's d evelopment process, each will have expectations about what activities are involved, what they produce, and when e ach product can be expected. In particular, the combinatio n of spiral model and risk table can be u sed to evaluate the risks p eriodically. With each revolution around the s piral, the probability and seve rity of each ris k can be r evisited and restated; when ris ks are unacceptably high, the process mode l can be re vised to include risk mitigation and red uctio n techniques, as we wiU see in Chapter 3.

2.6 REAL-TIME EXAMPLE

The Ariane-5 software invo lved the re use of software from Ariane-4. R euse was inte nded to re duce risk , increase productivity, and increase quality. Thus, any process mode l for developing new Ariane software shoulld include reuse activities. I n particu- lar, the process mode l must include activities to check the quality of re usable compo- ne nts, wilh safeguards to make s ure that the re used softwa re works properly within the context of the design of the new system.

Such a process model might look like the simplified mode l of Figure 2.17. The boxes in tbe mode l represent activities. 1be arrows entering the box from the left are resourc es, and those leaving on the right are outputs. Those en te ring from the top are controls or constraints, such as schedules, budgets, or standards. And those entering from below are mechanisms that assist in performing the activity, such as tools, data- bases, o r techniques.

The Ariane-4 re use process begins with the software's mi ssion , namely, control- ling a new rocke t, as well as software from previo us airframes, unmet needs, and other software compone nts available from other sources (such as purchase d softwa re or reuse re posito ries from othe r proj ects). Based on the business strategy of the aerospace builder, the develope rs can ide ntify reusable subprocesses, describe them (perhaps with annotations re lated to past experience), and place them in a library for considera- tion by the require me nts analysts. The reusable processes wiU often involve reusa ble compo ne nts ( i.e., re usable requfreme nts, design or code compone rnts, o r even test cases, process desc ripti ons, and othe r docume nts and artifacts).

Next, the require me nts ana lysts examine the requireme nts fo r the new airframe and the reusable compo nents that are available in the library. They produce a revised set of require ments, consisting of a mix of new and reused requirements. Then, the designe rs use those requireme nts to design the software. Once their design is complete, they evaluate all reused design components to certify that they ar'e correct and consis- te nt with the new parts of the design and the overall inte ntio n of the syste m as described in the require me nts. Finally, the certi fied components are used to build or

76 Chapter 2 Modeling the Process and Life Cycle

Business strategies

(Chan,ing) ~ I Missions I Rem bl

Software lrom previous Identify reusable

Subproees:ses Describe

e SIS subproces

- ai rlrame - subprocesses sub- -- process 1

Reusable an~ unreusable - eomponants t

Unmet domain needs Experience base

L Populate R equiremtnts Reviud requirements for new airframe Requirements domain -

analysis library

- Pot•ntia I rtusable

components

Evaluate Buil4 or Design Design _ and certify Certified components

airframe selecttd - change i--- - software so'1vlare reusable

Software

components

FIGURE 2.17 Reuse process model for new airframe software.

change the software and produce the final system. As we will see in late r chapters, such a process might have prevented the destruction of Ariane-5.

2.7 WHAT THIS CHAPTER MEANS FOR YOU

lo this c hapter, we have seen that the software de velopment process involves activities, reso urces, and products. A process model is useful for guiding your behavior whe n you are working with a group. De tailed process models tell you how to coordinate and col- labo rate with your co lle agues as you design and build a system. We have also seen that process models include organizational, functional , behavioral, and other perspectives, so you can focus o n particular aspects of the development process to enhance your understanding or guide your actions.

2.8 WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM

A process model has clear advantages for your development team, too. A good model shows each team member which activities occur when, and by whom ,so that the division of duties is clear. In addition, the project manager can use process tools to enact the pro- cess, simulating activities and tracking resources to dete rmine the best mix of people and activities in o rde r to meet the project's budget and schedule. This simulation is done before resources are actually committed, so time and money are saved by not having to

Openmirrors.com

Section 2.11 Key References 77

backtrack o r correct mistakes. Indeed, iteration and incremen tal development can be included in the process model, so the team can learn fro m proto typing or react to evolv- ing require ments and still meet the appropriate deadlines.

2.9 WHAT THIS CHAPTER MEANS FOR RESEARCHERS

Process. modeling is a r1ch field of research interest in software engineering. Many soft- wa re developers fee l that, by using a good process, the quality of the products of develop- ment can be guaranteed. Thus, there are severaJ areas into which researche rs are looking:

• Process notations: H ow to write down the process in a way that is understandable to those who must ca rry it out

• Process models: H ow to de pict the p rocess, using an appropriate set of activi ties, resources, products, and tools

• Process modeling support tools: H ow to enact or simulate a process mode l, so t hat resource avai la biLity, usage, and performance can be assessed

• Process measurem ent and assessment: H ow to determine which activi ties, reso urces, su bprocesses, and model types are best for p roducing high -quality products in a specified time or e nvironment

Ma ny o f these efforts are coordinated with process improvement research , an a rea we will investigate in C ha pter 13.

2.10 TERM PROJECT

It is early in the deve lopme nt process o f the Loan Arranger syste m for FCO. Yo u do no t ye t have a compreh ensive set o f requirements fo r the system. All you have is an overview o f system functi onaLity, and a sense o f bow the system will be used to s upport F CO's b usiness. Ma ny of the terms used in the overvie w are unfamiLiar to you, so you have as ked the cus tomer re presentatives to pre pare a glossary. They give you the descript ion in Table 2.3.

This info rmation c larifies some concepts for you , but you are still fa r from having a good se t o f require me nts. Nevertheless, you can make some preliminary decisions a bout how the develo pment should proceed. Review the processes presented in this chapte r and determine which o nes might be appropriate fo r developing the Loan Arranger. Fo r each process, make a li st o f its advantages and disad va ntages with respect to the Loan Arra nger.

2.11 KEY REFERENCES

As a result o f the FUth Internatio nal Software Process Workshop, a working group chaired by Ke llner formuJated a s tandard problem, to be used to evaluate and compare som e of the mo re popular p rocess modeling techniques. The problem was designed to be complex eno ugh so that it would test a technique's ability to include each of the following:

• multiple le ve ls o f abstraction

• control flow, seque ncing, and constraints on sequencing

78 Chapt e r 2 Modeling t he Process and Life Cycle

TABLE 2.3 G lossary of Terms for the Loan Arranger

Borro wer. A borrower is the recipient of money from a lender. Borrowers may receive loans jointly; that is, each loan may have multiple borrowers. Each borrower has an associated name and a unique borrower identification number.

Borrower's risk: The risk factor associated with any borrower is based on the borrower's payment history. A borrower with no loans outstanding is assigned a nominal borrower's risk factor of 50. The risk factor decreases when the borrower makes payments on time but increases when a borrower makes a payment late or default s on a loan. The borrower's risk is calculated using the following forroula:

Risk= 50 - (10 x (numberofyearsofloansingoodstanding)] + [20 x (number of years of loans in late standing)] + (30 x (nwnber of years of loans in default standing)]

For example, a borrower may have three loans. The first loan was taken out two years ago, and all payments have been made on time. That loan is in good standing and has been so for two years. The second and third loans are four and five years old, respectively, and each one was in good standing until recently. Thus, each of the two late-standing loans has been in late standing only for one year. Thus, the risk is

50 - [10 x 2) + (20 x {l + l}] + (30 x OJ = 70.

The maximum risk value is 100, and the minimum risk value is 1.

Bundle: A bundle is a collect ion of loans that has been associated for sale as a single wlit to an investor. Associated with each bundle is the total value of loans in the bw1dle, the period of rime over which the loans in the bundle are active (i.e., for which borrowers are still making payments on the loans), an estimate of the risk involved in purchasing the bundle, and the profit to be made when all loans are paid back by the borrowers.

Bundle rtsk: The risk of a loan bundle is the weighted average of the risks of the loans in the bw1dle, with each loan's risk (see loan risk, below) weighted according to th at loan's value. To calculate the weighted average over 11 loans. assume that each loan Uhas remaining principal Pi and loan risk Ri. The weighted average is then

n

'L,PiRi 1~1

n

'L,Pi 1- 1

Discount: The discount is the price at which FCO is willing to sell a loan to an investor. It is calculated according to the formula

Discoun t = (principal r emaining) x [(interest rate) x (0.2 + (.005 x {101 - (loan risk))))] Interest rate ty pe: An interest rate on a loan is either fixed or adjustable. A fixed-rate loan (called an FM) has the same interest rate for the term of the mortgage. An adjustable rate loan (called an ARM) has a rate that changes each year, based on a government index supplied by the U.S. D epartment or the Treasury.

Investor. An investor is a person or organization that is inter ested in purchasing a bundle of loans from FCO.

lm•estment req uest: An investor makes an investment request,specifying a maximum degree of risk at which the investment will be made, the minimum amount of profit required in a bundle, and the maximum period of time over which the loans in the bundle must be paid.

Le nder. A lender is an institution that makes loans to borrowers. A lender can have zero, one, or many loans.

Le nder info rmatio n: Lender information is descriptive data that are imported from o utside the application. Lender information cannot be changed or deleted. The following information is associated with each lender: lender name (institution), lender contact (person at that institution) , phone number for contact, a Wlique lender ident ification number. Once added to the system, a lender entry can be edited but not removed.

(continues)

Openmirrors.com

Section 2.1 1 Key References 79

TABLE 2.3 (continued)

Lending Institution: A synonym for lender. See lender.

Loan: A loan is a set of information that describes a home loan and the borrower-identifying information associated with the Joan. The following information ii; associated with each loan: loan amount , interest rate. interest rate type (adjustable or fixed), settlement dat.e (the date the borrower originally borrowed the money from the lender), term (expressed as number of years), borrower, lender, loan type Qu.mbo or regular), and property (identified by the address of the property). A loan must have exactly one associated lender and exactly one associated borrower. In addition, each loan is identified with a loan risk and a loan status.

Loan analyst: The loan analyst is a professional employee of FCO who is trained in using tile Loan Arranger system to manage and bundle l oans. Loan analysts are familiar with the terminology of loans and lending, but they may not have all the relevant information at hand with which to evaluate a single loan or collection of loans.

Loan rlsl.:: Each loan is associated witll a level of risk, indicated by an integer from 1 to 100. 1 represents the lowest-risk loan.; that is, it is unlikely that the borrower will be late or default on this loan. 100 represents the highest risk; that is, it is almost certain that the borrower will default on this loan.

Loan stntus: A loan can have one of three status designations: good, late, o r default. A loan is in good status if the borrower has made all payments up to the current time. A loan is in late status if the borrower's last payment was made but not by the payment due dat.e. A loan is in default status if the borrower's last payment was not re<:eived within 10 days of the due date.

Loan type: A loan is either a jumbo mortgage, where the property is valued in excess of $275,000, or a regular mortgage, where the property value is $275,000 or less.

Portfolio: The collection of loans purchased by FCO and available for inclusion in a bundle. The repository maintained by the Loan Arranger contains information about all of the loans in the portfolio ..

• decision points • iteration and feedback to earlier steps • user creativity

• object and information management, as weU as ftow through the process • object structure, attributes, and interrelationships • organizational respon sibility for specific tasks

• physical communication mechanisms for information transfer • process measurements

• temporal aspects (both absolute and relative) • tasks executed by humans • professiona l judgment or discretion

• connection to narrative explanations • tasks invoked or executed by a tool

• resource constraints and allocation, schedule determination • process modification and improvement • multiple levels of aggregation and parallelism

80 Chapter 2 Modeling the Process and Life Cycle

Eighteen different process modeling techniques were applied to tbe common problem, and varying degrees of sa tisfaction were found with each one. The results are reported in KeUner and Rombach (1990).

Curtis, Kellne r, and O ver (1992) present a compre hensive survey of process mod- e ling techniques and tools. The paper a lso summarizes basic language types and con- structs and gives examples of process modeling approaches that use those language types.

Krasner et al. (1992) describe lessons lea rned whe n impleme nting a software pro- cess mode ling syste m in a commercial e nvironment.

Several Web sites contain information about process mode ling.

• The U.S. Software Engineering Instilute (SEI) continues to investigate process mode ling as part of its process improvement efforts. A list of its technical reports and activities can be found at http://www.sei.cmu.edu. The information at http:// www.sei.cmu.edu/coUaborating/spins/ d escribes Software Process Improvement Netwo rks, geographically-based groups of people interested in process improve- ment who often meet to hear speakers o r discuss process-re lated issues.

• The E uropean Community has long sponso red research in process modeling and a process model language. Descriptions of c urrent research projects are avail able at h ttp://cordis.europa.eu/fp7 /projects_e n.h1tml.

• The Data and A n alysis Centre for Software Engineering maintains a list of resources about software process at https://www.thedacs.com/d ata bases/url/key/39.

More information about Lai no tation is available in David We iss and Robert Lai's book, Software P roduct Line Engineering: A Family-based Software Develop- ment Process (Weiss and Lai 1999).

lbe University of Southern california's Cente r for Software Engineering has deve loped a tool to assist you in selecting a process mode l suitable for your project's requirem e nts and constraints. It can be ftp-ed fro m ftp://usc.edu/pub/soft_engineering/ de mos/prnsa.zip, and mo re information can be fo und on the Ce nter's Web site: http:// sunset.usc.edu.

Jo urnals such as Software Process-Improvement and Practice have a rticles addressing the role of process mode ling in so ftware development and mainte nance. They also re po rt the hig hJights of relevant co nferences, such as the Inte rnational Soft- ware Process Workshop and the International Confe re nce on Software Engineering. The July/August 2000 issue of IEEE Software focuses on process diversity and has sev- e ral articles about the success of a process maturi ty approach to software development.

There are many resources available fo r learning about agile methods. The Agile Manifesto is posted at http://www.agilealliance.org. Kent Beck's (1999) is the seminal book on extre me programming, and Alistair Cockburn (2002) d escribes the Crystal famiJy o f me thodologies. Martin Beck (1999) explains refactoring, which is one of the most difficult steps of XP. Two e xce llent refe rences on agile me thods are Robert C. Martin's (2003) book on agile software development, and Daniel H. Steinberg and D a nie l W. Palmer's (2004) book o n extreme softwa re engineering. Two Web sites providing additional information abo ut extre me programming are http://www. xprgramming.com and http://www.extremeprogramming.o rg.

Openmirrors.com

Sectio n 2. 12 Exercises 81

2.12 EXERCISES

1. H ow does the description of a system relate to the notion of process models? Fo r e xample, how do you decide what the boundary should be for the system describe d by a process mode l?

2. For each of the process models described in this chapter, what a re the be nefits and draw- backs of using the model?

3. For each of the process models described in this chapter, bow does the mode l ha ndle a significant change in requirements late in development?

4. Draw a diagra m to capture the process of buying an airplane ticket for a business trip. S. Draw a Lai arti fact t able to define a module. M ake sure that you include arti fact states

that show the module when it is untested , partia lly tested, and completely tested . 6. Using the not ation of your choice, draw a process diagram o f a software develo pment

process that prototypes three diffe rent designs and choose the best from among them. 7. Examine the characteristics of good process mo dels described in Sectio n 2.4. Which char-

acteristics are essential for processes to be used on projects where the problem and solu- tion ar e not well understood?

8. In this chapte r, we suggested that software deve lopment is a creatio n process, not a manu- facturing process. Discuss the characteristics o f manufacturing t hat a pply to software d evelopment a nd explain which characteristics of software development are mo re like a creative e ndeavor.

9. Sho uld a develo pment o rganization adopt a single process mo del for all of its softwa re d evelopment? Discuss the pros and cons.

10. Suppose your contract with a customer specifies that you use a particular software devel- o pment process. H o w can the work be monitore d to e nforce the use of this process?

11. Conside r the processes introduced in this chapter. Which ones give you the most flex- ibility to change in reaction to changing require ments?

12. Suppose A malgama ted , Inc., requires you to use a given process model when it cont racts with you to build a system. You compl y, building software using the prescribed activities, resources, and const raints. After the software is d elivered and installed ,your system expe- riences a catastrophic failure. When Am algamated investigates th.e source of the fai!ure, you are accused of n ot having done code re views that would have found the source ot the proble m before delivery. You respond that code reviews we re not in the required process. W hat are the legal a nd ethical issues involve d in this dispute?

3

In this chapter, we look at • tracking project progress • project personnel and organization • effort and schedule estimation • risk management • using process modeling with project

planning

As we saw in the previous chapte rs, the software development cycle includes many ste ps, some of which are repeated until the system is complete and tbe customers and users are satisfied. However, before committing funds for a software develo pment or maintenance project, a custome r usuaUy wants an estimate of how much the project wiU cost and how lo ng the project wiU take. This chapte r examines the activities neces- sary to p lan and manage a software development project.

3.1 TRACKING PROGRESS

82

Software is useful only if it pe rforms a desired function or provides a needed service. Thus, a typical projec t begins when a customer approaches you to discuss a perceived need. For example, a large national bank ma y ask you for help in bujlding an informa- tion system that al lows the bank's clients to access tbeir account information, no matte r where i_n the world the clients are. Or you may be contacte d by marine biologists who would Like a system to connect with their water-morutoring equipment and perform statistical analyses of the data gathe red. Usually, customers have several questions to be answered:

• Do you unde rstand my proble m and my needs? • Can you design a system that will solve my problem or satisfy my needs? • H ow lo ng will it take you to develop such a "System? • H ow much wiU it cost to have you develop such a system?

Openmirrors.com

Section 3.1 Tracking Progress 83

Answe ring the last two questions requires a weU-thought-out project schedule. A project schedule describes the software development cycle for a particula r project by e numerating the phases or stages of the project and breaking each into discrete tasks o r activities to be done. Tue schedule also portrays the inter actio ns among these activities a nd estima tes the time that each task or acti vity will take. Thus, the schedule is a time- Line that shows whe n activities will begin and end , and wben the related develo pment products will be ready.

In Chapte r 1, we learned that a systems approach invo lves both analysis and syn- thesis: breaking the problem into its compone nt pa rts, devising a solution fo r each part, and then putting the pieces togethe r to form a coherent whole. We can use this approach to de te rmine the project schedule. We begin by working wi th custome rs and potential users to unde rstand what they want and need. A t the same time, we make sure that they a re comfo rta ble with our knowledge of their needs. We List a u p roject de livera bles, that is, the items that the customer expects to see during project de velop- ment. Amo ng the de l.ive rables may be

• docume nts

• de monstra tions of function • de monstra ti ons of subsyste ms • de monstrations of accuracy • de monstrations of reliability, security, or pe rformance

Next, we dete rmine what activities must take place in o rde r to produce these de liverables. We may use some of the process mod eling techniques we le arned in Chapter 2, laying out exactly what must happen and which activities de pe nd o n o ther activities, products, or resources. Ce rtain events are designated to be milesto nes, indi- cating to us a nd our custome rs t!hat a measurable level of progress bas been made. For e xample, when the require ments are documente d, inspec ted for consistency and com- pleteness, and turne d over to the design team , the requirements specification may be a project milesto ne. Similarly, mi lestones ma y include the completio n of the user's man - ua l, the pe rforma nce of a given set of calculati ons, or a d emonstration of the system's ability to communicate with another system.

In our analysis of the project, we must distinguish clearly between milestones and activities. An activity is a part o f the project that takes place ove r a pe riod of time, whereas a milestone is the completion of an activity-a particular point in time. Thus, an activity has a beginning and an end, whereas a mileston e is the end of a specially des- ignated activity. For example, the customer may want the system to be accompan.ied by an online operator tutorial. The development of the tutorial and its asso ciate d pro- grams is an activity; it culminates in the demonstratio n o f those functions to the cus- tomer: the milestone.

By e xamining the project care fuJl y in this wa y, we can separate development into a successio n o f phases. Each phase is composed of steps, and each step can be subdi - vided furthe r if n ecessary, as shown in Figure 3.1.

To see bow this analysis works, consider the phases, steps, and activities of Table 3.1, which describes the building o f a house. First, we consider two phases: landscaping the lo t and building the house itself. The n, we brea k each phase into smalle r s teps, such as

84 Chapter 3 Planning and Managing t he Project

FIGURE 3.1 Phases, steps, an:d activities in a project.

PROJECT

PHASE I

/STEPI PHASE 2 L..__ STEP 2

/ STEP I PHASE n ..:::::._STEP 2

ACTIVITY 2.1 ACTIVITY 2.2 ACTIVITY 3.3

clearing and grubbing, seeding the turf, and plant£ng trees and shrubs. Whe re necessary, we can divide the steps into activities; for example, finishing the inte rior involves com- ple ting the inte rior plumbing, interior electrical work, wallboard, interior painting, floor coverin g, doors, and fixtures. Each activity is a measura ble event and we have objective criteria to determine whe n the activity is complete . Thus, any activity's end can be a mile - sto ne, a nd Ta ble 3.2 lists the milestones for phase 2.

This analytical breakdown gives us a nd o ur custo me rs an idea of wh at is involved in constructing a house. Simil arly, analyzing a software develo pme nt o r mainte nance project and identi fying the phases, ste ps, a nd activ ities, bo th we and our customers have a bette:r grasp of what is involved in building and maintaining a system. We saw in C hapte r 2 that a process model provides a high-level vie w o f the phases and ste ps, so process mode ling is a u seful way to begin ana lyzing the project. In later chapte rs., we wiU see tha t the maj or p hases, such as requir ements e ngineering, imple mentation , or testing, involve many activities, each o f which contributes to product or process quali ty.

Work Breakdown and Activity Graphs

Ana lysis o f this kind is sometimes d escribed as gene rating a work breakdO\m structure for a give n project, because it depicts the project as a set of discrete pieces o f wo rk. No tice that the activities and milesto nes are ite ms that bo th customer and develo per can use to track developmen t or main te nance. At any point in the process, the cust ome r may wa nt to fo Uow our progress. We d evelope rs can point to activities, indicating what wo rk is unde r way, and to milesto nes, indicati ng what work has been completed . H ow- eve r, a p roject's wo rk breakdown structure gives no indica tion o f the interdepende nce of the work units or of the parts o f the project tha t can be develo pe d concurrently.

We can describe ea ch activity with fo ur pa ramete rs: the precursor, duratio n, due date, and endpoint A precursor is an event or set of events that must occur before the activity can begin; it describes the set o f conditions that allows the activity to begin. The duration is the length o f time needed to complete the activity. The due date is. the d ate by which the activity must be completed , freque ntly dete rmined by contractual deadlines. Sign ifying that the activity bas e nded , the endpoint is usually a milestone o r

Openmirrors.com

Sectio n 3 .1 Tracking Progress 85

TA BLE 3.1 Phases,Steps,andActivitiesof B uildinga H ouse

Phase 1: Landscaping the Lot Phase 2: Building the H ouse

Step 1.1: Step2.l: Clearing Prepare a11d the site grnbbi11g

Activity 1.1.l: Remove trees Activity 2.1.1: Survey the land

Activity 1.1.2: Remove stumps Activity2.1.2: Request permits

Step 1.2: Activity 2.1.3: Excavate for the foundation Seeding the turf

Activity 1.2.1: Aerat e the soil Activity 2.1.4: Buy materials

Activity 1.2.2: D isperse the seeds Step2.2: B<4ildi11g the exterior

Activity 1.2.3: Water and weed Activity 2.2.1: Lay the foundation

Step 1.3: Activity 2.2.2: Build the outside walls Pla11ti11g shmbsa11d trees

Activity 1.3.l: Obtain shrubs and trees Activity 2.2.3: Install exterior plumbing

Activity 1.3.2: Dig holes Activity 2.2.4: Exterior electrical work

Activity 1.3.3: Plant shrubs and trees Activity 2.2.5: Exterior siding

Activity 1.3.4: Anchor the trees and mulch Activity 2.2.6: Paint the exterior around them

Activity2.2.7: Install doors and fixtures

Activity 2.2.8: Install roof

Step 2.3: Fi11islri11g rhe imerior

Activity 2.3.1: Install the interior plumbing

Activity 2.3.2: Install interior electrical work

Activity2.3.3: Install wallboard

Acrivity2.3.4: Paint the interior

Activity 2.3.5: Install lloor covering

Activity 2 .3.6: Install doors and fixtures

86 Chapter 3 Planning and Managing the Project

TABLE 3.2 Milestones in Building a House

l.l. Survey complete 1.2. Penni ts issued 1.3. Excavation complete 1.4. Materials on hand 2.1. Foundation laid 2.2. Outside waUs complete 2.3. Exterior plumbing complete 2.4. Exterior electrical work complete 2.5. Exterior siding complete 2.6. Exterior painting complete 2.7. D oors and fixtures mounted 2.8. R oof complete 3.1. Interior plumbing complete 3.2. Interior electrical work complete 3.3. Wallboard in place 3.4. Interior painting complete 3.5. Floor covering laid 3.6. D oors and fixtures mounted

deliverable. We can illustrate the relationships among activities by using these parame- ters. In particular, we calll draw an activity graph tlo depict the dependencies; the nodes of the graph are the project milesto nes, and the Lines Linking the nodes represent the activities involved. Figure 3.2 is an activity graph for the work described in phase 2 of Table 3..1.

Install exterior electrical Install exterior siding

Paint exterior

Install exterior doors and fixtures

Install exterior plumb in!

Surveying

Excmtion

Buy materials

l ay loandation

Build 0<1t~ide wall

Install interior plumbing Install interior electrical 3.2

3.3 Paint interior

Install wallboard

interior doors and lixturu

FIGURE 3.2 Activity graph for building a house.

Openmirrors.com

Section 3.1 Tracking Progress 87

Many impo rta nt characte ristics of the project a re made visible by the activity graph. For example, it is. clear fro m Figure 3.2 tha t neithe r o f the ll:wo plwnbing acll:ivi- ties can start before milestone 2.2 is re ached; that is, 2.2 is a precursor to both inte rior and exterio r plumbing. Furthe rmo re, the figure sho ws us that several things cam be do ne simultaneously. Fo r instance, some of the in terio r and exte rio r activities a re inde- pe ndent (such as instaUing waUboard, connecting exterior electrical plumbing, and o the rs tieading to milesto nes 2.6 and 3.3, respectively). Tue activit.ies o n the left-hand pa th do no t depend o n t hose o n the right fo r the ir initiation, so they can be wo rk ed on concurrently. Notice thai t the re is a dashed line from requesting pe rmits (node 1.2) to surveying (node 1.1). This Line indicates that these activities must lbe completed before e xcavatio n (the activity leading to mi lesto ne 1.3) can begin. However,since the re is no rea l activity that occurs after reaching milestone ll.2 in o rder to get to milestone 1.1, the d ashed line indica tes a re latio nship without an accompanying activity.

It is impo rtant to realize that activity graphs depend on an understanding o f the parallel na ture o f tasks. If wo rk canno t be do ne in parallel, the n the (mostly straight) graph is no t use ful in depicting ho w tasks will be coordinated. Mo reover, the graphs must re flect a realistic de pictio n o f the parallelism. In o ur ho use-buildi ng example, it is clear that some o f the tasks, like plumbing, will be done by different people from those do ing o the r tasks, like electrical work. But on software development projects, where some people have many skills, the theoretical pa rallelism may not reflect reality. A restricted number o f people assigned to the project may resul t in the same person doin g many things in series, e ven tho ugh they could be done in parallel by a larger development team.

Estimating Completion

We can make a n activity graph mo re useful by adding to it information abo ut the estimated time it will ta ke to complete each activity. Fo r a given a ctivity, we label the corresponding edge o f the graph with the estima te. For example, for the activities in phase 2 o f Ta ble 2.1, we can append to the activity graph of Figure 3.2 estimates o f the number o f days it will ta ke to complete each activity. Ta ble 3.3 contains the estimates for each activity.

The result is the graph shown in Figure 3.3. Notice that milestones 2.7, 2.8, 3.4, and 3.6 are p recursors to the finish. Tha t is, these milestones must a ll be reached in o rde r to conside r the project complete. The zeros o n the links fro m those no des to the finish show that no additional time is needed. There is also an implicit zero o n the Link from no de 1.2 to1.1,since no additio nal time is accrued on the dashed link.

This graphical depiction o f the project tells us a lot about the proj ect's schedule. Fo r example, since we estimated that the first activity would take 3 days to complete, we ca nno t h o pe to reach milesto ne 1.1 be fore the e nd o f day 3. Similarly, we canno t re ach milestone 1.2 before the e nd of day 15. Beca use the beginning of e xcav ation (activity 1.3) canno t begin until milestones 1.1 and 1.2 a re both reached , e xcavation caillflot begin until the beginn ing o f day 16.

Analyzing the paths among the milestones of a project in this way is called the Critical Path Metho d (CPM). The pa ths can show us the minimum a mo unt of time it will take to complete the project, given o ur estimates o f each activity's duration. Mo reove r, CPM reveals those activities that a re most critica l to completing the project on time.

88 Chapter 3 Planning and Managing the Project

TABLE 3.3 Activities andTime Estimates

Activity Tune Estimate (in Days)

Step 1: Prepare tire site

Activity 1.1: Survey the land 3

Activity 1.2: R equest permits 15

Activity 1.3: Excavate for the foundation 10

Activity 1.4: Buy materials 10

Step 2: Building the exterior

Activity 2.1: Lay the foundation 15

Activity 2.2: Build the outside walls 20

Activity 2.3: Install exterior plumbing 10

Activity 2.4: Install exterior electrical work 10

Activity 2.5: i nstall exterior siding 8

Activity 2.6: Paint the exterior 5

Activity 2.7: install doors and fixtures 6

Activity 2.8: install roof 9

Srep 3: Finishing rhe i111erior

Activity 3.1: Install interior plumbing 12

Activity 3.2: install interior e lectrical work 15

Activity 3.3: install wallboard 9

Activity 3.4: Paint the interior 18

Activity 3.5: i nstall floor covering 11

Activity 3.6: install doors and fixtures 7

To see how CPM works, con sider again our house-buildin.g example. First, we notice that the activities leading to milestones 1.1 (surveying) and 1.2 (requesting p er- mits) can occm concurrently. Since excavation (the activity culminaHng in milestone 1.3) cannot begin until day 16, surve ying bas 15 days in which to be completed, even tho ugh it is o nly 3 days in duration. Thus, surveying has 15 days of available time, bu t requires only 3 days of real time. Io the same way, for each activity in our graph, we can compute a pair of times: rea l time and available time. The real time or actual time for an activity is the estimated amount of time required for the activity to be completed, and the ava ilable time is the amount of time available in the schedule for the activity's com- ple tion. Slack time o r float for an activity is the differe nce between the avaiJable t ime and the real time fo r that activity:

Slack time = available time - real time

Openmirrors.com

3

10

10

1S

20

10

8

6

Section 3.1 Tracking Progress 89

FIGURE 3.3 Activity graph with durations.

Ano the r way of looking at slack time is to com pa re the earliest time ao activity may begin with the latest time the activity may begin witho ut delaying the project. Fo r e xample, surveying may begin o n day 1, so the ea rliest start time is day 1. Howeve r, because it will take 15 days to re quest and receive penni ts, surveying can begi n as late as day 13 and still no t hold up the proj ect schedule. Therefore,

Slack time = latest start time - earliest start time

L et us compute the slack for our example's activities to see what it te lls us abo ut the proj ect schedule. We compute slack by examining aJJ path s from the start to the fi nish. As we ha ve see n , it must take 15 days to comp lete milestones 1.1 and 1.2. An additional 55 days are used in comple ting mil estones 1.3, 1.4, 2.1, and 2.2. At this poi_nt, the re are fo ur possible paths to be take n:

1. Follo wing milestones 2.3 through 2.7 on the graph re quires 39 days.

2. Follo wing milestones 2.3 through 2.8 on the graph requires 42 days.

3. Follo wing milestones 3.1 through 3.4 on the graph requires 54 days. 4. Follo wing milestones 3.1 through 3.6 on the graph requires 54 days.

Because milesto nes 2.7, 2.8, 3.4, and 3.6 must be met before the project is finished , o ur sc hedule is constrained by the lo ngest p ath . As you can see fro m Figure 3.3 and our preceding ca lculatio ns, the two p aths on the right require 124 days to comple te, and the two paths on the left require fewer days. To calculate th e slack , we can work backward along the pa th to see how much slack time the re is for each activity leading to a node. First, we no te tha t the re is ze ro slack o n the lo ngest pa th. The n, we e xami ne each o f the re ma ining nodes to calcul ate the slack for the acti vities leading to them. Fo r example,

90 Chapter 3 Planning and Managing the Project

54 days are available to comple te the activities leading to milestones 2.3, 2.4, 2.5, 2.6, and 2.8, but onJy 42 days are needed to comple te these. Thus, this portio n of tbe graph has 12 days of slack. Si milarly, the p ortion of the graph for activities 2.3 thro ugh 2.7 requires o nly 39 days, so we have 15 days of slack along this route. By working fo rward tbrough the graph in th.is way, we ca n compute the ea rliest start time and slack fo r each of the activities. The n, we compute the latest start time for each activity by moving from tbe finish back through each node to the start. Table 3.4 shows the results: the slack time fo r each activity in Figure 3.3. (A t milestone 2.6, the path ca n branch to 2.7 or 2.8. The latest start times in Table 3.4 are calcul ated by using the route from 2.6 to 2.8, rathe r than from 2.6 to 2.7.)

The longest path bas a slack of zero for each of its nodes, because it is the path tbat determines wbe the r or not the project is on schedule. For this reason, it is called the critical path. Thus, the critical path is the one for which the slack at every n ode is zero. As you can see from our example, there may be more than one critical path.

TABLE 3.4 Slack 'TI me for Project Activities

Activity Earliest Start 'Time Latest Start'Time Slack

l.l 1 13 12

1.2 1 1 0

1.3 16 16 0

1.4 26 26 0

2.1 36 36 0

2.2 51 51 0

2.3 71 83 12

2.4 81 93 12

2.5 91 103 12

2.6 99 111 12

2.7 104 119 15

2.8 104 116 12

3.1 71 71 0

3.2 83 83 0

3.3 98 98 0

3.4 107 107 0

3.5 107 107 0

3.6 118 118 0

Finish 124 124 0

Openmirrors.com

Section 3.1 Tracking Prog ress 91

Since the critical path has no sl ack, ther e is no margin for er ror when performing the activities a lo ng its route.

Notice what happens when an activity on the critical path begins late (i.e ., later than its earliest start time). The late start pushes alJ subsequent critical path activities forward, forcing the m to be late , too, if there is no slack. And for activities not o n the critica l path, the subsequent acti vities may also lose slack time. Thus, the activity graph be lps us to unde rstand tbe impact of any scbedule slippage.

Conside r what happens if the activity graph has seve ral loops in it. Loops may occur whe n an activity must be repeated. Fo r instance, in our house-building example, the building insp ector may require the plumbing to be redo ne. In software development, a design inspecti on may re quire design or requirements to be respecified. The a ppear- ance of these loops may change the critical path as the loop activi ties a re exe rcised more than once. In this case, the effects on the schedule are far less easy to evaluate.

Figure 3.4 is a bar cha rt th at shows some software develo pme nt project activities, including info rmatio n about the ea rly and la te start dates; this cbart is typical of those produced by a utoma ted project management tools. The horizon tal bars re present the d uration o f eac h activity; those bars composed of asterisks indica te the c ritica l path. Activities de pic ted by dashes and Fs are not on the critical path, a nd an F represents Hoat o r slack tjme .

Critical path anaJysis of a project schedule telJs us who must wait fo r what as the proj ect is being deve loped. It also tells us which activities must be completedl o n schedule to avoid delay. This kind of analysis can be enhanced in many ways. For instance, our house-building example supposes that we know exactly bow long each activity will take. Often, this is no t tbe case. Instead, we bave o nJy an estimated duration for an activity, based on our knowledge of similar projects and events. Thus, to each activity, we can

Early Late Jan Jan Jan Jan Jan Feb Feb M Feb Deml ptlon Date Date I 8 IS 22 29 s 12 17' 24

Test of phase 1 1 Jan 98 S Feb 98 I ................ ,,* • • • •••••• •

Deline tut mes I Jan 98 8 Jan 98 ~ Write test phn 9 Ju 98 22 Jan 98 I···**** Inspect test plan 9 Jan 98 22 Jan 98 I······· I nte~ratlon tertl ng 23 Jan 98 1 Feb 98 I······ I lnterfaee testing 23 Jan 98 1 Feb 98 , __ FFFFF I

Document m ulls 23 Jan 98 1 Feb 98 1----- FFFI System testing 2 Feb 98 17 Feb 98 E········ ••• I Perlormuce tests 2 Feb 98 17 Feb 98 1-------- FFFF FFFI Confl guntlon tests 2 Feb 98 17 Feb 98 1------- FFFFFFFFI Document results 17 Feb 98 24 Feb 98 B

FIGURE 3.4 CPM bar chart.

92 Chapter 3 Planning and Managing the Project

assign a probable duration according to some probability distributio n, so that each activ- ity has associated with it an expected value and a variance. In other words, inste ad of knowing an exact duratio n, we estimate a window or interval in which the actual time is like ly to fall. The expecte d value is a point within the interval, and the variance descriibes the width o f the interval. Yo u may be familiar WEth a standard pro bability distribut ion called a no rmal distribution, whose graph is a be ll-sh aped curve. The Program E valuation and Review Technique (PERl) is a popular critica l path anal ysis technique that assumes a no rmal distributio n. (See Hillie r and Lie berma n [2001) for more info rmation about PERT.) PERT determines the probability that the earliest start time for an activity is dose to the scheduJed time for that activity. Using information such as probability distribution, latest and earliest start times, and the activity graph, a PERT program can calcuJate the critical p ath and identify those acti vities most likely to be bottlenecks. Many project man- agers use the CPM or PE RT metho d to examine their p rojects. H owever, these methods are valuable only fo r stab le projects in which several activities take place concurren tly. If the project's activities are mostly sequential, then almost all activities are on the crit ical pa th and are candidates for bottlenecks. Moreove r, if the project requires redesign o r rework, the activity graph and critical path are likely to change during developme nt.

To ols to Track Pro gress

There are many tools that ca n be used to keep track o f a project's progress. Some are manual, others are simple spreadsheet applications, and still o the rs are sophisticated tools with complex graphics. To see wha t kinds of tools may be use ful on your proj ects, conside r the work breakdown structu re de picted in Figure 3.5. He re, the ove ralJ o bjec- tive is to build a system involving communicatio ns so ftware, and the proj ect manager has described the work in te rms of fi ve steps: syste m planning, system d esign , coding, testing, and delivery. For simplicity, we co ncen trate on the first two steps. Ste p 1 is then partitio ned into fo ur activities: reviewing the specifications, reviewing the budget, revie wing the scheduJe, and develo ping a proj ect plan. Similarly, th.e system design is

Build commwnioations sof tware

S~stem plannin! (1.0) S~tem design (2. 0)

Review spec ification(l.1 ) Top-level design (2.1)

Review ~ud9et (1.2) Prototyping (:2.2)

Review sc~edule ( 1.3) User interface (2.3)

Develop plan (1. 4) Detai led desi !" (2.4)

FI GURE 3. 5 Example work breakdown structure.

Openmirrors.com

Section 3.1 Tracking Progress 93

developed by doing a top-level design, prototyping, designing the user inte rface, and then creating a detailed design.

Many project management software systems draw a work breakdown structure and also assist the project manager in tracking progress by step and activity. For e xample, a proj ect manage ment package may draw a Gantt chan , a de piction or the project whe re tbe activities a re sh own in paraUel, with the d egree o f comple tion indi- cated by a co lor or icon. The chart helps the proj ect manager to unde rstand which activ- ities can be pe rformed concurrentl y, and also to see which items are o n the critical path.

Figure 3.6 is a Gantt chart for the work breakdown structure of Figure 3.5. The project began in January, and the dashed vertical line la be.led "today" indicates that the project te am is working during the middie of May. A vertical bar shows progress on each activity, and the color of the bar denotes comple ti on, duration, o r criticality. A dia- mond icon sho ws us whe re there bas been slippage, and the triangles designate an activ- ity's start and finish. The Gantt chart is similar to the CPM chart of Figure 3.4, but it includes mo re information.

Simple charts and graphs ca n provide information about resources, too. For e xample, Figure 3.7 graphs the re lationship between the people assigned to the project a nd those need ed at each stage of development; it is typical of graphs produced by proj ect managem ent tools. It is e asy to see that during January, Februa ry, and March,

: TODAY

ACTIVITY NUMBER JAN I FEB I MARI APR I MAY I JUN I JUL I AUG I SEP I OCT I HOV I DEC DESCRIPTION

WBS 1.0 $\'STEM PLAN NINC :

1.1 Review 1pecification 6. \7 _ . __ . __ Y ; SptclnuUu opprw•'

I

1.2 Review buiget A .0 \7 ' 0 ••• ~-.... Bd9e1 apprw•• I I '

1.3 Review schedwle L:::,,. ~ ________ _ <.j> So hiule opprwei I •:

1.4 Develop pl1n L:::,,. : \7 "'" .,, .... , I I I

WBS 2.0 SYSTEM DESICN ' '

2.1 Top-level dui gn L:::,,. : "? ........ 0 Deiig•

4 I I I op prov•

2 .2 Prototyping :6. '7 :• I

2.3 Um interface : L:::,,. \7

2.4 Detailed detign : L:::,,. \7 Outs• : I I opprmi eo .. pletti Du11tlon FIHt Clitlul Sllptoge Stott t11k Flnlth tuk

r - - - - - - - - -, ,_ -............... . <>

FIGURE 3.6 Gantt chart for example work breakdown structure.

94 Chapter 3 Planning and Managing the Project

FIGURE 3. 7 Resource histogram.

c=:1 Load c=:l Overload C:=J Unfoload

-

-

JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV &EC

people are needed but no one is assigned. In April and May, some team members are working, but not eno ugh to do the required job. On the other hand , the period during which the re are too many team members is clearly shown: from the beginning of June to the e nd! of September. T he resource allocati on for this project is clearly out o f balance. By changing the graph's input data, you can change the resource allocation and try to reduce the overload, findin g the best resource load for the schedule you have to meet.

Later in this chapter, we will see bow to estimate the costs of developm ent. Project manageme nt tools track actual costs against the estimates, so that budget progress can be assessed, too. Figure 3.8 shows an example of bow expenditures can be

FIG URE 3.8 ltacking planned vs. actual expenditures.

.., I>< < ::::: 0 0

•• -• --. Planne• expen•itwre -- Actyal expenditwre

...

.

JAN FEB MAR APR MAY JUN

Openmirrors.com

.

JUL AUG SEP OCT NOV DEC

Section 3.2 Pr·oject Personnel 95

monitored. By combining budget tracking witl1 pe rsonnel tracking, you can use project manage ment tools to de termine the best resources for your limited budget.

3.2 PRO JECT PERSONNEL

To de termine the project schedule and estimate the associated effort and costs, we need to know approximate ly bow many peopl e will b e wo rking on the project, what tasks they will pe rform , a nd w hat abilities a nd expe rie nce they must have so they ca n do their jo bs effectively. In this sectio n, we look at bow to decide who d oes what and how the s taff can be o rganized.

Staff Ro les and Cha racteristics

In Chapte r 2, we examine d several software process models, each depicting the way in which the several activities o f software develo pm ent are related. N o matter the model, there are certain activiti es necessary to any software project. For example, every project requires people to inte ract with the custo mers to de termine wha t they want and by whe n they want it. O ther project pe rsonne l design the system, a nd stiU othe rs write o r test the programs. Key proj ect activities are Like ly to include

1. re quire me nts analysis 2. syste m design 3. program design

4. program implementatio n 5. testing

6. tra ining

7. maintenance 8. quaLity assurance

H oweve r, no t every task is pe rfo rmed by the same person or group; the assignmen t of s taff to tasks depends on project size, staff expertise, and staff expe rience. The re is great advantage in assigning different responsibilities to different sets of people, o ffering "checks and balances" that ca n identi fy faults e arly in the develo pment p rocess. For e xa mple, suppose the test team is separate from those wh o design and code the system. Testing ne w o r modifie d software involves a syste m test, where the developers d emo n- strate to the custome r that the system works as sp ecified. The test team must define and docume nt the way in which this test wiLI be conducted and the criteria fo r linking the de mo nstrate d functionality and performance characte ristics to the requirements spec- ified by the custome r. The test team can gen er at,e its test plan from the requirements docume nts witho ut knowing bow the inte rnal pi eces of the syste m a re p ut togethe r. B ecause the test te am bas no preconceptions ab out how the hardware and software will work, it can concentrate on system functio nality. This approach ma kes it easier for the test te am to catch e rrors and omissions made iby the designers o r programme rs. It is in part fo r this reason th at the cl ea nroom metho d is o rganized to use a n independe nt test team , as we will see in la te r chapte rs (Mills, D yer, and Linge r 1987).

96 Chapter 3 Planning and Managing the Project

For similar reasons, it is use ful fo r program designers to be different from system designe rs. Program designers become deeply invo lved with the details of the code, and they som e times neglect the larger picture of bow tthe system sh ould work. We will see in late r chapters that techniques such as walkthroughs, inspections, and reviews can bring the two types of designe rs togethe r to double-check the design before it goes on to be coded, as we U as to provide continuity in the de ve lopme nt process.

We saw in Chapter 1 that there are many o the r roles for pe rsonne l on the d evel- opment or maintenance team. As we study each of the majo r tasks of development in subsequent chapters, we wiU describe the project tea m membe rs who perform those tasks.

Once we have decided on the roles of proj ect team members, we must deci de which kinds of people we nee d in each role. Project personnel may differ in many ways, and it is not enough to say th at a project needs an analyst, two designers, and five pro- g ramme rs, for example. Two people with the sa me jo b title may differ in at least o ne of the following ways:

• ability to perform the work

• interest in the worl< • expe rie nce with similar applications • expe rie nce with similar tools o r languages

• experie nce with similar techniques • expe rie nce with similar developme nt environment • t r.ai nin g • ability to communica te with othe rs • ability to share resp onsibility with o the rs • management skills

Each of these characteristics ca n affect an individual's ability to pe rform productively. These variations help to explai n why o ne programmer can write a particular routine in a day, whe re as another requires a week. The differences can be critical, not only to schedule estimatio n, but also to the success of the project.

To understand each worker's pe rfo rmance, we must know bis or her ability to perfo rm the work at ha nd. Some are good at vie wing " the big picture," but may not e nj oy focusing on detail if asked to work on a sma ll part o f a large project. Such people may be be tter suited to system design or testing than to program design or coding. Sometimes, a bility is related to comfort. In classes o r on projects, you may have wo rked with peop le wh o are mo re comfortable programming in one lan gu age than another. Indeed, some developers feel more confident abo ut their design abilities than th eir coding prowess. This feeling of comfort is impo rtant; people are usually more produc- tive when they have confidence in their ability to perform.

Interest in the work can also determine someone's success on a proj ect. AJtho ugh very good at doing a particular job, an emp loyee may be more interested in tryin g some thing new than in repeating something done many times before. Thus, the novelty of the work is sometimes a factor in generating interest in it. O n the other hand, there are always people who p refe r doing what they know and do best, rather than venturing

Openmirrors.com

Section 3.2 Project Personnel 97

into ne w territory. It is important that whoever is ch osen for a task be e xcited about pe rforming it, no matter what the reason.

Given equal ability and inte rest, two people may sWl diffe r in the amo unt of expe- rience or training they have had with similar applications, tools, or techniques. The per- son who has a lread y been successful at using C to wrire a communicatio ns contro ller is more like ly to write ano the r communkations controlle r in C faster (but no t necessarily more clearly or e fficiently) than someone who has neither e xperience with C nor knowl- edge of what a communicatio ns controller does. Thus, selection of project personnel invo lves no t o nly individual ability and skill , but also experience and training.

On every software development or maintenance project, members o f the devel- o pment team communicate with one another, with use rs, and with the custo me r. The project's progress is affected not only by the degree of communicatio n, but also by the a bility o f individuals to communicate their ideas. Softwa re failures can result fro m a breakdown in communicatio n and understanding, so the numbe r of people who need to communicate with o ne anothe r can affect the quality of the resulting product. Figure 3.9 shows us ho w quickly the lines of communication can grow. Increasing a work team from two to three people triples the numbe r of possibl e lines o f communicatio n. In gen- e ral, if a project h as n worke rs, then there are n(n - 1)/2 pairs of people who might need to communicate, and 2n - 1 possible teams that can be created to work o n smaller pieces of the project. Thus, a project involving only 10 people can use 45 lines of communication, and there are 1023 possible committees o r teams that can be formed to ha ndl e subsyste m deve lopme nt!

Ma ny proj ects involve seve ral people who must share responsibility fo r complet- ing o ne or mo re activiti es. Those working on one asp ect of project develo pmen t must trust o the r team me mbers to do their parts. In classes, you are usually in total control of the projects yo u do. Yo u begin with the re quirements (usually prescribed by your instructor), design a solutio n to the problem, outline the code, write the ac tual lines of code, and test the resulting programs. However, when working in a team, eithe r in school or for an e mployer or customer, you must be able to share the worklo ad. Not o nly does this require verbal co mmunicatio n of ideas and results, but it a lso requires written docume nta tion of what you plan to do and wha t you have done. You must

Two people

Thrae people

Four people

Five people

" people

~ .. -A .A_

~~~ A- ~

.A.><;A

1 line of communication

3 Ii nes of communication

6 Ii nes of communication

& ""-.. 10 lines o{ communication ~\··.52f. It = 11("· 11/2 lines of

communication

FIGURE 3.9 Communication pa ths on a projec1.

98 Chapter 3 Planning and Managing the Project

accept the results of oth ers withou t redoing their work. Many peo ple have difficul ty in sha ring control in this way.

Control is an issue in managing the project, too. Some people are good at direct- ing the work of others. This aspect of pe rsonnel interaction is also related to the com- fo rt people feel with the jobs they have. Those who fee l uncomfo rtable with the idea of pushing their colleagues to stay on schedule, to document their code, o r to meet with the custome r are no t good candidates for development jobs involving the management of o ther wo rkers.

Thus, several aspects of a worke r's background can affect the quality of the project team. A project manager should know each person 's interests and abilities whe n ch oosing who wilJ work togethe r. Sidebar 3.1 e xplains bow meetings and th eir o rganization can enhance or impede project progress. As we will see later in this chap - te r, employee background and communication ca n also have dramatic effects on the project's cost and schedule.

SIDEBAR 3.1 MAKE MEETINGS ENHANCE PROJECT PROGRESS

Some of the communication o n a software project takes place in meetings, either in person or as teleconferences or e lectronic conversations. However, meetings may take up a great deal of time without accomplishing much. Dressle r (1995) te lls us that "running bad meetings can be expensive ... a meeting o f eigh t people who earn $40,000 a year could cost $320 an hour, including salary and benefit costs. That's nearly $6 a minute." Common complaints

about meetings include

• The purpose of the meeting is unclear.

• The attendees are unprepared.

• E ssential people are absent or late.

• The conversation veers away fro m its purpose.

• Some meeting participants do not discuss substantive issues. Inste ad, they argue, domi- nate the conversation, o r do not participate.

• Decisions made at t he meeting are never enacted afterward.

Good project manage ment involves planning all software development activities, including meetings. There are several ways to ensure that a meeting is productive. First, the manager should make clea r to othe rs o n the project te am who should be at the meeting, when it will start and end, and what the meeting will accomplish. Second, every meeting should have a written agenda, dis tributed in advance if possible. Third, someone should take resp o n- sibility for keeping discussion on track and for resolving conflicts. Fourth, someone should be responsible for ensuring that each action ite m d ecided at the mee ting is actually put into practice. Most importantly, minimize the number of meetings, as well as the number of people who must attend them.

Openmirrors.com

Section 3.2 Project Personnel 99

Work Styles

Differe nt people have different preferred styles for interacting with others on the job and for understanding problems that arise in the course of their work. For example, you may prefer to do a de tailed analysis of aU possible information be fore making a deci- sio n, whereas your colleague may rely o n "gut feeling" fo r most of bis important deci- sions. You can think of your pre ferred work style in te rms of two components: the way in which your thoughts are communicated and ide as gathered , and the degree to which your emotions affect decision making. When co mmunicating ideas, some people tell o the rs their thoughts, and some people ask for s uggestions from othe rs before forming an opinion. Jung (1959) caUs the fo rme r extrove rts and the latter introverts. Clearly, your communication style affects the way you interact with other s on a project. Simi- larly, in tu itive people base their decisio ns on feeliings about and e motional reactio n s to a proble m. Othe rs are rational, deciding primarily by e xamining the facts and car efull y considering aU options.

We can describe the variety of work styles by considering the graph of Figure 3.10, where communication style forms the horizontal axis and decision style the vertical o ne. The more extroverted you are, the farthe r to the right your work style fa lJs on the graph. Sim ilarly, the more e motions play a pa rt in your decisions, the higher up you go. Thus, we can deflne four basic work styles, corresponding to the fou r quadrants of the graph. The rational extrove rts tend to assert their ideas and not let "gut feeling" affect the ir decision making. They te ll thei r colleagues what they want them to know, but they rare ly ask fo r more information be fo re doing so. When re asoning, t hey rely on logic, not e motio n . The rational introverts also avoid emo tional decisions, but they are wiUing to take time to conside r all possible courses of actio n. Rational introverts are informal.ion gathe re rs; they do not feel comfortable making a decision unless they are convinced that au the facts are at hand.

In contrast, intuitive extrove rts base mall!y decisions o n e motional reactions, te nding to want to teU others about them rather than ask for input. They use their intu- ition to be creative, and they often suggest unusual approaches to solving a proble m. The inh1itive intro,•ert is creative, too, but applies crea tivity only after having gathe red

INTUITIVE FIGURE 3 .10 Work styles.

INTUITIVE INTU ITIVE INTROVERT: ElCTROVERT: Asks others Tells others Acknowledges feelings Acknowlej9es feelings

..... "" m .... ~ > 0 "" ""

0 ..... RATIONAL < !!: RATIONAL m

"" INTROVERT: ElCTROVERT:

.....

Asks others Tells others

Decides logicallv Deci'8s lo9icallv

RATIO NAL

100 Chapter 3 Planning and Managing the Project

sufficient info rmation on which to base a decision. Winston Churchill was an intuitive introvert; when be wanted to learn a bout an issue, he rea d every !bit of mate rial avail- able that addressed it. H e often made his decisions based on bow he felt about what he had learned (Mancheste r 1983).

To see how work styles affect inte ractions on a project, con sider several typical staff profiles. Kai, a rational extrovert, judges he r coUeagues by the results they pro- duce. When making a decision, ber top prio rity is e fficiency. Thus, she wants to know o nly the bottom line. She examines he r options and the ir probable effects, bu t she does not need to see documents o r hear explanations suppo rting each option. If her time is wasted or he r e fficiency is ha mpered in some way, she asserts her authority to regain control of the situa tion. Thus, Kai is good at making sound decision s quickl y.

Marcel, a rational introvert, is ve ry different from his coUeagu e Kai. He judges his pee rs by how busy they are, and he h as little tolerance for tbose who appear not to be working hard al l the time . He is a good worker, admired for the e ne rgy he devotes to his work. His reputatio n as a good worke r is ve ry important to him, and be prides himself o n being accurate and thorough. H e does not like to make decisio ns without comp le te informa tion. Wben asked to make a presentation, Marcel does so only after gathering au relevant information on the subject.

Marcel sha res an office with D avid, an intuitive extrovert. Whereas Marcel will not make a decision without complete knowl edge of the situatio n, Da vid prefers to fol- low his feelings. Ofte n, he wilJ trust his intuitio n about a problem, basing his decision on professio nal judgme nt rathe r than a slow, care ful analysis of the information at hand. Since he is asse rtive, David tends to tell Lhe olhe:rs on his project about his new ideas. H e is creative, and he e njoys when othe rs recogni ze bis ideas. David Ukes to work in an e nvironme nt where the re is a great deal of inte raction among the sta ff members.

Ying, an intuitive introvert, also thrives on her coUeagues' atten tio n. She is sensi- tive and aware o f her e motional reactions to people and proble ms; it is very important that she be Liked by her peers. Because she is a good listener, Ymg is the project me m- ber to who m o thers turn to express their feelings. Ymg takes a lot of time to make a d ecision, not o nly because she needs complete info rmation, but also because she wants to make the right decision. She is sensitive to wh at othe rs think about he r ability and ideas. She ana lyzes situa tions much as Marce l does, but with a di(ierent focus; Marcel looks at all the facts and figures, but Yin g examines re lational dependencies and emo - tio nal invo lve me nts, too.

Clea rly, not everyone fits neatly into one of the four categories. Differe nt people have differe nt tende ncies, and we can use the framework of Figure 3.10 to describe those te nde ncies and prefe re nces.

Communicatio n is critica l to project success, and work style dete rmines commu- nicatio n style. For examp le, if you are responsible for a part of the project that is behind schedule, Kai and David are Likely to te ll you wh en your work must be ready. D avid may o ffer several ideas to get the work back on track , and Kai wiU give you a new schedule to follow. H owever, Marcel and Ymg wilJ probably ask when the results wilJ be read y. Marcel, in analyzing his options, will want to know why it is not ready; Ying wiU ask if the re is anything she can do to help.

U nde rstanding wo rk styles can he lp you to be He xible in your approach to othe r project team me mbers a nd to custome rs and users. In particular, work styles give you

Openmirrors.com

Section 3.2 Project Personnel 101

informa tio n about the priorities of o thers. If a colleague's priorities and inte rests are different from yours, you ca n present in form ation to her in terms of what she deems important. For example, suppose Claude is your customer and you are preparing a presentation fo r him Oll! the status o f the project. If Claude is an introvert, you know that he pre fe rs gathe ring information to giving it. Thus, you may Oiganize your presen - tatio n so that it tells him a grea t deal about how t he project is structured and how it is progressing. However, if Claude is an extrovert, you can include questions to allow him to te ll you what be wants o r needs. Similarly, if Claude is intuitive, you can take advan- tage o f his creativity by soliciting new ideas fro m him; if he is rational , your presen- ta tio n can include facts o r figures rather than judgments o r feelings. Thus, work styles affect inte ractio ns among customers, deve lo pers, a nd users.

·w ork styles can also invo lve choice o f worker for a given task. For instance, intuitive e mployees may prefer design and development (requiring new ideas) to mainte nance programming and design (requiring a ttention to de tail and analysis of complex results).

Project Organization

Software developmen t and maintenance project teams do not consist of people workin g independently or witho ut coordination. Instead , team members are orga nized in ways that enhance the swift completion o f quality products. The choice of an appropriate structure fo r your project depends o n several things:

• the backgrounds and work styles of the team members • the number o f people on the te am

• tb:e management styles of the customers and developers

Good p roject managers a re aware of these issues, and they seek team me mbers who are flexible enough to inte ract with a ll players, regardless of work style.

One popular o rganizatio nal structure is the chief programmer team, first use d at IBM (Bake r 1972). On a chief programmer team, one person is totally responsible for a system's design and developme nt. All other tea m members report to the chief pro- gramme r, who has the final say on every decision. The chief programmer supervises au o thers, designs all programs, and assigns the code development to the other team mem- bers. Assisting the chief is an understudy, whose principal job is substituting for the chief programmer when necessary. A librarian assists the team, responsible fo r main- ta ining a ll project documentation. The librarian a lso compiles and links the code, and performs preliminary testing of a ll modules submitted to the library. This division of labor aUows the programme rs to focus o n what they do best: programming.

The o rganization o f the chief programmer team is illustrated in Figure 3.11. By placing all responsibility for all decisions with the chief programmer, the team structure minimizes the amount of communication needed during the project. Each team member must communicate o ften with the chief, but not necessarily with other team members. Thus, if the team consists o f n - 1 programmers plus the chief, the team ca n establish o nly n - 1 pa ths of communication (one path for each team member's interaction with the chief) o ut of a potential n ( n - 1)/2 paths. For example, rathe:r than working o ut a proble m the mselves, the programmers can simp!y approach the chief for an answer. Similarly, the chie f reviews au d esign and code, removing the need for peer reviews.

102 Chapter 3 Planning a nd Managing the Project

FIGURE 3.11 Chie f programmer team o rganizat ion.

I

Senior pro 9 r1111111 a rs

I Junior

pro9rammers

Chief pro9rammer

Assishnt chief pro9rammer

I

I

Librarian A'mi11istration Test team

Altho ugh a chie f programme r team is a h ierarchy, groups of wo rkers may be formed to accomplish a s pecialized task. For instance, o ne o r mo re team members ma y form an administra tive group to provide a status report on the project's curren t cost and schedule.

Clearly, the chie f programmer must be good at making decisions quickly, so the chief is likely to be an extrovert. Howe ver, if mos t o f the team me mbe rs are introverts, the chie f programme r team may not be the best structure fo r the project. An alterna- tive is based o n the idea o f "egoless" programmi.ng, as describe d by We inberg (1971). Instead o f a single poin U o f responsibility, a n egoless a pproach holds eve ryo ne equ ally responsible. Mo reove r, Uhe process is separa te d from the indi viduals; criticism is m ade o f the product o r the resu lt, no t the people involved. The egoless team structure is d emocratic, and aU team members vo te o n a d ecision, whe ther it concerns design con- siderations o r testing techniques.

Of course, the re are many o the r ways to organize a de velo pme nt o r maintenance project, and the two described above represent ext remes. Which structure is pre ferable? The more people o n the project, the more need the re is fo r a formal structure. Certainl y, a develo pme nt team witfu only three or four membe rs does no t a lways need an e labo rate o rganiz ational structure. Howeve r, a team o f several d ozen wo rke rs must have a weLJ - d efined organizatio n. In fact, your company o r your custome r may impose a structure on the deve lo pment team, based o n past success, o n t he need to track progress in a certain way, or on the desire to minimize points of contact. For example, your customer ma y insist that the test team be to tally indepe ndent o f program design and development.

Resea rche rs continue to in vestiga te ho w project team structure affects the result- ing product and how to choose the most appropriate o rganization in a given situa tio n. A Natio nal Science Foundatio n (1983) investigation fo und that projects with a high d egree of certainty, stability, uniformity, and re pe tition can be accomplished m ore e ffectively by a hie rarc hica l o rganizatio nal stru cture such as the chie f programmer team. These projects require little communica tion amo ng project members, so they are well-suited to an o rga niza tio n that stresses rules, specializa tion, fo rmality, and a clear d efinitio n o f o rganiza tio nal hierarchy.

Openmirrors.com

Section 3.2 Project Personnel 103

TABLE 3.5 Comparison of Organizatjonal Structures

Highly Struc tured loosely Stn«:tured

High certainty Uncerta inty

Repetition New techniques or technology

Large projects Small projects

On the other hand, whe n there is much uncertainty invo lved in a p roject, a more de mo cratic approach may be be tter. Fo r example, if the requirements may cha nge as de ve lo pme nt proceeds, the project h as a degree of uncertainty. Likewise, suppose your custo me r is building a new piece of hardware to inte rface with a syste m; if the e xact specification of tbe hardware is not yet known , the n the leve l of uncertainty is high. He re, participation in decision making, a loosely defined hierarchy, and the encourage- ment of o pen communicatio n can be e ffective.

Table 3.5 summarizes the characteristics of projects and the suggested organiza- tio nal structure to address them. A large project with high certainty and repe tition pro ba- bly needs a highly structured organization, whereas a small project with new techniques and a high degree o f certainty needs a looser structure. Side bar 3.2 describes the need to balance structure with cre ativity.

SIDEBAR 3.2 STRUCTURE VS. CREATIVITY

Kunde (1997) reports the results of experiments by Sally Philipp, a developer of software training materials. When Philipp teaches a management seminar, she divides her class into two groups. Each group is assigned the same task: to b uild a hotel with construction

paper and glue. Some teams are structured, and the team members have clearly defined

responsibilities. Others are left alone, given no directio n or structure o ther than to build the

hotel. Philipp claims that the results are always the same. "The unstructured teams always do

incredibly creative, multistoried Taj Mahals and never comple te one on time. The structured teams do a Day's Inn [a bland but functional small hotel], but they're finished and putting

chairs around the pool when I call time," she says.

One way she places structure on a team is by encouraging team members to set dead- lines. The overall task is broken into small subtasks, and individual team me mbers are res-

ponsible for time estimates. The d eadlines help to preve nt "scope creep,'' the injection of

unnecessary functionality into a product. The experts in Kunde's article claim that good project management means finding a

balance between structure and creativity. Left to their own devices, the software developers

will focus only on functionality and creativity, disregarding d eadlines and the scope of the

specification. Many software project management experts made similar claims. Unfortu-

nate ly, much of this infonnatioo is based on anecdote, no t on so lid e mpirical investigation.

104 Chapter 3 Planning and Manag ing the Project

The two types of organizational structure can be combined , where appropriate. For instance, programme rs may be asked to develop a subsystem on their own , using an egole ss approach within a hierarchical structure. Or the test te am of a loosely struc- tured project may impose a hierarchical structure on itself and designate one person to be respo nsible fo r all majo r testin g decisions.

3.3 EFFORT ESTIMATION

One of the crucial aspects of proj ect planning and management is unde rstanding how much the project is likely to cost. Cost ove rruns can cause custome rs to cancel projects, and cost underestimates can force a proj ect team to invest much of its time without financia l compe nsa tion. A s described in Sidebar 3.3, there are many reasons for inaccu- rate estimates. A good cost estimate early in the project's life he lps the project manager to know bow many deve lope rs will be required and to arrange for the appropriate staff to be available wben the y are needed.

The proj ect budge t pays for several types of costs: facilities, staff, methods, and tools. The facilities costs include hardware, space, furniture, telephones, modems, heat- ing and air conditioning, cables, disks, paper, pe ns, photocopiers, and all o ther items tbat provide tbe physical e nvironment in whkb the de velope rs will work. For some projects, tbis environment may already exist, so the costs are well-unde rsto od and easy to esti- mate. But for o ther projects, tbe e nvironment may have to be created. For example, a new project may require a security vault, a raised floor, temperature or humidity con- trols, or special furniture . He re, the costs can be estimated, but the y may vary from ini- tial estimates as the e nvironme nt is built or changed. Fo r instance, installing cabling in a building may seem straightforward until the builders discover that the building is of specia l historical significance, so tbat the cabl es must be routed around the walls instead of through them.

There are some times hidden costs that are not apparent to the managers and d eve lopers. For examp le , studies indicate that a programme r needs a minimum amo unt o f space and quie t to be able to wo rk e ffective ly. McCue (1978) reported to his col- leagues at IBM that the minimum standard fo r programmer wo rk space shouJd be 100 square feet o f dedicated floor space with 30 square feet of horizon Ital work surface. The space also needs a floor-to-ce ilin g enclosure fo r no ise protection. D eMarco and Liste r's (1987) work suggests that programmers free fro m telephone calls and uninvited visilo rs are more e fficient and produce a better product than those who are subject to repeated interruption.

Othe r p roject costs invo lve purchasing software and tools to suppo rt develo p- me nt effo rts. Io addition to tools fo r designin g and coding the system, the project may buy softwa re to capture require me nts, organjze documentatio n, test the code, keep track o f changes, gene rate test data, support group meetings, and more. These tools, some times caJJed Computer-Aided Software Engineerin g (or CASE) tools, are some- times re quired by the customer or are part of a company's standa rd software develop- ment process.

For most projects, the biggest compone nt o f cost is effo rt. We must determine ho w many staff-d ays of effort wiU be require d to comple te the project. Effort is certainly

Openmirrors.com

Section 3.3 Effort Estimation 105

SIDEBAR 3.3 CAUSES OF INACCURATE ESTIMATES

Lederer and Prasad (1992) investigated the cost-estimation practices of 115 different orga-nizations.Thirty-five percent of the managers surveyed on a five-point Liker t scale indi- cated that their current estimates were " moderately unsatisfactory" or "very unsatisfactory."

The key causes identified by the respondents included

• frequent requests for changes by users

• overlooked tasks

• users' lack of understanding of their own requirements

• insufficient analysis when developing an estimate

• lack of coordination of systems development, technical services, operations, data administration, and other functions during development

• lack of an adequate method or guidelines for estimating

Several aspects of the project were noted as key influences on the estimate:

• complexity of the proposed application system

• required integration with existing systems

• complexity of the programs in the system

• size of the system expressed as number of functions or programs

• capabilities of the project team members

• project team's experience with the application

• anticipated frequency or extent of potential changes in user requirements

• project team's experience with the programming language

• database management system

• number of project team members

• extent of programming or documentation standa rds

• availability of tools such as application generators

• team's experience with the hardware

the cost compone nt with the grea test degree of uncertainty. We have see n how work style, project organization, ability, inte rest, e xperie nce, trainfog, and other employee characte ristics can affect the time it takes to complete a task. Moreover, when a group of workers must communicate and consult with one another, the e ffort needed is increased by the time required for meetings, documentation, and training.

Cost, schedule, and effort estimation must be done as e arly as possible during the proj ect's Life cycle, since it affects resource allocation and project feasibility. (If it costs too much, the customer may cancel the project.) But estimation should be done re peatedly throughout the life cycle; as aspects of the project change, the estimate can

106 Chapter 3 Planning and Manag ing the Project

4x

2x ..... Cb ~ 1.Sx "' 1.2Sr .... N c;; .... > ~ 5 ..... c.: O.Sx

0.2Sx

* Product Concept of Requirements design opention$ $pecilicalion speer

* Size (SLOC) + Cost ($)

Detailed foign specs

Accepted software

Feasibi I ity Plan$ & Product l>ehi led Development ud lest requirements des i!n desi!n

PHASES AND MILESTONES

FIGURE 3.1 2 Changes in estin13tion accuracy as project progresses (Boehm et al. 1995).

be re fined , based on more complete in forma tion about the proj ect's characteristics. Figure 3.12 illustrates how unce rtainty early in the project can affect the accuracy of cost and size estimates (Boehm et al. 1995).

The stars represe nt size estimates from actual projects, and the pluses a re cost estimates. The funne l-shaped lines narrowing to the right represent Boehm 's sense of how our estimates get more accurate as we learn mo re about a project. Notice that when the specifics o f the project are not yet known, the estimate can diffe r fro m the eve ntua l actual cost by a factor of 4. As decisions are made about the product and the process, the factor decre ases. Many expe rts aim for estimates that a re within 10 pe rcent o f the actual value, but Boehm 's data indica te that sucb estimates typicaUy occur o nly when the proj ect is almost done-too late to be useful for project managemen t.

To address the need fo r producin g accurate estimates, software e ngineers have d eve loped techniques fo r capturing the re lati onships a mong effort and staff character- istics, project require ments, and o the r factors that can affect the time, e ffort, and cost of d eve loping a so ftware system. For the rest of this chapter, we focus on effort-estimation techniques.

Ex pert Judgme nt

Many e ffo rt-estimation me thods re ly on expe rt judgment. Some are informal tech- niques, based on a manager's experie nce with similar projects. Thus, the accuracy of the prediction is based on the competence, experien ce, obj ectivity, and perception of the estimator. In its simplest form , such an estimate ma kes an educated guess about the effort needed to build an e ntire system or its subsystems. The complete estimate can be computed from eithe r a top-down or a botto m-up a na lysis of what is needed.

Openmirrors.com

Section 3.3 Effort Estimation 107

Many times analogies are used to estimate effort. If we have already b uilt a system much Like the one proposed, then we ca n use the similarity as the basis for our estimates. For example, if system A is simila r to system B, then the cost to produce system A should be very much like the cost to produce B. We can extend the analogy to say that if A is about hat[ the size o r complexity of B, then A should cost about half as much as B.

lbe analogy process can be fo rmalized by asking several experts to make three predictions: a pessimistic one (x), an optimistic one (z), and a most likely guess (y) . Then o ur estimate is the mean o f the beta probability distri bution de te rmined by these num- bers: (x + 4y + z)/6. By using thi s technique, we produce an estimate that " norma l- izes" the individual estimates.

The Delphi technique makes use of expert judgment in a different way. Experts a re asked to make individual predictions secretly, based on their expertise and using whateve r process they choose. T hen, the average estimate is calculated and presented to the group. Each expert has th e opportunity to revise his or her estimate, if desired. The process is re peated until no expe rt wants to revise. Some users o f the D e lphi tech- nique discuss the average before new estimates are made; at o ther times, the users a Uow no discussion.And in ano ther variation, the justifications o f each expert are circu- lated anonymously amo ng the experts.

Wolve rton (1974) built one of the fi rst models of software develo pment e ffort. His softwa re cost matrix captures bis experie nce with project cost at TRW, a U.S. soft- ware deve lo pme nt company. As shown in Table 3.6, the row name represents the type of software, and the column designates its difficulty. Difficulty de pends o n two factors: whether the problem is old (0) o r ne w (N) and whethe r it is easy (E), mode ra te (M), o r ha rd (H ). The matrix ele ments are the cost per line of code, as ca librated fro m historical data at TRW. To use the matrix, you partition the proposed software system into mod- ules. Then, you estimate the size of each module in terms of lines o f code. Using the matrix, you calcula te the cost p er module, and then sum ove r all the modules. Fo r instance, suppose you have a system with three modules: o ne input/output module that is o ld and easy, one a lgorithm module that is new and hard , and one data managemen t module that is o ld and moderate. If the modules are like ly to have 100, 200, and 100 Lines of code, respectively, the n the Wolverton mode l estimates the cost to be (100 x 17) + (200 x 35) + (100 x 31) = $11,800.

TABLE 3.6 Wolverton Model Cost Matrix

Diffic 11/ty

Type of software OE OM OH NE NM NH

Control 21 27 30 33 40 49

Input/output 17 24 27 28 35 43

Pre/post processor 16 23 26 28 34 42

Algorithm 15 20 22 25 30 35

Data management 24 31 35 37 46 57

nme-critical 75 75 75 75 75 75

108 Chapter 3 Planning and Manag ing the Project

Since the mode l is based on TRW data and uses 1974 doUars,it is not applicable to today's software de velopme nt projects. But the t echnique is useful an d can be trans- porte d ,easily to your own de velopme nt or maintenance environme nt.

I1i1 general , experiential models, by relying m ostly on exp ert judgment, are subject to a ll its inaccuracies. They re ly o n the expert's ability to determine which projects are similar and in what ways. H owever, projects that appear to be very similar can in fact be quite diffe rent. For example, fast runners today can run a mile in 4 minutes.A marathon race requires a runne r to run 26 miles and 365 ya rds. If we extrapolate the 4-minute time, we might expect a runne r to run a marathon in 1 hour and 45 minutes. Yet a marathon has never bee n run in unde r 2 hours. Consequently, the re must be character- istics of running a mara ttho n that are very different from those of running a mile. Like- wise, tbere are o fte n characte ristics of one project that make it very different from ano ther proj ect, but the characteristics a re not always apparent.

Even when we know how one project differs from another, we do not always know how the diffe rences a ffect the cost. A proportiona l strategy is unreliable, because project costs are not always linear: Two people cannot produce code twice as fast as one. Extra time may be needed for communica tion and coordination, or to accommodate differ- e nces in interest, ability, and e xperience. Sackman, E rikson, and G rant (1968) found that the productivity ratio be tween best and worst programmers averaged 10 to 1, with no easily definable re lationship between experience and performance. Likewise, a more rece nt study by Hughes (1996) found great variety in the way software is designed and developed, so a mo del that may work in on e org anization may not apply to another. Hughes also noted that past experience and knowledge of available resources are major factors in determining cost.

Expert judgment suffe rs not only from va riability and subj ectivity, but also from dependence on cu rre nt data. The data on which an expe rt judgmen tt model is based must reflect current practices., so they must be updated o ften. Moreove r, most expe rt judg- ment techniques are simplistic, neglecting to incor porate a large nlll1Ilber of factors il:bat can affect the effort needed o n a project. For this reason, practitio ners and researchers have turned to algorit hmic methods to estimate effort.

Algorithmic Methods

Researche rs have crea ted mode ls that express the re lationship be tween e ffo rt and the factors that influence it. l11e models a re usually described using equations, where e ffort is the de pendent va riabEe, and several factors (such as experience, size, and applicati on type) a re the inde pende nt variables. Most of these models ackno wledge that project size is the most influential factor in the equation b y e xpressing e ffo rt as

E = (a + bSc)m (X )

whe re Sis the estimated size of the syste m, and a, b, and c are constants.X is a vecto r of cost facto rs, x 1 through Xm and m is an adjustme nt multiplie r based on these factors. In o the r words, the effo rt is de te rmined mostly by the size o f t lhe proposed system, adjuste d by the effects of several o ther project, process, product, or resource cha racteristics.

Openmirrors.com

Section 3.3 Effort Estimation 109

WaJston and Felix (1977) deve loped one of t he first models of this type, finding that IBM data from 60 projects yielded an equati on of the form

E = 5.25S'°·91

111e projects that supplied data built systems with sizes ranging from 4000 to 467,000 Lines of code, writte n in 28 differe nt high-level languages o n 66 computers, and representing fro m 12 to 11,758 person -months of effort. Size was measured as lines of code, including comments as lon g as they did not exceed 50 percent of the total lines in the program.

The basic equation was supplemented with a productivity index that reflected 29 factors that can affect productivity, shown in Table 3.7 . Notice that the facto rs are tied to a ve ry specific type of d eve lopment, including two platfor ms: an operational computer and a de ve lopme nt compute r. The model reflects the particular develo pment s tyle o f the IBM Federal Syste ms orga nizations that p rovided the data.

TABLE 3.7 Walston and Felix Model Productivity Factors

1. Customer interface complexity 16. Use of design. and code inspections

2. User participation in requirements definition 17. Use of top-down development

3. Customer-originated program design changes 18. Use of a chie[ programmer team

4. Customer experience with the application area 19. Overall complexity of code

5. Overall personnel experience 20. Complexity of application processing

6. Percentage of development programmers 21. Complexity of program flow who participated in the design of functional specifications

7. Previous experience with the 22. Overall constraints on program's design operational computer

8. Previous experience with the programming 23. Design constraints on the program's language main storage

9. Previous experience with applications 24. Design constraints on the program's timing of similar size and complexity

10. Ratio of average staff si7.e to project 25. Code for real-time or interactive o:peration duration (people per month) or fo r execution under severe time constraints

11. Hardware under concurrent development 26. Percentage on code for delivery

12. Access to <level opment computer 27. Code classified as nonmathematical application open under sp ecial request and input/output formatting programs

13. Access to development computer closed 28. Number of classes of items in the database per 1000 lines of code

14. Classified security environment for computer 29. Number of pages of delivered documentation and at least 25% of programs a nd data per 1000 lines of code

15. Use of structured programming

110 Chapter 3 Planning a nd Managing the Project

Each of the 29 factors was weigh ted by 1 if the factor increases productivity, 0 if it has no effect on prod uctivity, and -1 if it decreases productivity. A weighted sum of the 29 factors was then used. to generate an effort estimate from the basic equation.

Bailey and Basili (1981) suggested a modeling technique, called a meta-model , for bui lding an estimation equatio n that reflects your own organization 's characteristics. They de monstrated their technique using a database of 18 scie ntific proj ects writte n in Fortralll at NASA's Goddard Space Flight Center. First, they minimized the standard e rror estima te and produ ced an equation that was ve ry accurate :

E = 5.5 + 0.73S u 6

The n, they adjusted this initial estimate based on the ratio of e rro rs. If R is the ratio between the actual e ffort, E, and the predicted effort, E ', then the e ffo rt adjustmen t is defined as

{ R - 1

E Radj = 1 - 1/ R if R 2:: 1 if R < 1

They the n adjusted the initial effort estimate Eadi this way:

E . = {(1 + ERa11;)E if R 2:: 1 adi E/(1 + E Radj) if R < 1

FinaUy, Bailey and BasiLi (1981) accounted for o the r factors that affect effort, shown in Table 3.8. For each entry in the table, the project is scored from 0 (not present) tto 5 (very impo rtant), depending o n the judgment of the project manager. llms, the total

TABLE 3.8 Bailey-Basili Effort Modifiers

Total Methodology Cumulative Complexity Cumulative Experience (METH) (CPLX) (EXP)

nee charts Customer interface complexity Programmer qualifications

Top-down design Application complexity Programmer machine experience

Formal documentation Program How complexity Programmer language experience

Chief programmer teams Internal communication Programmer application complexity experience

Formal training Database complexity Team experience

Formal test plans External communication complexity

Design fo rmalisms Customer-initiated program design changes

Code reading

Unit development folders

Openmirrors.com

Section 3.3 Effo rt Estimation 111

sco re fo r METH can be as high as 45, fo r CPLX as high as 35, and fo r EXP as ltigh as 25. Their mode l describes a procedure, based o n multilinear least-squa re regressio n, fo r using these scores to furthe r modify the effort estimate.

Clearly, o oe o f the problems with mode ls of this type is the ir de pe ndence o n size as a key variable . Estimates are usuaUy reqwred early, we ll before accurate size info r- mation is availa ble, and certainly be fore the system is expressed as Lines o f code. So the models simply translate tbe effort-estimation problem to a size-estimatio n problem. Boe bm's Constructive Cost Model (COCOMO) ackno wledges this problem and incor- po rates three sizing techniques in the latest version , COCO MO II.

Boehm (1981) developed the o riginal CO COMO model in the 1970s, using an e xtensive d ata base of informatio n fro m projects at TRW, an A merican compan y that built software for many diffe rent cli ents. Conside ring softwa re de ve lopme nt from bo th an engi neering and an economics viewpoint, Boehm used size as the primary de termi- nant of cost and then adj usted U1e initial estimate using over a dozen cost d rivers, includ- ing attributes of the staff, the project, the product, and the develo pment en viro nment. In the 1990s, Boehm updated the origin al CO COMO model, creating COCOMO II to re flect the ways in which softwa re deve lopme nt bad matured.

The COCOMO II estimation process reflects three majo r stages o f a ny de velop- ment project. Whe reas the o riginal CO COMO mo de l used d elivered source lines of code as its key input, the ne w mo del acknowledges that Lines of code are impossible to kno w early in the deve lopme nt cycle . At stage 1, projects usually build p.ro to types to resolve high-risk issues invo lving user interfaces, software and system inte ractio n, per- formance, or techno logical maturity. He re, little is known abo ut the like ly size o f the final product under consideration, so COCO MO II estimates size in wha t its creato rs caJI application po ints. As we shall see, this technique captures size in terms of high- level e ffo rt gene rato rs, such as the nwnber of screens and reports, an d the num ber o f third-ge ne ration language compo ne nts.

At stage 2, the e arly design stage, a decision bas been made to move fo rward with de ve lopme nt, but the designers must explore alte rnative architectures and concepts of o pe ration. Again, the re is no t en ough information to sup port fine-graine d e ffort and duration estima tio n, but far more is known than at stage 1. For stage 2, CO COMO II e mploys functio n points as a size measure. Function points, a technique explo red in de pth in IFPUG (1994a and b), estimate the functi onality captured in the require- ments, so they offer a rich er syste m descriptio n than applicatio n points.

By stage 3, the postarcbitecture stage, developme nt has begun, a nd far more info rmatio n is known. In this stage, sizing can be don e in te rms of functio n p oints or Lines o f code, and many cost factors can be estimated wi th some degree of comfo rt.

COCOMO II a lso includes models of reuse, takes into account maintenance and breakage (i.e., tbe change in require ments over time), an d mo re. As with tbe origina l COCO MO, the model includes cost factors to adjust the initial effort estimate. A research gro up at Ule Unive rsity of Southe rn California is assessing and improving its accuracy.

Let us look at COCOMO EI in more detail. The basic mode l is of the fo rm

E = bScm( X )

where the initial size-based estimate, bSc, is adjusted by the vector o f cost driver info r- mation, m(X). Table 3.9 describes the cost drivers at each stage, as well as the use of o the r mode ls to modi fy the estimate.

112 Chapter 3 Plan ning a nd Managi ng the Project

TABLE 3.9 Three Stages of COCO MO II

Stage 1: Application Stage 2: Stage3:

Model Aspect Composition Early Design Post architecture

Size Application Function points (FPs) and FP and language or source points language lines of code (SLOC}

Reuse Implict in Equivalent SLOC as function Equivalent SLOC as function of model or other variables other variables

Requiremellls Implicit in % change expressed as % change expressed as a cha11ge model a cost factor cost factor

Mai111e1umce Application Function of ACT, software Function of ACT, software points, understanding, unfmiliarity understanding, unfamiliarity annual change traffic (ACT)

Scale (c) i11 1.0 0.91to1.23,depending on 0.91to1.23, depending on 11omi11al ejfon precedentedness, conformity, precedentedness, conJormi.ty, equation early architecture, risk early architecture, risk

resolution, team cohesion, resolution, team cohesion, and and SEI process maturity SEI process maturity

Product cost None Complexity, required Reliability, database size, drivers re usability documentation needs, required

reuse, and product complexity

Platfonn cost None Platform difficulty Execution time constraints, drivers main storage constraints, and

virtua l machine volatility

Perso1111el cost None Personnel capability and Analyst capability, applications drivers experience experience, programmer

capability, programmer experience, language and tool experience, and persounel continuity

Project cost None Requued development Use or software tools, required drivers schedule, development development schedule, and

environment multisite development

At stage 1, application points supply the s ize measure. TI"ti s size measure is an exte nsion of the object- point approach suggested by Kauffman and Kuma r (1993) and productivity data reporte d by Banker, Kauffman, and Kuma r (1992). To compute appli- cation points, you first oount the number of screens, reports, and third-generation lan- guage components that will be involved in the application. It is. assumed that these ele ments are defined in a standard way as pa rt of an integrate d computer-aided soft- wa re enginee ring enviro nme nt. Next, you classify each application e lement as simple, medium, o r difficult. Table 3.10 contains guidelines for this classification.

Openmirrors.com

Section 3.3 Effort Estimation 113

TABLE 3.1 0 Application Point Complexity Levels

Number of views

contained

< 3

3-7

s+

For Screens For Reports

Number and source Number and source or data tables or data tables

Total < 4 Total < S Total s+ Number of Tota1 < 4 Total < S Total s+ (< 2 servers, (2.-3 servers, (> 3 servers, sections (< 2 servers, (2- 3 servers, (> 3 servers, < 3 clients) 3-5 clients) > 5 clients) co111ai11ed < 3 clients) 3-:S clients) > 5 cUents)

Simple Simple Medium Oor 1 Simple Simple Medium

Simple Medium Difficult 2or3 Simple M edium Difficult

Me dium D ifficult Difficult 4+ Medium Difficult Difficult

The number to be used for simple, medium, o r difficult a pplication points is a complexity weight fo und in Table 3.11. The weights reflect the relative e ffort required to imple ment a report or scree n o f that complexity level.

lben, you sum the weighted re ports and screens to o btain a single application - po int numbe r. If r pe rce n t o f the o bjects wiU be re11.1Sed from previous projects, the num - be r o f n ew application po ints is calculated to be

New application points = (application points) x (100 - r )/100

To use this numbe r fo r e ffort estimation, you use an adjustme nt factor, called a produc- tivity rate, based on de velope r experience and capability, coupled with C ASE ma turity and capability. For e xample, if the developer experience a nd capability are rated low, a nd the CASE maturity and capability are rated low, the n Table 3.12 te Us us that the productivity facto r is 7, so the number of person-mon ths require d is the number of n ew application points divided by 7. Whe n the deve lopers ' experience is low but C ASE maturity is high, the pro ductivity estim ate is the m ean of the two values: 16. Like wise, when a te am of de velopers has expe rience le ve ls that vary, the productivity estimate can use the mean o f the expe rience and capability weights..

At stage 1, the cost drivers are not appli ed to this effort estimate . Howe ver , at stage 2, the effort estimate, based on a functio n-po int calculation, is adjusted for degree o f reuse, requireme nts change, and maintenance. The scale (i.e., the val ue for c in the e ffo rt e quati on) had bee n set to 1.0 in stage l ; fo r stage 2, the sca le ranges from 0.91 to

TABLE 3.11 Complexity Weights for Application Points

Element Type Simple Medium Diffic ult

Screen 1 2 3

Report 2 5 s

3GL compon ent - - 10

114 Chapter 3 Planning a nd Managing the Project

TABLE 3.12 Productivity Estimate Calculation

Developers' experience and Very low Low Nominal High Very high capability

CASE ma mrity and capabiliry Very low Low Nominal High Very high

Productiviry factor 4 7 13 25 50

1.23, depending on the d egree of nove lty of the system, confonnity, early architecture and risk resolution , team cohesion, a nd process maturity.

Tfue cost drive rs in stages 2 and 3 are adjustment factors expressed as effort multi- pLie rs based o n rating your proj ect from "extra lo w" to "extra hig h," d epending on its characteristics. For example, a development te am's experie nce with an application type is conside red to be

• extra low if it has fe we r than 3 months o f experience

• very lo w if it bas at least 3 but fe we r than 5 months of expe rie nce • low if it has at least 5 but fewe r than 9 months of experience • nominal if it has at least 9 months but less than one year of expe rie nce • hi'gh if it has al least 1 year but fewe r than 2 years of expe rie nce • ve ry high if it bas ait least 2 years but fewe r than 4 years of experience • e:ctra high if it has a t le ast 4 years of e xpe rience

Similarly, analyst capability is measu red on an o rdinal scale based on percentiJe ranges. Fo r instance, the ra ti ng is " ve ry high" if the analyst is in the nine tieth pe rcentile and " nominal" for the fifty-filth pe rcentile. Correspondingly, COCO MO II assigns an effort muJtiplier ranging from 1.42 for very low to 0.71 fo r very high. These muJtiplie rs reflect the notion that an analys t with ve ry low capa bility e xpe nds 1.42 times as much effort as a nominal or ave rage ana lyst, while o ne with very high capability need s about tluee- quarters the effort o f an average analyst. Similarly, Table 3.13 Lists the cost driver cate- gories for tool use, and the multiplie rs range from 1.17 for very low to 0.78 for ve ry high.

TABLE 3.13 Tool Use Categories

Category

Very low

Low

Nominal

High

Very high

Mea11i11g

Edit, code, debug

Simple front-end, back-end CASE, little integration

Basic life-cycle tools, moderately integrated

Strong, mature life-cycle tools, moderately integrated

Strong, mature, proactive life-cycle tools, well-integrated with processes, methods, reuse

Openmirrors.com

Section 3.3 Effort Estimation 115

Notice that stage 2 of COCO MO II is intended for use during the early stages of design. The set of cost drive rs in this stage is smalle r than the set used in stage 3, reflect- ing lesser understanding of the project's parame te rs at stage 2.

The various components of the COCO MO model are intended to be tailored to fil the c haracte ristics o f your own o rganiz atio n. Tools are available that implemen t COCOMO II and compute the estimates from the project characteristics that you s up- ply. Late r in this chapter, we will apply COCO MO to o ur information system example.

M achine-Learnin g Methods

In the past, most effort- and cost-modeling techniques have re lied on algorithmic methodls. That is, researchers have examined data fro m past projects and gene rated equatio ns from them tbat are used to predict effort and cost o n future projects. H ow- e ve r, some researchers are looking to machine learning for assistance in producing good estimates. For example, neu ral networks can represent a numbe r of interconnected , interdependent units, so they are a promising tool for re presenting the various activities involved in produci ng a software product. In a neural ne twork , each unit (ca lled a neu- ron and represented by netwo rk node) represents an activity; each activity has inputs and o utputs. Each unit of the ne two rk has associate d software that performs an account- ing of its inputs, computing a weighted sum; if the sum exceeds a threshold value, the lllllit produces a n o utput. The output, in tum, becomes :input to other related units in the net- wo rk, until a fina l o utput value is produced by the network. The ne ural network is, in a sense, an e xtension or the activity graphs we examined earlier in this chapter.

There are many ways for a neural ne twork to produce its outputs. Some tech- niques involve looking back to what has happened at othe r nodes; these are called back-propagation techniques. They a re simila r to the me tho d we used with activity graphs to look back and dete rmine the slack o n a path. Othe r techniques look forward , to anticipate what is a bout to happe n.

Ne ural ne tworks aire d eveloped by " training" the m with data from past projects. Relevant data are supplied to tbe netwo rk , and the netwo rk uses forward and back- ward algorithms to " learn" by identi[)'ing patterns in the da ta. For example, historical data about past projects might con tain info rmation abo ut develo per experience; the network may identify relatio nships between leve l of experie nce and the amoun.t o f effort required to compl ete a project.

Figure 3.13 illustrates how Shepperd (1997) used a ne ural ne twork to produce an e ffort estimate. The re are three layers in the ne twork , and the ne two rk has no cycles. The fo ur inputs are factors that can affect effort o n a project; the network uses them to produce e ffo rt as the single output. To begin, th e ne two rk is initialized with random weights. Then, new we ights, ca lculated as a " training set" of inputs a nd o utpu ts based on past his to ry, a re fed to the ne twork. T he user o f the mo del specifies a training algorit hm that explains how the training data are to be used ; this algorithm is also based on past history, and it commonly involves back-propagation. Once the network is trained (i.e ., once the ne twork va lues a re adjusted to re flect past experience), ill: can then be used to estima te effort on new projects.

Several resea rche rs have used back-pro pagatio n algorithms o n similar neural netwo rks to predict d eve lo pme nt effort, including estimati on for projects using

116 Chapter 3 Planning a nd Managing the Project

Problem complexity

Noveltv ol application

Use of design tools

Team size

Input laver Intermediate lavers Output laver

FIGURE 3. 13 Shepperd's feed-forward neural network.

fourth-gene ratio n languages (Wittig and Finnie 1994; Srinivasan and Fisher 1995; Samson, E Uison, and Dilgard 1997). Sheppe rd (1997) reports that the accuracy of this type o f mode l seems to be sensitive to decisio ns about the topology o f the nernal netwo rk , the numbe r o f learning stages, and the initial random we ights of the neurons within tthe ne two rk. The netwo rks also seem to require large training sets in orde r to give good predictio ns. In o the r words, they must be based on a great deal of experi e nce rather tha n a few re presentative projects. Data o f this type are some times difficult to o btain, especially coUected consistently and in large quantity, so the paucity o f da ta lim- its this technique's usefulness. Mo reover, users tend to ha ve difficulty understanding neural networks. However, if the technique produces mo re accura te estimates, o rg ani- zatio ns may be more wiUing to collect data fo r the networks.

In general , this " le arning" approach has been tried in diffe rent wa ys by othe r resea rchers. Srinivasan and Fishe r (1995) used Ke me re r's data (Kemere r 1989) with a sta tistical technique caUecl a regression tree; they prod uced pre dictio ns more accUiate than those o f the o riginal COCOMO model and SLI M, a proprie tary commer cial mode l. H o weve r, their results we re no t as good as those produced by a ne ural ne twork o r a mo d el based o n function po ints. Briand, Basili, and Thomas (1992) obtained be tte r results from using a tree inductio n technique, using the Keme re r and COCOMO datasets. Po rter and Selby (1990) also used a tree-based approach; they constructe d a d ecision tree that identifies which project, process, and product characte ristics may be useful in predicting like ly effo rt. They also used the technique to predict which modules a re like ly to be fa ult-pro ne.

A machine- learning technique ca lled Case-Based Reasoning (CBR) can be applied to a nalogy-based estimates. Used by the artificial intelligence community, CBR builds a decision algorithm based on the seve ral combinations of inputs that might be encountered o n a project. Like the othe r techniques describe d he re, CBR requires informa tion about past p rojects. She ppe rd (1997) points out tha t C BR offers two clear adva ntages over man y o f the othe r techniques. First, CBR deals o nly wi th events t hat actually occur, ra the r than with the much la rger set of all possible occurrences. lbis

Openmirrors.com

Section 3.3 Effort Estimation 11 7

same feature also aUows CBR to deal with poorly understood domains. Second, it is easie r fo r users to understand particular cases than to depict events as chains of rul es o r as neural networks.

Estima tion using C BR invo lves four steps:

1. The user ide ntifies a new problem as a case. 2. The syste m re triev.es similar cases fro m a repository of historical informatio n.

3. The syste m reuses knowledge fro m previous cases. 4. The syste m suggests a solutio n fo r the new case.

The solutio n may be revised , d epe nding on actual eve nts, and the o utcome is placed io the repository, building up the coUection of completed cases. However, there are two big hurdles in crea ting ai successfltl CBR syste m: characterizing cases and determining simila rity.

Cases are characterized based o n the information that happens to be avail able. UsuaUy, experts are asked to supply a list of fea tures that are significant in describing cases and, in particuJar, in dete rmini ng when two cases are similar. ln practice, simiJar- ity is usuaUy measured using an n-dimensional vector of n features. Shepperd , Schofield, a nd Kitchenham (1996) found a CBR approach to be mo re accurate than traditio nal regressio n a nalysis-based algorithmic methods.

Finding the Model for Your Situation

The re a re many effo rt a nd cost models being used to day: comme rcial tools based on past e xperie nce o r intricate mode ls o f developme nt, and home-grown tools that access databases o f historical informatio n a bout past projects. Validating these models (i.e., making sure the mode ls reflect actual practice) is difficul t, because a large amo unt of d ata is needed for the valid ation exercise. Mo reover, if a model is to apply to a large and varied set of situations, the supporting database must include measures from a very large and va ried set o f development enviro nme nts.

Even when you fmd models tha t are desig ned for your development e nviron- me nt, you must be able to evaluate which are the most accurate on your proj ects. There are two statistics tha t are often used to help you in assessing the accuracy, PRED a nd MMRE. PRED(x/100) is the percentage of projects for which the estimate is wi thin x% of the actu al va lue. For most effort, cost, and schedule models, managers evaluate PRED(0.25), tthal is, those models whose estimates are within 25% of the actua l va lue; a mo del is conside red lo funct io n well if PRED(0.25) is greate r than 75% . MMRE is the mean magnitude of re lative e rror, so we ho pe that the MMRE fo r a particula r mode l is ve ry small. Some resea rche rs consider an MMRE of 0.25 to be fairly good , and Boehm (1981) suggests that MMRE should be 0.10 o r less. Table 3.14 lists the best va lues fo r PRED and MMRE re ported in the lite rature for a va riety of models. As you can see, t he statistics for most models are disappointing, indicating llhat no modle l appea rs to ha ve captured the essential characteristics and their relationships for a u ttypes of development. However, the re lationships among cost factors are not simple, aod the models must be flexible enough to handle changing use of tools aod me thod s.

118 Chapter 3 Planning a nd Managing the Project

TABLE 3. 14 Swumary of Model Performance

Model P RED(0.25) MMRE

Walsto n-Felix 0.30 0.48

Basic COCO MO 0.27 0.60

lnte rmediate CO COMO 0.63 0 .22

Inte rmediate COCOMO (variation) 0.76 0 .19

Bailey-Basili 0.78 0.18

Pfieeger 0.50 0.29

SUM 0.06-0.24 0.78-1.04

Je nsen 0.06-0.33 0.70-1.01

COPMO 0.38--0.63 0.23-5.7

Ge ne ral C O PMO 0.78 0 .25

Mo reover, Kitchenham, MacOonell, Pickard, and Sheppe rd (2000) point o ut t hat the MMRE and PRED statistics are no t direct measures of estimatio n accuracy. They suggest that you use the simple ratio o f estimate to actual: estimate/actual. This mea- sure has a distribution tha t directly re flects estima tio n accuracy. By contrast, MMRE and PR ED are measures o f the spread (sta ndard devia tion) and peakedness (kurtosis) o f the ratio, so they te ll us o nJy characte ristics of the distri butio n.

Even whe n estima tio n mo de ls produce reasona bly accurate estimates, we must be able to understand which types of e ffo rt are needed during development. For example , designers may no t be needed until the requireme nts analysts have finis hed d eve loping the specification. Some e ffort and cost models use formulas based on past expe rie nce to apportio n the effort across the software development life cycle. For instance, the o riginal CO COMO mode l suggested effort requiied by development activity, based on percentages aUo tted to key process activities. But, as Figure 3.14 iUus- tra tes, researchers report conflicting values fo r these percentages (Brooks 1995; Yo ur- do n 1982). Thus, when you are building your own database to suppo rt estimation in yo ur o rganizatio n, it is impo rta nt to record no t only how much effo rt is expended o n a project, but also who is d oing it and for what activity.

FIGURE 3.14 Diffe re nt reports of effort distributio n.

Openmirrors.com

Broo~s

Plunint

Yoar~on

Section 3.4 Risk Management 119

3.4 RISK MANAGEMENT

As we have seen, many software project managers take steps to ensure that t!beir projects are done on time and within effort and cost constraints. H owever, project man- age ment involves far more than tracking effort and schedule. Managers must determine whether any unwelcome events may occur during dev elopment or maintenance and make plans to avoid these events or, if they are inevitable, minimize their negative colllSe- que nces. A risk is an unwanted event that has negative conseque nces. Project managers must engage in risk management to unde rstand and control the risks on their projects.

What Is a Risk?

Many e ve nts occur dUiing software develo pment; Sidebar 3.4 lists Boehm's view of some of the riskiest ones. We distinguish risks from other proj ect e vents by looking for three things (R ook 1993):

1. A loss associated with the event. The event must create a situation where some- thing negative happens to the project: a lloss of time, quality, money, con trol, unde rstanding, and so on. For example, if re quireme nts change dramaticalJy after

SIDEBAR 3.4 BOEHM'S TOP TEN RISK ITEMS

Boehm (19<Jl) identifies 10 risk items and recommends risk management techniques to address them. 1. Personnel shortfalls. S taffing with top talent; job matching; team building; morale build-

ing; cross-training; prescheduling key people.

2. Unrealistic schedules and budgets. Detailed muLtisource cost and schedule estimation; design to cost; incremental development; software reuse; requirements scrubbing.

3. Developing the wrong software functions. Organizational analysis; mission analysis; opera-

tional concept formulation; user surveys; prototyping; ea rly user's manuals.

4. Developing the wrong user interface. Prototyping; scenarios; task analysis.

5. Gold plating. Require ments scrubbing; prototyping; cost-benefit analysis; design to cost.

6. Continuing stream of requirements changes. High change threshold; information hiding; incremental development (defer changes to later increments).

7. Shortfalls in externally performed tasks. Reference checking; preaward audits; award-fee coo tracts; competitive design o r prototyping; team building.

8. Shortfalls in externally fumished components. Benchmarking; inspections; reference checking; compatibility analysis.

9. Real-time performance shortfalls. Simulation; benchmarking; modeling; prototyping;

instrumentation; tuning. 10. Straining computer science capabilities. Technical analysis; cost-benefit analysis; prototyp-

ing; reference checking.

120 Chapter 3 Planning and Managing the Project

the design is done, the n the project can suffer from Joss o f control and unde r- standing if the ne w require me nts are for functions or fe atures with which the design team is unfamiliar. And a radical change in require m ents is Likely to le ad to losses of time and money if the design is not flexible e no ugh to be changed quic kly a nd eas ily. The loss associated with a ri sk is called the risk impact.

2. The likelihood that the event will occur. We must h ave som e idea of the probability that the e vent will occur. For example, suppose a project is being developed on one mac hine and will be ported to a nothe r whe n the syste m is fully tested. If the second mac hine is a ne w m ode l to be de live red by the vendo r, we must estimate the Like lihood that it will not be ready on time. The likelihood of the risk, mea- sured from 0 ( impossible) to 1 (certainty) is ca lle d the risk proba bility. Whe n the risk probability is 1, the n the risk is called a [Proble m , since it is certain to happe n.

3. The degree to which we can change the outcom e. For each risk , we must de te rmine what we can do to minimize or avoid the impact of the event. Risk control involves a set o f actions take n to reduce o r eliminate a ri sk. For example, if the requireme nts may change afte r d esign, we ca n minimize the impact of the change by creating a tle xible design . If the second machine is not re ady whe n the software is teste d , we may be able to ide ntify othe r m odels or brands that have the same functionality and performance and can run our ne w software until the new model is delive red.

We can quantify the effects of the risks we ide ntify by multiplying the risk impact by the ris k probability, to yie ld the ris k exposure. For example, i f the likelihood that the require m e nts wilJ c hange afte r design is 0.3 , and the cost to redes ign to new require- me nts is $50,000, the n the ris k e xposure is $15,000. Cle arly, the risk probability can c hange ove r time, as can the impact, so part of a project manager's j ob is to trac k these values over time and plan for the eve nts accordingly.

The re are two major sources of risk: ge ne ric risks and project-specific risks. Ge ne ric risks are those common to alJ software projects, such as misunde rstanding the require m e nts, losing key pe rsonnel, or allowing insufficie nt time for testing. Project- s pecific ris ks are thre ats that result from the particular vulne ra bilities of the given project. For example, a ve ndo r may be promising ne two rk softwa re by a partic ular date, but tbe re is some ris k that the ne twork software will not be ready o n lime.

Risk Management Activities

Ris k manageme nt invo lves several importa nt s te ps, each of which is illustrated in Figure 3 .15. First, we assess the risks o n a project, so that we unde rstand what may occur during the course of de ve lopm e nt o r m ainte nance. ll1e assessme nt consists of three activities: ide ntifyin g the ris ks, a na lyzing the m , a nd assigning priorities to each of the m. To ide ntify the m , we may use many di ffe rent techniques.

II the syste m we are building is similar in som e way to a syste m we have built before, we may have a ch ecklist of proble ms that may occur; we can review the check - lis t to de te rmine if the ne w project is likely to be s ubject to the risk s listed. Fo r systems tbat are ne w in some way, we may augme nt the ch eckli st with an a n alysis of each of the activities in the de velopme nt cycle; by decomposing the process i nto small pieces, we may be able to a nticipa te proble ms that may a rise. For example, we may decide t ha t

Openmirrors.com

Risk assessment

I Risk management

Section 3.4 Risk Management 121

C~ecklill De~omposilion

R' k 'd 'f . Anumpticn mlysis

1 is 1 en ti ieahon Decision driver analysis

Risk analysis System dynamics Per(ormance models

Risk prioritiz11~·on Cost models

\

Network analysis Decision analysis Quality risk hotor m lysis

Risk upome Compoun4 risk re4uction

Buyin9 in(ormation Risk midance Risk t ransrtr \

Risk control 1 Risk reduction Risk reduction I avenge

Doelopment process Risk management planning ~Risk element plannin5

RI k I , Risk plan integration

s reso ul1on --r Risk mili,alion Risk monitoring and reporting Risk reauessmenl

FIGURE 3.15 Steps in risk management (Rook 1993).

there is a risk of the chief designer leaving during the design process. Similarly, we may analyze the assumptions or decisions we make about bow tbe project will be done, wbo will do it, and with what resources. Then, each assumption is assessed to determine the risks invo lved.

FinaUy, we analyze the risks we bave identified , so tbal we can understand as much as possible about when, why, and where they might occur. The re arc many tech- niques we can use to e nhance o ur understanding, including system dynamics models, cost mode ls, pe rformance mode ls, network analysis, and more.

Once we bave itemized all tbe risks, we use our understanding to assign priorities them. A priority scheme enables us to devote our Limited resources only to the most threatening risks. UsuaUy, priorities are based on tbe ris!k exposure, whicb takes into account not o nly Likely impact, but also the probabiLity of occurrence.

The risk exposure is computed from the risk impact and the risk probabi li ty, so we must estimate each of these risk aspects. To see how the quantification is done, consider the analysis depicted in Figure 3.16. Suppose we have analyzed the system develop- ment process and we know we are working unde r tight de adlines for delivery. We have decided to build the system in a series of releases, where each re lease has more func- tionaLity than the one that preced ed it. Because the system is designed so that functions are re lative ly independent, we consider testing only the new functions for a release, and we assume that the existing functions still work as they did before. However, we may worry that there are risks associated with not performing regressio n testing: the assur- ance that existing functionality stiU works correctly.

For each possible outcome, we estimate two quantities: the probability of an unwanted outcome, P(UO), and the loss associated with the unwanted o utcome,

122 Chapter 3 Planning a nd Managing t he Project

P(UO) = o.7S L(UO) = $. SM

Fin~ critical fault

P{UO) = o.os l (UO) = $30M

Don't find critical fault L(UOI = $.OM

P(UO) = 0.20 No critical fao lt

P(UOI = o.2s L(UO) = $.SM

Fin~ critical fau lt

P(UO) = o.ss L(UOI = $30M

Don't find critical fault P(UO) = o.20 l (UOI = $oM

No critical fault

RISK EXPOSURE

$.mM

$1.SOM

$OM

$.12SM

$OM

FIGURE 3.16 E xample of risk ex:posure calculation.

COMBINED RISK

EXPOSURE

$1.87SM

$16.62SM

L(UO). For instance, there are three possible con sequences of pe rfo nning regression testin g: finding a critical fa ult if one e xists, not findi ng the critical fault (even tho ugh it exists), or d eciding (correctly) that the re is no cri tical fault. As the figure illustrates, we have es timated the probabi lity o f the first case to be 0 .75, of the second to be 0.05, and o f the third to be 0.20. The loss associated with an unwanted o utcome is estimated to be $500,000 if a critical fault is found, so that the risk exposure is $375,000. Similarly, we calcula te the risk exposure for the o ther branches of this decisio n tree, and we find rthat o ur risk e xposure if we perform regressio n testing is almost $2 million. Howeve r, the same kind of analysis sh ows us that the risk exposu re if we do not pe rform regression testing is almost $17 miUion. Thus, we say (loosely) that mo re is at risk if we do no t p er- fo rm regressio n testing.

Risk exposure he lps us to list the risks in prio rity o rde r, with t he risks of most con- cern given the highest priority. Next, we must take steps to control the risks. The n ortion o f control acknowledges that we may not be able to e li minate all r:isks. Instead, we may be a ble to minimize the risk o r mitigate it by taking actio n to ha ndle the unwan ted o ut- come in a n acce ptable way. The refore, risk control in volves risk reducti on, risk plan - ning, an d risk resolution.

The re are three strategies for risk reductio n:

• a voiding the risk, by cha nging requireme nts fo r performance or functio nality

• transfe rring the risk , by allocating risks to other systems o r by buying insurance to cove r any financiaE loss sho uld the risk beco me a reality

• assuming the risk, b y accepting it and controlling it with the project's resources

Openmirrors.com

Section 3.5 The Project Plan 123

To aid decisio n making abo ut risk reduction , we must take into account the cost of reducing the risk. We call risk leverage the difference in risk exposure di vided by the cost of reducing the risk. In other words, risk re duction leverage is

(Risk exposure be fore reducti on - risk exp osure after redu ction ) /(cost of risk reduction )

If the leverage value is n ot high e nough to justify the action, the n we can look fo r other less costly o r more e ffective reducti on techniques.

In some cases, we can choose a development process to help reduce the risk. For example, we saw in Chapter 2 that prototyping can improve understanding of the require- ments and design , so selecting a prototyping process can reduce man y project risks.

It is use ful to record decisions in a risk management plan, so th at both customer and developme nt team can re view how problems are to be avoided, as well as how they are to be handled should they arise. Then , we should monitor the project as development progresses, periodically reevaluating the risks, their probability, and their likely impact.

3.5 THE PROJECT PLAN

To communicate risk anal ysis and management, project cost estimates, schedule, and o rganiz ation to our custome rs, we usuaUy write a document ca lled a proj ect plan . The plan puts in writing the custome r's needs, as we U as what we ho pe to do to meet them. The custo me r can re fe r to the plan fo r informatio n abo ut activities in the develo pme nt process, making it easy to follow the project's progress during d evelo pment. We can a lso use the plan to con.firm with the custome r any assumptions we are making, espe- cially about cost and schedule .

A good proj ect plan includes the following items:

1. project scope

2. project sche dule 3. project team o rganiza tion 4. technical description o f the proposed system 5. project standards, p rocedures, and p roposed techniques and tools 6. quality assurance plan

7. configuration management plan 8. docume ntati o n pla n 9. da ta manage me nt pl an

10. resource manage me nt plan 11. test plan 12. training pl an 13. security pl an 14. ris k ma nagement pl an 15. mainte na nce plan

124 Chapter 3 Plan ning a nd Managing the Project

The scope de fines the system boundary, explaining what wi U be included in the system and what will nol be included. It assures the customer that we understand what is wanted. The schedule can be expressed using a work breakdown structure, the de liv- erables, and a timeline to show what will be happening at each point during the project lire cycne. A Gantt chart can be useful in illustrating the parallel nature of some of the deve lopmen t tasks.

The project plan also lists the people o n the development team, bow they are o rganized, a nd what they will be doing. As we have seen, not everyone is needed all the time dming the project, so the pla n usually contains a resource allocation chart to show staffing levels at diffe re nt times.

Writing a technical description fo rces us to answer questions and address issues as we a nticipate how development will proceed. This descripti on Lists hardwa re and software, including compile rs, interfaces, and special-purpose e quipment or software. Any special restrictions o n cabling, e xecutio n time, response time, security, o r other aspects of functionality o r performance a re docume nted in the plan. The plan also lists any stamdards or me thods th at must be used, such as

• algorithms • too ls • review o r inspectio n techniques

• design languages o r re presentations • coding la nguages • testing techniques

For large projects, it may be appropriate to include a separate quality assurance pla n, to describe bow reviews, inspectio ns, testing, and other techniques will help to evaluate q uality and ensure that it meets the customer's need s. Similarly, large projects need a configuration manageme nt plan, especially whe n there are to be multiple ver- sio ns and releases o f the system. As we will see in Chapte r 10, configuration manage- me nt he lps to contro l multiple copies of the softwa re. TI1e configuration manage men t plan teUs the custome r how we will track changes to the requirements, design, code, test plans, and documents.

Many documents a re p roduced du ring developme nt, especially for large projects whe re info rmation abou t the design must be mad e available to project team membe rs. The proj ect plan lists the documents that will be produced , explains who will write the m and when, a nd , in conce rt wi th the configuration manageme nt plan, describes how docume nts will be changed.

Because every software system involves data for input, calc ulatio n, and output, the project plan must explain bow data will be gathered, stored, manipuJated , and archived. The plan sho uld also explain how resources will be used. Fo r example, if the hardware configuratio n includes re movable disks, then the resource management p art of the project plan should explain what data are on each disk and how the disk packs or diskettes wiU be a llocated a nd backed up.

Testing requires a great deal o f planning to be effective, and the project plan describes the project's overall approach to testing. In particular, the plan should state

Openmirrors.com

Sectio n 3.6 Process Models and Project Management 125

bo w test da ta will be gen erated, how each program module will be tested (e.g., by test- ing a U paths o r all state me nts), how program modules will be integrated with e ach o the r and tested, h ow the entire system will be tested , and who will perform each type o f testing. So me times, syste ms are produced in stages or phases, and the test p lan sho uld exp lai n how eacb stage will be tested. Whe n new functio nali ty is added to a sys- te m in stages, as we saw in C hapte r 2, then the test plan must address regression testing, e nsuring that the existin g functionality stiU wo rks correctly.

Training classes and documents a re usually prepared during develo pment, rat her tha n a fter the syste m is complete, so that training can begin as soon as the system is ready ( and some times before). The project plan explains how training wiU occur, describing e ach class, suppo rting software and docume nts, and the expertise need ed by each stude nt.

When a syste m has securi ty requiremen ts, a sep ara te securi ty plan is sometimes needed. The security plan addresses the wa y that the system wiU protect data, users, and ha rdware. Since security involves confidentia Lity, availabili ty, and integrity, the p lan must explain how each face t of security affects system development. For example, if access to the syste m will be limited by using passwords, then the plan must describe who issues and maintai.ns t he passwords, who develops the password-handLing soft- ware, and wha t the password encryptio n sch eme wiU be.

FinaUy, if the project te am wiU maintain the syste m after it is d elivered to the user, the project plan sho uld discuss responsibilities for changing the code, re pairing the ha rdwa re, and upda ting supporting documen ta tio n and training m ateria ls.

3 .6 PROCESS MODELS AND PROJECT MANAGEMENT

We have see n how diffe rent aspects of a proj ect can affect the effort, cost, and schedule require d, as we U as the risk s involved. Man agers most successful at building quality products o n time and within budget are those who tailo r the project man agement tech- niques to the particular characteri stics of the resources needed , the chosen process, and the people assigned .

To unde rstand what to do on your next p roject, it is useful to examine project manage ment techniques used by su ccessful projects from the recent past. lo this sec- tio n, we look at two proj ects: Digital's A lph a AXP program and t!he F-16 aircraft soft- ware. We a lso investigate the merging o f process a nd project man agement.

Enrollment Management

Digital Equipme nt Corpora tion spent many years developing its Alpha AXP system , a new system arclLitecture and associated products that formed th e la rgest project in Dig- ital's his tory. The software po rtion of the effort involved four ope rating systems a nd 22 softwar e engineering groups, whose roles include d designing migration tools, network systems, compilers, databases, integration frameworks, and applications. Unlike many o ther d evelopment projects, the maj or p roblems with Alpha involved reaching mile- sto nes too early! Thus, it is instructive to look at bo w th e project was ma naged and what e ffec ts the manage me nt p rocess had on the fin al product.

126 Chapter 3 Plan ning a nd Managing the Project

During the course of development, the project managers developed a mo del t hat incorpo rated fou r tene ts, ca lled the Enrollment Manage me nt mod el:

1. establishing a n appropria tely large shared vision 2. de lega ting completely and e liciting specific commitments from pa rticipants 3. inspecting vigoro usly and providing supportive feedback 4. acknowledging every advance and learning as the program progressed (Conklin

1996)

Figure 3.17 illustrates the mode l. Vision was used to "enroU" the related pro- g rams, so they all sha red common goa ls. Each group or subgroup o f the project defined its own object ives in te rms of the global ones stated for the project, including the com- pany's business goals. Next, as managers developed plans, they delegated tasks to groups, soliciting comme nts and commitments about the content of each task and the scheduEe constraints imposed. Each requi red result was measurable and identified with a particular owne r who was held accountable fo r delivery. The owner may no t have been the pe rson doing the actual work; rather, he or she was the person responsible for getting the work done.

Managers continually inspected the project to make sure that delivery would be on time . P roject team me mbers were asked to iden tify risks, and when a risk th reatened to keep the team fro m meeting its commitme nts, the project manage r declared the project to be a "cusp": a critical event. Such a declaration meant that team members were ready to make substantial changes to help move the project forward. For each project step, the managers acknowledged progress both personally and publicly. They recorded what had been lea rned and they asked team me mbers how things could be improved the ne xt time.

Coordinating all the ha rdware and software groups was difficu lt, and managers realized that they had to oversee both technical a nd project events. That is, the tec!hni- cal focus involved technical design and strategy, whereas the project focus addressed

FIGURE 3. 17 Enrollment Management model (Conklin 1996).

Personal Public

E ncoura5ement

Openmirrors.com

Bus ineu goal$ Project objectives

VISION ENROLLMENT

T mt Acmnhbility (tas~-owner-~ate)

Section 3.6 Process Models and Project Management 127

System board o/ directors

:········ ............. . ! Project ! ! mana1ers : ~--······ ........... :

!, ... ··~~~~·~;~:;····1:. directors

~-- ................. :

FIGURE 3.18 Alpha project organization (Conklin 1996).

commitments and deliverables. Figure 3.18 illustrates tbe organizatio n tha t allowed both foci to contribute to the overall program.

The simpLicity of the model and organization does not mean that managing the Alpha program was simple. Several cusps threatened the project and were deal t with in a variety of ways. For example, management was unable to produce an overall plan, and project managers h ad difficulty coping.At the same time, technical leade rs we re gener- ating unacceptably large design documents that we re difficult to unde rstand. To gain control, the Alpha program managers needed a programwide work plan that illustrated the o rde r in which each contributing task was to be done arnd how it coordinated with the other tasks. They created a master plan based o nly on the critical program components- those things that were critical to business success. The plan was restricted to a single page, so that the participants could see the " big picture," without complexity or detail. Similarly, one-page descriptions of designs, schedules, and other key items enabled project partici- pants to have a global picture of what to do, and when and how to do it.

Anothe r cusp occurred whe n a critical Lask was announced to be several months behind schedule . The manage me nt addressed this proble m by instituting regular o pe ra- tional inspections of progress so there would be no more surprises. The inspection invo lved prese ntation of a o ne-page report, itemizing ke y points about the project:

• schedule • milestones • critical path eve nts in the past month • activities a lo ng the critica l path in the next month • issues and de pe ndencies resolve d • issues and depe ndencies no t resolved (with ownership and due dates)

An important aspect of Alpha's success was the managers' rea lizatio n that engi- nee rs are usually motivated more by recognition than by financial gain. Instead of rewa rding participants with mo oey, they focused on announcing progress and o n mak- ing sure that the pubLic kne w how much the managers appreciated the engineers' work.

128 Chapter 3 Planning and Managing the Project

The result of AJpl:ia 's flexible a nd focused management was a program that met its sche dule to tbe morntb, despite setbacks along the way. Enrollment management e nable d small groups to recognize their potential problems early and take steps to handle them while the problems were small and localized. Constancy of purpose was combined with concinua l learn ing to produce an exceptio nal produce. Alpha met its performance goals, and its quality was reported to be very higb.

Accountability M odeling

The U.S. Air Force and Lockheed Martin formed! an Integrated Product Developmen t Team to build a modular software system designed to increase capacity, provide needed functionality, and reduce the cost and schedule of future software ch anges to the F-16 aircraft. The resulting software included more tha n fo ur million lines of code, a quarter of which met re al-time deadlines in flight. F-16 deve lopment also involved building device drive rs, re al-time extensions to the Ada run-time system, a software engineering workstation network , a111 Ada compile r for the m odular missio n computer, software build and configuration managemen t tools, simulation and test software, and inte rfaces fo r loading software into tbe airplane (Parris 1996).

The ftight software's capability requirements were well-understood and stable, even though about a million lines o f code were expected to be needed from the 250 develo pers organized as e ight product teams, a chief engineer, plus a program manage r and staff. However, the familiar capabilities we re to be implemented in an unfamiliar way: modular software using Ada and object-oriented design and analysis, plus a transition from mainframes to workstations. Project manageme nt constraints include d rigid "need dates" and commitment to developing three re leases o f equal task size, called tapes. The approach was high risk, because the first tape included Little time for learning the new methods and too ls, including concurrent development (Parris 1996).

Pressure on the project increased because funding levels were cut and schedule deadlines were conside red to be extremely unrealistic. In addition, the project was o rganized in a way unfamiliar to most of the eng ineers. The participants were used to working in a matrix organization, so that eacb en ginee r belonged to a functional 11.lllit based on a type of skill (such as the d esign group or the test group) but was assigned to o ne or more projects as that sk ill was needed. In othe r words, an employee could be identifie d by his or ber place in a matrix, wi th functional skills as one dimension and project names as the othe r dimension. Decisio ns were made by the functional unit hier- archy in this traditional organization. However, the contract for the F-16 required the project to be o rga nized as an integrated product developme nt te am: combining indi vi d - uals from different functional groups into a n interdiscip linary work unit empowe red with separate channels of accountab ility.

To e nable the project members to handle the culture change associated with the ne w organization, the F-16 project used the accountability model sh own in Figure 3.19. In the model, a team is any collection o f people responsible for producing a given result. A stakeholde r is anyone affected by that result or tbe way in wbich the resu lt is achieved. Tue process involves a continuing exchange of accountings (a report of what you bave done, are doing, or plan to do) and conseque nces, with the goa l of doing only

Openmirrors.com

Section 3.6 Process Models and Project Management 129

DESIRED RESU LTS

TEAM

CONSEQUENCES • clarlflcatlon or dj utt111ent

of expectlont • utlttance • direction • reinforcement (positive or negative)

FIGURE 3.19 A ccountability model {Parris 1996).

what makes sense fo r both the team and the stake ho ld ers. The model was ap plied to the design of manageme nt systems and to team ope rating procedures, repladng indepen- de nt behavio rs with inte rde pendence, emphasizing " being good rat he r than looking good" (Parris 1996).

As a result, seve ral practices were required, including a weekly, o ne -hour team status revie w. To re inforce the n otions of responsibility and accounta bility, each pe rsonal action ite m had explicit closure criteria and was tracked to completion. An actio n item couJd be assigned to a team membe r or a stakeho lder , and o ften invo lved cla rifying issues or re quirements, p roviding missing info rma tion o r reconcil- ing confiicts.

Because the te ams had multiple, ove rlapping activities, an activity map was used to illustrate progress on each activity in the ove rall context o f the p roject. Figure 3.20 shows part o f an activity map. You can see bow each bar re presents an activity, and each activity is assigned a me thod for reporting progress. The point on a bar indicates when de tailed planning sho uJd be in place to guide activities. The " to da y" line sh ows current status, a nd a n ac tivity map was used during the weekl y re views as a n o ve rview o f the progress to be d iscussed.

Fo r each activity, progress was tracked using an appropria te evaluatio n or pe rfo r- mance me thod. So me times the method included cost estimatio n, critical path analysis, or scheduJe tracking. Earne d value was used as a common measure fo r comparing progress o n differe nt activities: a scheme for comparing activities de te rmined how much o f the project had been completed by each activity. The earned-value calcuJation included we ights to re present what percent o f the to tal process each step constituted , rela tive to overall e ffo rt. Similarly, each componen t was assigned a size value that

130 Chapter 3 Planning and Managing the Project

To41y

Prior 199S 1996 ind Oct: Nov Dec Jan Feb Mar Apr May Jrun Jul Aug Sep Oct Nov Dec 10

on :

I Ttpe 2 problem rm lution (PPL) I . """"""-- Tape 3 eo~e (EVS ) I . . ~ . .

I Tape 3 prohlem rm lution [PPL) : ~ Throughput and memory recovery (TPP} I , ........................................................

{ ,.~ " '"'"'' I : Reportln5 11ef~o41: : EVS Eme4 ~alue 11ttu1l19

detisn ( EVS) : PPL Prlorltlze4 problem list

L ~~~. !~~~~,~~ ~ P~~-o!~!~~~ !! ~ Tepe UI code (EVS} I

.......

lft

~ T 1pe U2 uptbil ity size

I estim1tes (EVS} I Tape UI probfe·m ruofvtion(PP L) FIGURE 3.20 Sample activity roadmap (adapted from Parris 1996).

re prese nted its pro po rtio n o f the total product, so that progress rel.alive to the final size could be tracked , too. Then, an e arned-value summary chart, simila r to Figure 3.21, was presented at each review meeting.

Once part o f a product was completed, its progress was n o longer track ed. lnstead , its performance was tracked, and problems were recorded. Each problem was assigned a prio rity by the stake ho lde rs, and a snapshot o f the to p fi ve problems on e ach product team's list was presented at the weekly re view meeting for discussion. The pri- o rity lists generated discussion about why the pro blems occurred , what work-arounds could be put in place, and how simila r problems could be prevente d in the future.

The project managers found a maj or problem with the accountability mo de l: it to ld the m no thing a bout coordinatio n among differe nt teams. As a result, they built software to catalog and track the hand-o ffs from one team to another, so that every team could unde rstand who was wai ting for actio n or p roducts from them. A mo de l of the ha nd-offs was used for planning, so th at undesira bl e pa tte rn s or scenarios could be e lim in ated. Thus, an exa minatio n o f the band-off model became part of the review process.

It is easy to see ho w the accountability mod el, coupled with the hand -off mo de l, addressed several aspects of project managemernt. First, it provided a mechanism for communicatio n and coordination. Seco nd, it encouraged ri sk man agement, especially by forcing te am membe rs to examine problems in review meetings. And third , it inte - gra ted progress repo rting with proble m solving. Thus, the model actuaJJy prescribes a project manage me nt process that was fo llowe d on the F-16 p roject.

Openmirrors.com

Section 3.6 Process Models and Project Management 131

3000

-c 0 2SOO ... .. c

2000

~ .. ISOO ~ .! ~ 1000 c ~

.~ .. soo ... ...

··----· Plufte~ completions

-- Actual completions

TODA'!'

:

1 2 3 4 S 6 7 8 9 10 II 12 13 14 IS 16 17 13 19 20

Week

FIGURE 3.21 Example earned-value summary chart (Parris 1996).

Ancho ring Milest o nes

In Chapter 2, we examined many process models that described how the technical activities of software develo pment should progress. The n, in this chapte r, we looke d at seve ral me thods to organize projects to pe rfo rm th ose activities. The Alpha AXP and F-16 examples have shown us that project management must be tjgbtly integrated with the develo pment process, not just for tracking progress, but, more impo rtantl y, fo r e ffective planning and decisio n making to prevent majo r pro blems from derailing the project. Boehm (1996) has identified three milesto nes common to au software development processes that can serve as a basis for bo th technical process and project manageme nt:

• life-cycle objectives • life-cycle architecture • initi al o perational capability

We can examine e ach milestone in mo re d etail. The purpose o f the life-cycle o bjectives milestone is to ma ke sure the stakehold -

e rs agree with the system 's goals. The key stakeho lders act as a te am to de termine the system bo undary, the en vironment in wruch the syste m will ope rate, and the e xternal systems with which the system must interact. Then , the stakeholde rs work through sce- narios o f bo w the system wiU be used. The scena rios can be expressed in terms of proto- types, scree n layouts, data Hows, o r o the r represe ntatio ns, some o f which we will learn a bout in late r chapters. If the system is business- o r safe ty-critical, the scenarios shou ld also include instances whe re the system fails, so that designe rs can dete rmine bo w the

132 Chapter 3 Planning and Managing the Project

syste m js supposed to re act to or even avoid a critical failure. Similarly, other essential features o f the system are derived and agreed upon. The result is an initial life -cycle plan that Jays out (Boehm 1996):

• Objecti ves: Why is the syste m being deve loped? • Milestones and schedules: What wiU be do ne by when? • Responsibilities: Wbo is responsible for a function? • Approach: How will the jo b be done, technically and managerially? • Resources: Ho w much o f each resource is needed ? • Feasibility: Can thi s be done, and is there a good business rea son fo r doing it?

The life-cycle architecture is coordinated with the life-cycle objectives. 1be p ur- pose o f the life-cycle architecture milestone is de fining both the system and the soft- ware architectures, the components o f whi ch we will study in Chapte rs 5, 6, and 7. The architectural choices must address the project risks addressed by the risk manageme nt plan, focusing o n system evo lution in the Jong term as we ll as system re quireme nts in the short te rm .

The key e leme nts o f the initial ope rational capa bility are the readiness of the soft- wa re itself, the site a t which the system will be used, a nd the selection a nd training of tbe team that will use it. Boe hm notes that diffe rent processes can be used to imple - me nt the initial operatfona l capabiUty, and diffe rent estimating techniques can be applied at diffe re nt stages.

To supple ment these milestones, Boehm suggests using ilhe Win- Win spiral model, illustrated in Figure 3.22 and intended to be an extension of the spiral model we e xa mine d in Chapter 2. The model e ncourages participants to con ve rge on a common unde rstanding of the system's next-level objectives, al terna ti ves, and constraints.

Boehm applie d Win-Win, call ed the Theory W approach, to the U.S. De partme nt o f Defe nse's STARS program, whose focus was de veloping a set o f prototype software

I. Identify next-level stakeholders.

7. Review, commitment.

6. Validate product and process definitions.

2. Identify stakeholders' win conditions.

S. Define next level ol product and process· including partitions.

win conditions. Establish nu t·

4. Evaluate product ~nd process a lternati~es. Resolve risks.

FIGURE 3.22 Win- Win spiral model (Boehm 1996).

Openmirrors.com

Section 3.7 Information Systems Example 133

e ngineering e nvironments. The proj ect was a good candidate for Theory W, because there was a great mismatch between wbat the gove rnment was planning to build and what the po te ntial users needed and wanted. The Win-Win mode l led to several key compromises, including n ego tiation of a set of common, open interface specifications to e nable t ool ve ndo rs to re ach a larger ma rketplace at reduced cost, and the inclusion of three de monstration projects to reduce risk. Boehm re ports tbat Air Force costs o n the project we re re duced from $140 to $57 per deLivere d line of code and that quality improve d from 3 to 0.035 faults per thousand delive red lines of code. Several other projects re po rt similar success. TRW developed over half a millio n Jines of code fo r oom- plex distributed software within budget and schedule using Boebm's milestones with five increme nts. The first increment included distribute d ke rnel software as part of the life- cycle architecture milestone; the project was re quired to demonstrate its ability to meet projectio ns that the own ber of requirements wo uld grow over time (Royce 1990).

3 .7 INFORMATION SYSTEMS EXAMPLE

Let us re turn to the PiccadiUy Te levisio n airtime sales system to see how we might esti - mate the amount of effort required to build the software. Because we are in the prelim- inary stages o f unde rstanding just what the software is to do, we ca111 use COCOMO Il 's initial e ffo rt model to suggest the number of person-months needed. A person-mo nth is the amount of time one person spends working on a softwa re d evelopment project fo r one mo nth. The COCOMO mode l assumes that tbe numbe r of person -months does not include ho Udays and vacations, no r time o ff at weekends. The number of pe rson- mo ntbs is not the same as the time n eeded to fini sh building the system. For insta nce, a system may require 100 person-months, but it can be finished in o ne month by having te n peo ple work in parallel for one month , or in two mo nths by having five people work in paralJel (assuming that the tasks can be accomplished in that manne r) .

The first COCOMO II model, appLication composition , is de signed to be used in the earliest stages of development. He re, we compute application points to help us determine the likely size of the project. lbe applica tion point count is determined from three calcula tions: the numbe r of se rver data tables used with a screen or report, the number of client data tables used with a screen or report, and the p ercentage of screens, re ports, and modules reused fro m previous applications. Let us assume that we are not reusing any code in building the Piccad1Uy system. Then we must b egin our estimation process. by predicting bow many screens and reports we will be using in this application. Suppose o ur initial estimate is that we need three screens and o ne report:

• a booking screen to record a new adve rtising sales booking • a ratecard scree n s howing the advertising rates for e ach day and hour • an availability screen showing which time slots are available • a sales re port showing to tal sales for the month and year, and comparing them

with previous months and years

For each screen or report, we use the guidance in Table 3.10 and an estimate of the number of data tables n eeded to produce a description of the screen or report. For example, the booking scr een may req uire the use of three data tables: a table of available

134 Chapter 3 Planning and Managing the Project

TABLE 3.15 Rating.-; for Piccadilly Screens and Reports

Name Screen or Report Complexity Weight

Booking Screen Simple 1

Ratecard Screen Simple 1

Availability Screen Medium 2

Sales Report Medium 5

time slots, a table o f past usage by this customer, and a table o f the contact information for this customer (such as name, address, tax numlber, and sales representative handling the sale). Thus, the number of data tables is fewer than four, so we must decide whether we need more than eight views. Since we are likely to need fewe r than e ight views, we rate the booking screen as "simple" according to the applica tion point table. Similarly, we may rate the rateca rd screen as "simple," the availability screen as "medium," and the sales re port as " medium." Ne xt, we use Table 3.11 to assign a complexity rate of 1 to simple screens, 2 to medium scree ns, and 5 to medium reports; a summary of our ratings is shown in Table 3.15.

We add all the weights in the rightmost colwnn to generate a count of new appli- cation points (NOPS): 9. Suppose our developers have low experience and low CASE maturity. Table 3.12 tells us that the productivity ra te for this circumstance is 7. Then the COCO MO model te lls us that the estimated e ffort to build the Piccadilly syste m is NOP divided by the productivity rate, or 1.29 person-months.

As we unde rstand more about the require me nts fo r Piccadilly, we can use the ot her parts of COCOMO: the early design model and the postarchitecture model, based o n nominal e ffort estimates derived from lines of code o r function points. These models use a scale exponent computed from the project 's scale factors, listed in Table 3.16.

TABLE 3.16 Scale Factors for COCOMO II Early Design and Postarchitecture Models

Scale Factors Very Low Low Nominal High Very High Extra High

Precedentedness TI10roughly Largely Somewhat Generally Largely Thoroughly unprecedented unprecedented unprecedented familiar familiar familiar

Flexibility Rigorous Occasional Some General Some General relaxation relaxation conformity conformity goals

Significant risks Little (20%) Some(40%) Often (60%) Generally Mostly Full (100%) eliminated (75%) (90%)

Team interaction Very difficult Some difficult Basically Largely Highl y Seamless process interactions interactions cooperative cooperative cooperative interactions

inte ractions

Process Determined by Detennined by Determined by Determined by Determined by Determined by maturity questionnaire questionnaire questionnaire questionnaire questionnaire questionnaire

Openmirrors.com

Section 3.8 Real-Time Example 135

"Extra high" is equivale nt to a rating of zero, "very high" to 1, "high" to 2, " no mi- na l" to 3, " low" to 4, and " ve ry low" to 5. Each o f the scale facto rs 1s rate d, and the sum o f all ra tings is used to weight the initial effort estimate . For example, suppose we know that the type o f application we are building for Piccadilly is gene raLiy familiar to the deve lopment team; we ca n rate the first scale factor as ·' high." Similarly, we may ra te fle xibility as "very bigh," risk resolution as "n ominal," team inte raction as "high," and the maturity rating may turn out to be " low." We sum the ratings (2 + 1 + 3 + 2 + 4) to get a scale factor o f 12. The n, we compute the scale exponent to be

1.01 + 0.01(12)

o r 1.13. This scale expo nent te Us us that if our initiaJ effort estimate is 100 pe rson- montbs, the n o ur ne w estimate, relative to the cha racteri stics re flected in Table 3.16, is 1001· 13, or 182 person-months. In a similar way, the cost dri vers adjust this estimate based o n characte ristics such as tool usage, analyst expertise, and reliability require- ments. Once we calculate the adjustment facto r, we multiply by our 182 person-months estimate to yie ld an adjusted e ffort estimate.

3 .8 REAL-TIME EXAMPLE

'The boa rd investiga ting the Ariane-5 failure examined the software, the documen ta- tio n, and the data captur ed before and during flight to dete rmine what caused the fa il- ure (Li ons e t al. 1996). Its report notes that the launcher began to disintegra te 39 seconds a fte r takeo ff because the angle of attack exceeded 20 d egrees, causing the booste rs to sepa rate from the main stage of the rocke t; this sepa ra tion triggered the launche r's self-destructi on. The angle of attack was de termined by soft ware in the o n- board computer on the basis o f data transmitted b y the active inertial reference system, SRI2. A s the re po rt no tes, SRI2 was supposed to contain valid Hight data, but instead it contained a diagnostic bit pattern that was interpreted erroneously as Hight data. The e rro neous da ta bad been declared a failure, and the SRI2 bad been shut off. Norma Uy, the on-board computer wo uld h ave switched to the o ther inerti al reference system, SRil, but that, too, had been shut down for the sa me re ason.

The e rror occurred in a so ftwa re module that compute d me aningful results o nly before lift-o ff. As soon as the launcher lifted off, the function performed by this module served :no useful purpose, so it was no longer needed by the rest of the system. H ow- eve r, tbe module continued its computations fo r approxim ate ly 40 seconds of ftight based o n a requireme nt for the Ariane-4 that was n ot needed for Ariane-5.

The inte rnal eve nts that led to the failure we re re produced b y simulation calcula- tio ns suppo rted by me mory re adouts and examination o f the soft ware itself. Thus, the Ariane-5 destruction might have been pre vented had tbe project managers developed a risk manage ment plan, revie wed it, and developed ri sk avoidance or mitigation plans for each identified risk. To see h ow, consider again the steps of Figure 3.15. The first stage of risk assessme nt is risk identificati on. The possible proble m with reuse of the Ariane-4 soft ware might bave been ide ntified by a d ecomposition o f the functions; someone might have recognized early on that the requirements for A riane-5 were

136 Chapter 3 Planning and Managing the Project

diffe rent from Ariane-4. Or an assumption analysis might have revealed that the assumptions for the SRI in Ariane-4 we re different from those for Ariane-5.

Once the risks were identified, the analysis phase might have included simula- tions, which probably would have higWighted the problem that eventually caused the rocket's destruction. And prioritization wouJd have identi.fied the risk exposure if the SRI did not work as planned; the high exposure might have prompted the project team to examine the SRI and its workings more carefully before implementation.

Risk contro l invo lves risk reduction, management planning, and risk resolutio n. Even if the risk assessme nt activities had missed the proble ms inherent in re using the SRI from Ariane -4, risk reduction techniques including risk avoidance analysis ntight have noted that both SRis could have been shut down for the sa me unde rlying cause. Risk avoidance might have involved using SRis with two diffe rent designs, so that the d esign e rror would have shut down o ne but not the other. Or the fact that the SRI cal- culations we re not needed after Lift-off might have prompted the designe rs or imple- mente rs to shut down the SRI earlier, before it corrupted the data for the angle calculations. Similarly, risk resolution includes plans for mitigation and continual reassessment of risk. Even if the risk of SRI failure had not been caught ea rlie r, a risk reassessment during design o r even during unit testing might have re ve aled the pro b- lem in the middle of development. A redesign or development at that stage wo uld h ave been costly, but not as costly as the complete loss of Ariane-5 on its maiden voyage.

3.9 WHAT THIS CHAPTER MEANS FOR YOU

This chapter bas introduce d you to some of the k ey concepts in project manageme nt, including project planning, cost and schedule estimation , risk manage ment, and team organization. You can make use of this information in many ways, even if you are not a manage r. Project planning involves input from all team membe rs, including you, and unde rstanding the planning process and estimation techniques gives you a good ide a of how your input will be used to make decisions for the whole team. AJso, we have seen how the numbe r o f possible communication paths grows as tbe size of the team increases. Yo u can take communication into account when you are planning your wo rk and estimating the time it will take you to complete your next task.

We have also seen how communication styles differ and how they affect the way we interact with each othe r on the jo b. By understanding your teammates' styles, you can create re ports and prese ntations for them that match their e xpectations and needs. You can prepare summary information for p eople with a bottom-line style and offe r complete analytica l informatio n to those who are ratio nal.

3.10 WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM

At the same time, you have learned how to organize a development team so that tea m interaction he lps produce a better product. There are seve ral choices for team structure, from a hierarchical chi ef programmer team to a loose, egoless approach. Each has its benefits, and each depe nds to some d egree on the uncertainty and size of the project.

Openmirrors.com

Section 3.13 Key References 137

We have also see n bow the team can work to anticipate and reduce risk from the project's beginning. Redundant functionality, team reviews, and other techniques can he lp us catch e rrors early, before tbey become embedded in the code as faults waiting to cause failures.

Similarl y, cost estimation should be don e early and often , i.ncluding input fro m te am membe rs about progress in specifying, designing, coding, and testing the system. Cost es timation and risk manageme nt can work hand in band; as cost estimates raise concerns about finishing on time and within budget, risk management techniques can be used to mitigate or eve n eliminate risks.

3 .11 WHAT THIS CHAPTER MEANS FOR RESEARCHERS

This ch a pte r has described many techniques that still requi.re a gre at deal of resea rcb. Little is known about which team organizations work best in which situations. Like- wise, cost- and schedule -estimation models are not as accurate as we would Like them to be, and improve ments can be made as we learn more about how project, process, prod- uct, and resource characte ristics affect our efficie ncy a nd productivity. Some metho ds, such as machine learning, look promising but require a great d eal of historical data to make them accurate. Rese arche rs can help us to understand how to balance practicali ty with accuracy whe n using estimation techniques.

Similarly, a great deal of research is needed in making risk management tech- niques practical. The calculatio n of risk exposure is currently more an art than a sci- e nce, and we need me thods to he lp us make our risk ca lculations m ore re levant and our mitigation techniques more effective .

3 .12 TERM PROJECT

Often, a company or organization must estimate the effort and time required to com- plete a project, even before de tailed requireme nt s are prepared. Using the approaches described in this chapte r, or a tool of your choosing from othe r sources, estima te the e ffort re quired to build the Loan Arranger syste m. How many people will be required ? What kinds of skills should they have? H ow much expe rience? What kinds of tools or techniques can you use to shorte n the amount of time that deve lopment will take?

You may want to u se more than one approach to generate your esti.roates. If you do, then compare and contrast the results. Examine each approach (its models and assumptions) to see what accounts fo r any substantial differences among estimates.

O nce you have your estimates, evaluate the m and the ir unde rlying assumptions to see how much unce rtainty exi sts in them. The n, perform a ri sk analysis. Save your results; you ca n exa mine the m at the e nd of the project to see which risks turned into real proble ms, and which on es were mitigated by your chosen risk strategies.

3 .13 KEY REFERENCES

A great deal of in fo rmation about COC O MO is available from the Center for Software E ngineering at the University of Southern CaJiforoia. The We b site, http://suoset. usc.

138 Chapter 3 Planning a nd Managing the Project

edu/csse/research/COCOMOil/cocomo_main.html, points to curren t research on CO CO MO, including a Java impleme ntation of CO CO MO II. It is at this site that you can also find out abou t COCOMO user-gro up meetings and o btain a copy o f the CO COMO II user's manual. Re lated info rmatio n about functio n points is available fro m IFPUG, the Inte rnational Functio n Point User Group, in Westerville, Ohio.

The Center for Software Engineering also performs research o n risk manage- me nt. You can ftp a cop y o f its So ftware Risk Technical Advisor at ftp://usc.edu!pub/ soft_engineeringtd emos/stra.ta r.z and read a bout curre nt research at http://sUI11set. usc.edu.

PC-based tools to support estimatio n are d.escribed and a vailable from the Web site for Bo urnemo uth U nive rsity's Empirical Software Engineering Research Group: http://d ec. bo urne mo uth.ac.uk/ESERG.

Several companies producing commercial project management and cost-estimation tools have info rmatio n avail able o n the ir We b sites. Quantitati ve So ftware Manage- ment , producers o f the SLIM cost-estimation package, is located at http://www.qsm.com. Likewise, Software Productivity Research offers a package calle d Checkpoint. Informa- tion can be found at http://www.spr.com. Computer Associates has developed a large suite of project management tools, including Estimacs for cost estimation and Plan.macs for planning. A full description of its pro ducts is at http://www.cai.com/products.

The Software Technology Support Cente r at Hill Air Force Base in Ogden, Utah , produces a newsle tte r ca lled CrossTalk thal repo rts o n method and tool evaluatio n. Its guidelines fo r successful acquisition a nd managemen t can be found at h ttp://stsc.hill.af. mil/stscdocs.hlml. The Center's Web pages also contain pointers lo several technology areas, including project management and cost estimation: you can find the listing at http://stsc.hill.af.mil.

Team building and team inte ractio n are essential on good soft ware projects. We inbe rg (1993) discusses work styles and the ir applica tio n to te am building in the sec- o nd vo lume o f his series o n software quality. Scho ltes (1995) includes mate rial o n how to hand!le difficult team members.

Project manageme nt fo r small projects is necessaril y diffe rent from that for la rge projects. The O cto ber 1999 issue of IEEE Comp uter addresses softwa re engineering in the s maU, with articles a bo ut smaU projects, Interne t time pressures, and extre me p rogramming.

Project ma nageme nt fo r Web applica tions is somewha t di ffe rent fro m mo re tr adi - tio nal so ftware e ngineering. Me ndes and Moseley (2006) explo re the diffe ren ces. In particula r, they address estimation fo r We b a pplications in t heir book o n "Web engineering."

3.14 EXERCISES

1. You a re about to ba ke a two-layer birthday cake with icing. Describe the cake-baking project as a work breakdown structure. Generate an activity grap h fro m that structure. What is the critical path?

2. Figure 3.23 is an ac tivity graph for a software d evelopment project. The number corre- sponding to each ed ge of the gra ph indicates the number o f days re quired t o comple te the activity represented by that branch. For example, it will take fou r days t o complete the

Openmirrors.com

Section 3. 14 Exercises 139

START

FIGURE 3.23 Activity graph for Exercise 2.

activity that ends i.n milestone E. For each activity, List its precursors and compute the earliest start time, the latest start time, and the slack. Then, ide ntify the critical path.

3. Figure 3.24 is an activity graph. Find the critical path.

START

FIGURE 3.24 Activity graph for Exercise 3.

4. On a software development project, what kinds of activities can be performed in parallel? Explain why the activity graph sometimes hides the interdependencies of these activities.

5. Describe how adding personnel to a project that is behind schedule might make the project completion date even later.

6. A la rge government agency wants to contract with a software developme nt firm for a project involving 20,000 lines of code. The Hardand Software Company uses Walston and Felix's estimating technique for determining the number of people required for the time needed to write that much code. H ow many person-months does Hardand estimate will be needed? If the government's estimate of size is 10% too Low (i.e., 20,CXX) lines of code represent only 90% of the actual size), how many additional person-months will be needed? In general, if the government's size estimate is k% too low, by how much must the person-month estimate change?

140 Chapter 3 Plan ning a n d Managing the Project

7. Explain why it ta kes longer to d evelop a utility program than an applications program and longer still to develop a system program.

8. Manny's Manufacturing must decide whethe r to build or buy a software package to keep track o f its inventory. Manny's computer experts estimate that it will cost $325,000 to buy the necessary programs. To build the programs in-house, programmers will cost $5000 each pe r month. Wlhat facto rs should Manny consider in making b is decision? When is it better to buiJd? To buy?

9. Brooks says that adding people to a late project makes it even late r (Brooks 1975). Some schedule-estimatio n techniques seem to indicate that adding people to a project can shorten development time. Is this a contradiction? Why or why not?

10. Many studies indicate that two of the major reasons that a project is late are changing require ments (called requirements volatility or instability) and employee turnover. R eview the cost mode ls discussed in this chapter, plus any you may use on your job, and d etermine which models have cost facto rs that reflect the effects otf these reasons.

11. E ven on your student projects, the re are significant risks to your fi n ishing your project on time. Analyze a student software development project and list the risks. What is the risk exposure? What techniques can you use to mitigate each risk?

12. Many project managers plan their schedules based on programmer productivity on past projects. This productivity is often measured in te rms of a unit of size per unit of time. For example, a n o rganmzation may produce 300 lines of code per day o r 1200 application points pe r month. ls it a ppropria te to measure productivity in this way? Discuss the mea- su re ment of productivity in terms of the fol.lowing issues:

• Different langua ges can produce diffe rent numbers o f lines of code for implementa- tion of the same design.

• Productivity in lines of code cannot be measured until implementation begins. • Programme rs may structure code to meet productivity goals.

Openmirrors.com

4

In this chapter, we look at • eliciting requirements from our

customers • modeling requi rements • reviewing requirements to ensure

their quality • documenting requirements for use

by the design and test teams

In earlier chapters, when looking at various process m odels, we noted several key steps for successful software development. In particular, each proposed model of the software-develo pme nt process 1ncludes activities aimed at capturing re quirements: unde rstanding o ur custome rs' fundamental proble ms an d goals. Thus, o ur understa nd- ing of system inte nt and functio n starts with an examina tion of requirements. In this chapter, we look at the various t ypes of requirements and the ir diffe re nt sources, and we discuss ho w to resolve confticting requirements. We detail a variety of modeling no tatio ns and requirements-specification me thods, with examples o f both auto ma ted and manual techniques. These models help u s understand the requirements and docu- ment the re latio nships among them. Once the requireme nts are well unde rstood, we learn how to review them for correctness and completeness. At the end o f the chapter, we learn how to choose a requireme nts-specification method that is appropriate to the project unde r consideration, based o n the project's size, scope, and the criticality of its missio n.

AnaJyzing requirements involves much mo re than me re ly writing down what the custo me r wants.. A s we sha ll see, we must find requireme nts on which bo th we and the custo mer can agree and on which we can build our test procedures. First, let us examine e xactly what requirements a re, why they are so important (see Sidebar 4.1), and how we wo rk with users and custo me rs to define and document them.

141

142 Chapter 4 Capturing the Require ments

SIDEBAR 4. 1 WHY ARE REQUIREMENTS IMPORTANT?

The hardest single part of building a software system is deciding precisely what tu build. Nu uther part uf the conceptual work is as difficult as establishing tire detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part. oft/re work so cripples tire resulting system if done wrong. No other part is more difficult to rectify later.

(Brooks 1987)

In 1994, the Standish Group surveyed over 350 companies about thei.r over 8000 software projects to find out how well they were faring. The results are sobering. Thirty-one percent o f the software projects were canceled before they were completed More·over, in large compa- nies, only 9% of the projects were delivered on time and within budget; 16% met those criteria

in small companies (Standish 1994). Similar results have been reported since then; the bottom

line is that developers have trouble delivering the right system on time and within budget.

To understand why, Standish (1995) asked the survey respondents to explain the causes

of the failed projects. The top factors were reported to be

1. Incomplete requirements (13.1%)

2. Lack of user involvement (12.4%)

3. Lack of resources (10.6%)

4. Unrealistic expectations (9.9 %)

5. Lack of executive support (9.3%)

6. Changing requirements and specifications (8.7%)

7. Lack of planning (8.1 % )

8. System no longer needed (7.5%)

Notice that some part of the requirements elicitation, definition. and. management process is involved in almost all of these causes. Lack of care in understanding, documenting, and manag-

ing requirements can lead to a myriad of problems: building a system that solves the wrong prob- lem, that doesn't function as expected, or that is difficult for the users to understand and use.

Furthermore, requirements errors can be expensive if they are not detected and fixed

early in the development process. Boehm and Papaccio (1988) report th.at if it costs $1 to find and fix a requirements-based problem during the requirements definiti on process, it can cost

$5 to r epair it during design , $10 during coding, $20 during unit testing, and as much as $200 after delivery of the system! So it pays to take time to understand the problem and its con-

text, and to get the requirements right the first time.

4.1 THE REQl!.JIREMENTS PROCESS

A custome r who asks us to build a ne w system has some notion of what the sys te m sbould do. Often, the custome r wants to automate a manual task , such as paying bills electronically rather than with handwritten checks. Sometimes, the customer wants to

Openmirrors.com

Section 4.1 The Requirements Process 143

e obance o r exte od a current manual or automated system. For example, a tele pho ne biJling syste m that charged cui;tomers only fo r local telephone service and long- distance calls may be updated to bill for call fo rwarding, call waiting, and o ther oe w fea- tures. Mo re and mo re frequently, a customer wants products that do things tha t have neve r been done before: tailo ring electronic news to a user's inte rests, c hanging the shape of an airpl ane wing in mid-fLigbt, or monitoring a diabetic's blood sugar aod automatically controlling insulin dosage. No matte r whether its functio oaJity is o ld or new, a proposed software system has a purpose, usually expressed in te rms o f goals o r desired behavio r.

A requirement is an expression of desired beh avior. A requirement deals with o bjects o r e otities, the states they cao be in, and the functions that are pe rformed to change states or object characte ristics. For example, suppose we are building a system to gene rate paychecks for o ur customer 's company. Ooe requirement may be that the chec ks are to be issued every two weeks. Another may be that direct de posit o f an e mployee's check is to be aJlowed for every employee at a certain sa lary leve l o r highe r. The custome r may request access to the paycheck system from several different com- pany loca tions. All of these requireme ots are specific d escriptio os of functions or char- acteristics that address the ge oeral purpose of the system: to generate paychecks. Thus, we look for requireme nts that identify key e ntities ("ao e mployee is a person who is paid by the company"), limit entities ("an e mployee may be paid fo r no more than 40 hours p er week"), o r define re lati onships among en tities ("employee X ms supervised by employee Y ifY can autho rize a change to X 's sa lary").

Note that n one of these requireme nts specif)' how the system is to be impleme nted. lllere is no mention o f what database-management system to use, whethe r a client-server architecture will be employed, ho w much memory the compute r is to have, o r what pro- gramming language must be used to develop the system. These implementation-specific descriptions are no t considered to be requirements (unJess they are mandate d by the cus- tomer). The goal of the requireme nts phase is to understand the customer's problems and oeeds. Thus, require ments focus on the customer and the problem, not on the solution or the imple me nta tio n. We ofte n say that requirements designate what behavio r the cus- tomer wants, without saying how that behavior will be realized. Any discussio n of a solution is premature uotil the problem is clea rly define d.

It he lps to describe requirements as interaction s among real-wo rld p heno mena, without any re fe rence to system phenomena. For example, billing require ments should refer to customers, services bille d, billing periods and amouots-wi thout mentioning system data o r procedures. We take this approach partly t o get at the heart o f the cus- tome r's n eeds, because some tiroes the stated needs are n ot the real needs. Moreover, the custo me r's proble m is usuaLiy most easily stated io terms of the custo me r's busi- ness. Ano ther reason we take thi s approa ch is to give the designer maximum flexibility in deciding how to carry out the requirements. During the specification phase, we wiU decide which re quire ments wiU be fuJfilJed by our software system (as opposed to requireme nts that are addressed by special -purpose hardware devices, by o the r soft- ware systems, o r by huma n operators o r users); duriog the design phase, we wil l de vise a plan for how the specifie d behavior will be implemen ted.

Figure 4.1 illustrates the process of dete rmining the require ments for a proposed software system. The person pe rfo rming these tasks usually goes by the title of requirements analyst o r systems analyst. A s a requirements ana lyst, we first work witb

144 Chapter 4 Capturing the Requirements

Soltwm

E llelt1tlon A11lysl1 Spee1nut1 01 V1lld1tlon R1.1lruient1 Speelncatloi

(SRSJ

CtllHll19 th• m t'1

U ndt tsllnd I n9 ind 11odelln9 t••

Dom1tnlln9 th b1•1vlor or th1

Chtckl19 th11 Oii 1pecl/ le1tlon

req1lru11ntt des I red beh1vlo r propo11d n hwi11 111ttths the u11(1 tyl l l ll requlre11utr

FIGURE 4.1 Process for capturin,g the requirements.

o ut customers to elicit the requirements by asking questions, examining current behav- io r, o r d e mo nstrating similar systems. Next, we capture the require ment s in a mo de l o r a pro totype. This exercise he lps us to better unde rstand the require d beh avior. and usu- aUy raises additional questions about what the custome r wants to happen in certain sit- uatio ns (e.g., what if an e mployee leaves the company in the middl e o f a pay pe rio d?). Once the requirements are we U understood, we p rogress to the specification phase, in which we decide whi ch parts o f the required behavior will be impl e mented in software. During validation, we cbcck that our specification matches what t he custome r expects to see in the final product. Analysi s and validati o n activiti es may expose proble ms o r o missio ns in our mode ls o r specifica tion that cause us to revisit the custo mer and re vise o ur mo de ls and specificati on. The eve ntual outcome o f the requirements process is a So ftware Requirements Specification (SRS), whi ch is used to communicate to othe r software develope rs (designe rs, testers, maintainers) how the final product o ught to behave. Side bar 4.2 discusses how the use of agile methods affects the requireme nts process and the resulting re quirements docume nts. The remainder of this ch ap ter e xplores the requirements process in more detail.

4.2 REQUIREMENTS ELICITATION

Require ments e licitatio n is an especially critical part of the process. We must use a vari- e ty o f techniques to de te rmine what the users and custo mers realJy want. Sometimes, we are auto mating a manual syste m, so it is e asy to examine what the system already does. But o fte n, we must wo rk with users and customers to understand a comple tely new problem. This task is rare ly as simple as asking the right questions to pluck the require- me nts from the custome r's he ad. At the ea rly stage o f a project, requirements a re ill - formed and ill-unde rstood by everyone. Custo me rs are not always good at describing e xactly what they want or need, and we are not always good at unde rstanding some - o ne e lse's business concerns. The custo me rs know their business, but they cannot always d escribe the ir business proble ms to outside rs; the ir descriptions are full of jargon and

Openmirrors.com

Section 4.2 Requirements Elicitation 145

SIDEBAR 4.2 AGILE REQUIREMENTS MODELING

As we noted in Chapter 2, requirements analysis plays a large role in deciding whether to use agile methods as the basis for software development. If the requirements are tightly coupled and complex, or if future requirements and enhancements are likely to cause major changes to the system's architecture, then we may be better o ff with a "heavy" process that emphasizes up-front modeling. In a heavy process, developers put off coding until the requirements have been modeled and analyzed, an architecture is proposed that reflects the requirements, and a detailed design has been chosen. Each of these steps requires a model, and the models are related and coordinated so that the design fuJJy implements the require- ments. This approach is most appropriate for large-team development, where the documenta- tion helps the developers to coordinate their work, and for safety-critical systems, where a system's correctness and safety are more important than its release date.

However, for problems where the requirements are uncertain, it can be cumbersome to

employ a heavy process and have to update the models with every change to the require- ments. As an alternative approach, agile methods gather and implement the requirements in increments. The initial release implements the most essential requirements, as defined by the stakeholders' business goals. As new requirements emerge with use of the system or with bet-

ter understanding of the problem, they are implemented in subsequent releases of the sys- tem. This incremental development allows fo r "early and continuous delivery of valuable software" (Beck et a l. 2004) and accommodates emergent and late-breaking requirements.

Extreme programming (XP) takes agile requirements processes to the extreme, in that

the system is built to the requirements that happen to be defined at the time, with no planning or designing for possible future requirements. Moreover, XP forgoes traditional requirements documentation, and instead encodes the requirements as test cases that the eventuaJ imple- mentation must pass. Berry (2002a) points out that the trade-off for agiJe methods' flexibility is

the difficulty of making changes to the system as requirements are added. deleted. or changed. But there can be additional problems: XP uses test cases to specify requirements, so a poorly written test case can lead to the kinds of misunderstandings described in this chapter.

assumptions with which we may not be familiar. Likewise, we as de velopers know about computer solutions, but not always about bow possible solutions will affect our customers' business activities. We, too, have o ur jargon and assumptio ns, and some times we think eve ryo ne is speaking the same language, when in fact people have different meanings fo r the same words. It is onJy by djscussing the requirements with eve ryone who has a stake in the syste m, coalescing these different views into a cohe rent se t of requirements, and reviewing these documents with the stakeholde rs tha t we all come to an agreement a bout what the requirements are. (See S ide bar 4.3 fo r an a lte rnative viewpoint.) If we cannot agree on what the requireme nts a:re, then the project is doomed to fail.

146 Chapter 4 Capturing the Requirements

SIDEBAR 4.3 USING VIEWPOINTS TO MANAGE INCONSISTENCY

A lthough most software engineers strive for consistent requirements, Easterbrook and Nuseibeh (1996) a rgue that it is often d esirable to tole rate a nd even encourage inconsis- tency during the requirements process. They claim that because the s takeholders' under- standing o f the domain and their needs evolve over time, it is pointless to try to r esolve inconsistencies early in the requirements process. Early resolutio ns are expensive and often unnecessary (and can occur naturally as stakeholders revise their views). They can a lso be counter-productive if the resolution process focuses attention o n how to come to agreement rather than on the underlying causes of the inconsistency (e.g., stakeholders' misunderstand- ing of the domain).

Instead, Easterbrook and Nuseibeh propose that stakeho lders' views be documented and ma intained as separate Viewpoints (Nuseibeh e t a l. 1994) throughout the software devel- o pment process. The require ments analyst de fines consistency rules that should apply

between Viewpoints (e.g., how objects, states, or transitions in o ne Viewpoint correspond to similar entities in a nother Viewpoint; o r how one Viewpoint refines ano ther Viewpoint), and the Viewpoints are a na lyzed (possibly automatically) to see if they conform to the consis- tency rules. If the rules a re violated, the inconsiste ncies are recorded as part of the View-

points. so that other software developers d o not mistakenly implement a view that is being contested. The recorded :inconsistencies a re rechecked whenever an associated Viewpoint is modified, to see if the Viewpoints a re still inconsiste nt; and the consistency rules are checked

periodlically, to see if any have been broken by evolving Viewpoints.

The o utcome o f this approach is a require ments document that accommodates all stake- holders' views at all times. Inconsistencies are highlighted but no t addressed until there is suf- ficient information to make an informed decision. This way, we avoid committing ourselves prematurely to require me nts o r design decisions.

So who are the stake holde rs? It turns out that there are ma ny people who have something to contribute to the requirements of a new system:

• Clients, who are the ones paying for the software to be developed: By paying for the development, the clien ts are, in some sense, the ultimate stakeholders, and have the final say a bout what the product does (Robertson and Robertson 1999).

• Customers, who buy the software after it is developed: Sometimes the customer and the use r are thte same; other times, the customer is a business manager who is interested in improving the productivity of h.er employees. We have to understand the customers' needs well enough to bui ld a product that they will buy and find useful.

• Users, who are familia r with the current system and will use the future system: These are the expe rts on how the cu rre nt system works, which features are the most useful, and which aspects of the system need improving. We may want to co nsult a lso with special-interest groups of users, such as users with disabilities,

Openmirrors.com

Section 4.2 Requirements Elicitation 147

people who are unfamiliar with or uncomfortable using computers, e xpert users, and so on, to understand their particular needs.

• Domain experts, who are familiar with the problem thal the software must auto- mate: For example, we would consult a financial e xpert if we were building a financial package, or a meteorologist if our software were to mode l the weathe r. These people can contribute to the requirements, or wiU know about the kinds of enviro nme nts to whi ch the product will be exposed.

• Market research ers, who have conducted surveys to determine ftt1ure trends and polential customers' needs: They may assume the role of the custo me r if our soft- ware is be ing developed for the mass market and no particular custome r has bee n identified ye t.

• Lawyers o r auditors, who are familiar with government, safety, or legal require- ments: For example, we might consult a tax expe rt to e nsure that a payroll pack- age adheres to the tax law. We may also consult with expe rts on standards that are re levant to the product's functions.

• Software engineers o r other technology experts: These expe rts e nsure that the product is technka Uy and econo mically feasible. Tuey can educate the custo mer about inno vative hardwa re and software techno logies, and can recomme nd new functionality that takes advantage of these technologies. They ca n a lso estimate the cost and developme nt time of the product.

Each stake holde r has a particular view of the system and how it sho uld work, and often these vie ws conflict. One of the many ski Us of a requirements analyst is the ability to unde rstand each vie w and capture the requirements in a way tha t re flects the con- ce rns o f each participant. For example, a customer may sp ecify that a system perfo rm a particular task, but the custo me r is not necessarily the user of the proposedl system. TI1e use r may want the task to be p erformed in three modes: a learning mo de, a novice mode, and an expe rt mode; this separation will allow the user to learn and master the system gradually. Some systems are imple mented in this way, so that new use rs can adapt to the new syste m graduaJly. H owever, conflicts ca n a rise when e ase o f use sug- gests a slowe r syste m than response-time requirements pe rmit.

Also, diffe rent participants may expect differing levels of de tail in the requirements documentatio n, in which case the requireme nts will need to be packaged in different ways for differe nt people. In addition, users and developers may have preconceptions ( right or wrong) about what the o the r group va lues and how it acts. Table 4.1 summarizes some of the common stereotypes. This table e mphasizes the role that human interactio n plays in the development of software systems; good requirements analysis requires excel- lent interpe rsonal skills as weU as solid technical skills. The book 's We b si te contains sug- gestions for addressing each of these differences in perception.

lo addition to interviewing stakeholders, other means of eliciting requirements include

• Reviewing avai lable documentation , such as documente d p rocedures o f manual tasks, and specificatio ns or user manuals of automate d systems

• Obse rving the current syste m (if one exists), to gathe r o bj ecti ve information about ho w the use rs perfo rm the ir tasks, and to bette r understand the system we are about to automate or to change; often , when a new computer system is deve lo ped ,

148 Chapter 4 Capturing the Requirements

TABLE 4.1 How Users and Developers View Each Other (Scharer 1990)

How Developers See Users

Users don't know whatthey want. Users can't articulate what they want.

Users are unable to provide a usable statement of needs.

Users have too many needs that are politically motivated. Users want everything right now. Users can't remain on schedule.

Users can't prioritize needs. Users are unwilling to compromise. Users refuse to take responsibility for the system. Users are not committed to development projects.

How Users See Developers

Developers don't understand operational needs. Developers can't translate clearly stated needs into

a successful system. Developers set unrealistic standards for requirements

definition. Developers place too much emphasis on technicalities. Developers are always late. Developers can't respond quickly to legitimately

changing needs. Developers are always over budget. Developers say "no" all the time. Developers try to tell us bow to do our jobs. Developers ask users for time and effort, even to the

detriment of the users' important primary duties.

the o ld system continues to be used because it provides some critical function that the designers of the new system overlooked

• Apprenticing with use rs (Beyer and Holtzblatt 1995), to learn about users' tasks in more detail , as the user performs them

• Inte rviewing users o r stakeholders in gro ups, so that they wiU be inspired by one another's ide as

• Using domain-specific strategies, such as Joint Application Design (Wood and Silver 1995) o r PIECES (Wethe rbe 1984) for information systems, to ensure that stakeholders consider specific types of requirements that are relevant to tlheir particular situations

• Brainstorming with current and pote ntial ll.lsers about how to improve the pro- posed product

The YoJere requirements process model (Robertson and Robertson 1999), as shown in Figure 4.2, suggests some additional sources for requirements, such as templates and ljbraries o f re quire ments from related systems that we have developed.

4 .3 TYPES OF REQUIREMENTS

When most people think about require men ts, they think about required functionality: What services should be provided? What o perations should be performed? What should be the reaction to certain stimuli? How does required be havior change over tim e and in response to the rustory o f events? A functional rc.qufrcmcnt describes required behavior in terms of required activities, such as reactions to inputs, and the state of each entity before and after an activity occurs. For instance, for a payroll sys- tem, the functional requirements sta te how o fte n paychecks are issued, what input is necessary for a paycheck to be printed, under what conditions the amount of pay can be changed, and what causes the removal of an employee from the payroLI list.

Openmirrors.com

Suke~older w1n11

'"' ""'' Cment 0191nlz1tlon

ind 1pte111

Exl1tln9 dmnentt

Sectio n 4.3

Oon1ln nodalr

Reuu•I• 1tqulre11111h

\

Camel 11tu1tlon 111o4tl

Types of Requirements 149

FIGURE 4.2 Sources of possible requirements (Robertson and Robertson 1999).

The functional require ments de fine the bounda ries of the solution space for our pro ble m. The solutio n space is the set of possible ways that software can be designed to implement the requirements, and initially that set can be very large. Ho we ver, in prac- tice it is usually no t e no ugh fo r a so ftware product to compu te correct outputs; there are o the r types o f req uirements that also distinguish between acceptable and unaccept- a ble products. A quality require me nt, or no nfunctional requirem ent, d escribes some qua li ty characte ristic tha t the softwa re solution must possess, such as fast resp o nse time, ea se of use, high r eliability, o r low maintenance costs. A d esign constraint is a design d ecisio n, such as cho ice o f p latfo rm o r interface compone nts, that has alre ady been mad e and that restricts the set o f solutions to o ur problem. A process constraint is a restric tio n o n the techniques o r resources that can be used to buiJd the system. For e xample, customers may insist tha t we use agile me thods, so that th ey can use early ve r- sions o f the system while we continue to add fea tures. Thus, quality requireme nts, design constraints, and process constraints furt her restrict our solutio n space by differ- e ntia ting acceptable, well-liked solutions fro m unused products. Table 4.2 gives e xamples of each kind o f requireme nt.

Quality requi reme nts sometimes sound like " mothe rhood " c!haracteristics that aU products o ught to possess. Afte r a ll, who is going to ask for a slow, unfri end ly, unre li- able, unmaintainable software system? It is bette r to think o f qu ali ty requir eme nts as design crite ria that can be optimized and can be used to choose amo ng aJte rnative implementatio ns o f functio nal requireme nts. G iven this approach, the questio n to be a nswe red by the require me nts is: To what exte nt must a pro duct satisfy these q ua li ty requireme nts to be acceptable? Side ba r 4.4 explains how lo exp ress quali ty require- ments s uch that we can test whether they are met.

Resolving Conflicts

In trying to elicit all types o f re quirements from a U of the relevant stakeholders, we are bound to encounte r conflicting ideas of what the requirements ought to be. It usu aUy he lps to ask the custo me r to prio ritize requireme nts. This task forces the custome r to

150 Chapter4 Capturing the Re q uirements

TABLE 4.2 Questions to Tease Out Different l)rpes of Requirements

Fu11ctlo11al RequJre ment s Functionality

• What will the system do? • When will the system do it? • Are there several modes of operation? • What kinds of computations or data

transformations must be performed? • What are the appropriate reactions to possible

stimuli? D ata

• For both input and output, what should be the format of the data?

• Must any data be retained for any period of time?

Design Constraints Physical Environment

• Where is the equipment to be located? • l s there one location or several? • Are there any environmental restrictions, such

as temperature, humidity, or magnetic interference?

• Are there any constraints on the size of the system?

• Are there any constraints on power, heating, or air oonditioning?

• Are there constraints on the programming language because of existing software components?

Interfaces • l s input coming from one or more other systems? • l s output going to one or more other systems? • Is there a prescribed way in which inpuVoutput

data must be formatted? • Is there a prescribed medium that the data

must use? Users

• Who will use the system? • Will there be several types of users? • What is the skill level of each user ?

Process Constraints Resources

• What materials, personnel, or other resources are needed to build the system'.1

• What skills must the developers have? Documentation

• H ow much documentation is required? • Should it be onJine, in book format, or both? • To what audience should each type of

documentation be addressed? Standards

Q uality R equirements Performance

• Are there constraints on execution speed, response time, or throughput?

• What efficiency measures will apply to resource usage and response time?

• H ow much data will flow through the system? • How often will data be received or sent?

Usability and Human Factors • What kind of training will be required for each

type of user? • How easy should it be for a user to understand

and use the system? • H ow difficult should it be for a user to misuse the

system? Security

• Must access to the system or information be controlled?

• Should eacb user's data be isolated from the data of otber users?

• Should user programs be isolated from other programs and from the operating system?

• Sbould precautions be taken against theft or vandalism?

Reliability and Availability • Must the system detect and isolate fau lts? • What is the prescribed mean time between failures? • Is there a maximum time allowed for restarting

the system after a failure? • H ow often will the system be backed up? • Must backup copies be stored at a different

location? • Should precautions be taken against fire or water

damage? Maintainability

• Will maintenance merely correct errors, or will it also include improving the system?

• When and in what ways might the system be changed in the future?

• H ow easy should it be to add features to the system?

• H ow easy should it be to port the system from one platform (computer, operating system) to another?

Precision and Accuracy • H ow accurate must data calculations be? • To wlilat degree of precision must calculations

be made? Time to D elivery I Cost

• ls there a prescribed timetable for development? • Is there a limit on the amount of money to be spent

on development or on hardware or software?

Openmirrors.com

Section 4.3 Types of Requirements 151

SIDEBAR 4.4 MAKING REQUIREMENTS TESTABLE

In writing about good design, Alexander (1979a) encourages us to make our requirements testable. By this, he means that once a requirement is stated, we should be able to determine whether or not a proposed solution meets the requirement. This evaluatio n must be objec- tive; that is, the conclusion as to whether the requirement is sat isfied must not vary according to who is doing the evaluation.

Robertson and Robertson (1999) point out that testability (which they call "measurabil- ity") can be addressed when requirements are being elicited. The idea is to quantify the extent to which each requirement must be met. These 6t criteria form objective standards for judging whether a proposed solution satisfies the requirements. When such crite ria cannot be

easily expressed, then the requirement is likely to be ambiguous, incomplete, o r incorrect. For example , a customer may state a quality requirement thjs way:

Water quality information must be accessible immediately.

How do you test that your product meets this requirement? The customer probably has a clear idea about what "immediately" means, and that notion m ust be captured in the require- ment. We can restate more precisely what we mean by " immediately":

Water quality records must be retrieved within 5 seconds of a request.

This second formulation of the requirement can be tested objectively: a series of requests is made, and we check that the system supplies the appropriate r;ecord within 5 seconds of each request.

It is relatively easy to determine fit criteria for quality requirements that are naturally quantitative (e.g., performance, size, precision, accuracy, time to delivery). What about more subjective quality requirements, like usability or maintainabil.ity? In these cases, developers use focus groups or metrics to evaluate fit criteria:

• 75% of users shall judge the new system to be as usable as the existing system.

• After training, 90% of users shall be able to process a new account within 5 minutes.

• A module will encapsulate the data representation of at most one data type.

• Complllation errors shall be fixed within 3 weeks of being reported.

Fit criteria that cannot be evaluated before the final product is delivered ar e har der to assess:

• The system shall not be imavailable for more than a total maximum of 3 minutes each

year.

• The mean-time-between-failures shall be no less than. 1 year.

In these cases, we either estimate a system's quality attributes (e.g., there a re techniques for estimating system reliability, and for estimating the number of fa ults per line of code) or

152 Chapter 4 Capturing the Requirements

evaluate the delivered system during its operation-and suffer some financial penalty if t he

system does not live up to its promise. Interestingly, what gets measured gets done. That is, unless a fit criterion is unrealistic, it

will probably be me t. 'The key is to determine, with the customer, just how to demonstrate

that a de live red syste m m eets its requirements. The R obe rtsons suggest three ways to he lp make requirements testable:

• Specify a quantitative description for each adve rb and adjective so that the meaning o f qualifiers is clear and unambiguous.

• Replace pronouns with specific names of entities.

• Make sure that every noun is defined in exactly one place in the requirements documents.

An alternative approach, advocated by the Quality Function Deployment (QFD) school

(Akao 1990), is to realize quality requirements as special-purpose functional requirements, and to test quality requirements by testing how well their associated fu n ctional requiremen ts

have been satisfied. This approach works bette r for some quality requirements than it does for

others. For example, real-time requirements can be expressed as additional conditions or con- straints on when required functionality occurs. Other quality requirements, such as security,

maintainability, and performance, may be satisfied by adopting existing designs and protocols

that have bee n developed specifically to optimize a particular quality requirement.

re flect on which o f the requested services and features are most essentia l. A loose prioritizatio n scheme might se parate requireme nts into three categories:

1. Re quire me nts that absolutely must be me t (Essential) 2. Re quire me nts that are highly desirable but n ot necessary (Desirab le) 3. Re quire me nts that are possible but could be eliminated (Optional)

Fo r exa mple, a credit ca rd billing system must be able to list curren t charges, sum th em, and re quest payme nt by a ce rtain date; these are essential requireme nts. But the biUing system m ay also separate the charges by purchase type, to assist the purcha ser in under- sta nding buying patte rns. Such purchase-type an alysis is a desirable but probably no nessential requirement. Finally, the system may print the credits in black and the d ebits in red, which wouJd be useful but is option al. Pri oritizing re quire ments by ca te- gory is helpful to all parties in unde rstanding what is really need ed. It is also useful whe n a software-develo pme nt project is constraililed by lime or resources; if the system as de fined will cost too much or ta ke too long to d evelop, option al requirements cao be dro pped , and desirable require ments can be ana lyzed fo r e limjn ation or postpone ment to la te r ve rsions.

Prioritiza tion can be especially helpful in resolving conflicts a mong q uality require me nts; o ften, two quality attributes will conflict, so that it i.s impossible to opti- mize fo r bo th. For example, suppose a system is re quired to be maintainable and deliver respo nses quickly. A design that emphasizes maintainabili ty through sepa ration of concerns and e ncapsulation may slow the performance. Likewise, tweaking a system to

Openmirrors.com

Section 4.3 Types of Requirements 153

pe rform especially well on one platform affects i ts portability to other platforms, and secure systems necessa rily control access and restrict availability to some users. Emphasizing security, reliability, robustness, usability, or p erformance can all affect maintainability, in that realizing any of these characteristics increases the design 's compl exity and decreases its cohere nce. Prio riti zing qua lity requireme nts forces the custome r to choose those software-quality factors about which the customer cares most-which helps us to provide a re aso nable, if not optimal, solution to the customer's quality requirements.

We can also avoid trying to o ptimize multiple conflicting quality requirements by identifying and aiming to achieve fit criteria, which establish cle ar-cut acceptance tests for these re quirements (see Sidebar 4.4). But what if we cannot satisfy the fit criteria? Then it may be time to reevaluate the stakeholders' views and to e mpl oy negotiation. However, negotia tion is not easy; it requires skill, patience, and experience in finding mutually acceptable solutions. Fortunate ly, stakeholde rs rarely disagree about the unde rlying problem that the softwa re system is addressing. More likely, conflicts will pertain to pos- sible approaches to, or design constraints on, solving the problem (e.g., stakeholders may insist on using different database systems, diffe rent encryption algorithms, diffe rent user inte rfaces, o r different programming languages). More seriously, stakeho lders may dis- agree o ve r priorities of requirements, or abou t the business policies to be incorporated into the system. For example, a unive rsity's colleges or departments may want different po licies for evaluating students in thei r respective programs, whereas unive rsity adminis- trators may prefer consolidation and uniformity. Resolutio n requires determining exactly wby each stakeholder is adamant about a particular approach, policy, or priority rankirug- for example, they may be concerned about cost, security, speed, or quality-and then we need to wo rk toward agreement o n fundamental requiiements. With effective negotiation, the stakeholders will come to unde rstand and appreciate each other's fundamental needs, and will strive for a resolution that satisfies everyone; such resolutions are usually very different from any of th e stakeholders' original views.

Tw o Kinds of Re quire ments Documents

In the end, the requirements are used by many different people and for different p ur- poses. Re qufrements analysts and their clien ts use requirements to explain their under- standing of bow the system should behave. Design e rs trea t require ments as constraints o n what would be conside re d an acceptable so lution. The test team derives from the require ments a suite of acceptance tests, which will be used to demonstrate to the cus- tomer that the system being delivered is indeed what was ordered. The maintenance team uses the requireme nts to he lp ensure that system e nhance me nts (repairs and new features) do not interfe re with the system's o riginal intent. Sometimes a single docu- me nt can serve all of these needs, leading to a common understanding among cus- tomers. re quire ments analysts, and developers. But often two documents are neede d: a requirements definition t hat is aimed at a business audience, such as clients, customers, and users, and a requirements specification that is aimed at a technical audience, such as designe rs, testers, and project managers.

We illustrate the d istinction using a sma ll running exa mple from Jackson and Zave (1995). Consider a software-contro lled turnstil e situated at the entrance to a zoo.

154 Chapter 4 Capturing the Requirements

Whe n the turnstile is fed a coin, it unlocks, allowing a visitor to push through the turnstile and ente r the zoo. Once an unlocked turnstile has rotated enough to allow one entry, the turnstile locks again, to prevent anothe r person from entering without payment.

A requireme nts de finition is a complete listing of everything the customer wants to achieve. The document expresses requi rements by describing the entities in the en vi- ronment in which the proposed system will be installed , and by describing the desired constraints o n, monito ring o f, or transformations of those entiti es. The purpose of the propose d system is to realize these requirements (Zave and Jackson 1997). Thus, the requirements are written entire ly in terms of the e nvironment, describing how the envi- ronment will be affected by the proposed system. Our turnstil e example has two require - ments: (1) no one sho uld enter the zoo without paying an entrance fee, and (2) for every e ntrance fee paid, the system sho uld not prevent a corresponding entry. 1 The require- ments definition is typically written j ointly by the client and the re quirements analyst, and it represents a contract describing what functionality the developer promises to d eliver to the clie nt.

The requireme nts s pecification restates the requirements as a specification of h ow the proposed syste m shall behave. The specification also is written entirely in terms of the envfronme nt, e xcept that it re fers solely to e nvironmental entities that are accessi- ble to the system via its inte rface. That is, the system boundary makes explicit those environme ntal e ntities that can be monitored or controlled by the system. This distinc- tio n is depicted in Figure 4.3, with requirements defined anywhere within the environ- ment's domain, including, possibly, the system's interface, and with the specification restricted o nly to the intersection between the e nvironment and system domains. To see the distinction, consider tbe require ment that no one sbouJd e nter the zoo without paying an e ntrance fee. If the turnstile has a coin slot and is able to detect when a valid coin is inserted, then it can determine when an entrance fee bas been paid. In contrast, the concept of an e ntry event may be outside the scope of the syste m. Thus, the requi re - ment must be rewritten to realize e ntry events using only events and states that the turnstile can. detect and control, such as whether the turnstile is unlocked and whethe r it de tects a visitor pushing the turnstile :

When a visitor applies a certain amount of force on an unlocked turnstile, the turnstile will automatically rotate a one-half turn, ending in a locked position.

In this way, the specification re fines the o riginal re quire ments de finition. The requireme nts specification is written by the re quirements anal yst and is used

by the o ther software developers. The analyst must be especially careful that no infor- mation is Jost or changed whe n refining the requirements into a specification. The re must be a direct corresponde nce between each require ment in the definition document and those in the specificatio n document.

1 A more intuitive expression of this second requirement, that anyone who pays sbould be allowed to enter the zoo, is not implementable. There is no way for the system to prevent external factors from keeping the paid visitor from entering the zoo: another visitor may push through the w1locked turnstile before the paid visitor, the zoo may close before the paid visitor enters the turnstile, the paid visitor may decide to leave, and so on (Jackson and Zave 1995).

Openmirrors.com

Envlten1u11

Section 4.4 Characteristics of Requirements 155

Shtrtd lnt1rfm

FIG URE 4.3 Requirements vs. Specification.

4.4 CHARACTERISTICS OF REQUIREMENTS

To e nsure that the eve ntual product is successful , it is importa nt that the requirements be o f hi gh quaLity; wha t is no t specified usu aUy is n ot built. We discuss la ler in this chap- te r how to validate and verify re quire ments. lo the me antime, we list below the desir- able characte ristics fo r which we should check.

1. Are the requirements correct? Bo th we and the customer sho uJd review the docu - mented require me nts, to e nsure that they confo rm to our understanding of the re quire me nts.

2. Are the requiremen.ts consistent? That is, are the re any confli cting requirements? Fo r e xample, if o ne require ment states that a maximum o f 10 users can be using the syste m at o ne time, and ano the r requfre ment says that in a certain situat ion there may be 20 simuJtaneous users, the two requirements are said to be incon sis- te nt. In gene ral, two requirements are inconsistent if it is impossible to satisfy bo th simultaneously.

3. Are the requirements unam biguous? The require ments are ambiguous if multiple reade rs o f the require me nts can walk away with diffe ren t ibut vaLid interpreta- tio ns. Suppose a customer for a satellite control system requires the accuracy to be sufficie nt to su pport mission planning. The requirement d oes not te ll us what missio n planning r equires fo r support. The customer and the developers may have ve ry diffe rent ideas as to what leve l o f accuracy is n eeded. Further discus- sio n o f the meaning o f " missio n planning" may result in a more precise require- ment: "I n ide ntifying the positio n o f the sate llite, position e rror sha ll be less then 50 feet a long orbit, less than 30 feet off orbit." Given this mo re detail ed require- ment, we can test for p osition error and know exactly whe the r or no t we have m et the requireme nt.

4. Are Lhe requirem ents complete? The set o f re quirements is complete if it spedfies re quired be havio r and o utput for all p ossible inputs in all p ossible states unde r aU possible constraints. Thus, a payro ll syste m should describe what happens when an e mployee takes a leave without pay, gets a raise, or needs an advance. We say that the requireme nts are exte rnally complete if all states, state changes, inputs,

156 Chapter 4 Capturing the Requirements

products, and constraints are described by some require me nt. A requireme nts descriptio n is inte rnally complete if the re are no unde fine d terms among the re quire ments.

5. Are the requirem ents feasible? That is, does a solution to tibe customer's needs eve n e xist? Fo r example, suppose the customer wants users to be able to access a m ain compute r tha t is located several thousand miles away and have the response time for remo te users be the same as for local users (whose wo rkstations are con- nected directly to the main computer) . Questions of feasibility o ften arise whe n the custome r requires two or more quality re qllirements, such as a request for an inexpensive system that analyzes huge amounts o f data and outputs the analysis results within seco nds.

6. ls every requirement relevant? Sometimes a requirement restricts the developers unnecessariJy, or includes functions that are not directly related to the custome r's needs. Fo r example, a general may decide that a tank 's n ew software sys te m should allow soldie rs to send and receive e lectroni c mail , even th ough the main purpose o f the tank is to traverse uneven terrain. We should e ndea vor to keep this "feature explosio n" under contro l, and to he lp keep stakeh olders foc used on their essential and desir able reqllireme nts.

7. A re the requirem ents testable? The require ments are testable if they suggest acceptance tests th at would clearly demon strate whethe r the eventua l product mee ts the requirements. Consider how we might test the requirement that a sys- te m provide real -time response to que ries. We do no t krnow what ·' real-time respo nse" is. Howeve r, if fit criteria were given, saying that the system shall respond to que ries in no t more than 2 seconds, then we know exactly how to test the syste m's reactio n to que ries.

8. Are the requirements traceable? Are the requirements o rganized and unique ly labe led for easy re ference? Does every entry in the re quirem ents d efinitio n ha ve correspo nding entries in the requirements sp ecification , and vice versa?

We can think of these characte risti cs as the functional and qu ality requireme nts fo r a se t o f product requireme nts. These char acte ristics can h elp us to d ecide whe rn we have collected eno ugh information, and when we need to learn mo re abo ut what a p ar- ticular requireme nt means. As such, the degree to which we wa nt to satisfy these char- acteristks wiU affec t the type of information that we gathe r during requireme nts e licitation, and how comprehe nsive we want to b e. It will also affect the specificat ion languages we choose to express the requirements and the validation and verificat ion checks that we eve ntually perform to assess the re quirements.

4.5 MODELING NOTATIONS

One trait o f an enginee ring discipline is that it bas re peatable prncesses, such as the techniques presented in Chapter 2, fo r develo ping safe and successful products. A sec- o nd trait is that there exist standard no tation s fo r modeling, documenting, and commu- nica ting decisions. Mode ling can help us to unde rstand the requirements thoroug hly, by teasing out what quest ions we should be asking. Holes in our mode ls reveal unkno wn o r ambiguo us behavior. Multiple, conflicting outputs to the same input reveal

Openmirrors.com

Sectio n 4.5 Modeling Notations 157

inconsiste ncies in the req uire ments. As the mo del develops, it becomes more and more obvio us what we don 't know and what the customer doesn 't know. We carnnot complete a model without unde rstanding the subject of the mode l. Also, by restating the req uir ements in a completely different form fro m the customer's original requests, we force the customer to examine ou r mode ls care fu lly in order to validate the mo d el's accuracy.

It we loo k at the Eiterature, we see that there is a seemingly infinite numbe r of specifica tio n and design no tations and me thods, and that new no tations are being intro- duced and marketed au the time. But if we step back and igno re the d etails, we see llhat man y notations have a simila r look a nd feel. Despite the number of individual nota- tio ns, the re a re probably fewe r than ten basic paradigms for expressing informattion about a problem's concepts, behavior, and properties.

This sectio n focuses o n seven basic nota tiona l paradigms that can be applied in several ways to ste ps in the de velopment process. We begin our discussion of each by introducing the paradig m a nd the types of proble ms and descriptions for which it is particularly apt. The n we describe one or two concre te examples of notations fro m that paradigm. Once you are fa miliar with the paradigms, you can easily learn and use a new no ta tion because you wiU understand how it relates to existing notations.

Howeve r, caution is advised. We need to be .especially careful about the termilllol- ogy we use when modeli ng require ments. Many of the requirements notations are based on successful design me thods and notations, which means that most other refer- e nces for the notatio ns provide examples o f designs rather than of requirements, and give advice about how to make design-orie nted mo de ling decisio ns. Requireme nts decisions a re made fo r di[fe rent reasons, so the terminology is interpreted differently. Fo r exa mple, in require ments modeling we discuss decomposition, abstraction, and separation of concerns, all o f which were o riginally design techniq ues for creating ele - gant moduJa r designs. We decompose a require me nts specification a long separate con- cerns to simplify the resulting mod el and make it easier to read and to understand. In contrast, we decompose a design to improve the system 's quality attributes (modular- ity, maintai nability, pe rformance, time to deli very, etc.); the re quireme nts name and constrain those attributes, but decomposition plays no role in this aspect of specifica- tion. Thtus, altho ugh we use the terms decomposilion and m odularity in both specifica- tio n and design, the decompositio n decisio ns we make at each stage are differen t because they have di ffe rent goals.

Throughout this section , we illustrate nota tio ns by using them to model aspects of the turnstile proble m introduced earlier (Jackson and Zave 1995) and a library prob- le m. The library needs to track its texts and o ther materials, its loan records, and inlor- mation about its patrons. Po pular items are placed on reserve, meaning that their lo an pe riods are shorter than those of o the r books and mate rials, and that the penalty for re turning the m late is hig he r than the late penal ty for re turning unreserved items.

Entity-Relationship Diagrams

Ea rly in the requireme nts p hase, it is conve nie nt to build a conceptual model o f the proble m that ide ntifies what o bj ects o r e nti ties are invo lved , what they look like (by de fining their attributes), and how they re late to o ne another. Such a mo del designates names fo r the basic eleme nts o f the proble m. These eleme nts are then re used in ot her

158 Chapter 4 Capturing the Requirements

descriptions o f the requirements (possibly written in othe r notations) that specify how the o bjects, their attribu tes, and their re lationships would change in the course of the proposed system's execution. Thus, the conceptual model helps to tie together multiple views and d escriptions o f the require ments.

The e ntity-re lationship diagram (ER diagram) (Chen 1976) is a popular graph.ical nota tional pa radigm for representing conceptual models. As we will see in Chapter 6, it forms the basis of most o bject-oriented require ments and design notations, where it is used to mode l the relationships among objects in a problem description o r to model the structure o f a softwa re a pplication. This nota tion paradigm is also popular for describ- ing database schema (i.e., describing the logical structure of data stored in a database).

ER d iagrams have three core constructs-entities, attributes, and relations-lthat are com bined to specify a p roble m's e le ments and their interrelationships. Figure 4.4 is an ER diagram of the turnstile. An e ntity, depicted as a rectangle, represents a coUec- tio n (some times ca lled a class) o f rea l-wo rld objects that have commo n properties and behavio rs. Fo r e xample, the world contains many Coins, but fo r the purpose of mo del- ing the turnstile problem, we treat all Coins as being equi vale nt to o ne another in au aspects (such as size, shape, and weight) except perhaps fo r thei r monetary value. A relations hip is depicted as a n edge between two e ntities, with a diamond in the middle of the edge specifyi ng the type of relationship. An attribute is an annota tion on an entity that d escribes data or prope rties associated with the entity. Fo r example, in the turnstile proble m, we are most in terested in the Coins that are inserted into the turn- stile's CoinSlot (a relatio nship), and how their monetary values compare to the price of admission into the zoo (comparison of attribute values). Va ri ant E R nota- tio ns introduce additio nal constructs, such as attributes on relati o nships, one-to -many re lationships, many-to -many re latio nships, special relationships like inheritance, and class- based in addition to individual-entity-based attributes. Fo r example, our turnstile mode l s hows the ca rdina lity (sometimes called the " arity") of the re la tio nships, assert- ing that the turnstile is to admit multiple Visitors. Mo re sophisticated notations have the concept o f a mutable e ntity , whose membership or whose relations to mem- be rs o f o ther e ntities may change over ti me. For example, in an E R diagram depicting a family, fa mily members and their interrelations change as they get married , have children, and die. By conventio n, the e ntities and re lationships are laid o ut so that re la- tio nships are read from left to right, o r fro m top to bottom.

ptltt ol ~i111lulo"

Col" Co11Slot

Bttller

loth4 # Ulllll

FIGURE 4.4 Entity-relationship diagram of turnstile problem.

Openmirrors.com

Section 4.5 Modeling Notations 159

ER diagrams are popular because they provide an overview of the problem to be addressed (i.e., they d epict all of the parties involved ), and beca use this view is rela- tively s table when changes are made to the pro blem 's require ments. A change in requirements is more likely to be a change in how one or more entities beha ve than to be a change in the set o f participating entities. For these two reasons, an ER diagram is Likely to be used to mo del a problem ea rly in the requirements process.

The sim plicity of ER no tations is deceptive; in fact, it is quite difficult to use ER modeling no tations weU in practice. It is no t always obvious at what level of d etail to model a pa rticular problem , even though the re are o nly three majo r language con- structs. For e xample, should the barrie r and coin slot be modele d as entities, or s hould they be re presente d by a mo re abstract turnstile entity? Also, i t can be di fficult to decide what data a re e ntities and wha t data are attributes. For example, sh ould the Jock be an entity? There are arguments for and against each of these choices. The primary crite ria fo r making decisions are whe ther a cho ice results in a clearer description, and whether a cho ice unnecessarily co nstrains design decisions.

Exa mple : UML Class Dia grams.

An ER no tation is often used by more complex approaches. For example, the U nified Modeling Langua ge ( U ML) (OMG 2003) is a coUection of notations used to document softwar·e s pecifications and designs. We will use UM L extensive ly in Chapter 6 to describe o bject-ori ented specifica tio ns and designs. Beca use UML was originally con - ceived for o bject-oriented systems, it represents systems in terms of objects and method s. Objects a re akin to e ntities: they a re o rg anized in classes that have an inheri- tance hie ra rchy. Each object provides me tho ds that perfo rm actions on the object's variables. As o bj ects execute, they send messages to invoke each oth er's metho ds, acknowledge actions, and transmit data.

The flagship model in any UML specificatio n is the class diagram, a sophisticated ER diagram relating th e classes (entities) in the specification. Although most UML texts treat class diagrams primarily as a design nota tion , it is possible and conveni ernt to use UML class diagrams as a conceptual modeling notation , in which classes represent real-world e ntities in the problem to be mo deled. It may be that a class in the concep- tua l model, such as a Cus tome r class, corresponds to a program class in the implemen - tation, s uch as a C us tomerR ecorcl, but this need no t always be the case. It is the software designe r's tas k to take a class-diagram s pecification and construct a suitable design mode l o f the impleme ntation's class structure.

In general, the kinds o f real-wo rld e ntities that we wo uld want to represent in a class diagra m include actors (e.g., patro ns, ope ra tors, personnel)~ complex data to be sto red , an alyzed , transfo rmed, o r displa yed; o r records of transie nt events (e.g., busi- ness transactio ns, p ho ne conversa tio ns). The entities in o ur libra ry proble m include people, Like the patrons and librarians; the ite ms in the library 's inventory, like books and periodicals; and loan transactions.

Figure 4.5 depicts a simple UML class d iagram fo r such a li brary. Each box is a class that represents a collectio n o f similarly typed entities; for exa mple, a single class represe nts a ll o f the Library's books. A class has a name; a set of attributes, which are simple data varia bles whose values ca n vary over time and among different entities of

160 Chapter 4 Capturing the Requirements

Pt lttr1 * hhlleatltn * ~ttton ID 0 •. 1 bo110Wt o .. * u ll au11bi1 llU bOllOWtl I mle

poute 1'41m I Y1lce ~ fl nu I depml1tlon

1 eheekhnu()

I

fun ul•' lnmm llnun l tt• .. ,,,, r1111nuu due 41te ruerte loan fetlod rmllNot fll over4o hnt ruerte 1in1 ttl•

I 11pouu ule 4ce 411e() rmil~erlO<I

ule mr4u• hne() lt14j1111•1: Plbltullon nmted to rmwO hrll

rmll() Im() borrow(I ret~rno IUtrlt() UftllHrll(I 4mmmua(I

y I

l ttk Pttltdlul

M~or ''''°' ,.,,,.. 1u111h1

~ --·- 0

* Artie le

1utho1

FIG URE 4.5 UML class model of the library problem.

the class; a nd a set of o pe rations o n tbe class's att ri butes. By "simple data va riable," we mean a va riable whose values are loo simple for lbe variable to be a class by itself. Thus, we model a Patron's address as an attri bute, likely as one or more string values, whereas we would model a Patron's credit card information, cre dit institution, credi t card nU1 mber, e xpiratio n date, o r bill ing address as a separate class (not shown). Note that ma ny attributes we might e xpect in the library class d iagram a re mjssing (e.g., records and films) o r a re imprecisely defined (e.g., pe riodical, which doesn't distinguish between newspapers and magazines), and operations are omitted (e.g., dealing with book repair o r loss). Th is imprecisio n is typical in ea rly conceptua l diagrams. The idea is to p rovide e nough attributes and operatio ns, a nd in sufficie nt de tail , that anyone who reads the specification can grasp what the class re presents and what its respon- sibilities are.

U ML also allows the specifier to designate attributes and operations as being asso- ciated with the class rather than with instances of the class. A class-scope attrib ute , represented as an unde rlined attribute, is a data va lue that is shared by all instances of the class. In the library class diagram , the attributes reserve loan period and reserve fine rate are val ues tbat apply to all publica tio ns on reserve. Th us in this model, the

Openmirrors.com

Section 4.5 Modeling Notations 161

Librarian ca n set and modify the loan duration fo r classes of ite ms (e.g., books, periodi- ca ls, items o n reserve) but not for individual items. Similarly, a class-scope operation, written as an underlined operation , is an operatio n performed by the abstract class, rather than by class instances, on a new instance or on the whole collectio n of instances; create (),search () , and delete () are common class-scope operations.

A Line betwee n two classes, called an association, indicates a relatio nship between the classes' entities. An association may represent intera ctions or even ts that involve o bjects in the associated classes, such as when a Patron borrows a Publication. Alte rnative ly, an association might re late classes in which o ne class is a property o r e le- ment of the other class, such as the relationship between a Patron and his Credit Card. Some times these latte r types of associations are aggregate associations, o r "has-a" re lationships, as in o ur exampl e . An aggregate associa tion is drawn as an association with a white diamo nd o n o ne end, whe re the class at the diamond end is the aggregate a nd it includes o r o wns instances of the class( es) at th e othe r end (s) of the associatio n. Compositio n association is a special type of aggregatio n , in which instances o f the com- pound class are physically constructed from instances of t he componen t dasses (e.g., a bike consists of wheels, gears, pe dals, a handle bar); it is re presented as an aggregation with a black diamond. In our library model, each Periodical,such as a newspape r or magazine, is composed of Articles.

Ao associatio n with a triangle o n one e nd rep resents a generalization associatio n, a lso called a sub-type re lation o r an "is-a" rela tion, whe re t he class at the triangle e nd of the association is the parent class o f the classes at the o the r ends of the association, ca lled subclasses. A subclass inhe rits all of the parent class's attributes, ope rations, and associations. Thus, we do not need to specify explicitly that Patrons may borrow Books, because this association is inherited from the association between Patron a nd Publication. A subclass exte nds its inhe rited behavior with additio nal attrib- utes, ope rations, and associations. In fact, a good clue as to whether we want to model an entity as a ne w subclass, as opposed to as an instance of an e xisting class, is whether we really need ne w attributes, o perations, or associations to mode l the class va riant. In many cases, we can model variants as class instances that have di ffe re nt attribute values. In our Library proble m, we represent whether an ite m is on reserve or on loan using Publication attributes2 rather than by creating Reserved a nd OnLoan subclasses.

A ssociations can have labe ls, usually verbs, that describe the relatio ns.hip be tween associated e ntities. An end of an association can also be labeled, to descri be the ro le that entity plays in the association. Su ch role names are useful for specifying the conte xt o f an entity with respect to a particular association. In the Library example, we might keep track of which patrons are married , so that we ca n warn someone whose spouse has ove rdue books. A ssociation ends ca n also be annotated wit h multiplicities, which specify constraints o n the number of entities and the number of hnks between associated enti- ties. Multiplicities can be expressed as specific numbers, ranges of numbers, o r unlimited numbers (designated "*").A multiplicity on one end of an association indicates how

2 In later examples, we model an item's loan state and reserve state as states in a state-machine model (Figure 4.9), and this information is included in the library's detailed class model (Figure 4.18) .

162 Chapter 4 Capturing the Requirements

man y instances of that dass can be Linked to one instance of the associated class. Thus at any point in time, a Patron may bo rrow zero o r mo re Publicat i o ns , but an individ- ual Publication can be borrowed by at most on e Patro n.

The L oan class in the library mo de l is a n association class, which relates att rib- utes a nd o pe ratio ns to a n associatio n. Associatio n classes are used to collect informa- tion tha t canno t be attributed solely to o ne class o r a nother. For example, the L o an attributes are no t properties o f the bo rrowe r o r of the item borrowed , but rathe r of the loan transactio n or contract. An associatio n class has exactly o ne instanti ation pe r link in the associa tio n, so o ur modeling Loan as an association class is correct onJy if we want to mode l snapsho ts of the libra ry inventory (i.e., model o nly current loans). If we wanted instead to maintain a histo ry of all lo an transactio ns, the n (because a p atron might bo rrow a n item multiple times), we would model Loan as a full-Hedged class.

Eve nt Traces

Altho ugh ER diagrams are helpful in providing a n overall view o f the problem be ing modele d , the view is mostly structura l, showing which entities are relate d; the diagram says no thing about ho w the e ntities are lo behave. We need o ther no ta tion paradigms for describing a system's beha vio ral requirements.

An event trace is a graphical description o f a sequence of events that are exchanged between reaE-wo rld entities. Each vertical line represents the timeline for a distinct entity, whose name appea rs at the top of the line. Each ho rizontal line repre- sents an e vent o r interactio n between the two entities bounding the Line, usually con- ceived as a messase passed from o ne e ntity to ano ther. Time progresses fro m the to p to the bo ttom of the trace, so if o ne event appears above ano the r event, then the upper eve nt occu rs be fo re the lower event. Each g raph depicts a single trace, representing only o ne of severa l possible be havio rs. Figure 4 .6 shows two traces for the turnstile problem: the trace o n the left represents typical be ha vior, whe reas the trace on the right sho ws exceptio na l behavio r o f what happens when a Visitor tries to sneak iinto the zoo by inse rting a value less to ken (a slug) into the coin slo t.

Eveot traces are popular among both developers and custo mers beca use traces have a semantics that is re la tively precise, with the e xception o f timing issues, yet is simple and easy to understand. Much o f the simplicity comes from decomposing requirements descriptions into scenarios, and conside ring (mo de ling, reading, understanding) e ach

Ylrltor

coin

puh

IOltll~

coin

puh

101m~

ttmrtlle Wlsltot

1lu9

t lu9

slug

coin

rotttd

FI GURE 4.6 Event traces in the turnst ile problem.

Openmirrors.com

Section 4.5 Modeling Notations 163

scenario separately as a distinct trace. But these very properties, make even t traces ine fficie nt fo r documenting behavior. We would not want to use traces to provide a com- ple te description of required behavio r, because the nwnber o f scenarios we would have to draw can quickly become unwieldy. Instead, traces are best used at the start o f a project, to come to consensus o n key require me nts and to help developers identify impo rtant entities in the pro blem being mo deled.

Exa mple: Message Sequence Chart

Messag,e Sequence C harts (ITU 1996) are an e nha nced event-trace notation, with facil- ities for creating and destroying entities, specifying actio ns and timers, and composing traces. Figure 4.7 displays an example Message Sequence Chart (MSC) for a loan trans- action in o ur library problem. Each vertical line re presen ts a pa rticipating entity, and a message is depicte d as an arro w fro m the sending en tity to the receiving entity; the arrow's label specifies the message name and data parame ters, if any. A message arrow may slo pe do wnwa rds (e.g., message recall n oti ce) to reflect the passage of time be tween when the mess age is sent and when it is received. Entities may come and go during t he course of a trace; a dashe d arro w, o ptio na ll y anno ta ted with data parame- ters, represents a create e vent that spawns a new e ntity, and a cross at the bottom of an e ntity liine represents the end of tha t e ntity's e xecutio n. In contrast, a solid rectangle at the e ndl o f the Line re presents the end o f an e ntity's specificatio n without meaning the e nd of its executio n. Actions, such as invoked ope rations or changes to variable values, a re specified as labeled rectangles positioned on an entity's execution Line, located at

Publledlon Pstm

borrow(p11101)

no 1111

esle 4o 411•

publlcttlon on loin

lltel"ie reetll

1mll nollhut101(publlestlon)

lll!UIR ,,,,,, eslc ovt14o fine

lnemnhm(omfo fine)

FIGURE 4 .7 Message Sequence Chart for library loan transaction.

164 Chapter 4 Capturing the Requirements

the point in the trace where the action occurs. Thus, in our MSC model of a library lo an , loa n requests are sent to the Publication to be borrowed, and the Publication entity is responsible for c reating a Loan entity that manages loan-specific data, such as tbe due date. Reserving an item that is out on loan results in a recall of that ite m. Re turning the borrowed ite m terminates the loan, but not befo re calcula ting the overdue fine, if any, for returning tbe item afte r the loan's due date.

There are facilities for composing and re fining Message Sequence Charts. For example, impo rtant states in an entity's e volution can be specified as conditions, repre - sented as labeled hexagons. We can the n specify a small collection of subtraces between conditions, and derive a variety of traces by composing the charts at points where the entities' sta tes are tbe same. For example the re are multiple scenarios between state publication on loan and the end of the loan transition: the patron renews the Loan once, the patron renews the Joan twice, the patron returns the publication, the patron re po rts the publicatio n as being lost. Each o f these subscenarios could be appended to a p re fix trace of a pa tron successfully bo rrowing the publication. Such composition and re finement features help to reduce the number of MSCs one would need to write to specify a proble m completely. However, these features do not completely address the trace-exp losion problem, so Message Seque nces Charts are usuaJly used only to describe key scenarios rathe r than to specify entire problems.

State Machines

State-machine notatio ns are used to represent collections of event traces in a single mode l. A state machine is a g raphical description o f all dialog between the system and its environment. Each node, called a state, represents a stable set of condi tions that exists between event occurre nces. Each edge, calle d a transition, represents a change in behavior o r conditio n due to the occurre nce o f an event; each transi tion is labeled with the triggering event, and possibly wi th an output event, precede d by the symbo l "/", that is genera ted whe n the transition occu rs.

State machines a re useful both for specifying d ynamic behavior and for describ- ing how behavior should change in response to tbe history o f even ts that have already occurred. That is, they are particularly suited for modeling bow the system 's responses to the same input change over the course of the system's executio n. Fo r each state, the set of transitio ns emanating fro m that state designates both the set of events that can trigger a r esponse and the corresponding responses to those events. Thus, when our turnstile (shown in Figu re 4.8) is in the unlocked state, its be havior is diffe re nt frnm

FIGURE 4.8 Finite-state-machine model of the turnstile problem.

Openmirrors.com

Section 4.5 Modeling Notations 165

when it is in state locked; in particular, it responds to different input events. If an unanticipated event occurs (e.g., if the user tries to push through the turnstile when the machine is in state lociked), the event will be ignored and discarded. We could h ave specified this latte r behavior explicitly as a tra nsition from state locked to state locked, trigge red by evem push; however, the inclusion of such "no-effect" transi- tions cam clutter the model. Thus, it is best to restrict the use of self-looping transitions to those that have an observable effect, such as an o utput event.

A path through the state machine, starting from the machine's initial state and following tra nsitio ns from state to state, represents a trace of observable events in the e nvironment. If the state machine is de terministic, meaning that for every state and event there is a unique response, the n a path thr o ugh the machine represents the event trace th at wiU occur, given the sequence of input events tha t trigger the path's transi- tions. Example traces of o ur turnstile specification include

coin, push, rotated, coin, push, rotated, ....

slug, slug, slug, coin, push, rotated, ...

which correspo nd to the event traces in Figure 4.6. Yo u may have encountered state machines in some of your other computing

courses.. In theory-of-computing courses, futile-state machines are used as automata that recognize strings in regular languages. ln some sense, state-machine specifications serve a simila r purpose; they specify the sequences of input and ou tput events that the proposed system is expected to realize. Thus, we view a state-machine specification as a compact re presentation of a set of desired, externally observable, event traces, just as a finite-sta te automaton is a compact representatio n of the set of strings that the automa - ton recognizes.

Exa mple: UML Statechart Diagrams

A UML statechart diagram depicts the dynamic behavior of the objects in a UML dass. A UML class diagram gives a static, big-picture view of a problem, in terms of the e nti- ties involved and lheir relationships; it says no thing about bow th e entities behave, or bow their behaviors change in response to input events. A statecbart diagram shows bow a class's instances should change state and how their attributes should change value as the objects inte ract with each othe r. Statechart diagrams are a nice counterpa rt to Message Sequence Charts (MSC). An MSC shows the events that pass between entities without saying much about each entity's behavior, whe reas a statechart diagram shows bow a single entity re acts to input events and generates output e vents.

A UML mode l is a colleclion of concu rre ntly executing statecharts--one pe r insta nti ated object-tha t commu nica te with each othe r via message passing (OMG 2003). Eve ry class in a UML class diagram has an associated statechart diagram t hat specifies the dynamic be havior of the objects of that class. Figure 4.9 shows the UML statechart diagram for the Publication class from our Library class model.

UML sta techart diagra ms have a rich syntax, much of it bor rowed fro m Harel's o riginaE conceptio n o f sttatecharts (Hare! 1987), including state hie rarchy, concurre ncy, and interrnacbine communication. State hierarchy is used to unclutter diagrams by col- lecting into superstates those states with commo n transitions. We can think of a superstate

166 Chapter 4 Capturing the Requirements

Publication

bolfowlpttron) "lot n.erutelpttm, ult)

~ ~(~1-nl-lb-,,-~----.i::::=:=;;~-~~-'-'u_ne~•1~~-==:J~-_;._~o-nl_n_•__,

--,.-,,-,.- "- 1-u -n.-ie-le-le-

rawn

tUtb

FIGURE 4.9 UML sta tecb art diagram fort he Publication class.

as a submacbine, with its own set of sta tes and transitions. A transitio n whose destina- tio n state is a supe rsta te acts as a tra nsition to the supe rsta te's default initial state, d es- igna ted by an arrow from tbe supe rstate's internal black circle. A transition whose source s tate is a supersta te acts as a set of transitio ns, o ne from each of the superstate's inte rnal states. Fo r example, in the Publicatio n state diagram, the transitio n t rig- gered by event lose cam be e nabled fro m any o f the supe rstate's internal states; this tra nsitio n e nds in a fina l sta te and designates the e nd o f the o bject 's life.

A supe rstate can actua lly comprise multiple concurrent submachines, separated by dashed lines. The UML sta techa rt for Publication includes two submachines: o ne that indicates whe ther o r not the publication is out on loan, and another that indicates whether or not the publication is o n reserve. The submachines are said to ope rate concurrently, in tha t a Publication instance could at any time receive and respond to events of inte rest to eithe r o r both submachines. ln gene ral, concurrent submachines are used to mo del separate, unre lated subbehaviors, making it easie r to understand and conside r each subbe havior. An equivalent sta techart for Publication in Figure 4.10 that does not make use of state hierarchy o r concurrency is compara tively messy and re petitive. Note that this messy statecha rt has a state for each combination o f states from Figure 4.9 (stacks "' Publication is in library and not on reserve, onloan "' Publication is o n loan and not o n reserve, etc.).3

31be messy statechart also has a recall sta te that covers the case where a publication that is being put on reserve is o n loan and needs to be recalled; this behavior cannot be modeled as a t ransition from on loan to r eserveloan, because state reserveloan bas a transition cancel (used to disallow a loan request if the Pa tr on has outstanding fines) that would be inappropriate in this situation. This special case is modeled in Figure 4.9 by tesring o n entry ( keyword entry is explained below) to state reserve whether the concur- rent submachine is In state on loan and issuing a recall event if it is.

Openmirrors.com

Section 4.5 Modeling Notations 167

Publication

borrow(pttron) " Lou.crute(pttron, tell)

lhtb cancel

return Aloin.411111

1etun Al02n.41lete

Ion borrow( patron)

1011 Alou.m1te(p1tron, tell)

cancel

return "loin.lelm

FIG URE 4.10 Messy UML statechart diagram for Publication class.

State trans itions are labele d with their enabljng events and conditions and with their side effects. Transition labels have syntax

event (args) [condition] /action* "Object . event (args) *

where the triggering event is a message that ma y carry paramete rs. The enabling conditi on, delimited by square brackets, is a predicate on the object's a ttribute values. If the transition is take n, its a<.1ions, each prefaced with a slash (/),specify assignme nts made to the o bject's attributes; the asterisk "*" indicates that a transitio n may have arbitrarily man y actions. If the transition is taken , it may generate arbitrarily many o utput events, /"Object . event, each prefaced with a caret (");a n o utput event may ca rry parameters and is either designated fo r a target Object or is broadcast to aU o bjects. For example, in the messy Publication statechart (Figure 4.10), the transi- tio n to state recall is enabled if the publication is in stalle onloan whe n a request to put the ite m on reserve is received. When the transition is taken, it sends a n event to the Loan o bject , which in turn will notify the borrowe r that the item must be returned to the Library soone r than the loan 's due date. Each of the transition-label elem ents is o ptio na l. For example, a transition n eed not be enabl ed by an input event; it could be e na bled o nly by a condition or by no thing, in whjch case the transitio n is a lways e nabled.

The U ML statechart diagr am fo r the Loan association class in Figure 4.11 illus- trates how states can be annotated with local variables (e.g., variable nwn renews) , actions, a nd activities. Variables that are local to a state a re declared and initialized in

168 Chapter 4 Capturing the Requirements

eheck llau

tnlry " p1tm.ch1cklln11(J

Loan

no fine " publlullon.formmlue()

Iott " p11ton.lncremfln11(p•blle1tlon.nlu1)

llne " p1bllutlon.e11eel

llftlW

"Pq•l11e1tlon.Jurmmloe()

n1111 ltntWt :e 0

entry /no11 11new++ 41 /ulc •ue d1t1(bouewl m 1ll "p1tron.rmllNot1fy(poblletlloil

/cilc due date (mall)

''''" 41 /u le omdu1 llne(I

"pttm.lnerem llnu(owdue fine)

FIG URE 4. 11 UMLstatechart diagram for Loan class.

the center section of the stale. The sta te's lower section lists actions and activi ties on the sta te's local variables as well as on the object's attributes. The distinction between actions and activities is s ubtle: an action is a computation that takes relatively no t ime to comple te and that is uninterruptible, such as assigning an expressio n to a variabl e or sending a message. An action can be triggered by a transition e nte ring or exiting the sta te, io which case it is d esignated by keyword entry or exit foUowed by arbitrarily ma ny actions and generated e vents; or it ca n be triggered by the occurrence of an eve nt , in which case it is designated by the event name followed. by a rbitra rily man y actio ns and gene rated e vents. In our Loan statechart, variable num renews is incre- mented! eve ry time state item on loan is entered , that is, every time the loa n is re newed; and a recallNotify even t is sent to the Patron whenever a recall event is received in that state. In contrast to actio ns, an activity is a mo re complex com- puta tion tha t executes o ver a pe riod o f time and that may be interruptibl e, such as exe- cuting an o peration. Activities are initiated o n entry to the state. When a trans ition, including a looping transitio n like the one triggered by renew, e xecutes, the o rde r in wh ich aclio ns a re appl ied is as fo llows: first, the e xit acti ons o f the transitio n's source state are applied , followed by the transitio n's own actio ns, follo wed by the entry actions and activities o f the new state.

The semantics o f UML diagrams, and how the different diagrams fit together, are intentionaUy undefined, so that specifiers can ascribe semantics that best fit their prob- le m. Howe ver, most practitione rs view UML statecharts as communicating finite -state machines with first-in, first-out (FIFO) communication channels.. Each object's s.tate machine has an input queue that holds the messages sent to the object from other o bjects in the mode l o r fro m the mode l's environment. Messages are sto red in the input

Openmirrors.com

Section 4.5 Modeling Notations 169

queue in tbe order io which they are received. In e ach execu tion step, tbe state machine reads the message at the head of its input queue, removing the message from the que ue. The message either trigge rs a transition in tbe statecbart or it does not, in whicb case the message is discardedl; the step runs to completion, meaning that the machine contin- ues to e xecute e nabled transitions, including tra nsitions that wait for ope rations to complete, until no mo re transitions can execute without new input from the input que ue. Thus, the machine reacts to only o ne message at a time.

The hardest part o f constructing a state-machine mode l is deciding ho w to decompose a n object's be havio r into slates. Some ways of thinking about states include

• EquivaJence classes of possible future behavior, as defined by sequences of input events accepted by lhe machine: for exa mple, every iteration of event seque nce coin, push, rotated leaves the turnstile in a locked position waiting for the ne xt visito r

• Pe riods of time between consecutive events, such as the time be tween the start and the end o f an operation

• Named control points in an object's evolution , during which the object is performing some computation (e.g., state calculate fine) or waiting [or some input event (e.g., state item on loan)

• Partitions of an o bject's be havior: for example, a book is out on lo an or is in the library stacks; an item is on reserve, meaning that it can be borrowed for only sho rt periods, o r it is no t on reserve

Some object prope rties could be mode led either as an attribute (defined in the class diagram) or as a state (d e fined in the object's statechart diagram), and it is not obvious which re prese ntation is best. Certainl y, if the set o f possible prop erty values is large (e.g., a Patron's Libra ry fines), the n it is best to mode l the prope rty as an attribute. AJte rnatively, if the events to which the object is ready to react de pend on a property (e.g., whe the r a book is out on lo an), then it is best to model the property as a state. Othe rwise, choose the re presentation that results in the simplest mo del that is easiest to unde rstand.

Example: Petri Net s

UML statechart diagrams nicely modularize a problem's dynamic behavio r into the be haviors o f individua l class objects, with the e ffect that it ma y be easier to consider each class's be havior separately than it is to specify the whole proble m in one diagram. This mo dula riza tion ma kes it harder, tho ugh, to see how objects inte ract with each o the r. Looking at a n individual statechart diagram, we ca n see when an object sends a message to anothe r o bject. However, we have to examine the two objects' diagrams simultaneously to see that a message sent by o ne object can be received by the other. In fact, to be completely s ure, we would have to search the possible e xecutions (event traces) of the two machines, to confirm that whe neve r one o bject sends a message to the othe r, the target object is ready to receive and react to the message.

Pe tri ne ts (Pe terson 1977) are a form of sta te-transition notatio n that is used to model concurrent activities and tbe ir interactions. Figure 4.12 sho ws a basic Petri net specifying the be havio r of a book loa n. The circles in the net are places that represent

170 Chapter 4

lnltllt1 Loin

Capturing the Requirements

Lou R1qu111

On loin

FIGURE 4.12 Petri net of book loan.

lnltl1t1 R1tu11

activities o r conditio ns, and the bars represent tra nsitions. Directed arrows, caUed arcs, connect a tran sition witb its inpul places and its output p laces. The p laces are p opula ted with tokens, wrucb act as en abLing condjtions for Lhe transitions. Wlhen a transition jires, it re moves to ke ns from e ach o f its input places and inserts toke ns into each of its o utput places. Each arc can be assigned a weight that specifies how many tokens are removed from the arc's input place, or inserted into the ar c's o utput place, when the transition ftres. A lransjtion is enabled if e ach of its input places contains en ough tokens to con- tribute its arc's weight's worth of tokens, sh ould the enabled transitio n actually fire. Thus, in Figure 4.12, transitio ns Re turn, Withdraw Re turn Reque s t, and Withdraw Lo an Re quest are all e nabled ; firing transition Return removes a toke n from each of the places ReturnReques t and OnLoan, and inserts a token into Avail. The n et's ma rkjng, which is the dis tribution of to kens among places, changes as transitions fire. In e ach executio n step, the marbng dete rmjnes the set of enabled transitio ns; one en abled transitio n is nondeterm inistically selected to fire; the firing of thfa t ransition produces a new markjng, wruch may ena ble a diffe rent set of transitions. We can model concurren t behavio r by combilling into a single net the activities, transitions, and to kens fo r several executing entities. Concurre nt entities are syncluoruzed whenever the ir acti vities, o r places, act as input places to the same transition. Thjs syn chronization e nsures th at alJ o f the pre -transitio n activities occur before the transition fires, but does not constrain the orde r in which these activities occur.

These features o f concurre ncy and synchronizatio n are especially useful fo r mod- e ling events whose o rde r of occurrence is not impo rtant. Consider the eme rgency room in a hospital. Be fore a pa tient can be treated , several events must occur. TI1e triage staff must attempt to find out the name a nd address of the patient and to dete rmine the patie nt's blood type . Someone must see if the patient is breathing, and also examjne the patie nt fo r injuries. The eve nts occur in n o particular order, but all must occur before a team o f doctors begins a more thorough examination. Once the tre atmen t begins (i.e., once the transition is made from a preliminary examination to a th orough ooe), tbe docto rs start ne w activities. The orth ope dic doctors check for broke n bo nes, while the be matologist runs blood tests and the surgeon p uts stitches in a bleeding

Openmirrors.com

Section 4.5 Modeling Notations 171

wo und. The doctors' activities are independent of one anothe r, but no ne can occur until the transitio n from the pre limjn ary examination takes pla ce. A state-machine mode l o f the eme rgency room might specify o nly a single o rder of events, the reby excluding sev- e ral acceptable behaviors, or it might specify all possible sequences o f events, resulting in an overly complex model for a re latively simple problem. A Petri ne t model of the sa me e me rge ncy room nice ly avoids both of these problems.

Basic Petri nets are fine for modeling bow control flows through events or among concurrent e ntities. But if we want to model control that depends o n the value o f data (e.g., borrowing a parti cular book fro m a collection of books), then we need to use a high-leve l Pe tri ne t no tation. A num ber of extensions to basic Petri nets have been pro- posed to improve the notation 's expressibility, including inhibito r arcs, which enab le a transitio n o nly if the input place is empty of tokens; priority among transilions; timing constraints; and struc ture d tokens, which have values.

To model our library problem, which tracks info rma tion and events for multipl e patrons and publications, we need a Petri ne t notation that supports structured tokens a nd transitio n actions (Gh ezzi e t al. 1991). A transition action constrains which tokens in the input places can en able the transition an d specifies the va lues of the o utput tokens. Figure 4.13 is a hi gh-level Pe tri net specifica ti on for the library problem. Each place stores tok ens o f a diffe re nt data type. Avail stores a token fo r every library i tern that is not curre ntly o ut o n loa n. A toke n in Fines is an n-tuple (i.e., an orde red se t of n eleme nts, some times called a tuple for short) that maps a patron to the value

lnltlttt 1.otn

'''J P1y111ut I 1erutt flnu

'''""~· f'Y/11161/ /. \ Proun 1,,,,,,, n,,, ~ ,,,,,., n •• , P1ynent '''""· ""'" fill/

'''''"'· f/a11 - f1y111111/ ? Avtll ~,~:4u

flnu r\_

~ ''''"'· ,,,,,,, ,,,., flm{p1tr01/~o 111111 "'\_____/

Bolf~ ~t~rn ,,,,,,,, """' '''''"· "'"· ''''"'· ,,,,., ''""'· ,,,,., ,.,,,,,, ,,,,,,.,

D Onuan -Wlthfow loin Requeit Wtthfow Rtturn Reqmt

FIGURE 4. 13 Petri net of the library problem.

lntttst• Ret~rn

172 Chapter 4 Capturing the Requirements

of his or he r to tal o utstanding library fines. A toke n in OnLoan is another type of tuple tbat maips a patron and a library item to a due date. A few of the transition predi- cates and actions are shown in Figure 4.13,such as the action on Process Payment, where the inputs are a payment and the patron's current fines , and the output is a new Fines tuple. The p redicates no t shown assert that if the to ke n e lements in a tran- sitio n's input o r o utput tokens bave tbe same name, tbey must bave tbe same value. So in transition Borrow, the patron making the Loan Request must match the patron with no outstanding Fines and match the patron who appears in the gener- ated OnLoan tuple; al the same time, the item be ing borrowed must match an item in Avail. Othe rwise, those tuples do not e nable the transition. The net starts with an initial marking of item tuples in Avail and (patron, o) tuples in Fines. As library use rs trigger input transitions Pay, Initiate Loan, and Initiate Return, new to kens are introduced to the system, which enable the library transitions, which in t urn fire and update the Fines to kens and the Avail and OnLoan toke ns, and so on.

Data-Flow Diagrams

The notatio n pa radigms discussed so fa r promote decomposing a problem by entity (ER diagram); by scenario (e vent trace): and by control state (i.e., equivalence classes of scenarios) (state machines). However, early require ments te nd to be expressed as

• Tasks to be comple ted • Functions to be computed • Data to be analyzed, transformed, o r recorded

Such re quire ments, when decomposed by entity, scenario, o r state, devolve into colJec- tio ns of lowe r-level behaviors that are distributed among multiple entities and ll:bat must be coordinated. This modular structure makes it harder to see a model's high- le vel functionality. In our library example, none of the above modeling notations is effective in showing, in a single mode l, all of the steps, and their variants, tha t a patron must take to bo rrow a book. For this reason, notatio ns that promote decomposition by functionality have always been popular.

A data-flow diagram (DFD) mode ls functio nality and the flo w of data from one function to anothe r. A bubble represents a process, o r function, that transforms data. An a rrow represents data flow, where an arrow into a bubble re presents an input to the bubble's function, and an arrow ou t of a bubble represents one o f the function's out- puts. Figure 4.14 sho ws a high-level data-flow diagram for o ur Library problem. The problem is bro ke n down into steps, with the results of early steps flo wing into later ste ps. Data that pe rsist beyond the ir use in a single computatio n (e.g., info rmatio n about patro ns' o uts tanding fines) can be saved in a data store-a forma l reposito r y or database of info rmatio n-that is represented by two para llel bars. Data sources or sinks, re presented by rectangles, are actors: entities that provide input data or receive the output results. A bubble can be a high-level abstraction of another data-Ho w dia- gram that shows in mo re de tail how the abstract function is computed. A lowest-leve l bubble is a functio n whose effects, such as pre -conditio ns, post-conditio ns, exceptio ns, can be s pecified in another no tation (e.g., tex t, ma thematical functions, event traces) in a separa tely linked docume nt.

Openmirrors.com

Section 4.5 Modeling Notations 173

R1qmu to flt 1111111 on ""IYt

~Kftowl1d11ot llbttty h1011 ud co1t1ntt __ ...,.,_

putting 1111111 on m1rn

Ru11Ye R1co141

Uuso 11end1

1!11111 h11ow0 __ _,_ __ _

l.o1n R1m41

lt11111h11ow14 ~l11m1tetu111d-~

i 1!1111 1etq1n1d Rt lt1n /

Ou 41111 ltettt 11tu1ned

........... ~~ ...... Ptttont' Finer

0111du1 flntt- PtllOI 1-----P~mlll ------'~ - -----

O•tt11ndl19 flm

FIGURE 4 .14 Data-ftow diagram of the library problem.

One o f the strengths of data-flo w diagrams is that the y provide an intuitive mo del of a proposed system's high-level functio nality and of the data dependencies am ong the various processes. D omain experts find the m easy to read and understand. H ow- e ve r, a data-flow diagram can be aggravatingly ambiguous to a software d evelo pe r who is less familiar with the pro blem be ing mo deled. Tn pa rticular, there are multiple ways of interpreting a DFD process that has multiple input flows (e.g., process Borrow) : are all inputs need ed to compute the function, is only o ne of the inputs needed, or is some subset of the inputs needed? Similarly, there are multiple ways of interpreting a DFD process that has multiple o utput flows: are all o utp uts generated every time the process e xecutes, is o nly o ne o f the o utputs generated, or is some subset generate d? IL is also no t o bvio us that two da ta flows with the same annotation represent the same values: are the Items Returned that flow from Return to Loan Records the sa me as the Items Returned that flow from Return to Process Fines? For these reasons, DFDs a re best used by users who are familiar with the application domain being m od- e led, and as ea rly models of a proble m, when de tails are less important.

Example: Use Cases

A UML use-case diagram (OMG 2003) is simi lar to a top-level data-flow diagram t hat de picts o bservable, use r-initiated functio nality in te rms of interactio ns between the sys- tem and its environment. A large box re presents the system boundary. Stick figures out- side the box portray actors, both humans and syste ms, and each oval inside the box is a use case tha t represents some major required functio nality and its variants. A line be tween an acto r and a use case indicates that the acto r participates in the use case. Use cases are no t meant to model aU the tasks that the system sho uld p rovide. Rathe r, they are used to specify user views of essential system behavior. As such, they model onJy

174 Chapter 4 Capturing the Requirements

FIGURE 4.15 Library use cases.

Library lnmtory

system functionality that can be initiated by some actor in the environment. For example, in Figure 4.15, key Library uses include bo rrowing a book, returning a bor- rowed book, and paying a library fine.

Each use case e ncompasses seve ral possible scenarios, some successful and some no t, but au re lated to some usage of tbe syste m. Exte rnal to the use-case diagram, the use cases and their variants are detailed as textual event traces. Each use case identifies pre-co nditio ns and alternative be havior if the pre-conditions are not me t, such as look- ing for a lost book; post-conditions, whicb summarize the effects of the use case; and a normal, e rror-free scenario comprising a sequence of steps performed by actors or by tbe syste m. A co mple te ly de tailed use case specilies alJ possible variatio ns of each step in the no rma l sce na rio, including both valid beha viors and errors. It also describes the possible scenarios that s.tem from the valid variations and from recoverabl e failures. If tbe re is a seque nce o f ste ps common to seve ral use cases, the seque nce can be extracted o ut to form a subcase that can be caUed by a base use case like a procedure call. la the use-case diagram , we draw a dashed arrow from a base case to e acb of its subcases and annotate these arrows with stereotype «include».4 A use case can also be appended with an extension subcase that adds functio nality to the end of the use case. In the use-case diagram, we draw a dashed arrow from tbe extension subcase to the base use case and annotate the arrow with stereotype «extend». Examples of stereotypes are included in Figure 4.15.

4 1n UML, a stereotype is a meta-language facility for extending a modeling notation, allowing the user to augment o ne of the nota tion's constructs with a new « keyword» .

Openmirrors.com

Section 4.5 Modeling Notations 175

Functions and Relations

The notational paradigms d iscussed so far are representational and relational. They use annotated shapes, lines, and arrows to convey the entities, re lationships, and character - istics inivolved in t he prohl e m hei ng mode le d. In contrnst, the re maining t hree nota- tional paradigms lhal we discuss are more strongly grounded in mathe matics, and we use them to build mathematical models o f the requiremen ts. Ma thematically based specifica tion and design techniques, called formal methods or approaches, are encour- aged by many softwa re engineers who build safety-cri tical syste ms-that is, systems whose fail ure can affect the health and safe ty o f people who use them or who are nearby. For example, Defence Standard 00-56, a draft British standard for building safety-critica l systems, re quires that fo rmal specification and design be used lo demon- strate required functionality, re liability, and safety. Advocates argue that mathematical models are mo re precise and less ambiguous than o ther models, aod that mathematical mode ls lend the mselves to mo re systematic and sophisticated analysis and verification. In fact, many formal specifications can be checked automatically for consistency, complete- ness, nondeterminism , and reachable states, as well as for type correctness. Mathematical proofs have revealed significant problems in requireme nts specifications, where they are more easily fixed than if revealed during testing. For example, Pfleeger and Hatton (1997) re port o n software de velopers who used forma l methods to specify and evaluate the com- plex communications require ments of an air-tra ffic-control support system. Early scrutin)( of the formal specification revealed major problems that were fixed well before design bega n, the re by reducing risk as well as saving development time. At the end of this chapter, we see how formal specification might have caught problems with Ariane-5.

Some fo rma l paradigms model requirements o r software behavior as a collecllion of mathe matical functions or relations tha t, when composed toge the r, map system inputs to system outputs. Some functions specify the sta te of a system's execution, and other functions specify o utputs. A re lation is used instead of a function whenever an input value maps to more than one output value. For example, we can represent the turnstile proble m using two functions: o ne function to keep track of the state of the turnstile, mapping from the current state and inpu t event to the next state; and a second function to specify tbe turnstile's ou tput, based on the curren t state and input event:

Nextst·ate(s,e)

Output ( s, e) =

{

unloc~ed rotating

locked

{ buzz

< none>

s=loc:ked AND e=coin

s=unlocked AND e=push

(s=rotating AND e=rotated)

OR (s = locked AND e=slug)

s = loc:ked AND e = slug

Otherwise

Toge the r, the above funct ions are semanticall y equiva lent to the graphical state- machine model of the turnstile shown in Figure 4.8.

Because it maps each input to a single o utput, a function is by definition consis- tent. If lhe function specifies an output for every distinct input, it is called a total func- tio n a nd is by defi nitio n complete. Thus, fu nctional specifications lend themselves to systematic and straightforward tests for consistency and completeness.

176 Chapter 4 Capturing the Requirements

(event) bottew T T T F F F F F (•Yentl """ F F F T T F F F (eYent) tetll'YI F F F F F T T F (event) urutrve F F F F F F F f 111111 out on lun F T . F T F 111111 on tuerve F T patt0n.flnu > 40.00 F T

(R1-)Calnlote fo d111 x x Put 111111 In sucks x x Put 111111 on m1rv1 1h11f x x Sand mall notlee x Rejw emt x x

FIGURE 4. 16 Decision table for library functions.

Example: Decision Ta bles

A decision table (Hurley 1983) is a tabular representation of a functional specification tbat maps eve nts and conditions to appropriate responses or actions. We say that the specification is informal because the inputs (events and cond itions) and outputs (actions) may be expressed in natural language, as mathematical expressions, or both.

Figure 4.16 sho ws a decision table for the libra ry functions borrow, return, reserve, and unreserve. AJI of the possible input events (i.e., function invocatio ns), conditio ns, and actions a re listed along the left side of the table, with the input events and conditio ns listed above the horizontal line a nd the actions Listed below the Line. Each column re prese nts a rule tbat maps a set of conditions to its correspo nding result(s). An e ntry of "T" in a cell mean s that the row's input conditio n is true, "F" means that the input condition is false, and a dash indicates that th e value of the condi- tio n does no t matte r. Ao entry of "X" at the bottom o f the table means that the row's action s ho uld be performed whenever its corresponding input conditio ns hold. Thus, column 1 represents tbe situatio n wbere a library patron wants to borrow a book, the book is no t alieady out o n loan, and the patron bas n o outstanding fine; in this situation, the loan is approved and a due date is calculated. Similarly, column 7 illustrates the case where there is a request to put a book on rese rve but the book is currently out on loa n; in this case, the book is recalled and the due date is reca lculated to re flect the recall.

This kind of re presentation can result in very large tables, because the numbe r of conditio ns to conside r is equal to the number o f c·ombinations of input conditions. That is, iJ the re a re n input conditions, tbe re are 2n possible combinations of conditions. For- tuna te ly, many combinations map to the same se t of results and can be combined into a single column. Some combinations of conditi ons may be infeasible (e.g., an item cannot be borrowe d and re turn ed at the sa me time). By examining decisio n tables in this way, we can re duce tbeir size and make the m easier to unde rstand.

What e lse can we te ll about a requirements specificatio n that is e xpressed as a d ecision table? We can easily check whe ther every combination of conditions has been conside red, to de te rmine iJ the specifica tion is complete. We ca n e xamine the table for consiste ncy, by ide ntifying multipl e instances of t he sa me input conditions and e limi- nating any conflicting o utputs. We can a lso search the table for patterns to see bow stro ngly individual input conditio ns correlate to indi vidual actions. Such a sea rch wo uld be arduous o n a specification modeled using a traditional textual notatio n for express- ing mathematical functio ns.

Openmirrors.com

Section 4.5 Modeling Notations 177

Exa mple: Parna s Ta bles

Pamas tables (Pa mas 1992) are tabular representations of mathematical functions or rela- tions. Like decision tables, Pamas tables use rows and columns to separate a function's definition into its different cases. Each ta hie entry either specifies an input condition that partially identifies some case, or it specifies the output value for some case. Unlike deci- sion tables, the inputs and o utputs of a Pamas table are purely mathematical expressions.

To see bow Parnas tables work, consider Figure 4.17. The rows and columns de fine Cale due date, a n o pe ratio n in our library example. The information is repre- sented as a Normal Table, which is a type o f Pamas table. Tue column and row he aders are precticates used to specify cases, and the inte rnal table entries store the possible functio n results. Thus, ea ch internal table entry represents a distinct case in the flUlc- tion's de finitio n. For e xample, if the e vent is to re new a loan (column hea der), and the publicatio n being borrowed is on reserve (column heade r), and the patron making the request has no outstanding fines (row heade r), t hen the due date is calcula ted to be public a ti on. reserve loan period days from Today. A table entry of"X" indi- cates that the operatio n is invalid unde r the specified conditions; in other specifications, a n entry o f " X" could me an that the combinatio n of conditions is infeasible. No tice how the column and ro w headers are structured lo cover all possible combinations of condi- tions that can affect the calculation of a loaned item 's due date. (The symbol--, me ans " not", so •publication. Instate (reserve ) means that the publication is not on reserve.)

The phrase Pa mas tables actually re fe rs to a collection of table types and abbrevi- ation stra tegies fo r o rganizing and simplifying functional and re latio nal expressio ns. A no the r table type is ao Inverted Table, which looks more like a conve ntional decision table: case conditio ns are specified as expressions in the ro w heade rs and in the table e ntries, and the functio n resul ts are listed in the column headers, at the top or the bot- tom of the table. Io gene ral , the specifie r's goa l is to choose or cre ate a table format t hat results in a simple and oompact representation for the function or relation being spec- ified. The tabular structure of these re presentations makes it easy for reviewers to check that a specificatio n is comple te (i.e., the re are no missing cases) and consistent (i.e., the re are no duplicate cases). It is easie r to review each function's definition case by case, rathe r than e xamining and re asoning abo ut the whole specification at o nce.

A functio nal specificatio n expressed using Pa rnas tables is best decomposed into a single function per outpu t variable. For every input event a nd for every condiltion o n entit ies or o the r variables, each function specifies the value o f its corresponding o utput variable. The advantage of this model structure over a state-machine model is that the definitio n of each output variable is localized in a distinct table, rather than spread throughout the model as actions on sta te transitions.

nut E {lttttew, rutw) llltnf = rteall pultlleatlu.la State p1ltlleafltn. ln Stata

pat,. •• n .. = o publlutlu .mtlYI lun petlo4 publltttlon.lun pe11o4 Mln(4ut 4ttt, pu•1tc1tlon.r1ttll pttlo.l) patrt1.nu > o x x x

FIGURE 4.17 (Normal) Pa mas Jable for operation Cale due date.

178 Chapter 4 Capturing the Requirements

Logic

With the exception of ER diagrams, the notations we have considered so far have been model-based and are said to be o perational. An operational notation is a notation used to descrrihe a prohl e m orr a proposed software solution in terms of .si tuationa l he havior: ho w a software syste m sho uld respo nd to diffe re nt input events, how a computat ion sho uld :flow from one step to another, and what a system sho uld o utput unde r various conditions. The result is a mode l of case-based b.ehavior that is particularly useful for answering questions about what the desired response should be to a particular situa- tion: for example, what the ne xt state or system output should be, given the curren t state, input e vent, process comple tion, and variable values. Such models also he lp the reader to visualize glo ba l behavior, in the form of paths representing allowable execu- tion traces thro ugh the model.

Opera tional notations are less e ffective at expressing global properties or con- straints. Suppose we we re modeling a traffic light, and we wante d to asse rt that the Lights controlling traffic :in cross directions are neve r green at the same time, or that the Lights in e ach directio n are pe riodically green. We could build an operational model that e xhibits these behaviors implicitly, in that all paths through the model satisfy these pro pe rties. Howeve r, unless the model is closed- meaning that the model expresses all of the d esired behavio r, and that any imple mentation that pe rforms additional func- tionality is incorrect-it is ambiguous as to whethe r these properties are requireme nts to be satisfied o r simply are accid ental effects of the modeling decisions made.

Instead, glo bal prope rties and constraints are bette r expressed using a descriptive notation, such as logic. A descriptive notation is ai notation that describes a proble m or a proposed solutio n in terms of its p rope rties or its invariant beh aviors. For e xample, ER diag ra ms are descriptive, in tha t they express relationship properties among e nti - ties. A logic consists of a language for e xpressing prope rties, plus a set of infe rence rules for dermving new, consequen t prope rties from the stated prope rties. Jn mathe matics, a logical e xpression,5 calle d a formula, evaluates to either true or false, depending on the values of the variables that appear in the formula. In contrast, when logic is used to express a p roperty of a software problem or syste m, the property is an assertio n about the problem o r system that sho uld be true. As such, a property specification represents only those va lues o f the pro perty's va riables fo r which the property's expression evalu- ates to true.

The re are multiple va riants of logic that differ in bow expressive their prope rty nota tion is, o r in what infe re nce rules they provide. The logic commonly used to express pro pe rties o f software require men ts is first-order logic, comprising typed variables; constants; functio ns; pre dicates, like re latio nal o perators < and > ; equality; logical connectives/\ (and), V (o r),-, (no t) , => (implies), and ¢:::> (logic al equivale nce); and quantifiers 3 (the re exists) and V (for all). Consid er the following variables of the turn- stile proble m, with their initial va lues:

5You can think o f a logic as a functio n that maps expressions to a set of possible values. An 11-valued logic maps to a set of n values. Binary logic maps expressions to (true, false}, but n can in general be larger than 2. ln t his book, we assume that 11 is 2 unless otherwise stated .

Openmirrors.com

Section 4.5 Modeling Notations 179

nurn_coins : integer := 0

nurn_entries : integer := O;

harrier : {lock ed, unlocked} := locked ;

may_enter : boolean : = false; insert_coin : boolean : = false;

push : boolean : = false;

/ * number o f coins inserted

/ * number o f half-rotati ons of

turnstile

/ * whether harrier is l ocked

/* whether anyone may enter /* event of coin being inserted

/* turnstile i s pushed sufficiently

hard to rotate it one-half

rotation

*/

*/ * /

* /

*/

*/

The following are examples o f turnstile prope rties over these variables, e xpressed in first-orde r logic:

num_coins ~ num_entries ( num_co ins > num_entries) ~ (barrier = unlocked ) (barrier = locked) ~ ,may_en ter

Togethe r, these formulae assert that the numbe r of entries through the turnstile's bar- rier should never exceed the numbe r o f coins inserted into the turnstile, and that when- e ve r the number of coins inse rted exceeds the numbe r of entries, the barrie r is unlocked to allo w another person to ente r the gated are a. No te that these prope rties say nothing about how variables change value, such as how the number o f inse rted coins increases. Presumably, anothe r part of th e specification describes this. The above properties simply ensure tba t ho we ver the variables' valu es ch ange, the values always sa tisfy the fo rmulae's constraints.

Temporal logic introduces additional logical connectives for constraining how variables can change value over time-mo re precisely, ove r multiple po ints in an exe- cution. For example, temporal-logic connec tives can express immin e nt c hanges, like variable assignme nts (e.g., an insert_coin event resu lts in variable num_coins be ing incremented by 1), or they can express future variable values (e.g., afte r an insert_ coin event, variable may_enter re mains true until a push event). We can mode l this behavior in first-orde r logic by adding a time parameter to eacb o f the mode l's variabl es and asking about the value of a varia ble at a particular time. How- e ve r, tempo ral logic, in allowing va riable va lues to change and in introducing special te mporal logic connectives, re presents varying behavior more succinctly.

A s with logics in gene ral , the re a re many variants o f temporal logic, which differ in the connectives that they int.roduce. The fo llowin g (Linear-time) connectives co n- strain future variable values, over a single execution trace:

D f = f is true now and throughout tbe rest of the execution 0 f = f is true now or at some future po int in the execution 0 f = f is true in the next po int of the execution f W g = f is true untiJ a point where g is true, but g may never be true

In the following, the temporal turnstile properties given above are expressed in temporal logic:

O(insert_coin ~ 0 (may_enter w push)) 0 ( V' n ( i n sert_coin A num_coins=n) ~ 0 (num_coins n+l))

180 Chapter 4 Ca pt uring the Requi remen ts

Properties are often used to augment a mode l-based specification, either to impose constraints o n tbe mode l's a llowable behaviors or simply to express redundant but nonobvious global properties of the specification. lo the first case, a property spec- ifies beh avior not expressed in the model, and the desired behavior is the conjunc!l:ion of the nnodel ancl the prope rty. In the second case, the property does not alter the spec- ifiecl behavior but may aid in understanding the mode l by explicating otherwise implicit behavio r. Redundant properties also aid in req uirements verifica tion, by providing expected prope rties of the model for the re viewer to check.

Example: Object Constrai nt Lan guage (OCL)

The Obje <.1 Constraint Language (OC L) is an attempt to create a constraint language that is both mathe matically precise and easy for n onmathematicians, Like customers, to read, write, and understand. T he language is specially designed for expressing con- straints on o bject mode ls (i.e., ER d iagrams) , and introduces language constructs for navigating from one object to another via associa tion paths, for dealing with collections of objects, and for expressing queries on object type.

A partia l Library class model from Figure 4.5 appears in Figure 4.18, in which three classes have been de tailed and annotated with OCL constraints. The leftmost constraint is an inva riant on the Patron class, an d specifies that no patron's fines may

'""" * p111ot ID: l1t19er n1111 : strln~ 1ddreu : str n9 /ins: tHI

checkflnu(): 1nn1, noflu?; lnCfHll nnes INOHl:rul ; p1y hnes(11uut:rul); rmllNonly(pu•:Pultwlon)

lus~O

Pqbll .. 11u.t lliulHCH->!ot1ll(t' · r21 p1<>p2 iNpllu p1.ullu1h1 <> p2.ull1uNhr)

Pl&llntltn * 0 .. 1 httOWt 0 ..• ull nu111b11 : sttlns httOlllf I 11111 : strins

vslu: rHI I !

Lua due 4111 : 1)111 overdqe fi ne : rul

ult due im(opmtlot:llrin5) ult overdue llu() renew() rm Ill)

41pmbllo1 : 1111 lou 211io4 : Dmt1on1 Ont rate: ml rmr11 lun f!rloi : D1r1tlot mar1e fine rate: rul rmll teilo~ : Dumlon 1ot1 sute: 11111amy, onlotn} 1mr1t t tt te : {stte~1. tutrlt}

nn4jt1th : 11r119I: P~bl1ut1on hy(I lose() borrow( p1tm: Pttron) ratu1n() rmr11() Uflllrleq dmmmqel)

• rmotdltlon. borrower.lines = o ind Im 11111 = lnlibmy •rotteond1t1u,. pott: loin rllte = onlotn

FIGURE 4.18 Library classes an.notated with OCL properties.

Openmirrors.com

Section 4.5 Modeling Notations 181

have a negative value ( i.e., the library always makes change if a patron's payme nt e xceeds his o r he r fines). The lo pmost constra int is an inva riant on the Public atio n class, and specifies that call numbers are unique. This constraint introduces

• Construct allinstances, which returns all instances of the Publication class • Symbol - , which applies the attribute o r o pe ration o f its right ope rand to all of

the objects in its le ft o pe rand

• Constructs /oral/, and, and implies, which correspo nd to the first-order connec- tives d escribed abo ve

Thus, the constra int lite rally says tha t fo r any two publica tions, p l and p2 , returned by al/instan ces, if pl and p2 a re no t the same publicatio n, then they have different caU numbe rs. The third const raint, attached to the me tho d b o rrow (),expresses the o pe ra- tio n's pre- and post-conditio ns. One o f the pre-condi tions concerns an attribute in the Patron class, which is accessible via the b orrow association; the patron object can be referenc.ed eithe r by its ro le name, b o r rowe r , o r by the class name written in lowe r- case le tte rs, if the associatio n 's fa r end bas no role nam e. If the associatio n's multiplicity we re greate r than 0 .. 1, then navigat ing the associatio n wo uld re turn a collecti on o f o bjects,, and we would use - no ta tion, rathe r than do t no tatio n , to access the o bjects' attributes.

Altho ugh no t o riginally designed as part o f UML, OCL is now tightly coupled with UML and is pa rt of the UML sta nda rd. O CL can augm ent ma ny o f UM L's mod els. For example, it can be used to e xpress invarian ts, preconditions, and post-conditiorns in class diagrams, o r invariants and transitio n condi tio ns in statechart diagrams. It can also e xpress co nditions on e vents in Message Sequ ence Charts (Wa rme r and Kleppe 1999). OCL annotatio ns o f UML require a re latively detailed class model, complete with attribute types, o pe ra tio n signatures, ro le names, m ultiplicities, and state enume rations o f the class's statechart diagram. OCL e xpressio ns can appear in UML diagrams as UML n o tes, o r they can be Listed in a supporting d ocument.

Example: Z

Z (pronounced "zed ") is a formal requirements -specification language that structures set-theore tic definitio ns of varia bles into a comple te abstract-data-type mode l o f a proble m, a nd uses logic to express the pre- and post-conditions for each op eration. Z uses software-engi neering abstractio ns to decompose a specification into manageably sized modules, called sche mas (Spivey 1992). Sep a rate schemas specify

• The syste m sta te in terms of typed variables, and invariants on variables' values • The syste m's initial state (i.e., initial variable values) • Ope rations

Mo reove r, Z o ffers the precision o f a mathema tical no ta tion and au of its benefits, such as being able to evaluate specificatio ns using proo fs o r automa te d checks.

Figure 4.19 shows part of ou r li brary example specified in z. Patro n, Item, Date, and Dura tion a re a ll basic types tha t correspo nd to their respecti ve rea l-wo rld designa tio ns. (See Side bar 4.5 for more on designations.) The Library sche ma declares the problem to consist of a Catalogue and a set of items OnReserve, b oth

182 Chapter 4 Capturing the Requirements

[Patron, ltu1, Data, Dq11t1on) IAtnPerllo4 : Du11t1on; Ruer1ell41n : Dmtlon; D1llyfln.e : II;

llbfJry ------- C111lo9ue, 01Rmrn : P ltu1 BorrOWtr: lteN -++ P1t1on DueD1t1: lte"-++ D1tt fine: P1t1on-++ N

d1111 Bo''°"" is. C111lo9ua OnReuNt s C111lo9u delft llo"°w" = dolft DoD111

lnltll~11ty ------­ llbrary

C111lo5qe = 0 A OnRmrtt .. 0 delft llot10Wt1 = 0 delft OoDm = 0 dt lft Fiie = 0

Gtt Dre Ottt .!llbr.ity 17 : Item iqel : Date

17E do111 Bor<ower iqel e 000111 (17)

FIGURE 4. 19

Buy--------- A ll~my I?: het1

I? « Cmlosue C1t1lo9u' = C111lo9a• U (I?) OnRemve' = OnRerern Borrower' = Borr-r DuDate' - h eDll• fine'= fine

Rt turn ------------- A rnraty 17: ltn1 p? : Patroa toity? : D1te

I? E dt lft BOllOWtl .. p? = Borrowe<(I?) Borrower' = {17} • B:otrowu OuDate' - (I?}• Dre011t Ou01te(17) • toity? < 0 =>

fine' • fine © {p? >-+ (Flne(t7J + ((OuDatt(I?) • toi1(1)*D1llyflne)} OuD111(1?) • toity? ~ o ..

Fine'= fine C111lo9u' = C111lo9ae OnRuerte' • OnRer.er1e

Partial Z specifica1ion of !be library proble m.

SIDEBAR 4.5 GROUND REQUIREMENTS IN THE REAL WORLD

Jackson's advice (Jackson 1995) to ground the requirements in the real world goes beyond the message about expressing the requirements and the specification in terms of the pro- posed system's e nvironme nt. Jackson argues that any model of the require ments will include primitive terms that have no forma l meaning (e.g., Patron, Publication, and Article in

our library example), and that the only way to establish the meaning of a primitive term is to relate it to some phenome non in the real world. He calls these descriptions designations, and he distinguishes designations from definitions and assertions. D efinitions are formal meanings

of terms based on the meanings o f othe r terms used in the model (e.g., the definition of a book out on loan), whe reas assertions descr ibe constr aints o n te rms (e.g., patrons can borrow

o nly those items not currently out on loan). If a mode l is to have a ny meaning with respect to

real-world be havior. its primitive terms must be clearly and precisely tied to the real world, a nd its designations" must be maintaine d as an essential part of the require ments documenlta-

tion" (Zave and Jackson 1997).

Openmirrors.com

Section 4.5 Modeling Notations 183

declared as powe rsets (P) of Items; these declarations me ao that the values of Catalogue and OnReserve can change during execution to be any subset of Items. The sch ema also declares partial mappings (-+>) that record the Borrowers and DueDates for the subset of Items that are out on Joan, and record Fines for the sub- se t of Patrons who have outs tanding fines. The do main (dom) of a partial mapping is the s ubset of e ntities curre ntly being mapped; hen ce, we assert that the s ubset of ite ms o ut o n loan should !Je e xactly the subset of ite ms that have due dates. The Ini tLibrary scheme initializes all o f the variables to be empty sets and functions. All of the re maining schemas correspond to library operatio ns.

The top sectio n of an operatio n schema indicates whe the r the operation modifies (~) o r simply queries (E ) the system state, and identifies tbe inputs (?) and outputs(!) of the o peration. The bo tto m section of an o pe ration sche ma specifies the operation's pre-conditio ns and post-conditio ns. In ope ratio ns that modify the system sta te, unprim ed variables represent variable values be fore the operatio n is performed, and prime d variables represent values fo llowing the opera tion. For example, the input to operation Buy is a new library Item, and the pre-condition specifies that the Item not already be in tbe library Catalogue. The post-conditions update the Catalogue to include tbe new Item, and specify that the o ther library variables do no t change value (e.g., the update d va lue Fine' equals the o ld value Fine). Ope ration Return is more complicated. It takes as input the Library Item being returned, the Patron who bor- rowed the Item, and the Date of the return. The post-conditions remove the returned item from variables Borrowers and DueDates; these updates use Z symbol <a, "domain subtraction," to return a submapping of their pre-operation values, excluding any ele- me nt whose domain value is the Item being returned. The next two post-conditions are updates to variable Fines, conditio ned on whether the Patron incurs an overdue fine for re turning the Item later than the loan's due date. These updates use symbol "4, which " maps" a domain value " to" a range value, and symbol e which "overrides" a function mapping, usually with a n ew "maps-to" element. Thus, if today's date is later than the re turned Item's DueDate, then the Patron's Fine is overridden with a new value that re flects the old fine value plus the new o verdue fioe. lhe last two post-conditions specify that the values of variables Catalogue and OnReserve do not change.

Algebraic Specifications

With the exception of logic and O CL notations, a U of the notatio n paradigms we have considered so far tend Lo result in models that s uggest particular implementations. For e xample,

• A UML class mod el s uggests what classes o ught to appear in the final (obj ect- orie nted) impleme nta ti on.

• A data-flow specification suggests how an imple mentatio n ought to be decom- posed into data-transforming modules.

• A state-machine model suggests how a reactive syste m should be decomposed ioto cases.

• AZ s pecification suggests how complex data types can be implemented in te rms of se ts, sequences, or functions.

184 Chapter 4 Capturing the Requirements

Such imple mentatio n bias in a require ments specification can lead a software designe r to produce a design that adheres to the specification's model, subconsciously disrega rd- ing possibly better designs that would satisfy the specified behavior. For example, as we wiU see in Chapter 6, the classes in a UML class diagram may be appropriate for expressing a problem simply a nd succinctl y, but the same class decomposition in a d esign may result in an ine fficient solution to the problem.

A comple tely di.ffe rent way of viewing a system is in te rms of what happens when combinations of operatio ns are performed. This multi-operational view is the main idea behind algeb raic specificati ons: to specif)' the beh avior of operations by specifying the interactions between pairs o f operations rather than modeling individual operations. An executio n trace is the sequence of operation s that have been performed since the start of execution. For example, one execution of our turnstile problem, starting with a new turnstile, is the operation sequence

new () .coin () .push () .rotated () .coin () .push ().rotated () ...

or, in mathematical-function notation:

... (rotated(push(coin(rotated(push(coin(new()))))))) ...

Specification axio ms specify the effects of applying pairs of operations on an arbitrary sequence of o perations that have already executed (whe re SEQ is some prefix sequ e nce o f o peratio ns):

num_entries (coin(SEQ)) .. num_entries (SEQ)

num_1mtries (puslh(SEQ)) .. num_entriQS (SEQ)

num_entries (rotated(SEQ) ) a 1 + num entries (SEQ) num_entries (new()) .. 0

The first three axioms specify the behavior of operation num_entries when applied to sequences ending with op erations coin, push, and rotated, respectively. For example, a rotated operation indicates that another visitor has entered the zoo, so num_entries applied to rotated(SEQ) should be one mo re than num_entries applied to SEQ. lhe fo urth axiom specifies the base case of num_en tries when applied to a new turnstile. Together, the four axioms indicate that operation num_entries re turns, for a given sequence, the number of occurrences of the operation rotated- witbou t saying anything about bow that informatio n may be store d o r computed. Similar axioms would need to be written to specify the behaviors of other pairs of operatio ns.

Algebraic specilicatio n notations are no t [popular among software developers because, for a collection of ope rations, it can be tricky to construct a concise set of axio ms tha t is comple te and consistent-and correct! Despite the ir complexity, alge- braic notations have been added to several fo rm al specificatio n la nguages, to en able specifie rs to de fine the ir own abstract data types fo r the ir specifications.

Example: SDL Da ta

SOL data definitions are used to create user-defin ed data types and parameterized data types in the Specification and Descript ion La ngu age (SDL) (ITU 2002).An SOL data type defi nition introduces the data type be ing specified, the signatures of au operations

Openmirrors.com

N e WTYPE LI bmy LITERALS New; OPERATORS

•uy: Llbmy, 111111 ..... Llbnty; loN: lllnty, ltu1 ..... Llbraty; •omiw: Llbnty, 111111 ..... Llbnty; " " ''" Ll•taty, I r.11 _, Llbt1ty; 11111'18: u•11ty, ten ..... llbn ty; unrmt'le: Llbrlr'f, lten ..... u•my; recall: Llbrity, 111111 .... ll•ttty; ltl1C1UIO!UI: Llbtl'Y, 111111 .... booleu; ltOnLoan: llbn!J, lte111 ..... boolun; lt OnRmr11: Llbttty, 111111 ..... boolun;

/*9nmto11 111 New, b1y, •omiw, 1111r1e */

Section 4.5 Modeling Notations 185

AXIOMS FOR ALL 11• In Llbr1ty (

FOR ALL I, 12 11 lten ( loN(New, 1) ; ERROR; loN(buy(lib, I), 12) = 111= 12 tlu 11•;

} }

elu biy(lou lll•. 12), 11; Ion( borrow( lib, 1), 12) • If I - 12 1~1n lonf llh, 12\

elu borrow(lote(llb, 12), ); loN(ri11r1e(m, 11. 12) •If 1. 12 1h1 lmtm, 121

elte rmt'le(lm (llb, 12), I); 1111m(N1w, I) =: ERROR; llltm(buy(lib, I), 12) ;;;: If I = 12 l~U hr (lib, I);

1lte h y(111m(I b, 12), I); 1111m( bo1m1(lib, I), 12) !!'II I = 12 then lib·;

du bo1tow(rel1m(llb, 12), I); 1111m(t1Ht'le(l1•, I), 12) !!' ltllt'll(t1111n(lib, 12), I);

lslnC111lo9u( New, I) =bin; ltlnC111lo9u( hy(ll•, 1), 12) • 11 1 • 12 tlu Im;

1111 l1hC112lo9u1(ll•, 12); 11lnCl11lo9u(h rr01w(llb, I), 12) =: lrlnC111lo9ae (Iii, 12); lslnClulo9u(rm rve(lib, I), 12) !!' lslnCl11lo9u (lib, 12);

E NDNE WTYPE Library;

FIGURE 4.20 Partial SOL data specifica tion for the library problem.

o o that da ta type, and axioms tha t specify ho w pairs of operations inte ract. Figure 4.20 shows a partial SOL data specificatio n for our Library proble m, whe re the Library itself-tbe catalogue of publications, and e ach publicati on 's loan and reserve status-is treated as a comple x data type . NEWTYPE introduces the Libra ry da ta type. The LITERALS section declares any constants of the new data type; in this case, New is the value o f an e mpty library. The O PERATORS section d eclares all o f the lib ra ry o pe ra- tio ns, including each operato r's parameter types and return type. The AXIOMS sectio n specifies the be haviors o f pairs o f ope rations.

A s me ntio ned above, the hardest part of constructing an algebraic specifica tio n is de fining a set of axio ms that is complete and consistent and that ref'lects the desired be havio r. It is especially difficult to ensure that the axioms are consistent because they are so interrela ted: each axiom contributes to the specification o f two o perations, a nd each ope rati o n is sp ecified by a collection of axioms. As such, a change to the spec- ificatio n necessarily implicates multiple axio ms. A heuri stic that helps to reduce the number o f axio ms, the re by reducing the risk o f inconsiste ncy, is to separate the o pe ra- tio ns into

• Ge nerators, which he lp to buiJd canoni cal re presenta tions o f the d e fined data type

• Manipulators, which re turn values of tbe defined data type, but a re not generators • Q ueries, which do no t re turn vaJues of the define d d ata type

'Ille se t o f gene rator o perati ons is a minimal set of ope ratio ns needed to construct any value o f the data type. That is, every sequence of opera tions can be re duced to some canonical sequen ce of only gen erator operations, such that the cano nical sequence

186 Chapter 4 Capturing the Requirements

represents the same data value as the original sequence. In Figure 4.20, we select New, buy, borrow, and reserve as our generator operations, because these opera- tio ns can re present any state of the library, with respect to the contents of the library's catalogue, and the loan and reserve states of its publications. This decisio n leaves lose, return, unreserve, and renew as our manipulator operations, because they a re the remaining ope rations that have return type Library, and leaves isinCatalogue, isOnLoan, and isOnReserve as our query operations.

The second part of the heuristic is to provide axioms that specify the effects of applying a non generator o peration to a canonical sequence of operations. Because canonical sequences consist o nly of ge nerator operatio ns, this step means that we need to provide axioms only for pairs o f ope rati ons, where each pair is a nongenerato r oper- ation tbat is applie d to an application of a ge ner ator operation. Each axiom specifies how to reduce an operatio n sequence to its canonical form: applying a manipulato r o peratio n to a can o nical sequence usually results in a smalle r canonical sequence, because the manipulator ofte n undoes the effects of an earlje r generator opera tio n, such as returning a borrowed book; applying a query o pe ration, like checking whether a book is out on loan, returns some result without modifying the already-canorucal system state.

The axioms for each nongenerator operation are recursive ly defined:

1. There is a base case that specifies the effect of each nongenerator o peratio n on an empty, New library. In o ur library specification (Figure 4.20), losing a book from an empty Library is an ERROR.

2. There is a recursive case that specifies the ,effect of two operations on common pa rame te rs, such as buying and losing the same book. In gene ral , such opera tions interact. In this case, the operations can cel each other out, and the result is the state o f the library, mjnus the two operatio ns. Lookjng at the c ase o f losing a book that has been borrowed, we discard the borrow operation (because there is no need to keep any Joan records for a Jost book) and we apply the lose operation to the rest of the seque nce.

3. There is a second recursive case that applies two operations to different parame- te rs, such as buying and losing different books. Such operations d o not interact, and the axiom specifies how to combine the effects of the inne r ope ration with the result of recursive I y applying the o uter operati on to the rest of the system state. In the case o f buying and losing ruffe rent books, we keep the ,effect of buying one book, and we recursive ly appl y the lose ope ration to the rest of the sequence of operations execute d so fa r.

There is no need to specify axioms for pairs of nongenerator operations because we can use the above axioms to reduce to cano ni cal fo rm the applicatio n of each non- generator operation before conside r1ng the next nongenerator o peration. We could write axioms for pairs o f gene rator o perations; for example, we could specify that con- secutive Joans of the same book are an ERROR. H owever, many combinations of gener- ator operations, such as consecutive loans of diffe re nt books, wiU not result in reduced cano nical fo rms. Instead , we write axioms assuming that many of the opera tions h ave pre-conditions that constrain whe n operations can be applie d. For example, we assume

Openmirrors.com

Section 4.6 Requirements and Specification Languages 187

in o ur library specification (Figure 4.20) that it is invalid to borrow a book that is already out o n loan. Given this assumption, the effect of returning a borrowed book

return(borrow(SEQ,i),i)

is that the two operations cance l each other out and the resuJt is equiva lent to SEQ. If we do not make this assumption , the n we wouJd write the axioms so that the return operation re moves all corresponding borrow operations:

return(New,i) .. ERROR;

return(buy(lib, i), i2 ) a if i = i2 then buy(lib, i); else buy(return(lib, i2), i);

return(borrow(lib, i), i2) "" if i = i2 then return(lib, i2); else borrow(return(lib, i2), i);

return(reserve(lib, i), i2) "" reserve(return(lib, i2), i);

Thus, the effect of re turning a borrowed book is t o discard the borrow operation and to reapply the return operation to the rest of the sequence, so that it can remove any extraneous matching borrow operations; this recursion terminates when the return operatio n is appLied to the corresponding buy operation, which de notes the beginning of the book's existence, o r to an empty library, an ERROR. Toge the r, these axioms spec- ify that operation return re moves from the Library state any trace of the item being borrowed, which is the d esired behavior. A specification written in thjs style wouJd nul- Lify consecutive buying, borrowing, or reserving of the same item.

4 .6 REQUIREMENTS AND SPECIFICATION LANGUAGES

At this po int, you may be wondering how the software -engineering community could have developed so many types of software mode ls with none be ing the preferred or ideal notation. The situation is not unlike an architect workjng with a coUection of blue- prints: each blueprint maps a particular aspect of a building's design (e.g., structural support, he ating conduits, electrical circuits, water pipes), and it is the coUection of plans that e nables the architect to visualize and communicate t he building's whole design. Each of the notational paradigms described above models problems from a dif- fe rent p erspective: entities and relatio nships, traces, execution states, functions, proper- ties, data. As such, each is the paradigm of choioe fo r modeLing a particular view o f a software problem. With practice and expe rience, you will learn to judge which view- points a nd notations are most appropriate for un dersta nding or communicating a given softwa re problem.

Because each paradigm has its o wn strengt!hs, a complete sp ecification may con- sist of seve ra l mode ls, e ach of which illustrates a different aspect of the problem. For this reason, most practical requireme nts and specification languages are actuaUy com- binations of several notational paradigms. By understanding the re lationships between specification languages and the notational paradigms they employ, you can start to rec- ognize the simjlarities among differe nt languages and to appreciate the essen tial ways in which specification languages differ. At this end of this chapte r, we discuss criteria for evaluating and choosing a specifica tio n language.

188 Chapter 4 Capturing the Requirements

Unified Modeling Language (UML)

The Unified Modeling Language (UML) (OMG 2003) is the language best known for combining multiple notatio n paradigms. Altogether, the UML standard comprises eight graphical mode ling no ta tio ns, plus the O C L constraint language. The l IML no ta- tio ns tha t a re used during require me nts definition a nd specifica ti on include

• Use-case diagram (a high-level DFD): A use-case diagram is used at the start of a new project, to record the essential to p-level functions that the to-be-develo ped product sho uld provide. In the course of detailing the use cases' scenarios, we may id entify impo rta nt entities that play a role in the p roblem being mo deled.

• Class diagram (an ER diagram): As mentio ned previously, the class di agram is the flagship model of a UML specification, emphasizing th e problem 's entities a nd their inte rre la tionships. The remaining UML specification models provide mo re de tail about how the classes' objects be have and how they interact with one ano the r. As we gain a better understanding of the problem being modele d, we de tail the class diagram, with additional attributes, attribute classes, operatio ns, a nd signa tures. ldeaUy, new insight into the p ro blem is more likely to cause changes to these de tails than to affect the model's entities or rela tio nships.

• Sequence diagram (an event trace): Sequence diagrams are early behavio ral mode ls that d epict traces o f messages passed be tween class instances. They are best used to docume nt impo rtant scena rios that involve multiple objects. When creating sequence diagrams, we look fo r commo n subseque nces th at appea r in severa l diagrams; these subsequences may help us to identify states (e.g., the start and e nd po ints o f the subsequence) in the objects' local behavio rs.

• Collaboration diagram (an event trace): A colla boratio n diagram illustrates one o r mo re e vent traces, overlayed o n the class diagram. As such, a collaboration dia- gram presents the same information as a sequence diagram. The d iffere nce is llhat the sequence diag ram emphasizes a scenario's tempo ral o rdering of messages because it o rganizes messages along a time line. On the o the r hand, the collabo ra- tio n diagram emp hasizes the classes' relationships, and treats the messages as elaborations of those re latio nships in the way that it re presents messages as arrows between classes in the class diagram.

• Statechart diagram (a state-machine model) : A UML statechart diagram specifies ho w each instance o f o ne class in the specification's class diag ram behaves. Before writing a statecha rt for a class (more specifically, for a represe ntative object o f that class), we sho uld identify the states in the object's life cyle, the events that this o bject sends to and receives fro m o the r o bjects, the order in which these states and e vents occur, and the o peratio ns that the object invokes. Beca use such informa tion is fa irly detailed , a statechart diag ram should no t be attempted until late in the require me nts phase, whe n the proble m's details a re better understood.

• OCL properties (logic): O CL expressio ns are prope rties a bout a model's e le- ments (e.g., o bjects, attributes, events, states, messages). OCL prope rties can be used in any o f the above mo dels, to explica te the model's implicit beha vio r o r to impose constraints o n the mode l's specifie d behavio r.

Openmirrors.com

Section 4.6 Requirements and Specification Languages 189

Most of these notations were discussed in the preceding section, as examples of differ- e nt notation paradigms. In C hapte r 6, we will see more details about how UML works, by applying it to a real-world problem for both specification and design.

Specification and Description Language (SOL)

The Specification and Description Language (SD!L) (ITU 2002) is a language standard - ized by the International Te lecommunications Union for specifying precisely the behavior o f rea l-time, concurre nt, distributed processes tha t communicate with e ach othe r via unbounded message queues. SDL comprises three graphical diagrams, plus algebra ic specifications fo r defining complex data types:

• SDL system diagram (a DFD): An SDLsystem diagram, shown in Figure 4.2l(a), depicts the top-level blocks of the speci ficatio n and the communication chanroels that connect the blocks. The channe ls are directional and are labeled with the types of signals tha t ca n flow in each dir ection. Message passing via channels is asynchronous, meaning that we cannot malke any assumptions about when sent messages will be received; of course, messages sent along the same channel wiU be received in the o rdler in which they were sen t.

• SDL block diagram (a DFD): Each SDL block may model a lower-level collec- tio n o f blocks and the message-de laying channe ls that interconnect them. Alter- natively, it can model a collection of lowest-level processes th at communicate via sig nal routes, shown in Figure 4.2l(b ). Signal routes pass messages synchronously, so messages sent between processes in the same block are received insta!llta" neously. In fact, this di ffe rence in comm unica tion mechanisms is a factor when deciding how to dlecompose behavior: processes tha t need to synchronize with one ano the r and that a re highly coupled sho uld reside in the sa me block.

119 .---~

block

119 11! ....----, block

(aJ An SOL ty11ei. 01 block of blocb

(bJ An SOL bloek ol pmenu

(•I An SOL procm

FIGURE 4 .21 SDL graphical notations.

190 Chapter 4 Capturing the Requirements

• SDL proce~ diagram (a state-machine mod el): An SOL process, shown in Figure 4.2l(c), is a state machine, whose transitions are seque nces of language constructs (input, decisions, tasks, o utputs) that start an d end at state con structs. Io each exe- cution step, the process re moves a signal from the head of its input que ue and compa res the signa l to the input constructs that foll ow the process's current sta te. If the signal matches one of the state's inputs, the process executes all of the con - structs that follow the matching input, until the execution reaches the next state construct.

• SDL data type (alge braic specificati on): An SOL process may declare local vari - ables, and SOL data type definitions are used to declare complex, user-de fined variable types.

la addition, an SOL specification is often accompanied by a set of Message Sequence C harts (MSC) (ITU 1996), each of which illustrates a single execu tion of the specifica- tion in terms o f the messages passed between the specification's processes.

Softwa re Cost Reduction (SCR)

Softwar e Cost R eductio n (SCR) (Heitmeyer 2002) is a collection of techniques that were designed to encourage software developers !lo employ good softwa re-engineering d esign principles. An SCR specificati on mode ls software re quirem ents as a mathe mati- cal func tion, REQ, tha t maps monito red variables, whi ch are e nvironmental variables that are sensed by the syste m, to co ntro lled varia bles, which a re environmen tal va ri- ables that a re set by the system. T he function REQ is decomposed into a collection of tabular functions, simiJar to Parnas tables. Each of these functions is respo nsible for set- ting the value of one contro lled variable or the value of a term , which is a macro- like variable that is refe rred to in o ther functions' definitions.

REQ is the result of composing these tabular functions into a network (a DFD, as sho wn in Figure 4.22), whose edges reflect the data dependencies among the functions. Every execution step starts with a change in the value of one monitored va riable. lbis cha nge is then propagated through the network, in a single, synchronized step. The specification 's functions are applied in a topological sort that adheres to the functions' data depende ncies: any function that re fers to updated va lues of variables must execute after the functions that upda te those values. Thus, an execution step resembles a wave of variable updates tlowing th rough the ne two rk, starting with newly sensed mo ni- tored-variable values, followed by updates to te rm variables, folJowed by updates to controUed-variable values.

A B C D

: FIGURE 4 .22 SCR specification as a network of tabular functions.

Openmirrors.com

Section 4.7 Prototyping Requirements 191

Othe r Features of Requirem ents Notations

The re are many othe r require ments-modeLing techniques. Some techniques include facilities for associating tbe degree of uncertainty or risk with each requirement. Other techniques have faciLities for tracing requirements to othe r system documents, such as design or code, or to o ther systems, such as when requirements are reused. Most specifi- cation techniques have been automated to some degree, making it easy to draw dia- grams, coUect te rms and designations into a darta dictionary, and check for obvio us inconsis te ncies. As tools continue to be developed to aid software engineering activi- ties, documenting and tracking require ments will be made easie r. However, the most difficult part of requirements analysis-understanding our customers' needs-is still a human ende avor.

4.7 PROTOTYPING REQUIREMENTS

Whe n trying to determine requirements, we may find that our customers are uncertain of exactly what they want o r need. Elicitation may yield onJy a "wish list" of what the custo me rs wouJd like to see, with few details or without being clear as to whether the list is complete. Beware! These same customers, who are indecisive in their require- ments, have no trouble distinguishing between a de live red system that meets their needs and one that does not-known also as " I'U know it when I see it" custome rs (Boehm 2000). In fact, most people find it easier il:o critique, in d etail , an existing prod- uct than to imagine, in d e tail, a new product. As sillch , one way that we can elicit details is to build a prototype of tbe proposed system and to solicit feedback from potential users about what aspects they would Like to see improved, which features are no t so useful, o r what functionality is missing. BuiJding a prototype ca n also he lp us determine whether the custome r's probJe m has a fe asible solution , or assist us in exploring optio ns for optimizing quality requirements.

To see how prototyping works, suppose we are building a too l to track how much a use r e xe rcises each day. Our custo mers are exercise physiologists and trainers, and their clients wiU be the u sers. The tool wiLI he lp the physiologists and trainers to work with their clie nts and to track their clients' training progress. The tool's user inte rface is important, because the users may not be familiar with computers. For example, in e nte ring information about the ir exercise routines, the users will need to ente r the date fo r e ach routine. The traine rs are not sure wbat this inte rface should look like, so we build a quick prototype to de monstrate the possibiLities. Figure 4.23 shows a first proto- type, in which the use r must type the day, month , and year. A more interesting and sophistica ted interface involves a cale ndar (see Figure 4.24), where the user uses a mouse to se lect the mo nth and year, the syste m d isplays the chart for that mo nth , and the use r se lects the appropriate day in the chart. A third alternative is depicted in Figure 4 .25, in which, instead of a calendar, the user is presented with three slider bars. As the use r the n uses the mouse to slide each bar le ft o r right, the box at the bottom of the screen changes to show the selected day, month, and year. This third inte rface may provide the fastest selection, even though it may be ve ry different from what the users are accustomed to seeing. In this example, prototyping helps us to select the right ''look

192 Chapter 4 Capturing the Requirements

FIGURE 4.23 Keyboard-entry p rototype.

FIGURE 4 .24 Calendar-based proto type.

FIGURE 4 .25 Slide-bar-based proto type.

Enter vear: __

Enter month: __

Enter dav:--

Jalr 2001.

I 2 3 4 s 16 7 8 9 10 " 12 13 14 IS If> 17 I& 19 20 21 22 23 24 2S 26 27 23 29 30 31

~2S ==01===

31

====I~ Jan Dec

and fee l" fo r the user's interactio n with the proposed system. The p rototype in terfaces wo uld be difficult to describe in wo rds o r symbo ls, and they dem onstrate how some types o f requi reme nts are be tte r represented as pictures o r prototypes.

The re are two approaches to prototyping: throwaway and evolutionary. A throwaway prototype is software that is developed to learn mo re abo ut a problem or abo ut a pro posed solutio n, and that is never intended to be pa rt of the delivered soft- wa re. This app roach allo ws us to write " quick-and-dirty" software that is poorly struc- tured , inefficient , with no erro r checking-that, in fact , may be a facade that does not imple me nt any o f the desired functio nality-but that gets quickly to the heart o f ques- tio ns we have abo ut the problem o r about a p roposed solutio n. Once o ur questions are answe re d , we thro w away the proto type software and start engineering the software tha t wrn be de li vered. In contrast, an evolutionary prototype is software that is d e vel- o ped no t o nly to help us answer questions but also to be incorp orated into the final

Openmirrors.com

Section 4.8 Requirements Documentation 193

product. A s such, we have to be much more careful in its development, because this software has to eventually exhjbit the quality requirements (e.g., r esponse rate, mod u- larity) of the final product, and these quaLities cannot be retrofitted.

Both techniques are sometimes called rapid prototyping, because they involve building so ftware in orde r to answe r questions about the requirements. The te rm " rapid" distingwsh es software prototyping from t!hat in other engineering disciplines, in which a prototype is typically a comple te solution, Like a prototype car or plane that is built manually acco rding to an already approved design. The purpose of such a pro to- type is to test the design and product before automating o r optinUzing the manufactur- ing ste p for mass production. In contrast, a rapid proto type is a partial solution that is built to he lp us understand the requirements o r to evaluate design alte rnatives.

Questions about tbe reqwrements can be explored via eithe r modeling or proto- typing. Whe the r o ne approach is bette r than the other depends on what our questions are, how we ll they can be expressed in models or in softwa re, and h ow qukkly the mod- e ls o r proto type software ca n be built. As we saw above, questions about user interfaces may be easie r to answer using prototypes. A prototype that impl ements a number of proposed features would more effective ly he lp users to prioritize these features, and possibly to ide ntify some fea tures that are unnecessary. On the oth er hand , questions about constraints o n the order in which events sh ould occur, or about the synchroniza- tio n of activities, can be answe red mo re qwckly using models. In the end, we need to produce final re qwre me nts documentation for the testing and maintenance teams, and possibly for regulatory bodies, as well as final software to be delive red. So, whethe r it is be tte r to mode l o r to pro totype depe nds on whe ther it is faste r and easier to mode l, and to develop the software from the refined models, or faster and eas.ier to prototype, and to deve lop docume ntation from the refine d prototype.

4.8 REQUIREMENTS DOCUMENTATION

No matter what method we choose for defining reqwrements, we must keep a set of docume nts recording the result. We and our customers will refer to these docume nts thro ughout develo pment and maintenance. Therefore, the requirements must be docu- mented so that they are use ful not only to the custome rs but also to the technical staff on o ur d evelopment team. For example, the reqllire me nts must be organized in such a way that the y can be tracked throughout the system 's development. Cle ar and precise illustrations and diagrams accompanying the docillffientation should be consistent with the text. Also, the leve l at which the reqwrements are written is important, as explained in Sidebar 4.6.

Require ments Definition

The reqllire ments de finition is a record of the req uirements expressed in the cus- to me r's te rms. Workmg with the custo me r, we docume nt what the custo mer can expect of the d elive red syste m:

1. First, we outline the general purpose and scope of the system, including relevant be ne fits, objectives, and goals. Re ferences to othe r related syste ms are included, and we list any te rms, designatio ns, and abbr eviati ons that ma y be useful.

194 Chapter 4 Capturing the Requirements

SIDEBAR 4.6 LEVEL OF SPECIFICATION

In 1995, the Australian D efence and Technology Organisation reported the results of a sur-vey of problems with requireme nts specifications for Navy software (Gabb and Henderson 1995). One of the problems it highJighted was the uneven level of specifications. That is, some requirements had been specified at too high a level and o thers were too d etailed. The uneven- ness was compounded by several situations:

• Requirements analysts used diffe rent writing styles, particularly in documenting differ- e nt system areas.

• The difference in experie nce among analysts led to different levels of detail in the requirements.

• In attempting to reuse requirements from previous systems, analysts used different for- mats and writing styles.

• R equirements were often overspecified in that analysts identifie d particular types of computers and programming languages, assumed a particular solution , or mandated inappropriate processes and protocols. A nalysts sometimes mixed requirements with partial solutions, leading to "serious problems in designing a cost-effective solution."

• R equirements were sometimes underspecified, especially when describing the operat- ing environment, maintenance, simulation for training, administra tive computing, and fault tolerance.

Most of those surveyed agreed that the re is no universally correct level of specification.

Customers with extensive experience prefer high-level specifications, and those with less expe- rience like more detail. The survey respondents made several recommendations, including:

• Write each clause so that it contains only one requirement.

• Avoid having o ne requirement refer to anothe r requireme nt.

• Collect similar requirements together.

2. Ne xt, we d escribe the background and the ratio nale behind the proposal for a ne w system. Fo r e xample, if the system is to replace an existing appro ach, we explain why the existing approach is unsatis facto ry. Curre nt me tho ds and proce- dures are ou tlined in e nough de tail so that we can separate those elements with which the custome r is happy fro m those that are disappointing.

3. Once we record this ove rview o f the problem , we describe the essential character- istics of an acceptable solution. This record includes brie f descriptions of the prod uct's core functionality, at the le ve l of use cases. It a lso includes qua lity requireme nts, such as timing, accuracy, and responses to failures. ld eaJly, we would prioritize these requireme nts and ide ntify those that can be put off to late r ve rsio ns o f the system.

Openmirrors.com

Section 4.8 Requirements Do cumentation 195

4. A s part o f the problem 's context, we describe the enviro nme nt in which the sys- te m will ope rate. We list any known hardware and software components with which the p roposed system will have to interact. To help e nsure that the user interface is appro priate, we sketch the general background s and capabilities of the inte nded use rs, such as their e duca tio na:I background, experience, and techni- cal expertise. For e xample, we wo uld devise d ifferent user inte rfaces for knowl- ed geable users tha n we wo uld fo r first-time users. In addi tio n, we list any known constraints o n the require ments o r the design, such as applicable Jaws, hardware limitations, audit checks, regulato ry policies, and so on.

5. If the custo mer has a proposal fo r solving the problem, we outline a descriptio n of the p ro posal. Reme mbe r, though, that the purpose o f the requiremen ts docu- ments is to discuss the pro blem , not the solutio n. We need to evaluate the pro- posed solutio n carefully, to de termine if it is a design constraint to be satisfie d o r if it is an overspecificatio n that could exclude better solutions. In the e nd, if the custo me r places any constraints o n the developme nt or if the re are any special assumptio ns to be made, they sho uld be incorporated into the requireme nts de finitio n.

6. FinaUy, we list any assumptions we make about how the environme nt behaves. lo pa rticular, we describe any environmental conditio ns that would cause the pro- posed system to foil , and any changes to the e nvironment that wo uld cause us to change o ur require me nts. Sideba r 4.7 explains in mo re de tail why it is impo rt ant to document assumptions. The assumptions sho uld be documen ted sepa rately fro m the requireme nts, so tha t d evelo pers kno w which be haviors they are respon- sible for impleme nting.

Require ments Specificatio n

The requirements specification cove rs exactly the same ground as tbe requiremen ts de finitio n, but from the pe rspective o f the d eve lopers. Where the requirements defi - nitio n is written in te rms o f the customer's vocabulary, referring to objects, states, events, and activities in the custo mer 's world, the requirements specification is writtten in te rms o f the syste m's inte rface. We accomplish this by rewriting the requirements so that they refer only to those real-wo rld o bjects (states, e vents, actions) that are sensed o r actua ted by the proposed system:

1. In docume nting the syste m's interface, we describe all inp uts and outputs in de tail, including the sources of inputs, the d estinations of ou tputs, the value rnnges and data fo rmats o f input and output da ta, protocols governing the order in which certain inputs and o utputs must be exchanged , windo w formats and organization, and a ny timing constraints. Note that the user interface is rarely the only syste m inte rface; the system may in te ract with other softwa re compo ne nts (e.g., a data base), special-purpose hardware, the Internet, and so o n.

2. Ne xt, we restate the required functio nality in terms of the interfaces' inputs and outputs. We may use a functio nal no tatio n o r data -flow diagrams to map inputs to outp uts, o r use logic to document functions' pre-conditions and post-conditions. We may use state machines o r event traces Lo illustrate exact sequences of operations

196 Chapter 4 Capturing the Requirements

SIDEBAR 4.7 HIDDEN ASSUMPTIONS

Zave and Jackson (1997) have looke d carefully at proble ms in software requirements and specification, including undocumented assumptions about how the real world behaves. The re are actually two types of environmental b ehavior o f interest: desired behavior to

be realized by the pro posed system (i.e., the require ments) and exis ting behavior that is uncharnged by the pro posed system. The latte r type of behavior is often called assumptions or domain knowledge. Most requirements writers consid er assumptions to be simply the condi- tions wnder which the system is gua ranteed to operate correctly. While necessary, these condi- tions are no t the only assumptions. We a lso make assumptio ns a bout how the environment will behave in response to the system's o utputs.

Conside r a rail road-crossing gate a t the intersection of a road and a set of railroad tracks. Our require ment is that trains and cars do not collid e in the intersection. However, t he trains and cars are outside the control of o ur syste m; all our system can do is lower the cross-

ing gate upon the a rrivaE of a train and lift the gate after the train passes. The only way o ur crossing gate will prevent collisio ns is if trains and cars follow certain rules. For one thing, we have to assume that the trains travel a t some maximum speed, so that we know how early to lowe r t he crossing gate to e nsure that the gate is down well before a sensed train reaches t he

intersection. But we also have to make assumptio ns about how car drivers wilJ react to the crossing gate being lowered: we have to assume tha t cars will not stay in o r enter the inte rsec- tio n whe n the gate is down.

o r exact o rderings of inputs and outpu ts. We may use an entity-relatio nship dia- gram to collect related activities and operations into classes. In the end, the speci- fication should be complete, meaning that it should specify an output for any feasible seque nce of inputs. Thus, we incl ude validity checks on inputs and system responses to exceptional situations, such as violated pre -conditions.

3. FlnaUy, we de vise fit criteria for each of the customer's quality requirements, so that we ca n conclusively demonstra te whe the r our system meets these quality requireme nts.

The result is a d escription of what the developers are supposed to produce, writ- ten in sufficient detaiJ to distinguish between aoceptable and unacceptable solutions, but without saying how t he proposed system sho uld be designed or implemented.

Several organizations, such as the Institute of Electrical and E lectronic Engineers and the U.S. De partment of De fense, have standards for tbe content and format of the requirem ents documents . For example, Figure 4.26 shows a templ a te based on IEEE's recommendations for o rganizing a software requirements specificatio n by classes or objects. The IEEE standard provides similar templates for organizing the requirements specifica tio n by mode of operatio n, fu nction, feature, category of user, and so on. You may want to consul t these standa rds in preparing documen ts for your own projects.

Openmirrors.com

Section 4.8

1. lntrofotlon 10th Oon 1111nt 1.1 P~~m ol the Pro' w 1.2 Seopt or th Pro4get

Requirements Documentation

1.3 Aerony111r, Abbml1tlonr, Oennltlou 1.4 Rnermu 1.S Outline ol the m t ol the SR$

2. Cem1I Omrlpllon ol P10,uc1 2.1 Context ol Profot 2.2 Product ftntllm 2.3 Uur Chm cterllllct 2.4 Coutrtlntr 2.S Anu111p1lou 1n4 Ot pu4inele.r

3. Sptclllc Req•lrt11ents 3.1 Externtl lnttrlm R•1ulru 1entt

3.1.1 Uttr hterlmt 3.1.2 Htr, llm lnt1rlmr 3.1.3 Solhlm lnterlmr 3.1.4 Co"'u nlutlonr lnterltcu

3.2 Funcllonll Requlmunu 3.2.1Clm 1 3.2.2 Cl1n 2

3.3 Perlomm e R111lre11entt 3.4 Oetl91 Conrt11l1ts 3.S Quilty R1qulre111111t 3.6 Other R11alre11entt

4. Appu,lur

197

FIGURE 4.26 IEEE standard fo r Softwa re Requiremenls Specification organized by object (IEEE 1998).

Process Management and Reqiuirements Traceability

The re must be a direct correspondence between the require ments in the definition d oc- ument and those in the specificatio n document It is he re that the process manageme nt method s used throughout the life cycle begin. Process manageme nt is a set of proce- dures that track

• The require ments tha t define what the syste m sho uld do • The design mod ules that are generated from the requireme nts • The program code that impleme nts the d esig n • The tests that ve rify the functio nality of the system • The documents that describe the system

In a sense, process management provides the th re ads that tie the system parts together, integrat ing docume nts and a rtifacts that have been de ve lo pe d separate ly. These threads aUo w us to coordinate the deve lopment activities, as shown by the horizontal " threads" amo ng en tities in Figure 4.27. In particular, during requiremen ts activit ies, we a re co ncerned about establishing a corresponde nce between ele ments of the req uireme nts de finitio n and those o f the require ments specification, so that the cus- tome r's view is tied to the de velope r's vie w in an o rganized , traceable way. If we d o no t de fine these links, we ha ve no way of designing test cases to dete rmine whe ther the code meets the requiremen ts. In later chapters, we will see ho w process ma nageme nt

198 Chapter4 Capturing the Requirements

Sp1elnut1on h•pln11n11t1on V111t1eat1on

FIGUR!E 4.27 Links between software-development entities.

also allo ws us to dete rmine the impacl of cha nges, as we U as to control the effects of parallel deve lopment.

To facilitate this correspondence, we establis h a numbering scheme or data file fo r convenient tracking of re quireme nts from one document to ano the r. Often, the process man agement team sets up or extends this numbe ring scheme to tie requiremen ts to o the r components and a rtifacts of tlte system. Numbe ring the requirements alJo ws us to cross-re fere nce them with the data dictionary and o the r supporting docume nts. If any chan ges are made to the require ments during the re maining phases o f develop- ment, the changes can be tracked fro m the requirements document thro ugh the design process and alJ the way to the test p rocedures. Ideally, then, it sh ould be possible to trace any feature or function of the system to its causal requirement, and vice versa_

4.9 VALIDATION AND VERIFICATION

Remembe r that the require ments documents se rve both as a contract between us and the custome r, detailing what we are to d elive r, and as guide lines fo r the design e rs, de tailing what they are to build. Thus, be fore the requirements can be turned ove r to the designers, we and o ur custome rs must b e a bsolutely sure that each knows the o the r's intent, and that our intents are captured in the require ments documen ts.. To establis h this certainty, we validare the require me n ts and verify the specifica ti on.

We have been using the terms " veri fy" and "validate" thro ughout this chapte r without fo rmally defining them. In requirements validation, we check tha t our require- ments d efinition accurately re flects the custo mer's-actually, aU of the stakeholde rs'- needs. Validation is trick y because the re are only a few documents that we can use as the basis for arguing that the requi rements de finitions are correct. In verification, we check that one document or artifact confo rms to another. Thus, we verify that our code conforms to our design, and that our design conforms to our requirements specification; at the require ments level, we verify that o ur requirements specification conforms to the

Openmirrors.com

Section 4.9 Validation and Verification 199

requiremen ts d efinitio n. To summarize, verification ensures that we build the system right, whereas validation ensures that we build the right system!

Requirements Validation

O ur criteria for valida ting the requirements a re the ch aracteristics that we Listed in Section 4.4:

• Correct • Consistent • Una mbiguous

• Complete • Re leva nt • Testable • Tracea ble

Depending on the definition techniques that we use, some of the above checks (e.g., that the requirements are consistent or are traceable) may be automated. Also, common errors can be r ecorded in a checklist, which reviewers can use to guide their search for errors. Lutz (1993a) reports on the success o f using checklists in validating re quirements at NASA's Jet Propulsio n La boratory. However, most validation checks (e.g., that a reqw re - meot is correct, relevant, or unambiguo us; o r that the requirements are complete) are sub- jective exercises in tha t they involve comparing the requirements definition against the stake ho lde rs' mental mo del of what they expect the system to do. For these validation checks, our o nly recourse is to rely o n the sta ke holde rs' assessment of our documents.

Table 4.3 lists some of the techniques that can be used to vaLidate the req uire- ments. Va lidatio n can be as simple as reading the document and re porting errors. We

TABLE 4.3 Validation and Verification Techniques

Validation Walkthroughs

Verification

Checking

Reading Interviews Reviews

Checklists Models to check functions and relationships Scenarios Prototypes Simulation Formal inspections

Cross-referencing Simulation Consistency checks

Completeness checks Checks for unreachable states or transitions Model checking Mathematical proofs

200 Chapter 4 Capturing the Requirements

can ask the va lidation team to sign off on the document, thereby declaring that they have reviewed the docume nt and that they approve it. By signing o ff, the stake ho lde rs accept partial resp onsibility for errors that are subsequently found in the document. Alterna tive ly, we can ho ld a wa lkthrough, in wbich one of the document's au tho rs pres- e nts the requireme nts t o the rest of the sta keho lders, and asks for feedback. Walk - thro ughs work best when there are a large number of varied stakeho lders, and it is unrealistic to ask the m a ll to examine the docume nt in detail. At the othe r extre me, val- idation can be as structure d as a formal inspection, in whi ch reviewers take on specific roles (e.g., presente r, moderator) and follow pr escribed ruJes (e.g., rules on how to e xa mine the require ments, whe n to meet, when t o take breaks, whether to schedule a follow-up inspectio n).

Mo re often, the require me nts a re validated in a requiremen ts review. In a revie w, re prese ntatives fro m our staff and the custome r's staff examine the requiremen ts do cu- me nt individually and the n mee t to discuss identified problems. The customer's repre - sentatives include those who wilJ be ope rating the system, those who will prepa re the system's inputs, and those who will use the syste m 's outputs; managers of these employ- ees may also a ttend. We provide me mbers o f the design team, the test te am , and the process team . By mee ting as a group, we can do more than check tha t the requirements d efinitio n sa tisfies the valida tion crite ria:

1. We revie w the stated goals and o bjectives of the system. 2. We compare the re quire ments with the goa ls and objectives, to make certain ll:hat

all require ments are necessary. 3. We re view the e nvironme nt in which the syste m is to o pe rate, examining the

interfaces between our proposed system and alJ other systems and checking ll:hat their descriptio ns are complete and correct.

4. The custome r's re presentatives review the information flow and the proposed functio ns, to confirm that they accurately re flect the custo me r 's needs and inten- tio ns. Our represe atatives review the proposed functions and constraints, to con - firm that they are realistic and witrun our development abilities. All requireme nts are checked agai n fo r o missions, incomplete ness, and inconsistency.

5. If any risk is invo lved in the developme nt or in the actual functio ning of the sys- te m, we can assess and docume nt this risk, d iscuss and compare alternatives, and come to some agreement o n the approaches to be used.

6. We can talk about testing the system: how the requireme nts will be revalidate d as the require me nts grow and change; who wjjl p ro vide test data to the test team; which requireme nts will be tested in which phases, if the system is to be de vel- op ed in phases.

Whe never a problem is identified, the p roblem is docume nte d , its cause is d eter- mined , and the requirements analysts are charged with the task o f fixing the problem. Fo r example, validatio n. may reveal that there is a great misunde rstanding about the way in wbicb a certain function will produce resuJts. The customers may require d ata to be re po rted in miles, whe re as the users want the d ata in kilome te rs. The customers may set a re liability or ava iJability goal that developers deem impossible to meet. These con- flicts need to be resolved before design can begin. To resolve a conflict, the developers

Openmirrors.com

Section 4.9 Validation and Verification 201

may need to construct simulations o r prototypes to expl o re feasibility constrain ts and the n work with the customer to agree on an acceptable requirement Sidebar 4.8 dis- cusses the nature and number of requirements-related problems you are like ly to find .

Our choice of valjdation techruque depends on the e xperi ence and prefere nces of the stake ho lde rs and on the technique's appropriate ness for the notations used in the req uirements de finition. Some notations have tool suppo rt for checking consistency and complete ness. There are also tools that can help with the review process and with tracking problems and their resolutions. For example, some tools work with you and the custome r to reduce the amount of uncertainty in the re quire ments. This book 's Web page points to re quirements-re lated tools.

SIDEBAR 4.8 NUMBER OF REQUIREMENTS FAULTS

H ow many development problems are created during the p rocess of capturing requi re-me nts? There are varying claims. Boehm and Papaccio (1988), in a paper analyzing soft- ware at IBM and TRW, found that most errors are made during design, and there are usually

three design faults for every two coding faults. They point out that the high number of faults

attributed to the design stage could derive from requirements errors. In bis book o n softwa re

engineering economics, Boehm (1981) cites studies by Jones and Thayer and others that

attribute

• 35% of the faults to design activities for projects of 30,000-35,000 delivered source

instructions

• 10% of the faults to requirements activities and 55% of the faults to design activities fo r projects of 40,000-80,000 delivered source instructions

• 8% to 10% of the faults to requirements activities and 40% to 55% of t he faults to design activities for projects of 65,000-85,000 delivered sou rce instructions

Basili and Perricone (1984), in an empirical investigation. of software errors, report that

48% of the faults observed in a medium-scale software project were "attributed to incorrect

or misinterpreted functional specifications or requirements."

Beizer (1900) attributes 8.12% of the faults in his samples to problems in functional

requirements. He includes in his count such problems as incorrect requirements ; illogical or

unreasonable re quire ments; ambiguous, incomplete, or overspecified reqwrements; unverifi-

able or untestable requirements; poorly presented requi rements; and changed requirements. However, Beizer's taxonomy includes no design activities. He says, " Requirements, especially

exp ressed in a specification (or often, as not expressed because there is no specification) a re a major source of expensive bugs. The range is from a few percent to more than 50%, depend- ing on application and environment. What hurts most about these bugs is that they're the ear-

liest to invade the system and the Last to leave. It's not unusual for a faulty requirement to get through all development testing, beta testing, and initial field use, only to be caught after hun- d reds of sites have been installed."

202 Chapter 4 Capturing the Requirements

Other summary statistics abound. For example, Perry and Stieg (1993) conclude that

79.6% of interface faults and 20.4% of the implementation faults are due to incomplete or

omitted requirements. Similarly, Computer Weekly Report (1994) discussed a study showing that 44.1 % of all system faults occurred in the specification stage. Lutz (1993b) analyzed

safety-related errors in two NASA spacecraft software systems, and found that " the primary cause of safety-related interface fa ults is misunde rstood hardware interface specifications"

(48% to 67% of such fa.ults), and the " primary cause of safety-related functional faults is

errors in recognizing (understanding) the requirements" (62 % to 79 % of such faults). What is the right number for your development environment? Only careful record keeping will tell

you. These records can be used as a basis for measuring improvement as you institute ne w

practices and use new tools.

Verification

In verification, we want to check that our require ments-specification document corre- s ponds to o ur requireme nts-definition docume nt. This verification makes sure that if we implement a system that meets t he specificatio n, then that system will satisfy the cus- tomer's requirem ents. Most often , this is simply a check o f trace ability, where we ens ure that each requirem ent in the definitio n document is traceable to the specification.

However, for criti cal systems, we may want to do more, and actually demonstrate that the s pecification fuliills t he re quiremen ts. This is a more s ubstantial effort, in which we prove that the sp ecificatio n realizes every functio n, eve nt, activity, and con- s traint in the require me nts. The specification by itsel f is rarely e nough to make thi s kind of argument, beca1USe the specification is written in terms o f actions perfo rmed at the syste m's interface, such as force applied to an unlocked turnstile, and we may want to prove som ething about the environme nt away from the inte rface, s uch as about the number of entries into the zoo. To bridge this gap, we n eed to m ake use of o ur assumptions about how the environme nt beh aves-assumptions about what inputs the syste m will receive, o r about how the e nviro nment will react to outp uts (e.g., that if an unlocked turnstile is pushed with s ufficie nt force, it wiU rotate a balf- turn, nudging the pusher into the zoo). Ma the matically, t he specification (S) plus o ur e nvironmental assumptions (A) must be su fficie n t to prove that the requireme nts (R) hold:

S,A ~ R

For e xample, to sh ow that a the rmostat andl furnace will control air temperature, we have to assume that air temperature changes con tinuously rather than abruptly, although the sensors may detect discrete va lue changes, and that an ope ratin g furnace will raise the air tempe rature. These assump tions may seem obvious, but if a building is s ufficiently porous and the outside temperature is sufficiently cold, the n our second assumptio n will not hold. In such a case, it would be prude nt to se t some boundaries on tbe requirement: as long as the outside temperature is above -lOO"C, the thermostat and rurnace wiH control the air temperature.

Openmirrors.com

Section 4.9 Validation and Verification 203

'This use of enviro nme ntal assumptions gets at the heart of why the documenta- tion is so important: we re ly on the environment to help us satisfy the customer 's requirements, and if our assumptions about how the environment behaves are wrong, then our syste m may not work as the customer expects. If we cannot prove that our specification and our assumptio ns fulfill the custome r's requirements, then we need e ither to change o ur specification, stre ngth en our assumptions about the e nvironment, or weaken the requirements we are trying to achieve. Sidebar 4.9 discusses some techniques fo r automating these proofs.

SIDEBAR 4.9 COMPUTER-AIDED VERIFICATION

Model checking is an exhaustive search of a specification's execution space, to determine whether some temporal-logic property holds of the executions. The model checker com- putes and searches the specification's execution space, sometimes computing the execution space symbolically and sometimes computing it on-the-Hy during the search. Thus, the verifica-

tion, while completely automated, consumes significant computing resources. Sreemani and

Atlee (1996) used the SMV model checker to verify five properties of an SCR specification of the A-7 naval aircraft. Their SMV model consisted of 1251 lines, most of them translated auto-

matically from the SCR specification, and theoretically had an execution space of 13 X 1<>22

states. In their model checking, the researchers found that one of the properties that was thought not to hold did indeed hold: it turned out that the conditions under which it would no t hold were

unreachable.They also di:soovered that a safety property did not hoht according to the specifica- tion, it was possible for the weapon delivery system to use stale data in tracking a target's loca- tion when the navigation sensors were deemed to be reporting unreasonable values..

A theorem proveruses a collection of built-in theories, inference rules, and decision p roce-

dures for determining whether a set of asserted facts logically entails some unasserted fact; most sophisticated theorem provers require human assistance in sketching out the proof strat-

egy. Dutertre and Stavridou (1997) used the theorem prover PVS to verify some of the func- tional and safety requirements of an avionics system. For examiPle, the assumption that relates

the wing sweep angle WSPOS at time t + eps and the wing sweep command CMD at time t, in

the case where aone of the interlocks is active, is expressed in PVS as:

crnd_wings : AXIOM

constant_in _interval (CMD, t, t + eps)

and

not wings_locked_in_interval (t, t + eps)

implies

CMD (t) = WSPOS (t + eps) o r

CMD (t) < WSPOS (t + eps) and

WSPOS (t + eps) <= WPOS (t) - eps * WS,Jnin_rate o r

CMD (t) > WSPOS (t + eps) and

WSPOS (t + eps) >= WPOS (t) 2 eps * ws_min_rate

204 Chapter 4 Capturing the Requirements

The entire PVS model, including specification and assumptions, consisted of about 4500

lines of PVS, including comments and blank lines. The verification of requirements involved two steps. Some theorems were proved to check that the PVS model was internally consistent and comple te, and othe rs were used directly to prove three main safety properties. The pro of o f safety was quite complex. In total, 385 proofs were performed, of which about 100 were discharged automatically by the theorem prover, and the rest required human guidance. It

took approximately 6 person-months to write the PVS model and s upport libraries, and another 12 person-months to formalize the assumptions and carry out the verification ; the verification of the three main safety properties took 9 of the 12 person-months.

Whe n requirements validation and ve ri1ication are comple te, we and our cus- to mers should fee l comforta ble about the requirement specification. Unde rstanding what the custo me r wants, we can proceed with tbe system design. Me anwhile, the cus- to mer has in band a docume nt describing exactly what the delivere d system should do.

4.10 MEASURING REQUIREMENTS

There are many ways to measure characte ristics of requirements su ch that the info rma- tion collected tells us a lo t a bout the requireme nts process and abo ut the quality of the require ments themse lves. Me asurements usually focu s on three are as: product, process, and resources (Fenton a nd Pfleeger 1997). The number of requirements in the require- me nts d efinition and specification can give us a sense o f bow large the developed sys- te m is like ly to be . We saw in C hapter 3 that effort-estimation models require an estimate o f product size, and requireme nts size can be used as input to su ch models. Mo reove r, requirements size and effort estimation can be tracke d throughout develop- ment. A s design and developme nt le ad to a deepe r unde rstanding of both problem and solution , n ew requireme nts may arise that were n ot apparent during the initial require- me nts-capture process.

Simila rly, we can measure the number of changes to require ments. A large nwn- ber o f changes indica tes some instability or uncertainty in our understa nding of wbat the system sho uld do or how it should be have, and suggests that we should take acti ons to try to lower the rate o f changes. The tracking o f changes al so can continue throu gh- o ut deve lo pme nt; as the system re quire ments cha nge, the impact of the changes can be assessed .

Whe re possible, re quirements-size and change measurements should be recorded by require ments typ e. Such category-based me trics tell us whe the r chan ge or uncer- ta inty in require me nts is product wide, o r rests solely with certa in kinds of req ui re- me nts, such as use r-inte rface or data base requir ements. This info rmation helps u s to d ete rmine if we need to focus o ur atte ntion on particular typ es of requirements.

Beca use the require men ts are used by the designe rs and tes ters, we may wa rnt to d evise m easures that re flect the ir assessment o f the requirements. For example, we can ask the designe rs to rate each re quire ment on a scale from 1 to 5:

Openmirrors.com

Section 4.10 Measuring Requirements 205

1. Yo u (the d esigner) unde rstand this requirement completely, you have designed from similar requireme nts in the past, and you should have no trouble develo ping a design from this requirement.

2. There are e le ments of this r equirement that are new to you, but they a re not radi- cally diffe rent from require ments you h ave successfully designed from in the past

3. There are elements of this r equirement that are very diffe rent from re quirements you have designed from in the past , but you unde rstand the requi re ment and think you can deve lop a good design from it.

4. The re are parts of this requirement that you do not unde rstand, and you are no t sure that you can deve lop a good design.

S. Yo u do no t unde rstand thi s requirement at all, a nd you cannot d evelop a design fo r it.

We can create a similar rating sche me that asks teste rs ho w well they unde rstand each require ment and how confide nt they are about being able to devise a suitable tesl suite for eac h re quire ment. In bo th cases, the profiles of ra nkings can serve as a coa rse indicator of whe the r the require me nts are written at the .appropriate leve l of de tail. If the designe rs and testers yie ld profiles with mostly ls and 2s, as shown in Figure 4.28(a), the n the require me nts a re in good shape and ca:n be passed o n to the design team. H o wever, if the re are many 4s and Ss, as shown in Figure 4.28(b), the n the require ments sho uld be revised , and the revisions reassessed to have better profiles, before we proceed to design. A lthough the assessment is subjective, the general trends sho uld be clear , and the scores can provide useful fee dback to both us and o ur custo me rs.

We ca n a lso ta ke note, for e ach requirement, of whe n it is reviewed, implemented as design, imple mented as code, and teste d. These measures telJ us the p rogress we are making toward completion. Testers can also measure th e thoroughness of the ir test cases with resp ect to the requireme nts, as we will see in Chapters 8 and 9. We can measure the number o f requirements covered by each test case, and the numbe r o f requirements that have been test ed (Wilson 1995).

Nu11ber or tequlreiuntt

Nu11ber or requlre1111ntt

2

2

ft )

4

4

FIGURE 4.28 Measuring requirements readiness.

206 Chapter 4 Capturing the Requirements

4.11 CHOOSING A SPECIFICATION TECHNIQUE

This chapter has presented examples of several requirements-sp ecification techniques, and many more are available for use on your projects. Each on e has useful characteris- tics, but some are more appropriate for a given project than o th ers. That is, no tech- nique is best for all proj ects. Thus, it is impo rtant to have a set of criteria fo r deciding, for each project, which technique is most suitable.

Le t us conside r some of the issues that shouJd be included i.n such a set of crite ria. Suppose we are to build a computerized syste m for avoiding collisio ns a mo ng ai rcraft. Participating aircraft are to be fitted with radar sensors. A subsyste m on each aircraft is to monitor o the r aircraft io its vicinity, detect when an aircraft is fl ying dangerou sly close, establish communications with that aircraft, negotiate evasive maneuve rs to avoid a collision (after aU , we wouldn't want both planes to independe ntly choose maneuve rs that would put them or keep them on a co llision course!), aod instruct its navigation system to execute the negotiated mane uvers. Each aircraft's subsystem p er- forms its own data analysis and decision-making procedures on onboard compute rs, although it shares flight plans with o the r aircraft aocl transmits a ll data and final maneu- ve rs to a central site fo r furt he r analysis. One of the key characte ristics of this coUision - avoidance system is that it is a distribute d, reactive system. Tha t is, it is a reactive system io that e ach aircraft's subsystem is continuously monitoring and reacting to the posi- tions of other aircraft. It is a distributed system i.n that the syste m's functions are di s- tribute d over several aircraft. The complexity o f this system makes it essential that the require me nts be specified exactly and comple te ly. loterfaces must be well-defined, and communica tions must be coordinated, so that eac h aircraft's subsystem can make decision s in a timely manne r. Some specificatio n techniques may be mo re appropriate tban oth e rs fo r this problem. For e xample, testing th is syste m will be difficult because, for safe ty reasons, most testing ca nnot take place in the real environme nt. Moreover, it will b e hard to detect and replicate transie nt e rrors. Thus, we rn.ight prefer a tech- nique that offers simulation , o r that facilitates e xhaustive or automated ve rification of the specification. Io particular, techniques that a utomatically check the specification o r syste m fo r consisten cy and completeness may catch e rrors that are not easy to spot o the rwise.

Mo re generally, if a system has real-time re quireme nts, we need a specification technique that suppo rts lhe notion of time. Any n eed fo r phased deve lopment mean s that we wiU be tracking requirements through several intermediate systems, which not only complicates the requi reme nts tracking, but also increases the li.kelihood that the requirem e nts will change over the life of the syste m. As the users work with interme di- ate ve rsio ns of tbe syste m, they may see the need fo r new fe atures, o r want to cha nge existing features. Thus, we need a sophisticated me thod that can handle change easily. If we want o ur requirements to have all of the desirable characteristics listed early in the cha pte r, the n we look fo r a method that he lps us to re vise the requi reme nts, track the changes, cross-re ference the data and functio nal ite ms, and analyze the requireme nts for as many characteristics as possible.

Ardis and his colleagues (1996) ha ve proposed a set of criteria fo r e valuating specificati on methods. They associa te with each crite rio n a li st of questions to he lp us to

Openmirrors.com

Section 4.11 Choosing a Specification Technique 207

determine how well a particular method satisfies that criterion. These criteria were inte nded for evaluating techniques for specifying reactive systems, but as you will see, most of the criteria are quite gen eral:

• A pplicability: C an the technique describe rea l-world problems and solutions in a natural a nd realis tic way? If the technique makes assumptions about the en viron- ment, are the assumptions re asonable? Is tbe technique compatible with the othe r techniques that will be used o n the project?

• Implementability: Can the specificatio n be refined or translated easily into an implementation? How difficult is the translatio n? Is it automated? If so, is the gene rated code e fficient? Is tbe generated code in the sam e language as is used in tbe manually produced parts of the impleme ntation ? Is there a clean, well- de fined interface betwee n the code that is machine-gene rated and the code that is not?

• Testability/simulation : Can the specification be u sed to test the imple mentatio n? Is every state ment in the sp ecification testable by tbe impl ementatio n? Is it pos- sible to execute the specification?

• C beckability: Are the s pecifications readable by n ondevelopers, s uch as the cus- to mer? Can domain experts (i.e., experts on the problem being specified) check the s pecification for accuracy? Are tbere automated specification checkers?

• Ma intaina bility: Will the sp ecification be use ful in making changes to the system? Is it easy to cbange the specificatio n as the system evolves?

• Modularity: Does the me thod a ll ow a large specification to he decomposed into smaller parts that are easie r to write and to understa nd? Can changes be made to the smalle r parts without re writin g the entite specification?

• Level of abstraction/exp ressibility: H ow closely and expressively do objects, states, and eve nts in the language correspond to the actual o bjects, actions, and conditions in tbe problem domain? H ow concise and elegant is tlhe resulting specification?

• Soundness: D oes the language o r do the tools facili tate checking for incons isten- cies o r a mbiguities in the specification ? Are the semantics of the specification lan- guage defined precisely?

• Verifiability: Ca n we de monstrate fo rmall y that the specification sa tisfies the require me nts? Cao the verification process be automated, and , if so, is the automation e asy?

• R untime safety: If code can be generated auto matically from the s pecificatio n, does the code degrade gracefully under unexpected runtime conditions, s uch as ove rflow?

• Tools maturity: If the specification technique has tool s uppo rt , are the tools o f high quality? Is there training available fo r learning how to use them? H ow large is the user base for the tools?

• Looseness: Can the specification be incomplete o r admit nondete rminism?

• Learning c urve: C an a ne w user learn quickly the technique's concepts, syntax, se mantics, and he uristics?

208 Chapter 4 Capturing the Requirements

• Technique maturity: H as the technique bee n certified or standardized ? Is the re a user g roup o r large user base?

• Data modeling: Does the technique include data representation, re lationships, or abstractio ns? Are the data-modeling facilities an integrated part of the technique?

• D iscipline: Does t he technique force its users to write we ll -structured, under- standable, and well-behaved specifications?

The fi rst ste p in choosing a specifica ti on technique is to determjne for o ur partic ular problem which of the above cri teria are especiall y important. Diffe rent problems place diffe rent prio rities on the crite ria. Ardis and his colleagues were interested in deve lop- ing te le pho ne switching systems, so they judged whether each o f the criteria is helpful in developing reacti ve systems. They considere d no t only the criteria's effects on require ments activities, but their effects on other life-cycle activities as well. Table 4.4 sho ws the results o f thefr evaluation. The second step in choosin g a specification tech- nique is to evaluate e ach o f the candidate techniques with respect to the criteria. For example, Ardis and colle agues rated Z as strong in modularity, a bstractio n, verifiability, looseness, technique maturity, and data mode ling; adequate in applicabiljty, checkabil- ity, maintainability, soundness, tools maturity, learning curve, and discipline; and weak in imp~ementability and testability/simulatio n. Some of their assessme nts of tha t Z, such as Z inhe rentl y suppo rts mo dularity, ho ld for all proble m types, whereas o ther assessments, such as applicabili ty, are specific t o the problem type. In the end, we choose a specification technique that best supports the criteria tha t are most important to o ur part icular problem.

Since no one approach is unive rsally applicable to all syste ms, it may be necessary to combine several approaches to define the requireme nts compl etely. Some me thods a re better at capturing control ftow and synchroniza tion, where as other methods are

TABLE 4.4 Importance of Specification Criteria During Reactive-System Life Cycle (Ardis.et al. 1996) (R = Requirements, D = Design, I = Implementation, T=Tusting, M =Maintenance, 0 = Othe r) © 1996 IEEE

R 0 T M 0 Criteria

+ + Applicability + + Implementability

+ + + Testability/simulation + + + Checkability

+ Maintainability + + Modularity

+ + Level of abstraction/expressability + + Soundness + + + + + Verifiability

+ + Runtime safety + + + Tools maturity

+ Looseness + Leaming curve + Technique maturity

+ Data modeling + + + + Discipline

Openmirrors.com

Section 4.12 Information Systems Example 209

be tte r at capturing data transformations. Some problems are more easily describe d in te rms of events and actions, whereas othe r problems are bette r d escribed in terms of control states that re flect stages of behavior. Thus, it may be useful to use one method for data requireme nts and another to describe processes or time-related activities. We may need to express changes in behavio r as we ll as glo bal invaria nts. Models that are adequate fo r designe rs may be difficult for the test team to use. Thus, the choice of a specification technique(s) is bound up in the characteristics of tbe individual proj ect and the pre fe rences of develo pe rs and customers.

4.12 INFORMATION SYSTEM S EXAMPLE

R ecall that o ur Piccadilly example involves se lling adve rtising time for the Piccadilly Te levisiion franchise area. We can use several specification notations to model the require me nts related to buying and selLing advertising time. Because this probl em is an informatio n syste m, we will use only notations that are data-orie nted.

First, we can draw a use-case diagram to represent the key uses of the system, showing the expected users and the major functions that each u ser might initiate. A partial diagram might look Like Figure 4.29. Notice that this high -level diagram cap- tures the esse ntial functionality of the system, but it shows nothing about the ways in which e ach o f these use cases might succeed or fail; for exampl e, a campaign re quest

x---+--------t Plmdllly

M1n~91111ut

Q.---1-------~ Report teletl1lon A tatln~1 Audlm 1

Memre111ut Buua

FIGURE 4.29 Use case for the Piccadilly Te levision advertising system (adapted from Robertson and Robertson 1994).

210 Chapter 4 Capturing the Requirements

I Admt1sln9 I I Conn11clal I I C: Con11111elll 11 R: Rite SeQnent I I ~I Bruk Btuk

ju111~119n hd!ll, ar91 iudluee,

target r1t11s p11cent1s1, lllrt dtte, 114 dtte, u11P.1l~1 dotttlon,

_!·-~!'~-!~O!_~!t!!O~! C111p1l91 I Httel (tltrt dlll, end d111)

- c• lonll c '" c' llnd tine (1at41t 11110)

111111 (•tHk 11111, do11t1on)

(01111 R In 1 j cal prlce (btuk start, fo1t1on)

C*-> Rate S1s•11t ~ p1le1

lonll C In C~ ___ J~:b!!~k_t_l!tl C.dmtloi, C.R111 ~!!~!.n!l_ ______ Co1111111cl1I I ------------- --- _Slot

"!!Hiid m1p1l!n (eo1111111clll tpot!, 10111 ptlce)

FIGURE 4.30 Message Sequeace Chart for a successful request for aa advertising campaiga (;ic;!<iptec;! frnm Robertson ;inc;! Rotiertson 1994).

would faiJ if all of the comme rcial time was already sold. The diagram also shows noth- ing about the type of information that the syste m might input, process, or output. We need more information about each of the uses, to better understand the problem.

As a next step, we can draw event traces, such as the one slhown in Figure 4.30, tbat de pict typical scenarios within a use case. For example, the request for a campaign involves

• Searching each re levant commercial break to see whe ther the re is any unsold time and whethe r commercials during that brea k are like ly to be seen by the campaign's inte nded target audie nce

• Computing the price of the campa ign, based on the prices of the available com- me rcial spots found

• R ese rving available commercial spots for the campaign

Figure 4.30 uses UML-style Message Sequence C harts, in which e ntities whose names are underlined represe nt object instances, whereas entities whose names are not underlined represent abstract classes. Thus, the search for available commercial spots is done by fi rst asking the class for the set C* of re levant Commercial Breaks, and then asking e acb of these Commercial Break instances whe ther it bas available time rtbat is suitable for the campajgn. Boxes surround sequ ences of messages that are repeated for mulltiple instances: for example, reserving time in multiple Commercial Break

Openmirrors.com

A ..

I drtH "ln• p one n1nlar

Pro ram

1udlme type

Sectio n 4.13 Real-Time Example 211

AdnrtltlR Cain al R 0 •• 1 eoordln1IH O •• • camP1lqn nun••r 19eney e1,.p1l91 11111 Ole

i nd d1h ur~tlon Ud,et

11r,1l t 'udluce tor 1' r1tlnq ""'1''9' req re4 1p11 "dun t on 1 mnnerela I/ re nove eon narc al() bull4 ca111p1l9•/j prl Cl CUI p1 l9n

* Coon,..erclal S ot dut1tlon

- ---<* Commtrchl 4a1111 dltpos1l d111

u :soclated with Ru• St mint day or week 119nent " "' momblllty pereent19• or 1udlenee typ•

I OI " '' n le t lu ()

FIGURE 4.31 Partial UML class diagram of Piccadilly Television advertising system (adapted from Robertson and Robertson 1994).

instances, o r creating multiple Commercial Spo ts. The resulting campaign of com- mercial spo ts and the campaign's price are re turned to the requesting Adv ert ising Agency. SimiJa r traces can be drawn for o the r possible respo nses to a campa ign request and fo r o ther use cases. In drawing these traces, we start to identify key entities a nd re la tio nships, which we can record in a UML class diagram, as in figure 4.31.

The comple te specifica tion fo r Picca dilly is quite long and invo lved, and the R obertsons' book provides many of the details. H owever, the examples here make it clear that diffe rent no tations are suitable for re presenting different aspects of a prob- lem's re quire me nts; it is important to choose a co mbination of techniques that paints a comple te picture o f the problem, to be used in designing, implementing, and testing the system.

4.13 REAL-TIME EXAMPLE

Recall that the Ariane -5 explosion was caused by the reuse of a secti on of code from Ariane-4. Nuseibe h (1997) analyzes the problem from the point of view of require- ments reuse. That is, man y software e nginee rs fee l tha t great bene fi ts can be had from reusing require ments spe cifications (and their re late d design, code, and test cases) from pre viously develo ped syste ms. Candidate specifications are identified by looking for functio nality o r beh avio ral requirements that are the same or similar, and then making modifications where necessary. In the case o f Ariane-4, the ine rtial reference sys tem (SRI) perfo rmed ma ny o f the functio ns needed by Ariane -5.

212 Chapter 4 Capturing the Requirements

However, Nuseibeh notes that although the needed functionality was similar to tbat in Ariane-4, there were aspects of Ariane-5 that we re significantly different. In par- ticular, the SRI functionality that continued after liftoff in Ariane-4 was not needed after Liftoff in Ariane-5. Had requirements validation been done properly, the analysts would have discovered that the functions active a t'ter lit'toff could not be traced back to any Ariane-5 require ment in tbe require ments definition or specification.1bus, require- ments validation could have played a crucial role in preventing the rocket's explosion.

Another preventive measure migbt have been to simulate the requirements. Sim- ulation would have shown that the SRI continued to function after liftoff; then, Ariane -S 's design could have been changed to re use a modified version of the SRI code. Consider again the list of criteria proposed by Ardis and colleagues for se lecting a speciJkation language. This List includes two items that are especially important for specifying a sys- tem such as Ariane-5: testability/simulation and runtime safety. In Ardis's study, the team examined seven specification languages-Modechart, VFSM, Esterel, Latos, Z, SOL, and C- for suitability against each of the criteria; only SOIL was rated "strong" for testability/simulation and runtime safety. An SOL model consists of several concur- re nt communicating processes like the coin slot process in Figure 4.32.

To validate an SOL mode l, the system requirements can be writte n as temporal- logic invariants:

CILAIM;

Barrier = locked IMPLIES (Barrier = locked)

UNLESS (sum >= entryfee);

ENDCLAIM;

DCL val, /* value of col• */ IUl'I lnttgtr: /* IUlll of COIH lnmted */

DCL lftt f11 Intl er: = 100 : /* fH to enter zoo•/

FIGURE 4.32 SOL process for the coin slot of the twnstile problem.

Openmirrors.com

Section 4.14 What This Chapter Means for You 213

SOL is a mature formal method that includes object-oriented concepts and powerful modeling features: for example, processes can be spawned dynamically, can be assigned identifiers, and can store persistent data; events can carry data parameters and can be directed to specific processes by refe rring to process identifiers; and timers can model rea l-time de lays a nd deadlines. Co mme rcia l tools are available to support design, de buggjng, and mainte nance of SOL specifications. Thus, one possible prevention tech- nique migbt have been the use of a specification method Like SOL, with accompanying too l suppo rt.

We will see in later chapte rs that preve ntive steps could also have been take n dur- ing design, imple mentatio n, o r testing; however, measures taken during require me nts analysis would have led to a greater unde rstanding of the differences between Ariane-4 and Ariane-5, and to de tecting the root cause of the error.

4.14 WHAT THIS CHAPTER MEANS FOR YOU

In this chapte r, we have shown tbe best practjces for developing quality software require ments. We have seen that requirements activities should not be performed by the software deve loper in isolation: definition and specification e fforts re quire working closely with users, customers, testers, designers, and othe r team members. Still, there are several skills that are important for you to master on your own:

• It is essential tbat the req uire ments de finition and specification documents describe the problem, le aving solution se lection to the designe rs. The best way of en suring that you do no t stray into the solution space is to describe require me nts and specifications in te rms of e nvironme ntal pbe nomena.

• There are a varie ty of sources and means for e liciting requirements. There are botb functional and quality req uire ments to keep in mind. The functional require - ments explain wbat the system will do, and the quality requirements con strain solutions in te rms of safety, reliabiJity, budge t, sche dule, and so on.

• There are many differe nt types of definition and specification tecbniques. Some are descriptive, suc h as e ntity-relationship diagrams and logic, while othe rs are be havio ra l, such as event traces, data-flow diagrams, and functio ns. Some h ave graphical nota tio ns, and some are based on rnatbematics. Each empha sizes a dif- fe rent vie w of the proble m, and suggests diffe rent criteria for decomposing a problem into subproble ms. It is often desirable to use a combination of tech- niques to specify the different aspects of a system.

• The specification tecbniques also differ in terms of their tool support, maturity, unde rstandability, ease of use, and mathe matical formality. Each one should be judged for the project at band, as the re is no best universal technique.

• Re quire ments questio ns can be answered using models or prototypes. In eithe r case, the goal is to focus o n the subpro blem that is at the heart of the question , ratbe r than necessarily modeling o r prototyping the e ntire problem. If prototyping, you need to decide ahead of time whether the resulting software will be kept or thrown away.

• Requirements must b e validated to ensure that they accurately reflect the cus- tome r's expec tations. The requirements should also be checked for comple te ness,

2 14 Chapter 4 Capturing t he Requirements

correctness, consistency, feasibility, and mo re, sometimes using techniques or tools that are associated with the specification me thods you have chosen. Finally, you should verify that the specification fulfills the requirements.

4 .15 WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM

Your development te am must work together to elicit, understand, and document require- ments. Ofte n, diffe rent team membe rs concentra te o n separate aspects of the require- ments: the networking expert may work on network requirements, the user-inte rface expert o n screens and reports, the database expert o n data capture and storage, and so on. Because the disparate requirements will be integrated into a comprehensive whole, requirem e nts must be written in a way that a llows them to be Jinked and controlled. For e xampl e, a change to on e re quirement may affect othe r, re lated re quire ments, and the me thod s and tools must support the cha nges to e nsure that errors are caught early and quickly.

At the same time, the requireme nts part o f your team must work closely with

• Cu stomers and users, so that your team builds a p roduct that serves their needs • D esigners, so that they construct a design that fulfills the requirements specification • Testers, so that their test scripts adequately evalua te whether the impl ementati on

mee ts the requirements

• D ocume ntation writers, so that they can write user manuals from the specifications

Your team must also pa y attention to measure me nts that reflect requireme nts quality. The measures can suggest team activities, such as prototyping some requirements when indicators show that the requireme nts are not well-unde rstood.

Finally, you must work as a team to review the requirements definition and sp eci - ficatio n documents, and to upda te those docume nts as the require ments change and grow during the development and maintenance processes.

4 .16 WHAT THIS CHAPTER MEANS FOR RESEARCHERS

The re are many research areas associated with require ments activities. Researche rs can

• Investigate ways to reduce the amount of uncerta inty a nd risk in requireme nts • D evelop specification techniques and tools tha t permit easier ways to prove assump-

tions and assertions, and to demonstrate consistency, completen ess, and determinism • D evelo p tools to allow traceability across the vario us in terme dfate and fi nal

products of softwa re developme nt. In pa rlicular, the tools can assess the impacl of a proposed ch ange on products, p rocesses, a nd resources.

• Evaluate the many different ways to review requireme nts: tools, checklists, inspections, wa lktbroughs, and more. It is mmportant to know which techniques are best for what situations.

• Cr eate new techniques for simulating requirements behavior. • H elp us to understand what types of requirements are best for reuse in subsequent

projects, and how to write requirements in a way that enhances their later reuse.

Openmirrors.com

Section 4.17 Term Project 215

4.17 TERM PROJECT

Your clients at FCO have pre pared the foUowing se t of English-language require - ments for the Loan Arranger system. Like most sets of re quireme nts, this set must be scrutinized in several ways to dete rmine if it is correct , complete, and consistent. Using the require me nts be re and in supple me ntary material about th e Loan Arrange r in earlier chapters, evaluate and improve this se t of requirements. Use many of the tech - niques presented in this chapte r, includin g requireme nts measure ment and Ardis's list. If necessary, e xpress the require me nts in a requirements lan gu age or mode ling technique, to make sure tbat tbe static and dynamic prope rties of the syste m are e xpressed well.

Preconditions and Assumptio ns

• The Loan Arranger syste m assumes that there alre ady exist lenders, borrowers, and loans fro m wbicb to choose, and that investors exist wbo are interested in buying bundl es of loans.

• The Loan Arranger syste m contains a repository of info rmation about loans from a varie ty o f lende rs. This reposito ry may be empty.

• At regular inte rvals, each lender provides reports listing tbe loans that it has made. Loans that have already been purchased by FCO will be indicated on these re po rts.

• Each loan in the Loan Arranger reposito ry represents an investment to the n be bundled and sold with other loans.

• The Loan Arra nger syste m may be used by up to four lo an analysts simultaneously.

High-Level Description of Functionality

1. The Loan Arranger system will receive monthly rep orts from e acb lender of new lo ans issued b y that lende r. The loans in tbe re port recentl y purchased by FCO for its investme nt po rtfolio will be marked in the rep ort. The Lo an Arranger system will use tbe repo rt information to update its repository of available loans.

2. The Loan Arrange r syste m will receive monthl y re po rts from e ach lende r pro vid - ing updates abo ut the sta tus of loans issued by that lender. The updated info rma- tio n will include : the curre nt interest rate for an adjustable rate mortgage, and the status o f the bo rrowe r with respect to the loan (good, late, o r default) . For loans in tbe FCO portfolio, the Loan Arranger will update the data in the rep ository. Loans not in the FCO portfolio will also be examined in order to determine if a borrowe r's standing sho uld be updated. FCO will provide e acb le ader with the format for the re ports, so that all reports will share a common format.

3. The loan analyst can change individual data records as described in Data Ope ra - tio ns.

4. AU ne w data must be validated before they are added to the repository (accord- ing to the rules described in Data Constraints).

5. The loan ana lyst can use the Loan Arrange r to identify bundles o f Joan s to sell to pa rticular investors.

216 Chapter 4 Capturing the Requirements

Functional Requirem ents

1. The loan analyst sh ould be able to review all of the information in the repository for a particular lending institution, a particular Joan, or a particular borrowe r.

2. The loan analyst ca n create, vi ew, edit, o r delete a loan from a portfolio or bundle. 3. A Joan is added to the portfolio automaticaUy, when the Loan Arranger reads the

re ports provided by the lenders. A report ca n be read by the Loan Arranger only after the associated lende r bas been specifie d.

4. The loan a na lyst can create a ne w lende r. 5. The Joan analyst can dele te a le nder only :if there are no loans in the portfolio

associated with this lender. 6. The loan analyst can change le nder contact and phone number but not lender

name and identification numbe r. 7. The loan analyst cannot change borrower information. 8. The loan analyst can ask the syste m to sort, search, o r organize loan informaition

by ce rtain crite ria: amount, inte rest rate, settleme nt date, borrowe r, lender, type of loan, o r whethe r it has been marked for inclusion in a ce rtain bundle. The o rga- nizational crite ria s hould include ranges, so that information will be included o nly if it is within two specified bounds (such as be tween January 1, 2005 and January 1, 2008). The organizational crite ria can al so be based on excl usion such as all loans not marked, or all loans not between January 1, 2005 and January 1, 2008.

9. The loa n analyst sh ould be able to request reports in each of three formats: in a file, on the screen, and as a printed report.

10. The loan analyst should be able to request tbe fo ll owing info rmatio n in a report: any a ttribute of loan, le nder, or borrowe r, and summary statistics of the attributes (mea n, standard deviation, scatter diagram, and histogram). The informatio n in a report can be restricted to a subset of the total information , as described by the loan analyst's o rganizing criteria.

11. The loan analyst must be able to use the Loan Arranger to create bundles ithat meet the prescribed characteristics of an investme nt request. 1be loan analyst can id!e ntify these bundles in several ways:

• By manually identifying a subset of loans that must be included in the burndJe, eithe r by naming particular loans or by describing tbem using attributes or ranges

• By providing the Loan Arranger with tbe investment crite ria , and allowing the Loan Arranger to run a loan bundle optimization request to select the best set of loans to mee t those criteria

• By using a combination of tbe above, wbere a subset of loans is fiist chosen (manually o r automatically), and then optimizing the ch osen subset according to the investme nt crite ria

12. Cr eating a bundle consists of two steps. F:irst, the loan analyst wo rks with the Loan Arranger to create a bundle according to the crite ria as described above. The n the candidate bundle can be accepted, rejected, or modified. Modifying a

Openmirrors.com

Section 4.14 Term Project 217

bundle means that the analyst may accept some but no t all of the loans suggested by the Loan Arranger for a bundle, and can add specific loans to the bundle before accepting it.

13. The loan analyst must be able to mark loans for possible inclusion in a loan bun- dle. Once a loan is so marked, it is not ava il able for inclusion in any other bundle. If the loan analyst marks a loan and d ecides not to include it in the bundle, the marking must be removed and the lo an made available for other bundling de cisions.

14. Whe n a candidate bundle is accep ted, its loans are remove d fro m consideration for use in other bundles.

15. All current transactions must be resolved before a loan analyst can exit the Loan Arranger system.

16. A loan analyst can access a re pository of investment requests.. This repository may be e mpty. Fo r each investment request, the analyst uses the request constraints (on risk, profit, and te rm) to de fine the paramete rs of a bundle. Then, the Loan Arranger system identifies loans to be bundled to meet the re quest constraints.

Dat a Con straints

1. A single borrowe r may have mo re than one loan.

2. Every lender must have a unique ide ntifie r. 3. Every borrower mus t ha ve a unique identifier.

4. Each loan must have at least o ne borrower. S. Each lo an must have a loan amount o f at le ast $1000 but n ot more than $500,000. 6. There a re two types of loans based on the amount of the loan: reguJar and jumbo.

A regular loan is for any amo unt less than or equal to $275,000. A jumbo loan is for any amount over $275,000.

7. A bo rrower is conside red to be in good standing if all loans to that borrowe r are in good standing. A borrower is considered to be in defauJt standing if any of the loa ns to that borrower have de fault stand ing. A borrower is said to be in late standing if a ny of the loans to that borrowe r have late standi ng.

8. A lo an o r borrowe r ca n change from good to late, from good to de fauJt, from late to good , or fro m late to default. Once a loan or borrower is in de fault standing, it canno t be changed to a no ther standing.

9. A loa n ca n change from A RM to FM, and from FM to ARM. 10. The profit requeste d by an investor is a number from 0 to 500. 0 represents no

profit o n a bundle. A nonze ro profit represents the rate o f return on the bundle; if the profit is x, then the investor expects to receive the o riginal in vestment plus x percent of the o rigina l investme nt whe n the lo ans are paid off. Thus, if a bundle costs $1000, and the investor expects a rate of return of 40, then the investor hopes to have $1400 when all the loans in the bundle are paid off.

11. No loan ca n a ppear in mo re than o ne bundle.

218 Chapter 4 Capturing the Requirements

Design and Interface Constraints

1. The L oan Arranger system should work on a Unix system. 2. The loan analyst should be able to look at information about more than one loan ,

le nding institution , o r borrowe r at a time. 3. The Jo an analyst must be able to move forward and backwards through the

information presented on a screen. When tbe information is too voluminous to fit o n a single scree n , the use r must be informed that mo re in formation earn be vie wed.

4. Whe n the system displays the results of a search, the current organizing criteria must always be displayed along with the info rmation.

5. A single record o r line of o utput must ne ve r be broken in the middle of a fie ld. 6. The use r must be advised when a search request is inappropriate or illegal. 7. Whe n an error is e ncountered , the system should return the user to the previous

screen.

Quality Requir,ements

1. Up to four loan analysts can use the system at a given time. 2. If updates are made to any disp layed informati on, the information is refreshed

within five seconds of adding, updating, or d eleting information. 3. The syste m must respond to a Joan analyst's re quest for informati on in less than

five seconds from submission of the request. 4. The syste m must be available fo r use by a loan anal yst during 97% of the business

day.

4.18 KEY REFERENCES

Michae l Jackson's book Software Requirem ents and Specifications (1995) provides gen - e ral advice o n how to overcome common problem s in understanding and formulating require me nts. His ideas can be applied to any requirements technique. D onald Gause and Ge ra ld Weinbe rg's book Exploring Requirem ents (1989) focuses on the hum an side of the requirements process: problems and techniques for working with customers and users and fo r devising new products.

A comprehensive require ments-definitio n template developed by James and Suzanne Robertson can be found at the Web site of the Atlantic Systems Guild: http:// www.systemsguild.com. This template is accompanied by a description of the Volere pro- cess mo de l, which is a comple te process for eliciting and checking a set o f requireme nts. Use of IIbe template is de scribed in the ir book Mastering the Requirements Process (1999).

Pe te r Coad and Edward Yourdon 's book Object-Oriented Analysis (1991) is a classic 1rext o n o bject-oriented requirements ana lysis. The most thorough re ferences on tbe Unified Mode ling L anguage (UML) are the books by James Rumbaugh, Ivan Jacobson, and Grady Booch, especially the Unified Modeling Language Referen ce Manual, and the docume nts re leased by the Object Management Group; the latte r can

Openmirrors.com

Section 4. 19 Exercises 219

be downloaded fro m the organization's Web site : http://www.omg.org. Martin Fowler 's book Analysis Patterns (1996) provides guidance on how to use U ML to model com- mon business proble ms.

Beginning in 1993, the IEEE Computer Socie ty has started to sponsor two con - fe rences that we re d irectly re late d to require me nts and were he l.d in aJtern ate years: the Inte rnatio nal Confe rence on R equireme nts E ngineering and the Internation al Symposium on R equirements Engineering. These confe rences me rged in 2002 to fo rm the Inte rnatio nal R eq uireme nts E ngi neering Confe re nce, which is he ld every year. Info rma tio n abo ut upcoming confe rences and a bout proceedin gs from past confer- e nces can be found a t the Computer Society's We b page: http://www.computer.org .

The Requirements Engineering Journal focuses exclusively on new results in elicit- ing, rep resenting, and validating requirements, mostly with respect to software systems. IEEE Software had special issues on requireme nts engineering in March 1994, Ma rch 1996, March/April 1998, May/June 2000, January/February 2003, and March/April 2004. Other IEEE publications ofte n have special issues on particular types of requireme nts analysis and specificatio n me thods. Fo r example, the September 1990 issues of I EEE Computer, IEEE Software, a nd IEEE Transactions on Software Engineering focused on formal m e thods, as did the May 1997 and January 1998 issues o f IEEE Transactions on Software Engineering and the A pril 1996 issue of I EEE Comp uter.

There are several standards re la ted to software requireme nts. The U.S. Depart- ment o f D e fense bas p roduced MilStd-498, Data Item D escripti on for Software R equire ments Specifications (SR S). The IEEE has produced IEEE Std 830-1998, which is a set o f recomme nded practices and sta11dards fo r fo rmula ting a nd structu![ing require ments s pecificatio ns.

There a re seve ra l too ls that suppo rt requirements capture an d traceabili ty. DOO RS/E RS (Tele logic), Analyst Pro (Goda Software), and R equisitePro (IBM Ratio na l) a re po pular tools for man aging require ments, tracing requirements in do wn- stream artifac ts, tracking ch anges, and assessing the impact of ch anges. Most mode ling no ta tions have tool support that at the least supports the creation and editing of m od- e ls, usu ally supports some fo rm of we lJ-formedoess checking a nd report generation , a nd a t the best offe rs automa ted validation and verificatio n. An independen t survey of requirem ents tools is located a t www.systernsgui ld.com.

There is a n IFIP Working Group 2.9 o n Software R equire ments E ngineering. Some of the presenta tio ns from their allnual meetings are available fro m their Web site: http://www.cis.gsu.e du/- wrobinso/ifip2_9

4 .19 EXERCISES

1. Deve lopers work together with customers and users to define requirements and specify what the proposed system will do. If, once it is built, the system works according to specifi- cation but harms so meone physically or financially, who is responsible?

2. Among the many nonfunctional requirements that can be included in a specification are those related to safety and reliability. How can we ensure that these requirements are testable, in the sense defined by the Robertsons? In particular, how can we demonstrate the reliability of a system that is required never to fail?

220 Chapter 4 Capturing the Requirements

3. In an early meeting with your custome r, the customer lists the following " requirements" for a system he wants you to build:

(.a) The client daemon must be invisible to the user ( b) The system should provide automatic verification of corrupted links or outdated data (<:) An interna l naming convention sho uld ensure that records are unique ( d) Communication between the database and servers should be e ncrypted (e) Relationships may exist between title groups (a t ype of record in the database] (:f) Files should be organizable into groups of file dependencies (g) The system must inte rface with an Oracle database ( h) The system must handle 50,000 users concurrently

Oassify e ach of the above as a functiona l requireme nt , a quality requirement, a d esign constraint, or a process constraint. Which o f the above might be premature design deci- sions? R e-express each of these decisions as a :require ment that the design decision was m eant to achieve.

4. Write a decision table that specifies the rules fo r the game of checkers. 5. If a decision table has two identical columns, the n the requirements specification is redun-

dant. How can we tell if the specification is contradictory? What other characteristics of a d ecision table warn us of problems with the requirements?

6. Write a Parnas table that describes the output of the algorithm for finding the roots of a quadratic equation using the quadratic form ula.

7. Write a state-machine specification to illustrate the requireme nts of an automatic bank- ing machine (ABM).

8. A state-machine specification is complete if and only if there is a transition specified for e very possible combination of state and input symbol. We can change an incomplete spec- ificatio n to a comple te one by adding an extra state, called a trap state. Once a transitio n is made to the trap state, the system remains in the trap state, no matte r the input. For example, if 0, 1, and 2 are the only possible inputs, t.he system depicted by Figure 4.33 can be completed by adding a trap st ate as shown in Figure 4.34. In same manner, complete your state-machine specification from Exercise 7 .

9. A safety prope rty is an invariant property that specifies that a particular bad behavior never happens; for example, a safety property of the turnstile problem is that the numbe r of e ntries into the zoo iis never more than the number of e ntry fees paid. A liveness property is a property that specifies that a particular behavior eventually happens; for example, a live- n ess property for t!he turnstile problem is that when an e ntry fee is paid, the turnstile b ecomes unlocked. Similarly, a liveness pro perty for the library syste m is that every borrow

FIGURE 4.33 Original system for Exercise 7.

Openmirrors.com

Section 4. 19 Exercises 221

FIGURE 4.34 Complete system with trap state for Exercise 7.

request from a Patron who has no outstanding library fines succeeds. These three proper- ties, when expressed in logic, look like the following:

0 (nurn_coins ~ nurn_entries) 0 (insert_ coin 0 barri er=unl ocked) D (borrow(Patron,Pub) A Patron.fines = 0) ~

03 Loan. [Loan.borrower~Patron A Loan.Publ i cati on ~ Pub] )

List safety and live ness properties for your automated banking machine sp ecifi cation fro m E xercise 6. Express these properties in te mporal logic.

10. Prove that your safety and liveness properties from Exercise 8 hold for your state- machine model of your automated banking machine specification from Exercise 6. What assumptio ns d o you have to ma ke about the ABM's environment (e.g., that the machine has sufficient cash) for your proofs to succeed ?

ll. Sometimes part of a system may be built quickly to demonstrate feasibility or functional- ity to a customer. This prototyp e system is usually incomplete; the real system is con- structed after the custome r and developer evaluate the prototype. Should the system requireme nts document be written before or after a prototype is developed ? Why?

U . Write a se t of UML models (use-case diagram, MSC diagrams, class diagram) for an on- line telephone directory to replace the phone book that is provided to you by your phone company. The directo ry should be able to provide phone numbers when presented with a na me; it showld also list area codes fo r differe nt parts of the country and gene rate emer- gency telephone numbers fo r your a rea.

13. D raw data-flow diagrams to illustrate the functions and data flow for the on-line tele- pho ne directo ry syste m specified in the pre vious problem.

14. What are the bene fits of separating functional flow from data fl ow?

15. What special kinds of proble ms are presented when specifying the requirements of real- time systems?

16. Contrast the benefits of an object-oriented requirements specification with those of a functional decomposition.

222 Chapter 4 Capturing t h e Requirements

17. Write a Z specification for a presenta tion sched u ling syste m. The system keeps a record of which presenters ar e to give presentations o n which dates. No presenter should be sch ed- uled to give more than one presentation. No more than four presentations should be scheduled for any particular date. The re sho uldl be operations to Add and R emove pres- e nta tions from the schedule, to Swap the dates of t wo presentatio ns, to List the presen- t atio ns scheduled for a particular date , to List the date on which a particular presenter is scheduled to speak, and to send a R eminder message to each presenter on the date o f his or he r presentation . Yo u may d efine a ny additio na l o perations that help simplify the specification.

18. C omplete the partial SDL data specification for the library problem in Ftgure 4.20. In particular, write axio ms for no ngenerator operations unres erve , i sOnLo an, and isOnReserve. Mo di fy your axioms for o pe ra tion unreserve so that this opera tion assumes that multiple requests to put an item on reserve mig ht occur between two re quests to unreserve that item.

19. What kinds of problems should you look fo r when do ing a require ments review? Make a checklist of these problems. Can the checklist be universally applicable or is it bette r t o use a checklist that is specific to the applicatio n do main?

20. Is it ever possible to have the re quirements definition document be the same as the re quirements specification ? What are the pros and cons of having two d ocuments?

21. Pfleeger and H atton (1997) examined the q ua lity of a system that had been specified using formal methods. They found that the syste m was unusually well-structured and easy t o test. They speculated that the high quality was due to the thoroughness of the specifica- tion, no t necessarily its formality. H ow could you design a study to d etermine whether it is fo rma lity or thoroughness that lea ds to high q ua lity?

22. Sometimes a customer requests a requireme nt t hat you know is impossible to implement. Sho uld you agree to put the requireme nt in the definition and sp ecification documents anyway, thinking th at you might come up with a novel way of meeting it, or thinking that you will ask that th e requirement be d ropped la te r? Discuss the ethical implication s of promising what you know you cannot de liver.

23. Find a set of natural-language requirements at your job or at this book's Web site. R eview the requirements to determine if there are any problems. For example, are they consis- te nt? Ambiguous? Conflicting? D o they contain any design or implementation decisio ns? Which representation techniques might help reveal a nd elimina te these problems? If the p roblems remain in the requirements, what is their likely impact as the system is designed a nd implemented?

Openmirrors.com

5

In this chapter, we look at • views of software architecture • common a rchitectural patte rns • criteria for evaluating and comparing

design a lte rnatives • software a rchitecture docume ntati on

In the last chapter, we learned ho w to work with our customers to determine wbat they want the proposed syste m to do. The result of the requiremen ts process was two docu- ments: a require me nts document that captures the customers' needs and a requirements specifica tion tbat describes how the proposed system should behave. The next step in development is to start designing how the system will be constructed. lf we are building a re latively small syste m, we may be able to progress directly from the specification to the design o f data structures and algorithms. Howe ve r, if we are building a larger system , then we wi ll want to decompose the system into units of manageable size, such as sub- systems or modules, be fore we contemplate d etails about the data or code.

The software architecture is this decomposition. In this chapter, we examine dif- ferent types o f decompositio n. Just as buildings are sometimes constructed of prefabri- cated sections based on commo nly needed architectural constructs, some prefabricated software architectural styles can be used as guide lines for decomposing a new system. Ofte n, tbe re will be multiple ways to design the archi tecture, so we explo re how to com- pare co mpe ting designs and choose the one that best sui ts our needs. We le arn bow to docume nt o ur decisions in a software architecture document (SAD) as the architecture sta rts to stabilize, and bow to verify that this architecture will meet the custom er 's requiremen ts. The ste ps we lay out result in a software architecture that guides the rest of the system's d evelopmen t.

5.1 THE DESIGN PROCESS

At this po int in the developme nt process, we have a good unde rstanding of our cus- to me r's proble m, and we have a requireme nts specifica tio n that describes wh at an

223

224 Chapter 5 Designing the Architecture

acceptable software solution would look like. If the specification was done well, it has focused on function, not form; that is, it gives few hints about how to build the proposed system. Design is the creative process of figuring out bow to implement all of the cus- tome r's requirements; tbe resulting plan is also caJled the design.

Early design deci.sio ns address the system's architecture, explaining how to decompose the system into units, how the units relate to o ne another, and describing any externally visible properties of the units (Bass, Cle ments, and Kazman 2003). Later design decisions address how to imple me nt the fodividual units. To see how architec- ture re lates to both design and require ments, conside r again the example in which C huck and Betsy HoweU want to build a new ho1J1se. TheiI require ments include

• rooms for the m and their truee children to sleep • a place for the children to play • a kitchen and a large dining room that will hold an extendable tabl e • storage for bicycles, lawn mowe r, ladder, barbecue, patio furniture, and more • a place for a piano

• heating and air conditioning

and so on. From the requirements, an architect produces preliminary designs fo r the Howe lls to consider. The architect may start by showing the Howe lls some generic plans based on different styles of houses, such as two-story colonials and bungalows, to get a better feel for what style the Howells would prefer. Within a particular architectural style, the architect may sketch. out various design alte rnatives. For instance, in one design, the kitchen, dining room, and children's play space may share o ne large open area, whereas another design may locate the play space in a Jess public part of the house. One design may emphasize large bedrooms, and another may reduce bedroom size to make room for an additional bathroom. How the Howells choose from among the design alternatives will depend on their preiferences for a design's distinguishing characteristics, such as the utility and character of the rooms' layouts, or the estimated cost of construction.

The resulting design is the house's architecture, as suggested by FigUie 5.1. M ost obviously, the architecture describes the skeletal structure of the house, the locations of walls and support beams, and the configuratio n of e ach room. It also includes plans for

FIGURE 5.1 Architectural plans.

Openmirrors.com

Section 5.1 The Design Process 225

sufficient heating and cooling, and the layout o f air ducts; maps o f water pipes and t!heir connections to the city's wate r mains and sewer lines; and maps of e lectrical circ111its, locatio ns of outlets, and the amperage of circuit breakers. Architectural decisions tend to be structural, syste ma tic, and systemic, making sure that all esse ntial elements of the requireme nts a re addressed in ways that harmonize custome r needs with the rea lities of ma te rials, cost, and availability. They are the earliest design decision s to be made and, once imple mented , are the hardest to change. In contrast, late r d esign decisio ns, such as those rega rding flooring, cabinetry, wa ll paint, or paneling, are relatively local - ized a nd easy to mo dify.

Difficult to change does not mean impossible. It is not unus ual o r unreasonable for the a rchitecture o r sp ecificatio ns to change as the ho use is being built. Modifications may no t be pro posed o n a whim, but instead on a change in pe rception or need , o r in reactio n to new info rma tion. In the Howells' h ouse, engineers ma.y suggest changes to reduce costs, such as moving bathroo ms or the locatio n of the kitchen sink, so that they ca n share wate r pipes and drains. As the Ho wells think about how rooms will be u'Sed , they ma y ask that a bea ting duct be re route d, so that it does not run along the walJ where they plan to put their piano. If there are construction-cost. overruns, they may scale back their plans to sta y within their budget. It makes sense fo r the Howells to raise these issues and to change their specifications now, rathe r than be stuck wiilh a ho use that displeases them, does not suit their need s, or costs more than they can afford. Indeed , a custo me r, in conce rt with the deve lo pers, will often modi fy require - ments well after the initiial requirements analysis is complete.

In many ways, designing softwa re resembles the process of designing a new house. We are obligated to devise a solution that meets the customer's needs, as docu- mentecll in the requi reme nts specificatio n. Howe ve r, as with the H owells' house, the re may no t be a single " best" o r "co rrect " architecture, and the nwnber o f possible solu- tio ns may be limitless. By gleaning ide as fro m past solutions and by seeking regular feedback fro m the custo me r, designe rs create a good architecture, one that is able to accommodate and ada pt to change, that results in a product that will make the cu s- to me r happy, and that is a useful re fe rence and source of guidance throughout the product's We time.

Design Is a Creative Process

Designing software is an intellectually challenging task. It can be taxing to keep track of all the possible cases that the software system mjght encounter, including the exceptio nal cases (such as missing or incorrect information) tha t the system must accommodate. And this effort takes into account onl y the system's expected functionality. In addition, the sys- tem has nonfunctio nal design goals to fulfill, such as being e asy to maintain and exte nd, being ea sy to use, o r being easy to po rt to other platforms. These nonfunctional reqlllire- ments oot only constrain the set of acceptable solutions, but also m ay actually conft.ict with each othe r. For exa mple, techniques for ma lting a software system retiable or reusable a re costly, and thus hinde r goals to keep de velopment costs within a specified budget. Furthe rmo re, exte rnal facto rs can complicate the design task. Fo r example, the softwa re may have to adhere to preexisting ha rdwa re in terface specificali ons, wo rk with legacy software, or confo rm with standard data formats or governmen t regulations.

226 Chapter 5 Designing the Architecture

There are no instructions or formulae that we can foUow to guarantee a successful design. Creativity, intelli gence, experience, and expert judgment are needed to devise a design that adequately satisfies aU of the system 's requirements. D esign methods and techniques can guide us in making design decisions, but they are no substitute for cre- ativity and judgme nt.

We can improve o ur design skills by studying examples of good design. Most d esign work is routine d esign (Shaw 1990), in which we solve a problem by reusing and adapting soluti ons from similar proble ms. Conside r a che f who is asked to pre pare din- ner for a finicky patron who has particular lastes a nd die tary co nstraints. The re may be few recipes that exactly fit the patron's tastes, and the chef is not likely to concoct brand new dishes for the occasion. Instead, the chef may see k inspiration from favorite recipes, will substitute ingredients, and will adapt cooking methods and times as appro- priate. lbe recipes alone are not e nough; there is considerable creativity in the making of this m eal: in choosing the starting recipes, in adapting the ingredient list, and in mod- ifying the cooking instructio ns to accentuate flavors, textures, and colors. What the chef gains by starting from proven recipes is efficiency in quickly settling on a plan for the mea l and predictability in knowing that the resulting dishes should be simiJar in quality to dishes de rived previously from the same recipes.

Similarly, experienced software developers rarely design new software from fust principles. Instead , they borrow ideas from existing solutions and manipulate them into new, but no t entire ly original, designs. By doing so, deve lopers can usually arrive at a suitable design more quickJy, using the properties o f the borrowed solutions to assess the properties of the proposed design. Figure 5.2 shows several sources from which d evelope rs can draw wh en looking for guidance in designing a new system.

There are many ways to le verage existing solutio ns. One extreme is clo n.ing, whe reby we borrow a whole design, and perhaps even the code, making mino r adjust- ments to fit our particular problem. For example, a de veloper might clone an existing system to customize it for a new custome r-though, as we will see, there are better ways of producing variations of the same product. Slightly less extreme is to base our design o n a reference model: a standard generic arcltitecture for a particular application domaia. A reference model suggests only how we decompose our system into its maj or

FIG URE 5.2 Sources of design advice.

Experience

Design Principle1

Openmirrors.com

Design Co~nntions

Similar Systems

Design Patterns

Reference Models

Architectu111I Styles

Section 5.1 The Design Process 227

compone nts and how those compone nts interact with each other. The design of the individual components and the d etails of their interactions will depend 0 111 the specific application being deve loped. As an example, Figure 5.3 shows the reference model fo r a compiler; the specifics of the parser, semantic analyzer,optimizations, and data repos- ito ries wi ll vary greatly with the compiler's programming language. The re are existing o r proposed re fere nce models for a varie ty of application domains, including operating systems, inte rpre ters, database management systems, process-control systems, inte- grated tool enviro nments, communication networks, and We b services.

Mo re typically, our proble m does not have a re fe re nce model, and we create a design by combining and adapting generic design solutions. In your other courses, you have learned about generi c, low- level design solutions such as data structures (e.g., lists, trees) and algorithm paradigms (e .g., divide-a nd-conquer, dynamic programming) tha t are useful in addressing entire classes of problems. Software architectures h ave generic solutio ns too, called a rchitectura I styles. Like refere nce mo dels, architectural styles give advice about how to decompose a problem into software units and how those units should inte ract with each other. Unlike refere nce models, architectural styles are no t optimized for specific application domains. R ather, they give generic advice abou t how to approach gene ric design problems (e.g., how to encapsulate data shared by all aspects of the system).

Sometimes, improving o ne aspect of a software system has an adve rse effect o n anot her aspect. For this reason, creating a software syste m design can raise severa l orthogonal issues. Good software architectural design is about selecting, adapting, and integrating several architectural styles in ways that best produce the desired result. There are many tools at our disposal for understanding our options and evaluating the

KE'I I Component I Dita store

Dita fetch/store

- - - - - Control flow

Stmbol table

Attributed parse tree

FIGURE 5. 3 Refe rence model for a compiler (adapted from Shaw and Garlan 1996).

228 Chapter 5 Designing the Architecture

chosen architecture . Design pat.terns are generic solutio ns for making lower-level design d ecisions about individual software modules o r smaU coUections of modules; they will be discussed in Chapter 6. A design convention or idiom is a coUection of d esign d ecisions and advice that, taken together, p romo tes certain design qualities. For e xample, abstract data types (ADTs) are a d esig n conve ntion that encapsulates data re prese ntation and supports reusa bitity. As a design convention matures and becomes more widely used, it is package d into a design patte rn o r architectural style, for e asier refe ren ce and use; uJtimate ly, it may be encoded as a program- language construct. Objects, moduJes, exceptions, and templates a re e xamples of design and programming conventions that are now suppo rted by programming languages.

Sometimes, existing solutions cannot solve a proble m satisfactorily; we need a no ve l solution that requires innova tive design (Shaw 1990). In contrast to routine d esign, the innovative design process is characte rized by irregula r bursts of progress tbat occur as we bave filashes of insight. The only guidance we can use in innovative design is a set of basic design principles that are descriptive characte ristics of good design, rather than prescriptive advice about how to design. As such , they are more use- ful whe n we are evaluating and comparing design a lternatives than when we are designing. Nevertheless, we can use the principles during design to assess h ow we U a particul ar design decisio n adheres to them. In the e nd, innovative design usually takes longer than routine desi.gn , because often the re a re stagnant pe riods be tween insights. Innovative designs must be mo re vigorously e valuated than routine designs, because they have no track record. Moreover, beca use such design evaluation is based mo re on expert judgment than o n obj ecti ve crite ria , a n innovative design sho uld be examined by seve ral seni or design ers before it is fo rmally approved. In general, an innovative design s houJd be superi or to competing routine d esigns to justify the extra cost o f its d eve lopment and evaluation.

So sho uJd we always stick with tried and true approaches, rather than explore new ways of designing systems? A s with other skilled disciplines, such as music or sp orts, it is o nly through continuous learning and practice that we improve our design skills. What distinguishes an experie nced chef from a novice is her large r re pertoire o f recipes, her pro ficie ncy with a wide range of cooking techniques, her d eep understandfog of ingre- dients and how they change when cooked , and her ability to re fashion a recipe or a mea l to emphasize o r e nh ance the desired experience. Similarly, as we gain more expe- rience with software design, we unde rstand be tte r how to select from among gene ric design solutions, how to apply design principles when deviating from gene ric solutions, and how to combine partial solutions into a cohere nt design whose characteristics improve o n past solution s to similar proble ms.

Design Process Model

D esigning a software system is an ite rative process, in whi ch desig ners move back and forth among activities involving understanding the require me nts, proposing possible solutions, testing aspects o f a solutio n fo r feasibili ty, presenting possibilities to the custo me rs, and docume nting the design for the programmers. Figure 5.4 illustrates the process of converging on a software architecture for a propose d syste m. We start the process by analyzing the system 's requireme nts specification and ide ntifying any

Openmirrors.com

Mod1lln9

Erperl11eatlng wltl. pou1bl1

deto11potltlonr

Anllytlt Dou1untaflon

Astenlng !he Recording p11l11111nuy mhllect•rtl mhltect~te decisions

Section 5.1 The Design Process 229

Review

Checking th1t ou ltthlflt fUll 111itllu

th req1l1u1entt

Soltwm A1ehlt1ttur1

Doeu1U1t (SADJ

FIGURE 5.4 Process for developing a software architecture.

c ritical prope rties o r con strain ts that the eventua l design must exlhibit or re flect. These propert ies can help us identify wbicb architectural s tyles might be usefuJ in our design. D iffe re nt properties will suggest different architectural styles, so we will like ly de ve lo p several architectural plans in paralle l, eacb de pict ing a single facet o r vie w of the archi- tecturn. The multiple vie ws in software design ar,e analogous to the blue pr ints that the H owells' architect produced for their house.

During t he firs t part of the design phase, we ite rate among t hree activities: drawing architectural plans, analyzing how well the proposed architecture promotes desire d properties, and using the a nalysis results to improve and optimize the architectura l plans. The t ypes o f a nalysis we pe rform at t his stage focus o n the syste m 's quality attrib- utes, s uc h as pe rformance, security, and re liability. Thus, our architectural mode ls must include sufficie nt detail t o support whatever analyses we are most inte reste d in perform- ing. Howeve r, we do not want our models to be too de taile d. At the architectural s t age, we focus o n syste m-level decisions, such as communication, coordi natio n, synchro niza- tio n , and sharing; we defer more de ta ile d design decisions, such as those that affect indi- vid ual modules, to the d etaile d design phase. As t he architecture starts to stabilize, we docume nt our mod e ls. Each of our models is an architectu ra l vie w, and the views are inte rconnected, so tha t a change to one view may have an impact o n othe r views. Thus, we keep track o f how the views are re late d and ho w they work togethe r to form a cohe r- e nt integrated design. Fina lly, o nce the architecture is docume nte d , we conduct a formal design review, in which t he project team checks that the architecture m eets all of the sys- te m 's re q uire me nts and is of high quality. If problems are identifie d during the design review, we may have to revise o ur design yet again to address these concerns.

The final o utcome of the software architect ure process is the SAD, used to com- munica te syste m- level design decis io ns to the rest of the deve lopm e nt team. Because the S AD provides a hig h-level overvie w of the syste m 's design , the docume nt is a lso useful for q uickly bringing new developmen t team membe rs up to speed , and for e du- cating t he mainte na nce team about how the system wo rks. Project managers may use the SAD as the basis for o rganizing de velopment teams a nd tracking the team s' progress.

230 Chapter 5 Designing the Architecture

Software architecture and architecture docume nts play a Jess clear role in agile d evelopme nt me thods. The re is an inhe rent conflict b e tween software architecture, which documents the syste m's load-bearing, hard-to-change design d ecisions, and the agile goal of avoiding irrevers ible decisions. This conftict is discusse d further in Sidebar 5.1.

SIDEBAR 5.1 AGILE ARCHITECTURES

A s we noted in Chapter 4, it can sometimes be helpful to use an agile process when there is a great deal of uncertainty about requirements. In the same way, agility can be helpful when it is not yet clear what the best type of design might be.

Agile architectures are based on the four premises of agile methods as stated in the "agile manifesto" (see http://agilemanifesto.org):

• valuing individuals and interactions over processes and tools

• valuing working software over comprehensive documentation

• valuing customer collaboration over contract negotiation

• valuing response to change over following plans

Agile methods can be used to generate an initial design that describes essential require- ments.As new requirements and design considerations emerge, agile methods can be applied

to " refactor" the design so that it matures with the understanding of the problem and the cus- tomer's needs.

But architectural generation is particularly difficult using agile methods, because both complexity and change must be managed carefully. A developer adhering to agile methods is at the same time trying to minimize documentation and to lay out the variety of choices avail- able to customers and coders. So agile architectures are based on models, but only small fea-

tures are modeled, often one at a time, as different options and approaches are explored. Models are often discarded or rebuilt as the most appropriate solution becomes clear. As Ambler (2003) puts it, an agile model is "just barely good enough": it "meets its goals and no more."

Because agile methods employ iteration and exploration, they encourage programmers to write the code as the models are being produced. Such linkage may be a significant prob- lem for agile architectures. As Ambler points out, although some agile methods advocates have high confidence in architectural tools (see Uhl 2003, for instance), others think the tools are not ready for prime time and may never be (see Ambler 2003).

A bigger problem with agile methods is the need for continuous refactoring. The inher- ent conflict between an architecture's representing a significant design decision and the need

for continuous refactoring means that systems are not refactored as often as they should be. Thomas (2005) calls the refactoring of large, complex systems high-risk " wizard's work ," par- ticularly when there is a great deal of legacy code containing intricate dependencies.

Openmirrors.com

Section 5.3 Decomposition and Views 231

5.2 MODELING ARCHITECTURES

In modeling an a rchitecture, we try to rep resent some prope rty of the architecture while hiding o the rs. In this way, we can learn a g reat d e al about the prope rty with out be ing distracted by o the r aspects o f the system. Most importantl y, the colJecti on of models he lps us to reason abo ut whe ther the proposed architecture wilJ meet the spec- ified requireme nts. Garlan (2000) p oints ou t tha t the re are six ways we can use the architectural models:

• to unde rstand the system: what it will do and how it will do it • to de termine how much of the system wilJ re use clemen ts of previo usly built sys-

tems and how much o f Lhe system will be reusable in the future • to p rovide a blueprint fo r constructing the system, including whe re the " lo ad-

be aring" pa rts of the system may be (i.e., those design decisio ns that will be diffi- cult to change later )

• to reason a bo ut ho w the system might evolve, including performan ce, cost, and prototyping concerns

• to analyze d epe nde ncies and select the most appropriate d esign, imple mentation, and testing techniques

• to support manage me nt decisions and unde rstand risks inhe re nt in implementa- tio n and maintenance

In Chapte r 4, we d escribed many techniques for modeling requirements. H ow- e ve r, software architecture mode ling is not so mature. Of the many wa ys to mo del architectures, your cho ice depends partly on the mo del's goal and partly on personal preferen ce. Each has p ros and cons, and the re is n o universal techrnique that works b est in eve ry situatio n. Some developers use the Unified Modeling Language (UML) class diagrams to d epict an architecture, emphasizing s ubsystems rathe r than classes. M ore typ ica lly, software architectures are modeled usin g simple box-and-arrow diagrams, pe rha ps accompa nied by a legend tha t explains the meaning of diffe ren t types of boxes and a rrows. We use this approach in our examples. As you build and evalua te real sys- te ms, you may use ano ther mo de ling technique. But the principles expressed in boxes and a rrows can easily be translated to other mode ls.

5.3 DECOMPOSITION AND VIEWS

In the past, software designers used decomposition as their primary tool, making a large problem more tractable by decomposing it into smaller pieces whose goals were easie r to address.. We ca ll this app roach " to p down ,'' because we start with the big picture and decompose it into smaller, lowe r-leve l pieces. By contrast, ma ny of to day's design ers wo rk o n the a rchitecture fro m the bottom up, packaging together small modules and components into a larger whole. Some experts think that a bottom-up approach pro duces a system that is easie r to maintain. We will look more carefull y at these maintenance issues in Chapter 11. As a rchitectural and design ap proaches change over time, and as we gathe r mo re evide nce to support claims o f maintainability and o the r qualHy characte ris- tics, we will have a bette r understanding o f the impact o f each design approach.

232 Chapter 5 Designing t h e Architecture

Some design problems have no existing solutions o r compo nents with which to start. H ere, we use decomposition, a traditio na l approach that helps the design ers unde rstand and isolate the key problems tha t the system is to solve. Because under- standing decomposition can also shed light o n the best ways to test, enhance, and main- tain an existing system, in this section, we explo re and contrast se veral decompositi on me thod s. D esign by decomposition starts with a high-level description o f the syste m's key e leme nts. The n we ite rati vely re fine the design by dividing each of the system's e le- me nts into its constitue111t pieces and describing their inte rfaces. We are done whe n fur- the r re fme me nt results in pieces tha t have oo interfaces. This process is depicted in Figure 5 .5.

H ere a re brief descriptions o f some popula r design methods:

• Functional decomposition: This method pa rtitions functions o r requirements into modules. The designer begins with the functions that are liste d in the require- ments specificati on ; these are system- le ve l functio ns that e xchange inputs and outputs with the system's e nvironment. Lower-level designs divide these func- tio ns into subfuncitio ns, which are then assigned to smalle r m odules. The design also describes which modules (subfuoctions) call each othe r.

• Feature-o riented design: This method is a type of functional decomposition that assigns fe atures to modules. The high-level d esign describes the system in terms of a service and a corn ection of features. Lower-level designs describe how each fea- ture augments the service and ide ntifies inte ractio ns among features.

• Data-oriented decomposition: This me tho d foc uses on how data will be parti- ti o ned into modules. The high-le ve l design describes conceptual data structures, and lowe r-level designs provide detail as to how data are distributed among mod- ules and how the distributed data rea lize the conceptual mode ls.

• P rocess-oriented decompositio n: This method partitions the system into concur- re nt processes. The high -level design (1) ide ntifies the system's main tasks, which

FIG URE 5.5 Level s of decomposirioo.

Openmirrors.com

fop lev·el

First level of decomposition

Second level of decomposition

Section 5.3 Decomposition and Views 233

ope rate mostly independently o f each othe r, (2) assigns tasks to runtime processes, and (3) explains how the tasks coordina te with e ach other. Lower-level designs describe the processes in mo re de tail.

• Event-o rie nted decomposition: This me thod focuses on the events that the sys- tem must h andle and assigns responsibility for events to diffe rent modules. The high-Level design catalogues the system's expecte d foput events, and lower-le vel designs decompose the system into states and describe how events trigger state trans fo rma ti ons.

• Object-oriented design: This method assigns objects to modules. The high-level design ide ntifies the system 's o bject types and explains how objects are related to one another. Lower-level designs de tail the o bj ects' attributes and operations.

H ow we choose which design method to use depends on the system we are developing: Which aspects o f the system's specificatio n are most prominent (e.g., functions, objects, features)? How is the system's interface d escribed (e.g., input events, data streams)? Fo r many syste ms, it may be appropriate to view seve ral decomposition s, or to use differe nt design me thods a t differe nt le vels of abstractio n. Some times, the cho ice of design me thod is not so important a nd may be based o n tbe designer's preferences.

To see bow decomposition works, suppose we want to follow a data-orien ted design method. We start with the conceptual data stores that were identified during requirements ana lysis. This analysis included externally visible operati o ns on these data, such as creation, que ries, modifications, a nd de le tio n. We design the system by cluste ring the conceptual data into data o bjects and o pe rations on those objects. We further decomp ose complex data objects into aggregation s of simple r objects, with the simplest objects storing one typ e of data. Each object type provides access operations fo r que rying and manipulating its data. This way, o the r parts o f the system can use the o bject's sto red information with out accessing the data directly. The resulting design is a hierarchical decomposition of objects. The design diffe rs from the requirements specifi- ca tion because it includes informatio n abo ut how system data are to be distri buted into objects and how o bjects manipulate data values, and no t just information about what data will be manipulated by the system.

No matter which design approach we use, the resulting design is likely to refer to seve ral types of software un its, such as component, subsystem, runtime process, module, class, package, library, or procedure . Tue diffe rent te rms describe diffe rent aspects of a design. For ex ample, we use the te rm module t o refer to a structural unit of the so ftware's code; a module could be an atomic unit, like a Java class, o r it could be an aggregatio n of other modules. We use the te rm component to refer to an ide ntifiable runtime ele ment (e.g., the parser is a compo nent in a compiler)-althoug h this te rm some times has a specific meaning, as explained in Sidebar 5.2. Some of the above terms designate software unjts at different levels o f a bstractio n. For example, a system may be made up of subsyste ms, which may be made up of packages, which are in turn made up of classes. In other cases, the terms may overla p and prese n t diffe rent vie ws of the sa me e ntity (e.g., a parse r might be bo th a compo oe ot and a high-Leve l module). We use the te rm software unit whe n we want to talk about a syste m's composite parts without be ing precise about wh at type of part.

234 Chapter 5 Designing the Architecture

SIDEBAR 5.2 COMPONENT-BASED SOFTWARE ENGINEERING

Co mpone nt-based software en gineering (CB SE) is a methcx:I of software development whereby systems are created by assembling togethe r preexistin g components. In this set- ting, a compone nt is " a self-contained piece of software with a well-defined set of interfaces"

(Herzum and Sims 2000) that can be developed, b oug ht, and sold as a distinct entity. The goal

of CBSE is to support the rapid development o f new systems, by reducing development to

component integration, and to ease the maintenance of such systems by reducing mainte-

nance to component replacement.

At this point, CBSE is stiU more o f a goal than a reality. There are software components for sale, and part of software design is deciding which aspects of a system we should buy off

the shelf and which we should build ourselves. But there is still considerable research being done on figuring out how to

• specify components, so that buyers can determine whether a particular component fits

their needs

• certify that a component performs as claimed

• reason about the properties of a system (e.g., reliability) from the properties of its components

We say that a design is modular when each activity of the system is performed by exactly one so ftware unit, and wben the inputs and outputs of each software unit are well-defined. A software unit is well-defined if its in terface accurately and precisely specifies the unit's externally visible behavior: each specified input is essential to the unit's function, and each specified output is a possible result of the unit's actions. In addition, " well-defined" means that the interface says nothing about any property or d esign d e tail that cannot be discerned outside the software unit. C hapter 6 includes a section on design principles that describes in more detail bow to make design decisions that result in modular designs.

Archit ectura l Views

We want to decompose the system's design into its constituent programmable units, such as modules, objects, or procedures. However, this set of elements may not be the o nly decomposition we consider. If the proposed system is to be distributed ove r sev- e ral compute rs, we may want a view of lhe design that sho ws the d istribution of the sys- tem's components as weU as bow those compone nts communicate with each other. Alternative ly, we may want a view of the design that shows the various services that the system is to offer and how the services operate togethe r, regardless of how the services are mapped to code modules.

Common types of architectural views include the following:

• D ecomposition view: This traditional view of a system's decomposition portrays the system as programmable units. As depicted in Figure 5.5, this view is likely to be

Openmirrors.com

Section 5.4 Architectural Styles and Strategies 235

hie rarchical and may be represented by multiple models. For example, a software unit in one model may be expanded in another model to show its constitue nt units.

• D e pendencies view: This view s hows dependencies among software units, such as when one unit ca.Us anothe r unit's procedures o r when one unit relies on data pro- duced by one o r more othe r units. This view is useful in project planning, to iden- tify which software units are dependency free and thus can !be implemented and tested in isolatio n. It is also useful fo r assessing the impact of making a d esign change to some sof tware unit.

• Ge nera lizatio n view: T his view shows software units that are generalizations or sp ecializa tions of one another. An obvio us example is an inheritance hierarchy among object-orie nte d classes. In general, this view is useful when designing abstract or extendible software units: the general unit encapsulates common data and functio nality, and we derive various specialized units by instantiating and exte nding the gene ral unit.

• Execution view: This view is the traditional box-and-arrow diagram that softwa re a rchitects draw, showin g the runtime structure of a system in terms of its compo- nents and connectors. Each component is a dis tinct executing entity, possibly with its own program stack. A connecto r is some intercompooent communication mechanism, s uch as a communication channel, shared data r e pository, or remote procedure call

• Imple me ntation view: This view maps code units, such as modules, objects, and procedures, to the source file that contains t he ir implementation. lhis view helps progrnm..mers find the implementation of a software unit within a maze of source- code files.

• D e ployme nt view: This view maps runtime e ntiti es, such as components and con- nectors, o nto computer resou rces, such as processors, data s tores, and communica- tion netwo rks. It helps the architect analyze the quality attributes of a design, such as pe rformance, reliability, and security.

• Work-assignme nt view: This view decomposes the system's design into w ork tasks that can be assigned to p roject teams. It helps project managers plan and aUocate project resources, as well as track each team's progress.

Each view is a model of some aspect of the system's structure , such as code struc- ture, runtime structure, file structure, o r project team structure. A system's architecture re presents the system's overall design structure; thus, it is the fu!U collection of these views. NormaUy, we do not attempt to combine views into a single integrated design, because such a descriptio n-comprising multiple overlays of different decompositioos- would be too difficult to read and keep up-to-date. Later in this chapter, we discuss h ow to document a system's a rchitecture as a collection of views. The documentation includes mappings among views so that we can understand the big picture.

5.4 ARCHITECTURAL STYLES AND STRATEGIES

Creating a software a rchitectural design is not a straightforward task. The design progresses in bursts of activi ty, with the design team often alternating between top-down

236 Chapter 5 Designing t h e Architecture

and bo ttom-up analysis. In top-down design, the team tries to partitfon the syste m 's key func tions into di stinc t m odules t hat can be assigned to separate compone nts. H owe ve r, if the te am recognizes that a known, pre vio usly implem ented d esig n solution might be useful , the team may switch to a bo ttom-up desig n approach, adapting a pre packaged solution .

O fte n, our approaches to solving som e proble ms ha ve common fe atures, and we can take advantage of the commo nality by applying gene ralized patte rns. Software archjtectural styles a re esta blished , large-scale pa tte rns o f syste m s tructure. A nalogous to a rc hitectura l st yles fo r buildings, softwa re a rc hitectural styles have defining rules, e le me nts, and techniques that result in designs w ith recognizable s tructures and well- unde rstood prope rties. H owever, styles are no t comple te de taile d solutions. Rathe r, they are loose templa tes that offer distinct solutions fo r coordinating a sys te m 's com - po ne nts. To be specific, a rchitectural styles focus o n the d iffe re nt ways that compo ne nts might communica te, syn chronize, or sha re data with o ne a nothe r. As such, their struc- tures codify constraine d inte ractio ns amo ng compo ne nts and offe r mechanisms, suc h as protocols, for realizing t!hose inte ractions. In t he e arly s tages of software develo pm ent, architectura l styles can be useful for exp lo ring and e xplo iting known a pproaches to o rganizing and coordina ting access to d ata a nd func tio nality. In gene ral, by cons tr ain- ing inte rcomponent inte ractions, a rchitectura l s tyles can be used to help the resulting syste m ac hie ve specific syste m prope rties, suc h as da ta security (by restricting d a ta flo w) and maintainabilit y (by simplifying communicatio n inte rfaces).

R esearchers are continuously a nalyzing good software designs, looking for u seful arc hitel:tural s tyles tha t can be applied mo re gene rally. These s tyles a re the n colJel:te u in style catalogues that an architect can re fe re nce whe n conside ring the best architec- ture fo r a give n set of re quire me nts. A few o f these cata logues a re listed a t the e nd of this c ha pte r.

In the rest of thi s. secti on, we e xamine six: a rchitectural styles commonly u sed in softwa re develo pment: pipe-and-filter, client-server, peer-to-p eer, p ublish-subscribe, rep ositories, and layering. Fo r each st yle, we d escribe the software e le me nts compris ing the style, the constraints on inte ractions amo ng e le me nts, a nd som e prope rties (good a nd bad) of the resulting syste m.

Pipe-and-Filter

In a pipe-and-filte r style, illustrated in Figure 5.6, syste m func tio n ality is achie ved by passing input data through a seque nce o f data-transfo rming compone nts, called filte rs, to produce output da ta . Pipes are connecto rs that simply tra nsmit data fro m on e filte r to the n ext without mo difying t he data . Each filte r is a n inde pe ndent function tha t ma kes n o assumptio ns a bout othe r fille rs tha t maiy be applied to the data.1llus, we can build o ur syste m by connecting togethe r different fi lte rs to fo rm a va rie ty of configura- tions. If the form a t o f the da ta is fixed-that is, if a U o f the filte rs and pipes assume a commo n re presentation of the d a ta being transmitted-the n we can join filte rs toge the r in any configuratio n. Such syste ms have seve ra l impo rtant prope rties (Shaw and G arlan 1996):

• We can unde rstand the syste m 's transforma tion o f input data to output data as the functional composition of the filte rs' d ata trans fo rmatio ns.

Openmirrors.com

Section 5.4 Architectural Styles and Strategies 237

KEY Pipe.

Filter

FIGURE 5.6 Pipes aad filters.

• Filte rs can be reused in any other pipe -and-filter style program that assumes the same format for input and output data. Examples of such filte rs and syste ms include image-processing systems and Unjx shell programs.

• System evolution is re latively easy; we can simply introduce new filters into our syste m's configuration , or replace or remove existing filters, without having to modHy o ther parts of the system.

• Because o f filter independe nce, we can perform certain types of anal yses, su ch as throughput analysis.

• There are pe rformance penalties when using a pipe-and-filte r arcrutecture. To support a fixed data fo rmat during data transmission, e ach filter must parse input da ta before performing its computati on and the n conve rt its results back to the fixed data format fo r output. This repeated parsing and unparsing of data can hamper syste m pe rformance. It can also make the construction of the individual filters more complex.

Io some pipe-and-filter style systems, the filte rs are independe nt data-transfo rming functio ns, but the representation o f data passed between filte rs is not fixed. For example, o ld-style compilers had pipe-and-filte r architectures in which the output of each filter (e.g., the lexical analyzer o r the parser) was fe d directly into the next filter. Because the filters in such systems a re indepe nde nt and have precise input and output fo rma ts, it is easy to re place and improve filters but hard to introduce or remove fi lters. For example, to remove a filter, we may need to substitute a stub t!hat conve rts the out- put fro m the pre vious filter into the input format expected by the n ext filter.

Client -Server

In a client-serve r arcrutecture, the design is div ided into two types of compone nts: clients and se rve rs. Server compo nents offer services, and clients access them using a request/reply protocol. The components execute concurrently and are usually distrib- uted across severaJ computers. There may be one centralized serve r, several replica ted servers distributed ove r several machines, or several distinct serve rs each ofiering a ilif- fe rent set o f services. The relationship be tween clie nts and servers is asymmetric: C lients know the identities of the serve rs fro m which they request information , but servers

238 Chapter 5 Designing the Architecture

SIDEBAR 5.3 THE WORLD CUP CLIENT-SERVER SYSTEM

In 1994, the World Cup soccer matches were held in the United States. Over a single month, 24 teams played 52 games, drawing huge television and in-person audiences. The games were played in nine different cities that spanned four time zones. As a team won a match , it often moved to another city for the next game. During this process, the results of each game were recorded and disseminated to the press and to the fans. At the same time, to prevent the likelihood of violence among the fans, the organizers issued and tracked over 20,000 identifi- cation passes.

This system required both central control and distributed functions. For example, the system accessed central information about all the players. After a key play, the system could present historical information (images, video, and text) about those players involved. Thus, a client-server architecture seemed appropriate.

The system that was built included a central database, located in 'fexas, for ticket man-

agement, security, news services, and Internet links. This server also calculated games statis- tics and provided historical information, security photographs, and clips of video action. The clients ran on 160 Sun workstations that were located in the same cities as the games and pro- vided support to the administrative staff and the press (Dixon 1996).

kno w nothing about which, o r eve n how many, clients they serve. Clients initiate oom- municatio ns by issuing a request, such as a message o r a remote-procedure call , and se rve rs respo nd by fulfill ing the request and reply ing with a result. Normally, serve rs are passive oomponents that simply react to clients' re quests, but in some cases, a serve r may initiate actions on behalf of its clients. For example, a client may send the server an e xe- cutable function, called a callback, which the serve r subsequently calls under specific cir- cumstances. Side bar 5.3 d escribes a system imple mented using the client-server style .

Be cause this architectural style separates client oode and server code into differ- e nt compo ne nts, it is possible to improve syste m pe rformance by ~hufiling the compo- nents am ong compute r processes. Fo r example, client code might execute locally o n a use r's p ersonal compute r or might execute re motely o n a more powerful server com- pute r. In a multi tier syste m, like the example shown in Figure 5.7, servers are structured hie rarchically into applicatio n-specific se rvers (th e middle tiers) that in turn use servers o ffering mo re gene ric services (the bottom tie r) (Cle ments et al. 2003). This architec- ture impro ves the syste m's modularity and gives designe rs more flexibility in assigning activities to processes. Moreove r, the clie nt-se rve r sty le suppo rts reuse, in that servers providing common services may be useful in multiple applicatio ns.

Peer-to -Peer

Technically, a peer-to-pee r (P2P) architecture is on e in whi ch each compo nent executes as its own process and acts as both a client of and a server to oth er peer compone nts. Each compo nent bas an interface that specifies n ot only the services it provide s, but

Openmirrors.com

Section 5.4 Architectur.al Styles and Strategies 239

KEV Client Preslftbtion

server

- request/ reply Business lo9io

Server

FIGURE 5.7 1bree-tiered client-server architecture.

Information System

also the se rvices that it requests fro m other peer components. Peers communica te by requesting services from each other. In this way, P2P communication is like the request/reply communicatio n found in client-server architecture, but any componen t can initiate a request to any other pee r component.

The best known P2P architectures are file-sharing networks, such as Napster and Freenet, in which the compo nents provide similar services to each o ther. What differs among components are the data each component stores locally. Thus, the system 's data are distributed among the components; whenever a component needs information not stored locally, it retrieves it from a peer component.

P2P networks are attractive hecause the y scale up we ll. Although each added compo ne nt incre ases demands o n the system in the fo rm of additional requests, it also increases the syste m's capabilities, in the fo rm of new or replicated data and as addi- tional server capacity. P2P networks are also highly tolerant of compone nt and network failures, because data are replicated and distributed over multiple pee rs. Sidebar 5.4 describes the pros and cons of Napster's P2P architecture.

SIDEBAR 5.4 NAPSTER'S P2P ARCHITECTURE

N apster. the popular music-sharing system, uses a P2P architecture. Typically, the peers are users' desktop computer systems running general-purpose computing applications, such as electronic mail clients, word processors, Web browsers, and more. Many of these user sys-

tems do not have stable Inte rnet protocol (IP) addresses, and they are not always available to the rest of the network. And most users are not sophisticated; they are more interested in

content than in the network's configuration and protocols. Moreover, there is great variation in methods for accessing the network, from slow dial-up lines t o fast broadband connections.

Napster's sophistication comes instead from its servers, which organize requests and man-

age content. The actual content is provided by users, in the form of files that are shared from peer to peer,and the sharing goes to other (anonymous) users, n ot to a centralized file server.

240 Chapter 5 Designing t h e Architecture

This type of architecture works well when the files are static (i.e. , their content does not

change often or at all), when file content or quality do not matter, and when the speed and reliability of sharing are not important. But if the file content changes frequently (e.g., stock prices or evaluations), sharing speed is key (e.g., la rge files are needed quickly), file quality is critical (e.g., photographs or video), or o ne peer needs to be able to trust another (e.g., the content is protected or contains valuable co rpo ra te information), then a P2P architecture may not be the best choice; a centralized serve r architecture may be more appro priate.

Publish-Subscribe

In a publish-subscri be archHecture, compone nts inte ract by broadcasting and reacting to events. A component expresses inte rest in an event by subscribin g to it. Then , whe n ano ther component ann ounces (publishes) th at the eve nt has take n place, the subscrib- ing compo nents are notified . The unde rlying publish-subscribe infrastructure is resp on- sible bo th fo r registering event subscriptions and fo r de live ring published events to the appropria te compone nt s. Implicit invocatio n is a common form of pubLish-subscribe architecture, in which a subscribing compone nt associa tes one o f its procedures with e ach event o f in terest (called registe ring the pro cedure). In th.is case, whe n the event occurs, the publish-subscribe infrastructure invok es all o f the event's registered proce- dures. In contrast to cLien t-server and P2P compo nents, publish-su bscribe compo ne nts kno w no thing about e ach o ther. Inste ad , the publishing co mpo nent simply anno unces eve nts a nd the n waits fo r interested components to react; each subscribing compo nent simply reacts to event a nnouncements, regardless of ho w they a re p ublished. In mod els o f this kind o f architecture, the underlying infrastructure is o fte n represented as an eve nt bus to whi ch all publish-subscribe compo ne nts are connected.

This is a common architectural style for integrating tools in a shared environ - ment. For example, Reiss (1990) rep orts o n an e nvironment ca lle d Field, where tools such as edi tors register for events that might occur d uring a debugger 's functioning. To see ho w, consider that the debugger processes code, one Line at a time. When it recog- nizes that it has reached a set b rea kpoint, it announces the event " reached brea kpoint"; tben, tbe syste m fo rwards the even t to aU registered tools, iocluding the editor, and the edito r re acts to the event by automatica lly scrolLing to the source-code Lioe that co rre- spo nds to the bre akpoin t. O ther events that the debugger might announce include e ntry and exit points of fuoctions, runtime errors, and commeots to clear or reset the program 's executio n. H owever, the de bugger is n ot aware of whi ch tools, if any, h ave registered fo r the diffe re nt events, and it has no contro l over what the o ther tools will do io respo nse to one of its even ts. Fo r this reason, a pubLish-subscribe syste m wiU often include some expLicit invocations (e.g., calls to access methods) when a compo nent wants to e nforce o r confirm a specific reaction to a critical event.

Publish-subscribe systems have severa l strengths and weaknesses (Shaw and G arlan 1996):

• Su ch systems provide strong suppo rt fo r system evolutio n and customization. Because all interactions are o rchestrated using eve nts, any pubLish -subscribe

Openmirrors.com

Section 5.4 Architectural Styles and Strategies 241

component can be adde d to the syste m and can register itself without affecting othe r compo ne nts.

• For the same reason, we can easily reuse publish-subscribe components in othe r event-drive n systems.

• Components can pass data at the time they announce events. But if components need to share persistent data , the system must include a shared repository to sup- port that inte raction. This sharing can diminish the system 's extensibility and re usability.

• Publish-subscribe syste ms are difficult to test, beca use the be havio r of a publish - ing compo nent will de pend o n which subscribing components are monjto ring its events. Thus, we cannot test the compone nt in isolati on and infe r its correctness in an integrated system.

Re p ositories

A re pository style o f arcrutecture consists of two types of compon ents: a central data sto re and associated data-accessing compo nen ts. Shared data are stockpiled in the data store, and the data accessors are computational units that store, retrieve, and update the informatio n. It is chaUenging to design such a syste m, because we must decide ho w the two typ es o f compone nts will inte ract. In a tra ditio nal d atabase, the data store acts like a server compo nen t, and the data-accessing clients request info rmation from the data sto re, pe rform calcu lations, and request that results be written back to the data store. In such a system, the d ata-accessin g components are active, in that they initiate the sys- tem's computations.

However, in the blackboard type of repository (illustrated in Figure 5.8), the data- accessing compo nents are reactive : they execute in reaction to the current contents of the data sto re. Typically, the blackboard contains information about the current state of the system's execution that triggers the e xecution of individual data accessors, called knowledge sources. For example, the blackboa rd may store computation tasks, and an idle knowledge sou rce checks a task o ut of the b lackboard, performs the computation locaUy, and checks the re sult back into the blackboard. More commonly, the blackboard stores the curre nt state o f the syste m's computatio n, and knowled ge sources detect pieces of the U10Solved proble m to tackle. For example, in a rule-based system , the current state

KEY nowle,ge $0~1C8

hlacHmd

-----e 1aad/w1ite

FIGURE 5.8 Typical blackboard.

Knowledge tourea 2

242 Chapter 5 Designing t h e Architecture

o f the solution is stored in th e blackboard , and knowledge sources iteratively revise and improve the solution by applying rewriting rules. The style is analogous to a computati on o r proof that is written on a real-world blackboard, where people (knowledge sources) ite ratively improve the write-up by walking up to the blackboard, erasing some part of the wri ting, and replacing it with new writing (Shaw and Garlan 1996).

An impo rtant prop erty of this style o f architecture is the ce ntra lized management o f the system's key data. In the data store, we ca n localize responsibility for storing p er- sistent data, managing concurrent access to the data, en forcing security a nd privacy po licies, and protecting the d ata against fa ults (e.g., via backups). A key architectural d ecision is whe ther to map d ata to mo re than o ne data sto re. Distributing or replica ting data may improve syste m performance, but o fte n the re are costs: adding complexity, kee ping data stores consiste nt, and reducing security.

Layering

Layered systems o rganize the system 's software uni ts into layers, each o f which pro- vides services to the layer above it and acts as a clien t to the layer below. In a " pure" laye red system , a softwa re unit in a given layer can access onl y the other units in the same laye r and services offered by the interface to the layer immediately below it. To improve pe rformance, this constraint may be relaxed in some cases, allo wing a layer to access the services o f la}•ers below its lower neighbor; this is called layer bridging. H ow- ever, if a design includes a lo t of layer bridging, the n it loses some o f the portability and maintainability that the layering style o ffe rs. Unde r no drcllllliitances does a layer access the services o[fered by a highe r-level layer; the resulti ng architecture would no longe r be called laye red.

To see bow this typ e of system works, consider Figure 5.9, which depicts the Open Syste ms Interconnecti on (OSI) re fe re nce mode l fo r netwo rk communicati ons (Inter- n atio nal Telecommunicatio n Union 1994). The bo ttom layer provides facilities for transferring data bits over a physical link, like a cable-possibl y unsuccessfull y. The next layer, the Data Link Layer, provides mo re complex facilities: it transmits fi xed- sized da ta fra mes, rou tes data frames to local addressa ble machines, and recovers from simple transmission errors. The D ata Link Layer uses the bottom Physical Layer 's facil- ities to pe rfo rm the actu al transmission of bits between physica Uy connected mac hines. The Ne twork Layer adds the ability to transmit variable-sized data pack ets, by bre ak- ing packets into fixed-sized data frames which are then sent using the Data Link facili- ties; tbe Ne twork Laye r also expands tbe routing o f data packets to nonlocal machines. The Transport Layer adds reli ability, by recovering fro m routing errors, such as when data frames are lost or reorde red as they a re routed (along possibly different pa tbs) through the ne twork. The Session Layer uses the Transpo rt Layer 's reliable data-transfer services to provide long-te rm communication connectio ns, ove r which len gthy d ata exchanges can take place. The Presentatio n Layer provides translatio n among diffe rent d ata represe ntations, to support da ta exchanges a mong compo ne nts tha t use diffe rent data forma ts. The Application Layer provides a pplication-specific services, such as tile transfers if the applicatio n is a file -transfer program.

In the O SI example, each layer raises the leve l o f a bstractio n of the communica- tion se rvices tha t are availa ble to the next layer, and hides all o f the de tai ls about how

Openmirrors.com

KEY

~ procefora call

_ ph1sical c1bla

Sectio n 5.4 Architectura l Styles and Strategies 243

FIGU RE 5.9 Layered architecture of OSI model for network communications.

those se rvices are implemented. In ge ne ral, the laye ring style is useful whenever we can decompose our system's functio nality into steps, each of which bui lds on pre vious st eps. The res ulting design is e asie r to po rt to othe r p latforms, if the lowest leve l encapsulates the software's interactio ns with the p latform. Mo reover, because a layer can inte ract o nly wi th its ne ighboring layers, layer modification is relative ly easy; such changes should affect at most o nly the two adjacent layers.

On the other hand , it is not always easy to structure a system into djstinct layers of increasingly powerful se rvices, especiaUy when software uruts are seemingly inter de- pe ndent. Also, it may appear that laye rs introduce a pe rformance cost from the set of calls and data transfe rs between syste m Laye rs. Fortunately, sophisticated compilers, linke rs, and loaders can reduce thjs ove rhe ad (Cle ments et al. 2003).

Co mbining Arc hitectural Styles

It is easiest to think about an architectura l style and its associated prope rties when we conside r the style in its purest form. However, actual software architectures are rarely based purely on a single style. Instead, we build our software architecture by combirting different a rchitectural styles, se lecting and adapting aspects of styles to solve particular proble ms in our design.

Architectural styles can be combined in several ways:

• We mjgbt use diffe rent styles at diffe rent levels of o ur system's decompositio n. For example, we might vie w our system's overa U structure as a client-serve r architec- ture, but subsequently decompose tbe se rver component into a se ries of laye rs. Or a simple intercomponent connection at one level of abstraction may be refine d to be a collection o f compo nents and connectors at a lower level of decomposition.

244 Chapter 5 Designing the Architecture

For instance, we might decompose one architecture's publish-subscribe inter- actions to elaborate the components and protocols used to manage eve nt subscrip- tions and to notify subscribing components of event announcements.

• Our architecture may use a mixture o f architectural styles to model differ ent components or different types of interactions among co mponents, such as the architecture shown in Figure 5.10. In this example, several client compone nts interact with each other using publish-subscribe communications. These same components use server components via request/reply protocols; in turn , the server components interact with a shared data reposito ry. In this example, the architecture integrates different styles into a single mode l by aUowing compo- ne nts to play multiple roles (e.g., client, publisher, and subscriber) and to engage in multiple types of interactions.

• Integration of diffe rent architectural styles is easier iI the styles are compatible. For example, all the styles being combined might relate runtime components, or all might relate code units. Alte rnatively, we may create and maintain diffe rent views of the architecture, as building architects do (e.g., the electrical wiring view, the plumbing view, the heatin g and air conditioning v]ew, and so on). This approach is appropriate iI integrating the views would result in an overly complex mode l, such as when components interact with each other in multiple ways (e.g., if pairs of components interact using both implicit invocation and explicit method calls), or if the mapping between the views' components is messy (i.e., is a many- to-many relationship).

If the resulting architecture is expressed as a collection of models, we must docu- me nt how tbe models re late to one anothe r. If o ne mode l simply shows the decomposi- tion of an e lement from a more abstract model, then this relationship is straightforward. If, instead , two models show differe nt views of the system, and if there is no obvious mapping between the two views' software units, th.en documenting the views' correspon- d ence is all the more important. Section 5.8 describes how to record the correspondences among views.

KEY

lttYll

tepotltoty

=jF=jf pu•ll11Vsubmlb1

- tequett/teply

~ d111b11t quules, tru11et1011

ppllcttlon 01ttbm

ppllutlon 01t1b11t

Client Applle1tlon and Prmntll Ion

SetY•Mlde Pmenlltlon

Enterprlse lnfo11utl01 Sy1t111t

FIGURE 5.10 Combination of publish-subscribe. client-seiver. and repository architecture styles.

Openmirrors.com

Sect ion 5.5 Achieving Quality Attrib utes 245

5.5 ACHIEVING QUALITY ATTRIBUTES

In Chap te r 4, we saw that software requirements are about more than the proposed system's func tionality. Othe r attribu tes, such as performance, reliability, and usability, are ca re fu ll y specified , re flecting the characte ristics that use rs want to see in the prod- ucts we build. As we d esign our syste m, we wa nt to select architectural styles that promote the required quality attributes. However, architectural style offers only a coarse-grained solution wit h generally beneficial pro perties; the re is no assurance that a specific qua lity attribu te is o ptimized. To assure the support of particular attributes, we use t actics (Bass, Cle me nts, and Kazman 2003): more fine -grained design decisions tha t can improve how weU our design achieves specific quality goals.

Mo d ifia bility

Modifiabil ity is the basis of most of the architectural styles presented in this chapter. Because more than half of the full life-cycle cost of a system-including deve lopment, proble m fixi ng, e nha ncement, and evolution-is spent after the first version of the soft- ware is d eve loped and re leased, modifiability is essen tial. That is, above all , we want our design to be easy to change. Diffe rent architectural styles address different aspects of modifiability, so we must know how to select the styles that address our specific modifi- ability goals.

G ive n a particular change to a system, Bass, Clements, and Kazman (2003) distin- guish be tween the software units that are directly affected by the cibange and those that are indirect! y affected. The directly affected units a.re those whose responsibilities change to accommodate a syste m modification. We can structure our code to minimize the num- be r o f units requiring change. The indirectly affected units are those whose respon- sibilities do not change, but whose imple mentations must be re vised to accommodate changes in the directly affected units. The difference is subtle. Both types aim to reduce the number o f altered software units, but the tactics associated with each are different.

Tactics fo r minimiz ing the number of software units directly affecte d by a soft- ware cbange focus on clustering anticipated changes in the design:

• Anticipate exp ected changes: Identify design decisions that are most likely to change, and e ncapsulate each in its o wn software unit. Anticipate d changes are no t limited to future features that the custo mer would like to see implemented. A ny service, functionality, or inte rnal check that the system performs is susce pti- ble to fu ture improveme nt or obsolescence, and as such is a candidate for fu ture changes.

• Cohesio n: We will see in Chapte r 6 that a software unit is cohesive if its pieces, data , a nd functio nality all contribu te to the unit's purpose and responsibilities. By keeping our softwa re units highly cohesive, we increase the cha nces that a change to the system's respo nsibilities is confine d to the few u nits that are assigned th ose respo nsibilities.

• Generality: Tue mo re general our software units, the more likely we can accom- modate change by mo difying a unit's inputs rathe r than modifying the unit it-self. This characte ristic is particularly true of servers, which ought to be genera l enough to accommodate all variants of requests for their services. For example,

246 Chapter 5 Designing the Architecture

an object that e ncapsulates a data structure s ho uld provide sufficient access m e thods to e nabl e other objects to easily re trieve and update data values.

By contrast, tactics for minimizing the impact on indirectly affected software units focus on r educing depe ndencies among software units. The goal is to reduce the degree to which a change to a directly affected unit a lso affects the system 's other Wlits:

• Coupling: As we di scuss in detail in Chapte r 6, the level of coup ling among software units is the degree t o which the units depend o n each othe r. By lowering coupling, we re duce the Like lihood that a change to one unit will ripple to othe r units.

• Interfaces: A software unit's inte rface reveals the unit's public requisites and responsi bi Ii ties, and hides the unit 's private design decisions. If a unit interacts with other units onJy throug h the ir interfaces (e.g., caUing public access m e thods), the n changes to o ne unit will not spread beyond the unit's boundary unJess its inte rface changes (e.g., if method signatures, precondit io ns, o r postconditions c hange).

• Multiple interfaces: A unit modified to provide new data or services can offer them using a new interface to the unit without c hanging any of the unit's existing interfaces. This way, d e pe nde ncies on the e xis ting inte rfaces a re unaffected by the ch ange.

The above tactics apply when modifiabili ty goals include reducing the cos.t of c hanging the design o r imple m e nta t ion of o ur softwar e. Another type of modiliability refe rs to our be ing able to mod if)' a system after it is r e leased , p e rhaps during set-up or o n the fty during execution. For example, the process of installing Unix o r Linux on a computer involves a complex configuration step in which many questions must be ans we re d about the compute r 's hardwa re a nd pe riphe ra l d e vices to be suppo rted , and which libraries, tools, application software, a nd versions of softwar e a re to be installe d. Sidebar 5.5 describes a tactic, called self-ma naging, whe re the so ftware changes o n the fiy in response to changes in its e nvironment.

SIDEBAR 5.5 SELF-MANAGING SOFTWARE

In response to increasing demands that systems be able to o perate optimally in diffe rent and sometimes changing environments, the software community is starting to experiment with self-managing software. It goes by several names (suc h as autonomic, adaptive. dynamic, self-

configuring, self-optimizing. self-healing, context-aware), but the essential idea is the same: that the software system monitors its environment or its own performance, and changes its behavior in response to changes that it detects. That is, as its e nvironme nt changes, the system may change its sensors. H ere are some examples:

• Change the input sensors used , such as avoiding vision-based sensors when sensing in

the dark.

• Change its communication protocols and interprotocol gateways.. such as when users, each with a communication device, jo in and leave an e lectronic meeting.

Openmirrors.com

Section 5.5 Achieving Quality Attributes 247

• Change the Web servers tha t are queried, based on the results and performance of past

queries.

• Move running components to different processors to balance processor load or to recove r from a processor failure.

Self-managing soft ware sounds ideal, but it is not easy to build. Obstacles include:

• Few architectural styles: Because self-managing software so strongly emphasizes context- dependent behavior, its design tends to be application specific, which caUs for significant innovative design. If there were more general architectural styles that supported self-

managing software, it would be easier to develop such software more rapidly and reliably.

• Monitoring nonfunctional requirements: Autonomic goals tend to be highly relate d to nonfunctional requirements. Thus, assessing how well the system is achievin g these goals means that we have to relate the goals to measurable characteristics of the sys- tem's execution, and the n monitor and dynamically evaluate these characteristics.

• Decision making: The system may have to decide whether to adapt on the basis of incom- plete informatio n about itself or its environment. Also, the system should not enter a perpe tua l state of adaptation if its environment Huctuates around a tt:hreshold point.

Performance

Pe rfo rmance att ributes describe constraints o n system speed and capacity, including:

• Response tim e: How fast does o ur software respond to requests? • Throughput: How many requests ca n it process per minute? • Load: How many users can it support be fore response time and throughput start

to suffer?

The obvious tactic fo r improving a syste m's pe rformance is increasing computing resources. Tha t is, we cam bu y faster computers, more me mory, or additional communi- ca tio n bandwidth. However, as Bass, Clemen ts, and Kazman (2003) explain, there are a lso software design tactics that can improve system performance.

One tactic is improving the utilization of resources. For example, we can make our software more concurre nt, thereby increasing the number of re quests that can be processed at the same time. This approach is effective if some resources are block ed or idle, waiting fo r o the r computatio ns to finish. For instance, multiple ATMs ca n simulta- neously gathe r informa tio n about customers' banking requests, authenticate the cus- to me rs' identification info rmatio n, and confirm the requested tr ansactions with the custo me rs, be fo re forwardi ng the requests to one of the bank's servers. ln this design, the serve r receives o nly authenticated and confirmed requests, which it can process without furthe r inte ractio n with the customer, the reby increasing the serve r's through- put. Ano the r o ptio n is to replicate and distribute shared data, the reby reducing con- tention for the data. However, if we replicate data , then we must also introduce mechanisms to keep the distributed copies in synch. The ove rhead of keeping data

248 Chapter 5 Designing the Architecture

copies consiste nt must be more than offset by tbe performance improve ments we gain from reducing data conte ntio n.

A second tactic is to manage resource allocatio n more effective ly. That is, we sbo uld decide care fully h ow competing requests for resources are granted access to tbe m. C rite ria for a llocating resources include minimizing response time, maximizing tbroughput, maximizing resource utilization , favoring high-priority or urgent requests, and maximizing fairness (Bass, Cleme nts, and Kazman 2003). Some common sched- uling policies are given below.

• First-come/first-served: Requests are processed in the o rde r in wbich they are rece ived. This policy e nsures that all requests are eventually processed. But it also means that a high -prio rity request could be stuck waiting for a lower-prio rity request to be serviced.

• Explicit priority: R equests are processed in o rder of tbeir assigned pri orities. Tbis po licy ensures that important requests are handled quickJy. H owever, it is p os- sible for a low-prio rity request to be delayed forever in favor of new bigb-priority requests. One remedy is to dynamically .increase the priority of delayed requests, to en sure that they are eventually sch eduJed.

• Earliest deadline first: Requests are processed in order of their impending dead- lines. Tbis po licy ensures tbat urgent requests are handled quickly, thereby help- ing the system mee t its rea l-time de adlines.

lbe a bo ve policies assume tbat once a request is s.chedule d for se rvice, it is processed to comp le tion. A lte rnatively, the syste m ca n inte rrupt an executing re quest. For example, a lowe r-p riority request can be preempted in favor of a higber-priority request , in which case the pree mpte d request is resche duJed for completion. Or we ca n use round robin scheduling that allocates resources to requests for fixed time inte rvaJs; if a request is no t completely se rviced witbin tbis time pe riod, it is preempte d and the uncomple ted portion is rescheduJed. H ow we cboose from among these scbeduling policies de pends e ntire ly on what pe rformance property the customer wants to o ptimize.

A tbird tactic is to reduce de mand for resources. At first glance, this approach may seem unhe lpful, because we may have no control over inputs to our software. Howe ver, we can some times reduce de mand on resources by making our code more efficient. Be tte r ye t, in some syste ms, we may be able to se rvice o nl y a fraction of the inputs we receive. For e xample, if some of tbe system inputs are sensor data rather than requests for service, our software may be able to sample inputs at a lower frequency without the system's missing important changes in the sensed environment.

Security

Our cho ice o f architectural style has a significant impact on our ability to implem ent security require me nts. Most security re quirements describe what is to be protected and from whom; the protection needs are o ften discussed in a threat mode l, which casts each need in terms of the possible threats to the system and its resources. It is the arcbi- tecture that describes how the protectio n should be achieved.

There are two ke y arcbitecturaJ characte ristics that are particularly relevant to security: immunity and resilience. A system h as high immunity if it is able to thwart an

Openmirrors.com

Section 5.5 Ac hieving Quality Attributes 249

a tte mpted attack. It bas high resilience if it can recover q uickJy and easily from a suc- cessful attack. The a rchitecture e ncourages immunity in several ways:

• ensuring that all security features are included in the design

• minimizin g the security wea knesses that migh t be exploited by an attacker

Likewise, the architecture encourages resilience by

• segmenting the functi onality so that the e ffects o f an attack can be contained to a smaU part of the system

• enabling the system to quickly restore functionality arnd performance in a s ho rt time

Thus, seve ral, more ge neral qua lity characte ristics, such as redundancy, contribute to the a rchitecture's sec urity.

A fuU discussio n of securit y architectures is beyond the scope o f this book; fo r a de tailed discussion, see Pfieeger and Pfteege r (2006), wh ere the archi tectural discus- sio ns are based o n type o f a pplicati on, such as ope rating system, database, or user inte r- face. No matter the application, some architectural styles, su ch as layering, are well-suited for any kind o f security; they inherently ensure that some objects and processes ca nno t inte ract with oth er o bj ects and processes. O the r styles, suclb as P2P, are m uch mo re di ffi- cult to secure.

Jo hnson, McGuire, and Wi lley (2008) investiga ted j ust how insecure a P2P net- work can be. They point out that this type of architecture is at le ast 40 years old: the U.S. D epartment o f D efense deve lop ed the Arpan et as a P2P system:

TCP/IP, introduced in 1973, cemented the notion of direct host-to-host communication, with the ne two rk handling the mechanics of guiding the p ackets to the ir d estination . Most of the protocols created since then (HTTP, SMTP, DNS, etc.) build on the idea that a host that needs data connects directly to the host that has it, and that it is the netwo rk's task to e nable this. The techniques used by P2P file-sharing networking systems are s imply a n evo - lutio n of these principles.

Although a P2P ne twork h as advantages such as replication and redundancy, the under- lying design encourages data sharing even whe n the da ta are not intended for open view.

To see ho w, consider that a typical P2P network involves use rs who place share- a ble items in a d esignated fo lde r. You may t hin.k that a ca re f11I user's files would be safe. But the re are many ways tha t da ta are uninte ntionally shared:

• TI1e use r accide ntall y s hares files or folders containing sensitive info rma tio n.

• Files o r da ta are misplaced.

• The use r inte rface may be confusing, so the user does not realize th at a file is being shared. Good and Kreke Ibe rg (2003) found tbe KaZaA system to have this problem.

• Files o r da ta a re poorly organized.

• The user re lies on software to recognize file or data types and make tbe m available, and the software mistakenly includes a file or data that should ha ve been protected .

• Ma licio us software shares files or folders witho ut the user's knowledge.

Indeed, Krebs (2008) describes how an investment furn employee used his company computer to pa rticipate in Lime Wire, an online P2P file-sharing network fo r people

250 Chapter 5 Designing the Architecture

trading in music and videos. In doing so, he inadvertently exposed his firm's private files. These files include d the names, dates of birth, and Social Security numbers for 2000 of the firm's clients, among whom was a U.S. Supreme Court Justice! The bead of Tiversa, the company hired to help contain the breach said, "such breaches are hardly rare. About 40 to 60 percent of all data leaks take place o utside of a company's secured network, usually as a result of employees or contractors installing file-sharing software on company computers" (Krebs 2008). Leaked often are files containing confidential company plans o r designs for new products. So architectural considerations sho uld address both conventi ona l a nd unconventional uses of the syste m being developed.

Reliability

Sidebar 5.6 warns us that software safety should not be taken for granted. That is, we need to be diligent in our design work , anticipating fa ults and handling them in ways that minimize disruptio n and maximize safety. The goal is to make our software as fault-free as possible, by building fault prevention and fault recovery into our designs. A software system or unit is reliable if it correctly performs its required functions under assumed conditio ns (IEEE 1990). In contrast, a system or unit is robust if it is able to function cor- rectly "in the prese nce of invalid inputs or stressful environment conditions" (IEEE 1990). Tbat is, reliability has to do with whether o ur software is inte rnally free of e rrors, and robustness has to do with how well our software is able to withstand errors or sur- prises from its environment. We discuss tactics for robustness in the next section.

SIDEBAR 5.6 THE NEED FOR SAFE DESIGN

How safe are the systems we are designing? The re ports from the field are difficult to inter-pret. Some systems clearly benefit from having some of their functions implemented in software instead of hardware (or instead o f leavin g decisions to the judgment of the people who are controlling them). For example, the automobile and aviation industries claim that large numbers of accidents have been prevented as more and more software is introduced into control systems. H owever, other evidence is disturbing. For instance, from 1986 to 1997,

there were over 450 reports filed with the U.S. Food and Drug Administration (FDA) detail- ing software defects in medical devices, 24 of which led to death or injury (Anthes 1997). Rockoff (2008) reports that the FDA established a software forensics unit in 2004 after it

noticed that medical device makers were reporting more and more software-based recalls. The reported numbers may represent just the tip of the iceberg. Because reports to the

FDA must be filed within 15 days of an incident, manufacturers may not yet have discovered the true cause of a failure when they write their reports. For instance, one reported battery failure was ultimately traced to a software flaw that dr ained it. And Leveson and Turner

(1993) describe in great detail the user-interface design problems that led to at least four deaths and several injuries from a mal functioning radiation therapy machine.

The importance of software design is becoming evident to many organizations that were formally unaware of software's role. Of course, design problems are not limited to medical

Openmirrors.com

Section 5.5 Achieving Quality Attributes 251

devices; many developers take special precautions. The Canadian Nuclear Safety Commission recommends that all " level 1" safety-critical software running in nuclear power plants be spec- ified and designed using formal (i.e., mathematical) notations, " so that the functional analysis can use mathematical methods and automated tools" (Atomic E nergy Control Board 1999). And many groups at Hewlett-Packard use formal inspections and proofs to eliminate faults in the design before coding begins (Grady and van Slack 1994).

Anthes (1997) reports the su ggestions of Alan Barbell, a project manager at Environ-

mental Criminology Research, an institute that evaluates medical devices. Barbe ll notes that software designers must see directly how their products wilJ be used , rather than re ly on sales- people and marketers. Then the designers can build in preventative measures to make sure that their products are not misused.

How do faults occur? As we saw in Chapte r 1, a fault in a softwa re product is the result o f some human error. For e xampl e, we might mi sunde rsta nd a user-inte rface requireme nt and cre ate a design that reflects our misunderstanding. Tue d esign fault can be propagated as incorrect code, incorrect instructions in the user manual, o r incor- rect test scripts. Io this way, a single e rror can generate one o r more faults, in o ne or more deve lopment products.

We distinguish faults from failures. A failure is an observable de parture of the sys- tem fro m its required behavior. Failures can be discovered both before and after system delivery, because they can occur in testing as we ll as during operation. In some sense, faults and failures refe r respectively to invisible and visible Haws. In other words, faul ts represent tlaws that only d evelopers see, whereas failures are problems tha t users or customers see.

It is important to realize that not every fault corresponds to a failure, since the conditio ns unde r which a fault manifests itself as an o bservable failure may ne ver be me t. Fo r example, fault-containing code may neve r be executed or may not exceed the boundaries o f correct be havior (as with Ariane-4).

We make our software more reliable by preventing or tole rating faults. That is, rathe r than waiting for the software to fail and then fixing the problem , we anticipate what might happe n and construct the system to re act in an acceptable wa y.

Al.1ivc Fa ult Detection. Whe n we design a system to wait until a failure occurs during executio n, we are practicing passive fault detectiom . Ho weve r, if we periodicaUy check for symptoms of faults, or try to anticipate when failure s will occur, we are pe r- forming active fault detection. A common method for det ecting faults within a process is to ide ntify known exceptions-that is, situations that cause the system to deviate from its desired be havior. Then, we include exception h andlin g in our design, so that the syste m addresses e acb exception in a sati sfactory way and returns the system to an acceptable state . Thus, for each service we want our system to provide, we iden tify ways it may fail and ways to de tect that it has faile d. Typical exceptions include

• failing to provide a service • providing the wrong service

252 Chapter 5 Designing t he Architecture

• corrupting data • violating a system invariant (e.g., security proper ty)

• deadlocking

Fo r example, we can de tect data problems by identifying relatio nships or inv ariants tbat sbo uld ho ld among data values and checking reguJarly at runtime tbat tbese invari- ants still hold at runtime. Sucb checks can be e mbedded in the same code that manipu- la tes the data . We say more in Cha pter 6 about ho w to use exce ptions a nd exception h andLing e ffectively.

Ano ther approach to active fault detectio n is to use some form of redundancy and then to check that the two techniques agree. Fo r example, a data structure can include both forward and b ackward pointers, and tbe program can ch eck that paths tbrough the data structure are consistent. Or an accounting program can add up aJJ the rows and the n aU o f the columns to veri fy that the totals are ide ntical. Some systems go so far as to provide, and con tinuously compare, multiple versions o f the whole system. The theory behind this approach, called n-versio 111 progra mming, is that if two function- ally e quiva lent systems are design e d by two different design teams at two diffe rent times using different techniques, tbe chance of the same fauJt occurring in both imple- mentations is very small. Unfortunately, n-version programming bas bee n sh own to be less reliable than originally thought, because ma ny designers learn to design in simil ar ways, using similar design patterns and principles (Knight and Leveson 1986).

In other systems, a second computer, running in parallel, is used to monitor the progress and health of the primary system. The second system interrogates the first, examining the system's data and processes, looking for signs that might indicate a prob· le m. For instance, the second syste m may fi nd a process that has no t been scheduled for a long pe riod of time. This symptom may indicate that the ftrst sys te m is "stuck" som e- where, looping through a process or waitin g for input. O r the system may find a block of storage that was allocated and is no longer in use, but is not yet on the list of avail able blocks. Or tbe second system may discover a communication Line that has not b een re leased at the end of a rt:ransmission. If the second system canno t directly examine the first system 's data or processes, it can instead initiate diagnostic tra nsactions. This tech - nique involves having the second system generate false but benign transaction s in the first compute r, to determine if the first syste m is work ing properly. For example, the sec- ond system can open a communicati on cha nnel to the first, to e nsure that the first sys- tem stil 1 responds to suc!h requests.

Fault Recovery. A detected fault must be handled as soon as it is discovered, rathe r t han waiting until processing is comple te. Such immediate fault handling he lps to Limit the fa uJt's damage, rather than allowing the fa uJt to become a failure and create a trail of destruction. FauJt-recovery tactics usuanJy involve some overhead in keeping the system ready fo r recovery:

• Undoing transactions: The system manages a seri es o f actions as a single transacti on that eithe r executes in its entire ty, or whose partial e ffects are easily undone if a fault occurs midway through the transaction.

• Checkpoint/rollback: PeriodicaUy, or afte r a specific o peration, the software records a checkpoint of its curren t state. If the system subsequently gets into

Openmirrors.com

Section 5.5 Achieving Quality Attributes 253

trouble, it " roUs" its execution back to this recorde d state, and re applies logged transactions that occurred since the checkpoint.

• Backup: The syste m automatically substitutes the faulty unit with a backup unit. In a safe ty-critical syste m, this backup unit can run in parallel with the active unit, processing e ve nts and transactions. Thjs way, the b ackup is read y to take over for the active unit at a moment's notice.Alternative ly, the backup unit is bro ught on-line only whe n a failure occurs, which means that the backup needs to be brought up-to-speed on the current state of the system, p ossibly by using check- points and logged transactions.

• Degraded service: The system re turns to its previo us slate, perhaps using check- po ints and roUback, and the n o ffe rs some degrade d versio n of the ser vice.

• Correct an d continue: If the monitoring software detects a problem with data con- sistency o r a stalled process, it may be easier to treat the sympto ms rather than fix the fault. For example, the software may be able to use re dundant informatio n to infe r ho w to fix data errors. As anothe r example, the syste m may te rmi nate and restart hung processes. Te lecommunications systems ope rate this way, dropping bad connections with the e xpectation that the customer can re initiate the call. In this manne r, the integrity of the overall system takes preceden ce ove r any individ- ual call that is placed.

• Report: The system returns to its previous state and rep orts the problem to an exception-handling unit. Alternatively, the syste m ma y simply no te the existence of the failure, and reco rd the state of the system at the time the fail u re occurred . It is up to the deve lopers or mruntainers to return to fix the problem hiter.

The criti cality o f the system dete rmjnes which tactic we choose. Some times it is desir- able to sto p system executio n when a fault affects the system in some way (e.g., when a failure occurs). It is much easier to find the source of the proble m if system processing ceases abruptly on detecting a fault than if the system continues executing; continuing may produce othe r e ffects that bide the underlying fault, o r may overwrite critica l data and program state info rmatio n needed to locate the fault.

Other times, sto pping syste m e xecution to correct a fault is too e xpensive, risk y, or inconve nie nt. Such a tactic would be unthinkable for software in a me dical device o r a viatio n syste m. Inste ad, our soft ware must mirumize the damage done by the fa ult and then ca rry o n with little disruptio n to the users. For example, suppose software controls several equivale nt conveyor be lts in an assembly line. If a fault is de tected o n o ne of the be lts, the system may sound an aJarm and reroute the mate rials to the othe r belts. When the de fective belt is fixed, it can be put back into production. This approach is certainly pre fe rable to sto pping producti o n completely until the de fective belt is fixe d. Similarly, a banking system may switch to a backup processor o r make duplica te copies o f da ta a nd transactio ns in case o ne process fa ils.

So me fault-recovery tactics rely on the ability to predict the locatio n o f faults and the timing o f failures. To build workarounds in the system design , we must be able to guess what might go wrong. Some faults are e asy to anticipate, but more comple x sys- te ms are more difficult to analyze. At the same time, complex systems are mo re Likely to have significant faults. To make matte rs worse, the code to implement fault de tectio n and recovery may itseli contain faults, whose presen ce may ca use irrepara ble damage.

254 Chapter 5 Designing the Architecture

Thus, some fault-recovery strategies isolate areas of Likely faults rather than pre dict actual faults.

Ro bustness

When we learn to drive a car, we are told to drive defen sively. That is, we not onJy m ake sure that we follow the driving rules and laws, but we also take precautions to avoid accide nts that mi ght be caused by proble ms in our surroundings, such as road condi - tio ns and othe r vehicles. In the same way, we sho uld design defe nsively, trying to antici - pate e xternal facto rs tha t might lead to proble ms in our software. Our system is said to be robust if it includes mechanisms for accommodating or recovering from proble ms in the e nviro nme nt o r in o ther units.

D e fe nsive designing is not e asy. It re quires diligence. For example, we may foUow a policy of mutual s uspicion , where e ach software unit assumes that the other units con- tain fauJts. In this mode, each unit checks its input for correctness and consistency, and tests that the input satis fies the unit's preconditions. Thus, a payroll program wo uld e nsure that hours_worked is no nnegative before calculating an employee's pay. Simi- larly, a ch ecksum, guard bit, o r parity bit included in a data stream can warn the system if input data are corrupted. In a distributed system , we can check the he alth of rem ote processes and the communicatio n ne twork by pe riodicaJly issuing a "ping" and check- ing that the processes answer within an acceptabl e time frame. In some distributed sys- tems, multiple computer s pe rform the same calculation s; the space shuttle operate s this way, using five duplicate computers that vote to dete rmine the next o peration. lbis approach is different from n-version programming, in that all of the computers run the same software . Thus, this redundancy will not ca tch logic errors in the softwa re, but it wiU overco me hardware failures and transient errors caused by radiation. A s we will see late r in this chapte r, we can use fault-tree analysis and failure -mode analysis to h elp us identify pote ntia l hazards that our software must detect and recover from.

R o bustness tactics for de tecting faults diffe r from reliability tactics because the source of problems is different. That is, the problems are in our software's environment rather than in o ur o wn software. H owever, the recovery tactics are similar: our software can rollback the syste m to a checkpoint state, abort a transaction , initiate a backup unit, pro vide reduced se rvice, co rrect the symptoms and continue processing, or trigger an e xception.

Usability

Usability attributes re tlect the ease with which a user is able to operate the system. Most aspects o f use r-inte rface design are about how information is presented to and collected from the use r.111ese design decisions tend not to be architectural , so we post- pone a d e tailed discussio n of this topic until the n ext chapter. H owever, there are a few user-interface decisions that do significantly affec t the software's architecture, and they are worth me ntioning he re .

First and fore most, the user inte rface should reside in its own software unit, or possi- bly its o wn architectural Jaye r. lbis separation makes it easier to customize the user inter- face for diffe rent audiences, such as users of diffe re nt nationalities or different abiJHies.

Openmirrors.com

Section 5.5 Achieving Quality Attributes 255

Second, there are some user-initiated commands that require architectural support. These include generic commands such as cancel, undo, aggregate, and show multiple views (Bass, C lements, and Kazman 2003). At a minimum, the system needs a process that lis- te ns for these commands, because they could be generated at any time, unlike user com- mands l hal are input in response to a system prompt In additi on, for some of these commands, the system needs to prepare itself to receive and execute the command. For e xample, for the undo command, the system must maintain a chain of pre vious states to which to return. Fo r the show multiple views comma nd , the syste m must be able to present multiple displays and keep them up-lo -date and consistent as data ch ange. In general, the design should include facilities fo r de tecting and responding to any expecte d user input.

Third, the re are some system-initiated activities for which the system should main- tain a mode l o f its e nviro nment. TI1e most obvious examples are time-activated activiities that occur at defined tiroe inte rva ls or on specified dates. For examjple, a pacemaker can be configured to trigger a hea rtbeat 50, 60, or 70 times a minute, and an accounting system can be set up to gene rate mo nthly paychecks o r bills automatically. The system must track the passage o f time o r days to be able to initiate such time -sensitive tasks. Similarly, a process-control system, such as a system that moniitors and controls a che mical reaction , will maintain a model o f the process being controlled, so that it can make informed d eci- sions abo ut ho w to react to particular sensor input. If we encapsula te the model, we will be bette r able to replace this softwa re uni t when new modeling technologies are invented , o r to tailo r the model for diffe rent applications or custo me rs.

Business Goals,

The sys tem may have qua lity attributes tha t it is expected to exhi b it. In a ddition, we or o ur custo mers may ha ve associated business goals that are important to achieve. The most common o f these goals is mi nimizing the cost of development and the time to m ar- ket. Such goals can ha ve major e ffec ts on our design decisions:

• Buy vs. build: It is becoming increasingly p ossible lo buy majo r components. In addition to saving development time, we may actually save money by buying a component rathe r than paying o ur empl oyees to build it. A purchased component may also be mo re re lia ble, especially if it has a hfatory and h as been tested o u t by ot he r users. O n the o the r band , using a third-pa rty or existing component places constraints o n the rest o f our design, with respect to h ow the architecture is decomposed and wha t its interfaces to the compo nent look like. It can also make our system vulnerable to the availability of the compone nt's. supplier, and can be di sastrous if the supplie r goes o ut o f business o r evolves the compon ent so that it is no lo nger compatible with o ur hardware, software, o r needs.

• Initial develop ment vs. m aintenance costs: Many of the arc!hitectural styles and tactics that promote modifiability also increase a design's comple xity, and thus incre ase the system's cost. Because more than half o f a system 's to ta l development costs are incurred after the first version is released , we can save money by making our syste m mo re modifiable. However, increased complexity may delay the system's initia l re lease. During this de lay, we collect no pa yment fo r our product, we risk losing ma rket sha re to o ur competitors, and we risk our reputatio n as a relia ble

256 Chapter 5 Designing the Architecture

software supplier. Thus, for each system that we build, we must evaluate the trade- o ff be tween early delive ry and easie r mainte nance.

• New vs. known technologies: Ne w techno logies, architectural styles, and compo- ne nts may require ne w expertise. Past examples of such technological bre ak- thro ughs include o bject-oriented programming, middleware tec hn ologies, and op en -systems standards; a more recent example is the prevalence o f che ap multi- processors. Acquiring expertise costs mo ne y and delays product rele ase, as we eithe r learn how to use the ne w techno logy or hire new per sonne l wh o alrea dy ha ve that knowled ge. EventuaUy, we must develop the expertise ourselves. But fo r a give n project , we must decide whe n and h ow to pay the costs and reap the be ne fits o f applying new technology.

5.6 COLLABO RATIVE DESIGN

No t aU design questions are technical. Many are sociological , in that the design of soft- ware syste ms is usuaUy performed by a team of de velopers, rather than by a single per- son. A design team works coUaboratively, ofte n by assigning different parts o f the d esign to vario us p eople . Seve ral issues must be addressed by the team , including who is best suited to design e ach aspect o f the system , how to docume nt the design so lthat e ach te am me mbe r unde rstands the designs of others, and how to coordinate the result- ing soft ware units so that they work we U when integrated together. The design te am must be aware o f the causes o f design bre akdown (Sidebar 5.7) and use the te am's s tre ng ths to address the m.

SIDEBAR 5.7 THE CAUSES OF DESIGN BREAKDOWN

Guindon, Krasner, and Curtis (1987) studied the habits of designers on 19 projects to de termine what causes the design process to break down. They found three classes of breakdown: lack of knowledge, cognitive limitations, and a combination of the two.

The main types of process breakdown were

• lack of specialized data schemas

• lack of a meta-schema about the design process, leading to poor allocation of resources

to the various design activities

• poor prioritization of issues, leading to poor selection of alternative solutions

• difficulty in considering all the stated or inferred constraints in defining a solution

• difficulty in performing mental simulations with many steps or test cases

• difficulty in keeping track of and returning to subproblems whose solution has been

postponed

• difficulty in expanding or merging solutions from individual subproblems to form a

complete solution

Openmirrors.com

Section 5.6 Collaborative Design 257

One of the major problems in pe rforming coUaborative design is addressing dif- fe rences in pe rsonal exp erie nce, understanding, and preference. Another is that people sometimes behave differe ntly in groups from the way they behave individuaUy. For example, Japanese software developers are less likely to express individual opinions when working in a gro up, because they value teamwork mo re than they value individ - ual work. Harmony is ve ry important, and junior personnel in Japan defe r to the opin- ions of the ir more senior colleagues in meetings (Ishii 1990). Watson, H o, and Raman (1994) fo und a similar s ituatio n when they compared groupware-supported mee ting behavior in the United States to that in Singapore . ParaUe l communication and anony- mous information exchange we re important for the American groups, but were not as impo rtant for the Singaporean groups, who valued harmony. In cases su ch as these, it may be desirable to design using a groupware tool, where anonymity can be preserved. Indeed, Valacicb et al. (1992) report that preserving anonymity in this way can enhance the group's overall performance. There is a trade-off, however. Anonymity in some groups can lead to diminished responsibilities for individuals, leading the m to believe that they can get away with making fewer contributions. Thus, it is impo rtant to view the group interactio n in its cultural and ethi cal co ntexts.

Outsourcing

As the software industry see ks to cut costs and improve productivity, more software development activities wiU be outsourced to other companies o r divisions, some of which may be located in other countries. In such cases, a collaborative design team may be distributed around the world, and the importance of understanding group behavio r will increase.

Yo urdo n (1994) ide ntines four stages in tltis kind of distributed deve lopment:

1. In the first stage, a project is pe rformed at a single site with on-site developers from foreign countries.

2. In the second stage, on-site analysts determine the system 's requirements. Then , tbe require me nts a re provided to off-site groups of develope rs and programmers to continue development.

3. In the third stage, o ff-site developers build gene ric products and components that are used worldwide .

4. In the fourth stage, the off-site deve lope rs build products that take advantage of their individual areas of expe rtise.

Notice that this model conflicts with advising designers to shuttle a mong requireme nts a na lysts, teste rs, and coders, in o rde r to e nha nce everyone's unde rstanding of the sys- te m to be deve loped. As a developme nt team advances through the stages of Yourdo n 's model, it is like ly to e ncounter problems at stage 2, whe re communicatio n paths must remain open to support an ite rative design process.

Time zone differences and unstable Inte rnet connections are just some of the challe nges that ca n make it difficult fo r a distributed design team to coordinate its efforts. Yourdon (2005) bas studied the trends and e ffects of o utsourcing knowledge- based work, and he reports that distributed team& often use different development pro- cesses. Outsourced subteams are more likely to be staffed with junior developers who

258 Chapter 5 Designing t he Architecture

e mploy current best practices, whe reas more mature subteams tend to use older me thod s that have proven effective o n past projects. This mismatch of processes can be a source of contention. Also, outsourced subteams, esp eciaUy thos.e that work offshore (i.e., in another country), are less likely to know local business rules, customs, and laws.

Communication among distributed team membe rs can be e nh anced using no tes, prototypes, graphics, and other aids. However, these expLicit representations of the requirem e nts and design must be unambiguous and capture all o f the assumptions about how the system should work. Polanyi (1966) notes that intentio ns cannot be spec- ified fully in any language; some nuances are not o bvio us. Thus, communication in a group may break down when an informatio n reci pient inte rpre ts information in te rms of his or her unde rstanding and context. Fo r example, in person, we convey a great deal of information using gestures and facial expressions; this type of information is lost whe n we are collaborating e lectronically (Kra uss and Fusse ll 1991).

This difficulty is compounded when we communicate in more than on e language. For example, the re are hundreds of words to describe pasta in ItaLian , and Arabic has ove r 40 words for camel. It is extreme ly difficult to translate the nuances embedde d in these differe nces. Indeed, Winograd and Flo res (1986) assert that complete translati on from on e natural language to another is impossible, because the semantics of a natural language cannot be defined formally and comple te ly. Thus, a maj or ch alle nge in pro- ducing a good software design is reaching a shared understanding among groups of p eople who may view th e system and its e nvironment in very diffe rent ways. Th.is chal- lenge derives n ot just from "the comple xity of technical problems, but [also] because of lhe social inte racti on when users and system de ve lope rs learn to create, develop and express their ideas and visions" (Greenbau m and Kyng 1991).

5.7 ARCHITECTURE EVALUAT ION AND REFINEMENT

D esign is an iterative process: we propose some design decisions, assess wheth er they are the ri ght decisions, p erhaps make adj ustme nts, and propose more decisions. In thi s section, we look at several ways to evaluate the cllesign , to assess its quality and to gain insight into how to improve the design before we implement it. These techniques evalu- ate the design according to how well it achieves specific quality a ttributes.

M easuring Design Quality

Some researchers are developing metrics to assess certain key aspects of design quality. For example, Cbidamber and Kemerer (1994) have proposed a gene ral se t of metrics to apply to object-orie nted systems. Briand , Mo rasca, and Basili (1994) h ave propos.ed me trics fo r eva luating high -level design, including cohesion and coupLing, and Briand, D evanbu, and Melo (1997) build o n those ideas to propose ways to measure coupling.

To see bow these measurements reveal info rma tion about the design, con sider the latter group's coupling metrics. Briand et al. mote that coupling in C++-Like design can be based on three different characteristics: relatio nships be tween classes (e.g., frie ndship, inhe rita nce), types of inte ractions betwee n classes (e.g., class-attribute interaction , class-method interaction, method-me thod interaction), and the loci of rip- ple effects due to design ch anges (i.e., whethe r a change Hows to ward or away from

Openmirrors.com

Section 5.7 Architecture Evaluation and Refinement 259

a class). For each class in a design, they defined metrics that count the interactions be tween the class and other classes or methods. The n, using empirical informartion about the design for a real system and the resullting system 's faults and failures, they analyzed the relationship be tween the type of coupling and the kinds of faults that were found. Fo r exa mple, they report tha t when a class d epended on a large numbe r of attributes that belonged to other classes that were not ancestors, d escendants, or friends of that class, the n the resulting code was more fault prone than usual. Similarly, when many me thods belo nging to friend classes depended on the me thods of a par- ticular class, the n that class was mo re fault prone. lo th.is way, d esign information can be used to predict which parts o f the softwa re are most likely to be problematic. We can take steps during the design stage to build in fault prevention or fault tole rance, and we can focus more of o ur initial testing efforts on the most fault-prone parts of the design.

Safety Analysis

We learned ea rlier about the importance of fault identification, correction, and to le rance in creating reliable and robust designs. There are several techniques that can be used dur- ing design to identify possible faults o r their likely locations. Fault-tree analysis, a method originally developed for the U.S. Minuteman missile program, he lps us to examine a design and look for fa ults that might lead to failure. We build fault t rees that trace back- wards through a design, along the logical path from e ffect to cause. The trees are then used to help us decide which faults to correct o r avo id, and which faults to tolerate.

We begin our analysis by ide ntif-ying possible failures. Although our identificail:ion takes place during design , we consider failures that might be affect ed by design , opera- tio n, o r even mainte nance. We can use a set of guidewords to help us understand h ow the system might deviate from its intended behavior. Table 5.1 illustrates some of the guidewords that might be used; you can select your own guidewords or checklists, based on your system 's application domain.

Ne xt, we build an upside-do wn tree whose root node is some failure that we want to analyze, and whose other nodes are events or faults that realize or le ad to the root no de's fail ure. The edges of the graph indicate the relationships among n odes. Parent nodes aire drawn as logic gate operators: an and-gate if both of the child nodes' events must occur for the parent node's event to occur; a n or-gate if o ne chjld's event is suffl - cient to cause the parent's e vent. Some times, an edge is labele d n._of Jn if the system

TABLE 5.1

Guideword

no more less part of otbertban early late be fore after

Guidewords for Identifying Possible Failures

Interpretation

No data or control signal was sent or received The volume of data is too mucb or too fast 111e volume of data is too low or too slo w 111e data or control signal is iuoomplete The data o r control signal has another component The signal arrives too early for the clock The signal arrives too late for the clock The signal arrives too early in the expected sequence The signal arrives too late in the expected sequence

260 Chapter 5 Designing the Architecture

Both events must occYr to cause fai IYre

Fai lwre ······················

1111111 aeous ,, .. ,111

Semity bmeli

·····

FIG URE 5. 11 Fault tree for a security breach.

Either event luds to failura

/ Buie events

includes m redundant components, where n. faulty components le ad to the designated failure. Each node represents an indepe ndent event; otherwise, the analysis results may be invalid, especially with respect to compouml fa ults.

For example, consider the fault tree presented in Figure 5.11 . The tree shows that a security breach co uld occur e ithe r if a previo us logout is not recognized Oea ving the previous user logged in) or an unauthorized user gains access to th.e system. For the lat- te r to happen, both o f two basic events must happe n: a valid user's password is exposed, and the passwo rd is no t changed be tween the time of the exp osure and the time an unauthorize d user atte mpts to use it.

The conce pts we have described can be applied to any syste m's hardware or soft- ware. The challe nge is to ide ntify ke y possible failures, and then trace backwards through the design, looking for data and computations that could contribute to the fail- ure.Da ta- flow a nd contro l-flo w graphs can he lp us trace th1ough a design.As we saw in Cha pte r 4, a data-flow graph de picts the transfe r of data from one process to ano ther. The same ideas can be applied to an architectural design, to show what kinds of data flo w among the design's software units. In this way, if one of the failures we are ana lyz- ing is da ta rela te d, we can trace backwards throug h the d ata-fl.ow g raph to find the soft- wa re units that could a ffect the data and thereby ca use the fault. Similarly, a control-flow graph de picts possibl e tra nsfers of control among softwa re units. Whe n applied to a design, a control-flow graph can show bo w a control thread prog resses from o ne unit to the next during execution. If we are analyzing a failure that is re lated to computatio n or to a quality attribute, we can trace backwards through the control- flo w graph to find the so ftwa re units involved in that computatio n.

Once the fault tree is constructed, we can search for design weaknesses. For e xample, we can de rive ano the r tree, called a cut-set tree, that reveals which event com- bina tion s can cause the failUJe. A cut-set tree is especiaLiy useful when the fault tree is

Openmirrors.com

Section 5.7 Architecture Evaluation and Refinement 261

complex and difficult to analyze by eye. The rules for formjng the cut-se t tree a re as fo llows:

1. Assign the top node of the cut-set tree to match the logic gate at the top of the fault tree.

2. Wo rking from the top down , expa nd the cut-set tree as follows:

• Expand an or-gate node to have two children , one for each o r-g ate cillld. • Expand an and-gate node to have a child composition node listing both of the

and-gate cllldren. • Expand a composition n ode by propagating the node to its childre n, but

expanding o ne of the ga tes listed in the node.

3. Continue until au leaf nodes are basi c events or compositi on nodes of basic events.

The cut-set is the se t of le af n odes in the cut-set tree. For e xample, consider the faul t tree on the le ft side of Figure S.12. Gl is the top logic gate in the fault tree, and its or conditio n leads us to expand its corresponding node in the cut-set tree to have two child nodes, G2 and G3. In turn, G2 in the fault tree is composed of both G4 and GS, so G2 in the cut-set tree is expanded to have a composition child n ode with labe l IG4, GS). Continuing in this manne r, we end up with the cut-set{Al ,A 3), IA1,A4) ,IA2, A3), IA2, A4), IA4, AS). The cut-set represents the set of minimal eve nt combinations that could lead to the failure listed at the top of the cut-set tree. Thus, if any member o f the cut-set is a singleton event se t, !Ai), then the top failure could be caused by a single eve nt, Ai. Similarly, the cut-set ele ment !Ai, Aj) means that the top failure can occur if both events Ai and Aj occur, and cut-set element !Ai, Aj, .. . , An) means thall: failure can occur only if aU of the composite eve nts occur. Thus, we have re asoned from a failure to a u possible causes of it.

GI

~ G2 G3

! l {G4, GS} {A4, AS)

~ {A I, GS} {A2, GS}

/\ ~ {Al, A4} {A2, A3} {A2, A4}

Fault tree Cut ·sel tree

FIGURE 5.12 Cut-set tree gene rated from a fault tree.

262 Chapter 5 Designing the Architecture

Once we know the points of failure in our design, we can redesign to reduce the vulnerabilities. We have several choices when we :find a fault in a design:

• Correct the fault. • Add components or conditions to prevent the conditions that cause the fault.

• Add compon ents that detect the fault o r failure and recover from the damage.

Although the first option is preferable, it is not always possible. We can aJso use fauJt trees to calcuJate the probability that a given failure wilJ occur

by estimating the probability of the basic events amd propagating these computations up through the tree. But the re are some drawbacks to fauJ t-lree anaJysis. First, constructing the grapbs can be time consuming. Second, many systems involve many dependencies, wbich means that anaJysis of the design's data-flow and control-How graphs yields a large number of suspect software units to explore; it is difficuJt to focus only on tbe most critical parts of the design unJess we have very low coupling. Mo reover, the number and bnds of preconditions that are necessary for each failure are daunting and not always easy to spot, and the re is no measurement to help us sort them out. H owever, researche rs continue to seek ways to automate the tree building and analysis. I n the United States and Canada, fault-tree analysis is used for criticaJ aviation and nuclear applications, where tbe risk of failure is worth the intense and substantial effort to build and evaJuate the fauJt trees.

Security Analysis

In Chapte r 3, we saw how risk analysis is used to determine the likely threats to a project's cost and schedule. When designing the system's arch itecture, we must carry o ut a similar analysis, this time to address security risks. Allen et al. (2008) describe the six steps in performing a security analysis:

1. Software characterization. In the first step, we review the software requireme nts, business case, use cases, SAD, test plans, and other available documents to give us a complete unde rstanding of what the system is s upposed to do and wby.

2. Threat analysis. Next, we look for threats to the system: Who might be interested in attacking the system, and when might those attacks occur? NIST (2002) lists many sources of threats, including hacke rs, computer criminals, terrorists, indus- trial espio nage agents, and both na'ive and malicious inside rs. The threat activities might include indl!lstrial espionage, blackmail, interception or disruption of com- munications, system tampering, and more.

3. Vulnerability assessment. Security problems occu r when a threat exploits a vuJ - ne rability. The vulnerability may be a flaw in t be software design or in the code itself. Examples include failure to authenticate a pe rson or process before allow- ing access to data or a system, or use of a cryptographic algorithm that is easy to break. VuJnerabilities can arise not only fro m mistakes but also from ambiguity, de pe ndency, or poor error handling. Ant6n e t al. (2004) describe a complete methodology for finding a system's vuJnerabilities.

4. Risk likelihood determination. Once the threats and vulnerabilities are documented, we examine the likelihood that each vulnerabili ty will be exploited. We must con- sider four things: the motivation (i.e., why the person or system is threatening), the

Openmirrors.com

Section 5.7 Architecture Evaluation and Refinement 263

ability of the thre at to exploit a vulne rability, the impact of the exploitation (i.e., how much damage will be do ne, bow lo ng the effects will be felt, and by whom), and the degree to which current controls can prevent the exploitation.

5. R isk impact determination. Ne xt, we look a t the business consequences if the attack is successful. Wh at asse ts are threa te ned ? How long will functi onality be impaired ? How much will recognition and re media tion cost? Pfieeger and Ciszek (2008) describe RAND 's InfoSecure methodo logy, which provides guide lines for recognizing and ra nking various threats and vulnera bilities in terms of business impact. The highest rank is busin ess-en ding, where an organization or business would not be able to recover from the attack. Fo r example, the business may lose the designs fo r aJI o f its new products. The next ca tegory is damaging: a temporary loss of business from which it may be difficult but not impossible to recove r. For insta nce, the business may lose sensitive fi nancial data tha t can eventually be re trieved fro m backup media. The next lo we r category is recoverable; he re, the business ma y lose its corporate benefi t po licies (such as life and health insur- ance), which can e asily be replaced by the insurance providers. The lowest cate - gory is nuisance, where assets such as nonsensitive email a re de le ted from the serve r; restoration may n ot even be necessar y.

6. R isk mitigation planning. The final step involves planning to re duce the likelih ood and conseque nces of the most severe risks. InfoSecure pe rforms this planning by first having us devise projects to address each risk. The proj ects specify both staff impact and policy impact. The projects are prioritized according to the business impact, conside ring bo th capital and ove rhead costs. A final list of projects to imple- ment is based on likelihood of risks, business impact of mitigatio ns, and cash flow.

Altho ugh the six security ana lysis steps can be applied to e valuate how well an a rchitectural design meets security needs, these steps can also be applied later in the de velopme nt process. Even when the system is o peratio nal, it is useful to perform a security analysis; thieats and vulne ra bilities change over time, and tbe system sh ould be updated to meet n ew securi ty needs.

Tra d e -off Ana lysis

Often, the re are severa l alternative designs to consider. In fac t, as pro fessionals, it is our duty to explore design alternatives and no t simply imple ment the first design that com es to mind. For example, it may not be immediate ly obvious which a rchitectural styles to use as the basis fo r a design . This is especially true if the design is expected to achieve quality a ttributes that conflict with one anothe r. Alternatively, different me mbers of our design team may promote competing designs, and it is our responsibility to decide which one to pursue. We need a measl!IIement-based method fo r comparing design alternatives, so that we can m ake informed decisions and ca n justify o ur decisio ns to o thers.

One Specificati on, Many Designs. To see how diffe rent architecture styles can be used to solve the same problem , conside r the p ro blem posed by Parnas (1972):

The [key word in context] KWIC system accep ts an o rdered set o f lines; each line is an ordered set of words, and each word is an o rd e red set o f charac ters. Any line may be

264 Chapter 5 Designing t he Architecture

"circularly shifted" by repeaiedly removing the first word and appending it at the end of the line. The KWIC index system outputs a list of all circular shifts of all lines in alphabeti- cal order.

Such syste ms are used to index text, supporting rapid searching for keywords. For e xampl e, KWIC is used in e lectronic library catalogues (e.g., flnd a ll titles that contain the name "Martin Luther King Jr.") and in online he lp systems (e.g., find all index e ntries th at contain the word "customize").

Sh aw and Ga rlan (1996) presen t fo ur diffe rent architecturaJ d esigns to implement KWIC: repository, data abstraction , implicit invocatio n (a type of publish-subscribe), and pipe -and-filter. The rep ository-based solutio n, shown in Figure 5.13, breaks the problem into its fo ur primary functions: input, circular shift, alphabetize, and output. Thus, the system's function ality is d ecomposed and modularized . "These four mo dules are coordinate d by a master program that calls them in sequence. Because the da ta are loca lized in their own modules, and not replicated or p assed amon g the computatio nal modules, the design is e fficient. However, as Paroas points out, this design is di.fficult to change. Because the computational modules access and manipula te the data directly, via read and write operations, any change to the data and d ata format wiU affect all modules. Also, none of the elements in the design are pa rticularly reusable .

Figure 5.14 illustrates a second design that has a similar decomposition of func- tionality into sequentiaLly ca lled modules. However, in this design, the data compute d by each computational module is stored in that mod ule. For example, tbe circular-shift module maintains the index to keywords in the text, and the alpha betic-shift module maintains a sorted (alph abe tized) ve rsion of this index. Each module's data are accessi- b le via access methods, rathe r than directly. Thus, 1!.he modules fo rm data abstraclions . In a data abstraction , the methods ' inte rfaces give n o hint of the module's data or data re prese ntations, making it easier to modify data-re la ted design decision s without affecting other modules. And because data-abstractio n modules encompass both the

KEV Direct memory access

¢ Subprogram cal I Svstem 1/0

Input medium

FIGURE 5.13 Shared-data solution for KWIC(Sbaw and Ga rlan 1996).

Openmirrors.com

Output mediqm

KEY

¢ Subprogr1m call ----- System 1/0

Section 5.7

Input medium

Architecture Evaluation and Refinement 265

Output medium

FIGURE 5.14 Data-module solution for KWlC (Shaw and Garlan 1996).

data to be maintained and the operations for maintaining the data , these modules are easie r to re use in other applications than modules fro m our first design. On the down- side, changes to the system's functionality may not be so easy, because the functionality is so tightly coupled with the data. For example, omitting indices whose circular shifts sta rt with noise words means either (1) enhancing an existing module, making it more complex, mo re context specific, and less re usable; or (2) inserting a new module to remove use less indices after they have been created, which is inefficie nt, and modifying e xisting modules to call the new module (Garlan, Kaiser, and Notkin 1992).

Instead, Garlan, Kaiser, and Notkin (1992) propose a third design, shown in Figure 5.15, in which the data are stored in ADTs that manage generic data types, such

KEY - Implicit invocation c:::::::;> Subprogram call ---- System 1/0

Input

Input medium

FIGURE 5.15 ADTsolution for KWIC (Shaw and Garlan 1996).

Output

Output medium

266 Chapter 5 Designing the Architecture

as Lines of text and sets of indices, rather than in KWIC-base d data abstractions. Because ADTs are gene ric, they are even more re usable than data abstractions. More- over, the data and operations on data are encapsulated in the ADT modules, so changes to data re prese ntation are confined to these modules. This design resembles the first design, in that the syste m's functionality is decomposed and modularized into compu- tationaJ modules. H oweve r, in this design, many of the computation al modules are trig- gered by the occurrence of events rathe r than by explicit procedure invocation. For exampl e, the circular-shiJt module is activated wheneve r a new Line of text is input. The d esign can be easily exte nded, via new computa tio nal modules whose me thods are trig- gered by system events; existing modules do not need to be modified to integrate the new mo dules into the system.

One complicatio n with an implicit-invocation design is that multiple computa- tional methods may be trigge red by the same e vent. If that happens, au the triggered me thods will execute, but in what order? If we do not impose an o rder, then the trig- gered methods may execute in any arbitrary order, which may not be desired (e.g., a me thod that expands macros in new lines of text should execute b efore a metho d t hat inserts a new line into the ADT). H owever, to control execution o rder, we must devise some gene ric strategy that applies to bo th curre nt and future sets of methods triggered by the same eve nt, and we cannot always predict what methods may be added to the system in the future.

Th.is complication leads us to a fourth design, based on a pipe-and-filter archjtec- ture (Figure 5.16), where the sequence of processing is controlled by the sequence of the filte r mouules. This uesign is easily extenueu to include ne w features, in that we can sim- ply insert additional filte rs into the sequence. Also, each filter is an independent entity tha t can be changed without affecting other filte rs. The design supports the reuse of fil- ters in other pipe-and-filte r applications, as long as a filter's input data is in the form that it expects (S haw and Garlan 1996). The fLlters may execute in paraUel, processing inputs as they are received (although the Alphabetizer cannot output its results until it bas rece ived and sorted all o f the input lines); this con current processing can enhance per- fo rmance. Unlike the o tber designs, a data item is no lo nger stored in any locatio n, but ra the r flows from one filter to another, being transformed along the way. As such , the d esign is no t conducive to changes that would re quire the storage of persistent data ,

KEY - Pipe ----System 1/0

Input medium

Alphabetim

Input

Output

Circular sh ift

Output mo~ium

FIGURE 5.16 Pipe-and-filter solution for KWIC (Shaw and Gari an 1996).

Openmirrors.com

Section 5.7 Architecture Evaluation and Refinement 267

TABLE 5.2 Comparison of Proposed KWICSolutions

Shared Data Implicit Pipe and Attribute Data Abstraction Invocation F ilter

Easy to change algorithm + + Easy to change data representation + Easy to add functionality + + + Good performance + + Efficient data representation + + + Easy to reuse + +

Source: Ada:pted from Shaw and Garlan (1996).

such as an undo operation. Also, there are some space ine fficiencies: the circular shifts ca n no lo nge r be represented as indices into the originaJ text and instead are permuted copies of the original lines of text. Moreover, the data item is copied each time a filter o utputs its results to the pipe leading to the next filter.

We can see that each design has its positive and negative aspects. Thus, we need a method for comparing diffe rent designs that aUows us to choose the best one for our purpose.

Compa rison Tables. Shaw and Garlan (1996) compare the four designs accord- ing to how well they achieve important quality attributes and then organize this infor- mation as a tabl e, shown as Table 5.2. Each row represents a quality attribute, and there is one column for each of the proposed designs. A minus in a celJ means that the attrib- ute represe nted by the row is not a property of the design fo r that column; a plus means that the d esign has the attribute. We can see from the table that the choice is still not clear; we must assign priorities to the attributes and form weighted scores if we want to select the best design for our particular needs.

We start by prioritizing quality attributes with respect to how important the attributes are to achieving our customer's requirements and our development strategy. For example, on a scale of 1 to 5, whe re 5 indicates that an attribute is most desirable, we may assign a "5" to reusability if the design is to be reused in several other products.

Next, we form a matrix, sh.own in Table 5.3, labe ling the rows of the matrix with the attributes we value. The second column lists the priorities we have determined fo r

TABLE 5.3 Weighted Comparison of Proposed KWIC Solutions

Shared ID a ta Implicit Pipe and Attribute Priority Data Abstraction Invocation Filter

Easy to change algorithm 2 4 5 Easy to change data representation 4 1 5 4 1 Easy to add functionality 3 4 1 3 5 Good performance 3 4 3 3 5 Efficient data representation 3 5 5 5 Easy to reuse 5 1 4 5 4 Total 49 69 78 62

268 Chapter 5 Designing the Architecture

each of the attributes. Io the re maioing columns, we record how well each design achieves each attribute, on a scale of 1 (low achievement) to 5 (high achievement). Thus, the entry in the cell in the ith row andjth column rates the design represented by column i in te rms o f how well it satisfies the quality attribute represented by row j.

Finally, we compute a score fo r e ach design by multiplying the priority o f e ach row by the design's scor e fo r that attribute, and summiog the results. For example, the pipe-and-filte r desigo score would be calculated as 1 x 5 + 4 x 1 + 3 x 5 + 3 x 5 + 3 x 1 + 5 x 4 = 62. The scores of the other designs are listed on the bottom row of Table 5.3.

I n this case, we would choose the implicit-invocation design. However, the priori- ties and ratings, as well as the choice of attributes, are subjective and depend o n the needs o f our custome rs and users, as we ll as our preferences for building and maintain- ing systems. Other attributes we might have considered ioclude

• modularity • testability

• security • ease of use • ease of understaoding • ease of iotegration

Including these attributes (in parti cular, e ase o f integration) in our analysis might have affecte d o ur final decisio n. Othe r evaluators are likely to score the designs diffe re ntly and ma y reach different conclusions. As we learn more about measuring design attrib- utes, we can remove some of the subjectivity from this ratin g approach. But design e val· uatio n will always require some degree o f subjectivity and expe rt judgme nt, since e ach of us has diffe re nt p e rspectives and experiences.

Cost-Benefit Analys is

Trade-o ff analysis gives. us a means for evaluatiog design alte rnatives, but it focuses o nly on the technica l me rits of designs, in terms of b ow well the designs achieve desired quality attributes. At least as important are the business merits of a design: Will the ben - e fits o f a syste m based o n a particular design outwe igh the costs of its implementati.on ? If the re are competing d esigns, which o ne will give us the highest re turn o n investme nt?

Suppose that we a re respo nsible fo r maintaining the catalogue for a natio nal o nline video re ntal company. Customers use the ca tal ogue to search for and request video reo tals, to ide ntify actors in videos, and to access video revie ws. KWIC is use d to inde x catalogue entries fo r fast lookup by keywords in video titles, acto rs' names, and so o o. The numbe r of users, as we ll as the size of the catal ogue, has been gro wing steadily, and the response time for querying the cata logue has gotten noticeably longer- lo the point that users have started to complain. We have some ideas about how to improve the syste m's response time. Figure 5.17 shows the part of the sys.tern architecture that is affected by our proposed changes, including the impacts of our three ideas:

1. We could eliminate entries in the KWIC index that start with noise words, su ch as articles ("a, the") a nd pre positions. 1bis change reduces the number of indices to

Openmirrors.com

Section 5.7 Architecture Evaluation and Refinement 26'9

KEY

hnpllclt ln¥0e1tlon

~ Subprogru1 c1ll ------ Sytt111 l/ O

Muter control

Input

l1p1t 11111dlan

lnJu '------ Query ~--,

": promtot ~ ~ _ : .-;::: '("... • I

' .... , t ~ I ,, '' t -:.. I ', ' " t .It I

' ...4- - - - - - - - - - I I a I I Qoery I 1 I I ,... _.. I

, p1ou u or 2 , ... - - '-----------

FIGURE 5.17 Proposed changes to KWIC.

be searched when se rvicing a lookup query. It wo uld invo lve adding a filter mod- ule, between the circular-shift and sorted-indices mo dules, tha t aborts any request to store an index to a noise word. (The design changes involve a new Hiter mod - ule, s bo wn in dasbed lines in Figure 5.17.)

2. We could change the representatio n of indices to be bins of indices, where e ach bin associates a keyword with the set of indices that point to lines that contain tbat wo rd. This change reduces the time it ta kes to find subseque nt insta nces of a ke ywo rd o nce the ftrst instance (i.e., the bin) bas been found. (The design changes the inte rnal data represe ntati on within the Ind ex module, shown in dashed lines in Figure 5.17.)

3. We co uld incre ase ser ver capacity by adding ano the r compute r , Que ry P rocessor 2, that shares the task of processing queries. This change invo lves not only buying the serve r, but a lso changing the software architecture to include a Dispatche r moduJe that assigns q ueries to servers. (The design changes shown invo lve a new Query Processo r 2 and a Dispatcher, shown in dashe d lines in Figure 5.17.)

A H three proposals would improve the time it takes to lookup cata logue entries, but which one would be the mo st e ffective?

Most companies de fine "effectiveness" of a system in terms of vaJue and cost: how much vaJue will a proposed change add to the syste m (or h ow much value will a new

270 Chapter 5 Designing the Architecture

system add to the company's business) compared with bow much it wiU cost to imple- ment the change. A cost-benefit analysis is a widely used business tool for estimating and comparing the costs and be nefits of a proposed change.

Comput ing Be nefits. A cost-benefil analysis usually contrasts financial be nefits with finiancial costs. Thus, if the benefit of a design is in the extra features it provides, or in the d egree to which it improves quality attributes, then we must express these be ne- fits as a financial value. Costs are often o ne-time capita l expenses, with pe rhaps some ongoing operating expenses, but be ne fits almost a lways accrue over time. Thus, we cal- culate benefits over a sp ecific time pe riod, or calculate the time it would take for be ne- fits to pay for the costs.

For example, le t us compute the bene fits of the above design proposals, with respect to bow we U we expect the m to improve the response time for querying the video catalogue. Suppose that the current catalogue contains 70,000 e ntries, and that the average size of an e ntry (i.e., the number of words per record, including the video's title, the director's name, tbe actors' names, and so on) is 70 words, for a total of almost five millio n circular shifts. On average, it curre ntly takes the system 0.016 seconds to find and o utput all entries that contain two keywords, which means that the system accommodates about 60 such requests per second. Ho wever, at peak times, the system wil l receive up to 100 queries per second, and the system is eventually expected to handle 200 queries pe r second.

Table 5.4 summarizes the bene fits of implem enting the three designs. Eliminating noise words does not significantly improve perfo rmance, mainly because most of the words in an entry are names, and names do not have noise words. In contrast, adding a second serve r almost doubles the number of requests that the system can service per sec- ond. And restructuring the sorted-index data structure provides the gr eatest bene fits, because it reduces the search space (to keywords rather than circular shifts), and because the result of the search re turns all of the associated indices rather than just one.

Next, we compute the financial value of these improveme nts. The value oif an improveme nt depends o n ho w badly it is needed, so value might not increase propor- tionally with increases in quality. In some cases, a small improvement may be of Little

TABLE 5.4 Cost-Benefit Analysis of D esign Proposals

Eliminate Store Indices Add Second Noise Words in Bins Server

Benefits Search time 0.015 sec 0.002sec 0.008sec Throughput 72 requests/sec 500 requests/sec 115 requests/sec Added value $24,000/yr $280,000/yr $110,000/yr

Costs Hardware $5,000 Software $50,000 $300,000 $200,000 Business losses $28,000+/yr Total costs first year $78,000 $300,000 $205,000

Openmirrors.com

Section 5.7 Architecture Evaluation and Refinement 271

L4w v1lue L4w vilue Low ulu =------<-LL.L.---

C m 11 t INprov14 Cumll l111prov14 Cuuent h11p1m4

019111 of qu1flty 111t1•u11 019111 of qu1l1ty 1ttrlhtt 019m or q;u1flty 1tt1lhte

FIGURE 5.18 Value added by improving a quality attribute (Bass, Clements, and K3Zllilan 2003).

vaJue if it is not e nough to address a problem; in othe r cases, small improvements are significant , and further improve ments yield Little additional value. Figure 5.18 shows se ve ra l ways in which value may incre ase as a quality attribute improves. Given such a vaJue functio n fo r a particula r quaLity attribute for a particular system, tbe ne t va lue of a n impro veme n t is tbe area under tbe curve between the current and improved mea- sures o f tbe qua(jty a ttribute.

For simplicity, suppose that every additional request per second that the syste m can process, up to 200 requests/second, would save the company $2000 per year, based o n retained custo me rs and re duced ca lls to technical support. Given this value func- tio n, eLimina ting no ise words would save tbe company $24 ,000 per year, caJculated as

(72 requests/second - 60 requests/second) x $2000/year = $24,000/year

Adding a second serve r would save the company $110,000 per ye ar, calculated as

(115 requests/second - 60 requests/second) x $2000/year = $110,000/year

The second design option would improve the syste m's throughput beyond what will be needed (the system will rece ive at most 200 requests per second). Therefore, the va lue added by changi ng to bin-based indexing is the maximum possibl e vaJue:

(200 requests/second - 60 requests/second) x $2000/year = $280,000/year

If there are multiple attributes to consider (e.g., the time it takes to update, reindex, and re-sort the ca tal ogue), the n a d esign's total financial added value is the sum o f the added values ascribed to eacb o f the attributes-some of whose added values may be nega tive if a design improves one attribute at the exp ense of a confLicting a ttribute.

Co mputing Return on Investment (R OI). The return on in.vestment of making one of these design changes is the ratio of the benefits gained from making the change to the cost o f its implementation:

ROI = Benefits/Cost

These costs are estimated using the techniques described in C hapter 3. The estimated costs of the proposed design changes in our example are s!hown in Table 5.4. ln general,

272 Chapter 5 Designing the Architecture

an ROI o f 1 or greate r means that the design's b enefits outweigh its costs. The high er the ROI value, the more e ffective the design.

Another useful measure is the payback period: the length of time before accumu- lated be nefits recove r tbe costs of imple mentation. In our example, the payback period for restructuring the sorted-index modul e (design 2) is

$300,000/$280,000 = 1.07 of a year = approximately 13 months

We retlLIIn to calcula tions such as these in C hapter 12, where we investigate the best techniques fo r evaluating the re turn on investing in software reuse.

Prototyping

Some d!esign questio ns a re b est answered by prototyping. A prototype is an executable mode l o f the syste m we are developing, built to answer specific questions we have abo ut the system. For example, we may want to test that our protocols for signaling, synchro nizing, coordinating, and sharing data among concurre nt processes work as expecte d. We can develop a prototype that impleme nts processes as stubs and that e xe rcises o ur communication protocols, so that we can work o ut the kinks and gain confidence in our plans fo r how the processes will interact. We may also learn some- thing about the Limits (e.g., minimum response times) o f our design.

Prototyping offers different advantages in the design stage from those gained during re quire ments analysis. As we saw in Chapter 4, prototyping is an e ffective rtool for testing the feasibility of questionable requirements and for exploring user-inte rfa ce alternatives. The process of developing the prototype e ncourages us to communicate with our customers and to explore areas o f uncertainty that eme rge as we think about the syste m's requireme nts. As long as our customers understand that the prototype is an explorato ry mode l, n ot a be ta-version of the product, prototyping can be useful in helping both us and our customers unde rstand what the system is to do.

In the design phase, prototyping is used to answer design questions, compare design altemaltives, test complex interactions, or explore the effects of change requests. A proto- type omits many of the d etails o f functionality and performance that will be part of the real system, so that we can focus narrowly o n particuJar aspect-s of the system. For example, a smal l team may gene rate a prototype fo r each design issue to be resolved: one pro to type for modeling the use r interface, one for certifying that a purchased component is compatible witb our design, one for testing the network performance between remote processes, o ne for each security tactic being conside red , and so on. "The final design is then a synthesis of the answers obtained fro m the indivi.dua l prototypes.

If a prototype is intended o nl y to explore design issues, we may not give its devel- opment the same careful atte ntion that we would give to a real system. For this reason, we freq uently discard the prototype and build the actual syste m from scratch, rather than try to salvage parts from the proto type. In these cases, the throw-away prototype is meant to b e discarded; its deve lopment is intende d only to assess the feasibility o r par- ticular characteristics in a proposed design. In fact, Brooks (1995) recommends building a system , thro wing it away, and building it again. The second version of the system bene- fits from the learning and the mistakes made in the process of building the first syste m.

Openmirrors.com

Section 5.8 Documenting Software Architectures 273

Alte rnatively, we may attempt to reuse parts o f the prototype in the actual sys- te m. By taking care in the design and de ve lopme nt of the proto type's components, we can produce a prototype that answe rs questions about the design and at the same time provides building blo cks fo r the final system. The challenge is to en sure that this style of pro to typing is still fast. lf the prototype cannot b e built more quickly than the actual system, then it loses its value. Mo reover, if too much effort is invested in developing a quality prototype, we may become too attache d to the design decisions and other assets e mbedded in the pro to type, and we may be less op en to con side ring design alte rnatives.

An extreme ve rsio n of this approach is calle d rapid prototypiing, in which we pro- gressive ly re fine the p ro totype until it beco mes the final system. We start with a proto- type of the require me nts, in the form of a pre liminary user in terfa ce that simulates the system's responses to user input. In successive ite ratio ns of the prototype, we flesh out the system's design and implementation, providing the functionality promised by the initial U1Se r inte rface. In many ways, rapid proto typi ng resembles an agile deve lopme nt process, in that the syste m's deve lopme nt is ite rative and the re is continual feedback fro m the custo me r. The diffe re nce is that the initial proto type is a use r-interface shell rathe r than the core o f the o perational system.

Boehm, Gray, and Seewaldt (1984) studied proj ects that we re d eveloped using rapid proto typing, and they re port tha t such projects performed albout as well as those de ve lo ped using traditio nal design techniques. In additi on, 45 pe rcent less effort was e xpe nde d and 40 percent fewe r lines of code we re generated by the d evelopers who used proto types. Also, the speed and efficiency o f the systems de ve loped with proto- types were almost the same as those of the tradit ionally deve lo pe d systems. Ho we ver, the re are some risks in u sing rapid prototyping. l ih e biggest risk is that by showing cus- to me rs an o peratio nal prototype, we may misle ad them into believfog that the system is close to being finished. A re lated risk is that customers ma y e xpect the final system to e xhibit the same performance characte ristics as the prototype, whic h could be umeali s- ticaH y fast due to o mitte d functionality, smaUe r scale, and communicatio n delays. Also, because of the lack of d o cumentation, proto typing as a de velopment process is b est suited for smaller p rojects invo lving smaller d evelopment teams.

5.8 DOCUMENTING SOFTWARE ARCHITECTURES

A syste m's architecture plays a vital role in its o verall developme nt: it is the basis on which most subseque nt d ecisio ns abo ut design, quality assurance, and project manage- ment a re made. As such , it is crucia l that the system 's d evelopers and stakeholde rs have a consistent unde rstanding o f the syste m's architecture. T he SAD serves as a repo sitory fo r info rmatio n a bo ut the a rchitectural design and helps to commWlicale this vision to the va rio us membe rs o f the de ve lo pment team.

The SAD's conten ts de pend heavily on h ow it will be used. That is, we try to antici- pate what informatio n will be sought by different types o f SAD re ade rs. Customers will be looking fo r a natural-language description of what the system will d o. Designers wiJJ be looking for precise speci.ficatio ns of the software units to be developed. A performance analyst will want enough info rmatio n about the software design, the computing platform, and the system's environmen t to car:ry out analyses of likely speed and load. Different

274 Chapter 5 Designing the Architecture

team members read the SAD, eacb with a different purpose. For example, coders read the SAD to understand the overall design and make sure that each design fea ture or function is imple mented somewhere in tbe code. Testers read the SAD to e nsure that their tests exercise all aspects of the design. Maintainers use the SAD as a guide, so that architectural integri ty is maintained as proble ms are ftXed and ne w fea tures imple mente d.

Give n these uses, a SAD should include the following information:

• System overview: This section provides an introducto ry descripti on of the system, in te rms of its key functions and usages.

• Views: Each view conveys information about tbe system's overall design structure, as seen from a particular perspective. In addition to the views, we document also ho w tbe views relate to one ano ther. Because the views are lilkely to be read by all SAD readers, each section is pre faced with a summary of the view and its main ele- ments and interactions; technical de tails are addressed in separate subsections.

• Software units: We include a comple te catal ogue of the software units to be d evel- op ed , including precise specifications of the ir inte rfaces. For each software unit, we i.ndicate a ll o f the views in which the unit appears as an element.

• Analysis data and results: This section contains e nough de tails abo ut the syste m's architecture, computing resources, and executio n e nvironment so that a design analyst can measure the design 's quality attributes. The results o f the analyses are also recorded.

• Design rationale: D esign decisions must be explained and defende d, and the ratio nale for the ch ose n design is recorded to ensure that project managers and future architects have no need to revisit design alternatives that were o riginall y dismissed fo r good reason.

• Definitions, glossary, acronyms: These secti o ns provide all readers with the same unde rstanding o f the technical and domain vocabulary used throughout the document.

lo additio n, the SAD is identified with a ve rsio n numbe r o r date of issue, so that readers can e asily confirm that they are working with the same versio n of the document and that the ve rsio n is recent.

There a re few guide lines, in the fo rm of standards or recommended templates, for ho w to o rganize aU of this info rmation as a useful. technical reference. For example, the IEEE recomme ndation s for documenting software architectures, IEEE Standard 1471-2000, prescribe what informati on to include in an architectural document, but say little about ho w to structure o r format the information. Thus, it makes sense to deve lop an in-ho use sta ndard fo r organizing the SAD's co ntents, including guidance on the doc- ume nt's structure, conte nts, a nd the source o f each type of in.fo rm ation (e.g., whe ther the write r must collect o r create the info rmatio n) . More importantl y, a standard he lps the read er know bow to navigate thro ugh the docume nt and find information quickly. Like o ther reference texts, such as dictio naries and encyclopedias, technical documen- tatio n such as the SAD :is rare ly read fro m cover to cover; most users use the SAD for quick que ries about design decisions that are described at a high le vel in o ne part of the docume nt but are described in de tail e lsewhere in the document. Thus, the SAD sho uld be organized and indexed fo r easy reference.

Openmirrors.com

Section 5.8 Documenting Software Architectures 275

As Bass, Clements, and Kazman (2003) note,

One of the most fundamental rules for technical documentation irn general, and software architecture documentation in particular, is to write from the point of view of the reader. Documentation that was easy to write but is not easy to read will not be used, and "easy to re.ad " is in the eye o f the beho lder-or in this case, the stakeholder.

Given the many uses o f the SAD, we h ave many readers to satisfy with a single document. As such, we may choose to split the SAD into diffe rent but related docume nts, where each piece addresses a different type of reader. Alternatively, we can try t o merge all informa- tion into a single document, with directions to guide different readers to their information of interest. For example, we may suggest that customers read the system overview plus summaries of each view. B y contrast, developers wo uld be expected to read details of the software units they are to implement, the uses view to see h ow the Wlits relate to the rest of the syste m, any o the r view that uses the corresponding architectural elements, and the mappings among views to see if the units correspond to other architectural elements.

Mappings among Views

How ma ny and which views to include in the SAD depends on the structure of the sys- tem being designed and the quality attributes that we wan t to measure. At the very least, the SAD should contain a decomposition view showing the design 's constituent code units, plus an execution view showing the system 's runtime structure. In addition , a deployment view that assigns software units to computing resources is essential if we wanl lo reason about the system's perfo rmance. Alte rnatively, we ma y include multiple e xecution views, each based o n a different architectural style, if each of the styles re flects use ful ways o f thinking about the system 's structure and inte ractio ns. For example, if our design is based on a publish-subscribe style, in which components are trigge re d by e ve nts, we may also include a pipe-and-filte r view tha!I: depicts the o rde r in which components are to be invoked.

Because our design is documented as a collection of vie ws, we should show how the views rela te to one a nother. If o ne view details ao elemeot that is a software unit in a more abstract view, the n this relationship is straightforward. Howeve r, if two views show d mffe rent aspects of the same part of the design, and if the re is no obvious corre- spo ndence be tween the e lements in the two views, the n mapping tbis corresp onde nce is essential. Fo r e xa mple, it is useful to record how runtime compo nents and connecto rs in an execution view map to code-level units in a decomposition view. Such a mapping docume nts bow the compo ne nts and connectors will be imple mented. Similarly, it is useful to record bow ele ments in one decomposit ion view (e.g., a m odule view) map to e leme nts in ano the r decompositio n view (e.g., a layer view). Such a mapping revea ls all of the um.its needed to impleme nt each layer.

Cleme nts et a l. (2003) descri be how to document a mapping between two views as a table, indexed by the e lements in one of the views. For each e lement in the first view, the tabl e lists the corresponding element(s) in the second view and describes the nature of the correspondence. Fo r example, the inde xed e le ment implements the other ele- ment(s ), o r is a generalization of the other e leme nt(s). Because it is possible that parts of elements in o ne view ma p to parts o f e lements in the other view, we should also indicate whe ther the corresponde nce is partial or complete.

276 Chapter 5 Designing the Architecture

Docume nting Rationa le

In addition to design decisions, we also document design rationale , outlining the critical issues and trade-offs tba t were considered in ge ne rating the design. This guiding philos- ophy he lps the custo me rs, project managers, and other developers (particularly main- taine rs) unde rstand bo w and why ce rtain parts of the design fit together. It also he lps tbe architect reme mber the basis for certain decisions, thereby avoiding the need to revisit these decisio ns.

R ationale is usually exp ressed in te rms of the system's re quirements, such as d esign constraints that limit the solution space, or quaLity attributes to be optimized. This sectio n o f the SAD lists decision alte rnatives that were conside red and rejecte d, along witb a justification fo r why tbe chosen option is best; if several a lternatives are equally good, then those sh o uJd be described too. The design rationale may also include an evaluatio n of the po te ntial costs, be nefits, and ramifications of changing the decision.

Good practice dictates that we provide rati onal e for lower-level design decision s, such as details a bout softwa re -unit inte rfaces or the structure o f a view, as well as over- all architectural decision s, such as ch oice of arch.itectural style{s). But we need not jus- tify every decision we make. Cleme nts et al. (2003) offer good advice on whe n to docume nt the rationale behind a decision:

• Silgnificant time was spent on considering the options and arriving at a decision. • The d ecision is critical to achieving a re quire ment.

• The decision is counterintuitive or raises questions. • It would be costly to change the decision.

5.9 ARCHITECTURE DESIGN REVIEW

D esign review is an esse ntial part of e ngineering practice, and we evaluate the quaLity o f a SAD in two diffe re nt ways. First, we make sure that the design satisfies all of the requirem ents specified by the customer. This procedure is kno wn as va lidating the d esign. Then we address the quality of the design. Ve rification involves ensuring that tbe design adheres to good design principles, and that the design documentation fits tbe needs of its users. Thus, we validate the design to make sure that we are buiJding wha t the custo mer wants (i.e., is this the right system ?), and we ve rify our documenta- tio n to he lp ensure that the developers will be productive in their development tasks (i.e., are we buiJding the system right?).

Va lidation

During validation, we ma ke sure that all aspects of the requirements are addressed by o ur des ign. To do that, we invite seve ra l key people to the review:

• the analyst(s) who helped to de fine the syste m re quirements • the syste m architect(s) • the program designer (s) for this project

Openmirrors.com

Section 5.9 Architecture Design Review 277

• a syste m teste r • a system maintainer

• a moderator • a recorder • otbe r inte rested syste m develo pers who are n ot othe rwise involved in this project

The numbe r of p eople actually at the revi ew depends on the size and complexily o f the syste m unde r de velopment. Eve ry me mbe r of the review team should have the author- ity to act as a representative of h.is or her organizatio n and to make decisions and com- mitments. The to tal numbe r sh ould be kept small, so that discussio n a nd decisio n making are not hampered.

The mode rato r leads tbe discussion but bas n o veste d interest in the project itself. H e or sbe encourages discussion , acts as an intermediary Ile tween opposing viewpoints, keeps the discussion moving, and maintains o bj ectivity and balance in the p rocess.

Because it is difficult to take part in the discussio n and also record the main points and outcomes, another impartial partjcipant is recruite d to serve as recorde r. The recorder does n ot ge t involved in the issues that arise; his or her sole job is to document what transpires. H oweve r, more than sten ographic skill s are required ; the recorder must bave enough technical knowledge to unde rstand the proceedings and record rele- vant technical info rmation.

Deve lopers who are not in.valved with the project provide an outside r's perspec- tive. They can be objective wbe n commenting on the proposed design, because they bave no pe rsonal stake in it. In fact, they may bave fresh ideas and can offerr a new slant on things. They also act as ad hoc verifiers, checking that t!he design is correct, is consis- te nt, and confo rms to good desig n practice. By participating in the review, they assume equal responsibility for the design with the designers the mse lves. nus shared respon- sibility forces aU in the review process to scrutinize every d esign detail.

During the revie w, we present the proposed architecture to our audience. In doing so, we de monstrate that the design bas the required structure, functio n, and char- acteristics specified by tbe requireme nts docwnents. Together, we confirm tbat the pro- posed design includes the re quired hardware, interfaces witb o ther systems, input, and o utput. We trace typical execution paths through the architecture, to convince our- se lves that the communica tio n and coordination mechanisms wo rk prope rly. We a lso trace exceptio nal executio n paths, to re view the design measures we have taken to de tect aod recover from faults and bad inputs. To validate nonfunctional re quireme nts, we review the results of analyses that have been performed to predict like ly system be havior, and we e xamine any documented design rationale that pe rtains to quality attributes.

Any discre pancies fo und during the review are noted by the recorder and dis- cussed by the group as a whole. We resolve minor issues as they appea r. However, if major faults or mi sunderstandings arise, we may agree to revise the design. In this case, we schedule anothe r design review to eva luate the new design. Just as the Howells would rather re do the blue prints of their house than tear out the foundation and walls late r and start a gain, we too would rather redesign the system now, on pape r, instead of late r, as code.

278 Chapter 5 Designing the Architecture

Verificatio n

Once we have convinced ourselves that the design will lead to a product with which the customer will be happy, we evaluate the quality of the design and the documentation. In particulla r, we examine the design to judge whe ther it adheres to good design principl es:

• Is the architecture modular, we LI structured , and easy to unde rstand? • Can we improve the structure and unde rstandability of the architecture? • Is the a rchHecture portable to o ther pl atforms? • Are aspects of the architecture reusable? • Does the architecture support ease of testin g? • D oes the architecture maximize performance, whe re appropriate? • Does the architecture incorpo rate appropriate techniques fo r handling fauJts and

preventing failures? • Can the architecture accommodate aU o f the expected design changes and ext en-

sions that have been docume nted?

The revie w te am also assures that the docume ntation is comple te by ch ecking that the re is an inte rface specifica tion for every referenced software unit and that these specificatio ns are complete. The te am also makes sure that the documentati on d escribes a lte rnative design strategies, with explanatio ns of how and why major design d ecisions were made.

An active design review (Parnas and We iss 1985) is a p arti cuJarly effective me thod for evaluating the quality of the SAD and determining whether it contains the right info rma tion. In a n active review, revie we rs exercise the design document by using it in ways tha t develope rs will use the final document in practice. That is, rather t han reading the docume ntation and looking for problems, which is characterized as a passive review process, the reviewe rs are given or devise questions that they must answer by looking up information in the SAD. Each reviewer re presents a different class of reade r and is asked questions suitable to his or her use of a SAD. Thus, a main- tainer may be aske d to determine which software units wouJd be affected by an e xpecte d change to the syste m, whe reas a program designer may be asked to explain why an interface's preconditio ns are necessa ry.

In gene ral , the point of the design review is to detect fa ults rathe r than conect them. It is impo rtant to remember that those who participate in the review are investi- gating tt.he integrity of the design , no t of the designers. Thus, the r eview is valuabl.e in e mphasizing to all concerned that we are working toward the same goa l. The criticism and discussion during the design revie w are ego less, because comments are directe d at the process and the product, no t at the pa rti cipants. The review process e ncourages and e nhances co mmunicat io n amo ng the dive rse me mbers of the team.

Mo reover, the process be nefits everyone by finding faults and problems when they are easy and inexpensive to correct. It is far easie r to change something in its abstract, conce ptual stage tha n whe n it is already imple mented. Much of the difficuJty and expense o f fixing fauJts late in developme nt de rive from tracking a fault to its source. If a fault is spotted in the design review, there is a good chance that the problem is loca te d somewhere in the design. Ho wever, if a fauJt is n ot detected until the system

Openmirrors.com

Section 5.10 Software Product Lines 279

is ope ratio nal, the root o f the problem may be in several places: th e hardware, the soft- wa re, tbe d esign, the imp lementa tio n, o r the d ocumentatio n. The soone r we identify a problem, the fewer places in which we have to look to find its cause.

5.10 SOFTWARE PRODUCT LINES

Thro ughout this chapter, we have focused on the design and development of a single software system. Bul ma ny softwa re companies buiJd and sell multiple products, often working with different kinds of custo mers. Some successful companies build their re pu- tatio ns a nd their set o f c lients by specializing in pa rticular application do mains, such as business support softwa re o r computer games. That is, they become known not only for provid ing qua lity software but a lso for their understanding of th e special n eeds of a p articulla r ma rke t. Many o f these companies succeed by reusing their expertise and softwa re assets across fa milies of re lated products, thereby spre ading the cost o f devel- o pment across products and reducing the time to market fo r each one.

The corpo rate strategy fo r designing and developing the re lated products is based o n the reuse o f ele ments of a common product line. The company plans upfront to manufacture and market several re lated products .. Part of the planning process invo lves deciding how those products will share assets and resources. The products may appear to be quite diffe rent fro m o ne ano the r, varying in size, quality, fe atures, or price. But they have e no ugh in common to a.Uo w the compa ny to take advantage o f economies of scope by sharing techno logies (e.g., a rchitecture, comm on parts, test suites, or en viron - ments),. assembly facilities (e.g., worke rs, assembly plan ts), business plans (e.g., budgets, re lease schedules), marke ting stra tegies and distri bu tion channe ls, and so on. A s a resuJt, the cost and e ffo r t lo develop the family o f p roducts is far less th an the sum of the costts to de velop the products indi vidually. The product-line notion is not particular to softwa re; it has been used for years in aU types of manufacturing. For example, an auto mo bile compan y o ffers muJtiple mo de ls of cars, each with its own specificatio n s of passenger and cargo space, powe r, and fue l economy. Individual brands h ave their own distinct appearance, d ashbo ard interfaces, feature pack ages, a nd luxury options; the brand is ta rgeted a t a particular market and sold at prices within a particular range. But many of the mode ls are b uilt o n the sa me chassis, use common parts fro m the sa me sup- plie rs, use commo n software, are assembled a t th e same manufac turing plant, and are sold at the same deale rsh ips as o the r models.

A distinguishing featu re o f building a product line is the tre atment o f the de rived products as a product fa mily. "rbeir simuJtaneous developme nt is pla nned fro m the beginning. The family's co mmo nalities a re described as a coUecti on of reusa ble assets (includmn g requireme nts, designs, code, and test cases), all sto re d in a core asset base. When d eveloping products in the family, we retrieve assets from the base as needed. As a resul tt, develo pme nt resembles a n assembly line: many of the components can be adapted fro m compone n ts in the core asset base and then plugged together, rathe r than de velo ping each fro m scratch. The design of the core asset base is planned carefuUy, a nd it evo lves as the pro duct fa mily grows to incl ude n ew p roducts.

Because the products in the product fa mily are re la ted , the opportunities for reuse abo und and extend well beyond the re use of code units. Clements and

280 Chapter 5 Designing t he Architecture

No rthrop (2002) describe why a number of candidate e lements may belong in the core asset base:

• Requirements: Relate d products often have commo n func tional requireme nts and quaJity attri butes.

• Software architecture: Product lines are based on a commo n architecture that rea ljzes the product family 's shared requireme nts. Differe nces a mong famjly me mbe rs ca n be isolated or parameterized as va riatio ns in the architecture; for example, fe atures, user interfaces, computing platforms, and some quality attrib- utes can be alte red to address p articular product needs.

• Models and analysis results: Models and analyses (e.g., performance an alysis) of an individuaJ product's architecture are likely to build o n analyses of the product- line architecture. So it is important to get the product-line architecture ri ght, because it affects the performance of so ma111y associated products.

• Software units: The reuse of software units is mo re than just code reuse. It includes the reuse of significant design work, including inte rface specifications, re lationships and inte ractions with other units, documentation, test cases, scaf- folding code (i.e ., code developed to support testing and analysis that is not de liv- ered with the finaJ product), and more.

• Testing: Reuse of testing includes test plans, test documentation, test data, and testing environments. It may also include the test results o f re used software units.

• Project planning: P roject budgets and deli very schcduJcs of product-family me m- bers are likely to be more accurate than products developed from scratch, because we use our knowledge of the costs a nd schedu les of past fami ly members as guides in estimating the costs of subseque nt members.

• Team organization: Because product-family membe rs have similar design struc- tures, we can reuse information from past decisions on how to decompose a prod- uct into work pieces, h ow to assign work pieces to teams, and what skill sets those teams need.

According to the Software E ngineering Institute's Product Line Ha U of Fame (at http://www.sei.cmu.edu/productlines/plp_hof.btml), companies such as Nokia, Hewlett- Packard, Boeing, and Lucent report a three- to sevenfo ld improvement in development costs, time-to-marke t, and productivity from using a product-line a pproach to software deve lopment. Sidebar 5.8 describes one compan y's conversion to a software product line.

St rategic Sco ping

Product lines are based not just on commonalities among products but also on the best way to exploit them. First, we employ strategic business planning to identify the family of products we want to build. We use knowledge and good judgm ent to fo recast mar ket tre nds and predict the de mand for various products. Second, we scope our plans, so that we focus on products that h ave enough in commo n to warrant a product-line approach to development. That is, the cost of develo ping the (common) product line must be

Openmirrors.com

Section 5.10 Software Product Lines 281

SIDEBAR 5.8 PRODUCT-LINE PRODUCTIVITY

Brownsword and Clements (1996) report on the experiences of Celsius Tech AB, a Swedish naval defense contractor, in its transition from custom to product-line development. The transition was motivated by desperation. In 1985, the company, then Philips Elektronikin- dustier AB, was awarded two major contracts simultaneously, one for the Swedish Navy and one for the Danish Navy. Because of the company's past experiences with similar but smaller

systems, which resulted in cost overruns and scheduling delays, senior managers questioned whether they would be able to meet the demands of both contracts, particularly the promised (and fixed) schedules and budgets, using the company's current practices and technologies.

This situation provided the genesis of a new business strategy: recognizing the potential business opportunity of selling and building a series, or family, of related systems ratherthan some number of sp ecific systems . .. . The more flexible and extendable the product line, the greater the business opportunities. These business drivers . .. forged the technical strategy. (Brownsword and Clements 1996)

Development of the product line and the first system were initiated at the same time; development of the second system started six months later. The two systems plus the product line were completed using roughly the same amount of time and staff that was needed previ- ously for a single product. Subsequent products had shorter development timelines. On aver- age, 70--80 percent of the seven systems' software units were product-line units (re)used as is.

more than offse t by the savings we e xpect to accrue from de riving famil y me mbe rs fro m the produc t line.

Produc t-Line scoping is a challe nging proble m. If we strive for som e no tio n of optimal commonality among tbe products (e.g., by insisting o n re using 80 pe rcent of the code), we may e xclude some interesting and profitable products that He outside o f the scope. On the othe r hand, if we try to include any product that looks relate d , we reduce the degree of commonality among the de rived produc ts, and conseque ntly the amo un t o f savings that c an be a chie ve d. A successful product line Ji es somewhe re in the middle o f these two e xtre m es, with a core arc hitecture that stro ngly supports the m o re promis- ing products that we want to build.

ln the e nd, a product line's success de pe nds on both its inhe re nt variability and the degree o f ove rlap be twee n its core asset base and the de rive d produc ts. To o btain desire d produc tivity-improve me nt numbe rs, eac h de rive d product's a rchitecture mus t s tart with the produc t-line arc hitecture, incorporating a s ignificant frac tio n of its soft- ware units from the product line's core asse t base. The n the product design adds e asily accommodate d changes, such as compone nt replaceme nts o r e xte nsions and re trac- tions of the arc hitecture. The less the final de rive d product has in commo n with the product line, the mo re the de rive d product 's de ve lo pme nt will resemble a comple te ly ne w ( i.e., nonde rive d) product.

282 Chapter 5 Designing the Architecture

Advantages of Product-Line Architecture

A product-line architecture promotes planned modifiability, where known differen ces among product-famil y m embers are isolated in tbe architecture to allow for e asy ad ap - ta ti on. E xamples o f product-line vari abili ty are given be lo w:

• Component replacements: A software unit c.an be realized by any implementation that satisfies the unit's interface specification. Thus, we can instantiate a n ew product-family me mber by ch anging the impleme ntations o f one or more soft- ware units. For example, we can use a layered a rchitecture to iso late a product family's interfaces to users, communicatio n ne two rks, o ther software compo- ne nts, the computing platforms, input senso rs, and so on.1his way, we can instanti- ate new family members by reimplementing the interfac.e layers to accommodate ne w inte rfaces. Similarly, we can improve q uality attributes, such as pe rforman ce, by reimpleme nting key software units.

• Component specializations: Specializatio n is a specia l case o f component replace- ment that is most strongly supported by object-o riented designs. We can replace any class with a subclass whose methods augment o r override tbe parent's methods. Thus, we can instantiate new family members by creating and using new subclasses.

• Producl-line param eters: We can think o f software units a s parameters in the product-line archiitecture, so that varying the p arame te rs results in a set o f p os- sible system configurations. For e xample, pa rame te rs could be used to speci fy fea- ture combina tions, which a re then instantiated as compo nent additions or re place ments. If pa rameters are the onl y source o f p roduct-line variation, then we can auto maticall y configure a nd gene rate p roducts by se tting parame ter val.ues. See Sideba r 5.9 fo r a description o f o the r work on genera ting product-fa mil y membe rs automatically.

SIDEBAR 5.9 GENERATIVE SOFTWARE DEVELOPMENT

G en erative software development (Czarnecki 2005) is a form of product-line development

that e nables products to be gene rated automatically fro m specifications. It proceeds in two phases: first, domain engineers build the product line, including mechanisms for gene rat- ing product instances, and the n application engineers generate individual products.

The domain engineer defines a domain-specific language (DSL) that application engi- neers then use to specify products to be gene rate d. A DSL can be as simple as a collection of paramete rs, with a set m enu of supported paramete r values, or it cao be as complex as a

specia1-purpose programming language. In the forme r case, the engine for deriving product instances is a collection of construction rules (for s electing and assembling prefabricated components) and optimiz atio n rules (for optimizing the code with respect to the combination

of parameter values specified). In the latte r case, the product line includes a compiler that transforms a DSL program into a product, making heavy use of the product-line architecture

and prefabricated compo nents.

Openmirrors.com

Section 5.10 Software Product Lines 283

Lucent developed several product lines and ge:nerative tools for customizing different

aspects of its SESS tele phone switch (Ardis and Gree n 1998):

• forms that service-·providc r operators and administrators use to ente r and change switch-rela ted data about custo mers (e.g. , phone numbers, features subscribed)

• billing records that are generated for each call

• co11jigura1io11-control software that mo nitors and records the status of the switch's ha rdware components a nd assists with compone nt transitions

Lucent created GUI-based DSLs that could be used to specify custom data-entry forms, billing-

record contents, and hardware-interface specifications It built compilers and other tools to gen- erate code and user documentation. 'This technology allowed Lucent to customize its telephone switches as its custome r base evolved from internal sales within AT&T to external and inter-

national service providers.; as hardware technology evolved; and as feature sets grew.

• Architecture extens io ns and retractions: Some architectural st yles, such as publish- su bscribe and client-serve r, allo w fo r easy feature additions and removals; these sty les a re use ful in product lines that have va rying feature sets. More generally, we can use dep endency graphs to evaluate de rived architectures. For example, a via ble subarchiteclure o f the product-line archi tecture corresponds to a subse t of the product line's modules plus all o f the modules' dependencies. We wan t to limit a rchitectura l extensions to those whose effects o n the architecture's dependen cy graph a re stricll y a dditive. In o ther wo rds, we seek only those extensions that aug- ment the product line's depe ndency graph with new nodes such that all new de pendencies o riginate from the ne w no des..

Docume nting a product-line architecture is differen t from docwnen ting the architecture for a specific system, because the prod uct line is no t in itself a prod uct. R athe r, it is a means for rapidly de riving products. Thus, its docwnentation focuses on the range o f pro ducts tha t can be d erived fro m the pro duct line, the points of variability in the prod uct-Line a rchitecture, and the mechanisms for deriving family members. The docume ntatio n of a give n product is then re duced to a descripti on o f how it d iffers from o r insta ntiates the product-line architecture, in terms o f specific feature sets, com- ponent instances, subclass d efinitions, paramete r values, and mo re.

Product-Line Evolution

Afte r s tudying seve ra l industrial examples, Cle me nts (Bass, Cle me nts, and Kazmao 2003) concl udes that the most important contributor to product-line success is having a producl-line mindset. That is, the co mpany's primary focus is o n the developme nt and e vo lutio n o f the product-Line assets, rathe r than on individual products. Product-line changes are made for the purpose of improving the capabili ty to de rive products, while re maining backwards compatible with previous products (i.e., previous products are still derivable). Thus, no product is de veloped or e volves separate ly from the product

284 Chapter 5 Designing the Architecture

line. In this sense, a company with a product line is like the farmer with a goose that Jays golden eggs. Instead o f focusing o n the eggs, the company nurtures the goose, so that it wiU continue to lay gold en eggs for years to come .

5.11 INFORMATION SYSTEMS EXAMPLE

So, what might be a suitable software architecture for the Piccadilly system? Certainl y a key compo nent wo uld b e the re pository of info rmatio n that needs to be maintained a bout Lelevision programs, program scheduling, comme rcial s po ts, agreements, and so o n. In addition, the syste m s ho uld be able to process multiple he terogeneous queries on this informatio n, in parallel, so that the info rmation can be kept up-to-date and can be used to make important decisio ns a bout future comme rcial campaigns.

A typical reference architecture for an information o r business-processing system is an n-tiered client-server a rchitecture (Morgan 2002). Such an architecture for our Pic- cadilly system is depicte d in Figure 5.19. The bottom laye r is a data server that simply maintains all the info rmation that Piccadilly must track for its own business as we ll as information about its compe tito rs. The application programming interface (API ) for this layer is likely to consist of basic queries and updates on these data. The middle layer con- sists of application se rvices that provide richer, m ore application-specific queries and updates on the lower-level data. An example of an application-specific query might be to find all television programs that air at the same time as some Piccadilly program. The top layer of the architecture consists of the user interfaces through which Piccadilly's man- agers, accountants, te le vision-programming specialists, and sales force use the informa- tion system.

In addition to the high-level architecture of the system, we also need to provide some details about each of the components. For example, we need to describe the data and rel.ations hips that the da ta serve r is to maintain, the applica tion services that the application layer is to maintain, and the user interfaces that the presentation laye r is to

KEY

I

Pro91111 Pirehuln9

.. tY., I mlynr

D1t1bm Sernr

reqmt/reply

FIGURE 5.19 N-tier architecture of the Piccadilly system

Openmirrors.com

Cllut Prueiutlon

Bllllng ud Bu1lne1t Aceout1n9 lo~lc

lnfonn1tlon Sy1te111

Section 5 .11 Information Systems Example 285

Asmy Uvertltln9 C1111pal9n fttlU 0 .. 1 coo1d 111111 o .. * •111p1i91 au11bor

~ tddms t91ncy c1np1l9n rhrt •••• Ce11111ml1I phone 1UNb11 ....... UIH

duntioa dlepoul ••tt ld51t ... , •• 11di111e1 111511 nti19 '•ru1t19• 11quir1d 1p1t •mtiu

14' co111Nercl1I() llNOVI COl!INercl1I() bllld en1pa19n() ptlCI 11nip1l9n()

t Program Co1111111rcl1I S~ot

1udlenc1 type duttlon

I schedule~ ~nt

* mocl111d with Coon111rcl1I Bruk Riie S19on1nt

Eplude * * dtte dty of week

pmen1191 of 1ud111ce 11u1 tine u91111nt tine tyte .. , llNI niootblllty

sold value rpot 1111 u~rold v1lue

NlllN1n "" ulc prlee(J prtdlclld 11t1n9

ru11• fl fl1d ilNt()

FIGURE 5.20 Partial domain model of the Piccadilly system.

provide. The domain mode l that we created in Chapte r 4, as part of our elaboration of the system's re quire ments, can form the basis of the data model for the data serve r. The model is reproduced in Figute 5.20. We augment this model with additional concepts and relationships that arise as we work out the details of the application services. For e xample, a high-level description of the query to find the television programs that are aired at the same time as PiccadiJly programs might look like the following:

Input: Episode For each Opposition television company,

For each Programming schedule, If Episode schedule date = Opposition transmission date

AND Episode start time = Opposition transmission time Create instance of Opposition program

Output: List of Opposition programs

This functio n suggests new e ntities and relationships to lbe added to our data model, such as the concept of an opposition company. Each opposition company broadcasts its

286 Chapter 5 Designing the Architecture

Oppo11tlon Opposition Program

n1me 1..* broadcasts * pro9ram name a4dress shtion pro5ram transmission 4ate phone nwmber transmission start time

transmission end time transmission 4uration predicted rating

FIGURE 5 .. 21 Newly identified concept of 0pposi ti on programs.

own programs, and each program has a time and date . We include this information in tbe data mode l, so that o ur system is able to issue queries on programs tbat air on com- peting s tations. These ne w concepts are shown in iFigure 5.21.

In addition, we need to tbink about how well our architecture meets any nonfunc- tional requirements that have been s pecified. For e xample, if the speciali sts in cha rge of te levision programming want to use the system to explore how diffe rent broadcasting scheduJes affect predicted ratings and corresponding prices of commercial spots, the n our architecture needs to support the ability to undo edits. As another example, secu - rity may be a concern. We want to ensure tbat the compe tition cannot break into the system and access Piccadilly's business plans or proposed prices.

These models and descriptions are clearly high level. Architecture focuses on design decisions that re quire conside ratio n of rnuJtiple components and their inter- actions.. In C hapter 6, we narrow o ur focus to the mo re detailed design of individual components-{!(}Cb of which we are able to consider in isolation.

5.12 REAL-TIME EXAMPLE

One of the findings of the inquiry board that was set up to investigate the Ariane-5 acci- de nt was that the Ariane program in general had a "culture ... of o nly addressing ran- do m hardware failures" (Lions et al. 1996) and of assuming that seemingly correct software was in fact correct. The board came to this conclusion partly because of the way the Ariane-S's fauJt-recovery system was d esigned. The Ariane-5 included a num- be r of redundant compo nents in which both the ha rdware equipment and the associ- ated software were identical. In most cases, o ne o f the compo ne nts was s upposed to be active; the o the r was to stay in "hot standby" modle, ready to become the active compo- nent if the current activ'e component failed. But this architecture is not a good cho ice for this kind of system, b ecause hardware failures are very different from software fail- ures. Hardware failures are independent: if o ne unit fails, the standby unit is usually unaffected and can take over as the active unit. By contrast, software faults tend to be logical e rrors, so all copies of a software component have the same set of faults. More- o ve r, even if the software is not the underlying cause o f a failure, repli cated software components are like ly to exhjbit the same bad behavio r in response to bad input. For these re asons, the hot sttandby redundancy in Alriane-5 is Likel y to recover only from hardware failures.

To see why, consid er Table 5.5's List of sources of software failures (NASA 2004). Some of the software faults are internal to lhe software itself, and some are caused by

Openmirrors.com

Section 5.13 What This Chapter Means for You 287

TABLE 5.5 Causes of Safety-Related Software Failures (NASA 2004)

Software Faults

Data sampling rate Data collisions lllegal commands Commands out of sequence Tune delays, deadlines Multiple events Safe modes

Failures in the Environment

B roken sensors Memory oveiwritten Missing parameters Parameters out of ran ge Bad input. Power Huctuations Gamma radiation

input errors o r erroneous events in the environment. Regardless of the source, most types of faults would adversely affect all instances of replicated software compone nts tha t are processing the same input at the same time (with the excepti on o f ga mma radi- atjon, wruch is a se rio us conce rn in software on spacecraft). As a result, softwa re !fail- ures among replicated compone nts in hot standby mode are rare ly independent. lb.is was the situation with the fa iled ine rtial refe re nce systems (SRis) o n the Ariane-5: both units Slllffered the same overflow e rror, simultaneously.

The manner in which SRI proble ms were handled is another factor that con- tributed to the Aria ne-5 accident. A key design decision in any software architecture is de termining which component is responsible for handling problems that occur at run- time. Sometimes the com pone nt in which the problem occurs has information about its ca use and is best sw ted to address it. However, if a problem occurs in a service compo- ne nt, it is o ften the clie nt compo nent (which invoked the service) that is responsible fo r deciding how to recove r. With this strategy, the client can use contextual informail:ioo about what goals it is trying to achieve whe n it determines a recovery plan. In the Ariane-5, the planned exception-handling strategy for any SRI exception was to log the e rror and to shut down the SRI processor (Lions et al. 1996). A s we saw earlie r in tills chapter, shutting down o r re booting is an extre me e rror-handing strategy that is not advisable in critical syste ms. Another recovery strategy, such as working with the maxi- mum va lue that the affected data variable wo uld allow, migh t have kept the software opera ting well eno ugh fo r the rocke t to have achieved orbit.

5.13 WHAT THIS CHAPTER MEANS FOR YOU

In tbis cha pte r, we have investigated what it means Lo design a system based o n care- fully expressed req uire ments. We have seen that d esign begins with a high-level archi - tecture, where architectura l decisio ns a re based not only on syste m functionality and req uired constraints but also on desirable attributes and the lo ng-tterm intended use of the system (including p roduct lines, reuse, and like ly modificatio n). You should keep in mind several characteristics of good architecture as you go, including appropriate use r interfaces, performance, modularity, security, and fa ult tolerance. You may want to build a prototype to evaluate seve ral options or to demonstrate possibilities to your custome rs.

The goa l is not to design the ideal software architecture for a system, because such an architecture might no t even e xist. Rather, the goal is to design an architecture

288 Chapter 5 Designing the Architecture

tbat meets all of the customer's requirements while staying within the cost and scbed- ule constraints that we discussed in Chapter 3.

5.14 WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM

There a re many team activities involved in architecture and design. Because designs are usuall y expressed as collections of compo nents, the inte rrelationships among com- ponents and data must !be well documented. Part of tbe design process is to have fre- que nt discussions with other te am members, no t onJy to coordinate how diffe rent components will inte ract but also to gain a bette r unde rstanding of the requirements and of the implications o f ea ch design decisio n you make.

You must also work with users to decide how to design the system's interfaces. Yo u may develop seve ral prototypes to show use rs the possibilities, to dete rmine what mee ts perfo rmance requirements, or to evaluate fo r yourseli the best " look and feel."

Your choice o f architectural strategy and d ocumentation must be made in the context of who wiU read your designs and who must understand them. Mappings among views help explain which parts of the desig n affect which componen ts and data. It is essential that you document your design clearly and comple tely, with discussions of the o ptions you had and the choices you made.

As a te am me mbe r, you will participate in architectural revie ws, evaluating the architecture and making suggestions fo r improvement. Remembe r that you are criti ciz- ing the architecture, not the architect, and that software development works best when egos are le ft o ut of the discussion.

5.15 WHAT THIS CHAPTER MEANS FOR RESEARCHERS

The architectures in this chapter are depicted as simple box-and-Line diagrams, and we no te that the modeling techniques discussed in Chapte rs 4 and 6 may also be useful in modeling the syste m. However, there are seve ra l drawbacks to representing the system o nJy with diagrams. Garlan (2000) points o ut that informal diagrams cannot e asil y be evaluate d for consistency, correctness, and completeness, particuJarly whe n the system is large or complex. Neithe r can desired architectura l properties be ch ecked and enforced as the syste m evolves over time. Thus, many researche rs are investi gating the cre ation and use of fo rmal languages for expressing and ana lyzing a software architecture. These Architectural Description Languages (ADLs) include three things: a framework, a notation, and a syntax for expressing a software architecture. Many also have associated tools fo r parsing, displaying, analyzing, compiling, o r simulating an architecture.

The ADL is o fte n specific to an applicatio n do main. For instance, A d age (Coglia nese and Szymanski 1993) is inte nded for use in describing avionics navigation and guidance, and Darwin (Magee et al. 1995) s uppo rts distributed message-passing syste ms. Researchers are also investigating ways to integrate various architectural tools into high.e r-level architectural environments, some o f which may be domain specific. And o ther researchers are mapping ADL concepts to object-based approaches, such as the UML (Medvidovic and R osenblum 1999) .

Another area ripe for research is bridging tbe gap across architectural styles. Sometimes systems are developed from pieces that are specified in different ways.

Openmirrors.com

Sectio n 5.16 Term Project 289

DeLine (2001) a nd o the rs are examining ways to translate a collection o f different pieces into a mo re cohe rent who le.

Finally, researchers are continually challenged by systems that are " ne two rk cen- tric," ha ving little or no centralized control, confo nning to few standards, and varying wide ly in ha rdware and applicatio ns from o ne use r to anothe r. "Pe rvasive computing" adds complications, as users are e mploying diverse devices that were not designed to inte rope rate, and even moving a round geographicaUy as they use them. A s Garlan (2000) po ints o ut, this situa tion presents the following four problems:

• Archi tectures must scale to the size and variability of the Interne t. Traditio nally, one " assumes that e ve nt delivery is reliable, that centralize d routing of messages wilJ be sufficie nt, and that it makes sense to define a common vocabulary of events that a re understood by a ll of the componen ts. In an In ternet-based se tting, au o f these assumptions are questionable."

• Software must ope rate o ver " d ynamica ll y forme d, task-specific coaliti ons o f di s- tributed auto no mo us resources." Many of the Internet's resources are "indepen- de ntly de ve lo ped a nd independe ntly suppor ted; they may even be transient," but the coalitio ns may have no control over tlhese independent resources. Indeed , "selectio n and composition o f resources [a re] likely to be d one afresh fo r e ach task, as resources a ppear, change, and disappear." We will need new techni q ues for managing architectural mo de ls at runtime, and for evaluating the properties of the systems they describe.

• We will need flexible architectures tha t accommoda te services p rovided by pri- va te industry, such as billing, security, and communications. These applications are lik ely to be composed fro m both local and remote computting capabilities and o ffered at each user 's desktop, which in turn ca n be built from a wide variet y of ha rdware and software.

• End use rs may wa nt to compose systems themselves, tailo ring available applica- tio ns to their particula r needs. These use rs may have very little experience in building systems, but they still want assura.nces that the composed systems wiU pe rform in expected ways.

We a re designing systems tha t a re larger a nd mo re comple x than ever before. Northro p e t al.'s re por t (2006) o n ultra-large scale systems explains our aeed to de velo p huge systems with thousa nds o f sensors and decision no des that are connected through he terogeneous and o pportunistic networks and that adapt to unforeseen changes to their environment. These systems will need special arclhitectural conside ra - tio ns, because current testing techniques will not wo rk. Shaw (2002) discusses why it will be iimpossible for such systems to be absolutely correct, and that users and deveiop- e rs will need to soften their views and e xpectations abo ut correctness. She suggests !that we strive instead fo r sufficie nt correctness.

5.16 TERM PROJECT

Architecture is as much an artistic and creative endeavor as an e ng ineering one. Difie r- e at expert architects caa take very diffe rent approaches to how they conceive aad

290 Chapter 5 Designing t h e Architecture

docume nt their designs, with the results of each be ing solid and elegant. We can think of architects approaching their j obs alo ng a continuum, fro m what is called task-cente red to user-ce ntered design. Task-centered design begins with thinking about what the sys- tem must accomplish. By contrast, user-centered design begins with the way in which a use r in teracts with the syste m to pe rfo rm the req uired tasks. The two are no t mumall y e xclusive and indeed can be comple mentary. Ho wever, o ne design philosophy often do mina tes the other.

As pa rt of your te rm project, de velo p two di ffe re nt architectural a pproaches to the Loan Arranger: one that is task cente red and o ne tha t is use r ce ntered. What archi- tectural style(s) have you chosen fo r each? Compare a nd contrast the results. Which architecture is e asie r to change? To test? To configure as a product Line?

5.17 KEY REFERENCE S

There are many good books about softw are architecture. The first one you should read is Shaw and Garlan (1996), to provide a good founda tion for how you learn about architecture and design. This and othe r books can act as architectural style catalogues, including Buschmann et al. (1996) and Schmidt e t al. (2000). Ther e are several books that address particular kinds of architectures: Go maa (1995) fo r re al-time systems, Hix and Hartson (1993) and Shneiderman (1997) for inte rface d esign, and Weide rhold (1988) for databases, for example.

More generaUy, H ofmeister, Nord, and Soni ( 1999) and Kazman, A sundi, and Klein (2001) discuss how to make a rchitectural desig n d e cis io n s, and C le m e nts e t a l. (2003) and Krutche n (1995) address the best way to document an architecture. In addition, the IEEE and other standards organizations pu blish various architectural standards.

You can read several product-line success stories at the Product Line Hall of Fame We b site (http://www.sei.cmu.edu/productliines/plp_hof.btml), maintained by the So ftware Engineering Institute (SEI) .

Scott Amble r has written extensively abo ut the views o f propo nents of a gile me thod s on architecture and agile modeling. See bis Web site (http://www.agilemo del ing.com) and his book on agile modeling (Ambler 2002).

5.18 EXERCISES

1. What type of architectural style is represented by the NIST/ECMA model (shown in Figure 5.22) for environment integration? (Chen and Norman 1992).

2. For each of the architectural styles described in this chapter, give an example of a r eal- world application whose softwa re design might incorpo ra te that style.

3. R eview the four different archite ctural styles proposed by Shaw and Garlan (1996) to imple ment KW1C: repository, da ta abstractio n , implicit invocatio n (a type of publish- subscribe ), and pipe-and-filter. Fo r e ach o ne, are the high-level components likely to have high or low cohesio n and coupling?

4. G ive an example of a system for which d eveloping a prototype would no t result in saving a significant amount of d e velopment time.

5. List the characteristics o f a system for which prototyping is most appropriate.

Openmirrors.com

FIGURE 5.22 NlST/ECMA model.

Section 5.18 Exercises

Repos1itor¥ services

User interlace services

Rlti;,c.., ....... ,~

""'II I

291

6. Explain why modularity and application generators are inseparable concepts. Give an example of an application generator with which you have worked.

7. Explain why a shared data architecture is not easy to reuse.

8. List the ch aracteristics you might include in an architecture evaluation table similar to Table 5.2. For each of the following systems, identify the weights you might use for each characteristic: an operating system, a word processing system, and a satellite tracking system.

9. Many of your class projects require you to develop your programs by yourself. Assemble a small group of stude nts to perform an architectural review for one such project. H ave seve ral students play the roles of customers and users. Try to express all the requirements and system characteristics in nontechnical terms. List an the changes that are suggested by the review process. Com pa re the time required to make the changes at the architecture stage to that of changing your existing programs.

10. You have been hired by a consulting firm to develop an income tax calculation package for an accowiting firm. You have designed a system according to the customer's require- ments and presented your design at an architectural review. Which of the following ques- tions might be asked at the review? Explain your answers.

(a) What computer will it run on? (b) What will the input screens look like?

(c) What reports will be produced? (d) How many concurrent users will there be?

(e) Will you use a multiuser operating system?

(I) What are the details of the depreciation algorithm?

11. For each of the systems described below, sketch an appropriate software architecture and explain how you would assign key functionalities to the d esign's components.

292 Chapter 5 Designing t he Architecture

(.a) a system of au tomated banking machines, acting as distributed kiosks that bank customers can use to deposit and withdraw cash from their accounts

(b) a news feeder that notifies each user of news bulletins on topics in which the user has expressed an inte rest

(c) image-processing software that allows users to apply various opera tions to mo di fy their pictures (e.g., rotation, colo r tinting, cropping)

( d) a weather forecasting application that analyzes tens of thousands of data elements collected from various sensors; the sensors periodically transmit new data values

12. Propose a redesign of your software a rchitecture for the syste m of automated bankin g machines from the previous exercise so that it improves performance. Propose an alter- nate redesign that improves security. Does your strategy to improve performance adversely affect security, or vice versa?

13. Suggest how the weather forecasting application in exercise ll(d) might detect faults in its data sensors.

14. D erive the cut-set trree for the fault tree given in Figure 5.11. 15. Table 5.4 shows a cost-benefit analysis fo r three compe ting design proposals. The compu-

tation of benefits is based on projections that the rate of queries could increase to a peak of 200 queries per second. Suppose that, due to increased competition by other on-line com- panies, more recent projections estimate that the re will never be mo re than 150 queries per second. How does this new information affect the original cost-benefit analysis?

16. Your university wants to automate the task of c hecking that students who are scheduled to graduate have actually satisfied the degree requirements in the ir respective majors. A k ey challenge in automating this task is that every degree major has its own unique re quirements. Study the degree requirements o f three disciplines at your university; iden- tify which graduation require ments they have in common and where they dive rge. D escribe how the variability might be gene raliized so that checking the degree require- ments of each major can be derived from the same product line.

17. D esign a simple full-screen editor on a video display t erminal. The editor allows text t o be inserted, deleted, and modified. Sect.ions of text can be " cut" from one part of the file and " pasted" to another part of the file. The user can specify a text string, and the editor can find the next occurr,ence of that string. Through the editor, the user can specify margin set- tings, page length, a nd tab settings. Then, evaluate the quality of your design.

Openmirrors.com

6

In this chapter, we look at • design principles • object-oriented design heuristics • design patterns • exceptions and exception handling • documenting designs

In the last chapter, we looked at strategies and patterns for creating a high-level archi- tectural design of our software syste m. This type of design identifies what the system's majo r compo ne nts will be, a nd how tbe components will inte ract with each othe r and share information. The next ste p is to add more detail , deciding bow the individual compo ne nts will be designed at a moduJar level so that develo pers can write code tha l imple ments the design. Unlike architectural design, where we have architectural styles to guide o ur design work , tbe process of creating a mo re detaile d design offe rs us fewer ready-made soluti o ns fo r how to decompose a compone nll: into moduJes. Thus, module- level design is Ukely to invo lve more improvisati on than architectural design does; it relies o n bo th innovatio n and continual evaluation of our design decisions, and we pay ca reful attention to design principles and conventi ons as we proceed.

In this cbapte r, we summarize the abundance of module-le vel design advice that exists in the literature. We begin with design principles: general p roperties of good designs that can guide you as you create your own designs. Then, we presen t se vera l design he uristics and patterns that are particularly useful for object-orie nted (00) designs. 00 notations and programming languages were developed specifically to e ncode and promo te good design principles, so it makes sense to look at how to use these techno log ies to their best advantage. We also look at documenting a module -le vel design in a sufficiently precise way that allows the design to be impleme nted easily by o ther developers.

Your e xperi ence with mo dule- level design fro m your pre vious programming courses may he lp you to understand this chapte r. The desig n advice we include is based o n the collec tive e xperie nce o f a wide variety o f develo pers building many types o f sys- te ms. We have chosen advice based on quality attributes that the design is to achieve, such as improving modularity o r ensuring robustness. This chapte r ca n help you see

293

294 Chapter 6 Designing the Modules

why ce rtain design principles and conventio ns are applicable, and the n assist you in deciding when you shoulld apply them.

To iUustrate design choices, concepts, and p rinciples, we introduce an example : automating a business, the Royal Service Station, that services automobiles. This e xample e nabl es us to see that designing modules must retlecL not only technological options but also business constraints and developer experience. Some aspects of our example were originally developed by Professor Guilherme Travassos, of COPPE/ Sistemas at the Federal University of Rio d e Janeiro, Brazil. Mo re details plus o ther exampl es are available at Prof. Travassos's We b site : bltp://www.cos.ufrj.br/-ght.

6.1 DESIGN METHODOLOGY

At this point in the development process, we have an abstract description of a solution to our customer's problem, in the form of a software architectural design. As such, we have a plan for decomposing the design into software units and allocating the system's functional requirements to them. The architecture also specifies any protocols that constrain how the units interact with each other, and specifies a precise inte rface for each unit. Moreover, the architectural design process bas already resolved and documented any known issues about data sharing and about coordination and synchronization of concurrent compo- nents. Of course, some of these decisions may change when we learn more about designing the individual software units. But at this point, the syste m's design is complete enough to allow us to treat the designing of the various units ais independent tasks.

In practice, there is no sharp boundary between the end of the architecture-design phase and the start of the module-design phase. In fact, many software architects argue that a software architecture is not complete until it is so detailed that it specifies all of the system's atomic modules and interfaces. However, fo r the purposes of project manage- ment, it is convenient to separate design tasks that re quire consid eration of the entire system from design tasks that pertain to individual software units, because the latter can be parUtioned into distinct work assignments afild assigned to separate design teams. Thus, the more we can restrict ourselves during the architecture-design phase to ide nti- fying the major software units and the ir interfaces, the more we can paralle lize the rest of the design work. This chapter focuses on the detailed design of a well -defined archi- tectural unit, looking at bow to decompose the unit into constituent modules.

Once again, the software architecture-desig111 decisions correspond to meal pre pa- ration decisions: degree of formality, numbe r o f guests, numbe r of courses, culinary theme (e .g., Italian or M exican), and perhaps maiin ingredie nts (e.g., meat or fish in the main course, and which seasonal vegetables). These decisions he lp to scope the set of possible dishes that we could make. And, like a r,chitectural decisions, they are funda- me ntal to the planning and preparation of the e!lllire mea l; they are difficu lt lo cha nge in the middle of cooking. Plenty of open design questions will remain , such as which specific dishes to prepare, cooking methods for the meats and veg etables, and comple- mentary ingredi ents and spices. These secondary decisions tend to app ly to speciflc dishes rather than to the whole meal; they ca n b e made in isolation or delegated to other cooks. However, secondary decisions still require significant knowle dge and expe rtise, so that the resulting dishes are tasty and are ready at the appropriate time.

Openmirrors.com

Section 6.2 Design Principles 295

Altho ugh the re are many recipes and instructio nal videos to show you how to move from ingredie nts to a complete meal , there are no comparable design recipes for progressing from a software unit's specification to its modular d esign. Many design method s advocate to p-d own design, in which we recursively decompose design ele- ments into sma lle r constitue nt e leme nts. H oweve r, in reality, designers altern ate am ong top-do wn, bo tto m-up, and o utside-in design me thods, sometimes focusing on parts of the design that are less we ll understood and at other times Heshing out details with which th ey a re fa miliar. Krasne r, Curtis, and Iscoe (1987) studied the habits of develop- e rs o n 19 projects; they repo rt, and o the r eviden ce confirms, that designe rs regularly move up and down a design's levels of abstractions, as they understand more abo ut the solutio n and its implications. Fo r example, a design team may start off using a top-do wn method or an outside-in me thod that focuses first on the system 's inputs and expected o utputs. AJte rnative ly, it may make sense to explore the hardest and most uncertain areas of the design first, because surprises that arise in clarifying an obscure problem may force changes to the ove rall design. If we are using agile me thods, then the design progresses in ve rtical sli ces, as we ite ratively design and impleme nt subse ts o f features at a time. Whe neve r the design te am recognizes that known design solutions mig ht be useful, the team may switch to a botto m-up design approach in which it tries to tackle parts o f the design by applying and adapting pre packaged solutions. Periodically, design decision s are revisited and revised, in an activity called refacto ring, to simplify an o verly complic ated solution or to optimize the design for a particular quality attribute.

The process we use to wo rk towards a final solution is not as important as the d oc- umenta tion we produce so that o the r designers can unde rstand it. lllis understanding is crucial no t o nly fo r the programme rs who will imple ment the design but also fo r the maintaine rs who will ch ange it, the testers a nd reviewers who will e nsure that the design imple ments the re quire ments, and the specialists who will write user docume n- tation d escribing ho w the system works. One way to achi eve this understanding is by " faking the rational design process": writing the d esign documentation to reflect a top - do wn d esign process, even if this is no t how we arrived at the design (Parnas and Cleme nts 1986), as described in Side bar 6.1. We discuss design documentati on in more de tail in Sectio n 6.8.

6.2 DESIGN PRINCIPLES

With cle ar requireme nts and a high-leve l syste m architecture in hand, we are ready to add de tail to our design. A s we saw in Chapte r 5, architectural design can be expressed in te rms of architectural sty les, each o f which provides advice abo ut decomposing the system into its majo r compo nents. Architectural styles help us to solve generic prob- lems of communication, synchronization, and data sharing. H owever, once we focus on decomposing individua l compone nts a nd software units into mo dul es, we must address functio n ality a nd pro pe rties that are no longe r ge neric; rathe r, they are specific to our design p roble m and the refore are less likely to have ready-made solution s.

D esig n principles a re guidelines for decomposing our system 's required function- a lity a nd behavior into modules. In p a rticul ar, they identify the crite ria that we sho uld use in two ways: fo r decomposing a system and then fo r deciding what information to

296 Chapter 6 Designing the Modules

SIDEBAR 6.1 "FAKING" A RATIONAL DESIGN PROCESS

In an ideal, methodical, and reasoned design process, the design of a software system would progress from high-level specification to solution, using a sequence of top-down, error-free design decisions resulting in a hierarchical collection of modules. For several reasons (e.g.,

poorly understood or changing requirements, refactoring, human error), design work rarely

proceeds directly or smoothly from requirements to modules. Nonetheless, Pamas and

Clements (1986) argue that we should behave as if we are following such a rational process:

• The process can provide guidance when we are unsure of how to proceed.

• We will come closer to a rational design if we attempt to follow a rational process.

• We can measure a project's progress against the process's expected deliverables.

Parnas and Oements suggest that we simulate this behavior by "writing the documenta-

tion that we would have produced if we had followed the ideal process." That is, we document

design decisions according to a top-down process by (1) decomposing the software unit into

modules, (2) defining the module interfaces, (3) describing the interdependencies among mod-

ules, and, finally. (4) documenting the internal designs of modules. As we take these steps, we insert placeholders for design decisions that we put off. Later, as details become known and

deferred decisions are made, we replace the placeholders with the new information. At the same time, we update documents when problems are found or the design is revised. The result

is a design documenc that reads as if the design process were purely top-down and linear.

The distinction between the actual design process and the ideal one is similar to the dis-

tinction between discovering the main steps of a new mathematical proof and later fornm- Jating it as a logical argument. "Mathematicians diligently polish their proofs, usually

presenting a proof [in a published paper that is] very different from the first one that they dis- covered" (Parnas and Clements 1986).

pro vide (and what to conce al) in the resulting modules. Design principles are use ful when creating innovative designs, but they have other uses too, especially in forming the basis for the design advice that is package d as design conventi ons, design patterns, and architectural styles. Thus, to use styles and patterns effectively, we must understa nd and appreciate their underlying principles. Othe rwise, when we define, modify, and e xte nd patte rns and styles to fit our needs, we are Like ly to vio late the very principles that the conve ntions and patte rns engende r and promote.

The collection o f software design principles grows as we ·'encode" our collective experie nce and obse rvations in ne w design advice . For example, Davis (1995) proposes 201 principles of software developme nt, many of which are design relate d. In this book, we restrict o ur discussion to six dominant principles: modularity, interfaces, information hiding, incremental development, abstraction, and generality. Each seems to have stood tbe test of time and is independent of style and metbodology. Collectively, tbey can assist us in building effective, robust designs.

Openmirrors.com

Section 6.2 Design Principles 297

Modularity

M odularity, also called separation of concerns, is the principle of keeping separate the vario us unrelated aspects of a system , so that each aspect can be s tudied in isolation (Dijkstra 1982). Concerns ca n be functions, data , features, tasks, qualities, or any aspect of the re quire me nts or d esign that we want to define or unde rstand in more de tail. To build a modular design, we decompose our system by identifying thte system's unrelated conce rns and e ncapsulating e ach in its own mod ule. If the principl e is applied we ll , e ach resulting module will have a s ingle purpose and will be relatively inde p e ndent of the othe rs; in this way, each module will be easy to understand a nd de velop. Module inde - pendence also makes it easier to locate faults (because there are fewer suspect modrules pe r fa ult) a nd to change the system (because a change to one module affects relatively fe w other modules).

To dete rmine how well a design separates concerns, we use two concepts that m ea- sm e module independe nce: coupling and cohesion (Yourdon and Constanti ne 1978).

Coupling. We say that two mo dules are tightly coupled when they depend a great dea l o n each o t her. Loosely coupled m odules have some dependence, but tlheir inte rcol!lllections are weak. Uncoupled modules have no inte rconnections at all; they are comple te ly unrelated, as s hown in Figure 6.1.

There are ma ny ways that mo dules can be de pe ndent on each othe r:

• The references made from one module to another: M odule A may invoke opera- tions in module B, so module A de pe nds on module B for comple tion of its func- tion or process.

• The amount of data passed from one module to another: Modu le A may pass a paramete r, the contents of an array, o r a block of data to module B.

DD DD

loosely coupled • nr11 depend11el11

FIGURE 6.1 Module coupling.

Umupled · no d1p1nd1n1ln

Tl9~tly m pied 1111ny dependencies

298 Chapter 6 Designing t he Modules

TIC HT COU PLI NC

C011•u eoupll19

Coetrtl cou,1119 LOOSE COU PLI NC

Sta111p m,1119

LOW COUPLINC

FIGURE 62 l}'pes of coupling.

• The amount of control that one module has over the other: Module A may pass a con- tro l Jlag to module B. The value of the Jlag tells module B th e state of some resource or subsystem, which proce dure to invoke, o r whether to invo ke a procedure at aJl.

We can measure couplin g along a spectrum o f dependence, ranging from complete dependence to com plete independence (uncouple d), as shown in Figure 6.2.

In actuality, it is unlikely that a system wouJd be built of completely uncouple d modules. Just as a table and chairs, although imdepe ode nt., can combine to form a dining-room set, context can indirectly cou ple seemingly uncoupled modules. For e xampl e, two unrelated fe atures may interact in such a way that one fe ature disabl es the possible execution of the other feature (e.g., a n autho rization feature that prohibits an unautho rized user from accessing protected services). Thus, our goal is not necessar- ily to have comple te independence among mo dules, but rather to keep the degree of their coupling as low as p ossible.

Some types of coupling are less desira ble tlllan o the rs. The least desirable occurs whe n o ne module actually modifies another. In such a case, the modified module is com- ple te ly d ependent on the modifying o ne. We ca ll this content coupU ng. Conte nt coupling might occur when one m oduJe is imported into a nother module, modifies the code of another module, or branches into the middle o f ano ther module. In Figure 6.3, module B generates and then invokes module D. (This situatio n is possible in some programming

FIGURE 6.3 Example of content coupling.

MoMt 8

Gen111t1 D---------- Ctll D

Openmirrors.com

Modul• D

--------

Section 6 .. 2 Design Principle s 299

languages, such as LISP and Sch eme.) Although self-mo difying code is an extremely powe rful tool for implementing programs that can improve the mselves o r learn dynam- ically, we use it knowing the conse quences: the resulting mo dules are tightly coupled and canno t be designed o r modified inde pendently.

We can reduce the amo un t of coup ling some what by organjz ing our design so tha t da ta are accessible from a common data store. However, depe ndence still e xists: mak- ing a change to the commo n data means that, to evaluate th e effect of the change, we have to loo k at all modul es that access th ose data . This !kind of dependence is called common coupling. With common coupling, it can be difficult to determine which mod- ule is respo nsible fo r having se t a variable to a particular value. Figure 6.4 shows how common coupling wo rks.

When one module p asses parame ters o r a return code to control the behavior of a no the r module, we say that there is control coupling between the two. It is impossible for the controUed module to functio n with out some directio n from the controlling module. If we employ a design with control coupling, it helps if we limi t each module to be respo nsible fo r o nly one function or one activity. TIUs restriction minimizes the amo unt o f information that is passed to a controlled module, a nd it simplifies the mod- ule's interface to a fixed and recogniza ble set of p ar ame te rs and re turn va lues.

When complex data structures are passed between m odules, we say the re is stamp coupling between the modules; if only data values, and no t structured d ata, are passed , the n the modul es are connected by data coupling. Stamp coupling represents a more complex inte rface be tween modules, because the modules h ave to agree o n the data's fo rmat and o rganiza tion.111us, d ata coupling is simple r and less likely to be affected by changes in data representation. H coupling must exist between modules, da ta coupling

Module X

Glohlt: At A2 A3

V1 rl1bl11: Vt V2

Module V

lnu1111nt@

Com 1101 d1u tru

ModQle Z

@ ~ V2 + A1

FIG URE 6.4 Example of common coupling.

300 Chapter 6 Designing the Modules

is the most desirable; it is easiest to trace data through and to make chan ges to data- coupled modules.

Objects in an 00 design often have low coupling, since e ach object contai ns its own data and operations on those data. In fact, one of the objectives of the 00 design me thod ology is to promote loosely coupled d esigns. Ho wever, basing our desig n on o bj ects does not guaranttee that au of the modules in the resulting design will have low coupLing. For example, if we create an object that serves as a common data store that can be manipulated, via its me thods, by several o ther o bjects, then these o bjects suffer from a fo rm of common coupling.

Cohesion. In contrast to measuring the inte rde pendence among multiple mod- ules, cohesion refers to tlhe dependence within and amo ng a module's inte rnal eleme nts (e.g., data, functions, inte rna l modules). The more cohesive a module, the more closely re lated its pieces are, bo th to each o the r and to the module's singular purpose. A mod- ule that serves multiple purposes is at grea ter risk of its elements needing to evolve in differe nt ways or at diffe rent rates. For e xample, a module that encompasses both data and routines for displaying those data may change frequently and may grow in differ- e nt dfrections, as new uses of the data require bo th new functions to manipulate data and new ways of visuaLizing them. Instead, o ur d esign goal is to make each module as cohesive as possible, so that each module is easie r to understand and is less Like ly to change. Figure 6.5 shows the several types of cohesion.

The worst degree of cohesion, coincide ntal, is found in a module whose parts are unrelated to one anothe r. In this case, unrelated functions, processes, or data arc com- bined in the same modnle for reasons of convenie nce or se rendipity. For example, it is not uncommo n for a me diocre design to consist of seve ral cohesive modules, with the rest of the system's functio nality clumped together into modules MiscellaneousA and MiscellaneousB.

A module has logical cohesion if its parts are related only by the logic structure of its code. As an example, shown in Figure 6.6, consider a template module or procedure that pe rforms very different operations depe nding on the values of its parameters. Altho ugh the different o perations have some cohesio n, in that they may share some

FIGURE 6.5 Types of cohesion. LOW COHESION

Celncl4uul

L9'1ul

r •• ,.,.1 Prou4urtl

C.m111,nleatlonal

Fuctlenal

lnfen11tleul

Hlc;H COHESION

Openmirrors.com

Mod1le X (pirnl, pum2, ••• , pir111N )

If (pir111I = I)

1 lulf (p11111I = 2)

If (p1rll12 = I)

Section 6 .. 2 Design Principles 301

P111n1te1lzed code

------j- Co111111on code

FIGURE 6.6 Example of logical cohesion.

program stateme nts and code structure, this cohesion of code structure is weak compared to cohesion of data, function, or purpose. It is likely that the different operations will evolve in diffe re nt ways over time, and that this evolution, plus the possible addition o f new operations, will make the module increasingly difficult to llllderstand and maintain.

Sometimes a design is divided into modules tbat represent the different phases of execution: initialization, read input, compute, print output, and cleanup. TI1e cohesion in these modules is tempo ral, in that a module's data and functions are related only because they are used at the same time in an execution. Such a design may lead to duplicate code, in which multiple modules perform similar operations on key data structures; in this case, a change to the data structure would mandate a change to all of the modules that access the data structure. Object constructors and destructo rs in 00 programs he lp to avoid temporal cohesion in initiaLizatiorn and clean-up modules.

Ofte n, functions must be performed in a certain order. Fo r example, data must be e ntered before they can be ch eck ed and then marupulated. When functions are grouped together in a module to encapsulate the orde r of their execu tion , we sa y tha t the module is p:roceduraUy cohesive. Procedural cohesion is similar to temporal cohe- sio n, with the added advantage that the functions pertain to some related action or pur- pose. However, such a module appears cohesive only in th e context of its use. Without knowing the module's context, it is hard for us to unde rstand bow and why the module works, or to know how to modify the module.

Alte rnatively, we can associate certain functions because they operate o n the same data set. For instance, unre lated data may be fetched togethe r because the data are collected from the same input sensor or with a single disk access. Modules that are designed around data sets in th.is way are communicatio nally cohesive. The cure fo r commllllication al cohesio n is placing each data e lement in its own module.

Our idea l is functional cohesion, where two conditions hold: all elements essen- tial to a single function are contained in one module, and all of that module's ele ments

302 Chapter 6 Designing t he Modules

are essential to the pe rformance of that function. A functio naUy cohesive module p er- forms o nl y the function for which it is designed , and nothing e lse. The adaptation of functional cohesion to data abstraction and object-based design is called informatio nal cohesion. The design goal is the same: to put data, actions, or objects togeth er o nly whe n they have one com moo , sensible purpose. For exa mpl e, we say that an 00 design compon ent is cohesive if all of the attributes, met hods, and action are strongly interde- p ende nt and essential to the object. Well-designed 00 systems have highly cohesive designs because they encapsulate in each modu le a single, possibly complex, data type and a ll o pe rations on that data type.

Interfaces

In Chapte r 4, we saw that a software system has an external boundary and a correspon- ding interface through which it senses and controls its environme nt. Similarly, a software unit has a boundary that separates it fro m the rest of the syste m, and! an interface through which the unit interacts with othe r software units. An interface defines what services the software unit provides to the rest o f the syste m, a nd how other units can access those services. For example, llie interface to an object is the collection o f the o bject 's public o perations and the operations' signatures, which specify each operation 's name, parame- ters, and possible return values. To be complete, an inte rface must also define what the unit requires, in terms of servi ces or assumptions, fo r it to wo rk correctly. For example, in the object interface described above, one of the opera tio ns may use program libraries, invoke external services, or make assumptions about the context in which it is invoke d. If any o f these requiremen ts is absent o r violated, the operation may fail in its attempt to offer its se rvices. Thus, a software unit's interface describes wha t the unit requires o f its e nvironment, as well as what it provides to ils enviro nment. A software unit may have seve ral interfaces that mak e different demands o n its environment o r that o ffer different levels of service, as shown in Figure 6.7. For example, the set of services provided m ay d epend on the user privileges of the client code.

Module

h11pl1111en11tlon lC

0111

Opmtlon 1

Opet1tlon 2

Opentlon 3

Opmtlon 4

FIG URE 6. 7 Example of interfaces.

Openmirrors.com

h tetlm A

Op111tlon t fl Op111tlon 2 () Ope11t1on 4 ()

h tetlice B

Op111tlon 2 () Op111tlon 3 fl

Section 6 .. 2 Design Principles 303

Inte rfaces are the design construct that allows us to encapsulate and hide a soft- ware unit's design and imple me ntation detai.ls from other developers. Fo r example, rather than manipulate a stack variable directly, we de fine an object called stack and methods to perform stack operations push and pop. We use the object and its methods, not the stack itse lf, to modify the contents of the stack. We ca n also de fine probes to give us in fo rmatio n about the stack- whe ther it is full or e mpty and what e lement is o n top-without changing the stack's state.

The specificatio n of a software unit's interface descri bes the ex te rnally visible properties of tile software unit. Just as a require ments sp ecification describes system be havior in terms of entities at the system's boundary, an interface sp ecification 's descripti ons refe r only to entities that exist at the unit's boundary: the unit's access functions, parame ters, re turn val ues, and exceptions. An interface specificatio n shou.ld communicate to o the r syste m de velo pe rs eve rything that they need to know to use our software unit correc tly. This info rmation is not limited to t!he unit's access functio ns and the ir signatures:

• Purpose: We document the functionality of e ach access function, in enough detail that o the r de velo pers can identify which access functions fit their needs.

• Preconditions: We list aU assumptions, called preconditions, that our unit makes about its u sage (e.g., values of input parameters, states of glo bal resources, o r presence o f program librari es or other software units), so that other develope rs kno w unde r what conditions the unit is guaranteed to wo rk correctly.

• Protucols: We include protocol informatio n about the orde r in which access func- tions should be invoked, or the patte rn in whic h two components should exchange messages. Fo r example, a ca lling modu.le may need to be autho rized before accessing a share d resource.

• Postconditions: We docume nt a U visible effects, called postconditions, of each access function, including r eturn values, raised exceptions, and changes to shared variables (e.g., o utput files), so that the calling code can react appropriate ly to the function 's output.

• Quality auributes: We describe any quality attributes (e.g., performance, reliabil- ity) that are visible to developers or use rs. For example, a client o f o ur so ftware may want to know whe the r inte rnal data structures !have been optirnized fo r data iosertio os or data re trievals. (Optimizing for on e ope ratio n usually slo ws the pe r- formance of the other. )

Ideally, a unit's inte rface sp ecificatio n defines exactly the set o f acceptable implementa- tio ns. At least, the specifica tio n needs to be precise eno uglh so that any implementatio n tha t satisfies the specificatio n wou ld be an acceptable impleme ntation of the unit. Fo r e xample, the specifica tion of a Find ope ration that re turns the index o f an ele ment in a list sho uld say what happens if the element occurs mu.ltiple times in the list (e.g., returns the index o f the first occurre nce, or the index of an arbitrary occurrence), if the element is not found in the list, if the list is empty, and so on. In addition, the specification should not be so restrictive that it excludes several acceptable implementatio ns. For example, the specificatio n o f the Find o per ation should not specify t hat the operation re turns the first occurre nce of an e lement when aoy occurrence would do.

304 Chapter 6 Designing the Modules

Inte rface specifications keep other developers from knowing about and exploit- ing our design decisions. At first glance, it may seem desirable to aJl ow othe r developers to o ptimize their code based on knowledge about how our software is designed. How- e ve r, su ch optimization is a form of coupling among the software units, and it reduces the maintainability of the software. If a developer writes code that depends on how our software is implemented, then the interface between that deve loper's code and our code has changed: the d eve loper's code now re quires more from our software than what is advertised in our software's inte rface speciiicatio n. When we want to cha nge o ur software, e ither we must adhere to this new interface or the other developer must change he r code so that it is optimized with respect to the new implementation.

A software unit's inte rface can also suggest the nature of coupling. If an inte rfa ce restricts aJI access to the software unit to a collection of access functions that can be invoked , then there is no conte nt coupling. If some of the access functions have com- ple x data paramete rs, then the re may be stamp coupling. To promote low coupling, we want to keep a unit's interface as small and simple as possible. We also want to mini - mize the assumptions and requireme nts that the software unit makes of its environ- me nt, to reduce the chance that changes to other parts of the syste m will violate those assumptions.

Information Hiding

Information hiding (Parnas 1972) aims to make the software system easier to maintain. IL is c.listinguishe<l by its guidance for decomposing a system: each software unit encap- sulates a separate design decision that could be changed in the future. Then we use the interfaces and inte rface specifications to describe each softwa re unit in terms of its externally visible prope rties. The principle's name thus reflects rt:he result: the unit's d esign d ecision is hidde n.

The notion of a "d esign decision" is quite general. It could refer to many things, includil!lg a decisio n about data format or operations on data ; the hardware devices or o the r compo nents with which o ur software must interoperate; protocols of messages between compon ents; or the cho ice o f algorithms. Because the design process involves many kinds o f decisions about the software, the resulting softwa re units encapsulate different kinds of information. D eco mpositio n by info rmation hiding is different frnm the decomposition me thodologies Listed in Chapter 5 (e.g., func tionaJ decomposition, data-ori ented decompositio n), because the so ftware units that result from the la tter e ncapsulate only informati on o f the same type (i.e ., they all e ncapsulate functions, data types, o r processes). See Side bar 6.2 for a discussion o n how we ll 00 design me tho- dologies imple ment in fo rmati o n hiding.

Because we want to e ncapsulate changeable design decisions, we must e nsure that o ur interfaces do no t, the mselves, refer to aspects of the design that are like ly to cha nge. For example, suppose that we encap sula te in a module the choice of sorting algorithm. The sorting module could be designed to transform input strings into sorted o utput strings. Howeve r, this approach results in stamp coupling (i.e., the data passed between the units are constrained to be strings). If changeability of da ta format is a d esign d ecision, the data format sh ould no t be exposed in the module's interface. A bet- te r design would e ncapsulate the data in a single, separate software unit; the sorting

Openmirrors.com

Section 6 .. 2 Design Principles 305

SIDEBAR 6.2 INFORMATION HIDING IN 00 DESIGNS

In 00 design, we decompose a system into objects and their abstract types. That is, each object (module) is an instance of an abstract data type. In tlhis sense, each object hides its data representation from other objects. The only access that other objects have to a given

object's data is via a set of access functions that the object advertises in its inte rface. This

information hiding makes it easy to change an object's data re presentatio n without perturb-

ing the rest of the system.

However, data representation is not the only type of design decision we may want to

hide. Thus, to create an 00 design that exhibits information hiding, we may need to expand

our notion of what an object is, to include types of information besides data types. For

example, we could encapsulate an independent procedure, such as a sorting algorithm o r an event dispatcher, in its own object.

Objects cannot be completely uncoupled from one another, because an object needs to

know the identity of the other objects so that they can interact. In particular, one object must know the name of a second object to invoke its access functions. This dependence means that

changing the name of an object, or the number of object instances, forces us also to change all units that invoke the object. Such dependence cannot be helped when accessing a n object

that has a distinct identity (e.g., a customer record), but it may be avoided when accessing an arbitrary object (e.g., an instance of a shared resource). In Section 6.5, we discuss some design patterns that help to break these types of dependencies.

module could input and output a gene ric object type, and could re trieve and reorder the object's data values using access functions advertised in the data unit's interface.

By following the information-biding principle, a design is likely to be composed of many small modules. Moreover, the modules may exhibit all kinds of cohesion. For e xample :

• A module that hides a data representatio n may be informatio nally cohesive.

• A module that hides an algorithm may be functionally cohesive. • A module that bides the sequence in which tasks are performed may be procedu-

rally cohesive.

Because each software unit hides exactly one design decision, all th.e units have high cohesion. Even with procedural cohesion, other software units hide the designs of the individual task s. The resulting large numbe r of modules may seem unwieldy, but we have ways to deal with this trade -off between number of modules and information hid- ing. Late r in this chapter, we see h ow to use dependency graphs and abstraction to man- age large collections o f modules.

A big advantage of information hiding is that the resulting software units are loose ly coupled. The interface to each unit lists the set of access functions that the unit offers, plus the set of other units' access functions that it uses. This feature makes the software units easier to understand and maintain, be cause each unit is re lative ly

306 Chapter 6 Designing t h e Modules

self-contained. And if we are correct in predicting which asp ects of the design will cha nge ove r time, then our software will be easie r to maintain later on, because chan ges wiU be localize d to particular software units.

Incre m ental Develo p ment

G ive n a design consisting of software units and the ir inte rfaces, we can use the info rma- tio n about the un.its' dep ende ncies to de vise an imcremental sche dule of de velopm ent. We sta rt by mapping out the units' uses relation (Pa mas 1978b), wh.ich re lates each software unit to the othe r software units o n which it depends. Recall fro m our discus- sion about coupling that two software units, A a nd B, need not invok e e ach othe r in o rder to de pe nd on each othe r; for example, unit A may d epend o n unit B to popula te a d ata structure, stored in a separate unit C, that unit A subseque ntly queries. In general, we say that a software unit A '·uses" a software unit B if A "re quires the presence of a correct ve rsion of B" in orde r for A to comple te its task, as specifie d in its inte rface (Parnas 1978b) . Thus, a unit A uses a uni t B if A does no t wo rk correctly unless B works. The a bo ve discussion assumes that we can d ete rmine a system's uses rela tion fro m its units' inte rface specifications. If the interface specifications do no t completely describe tbe units' de pendencies, tbeo we will need to kno w enough abo ut each unit's planned implementatio ns to know which othe r units it will use.

Figure 6.8 de picts the uses re lation o f a system as a uses gra ph, in whi ch no des re prese nt software units, and directe d edges run fro m the using units, such as A , to the used units, such as B. Such a uses graph can help us to identify progressively larger sub- sets o f o ur syste m that we can implement and test incre mentally.A subset of our system is some useful subprogram togethe r with alJ o f the software units that it uses, and all of the software units that those uni ts use, and so o n. '"Conceptuall y, we pluc k a program P1 o ut fro m the uses graph , and then see what prog rams co me dangling beneath it. This is o ur subset" (Clements e t al. 2003). Thus, the degree to which our syste m can be con- structe d incrementally depends on the degree to which we can find useful small subsets that we can implement and test early.

A uses graph can also help us to idenlify areas of the design that could be improve d, with respect to e nabling incre mental develo pment. For example, con sider D esigns 1 and 2 in Figure 6.8 as two possible designs o f the same system. We use the te rm fa n-in to refer to the number of units that use a pa rticula r so ft wa re unit, and the te rm fa n -out to refer to the number of units used by a software unit. Thus, unit A bas a fan-o ut of three in Design 1 but a fan-out of fi ve in D esign 2. In gene ral , we want to minimize the number of units with bigh fan-out. High fan-out usually indicates that the software unit is doing too much and probably ou ght to be decomposed into smaller, simple r w.1its. Thus, Desi.go 1 may be bette r than D esign 2, because its components have lower fan-out. On the o the r hand, if several units pe rform similar functions, such as

Design 2

FIGURE 6.8 Uses graphs for two designs.

Openmirrors.com

(1)

Section 6.2

~~ ~

(~)

Design Principles 307

(c)

FIGURE 6.9 Sandwiching, to break a cycle in a uses grapb.

string searchiog, theo we may prefer to combine these units into a siogle, more general- purpose unit that can be used in place of any oft.he original units. Such a utility unit is Likely to have high fan-in. One of our goals in designiog a syste m is to create software units with high fao-io and low fao-out.

Consider another example, shown as a uses graph in Figure 6.9(a). The cycle io this uses graph identifies a collection of units that are mutually depe ndeot oo each o the r. Such cycles are not oecessarily bad. If the problem that the units are solving is oaturally recursive, then it makes sense fo r the design to include modules that are mutually recursive. But large cycles Limit the design's ability to support increme ntal development: oone of the units in the cycle can be developed (i.e., impleme nted, tested , de bugged) until all of the cycle's units are developed. Mo reover, we cannot choose to build a subset of our system that incorporates o nly some of the cycle's units. We can try to break a cycle in the uses graph using a technique called sa ndwic hing (Paroas 1978b ) . In sandwiching, one of Lhe cycle's units is decomposed into two units, such Lhal on e of the new units has no dep endencies (e.g., unit B2 i_n Figure 6.9(b)) and the other has no de pe ndents (e.g., unit B1 in Figu re 6.9(b)). Sandwiching can be applied mo re than on ce, to break either mutua l dependencies in tightly coupled units or long dependency chaios. Figure 6.9(c) shows the resul ts of applying sandwiching twice, once to unit A aod once to unit B, to transform a dependency loop into two shorter depeodency chains. Of course, sandwiching works o nly if a unit's data and functio naLity ca n be cleanly partitioned, which is not always the case. In the next sec tion, we explore a more sophisticated technique, calle d depe ndency inversion , that uses 00 technologies to reverse the direction of depende ncy between two units, the reby breaking the cycle.

llle best uses graph has a tree structure o r is a forest of tree structures. In sucb a structure, every subtree is a subset of our system, so we can increme ntally develop our system one software unit at a time. Each completed unit is a correct implementation of part of our system. Each increment is easier to test and correct because faults are more Likely to be found in the new code, not in the caUed units that have already been tested and deemed correct. In addition, we always have a working version of a system subset to demonstrate to our c1Ustomer. Mo reover, morale among deve lopers is high , because they fre quently make visible progress on the system (Brooks 1995). Contrast these advantages of incre menrt:al development to its alte rnative, in which nothing works until everything works.

Abstraction

An abstraction is a mod el or representation that omi ts some details so that it can focus on other details. The definition is vague about which details are lefl out of a model ,

308 Chapter 6 Designing the Modules

because different abstractions, built fo r diffe rent putposes, omit different kinds of de tails. For tbis reason, it may be easie r to understand the gene ral notion o f abstraction by reviewing the types of abstractio ns we have encountered already.

We discussed decomposition in Chap te r 5. Figure 5.5 was an example of a decomposition hierarchy: a frequently used fo rm of abstraction in which the syste m is divided into subsystems, wbich in turn are d ivided into sub-subsys tems, and so on. The top leve l of the decomposition provides a system-level overview of the solution, hiding details that might otberwise distract us from the design functions and features we want to study and understand. As we move to lower levels of abstraction, we find more de tail about eacb software unit, in terms of its major elements and the relations among those e leme nts. In this way, eacb level of abstractio n h ides information about how its e le- ments are further decomposed. Instead, each e lement is described by an interface specification, another type of abstraction that focuses on the ele me nt's external be hav- iors and avoids any refe rence to the element's in te rnal design de tails; those details are revea le d in models at the next level of decomposition.

As we saw in Chapter 5, there may not be a single decomposition of the system. Rather, we may create several decompositio ns that show diffe rent structures. For instance, o ne view may show the system's different runtime processes and their inter- connections, and another view may show the system's decomposition into code units. Each of these views is an abstraction that highlig hts one aspect of the system's struc- tural design (e.g., runtime processes) and ignores o ther structural information (e.g., code units) and nonstructural details.

A fourth type of abstraction is the virtual machine, sui..;h as that in a layered ar·chi- tecture. Each layer i in the architecture uses the services provided by the layer i - 1 below it, to crea te mo re powerful and re liable services, which it the n offers to tbe layer i + l above it. Recal l that in a true laye red a rchitecture, a layer can access only those services offered by the layer directly below it, and cannot access the services of lower- level layers (and certainly not the services of the highe r-level layers). As such, laye r i is a virtual machine that albstracts away tbe de tails of the lower-leve l layers and presents only its services to the rnext layer; the guiding design principle is that laye r i's services are improve ments over the lower-layers' services and thus supe rse de them.

The key to writing good abstractions is determilling, for a particular model, which details are extraneous and ca n the re fore be igno red. The nature of tbe abstraction depends o n wby we are !building tbe model in the first place: what information we want to communicate, or what analysis we want to perform. Sidebar 6.3 illustrates how we can model different abstractions of an algoritbm fo r different purposes.

Generality

Recall from Chapter 1 that one of Wasserman's principles of software engineering is re usa bility: cre ating software units that may be used again in future software products. The goal is to amortize the cost of developing the unit by using it multiple times. (Amortization means tbat we conside r the cost of a software unit in terms of its cost per use rather than associate tbe full cost with the project that d evelo ped the unit.) Genera lity is the design principle that makes a software unit as universally applicable as possible, to increase the cbance that it will be useful in some future system. We make

Openmirrors.com

Section 6 .. 2 Design Principles 309

SIDEBAR 6.3 USING ABSTRACTION

W e can use abstraction to view different aspects of our design. Suppose that o ne of the system functions is to sort the elements of a (jst L. The initial description of the design is

Sort L in nondecreasing order

The next level of abstraction may be a particular algorithm:

DO WHILE I is between 1 and (length of L)-1:

Set LOW to index of smallest value in L(I), ... , L(length of L)

Interchange L(I) and L(LOW)

END DO

The algorithm provides a great deal of additional information. It tells us the procedure that will be used to perform the sort operation on L. However, it can be made even more detailed. The third and final algorithm describes exactly how th e sorting operation will work:

DO WHILE I is between 1 and (length of L)-1

Set LOW to current value of I DO WHILE J is between I+l and (length of L)

IF L(LOW) is greater than L(J)

THEN set LOW to current value of J

ENDIF

END DO Set TEMP to L(LOW) Set L(LOW) to L(I)

Set L(I) to TEMP

END DO

Each level of abstraction serves a purpose. If we care only about what L looks like before and after sorting, then the first abstraction provides all the information we need. If we

are concerned about the speed of the algorithm, then the second level of abstraction provides sufficient detail to analyze the algorithm's complexity. However, if we are writing code for the sorting operation, the third level of abstraction tells us exactly what is to happen; little addi- tional information is needed.

If we were presented only with the third level of abstraction, we might not djscem immediately that the procedure describes a sorting algoritlun; with the first level , the natu re of the procedure is obvious, whereas the third level distracts us from the real nature of the procedure. In each case, abstraction keeps us focused on the purpose of the respective description.

310 Chapter 6 Designing t he Modules

a unit more gen eral by increasing the numbe r of contexts in which can it be used. There are several ways of doing this:

• Parameterizing context-specific information: We crea te a more gene ral version of our software by makin g into parameters the data o n which it operates.

• Removing preconditions: We re move preconditions by making our software work under conditions t!hat we previously assume d would never happen .

• Simplifying postconditions: We re duce postconditio ns by splitting a complex soft- ware unit into multiple units that divide responsibility for providing the postcon- ditions. The units can be used together to solve the original proble m, or u sed separately when onl y a subset of the postconditions is needed.

For example, the following fo ur procedure interfaces are listed in order of increasing generality:

PROCEDURE SUM: INTEGER;

POSTCONDITION: returns sum of 3 global variables

PROCEDURE SUM (a, b, c : INTEGER) : INTEGER ;

POSTCONDITION: returns sum of parameters

PROCEDURE SUM (a [ ] : INTEGER; len: INTEGER) : INTEGER

PRECONDITION: 0 <= len <= size of array a

POSTCONDITION: returns sum of elements 1 .. len in array a

PROCEDURE SUM (a [ ] : INTEGER) : INTEGER

POSTCONDI TION: returns sum of elements in array a

The firs t procedure works only in conte xts whe re global variables have names that match the names used within the procedure body. The second procedure no lon ger needs to know the names of the actual variables being summed , but its use is restricted to summing exactl y three va riables. The third procedure can sum any numbe r of vari- ables, but the calling code must specify the number of eleme nts to sum. The last proce- dure sums all of the e lements in its array parameter. Thus, the more gen eral the procedure, the more Lik ely it is that we can re use the procedure in a n ew context by modifying its input parameters rathe r than its impleme nta ti on.

Although we would always like to create reu sable units, othe r design goals so me- times conflict with this goal. We saw in C hapte r 1 that software engineering diffe rs from computer science in part by focusing on context-specific software soluti ons. That is, we tai- lor our solution for the specific needs of our customer. The system's requirements specifi- ca tion lists specific design criteria (e.g., performance, efficiency) to o ptimize in the design and cod e. Often, this cu stomization decreases the software's gene rality, reflecting the trade-o ff between gene rali ty (and the refore reusaibility) and customizatio n. There is no gene ral rule to help us balance these competing design goals. The ch oice depends o n the situation , the importance of the design criteria, and the utility o f a mo re general version.

6.3 00 DESIGN

D esign characteristics have significant effects on subsequent development, mainten ance, and evolution. For this reason, new software engineering techno logies are frequently

Openmirrors.com

Section 6.3 00 Design 311

created to help developers adhere to the design principles we introduced in the last sec- tio n. For example, design methodologies codi fy advice o n how to use abstraction, sepa- ration of concerns, and inte rfaces to decompose a system into software units that are modular. 00 methodologies are the most popular and sophisticated design me th o- dologies. We caU a design object orie nte d if it decomposes a system into a coUection of runtime components called objects that encapsuJate data and functionality. The folJow- ing features distinguish objects from other types of components:

• Objects are uniquely identifiable runtime e ntities that can be designated as the target o f a message or request.

• Objects can be composed , in that an o bject's data variables may themselves be objects, thereby encapsulating the imple me ntations of the object's internal vari- ables.

• The impleme ntatio n of an object can be reused and extende d via inheritam.-e, to de fine the implementalion of o ther objects.

• 00 code can be polymorphic: written in generic cod e that works with objects of diffe re nt but re lated types. Objects of re lated types respond to the same se t of messages or requests, but each object's response to a requ est de pe nds on the object's specific type.

lo this section, we review these features and some o f the d esig n choices they pose, and we prese nt he uristics for improving the quality of 00 designs. By using 00 fea- tures to their best advantage, we can create designs that respect design principles.

Te rminology

The runtime structure of an 00 system is a set o f objects, each of which is a cohesive collection o f data plus all operations for creating, re ading, altering, and destroying those data. An object's data arc called attributes, and its operations arc called methods. Objects interact by sending messages to invoke each o ther's methods. On receiving a message, an object executes the associated me thod , which reads o r modifies the object's data and pe rhaps issues messages to other objects; when the method terminates, the object sends the resuJts back to the requesting object.

Objects are prima rily runtime e ntities. As such, they are o ften not represented directly in software designs. Instead , an 00 design comprises objects' classes and inter- faces. An inte rface advertises the set of e xte rnally accessible attributes and methods. This information is typically limited to public me thods, and includes the methods' sig- natures, preconditions, postconditio ns, protoco l requirements, and visible quality attributes. Thus, like other interfaces, the inte rface o f an o bj ect re presents the object's pubLic face, sp ecifying all aspects of the object's externaUy observable be havio r. Other system components that need to access the object's data must do so indirectly, by invo king the me thods adve rtised in the o bject's interface. An object may have multiple inte rfaces, each offering a different level of access to the object's data and meth ods. Such interfaces are hierarchically related by type: if one interface offers a stri ct subset of the services that anothe r interface o ffe rs, we say that the first interface is a subtype of the second inte rface (the supertype).

An object's implem en tation d etails are encapsulated in its c lass definition. To be precise, a class is a software module that partially or totally imple ments an abstract data

312 Chapter 6 Designing t h e Modules

type (M eyer 1997). It includes definitions of the attributes' data; declarations o f the me thod s that operate on the da ta ; and implementatio ns o f some or aU o f its metho ds. Thus, it is the class modules that con tain the actual code that implements the objects' data representations and method procedures. If a class is missing implementatio ns for some of its methods, we say that it is an abstract class. Some 0 0 notatio ns, including the Unified Modeling Language (UM L) , do no t separa te an object's interface from its class mo dule; in such no tations, the class definitio n distinguishes between public d efi- nitions (constituting th e interface ) and priva te definitio ns (constituting the class's implementatio n) . In this chapte r, we consider inte rfaces and classes to be distinct e nti- ties, because the se t o f obj ects satisfying an inte rface can be much larger than the set of o bj ects instantiating a class definitio n. G raphically, we distinguish an inte rface or abstract class from othe r classes by italicizing its name and the na mes o f its unimple- mented methods.

Suppose we are designing a program that logs all sa les transactions for a particu- lar sto re . Figure 6.10 shows a partial design o f a S a l e class that de fines attributes to store information associated with a sale (such as the list o f items sold, their prices, and sales tax) . The class implements a number o f o pe ratio ns o n transaction data (such as adding or removing an item from the transaction , computing the sales tax, or vo iding the sale). Each Sale o bject in our program is an instance of this class: each object e ncapsula tes a distinct copy of the class's data variables a nd pointe rs to the class's oper- atio ns. M o reove r, the d ass de finitio n includes constructor me thods that spawn new o bj ect instances. Thus, during execution, o ur program can instantiate new Sal e o bjects to recor<l the de tails of each sale as the sale occurs.

We also have instance variables, which are program variables whose values are re fe ren ces to o bj ects. An object is a distinct va lue o f its class type, just as '3' is a va lue of the INTEGER data type. Thus, an instance varia ble can refer to different o bject insta nces during program e xecution, in the same way that an integer variable can be assigned diffe rent integer values. However, the re is a critical differe nce between insta nce va riables and traditional p rogram variables. An instance variable can be d eclare d to have an inte rface type, rathe r than be a particular class type (assuming that inte rfaces and classes are distinct entities); in this case, a n instance variable can refe r to o bj ects of any class that imple ments the variable 's (inte rface) type. Moreove r, because

Stla Dal•

. I dty: 1.. 31 subtotal : Monty nont~ : t .• 12 tu : Mouy ••le '"' total : Mouy

year : lnt19ar

tddlte11( I tan) ta111ovalta111lprodut1N o.) ltn 1 eo111put1S1bto11I()

~

. product No.

eo11put1Tu l) - eo11puteT011l l) fttllll

voldSt la() duertptlH p11e1 : Monay

FIGURE 6.10 Partial design of a Sale class.

Openmirrors.com

Section 6.3 00 Design 313

of the sub typing relation among inte rfaces, an instance variable can also refer to objects of any class that imple me nts some ancestor supertype of t!he variable's (inte rface) type. The variable can eve n refer to objects of diffe rent classes over the course of a pro- gram's execution. This fiexibiLity is called dynamic binding, because the objects to wh.ich the variables refe r cannot be infe rred by examining the code. We write code tha t o pera tes on instance variables accordfog to their inte rfaces, but the actual behavior of that code varies during program execution, depending on the types of objects on wh.ich the code is o perating.

Figure 6.11 shows these four 00 constructs-classes, objeds, interfaces, and ins tance variables-and bow they are related. Directe d arrows depict the relationsh.ips be tween constructs, and the adornments at the ends of each arrow indicate the multiplic- ity (some times caUed the "a rity") of the relationship; the multiplicity tells us bow man y of an item may e xist. For example, the re lationship between instance variables and objects is many (*) to one (1), mean.ing that many instance variables may refer to the same object a t any point in a program's execution. Some of the other relationships merit me ntio n:

• Each class encapsulates the impleme ntation details of on e o r mo re inte rfaces. A class that is declared to impleme nt one interface also implicitly (via inheritance) impleme nts all of the interface's supertypes.

• Each interface is impleme nted by one o r more classes. For example, diffe ren t class imple mentations may emphasize different quality attributes.

• Each object is an instance of one class, whose attribute and meth od defin.itions de te rmine what data the object can ho ld and what method implementations the object executes.

• Multiple instance variables of different types may refer to the same object, as lo ng as the o bject's class implements (directly o r implicill:Jy via supertypes) each vari- able's (inte rface) type.

• Each instance variable's type (i.e., interface) determines what data a nd me thods can be accessed using that variable .

Bo th the separation of object instances from instance variables and of interfaces from class definitions give us conside rable ftexibilit)' in encapsulating design d ecisions and in modifying a nd reusing designs.

Suppo rt fo r reuse is a key characteristic of 00 design. For example, we can build new classes by combin.ing compone nt classes, much as children build structures from building blocks. Such constructio n is done by o bj ect composition, whe reby we de fine a

Ru11-t1111 11,111111

Object

0 •• 1 11ler1ncer •

lnlltnce w11•I•

FIGURE 6.11

Ctde Ty~• NldMIH dtcl1111ftnt

t1bclut ubtyp• It of lftl

Me la-model of 00 constructs.

314 Chapter 6 Designing the Modules

class's attributes to be instance variables of some interface type. For example, the Sale class de fined in Figure 6.10 uses composition to mai ntain an aggregated record of the Items sold, and uses a component Date object to record the date of the sale. An advantage of object composition is its support of modularity; the composite class knows nothing about the implementations of its object-based attributes and can manip- ulate these attributes only by using the ir interfaces. As such, we can e asily replace one class component with an other, as long as the re placeme nt complies with the same inter- face . Th.is technique is much the sa me as re placing a red building block with a blue o ne, as long as the two blocks are the sa me size and shape.

Alternatively, we can build new classes by extending or modifying definitions of e xisting classes. This kind of construction, called inherita nce, de fines a new class by directly reusing (and adding to) the definitions of an e xisting class. Inhe ritance is com- parable to creating a new type of building block by drilling ho les in an existing block. In an inhe ritance relation, the existing class is ca lled the parent class. The new class, ca lled a subclass, is said to "inhe rit" the parent class's data and function definitions. To see how inheritance works, suppose tha t we want to create a Bulk Sale class for record- ing large sales transactions in which a buyer quali fies for a discount. If we define Bulk Sale as an extension of our regular Sale class, a s in Figure 6.12, then we need to pro- vide onJy the definitions that distinguish Bulk Sale from its pare.at class, Sale. These de finitions include new attributes to record the discount rates, and a revised met.hod that applies the discount when totaling the cost of the sale. Any Bulk Sale object will

Date Sale

• I 4ay: 1 .. 31 subtotal : Money

1tl1 •au month: 1 .. 12 tax : Money year : inte5er total : Money

aWtem(ltem) remmltem(produet No.} Item computeSubtotal(J • product No . ~ compute Tu(} - name computeT otal(I 4emiption voidSale() price : Money

I Bulk Sale

Discount addDiscount(threshold, rate) • removeD iscount(rate) ~ thmhol4 : Money compute D iseountedSubtota I() rate : Percentage oomputeDiscountedT ax(} computeDiscountedTota 1(1

FIGURE 6.12 Example of inheritance.

Openmirrors.com

Section 6.3 00 Design 315

comprise attributes and methods d efined in the parent Sale class together with those de fined in the Bul k Sale class.

Object o rientation also supports polymorphism, whereby code is written in te rms o f interactions with an interface, but code behavior depends on tbe o bject associated with the inte rface a t runtime a nd o n the imple mentatio ns of th at object's meth ods. Objects of different types may react to the same message b y producing type-specific respon ses. Designe rs and programmers need no t know the e xact types of the objects that the poly- mo rphic code is ma nipula ting. Rather, they need make sure only that the code adheres to the insta nce va riables' interfaces; they re ly on e ach object's class to specialize how o bj ects o f that class should respo nd to messages. lo the Sales program, the code for finalizing a purchase can simply request the total cost from the appropriate Sale o bj ect. Ho w the cost is calculated (i.e., which metho d is e xecuted and whether a discount is appLied) will depend on whethe r the object is an o rdinary Sale o r a Bulk Sale.

Inhe ritance, o bject composition, and polymo rphism are important features o f an 00 design that make the resulting syste m mo re useful in many w.ays. The next sect ion discusses strategies fo r using these concepts effecti vely.

Inheritance vs. Object Composition

A key d esign d ecision is de te rmining how best to structure and relate complex o bjects. In an 00 system, the re are two main techniques fo r constructing large objects: inhe ri- tance and compositio n. Tha t is, a new class can be created by exte nding and ove rriding the beh avior o f an existing class, o r it can be cre ated by combining simpl er classes to form a composite class. The distinctio n between these two approaches is exhibite d by e xamples simila r to those o f Be rtrand Meyer (1997), shown in Figure 6.13. On tbe le ft , a Software Engineer is defined as a subclass o f Engineer and inherits its pare nt class's e ngineering capabili ties. On the right, a Software Engineer is defined as a composite class that possesses engineering capabilities from its component Engineer o bject. N o te tha t both a pproaches e nable design reuse and extension. That is, in both approaches, the reused code is maintained as a separate class (i.e., the parent class or the compo ne nt o bject), and the new class (i.e., the subclass o r the composite o bject) e xtends this behavio r by introducing new attributes and methods and no t by modifying the re used code. Moreover, because the re used code re mains e ncapsulated as a sep a- ra te class, we can safely change its implemen tatio n and thereby indirectly upda te the be ha vior o f the new class. Thus, changes to the Engineer class ar,e auto matically real- ized in the So ftware Engineer class, regardless o f whether the Software Engi - neer class is constructed using inheritance o r composition.

Engineer Sotwue Enalneer I engCapabilties 1 1 Engineer

FIGURE 6. 13 Class in he ritance (left) vs. object construction (right).

316 Chapter 6 Designing the Modules

Each construction paradigm has advantages and disadvantages. Composition is b et- te r than inhe ritance at prese rving the encapsulation of the reused code, because a com- posite object accesses the component only through its advertised interface. In our example, a Software Engineer would access and update its engineering capabilities using ca Us to its component's methods. By contrast, a subclass may have direct access to its inhe rited attributes, depenrung on the design. The greatest advantage of composition is that it allows dynamic substitution of object compo nents. The component object is an attribute variable o f its composite object and, as with a ny variable, its value can be changed during program execution. Moreover, if the component is d efined in terms of an interface, the n it can be replaced with an object of a different but compatible type. In. the case of the composite Software Engineer, we can change its e ngineering capabilities, including me thod implementations, by reassigning its engCapabilities attribute to another object. This degree of variability poses its own pro blems, thou gh. Because compo- sition-designed systems can be reconfigured at runtime, it can be harder to visualize and reason about a program's runtime structure simply by studying the code. It is not always clear which objects reference which othe r objects. A second disadvantage is that object compositi on introduces a level of indirection. Eve ry access of a compone nt's me thods must first access the component object; this indirection may affect runtime performance.

By contrast, using the inheritance approac h, the subclass's imple mentation is de te rmined at design time and is static. The resulting objects are Jess flexible than objects instantiated from composite classes because the methods they inherit from tlheir pare nt class cannot be ch anged at runtime. Moreove r, because the inherited properties o f the parent class are usually visible to the subclass, if no t <lireclly accessible, it can be easier to unde rstand and predict the behavior o f classes constructed using inheritance. Of course, the greatest advantage o f inheritance is the ability to ch ange and specialize the behaviors of inherited methods, by selective ly overriding inher ited definitions. This cha racteristic helps us to quickly create new types of objects that exhibit new behaviors.

In general, experienced designers prefer o bj ect composition over inheritance because of its ability to substitute component objects a t runtime. When instance vari- ables a re de fined in terms o f interfaces rather than concrete classes, the variables can re fe r to objects of any type that imple ment the interface. As a result, the client code can be written without knowledge of the specific types of objects it uses or even the cla'Sses tha t imple me nt those objects; the client code d e pe nds o nly o n t he de finiti on of the inte rface. Such flexibility ma kes it easier to cha nge or e nhance capa bilities in the future. For example, in the Software Engineer constructe d by composition, we can satisfy the Engineer interface with any object that com plies with the inte rface. We can de fine a new Senior Engineer class or subclass th at has more capabiLities and responsibil- ity than a Junior Engineer bas, and we can promote a Software Engineer to have senio r engineering capabilities using a simple attribute assignme nt. This pre fer- e nce of compositi on over inhe ritance is not a definitive design rule, because some times it is easier to consider o bjects as specialized insta nces of o ne another. Fo r example, a Sedan is probably bette r modeled as a subclass of Car than as a composite object that bas car-like properties. Mo reover, because o bject composition introduces a leve l of inrurection , it may be overly inefficie nt for the d egree of flexibility it offers. Thus, the cho ice be tween class inhe ritance and object compositio n invo lves trade-offs among design cohe rence, predictability of be havior, enca psula tion of design decisions, runtime performance, and runtime configurability.

Openmirrors.com

Section 6.3 00 Design 317

Substitutability

The use of inheritance does not necessarily result in subclasses that can be used in place of their pare nt class. Most 00 programming languages aUow subclasses to ove rride the be haviors of their inherited me thods, without regard to whe ther the result complies with the pare nt class's in terface. As a result, clie nt code tha t relies on the parent class migh t no t wo rk co rrectly when passed an instance o f a subclass.

Conside r a BoundedS tac k that is a specialized type o f Stack that can st ore o nly a limited number o f e leme nts. The BoundedSta c k subcl ass not o nly intro duces an a ttribute to reco rd the bound on its size, but also ove rrides the behavior o f the push ( ) me thod to handle the case whe re an eleme nt is pushed onto a fuU stack (e.g., the BoundedStac k might ignore tbe re quest, o r it might push the botto m eleme nt off the stack to make room fo r the new eleme nt) . A BoundedStack object is no t sub- stitutable fo r a normal Stack o bject, because the two objects behave differently when their respective stacks a re full

Ideally, a subclass must preserve the be havior o f its paren t class, so that clie nt code can treat instances o f it as instances of the parent class. This noti on is best described by the Liskov Substitutability Principle, name d after its inventor, Barbara Lisko v, a pio nee r in 00 programming and data abstraction.According to the principle, a subclass is substitutable fo r its parent class if aU of the fo llowing prope rties are sati s- fied (Lisko v a nd Guttag 2001):

1. The subclass suppo rts aU of the methods of the parent class, and their signatures are compatible. That is, the pa rame ters a nd re turn types of the subclass's me thods must be substi tutable fo r the corresponding paramete rs and return types o f the pa rent class's me thods, so tha t any ca ll to a method of the parent class wo uld be accepted by the subclass.

2. The subclass's me tho ds must satisfy the specifications of the pare nt class's me tho ds. The beha viors o f the two classes' methods do not !have to be the same, but the subclass must no t vio late the pre - and postconditio ns of the parent class's me tho ds: • Preco ndition rule: The preconditio n o f a subclass me thod must be the same as

o r weake r than the preconditio n o f the parent class's method, so that the sub- class metho d succeeds in all cases that the pa rent class m etho d succeeds. We ca n re present this relatio nship as:

pre_parem => pre_sub

• Postcondition rule: In those cases whe re the precondition o f the parent class metho d bolds, the subclass me thod d oes e ve rything tha t the pare nt method does, and may do mo re (i.e., tbe postcondition o f the subclass method subsumes the postconditio n of the pare nt class's metho d).

pre_parent => {post_sub => post_yarent)

3. The subclass must preserve all declared pro perties o f the parent class. Fo r example, in UML, a subclass inherits all of the constraints on its pa rent class and all or its parent's associations with other classes.

318 Chapter 6 Designing the Modules

If any of the above rules does not hold, then sending a message to an instance of the subclass might not give the sa me result as sending tbe message to an instance of the parent class. In the case of BoundedStack, the push ( ) me thod does not simply extend tbe postcondition of its parent class's push () method; it has a different post- conditi o n. Thus, the definition of Boundedstack violates the postcondition rule, and a BoundedStack object is not substitutable for a normal Stack object.

In contrast, consider PeekStack, anothe r specialized type of Stack tbat all ows use rs to peek at the contents of the stack rather than being able to view o nly the top e leme nt. A Peek Stack subclass introduces a single new method, peek (pas), that re turns the value of the element at depth pos in the stack. Because PeekStack over- rides none of the methods it inherits from Stack, and because the new me thod peek () n ever changes the object's attributes, it satisfies au of the s ubstitutability rules.

The primary use of the Liskov Substitutability Principle is in dete rmining when one object can safely be substituted for ano ther object. If we conform to the principle when extending our designs and programs with new subclasses, we can be confident that the existing code will work with the new subclasses without modification. Despite this obvious advantage, in our study of design patterns we will e ncounter a number of useful patterns that violate the Liskov Substitutability Principle. As with most other d esign principles, sub- stitutability is not a rigid design rule. R ather, the principle serves as a guideline for de ter- mining when it is safe not to reexamine the client modules of an extended class. Whenever we conform to the principle, we simplify the overal.E task o f extending our design.

Law o f Dem e t e r

A ltho ugh the design advice suggests that we prefer compositi o n ove r inheritance, the resulting design may have multiple dependencies amo ng classes.1bis problem occurs whe never a class that depends on a composite class also depends on all of the class's component classes. In our sales transaction example, consider a new class Bill that generates an invoice each month , listing aU of the ite ms sold that month to a particular customer. Suppose that each class in our design offers only se rvices that manipulate that class's local attributes. Then to print the list of ite ms sold, our generateBill () method must track down all of the appropriate Item objects:

For customerAccount c : For each Sale c . s made to customerAccount c:

For each Item c . s.i in Sale c .s: c.s.i.printName(); c . s.i .printPrice();

In such a design, our Bill class accesses and thus depends directly on CustornerAccount, Sale, and Item classes. We must know the in terfaces of all of them to invoke the appropriate methods correctly. Wo rse, we have to rech eck our irnplementatfon of generateBill () whenever any of these classes is changed.

We can reduce these dependencies by including in eacb composite class me thods for operating on the class's components. For example, we can add a printitemLis t () method to our Sale class, and add a printSaleitems () me thod to our Customer Account class. In this new design,

Openmirrors.com

Section 6.3 00 Design 319

• our generateBill () me thod calls printSaleitems () in CustomerAccount • printSaleitems () call s printitemLi st () in the appropriate Sale o bject

• printitemList () calls the print methods in the appropri ate Item objects

This design conve ntion is called the Law of D emeter (Li eberherr and Ho lland 1989), named after a research project called Demeter. It is also known more informally as the " Do n' t talk to s trangers" design principle. The benefit of this conven tion is that clien t code that uses a composite class needs to know only about the composite itself and no t about the composites' compone nts. The diffe rence be tween these two design alte rna- tives and their r esulting class de pendencies ca n be visualized by the designs' induced dependency graphs, shown in Figure 6.14. In general, designs that obey the Law of D eme ter have fewer class de pendencies, and classes with fewer depende ncies tend to have fewer software fa ults (Basili, Briand, and Melo 1995) and are easier to change (Li and H enry 1993).

Aceountln

1 911mteBlll{Account No.)

I I I I

I I I I

I I I I I I I I I I I I I I I \

CCOUI O.

l Cu1tont1 Account

IUll

1dd1111 b1 lme : Money - --

I I / I \ /

uwS1lt(I ,,, ', ', ....................

\ ........ _ .... ' ---------

Sile subtolll : Money tu: Mouy toul : Money

1ddltem(ltenl 11m0111l1tm(p1oduet No.1 comput1S1btotol{I eompu11T11(/ eom~u11Tou II void 111(1

---------, __ -- ---------

Aeco11t119

9m1111Blll(kee1nt No.) ceount o.

I

• Cu1tomu Account ftllll

'""" baluee : Monn n1wS1l10 PrlntS1lulttm1()

-

Sale 11btou1 : Monty tu : Monty 10111 : Money 1ddlt111{lt1m) 1111mlt1n{ptoduet No.) co11p11.Sultot1IO

- eonp111Tni/ eon~111Tot1 II void 111() p11n1l1111L1110

-

-

Date day: t .. 31

------ l!Onth: 1 .. 12 y111 : lntegat

lttll _ ptofot No.

na m1 duerlptloi ttlu : Mon1y ------ ptlntN111eO trlntP1lt1(1

Due dty: 1 •• 31

------· 1101th: 1 .. 12 ym : 1111911

11111

• p1odect No. nine demlptlon p1lce : Mone:f ptlntN1111{) ptlntPrlul)

FIGURE 6.14 Contrasting designs and dependencies.

Duis• 1

Du l9• 2

320 Chapter 6 Designing the Modules

On the downside, such designs often use a wrapper class to add functionality witho ut changing the imple mentations of existing classes. For example, we could have added printitemList () via a wrapper class associated with class Sale. Although wrapper classes ease the task of adding operations to composite classes, they can compli- cate the design and degrade runtime pe rformance. Thus, deciding whether to adhere to the Law of Demete r involves evaluating trade-offs amon g design complexity, develop- me nt time, runtime pe rformance, fault avoidance, and ease of maintenance.

Dependency Inversion

Cllut

D ependency inve rsio n is our final 00 design he uristic. It can be used to reverse the direction o f a depe nde ncy ljok between two classes. For example, if a client class d ep ends o n some server class, we can use depe ndency inversion to revise the depe nd- e ncy, so tbat the serve r class depends on the c lient class instead. We might invert d ependency to brea k a d epe ndency cycle among classes, as we saw ea rLie r in trus chap- te r. Or we might rearrange o ur design so that each class depends only on classes ltbat are more stable and less likely to cbange than it is.

D ependency inve rsion works by introducing interfaces. Suppose we have a design in wruch a client class uses the me thods of some server class, as sbown in Figure 6.15(a). The clie nt depends on the serve r. The first step of dependency inve rsion is to create an inte rface o n which the client can depend instead. nus interface should include specifica- tions of all the methods that the client expects from the server class. We modify tbe client class to use this new inte rface rathe r than using the server class, and we package together the original clie nt class and the new inte rface into a new client module . The result is shown in Figure 6.15(b ). The second step is to create a wrapper class for the server class (or to modify tbe se rver c lass), so that the wrapper class implement::. the inte rface created in step 1. nus second step sho uld be easy because the interface matches the speci1icatiions of the serve r class's methods. The resulting design, shown in Figure 6.15(c), induces a

NewCllut

Cl1w «Ulll» CllutServer

111111111 I Client I

N1wCllent

• lleh Cll111Serv11 I lnterftce

L;,.

«UH•

Server Serv11Wr1pp11

B (1) l•l (e)

FIGURE 6.15 Three steps of dependency inversion.

Openmirrors.com

Section 6.4 Representing 00 Designs in the UML 321

de pe nde ncy graph in which tbe ne wly wra pped server cl ass de pe nds on the new clle nt package. In the original design, a ny ch a nge to the serve r code wo uld cause us to reexam - ine and recompile the client code. In the ne w design, both the client code and the server code de pend only o n the ne w ClientSe rverint erface. A c hange to eithe r class's imple m entation does no t cause us to revisit or recompile the othe r class, so the n ew design is eas ie r to maintain. As we will see, the de pe nde ncy inversio n principle is used in the definitions of seve ral design patte rns.

6.4 REPRESENTING 00 DESIGNS IN THE UML

The UML is a suite o f d esign no tations thal is po pular for describing 00 solution s. It can be tailo red to fit diffe re nt develo pme nt situations and software life cycles. In fac t, o rganizations s uch as the O bj ect Managem ent G roup ha ve adopted the UML as the 0 0 no ta tio nal standa rd. In this sectio n, we re vie w tbe UML cons tructs introduce d in Cha pter 4 a nd a pply the m to an example proble m. For a more comple te introductio n to the UML, see Larman (1998).

The UML can be used to visualize, specify, or document a softwa re design. It is especially use ful for describing diffe re nt design alte rnatives, and eventually for docu- me nting design a rtifac ts. UML diagrams include the dynamic vie w of the syste m , the s tatic vie w, restric tions, a nd fo rmaliza tion. The dyna mic vie w is de picted with use cases, lis ts of ac tivities, interactio n diagrams showing seque nces and communica tio n, and s tate machines to iUustrate s tates and their changes. Tue sta ti c vie w is de pi cted with class diag ra ms, showing re lationships (associati on, gene ralizati on , de pe nde ncy, and realization) and exte nsibility (cons traints, tagged values, and ste reot yp es). In addition , the s tattic vie w sh ows packages and de ployme nt. R estriction s and formalization are e xpressed with the Object Constra int L a nguage ( O C L).

UML in the Process

Because 00 conce pts a pply to all pa rts of de velo pme nt, the U ML can be used thro ughout the software develo pme nt process. Figure 6.16 shows h ow the UML can be used in r equire me nts specificatio n, design , and coding. N otice that the UML makes use of many o f the notatio ns introduced in Chapte r 4. Each no tatio n makes explicit som e aspect o f the syste m , so that, in conce rt, the re presentations provide a de tailed picture of the pro ble m o r its prop osed solution. ln the require me nts process, use case diagrams describe tbe syste m to be built by describing the gene ral processes that the system must pe rform. In additio n, the use cases can embody the diffe re nt scenarios that describe bo w the syste m wiU work and how the use rs wiU inte rac t with the syste m. These dia- grams can be s upple mented by U ML activity diagrams, which are a type of wo rkflow process. mode l for describing the activities that the business wiU pe rform, o r with a do main mode l that de fines the syste m's domain in te rms o f its e ntities. If the syste m is large, its software a rc hitecture can be modeled u sing UML component diagram s, to s how the runtime compo ne nts a nd their inte racti o ns, a nd UML de ployment diagrams, to s how ho w compo nents a re a llocated computing resources.

M odula r design begins with the UML class diagra m. C lasses and their relati on- s hips are first define d informally, as e ach scenario is worked out with the user, and

322 Chapter 6

Requlremenh

Domtln models

UML tetlvtty 4ilt9rtntt

Designing the Modules

Architecture

UML component tllt9rtms

UML detloynitnl dl1gram1

UML H.llllCt

d!tgrtMI

UML elm diagrams

Detlgn

UM l IC! IW!ty ~littiNi

FIGURE 6.16 How the UML is used m t he development process.

UML ctMmulcttlon

tllt9rtMI

UML obJtcl 4il19rtn1t

UML tnkage 4119rtn11

UML stttt ~••tl'llllt

they become more detailed as design progresses. A se t of s tructure and object diagrams describes h ow each class is associated with others, including inheritance re lationships.

Nex t, design continues by addressing the dynamic aspects of the syste m. Initi ally, tbe interactions among cl asses are illustrated using simple interaction dfagram s: sequence and communicatio n diagrams. Sequence diagrams, introduced in Chapte r 4, sho w how messages How from one object to ano ther, fo rma lizing the info rmal descrip- tions of eve nts in the requirements.

Communication diagrams show the same iOtforma tion, but from the context of an object diagram. As understanding improves, we assign respo nsibilities to individual objects. At this stage, we can use activity d iagra ms as a type of flowchart notation to describe complex operations. In concert with the activity diagrams, we develop state d iagrams to show a ll possib le states that an o bject can take, and t he conditi ons under which objects execute their operations. The change from o ne state to another is trig- gered by a message (representing an event) that is sent fro m o ne object to another. Finally, we group the classes into packages, to make the design more hie rarchica l and easier to unde rstand, and model tbe result in a package diagram .

Openmirrors.com

Section 6.4 Representing 00 Designs in the UML 323

lo the rest of this section, we use the UML to generate an 00 design fo r the Royal Service Station system, whose requirements are listed in Sidebar 6.4. The corresponding use case diagram, showing the system's essential functional- ity and the principal actors that interact with the system, is shown in Figure 6.17.

SIDEBAR 6.4 ROYAL SERVICE STATION REQUIREMENTS

L The Royal Service Station provides three types of services to its customers: refueling,

vehicle maintenance, and parking. That is, a customer can add fuel to the tank of his o r her

vehicle (car, motorcycle, or truck), can have the vehicle repaired, or can park the vehicle

in the station parking lot. A customer has the option to be billed automatically at the time

of purchase (of fuel, maintenance, or parking) or to be sent a monthly paper bill. In e ither

case, customers can pay using cash, credit card, or personal check. Royal Service Station fuel

is sold according to price per gallon,depending on whether the fuel is diesel , regular, o r pre-

mium. Service is priced according to the cost of parts and labor. Parking is sold according to

daily. weekly, and monthly rates. The prices for fuel, maintenance services, parts, and parking

may vary; only Manny, the station manager, can enter or change prices. At his discretion,

Manny may designate a discount on purchases for a particular customer; this discount may vary from one customer to another. A 5% local sales tax applies to all purchases.

2. The system must track bills on a month-to-month basis and the products and services pro-

vided by the gas station on a day-to-day basis. The results of this tracking can be reported

to the station manager upon request.

3. The station manager uses the system to control inventory. The system will warn o f low

inventory and automatically order new parts and fuel.

4. The system will track credit history and send warning letters to customers whose pay-

ments are overdue. Bills are sent to customers on the first day of the month after the pu r-

chases are made. Payment is due on the first day of the succeeding month. Any bill not

paid within 90 days of the billing date will result in cancellation of the customer's credit.

5. The system applies only to regular repeat customers. A regular repeat custome r means a

customer identified by name, address, and birthdate who uses the station'sservices at least

once per month for at least six months.

6. The system must handle the data requirements for interfacing with other systems. A credit

card system is used to process credit card transactions fo r products and services. The

credit card system uses the card number, name, expiration date, and amount of the pur-

chase. After receiving this information, the credit card system confirms that t he transac-

tion is approved or denied. The parts ordering system rece ives the part code and number

of parts needed. It returns the date of parts delivery. The fuel ordering system requires a

fuel order description consisting of fuel type, number of gaillons, station name, and station

identification code. It returns the date when the fuel will be delivered.

324 Chapter 6 Designing the M odules

7. The system must record tax and related information, including tax paid by each customer,

as well as tax per item.

8. The station manager must be able to review tax r ecords upon demand.

9. The system will send periodic messages to customers, reminding them when their ve hicles

are due for maintenance. Normally, maintenance is needed every six months.

10. Customers can rent parking spaces in the station parking lot on a day-to-day basis. Each

custome r must request from the system an available parking space. The s tation mana ger

can view a monthly report summarizing how many parking spaces were available or

occupied.

ll. The system maintains a repository of account information, accessible by account numbers and by customer name.

12. The station manager must be able to review accountin g information upon demand.

13. The system can report a n analysis of prices and discounts to the station manager upon

request.

14. The system will automatically notify the owners of dormant accounts. That is, customers who did not make service station purchases over a two-month pe riod will be contacted.

15. The system cannot be unavailable for more than 24 hours.

16. The system must protect customer information from unauthorized access.

UML Class Diagram

To see how the UML can be used , consider the system design of the Royal Se rvice Sta- tion syste m. For simplicity, assume that the R oyal Se rvice Sta tion consists of a single component, and thus is smaU enough not to warrant an architectu ra l design. The n , we can gen erate a modular system design directly from the requirements in Sidebar 6.4. We begin with UML class diagrams. These cliagrams describe the o bject typ es and their static re lationsnips. In particular, we wa nt to de pict associations amo ng objects (e.g., a custo mer is associated with a biU) and relatio nships betwee n ty pes and subtypes (e.g., diesel fue l is a subtype of type fue l) . We want the diagrams to iUustrate the attribute s of e ach obj ect, their individual be haviors, and the re stri ctions on each class or object.

The design process starts with a stateme nt of the require me nts. We try to extract nouns, Looking for partic ular items that can suggest our first cut at object classes. We seek

• acto rs • physical o bj ects • places • organizatio ns • re cords • transactions • collections of things

Openmirrors.com

Section 6.4 Representing 00 Designs in the UML 325

Royal Serwlu Stallen

C1ntrollln1

'"""'"' AcC1untln9

Ser'ftcu

lhlol•• .... S.rtleu

P1111 Orderh~ Sptu1 Ii

Ful 01d1rln9 Sy1te"

Credit Cird Sy111"

FIGURE 6.17 Use case diagram of the Royal Service Station system.

• opera ting procedures • things that are manipulated by the system to be built

Fo r example, consider this part of the first Roya l Service Station requirement:

A customer has the option to be billed automatically at the time of purchase (of fuel, main- tenance, or parking) or to be sent a monthly paper bill. In either case, customers can pay using cash, credit card, or personal check. Royal Service Station fuel is sold according to price per gallon, depending o n whether the fuel is diesel, regular, or pr emium. Service is priced according to the cost of parts and labo r. Parking is sold according to daily, weekly, and monthly rates. The prices for fuel. maintenance services, parts, and parking may vary; only Manny, the station manager, can e nter o r change prices. At his discretion, Manny may designate a discount on purchases for a particular custome r; this discount may vary fro m one cus tomer to another. A 5% local sales tax applies to all purchases.

Fro m th is requirements state me nt, we can extract several te ntative classes:

• personal check • services • paper bill

• discounts • credit ca rd

326 Chapter 6 Designing the Modules

• tax • customer

• parking • station manager • mainte nance • purchase • cash

• fuel • prices

The fo Uowing questio ns can act as guide lines for what can be included in a list of candidate classes:

1. What data need to be "processed " in some way? 2. What items have multiple attributes?

3. Whe n do we have more than one object in a class? 4. What information is based on the requireme nts themse lves, and not derived from

our understanding of the requireme nts? 5. What attributes and operations are always applicable to a class or object?

Answering these questions can help us to group the candidate classes and objects, as sbown in Table 6.1.

Next, we examine other requireme nts to see what they add to our existing table of attributes and classes. Fo r example, the fifth requireme nt states that,

The system applies only to regular repeat customers. A regular repeat customer means a customer identified by name, address, and birthdate who uses the station's services at least once per month for at least six months.

Similarly, the ninth requirement says,

The system will send periodic messages to customers, reminding them when their vehicles are due for maintenance. Normally, maintenance is needed every six months.

Thus, we have new candidate classes, such as regular repeat customer, name, address, and periodic messages. We can revise Table 6.1 as Table 6.2 to re flect this. Howe ver,

TABLE 6 . 1 Initial Grouping of Attributes and Classes: Step 1

Attributes Oasses

Personal check Tux Price Cash Credit ca.rd Discounts

Openmirrors.com

Customer Maintenance Services Fue l Bill Purchase Station manager

Section 6.4 Representing 00 Designs in the UML

TABLE 6.2 Initial Grouping of Attributes and Qasses: Step 2

Attributes Classes

Personal check Tax Price Cash Credit card Discounts Name Address Birthdate

Customer Maintenance Services Parking Fuel Bill Purchase Maintenance reminder Station manager

327

" regular repeat customer " is re dundant, so we ca n leave it out. For tbe full set of requireme nts, we might expand our table to include all of the classes in Table 6.3.

Next, we identify be haviors that must be described in our design. From the requirements statements, we extract verbs. Again, we can look for particular items that suggest behaviors:

• imperative verbs • passive verbs • actions • membership in • management or ownership • respo nsible for • services provided by an organization

TABLE 6.3 Initial Grouping of Att1ibutes and Classes: Step 3

Attributes

Personal check Tax Price Cash Credit card Discounts Name Address Birthdate

Classes

Customer Maintenance Services Parking Fuel Bill Purchase Maintenance reminder Station manager Overdue bill letter Dormant account warning Parts Accounts Inventory Credit card system Part ordering system Fuel ordering system

328 Chapter 6 Designing t he Modules

The behavio rs wiU become actions or responsibilities taken by a class or object, or actions done to a class or object. Fo r e xample, billing a custo me r is a behavior. The behavior is performed by part of the Royal Se rvice Station system (i.e., the Royal Service Station system is responsible for billing), a nd the billing affects the custome r.

To make it easier to manage the objects, classes, a nd behavio rs, we use a UML diagram to describe their relationships. We can d raw class boxes for our initial design for the Royal Service Station. Figure 6.18 shows tbe 17 classes we think we will need for o ur 00 re presentation of a solution. Recall fro rm Chapter 4 that the top segment of each box contains the class name, the middle segment lists the class's attributes, and the bo ttom segment lists the class's methods. Figure 6.19 summarizes the UML notatio n for de no ting specific types of relati onshi ps be tween classes.

Le t us exantine our first attempt at a solutio n to the Royal Service Station prob- lem. By comparing our design with the require ments in Sidebar 6.4, we see tha t the class diagram can be improved substa ntially. First, we can add an abstract Message class that combines the commonalities o f tbe various types o f le tte rs and warnings. Similarly, we can create an abstract Services class that gene ralizes the diffe rent types of services (Fuel, Maintenance, and Parking) that the statio n offers. By crea ting the abstract classes, we take advantage of the polymo rphism afforded by o bj ect o rientation. For example, the price () me thod is commo n among aU service classes, but the actual computatio n can be diffe rent, de pending on which service is being purchased.

We can simplif]' the design by dele ting the classes that depict adjacent systerns- Credit Card System, Part-Ordering System,an<lFuel-Ordering System-- since they are outside of the boundary of our system. We can also remove the Station Manager class, because it is not related to any o the r classes.

The location of discount as an attribute of the Purchase class is inappropri- ate. The discount rate d epends on the service being discounted as well as on the cus- to me r (who can be derived from the associated Purchase class). Thus, it is more appropriate to model discount as an associa tion class.

There are other problems with our initial design: the se rvice classes Maintenance, Fuel, and Parking are components of both the Purchase class and the Inventory class, and no object instance would ever simul taneously be a component of both the Purchase class and the Inventory class. Mo reover, the information we need to main- tain about the inventory is different from the informalion we are tracking about pur- chases. Thus, it is appropriate to represent these concepts as separate classes, keeping in mind that e ach purchase has an e ffect on the in ventory. The resulting design is iUustrated in Figure 6.20.

We need not stop he re . By scrutinizing the second design further, we find that we can add a Vehicle class so that maintenance records a nd notifica tions a re associa ted with ve hicles being mainta ined. We also need o pe rati o ns to ge ne rate the re ports and the reviewing capabiliti,es described in the requireme nts. For example, the Account class requires an operation to allow the statio n manage r to review account information o n demand. Because such analyses apply to a ll objects of a class, ra the r than to individ- ual o bj ects, we mark them as being class-scoped by underlining the method names. Similarly, the tax rate in the Purchase class is a class-scope attribute: all purchases use the same tax rate. Finally, we add cardinality to the diagram, so that we have a better

Openmirrors.com

// I ····-· 1 1

1111 11 ........ ...~ ..

l lut I I 1t11 I l 1t11

I , ... , ...... ,., I

...... .., ....... I I

I I •. ~~·~~'.... I l 1thr I l otlull I

I ,.,, P'll-"""' , .... cwnet_~••lftr .,,., tflfHt • t

I

..... .u: ... ,_ .... , ....... , .......... 1 ...

.......... ... 41tcHtt tffttlt l tu till tu

""' .. .,.1,_tull .. .,. •• _1111111

(

pdttJOf..!lllH

""'" ttlfHl_~lfllf .,,., lrltttt • 100

,dull ""' 1 .. 111

... . ....... , l<-:>-------t ••• 1.11 -- ,,.._~.r ....

I ... 11 •• ,,_, , .... ,,11,_ .... wully_rett ... tti1,_,. •• ~lft'lllH

trk•ll

..,,. .. _ .. , .... lklJ"'lttttll ,. ..... .... 111

""-upk1H11_4tt1 -tl iktitH

r...,, ..

I Ftt1 .. r•ertH -• ...._____... l1fttftt1 ,,,. .. ,..,. .. -• I

FIGURE 6.18 Fmtcut ot Royal Suviee Statioo design.

I

330 Chapter 6 Designing t h e Modules

association

~~I •~I-~ composition t--~~~----i~t--~~~--t ag9re5ation

--~-- genera liution --~-----~I----- ~ependen cy

navigation

FIGURE 6.19 'I}'pesofclass relationships.

unde rstanding of the relatio nships between pairs o f classes; at the same tjme, we indi- cate whethe r e ach attribute and method is publid y accessible (+), is private and cannot be accessed directly by o the r objects( - ), or is protected (#) and can be accessed o nly by subc lasses. The result is the design in Figure 6.21.

Other UML Diagra m s

To supplement our syst em 's design, we need a varie ty o f othe r dfagrams. First, e ach class must be described in more de ta il using a class description template. The template re peats some informatio n from the cl ass diagram: the position o f the class (in terms of de pth of inheritance) in the ove rall hie rarchy, the expo rt controls, the cardin ality (i.e., ho w ma ny o bjects we might expect in the class), a nd associations with othe r classes. In fact, the te mplate can be partiall y generated auto matically from the class diagram. But the template also specifie s the opera tions in the class, and their public and private inter- faces. H e re is an example of a class descriptio n template for the Refu e l class in our design:

C1ass name: Refue1

Category: service Ex ternal docUJDents:

Export control : Public

Cardinality: n Hierarchy:

SUperclasses : Servi c e

Associations:

<no r olen arne>: f u e l in assoc i at i o n updates

Operation name: price

Public member of : Refuel

Documentation:

II Calc ulates f uel final price P r econ ditions:

g a l lon s > 0

Openmirrors.com

"' "'

e. ...... , 1&0111_ .. ., kloou 4tn111at : ... , ... ,.,,.,II

1----------l111t1hl111)

1111_ ........ 11

'""""'-"'"'"II

• tto ... , ..

.. , .... . ... ,,,. .... _ .. .. I Ml~1 ... ftH

P1rld1 ... 11 •• 1._1ptct1

''"'-"'' ... 11,_,.,, •trill nt•

.. , .......... •••d•t

FIGURE 6.20 Second cut at Royal Service Station design.

hMHl'f ...... ,

..... -Mollttt _,,,,.,, ..

1 .. • ,,

....... -ICCtlll_1•n -loluc• -•tM•t ! ... 1 ...

' , .. ,.,~II 1-----...... ., ... ll••llll +mttw liUf!llUll •"Y_11•t1hrll . , .,,,, ... _ .. ,.1 .. 11

I: .. · .. , ..... . " ""'""' .:l!.!..!l!1 .... -!ltd

+ H ltfHtlll_f ... ll Mt(I

...... bttt

......

,, ·•tll1.i1_ 1pec•

-~111( "" .... ij,.111

I -Mill. - tat11

+ ••• ,.,. ,. .,, J

-llfftt l•• Pltft

FIGURE 6.21 Thi1d and final cut at Royal Service Station design.

Openmirrors.com

. ..... ., Weml•t

-lt tfft U•plttt

Section 6.4 Representing 00 Designs in the UML 333

Object diagram: {unspecified)

Semantics:

price= gallons * fuel.price_per_ gallon tax= price * purchase . tax_rate Object diagram: (unspecified)

Concurrency : sequential

Public interface:

Operationss

price Private interface:

Attributes:

gal l ons l:mplementation:

Attributes:

gallons State machine: n o

Concurrency: sequential

Persistence: transient

Notice that the class description template la ys the groundwork for t he program design. In o the r wo rds, the class description te mplate includes informati on essential fo r programmers to imple ment the design as code. For example, the template contains fo r- mulas to be used in the class's o perations and separates the public from the priva te interfoces. A privllte interface to a class is a mechanism that restricts access to class members; o the r objects canno t see the attri butes or (some) methods for tha t class. A public inte rface a llows access to some methods, but not to a ttributes, since a public attribute wo uld vio late the principle of encapsulation.

UML package diagram s allow us to view the system as a sma ll collection of pack- ages, e ach o f which can be e xpanded to a larger set of classes. The package diagrams show the d epende ncies among classes that belong to difie rent packages. We sa y that two items are d e pe nde nt if changes to the de finition of one may cause changes to the other. For example, two classes may be dependent if one class sends a me ssage to the o the r, one class has data needed by another class, o r o ne class u ses anothe r as a para m- e ter in pe rfo rming an operation. In particular, two packages are dependent if there is a de pendency between a class in each of the packages. As with any good d esign, we want lo minimize unnecessary coupling; thus, we want to keep d ependencies to a minimum.

Packages and their dependencies are especially important during testing. As we will see in Chapters 8 and 9, we must design test cases to account for the diffe re nt pos- sible inte ractio ns among components. UM L package diagrams help us to unde rstand the depende ncies and create our test cases. Figure 6.22 is an ex ample of a UML pack- age diagram for the Royal Service Station. In the figure, th ere are five major packages: accounting, transactions, services, inventory, and messages. Each of the packages is composed o f classes from the design in Figure 6.21. For instance, the Services pack- age consists o f five key classes: Service, Refuel, Vehicle Maintenance, Parking Penni t, and mainte nance Part; the contents of the Services package a re depicted in the figure to illustrate the connection between classes and packages bu t

334 Chapter 6 Designing t he Modules

~-A-e-eo_u"_'_ing~~~----------~

~--------~ ...... ..•• ~ ..... .. ... .

• • • • • • • • • . . . . . ,,,.., ..... . e e e · Htt pltN e e e •• • • •• • • • • • • •

FIGURE 6.22 Package diagram for the Royal Service Station.

would not ordinari ly be included i n a package diagram. The dashed arrows show the package de pe nden cies. For instance, the Accounting package de pe nds on the Transactions package. As you can see, the package diagram gives a high-le vel overvie w of the system and highlights the high-level de pendencies.

To model dynamic behavior, we create interactio n diagra ms that describe h ow o perations and behaviors are realized by the o bjects in the design. We usually gene rate o ne interaction diagram [or each use case to identi fy the exchange of messages between the system and the external actors that typically occur in that use case.

There are two kinds of inte raction diagrams: sequence and communication. A seque nce dfagram shows the sequence in which activi ties o r behaviors occur. An object is de picted as a box at the top of a vertical line, known as the object's lifeline. A narrow box o n ·the lifel.ine indicates a period of time whe n the object is actively computing, usu- ally in response to a received message. An a rrow between two life lines represents a message be tween the two objects, and it is labeled wi th the message's name and some- times with the conditi on that must be met for the message to be se nt. An asterisk on the a rrow indicates that the message is sent many times, to seve ra l diffe rent receiving objects. When the message arrow loops back to its starting box o n the same object, the o bj ect is se nding a message to itself. Figure 6.23 is an example of a sequence diagram fo r the R oyal Service Station, showin g the use case for the Refuel class.

A communic.ation diagram also depicts a seque nce of messages between objects, but it is superimposed on an object model and uses the links between objects as implicit communication channels. As with sequence diagrams, the objects a re icons, and arrows are used to depict the m essages. However, unlike sequence diagrams, the sequence of

Openmirrors.com

S.mttStttlOll Credit Cud Sy1t1N

r1ft1I ( J

i <rdll ..,. : .---~ I .,,,...., I

~•rltr_cr .. lt (mdlt_urd_tUN,

••out}

.. w_pm~m (tm11111,d.ttt,t1f•1I, t•lloot}

hrcM1t

HW_IHI (UUHI, 41Mt ,

t •lltu}

FIGURE 623 Sequence diagram for the Refuel use case.

htl

336 Chapter 6 Designing the Modules

I Customer I

1: parkin1( ) i 3: new_ purchase (account, date,

parlcing, duration)

I Service Station :1---------------1: Purchase I 2: eheck_milability( ) i l 4: new_parking (durgtion)

S: update_milability()

I Parlcing :1-----------1: Parking Permit I FIGURE 6.24 Communication diagram for the Parking use case.

messages is indica ted by a numbering scheme . For example, the communication dia- g ram in Figure 6.24 shows the Parking use case. First, the parking () message, labeled "1," is sent from the Customer class to the Service station class. Then, the check_availability () message is sent from Service station to Parking; it is labeled with a "2." Tue re are five messages sent within this single use case.

So far, we have used UML diagrams to capture individual scenarios. The UML supports two more kinlls of interaction diagrams, state and adivity, that are used to model tthe dynamic behavior of entire objects or operations. A state diagram shows the possible states an object can take, the events that trigger the transition from one state to the next , a nd the actions that result from each state change. Usually, an object state is re lated to a set of attribute values, and event:s occur when messages are sent: or received. Thus, a state diagram is needed only for classes where the objects exhibit dynamic behavior with many changing attribute values and messages.

The notation for a state diagram is similar to that of the state transition diagrams introduced in Chapter 4. As sho wn in Figure 6.25, the start node is represented by a black dot, and the e nd node is a smalle r black dot inside a white dot. A rectangle repre- sents a state, with an arrow showing a transition from one state to anothe r. A condit ion is noted with a bracke te d e xpression next to an arrow. For instance, if no payment is made to an account within 90 days, the account becomes delinquent. We can now build state diagrams for the Royal Service Station classes. As examples, Figure 6.25 shows the state diagram for the Account class and Figure 6.26 shows the state diagram for the Fuel class.

We can use activity diagrams to model the ftow of procedures or activities in a class. When co nditio ns are used to decide which activity to invoke, a decision node rep- resents the choices. Figure 6.27 iUustrates the no tation used in a UML activity diagram. As with state diagrams, the start node is represe nted by a black dot, and the end node is a smalle r black dot inside a white dot. A rectangle represents an activity, with an arrow showing transitions from one activity to anothe r. [n this example, after activity Bis per- formed, a decision must be made. If one condition is satisfied, Xis o utput to some other class. Otherwise, activity C o r D (or both) is invoked. Tue long h orizontal bar above

Openmirrors.com

"' ... ....

.. _., ...... _ ...... .. , .... 4., .... , ... 11 ..

... , .... 0 metlnttO IWllW tcUt!b!l

•111_ -INt11) 4...,,.,_ ....... 11

Acet•ot

, • ..i t1M4l11

111 ... >' ... th) ,.,.. .. l .. tlll) , .. , .... : = .. It ... . ......

•UJt1dl1 .. (••••I t •11tou :• •• , .... 4 _ ..

[ .. l11ct <• OJ

41111~1111

(11111 > ',..I) -----@

,., .. 11(1•Hlll , .,, .... , ... , ..... _ .. FIGURE 6.25 State diagram !0< I.be Account closs.

338 Chapter 6

Fol prlc1_p11_!1llon current_quutlty ori1r trlu11 - 100 orilr fualf)

Designing the Modules

Fol

"""' ''"k [ci1111U111•llty > 0<4t1_trl1111J

upd1l•(tallt1s) , ,.,, .. 1_ ..... 111, :s .. ,, .. ,_ .... 111, ••• 11 ...

1u1ocklt1llu1) 1 • .,,,.,_ .... 111, :- .. "'"'-~"""'' + ,.11 ...

lowrtock

., .... ,,.11 ... 1 / u 11ul_.11nlll1 :s umnt_.11nlllJ • t•llou

FIGURE 6.26 State diagram for the Fuel class.

activities C and D indicates that a message from one activity (in this case, B) can be broadcast to o ther activities (in this case, C and D ). Then C and D are invoked sepa- rately, seria lly, o r in parallel.

We can draw an activity diagram for the Inventory task of reorde ring suppli es whenever the stock runs Low. As sh own in Figure 6.28, the activity diagram may have two decisions: one to ve rify that the re is enough fuel, a nd anothe r to ve rify that parts a re in s tock. If the inve ntory is sho rt of eithe r of these, the activity diagram indic ates tha t activities are in voke d to orde r parts and fue l. Notice that the horizontal bar allows bo th o rde ring activities to be initiate d. This situation may arise when the station is busy and custome rs are buying bo th fuel and automotive parts.

6.5 00 DESIGN PATTERNS

As we can see from our expe rie nce with the RoyaJ Service Station syste m, design is an inhe re ntly creative activity in which we iteratively devise poten tial solutions and t hen e valuate the m. We have explored severa l design principles that act as criteri a for assess- ing des ign decisions, th e reby helping us e valuate design quality and choose a mong

~~ ActivityB

FIGURE 6.27 Activity diagram notation.

Openmirrors.com

okay verify fuel stock

order lol

Section 6.5

' verify stock verify

puts stock

order parts

00 Design Pat terns 339

FIGURE 6.28 A c tivity diagram for I n v entory operation.

competing design alte rna tives. Wbile extreme ly useful, these principles p rovide no pre- scriptive advice abo ut creating or refining our designs. In fact, no design a ids can pro- vide such advice. Inste ad, we can study examples of good d esigns and try to apply their lessons to creating and evaluating our own designs. Just as we can read high -quality lit- e ra ture to improve o ur vocabulary and writing skills, so too can we examine superio r designs to improve o ur own design skills. The richer our d esign knowledge and experi- e nce become, the mo re we can draw ideas from them wh en we are presented with a new pro ble m to solve.

When lea rning how to build physical structures, studen ts of architecture learn to use collectio ns o f a rchitectural patte rns as the basic building blocks of new designs. In the same way, we can use a colJecti on o f design p atterns to help us build a new software design. The collection prese nted by Gamma e t al. (1995) is a good place to start. These pa tte rns docum ent design experience that can be studied in isolation. Each patte rn can be adapted fo r re use in new contexts. In fact, it was not until the software d evelopment community began to catalogue r eusable designs as design patterns, architectural styles, a nd refe rence aTchitectures that software engineering ga ined credibility as a true engi- neering discipline.

A design patte rn codifies d esign decisio ns and best p ractices for solvi111g a particu- lar d esign proble m according to d esign principles, some of which were identified earlier in this chapte r. Design patte rns are not the same as softwa re li braries; t hey a re no t packaged soluti ons that can be used as is. R ather , they are templates fo r a solution tha t

340 Chapter 6 Designing the Modules

must be modified and adapted for each particular use. This adaptation is similar to the way that e le me ntary data structures, such as queues and lists, must be instantiated and specialized for each use. The design patterns provide more specific guidance than design principles do, but they are less concrete and detailed than software libraries or toolkits.

The main goal of d esign patterns is to improve a design 's modularity. In fact, each pattern is designed to e ncapsulate a particular type of design decision. The decision types vary wide ly, from the choice of algorithm that implements an operation to the type of object instantiated to the orde r in which a coUection of objects is trave rsed. Some design patterns structure a design to make future design changes easier to imple- me nt. Other patterns e nable a program to change its structure or behavior at runtime. The original design patterns ide ntified by Gamma et al. (1995) are listed in Table 6.4, along with the purpose of each.

Design patterns make substantial use of in terfaces, informati on hiding, and p oly- mo rphism, a nd they often introduce a level of indirection in a cle ver way. Because the patterns add extra classes, associations, and method calls, they sometimes can seem overly complicated. This complexity improves modularity, even at the expense of other quality attributes such as performance or e ase of development. For this reason, the pat- terns are useful only in situations where the extra flexibility is worth the extra cost require d to imple ment them.

Let us look at some of the popular patte rns in more detail

Te mplat e Method Pattern

The Template Method pattern aims to reduce the amount of duplicate code among sub- classes of the same pare nt class. It is particularly useful when muJ tiple subclasses have similar but not identical implementations of the same me thod. The pattern addresses thi s problem by localizing the duplicate code structure in an abstract class from which the subclasses inherit. To be precise, the abstract class defines a te mplate method that imple- ments the common steps of an operation, and declares abstract primitive o peratio ns that represent the variation points. The template me thod calls the primitive operations at points where its behavior depends on the object being involved. The subclasses override the primitive ope ratio ns to realize subclass-specific variations of the template method.

To see how the Te mplate Method patte rn works, conside r the task of printing a purchase record, including an itemized list of the services purchased, in the Royal Service Station system. Each line ite m should inc lude a description of the se rvice pur- chased, the price, and the tax on that ite m. The code to print an item 's description or tax is the sa me for all types of se rvices, but the computation of an ite m's price varies g re atly among the se rvices. Applying the Template Me tho d patte rn , we create a single me thod, called list_line_i tern () , in the Services class that prints the line item fields. This method caUs a local abstract method price () to print the item's price. Each of the service subclasses ove rrides the price () method to reflect bow the price for that service is compute d (e.g., the price of a maintenance visit is the sum of the prices of the new automotive parts plus the cost o f the labo r) . Then, when list_line_i tern () is called for a particular object, the price is compute d appropriate ly. Tue resulting design is shown in Figure 6.29.

Openmirrors.com

Section 6.5 00 D'esign Patterns 341

TABLE 6.4 Gamma et al. (1995) Design Patterns

Pattern name

Crclltlo na l Patterns Abstract factory Builder Factory method

Prototype Singleton

Structural Paltems

Adapter

Bridge Composit e Decorator Fa~de

Flyweight Proxy

Behovioral Patterns

Chain of responsibility

Command Interpreter

Iterator Mediator

Memento Observer

State Strategy Template method Visitor

Purpose

Class l nstanthlllon Groups collections of dependent objects with a common theme Separates construction from representation Creates objects without specifying exact class, deferrin.g instantiation to

subclasses Cfones an existing object from a prototype Restricts object to one instance with a single point of access

Class and Object Composition

Wraps interface of one object around the incompatible interface of another object, to allow both objects to work together

Separates an abstraction from its implementation Composes several objects into a tree structure so that they can act unifonnly Adds or overrides responsibilities dynamically Provides a unified interface to simplify use Similar objects share data/state to avoid creating and manipulating many objects Provides placeholder for another object to control access

Class and Object Communication

D elegates commands to chain of i()mcessing objects, allowing more than one to handle a given request

Creates objects to encapsulate actions and parameters Implements special language by representing grammar to interpret sentences

in the language Accesses objects sequentially without exposing underlying representation Defines an object to encapsulate b ow a set of objects interact, providing onEy

that object with detailed knowledge of other objects Restores an object to its previous. state Plublish/subscribe, allowing several objects to see an event and change state

appropriately Object alters its behavior when internal state changes Selects one of a family of a lgorithms at runtime Defines an algorithm skeleton, then subclasses provide concrete behavior Separates algorithm from object structure by putting hierarchy of methods

into a separate algorithm object

In this manner, the Template Method pattern provides the operation's ske leton, and the vario us subclasses fill in the details. This approach allows tbe subclasses to spe- cialize the ste ps of an o peration rather than overriding the entire operation. It also allows the pa rent class to limit the degree of variation in su bclasses' versions of the method.

Factory Method Pattern

The Factory Method pat tern is used to encapsulate the code that creates objects. N or- maUy, we try to construct our designs so that when modules relate to other modules, they relly o n interfaces rather than on explicit class types. However, we cannot rely on

342 Chapter 6 Designing the Modules

S1ttlt1

focription tu I ist_line_item () 1riu//

/ ""' I

Vthlcle Refuel P1tkl1g Permit M1lnten1nce

gallons 4uration: {'ay, week, month} labor

priee(J price() price()

1

* Put

price tu

FIGURE 6.29 Applicatioa of tbe Tumplate Metho d patte rn to price ( ).

an inte r face during o bject cre atio n; he re, the constructo r of the a ppropri ate class must be ca lle d in o rder to create an object instance. !By encapsulatin g the object cre ati on code, tbe rest of our design can re ly on abstract types and inte rfaces.

The Factory Me thod pattern is similar to the Te mplate Me thod patte rn. In this case, the similar but no t identical me thods are the constructor me thods that instantiate o bjects.. We cre ate an a bstract class that defines an a bstract constructo r method (the Facto ry Method). The s ubclasses override the Factory Method to construct specific concre te o bjects.

Strategy Pattern

The Strategy patte rn a llows a lgorithms to be selected at runtime. It is use ful whe n vari- o us algorithms are avai lable to an appLication, but the choice o f best algorithm is not kno wn until the applicati on is running. To do thj s, the pattern de fines a farnjly of algo- rithms; each o ne is e ncapsu lated as an o bject, so th at they are inte rchangeabl e fro m the appLicati o n's po int of vie w. The application acts as a client, se lecting a n algorithm as needed.

Fo r example, suppose that we want to decide at runtime which user-authentica- tio n a lgorithm to use, de pending on the login request that we receive (e.g., rl ogin vs. ssh request in UNIX) . Figure 6.30 shows how we can use the Strategy patte rn to support seve ral authenticatio n policies, and to choose from the m dynamic ally. First, we imple- ment ea ch poLicy as a method of its o wn class. It is unlikely that the different policies

Openmirrors.com

Um Sutl••

Pauwor4

uth11llut1()

Section 6.5

A111/11111/t1//1t1 f 1/l1

Ch1llHt t-H11dth1kt 'heekuin

nt~entlut•ll

00 D·esign Patterns 343

Pu•llc!Prl~lft Kt • ,ullle hf

rlvtle ktf n th11lle1t1()

FIGURE 6.30 Application of the Strategy patt ern to defer decision on authentication policy.

have the same signatures, but we can simpli fy the signatures and store the parameters as local membe r variables. Then, we create an abstract class, Authentication Pol- icy, gene ral enough to act as a superclass for all the concrete policy classes. Fina lly, the User Session class has a member variable, policy, of type Authentication Pol- icy. This variable can be set to any of the concrete policy objects. Invoking the policy is achieved by executing the variable's method:

policy:= new Password(password);

policy.authenticate();

Decorator Patt·ern

The Decorato r patte rn is used to extend an object 's functionality at runtime; it is a ftex- ible alte rnalive to using inheritance at design time to create subclasses that support new features. The key to the Decorator pattern is that each feature that decorates a base class is constructed in such a way that

1. the decorator is a subclass of the object it decorates

2. the d ecorator con tains a refe rence to the object it decorates

The first prope rty e nsures tha t the decorated object will be accepte d wherever the orig- inal object is accepted, including as the base for another decorator feature. The second property ensures that each decorator is like a wrapper: it provides new functionality while still including the original object as a componen t. Thus, successive decorators can be applied to the same object, each o ne adding a new outer wrapper to the decorated object.

To see how the Decorator pa ttern works, consider the design of a simple informa- tion sys.tern for a movie renta l company, shown in Figure 6.31. In this example, the base object is a n Account, and the decorators a re various features to which the users can subscribe. The abstract Decorator class, as prescribed , is a subclass of the base obj ect Account. It also has a member variable named component that corresponds to the account being decorated. Each possible feature of an account is a subclass of Decorator. A fea ture is applied by creating an instance of the fe ature and making its component me mbe r the account that subscribes to the fea ture. A second feature is applied by creating that feature object and making its component me mbe r the already

344 Chapter 6 Designing the Modules

l11temetFll1 Movie

eheek_ava ii (Movie) 1<>0 .. 1 • title • oheck_out(Mo~ie) on_loan : holean eheck_in( Movie) rental_fee

0 late_fee loan_perio~

• 0 .. 1 I 1 Ace out

K:: 0 .. 1 ban

0 .. 2 &alance due Date &orrow( Movie) return( Movie)

T compount ' '""'" ........ ~

imw{/ rtlm{/

~ I I

Bulk Uttr $ubml~tlon limit monthl1 fee

&orrow(Movie) = 0 &orrow(Movie) = 0 <> . {or~ered} return (Movie) request( Movie)

quue

unrequest( Movie) ch1r'e Fee()

FIGURE 6.31 Application of tbe D ecorator pattern to add features to Account.

decorated account. In this way, an account can have any number of decorators applied to it; it can even have the same decora tor applied more than once (which makes sense for some fea tures).

Observer Patte rn

The Observer pattern is an application of the publish-subscribe architecture style. It is particuJarly use ful when our software needs to notify multiple objects of key events, and we do not want to hard-code into o ur solution which objects are to be notified.

We can see how the Observer pattern works by examining a simple text e ditor that offers multiple vie ws of a document being ed ite d. The page being edited migltt be disp layed in the primary window. Miniature thumbprints of several pages may be dis- played alongside the edited one, and a tool bar may show metadata about the text (e.g., font family, font size, text color) . The views represe nted by the different windows sbould be synchronized , so that changes to the text are immediately reflected in the associated thumbprint, and changes to the fo nt size are realized immediately in the text.

Openmirrors.com

Section 6.5 00 Design Patterns 345

Doum111t I • l1111m1111 Ol11rt11 .... /

insert(I 11p/111(i11l1/ delete fl

~ qu•rf(J re9 isle r( l>ocumentObserver) -utiFy II

Editor

- update(inlo)

Tlllumh1ll

- update(inlo)

Tooll11r -

update(inlo)

FIGURE 6.32 Application of tbe Observer pattern to syncbronize views in editor.

We could design tbe system so that eacb view is e xpli citly updated whene ve r the docu- ment is. cba nged. But we could e mploy a more e fficie nt design by having the system publish notificatio ns of updates, and having modules register to receive the notifica- tions. This type o f design uses an Obse rver pattern and is shown in Figure 6.32. The re are seve ral important constraints on this design. First, the design needs facilities for r eg- iste ring and noti fying o bse rver modules. Second, the o bserve r mo dules must agree on an inte rface for tbe notifications, which is declared in the Document Observer abstract class.

Composite Patte rn

A composite object is a be te rogeneous, possibly recursive, colJection of objects that represe nts some composite e ntity. For example, Figure 6.33 sbows a class diagram for matbe matica l expressions tha t are modeled as tree-like structures of no des represent- ing vario us o pe rators and varia ble o pe rands. The Composite patte rn promotes the use of a sing le uniform interface that applies to any of the composite object's elements. In Figure 6.33, the abstract class Expr provides tbis inte rface. Tus pattern 's advantage is that clie nt modules deal only with the ne w interface; tbey do not need to know bow the composite object's data nodes are structured. Moreover, clients are no t affected by changes to tbe composite object's class structure.

The Composite patte rn conflicts with the Liskov Substitutability Principle, because the o n.ly way fo r the composite object's new interfa ce to be uni form is fo r its se t o f me thods to be the unio n of all the possibl e components' methods. As a result, subclasses may inherit me aningless ope rations. For example, the Variable subclass inherits operatio ns to access left and right ope rand nodes. As such, the Composite pat- te rn emphasizes uniformity o f composite nodes o ver safety in kn o wing tbat each com- posite e le ment reacts appropriate ly to any message that it can receive.

346 Chapter 6 Designing t he Modules

E11r

I I 111_/111(/ Client I 111_ri1NI

,,,_,,~1111(/

2 111_nl{/ 11'11¥111(/ f rill(/

~ I

~ 8"11ty E11r V1tl1ble - name : string t •i_left()

val : int t•l_ ri9ht()

9;&1_name0

~ !,&!_val() evaluate() print()

I I I Plu Minus fltultl•lv' Divide

evaluate() evalote() evaluate() evaluate() print() print() print() print()

FIGURE 6.33 Application of the Composite pattern to represent mathematical expressions.

Vis itor Pattern

Although the Composite pattern reduces coupling between client modules and a com- posite o bj ect, it does nothing to alleviate the task of adding new functi ons that operate over a composite o bject. For instance, the o perations in Figure 6.33 are distributed over the various components, appearing as me thods in each of the component types. Each of these me thods contributes a fraction of the overalE computation o f an operation. Adding a ne w o peratio n requires adding a new method to every class in the composite object.

The Visitor pattern reduces this problem by collecting and encapsulating tbese ope rati o n fragments into their own classes. Each operatio n is imple mented as a sepa- rate subclass of an abstract Visitor class, a nd this subclass has me thods that apply the o peration to each compo nen t type. In addition, each class in the composite object has a single method for performing ope rations over the composite. In Figure 6.34, thi s me thod is named accept (). The method takes as a parameter a Visitor object that e ncapsulates the operation being applied.

Figure 6.35 shows !how the composite objeclt and visito r objects work together. To evaluate composite expression e, we invoke e's accept () method, passing an Evaluation object as the paramete r. The accept () method responds by invo king the appropriate Visitor method , accordin g to e's class type . For example, the accept () me thod in class Plus a lways calls Visi tPlus ().Tue invo ked Visi t or me thod the n operates o n e. As the operatio n progresses, the Visitor operatio n is re peate dl y passed to the accept () me thods o f various eleme nts in the composite object; those e lements caU the type-appropriate me thods in the Visitor; the n the type·appropriate methods operate on the elements.

Openmirrors.com

"'"" •l1llYNi1JJ.{YKi1JJ.J

I '''"""'""' Cllllll I f11//ltl111/ltl111/ I

"''""'1/t."'"''"'''' /1/111/J: •IPMll/ 6. b•r

2 '"-~"" ,,,_,,,St{/ ,,,_,_// lul1tlt ,,,_,,,{/ wlr1tV1~1•l•(V1~rliloJ ##/f/Yillllf/

~ iltt"11r(Pl•rl wltttll1 ... 1•1 ... 1 wltttll•ltlpl,(M1ltlpl1J wtrltDlwt4t(Plwt'41 .,.,.... lflltt blf Vatlallt - .... : '"'" 1•U•ftU nl: l•t l\'lftl

1tt_rJtltU Httpl(Vlrltor)

ftl_u11t() wh1tY1tl1ll1(Vttl1ll1) ,.,_ .. 111 whltPltrlPl.r)

~ nttpt(Vlritorl

wh1tM1 .. tJMl1tr) •bitMthipifllltltiply)

I I I wl1llDt.t'•IDM'•l I Pitt I 1111111 I I ll•ltlolr I ""'' I JtuoptJYlrltttJ l11uptJVltttttJI IMuptJVhtttt) 1 .... ,.1v1r1terll u-.... ~

wlr1tVor11lloJVt<t1llo) wtr1tPl1t(Pltt) wlritlllottJlllMt) wlritllohtply(llthiply) wtrltDM'•IDM'•I

FIGURE 6.34 Application of the Visitor pattern to implement operation.s over composite.

348 Chapter 6 Designing the Modules

:Varlahlt I :Varlahlt I 1nl:Ew1lu11t t·>accol laval I vl1llPlu1!thlt) ,

( ,., ltft(( ................... ;:. (

9tl_rlghl()

-- ................... ;:. __ ~,.--------+----'•"""cc"""o'"'"l_.lt"""v"'"tl....,1 --i

~.11var11~l1!thl1) ul Vaill"

' ~ - ......................... ············-···--···:>

-~~,.-------+---------t----•-cc_•~~•~l_,,v_al~l--i vt11!Varl1hl1(1hl1)

ul valll " -- ::: ....................................... ....... ······················)> --

FIGURE 6.35 Execution of the visitor operation Evaluate () on expression e =a+ b.

This example makes clear that the Visitor pattern does not eliminate coupling between the operations and the composite object; indeed , the designs of the operations depend on the structure of the composite object. The majn advantage of the Visitor pat- te rn is that the ope ratio ns are more cohesive, and n ew o perati ons can be added without touching the composite object's code.

6.6 OTHER DESIGN CONSIDERATIONS

There is more to creatin g the program design than laying o ut classes and interfaces. We must consider some global issues that may not have been addressed in the architecture. In this sectio n, we e xplor e issues related to data management, exception handling, user interfaces, and frameworks.

Data Management

The program design must address ways to store and recover persistent objects. Data man- agement takes into account the system require ments concerning performance and space. Fro m our understanding of the data requirements and constraints, we must lay out a d esign fo r the objects and for their operati ons. We can perform this task in four steps:

1. Identify the data, data structures, and relationships among them. 2. Design services to manage the data structures and relati onships. 3. Find tools, such as database management systems, to impl ement some of the data

management tasks. 4. D esign classes and class hie rarchies to oversee the data management functions.

Openmirrors.com

Section 6.6 Other Design Considerations 349

An 00 solution can use conventional files or relational databases, but it inter- faces most easi ly with 00 databases. To see how, conside r the tracking of vehicle main- te nance and parts at the Royal Service Station, as shown in Figure 6.36. If we wer e to use conventional files, we would have to set up a file for each class, and then program links among the fiJes to e nable us to pe rform the uasks required o f the system. Using an object-relational database makes our job a bit easier because the structure of our class diagram suggests the database relations that we need to define. As shown in the figure, we must set up tables: on e for each class and association in our model. Fo r exa mple, we will need not onJ y a part table and a maintenance table, but also a part-by-vehi cle table. In this way, object-oriented or object-relational databases establish a close correspon- dence betwee n our 00 design and the resulting database tables.

Exception Ha n d ling

We learned in Chapter 5 to program defensively by proactively ide ntifying exceptions (situations that couJd cause our softwa re to deviate from its normal behavior) and including exception handling that re turns the system to an acceptable state. In practice, a great deal of implemented industrial code is de voted to input validation, error check- ing, and exception handling. Beca use embedding this error-ch ecking code within the normal program-application logic distracts from the coherence of the overaU func- tional design, many programming languages support e xplicit exce ption handling con- structs that help to separa te error checking and recovery l'rom the program 's main functio nality.

Meyer (1992a) provides an example to show how exception handling can be e mbedded in a design. Suppose we are sending a message ove r a netwo rk. We know

vehicle 111lnten1nce ID 4mrl,tlon tu l1bor

~ oil ehuge 0.2S

2 rotate tlru 0.2S

3 rtpl1ce tlnln! belt s 100

=> M1lnttunu )(

ID p1rt_n1mber pert

[ llC782 .. 2 P1rt F89SERT

part_number

C::::) prlu tu part part_n1mber price , .. llC782 8 .40 P3291 20 0 10

E39WWY 34 1.70

FIGURE 6.36 Implementing the classes using an object-relational database.

350 Chapter 6 Designing the Modules

tba t if the procedure fails, we want to transmit again, giving up after 100 unsuccessful attempts. We can include this information in o ur d esign in the following way:

at t empt_transmis sion (message: STRING) raises TRANSMISS I ONEXCEPTION II Attempt to transmit message over a communication line using the

II low-level procedure unsafe_tra.nsmit, which may fail, triggering an

II exception.

II After 100 unsuccessful attempts, give up and raise an exception

local

failures: INTEGER try

unsafe_tra.nsmit (message)

rescue

end

fail u res := fail ures + l; if fail ures < 1 00 then

retry else

rais e TRANSMISSIONEXCEPTION

end

In the above example, all o f the procedure's no rmal behavior is loca ted in the itry clause. Alternatively, we could separate safe code from unsafe code, and protect o nly the unsafe code inside a try-re~c14e construct. Titis strategy not only makes explicit which aspects of our design are potentially unsafe, but also narrows the scope o f anti - cipa ted failures; the resulting construction allows us to offer more targeted recovery schemes in the matching rescue clause. Notice that one possible recove ry mechanism is to raise a ne w exceptio n to be passed to the calling code.

An e ffective use of exception s is to make our programs mor e robust by weak en - ing mo dules' preconditions. Conside r the fo llowing interface for a procedure il:hat performs division:

division(dividend,divisor: FLOAT): FLOAT raiaea DIVIDEBYZEROEXCEPTION

enaure: if divisor=O then rai a e DIVIDEBYZEROEXCEPTION,

elae r esul t = dividend I d i visor

By using exceptio ns, we can design the interface with no preconditions. Had we not used exce ptions, the a bove interface would have needed a precondition indicating that the procedure works correctly o nly if it is called with a nonzero-valued divisor. Then, we must rely on the calling code to no t pass an invalid divisor; this approach risks a runtime e rror if the calling code is negligent or incorrect in its checking. By using excepti ons, the divi- sion procedure does not need to trust the ca lling code. Instead, the division procedure checks the value of divisor itself, issuing a clear warning (in the form of a raised excep- tio n) back to the calle r if the re is a pro blem. H owe ver, not all preconditions are so easily checked. For example, it would no t be cost e ffective to check that a list is sorted properl y

Openmirrors.com

Section 6.6 Other Design Considerations 351

before p erforming a binary search because the check would take longer th an the savll1gs achieved by the binary search; instead, during the search, we could perform sanity checks to confirm that each element encountered is sorted properly with respect to the previous e lement encounte red. In gene ral, exceptions are most useful for e liminating precondi- tions that can be easily checked.

Designing User Interfaces

Let us look mo re closely at designing a user inte rface. We must con sider several issu es:

• ide ntify ing the humans who wi ll inte ract with the system • de fining scenarios for e ach way that the system can perform a task • designing a hierarc hy of user commands • re:finjng the sequen ce of user inte ractions with the system • designing relevant classes in the hie rarchy to implement the user-interface d esign

decisio ns • integrating the user-inte rface classes into the overall system class hi erarchy

The fi rst step in use r-inte rface design is laying o ut the inte ractio n o n paper. To do this, we dete rmine how paper Hows in the exjsting system; the paper documents may suggest comfo rtable use r inte rfaces in the automated system. For e xample, the le ft- hand side of Figure 6.37 shows the pape r bill that Manny uses at the Royal Service Sta- tion. Now, to automate his bilLing process, we may suggest a screen Like the one on the right-hand side.

If Manny agrees to the screen design, the next step involves designing one or more classes to imple ment the screen. We may decide to use the design sho wn in Figure 6.38. Notice that this design includes classes for an okay button and a text box. These objects a re not Likely to have ente red our initial conve rsati ons with Manny when we de rived o ur use cases fro m his requirements. They reflect o ur solutio n, not his prob- le m. It is common for the set of objects and classes to grow as we move through the life cycle from problem unde rstanding to solution generation. This expansion of classes and hie rarchy is ano the r important reason to conside r design fte xjbility as we devise our solution.

Frameworks

No one way o f designing is best fo r all situations. The only gllideline that applies to aU systems is this: d esign for change. No matter what system we are bwlding, it is Jjkely to change at some time o r other. There are many techniques and technologies to he lp us make the system mo re ftexjble a nd maintainable. Fo r example, toolkits are set'S of related, reusable classes that provide well-defined sets of functions. Toolbts are much Like the subroutine libraries of procedural languages. As such, we may employ a toolkit to bwld the user inte rface from butto ns and windows rathe r than write the code anew o urselves.

352 Chapter 6 Designing the Modules

Belo re. Alter

Royal Service Stati°" BILL 6S Ninth Avenue

New York Cit~. NY Customer name: I I

Bill lsne date: I I Purehutt

Customer: Date Toe Amn•t

Date:

~ Purchases l 0K? I Date Type Amount Tot1I: I I

Total:

FIG URE 6.37 Transition from paper to screen.

Fram e works and patterns are also design aids. They differ from a toolkit in rtbat tbey are more focused on design reuse than on code reuse. As we saw earlier in this chapter, a patte rn is a te mplate o f abstract archjtectural eleme nts that can be used to guide us in generating o ur design. Every patte rn has a context and forces defined with it. The conte xt explains the situations in which tbe pattern would be appropriate. The forces a re eleme nts o f the context that vary to some degree. If our situation match es a pattern 's forces and context, the patte rn is well suited for our application. Howe ver, patte m s a re no t as useful if they constrain a design that needs to be flexible.

A framework is a large reusable design for a specific application domain. For example, frame works exist for building graphical editors, web applicati ons,

Aeceut Biii Biii Screen accoqnt_ number

chte_iuue~ I 0 size balance * clue ~ate wi~th dormant : •oolean re prev_balance customer name mpen4() current_balance show_•illO reactivate()

list_purchms()

? re vi aw 1 ccoun ts() bill_reminder() compate_total() .. rm1ncy_warnin9()

I I I Ohy Button I I T11th1 I I I I I

FIGURE 6.38 Pos.sible design forne w billing screen.

Openmirrors.com

Section 6.7 00 Measurement 353

da tabase-centric systems, accounting systems, a nd more. A framework often includes a substantial code base that is re used as weU. We can think of a framework as a partially completed application missing some lower-le ve l modules; we add modules to the framework to complete and specialize it for a particular application. Unlike software product lines, which are de ve loped by a company for its own use. frameworks te nd to be publicly avail able resources like software libraries and toolkits. Libra ries are lower- level software units that we can incorporate into our programs, whe reas software frameworks te nd to be hi gh-leve l a rchitectures and modules whose low-level details need to be filled in. The use of fra meworks and toolkits makes it easier for nonexperts to imple ment specialized code and improves the quality of the resulting code.

6.7 00 MEASUREMENT

Once we have an 00 design o f a system, we want to be able to measure its prope rties. Fo r example, we have seen that the re are desirable characteristics of designs such as low coupling and high cohesio n, and that we can measure several aspects of design complexity. We want to measure these kinds of characte ristics of 00 systems, and we want the measureme nts to be useful for understanding, control, and prediction. In this section, we loo k at several kinds o f 00 measurement.

00 Size Measures

00 systems tend to grow in size as we move trom requirements anaJysis to design to code and test. In this respect, they are no diffe rent from systems developed using a different paradigm. Howeve r, unlike othe r paradigms, with an 00 approach, we use the sa me or similar language throughout each stage o f the life cycle, making it convenient to measure size in the same terms from a system's inception to its delivery and maintenance.

Researche rs have taken advantage of this common vocabulary when measuring size a nd making predictions based o n size. For example, Pfleeger (1991) used obj ects a nd methods as a basic size measure in h er effort-estima tio n approach; she found that he r me thod was more accurate than COCOMO in predicting the resulting effort needed to build seve ra l 00 syste ms. O lsen (1993) applied this technique to a commer- cial project, and the estimates we re extraordinarily accurate. The advantage of assess- ing size in the same terms througho ut developme nt is clear: the estima tion technique can be reapplied during development, and the estimate inputs are directly compara- ble. In other words, it is easy to see what the initial size is, and to track its growth over the product's life.

Lorenz and Kidd (1994) have described additional 00 size m easures that offer a finer level of detail. They defined nine aspects of size that reflect not only the general " bulk" of the system but also how the class characteristics affect the product. First, they look at the product in te rms of its use cases. Each use case is associated with a scenario that describes a task performed by the system. Lorenz and Kidd count the numbe r of scena rio scripts (NSS) in the use cases. They report that this me asure is correlated with applicatio n size and number of test cases. For this reason, NSS is useful in at least two ways. As a size measure, it can feed an estimation model for predicting project effort or

354 Chapter 6 Designing the Modules

duration. As a test case estimate, it he lps the test team prepare test cases and allocate resources fo r future testing activities.

Next, Lorenz and Kidd count the number of k ey classes (i.e ., dom ain classes) in the system. This measure is inte nded to evaluate high-level design, suggesting h ow much effort is needed to b uild the syste m. They also tall y the number of support classes, this time targe ting low-level design and the like ly effort needed. The average number o f support classes per key class and the numbe r of subsystems are useful for tracking the structure of the syste m being deve lo ped.

Lo re nz a nd Kidd a lso defi ne size in te rms o f an individual class. Class size is. the sum o f the to tal numbe r of o perations and the number of attributes; h ere, we count inhe rite d fea tures as we ll as features define d in the class. In a metric that eva luates the e ffec ts o f inhe ritance, they consider no t o nly the class's depth in the inhe ritance hierar- chy (wit h de pth = 1 being the root), they also count the number oi operations overrid- d en by a subclass (NOO) as well as the numbe r o f operations added by a subclass. Frnm these, they de fine a specializatio n index, SI:

SI = (NOO x depth) I (total number o f class me thods)

Each of these me trics can be applied during the different stages of de velo pmen t, as shown in Table 6.5. The numbe r of use case scripts and number of key classes can be measured very e arly, durin g require me nts capture . This type o f size measureme nt is typicall y mo re concre te and accurate than the require ments-counting schemes use d in mo re traditional de velopme nt, pleasing project m anage rs who must aUol:ate reso urces early.

Le t us apply these measures to the Roya l Service Stati on proble m. Figu re 6 .39 sho ws the overview of o ur 0 0 analysis o f the problem. Reviewing Sideb ar 6.4 and the o vals in this figure, we see that there a re six ovals, representing the six key use cases we envision for this system. So, using Lorenz and Kidd's me trics, the N SS is equal to 6.

TABLE 6.5 Lorenz and K idd Metrics Collection in D ifferent P hases of Development

Phase

Requirements System Program Metric Description Design D esign Coding Testing

Number of scenario scripts x Number o f key classes x x Number of support classes x A verage number of support x

classes per key class N umber of subsystems: x x x aasssize x x x Number of operations x x x x

overridden by a subclass N umber of operations x x x

added by a subclass Specialization index x x x x

Openmirrors.com

~ Cutomer

a ~- -

Manager

Reyal Service Station

Contrellhl9 lnHnhry

Atceunt1n9 S1rvle11

Section 6.7 00 Measurement 355

Putt 01,erln9 Syitem

Fol Ordering

L~---t------~ Srsten

.• Jli P1hte1 System

Ctedlt C11d Syttem

FIGURE 6.39 Use case diagram of the Royal Service Station .

We ca n ca lculate some o f the re maining measures by referring to the class hie rar- ch y of the system design re prese nted in Figure 6.40. The table at the left of the fig ure lists the maximum and minimum values for each of the five Lore nz and Kidd metrics de rived [rom this design. We can use these measures as a baseline from which to evalu- a te gro wth as the syste m evolves.

00 Design Quality Measures

Chidambe r a nd Ke mere r (1994) have also devised a suite of metrics for 0 0 develop- ment. Their work is more foc used on design quality than on size, so it comple ments the wo rk of Lo re nz and Kidd. In addition to size me asures such as we ighte d methods per class, de pth o f inhe ritance, and numbe r of childre n, Chidamber and Ke me rer measure the coupling be tween o bjects, the response for a class, and the lack o f cohesion in method s (LCOM). Table 6.6 sho ws whe re each of these me trics can be coUected and used during developme nt. Because they are wide ly used and h ave become a stan da rd to whic h o the r 00 me tri cs are compared , let u s look mo re closely at some of the Chidambe r-Ke me re r metrics.

We no ted in C hapter 5 that we can measure aspects of design quality, such as com- ple xity. As we will see in Chapte r 11, there are also several ways to measure the complex- ity o f a piece of cod e. Chidamber and Kemerer leave the definition of comp lexity open, so

Metric Min

Namber of 21 Ker Clum

Clm Size 0

Namber oF Opmtiont 0 Overridden

Namber of Oieretlont 0 A ded

Speel1lization Index 0

Mu

21

9

0

.... "'' llllllll• _ _ ,,...,.,g

,.....,_ ... kf hf- •rm•t: ~ ..

"" .... ln"4 ... .,. .. , ... _ .. 1- .,,._hlHM htt_rflhlu(J - .. _....iu

.. ,.. .... upfnt91 4ttt .,,,.,. tM l11u

,., ...

... ., .... tt fl

FIGURE 6.40 Oass hie rarchy for Royal Service S tation. plus Lore nz and Kidd measures.

Openmirrors.com

'""'"" .. ,. ... I'"" ... Im

Section 6.7 00 Measurement 357

TABLE 6.6 Chidam ber and Kemerer Me trics Collection in Diffe rent Phases o f Development

Met ric

Weighted methods pe r class Depth of inh eritance Number of children Coupling between objects Respo nse for a class Lack o f cohesio n of methods

System Design

x x x

Pba.se

Program D esign

x x x x x x

Coding

x x

Testing

x x x x

x

that the developers can choose a complexity measure appropria te fo r the project Then, Chidamber and Ke me rer use the number of methods, n, with the comple xi ty of each method, c, as a weight in defining a we ighted complexity me asure for classes:

n

weighte d me thods per cl ass = ,Le; i=I

That is, we sum the set of method complexities to find the total complexi ty for the class. If the complexity of each me thod is 1, then the complexity is simply the numbe r of methods in the class. 'CT1e numbe r o f methods and the comple xity of meth ods suggest the amount o f time and e ffort needed to buiJd and maintain the class; the larger the number of methods, the more the e ffo rt and the grea ter t he impact o n the child ren o f the class.

They also conside r a class's de pth in the inheritance hie rarchy (wi th de pth=l be ing the roo t): the dee per a class is in the hierarchy, the mo re me thods it is likely to inherit. This characte ristic makes the class harder to understand and harde r to main- tain. Ano the r metric is the numbe r o f immediate subclasses subordinated to the given class. This measure is an indication of the degree of varia bility of the pare n t class, and thus is ano ther indicator of the e ase o f mainte nance, testing, and reuse.

We can apply these co ncepts to the architecture fo r the Roya l Service Statio n. In Figure 6.41, we see pa rt of the d esign re lating to accounts, biUs, and payments. For the Bill class, the weighted me thod s metric is 2, and the d epth of inheritance and the num- be r o f childre n are each 0.

The coupling between a Bill and othe r objects is 1, because the Bi ll class is associated o nly with the account be ing billed. H owever, coupling between a n Accoun t o bject and associated o bjects is 5 , as we can see from the five arrows entering o r leaving the box represe nting that class. A s we noted earlier in this chapter, excessive coupling in any design is undesira ble; we want to maximize the in dependence of each class, so tha t it is easie r to deve lop, maint ain, test, and reuse.

Calculating the degree of cohesion in methods is m ore complica ted. Consider a given class C with fl me thods, M 1 through M 11• Suppose Ii is the set of instance variables used by the method Mi. Then the re are fl such sets, one for each of the n methods. We can de fine P to be a collectio n o f pairs (/,, Is) wbere I, and Is sha re no common members,

w Ill ..

e ...... ., Ulll ... , ... •111J11lm

I

I .. • I Ythlclt

1 ... 1mmu_rMlod11i1

I

~ .......... .

Metric

Wei11hted Methods I Clm Number of C1hildren Depth of Inheritance Tree Coupling Between Objects

I I

I

I

Bill

2

0

0 I

6 8111 ....... • ... 111.-.4 ....... _ .. •kt - ........ .. , .... - ,, .. _k l .... .. , .... ,: ~ .. , ... ..,, .. ,_,.,_ mru•u lll1J1tdo111110 IUlllmt(J ....... ""'" ltrllW IUMllllll ~'"-'"''"""ll

. I - ....... ff,,_Utf_Wtllllf(J .... I I: ... ••Miii

I C1t411 Cu4 ........

.. ,4,. .. ntl11t1"_4ttt •pt_,, ... , ...

Payment Credit Card

Account Customer Pavment

0 0 s 0 1 0 0 0

0 I 0 0 2 I s 2

FIGURE 6,41 Chidarnber-Kemerer metrics applied to the Royal Service Station cl..., design.

Openmirrors.com

Vehicle

I

0

0 2

Section 6.7 00 Measurement 359

a nd Q is the coUection of pa irs (1,, Is) where I, and Is share at least one common mem- be r. More forma lly, we define P a nd Qin the following way:

P = l(I,,Is)I I ,nis = 0) Q = l(I ,, l s)I I,nis -::f:. 0 )

We define the LCOM fo r C to be IPI - IQI if IPI is greater than IQI. Otherwise, LCOM is ze ro. In pla ine r language, the LCOM is the degree to which there a re more pairs of methods tha t do not sha re varia bles than there are pairs of me th ods that do share vari- ables. The me tric is based o n the no tion that two me thods are related if th ey share an instance variabl e. The large r the number of related methods, the mo re cohesive the class. Thus, the LCOM metric is a measure of the relatively disparate nature of the methods in the class.

Another metric, the response fo r a class, is the set o f methods that might be exe- cuted in response to a message received by an object in that class. If many me thods can be invoked when a message is received, then testing and re pair become far more difficult. So designers should atte mpt to keep response for a class low and to view high values as an indication tha t additional scrutiny of the class and its implemen tation is warranted .

We can also use the C hidamber- Kemere r metrics to evaluate design changes. Con- sider the part o f the module design for the Royal Service Station, shown in Figure 6.42, that is exte nded with user-inte rface modules. We can see fro m the table in the figure tha t the coupLing between objects for the Bi ll class h as increased from one to two, but the o the r metrics for bill, account, and payments h ave stayed th e sam e.

The me trics help to identify pro blematic areas of the design. For each metric listed be low, a higher value indicates greater likelihood of fa ults in the corresponding code:

• the larger the we ighted complexity of a class (i.e., the system is mo re comp lex and therefore harde r to understand)

• the more children a class has (i.e., there is greater variability in the class' hierarchy and therefore more code to implement and test)

• the larger the de pth of the class's inheritance (i.e .. , attributes and methods are inhe rited from a large r collectio n of ancestor classes, thus the class is ha rder to unde rsta nd)

• the large r the response for a class (thus, there are m ore methods to implement and test)

These guide lines we re suggested in an empirical ev aluati on o f C++ code do ne by Basili, Briand, and Me lo (1995). Li and Henry (1993) studied these metrics too, adding two of their o wn to a pre liminary set de fined by Chidamber and Keme rer:

• message-passing couplin g: the number of metho d invocations in a class's imple- mentatio n

• data abstraction coupling: the numbe r o f abstract data types used in the mea- sured class and de fined in a nothe r class o f the system

Li and Henry showed how these metrics can be used to p redict the size o f changes in classes during mainte nance.

lK 0

MHUt U• t .. , .... - 4ot•lut: ... , ...

I tup114() ----1 rMetlw11t()

ttflt! IWH ttl)

1111_rt•l14trU .. , .... ,_.,.,.. .. ,() ....

Metric Bill

Weighted Methods I Clm 2 Number ol Children 0 Doth of I nherihnce Tree 0 Couplin1 Between Objech 2

1111 1111 111'1• 4ott 111...i

K>----l· ... 4. .. i-:_-------0! ~.1,~

Payment

0

1 0

2

'"'-"'-mrttt_k lMCt ll1t_J1rdi11t1(1 , .... ttttl

.... ..... ,

'"' .. , .. .. ,.,., .... _ ... . . _,, .. ,, .. . Credit Card

Payment

0

0 1

1

mttMr llM

Oh 81tt1ft

Bill Okay Account·

Screen Button

s 1 () 0 0 ()

0 0 ()

s 3 1 FIGURE 6.42 Otidamber-Kemerer m ecrics applied ro a modified R oyal Service Station design.

Openmirrors.com

T11tloo1

Textbox

0

0 0

1

I: P•tltl19 (I

spaet Is m ll•ll•

Metric

Average operation size

Average number of parameters per operation

Service Station

2: ektek_ mll••ilitr!I

3: HW_fmhm

(aeuutl, ''''• p•tlti19, 'u11tittl

Section 6.7

Min

s

0

00 Measurement 361

Mu

s

4

4: on1_parllo9 (lmHMJ

P1r•1n9 Ptrmlt

S: tpJ•tt_ mil•bility(I

FIGURE 6.43 M easuring from a seque nce d iagram.

Travassos and Andrade (1999) suggest o the r possibl e me trics fo r 00 syste ms. The number of messages sent by an opera tion ca n be used to calculate the average o peration size. Similarly, it may be useful to know tbe average number of parame ters pe r message. Each operation itself can be evalua ted in terms of a host of comple xity me asures that apply e qually well to non-00 developme nt. The above measures are shown in Figure 6.43, applied to a seque nce diagram for the Royal Service Station. Since the operation re presented has five messages, tbe maximum a nd minimum ope ra - tio n sizes are the same: five. We can see that the fourth message re quires four parame - te rs, a o.d the first message requires none, so the ave rage numbe r of parameters pe r message can range from zero to fou r.

We can also derive measurements from a class description. For example, consider this template for the refuel class:

C1a•• names Refuel

Category: service External documents: Export control : Public

Cardinality: n

362 Chapter 6 Designing the Modules

Hierarchy: SUperclasses: Service

Associations:

<no rolename> : fuel in association updates Operation name: price

Public member of: Refuel

Documentation:

II Calculates fuel final price Preconditions:

gallons > 0 Object diagram : (unspec ified )

Semantics: price = gallons * fuel.price_per_gallon

tax = price* purchase . tax_rate

Object diagram: (unspecified)

Concurrency: sequential Public interface:

Operations:

price

Private interface: Attributes:

gallons

:i:nplementation: Attributes:

gallons

state machine: no Concurrency: sequential

Persistence: transient

From this template, we can find Lo renz and Kidd's class size, calculated as the total number of operations plus the number of attributes (including inherite d fe atures). H e re, the class size is four. We can also evaluate a class in te rms of mo re traditional measures, such as fan-in (the numbe r of classes calling thi s class) and fan-out (the number o f classes caUed by this class). Such measures can assist us with baselining and tracking, so we can observe growth in complexity and evaluate proposed changes.

Where to Do 00 Measurement

There are many ways to measure 00 syste ms, and the " best" se t o f metrics is yet to be identified. It is important to remember that measm eme nt is valuable only when we can apply it to incre ase our understanding, prediction, o r control. Any or all of the me trics presented he re, or others in the lite rature o r that you d evise fo r yo ur own projects, can b e he lpful, depending on ease of collection and re levance to the problem you are trying to solve. We can examine the metrics presented in this chapter to d e termine which ones are best capture d from the various 00-re lated docume nts we have described.

Openmirrors.com

Section 6.8 Design Documentation 363

TABLE 6.7 Where to Capture 00 Metrics

Phase

Class Interaction Class Package Metric Use Cases Diagrams Diagrams Descriptions Diagrams

Number of scenario scripts x Number of key classes x Number of suppon classes x Average number of support x

classes per key class

Number of subsystems x Class size x x Number of operations x

overridden by a subclass Number of operations added x

by a subclass Specialization index x Weighted methods in class x Depth of inheritance x Number of children x Coupling between objects x Response for a class x Lack of cohesion in methods x Average operation size x Average number of parameters x

per operation Operation complexity Percent public and protected x x Public access to data members x x Number of root classes x Fan-in/fan-out x

As you can see in Table 6.7, the re are metrics related to many types of documents, incl udiog use cases, class diagrams, interaction diagrams, class descriptions, state diagra ms, and package diagrams. In ge neral, measurement s upports development by highlighting po tential proble ms. Just as each type of diagram or chart reveals an issue or perspective that enhances our understanding of the problem or solution , each metric provides a differ- ent perspective on the d esign's quality and complexity that can he lp us anticipate and address problem areas of the software during development and maintenance.

6.8 DESIGN DOCUMENTATION

In Chapter 5, we discussed bow to capture the details of the system architecture in a Software Architecture Document (SAD) . The SAD acts as a bridge between the require- ments and the design. Jn t he same way, the program design acts as a bridge from the archi - tectural design to the cod e, describing the modules in enough detail that programmers can

364 Chapter 6 Designing the Modules

implement them in a way that is consistent with tbe SAD, with good design principles, and with what the users expect to see in the finaJ product (i.e., according to the requirements).

There are many ways to docume nt the design. Much of it depends on developer prefe ren ce and expe rien ce, and on the needs o f the programmers and maintainers whose work de pends o n care ful, complete documentation. ln thi s section , we explore a particular approach to documentatio n, called design by contract, that uses the docwnen- tation n ot o nJy to capture the design but to encourage inte ractio n among develope rs.

In eve ryday life, a contract is written between two parties wh en one commission s tbe o the r fo r a pa rticula r se rvice or product. Each party expects some benefit for some o bligatio n: the supplier produces a service o r product in a given pe riod of time (a n obli- gatio n) in exchange fo r money (a benefit), and the cli ent accepts the service o r product (a bene fit) fo r the mo ney (an o bligatio n). The contract makes au obliga tions and be ne- fits explicit. In building software, a contract is an agreement between a module's provide r and its user, as shown in Figure 6.44.

In design by contract, each moduJe bas an interface specification that precisely d escribes what the module is supposed to do. Meyer (1997) suggests that design by con- tract he lps ensure that moduJes interoperate correctly. This specification, calJe d a contract, gove rns how the moduJe is to interact with other moduJ es and systems. Such specification cannot guarantee a moduJe's correctness, but it forms a clear and consis tent basis fo r testing and verification. The contract covers mutual obligations (the precondi- t.io ns), b e nefi ts (the postconditions), and consistency constraints (calJ ed invariants). Toge the r, these contract properties are calJed assertions.

As the mo<luJe provider, we upho ld o ur e ntl u f the w ntrnct as long as

• our module provides (at the le ast) all of the postconditions, protocols, and qua lity attributes that a re adve rtised in the inte rface specification

• our code requ.ires from its environment no more than what is state d in the inter- face 's precondition s and protocols

As a software-unit us.e r, we upho ld the contract as long as

• o ur code uses the unit onJy when the un.it's s pecified preconditions and protocols are satisfied

• our code assumes no mo re about the unit 's behavior than is stated in its inter- face 's postconditions, pro tocols, and inva riants

Software Unit Pro~ider

Software Unit User

FIGURE 6.44 D esign contract between software provider and user.

Openmirrors.com

Section 6.8 Design Documentation 365

As we maintain the software system, the interfaces continue to apply: a software unit can be replaced by any new impleme ntation that adhe res to the unit's inte rface specifi- cation. Thus, contracts help us adhere to the substitutability design principle.

For example, conside r a software unit that maintains a dictionary of elements i.ndexed by a key. The provide r of the software unit is resp onsible fo r providing operations to majntain the dictionary's contents. The software unit's users are respon- sible for invoking those operations correctly. For example, to insert a new entry into the dictio nary:

1. The clie nt ensures that the dictionary is not already fuJJ , that the element has a valid key, and that the dictionary does not already have an element indexe d by that key.

2. The provider inse rts e leme nts into the dictionary. 3. If an element to be inserted has an invalid or duplicate key, no action is take n.

We can formalize this contract by being more precise about various respon- sibilities. Meyer (1992a) suggests a format in which a require clause specifies a method's precondition and an ensure clause sp ecifies a me thod 's postcondition:

II Implements data abstracti o n dictionary that maps String keys to Elements

loca1

count: INTEGER

capacity: INTEGER

dictionary: functi o n that maps Key to Element

insert(elem: Element; key : String)

II Insert elem into dictionary require: count < capacity and key.valid () and not has(key)

enaure: has(key) and retrieve (key) ==elem

retrieve ( key: String): Element

II Returns the element indexed by key

require: has(key)

enaure: result = dictio nary ( key)

Contracts also specify class invariants, which are properties over the instance variabl es that ho ld after eve ry method invocatio n, including immediately after the con- structo r me thod creates each object of the class. For example, the above dictio nary should never have duplicate e ntries:

invariant: forall (keyl, El ement!) and (key2, Element2) in dictionary,

if keyl<>key2 then Elementl<>Element2

Class invariants are especiaUy useful fo r testing the correctness of our design and test- ing design cha nges.

Contracts can be constructed for all types of designs. For example, suppose we are using data abstraction to design an 00 system that controls the flow of water into rese rvoirs and o ut thro ugh dams. We may have classes of objects, such as Dam, Reservoir, and River. We ca.a ask questio ns about the obj ects, such as is_empty

366 Chapter 6 Designing the Modules

and is_full for a reservoir, and we can issue commands, such as empty or fill. Our design can specify preconditio ns and postconditio ns; for instance, we may write

local gauge: I NTEGER capacity: INTEGER

fill()

//Fill reservoir with water r e qui r e: in_valve.open and out_valve .closed e nsure: in_val ve .closed a nd out_valve .closed and i s_full

is_full(): BOOLEAN II Tests whether reservoir is full ensur e: resul t == (0.95*capacity <=gauge)

A contract can be compared with subsequent implementations to prove mail:be- maticalJy that the two are consistent. In addition , the contract's assertions provide a basis fo r testing. Class by class, the testers can de termine the effects of each operati on o n each assertion. Mo reove r, when the design is changed in some way, each assertion can be checked to see if it is weakened or strengthened by the change.

6.9 INFORMATION SYSTEMS EXAMPLE

We saw in Chapte r 5 ho w to structure the architecture of the Picca diUy system as a clie nt-serve r syste m. But tha t design conside red onl y the initial d ecomposition of the system into its majo r compo nents. No w we need m ore de tail about the individual com- ponents, so that programme rs can imple ment the e lements of the architecture as code. Fo r example, the design needs more information about bow to handle situations in which programs are o n at similar but no t identical times. For instance, a Piccadilly pro- g ram that is televised from 9 PM to 10:30 PM may overlap with programs that air frnm 8 PM to 10 PM and from 10 PM to 11 PM. We must also decide how to handle faults; in this case, the Opposition schedule may contain an invalid date, such as February 31, or an inva lid time, such as 2900 hours. Our lo west leve l of de tai l should include module inter- face specificatio ns, so that programmers can be assigned to code and test individual modules. Neverthe less, this example shows that we must consider and combine a vari- e ty o f complementary d esign techniques to formulate a solution that meets all of the custo me r's needs.

As we decompose our design into modules, we may n eed to reorganize which data and operations we combine into modules, to improve cohesion and coupling in the overall design. For example, at the end of Chapter 5, we identified a number of domain e leme nts and re lationsh:ips that the Piccadilly database will need to maintain, including the concept o f Opposition Program shown in Figure 6.45. H oweve r, if we look at the mod els care fully, we see that the re is conside rable commo nality in what we origi- nally tho ught we re disjo int conce pts. In particula r, the information and operations that we associate with Piccadilly te levisio n programs are the same as those that we associate

Openmirrors.com

Section 6 .11 What This Chapter Means for You 367

Opposition Opposition Program I .. * broadcasts "' name pro5ram name -address station pro9nm transmission date

phone number transmiuion start time transmission end time transmission duration predicte~ rating

FIGURE 6.45 Data model of Opposition Programs broadcast by Piccadilly's competition.

with tbe programs broadcast by opposition stations. Figure 6.46 shows how we might integrate these concepts and the ir respective associations into a single Program class. With this re factoring, we avoid the extra work of implementing and testing separate ve rsions of the same concept; we also avoid the headache of trying to maintain both versions of the class as it is moclified or e nhanced in the future.

In general, whether we are working on the design of a to-be-developed system or are enhancing an existing software system, we need to reevaluate and refactor the design's modular structure continually in order to minimize the coupling between modules.

6.10 REAL-TIME EXAMPLE

The proponents o f 00 development o ften tout the obj ects' reuse potential. As we have see n, the Ariane-5 system reused the ine rtial reference software (SRI) from Ariane-4. H ad Ariane -5 been impleme nted using an 00 approach, the reuse would have been in te rms of e ithe r compos:ition or inheritance. In a compositional approach , the SRI is viewed as a black box and is called from the main system, returning appropriate values for use in other parts of the Ariane-5 system. In an inheritance approach, the SRI struc- ture and behavior are open to view, inheriting as much structure and behavior from parent classes as possible . A compositional approach is not likely to have prevente d the disaste r that occurred , since the black box would not have made the ove rfl ow problem visible. On the othe r ba nd, an inheritance-based re use might have exposed the SRI design vulnerabilities to the Ariane-5 designers. They might at least have seen the unprotected exceplion and the comment stating that the exce ption would never be raised. Then, they might have reexamined this assumption and taken preventive action.

6.11 WHAT THIS CHAPTER MEANS FOR YOU

This chapter has described both program design and some 00 development processes that support it. We have seen the need for modular designs that allow development teams to work in parallel on the design, imple me ntation, and testing of separate soft- ware units. Each unit is described in terms of an interface that exposes what other pro- grammers need to know to use the unit, while hiding design decisions that might change

368 Chapter 6 Designing the Modules

Agency name address phone number

0 .. 1 a9enoy

coordinates

0 .. * campai9n Advertltlng Campaign

Opposition campaign number * - Commerchl name start date - address end date name phone number duration d i1posal date

budget

o .. * ~ station target audience target rating percentage required spot duration

roadcasts add commercial()

* pro!nm remo~e commercial() build campaign()

Program price oampa lgn ()

program name tnnsm ission date transmission sll rt time

* tnnsm ission end I ime transmission du rat ion Commercial Spot audience type

duration predicted rating

scheduled fo~ ~enl

* Commercial Break Rate Segment

associated with date Episode * * start time

day of week

percentage of ndisnee type end time segment time

sold value moveability unsold VI lue spot rate minimum rate

calc price() predicted rating

mroh II find time()

FIGURE 6.46 Integrated data model that merges Programs and Opposition Programs.

in the future. Such interfaces must include qua lity attributes as well as functionality, so tbat othe r programme rs can de termine whether the unjt meets all of their reqillre- me nts, iincludjng nonfun ctional require ments.

We have presented several design principles usefuJ in helping to keep your design s modular, reusable, and secure, and some design patterns that support the desjgn prin- ciples. At the same time, we have introduced several metrics that are commonly used to measure size and design cbaracteristics of 00 artifacts. These measurements help us not

Openmirrors.com

Section 6.14 Term Project 369

ooJy to predict resource allocation for development, testing, and maintenance; they also act as warnings when the system is becoming complex and difficult to understand.

6.12 WHAT THIS CHAPTER MEANS FOR Y OUR DEVELO PMENTTEAM

"The design process describes the system components using a common language with which to communicate. Object orie ntation is a particularly appealing basis for such design, because it allows us to describe and reason about the syste m from its birth to its de livery in the same terms: classes, objects, and me thods. Th.is consistency of terminology e nables you to anticipate the size and structure o f a syste m weU before the design is com- ple te. It simplifies the traceability across artifacts; you can see how a domain object in the require ments becomes an object in the design and then an object in the code, for instance.

A consistent notation makes it easier for your te am to understand the implications o f using a particular object o r class-especially when you are constructing a system from someone e lse's 00 components. Mo reover, consistency assists the maintainers and testers, e nabling them to build test cases and monitor changes mo re easily. And because the requirements, design , and code are expressed in the same way, it is easier for you to evaluate the effects of proposed ch anges to the requireme nts or desjgns.

6.13 WHAT THIS CHAPTER MEANS FOR RESEARCHERS

Both program design and the 00 approach have been fertile fields for softwa re e ngi- nee ring research. Design principles arc heuristics for improving d esigns, but relatively Little resea rch has been done to evaluate whethe r following the principles actually results in consiste ntly high-qual.ity code over the lj fe of a system. Simil arly, object orientation has been embraced but not often rigorously compared with other development paradigms in te rms of quality (especially security). Indeed , traditi onal ways of evaluating a system have been inappropriate or inadequa te for object orientation. Projections based on lines of code are being replaced by prediction methods that take advantage of the characte ris- tics of classes and hie rarchies. In particular, research on fault prediction has produced new, more 00 ways of estimating the number of proble ms remaining in designs or code.

O the r resea rche rs are evaluating the best ways to exploit the best characteri stics of object orientation. How dee p should the hie rarchies be? Whe n is composition be tter than inheritance fo r re use? What are the best ways to take advantage of inheritance and polymo rphism? Coupled with these resea rch areas is a continuing effort to find good ways to measure the 00 process and its products.

6.14 TERM PROJECT

Review your req uire me nts fo r the Loan Arranger system. How wouJd they change we re they to be impleme nted as 00 require me nts? How would these changes make the system easier to fix or change? Next, review the characteristics of 00 systems. Would any of these characte ristics be beneficial for the Loan Arranger? Finally, deve lop an 00 design for the Loan Arrange r. WiU it be easy to test the resulting imple- mentation? To change? Why?

370 Chapter 6 Designing t he Modules

6.1 5 KEY REFERENCES

There are several good books that provide de t-0ile d instructions o n how to think about systems in a n 00 way. Gamma et al. (1995) provide an overview of how to think o f sys- tems in te rms of design patte rns. Books such as Booch ("I 994), Ja cobson et al. (1995), and Rumba ugh et aJ. (1991) offe r detailed info nnatio n about how to specify, design, and code 00 systems. These three approaches form the basis for the UML. The classic texts on the UML are The UM L User G uide (Booch, Rumbaugh, and Jacobson 2005) and The UM L Reference Manual (Rumbaugh, Jacobson, a nd Booch 2004). In additi on, Larman (2004) offers an excellent primer o n htow to use the UML. Binde r (2000) describes eve rything you ever wan ted to know about testing 00 syste ms; it is fuJl of good examples and counterexamples.

The classic referen ces on 00 measure ment include Chida mber and Keme rer (1994), Li and Henry (1993), and Lorenz and Kidd (1994). Travassos and Andrade (1999) tie together the goals of OO measureme nt with some sensible guidelines for 00 d evelopment.

6.1 6 EXERCISES

1. Manny, the Royal Service Station manager , is going to expand his services to include an automated car washin g system. The custome r chooses the type of wash and specifies the type of car. The system computes the fee and displays the amount due on a control pa nel. The customer can then pay for the car wash . After payme nt, if the wash is currently busy, the system indicates that the custo mer must wait. Otherwise, the system indicates that the custo mer should drive the car into the car wash bay. How would you change the U ML c lass diagram in Figure 6.21 to accommodate th:is new service?

2. What is the signi.ficance of Lorenz and Kidd's sp ecialization index? What are the implica- tions of a high specialization inde x? A low one? A major change in the index as the prod- uct evolves?

3. Can an 00 approach be used to develo p any system? What are the strengths of object orientation? What are its weaknesses? Give an e xample of a syste m where object orie nta- tion would not be an appropriate development s trategy.

4. The re is stamp coupling between two so ftware units if one of those units passes complex data structures t o the other unit (e.g., as parameters in a method call). Suggest a wa y to refine such a design to avoid stamp coupling.

S. In the Ariane-5 design. the developers made a conscious decision to leave out the excep- tion handling for three of seven exceptions tha t could be raised. What are the legal and e thical implications. of this decision? Who is legally and mo rall y responsible for the disas- te r that resulted ? Are the testers at fault for no t having caught this design flaw?

6. For each type of cohesion, write a descriptiolll of a component exhibiting that kind of cohesion.

7. For each type of coupling, give an example o f two components coupled in that way. 8. For a project that you have already developed fo r another class, draw a system diagram of

your software using multiple levels of interconnected components. How modular was your syste m? What kind of coupling did it exhibit? Were the components cohesive? Can your syste m be restructured to increase the cohesion and decrease the coupling of components?

Openmirrors.com

Section 6. 16 Exercises 371

9. Can a system ever be completely "decoupled"? That is, can the degree of coupling be reduced so much that there is no coupling between compone nts? Why or why n ot?

10. Are the re some syste ms tha t canno t be made complete ly functionally cohesive? Why or why not?

11. For each of the qua lity attributes in the quality mode ls of Chapter 1, explain how the characte ristics of good design contribute to the product quality. For example, how do coupling, cohesion, and modularity affect reliability and traceability?

U. A recursive component is one that calls itself or in some way re fers to itself. Given the design guidelines presented in this chapter, is a recursive component a good or a bad idea? Why?

13. For a comple x module that you have already developed fo:r another project, specify the module at varying degrees of abstraction (according to the descriptions in Sidebar 6.3). How might each abstraction be distinctly useful?

14. Provide an interface specification fo r a module that serves as an English- French diction- a ry. The module sho uld provide facilities for adding new words to the dictionary, looking up the pronunciation of a French word, a nd returning the F rench word that corresponds to a n input Eng.lish wo rd.

15. Conside r the following procedure interface for a module that sorts data:

PROCEDURE sort (a [] : INTEGER) en•ure: reorders elements so that they are in nondecreasing order

In what ways could this module be redesigned to improve its gene ra lity? 16. Consider a module that ta kes two a rrays of integers, and creates and returns a new array

o f integers whose e le ments are the sums of the respective elements of the input arrays. How might this module fail? If this module were responsible for recovering from these failures, how might it do so?

17. Inexperienced 00 programmers o ften imple ment the following class hierarchy, where a Stack class is defined to be a subclass of List:

CLASS List { data: array (1 .. 100] of INTEGER; count: INTEGER:= 0 ;

METHODS

insert (pos : 1 .. 100; value: INTEGER); require: insert value into List at position pos

delete (pos : 1 .. 100 ) en•ure: remove value stored at positio n pos from List

retrieve (pos : 1 . . 100): INTEGER; enaure: return value stored at positi o n pos in List

CLASS Stack EXTENDS List METHODS

push(value: INTEGER ) en•ure: append value to end of Stack

pop(): INTEGER; en•ure: remove and return value from end of Stack

Explain why this is a bad use of inhe ritance.

372 Chapter 6 Designing the Modules

I

18. C onsider the following four specifications to insert an element val into a list l i st. For e ach pair of specificatio ns, state whether one is substitutable for t he other. D efend your answer.

(a) require: val is not in list e nsure: list contains all of its previous values plus val

( b) e nsure: if va l is alread y in l i st, then li st is unchanged ; otherwise l ist contains a ll o f its previous values plus v a l

(c ) e nsure: 1 is t conta ins all of its previous values plus val ( d) require: list is sorted

e nsure: l i st contains all of its previous values plus val , and l ist is sorted

19. An a lte rnate versio n to specification 18(a) would be (a' ) below, which declares an excep- tion ra ther tha n requiring that the list not alread y contain the element to be inserte d:

(a' ) exceptio n: throws Dupl i cateEle m if val is alre ady in 1 ist e nsure: 1 i s t contains all of its pre vious values plus val

Which version of sp ecification, a or a', is better, and why?

20. R ewrite the sp ecificatio ns in Section 6.8 (on design documentation ) t o use exceptio ns. 21. You are a bout to ch oose be tween two modules t o use in your desi gn, both of which com-

pute the minimum value in an array of integers. One module returns the smallest re pre- senta ble integer if the input array is empty. The other module requires a nonempty array. Which module is better, a nd why?

22. Consider a simplifie d 00 design, shown in Figure 6.47, for a banking system. Accounts can be created at the bank, and money can be de posited and withdrawn from the account. An account is accessed by its account number. Use the D ecorator design pattern to add two new banking features to the design:

(a) Overdraft protection: a llows the customer t o withdraw money when the account bal- a nce is ze ro; the tota l amount that can be withdrawn in this -feature is a pred efined credit limit.

( b) Transactio n fee: charges the customer a fixed fee for each deposit and withdrawal transactio n.

23. A bank must report to the government's tax institution all transactions (deposits and withdrawals) tha t e xceed $10,000. Buildin g on the initial design of the banking system fro m question 22, use t he Observer design pattern to construct a class that monitor s all Account transactions.

Account

b1l1nee : Monev = 0 Buk 1 ~ 1eeount #

leruteAeeountfl ~ 9et81lme() : Money

deposit !•mount) withdriwl1mount) : boolun

FIGURE 6.47 Design for banking system in Exercises 6.22 and 6.23.

Openmirrors.com

7

In this chapter, we look at • standards for programming • guidel ines for reuse • using design to frame the code • internal and external documentation

So far, the skills we have le arned have helped us to understand the customers' and use rs' problem and to de vise a high-leve l solution for it. Now, we must focus on imple- menting the so lutio n as software. That is, we must wri te the programs that imple ment the design. This task can be daunting, for severaJ reasons. First, the designe rs may not have addressed alJ of the idiosyncrasies of the platform and programming environ - ment; structures and re lationships that are easy to describe with charts and tables are no t always straightforward to write as code. Second, we must write our code in a way that is unde rstandab le oa t o nly to us when we re visit it fo r testing, but also to o thers as the syste m evolves over time. Third, we must take advantage o f the characte ristics of the d esign's o rganizatio n, the data's structure, and the programming langu age 's constructs while stilJ creating code that is easily re usable.

Clea rly, the re are many ways to implement a design, and many languages and too ls are available; we cannot hope to cover aJI of them in this book. In this chapter , we present examples fro m some of the popular languages, but the guidelines are generalJy applicab le to any implementatio n. That is, this chapter does not te ach you how to pro- gram; rather, it explains some o f the software en ginee ring practices thal you should kee p in mind as you write yo ur code.

7. 1 PROGRAMMING STANDARDS AND PROCEDURES

During your career, you are like ly to work on many different software projects, writing code in many applica tio n do mains using a varie ty o f tools and techniques. Some of your wo rk will also invo lve evaluating existing code, because you want to replace or mo dify it, o r to reuse it in anothe r app licatio n. You wi ll also participate in formal and informal reviews to e xamine your code a nd othe rs'. Much o f this work will b e different from the

373

374 Chapter 7 Writing the Programs

programming you have done for your classes. In class, your work is done inde pendently, so that your instructor can judge its quality and su ggest improvements. H owever, in the wider world, mos t software is developed by te ams, and a variety of jobs are r e quire d to generate a quality product. Even when writing th.e code itself, many people are usually invo lve d, and a great deal o f coope ratio n and coordina tio n is re quire d. Thus, it is very important for othe rs to be able to unde rstand no t only what you h ave writte n , but also why you bave writte n it and how it fits in witb tbeir work.

Fo r these reasons, you must know your organizatio n's standards and procedures befo re you begin to write code. Many companies insist that the ir code conform to style, format, and content standards, so that the code and associate d documentation are c lear to e ve ryone who reads the m. Fo r e xample, Side bar 7.1 d escribes Microsoft's approach to programming standards.

Standards for You

Standards and proce dures ca n he lp you to o rganize your tho ug hts and avoid mis takes. Some of the proce dures invo lve me thods of docume nting your code so that it is cl e ar and easy to follo w. Such documentation allows you to le ave and r e turn t o your work witho u tt losing track of what you had been doing. Standardized docume ntation also he lps in locating faults and making c hanges, because it clarifies wbicb sections of your program pe rform whicb functio ns.

SIDEBAR 7 .1 PROGRAMMING STANDARDS AT MICROSOFT

Cusumano and Selby (1995, 1997) have studied software development at Microsoft. They point out that Microsoft tries to blend some aspects of software engineering practice into its software development cycle while preserving the creativity and individuality that hackers

usually exhibit. Thus, Microsoft must find ways " that structure and coordinate what the indi- vidual members do while allowing them enough flexibility to be creative and evolve the prod- uct's details in stages." Because of market pressures and changing needs, Microsoft teams iterate among designing components, building them , and testing them. For example, team me mbe rs revise both the types of features and their details as they learn more about what the produc t will do.

However, flexibility does not preclude standards. Nearly all of Microsoft's teams work at a single physical site, using common development languages (usually C and C++), common coding styles, and standard development tools. These standards help teams to communicate, to discuss the pros and cons of different design alternatives, and to resolve problems. Microsoft also re quires its teams to collect a small set of measurements, including information about whe n failures occur and when the unde rlying faults are found and fixed. These measurements guide decisions about whe n to continue development and when to ship a product.

Openmirrors.com

Section 7.1 Programming Standards and Procedures 375

Standards and procedures also help in translating designs to code. By structur- ing cod e according to standards, you maintain the corresponde nce between design compooeots and code compo ne nts. Conseque ntly, changes in design are easy to imple- ment in the code. Similarly, modjfica tions to code that result from changes in hard- ware or inte rface specifications are straight fo rward, a nd the possibility of error is minjmized.

Standards for Others

Once your code is complete, o thers are Likely to use it in a variety of ways. For example, as we shall see in late r chapte rs, a separate team may test the code. Or another set of people may integrate your software with oth er programs to build and test subsystems and finally the whole system. E ve n after the system is up and running, changes may be needed , eithe r because of a fault or because the customer wants to change the way the system pe rforms its functions. You may not be part of those mainte nance or test teams, so it is essential that you o rgaruze, format, and document your code to make it easy for oth e rs to understand what it does and how it works.

Fo r example, suppose eve ry program produced by your company begins with a sectio n describing the program's functions and inte rfaces with other programs. The operung section might look like thls:

* * *****************************************************

* * COMPONENT TO FIND INTERSECTION OF TWO LINES * * COMPONENT NAME: FINDPT * PROGRAMMER: E. ELLIS * VERSION: 1.0 (2 FEBRUARY 2001)

* * PROCEDURE INVOCATION :

* CALL FINDPT (Al, Bl, Cl, A2, B2, C2, XS, YS, FLAG) * INPUT PARAMETERS :

* INPUT LINES ARE OF THE FORM

* Al*X + Bl*Y + Cl = 0 AND * A2*X + B2 *Y + C2 = 0 * SO INPUT IS COEFFIC IENTS Al , Bl, Cl AND A2, B2, C2

* OUTPUT PARAMETERS :

* IF LINES ARE PARALLEL, FLAG SET TO 1. * ELSE FLAG = 0 AND POINT OF INTERSECTION IS (XS, YS) * ******************************************************

This block of comments teUs the reade r what the code does and gives an overview o f the approach. To someone who is loo king for a reusable component, this block is e nough in fo rmatio n to help decide if this code is what is be ing sought. To someone who

376 Chapter 7 Writing the Programs

is tracing the source o f a failure, the block gives en ough detail to help decide if this compo ne nt is the like ly culprit or eve n a co-conspirato r.

A maintenance programmer reading block s like this one wm find the compon ent that needs to be ch anged mo re easily. Once that component is located, if the data names are clear a nd the inte rfaces we ll-de fined, the maintenance programmer can be sure that the change needed will n ot have any unexpected e ffec ts on other parts of the code .

Ai1to mated tools are available that can analyze the code to determine which procedu res a re called by this compo ne nt and which procedures invoke it. That is, the docume nta tion gene rate d by the tools points up to the components that may invo ke it and down to those calle d by the procedure. With info rmation such as this, making a change to tbe syste m is re lative ly straightforward. At the end of this chapter, we exam- ine an e xample of stand ards and procedures to see bo w they may direct our program- ming effo rts.

M atching Desig n w it h Implem entation

The most c ritical standard is the need for a direct corresponde nce between the pro- gram design compo nents and the progra m code compo nents. The e ntire design process is o f little value if the design 's modula rity is n ot c arried forward into the code. D esign characte ristics, such as to w coupling, high cohesion, and well-de fined interfaces, sho uld also be program characteristics, so that the algorithms, functions, interfaces, and data structures can be traced e asily from design to cod e and back again.

Reme mber tha t Lhe system's general p urpose is likely to remain the same throughout the software's life time, but its nature ma y change over time as custo mers ide ntify enhance ments and mod ificatio ns. For exa mple, suppose you are part of a te am designing compute r-aide d disp lays fo r automo biles. The system you build will proba bly always b e part of an automo bile, but the menus and input de vices may change, o r n ew features may be added. These changes are made first to the high-level d esign and then are traced through lo we r design levels to tbe code that must be mo dified. Thus, the cor- respo nde nce between d esign and code is esse ntial. In later chapte rs, we will see ilhat testing, maintenance, and configuration manage ment are impossible without the links established by these standards.

7.2 PROGRAMMIN G GUIDELINES

Prog ramming invo lves a great deal of crea tivity. R emember th at the design is a guide to the func tion or purpose of each compone nt, but the programmer has great ftexibiJity in impleme nting the design as code. The design o r re quire me nts specificatio n ma y su ggest a programming language , either directly because it is specified by the designers o r cus- to mers, o r indirectly because o f the constructs u sed. Language-specific guidelines are no t addressed here, because there are many good books on the subject. Instead, we dis- cuss several guide lines that apply to programming in general , rega rdless o f the langu age.

No matte r wha t lan guage is used, each progr am component in volves at least three majo r asp ects: control s tructures, algorithms, and data structures. We examine e ach more closely.

Openmirrors.com

Section 7.2 Programmi ng Guidelines 377

Control Structures

Many o f the contro l structures for a compone nt a re su ggested by the architecture and design, and we want to preserve them as the design is translated to code. In the ca se of some architectures, such as implicit invocation and o bject-orie nted design , control is based o n system s tates a nd changes in variables. lo other, more proceduraJ designs, con - trol de pends on tbe struc ture o f the code itself. For any type of design, it is important for your program s tructure to re flect tbe design's control structure. R eaders s hould not have to jump wildly through the code, marking sections to wbich to re turn and wondering whe ther they have foUo wed the right path. They should concentrate on what is being done by the program, no t on the control flow. Thus, many guidelines and standards s ug- gest th a t the code be written so that you can read a component easily from the top do wn.

Let us look a t an example to see how restructuring can aid understanding. Con - side r the foUowing program. Its control skips around among the program's stateme nts, making it difficult to follow.

benefit = minimum; if (age < 75) goto A; b enefit = max i mum; goto C ;

if (age < 65) g oto B ; if (age < 55) goto C ;

A : i f (age < 6 5) go t o B;

ben e fit= benefi t * 1. 5 + b o nus ; goto C ;

B : if (age < 55) goto C ;

b e n e fit= benefit * 1. 5 ; c : next sta tement

We can accomplis h the same thing in a format that is easier to foUow by rearrang- ing the code :

i f (age < 55) b e n e fit = min imum; e l seif (age < 65) ben e fi t = mi n i mum + bonus ; e l seif (age< 75) benefit= minimum* 1.5 +bonus;

e l se benefit = maxi mum;

Of course, it is not a lways possible or practical to have exactly a top-down flow. For example, reaching the end of a loop may disrupt the flo w. H oweve r, it is helpful when - e ve r possible to have the required action foll ow soon afte r the decision that genera tes it.

We saw in previous chapters tbat modularity was a good design attribute. Its same adva ntages carry thro ugh to tbe code as well. By building a program from modular blocks, we can hide implementation details at different levels, making tbe entire system easie r to understand, test, and ma intain. In other words, we can consider a program compon ent itse lf to be modular, and we can use macros, procedures, subroutines, metho ds, and inheri- tance to hide details while enhancing understandability. Moreove r, the more modul ar the code component, the more easily it can be maintained and reused in other applications; modification can be isola ted to a particular macro, subro utine, or other subcomponent.

378 Chapter 7 Writing the Programs

Thus, in writing your code, keep in mind that generality is a virtue; do n ot make your code more specialized than it needs to be. Fo r instance, a component that searches a string of 80 characters of text for a period can be written so that the input parame ters include the length of the string and the character to be found. Then, the component can be used again to sea rch a string o f any length for any characte r. At the same time, do no t make your components so general that p erformance and understanding are affected.

Othe r design char acte ristics translate to cod e compo nents, such as coupling and cohesio n. Whe n you writte your progra ms, reme mber lo use parame ter na mes and com- ments to exhibit the coupling among compone nts. For instance, suppose you are writing a component to estimate income tax. It uses the values of gross income and deductions provide d by other compone nts. Instead of comme nting your code with

Reestimate TAX

it is better to write

Reestimate TAX based on values of GROSS_INC and DEDUCTS

The second comment e xplains how the calculation is tied to data items in o ther components.

Your code must enable the reade r to discern which parameters, if any, are be ing passed to the component and back again. O the rwise, testing and mainte nance wiU be e xtre me ly difficult. Io other words, dep endence among compone nts must be visible. By the same token, just as the system components were designed lo hide info rmation from o ne another, the subcomponents of your program should bide calculati on de tails from each othe r. For example, in the earlie r string-searching program, the text-sea rching compon ent must contain info rmatio n about how the specified cha racter is sought. But the caUing components n eed not know how the character is found, only that it is found and where it is. This information hiding aUows you to change the searching algorithm without disturbing the rest of the code.

Algorithms

The program design o fte n specifies a class o f algorithms to be use d in coding the com- po ne nt you a re writing. For example, the design may teU you to u se a Quicksort, o r it may list the logical steps of the Quicksort a lgorithm. H owever, you have a great deal of fle xibility in converting the algorithm to code, su bj ect to the cons traints of the impl e- men tation language and hardware.

O ne of the a re as in whi ch you have gre at discre tio n is the perfo rm ance o r e ffi- cie ncy of your imple mentation. Your instinct may tell you to make the code run as fast as possible. However, making the code faster may involve hidde n costs:

• the cost to write the faste r code, which may be mo re complex and thus take more time to write

• tbe cost of time to test the code, whose complexity requires more test cases or test data

• the cost of time for users to understand the code • tbe costs of time to modify the code, if necessary

Openmirrors.com

Section 7.2 Programm ing Guidelines 379

Thus, e xecution time is o nly a small part of the overall cost equation. You must balance executio n time conside rations with design quality, standa rds, and customer require - ments. fa particular, do not sacrifice clarity and correctness for spe,e d.

If speed is importa nt to your implemen tatio n, you must le arn how your compiler o ptimizes your code. O therwise, the o ptimizatio n may take your seemingly faste r code and actually slow it down. To see how this pa radoxical situation can happen, suppose you are writin g code to imple me nt a three-dimensio nal array. You decide to incre ase efficiency by crea ting ins tead a o ne-dime nsional a rray and performing all the indexing computatio ns yourself. Thus, your code computes such variables as

index = 3 *i + 2*j + k ;

to calcula te the positio n of an entry in a three-dimensional array. However, your com - pile r may pe rfo rm its array indexing in the registers, so execution time is small. If the compile r uses an additive incre ment technique in the registers, rather than adding and multiplying for each positio n ca lculation, the n your o ne -dimensio nal array technique may actua lly result in increased e xecution time!

Data Structures

In writing your programs, you should format and store data so tha t data management and ma nipulation a re straightforwa rd. There are several techniques that use the struc- ture o f the d ata to suggest how the program sho uld be organized.

Keeping the Program Simple. The program's design may specify some o f the d ata structures to be used in imple menting functio ns. Often, these structures are chosen because they fit into an overa ll sche me that promotes informatio n hiding and con trol of compo nent inte rfaces. Data manipulatio n withi n a component can influence your choice of data structures in a simila r way. Fo r example, restructuring data can simplify a p rogram's calculations. To see how, suppose you are writing a program to de termine the amo unt o f federal inco me tax due. As input, you are given the amo unt of taxable income and are told the following:

L For the first $10,000 of income, the tax is 10%. 2. For the next $10,000 o f income above $10,000, the tax is 12% . 3. For the next $10,000 o f income above $20,000, the tax is 15% . 4. For the ne xt $10,000 o f income above $30,000, the tax is 18% . 5. Fo r any income above $40,000, the tax is 20% .

Thus, someone who has a taxa ble income of $35,000 pays 10% of the first $10,000 (or $1000), 12% of the next $10,000 (or $1200), 15% o f the next $10,000 (or $1500), and 18% o f the re maining $5000 (or $900), fo r a tota l of $4600. To calculate the tax, you ca n ind ude code in your component that read s in the taxable income a nd follows this a lgorithm:

tax= 0 .

i f (tax able_ income == 0) goto EXIT ;

if (tax able_ income > 10000) t ax = tax + 1000 ;

380 Chapter 7 Writing the Prog rams

ell.se{ tax = tax + .l O*taxable_ income;

goto EXIT; }

if (taxable_income > 20000) tax = tax+ 1200; ell.se{

tax= t a x + .12 * ( taxable_income- 1 0000) :

goto EXIT;

if (taxabl e_inc o me > 30000) tax = tax+ 1500; else{

tax= tax+ .15*(taxable_income-20000); goto EXIT;

if (taxable_ inc ome < 40000 ) { tax= tax+ .lS*(taxable_ income- 30000); goto EXIT;

else tax tax+ 1 800 . + . 20*(taxabl e_i ncome-40000);

EXIT: ;

H oweve r, we can define a tax table for each " bracket" of tax liability, as sho wn in Table 7 .1, whe re we use a base figure and a pe rcentage for each bracket.

Then , using the table, we can simplify our a lgorithm considerably:

for (int i-2; l evel=l; i <= 5 ; i++) if (taxable_income > bracket[i])

level = level + 1; tax= base [leve l]+percent[ l evel]*(taxabl e_income - brack et [level] );

Notice how the calculation s are si mplified just by changing the way the data are de fined. This simplificatio n makes the program e asier to understand, test, and mo dify.

Using a Data Structure to Dete nninc a Program Structure. In the tax table e xampl e, the way we de fine the data dictates how we perform the n ecessary ca lcula - Lions. In genera l, data structures can infl uence the organiza lion and flow o f a program. ln some cases, the data structures ca n inJlue nce the choice of language, too. For

TABLE 7.1 Sample Tax Table

Bracket Base Percent

0 0 to 10,000 1000 12 20,000 2200 15 30,000 3700 18 40,000 5500 20

Openmirrors.com

Sectio n 7.2 Programming Guidelines 381

e xa mple, LISP iis designed to be a list processor, a nd it contains structures that ma ke it much mo re a ttraclive than some o the r languages fo r ha ndling lists. Similarly, Ada and Eiffe l co ntain cons tructs for handling unaccepta ble states called e xceptio ns.

A data strncture is said to be recursive if it is defined by identifyin g a n initia l e le- ment and then gene rating successive elements as a functio n of those pre viously de fined. Fo r exa mple, a rooted tree is a g raph co mposed o f no des and lines so that the follo wing conditions hold:

1. Exactly one node o f the tree is designated as the roo t. 2. If the lines e manating fro m th e root a re e rased, the resu lting graph is a set o f no n-

intersecting g raphs, each o f which is a rooted tree.

Figure 7.1 illustrates a roo ted tree, and Figure 7.2 sh ows how re moving the root results in a set o f sma ller rooted trees. The root o f each sm aller tree is the no de that bad previo usly been connected to the o rigina l root of the la rger tree. Thus, the rooted tree is defined in terms of its root and subtrees: a recursive definiition.

Root

Root

•

Root

• 0. , ' , '

i01 Root

• JV

Root

+

J.

FIGURE 7 .1 A rooted tree.

FIGURE 7.2 Su btrees of a rooted tree .

382 Chapter 7 Writing the Prog rams

Programming languages such as Pascal aUow recursive procedures to deal with recursive da ta structures. Yo u may prefer to use recursive procedures for this type of data, since their use forces the burde n of managing the data structure to be borne by the compile r rathe r than your program. llle use of recursion may make the actual pro- gramming easie r o r may make your program mo re understandabl e. Thus, in gene ral, you sho uld conside r the data structures carefully when deciding which language to use in imple menting the des ign.

General Guidelines

Several overall strategies are useful in preserving the design quaLity in your code.

Lo calizing In put a nd Output. Those parts of a program that read input or gen- era te output are highly specia lized and must retlect characteristics of the underlying hardware and so ftware. Because of this dependen ce, the program sectio ns performing input and o utput functio ns are sometimes difficult to test. In fact, they may be the sec- tions most likely to change if the hardware o r software is modified. Therefore, it is desirable to localize these sectio ns in components separate from the rest of the code.

Ao added benefit of locaLization is gen e raLizatioo of the overall system. O ther systemwide functions to be performed on the input (such as reformatting or type checking) can be included i.n the specia lized component, relieving the other compo- ne nts of the burde n and thus e Liminating repe titio n. Similarly, putting output functions in o ne place ma kes the system easier to understand and change.

Incl uding Pseudocode. The design usuall y lays out a framewo rk for each p ro- gram compo nent. Then, you add your creativity and exp ertise to build the lines of code that imple me nt the design. For example, the design may be relatively language- independe nt, giving you many choices about the particular language constructs to use, ho w to u se the m, ho w the data will be represented , and so on. Since the design is an out- line o f wha t is to be do ne in a program compone nt, it is useful to move i.n stages fro m the specified design to the code, rather than to translate the design immediate ly into cod e.

Pse udocode can be used to adapt the design to your ch osen language. By adopt- ing constructs and data re presentation s witho ut becoming invo lved immediately in the specifics of each command, you ca n e xperime nt and decide whic h implementation is most desirable. In this way, code can be rearranged and restructure d with a minimum of rewriting. Fo r instance, suppose the design for a compo nent of a text processing system states

COMPONENT PARSE_LINE:

Read next e ighty character s .

IF this is a con t inuati o n of the prev i o u s line,

Cal 1 CONTINUE ELSE determine command type .

END IF CASE of COMMAND_ TYPE

COMMAND_TYPE is paragraph: Call PARAGRAPH.

COMMAND_TYPE is indent : Call INDENT .

COMMAND_TYPE i s s kip line : Call SKIP_LINE.

Openmirrors.com

Section 7.2 Programming Guidelines 383

COMMJ..ND_TYPE is margin : Call MARGIN .

COMMJl.ND_TYPE is new page : Call PAGE.

COMMAND_ TYPE is double space: Call DOUBLE_ SPACE.

COMMAND_ TYPE is single space: Call SINGLE_ SPACE .

COMMAND_TYPE is break : Call BREAK. COMMAND_TYPE is anything else: Call ERROR.

ENDCASE

Depending o n the chosen language and your pre fe rence as a programme r, this design can be imple mented in many ways. As the first stage in translating design to code, you might examine each type of command to de termine what is involved in cod- ing it. Using inte rmediate pseudocode, you might describe wha t you wan t your code to do in the following way:

PARAGRAPH:

Break line , flush line buffer . Advance one line between paragraphs. If fewer than 2 lines left on page, eject . Set

line pointer to paragraph i ndent .

INDENT: Break line, flush line buffer. Get indent parameter. Set

line pointer to indent parameter, set left margin to indent .

SKIP_LINE:

Break line, flush line buffer. Get line parameter. Advance

(parameter) lines or eject if not enough space left on

current page . MARGIN:

Break line, flush line buffer . Get margin parameter. Set

line pointer to left margin. Set right margin to margin. PAGE:

Break l i ne, flush line buffer . Eject page . Set line

poi nter to left margin .

DOUBLE_ S PACE :

Set interline space to 2.

SINGLE_S PACE : Set interline space to 1.

BREAK:

Break line, flush line buffer. Set line pointer to left

margi n.

However, by reviewing this psell!docode, you might see that the steps can be regrouped so that certain commo n functions follow one another:

FIRST: PARAGRAPH, INDENT, SKIP_LINE, MARGIN, BREAK, PAGE:

Break line, flush line buffer. DOUBLE_SPACE, SINGLE_ SPACE :

No break line, no flush line buffer.

SECOND :

INDENT, SKIP_LINE, MARGIN:

384 Chapter 7 Writing the Prog rams

Get parameter.

PARAGRAPH, BREAK, PAGE , DOUBLE_SPACE , S I NGLE_SPACE:

No parameter n eeded .

THIRD :

PARAGRAPH, INDENT, SKIP_LINE, MARGIN, BREAK, PAGE : Set new line pointer .

DOUBLE_SPACE, S I NGLE_SPACE:

New line pointer unchanged. FOURTH :

I ndi v i d u al actions tak en .

H a ving described the commands in this way, you may recognize that tbe F IRST and THIRD se t o f actions apply to the same group o f comma nds. l o addition , you notice that the line po inter depends on the left margin in a ll cases except when the comman d is PARAGRAPH. Using this info rma tion, you can write pse udocode in more detail:

INITIAL : Get parameter for indent, skip_l ine, margin .

Set l eft marg i n to p arame t e r f o r indent.

Set temporary l ine p o i nter to l eft margi n for a ll but

paragraph; for paragraph, set i t to paragraph

indent .

LINE_BREAKS :

If not (DOUELE_SPACE or S INGLE_SPACE), break l ine, flush

line buffer and set line pointer to temporary line

poi nter .

If 0 lines l eft o n page , e j ect page and pri nt page header . I NDI VIDUAL CASE S :

INDENT, BREAK : do nothing .

SKIP_LINE : skip parameter lines or eject. PARAGRAPH : advance 1 l ine ; if < 2 lines on page, eject.

MARGIN: right_margin = parameter .

DOUBLE_SPACE: interline_space = 2. S I NGLE_SPACE : i n terline_space = 1.

PAGE: eject page, p r int p a g e header .

Finally, you are ready to write code to implement the design:

//initi al : get parameters if ((command_type==INDENT) I I (command_type==LI NE_SKI P)

I I (command_ type==MARGIN ) ) parm_ value =get_parm ( i nput_line);

if (command_type = INDENT) lef t _ margin:=parm_ value;

if (command_type==PARAGRAPH) temp_l i n e_pointer=paragraph_indent; else temp_line_pointer=LEFT_MARGIN;

Openmirrors.com

Section 7.2 Programming Guidelines 385

//break current line, begin new line

if (not( (command_type==DBL_SPC) I I (command_type==SNGL_SPC))){ break_ and_flush_ line( ) ;

if (lines_left==O)

begin_new_page(); line_ pointer=temp_line_pointer

//actions for individual commands

switch(command_type){ case LINE_SKIP:

if ( lines_ left > parm_value)

for (i=l; i<parrn_value; i++) advance_line () ;

else begin_new_page();

case PARAGRAPH: advance_line();

if (lines_left < 2)

begin_new_page( ) case MARGIN: right_rnargin=parm_value;

case DBL_SPC: interline_space=2;

case SNGL_SPC: interline_space=l;

case PAGE: begin_new_page } //end switch

Thus, pse udocode has acte d as a frame work on whicb to construct the code. In brie f- ing tbe code from the design in this way, notice that the design's org a111izatio n has cha nged several times. Such changes must be reported to and approved by the design- e rs, so that tbe links among requirements, design , and code can be documented and maintained.

R evising a nd Rewriting, Not P atching. When writing code, as when preparing a te rm paper o r c reating a work of art, you ofte n wri te a rough draft. Then you carefully revise and rewrite until you a re satisfied with the result. If you find tbe control flow con- voluted, or the decision processes h ard to understand, or the unconditional branches difficult to e liminate, then it may be time to return to the design. Reexamine the design to see whether the problems you are e ncounte ring are inherent in the design o r in your translatio n to code. Look again at how the data are represented and structured, at the a lgorithms chosen, and at the decompositi on.

Reuse. There a re two ki.nds of reuse: producer reuse, where we are creating components designed to be reused in subsequent applications, and consumer reuse, where we are using components that were originally develope d for other projects (Barnes and Bo llinger 1991). Some companies have division-wide o r company-wide reuse programs., with standards fo r evaluating and changing components; Sidebar 7.2 describes such a program at Lucent. The success of these programs suggests reuse

386 Chapter 7 Writing the Programs

SllDEBAR 7.2 SELECTING COMPONENTS FOR REUSE AT LUCENT

Lucent Technologies initiated a companywide program to reuse software components (McOure 1997). As a conseque nce, the Workstation Software D evelopment D epartment formed a Re use Council to devise a strategy for selecting candidate components for its reuse repository. The Council consisted of seven people, representing all groups in the department. The Council created an inventory of components and formed a matrix with the features of all past and planned projects. Then, each feature was rated in terms of whether it had been implemented and was still needed. had been implemented but was no longer needed, or had not been implemented but was still needed. Those features that were needed and were com- mon to more than one project were targeted for reuse. In fact, some were redesigned to make them more reusable.

The Council met every week for two hours to make component selections, inspect design documentation for those components already in the repository, and to monitor the

levels of reuse in the department's projects.

guide lines for you. If you are a consumer for your curre nt project, there are four key characte ristics to check about the components yo u are about to reuse:

1. Does the compone nt perform the functio n or provide the data you need? 2. If mino r modificatj on is required , is it Jess modification than buiJdin g the compo-

ne nt from scratch? 3. Is the component well-documented , so you can understa nd it without having to

ve rify its impleme ntation line by line? 4. Is there a comple te record of the compone nt's test and revision history, so you can

be certain tha t it contains no fa ults?

You must also assess the amount of code yo u need to write so that your syste m can interface with the re used compo ne nts.

On the othe r hand, if you are a produce r of reusable components, you sh o uld keep in mind several things:

• M ake your component gene ral, using parameters and anticipating similar condi- tio ns to the o nes in which your system will invoke your components.

• Se para te de penden cies so that sections like ly to need cha nge are isolate d from those that are like ly to re main the sa me.

• Kee p the compone nt inte rface general and well-defined. • Include informatio n about any faults found and fixed. • U se clear naming conve ntions. • Document the data structures and algorithms. • Keep the communication and e rror-handJing sections separate and easy to modify

Openmirrors.com

Section 7.3 Documentation 387

7.3 DOCUME.NTATION

Man y corporate or organiza tional standards and procedures focus on the descriptions accompanying a coUectio n o f programs. We consider program documentation to be the set of written descriptions that explain to a reader what the programs do and how they do it. Inte rnal docume ntatio n is descriptive material writte n directly within the code; aJl other docume ntation is exte rnal documentatio n.

Internal Documentation

The interna l docume ntation contains informatio n directed at someone who wm be reading the source code of your programs. Thus, summary info rmation is provided to identify the program and describe its data structUies, aJgoritbms, and control tlow. Usu- ally, this information is placed a t the beginning of each compone nt in a set of comments ca lled the heade r comme nt block.

Heade r Comment Block. Just as a good n ewspape r reporte r includes the who, what, where, when, how, and why of a story, you must include the foUowing information in yom h eader comment block for each compo nent:

1. what your compo ne nt is caUed 2. who wrote the compone nt

3. whe re the component fits in the ge neral system design 4. when the compone nt was written and revised 5. why the component exists 6. how the compo ne nt uses its data structures, algorithms, and control

We can examine each of these pieces o f informati on in mo re depth. First, the name of the component must figure prominently in the documentation.

Next, the block ide ntifies the writer, with pho ne nUIDber or e-mail address, so that the maintenance and test teams can reach the writer with questions or· comments.

Dming the system 's Lifetime, components a re often updated and revised , either for fault correctio n o r because requirements change and grow. As we wiU see in C hapte r 11, it is impo rt ant to track the revisio ns, so program docume ntation should keep a log of changes made and who made them.

Because the compo nent is part of a larger system, the block should indicate how it fits in the component hierarchy. lllis information is some times conveyed with a dia- gram; at othe r times, a simple description will do. The header block sh ouJd also explain bow the compone nt is invoked.

M ore detailed information is required to explain how the component accom- plishes its goal. The block sh ould list

• the name, type, a nd purpose of each major d ata structure and variable • brie f descriptions of the logic ft ow, algorithms, and e rror h andling • expected input and possible output • aids to testing and how to use them • expected extensions o r revisions

388 Chapter 7 Writing the Programs

Your organizational standards usuaUy specify the order and content of the header comme nt block. He re is bow a typical header comment block might look:

PROGRAM SCAN: Program to scan a line of text for a given character

PROGRAMMER: Beatrice Clarman (718) 345-6789/[email protected]

CALLING SEQUENCE: CALL SCAN(LENGTH,CHAR,NTEXT)

where LENGTH is the length of the line to be scanned;

CHAR is the character sought. Line of text is passed

as array NTEXT. VERSION 1: written 3 November 2000 by B. Clarman

REVISION 1.1: 5 December 2001 by B. Clarman to improve searching

algorithm. PURPOSE: Genera l-purpose scanning module to be used for each

new line of text, no matter the length. One of several text

utilities designed to add a character to a line of text, read a character, change a character, or delete a character .

DATA STRUCTURES: variable LENGTH - integer

variable CHAR - character Array NTEXT - character array of length LENGTH

ALGORITHM: Reads array NTEXT one character at a time; if

CHAR is found, position in NTEXT returned in variable LENGTH; else variable LENGTH set to 0.

O ther Program Comments. The he ade r comme nt block acts as an introduction to your program, much as the introduction to a book explains its purpose. Additional comments enlighten readers as they move through your program, helping them under- stand how the intentions you describe in the header are implemented in the code. If the code's organization re flects a weU-structured design, if the statements are formatted clearly, and if the la bels, variable names, and data names are descriptive and easy to dis- tinguish, then the necessary number of additional comments is smaU. That is, following simple guidelines for code format and structure allows the code to be a source of infor- mation about itself.

Comments have a place eve n in clearly structured and well-written code.Although code clarity and structure minimize the need for other comments, additional comments are usefuJ wherever he lpfuJ information can be added to a component. Besides provid- ing a line-by-line explanation of wbat the program is doing, tbe comments can also break the code into phases that represe nt majo r activities. Then, each activity can be divided into yet smaller steps, each onJy several lines in length. Pseudocode from your program design can serve this purpose and be e mbedded in the code itself. Also, when code is revised, programmers sh ould update the comments to reflect the changes. In this way, the comments build a record of revisions over time.

It is essential that the comments re flect the actual code behavior. In addition, make sure that the comments add new information, rather than state what is already obvious from your use of good labels and variable names. For example, it is useless to write

Openmirrors.com

II Inc r e me n t i 3 i 3 = i 3 + l;

Section 7.3

wbe n you can add substantially m ore information by writing

I I Set counter to read next case i 3 = i3 + 1;

Ideally, tbe variable names should explain tbe activity:

case_counter = c a se_c o unte r + 1;

Documentation 389

Usually, you begin coding by moving from the design to pseudocode, wbich in turn provides a framework for your final code and a basis for your comme nts. Be sure to write the comme nts as you write the code, not afterw ard, so you capture botb the design and your inte ntion. Beware o f code that is difficw t to comment; the di fficul ty o fte n suggests th at the design sbould be simplifie d before you finish coding .

Meaningful Variable Nam es a nd Statement Labels. Choose n ames fo r your va ria bles and sta teme nts that reftect their use o r meaning. Writing

weekwa ge = (hrra te *hours) + ( .5 ) * (hrrate) * ( hours - 4 0 . ) ;

makes mo re sense to the re ade r than

z = (a * b) + ( . 5) * (a) * (b - 40.);

In fact, the weekwage example is not likely to need comments at all, a nd you a re less like ly to introduce fa ults.

Simila rly, alpha be tic stateme nt labels should te ll re ade rs something abo ut what the labeled sectio ns o f your program do. If the labels must be numeric, then be sure they are in ascending order and cluste red by related purpose.

Formattin g to E nhan ce U nderstandin g. 1be fo rmat of your comments can help a reade r unde rstand the goal of the code and how the goal is reach ed. Indentation and spacing o f state me nts can reftect the basic control structure. Notice how uninde nted code like this

i f (x coord < y coord)

r es u lt = -1; e l seif (x coord == ycoord ) i f (s l ope l > s l ope2)

res u l t = O; e l se result = l; elseif (slopel > slope2 )

res u lt = 2; elsei f (s l o pel < s l op e2)

res u lt 3 ;

res u l t = 4;

390 Chapter 7 Writing the Programs

can be clarified by using inde ntation and rearranging the space:

if ( x coord < ycoord) result = - 1; elseif (xcoord == y coord)

i f (slopel > slope2) result= 0·

else result = 1; elseif (slopel > slope2) result 2; elseif (slopel < slope2) result = 3; else result = 4;

In addition to using fo rmat to display the control structure, Weinberg (1971) rec- o mmends fo rmatting your state ments so that the comments appear on o ne side of the page and the stateme nts on the o ther. In this way, you can cover up the comments when testing your program and thus not be misled by what may be incorrect documentation. For example, the following code (from Lee and Tep fe nhart 1997) can be read without comme nts by looking only at the left side of the page.

void free_store_empty()

static int i = O; if (i ++ == 0)

cerr << "OUt of memory\n~; abort();

//guard against cerr

//allocating memory

I / tell user //give up

Docume nting Data. O ne of the most difficult things fo r program reade rs to understand is the way in which data are structure d and used. A data map is very useful in interpre ting the code 's actions, especially when a system handles many files of vary- ing types a nd purposes, coupled with flags and passed parameters. lhis map sh ould cor- respond with the data di ctio nary in the external documentation , so the reader can track data ma nipula tio n thro ugh the require me nts and design to the code.

Object-oriented designs minimize or eliminate some of these problems, but some- times this info rmatio n hjding ma kes it e ven mo re difficult fo r the reader to understand e xactly how a data value is changed. Thus, the internal documentation should include descriptions of the data structures and uses.

External Documentation

Whe reas inte rn al documentatio n is concise and written at a leve l appropriate for a pro- gramme r, exte rn al documentatio n is inte nded to be read also by those wh o may ne ver loo k a t the actual code. For example, designe rs may revie w the exte rn al documentation when conside ring modifications o r enhancements. In addition, the external documenta - tion gives you a cha nce to explain things more broadly than might be reasonable within your program's comme nts. If you consider the heade r comme nt block to be an overview o r summa ry of your program, then the exte rnal documentation is the full - blown report. It answers the same questions-who, what, why, whe n, where, and how- using a system rather than a compone nt pe rspective.

Openmirrors.com

Section 7.4 The Programming Process 391

Because a software system is built from interrelated components, the external docume ntatio n ofte n includes an ove rview of the syste m's components or of several groupings o f compo ne nts (the user-inte rface compone nts, the database e.g., manage - ment compo nents, the ground-speed-calculatio n compo nents). Diagrams, accompanied by narrative describing each compo nent, show bow data are shar ed and used by one o r mo re compo ne nts; in gene ral , the overview d escribes bow information is passed from o ne compone nt to another. Object classes and their inheritance hierarchy are explaine d here, as are reasons fo r defining special types or categories of data.

E xternal compo ne nt documentation is part of the overaU syste m documentation. At the time the compo ne nt is written, much of the ratio nale fo r the component's struc- ture and ftow have a lready bee n de taile d in the design docume nts. In a sense, the design is the ske le ton o f the externa l docume ntation, and the ftesh is supplied by narrative dis- cussing the code compone nt's particulars.

Describing the P ro ble m. In the first secti on of the code's documentatio n, you sho uld explain what problem is being addressed by the compone nt. This sectio n sets the stage fo r descri bing w bat o ptions we re considered fo r solution s and why a pa rticu - lar solllllio n was chosen. The problem description is no t a repeat o f the requireme nts docume ntatio n; rather, it is a general discussio n of the setting, e xplaining whe n tbe compo nent is invoke d and why it is needed.

D escribing the Algorithms. Once you make clear why the component exists, you sho uld address the cho ice o f al gorithms. You sho uld explain each a lgorithm u sed by the compone nt, including fo rmul as, boundary or special conditions, and even its d er - ivatio n or re ference to the book or paper from which it is derive d.

If an algorithm de als with specia l cases, be sure to discuss each one and explain bow it is handled. If certain cases are no t handled because they are not expected to be enco untered , explain your rationale and describe any related error handling in the code . Fo r example, an algorithm may include a fo rmula where o ne va riable is divided by a nothe r. The docume nta tio n should address cases where the de nominator migh t be zero, pointing o ut whe n tbis situation might occur and how it is ha ndled by the code .

Describing the D a ta. In the exte rnal documentation , the users or programmers should be able to view the data flow a t the compon ent level. Data flow diagrams should be accompanied by rele vant data dictionary references. For o bject-orie nted compo- nents, the ove rview of objects and classes should explain the ge neral interaction of o bjects.

7.4 THE PROGRAMMING PROCESS

This chapter discusses guide lines, standards, and d ocumentation. What kind of process do prog rammers follow to e nsure that the code they produce is of high quality? U ntil rece ntly, the programming process was not the focus o f much rese arch. A s Whittake r and A tkin (2002) po int o ut, softwa re engineering r esearche rs often assume that, given a good design, a ny programme r can translate the design into solid code. But good code is the result no t only of a good design but also of skill, experien ce, and artfulness de rived

392 Chapter 7 Writing the Programs

from imaginatio n and good problem solving. To understand wha t processes support good programming prac tices, we begin by examining how to solve problems.

Programming as Problem Solv ing

Po l ya (1957) wrote the c lassic book o n how we solve pro blems. He points out that find - ing a good solution involves fo ur distinct stages:

1. U nde rstanding the pro ble m 2. D evising a plan 3. Carrying out the plan 4. Loo king back

To unde rstand the pro ble m, we analyze each o f its ele ments. Wha t is known? Wha t is no t kno wn? What is possible to know? What is impossible to kno w? These questions address bo th data and re latio nships. Just as a good systems analyst frames a problem in te rms of the syste m bo undary, ide ntifying what is. inside the boundary and what is out- side, a good proble m solver must understand the conditions unde r which the problem must be solved. The n, once we can de fine the conditions, we ask if the conditions can be sa tisfied.

So me times it is he lpful to draw a picture to e nhance unde rstanding. Programmers o ften do this by drawing a flow chart or diagram to show how a d ynamically alJocated da ta structure changes sh ape as vario us operation s are p erformed on it. Such depiction he lps us to identify va rio us parts o f the condition , and perhaps eve n to decompose the problem into sm(IUer, more trnct'1ble problems. In (I way, tbis refrnming to gain under- standin g is a micro-design activity: the program design is viewed ca refull y and reorg an - ized in pieces that a re easier to address than the o riginaJ framing of the design.

Nex t, a plan is devised to de te rmine how a solution can be d erive d from what is kno wn about the problem. What are the connectio ns between the data and the unkno wns? If no connectio n is immediately clear, the n are the re ways in which this proble m is similar to other, be tter-known proble ms? It is here that we try to thin!k of the current problem in terms of patterns: ls there a p attern or set of pa tterns that we can adapt to fit our problem?

We ca n try seve ra l techniques to find the rig ht pl an of attack:

• lden1ifying a related problem: Are the re d ata, algorithms, libraries, or me th ods tha t we can use to attack our proble m?

• Restating the problem: What are the key definitio ns? Cao the proble m be gen eral- ized or made mo re specific to make it mo re tracta ble? Can simplify ing assump- tio ns be made?

• Decomposing the p roblem: What are the essenti al e lements of the problem ? Can the da ta be partitioned into categories, so that each category can be processed se pa rate ly?

Pe rkins (2001) su ggests ways to brainstorm and arrive at what he calls the " Eureka" e ffect: recognizing the best solution. H e wants us to rove through many dif- ferent p ossibilities, stre tching our minds to think even of implausible scenarios. We can also look for subtl e clues that signal anomalies-reasons that a p ossible solution will

Openmirrors.com

Section 7.4 The Programming Process 393

no t work. Io addition to reframing the proble m, Pe rkins suggests " decentering" from curre nt fixations by exa mining every assumption and attitude. He teUs us to think of creativity as a sophisticated form of questioning everything; we use our creativity to question proposed solutions and to find a better solution to our problem.

Once the plan of attack is chose n, Polya tells us to carry it out. Step by step, we must verify that the solution- in our case our program- is correct. If necessary, we can use some of the techniques presented in C hapters 8 and 9 to evaluate each step, making sure that each logica l statement fo ll ows from previous steps. Whe n the solution is done, we look back and e xamine it, revisiting e ach part of the argume nt. At the same time, we evaluate the solution for its applicability to other situations. Is the solution reusable? Cao it be used to solve a different proble m? Should it become the basis for a pattern?

Any programming process that e ncourages these steps can enhance the speed at which we find a good solution. Libraries of programs, good documentation, and auto- mated tools suppo rt a good process. As we will see in later chapters, reuse reposito ries, change management, and post-mortems also improve the process, particularly by ana- lyzing our successes and failures and by encoding in our products and processes the rec- ommendations from our analyses, so that programming is easier the next time around.

Ext reme Programming

I n Chapter 2, we learned about agile me thods and the related philosophy of program- ming, caUed extreme programming. In extreme programming, there are two types of participants: customers and programmers. Customers represent the users of the even - tual system. In this role, they perform the foUowing activities:

• D e fine the fe atures that the programmers wiU impl eme nt, usin g sto ri es to describe the way the system wiU work

• D escribe de tailed tests that they will run when the softwa re is ready, to verify that the stories were implemented properly

• Assign priorities to the sto ries and their tests

In turn, the programmers write code to implement the stories, doing so in the order specified by the customers' priorities. To assist the custo me rs, the programmers must es timate how lo ng it will take to code up each story, so that the custome rs ca n plan the acceptance tests. The planning occurs in two-week increme nts, so that trust builds up between custome rs and programmers. Martin (2000) points out that extreme pro- gramming invo lves more than just this dialog between progra mme rs and customers; there are also dialogs between programmers as they pair program: sitting side by side at a workstation and collaborating on the construction of a single program.

Pair Programming

The concept of pair programming is one of the more radical of th e agile method tech - njques, so we examine it in more depth in this ch apter. In pair programming, a pair of programmers uses a single keyboard, display, and mouse. Each membe r of the pair assumes a very specific role. One person is the driver or pilot, controlling the computer and actually writing the code. The other person is the navigator, re viewing the drive r's code and providing feedback. The two tea m me mbers exchange ro les p eriodically.

394 Chapter 7 Writing the Programs

There are many claims made for pair programming, including improvements in productivity and quality. H owever, the evide nce is thin and often ambiguous. For example, Parrish e t al. (2004) report on the productivity impact of using pairs of devel- opers. On average, the programmers in the s tudy had 10 years of work expe rience. The study measured programmer colla boration as th e degree to whicb pairs of program- mers worked on the same module on the same day. Parrish and his colleagues found that " the high-concurrency pairs were significanUy less productive despite the fact that they were experi enced, me thodology-trained programmers." Mo reover, the study found, pairs were no mo re productive on later modules than on earlie r modul es. H ow- eve r, re po rts from the Software Engineering I nstitute (in evaluating the Personal Soft- ware Process) suggest tlhat programmers using traditional methods get better as they do mor e programming, in te rms of both productivity and quality. Concluding that p airs working together are n ot naturally productive, Parrish and bis colleagues suggest that there are ways to use the role-based protocol of pair programming to he lp overco me the natural productivity loss that happens in pairs.

Othe r studies, such as Cockburn and Williams (2000), Nose k (1998), and Willi ams e t al. (2000), suggest tbat pair programming produces code faster and with lower fault density than traditional individual programming. Howeve r, Padbe.rg and MillJer (2003) found that tbe cost-benefit ratio for pair programming d epends o n ho w large these advantages really are. [n particular, they show t hat pair programming pays off o nly under s trong market pressure, where managers encou rage programme rs to imple m ent the next set of features 'quickly for tbe next release. D robka, Noftz, and Ragbu (2004) show mixed results: in o ne study, an extreme programming team was 51 % more pro- ductive than the team using traditional approaches, but in anothe r 'Study, a non-extre me programming te am was tbe more productive, by 64%. Many of these studies invo lve small, unrealistic projects; othe rs may suffer from the so-called H awthorne effect, in which be havior improves not because of better processes but becau se attention is be ing paid to the participants.. We will see in Chapter 14 how to make decisions from these disparate and often conflicting pieces of evide nce.

The othe r benefits of pair programming seem clear. Having an older, experie nced programmer advise a novice while writing code can be a powerful learning experien ce. And having a second pair of eyes reviewing code as it is being developed can help to catch erro rs e arly. H owever, Skowronski (2004) points out that pair programming can inhibit esse ntial steps in problem solving. H e claims that the focus o n the problem can be disturbed by the necessary interactio ns between pairs. "Agile m ethods could push people who excel at problem solving into tfue background, giving center stage to programming-te am me mbers who can talk well but might lack the analytical skills nec- essa ry to do the difficult design and coding tasks" (Skowronski 2004). Moreover, as Polya (1957) and Perkins (2001) point out, good problem solvers need time alo ne, to think care ful ly, devise the ir plans, a nd ana lyze the ir optio ns. This quiet time is not built into the pair-programming process.

Whit her Programming?

A s with almost anything, the answer may be " aU things in moderation." Drobka, No ftz, and Ra ghu (2004) describe their use of extrem e programming o n four mission -critical

Openmirrors.com

Section 7.5 Information Systems Example 395

projects. They found that ext ra steps we re neede d to adjust extre me programming to the rea lities of large-scaJe, mission-critical software. For exa mple, with no architectural guidelines, each programmer had bis o r her own vision of what the overall architecture should b e, and the visions differed considerably. Thus, the high -level architecture docu- ment was used as a roadmap to assist the deve lope rs in planning. R ather than use prior- itized stories, the researchers found it essential to define baseLine architectures, using docume nted scenarios to he lp describe key abstractions, and to define system bound- aries. Finally, documentation was used to assist in communicating among team mem- be rs. Strict agile -methods advocates eschew documentation, but Drobke, Noftz, and Raghu found it to be essential. So, too, were design reviews to ensure that the software be ing built would be maintainable over its likely 30-year life span.

Thus, in the future, programming is likely to be a blend of the good practices that have been advocated fo r decades and the flexible approaches being espoused by the agile-me thods propo ne nts. We will see in Chapte r 14 that software e ngineers are de fin - ing a software e ngineerin g body of knowledge that describes the information and prac- tices that a good software e nginee r should mas ter in order to produce high-quality systems.

7.5 INFORMATION SYSTEMS EXAMPLE

Recall that in C hapte r 6 we looked at designing the modules of the Piccadilly system. One aspect of the design involved finding television programs on competing channels, so that we could use informatio n about them in o ur advertising campaign. This resulte d in the design of a module that re presents te levision Programs. According to our data model, the Program class will have attributes program name, transmission date, transmis- sion start time, transmission end time, audience type, and predicted rating. We want to write a C++ function that finds all opposition programs that are broadcast at the same time as some given Episode o f a Piccadilly program. One of the decisions we must make is bow to pass in fo rmation about an Episode to the function. There are several argume nt- passing mechanisms from which we can choose: passing a value, a pointer, or a reference.

If information about an Episode is passed by value, the actual value of Episode is not ch a nged. Instead, a copy is made and place d on a loca l stack. O nce the me thod te rmina tes, the local values are no longer accessible to the method. One advantage of using this approach is that the caUing compone nt does not need to sa ve and resto re argument values. H owever, passing a value can use up a great deal of time and space if the argument is large.Moreover, this technique is not useful if the method must ch ange the actual value of the argument. If we impleme nt the me th od passing by value, it may look like this in C++:

void Match:: calv ( Episode ep i sode_start_time) (

first_advert = episode_start_time + increment; II The system makes a copy of Episode /I and your program can use the values directly.

396 Chapter 7 Writing the Programs

Another alternative is to pass the argument as a pointer. No copy is made of the argument; instead, the me thod receives a pointe r to an instance of Episode. If passed by poiruter, the argument can be changed and the changed value persists after the rou- tine terminates. The refe ren ce code might look Like this:

void Match:: calp(Episode* episode) {

episode- >setStart {episode- >getStart() );

I I This example passes a pointer to an instance o ·f Episode. II Then the routine can invo ke the services (such as setStart II and getStart) of Episode u s ing the-> operator . }

Fiinall y, the argume nt can be passed as a re ference. Pass by reference is like pass by po inter (e.g., the value of the argument can be changed), but the argument and its serv- ices a re accessed as if it had been passed by va lue. The code might look like this:

void Match:: calr ( Epi sode& episode)

episode.setstart (episode.getstart()};

II Thi s example passes the address of Episode . II Then the routine can invo ke the servi ces (su ch as setStart II and getst art) of Episode u sing the . operator . }

O nce you decide on your pre fe rred way to handl e the argument passing, you should docume nt yo ur c hoice both in the inline comments and in the exte rnal docu- me ntation. In that way, ano the r programmer who might be reusing or updating your code will unde rstand your lo w-level design decisions and keep the new code consistent with the old.

7.6 REAL-TIME EXAMPLE

We have see n that a major proble m with the Ariane-5 software was its need to handle fa ults and failures appropriately. Such situations m ay influence the ch oice of imple men - tation language. Coleman e t al. (1994) discuss several object-orie nted languages and their abili ty to dea l with failures.

In C hapter 6, we learned that one popular way of handling a fault is to raise an exceptio n. An en-eptio n is a condition that, whe n detected, causes control of the system to be passed to a special part of the code called an exceptio n handler. In turn, the exception handler invokes code designed to fix the underlying fault or at least move the system to a state tha t is more acceptable than the exception sta te . D esign by contract often includes specific exception-handling behavi or in the contract.

The Eiffe l language (Meyer 1992b) contains expLicit exception-handling mecha- nisms. We lea rned in Section 6.6 that if an exceptio n occurs when a meth od is executing, then special code, called rescue code, can be invo ked to address the problem. We must

Openmirrors.com

Section 7.7 What This Chapter Means for You 397

make d esign decisio ns abou t ho w the rescue will work. Sometimes the rescue fixes the problem and tries to re-e xecute the method. In other cases, the rescue code finishes its wo rk and then passes control to another exceptio n bandier; if the p roblem canno t be repaired , then the syste m reve rts to a state in which it can terminate gracefull y and safe ly. In a design by contract, the contract includes precondition s, an assertion, and p ostconditions. To handle exce ptions, the Eiffel lan gu age also contains other postcondi - tio ns that explain what the syste m state should be if the assertion is found to be false. Thus, had it been imple me nted in Eiffe l, the Arian e-5 code could h ave contained post- conditio ns that sto pped the SRI subsystem before it caused the rocket to veer off course.

On the o ther ha nd, C++ compile rs do no t have standa rd exception handlers. Colema n et al. (1994) po int out that Eiffe l-style exception code can be implemente d as

t r y {

c atch ( ... )

II attempt to patch up s t a t e II e i ther s a t i s f y p os t conditi o n o r r a i s e e x cepti on aga i n }

Whatever language and exceptio n-handling strategy are chosen, it is important to have a systemwide policy, rathe r than having different a pproaches in each compo nent. Consiste ncy o f approach makes it easier to troubleshoot and trace a failure to its root cause. Fo r the same reason, it is helpful to save as much state info rmation as possible, so that the conditio ns leading to failure can be reconstructed.

7. 7 WHAT THIS CHAPTER MEANS FOR YOU

In this chapter, we have loo ke d at several guide lines for imple me nting programs. We ha ve see n that you sho uJd consider the fo Liowing when you write your code:

• o rganizational standards and guide lines

• re using code fro m o ther projects • writing your code to make it re usable on future projects • using the low-leve l design as a n initial framework, and moving in several ite ra-

tio ns from design to code • inco rpo rating a systemwide error-handling s trategy • using documentation within your programs and in external documents to e xplain

yo ur code's organizatio n, data, control, and function, as well as your design decisjons • prese rving the quality design attributes in your code

• using design aspec ts to suggest an imple me ntation language

The re are many good books that provide specialized advice based on the particu - lar impleme ntation la nguage you select.

398 Chapter 7 Writing the Programs

7.8 WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM

Although much of coding is a n individual endeavor, a u of coding must be done with your team in mind. Your use of information hiding allows you to reveal only the essen - tial info rmatio n about your components so that your colleagues can invoke them or re use the m. Yo ur use of standards e nhan ces communication among team members. And your use of commo n design techniques and strategies makes your code easier to test, maintain, a nd reuse.

7.9 WHAT THIS CHAPTER MEANS FOR RESEARCHERS

-There is a great deal of research needed on many aspects of programming.

• We need more info rma tion on the attributes of good programme rs. Productivity can vary by a factor of 10, and quaLity is also highly variable. U nderstanding m ore about which characteristics lead to good code developed quickly wiU help us train developers to be more effective and efficie nt.

• It is difficult to ide ntify compone nts that have the best reuse potential. Measure- ment and evaluatio n are needed to he lp us unde rstand which component attrib- u ttes a re the best predictors of reusability.

• \Ve continue to need more research on language characte ristics and their effect on product quality. For example, Hatton (1995) explains that some of the no nstandard aspects of C should be avoided in order to make software safer and more reliabl e.

• Automated tools a re a lways he lpfu l in ge ne rating code auto matica Uy, managing cod e re posito ries, en forcing design contracts, and providin g templates for stan- dard code structures. Researchers continue n ot only to build n ew tools, but also to evaluate existing tools for use in practical situations on large projects.

7.10 TERM PROJECT

ln preceding chapte rs, you examined requireme nts fo r the Loa n Arrange r, and devised se vera l designs to implem ent your solution to the described problem. Now it is time to imple ment the syste m. The re are several areas that deserve p articular attention , because they are more difficult than their require ments description makes them seem. O ne is the need to allow four loan an alysts to use the system at o nce. This requirem ent sho uld have suggested to you that it is necessa ry to design the L oan Arranger so rthat certa in loans are locked while they are being considered for a bundle. Wbat is the best way to i mple ment this sche me? H ow can the imp leme ntati on be done so that you can easily change the numbe r of analysts a Uowed o n the system at a given time?

A second implementation difficulty arises when you implement the bundLing algorithm. How will your code find the best bundle to fit the crite ria ? Remember rthat you must respond to the user in a sho rt period of time.

Finally, how does your choice of language affect the ability to meet the p erfor- mance require me nts?

Openmirrors.com

Section 7.12 Exercises 399

7.11 KEY REFERENCES

The re are several good books providing programming guidelines: Ke rnighan and Plauger (1976, 1978); Hughes, Plleeger, and Rose (1978); Ba rron and Bisho p (1984); Be ntley (1986, 1989); and M cConne ll (1993) .

Re use re positories a re available worldwide. Some of the m o r e popuJar o nes a.r e

• ASSET ( A s.set Source for Software Eng ineering Techn o logy)

• C ARDS (Centra l Archive for R e usa ble D e fe nse Software)

• COSMIC (Compute r Software Manageme nt and Information Cente r)

• DSRS ( De fe nse Software R e posito ry System)

• Software Techno logy S uppo rt Ce nte r at HiU Air Force Base

Contac t info rmation fo r these and o the r r e use resources c an be fo und o n tbe book's We b page.

7.12 EXERCISES

1. We call a statement in any language a compute d case type of statement if it branches to one of several areas in the program, depending on the value of a variable. Discuss the pos- itive and negative aspects of a computed case statement. In particular, how does it affect control How? Maintainability? Reusability?

2. If one person has written a component but others have revised it, who is responsible if the component fails? What are the legal and ethical implications of r eusing someone else 's component?

3. A list is a data structure that can be defined recursively. Give a recursive definition of a list. If you are familiar with a programming language that has recursive procedures (such as LISP or PUI), explain how elements are added to and de leted from a list in that language.

4. Give an example to show how a language designed for recursion makes list handling eas- ie r to understand than a language without such provision.

5. You are asked to write a program to print out a yearly calendar. The user enters the year d esired , and the output is a calendar for that year. Discuss how the representation of internal data will affect the way in which the program is written. Give several examples of data structures that might be used in such a problem. (Hint: Are your data structures cumulative or not? How is a leap year handled?)

6. The common algorithm for calculating the roots of a quadratic equation by the quadratic formula requires considering several special cases in your code. Write appropriate comments for this algorithm so that the comments make it easy to see the diffe rent cases a nd how they are handled. Write accompanying ext ernal docume ntation to explain this algorithm.

7. Find out the paging algorithm for a computer operating system with which you are famil- iar. Write external documentation for the algorithm, explaining to a user how pagin g is d one.

8. Look at a program you have submitted as a project in another class. Can it be improved by using the suggestions in this chapter? If so, how? Does incorporating these suggestions make your program mo re o r less efficient?

400 Chapter 7 Writing the Programs

9. What are the advantages and disadvantages of using the same standardized language or tools across all applications in your organization?

JO. When code components are gene rated automatically by a tool or reused from a reposi- tory, how should coding, documentation, and design standards be en forced?

11. How can control flow be documented for an object-oriented program?

Openmirrors.com

8

In this chapter, we look a t • types of faults and how to classify

t hem • t he purpose of testi ng • unit t esti ng • integration testi ng strategies • test planning • w hen to st o p test ing

Once you ba ve coded your program components, it is time to test them. There are many types of testing, and this chapte r and the next will introduce you to several testing approaches that lead to d elive ring a qualjty syste m to your custom ers. Testing is not the first place where fault finding occurs; we have seen how requirements and design reviews he lp us fe rret o ut problems ear ly in development. But testing is focused on finding faults, and the re are many ways we can make o ur testing e fforts more efficient and e ffective . In tills chapter, we look at testing compone nts indjviduaUy and then ilnte- grating the m to check the inte rfaces. Then, in C hapter 9, we concentrate on techniques fo r assessing the syste m as a whole.

8.1 SOFTWARE FAULTS AND FAILURES

In an ideal situatio n, we as programmers become so good at our craft that every pro- gram we produce works properly every time it is run. Unfortunately, trus ideal is not re ality. The diffe rence be tween the two is the res ult of several things. First, many soft- ware syste ms deal with lar ge numbe rs o f states and with complex fo rmuJ as, activities, and algorithms. In addition to that, we use the tools at our disposal to implement a cus- tome r's conception of a syste m whe n the customer is sometimes uncertai.n of exactly what is needed. Finally, the size o f a project and the number of people involved can add complexity. Thus, the presence of faults is a functio n not just of the software, but also of user and customer expectations.

What do we mean whe n we say that our software has failed? Usu ally, we mea n that the software does not do what the requirements describe. For example, the specification

401

402 Chapter 8 Testing the Programs

may sta te that the system must respo nd to a particular query only when the use r is authorized to see the data. If the program respo nds to an unautho rized use r, we say that the syste m bas failed. The failure may be the result of any of several reasons:

• The specifica tion may be wrong o r have a missing require me nt. The specification may not state exactly what the customer wants o r needs. In our example, the cus- tomer may actually want to have several categories of authorization, with each cat- egory having a different kind of access, but has neve r stated that n eed explicitly.

• The specificatio n m ay contain a re quire ment that is impossible to implem ent, given the prescribed hardware and software .

• The syste m design may contain a fauJt. Perhaps the database and que ry-langu age designs make it impossible to autho rize user s.

• The program desig n may contain a fault. The component description s may con - ta in an access control a lgorithm that does no t handle this case correctly.

• The program code may be wro ng. It may implement the algorithm improperly or incomple tely.

Thus, tbe failure is the result of one o r more faults. in some aspect of the system. No matte r how capa bly we write programs, it is clear from the varie ty of possible

faults that we should check to e nsure that our compo nents are coded correctly. Many programme rs view testing as a demo nstratio n that their programs pe rform prope rly. H oweve r, the idea of de monstrating correctness is reaUy the reverse of what testing is au about We test a program to demonstrate the existem:e o f a fa ult. Because our goal is to discover faults, we conside r a test successful only when a fault is discove red or a fa il - ure occurs as a result o f o ur testing procedures. Fa ult identification is the process of determining what fa ult or faults caused the failure, and fault correction or removal is the process of making chan ges to the system so that the faults are removed.

By the time we have coded and are testing program compone nts, we hope that the specifications are correct. Mo reover, having used the software engineering techniques described in previous chapte rs, we have trie d to en sure that the design of both the sys- tem and its compo ne nts reflec ts the re quirements and forms a bas.is for a sound imple- me ntation. However, the stages o f the software de ve lo pment cycle involve not only our computing skills, but also our communication and inte rperson al skills. It is entirely pos- sible that a fa ult io the software can result from a misunde rstanding during an earlier develo pment activity.

It is important to remember that software faults are diffe rent from hardwa re fa ults. Bridges, bui ldings, a nd otbe r e ngineered constructions may fa il because of sh oddy mate rials, poor design, o r because their compo nents wear o ut. But loops do not wear out after several hundred iterations, and argume nts are no t droppe d as they pass from o ne compon ent to another. If a particular piece o f code is n ot working prope rly, and if a spurious hardware failure is not the root of the proble m, the n we can be certain that the re is a fau lt in the code. For this reason , many software eng ineers refuse to use the te rm " bug" to descr]be a software fa ult; calling a fault a bug implies that the fault wandered into the code from some exte rnal source ove r which the developers have no control. In building software, we use software e ngineering practices to control the qual- ity of tbe code we write.

Openmirrors.com

Section 8.1 Software Faults and Failures 403

In previous chapte rs, we examined many of !be practices tbat belp minimize tbe introductio n of faults during specification and design. I n this chapte r, we examine tech- niques that can minimize the occurrence of faults in the program code itse lf.

Typ es o f Fa ults

Afte r coding the program componen ts, we usually examine the code to spot faults and e liminate the m right awa y. When no obvio us tau.Its exist, we then test our program to see if we can isolate more faults by cre ating condi tions where the code does not react as planned. Thus, it is impo rtant to kno w what kin d o f faults we are seeking.

An a lgorithmic fa ult occurs when a component's algorithm or logic does not pro- duce the proper output for a given input because some thing is wrong with the process- ing steps. These faults are sometimes easy to spo t just by reading th.rough the program (caUed desk checking) or by submitting inpu t data from each of tbe differe nt classes of data that we expect the program to receive du ring its regular working. Typical algorith- mic faults include

• branching too soon • branching too late • testing for the wrong condition • forge tting to initialize variables or set loop invariants • forge tting to test for a particular condition (e.g., whe n division by zero might

occur) • comparing variabl es o f inappropriate data types

Whe n checking for algorithmic faults, we may also look for syntax fa ults. Here, we want to be sure that we have prope rly used the constructs of the programming lan- guage. Sometimes, the presence o f a seemingly trivial fault can lead to disas trous results. For example, Mye rs (1976) points o ut that the first U.S. space mission to Ve nus failed because of a missing comma in a Fortran d o loop. Fortunately, compile rs catch many of o ur syntax faults fo r us.

Computation and precision faults occu r whe n a formula's imple mentation is wro ng o r does not comp ute the result to the required num ber o f decima l places. For instance, combining integer and fixed - or floa ting- point variables in an expression may produce unexpected results. Sometimes, improper use of floating-point data, unexpected truncation, or ordering o f operations may result in less-than-acceptable precision.

Whe n the docume ntation does not match what the program actually does, we say that the program has documentation fa ults. Often , the docume nta tion is derived from the program design and provides a ve ry clea r d escriptio n of what the programmer wo uld I ike the program to do, but the impleme nta tio n of those functions is fault y. Such faults can le ad to a proliferation o f othe r faults late r in the program's Life, since many of us te nd to believe the documentation when examining the code to make modificatio ns.

The requirements specification usually de tails the numbe r o f users and devices and the need for communication in a system. By using this info rmation, the designer often tailors the system characteristics to handle no more than a maximum load described by the require ments. These characte ristics are carried through to the program

404 Chapter 8 Testing the Programs

design as limits on the le ngth o f queues, the size of buffe rs, the dime nsion s of table s, and so o n. Stress o r overload faults occur when these data structures are filled past t!beir specified capacity.

Similarly, ca pacity o r bo undary faults occur when the system 's performance becomes unacceptab le as system activity reac hes its specined limit. For instance, if the requirem e nts sp ecify that a system must handle 32 devices, the programs must be tested to monito r syste m performance when all 32 devices are active. Moreover, the system should a lso be tested to see what happens whe n more than 32 devices are active, if such a configuratio n is possible. By testin g a nd documenting the syste m's reaction to over- loading its stated capacity, the test team can help the maintenance te am understand the implica tio ns of increasing syste m capacity in the future. Ca pacity conditi ons should also be examined in relation to the number o f disk accesses, the number of inte rrupts, the numbe r o f tasks running concurre ntly, and similar system-re lated me asures.

In developing real -time systems, a critical consideration is the coordination of several processes e xecuting simultaneously or in a carefull y de fin ed sequence. Timin g o r coordination faults occu r when the code coordina ting these events is inadeq u ate. The re are two reasons why this kind of fault is hard to identify and correct. First, it is usually difficult for desig ners a nd programmers to anticipate all possible system states. Second, because so many factors are involved with timing and p rocessing, it may be impossiible to replica te a fault after it has occurred.

Throughput or performance faults occur when the system does not perform at the speed prescribed by the require ments. These are timing proble ms of a different sort: Tune constraints are placed on the system's pe rformance by the custo mer's re4llire- ments rathe r than b y the need for coordinati on.

A s we saw during d esign and programming, we take grea t ca re to ensure that the system can recover from a variety of failures. Recovery faults can occur whe n a failure is encou ntered and the syste m does not behave as the designers desire or as the cus- tomer requires. For example, if a power failure occurs during system processing, the sys- tem sho uld recover in an acce ptable manner, such as restoring all files to their stale just prior to tbe failure. For some systems, such recovery may mean that the system will con- tinue full processing by using a backup p ower source; for othe rs, this recovery me ans that the system keeps a Log o f transactio ns, allowing it to continue processing whe never po we r is resto red.

Fo r many systems, some of the hardware and re lated syste m software are pre- scribed in the require me nts, and the components are designed according to the spe cifi- cations o f the reused or purchased programs. For example, if a prescribed modem is used for comm unication s, the modem driver gene rates the commands expected by the mode m and reads co mm ands received from the mode m. H owever, hardware and sys- tem software faul ts can arise when the suppLied h ardware and system software d o not actuall y work according to the docume nted ope rating conditions and procedures.

Finally, the code sh ould be reviewed to confirm that organizational standards and procedures have bee n followed. Standa rds and procedure faults may no t always affect the running of the programs, but they may foste r an environment whe re faults are cre- ated as the system is tested and modifie d. By failing to follow the required standards, o ne programmer may make it difficult for another to understand the code's logic or to find the data descriptions needed for solving a problem.

Openmirrors.com

Section 8.1 Software Faults and Failures 405

Orthogona l De fe ct Cla ssificati o n

It is usefuJ to categorize and track the types of faults we flnd, not just in code, but any- where iin a software system. Historical information can help us predict what types of fault<; o ur code is like ly to have (which he lps direct our testing efforts), and clusters of ce rtain types of faults can warn us that it may be time to rethink o ur designs or even our requirements. Many organizations perform statistical fault modeling and causal analy- sis, both of which depend o n understanding the numbe r and distribution of types of faults. For e xample, IBM's Defect Preve nti on Process (Mays et a l. 1990) seeks and doc- uments the root cause of every proble m that occurs; the information is used to help sug- gest what types of faults testers should look for, and it has reduced the number of faults injected in the software.

Chillarege et al. (1992) at IBM have developed an approach to fault tracking ca lled o rt hogon al defect classification, where faults are placed in categories that collec- tive ly paint a picture of which parts of the development process need attention because they are responsible for spawning many faults. Thus, the classification scheme must be product- and o rganization-indepe nde nt, and be applicable to all stages of develop- ment. Table 8.1 lists the types of faults that comprise IBM's classification. When using the classification, the developers identify n ot o nly the type of fault, but also whether it is a fault of o otissio n or commission. A fault of omission is one that results when some key aspect of the code is missing; for example, a fault may occur when a variable is not initialized. A fa ult of commissio n is one that is incorrect; for exam ple, the variable is ini- tialized to the wrong value.

One of the key features of orthogonal defect classification is its orthogonality. That is, a classification sche me is o rth ogona l if any item being classified belongs to exact ly one category. In othe r words, we want to track the fa ults in our system in an unambiguous way, so that the summary information about the number o f faults in each class is meaningful. We lose the meaning of the measurements if a fault might belong to more than one class. In the same way, the fault classification must be clear, so that any two developers are like ly to classify a particular fault in the same way.

TABLE 8.1 IBM Orthogonal. Defect Oassification

Fault Type Meaning

Function

Interface

Checking

Assignment liming/serialization Build/package/merge

Documentation Algorithm

Fault that affects capability. end~user interfaces. product interfaces. interface with hardware architecture, or global data structure

Fault in interacting with otber components or drivers via calls, macros, control blocks, or parameter lists

Fault in program logic that fails to validate data and values properly before tbey are used

Fault in data structure or code block initialization Fault that involves timing of shared and real-time resources Fault that occurs because of problems in repositories, management changes,

or version control Fault that affects publications and mainte nance notes Fault involving efficiency or correctness of algorithm or data structure but not

design

406 Chapter 8 Testing the Programs

SIDEBAR 8.1 HEWLETT-PACKARD' S FAULT CLASSIFICATION

Grady (1997) describes Hewlett-Packard's approach to fault classification. In 1986, Hewlett-Packard's Software Metrics Council identified several categories in which to track faults. The scheme grew to be the one depicted in Figure 8.1. The developers use this model by selecting three descriptors for each fault found: the origin of the fault (i.e., where the fault was injected in a product), the type of fault, and the mode (i.e., whether information was missing, unclear, wrong, changed, or could be done a better way).

Each Hewlett-Packard division tracks its faults separately, and summary statistics are reported on pie charts like the one in Figure 8.2. Different divisions often have very different fault profiles, and the nature of the profile helps the developers devise r equirements, design, code, and test activities that address the particular kinds of faults the division usually sees. The overall effect has been to reduce the number of faults over time.

Fault classifications, such as IBM's and H ewlett-Packard 's (see Sidebar 8.1), h elp improve the entire developme nt process by te lling us which types of faults are found in which d eve lo pment activiti es. For example, for each fault-identification or testing tech- nique u sed while building the system, we can build a profil e of the types of faults located. It is like ly that diffe re nt methods wiU yield different profiles. Then we can build our fault-pre vention and -de tection strategy based on the kinds of faults we expect in o ur system, and the activities tbat will root the m out. Chillarege e t al. (1992) illustrate

ORIGIN: WHERE?

Other

('. Requirements H W interface (Inter-) Process logic Test HW .... cc

communications % or SW interface Computation Test SW ~ speeific1tions

Data 4efin ition <41 User interface Data hand I in! Integration SW 0...

~ Functionalily Functiml

Mo4ule design Mo4ule Development

4escription Lo5ic interface/ tools

4ncription implementation

Error checking Standards

Standards

MOOE: WHY?

Nissin! Unclear Wrong iChan914 Better way

FIGURE 8.1 Hewlett-Packard fault classification (Grady 1997).

Openmirrors.com

Computation 18%

Other code 11%

Logic 32%

Section 8.2 Testing Issues 407

Data handli ng 6%

Documentation 19%

Reqqire ments S%

Hard:ware 4 %

FIGURE 8.2 Faults for one Hewlett-Packard division (Grady 1997).

IBM's use of this concept by showing us that the fa ult profile for d esign review is very diffe rent from that for code inspectio n.

8.2 TESTING ISSUES

Many types of tests are done before we ca n re lease the system to the custome r with confide nce that it will work prope rly. Some tests depe nd on what is being tested: com- ponents, groups of components, subsystems, or the who le system. Othe r tests depe nd on what we want to know: Is the system working according to the design? The require - ments? The custome r's e xpectations? Let us consider some of these issues.

Test Orga nizat ion

In developing a large system, testing usually in volves several stages. First, e ach program compo nent is tested on its own, isolated from the other components in the system. Such testing, known as modu le testing, component testing, or unit testing, ve rifies that the component functions properly with the types o f input e xpected from studying the com- ponent's design. Unit testing is done in a controlle d environment whenever possible, so that the test team can feed a predete rmined set of data to the component being tested and o bserve what output actions and data are produced. In addition, the test team checks the inte rnal data structures, logic, and boundary conditions for the input and output data.

When collections of components have been unit-tested, the n ext step is ensuring that the inte rfaces among the compone nts a re defined a nd handled properly. Integration testing is the process of verifying that the system compone nts wo rk together as described in the system and program design specification&

Once we are sure that informati on is passed a mong componen ts in accordance with the design, we test the syste m to ensure that it has the desired func tionality. A function test eva luates the system to determine if the func tions described by the requireme nts

408 Chapter 8 Testing the Programs

specification are actually pe rformed by the integrated system. The resuJt is a function- ing system.

R ecall that the require ments were documented in two ways: first in the cus- tomer's te rminology, and again as a set of software and hardware requirements the develo p ers could use. The functi on test compares the system being built with the func- tio ns described in the de velope r's requirements sp ecification. Then , a performance test compares the system with the re mainder of these softwa re and hardware requireme nts. When the test is pe rformed successful ly in a custo mer's actual working e nvironme nt, it yields a validated system.

When the performance test is complete, we developers are certain that the system functions according to our understanding of the system descriptio n. The next step is con- ferring with the customer to make certain that the system works according to customer expectatio ns. We join the customer to pe rform an acceptance test, where the system is checked against the custome r's requirements description. Upon comple tion of acce pt- ance testing, the accepted system is install ed in the environment in which it will be u sed ; a final installatio n test is run to make sure that the system stiU functions as it should.

Figure 8.3 illustra tes the relationship among these testing steps. No matte r the size of the syste m being tested, the type of testing described in each step is necessary for e nsuring proper functioning. In this chapter , we focus primarily on unit a nd integration testing, whe re compone nts are tested by the mselves and then merged into a larger, working syste m. In Chapte r 9, we will look at the re maining steps in the testing process, collectively called system testing. In these later steps, the system is viewe d and teste d as a whole rather than as separate pieces.

., .... 8

Design System Other Cutomer - Unit User c :1

test specifications functional software requirements environment 0 e reqai rements requirements specification 0 ~

., .... 8 - Unit c :1 test 0 e ~

• Function Performance Acceptance Installation t8$t test test tett test

• I nte5r1ted Function in5 Verified, Accepted

• modules system validated system ., .... 0 ..

software

- Unit e .. c

test SYSTEfl41 0 .... E ~ IN USE!

FIGURE 8.3 Tusting steps.

Openmirrors.com

Section 8.2 Testing Issues 409

Attitudes Toward Testing

New programmers are not accustomed to viewing testing as a discovery process. As stu- dents, we write programs according to the specificatio ns given by out instructor. After having d esigned a program, we write the code and compile it to determine if any syntax fa ults a re present. When submitting our program for a grade, we usuaJly present our instructor with a program listing, data used as test input, and any output that sh ows h ow our p rogram handled the input. The collectio n of code, input, and output acts as evi- dence that o ur code runs correctl y, and we usually choose our input to persuade our instructor tha t the code functions as directed in our class assignment.

We may have considered our program o nly as a solution to a problem; we may not have considered the proble m itself. If so, our test da ta may have been ch osen to sh ow positive results in certain cases ra th er than the absence of fa ults. Programs writte n and presented in this way are evidence of o ur programming skill. Thus, psycho logically, we may conside r a critique of o ur program to be a critique o f our ability. Testing to sh ow that our program works correctl y is a way of de mo nstrating our skills to our instruc tor.

H owever, developing a system for customers is different. C ustomers are not inter- ested in knowing that the system works prope rly u nder certain conditions. Rather, they are inte rested in being sure that the system works properly under all conditions. So o ur goal as a deve lope r sho uld be to e liminate as many faults as possible, no matter where in the system the y occur and no matter who crea ted them. Hurt feelings and bruised egos have n o place in the development process as faults are discovere d. Hence, many software engineers adopt an attitude known as egoless programming, where pro- grams are viewe d as compo nents of a larger syste m, no t as the property of those who wrote the m. When a fault is disco ve red o r a fa ilure occurs, the egoless development te am is concerned with correcting the faul t, not with placin g blame on a particular developer.

Who Performs the Tests?

Even when a syste m is developed with an egoless approach, we sometimes have diffi- culty removing our pe rson al feelings from the testing process. Thus, we often use an inde pendent test team to test a system. In this way, we avoid co nfuct between personal responsibility for faults a nd the need to discover as ma ny fa ults as possible.

In addition, several other factors justi fy an independent team. First, we may inad- vertently introduce faults when interpre ting the dlesign, determining the program logic, writing descriptive docum entation, o r impleme nting the a lgorithms. Clearl y, we wo uld n o t have submitte d our code for testing if we did not think the code p erformed accord- ing to specification. But we may be too close to the code to be o bjective a nd to recog- nize some of the more subtle faults.

Furthe rmore, an independent test team can participate in re viewing the compo- ne nts thIOughout develo pment. The tea m can be part of the require me nts and design reviews, can test the code components individually, and can test the syste m as it is inte- grated and presented to the customers for acceptance. In this way, testing can proceed co ncurre ntly with coding; the test te am can test components as they a re comple ted and begin to piece them together while the programming staff continues to code othe r components.

410 Chapter 8 Testing the Programs

Views o f t h e Test Objects

Before we look care full y at unit testing, let us consider the philosophy behind our testing. As we test a component, group of components, subsystem, o r system, our view o f the test o bject (i.e., the compo ne nt, group, subsystem, or system) can affect the way in which testing proceeds. If we view the test object from the outside as a closed box or b lack box whose contents are unknown, our testing feeds input to the closed box and no tes what output is produced. Io this case, the test's goal is to be sure that every kind of input is submitte d, and th at the o utput o bserved matches tbe output expected.

There are advantages and disadvantages to this kind of testing. The obvious advantage is that a closed box is free of the constraints imposed by the inte rnal struc- ture and logic of the test object. However, it is n ot always possible to run a complete test in this manner. For example, suppose a simple compone nt accepts as input the three numbe rs a, b, and c, and produces as output the two roots of the equation

ax2 +bx+ c = 0

o r the message " no real .roots." It is impossible to test the compo nent by submitting to it every possible triple of numbers (a, b, c). In this case, the test team may be able to choose representative test data to show that all possible combinations are bandied properly. For instance, test data may be chosen so that we have all combinations o f pos- itive, negative, and zero for each of a, b, and c: 27 possibilities. If we know something about solving juadratic e quations, we may prefer to select values that e nsure that the discriminant, b - 4ac, is in each of three classes: positive, zero, or negative. (In this sit- uatio n, we a re guessing a t how the compo nent is impl emented.) H owever, even if a test in each of the classes reveals no faults, we have no guarantee that the component is fault-free. The compo ne nt may still fail for a particula r case because of subtleties such as round-off e rror o r incompatible data types.

For some test o bjects, it is impossible for the test team to gen erate a set of repre- se ntative test cases that demonstrate correct functionality for all cases. RecalJ from Chapte r 7 the componen t that accepted adjusted gross income as input and produced the amount of federal income tax owed as output. We might have a tax table showing expecte d o utput fo r cert ain give n inputs, but we m ay not know in gene ral how the tax is caJculalled. The a lgorithm for comp uting tax depends on tax brackets, and both the bracket limits and associated pe rcentages are part of the component 's internal process- ing. By v iewing this component as a closed box, we could not choose representative test cases because we do not know e nough about the processing to choose wisely.

To ove rco me this proble m, we can instead view the test object as an open box (some times called clear box or white box); the n we can use the structure of the test o bj ect to test in diffe re nt ways. For example, we can devise test cases that execute all the stateme nts or all the control paths within the component(s) to be sure the test object is working properly. Ho weve r, as we will see later in this ch apter, it may be impracllical to take this kind of approach.

Fo r example, a component with many branches and loops has many pa tbs to check. Even with a fairly simple logical structure, a compone nt with substantial iteration or recursio n is difficult to test thoroughly. Suppose a compo nent's logic is structured so it

Openmirrors.com

I= I + 1 J = 1

Section 8.2

l = J = I

PERFORM A

NO

PERFORM B

NO

J = J + 1

PERFORM D

FIGURE 8.4 Example logic structure.

Testing Issues 41 1

PERFORM C

loops nm times, as shown in Figure 8.4. If n and mare each equal to 100,000, a test case would have to loop 10 bilLion times to e xercise au logic paths. We can use a test strategy to exe rcise the loop just a few times, checkjng on ly a small number of re levant cases that represent the e ntire set of possibiHties. In trus example, we can choose a value for I that is less than n, another that is equa l to n, a nd still anoth er greater than n ; simil arly, we can look at J less than m , equal tom, and greater than m , and at combinati ons of these with the three combinations of values of/. In gene ral , the strategy can be based on data, structure, function, or several othe r criteria, as we shall see.

Whe n dec iding how to test, we need not choose e ithe r open- or closed-box test- ing e xclusive ly. We can think of closed-box testing as one end o f a testing continuum and o pen-box testing as the other end. Any test prulosophy can lie som ewhe re in be twee n. Sidebar 8.2 shows us how some approaches, such as the box-structured approach, combine several points on the continuum to address a compone nt from sev- e ral perspectives. In general , the choice of test philosophy de pends on many factors, including

• the numbe r o f possible logical paths • the nature of the input data • the amount of computati on involved

• the complexity of the algorithms

41 2 Chapter 8 Testing the Programs

SIDEBAR 8.2 BOX STRUCTURES

TJte box-structured approach to information systems ties together and extends the notions I of open-box and closed-box views (Mills, Linger, and Hevner 1987;Mills 1988). This tech-

nique begins with a black-box view and extends it by stepwise refinement to a state box and then a clear box.

The black-box view of an object is a description of its external behavior in all possible circumstances. The object (a component, subsystem, or complete system) is described in terms of the stimulus it accepts, plus its stimulus history-that is, the record of how it has reacted to stimuli in the past. We can thus describe each response as a transition

(stimulus, stimulus_history-+ response)

Next, the state-box description is derived from the black box by adding state informa- tion. Each transition is written as

(stimulus, old_state-+ response, new _state)

Finally, the clear-box description adds a procedure that implements the state box; that is, it describes how the stimulus and old state are transformed to the response and new state:

(stimulus, old_state -+ response, new _state) by procedure

The procedure is written in terms of sequence. alternation. iteration. and concurrency. The progression from black box to clear box is useful not only in testing, but also in designing components, helping to turn a high-level description into a lower-Level , more carefully described design.

8.3 UNIT TESTING

If our goal is to find faults in compone nts, how do we begin? The process is similar tot.he one yo u use wben testing a program assign ed in class. First, you examine your code by re ading through it, trying to spot algorithm, data, and syntax faults. You may even compare the code with the sp ecifications and with your design to make sure you have considered all re levant cases. Next, you compile the code and e liminate any remaining syntax faults. Finally, you deve lop test cases to show if the input is properly conve rted to the desire d out- put. Unit testing foUows exactly these s teps, and we examine them on e at a time.

Examining t he Code

Because the design description helps you to code and document e ach program compo- nent, your program re flects your interpretation of the design. The documentation explains in words and pictures what the program is supposed to do in code . Thus, it is helpful to ask an objective group of experts to review both your code and its documentation for

Openmirrors.com

Section 8.3 Unit Testing 413

misunderstandings, inconsistencies, and other faults. The process, known as a code review, is similar to the require ments and design reviews discussed in earlie r chapte rs. A team is formed, composed of you as the programmer and three or four other technical experts; the team studies the program in an organized way to look for faults. The technical experts can be ot her programmers, designers, technical writers, or project supervisors. Whe reas the design review team included customer representatives, the code review team contains no one from the customer's organization. Customers express requirements a nd approve the proposed design; they are interested in implementation onJy when we can demon- strate that the syste m as a whole works according to the ir description.

Code Walkthroughs. The re are two types of code review: a walkthrough and an inspection. In a walk thro ugh, you present your code and accompanying documentation to the re view team, and the team comments on their correctness. During the walk- thro ugh, you lead and contro l the discussion. The atmosphere is informal, a nd the focus of attention is o n the code, not the coder. Although supervisory personnel may be pre- sent, the walktluough has no influence on your performance appraisal, consistent with the gene ral inte nt of testing: finding faults, but not necessarily fixing them.

Code Inspectio ns. A code ins pection , o riginally introduced by Fagan (1976) at IBM, is similar to a walkthrough but is more formal. In an inspection, the review team checks the code and documentation against a prepared List of con cerns. For example, the team may examine the definition and use of data types and structures to see if their use is consiste nt with the design and with system standards and procedures. The team ca n review algorithms and computations for their correctness and efllciency. Com- ments can be compared with code to ensure that they are accurate and complete. Simi- larly, the inte rfaces among components ca n be checked fo r correctness. ll1e team may eve n estimate the code's pe rformance characte ristics in terms of memory usage o r pro- cessing speed, in preparation for assessing compliance with performance requirements.

Inspecting code usuaUy involves several steps. First, the team may meet as a group for an overview of the code and a description of the inspe<:tion goals. Then , Learn mem- bers prepare individuaJly for a second group meeting. Each inspector studies the code and its re lated documents, noting faults found. FinaUy, in a group meeting, team mem- bers report what they have fo und, recording additionaJ faults discovered in the p rocess of discussing individuals' findings. Sometimes faults discove re d by an individual are considered to be " false positives": ite ms that seemed to be faults but in fact were not considered by the group to be true problems.

Insp ectio n team members are chosen based on the inspection's goals, and some- times a team member will have more than one role. For example, if the inspection is intended to verify that the inte rfaces are correct, then the team should include interface designers. Becau se the goal is the focus of the inspection , a team moderator, not the programme r, is the meeting's leader, using a se t of key questions to be answered . As with walkthroughs, inspectio ns criticize the code, not the code r, and the results are no t reflected in a performance evaluatio n.

Success of Code R eviews. You may feel uncomfortable with the idea of ha ving a team examine your code. Howeve r, re views have been shown to be extraordinarily

414 Chapter 8 Testing the Programs

successful at detecting faults and are often include d in an organization's list of manda- tory o r best practi ces. R emember that the earlje r in the development process a fault is spotte d , the easie r and Jess expensive it is to correct. It is better to find a problem at the compone nt leve l than to wait until later in the testing cycle, when the source of the proble m may be fa r less clear. In fact, for this reason, G ilb (1988) and G ilb and Graham (1993) suggest inspecting early deve lopment artifacts, su ch as specifications and designs, not just cod e.

Severa l researche rs bave investigated the extent to which reviews have identified faults. Fagan (1976) pe rformed a n experiment in which 67% of the system's faults even- tually d etected were found befo re urut testing using inspections. In Fagan's study, a sec- o nd group o f programmers wrote simjlar programs using informal walkthroughs rather than inspections. The in spectio n group's code had 38% fewer failures during the first se ven months of operatio n than the walktbrough group's code. In a nothe r Fagan exper- ime nt, o f the to tal number o f faults discovered during system development, 82% were found during design and code inspections. The early detection of faults le d to large sav- ings in developers' time. Other researche rs re port results from the ir use of inspections. For instance, Ackerman, Buchwald, and Lewski (1986) noted that 93% of all faults in a 6000-Line business appLication were found by ins pections.

Jo nes (1977) bas studjed programmer productivity exte nsively, inclurung the nature of faults and the methods for finrung and fixing them. Examining the history of 10 milli on Lines o f code, h e found that code ins pections removed as many as 85% of the total faults found. No other technique studied by Jones was as successful; in fact, none coukJ re move e ven half of the known faults. More recent investigalions by Jones (1991) s uggest typical preparation times and meeting times, as shown in Tabl e 8.2.

G rady (1997) explains that at H ewlett-Packard, planning for an inspectio n typi- cally takes a bo ut two hours, followed by a 30-minute meeting with the team. Then, individual preparation invo lves two hours of finding fauJts and 90 minutes of recording the individual findings. Tue team spe nds about 30 minutes brainstorming the findings and recomme nding ac tions to be taken. After the faults have been fixed, the moderator of the inspec tion meeting spends an additional half-hour to write and release a sum- mary docume nt. Sidebar 8.3 describes how software developers at BuJL Information Systems investigated ways to re duce resources n eeded for inspections but maintain their effective ness.

Jones (1991) summarizes the data in rus lar ge repository of project information to paint a ruffe rent picture of how reviews and inspections find faults, relative to other

TABLE 8.2 'JYpical Inspection Preparation and Meeting Tunes (Jones 1991)

Development Artifact

Requirements document Functional specification Logic specification Source code User documents

Preparation Time

25 pages per hour 45 pages per hour 50 pages per hour 150 lines of code per hour 35 pages per hour

Openmirrors.com

Meeting Time

12 pages per hour 15 pages per hour 20 pages per hour 75 lines of code per hour 20 pages per how·

Section 8.3 Unit Testing 415

SIDEBAR 8.3 THE BEST TEAM SIZE FOR INSPECTIONS

W eller (1993) examined data from three years of inspections at Bull Information Sys-tems. Measurements from almost 7<XXJ inspection meetings included information about 11,557 faults and 14,677 pages of design documentation. He found that a three-person inspectio n team with a lower preparation rate did as well as a four-person team w ith a higher

rate; he suggested that the preparation rate, not the team size, determines inspe ction e ffec-

tive ness. He also found that a team's effectiveness and efficiency depended on the ir familiar-

ity with their product: the more familiarity, the better.

On the other hand, Weller found that good code inspection results can create fa lse confi-

dence. On a project involving 12,000 lines of C, the requirements and design were not reviewed: inspections began with the code. But the requirements continued to evolve during unit and integration testing, and the code size almost doubled d uring that time. Compa ring

the code inspection data with the test data , Weller found that code inspections identified

mostly coding or low-level design faults, but testing discovered mostly require ments and architectural faults. Thus, the code inspection was not dealing with the true source o f variabil-

ity in the system, and its results did not represent the true system quality.

discove r y activi tie s. Be cause products var y so wildly by size, Table 8.3 presents the fault discovery rates re lative to the number of thousands of lines o f code in the de live red product. The table makes it cle ar that code inspectio n finds fa r more faults than most other technique s. H oweve r, rese archers continue to inve&tigate whether some types o f activities find diffe re nt categories of fauJts than othe rs. For example, inspections tend to be good at findjng code fa ults, but prototyping is better for identifying require ments problems.

Afte r Fagan published his guidelines for inspecting code at IBM, many o ther organizations, including He wlett-Packard (Grady and van Slack 1994), ITI, and AT & T (Jo nes 1991), adopted inspections as a recomme nded o r stand ard practice. D escriptio ns o f the successful app licatio n o f inspections continue to .appea r in the literature, and some are refe renced on this book's We b site.

TABLE 8.3 Faults Found During Discovery Activit ies (Jo nes 1991)

Discove ry Activity

Require ments review Design review Code inspection Integration test Accepta nce test

Faults Found per Thousand Lines of Code

2.5 5.0

10.0 3.0 2.0

416 Chapter 8 Testing the Programs

Proving Code Correct

Suppose your component has been coded, examined by you, and reviewed by a team. The next step in testing is to subject the code to scrutiny in a more structured way to establish its correctness. For the purposes of uni t testi ng, a program is cor rect if it imp le- ments the functions and data properly as indicated in the design, and if it interfaces properly with other components.

One way to investigate program correctness is to view the code as a stateme nt of logica l flow. If we ca n r ewrite the program using a fo rma l, logical syste m (such as a se ries of stateme nts and implica tio ns about data), then we can test this new expression fo r correctness. We inte rpret correctness in terms of the design, and we want our expressions to foUow the precepts of mathematical logic. For instance, if we can formu- late the program as a sert of assertions and theorems, we can sho w that the truth of the theore ms implies the correctness of the code.

Formal Proof'Tcchniqucs. Let us loo k at how a fo rmal proo f works. We convert tbe cod e to its logical counte rpart in a series o f steps:

1. First, we wdte asser tions to describe the component's input and output condi- tions. These statements are combinations of logical variables (each of which is true or fa lse), connected by the logical connective symbols displayed in Table 8.4.

For exampl e, suppose a component accepts as input an array T of size N. As out- put, the component produces an equivalent a rray T ' , consisting of the e lemen ts of T arranged in ascending order . We can write the input conditio ns as tbe assertion:

A 1: (T is an array) & (Tis of size N)

Similarly, we can write the output as the assertio n

A end: (T ' is an array) & (Vi ifi < N then (T '(i) :5 T ' (i + 1))) & (Vi if i :s N then 3 j(T' (i) = T(j)) & (T' is of size N))

2. Next, we draw a ft.ow diagram depicting the logical How of tbe componen t. On the d iagram, we denote ]points at which a transforma tio n ta kes place.

Figure 8.5 shows such a diagram fo r a component where a bubble sort is used to rearrange T into ascending order. Io the figure, two po ints a re highlighted to show

TABLE 8.4 Logical Connect ives

Connective

Conjunction Disjunction Negation Implication Equivalence Universal quantifier Existential quantifier

Example

x&y xVy -x x-+ y x = y V x P(x) 3 x P(x)

Openmirrors.com

xand y xory notx ifx then y xequalsy

Meaning

for all x, condition P (x) is true for at least one x, P(x) is true

8-- -- NO

NO

f = T MORE = TR UE

l = O

NOT(MORE) = TRUE

I = I + I

EXCHANGE f (I) WITH f (I + I)

Section 8.3 Unit Testing 417

MO

······ ········· ·· ····· ·· ···0 ~-----'----~

MORE = TRU E

FIGU RE 8.5 Flow diagram for array rearrangement.

wbe re tbe transforma tio ns take place. The point marked with a single aste risk can be described as an assertion in the f'o Uo wing way:

[( no t(more) = true) & (i < N ) & (T '(i) > T '(i + 1))] -+ ((T ' (i )) is excha nged with T ' (i + 1)]

Similarly, the po int marked with a double asterisk can be writte n as

[(no t(rno re) = true) & (i 2: N )) -+ [T' (i)sorted) 3. From th e assertions, we gene rate a series o f theorems to be proven. Beginning

with the first assertio n a nd moving fro m one transforma tion to ano the r, we work o ur way through to e nsure that if one is true, then the next one is true. In other words, if tbe first asse rtion is A1 and the first transformatio n po int is A2 , the n o ur first th eorem is

A1-+A2

If A3 is the next transforma tio n po int, the n the secomd Lbeorem is

A i -+ A 3

418 Chapter 8 Testing the Programs

In this way, we state theorems

A;-+A;

where A; and Aj are adjacent transformation points in the fiow diagram. The last theo- rem states that a conditio n of "true" at the last transformation poinl implies the truth of the o utput assertio n:

Alternatively, we can work backward through the transformation points in the flo w diagram, beginning at Aend and finding the preceding transformation point. We prove first that

and the n tha t

aod so on until we have s bown that

A1-+A2

The result o f eithe:r approach is the same .

4. Next, we Locate loops in the flow diagram and specify an if-then assertion fo r each.

S. At this po int, we have identified aU poss:ible assertions. To prove the program correct, we locate all paths that begin with A1 and end with Aend· By following each of these paths, we are foUowing the ways in which the code shows th at the truth of the input condition leads to the truth of the output conditi on.

6. After ide ntifying all paths, we must verify the truth of each one by proving rig- orously that the input assertion implies the output assertion according to the transfor- ma tions of that path.

7. Finally, we prove that the program te rminates.

Advantages and Disadvantages of Correctness P roofs. By constructing an auto- matic o r manual proof in the manner described above, we can discover algorithmic faults in the code. In addition, the proof technique provides us with a formal under- standin g of the program, because we examine its underlying logical structure. Regular use of this approach forces us to be more rigoro us and precise in specifying data, data structures, a nd a lgo rithmi c rules.

Ho weve r, a price is paid fo r such ri gor. Mu ch work is invo lved in setting up and carrying o ut the proof. For e xample, the code fo r the bubble-sort compone nt is much smaUe r than its logical d escriptio n and proof. In many cases, it takes more time to prove the code correct than to write the code itself. Mo reover, larger and more complex com- ponents ca n involve eno rmous logic diagrams, man y transformati ons, and verificartion of a large number of paths. For instance, nonnume rical programs may be mo re difficult to represent Logically than numerical ones. Parallel processing is hard to handle, and complex data structures may result in ve ry complex transformation statements.

Openmirrors.com

Section 8.3 Unit Testing 419

Notice that the proof technique is based onJy on how the input asse rtions are transformed into the output assertions according to logical precepts. P roving the pro- gram correct in this logical sense does not mean that there are no faults in the software. Indeed , this technique may not sp ot fauJts in the design , in interfaces with other compo- ne nts, in inte rpreting the specification, in the syntax and semanti cs of the programming language, o r in the docume ntation.

Finally, we must acknowledge that not all proofs are correct. Seve ral times in the histo ry of mathe matics, a proo f that had bee n accepted as va(jd fo r maruy years was late r shown to be fallacious. It is. always possibl e for an especially intricate proo f argu- ment to be invalid.

Other Proof Techniques. The logical proof technique ignores the structure and syntax of the programming language in which the test program is implemented. In a sense, the n, the technique proves that the component's design is correct but not necessar- ily its implementation. Othe r techniques take the language characteristics inllo account.

One such technique, symbolic execution, invo lves. simulated execution of the code using symbols instead of data variables. The test program is viewed as having an input state de te rmined by the input data and conditions. As each line of the code is exe- cuted, the technique checks to see whether its state has changed. Each state change is saved, and the program's executi on is viewed as a series of state changes. Thus, each log- ical path through the program corresponds to an ordered series of state changes. The final state of each path sh ouJd be an output state, and the program is correct if each pos- sible input state generates the proper o utput state.

We can look at an example to see how symbolic execution works. Suppose we are testing these lines of a prog ram:

a = b + c; if (a> d) taskx(); else tasky () ;

II PERFORM TASKX I I PERFORM TASKY

A symbolic execution tool will note that the condition, a > d, can be either true o r false. Whe reas the conventional code execution would invo lve specific values of a and d, the symbolic executio n tool records two possible states: a > dis false and a > d is true. Instead o f testing a large number of possible values fo r a and d, symbo(jc execution con- siders only these two cases. In this way, large sets of data are divide d into disjoint equiva- lence classes or categories, and the code can be considered only with respect to how it reacts to each category of data. Considering only equivalence classes of data, repre- sented as symbo ls, greatly reduces the numbe r of cases considered in a proof.

Howeve r, this technique bas many of the same di sadvantages as logical theorem proving. D eve loping a proof may take longer than writing the code itself, and proo f o f correctness does not e nsure absence of faults. Moreover, the technique re(jes on a ca re- ful tracing of changing conditions throughout the program's paths. Although the tech- nique can be automated to some extent, large or comple x code may s till. require the checking of many states and paths, a time-consuming process. It is difficult for an auto- mated symbo lic e xecutio n tool to fo Uow executi on How through loops. In additio n, wbe neve r subscripts and pointe rs are used in tbe code, partitioning into equivalence classes becomes more difficult.

420 Chapter 8 Testing the Programs

A utomated Theorem Provin g. So me software e ngineers have tried to auto mate the process o f proving programs correct by develo ping tools that read as input

• tbe input data and condition s • the o utput da ta and co nditio ns • tbe Lines of code for the component to be teste d

The o utput fro m the automated tool is e ithe r a proof o f the compo nent's correct- ness o r a counte rexample showin g a set of da ta that the compo nent does not correctJy transform to output. The auto mated theore m prover includes information about the language in which the compo nent is written, so that the syntax and semanti cs rules are accessib le. Following th e program's steps, the theorem prover identifies the pa ths in se veral ways. If the usua l rules o f infere nce and d eduction are too cumbersome to be used , a h e uristic solutio n is some times e mployed instead.

Such theorem-provin g software is nontrivial to develop. For example, the tool must be able to verify the correct use o f unary and binary ope rations (e.g., addition , sub- traction , negation), as well as of comparisons involving equality and inequality. M ore complex laws such as commutativity, distributivity, and associativity must be incorpo- ra ted. E xpressing the programoting language as a set of postulates from which to derive theorems is very difficult.

Suppose these difficulties can be ove rcome. U sing trial and error to construct theo- rems is too time -conswning fo r any but the most trivial of components. Thus, some human inte raction is desirable to guide the theorem prove r. Using meth ods frequently e mployed when developing an expert system , an inter active theorem prover can work with its use r to choose transformation points and trace paths. Thus, the theorem pro ver does no t rea lly generate the proof; rather, it checks the proof o utlined by its user. Symbo lic-executi on-based tools have been developed to evaluate code in small pro- grams, but the re is no gene ral-purpose, language-independent, automated , symbo lic- execution syste m available.

Can the ideal theorem prover ever be buiJt, assuming the existence of a machine that is fast eno ugh and an implementation language that can handle the complexities of the proble m? The ideal theore m prove r would re ad in any program and produce as its o utput either a statement confi.rming the code's correctness or th e loca tion o f a fa ult. T he theorem prove r wo uld have to dete rmine if an arbitrary statement in the code is e xecute d fo r arbitrary input da ta . Unfortunately, this kind of theorem prover can never be built. It can be shown (in Pfteeger and Straight [1985], for exampl e) that the construc- tio n o f such a program is the equivale nt of the baiting p roblem fo r Turing machines. The halting proble m is unsolvable, which means no t only that there is n o solution to the pro blem, bul also tha t il is impossible eve r to find a solution. We can make our theorem prove r solvable by a ppl ying it o nly to code having no branches, but this Limitation makes the tool applicable only to a very narrow subse t of aU programs. Thus, a lthough highly desirable, an y auto mated theore m prover will o nly approximate the ideal.

Testing Program Com ponents

Proving code correct is .a goal to which software engineers aspire; consequently, much related research is do ne to deve lop me thods and autom ated tools. H owe ver, in the n ear

Openmirrors.com

Section 8.3 Unit Testing 421

future, development teams are more likely to be concerned with testing their software ratbe r than with proving the ir programs correct.

Testing vs. Proving. In proving a program correct, the test team or p rogrammer considers only the code and its input and output conditio ns. The program is viewed in te rms o f the classes o f data and conditions described in the design. Thus, the prroof ma y not invo lve executing the code but rather understanding what is going on inside the program.

H oweve r, customers have a different point o f view. To demonstrate to them that a program is wo rking prope rly, we must show them how the code performs from o utside the program. In this sense, testing becomes a series of experiments, the results o f which beco me a basis fo r deciding how the program will behave in a given situatio n. Whe reas a proo f te lls us how a program will work in a hypothetica l environment described by the design and requirements, testing gives us information about how a p rogram works in its actua l o pe rating e nviro nme nt.

Choosing Test Cases. To test a component, we c!hoose input d ata and condi- tions, a llow the compo ne nt to manipulate the data, and o bserve the o utput. We select the input so that the output demonstrates some thing about the beha vio r of the code. A test point o r test case is a particular choice o f input data to be used in testing a program. A test is a finite collection o f test cases. How do we choose test cases and de fine tests in o rde r to co nvince o urselves and our customers th at the program wo rks correctly, not o nly fo r the test cases, but for all input?

We begi n by de te rmining o ur test o bj ectives. The n, we select test cases and de fine a test designed to meet a specific obj ective. One objective may be to demo nstrate that aJI stateme nts execute prope rly. Ano ther m ay be to sh ow that every function per- formed by the code is done correctly. The o bjectives de termine how we classify tbe input in o rder to choose o ur test cases.

We can view the code as either closed box or o pen box, depending o n the test o bjec tives. If closed box, we supply the box with all possible input, and compare the out- put with wha t is expected according to the requiremen ts. H owever, if the code is viewed as an open box, we can examine the code's internal logic, using a ca re ful testing strategy.

Recall the example compo nent to calculate the roo ts of a quadratic equation. If o ur test o bjective is demonstrating that the code functions properl y, we might choose test cases where the coe fficients a, b, and c range through representative combinations o f negative numbe rs, positive numbe rs, and zero. Or we can select combina tions based on the rela tive sizes o f the coefficients:

• a is gre ate r than b, which is greate r than c • bis greate r than c, which is greater than a • c is greater than b, which is greater than a

and so on. Ho weve r, if we ackno wledge the code's inner wo rkings, we can see that the logic depe nds o n the value o f the discriminant, b2 - 4ac. The n, we ch oose test cases that represe nt whe n the discriminant is positi ve, negative, and zero. We ma y also include test cases fo r no nnume ric data . For exa mple, we may input the le tter ' F' as a coe fficie nt, to d ete rmine how the system reacts to some thing nonnume rk. Including the three nume ric cases, we have four mutually exclusive t ypes of test input .

422 Chapter 8 Testing the Programs

In this fashion, we use the test o bjective to help us separate t!he input into equiva- le nce classes. That is, the classes of data sh ould meet these criteria:

1. Eve ry possible input belongs to one of the classes. That is, the classes cover the e ntire se t of input data.

2. No input datum be longs to more than one class. That is, the classes are disjoint. 3. If the executing code demonstrates a fault when a particular class member is used

as input, then the same fault ca n be detected using any othe r member of the class as input. That is, ao y element of the class re presents all ele me nts of that class.

It is no t always easy or feasible to te U if the third restriction on th e classes can be met. We can loosen the third requirement so that if a data e lement belongs to a class and reveals a fault, then the probability is high that e very other elem ent in that class wiU re veal the same fault.

Closed-box testing suffers from unce rtainty about whether the test cases selected will uncove r a particular fault. On the other hand, open-box testing always admits the dange r of paying too much attention to the code's inte rnal processing. We may e nd up testing what the program does instead o f what it should do.

We can combine open- and closed-box testing to gene rate test data. First, by con- sidering the program as a closed box, we can use the program's external specifications to gene rate initial test cases. These cases should incorporate not only the expected input data, but also boundary conditions for the input and output, as well as several cases o f invalid data. For instance, if the compo ne nt is coded to expect a positive input va lue, we may include a test case for each of the following:

• a very la rge positive integer • a positive intege r • a positive, fixed-point decimal • a number greater than 0 but less than 1 • ze ro

• a negative number • a n onnumeric character

Some d ata a re purposely chose n to be impro pe r; we test with the m to check that the code ha ndles incorrect data gracefully.

Nex t, by viewing the program's internal structure, we add othe r cases. For exampl e, we can add test cases to test a ll branches and to exercise as many paths as pos- sible. If loops a re invo lved, we may include test cases that loop once, many times, and no t a t a ll. We can a lso e xamine the implementation o f algorithms. For instance, if the program does trigono me tric calculatio ns, we can include cases tha t test the extremities of the trigonometric functions, such as zero, 90, 180, 270, and 360 degrees. Or we may have input that causes a deno minator to be se t to zero.

Some times a system " re members" conditions from the previous case, so sequences o f test cases are neede d. For example, whe n a syste m imple ments a finite- state machine, the code must recall the previous syste m state; the previous state plus current input de te rmine the next state . Similarly, re al-time systems are o ften inte rrupt- driven; tests exercise se ts of cases rather than single ones.

Openmirrors.com

Section 8.3 Unit Testing 423

Test Thoroughness. To perform a test, we decide how to demonstrate in a con- vincing way that the test data exhibit aU possible behaviors. Le t us see what cho ices we have.

To test code thoroughly, we can choose test cases using at least one of several approaches based o n the data manipulated by the code:

• Statement testing: Eve ry statement in the component is e xecuted at least o nce in some test.

• Branch testing: For eve ry d ecision point in the code, each branch is chosen a t least once in some test.

• Path testing: Every distinct path through the code is executed at le ast o nce in some test.

• D efinition-use path testi ng: Every path from every definition of every variable to every use of that definition is exercised in some test.

• All-uses testing: The test set includes at least one path from every de finition to every use that can be reached by that definition.

• All-prcdkatc-uscs/somc-computational-uscs testing: For every variable and every defmition of that variable, a test includes at least one path from the definition to every predicate use; if there are definitions not covered by that description, then include computational uses so that every definition is covered.

• All-computational-uses/som e-predicate-uses testing: For e very variable and e very defmition of that variable, a test includes at least one path from the definition to every computatio nal use; if the re are definitions not covered by that descriptio n, then include pre dicate uses so that every definition is covered.

The re are othe r, similar kinds of testing, such as a ll-definiti ons, all-predicate -uses, and all-computational-uses. Beizer (1990) describes the re lative strengths of these test strategies, as shown in Figure 8.6. For example, testing all paths is stronger than testing all paths from de finition to use. In gene ral , the stronger the strategy, the mo re test cases

All eompuhtional/

soma predic1te uses

l All computational uses

All paths

~ All defln ition-qse paths

~ All QUS

/~ All predicate/ some computational 11111

\ I "' ··+" ""' Branch t All ~efl nit ions Statement

FIGURE 8.6 Relative stre ngths of test strategies (Beizer I 990).

424 Chapter 8 Testing the Programs

are invo lved ; we must always conside r the trade-off between the resources available for testing and the thoroughness o f the strategy we ch oose.

We are likely to do be tter with a strategy than with random testing. For example, Ntafos (1984) compared random testing with branch testing and all-uses testing on se ven mathe matical programs with known faults. He found th at random testing fo w1d 79.5% of the faults, bran ch testing found 85.5%, and all-uses testing found 90%.

To see how the strategy affects the number of test cases, consider the exampl.e in Figure 8.7, which illustrates the logic flow in a compone nt to be tested. Each state ment, represe nted by a diamond o r rectangle, has bee n numbered. Statem ent testing requires test cases that execute state me nts 1 through 7. B y choosing X larger than K that pro- duces a positive RESULT, we can execute statements

1-2-3-4-5-6-7

in o rder, so o ne test case suffices. Fo r branch testing, we must identify all the decision points, represented by dia -

mo nds 1n Figure 8.7. The re a re two decisions: one about the relatio nship of X to K , and anothe r about whether o r no t RESULT is positive . Two test cases will exercise paths

1-2-3-4-5-6-7

and

1-2-4-5-6-1

an<l trave rse each branc h at least once. The first path uses the yes branch of the first decision point, and the second uses the n.o branch. Likewise, the nrst path uses the yes branch o f the second decisio n point, a nd the secon d path uses the n o branch.

POINTER =FALSE 8 YES

POINTER= TRUE 0

X = X+l 8 CALL SUB (X, 0 PO INTER, RESULT)

YES

8 PRINT RESULT

FIGURE 8.7 Logic flow.

Openmirrors.com

Secti o n 8.3 Unit Testing 425

If we want to e xe rcise each possible pa th through the program, then we need mo re test cases. The pa ths

1-2-3-4-5-6-7 1-2-3-4-5-6-1 1-2-4-5-6-7 1-2-4-5-6-1

cover all the possibilities: two decisio n points with two choices at each branch. ln o ur example, sta te ment testing re quires fewer test cases th an branch testing,

which in turn re quires fe wer cases than path testing. This relationship is true in gene ral. Mo reover, the more comple x a program, the more path test cases required. Exercise 4 investigates the relationship between the structure and o rder of decision points and the number o f paths through the code .

The re are many o ther test strategies that can be e mployed during unit testing. For example, secure applicati ons a re o fte n tested by following e ach possible transaction to its end, employing a strategy called transaction flow testing. Fo r a thorough discussion o f testing strategy, see Beize r (1990).

Comparing Techniques

Jones (1991) has compared several types o f fault-discovery me thods to determine which o nes a re most Likely to find certain ca tegories of fa ults. Table 8.5 shows tbe results of his survey, o rganized by the development activity ge ne rating the fa uJt. For e xa mple, if a fault is located in the code but is the result o f a problem with the require- ments specificatio n, it is listed in the " requiieme nts" co lumn.

Jo nes (1991) a lso investigated whi ch ty pes. of re moval techniques we re best in ca tching which kinds o f fauJts. Ta ble 8.6 shows that reviews and inspecti ons were the

TABLE 8.5 Fault-Discovery Percentages by Fa ult Origin (Jones 1991)

D iscovery Technique Requirements Design Coding D ocumentation

Protot yping 40 35 35 15 Requirements review 40 15 0 5 Design review 15 55 0 15 Code inspection 20 40 65 25 Unit testing 5 20 0

TABLE 8.6 Effectiveness of FauJt-DiscoveryThchniques (Jones 1991)

Requirements D ocumentation Faults Design Faults Code Faults Faults

Reviews Fair Excellent Excellent G ood P rototypes Good Fair Fair Not applicable Testing Poor Poor Good Fair Correctness proofs Poor Poor Fa.iJ Fair

426 Chapter 8 Testing the Programs

SIDEBAR 8.4 FAULT-DISCOVERY EFFICIENCY AT CONTEL IPC

0 !sen (1993) describes the development of a 184,000-lines-of-code system using C, Objec-tive C, assembler, and scripts at a company that provided automated assistance to the financial community. H e tracked faults discovered during various activities and found diffe r-

ences: 17.3% of the faults we re found durin g inspections of the system design , 19.1 % during

component design inspection, 15.1 % during code inspection, 29.4% during integration test-

ing, and 16.6% during system and regression testing. Only 0.1 % of the faults were revealed

after the system was placed in the field. Thus, Olsen's work shows the importance of using dif-

ferent techniques to ferret out different kinds of faults during development; it is not enough

to rely on a single me thod for catching all problems.

most effective for discovering design and code problems, but that prototyping was best at identifying problems with re quirements. Sidebar 8.4 illustrates why it is best to u se a diverse set of techniques to discover faults.

8.4 INTEGRATION TESTING

When we are satisfied that individual components are working correctly and meet our objectives, we combine them into a working system. This integration is planned and coordinated so tha t whe n a fai lure occurs, we have some ide a of what ca used it. lo addi- tio n, the o rde r in which compo ne nts are teste d affects our choice of test cases and tools. Fo r large systems, some compo nents may be in the codin g phase, others may be in the unit-testing phase, and still o the r collections o f components may be tested together. Our test strategy explains why and bo w compo ne nts are combined to test the wo rking system. This strategy affects not o nl y the integrati on timing and coding order, but also the cost and thoroughness of the testing.

The syste m is again vie we d as a hierarchy of components, where each compon ent be lo ngs to a layer of the design. We can begin fro m the top and work our way down as we test, work from the bottom up, o r use a combination of these two approaches.

Bottom-Up Integration

O ne po pular approach for me rgi ng compone nts to test the larger system is called bottom-up testing. When this me thod is used, each compo nent at the lowest level of the system hje rarcby is tested individuall y first. The n, the next components to be tested are those th at call the p reviously tested o nes. lhis approach is follo wed repeatedly until all compo ne nts a re included in the testing. The bo tto m-up meth od is u seful when many of the low-leve l components a re general-purpose utility routines that are invoked often by o the rs, when the design is object-orie nted, or when tbe system is integrating a la rge number of stand-alone reused compo ne nts.

Fo r example, consider the compon ents and hierarchy in Figure 8.8. To test this system from the bo ttom up, we fust test the lo west level: E , F, and G. Because we h ave

Openmirrors.com

A

B c

Section 8.4 Integratio n Testing 427

FIGURE 8.8 Example component hierarchy.

no compone nts ready to caU these lowest-level progra ms, we write special code to aid the integration. A component driver is a routine that caUs a pa rticular component and passes a test case to it. The driver is n ot difficult to code, since it rarely requires comp lex p rocessing. Howeve r, care is tak en to be sure th at the dr iver's inte rface with the test compo ne nt is de fined prope rly. Some times, test data can be sup plied automatica ll y in a special-purpose langu age that fa cilitates defining the d ata.

In o ur exa mple, we need a component driver for each of E , F, and G. When we are satisfied that those three compon ents work correctly, we move to the next higher level. Unlike the lo west-leve l components, the next-level components are not tested sepa- rate ly. Instead, they a re combine d with the components t hey ca ll (which bave already been tested). In this case, we test B, E , and F together. If a problem occurs, we know that its cause is e ithe r in B o r in the inte rface between B an d E or B and F, since E and F functio ned properly on the ir own. Had we tested B, E, and F without h aving tested E a nd F sepa rate ly, we might no t have been able to isola te the problem's cause so easily.

SimiJa rly, we test D wi th G. Because C call s no othe r componen t, we test it by itse lf. Finally, we test aU compon ents together. Figure 8.9 shows the seque nce of tests a nd their de pende ncies.

A freque nt complaint a bout bo ttom-up testing in a functionally decomposed sys- tem is that the top -leve l compon ents are usually the mosll: important but the last to be tested . The top leve l d irects the m aj or system activities, whereas the bottom level often pe rfo rms the more mundane task s, such as input and o utput functions o r repetitive cal- cula tio ns. The to p leve ls are more general , whereas the lowe r levels are more specific.

FIGURE 8.9 Bottom-up testing.

428 Chapter 8 Testing the Programs

Thus, some develope rs feel that by testing the bo ttom levels first, the discovery of major faults is postponed until testing's e nd. Moreover, sometimes faults in the top levels reflect faults in design; obviously, these proble ms should be corrected as soon as pos- sible in deve lopment, rathe r than waiting until the very e nd. Ftnally, top-level compo- ne nts ofte n contro l or influe nce timing. It is difficult to test a system from the bottom up when much of the system 's processing depends o n timing.

On the other band, bottom-up testing is often the most sensible for object-oriented programs. Objects a re combined o ne at a time with obj ects or coUecti ons of objects that have been tested previously. Messages a re sent from one to another , and testing en sures that the obj ects react correctly.

Top-Down Integration

Many d evelo pers prefer to use a top-down approach, which in many ways is the reverse o f bo tto m-up. The top level, usually one controlling component, is tested by itself. Then , aU compo ne nts caUed by the tested component(s) are combine d and tested as a larger unit. This approach is reapplied until all compone nts are incorpo rated.

A component being tested may call another that is not yet tested, so we write a stub, a specia l-purpose program to simuJate the activity of the mis-sing component. The stub answers the calling seque nce and passes back output data that lets the testing pro- cess continue . Fo r example, if a component is called to calculate the next available address but that component is not yet tested, the n a stub for it may pass back a fixed address only to aUow testing to proceed. As with drivers, stubs n eed not be complex or logically comple te.

Figure 8.10 shows bow top-down testing works with our example system. Only the top compo nent, A, is tested by itsel ~ with stubs needed for B, C, and 0. O nce tested, it is combined with the next le vel, and A, B, C, and Dare tested together. Stubs may be needed for compone nts E , F, or G at this stage of testing. Finally, the entire system is tested.

If the lowest level of components p erforms the input and o utput opera lions, stubs for the m may be almost identical to the actual components they replace. Io this case, the integratio n sequence may be alte red so that input and o utp ut components are incorpora ted earlier in tbe testing seque nce.

M any o f the advantages o f top-do wn design and coding a lso apply to top-do wn testing. When functions in particular components h ave been localized by using top- down d esign, testing from the top down allows the test team to exe rcise o ne function at a time, following its command sequence fro m the highest levels of control do wn thro ugh appropriate compone nts. Thus, test cases can be defined in terms of the func- tio ns be ing exa mine d. Moreove r, any design faults or maj or questions about functio nal feasibiLity can be addressed at the beginnin g of testing instead o f the end.

Notice, too, that driver programs are not needed in top-down testing. On the other hand, writing stubs ca n be difficult, because they must allow all possible conditions to be

FIGURE 8.10 Top-down testing.

Openmirrors.com

Section 8.4 Integration Testing 429

tested. For e xample, suppose compone nt Z of a map-drawing system p erforms a calcula- tio n using latitude and lo ngitude o utput by compo nent Y. The design specification states that the output fro m Y is aJways in the northe rn hemisphere. Since Z calls Y, when Z is p art of a to p-down test, Y may no t yet be coded. If a stub is writte n to generate a number be twee n O and 180 to allow testing o f Z to contin ue, the stub must be changed if the design is changed to aUow southe rn hemispherical locations. That is, the stub is an impo rta nt part o f testing, and its correctness may affect the validity of a test.

A disadva ntage to top-down testing is the p ossibili ty that a very la rge number of stubs may be requi red. This situation can a rise whe n the lowest s.yste m level cont a ins many gene ral-purpose routines. One way to avoid this problem is to alter the strategy slightly. R athe r than incorpora te an entire level at a time, a modified top-down approach tests each level's components individua Uy before the me rger takes place. For instance, o ur sample system can be tested with the mo dified approach by first testing A , then testing B, C, and D, and then me rging the four for a test o f the first and second le ve ls. The n E , F, and Ga re tested by the mselves. Fina ll y, the e ntire syste m is combined fo r a test, as shown in Figure 8.11.

Testing each le ve l's components indi vidually introduces ano ther di fficulty. Both stubs and drivers a re needed fo r each compo nent, leading to much more coding and man y potential pro blems.

Big-Bang Integration

When aill compo ne nts a re tested in isolatio n, it is tempting to mix !l:hem together as. the tina l syste m a nd see if it works the lirst time. Myers (1979) calls this big-bang testing, a nd Figure 8.12 sho ws ho w it works on our example syste m. Many programmers use the big-bang a pproach fo r small systems, but it is no t practical fo r large ones. In fact, since bi g-bang testing has several disadvantages, it is not recommended for any syste m. First, it requires both stubs and drivers to test th e independent components. Second, because all compone nts a re me rged at o nce, it is difficul t to fin d the cause of any failure. Finally, inte rface faults cannot be distinguished easily from othe r types of fauJts.

FIGURE 8. 11 Modified top-down testing.

430 Chapter 8 Testing the Programs

FIGURE 8.12 Big-bang testing.

Sandwich Integration

Myers (1979) combines a top-down strategy with. a bottom-up one to fo rm a sandwich testing approach. The system is viewed as three Laye rs, just like a sandwich: the target laye r in the middle, the le vels above the targe t, and the levels below the target. A top- down approach is used in the top layer and a bo ttom-up one in the lowe r layer. Testing converges o n the targe t laye r, chosen on the basis of system characteristics and the structure of the compo nent hie rarch y. For example, if the bottom Layer contains many general-purpose utility programs, the target laye r may be the o ne above, in which lie most of the compo ne nts using the utilities. This approach allows b ottom-up testin g to ve rify the utilities' co rrectness at the beginning of testing. Theo stubs for utilities need not be writte n, since the actual utilities are available for use. Figure 8.13 depicts a p os- sible sandwich integration sequence for our example component hierarchy, where the target layer is the middle level, compo nents B, C, and D.

Sandwich testing allows integration testing to begin early in the testing process. It also combines the advantages o f top -do wn with bottom-up by testing control and u tili- ties from the very beginning. H oweve r, it does no t test the individual components thor- o ughly before integratio n. A variati on, modified sandwich testing, allows upper-le vel compo n ents to be tested befo re merging them with othe rs, as shown in Figure 8.14.

Comparison of Integration Strategies

Choosing an integra tion strategy depends not only on system characteristics, but al so on custome r e xpectations. For instance, the customer may want to see a working version as

Openmirrors.com

Section 8.4 Integ ratio n Testi ng 431

FIGURE 8.13 Sandwich testing.

FIGURE 8.14 Modified sandwich testing.

soon as possible, so we may adopt an integration schedule that produces a basic working system early in the testing process. In this way, some programmers are coding while others a re testing, so that the test and code stages can occur concurrently. Mye rs (1979) has composed a matrix.shown i.n TabEe 8.7, that compares the several testing strategies acco rd- ing to several system attributes and cus to mer needs. Sideba r 8.5 explains Microsoft's s trat- egy, driven by market pressures.

432 Chapter 8 Testing the Programs

TABLE 8.7 Comparison of Integration Strategies (Myers 1979)

Modified Modified Bottom-Up Top-Down Top-Down Big-Bang Sandwich Sandwich

Integration Early Early Early Late Early Early· llme to basic La.te Early Early Late Early Early

working program Component drivers Yes No Yes Yes Yes Yes

needed Stubs needed No Yes Yes Yes Yes Yes Work parallelism Medium Low Medium High Medium High

at beginning Ability to test Easy Hard Easy Easy Medium Easy

particular paths Ability to plan and Easy Hard Hard Easy Hard Hard

control sequence

SIDEBAR 8.5 BUILDS AT MICROSOFT

M icrosoft's integration strategy is market-driven, based on the need to have a workin g product as quickly as possihle (Cusumano and Selby 1995, 1997) . Tt uses many small, parallel teams (three to eight deve lopers each) implementing a "synch-and-stabilize" approach. The process iterates among designing, building, and testing components while involving customers in the testing process. All parts of a product are integrated frequently to determine what does and does not work.

The Microsoft approach allows the team to change the specification of features as the

developers learn more about what the product can and should do. Sometimes the feature set changes as much as 30% or more. The product and project are divided into parts, based ·on features, and different teams are responsible for different features. Then, milestones are

defined, determined by a partitioning of features into most critical, desirable, and least critical. The feature teams synchronize their work by building the product and by finding and fixing faults on a daily basis, as shown in Figure 8.15. Thus, the most important features

are developed and integrated first, and each milestone includes "buffer time" to handle unexpected complications or delays. If the schedule must be shortened, the least important features are cut from the product.

No matter what strategy is chosen, each component is merged o nl y once for testing. Furthermore, at no time sho uld a compo ne nt be modified to simplify testing. Stubs and drivers are separate, new programs, not temporary modifications of existing programs.

Openmirrors.com

Section 8.5 Testing Object-Oriented Systems 433

Milestone 1: Most critic1I features and shm~ components Design, code, prototype

Usability testint D1ily builds

Feature integration E limin1te seveM faults

Milestone 2: Desirable features Design, code, prototype

Usability testint Daily bui14s

Feature inte9r1tion

Milestone 3: Lent critical lutares Design, co,e, prototype

Unbility testing Dail¥ builds

Future inte5ration an4 completion Release to m1nuncturint

FIGURE 8.15 Microsoft syoch-and-stabilize approach.

S.5 TESTING OBJECT-ORIENTED SYSTEMS

Many o f the techniques we have described for testing systems apply to a ll ty pes of sys- te ms, including object-oriented ones. However, you shouJd take several additional steps to make sure that your object-oriented programs' characteristics have been addressed by your testing techniques.

Testing t he Cod e

Rumbaugh et al. (1991) propose that you begin testing object-oriented systems by ask- ing seve ral questions:

• Whe n your code expects a unique value, is there a path that generates a unique result?

• Whe n the re are many possible values, is there a way to select a unique resuJt? • Are the re use ful cases that are not handl ed?

Next, make sure that you check the objects and classes the mselves for excesses and deficiencies: missing objects, unnecessary classes, missing or unnecessa ry associa- tions, or incorrect placement of associations o r attributes. Rumbaugh et al. (1991) pro- vide some guidelines to he lp you identify these conditions during your testing. They note that objects might be missing if

• you find asymmetric associations or generalizations • you find disparate attributes and operations on a class

4 34 Chapter 8 Testing the Programs

• one class is playing two or more roles • an operatio n has n o good targe t class

• you find two associations with the same name and purpose

A class might be unnecessary if it has no attributes, operati ons., or associations. Sim- ilarly, an association might be unnecessary if it has redundant info rmation or if no opera- tions use a path. If role names are too broad or narrow for their placement, an association may be in the wrong place. Or if you need to access an object by one of its attribute values, you may h ave an incorrect placement of attributes. For each of these situations, Rumbaugh et al. (1991) suggest ways to change your design to reme dy these situatio ns.

Smith and Ro bson (1992) suggest that your testing should address many differ ent le vels: functions, classes, clusters (interacting groups of coUaborating objects), and the system as a whole. The traditio na l testing approaches apply well to functions, but many approaches do no t take into account the object states neede d to test classes. At a mini- mum, you sho uld develop tests that track an o bj ect's state and changes to that state. During your testing, beware o f concurrency and synchronizatio n problems, and make sure that corresponding events are complete and consistent.

Differences between Object-O riented and Traditional Testing

Perry and Kaiser (1990) ta ke a care ful look at testing object-oriented compone nts, especiaJly those that are re used from other appLications. The prope rties of object orien- tation a re o ften tho ught to he lp minimize testing, but that is n ot always the case. For exampl e, encapsulation isolates components that were developed separately. It is te mpting to think that if a programme r reuses some components without change, and reuses others but with s.ome changes, the n only the modified code needs to be tested. H owever, "a program that has been adequate ly tested in isolation may not be ade- qua tely tested in combinatio n" (Perry and Kaiser 1990). In fact, they show that when we add a new subclass o r modify an existing subclass, we must re test the me thods inher- ited fro m each of its ancesto r superclasses.

They also examine the adequacy of test cases. For procedural languages, we can use a set of test data to test a system; the n, whe n a change is made to the syste m, we can test tha t the change is correct a nd use the existing test data to ve ri fy th at the additional, remaining functionaLity js stiU the same. But Perry and Kaiser (1990) show that the situ- atio n is different for o bject-orie nted systems. When a subclass re pla ces an inhe rited me thod with a locaUy de fined method with the same name, the overriding subclass must be re tested, and probably with a different set of test data. H a rrold and McGregor (1989) d escribe a technique for using the test case history of an object-oriented system to minimize the amo unt of additi onal testing. They fust test base classes having no par- e nts; the test strategy is to test each functi on individu ally and the o test the inte racti ons among functions. Next, they provide an algorithm to update incrementally the test his- tory of the pare nt class; onl y attributes that are new o r are affected by the inheritance scheme are tested.

Graham (1996a) summarizes the differences between obj ect-oriented and tradi- tio nal testing in two ways. First, she notes which aspects of o bject orie ntation make testing easie r and which ma ke it harder. For example, o bj ects te nd to be sm aU, and the

Openmirrors.com

Section 8.5 Testing Object-Oriented Systems 435

Easier

Modularity

Sm1ll methods

lnterf1cu ident i(ied

Encapsul1tion Dynamic binding

Complex Interfaces

FIGURE 8.16 Easier and harder parts of testing object-oriented systems (Graham 1996a).

complexity that might ordinarily reside in the component is often pus hed instead toward the inte rfaces among components. This differe nce means that unit testing is less difficult, but integration testing must be much more extensive. As we ha ve seen, e ncap- sulation is ofte n considere d a positive attribute of object-oriented design , but it also requires mo re exte nsive integration testing.

Similarly, inhe ritance introduces the need for more testing. An inhe rited function needs additio nal testing if

• it is redefine d • it has a spe cific behavior in a de rived class • o the r func tio ns in that class are supposed to be consiste nt

Figure 8.16 de picts Graham's view of these diffe rences. Graham also looks at the steps in the testing process that are affecte d by o bject

orientation. The diagram in Figure 8.17 is a Kiviat or radar graph that compares the dif- fere nces betwee n o bject-orie nted and traditi onal testing. The gray polygon shows that

Requirements 1nalvsis and

val id1tion

Tut case 1eneration

Source code analysis

Plmin9 and min19ement

Covmge 1nalysis

Simulation and load testin9

Test execution

Test development

FIGURE 8.17 Significant aspects of the testing domain where object-oriented testing is diffe rent (Graham 1996a).

436 Chapter 8 Testing the Programs

requireme nts analysis and validation, test case generation, source code analysis, and cov- erage analysis require special treatme nt. The farther the gray line is out from the center of the d!iagram, the more the difference be tween object-oriented and traditional testing.

• R equireme nts are like ly to be expressed in the req uirements document, but there are few tools to s uppo rt validatio n of requireme nts expressed as objects and methods.

• Like wise, most tools that assist in test case gene ration are no t prepared to handle a model expressed in objects and me th ods.

• Most source code measure ments are define d for procedural code, not for o bj ects and me thods. Traditi onal metrics such as cyclomatic numbers are of little use when assessing the size and complexity of o bject-oriented systems. Over time, as researche rs propose and test useful object-oriented measure ments, this poin t of diffe re nce wiU diminish.

• Because it is the inte raction of obj ects that is the source of complexity, code cov- erage measurements and too ls are of less value in object-ori ented testing than in traditio nal testing.

8.6 TEST PLANNING

As we have seen, much is invo lved in testing components and integrating them to build a system. Care ful test planning helps us to design and organize the tests, so we are con - fident that we are testing appropriate ly and thoroughly.

Each step of the testing process must be planned. In foct, the test process has a life o f its o wn within the development cyc le, and it ca n proceed in parallel with many of the o ther developme nt activities. In particular, we must pla n each of these test steps:

1. establishing test o bjectives 2. designing test cases 3. writing test cases

4. testing test cases S. executing tests

6. evaluating test results

The test o bj ective tells us what kinds o f test cases to gene rate. Mo reover, the test case design is key to successful testing. If test cases are not representati ve and d o not tho ro ug Wy exe rcise the functions that de mon stra te tbe correctness and validity of the system, the n the remainde r of the testing process is useless.

Therefore, running a test begins with reviewing the test cases to verify that they are correct, feasib le, provide the desired degree of coverage, and de monstrate the desired function ality. Once these checks have been made, we can actually execute the tests.

Purpose of the Plan

We use a test plan to or ganize testing activities. The test plan ta!kes into account the test objectives and incorporates any scheduling mandated by the test strategy or the project deadlines. The system development life cycle requires several levels of testing,

Openmirrors.com

Section 8.6 Test Planning 437

beginning with unit and integration testing, and proceeding to d emonstrate the full syste m's functio nality. The test plan describes the way in which we will show our cus- tomers that the software works correctly (i.e., that the software is free of faults and pe rforms the functions as specified in the requirements). Thus, a test plan addresses no t o nJy unit and integra tio n testing, but also system testing. The plan is a guide to the entire testing activity. It explains wbo does the testing, why the tests are performed, how the tests are conduc ted , and whe n the tests are sche duJed.

To deve lop the test plan, we must know the re quire ments, functional specifica- tio ns, and moduJar hiera rch y of the syste m's design and code. As we develop each of these system eleme nts, we can apply what we kno w to choosing a test objective, de fin- ing a test strategy, and generating a se t of test cases. Consequently, the test plan is devel- oped as the system itse lf is developed.

Contents of t he Plan

A test plan begins witb the test objectives, addressing each type of testing from unit through functio nal to acceptance and installation testing. Thus, the system test plan is really a series o f test plans, one for each kind of test to be administe red. Next, the plan looks at how the tests will be run and what criteria will be used to determine whe n the testing is complete. Knowing whe n a test is over is not always easy. We have seen exa mples o f code where it is impossible or imprac tical to exercise every combination o f input data and conditions. By ch oosing a subset of all possible data, we admitte dly increase the like lihood that we will miss testing for a particular kind of fault.This tra de- off between compl ete ness and the re alities o f cost and time invo lves a compromise o f o ur o bj ectives. Late r in this chapter, we look at bow to estimate the number of faults le ft in the code, as well as ide ntifying fault-prone code.

Whe n the test team can recognize that a test obj ective has been met, we say that the test objectives are well -defined. It is then that we decide h ow to integrate the com- ponents into a working system. We consider statement, branch, and path cove rage at the compo nent leve l, as well as top-do wn, bo ttom-up, and othe r strategies at tbe inte - gratio n level. The resulting plan fo r merging the compo nents into a whole is some times called the system integration plan.

Fo r eac h stage of testing, the test pla n describes in detail the methods to be used to perfo rm each test. Fo r e xample, unit testing m ay be composed of informal walk - througbs o r formal inspections, fo ll owe d by analyzing the code structure and tben ana- lyzing the code's actual pe rformance. The plan notes any automate d support, including conditio ns necessa ry for tool use. This information helps the test te am plan its activities and schedule the tests.

A de tailed list o f test cases accompanies e ach test me thod or technique. The plan also explains bow test data will be gene rated and bow any output data or state informa - tion wil!I be captured. lf a database is used to track tests, data , and output, the database and its use are a lso described.

Thus, as we read the test plan, we have a complete picture of h ow and why tes ting will be performed. By writing the test plan as we design the syste m, we are forced to unde rstand the syste m's overall goals. Jn fact, some times the testing perspective encour- ages us to questi on the nature of the problem and tbe appropriateness of the design.

438 Chapter 8 Testing the Programs

Many customers specify the test plan's contents in the requirements documenta- tion. For example, the U.S. D epartment of Defe nse provides a developer with automated data systems documentation standards when a system is being built. The standards explain tbat the test plan

is a tool for directing the ... testing, and contains the orderly schedule of events and list of materials necessary to effect a comprehensive test of a complete [automated data system]. Those parts of the document directed toward the staff personnel shall be presente d in no ntechnical language and those parts of the document directed toward the operations personnel shall be presented in suitable tenninology. (Department of Defense 1977)

We investigate the details of this test plan example in Chapte r 9.

8.7 AUTOMATED TESTING TOOLS

There are many automated tools to he lp us test code components, and we have m en- tio ned several in this chapte r, such as automated theore m prove rs and symbolic execu- tion tools. But in ge ne ral, there are several places in the testing process where tools are useful, if not essential.

Code Analysis Tools

'There are two categories of code analysis tools. Static analysis is performed whe n the program is not actually exec uting; dynam ic analysis is done whe n the program is run- ning. Each type o f tool reports back information about the code itse lf or the test case that is being run.

Static Analysis. Several tools can analyze a source program before it is run. Tools that investiga te the correctness of a program or set of components can be grouped into four types:

1. Code analyzer: The components are evaluated automatically for proper syntax . Statements can be higWighted if the syntax is wrong, if a construction is fault- prone, or if an ite m has no t been defined.

2. Stru<.1ure checker: This tool gene rates a graph fro m the components submitte d as input. The graph depicts the logic flow, and the tool checks for structural ftaws.

3. Data analyze r: The tool reviews the data structures, data declarations, and com- ponent interfaces, and then notes imprope r linkage among components, conflict- ing data definitions, and illegal data usage.

4. Seque nce checker: The tool checks seque nces of events; if coded in the wrong seque nce, the eve nts a re highlighte d.

For example, a code analyzer can generate a symbol table to record where a variable is first de fined and when it is used, supporting test strategies such as d efinition -use testing. Similarly, a structure checke r can re ad a progra m and dete rmine the location o!f all loops, mark stateme nts that are neve r executed, note the presen ce of branches from the middle of a loop, and so on. A data analyzer can notify us when a denominator may be set to zero; it can also check to see whether subroutine arguments are passed properly.

Openmirrors.com

Section 8.7 Automated Testing Tools 439

The input and o utput compone nts of a system may be submitted to a sequence checker to de termine if the events a re coded in the proper sequen ce. For example, a sequence checker can e nsure that all files are opened before they are modified.

Measurements and structural characteristics are included in the output from many static anaJysis tools, so that we have a better unde rstanding of the program's attributes. For example, flow graphs are often supplemented with a listing of aU possible paths through the program, aUowing us to plan test cases for path testing. We a re also supplied with information about fan-in and fan-out, the numbe r of operators and operands in a p rogram, the number of decision po ints, and several measures of the code's structural complexity. In Figure 8.18, we see an example of output from a static analysis program, comparing the findings for a particular piece of code with a large database of historical information. The comparison involves not only measurements such as depth of nesting, coupling, and number of decisions but also information about potentiaJ faults and unini- tiated variables. Depictions like this one tell us how easy testing is likely to be and warn us about possible faults that we may want to fix before formal tests are run.

Dynamic A nalysis. Many times, systems are difficult to test because several par- allel operations are being performed concurrently. This situation is especiaUy true for real-time systems. In these cases, it is difficult to anticipate conditions and generate rep- rese ntative test cases. Automate d tools enable the test t ea m to cap ture the state o f eve nts during the executio n of a program by preserving a "snapshot" of conditio ns. These tools are sometimes caUed program mo nitors because they watch and report the program's behavior.

A mo nito r can list the number of times a compo nent is call ed o r a line of code is executed. These statistics tell testers about the stateme nt o r path coverage of the ir test cases. Similarly, a monitor can re po rt on whe ther a decision point bas branched in all direc tions, thus providing info rmatio n about branch coverage. Summary statistics are also reported, providing a high-level view of the percentage of statements, paths, and branches that have been covered by the coUective set of test cases run. This information is important when test objecUves are stated in terms of coverage; for example, the Lo ndon air traffic control system was required by contract to have 100% state ment coverage in its testing (Pfteeger and Hatton 1997).

lnline fault$

Internee faults

Nesting

Pat~$

Uninitiated variables

External coupling

Bad

I

I I I

I

I

I

Average Good

FIGURE 8. 18 Output from static analysis.

440 Chapter 8 Testing the Programs

Additional information may help the test te am evaluate the system's p erfor- ma nce. Statistics can be gene rated about particular variables: their first va lue, last va lue, minimum, and maximum, fo r example. Breakpoints can be defined within the system so tha t when a variable attains or exceeds a certain value, the test tool rep orts the occur- re nce. Some tools stop when breakpo ints are reached , a llowin g the teste r to examine the contents of memo ry or values of specific da ta ite ms; sometimes it is possible to change values as the test progresses.

Fo r real-time syste ms, capturing as much informa tion as possible about a par- ticula r sta te or condition during execution can be used after executi on to provide addi- tio nal information a bout the test. Control flow can be traced backward or forward from a breakpo int, and the test tea m can e xamine accompanying data changes.

Test Execution Tools

The tools we have descri bed so far have focused on the code. Other tools can be use d to automate the planning and running of the tests themse lves. Given the size and com- plexity of most syste ms today, automated test executio n tools are essential fo r handling the very large number of test cases that must be run to test a system thoroughly.

Ca pture and Re pl ay. When tests are planned , the test team must specify in a test case what input will be provided and what o utcome is expected fro m the actions being tested. Ca pture-and-re play o r ca pture-and-playback tools capture the key- strokes, input, and responses as tests are being run, and the tools compare expected with actual o utcome. Ojscre pancies a re re porte d to the te am, and the ca ptured data he lp the te am trace the discre pancy back to its root cause. This type of tool is especially use ful afte r a fa ult has been fo und and fixed; it can be used to ve ri fy that the fix has cor- rected the fault witho ut introducing o ther faults into the code.

Stubs and Drive rs. We noted earlier the importance of stubs and drivers in inte- gratio n testing. Comme rcial tools are availab le to assist you in generating stubs and drivers automatically. But test drivers can be broader than simply a program to exercise a particular compo ne nt. The drive r can

1. se t a ll appropriate state variables to prepare for a given test case, and then run the test case

2. simulate keyboard input and other data-rela ted responses to conditi ons

3. compare actual outcome to expected outcome and report rufferences 4. track which paths have been trave rsed during executi on 5. reset variables to prepare fo r the nex t test case 6. interact with a de bugging package, so that faults ca o be traced and fixed during

testing, if so desired

A utomated Testing Environme nts. Test executio n tools can be integrated with o ther tools to form a compre hensive testing e nvironment. Often, the tools we describe here are connected to a testing database, measurement tools, cod e analysis tools, text edito rs, and simulation a nd modeling tools to automate as much of the test process as

Openmirrors.com

Section 8.8 When to Stop Testing 441

possible. For example, databases can track test cases, storing the input data for each test case, describing the expecte d output, and record ing the actual output. Ho we ve r, finding evidence of a fault is not the same as locating the fa ult. Testing will always involve the manual effort required to trace a proble m back to its root cause; tbe automation assists but does not replace this necessarily human fllJlctio n.

Test Case Gene rators

Testing depends on careful, thorough de finitio n of test cases. Fo r this reason, it is useful to auto ma te part of the test case generation pro cess, so that we can be sure that our cases cove r au possible situations. The re a re seve ral types of tools to he lp us with this jo b. Structura l test case generators b ase their tes t cases on the structure of the source code. They list test cases for path, branch , o r statement testing, and they often incl.ude h euristics to help us get the best coverage.

Othe r test case generators are based o n data flow, funcLionaJ testing (i.e., on exer- cising a u possible states that affect the completio n of a given function), or the state of each variable in the input domain. Other tools a re available to gene rate random sets of test data , used mostly to support re liability mode Eing (as we will see in C hapter 9).

8.8 WHEN TO STOP TESTIN G

We note d in e arlier chapters that software q uality can be measured in many ways. One way to assess the "goodness" of a component is by the number of faults it contains. It seems natural to assume that software faults that are the most dif.ficult to find are .also the most difficult to correct. It also seems reasonable to believe that the most easily fixed faults a re detected when the code is first exa mined , and the more difficult fa ults are located later in the testing process. However, Shooman and Bolsk y (1975) found th at this is not the case. Sometimes it takes a great deal of time to find trivial faults, and many such p roble ms are overl ooked or do not appear until we ll into the testing process. More- over, Myers (1979) reports tbat as the numbe r o f d etected fau lts inc re ases, the probabil- ity o f the existence of mo re undetected faults incre ases, as shown in Figure 8.19. If the re are many faults in a component, we want to find them as early as possible in the tes ting process. However, the graph shows us that if we find a large number of faults at the beginning, the n we are likely sLill to have a large numbe r undetecte d.

Probability of existence of ad4itiona I

faults

Number of fa~lts founi to 4ate

FIGURE 8.19 Probability of finding faults during development.

442 Chapter 8 Testing the Programs

In addition to being contrary to our intuitio n, these results also make it difficuJt to kno w whe n to stop loo king fo r faults durin g testing. We must estimate the numbe r of remaining faults, no t onJy to know whe n to stop o ur search for more faults, but also to give us some degree of confide nce in the code we are producing. The number of faults also indicates the like ly mainte nance effo rt neede d if faulrs are le ft to be detected after the system is delivered.

Fault Seeding

MiUs (1972) developed a technique known as fa ult seeding or error seeding to estimate the number o f faults in a program. The basic pre mise is that one member of the test team intentionally inserts (or "seeds") a known number o f fa ults in a p rogram. Then, the o the r team members locate as m any faults as possible . The number of undiscove red seede d faults acts as an indicator of the numbe r of to tal faults (including indigen ous, no nseeded ones) re mainin g in the program. That is, the ratio o f seeded faults de tected to to ta l seeded faults should be the same as the ratio of nonseede d faults detected to to tal no nseeded faults:

detecte d seeded faults de tected n onseeded faults to tal seeded faults to tal nonseeded faults

Thus, if a program is seeded with 100 faults and the test te am finds only 70, it is likely tha t 30% of the indige no us faults remain in the code.

\.Ve can express this ratio more fo rmally. Le t S be the number of seeded fa ults placed in a program, and le t N be the numbe r o f indigenous (no nseeded ) faults. If n is the actual number o f no nseeded faults detected during testing, and s is the numbe r of seeded faults de tected during testing, then an estimate of the tota l number of indige- no us faults is

N = Sn/ s

Altho ugh simple and use ful , this approach assumes that the seeded faults are of the same kind and complex ity as the actual faults in the program. But we do n ot know what the typical faults are be fore we have found them, so it is difficult to make the seede d faults representa tive o f the actual ones. O ne way to increase the likelihood of represe ntative ness is to base the seede d faults on histori cal records for code from simi- lar past projects. H owever, this approach is useful only when we have built like syste ms before. And as we po inted o ut in Chapter 2, things that seem similar may in fact be quite diffe re nt in ways of which we are n ot always aware.

To overcome this obstacle, we can use two independent test groups to test the same program. Call the m Test G roup 1 and Test Group 2. Let x be the number of faults de tecte d by Test Group 1 and y the number detecte d by Test Group 2. Some faults will be de tected by bo th groups; ca ll this numbe r of faults q, so that q :s: x and q ::;; y. Finally, le t n be the tota l number o f all faults in the program ; we wa nt to estimate n .

The effectiveness of each group's testing can be measured by calculating the frac- tio n o f faults found by each group. Thus, the e ffectiveness E 1 of Group 1 can be expressed as

E1 = x/n

Openmirrors.com

Section 8.8 When to Stop Testing 443

and the effective ness E2 of Group 2 as

E2 = y/n

The group effectiveness measures the group's ability to detect faults from among a se t of existing faults. Thus, if a group can find half of all the faults in a program, its effective ness is 0.5. Consider the faults detected by both Group 1 and Group 2. If we assume that Group 1 is just as e ffective at finding faults in any part of the program as in any othe r part, we can look at the ratio of faults found by Group 1 from the set of faults found by Group 2. That is, Group 1 found q of they faults that Group 2 found, so Group l 's effectiveness is qty. In other words,

E 1 = x/n = q/y Howeve r, we know that E 2 is yin, so we can derive the following formula for n.:

n = q/( E1 *E2)

We have a known value for q, and we can use estimates of qty for E 1 and q!x for E 2 , so we have e no ugh information to estimate n.

To see ho w this method works, suppose two groups test a program. Group l finds 25 faults. Group 2 finds 30 faults, and 15 of those are duplicates of the faults found by Group 1. Thus, we have

x = 25 y = 30

q = 15 The estimate, E i, of Group l's effective ness is qty , or 0.5, since G ro up 1 found 15 of the 30 faults found by Group 2. Similarly, the estimate, E 2, o f Group 2's effectiveness is qlx, or 0.6. Thus, our estimate of n, the total number of faults in the program, is 15/(0.5*0.6), or 50 faults.

The test strategy d efined in the test plan directs the test team in deciding when to stop testing. The strategy can use this estimating technique to decide when testing is complete.

Confidence in the Software

We can use fault estimates to te U us how much confidence we can place in the software we are testing. Confidence, usually expressed as a p e rcentage, tells us the Ukelihood that the software is fault-free. Thus, if we say that a program is fault-free with a 95% level of confidence, then we mean that the probability that the software has no faults is 0.95.

Suppose we have seeded a program with S faults, and we claim that the code has o nly N actual faults. We test the program until we have found alJ S of the seeded faults. If, as before, n is the number of actual faults discove red during testing, then the confi- de nce level can be calcuJated as

{ - 1

C = S/(S - N + 1) ifn > N ifn s N

444 Chapter 8 Testing the Programs

Fo r exa mple, suppose we claim that a component is fault-free, mea ning that N is zero. If we seed the code with 10 faults and find all 10 without uncovering an indigenous fault, then we can calculate the confidence level with S = 10 and N = 0. Thus, C is 10/11, for a confiden ce level o f 91 % . If the requirements or contract mandates a confidence level o f 98%, we would need to seed S faults, whe re S / (S - O + 1) = 98/100. Solving this equation, we see that we must use 49 seeded faults and continue testing until all 49 faults are fo und (but no indigenous fauJts discove red).

This approach prese nts a maj o r proble m: We cannot pre dict the level of confi - de nce until a ll seeded faults are detected. Richards (1974) suggests a modifica lion, where the confide nce level can be estimated using the number of detected seeded faults, whe the r or no t all have been located. In this case, C is

c{ : I( S ) ; ( S + N + 1 ) s- 1 N+s

ifn > N

ifn ::;; N

These estimates assume that all faults have an equal probability of being de tecte d, which is not likely to be true. However, many other estimates take these fac- to rs into account. Such estimation techniques not only give us some idea of the confi- de nce we may have in our programs but also provjde a side benefit. Many programmers are tempted to conclude that each fault discovered is the last one . If we estimate the number of faults re maining, or i[ we know how many faults we must find to satisfy a confide nce require ment , we have ince ntive to keep testing for o ne more fault.

These techniques a re a lso useful in assessing confide nce in compo nents that are about to be reused. We can loo k at the fault history of a compo ne nt, especially if fault seeding bas take n place, and use techniques such as these to decide bow much confi- dence to place in re using the component without testing it again. Or we can seed the compo n ent and use these techniques to establish a baseline leve l o f confide nce.

Other Stopping Crite ria

The test strategy itse lf can be used to se t sto pping criteria for testing. For example, when we are doing stateme nt, path, or branch testing, we can track how many state- me nts, paths, or branches need to be executed and dete rmine our test progress in te rms of the numbe r of stateme nts, paths, o r branches left to test.

Many automated tools ca lculate these coverage values for us. Consider this code from Lee and Tepfe nbart (1997) to imp lement a computer game :

LISTING BRANCH

void Col l is i on: : moveBall(Ball *ball)

ball - >chang.e_position(final_l oc) ,upperLeft());

int sf = 1; //speed factor

Openmirrors.com

STATEMENT NUMBER

1

2

3

4

5

Section 8.8 When to Stop Testing 445

for(int i = O; i <number_hit (); i++ )

obstacle *hitptr=

(obstacle*) obj ( i) ->real_identity();

sf*= hitpte->respond_to_being_hit(this);

Point v = r ebound(ball ->g e t _ve locity ());

if(v.X() == 0 )

v.X(l); if (v.Y() == 0

v. Y( -1 ) ;

ball->change_velocity(sf*v);

1 - 2 6

3 - 4

5 - 6

7

B

9

10 11

12

13

14 15

16

17 18

A tool may add to the listing a no tati on about whe re the branches are, as shown. Thus, branch 1 is the path take n whe n i is within the loop parame ters in stateme nt 6, branch 2 is the path taken when i is no t in the loop parameters, branch 3 is the path taken when v. X is zero in sta tement 13, branch 4 is the path taken when v. X is not zero, an d so o n. Ao auto mated tool can calculate au of the paths to be covered by tests; in this case, there are 23, or 8, possibilities. The n, as testing progresses, the tool may pro- duce a report like the ones in Tables 8.8 and 8.9, so we see how many paths are le ft to trave rse in order to have path or branch coverage.

Identifying Fault-Prone Code

The re a re many techniques used to he lp identify fault-prone code, based on past hist ory of faults in similar applications. For exa mple, some researchers track the numbe r of faults found in each compone nt during developme nt and mainte nance. They also collect measurements about each component, such as size, number of decisions, numbe r of operato rs and operands, or numbe r of modifications. The n, they generate equations to

TABLE 8.8 Summary of Path Traversals

ThisTust Cumulative

Test Number Paths % Pa tbs % Case of Paths Invocation Traversed Coverage Invocation Traversed Coverage

6 8 4 50 5 6 75

TABLE 8.9 Paths Not Executed

Test Case Pa tbs Missed Total

6 1234 4

446 Chapter 8 Testing the Programs

FIGURE 8.20 Classification tree to identify fault-prone components.

suggest tbe attributes of the most fault-prone compone nts. These equations can be used to suggest which of your components sbould be tested first, or whicb should be given extra scrutiny during reviews o r testing.

Porte r and Selby (1990) suggest tbe use o f classification trees to identify fault- prone components. Classifica tion tree analysis is a statistical technique that sorts thro ugh large arrays of measureme nt information, creating a decision tree to sh ow which measurements arc the best predictors o f a particular attribute. Fo r instance, sup- pose we collect measure ment data about each compone nt built in our organization. We include size (in lines of code), numbe r of distinct paths through the code, number of opera to rs, de ptb of nesting, degree of coupling and cohesion (rated on a sca le from 1 as lowest llo 5 as bighest), time to code the component, number of faults found in the com- po ne nt, and mo re. We use a classification tree analysis tool to analyze the attributes of the co mpo nents that bad five or more faults, compared with tbose tbat had fewer than five fa ults. The result may be a decisio n tree like the one in Figure 8.20.

The tree is used to he lp us decide which compo nents in our curre nt system are like ly to have a la rge number of fa ults. According to the tree, if a component has be tween 100 and 300 lines of code and has at least 15 decisions, then it may be fault- prone. Or if the component has over 300 lines of code, has not had a design review, and has been changed at least five times, then il, too, may be fault-prone. We can use tbis type of analysis to he lp us target our testing when testing resources are Limited. Or we can sch ed ule inspectio ns fo r such components, to help catch problems before testing begins.

8.9 INFORMATION SYSTEM S EXAMPLE

Suppose we are generating test cases to test tbe Piccadilly system 's compo nents, and we choose a test strategy that plans to exercise eve ry path in a compo nent. We ma y decide to write test sc ripts that describe an input and an expected outcome, and the test pro- cess will involve comparing the actual o utcome with the expecte d outcome for e ach

Openmirrors.com

Section 8.10 Real-Time Example 447

test case. If the actual outcome is indeed equal to the expected outcome, does that mean tbe co mpone nt is fault-free? Not really. We may have what Beize r (1990) c alls coincidental correctness in the component. To understand why, consider a component that has the following structure :

CAS E 1: Y : = X/3 ;

CASE 2 : Y := 2X - 25;

CAS E 3 : Y := X MOD 1 0 ;

ENDCASE;

If our test case uses 15 as the input for x, expects 5 as the output for Y, and actually yields Y equal to 5, we d o no t know which path was exercised; eve ry case produces a Y o f 5 fo r an x o f 15! For this reason, test cases must be suppleme nte d with markers that help the test team to ide ntif}' which path is actually taken by tbe code. In tbis example, a path cove rage tool would be ve ry use ful in tracking exactly which statements are exer- cised whe n each test case is run.

Because the Piccadilly syste m is an informa tion system, we may in fact pre fe r to use a data-flow testing s trategy rathe r than a structural one. We can identify each data eleme nt easily by using the data dictionary and then consider possible values for e ach. Strategies such as definition-use testing may be the most appropriate; we follow e ach data ite m through a component, looking for situations where the value of the data ele - ment can change, and ve riiying that the change is correct. Such testing can be sup- po rted by many auto ma ted tools: database re positories, test case generators, and test e xecution mo nitors that note each change in a ualum 's value. In fact, our test team may want to link the database that contains the data dictionary with other tools.

8.10 REAL-TIME EXAMPLE

The Ariane-5 syste m underwe nt a great deal o f re view and testing. A ccording to Lions e t al. (1996), the flight control system was tested in four ways:

L equipment testing 2. on-board compute r software testing

3. staged integra tion 4. syste m validatio n tests

The ove rall philosophy o f the Ariane -5 testing was to check at e ach le vel what could no t be achieved a t the previo us level. In this way, the deve lopers hope d to provide com - plete test cove rage o f each subsystem and of the integra ted system. Let us look at the poste xplosio n investiga ti on to see why the testing during soft ware quaLification did not discove r the SRI proble ms be fo re the actual f'light. (We will examine the integration and vaJidation tests in C hapte r 9.)

The investigators reporte d that " no test was performed to ve rify that the SRI wo uld behave correctly when being subjecte d to the count-down and flight time seque nce a nd the trajecto ry o f Ariane-5" (Lions et al. 1996). ln fact , the specificati on for the SRI software did no t contain the Ariane-5 trajectory data among its functional requirem ents. In o the r words, there was no discussion in the requirements documents

448 Chapter 8 Testing the Programs

o f the ways in wbich the Ariane-5 trajectory wo uld be diffe re nt from Ariane-4. The investigato rs no te d that "Such a declaration o f Limitatio n, which should be mandatory fo r every missio n-critical device, would have serve d to identify any non-compliance with the trajectory of Ariane-5."

Because the roo t ca use is in the require me nts, it could have been noticed quite early during the deve lopment process. Indeed , re views were an integral p art of the design and coding activities, and the investigators point out that they we re "carried out at a ll levels a nd invo lved all major p artne rs in the project (as we ll as exte rn al experts)." They conclude d th at

... it is evident that the limitations of the SRI software were not fully analyzed in the re views, and it was not realized that the test coverage was inadequate to expose such limi- tations. Nor were the possible implications of allowing the alignment software to operate during flight realized. In these respects, the review process was a contributory factor in the failure. (Lions et al.1996)

Thus, the Ariane-5 develope rs relied on insufficient reviews and test coverage, giving them a false sense o f confidence in the software.

There are seve ral ways to improve the like Libood that reviews and test cover age are complete. One is to invo lve a n onexpert in the review process. Such a p articipant will question many of tbe assumptions that o ther revie wers take for granted---0ften wrongly. Anothe r is to examine tbe completeness of test cases, either by asking an exte rnal partic- ipant to review the m o r by using a formal technique to assess the degree o f coverage. As we will see in Chapte r 9, the Ariane-5 developers had several other opportunities to find the SRI proble m during testing, but it slipped through their safety n et.

8.11 WHAT THIS CHAPTER MEANS FOR YOU

This chapter describes many techniques that you can u se to test your code compone nts individually and as they are integrated with those of your colle agues. It is importa nt for you to unde rstand the diffe re nce be tween a fault (a problem in the require me nts, design, code, docume nta tion, or test cases) and a failure (a pro ble m in the functioning of the system). Testing looks for faults, sometimes by forcing code to fail and then seek - ing the root cause. Unit testing is the developme nt activity th at exercises each compo- ne nt sepa ra te ly; integrati on testing puts compo nents together in an organized way to he lp you isola te faults as the combined components are tested together.

The goal of testing is to find faults, not to prove correctness. Indeed , the absence o f fa ults does not guarantee correctness. There ar e many manual and automated tech - niques to he lp you find faults in your code, as well as testing tools to show yo u bow much has been tested a nd whe n to stop testing.

8 .12 WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM

Testing is bo th an individual and a group activity. Once a compo nent is written, it can be inspected by some o r all o f the deve lopment team to look for faul ts that were not apparent to the pe rson who wrote it. The research Literature cle arly sbows that inspec- tio ns are very e ffec tive at finding faults e arly in the de velopme nt process. But it is

Openmirrors.com

Section 8.15 Key References 449

equally clear that other techniques find faults that inspectio ns often miss. So it is impo rtant for you to work with your team in an egoless way, using the many methods at your disposal, to find faults as early as possible during development.

Integration testing is a team activity, too, and you must coordinate with other te am membe rs in choosing a n integration strategy, planning your tests, generating test cases, and running the tests. Automated tools are useful in these activities, and they help you and your teammates scrutinize the test resu lts to identify problems and their causes.

8. 13 WHAT THIS CHAPTER MEANS FOR RESEAR CHERS

R esearc he rs continue to investigate a large number of important issues associated with testing:

• Inspectio ns are e ffective, but the y can be made mo re e ffective in a variety o f ways. Researche rs are looking at the best ways to choose inspecti on te am me mbe rs, to review developme nt artifacts, and to interact in group meetings to find as many faults as possible. Some researchers are comparing the use o f the group mee ting to lack of a gro up meeting, to see what a group meeting really accomplishes.

• Researchers continue to try to understand whi ch techniques are best at finding what kinds of faults.

• The systems we are building are far more complicated and far larger than the sys- te ms built even just a few years ago. Thus, it is becoming more and more impor - tant to have automated tools to support our testing. Researchers are lookin g at ways to de fine test cases, track tests, and assess coverage completeness, and at the role o f automation in these activities.

• Testing resources are usuall y limite d, especially by schedules for market-driven products. Researchers continue to seek ways to identify fault-prone compone nts, so that testing can be targe ted at those first. SimiJarly, for safety-critical systems, researche rs a re bllilding models and tools to ensure that the most critical compo- ne nts are tested thoroughly.

8. 14 TERM PROJECT

The Loan Arrange r requires a great deal of testing. Because tbe system is important to the econ omic health o f the FCO, the custome r wants the softwa re delive red as soon as possible . D evise a test s trategy that tests the Loan Arranger bul uses a minimum o f resources. Justify your strategy, and e xplain how you will know whe n to sto p testing and turn over the system to the customer.

8.15 KEY REFERENCES

Testing has been the subject of several special issu es of journals and magazines, includ- ing the March 1991 issue of IEEE Software and the June 1988 issue of Communications

450 Chapter 8 Testing the Programs

of the ACM. The September 1994 issue of Communications of the ACM discusses s pecia l consideratio ns in testing obj ect-ori ented syste ms. And the January/February 2000 issue of I EEE Software addresses why testing is so hard. In addition, IEEE Trans- actions on Software Engineering often bas articles that compare different testing tech- niques in terms of the kinds of faults they fLOd.

There are several good books that describe testing in great detail. Myers (1979) is the classic text, describing tbe philosophy of testing as we ll as several specific tech- niques. Be i.ze r (1990) offers a good ove rview of testing considerations a nd techniques, with many refe rences to key papers in the field. His 1995 book focu ses parti cula rly on black-box testing. Hetzel (1984) is also a use ful refe rence, as are Perry (1995), Kit (1995) , and Kane r, Falk, and Nguyen (1993). Binde r (2000) is a comprehe nsive guide to testing o bject-oriented syste ms.

There are many good papers describing the use of inspectio ns, including We ller (1993 and 1994) and Grady and van Slack (1994). Gilb a nd Graham's book (1993) on inspectio ns is a good, compre hensive, and prac tical guide. R esearchers continue to refine inspectio n techniques, and to expand the m to other process artifacts such as require me nts. For examples o f this work, see Po rter e t al. (1998) and Shull, Rus, and Basili (2000).

There are many automated testing tools available for you to use with your p ro- gra ms. Software Quality Engineering provides a variety of resources o n its Web page, and publishes an e lectronic newslette r, StickyMinds, with information about tbe latest testing tools. It also o rganizes several annual conferences, including STA R (Software Testing, Analysis and Re view) on the East Coast o f the U.S. and STARWest on the West Coast. [nformation about particular tools ca n be found at vendor Web sites, such as C igita l a nd Ra tio nal Softwa re. The Ogi tal site also contains a database of testing resources. Fewster and G raham's (1999) book discusses the issues invo lved in software test automation.

Other testing-related con fe rences sponsored by the IEEE Computer Society and the AC M are described at the ir Web sites. In addition, the America n Society for Quality runs a n annual World Congress for Software Quality, where testing and quality control are the key issues discussed.

8.16 EXERCISES

1. Examine the fault categories in Hewlett-Packard's classification scheme, shown in Figure 8.1. Is this an orthogonal classification? If not, explain why, and suggest ways to make it orthogonal.

2. Let P be a program component that reads a list of N records and a range condition on the record key. The fi rst seven characters of the record fonn the record key. P reads the key and produces an output file that contains only those records whose key falls in the prescribed range. For example, if the range is "JONES" to "SMITH," then the output file consists of all records whose keys are lexicographically between "JONES" and " SMITH." Write the input and output conditions as assertions to be used in provin g P correct. Write a flow diagram of what P's logical flow might be and identify the transfor- mation points.

Openmirrors.com

Section 8.16 Exercises 451

3. Complete the proof of the example in the text illustrated by Figure 8.5. In other words, write assertions to correspond to the flow diagram. Then, find the pa ths fro m input condi- tion to output. Prove that the paths are theorems.

4. Suppose a program contains N decision points, each of which has two branches. H ow many test cases are needed to perform path testing on such a program? If there are M choices at each decision point, how many test cases are needed for pa th test ing? Can the program's structure reduce this number? Give an example to suppo rt your answer.

5. Consider a program How diagram as a directed graph in which the diamonds and boxes of the program a re nodes, and the logic How arrows between them a re di.reeled edges. For e xample, the program in Figure 8.7 can be graphed as shown in Figu.re 8.21. Prove that statement testing of a program is equivalent to finding a path in the graph tha t contains all nodes of the g raph. Prove that branch testing is equiva le nt to finding the set of paths whose union covers the edges. Finally, prove that path testill!g is equivalent to finding all possible paths through the graph.

6. Programmable problem: Write a program that accepts as input the nodes and e dges of a directed graph and prints as output all possible paths through the graph. What are the major design considerations for you.r program? H ow does the complexity of the graph (in terms of number of branches and cycles) affect the a lgorithm you use?

7. Figure 8.22 illustrates the component hierarchy in a software system. Describe the sequence o f tests for integrating the components using a botto m-up a pproach,a top-down

FIGURE 8.21 Graph for program in Figure 8.7.

FIGURE 8.22 Example component hierarchy.

452 Chapter 8 Testing the Programs

approach, a modified top-down approach, a big-bang approach, a sandwich approach, and a modified sandwich approach.

8. Explain why the graph of Figure 8.19 can be interpreted to mean that if you find many faults in your code at compile time, you should throw away your code and write it again.

9. What are some poss ible explanations for the behavior of the graph in Figure 8.19? 10. A program is seeded with 25 faults. During testing, 18 faults are detected, 13 of which are

seeded faults and 5 of which are indigenous faults. What is Mills's estimate of the number of indigenous faults remaining undetected in the program?

ll. You claim that your program is fau lt-free at a 95% confidence level. Your test plan calls for you to test until you find all seeded faults. With how many faults must you seed the program before testing in order to substantiate your claim? If for some reason you do not intend to find all seeded faults, how may seeded faults does the Richards formula require?

12. Discuss the differences in testing a business-critical system, a safety-critical system, and a system whose failure would not seriously affect lives, health, or business.

13. Give an example of an object-oriented system where synchronization problems require careful testing.

14. If an independent test team does integration testing and a critical fault remains in the code after testing is complete, who is legally and ethically responsible for the damage caused by the fault?

15. Suppose you are building a tax preparation system that has three components. The first component creates forms on the screen , allowing the user to type in name, address, tax identification number, and financial information. The second component uses tax tables and the input information to calculate the amount of tax owed for the current year. The third component uses the address information to print forms for federal, state (or provin- cial), and city taxes., including the amount owed. Describe the strategy you would use to test this system, and outline your test cases in a test plan.

Openmirrors.com

9

In this chapter, we look at • function testing • perforrmance testing • acceptance testing • software reliability, availability,

and maintainability • installation testing • test documentation • testing safety-critical systems

Testing the syste m is ve ry diffe rent fro m unit and integration testing. When yo u unit test your compone nts, you have comple te control ove r the testing p rocess. You create your o wn test data, design your own test cases, and run the tests yourself. Whe n you integrate compone nts, you sometimes work by yourself, but often you coll aborate with some o f the test or deve lopment team. H owe ve r, when you test a system , you work with the e ntire developme nt te am, coordinating what you do and be ing directed by the test team le ader. In this chapter, we look at the system testing process: its purpose, steps, pa rticipants, techniques, and tools.

9 .1 PRINCIPLES OF SYSTEM TESTING

The o bj ective of unit and integration testing was to ensure that the code implemented the design p roperl y; that is, tha t the p rogramme rs wrote code to d o what the designers inte nde d. In system testing, we have a very differe nt o bjecti ve: to ensure that the sys tem does what the custome r wants it to do. To under stand how to meet this objective, we first must unde rstand where faults in the syste m come fro m.

Sources of Software Faults

Recall tha t a softwa re fault ca uses a failure only when accompa nied by the right con- ditions. Tha t is, a fa ult may exist in the code, but if the code is never executed , or if the cod e is no t executed lo ng e nough or in the appropriate configuration to cause a

453