Register your product to gain access to bonus material or receive a coupon.
Unified Modeling Language User Guide, The, 2nd Edition
- By Grady Booch, James Rumbaugh, Ivar Jacobson
- Published May 19, 2005 by Addison-Wesley Professional. Part of the Addison-Wesley Object Technology Series series.
Book
- Sorry, this book is no longer in print.
Description
- Copyright 2005
- Dimensions: 7-3/8" x 9-1/4"
- Pages: 496
- Edition: 2nd
- Book
- ISBN-10: 0-321-26797-4
- ISBN-13: 978-0-321-26797-9
For nearly ten years, the Unified Modeling Language (UML) has been the industry standard for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. As the de facto standard modeling language, the UML facilitates communication and reduces confusion among project stakeholders. The recent standardization of UML 2.0 has further extended the language's scope and viability. Its inherent expressiveness allows users to model everything from enterprise information systems and distributed Web-based applications to real-time embedded systems.
In this eagerly anticipated revision of the best-selling and definitive guide to the use of the UML, the creators of the language provide a tutorial to its core aspects in a two-color format designed to facilitate learning. Starting with an overview of the UML, the book explains the language gradually by introducing a few concepts and notations in each chapter. It also illustrates the application of the UML to complex modeling problems across a variety of application domains. The in-depth coverage and example-driven approach that made the first edition of The Unified Modeling Language User Guide an indispensable resource remain unchanged. However, content has been thoroughly updated to reflect changes to notation and usage required by UML 2.0.
Highlights include:
- A new chapter on components and internal structure, including significant new capabilities for building encapsulated designs
- New details and updated coverage of provided and required interfaces, collaborations, and UML profiles
- Additions and changes to discussions of sequence diagrams, activity diagrams, and more
- Coverage of many other changes introduced by the UML 2.0 specification
With this essential guide, you will quickly get up to speed on the latest features of the industry standard modeling language and be able to apply them to your next software project.
Extras
Related Articles
Grady Booch on Developing the Handbook of Software Architecture
On Architecture: Goodness of Fit
On Architecture: It Is What It Is Because It Was What It Was
On Architecture: Speaking Truth to Power
Sample Content
Online Sample Chapter
An Introduction to UML and Classes
Downloadable Sample Chapter
Download the Sample
Chapter related to this title.
Table of Contents
Preface xiii
Part 1: Getting Started 1
Chapter 1: Why We Model 3
The Importance of Modeling 4
Principles of Modeling 8
Object-Oriented Modeling 10
Chapter 2: Introducing the UML 13
An Overview of the UML 14
A Conceptual Model of the UML 17
Architecture 31
Software Development Life Cycle 33
Chapter 3: Hello, World! 37
Key Abstractions 38
Mechanisms 41
Artifacts 43
Part 2: Basic Structural Modeling 45
Chapter 4: Classes 47
Getting Started 47
Terms and Concepts 49
Common Modeling Techniques 54
Hints and Tips 59
Chapter 5: Relationships 61
Getting Started 62
Terms and Concepts 63
Common Modeling Techniques 69
Hints and Tips 74
Chapter 6: Common Mechanisms 75
Getting Started 76
Terms and Concepts 77
Common Modeling Techniques 84
Hints and Tips 88
Chapter 7: Diagrams 89
Getting Started 90
Terms and Concepts 91
Common Modeling Techniques 96
Hints and Tips 101
Chapter 8: Class Diagrams 103
Getting Started 103
Terms and Concepts 105
Common Modeling Techniques 106
Hints and Tips 113
Part 3: Advanced Structural Modeling 115
Chapter 9: Advanced Classes 117
Getting Started 117
Terms and Concepts 118
Common Modeling Techniques 130
Hints and Tips 131
Chapter 10: Advanced Relationships 133
Getting Started 134
Terms and Concepts 135
Common Modeling Techniques 148
Hints and Tips 149
Chapter 11: Interfaces, Types, and Roles 151
Getting Started 151
Terms and Concepts 153
Common Modeling Techniques 157
Hints and Tips 161
Chapter 12: Packages 163
Getting Started 164
Terms and Concepts 165
Common Modeling Techniques 170
Hints and Tips 174
Chapter 13: Instances 175
Getting Started 175
Terms and Concepts 176
Common Modeling Techniques 182
Hints and Tips 183
Chapter 14: Object Diagrams 185
Getting Started 185
Terms and Concepts 187
Common Modeling Techniques 188
Hints and Tips 191
Chapter 15: Components 193
Getting Started 193
Terms and Concepts 194
Common Modeling Techniques 203
Hints and Tips 205
Part 4: Basic Behavioral Modeling 207
Chapter 16: Interactions 209
Getting Started 210
Terms and Concepts 211
Common Modeling Techniques 221
Hints and Tips 222
Chapter 17: Use Cases 225
Getting Started 225
Terms and Concepts 228
Common Modeling Techniques 236
Hints and Tips 237
Chapter 18: Use Case Diagrams 239
Getting Started 239
Terms and Concepts 241
Common Modeling Techniques 242
Hints and Tips 248
Chapter 19: Interaction Diagrams 249
Getting Started 250
Terms and Concepts 251
Common Modeling Techniques 260
Hints and Tips 264
Chapter 20: Activity Diagrams 267
Getting Started 268
Terms and Concepts 269
Common Modeling Techniques 280
Hints and Tips 284
Part 5: Advanced Behavioral Modeling 285
Chapter 21: Events and Signals 287
Getting Started 287
Terms and Concepts 288
Common Modeling Techniques 293
Hints and Tips 296
Chapter 22: State Machines 297
Getting Started 298
Terms and Concepts 300
Common Modeling Techniques 315
Hints and Tips 318
Chapter 23: Processes and Threads 319
Getting Started 320
Terms and Concepts 321
Common Modeling Techniques 326
Hints and Tips 330
Chapter 24: Time and Space 331
Getting Started 331
Terms and Concepts 332
Common Modeling Techniques 335
Hints and Tips 338
Chapter 25: State Diagrams 339
Getting Started 340
Terms and Concepts 341
Common Modeling Techniques 343
Hints and Tips 347
Part 6: Architectural Modeling 349
Chapter 26: Artifacts 351
Getting Started 351
Terms and Concepts 352
Common Modeling Techniques 355
Hints and Tips 360
Chapter 27: Deployment 361
Getting Started 361
Terms and Concepts 362
Common Modeling Techniques 366
Hints and Tips 368
Chapter 28: Collaborations 369
Getting Started 369
Terms and Concepts 371
Common Modeling Techniques 376
Hints and Tips 382
Chapter 29: Patterns and Frameworks 383
Getting Started 383
Terms and Concepts 385
Common Modeling Techniques 389
Hints and Tips 394
Chapter 30: Artifact Diagrams 395
Getting Started 395
Terms and Concepts 396
Common Modeling Techniques 398
Hints and Tips 407
Chapter 31: Deployment Diagrams 409
Getting Started 409
Terms and Concepts 411
Common Modeling Techniques 413
Hints and Tips 419
Chapter 32: Systems and Models 421
Getting Started 421
Terms and Concepts 423
Common Modeling Techniques 426
Hints and Tips 428
Part 7: Wrapping Up 431
Chapter 33: Applying the UML 433
Transitioning to the UML 433
Where to Go Next 435
Appendix A: UML Notation 437
Appendix B: Rational Unified Process 443
Glossary 451
Index 463
Preface
The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML gives you a standard way to write a system's blueprints, covering conceptual things such as business processes and system functions, as well as concrete things such as classes written in a specific programming language, database schemas, and reusable software components.
This book teaches you how to use the UML effectively.
This book covers UML version 2.0.
Goals
In this book, you will
- Learn what the UML is, what it is not, and why the UML is relevant to the process of developing software-intensive systems.
- Master the vocabulary, rules, and idioms of the UML and, in general, learn how to "speak" the language effectively.
Understand how to apply the UML to solve a number of common modeling problems.
The user guide provides a reference to the use of specific UML features. However, it is not intended to be a comprehensive reference manual for the UML; that is the focus of another book, The Unified Modeling Language Reference Manual, Second Edition (Rumbaugh, Jacobson, Booch, Addison-Wesley, 2005).The user guide describes a development process for use with the UML. However, it is not intended to provide a complete reference to that process; that is the focus of yet another book, The Unified Software Development Process (Jacobson, Booch, Rumbaugh, Addison-Wesley, 1999).
Finally, this book provides hints and tips for using the UML to solve a number of common modeling problems, but it does not teach you how to model. This is similar to a user guide for a programming language that teaches you how to use the language but does not teach you how to program.
Audience
The UML is applicable to anyone involved in the production, deployment, and maintenance of software. The user guide is primarily directed to members of the development team who create UML models. However, it is also suitable to those who read them, working together to understand, build, test, and release a software-intensive system. Although this encompasses almost every role in a software development organization, the user guide is especially relevant to analysts and end users (who specify the required structure and behavior of a system), architects (who design systems that satisfy those requirements), developers (who turn those architectures into executable code), quality assurance personnel (who verify and validate the system's structure and behavior), librarians (who create and catalogue components), and project and program managers (who generally wrestle with chaos, provide leadership and direction, and orchestrate the resources necessary to deliver a successful system).
The user guide assumes a basic knowledge of object-oriented concepts. Experience in an object-oriented programming language or method is helpful but not required.
How to Use This Book
For the developer approaching the UML for the first time, the user guide is best read linearly. You should pay particular attention to Chapter 2, which presents a conceptual model of the UML. All chapters are structured so that each builds upon the content of the previous one, thus forming a linear progression.For the experienced developer seeking answers to common modeling problems using the UML, this book can be read in any order. You should pay particular attention to the common modeling problems presented in each chapter.
Organization and Special Features
The user guide is organized into seven parts:
- Part 1Getting Started
- Part 2Basic Structural Modeling
- Part 3Advanced Structural Modeling
- Part 4Basic Behavioral Modeling
- Part 5Advanced Behavioral Modeling
- Part 6Architectural Modeling
- Part 7Wrapping Up
The user guide contains two appendices: a summary of the UML notation and a summary of the Rational Unified Process. A glossary of common terms is also provided. An index follows.
Each chapter addresses the use of a specific UML feature, and most are organized into the following four sections:
- Getting Started
- Terms and Concepts
- Common Modeling Techniques
- Hints and Tips
The third section introduces and then solves a set of common modeling problems. To make it easy for you to browse the guide in search of these use cases for the UML, each problem is identified by a distinct heading, as in the following example.
Modeling Architectural Patterns
Each chapter begins with a summary of the features it covers, as in the following example.
In this chapter
- Active objects, processes, and threads
- Modeling multiple flows of control
- Modeling interprocess communication
- Building thread-safe abstractions
Similarly, parenthetical comments and general guidance are set apart as notes, as in the following example.
Note:
Abstract operations map to what C++ calls pure virtual operations; leaf operations
in the UML map to C++ nonvirtual operations.
The UML is semantically rich. Therefore, a presentation about one feature may naturally involve another. In such cases, cross references are provided in the left margin, as on this page.
Blue highlights are used in figures to indicate explanations about a model, as opposed to the model itself, which is always shown in black. Code is distinguished by displaying it in a monospace font, as in this example.Acknowledgement. The authors wish to thank Bruce Douglass, Per Krol, and Joaquin Miller for their assistance in reviewing the manuscript of the second edition.
A Brief History of the UML
The first object-oriented language is generally acknowledged to be Simula-67, developed by Dahl and Nygaard in Norway in 1967. This language never had a large following, but its concepts were a major inspiration for later languages. Smalltalk became widely available in the early 1980s, followed by other object-oriented languages such as Objective C, C++, and Eiffel in the late 1980s. Object-oriented modeling languages appeared in the 1980s as methodologists, faced with a new genre of object-oriented programming languages and increasingly complex applications, began to experiment with alternative approaches to analysis and design. The number of object-oriented methods increased from fewer than 10 to more than 50 during the period between 1989 and 1994. Many users of these methods had trouble finding a modeling language that met their needs completely, thus fueling the so-called method wars. A few methods gained prominence, including Booch's method, Jacobson's OOSE (Object-Oriented Software Engineering), and Rumbaugh's OMT (Object Modeling Technique). Other important methods included Fusion, Shlaer-Mellor, and Coad-Yourdon. Each of these was a complete method, although each was recognized as having strengths and weaknesses. In simple terms, the Booch method was particularly expressive during the design and construction phases of projects; OOSE provided excellent support for use cases as a way to drive requirements capture, analysis, and high-level design; and OMT was most useful for analysis and data-intensive information systems.
A critical mass of ideas started to form by the mid 1990s when Grady Booch (Rational Software Corporation), James Rumbaugh (General Electric), Ivar Jacobson (Objectory), and others began to adopt ideas from each other's methods, which collectively were becoming recognized as the leading object-oriented methods worldwide. As the primary authors of the Booch, OMT, and OOSE methods, we were motivated to create a unified modeling language for three reasons. First, our methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying our methods, we could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Third, we expected that our collaboration would yield improvements for all three earlier methods, helping us to capture lessons learned and to address problems that none of our methods previously handled well.
As we began our unification, we established three goals for our work:
- To model systems, from concept to executable artifact, using object-
- oriented techniques
- To address the issues of scale inherent in complex, mission-critical systems
- To create a modeling language usable by both humans and machines
Devising a language for use in object-oriented analysis and design is not unlike designing a programming language. First, we had to constrain the problem: Should the language encompass requirements specification? Should the language be sufficient to permit visual programming? Second, we had to strike a balance between expressiveness and simplicity. Too simple a language would limit the breadth of problems that could be solved; too complex a language would overwhelm the mortal developer. In the case of unifying existing methods, we also had to be sensitive to the installed base. Make too many changes and we would confuse existing users; resist advancing the language and we would miss the opportunity to engage a much broader set of users and to make the language simpler. The UML definition strives to make the best trade-offs in each of these areas.
The UML effort started officially in October 1994 when Rumbaugh joined Booch at Rational. Our project's initial focus was the unification of the Booch and OMT methods. The version 0.8 draft of the Unified Method (as it was then called) was released in October 1995. Around the same time, Jacobson joined Rational and the scope of the UML project was expanded to incorporate OOSE. Our efforts resulted in the release of the UML version 0.9 documents in June 1996. Throughout 1996, we invited and received feedback from the general software engineering community. During this time, it also became clear that many software organizations saw the UML as strategic to their business. We established a UML consortium, with several organizations willing to dedicate resources to work toward a strong and complete UML definition. Those partners contributing to the UML 1.0 definition included Digital Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments, and Unisys. This collaboration resulted in the UML 1.0, a modeling language that was well-defined, expressive, powerful, and applicable to a wide spectrum of problem domains. Mary Loomis was instrumental in convincing the Object Management Group (OMG) to issue a request for proposals (RFP) for a standard modeling language. UML 1.0 was offered for standardization to the OMG in January 1997 in response to their RFP.
Between January 1997 and July 1997, the original group of partners was expanded to include virtually all of the other submitters and contributors of the original OMG response, including Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, PTech, Reich Technologies, Softeam, Sterling Software, and Taskon. A semantics task force was formed, led by Cris Kobryn of MCI Systemhouse and administered by Ed Eykholt of Rational, to formalize the UML specification and to integrate the UML with other standardization efforts. A revised version of the UML (version 1.1) was offered to the OMG for standardization in July 1997. In September 1997, this version was accepted by the OMG Analysis and Design Task Force (ADTF) and the OMG Architecture Board and then put up for vote by the entire OMG membership. UML 1.1 was adopted by the OMG on November 14, 1997.
For several years, UML was maintained by an OMG Revision Task Force, which produced versions 1.3, 1.4, and 1.5. From 2000 to 2003, a new and expanded set of partners produced an updated specification of UML, version 2.0. This version was reviewed for a year by a Finalization Task Force (FTF) headed by Bran Selic of IBM, and the official version of UML 2.0 was adopted by the OMG in early 2005. UML 2.0 is a major revision of UML 1 and includes a large number of additional features. In addition, many changes were made to previous constructs based on experience with the previous version. The actual UML specification documents are found on the OMG Website at www.omg.org.
UML is the work of a large number of individuals, and the ideas in it come from a wide range of previous works. It would be a major historical research project to reconstruct a complete list of sources, and even more difficult to identify the many predecessors who have influenced UML in manners large and small. As with all scientific research and engineering practice, UML is a small hill atop a large mountain of previous experience.
Index
Download the Index
file related to this title.