Prentice object oriented software engineering using UML patterns and java 3rd 2012

Object-Oriented Software Engineering Using UML, Patterns, and Java™ Third Edition Bernd Bruegge & Allen H Dutoit Technical University of Munich Department of Computer Science Munich, Germany Carnegie Mellon University School of Computer Science Pittsburgh, PA, United States Prentice Hall Boston Columbus Indianapolis New York San Francisco Upper Saddle River Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto Delhi Mexico City Sao Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo Vice President and Editorial Director, ECS: Marcia J Horton Editor in Chief: Michael Hirsch Executive Editor: Tracy Dunkelberger Assistant Editor: Melinda Haggerty Editorial Assistant: Allison Michael Director of Marketing: Margaret Waples Marketing Manager: Erin Davis Marketing Coordinator: Kathryn Ferranti Senior Managing Editor: Scott Disanno Senior Operations Supervisor: Alan Fischer Operations Specialist: Lisa McDowell Art Director: Kenny Beck Cover Designer: Bruce Kenselaar Media Editor: Dan Sandin Copyright © 2010, 2004, 2000 Pearson Education, Inc., publishing as Prentice Hall All rights reserved Manufactured in the United States of America This publication is protected by Copyright, 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, mechanical, photocopying, recording, or likewise To obtain permission(s) to use material from this work, please submit a written request to Pearson Education, Inc., Permissions Department, One Lake Street, Upper Saddle River, NJ, 07458 Many of the designations by manufacturers and seller to distinguish their products are claimed as trademarks Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed in initial caps or all caps Quote of Chapter from Object-Oriented Analysis and Design with Applications by Booch, © 1994 Benjamin Cummings Publishing Company Inc Reprinted by permission of Pearson Education, Inc Quotes of Chapters & 12 from Zen and the Art of Motorcycle Maintenance by Robert Pirsig, © 1974 by Robert Pirsig Reprinted by permission of HarperCollins Publishers Inc William Morrow For British Commonwealth excluding Canada, Zen and the Art of Motorcycle Maintenance by Robert M Pirsig published by Bodley Head Used by persmission of The Random House Group Limited Quote of Chapter from The Emperor’s Old Clothes by C A R Hoare, © 1981 Association for Computing Machinery, Inc Reprinted by permission Quote of Chapter 13 from Chapterhouse: Dune by Frank Herbert, © 1985 by Frank Herbert Used by permission of Berkeley Publishing Group, a division of Penguin Group (USA) Inc All other chapter quotes are in the public domain or fall within the realm of fair use Book photos: Bernd Bruegge, Rich Korf, and Blake Ward Library of Congress Cataloging-in-Publication Data on File 10 Prentice Hall is an imprint of www.pearsonhighered.com ISBN 10: 0-13-606125-7 ISBN 13: 978-0-13-606125-0 To Goeg, Toby, and Clara —B.B To my family: Vicky, Eleni, Anna-Maria, Michelle, and Chris with love —A.H.D This page intentionally left blank Foreword O ver ten years ago, I read about a software engineering course taught by Bernd Bruegge at Carnegie-Mellon University In software engineering courses at many other universities, small groups of or students were assigned several toy problems during a semester with deadlines of less than a month On such small projects, one strong programmer can carry the whole team by brute force It isn’t necessary to learn communication skills, use modeling tools, or deal with the ambiguities of actual problems Students come away unprepared for the complexities of realworld development In Bruegge’s course, the entire class worked on a single, semester-long project to produce a query-oriented navigation system for the city of Pittsburgh They had to build on the interactive mapping system produced by the previous semester’s class The clients were managers for the county planning department and port authority The geographic and bus schedule data had misspellings, inaccuracies, and incompatible formats The students produced an accepted system of over 27,000 lines of code What a difference from the toy projects taught at many other places! Students came away from the course with an appreciation of the need for strategy, organization, and tools to deal with the complexity and messiness of the real world They learned software engineering the only way one learns any craft—by practicing it on realistic cases This book is a reflection of that pragmatic philosophy of software development as an engineering discipline The authors adopt a point of view—an object-oriented approach using UML—that makes the many facets of software engineering approachable to students They cover both the modeling techniques and the human communications skills needed to achieve success They also include several chapters on managing change, a topic that appears in every real project but which is often neglected in texts Readers of this book will gain a solid appreciation of the rich scope and complexity of software engineering v vi Foreword I particularly enjoyed the many illuminating anecdotes selected from a wide range of fields These provide lively examples of problems large and small that illustrate the subtleties and traps that engineers must confront Any book that makes relevant examples of Polynesian navigation, the tangled history of the text of Tolkien’s Lord of the Rings, and grandmother’s recipe for trimming hams is not only useful but also fun to read Jim Rumbaugh Preface T he K2 towers at 8,611 meters in the Karakorum range of the western Himalayas It is the second highest peak of the world and is considered the most difficult 8000er to climb An expedition to the K2 typically lasts several months in the summer, when the weather is most favorable Even in summer, snowstorms are frequent An expedition requires thousands of pounds of equipment, including climbing gear, severe weather protection gear, tents, food, communication equipment, and pay and shoes for hundreds of porters Planning such an expedition takes a significant amount of time in the life of a climber and requires dozens of participants in supporting roles Once on site, many unexpected events, such as avalanches, porter strikes, or equipment failures, will force the climbers to adapt, find new solutions, or retreat The success rate for expeditions to the K2 is currently less than 40% The United States National Airspace System (NAS) monitors and controls air traffic in the United States The NAS includes more than 18,300 airports, 21 air route traffic control centers, and over 460 control towers These add up to more than 34,000 pieces of equipment, including radar systems, communication switches, radios, computer systems, and displays The current infrastructure is aging rapidly The computers supporting the 21 air route traffic control centers, for example, are IBM 3083 mainframes that date back to the early 1980s In 1996, the United States government initiated a program to modernize the NAS infrastructure, including improvements such as satellite navigation, digital controller/pilot communications, and a higher degree of automation in controlling the air routes, deciding the order in which aircraft land, and controlling ground traffic as aircraft move from and to the runways Such a complex infrastructure, however, can only be modernized incrementally Consequently, while new components offering new functionality are introduced, older components still need to be supported For example, during the transition period, a controller will have to be able to use both analog and digital voice channels to communicate with pilots Finally, the modernization of the vii viii Preface NAS coincides with a dramatic increase in global air traffic, predicted to double within the next 10–15 years The previous modernizing effort of the NAS, called the Advanced Automation System (AAS), was suspended in 1994 because of software-related problems, after missing its initial deadline by several years and exceeding its budget by several billions of dollars Both of the above examples discuss complex systems in which external conditions can trigger unexpected changes Complexity puts the problem beyond the control of any single individual Change forces participants to move away from well-known solutions and to invent new ones In both examples, several participants need to cooperate and develop new techniques to address these challenges Failure to so results in failure to reach the goal This book is about conquering complex and changing software systems The theme The application domain (mountain expedition planning, air traffic control, financial systems, word processing) usually includes many concepts that software developers are not familiar with The solution domain (user interface toolkits, wireless communication, middleware, database management systems, transaction processing systems, wearable computers) is often immature and provides developers with many competing implementation technologies Consequently, the system and the development project are complex, involving many different components, tools, methods, and people As developers learn more about the application domain from their users, they update the requirements of the system As developers learn more about emerging technologies or about the limitations of current technologies, they adapt the system design and implementation As quality control finds defects in the system and users request new features, developers modify the system and its associated work products The result is continuous change Complexity and change represent challenges that make it impossible for any single person to control the system and its evolution If controlled improperly, complexity and change defeat the solution before its release, even if the goal is in sight Too many mistakes in the interpretation of the application domain make the solution useless for the users, forcing a retreat from the route or the market Immature or incompatible implementation technologies result in poor reliability and delays Failure to handle change introduces new defects in the system and degrades performance beyond usability This book reflects more than 10 years of building systems and of teaching software engineering project courses We have observed that students are taught programming and software engineering techniques in isolation, often using small problems as examples As a result, they are able to solve well-defined problems efficiently, but are overwhelmed by the complexity of their first real development experience, when many different techniques and tools need to be used and different people need to collaborate Reacting to this state of affairs, the typical undergraduate curriculum now often includes a software engineering project course, organized as a single development project Preface ix The tools: UML, Java, and Design Patterns We wrote this book with a project course in mind The book can be used, however, in other situations as well, such as short and intensive workshops or short-term R&D projects We use examples from real systems and examine the interaction among state-of-the art techniques, such as UML (Unified Modeling Language), Java-based technologies, design patterns, design rationale, configuration management, and quality control Moreover, we discuss project management related issues that are related to these techniques and their impact on complexity and change The principles We teach software engineering following five principles: Practical experience We believe that software engineering education must be linked with practical experience Students can understand complexity only by working with a complex system—that is, a system that no single student can completely understand Problem solving We believe that software engineering education must be based on problem solving Consequently, there are no right or wrong solutions, only solutions that are better or worse relative to stated criteria Although we survey existing solutions to real problems and encourage their reuse, we also encourage criticism and the improvement of standard solutions Limited resources If we have sufficient time and resources, we could perhaps build the ideal system There are several problems with such a situation First, it is not realistic Second, even if we had sufficient resources, if the original problem rapidly changes during the development, we would eventually deliver a system solving the wrong problem As a result, we assume that our problem-solving process is limited in terms of resources Moreover, the acute awareness of scarce resources encourages a component-based approach and reuse of knowledge, design, and code In other words, we support an engineering approach to software development Interdisciplinarity Software engineering is an interdisciplinary field It requires contributions from areas spanning electrical and computer engineering, computer science, business administration, graphic design, industrial design, architecture, theater, and writing Software engineering is an applied field When trying to understand and model the application domain, developers interact regularly with others, including users and clients, some of whom know little about software development This requires viewing and approaching the system from multiple perspectives and terminologies Communication Even if developers built software for developers only, they would still need to communicate among themselves As developers, we cannot afford the luxury of being able to communicate only with our peers We need to communicate alternatives, articulate solutions, negotiate trade-offs, and review and criticize others’ work A large number of failures in software engineering projects can be traced to the communication of inaccurate information or 768 analysis object heuristics for initial set 145 identifying initial set 143 analysis object model 175, 176, 722 analyst 201, 722 API 230, 311, 722 API engineer 87, 722 application domain 41, 722 application domain specialist 88, 723 application framework 332, 723 application logic layer 244 application object 313, 723 application programmer interface 230 architect 723 during analysis 201 during object design 381, 424 during system design 286 architectural pattern 723 architectural risk 667 architectural style 723 architecture first 664 architecture liaison 723 during object design 381, 424 during system design 286 ARENA 23 analysis 206– 218 design patterns 341– 344 mapping to code 424– 432 requirements elicitation 153– 168 specifying interfaces 382– 388 system design 290– 302 argument 59, 503, 723 argumentation 495, 723 Ariane 501 78 as-is scenario 133, 723 assembly connector 230 assessment 502 association 52, 190, 723 heuristics 191 identifying 190 name 190 association class 53, 723 Index realizing association table asynchronous groupware ATRACT attribute description heuristics identifying identifying missing name attribute type attribute visibility auditing auditor authentication availability 411 419 108 681– 683 39, 193, 723 193 194 193 366 193 723 723 540, 723 568, 723 273, 723 126, 250, 724 B ball-and-socket connectors base class baseline bazaar model benchmark test beta testing big bang testing blackbox framework blackbox test blooper Boehm’s spiral model Boeing 747 bottom-up testing boundary condition identifying boundary object heuristics identifying boundary testing boundary use case brainstorming branch branch management Bridge design pattern bug 230 313, 724 543, 724 724 475 475 466, 724 333, 724 450, 724 308 639 538 466, 724 279, 724 279 177, 724 183 182 456 279, 724 97, 724 546, 724 557 321, 712 724 Index build management buried association burn down chart 769 540, 724 418, 724 613 C callback 244, candidate keys 417, capability 271, Capability Maturity Model 633, cathedral model centralized traffic control 498, change 548, change control 540, change control board 568, change management 565, change request 541, 544, change set 548, changed-based view chief programmer organization 616, chronological minutes ciphertext clarity 128, class 35, 38, 50, class diagram 43, applying class extender 353, class implementor 353, class user 353, ClearCase client 88, 242, during analysis client class 318, 353, client review 81, 95, client sign-off client type client/server 242, closed architecture 235, closed issue 645, CM aggregate 541, 542, identifying CMM See Capability Maturity Model cohesion 228, 231, 724 724 724 725 725 725 725 725 725 664 725 725 548 725 517 274 725 725 725 59 725 725 725 548 726 200 726 726 204 655 726 726 726 726 552 633 726 Command design pattern 329, communication activity communication diagrams communication event communication infrastructure setting up communication mechanism communication relationship competitor testing completeness of the system design component encapsulating inspecting logical physical component champion component expert component inspection component-based development Composite design pattern composition aggregation concept configuration 542, configuration item 541, identifying configuration management activities documenting managing planning roles tools configuration management aggregate configuration manager 87, during analysis during object design during reuse during system design conflict resolution consistency 342, 713 726 21 61, 726 726 598 102, 726 46, 726 475 128, 726 283 726 323 451 229 229 340 727 727 664 330, 714 192, 727 727 543, 727 542, 727 540, 552 727 550 567 566 568 568 548 541, 727 568, 727 201 381 340 286 531 128, 727 770 Index of the system design constraint 70, heuristics consultant role 88, continuous integration contract 356, inheriting contract inheritance 374, control flow 275, encapsulating control node 66, control object 177, heuristics identifying controller correction 445, 451, correctness 128, of the system design correctness debugging cost criterion 250, coupling 228, 230, coverage (in equivalence testing) CRC card 189– 190, 672, criterion 495, 502, critical path 588, cross development cross-functional role 87, cross-functional team 85, 109, CTC 498, 510, See also Centralized Traffic Control CVS cycle 283 727 373 727 569 727 374 727 727 329 728 728 184 184 728 728 728 282 441 728 728 455 728 728 728 728 728 728 728 548 639 D daily Scrum meeting data flow data record data type DCOM debugging decision in an activity diagram decision rationale 613 728 416 35, 37, 728 333 441, 729 495, 729 66 507 Decision Representation Language 505, 507, defect delegation 316, deliverable 13, 90, 586, delta 548, dependability criterion 126, 250, deployment cost deployment diagram 262, derived class derived classes design goal addressing identifying design pattern 317, 709– 718, developer during configuration management during object design development cost development processes development role different time, different place groupware discount usability engineering disjointedness (in equivalence testing) distribution document editor 87, during analysis during system design DoD Std 2167A domain experience domain object double test DRL dynamic access control 273, dynamic model 30, 175, 176, 729 729 729 729 729 729 251 729 729 313 729 264 249 729 729 568 424 251 630 86 108 453 456 657 729 201 286 647 667 729 465 505 730 730 E egoless programming encryption end user during analysis end user criterion enterprise application framework entity object 616, 730 274, 730 88, 656, 730 200 251, 730 333, 730 177, 730 Index 771 heuristics 181 identifying 180 entity-centered software life cycle model 623, 644, 730 entry condition 45, 730 environment 730 equivalence testing 455 erroneous state 440, 444, 730 error 440, 730 evaluation scenario 133, 730 event 40, 730 event class 40, 730 event-driven control 276, 730 exception 730 exception handling 280– 281, 730 exit condition 46, 730 expensive computation caching the result of 405 delaying 405 extend relationship 47, 140, 731 heuristics 143 extender class 318, 731 extensibility 251, 731 external behavior 44, 731 Extreme Programming 669– 673, 731 F Facade design pattern facilitator failure falsification fault interface misuse leap year security year 1900 fault avoidance fault detection fault tolerance field testing filter Final Document (JAD) firewall 253, 715 105, 731, 740 440, 444, 731 43, 731 440, 444, 731 4 4 440, 731 441, 731 250, 441, 731 475, 731 245 150 271, 731 flat file flat staffing floor plan example flow of events in a scenario in a use case fly-by-wire foreign key fork node forward engineering 376, 400, four-tier framework identifying and adjusting FRIEND 49, 62, 68, functional model 30, functional requirements functional testing 442, FURPS+ 417, 66, 644, 245, 332, 131, 175, 125, 472, 268 602 224 731 50 46 538 731 732 732 732 732 332 684 732 732 732 126 G Gantt chart generalization generalization-specialization gIBIS global access table global control flow goal goodness measure gradual staffing greenfield engineering groupware different time, different place same time different place 90, 732 49, 178, 732 179, 732 507 270, 732 275 732 502, 732 602 129, 732 732 108, 729 108, 745 H hallway conversation ham hardware configuration hierarchical decomposition hierarchical organization hook method horizontal mapping horizontal prototype 104, 732 494 264 235 84, 733 333, 733 420 289, 454, 733 772 Index I IBIS 506, ideal week 670, IEEE Std 1042 540, IEEE Std 1058.1 IEEE Std 1074 IEEE Std 828 imperative language implementation 20, implementation decision 38, implementation domain See also solution domain implementation inheritance 315, implementation requirements 127, implementor class 318, include relationship 46, 47, 141, heuristics infrastructure framework 333, inheritance 38, 57, 178, 195, inheritance relationship inspection 96, 441, installation 610, installation test installation testing 442, 476, instance 35, 37, integral processes integration testing 442, 451, 465, strategies interaction diagram 43, 59, interface engineering 130, interface inheritance 315, interface layer interface misuse interface requirements 127, internal transition 64, internal work product 90, 586, invariant 356, 371, ISO 9126 issue 495, 499, closed consequent open subissue 734 733 541 589 626 567 733 733 733 733 733 733 733 733 143 733 733 733 734 734 476 734 734 632 734 466 734 734 734 244 734 734 734 734 126 734 499 499 499 499 issue model issue resolution issue-based development Issue-Based Information System issue-based life cycle model 81, 101, 9, 505, 645, 735 735 734 734 734 J JAD See also Joint Application Design JAMES 691 join node 66, 735 Joint Application Design 124, 148, 735 JUnit 483 K K2 key process area kick-off meeting knowledge acquisition KPA See key process area 652 634, 735 602, 735 5, 8, 735 735 L late and over budget layer leap year bug legal requirements liaison liaison-based communication life cycle light rail system link Liskov Substitution Principle local king client Lord Of The Rings, The 228, 235, 735 127, 735 85, 87, 735 85 735 350 52, 735 317, 735 655, 735 394 M maintainability maintenance cost maintenance criterion management role many-to-many association 126, 735 251 251, 736 86, 600, 736 54, 736 Index realizing mapping master directory meeting meeting agenda meeting minutes memory merge message method methodological heuristics methodology metrics middleware framework MIL Std 480 minute taker minutes model model object model transformation Model/View/Controller modeling models modifiability modified sandwich testing multiplicity MVC myCarParts myTrip 773 542, 545, 105, 40, 58, 59, 15, 58, 655, 15, 655, 604, 604– 607, 333, 105, 528, 12, 35, 397, 240, 5, 6, 35, 659, 251, 54, 191, 409 736 736 736 105 105 250 546 736 736 702 736 668 736 542 736 736 736 737 737 737 737 659 737 469 737 737 550 247 N name navigation negotiation nested state nested state machine NFR Framework nonfunctional requirements identifying notation note in UML 737 52, 737 530 65, 737 65, 737 505, 508, 737 126, 737 146 15, 37, 737 738 69 O object 35, 39, 50, collapsing interactions Object Constraint Language 357, object design 19, 310, activities 320, 365, concepts 313, 352, documenting managing 337, 375, roles 340, 381, Object Design Document 375– 381, template object design model object designer 381, object diagram object model 30, object-oriented analysis 41, object-oriented database object-oriented design 41, Observer design pattern 242, 343, OCL 357, OCL bag 364, OCL collection 363, OCL sequence 363, OCL set 363, ODD See also Object Design Document on time delivery one-to-many association 54, realizing one-to-one association 54, realizing open architecture 235, open issue 645, operation 39, 58, identifying missing operations requirements 127, optical illusion organization OWL client acceptance test agenda 738 404 185 738 738 402 396 375 422 424 738 378 738 738 738 738 738 268 738 716 738 738 738 738 738 739 739 408 739 406 739 739 739 366 739 174 739 95 774 Index Problem Statement 94 P package (UML) 68, packaging requirements 127, pair programming 669, participant 11, 79, participating actor participating actor instance participating actors in a scenario in a use case participating object 32, 143, cross checking with use cases partition 228, 237, path testing pattern expert pattern interface 318, patterns champion peer review 81, peer-based communication 86, peer-to-peer 243, Perforce performance criterion 250, performance debugging performance testing 442, 473, persistent data 266, persistent data store defining PERT chart 92, phase 13, phenomenon pilot testing 475, pipe and filter 245, plaintext planned communication event platform polymorphism testing portability 126, 251, postcondition 356, 369, post-development processes postmortem review 98, 611, potentially deliverable product increment 739 739 672 739 739 739 50 45 739 146 739 458 739 739 340 739 739 739 548 740 441 740 740 266 740 740 740 740 740 274 92 264 463 740 740 631 740 611 precondition pre-development processes preparation (JAD) primary key problem definition problem domain problem inspection problem presentation problem solving Problem Statement developing template problem statement procedural language procedure-driven control process process flexibility process group process management process maturity product owner product test Project Agreement project backlog project communication project conception phase project definition (JAD) project definition phase project environment project function project goal project initiation project management activities project management processes project member project review project scale project start phase project steady state project steady state phase project termination project velocity project-based organization 356, 369, 740 630 150 416, 740 580, 740 740 81, 740 93, 740 5, 8, 741 741 594 595 580, 593 741 275, 741 626, 741 667 626, 741 541, 741 667 612 454 589, 741 612 92 741 150 80, 741 655 585 654 592, 741 23, 577, 741 592 628 79, 741 81, 95, 742 666 80, 742 742 80 81, 592, 742 671, 742 741 Index promotion promotion management proposal prototype test prototyping proxy client Proxy design pattern pseudo client pseudo requirements 775 542, 544, 742 554 500, 742 454 43, 742 656, 742 265, 273, 405, 717 656, 742 127, 742 Q QOC 505, 507, 742, 743 quadruple test 465 qualification 56, 742 qualified association 57, 742 realizing 410 qualifier 57, 742 quality requirements 127 in a use case 46 questionnaire 104, 743 Questions, Options, and Criteria 505, 507, 743 R RAD 199, 594, 743 See also Requirements Analysis Document rationale 6, 10, 495, 743 activities 510 capturing asynchronously 519 capturing in meetings 511 capturing when discussing change 520 communicating about 529 concept 497 documenting 526 management 9, 22, 526 reconstructing 524 roles 528 rationale editor 528, 743 rationale management 493– 532, 743 rationale model 526, 743 RCS 548 readability 251, 743 of the system design 283 realism 129 of the system design 283 realizability 743 recovery tests 474 reengineering 129, 743 refactor 672 refactoring 398, 743 refined class 743 regression test 481 regression testing 743 relation 416 relational database 268 release 81, 97, 542, 545, 743 release management 555 reliability 126, 250, 440, 743 reporting structure 84, 743 repository 239, 542, 545, 744 repository architectural style 239, 744 representation (in equivalence testing) 456 request for change 81, 100, 744 request for clarification 81, 99, 744 requirements 744 functional 14, 125 nonfunctional 14, 126 identifying 124 Requirements Analysis Document 151– 153, 199, 744 template 152 requirements elicitation 16, 123, 744 activities 130 concepts 125 documenting 151 managing 148 requirements engineering 744 requirements specification 123, 744 requirements testing 472 resolution 504, 744 resources 14, 744 response time 126, 250, 744 reverse engineering 377, 401, 644, 744 review 441 reviewer 528, 744 during analysis 201 776 during system design risk risk management risk-based development robustness role in an association in an organization round round-trip engineering Royce’s methodology Rubin Index 607– 609, 9, 126, 250, 54, 644, 664, 663, 286 744 744 744 745 745 191 11 639 745 745 174 S safety 126, 250, 745 sandwich testing 467, 745 SatWatch 125 sawtooth model 647 scenario 50, 135, 745 heuristics 134, 139 identifying 124 scenario test 454 schedule 79, 745 creating initial 597 schema 268, 416, 745 SCMP 745 See also Software Configuration Management Plan Scrum master 612 Scrum team 613 SDD 442, 745 See also System Design Document secondary facilitator 745 security 4, 250, 745 security testing 474 sequence diagram 32, 59, 185, 745 heuristics 189 server 242 service 228, 230, 745 session (JAD) 150 shadow testing 475 shared aggregation 192, 745 signature 354, 746 specifying 368 skill identifying 599 slack time 588, 746 software architecture 238, 746 software configuration management 22, 537– 569 Software Configuration Management Plan 567– 568, 746 template 567 software engineering methodology 655 software library 542, 545, 746 software life cycle 23, 626, 746 software life cycle model 623, 746 Software Project Management Plan 589– 592, 746 software reliability 440, 746 solution domain 41, 746 solution object 313, 746 Space Shuttle computer redundancy 260 Space Shuttle Challenger 576 Space Shuttle Columbia 438 Space Shuttle Discovery 122 specialization 178, 746 specification inheritance 315, 746 Speed 308 spiral model 746 SPMP 594, 746 See also Software Project Management Plan sprint 611 sprint backlog 612 sprint planning meeting 612 staged build 570 stakeholder cohesion 667 stand up meeting 673 Star Wars Trilogy 308 state 62, 747 state machine diagram 44, 62, 747 applying 65 state-based testing 461 state-based view 548 static access control 272, 747 status accounting 540, 747 status meeting 81, 747 Index status review stereotype stimulus storage layer Strategy design pattern streetcar system stress testing strict inheritance structural testing structured interview structured minutes STS-51L Stuttgart subclass subclasses subsystem allocating to node encapsulating identifying subsystem decomposition subsystem interface subsystem team subtype superclass supportability swimlane Swing SYBIL system system design activities communicating concepts documenting iterating managing reviewing System Design Document system design model system model system structure testing system testing system under test 777 96 70, 747 747 244 325, 718 350 474 317, 747 747 104, 747 518 576 350 38, 57, 747 313 35, 228, 747 265 253 253 748 230, 748 109, 748 317 38, 57, 313, 748 126, 748 66, 748 236 507 12, 35, 748 19, 223– 302, 748 247, 264 287 228, 262 284 288 284 282 284, 748 748 35, 36, 748 442 442, 452, 471, 748 484 T tables tame problem task task model team team leader team-based organization technical consultant technical role technical writer during object design during reuse test case Test Case Specification template test component test context test driver test first test harness Test Incident Report Test Manual test objective Test Plan template test planning Test Report Summary test stub Test Summary Report test system tester testing concepts managing thread three-tier throughput time constraint timekeeper timing tests Titanic Tolkien, J.R.R 14, 80, 88, 584, 586, 109, 602, 83, 88, 746, 444, 448, 484, 444, 444, 450, 442, 444, 450, 88, 20, 440, 276, 244, 126, 250, 105, 416 506 748 749 749 749 749 749 600 749 381 340 749 478 480 484 484 749 672 484 478 749 484 478 478 749 478 749 478 484 749 749 444 476 749 749 749 588 749 474 308 394 778 top-down testing top-level design defining traceability maintaining training scenario transformation transition internal transition triple test tuple type of an attribute Index 466, 749 593, 750 594 124, 129, 251, 750 150 133, 750 395, 750 62, 750 64, 734 465 750 750 194, 354 U U2TP UML profile UML state machine unambiguous requirement Unified Modeling Language (UML) 30, Unified Process 641, 663, Unified Software Development Process 641, unit testing 442, 451, 455, unnecessary complexity unplanned communication event upgrade cost usability 126, 252, examples usability testing 442, 451, 453– 487, use case 44, 135, cross checking with participating objects heuristics identifying 124, identifying relationships 124, refining 124, use case diagram 31, 43, user user interface prototype User Manual utility 484 484 750 750 750 750 750 750 99 251 750 122 750 750 146 139 135 140 138 750 750 454 750 252 V validation variant variant management verdict verifiability verification version version identifier vertical mapping vertical prototype view visibility specifying visionary scenario V-model volume testing 751 542, 543, 751 562 484 129, 751 751 542, 543, 751 545, 751 420 289, 454, 751 36, 751 354 368 133, 751 638, 751 474 W walkthrough 96, 441, 751 waterfall model 637, 751 WBS 751 WebObjects 335 whitebox framework 333, 751 whitebox test 450, 751 wicked problem 506 wizard of Oz prototype 454 work breakdown structure 586, 751 work package 90, 585, 751 work product 13, 79, 88, 585, 752 deliverable 13 internal 13 workflow 752 workspace 545, 752 X XP 669, 731 Y year 1900 bug year 2000 bug 494 Dealing with complexity problem statement Requirements elitation (Ch.4) nonfunctional requirements functional model use case diagram Analysis (Ch.5) class diagram analysis object model statechart diagram dynamic model System design (Ch.6 & 7) sequence diagram subsystem decomposition system design object model design goals Object design (Ch.8 & 9) class diagram object design model Implementation (Ch.10) source code Test (Ch.11) deliverable system Managing change Rationale (Ch.12) assesses Criterion Proposal * * * solvable-by Issue based-on Resolution resolved-by Testing (Ch.11) implementedBy Test suite exercises * is-revised-by 1…n * Test case Component Correction * finds * * * repairs * Failure * * Error * Fault is-caused-by is-caused-by Project Management (Ch.14) Project Resource * * Outcome Work * * Set of work products Work product Activity Configuration Management (Ch.13) * Controlled item * CM Aggregate Version Configuration item Promotion Release Task Design patterns Abstract Factory (328, 341, 710) this pattern shields a system from the concrete classes provided by a specific platform, such as a windowing style or an operating system Adapter (319, 711) This pattern encapsulates a piece of legacy code that was not designed to work with the system It also limits the impact of substituting the piece of legacy code for a different component Bridge (321, 712) This pattern decouples the interface of a class from its implementation Unlike the Adapter pattern, the developer is not constrained by an existing piece of code Command (329, 342, 713) This pattern enables the encapsulation of control objects so that user requests can be treated uniformly, independent of the specific request This pattern protects these objects from changes required by new functionality Composite (55, 228, 233, 330, 714) This pattern represents a hierarchy which has dynamic width and depth The services related to the hierarchy are factored out using inheritance, allowing a system to treat leaves and intermediate composite nodes uniformly Facade (254, 715) This pattern reduces dependencies among classes by encapsulating a subsystem with a simple unified interface Observer (240, 342, 716) This pattern allows to maintain consistency across the states of one Publisher and many Subscribers Proxy (274, 405, 717) This pattern improves the performance or the security of a system by delaying expensive computations, using memory only when needed, or checking access before loading an object into memory Strategy (325, 463, 718) This pattern decouples a policy from a set of mechanisms or a context from a set of implementations Depending on the policy or context, the mechanisms or implementations can be changed at runtime transparently from the client Notations UML use case diagrams (31, 44) Use case diagrams are used to represent the functionality of the system, as seen by an actor UML class diagrams (32, 50) Class diagrams are used to represent the structure of the system, in terms of subsystems, classes, attributes, operations, and associations UML sequence diagrams (32, 59) Sequence diagrams represent behavior in terms of a series of interactions among a set of objects UML statechart diagrams (33, 62) Statechart diagrams represent behavior of a single object as a state machine in terms of events and transitions Activity diagrams (33, 65) Activity diagrams are flow diagrams which represent behavior of a set of objects as activities and transitions UML deployment diagrams (228) Deployment diagrams represent the mapping of software components to hardware nodes Issue models (497) Issue models represent the justification of decisions in terms of issues, proposals, arguments, criteria, and resolutions PERT charts (90) PERT charts represent the division of work into tasks and ordering constraints Example systems 2Bwatch and SatWatch (125) 2Bwatch is a digital watch with two buttons SatWatch is a digital watch that uses GPS satellites to select the correct time zone Except for a display, it provides no interface for its user Both are systems that are simple enough for introducing basic requirements elicitation concepts FRIEND (131, 181) FRIEND is a distributed information system for managing accidents It allows field officers, dispatchers, and authorities to communicate and allocate resources to an emergency FRIEND is a much more complex system than either 2Bwatch or SatWatch It illustrates how requirements elicitation and analysis methods scale up to a real system FRIEND was realized in CMU between 1992 and 1994 myTrip (247) myTrip enables users to plan a trip and download its information into their car Once in the car, users can execute their trip and receive directions This example was inspired from the JAMES system which was realized in CMU and in TUM in 1997 and 1998 We use the myTrip system to illustrate system design methods CTC (510) CTC is a centralized traffic control system for trains It enables dispatchers to monitor and direct trains remotely Such systems usually have a long life and high availability requirements We use the access control mechanisms of CTC for illustrating rationale management methods myCarParts (550) myCarParts is a web-based electronic catalog of car parts It enables novice users and mechanics to browse, search, and order parts myCarParts is a client server system in which both the server and the client are incrementally improved We use myCarParts to illustrate the activities of configuration management myCarParts was inspired by PAID, a system realized at CMU and TUM in 1998 and 1999 ARENA (153, 206, 290, 341, 382, 424) ARENA is a multi-user, Web-based system for organizing and conducting tournaments ARENA is game independent in the sense that organizers can adapt a new game to the ARENA game interface, upload it to the ARENA server, and immediately announce and conduct tournaments with players and spectators located anywhere on the Internet Organizers can also define new tournament styles, describing how players are mapped to a set of matches and how to compute an overall ranking of players by adding up their victories and losses (hence, figuring out who won the tournament) To recoup their operational costs, organizers can also invite potential sponsors to display advertisement banners during games ARENA has been realized at TUM and the University of Otago in 2002 and 2003 .. .Object- Oriented Software Engineering Using UML, Patterns, and Java Third Edition Bernd Bruegge & Allen H Dutoit Technical University... pragmatic philosophy of software development as an engineering discipline The authors adopt a point of view—an object- oriented approach using UML that makes the many facets of software engineering approachable... on object- oriented techniques applied to software engineering It is neither a general software engineering book that surveys all available methods nor a programming book about algorithms and