统一软件开发过程The Unified Software Development Process(英文原版进口)

.2.3.3 a system has a collection of models 21
2.3.4 what is a model? 22
2.3.5 each model is a self-contained view of the system 22
2.3.6 inside a model 23
2.3.7 relationships between models 23
2,4 process directs projects 24
2.4.1 process: a template 24
2.4.2 related activities make up workflows 25
2.4.3 specializing process 26
2.4.4 merits of process 27
2,5 tools are integral to process 28
2.5.1 tools impact process 28
2.5.2 process drives tools 28
2.5.3 balance process and tools 29
2.5.4 visual modeling supports uml 29
2.5.5 tools support the whole life cycle 30
2,6 references 31
chapter 3: a use-case-driven process 33
3.1 use-case-driven development in brief 35
3.2 why use cases? 37
3.2.1 to capture the value adding requirements 37
3.2.2 to drive the process 38
3.2.3 to devise the architecture and more... 39
3.3 capturing the use cases 40
3.3.1 the use-case model represents the functional requirements 40
3.3.2 actors are the environment of the system 41
3.3.3 use cases specify the system 41
3.4 analysis, design, and implementation to realize the use cases 42
3.4.1 creating the analysis model from the use cases 43
3.4.2 each class must fulfill all its collaboration roles 48
3.4.3 creating the design model from the analysis model 48
3.4.4 subsystems group classes 51
3.4.5 creating the implementation model from the design model 53
3,5 testing the use cases 55
3.6 summing up 57
3.7 references 57
chapter 4: an architecture-centric process 59
4.1 architecture in brief 60
4.2 why we need architecture 62
4.2.1 understanding the system 62
4.2.2 organizing development 63
4.2.3 fostering reuse 63
4.2.4 evolving the system 64
4.3 use cases and architecture 65
4.4 the steps to an architecture 69
4.4.1 the architecture baseline is a "small, skinny" system 69
4.4.2 using architecture patterns 71
4.4.3 describing architecture 74
4.4.4 the architect creates the architecture 76
4.5 finally, an architecture description! 77
4.5.1 the architectural view of the use-case model 78
4.5.2 the architectural view of the design model 78
4.5.3 the architectural view of the deployment model 81
4.5.4 the architectural view of the implementation model 83
4.6 three interesting concepts 83
4.6.1 what is architecture? 83
4.6.2 how is it obtained? 83
4.6.3 how is it described? 83
4.7 references 84
chapter 5: an iterative and incremental process 85
5.1 iterative and incremental in brief 86
5.1.1 develop in small steps 87
5.1.2 what iteration is not 88
5.2 why iterative and incremental development? 89
5.2.1 mitigating risks 89
5.2.2 getting a robust architecture 91
5.2.3 handling changing requirements 91
5.2.4 allowing for tactical changes 92
5.2.5 achieving continuous integration 92
5.2.6 attaining early learning 93
5.3 the iterative approach is risk-driven 94
5.3.1 iterations alleviate technical risks 95
5.3.2 management is responsible for nontechnical risks 97
5.3.3 dealing with risks 97
5.4 the generic iteration 98
5.4.1 what an iteration is 98
5.4.2 planning the iterations 100
5.4.3 sequencing the iterations 100
5.5 the result of an iteration is an increment 101
5.6 iterations over the life cycle 102
5.7 models evolve from iterations 105
5.8 iterations challenge the organization 106
5.9 references 106
part 2: the core workflows 109
chapter 6: requirements capture: from vision to requirements 111
6.1 why requirements capture is difficult 112
6.2 the purpose of the requirements workflow 113
6.3 overview of requirements capture 113
6.4 the role of requirements in the software life cycle 118
6.5 understanding the system context using a domain model 119
6.5.1 what is a domain model? 119
6.5.2 developing a domain model 121
6.5.3 use of the domain model 121
6.6 understanding the system context using a business model 122
6.6.1 what is a business model? 122
6.6.2 how to develop a business model 124
6.6.3 find use cases from a business model 126
6.7 supplementary requirements 128
6.8 summary 130
6.9 references 130
chapter 7: capturing the requirements as use cases 131
7.1 introduction 131
7.2 artifacts 133
7.2.1 artifact: use-case model 133
7.2.2 artifact: actor 134
7.2.3 use case 135
7.2.4 artifact: architecture description (view of the use-case model) 139
7.2.5 artifact: glossary 139
7.2.6 artifact: user-interface prototype 140
7.3 workers 140
7.3.1 worker: system analyst 140
7.3.2 worker: use-case specifier 141
7.3.3 user-interface designer 142
7.3.4 worker: architect 142
7.4 workflow 143
7.4.1 activity: find actors and use cases 144
7.4.2 activity: prioritize use cases 153
7.4.3 activity: detail a use case 153
7.4.4 activity: prototype user interface 160
7.4.5 activity: structure the use-case model 166
7.5 summary of the requirements workflow 171
7.6 references 172
chapter 8: analysis 173
8.1 introduction 173
8.2 analysis in brief 176
8.2.1 why analysis is not design or implementation 176
8.2.2 the purpose of analysis: summary 177
8.2.3 concrete examples of when to employ analysis 178
8.3 the role of analysis in the software life cycle 179
8.4 artifacts 181
8.4.1 artifact: analysis model 181
8.4.2 artifact: analysis class 181
8.4.3 artifact: use-case realization--analysis 186
8.4.4 artifact: analysis package 190
8.4.5 artifact: architecture description (view of the analysis model) 193
8.5 workers 194
8.5.1 worker: architect 194
8.5.2 worker: use-case engineer 194
8.5,3 worker: component engineer 195
8.6 workflow 196
8.6.1 activity: architectural analysis 196
8.6.2 activity: analyze a use case 203
8.6.3 activity: analyze a class 207
8.6.4 activity: analyze a package 211
8.7 summary of analysis 213
8.8 references 214
chapter 9: design 215
9.1 introduction 215
9.2 the role of design in the software life cycle 216
9.3 artifacts 217
9.3.1 artifact: design model 217
9.3.2 artifact: design class 218
9.3.3 artifact: use-case realization--design 221
9.3.4 artifact: design subsystem 224
9.3.5 artifact: interface 226
9.3.6 artifact: architecture description (view of the design model) 226
9.3.7 artifact: deployment model 227
9.3.8 artifact: architecture description (view of the deployment model) 228
9.4 workers 229
9.4.1 worker: architect 229
9.4.2 worker: use-case engineer 230
9.4.3 worker: component engineer 230
9.5 workflow 231
9.5.1 activity: architectural design 232
9.5.2 activity: design a use case 249
9.5.3 activity: design a class 255
9.5.4 activity: design a subsystem 263
9.6 summary of design 265
9.7 references 266
chapter 10: implementation 267
10.1 introduction 267
10.2 the role of implementation in the software life cycle 268
10.3 artifacts 269
10.3.1 artifact: implementation model 269
10.3.2 artifact: component 269
10.3.3 artifact: implementation subsystem 272
10.3.4 artifact: interface 274
10.3.5 artifact: architecture description (view of the implementation model) 275
10.3.6 artifact: integration build plan 276
10.4 workers 277
10.4.1 worker: architect 277
10.4.2 worker: component engineer 277
10.4.3 worker: system integrator 279
10.5 workflow 279
10.5.1 activity: architectural implementation 280
10.5.2 activity: integrate system 283
10.5.3 activity: implement a subsystem 285
10.5.4 activity: implement a class 288
10.5.5 activity: perform unit test 289
10.6 summary of implementation 293
10.7 references 293
chapter 11: test 295
11.1 introduction 295
11.2 the role of testing in the software life cycle 296
11.3 artifacts 297
11.3.1 artifact: test model 297
11.3.2 artifact: test case 297
11.3.3 artifact: test procedure 300
11.3.4 artifact: test component 302
11.3.5 artifact: plan test 302
11.3.6 artifact: defect 302
11.3.7 artifact: evaluate test 302
11.4 workers 303
11.4.1. worker: test designer 303
11.4.2 worker: component engineer 303
11.4.3 worker: integration tester 303
11.4.4 worker: system tester 304
11.5 workflow 304
11.5.1 activity: plan test 305
11.5.2 activity: design test 306
11.5.3 activity: implement test 309
11.5.4 activity: perform integration test 310
11.5.5 activity: perform system test 311
11.5.6 activity: evaluate test 311
11.6 summary of testing 313
11.7 references 313
part iii: iterative and incremental development 315
chapter 12: the generic iteration workflow 317
12.1 the need for balance 318
12.2 the phases are the first division of work 319
12.2.1. inception phase establishes feasibility 319
12.2.2 elaboration phase focuses on "do-ability" 320
12.2.3 construction phase builds the system 321
12.2.4 transition phase moves into the user environment 322
12.3 the generic iteration revisited 322
12.3.1 core workfiows repeat in each iteration 322
12.3.2 workers participate in the workfiows 323
12.4 planning precedes doing 324
12.4.1 plan the four phases 325
12.4.2 plan the iterations 326
12.4.3 think long term 327
12.4.4 plan the evaluation criteria 327
12.5 risks affect project planning 328
12.5.1 manage a risk list 328
12.5.2 risks affect the iteration plan 329
12.5.3 schedule risk action 329
12.6 use-case prioritization 330
12.6.1 risks specific to a particular product 331
12.6.2 risk of not getting the architecture right 331
12.6.3 risk of not getting requirements right 332
12.7 resources needed 333
12.7.1 projects differ widely 334
12.7.2 a typical project looks like this 335
12.7.3 complex projects have greater needs 335
12.7.4 new product line calls for experience 336
12.7.5 paying the cost of the resources used 337
12.8 assess the iterations and phases 338
12.8.1 criteria not achieved 338
12.8.2 the criteria themselves 339
12.8.3 the next iteration 339
12.8.4 evolution of the model set 340
chapter 13: inception launches the project 341
13.1 the inception phase in brief 341
13.2 early in the inception phase 342
13.2.1 before the inception phase begins 342
13.2.2 planning the inception phase 343
13.2.3 expanding the system vision 344
13.2.4 setting the evaluation criteria 344
13.3 the archetypal inception iteration workflow 346
13.3.1 introduction to the five core workflows 346
13.3.2 fitting the project into the development environment 348
13.3.3 finding critical risks 348
13.4 execute the core workflows, requirements to test 348
13.4.1 capture the requirements 350
13.4.2 analysis 352
13.4.3 design 353
13.4.5 test 354
13.5 make the initial business case 354
13.5.1 outline business bid 354
13.5.2 estimate return on investment 356
13,6 assess the iteration(s) in the inception phase 356
13.7 planning the elaboration phase 357
13.8 the deliverables for the inception phase 358
chapter 14: the elaboration phase makes the architectural baseline 359
14.1 the elaboration phase in brief 359
14.2 early in the elaboration phase 360
14.2.1 planning the elaboration phase 361
14.2.2 building the team 361
14.2.3 modifying the development environment 361
14.2.4 setting evaluation criteria 361
14.3 the archetypal elaboration iteration workflow 362
14.3.1 capture and refine most of the requirements 363
14.3.2 develop the architectural baseline 364
14.3.3 iterate while the team is small 364
14.4 execute the core workflows---requirernents to test 364
14.4.1 capture the requirements 365
14.4.2 analysis 367
14.4.3 design 372
14.4.4 implementation 374
14.4.5 test 376
14.5 make the business case 377
14.5.1 prepare the business bid 378
14.5.2 update return on investment 378
14.6 assess the iterations in the elaboration phase 378
14.7 planning the construction phase 379
14.8 the key deliverables 380
chapter 15: construction leads to initial operational capability 381
15.1 the construction phase in brief 382
15,2 early in the construction phase 382
15.2.1 staffing the phase 383
15.2.2 setting the evaluation criteria 383
15.3 the archetypal construction iteration workflow 384
15.4 execute the core workflows--requirements to testing 385
15.4.1 requirements 387
15.4.2 analysis 388
15.4.3 design 389
15.4.4 implementation 390
15.4.5 test 391
15.5 controlling the business case 393
15.6 assess the iterations and the construction phase 393
15.7 planning the transition phase 393
15.8 the key deliverables 394
chapter 16: transition completes product release 395
16.1 the transition phase in brief 396
16.2 early in the transition phase 397
16.2.1 planning the transition phase 397
16.2.2 staffing the transition phase 399
16.2.3 setting the evaluation criteria 399
16.3 the core workflows play a small role in this phase 400
16.4 what we do in the transition phase 401
16.4.1 getting the beta release out 401
16.4.2 installing the beta release 402
16.4.3 responding to the test results 402
16.4.4 adapting the product to varied user environments 403
16.4.5 completing the artifacts 404
16.4.6 when does the project end? 404
16.5 completing the business case 405
16.5.1 controlling progress 405
16.5.2 review of the business plan 405
16.6 assess the transition phase 406
16.6.1 assess the iterations and the phase 406
16.6.2 postmortem of the project 407
16.7 planning the next release or generation 407
16.8 the key deliverables 407
chapter 17: making the unified process work 409
17.1 the unified process helps you deal with complexity 409
17.1.1 the life cycle objectives 410
17.1.2 the life cycle architecture 410
17.1.3 initial operational capability 411
17.1.4 product release 411
17.2 the major themes 411
17.3 management leads conversion to unified process 412
17.3.1 the case for action 413
17.3.2 the reengineering directive persuades 413
17.3.3 implementing the transition 414
17.4 specializing the unified process 416
17.4.1 tailoring the process 416
17.4.2 filling in the process framework 417
17.5 relate to the broader community 418
17.6 get the benefits of the unified process 418
17.7 references 419
appendix a: overview of the uml 421
a.1 introduction 421
a.1.1 vocabulary 422
a.1.2 extensibility mechanisms 422
a.2 graphical notation 423
a.2.1 structural things 423
a.2.2 behavioral things 424
a.2.3 grouping things 425
a.2.4 annotational things 425
a.2.5 dependency relationships 425
a.2.6 association relationships 425
a.2.7 generalization relationships 426
a.2.8 extensibility mechanisms 426
a.3 glossary of terms 426
a.4 references 433
appendix b: the unified process-specific extensions of the uml 435
b.1 introduction 435
b.2 stereotypes 435
b.3 tagged values 438
b.4 graphical notation 439
b.5 references 439
appendix c: general glossary 441
c.1 introduction 441
c.2 terms 441
index 451

.　　We give the most space in this book to those activities--requirements, analysis, and design--on which UML places primary emphasis. It is in these fields of emphasis that the process develops the architecture of complex software systems. We do, however, treat the entire process, although in less detail. Still, it is the executable program that finally runs. To get there, a project depends on the efforts of every member of its team as well as the support of the stakeholders. As you will see, the process rests on a tremendous variety of activities. Many artifacts must be produced and kept track of.
　　All the activities must be managed.
　　A complete account of a comprehensive, full life-cycle process is beyond the scope of any one book. Such a book would have to cover design guidelines, templates for artifacts, quality indicators, project management, configuration management, metrics, and more--much more! With the development of on-line access, that "more" is now available, and it can be updated as new developments dictate. For this, we refer you to the Rational Unified Process, a new Web-enabled software product that guides software development teams to more effective software development pracrices. (See http://www, rational.com for more information.) In covering the full software life cycle, the Rational Unified Process extends the Unified Process beyond areas described in this book and provides additional workflows that are not covered in this book or are mentioned only in passing, such as business modeling, project management, and configuration management.
　　History of the Unified Process
　　The Unified Process is balanced because it is the end product of three decades of development and practical use. Its development as a product follows a path (see Figute P. 1) from the Objectory Process (first released in 1987) via the Rational Objectory Process (released in 1997) to the Rational Unified Process (released in 1998). Its development has been influenced by many sources. We don't intend to try to identify them all (we actually don't know what they all are) and leave that for software archeologists to research. However, we will describe the impact of the Ericsson and Rational approaches to the product as well as several other sources.
　　Figure P. 1 The development of the Unified Process. (Versions of the product are denoted in gray rectangles.)
　　The Ericsson Approach
　　The Unified Process has deep roots. To employ the language of Peter F. Drucker, it is a "knowledge-based innovation." "There is a protracted span between the emergence of new knowledge and its distillation into usable technology," he advises us. "Then there is another long period before this new technology appears in the marketplace in products, processes, or services." [1] One reason for this long lead-time is that knowledge-based innovation is grounded on the bringing together of many kinds of knowledge, and this takes time.
　　Another reason is that the people who have to make the new idea effective need time to digest it and spread it to others.
　　As a first step toward illuminating the development of tile Unified Process, let us go back to 1967 and outline more specifically what Ericsson achieved [14], [15], [16]. Ericsson modeled the whole system as a set of interconnected blocks (in UML these are known as "subsystems" and implemented as "components"). They assembled the lowest-level blocks into higher-level subsystems to make the system more manageable. They found the blocks by working through the previously specified traffic cases--now called "use cases." For each use case, they identified the blocks that cooperate to realize it. Knowing the responsibilities of each block, they prepared a specification for it. Their design activities resulted in a set of static block diagrams with their interfaces, and groupings into subsystems. These block diagrams correspond directly to a simplified version of UML class or package diagrams--simplified in that it only showed associations used for communications.
　　The first work product in the design activities was a software architecture description. It was based on understanding the most critical requirements. It described briefly each block and their groupings into subsystems. A set of block diagrams described the blocks and their interconnections. Over the interconnections, signals, that is, a kind of message, were communicated. All messages were described one by one in a message library. The software architecture description and the message library were key documents that guided the development work, but they were also used to present the system to customers. At that time (1968) customers were not used to having software products presented to them by means similar to engineering blueprints.
　　For each use case, the engineers prepared either a sequence diagram or a collaboration diagram (now further developed in the UML). These diagrams showed how the blocks dynamically communicate to realize the use case. They prepared a specification in the form of a state graph (including states and transitions only) and a state-transition graph (a simplified version of the UML activity diagrams). This approach, designing with blocks with well-defined interfaces, was key to the success. Now a new configuration of the system could be created--for instance, for a new customer-by exchanging a block with another one that provided the same interfaces.
　　Now, the blocks were not just subsystems and source-code components; they were compiled into executable blocks, they were installed in the target machine one by one, and it was established that they worked with all the rest of the executable blocks. Beyond that, they must be able to install each new or changed executable block in the field in a running system while it was executing calls for telephone systems operating 100% of the time. One does not shut down such a system just to make changes. It is like changing tires while a car is moving 60 miles an hour.
　　In essence, the approach used was what we today call component-based development. Ivar Jacobson was the originator of this development method. He guided its evolution into a software development process over the many years of the pre-Objectory period.
　　The Specification and Description Language
　　A significant development during this period was the issuance in 1976 by CCITT, the international body for standardization in the telecommunications field, of the Specifi
　　cation and Description Language (SDL) for the functional behavior of telecommunications systems. This standard, significantly influenced by the Ericsson approach, specified a system as a set of interconnected blocks that communicated with each other solely through messages (called "signals" in the standard). Each block owned a set of "processes," which was the SDL term for active classes. A process had instances much as classes do in object-oriented terms. Process instances interacted by messages. It recommended diagrams that were specializations of what UML now calls class diagrams, activity diagrams, collaboration diagrams, and sequence diagrams.
　　Thus, SDL was a specialized object-modeling standard. Periodically updated, it is still in use by more than 10,000 developers and supported by several tool vendors.
　　Developed originally more than 20 years ago, it was far ahead of its time. However, it was developed at a time when object modeling had not matured. SDL will likely be supplanted by the Unified Modeling Language, which was standardized in November 1997.
　　Objectory
　　In 1987 Ivar Jacobson left Ericsson and established Objectory AB in Stockholm.
　　During the next eight years he and his associates developed a process product called Objectory ("Objectory" is an abbreviation of "Object Factory."). They extended it to industries outside of telecommunications and to countries beyond Sweden.
　　Although the concept of the use case had been present in the work at Ericsson, it now had a name (which was introduced at the OOPSLA conference in 1987), a diagramming technique was developed, and the idea was extended to embrace a variety of applications. That it is use cases that drive development became more clear.
　　That it is architecture that guides the developers and informs the stakeholders came to the fore.
　　The successive workflows were represented in a series of models: requirements-use cases, analysis, design, implementation, and test. A model is a perspective of a system. The relationships between the models in this series were important to developers as a way of following a feature from one end of the model series to the other end. In fact, traceability became a prerequisite of use-case-driven development.
　　Developers could trace a use case through the model sequence to the source code or, when problems arose, back again.
　　Development of the Objectory process proceeded in a series of releases, from Objectory 1.0 in 1988 to the first on-line version, Objectory 3.8, in 1995 (an overview of Objectory is presented in [2]).
　　It is important to note that the Objectory product itself came to be viewed as a system. This way of describing the process--as a system product--provided a better way to develop a new version of Objectory from an earlier one. This way of designing Objectory made it easier to tailor it to meet the particular needs of different development organizations. The fact that the Objectory software development process itself was engineered was a unique feature.
　　The experience in developing Objectory also provided insights into how to engineer the processes on which a business in general operates. The same principles were applicable and were incorporated in a 1995 book [3].
　　The Rational Approach
　　Rational Software Corporation acquired Objectory AB in the fall of 1995 and the task of unifying the basic principles underlying the existing software development processes gained new urgency. Rational had developed a number of software development practices, many of which were complementary to those embodied in Objectory. For example, "In 1981, Rational set out to produce an interactive environment that would improve productivity for the development of large software systems," James E. Archer Jr. and Michael T Devlin recalled in 1986 [4]. In this effort, object-
　　oriented design, abstraction, information hiding, reusability, and prototyping were important, they went on to say.
　　Scores of books, papers, and internal documents detail Rational developments since 1981, but perhaps the two most important contributions to process were the emphases on architecture and iterative development. For instance, in 1990 Mike Devlin wrote a vision paper on an architecture-driven iterative development process.
　　Philippe Kruchten, in charge of the Architecture Practice within Rational, authored papers on iteration and architecture.
　　We cite one, an article on an architectural representation in four views: the logical view; the process view; the physical view; and the development view, plus an additional view that illustrates the first four views with uses cases or scenarios [6].
　　The value of having a set of views, rather than trying to cram everything into one type of diagram, grew out of Kruchten's experience on several large projects. Multiple views enabled both stakeholders and developers to find what they needed for their diverse purposes in the appropriate view.
　　Some have perceived iterative development as somewhat chaotic or anarchic.
　　The four-phase approach (inception, elaboration, construction, and transition) was devised to better structure and control progress while iterating. The phases impose order on the iterations. The detailed planning of the phases and ordering of the iterations within phases was a team effort with Walker Royce and Rich Reitman, as well as the continuing participation of Grady Booch and Philippe Kruchten.
　　Booch was on the scene from the very beginning of Rational, and in 1996 in one of his books he cited two "first principles" that bear upon architecture and iteration:
　　· "An architecture-driven style of development is usually the best approach for the creation of most complex software-intensive projects."
　　·"A successful object-oriented project must apply an incremental and iterative process." [7]
　　Rational Objectory Process: 1995-1997
　　At the time of the merger, Objectory 3.8 had shown how a software development process as a product could be developed and modeled. It had designed the original architecture of a software development process. It had identified a set of models that recorded the outcome of the process. In areas such as use-case modeling, analysis,
　　and design, it was well developed. In other areas--requirements management other than use cases, implementation, and test--it was less well developed. Moreover, it contained little on project management, configuration management, deployment, and the preparation of the development environment (tools and process procurement).
　　Now Rational's experience and practices were added to form the Rational Objectory Process 4.1. The phases and the controlled iterative approach, in particular, were added. Architecture was made explicit in the form of an architecture description--the "bible" of the software development organization. A precise definition of architecture was developed. It treated architecture as being the significant parts of the organization of the system. It depicted the architecture as architectural views of the models.
　　Iterative development was advanced from a relatively general concept to a risk-driven approach that put architecture first.
　　At this time UML was in development and was used as the modeling language of the Rational Objectory Process (REP). The authors of this book contributed as the original developers of UML. The process development team, headed by Philippe Kruchten, alleviated some of the weaknesses in ReP by strengthening project management, for instance, based on contributions from Royce [8].
　　Unified Modeling Language The need for a uniform and consistent visual language in which to express the results of the rather numerous object-oriented methodologies extant in the early 1990s had been evident for some time.
　　During this period Grady Beech, for example, was the author of the Beech method [9]. James Rumbaugh was the principal developer at the General Electric Research and Development Center of OMT (Object Modeling Technique) [10] When he joined Rational in October 1994, the two began an effort, in concert with many of Rational's customers, to unify their methods. They released version 0.8 of the Unified Method in October 1995, about the same time that Ivar Jacobsen joined Rational.
　　The three, working together, released Unified Modeling Language 0.9. The effort was expanded to include other methodologists and a variety of companies, including IBM, HP, and Microsoft, each of which contributed to the evolving standard. In November 1997 after going through the standardization process, the Unified Modeling Language version 1.1, was promulgated as a standard by the Object Management Group. For detailed information refer to the User Guide [11] and the Reference Manual [12].
　　UML was used for all models in the Rational Objectory Process.
　　Rational Unified Process
　　During this period Rational acquired or merged with other software tool companies. Each brought to the mix expertise in process areas that further expanded the Rational Objectory process:
　　· Requisite Inc. brought experience in requirements management.
　　· SQA Inc. had developed a test process to go with its test product, adding to Rational's long experience in this field.
　　· Pure-Atria added its experience in configuration management to that of Rational.
　　· Performance Awareness added performance testing and lead testing · Vigortech added expertise in data engineering.
　　The process was also expanded with a new workflow for business modeling, based on [3], that is used to derive requirements from the business processes the software was to serve. It also was extended to design user interfaces driven by use cases (based on work done at Objectory AB).
　　By mid-1998 the Rational Objectory Process had become a full-fledged process able to support the entire software development life cycle. In so doing, it unified a wide variety of contributions, not only by the three present authors but by the many sources from which Rational and the UML were able to draw upon. In June, Rational released a new version of the product, the Rational Unified Process 5.0 [ 13]. Many elements of this proprietary process now become available to the general public for this first time in the form of this book.
　　The name change reflects the fact that unification had taken place in many dimensions: unification of development approaches, using the Unified Modeling Language, and unification of the work of many methodologists--not just at Rational but also at the hundreds of customer sites that had been using the process over many years.
　　Acknowledgments
　　A project of this magnitude is the work of many people, and we would like to acknowledge as many as is practical by name.
　　For Contributions to This Book
　　Birgitte Lonvig prepared the Interbank system example and worked it through all models. This is the primary example used throughout the book.
　　Patrik Jonsson extracted material from the Rational Objectory Process documentation and arranged it in the order of the proposed chapters. He also assisted in the preparation of the examples. In doing so, he contributed many ideas on how best to present the Unified Process.
　　Ware Myers participated in the development of this book from the initial outlines forward. He took first drafts prepared by the lead author and turned them into more readable English prose.
　　Of the reviewers we particularly thank Kurt Bittner, Cris Kobryn, and Earl Ecklund, Jr. In addition, we are most appreciative of the reviews by Walker Royce, Philippe Kruchten, Dean Leffingwell, Martin Griss, Mafia Ericsson, and Bruce Katz.
　　The reviewers also include Pete McBreen, Glenn Jones, Johan Galle, N. Venu Gopal, David Rine, Mary Loomis, Marie Lenzi, Janet Gardner, and some anonymous reviewers, all of whom we want to thank.
　　Terry Quatrani of Rational improved the English in Chapters 1-5. Karen Tongish copyedited the whole book. We thank both of them.
　　In particular, we want to thank Stefan Bylund who reviewed the drafts extensively and suggested improvements in detail, many of which we incorporated. His contributions have substantially increased the quality of the book.
　　Over The Years
　　We also want to thank several people who have over the years helped us to "get the process right" and supported the work in its various forms. Specifically, we would like to thank the following individuals: Stefan Ahlquist, Ali Ali, Gunilla Andersson, Kjell S. Andersson, Sten-Erik Bergner, Dave Bemstein, Kurt Bittner, Per Bjork, Hans Brandtberg, Mark Broms, Stefan Bylund, Ann Carlbrand, Ingemar Carlsson, Margaret Chan, Magnus Christerson, Geoff Clemm, Catherine Conner, Hakan Dahl, Stephane Desjardins, Mike Devlin, Hakan Dyrhage, Susanne Dyrhage, Staffan
　　Ehnebom, Christian Ehrenborg, Maria Ericsson, Gunnar M. Eriksson, Iain Gavin, Carlo Goti, Sam Guckenheimer, Bjorn Gullbrand, Sunny Gupta, Marten Gustafsson, Bjorn Gustafsson, Lars Hallmarken, David Hanslip, Per Hedfors, Barbara Hedlund, Jorgen Hellberg, Joachim Herzog, Kelli Houston, Agneta Jacobsen, Sten Jacobsen, Paer Janssen, Hakan Janssen, Christer Johansson, Ingemar Johnsson, Patrik Jonsson, Dan Jonsson, Bruce Katz, Kurt Katzeff, Kevin Kelly, Anthony Kesterton, Per Kilgren, Rudi Kester, Per Kroll, Ron Krubeck, Mikael Larsson, Bud Lawson, Dean Leffingwetl, Rolf Leidhammar, Hakan Lidstrom, Lars Lindroos, Fredrik Lindstrom,Chris Littlejohns, Andrew Lyons, Jas Madhur, Bruce Malasky, Chris McClenaghan, Christian Meck, Sue Mickel, Jorma Mobrin, Christer Nilsson, Rune Nilsson, Anders Nordin, Jan-Erik Nordin, Roger Oberg, Benny Odenteg, Erik Ornulf, Gunnar Overgaard, Karin Palmkvist, Fabio Peruzzi, Janne Pettersson, Gary Pollice, Tonya Prince, Leslee Probasco, Terry Quatrani, Anders Rockstrom, Walker Royce, Goran Schefte, Jeff Schuster, John Smith, John Smith, Kjell Sorme, Ian Spence, Birgitta Spiridon, Fredrik Stromberg, Goran Sundelof, Per Sundquist, Per-Olof Thysselius, Mike Tudball, Karin Villers, Ctirad Vrana, Stefan Wallin, Roland Wester, Lars Wetterborg, Brian White, Lars Wiktorin, Charlotte Wranne, and Jan Wunsche..
　　In addition, the following people have given the lead author personal support over the years, for which he is highly appreciative: Dines Bjorner, Tore Bingefors, Dave Bulman, Larry Constantine, Goran Hemdal, Bo Hedfors, Tom Love, Nils Lennmarker, Lars-Olof Noren, Dave Thomas, and Lars-Erik Thorelli. Finally, We Would Like to Thank in Particular
　　Mike Devlin, president of Rational Software Corporation, for his belief in the Objectory process as a product to help those developing software worldwide, and for his continued support in using effective software process as a driver for the development of software tools.
　　And lastly, we would like to thank Philippe Kruchten, director of the Rational Unified Process, and all the members of the Rational process team for integrating the best of Objectory with Rational's best practices and the UML, while preserving the values of each. In addition, we could not have reached this objective without Philippe's personal commitment and perseverance to the task of building, quite simply, the best software process the world has ever seen.
　　Process Breaks Through
　　Through this book and its related books, on-line versions, and tools, software development process comes of age. The Unified Process drew its inspiration from many sources. Already it is being widely used. It provides a common medium of process understanding from which management, developers, and stakeholders can draw. Still, much work remains to be done. Developers have to learn unified ways of working. Stakeholders and management have to support them. For many software organizations, the breakthrough is only potential. You can make it actual.
　　Ivar Jacobson
　　Palo Alto, California
　　December 1998
　　ivar@ rational, com
　　References
　　[1] PeterE Drncker, "The Discipline of lnnovation," Harvard Business Review,May-June, 1985; reprinted Nov.-Dec. 1998, pp. 149-157.
　　[2] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard,Object-Oriented Software Engineering: A Use-Case Driven Approach, Reading,MA: Addison-Wesley, 1992.
　　[3] Ivar Jacobson, Maria Ericsson, and Agneta Jacobson, The Object Advantage:Business Process Reengineering with Object Technology, Reading, MA:Addison-Wesley, 1995.
　　[4] James E. Archer Jr. and Michael T. Devlin, "Rational's Experience Using Ada for Very Large Systems," Proceedings of the First International Conference on Ada Programming Language Applications for the NASA Space Station, June, 1986.
　　[6] Philippe B. Kruchten, "The 4 + 1 View Model of Architecture," IEEE Software, November 1995, pp. 42-50.
　　[7] Grady Booch, Object Solutions: Managing the Object-Oriented Project, Reading, MA: Addison-Wesley, 1996.
　　[8] Walker Royce, Software Project Management: A Unified Framework, Reading, MA: Addison-Wesley, 1998.
　　[9] Grady Booch, Object-Oriented Analysis and Design with Applications, Redwood City, CA: Benjamin/Cummings, 1994.
　　[10] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen, Object-Oriented Modeling and Design, Englewood Cliffs, NJ: Prentice Hall, 1991.
　　[11] Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Reading, MA: Addison-Wesley, 1998.
　　[ 12] James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Reading, MA: Addison-Wesley, 1998.
　　[13] Philippe Kruchten, The Rational Unified Process: An Introduction, Reading, MA: Addison-Wesley, 1998.
　　[14] Ivar Jacobson, Concepts for Modeling Large Real Time Systems, Chapter 2, Dissertation, Department of Computer Systems, The Royal Institute of Technology, Stockholm, Sept. 1985.
　　[15] Ivar Jacobson, "Object-Orientation as a Competitive Advantage," American Programmer, Oct. 1992.
　　[16] Ivar Jacobson, "A Large Commercial Success Story with Objects, Succeeding with Objects," Object Magazine, May 1996.