Home > Store > Software Development & Management > Object Technology

UML Explained

Register your product to gain access to bonus material or receive a coupon.

UML Explained


  • Your Price: $27.99
  • List Price: $34.99
  • Usually ships in 24 hours.




  • Copyright 2001
  • Dimensions: 7-3/8x9-1/4
  • Pages: 176
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-72182-1
  • ISBN-13: 978-0-201-72182-9

UML Explained is an approachable, non-technical introduction to the Unified Modeling Language (UML), the standard graphical notation for modeling the elements, structure, and behaviors of object-oriented software systems.

Assuming no prior knowledge of the UML, object-oriented design, or programming fundamentals, this book fully explains basic concepts and terminology such as objects, classes, and use cases. It shows how the UML integrates with an iterative and incremental process. Numerous sample UML diagrams and a running example throughout the book help you understand how to apply the UML to real-world software development. Also included is a comprehensive glossary of important terms.

You will learn about such essentials as:

  • The importance of visual modeling
  • How the UML identifies objects and classes
  • Capturing requirements and defining use cases with the UML
  • How to extend the UML and enhance visual models
  • Modeling the details of object behavior with activity diagrams and statechart diagrams
  • Component and deployment diagrams

Whether you are a non-technical professional who needs to understand software development activities within the workplace or a system designer who has never worked with the UML before, UML Explained is the perfect place to start.


Sample Content

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:

Table of Contents


Organization of This Book.



1. Why the UML?

2. The UML and Process.

3. Identifying Relevant Real-World Things.

4. Capturing Requirements.

5. Expressing How Things Work Together.

6. Refining the Structure of Things.

7. Describing Flows.

8. Tracking the Lives of Things.

9. Showing How Groups of Things Work Together.

10. Describing How Things Will Be Built.




When I started seriously considering writing a proposal for a book about the Unified Modeling Language (UML), Amazon.com listed about 62 books whose titles contained "UML." By my reckoning, 61 of those books were aimed at programmers and other highly technically oriented people. The other one introduced its example system more than halfway through the book and, a few pages into that chapter, started showing figures with way too many things in them for a beginner to be able to handle. It became clear to me that what was missing was a book that approaches the UML from the standpoint of what relatively nontechnical people need to understand in doing their jobs--like how to capture requirements--rather than starting with the diagrams, as most of these other UML books do.

I wrote this book literally for "the rest of us," people who see the UML from the outside looking in. UML Distilled (Fowler and Scott, Addison-Wesley, 1997), for instance, made certain assumptions about its readers, namely, that they were comfortable with object-oriented terminology and concepts and that, for the most part, they were already using one or another of the approaches designed by the "three amigos," the creators of the UML--Grady Booch, Jim Rumbaugh, and Ivar Jacobson. For every set of modelers and analysts and developers who sank their teeth into Martin Fowler's brilliantly conceived book, though, there were at least a few people who wanted to know about this cool language but didn't quite know where to start. If you're in that latter group, this book may be for you.

I'm not assuming any knowledge of object orientation (OO). (Note that although the UML certainly is applicable in non-OO contexts, such as data modeling, the language was explicitly designed for use with OO.) If you find yourself reading a definition you're already familiar with, you should be able to skip that paragraph (or subsection or section) without any problem. I've also focused on capturing what I think are the most important aspects of the UML for people who probably aren't at the center of development efforts but still need to know what's what. The UML is a pretty big language; I suggest you visit my UML Dictionary (http://usecasedriven.com/UML.htm) and the UML Resource Center (http://www.rational.com/UML) if you want to explore it in depth.

I made my living as a technical writer for 16 years, translating complicated subject matter into reader-friendly documents and manuals. Now I make my living as a trainer and mentor, teaching people about the UML and about the approach to software development that Use Case Driven Modeling with UML (Rosenberg and Scott, Addison-Wesley, 1999) advocates. I'd like to think that this book reflects my years of experience.

Organization of This Book

Chapter 1, Why the UML?, describes why it's important to learn about the UML. This includes an explanation of the crucial nature of visual modeling. The chapter also offers some history about how the UML evolved and an overview of the key underlying principles of the language.

Chapter 2, The UML and Process, explains that even though the UML is technically process independent, it's been explicitly designed to work within the context of an iterative and incremental process. This discussion includes an overview of the Unified Process and a look at how the phrases "use case driven," "architecture-centric," and "iterative and incremental" will appear, in one form or another, throughout the rest of the book.

Chapter 3, Identifying Relevant Real-World Things, describes how a project team uses the UML in identifying, and beginning to refine, the things and concepts in the real world of relevance to the problem that the team is trying to solve with the new system. This chapter introduces The Internet Bookstore, a proposed online bookstore that will serve as a running example throughout the rest of the book.

Chapter 4, Capturing Requirements, describes how people can use what are known as "use cases," which are scenarios that include user actions and system responses, to explore, negotiate, and refine functional requirements. The chapter also addresses the role that prototyping plays in the development and refinement of use cases.

Chapter 5, Expressing How Things Work Together, describes how a project team explores how objects work together to address the behavior specified by use cases, as well as other required system behavior. This includes a discussion of robustness analysis, which uses extensions to the UML that are specific to the Unified Process.

Chapter 6, Refining the Structure of Things, describes the tasks involved in refining and expanding the domain model, which contains the real-world things and concepts first discussed in Chapter 3, and how this effort happens in response to the work involved in modeling interactions (discussed in Chapter 5).

Chapter 7, Describing Flows, describes how you can use the UML to describe business and process workflows. The chapter also discusses how you capture the behavior of a system that can have multiple activities occurring at once.

Chapter 8, Tracking the Lives of Things, describes how the UML represents the lifetimes of objects as they carry out the work of the system. This discussion includes a look at how certain kinds of objects can exist in more than one state at the same time.

Chapter 9, Showing How Groups of Things Work Together, describes how a team can use various UML constructs and diagrams to illustrate how groups of things will work together in the system, on a conceptual level. This includes the UML definitions of terms such as "pattern" and "framework" that are increasingly important in the realm of software development.

Chapter 10, Describing How Things Will Be Built, describes the ways that one shows how the system being designed will actually be built, in terms of packages of software called "components," and how those components will be geographically distributed in the new system.

The book also includes a glossary, which contains definitions for all the terms introduced in the body of the text, and a complete index.


This book has been in the works for a long time.

The story starts in the spring of 1996. I was living in Dallas, getting a little bored making my living as a technical writer, cranking out software documentation for programmers I'd never meet. I decided to approach Rational about getting some kind of job that would get me closer to actual customers.

That conversation didn't lead to anything in the way of a job, but it did lead to me getting a copy of the 0.8 version of the documentation set for what was then called the Unified Method, written by Grady Booch (who I'd heard of) and James Rumbaugh (who I hadn't). After a quick glance at the densely packaged paragraphs and the scary diagrams (one had 15 boxes and 19 lines), I put it aside.

My relentlessly curious nature caused me to pick up the book again soon after that. Then I spent several hours trying to make sense out of it. I finally realized that I was looking at something fairly significant, and that the only way I'd be able to really understand it would be to rewrite it. I was just beginning to follow the comp.object newsgroup on the Internet, so I decided, on a lark, to post a query that read something like this: "What would you think if a professional writer rewrote this material?"

Grady Booch wrote back and said "Go for it!"

This was more than a little disorienting. On the one hand, I was encouraged to get a positive response; on the other hand, I thought, "Great. The first thing I did is annoy Grady Booch." When I asked him what he meant, though, he told me that he and Jim and Ivar Jacobson (whose name would appear on the cover of the next version of the Unified Method documentation) were all likely to write 600-page books, and there was a good chance they wouldn"t be ready for a long time. Then he said that if I were to write a concise guide to the Unified Method--say, 150 pages--people would buy it.

So, I put together a proposal and sent it to Addison-Wesley, on my birthday (never mind which one). I was pretty dubious about it, given that I knew almost nothing about object orientation, but I figured I had nothing to lose.

Over the next six months, the proposal didn't get accepted, but it wasn't exactly rejected either. I decided to move to San Francisco at the end of 1996, and soon after that, interesting things started happening.

I met the editor to whom I'd submitted the proposal, Carter Shanklin, at Rational's user conference early in 1997. He said that my proposed book wasn't going to be viable, but also that he was ready to do a deal for the first book about what was now called the Unified Modeling Language (UML), and that he'd be interested in having me involved in some way.

Around that time, I met Jim and Ivar. (Grady was at Oracle, so unfortunately I didn't get a chance to meet him then and thank him for helping me get to that point. Oddly enough, I was working for Oracle at the time.) There were various ideas bouncing around about how this book was going to get done, but in the end, Booch, Jacobson, and Rumbaugh weren't directly involved in the production of the book. Instead, Carter brought Martin Fowler, whose recently published Analysis Patterns was already getting great reviews, and myself together to see if the chemistry was right for cranking a book out in, oh, four months.

I had no idea whether we could come anywhere near meeting that deadline, but I figured I'd give it a shot. Martin already had about half the book written when we got started, which helped considerably. The first thing I did was take a chunk of about 75 pages of text and diagrams and turn it into a reviewable piece of material, making decisions about subsections and mixing up paragraph lengths and many other things--over a period of three days, which included one full day of work for Oracle--and we were off to the races. I guess UML Distilled came out pretty well, all things considered.

After the book came out, I wanted to publish something in my own voice, so I put together the first version of my UML Dictionary. This was based on the official documentation that Rational submitted to the Object Management Group (OMG) in the spring of 1997, when it was first seeking approval of the UML as a standard. The text was still fairly stiff, but at least I was getting a good handle on the material.

The Dictionary led to another book deal (Use Case Driven Object Modeling, with Doug Rosenberg), and now, here I am with my first solo book.


I'd like to thank the Academy...

Let's start again.

I'd like to thank the several thousand people who've played crucial roles in my development as an author. In alphabetical order...

Maybe not.

I'd like to extend special thanks to the following Lucky 13: Guy and Nancy Scott, who had the good sense to put me on the right path and then (mostly) stay out of the way; Jonathan Leach, intellectual foil supreme; Lisa Silipigni, who helps me remember every day to fight the good fight; Grady Booch, without whom I wouldn't have been able to write this book; Martin Fowler, for letting me produce the world's best UML book; Carter Shanklin, Paul Becker, and Ross Venables, past and present representatives of a class organization, Addison-Wesley; Doug Rosenberg, who supplied the inspiration for the running example, taught me how to do robustness analysis, and provides me a healthy living as a UML trainer and mentor; Laura Danoff, for at least trying to read my other books; Robert Pirsig, who posed the questions that keep me going; and Hunter Faires, the greatest teacher ever.

Kendall Scott
Harrison, Tennessee
February 2001



abstract class
defined 75
example 76
notation 76
defined 59, 89
examples 64, 90, 103
notation 60, 61, 62, 63, 90
active class
defined 96
example 97
notation 97
active object
defined 96
example 97
notation 97
defined 89
examples 90
notation 90
activity diagram
defined 94
example 95
defined 39
examples 40
notation 40
addOnly property, 79
and classes 26
notes 35
defined 27
examples 30
notation 29, 30
alternate course of action
defined 43
examples 44, 46
analysis class
and packages 72
types 53
analysis model
analysis classes 53
Analysis workflow 15
and architecture 15
defined 14
packages of classes 37
robustness diagrams 72
and use case model 13
use cases 49
analysis package 72, 73
Analysis workflow
activities 14
and frameworks 117
robustness analysis 53
and Unified Process phases 15
architectural baseline 11, 19
architecture 7
architecture-centric 11
defined 25
examples 26, 27, 28
name 26, 27
navigation 27
notation 26
association class
defined 30
example 33
notation 32
defined 22
details 79
examples 22
full form 78

balking message 72
basic course of action
defined 43
examples 43, 45
behavior allocation 88
black-box testing 17, 52
Booch method 6
Booch, Grady xiii, xvi, 4, 6
boundary object
defined 54
examples 55, 56, 57
and Model-View-Controller pattern 118
notation 54
defined 90
example 91
notation 91

call action
defined 60
examples 61
notation 60
call event 99
candidate architecture 10, 11
change event 100
changeable property 79
defined 28
examples 32
versus component 122
defined 23
examples 24, 38
interface 84
notation 23, 24, 38
notation (described) 38
versus object 23
and use case text 44
class diagram
defined 32
example 34
defined 111
examples 112, 118
and frameworks 117
notation 112
collaboration diagram
defined 70
elements 70
example 71
versus class 122
defined 121
examples 123, 125
and nodes 126
notation 122
versus package 121
component diagram
defined 124
examples 125
locationtagged value 128
composite state
defined 106
examples 107, 110
notation 107
composition 119, 125
concurrent property 80
concurrent substate
defined 109
examples 110
notation 110
defined 82
examples 83
notation 82
Construction phase
Analysis workflow 15
Design workflow 16
Implementation workflow 16
Requirements workflow 14
tasks 12
Test workflow 17
control object
defined 54
examples 56, 58
and Model-View-Controller pattern 118
notation 55
create action
defined 61
notation 62
cycle 9

data hiding 22
deferred event 106
and components 124
defined 76
examples 77, 125
notation 77
deployment component
defined 123
example 124
deployment diagram
defined 127
example 127
deployment model
architecture 15
defined 15
deployment diagrams 128
Design workflow 15
and use case model 13
use cases 50
deployment package 128
deployment view
defined 8
deployment model 15
design class 87
design model
and analysis model 66
architecture 15
defined 15
Design workflow 15
and use case model 13
use cases 50
design package 74, 87, 98, 110, 129
design pattern
defined 114
example 116
sample behavior 117
sample structure 116
design view
analysis model 15
defined 7
design model 15
Design workflow
activities 15
collaboration diagrams 70
sequence diagrams 65
and Unified Process phases 15
destroy action
defined 62
notation 63
document stereotype 123
domain model
defined 38
refining and expanding 75
and use case text 44

Elaboration phase
Analysis workflow 15
Design workflow 16
Implementation workflow 16
Requirements workflow 14
tasks 11
Test workflow 17
encapsulation 22
entity object
defined 54
example 58
and Model-View-Controller pattern 118
notation 54
entry action 105
defined 99
examples 103, 104, 107
exceptional flow of events
defined 43
examples 44, 46
exceptions 63
executable stereotype 123
execution component 123
exit action 106
defined 47
example 48
notation 48
extension points
defined 47
example 48

file stereotype 123
final state
defined 105
on activity diagram 94
on statechart diagram 105
flowchart 91
focus of control 65
defined 92
example 93
notation 92
forward engineering 3
Fowler, Martin xiii, xvii
defined 117
example 118
notation 118
frozen property 79

defined 28
examples 32, 50, 76
notation 31, 49
and use cases 48
guard condition
defined 91, 103
examples 104
notation 103
guarded property 80

history state
defined 108
example 109
notation 108

implementation model
architecture 16
component diagrams 128
defined 16
Implementation workflow 16
and use case model 13
use cases 50
implementation package 128
implementation view
defined 8
implementation model 16
Implementation workflow
activities 16
and Unified Process phases 16
Inception phase
Analysis workflow 15
Design workflow 15
Implementation workflow 16
Requirements workflow 14
tasks 10
Test workflow 17
defined 46
examples 47
notation 47
increment 17
inheritance 29
Initial Operational Capability|
major milestone 12
initial state
defined 105
on activity diagram 94
on statechart diagram 105
instance 23
interaction diagrams 71
class 84
component 121
defined 84
examples 85, 123
notation 84, 122
internal transition 106
isQuery property 80
iteration 17
iterative and incremental
defined 17
illustrated 18

Jacobson, Ivar xiii, xvi, 4, 5, 6
defined 92
example 93
notation 92

library stereotype 123
Life-Cycle Architecture major milestone 12
Life-Cycle Objectives major milestone 11
lifeline 60, 65
location tagged value 128
lollipop notation 84, 122

main flow of events
defined 43
examples 43, 45
major milestone
defined 9
Initial Operational Capability 12
Life-Cycle Architecture 12
Life-Cycle Objectives 11
Product Release 12
defined 114
and frameworks 117
defined 90
example 91
notation 91
defined 59
examples 66, 67, 68
on sequence diagrams 65
defined 22
versus operation 23
method wars 4
construction 3
defined 1
documentation 3
good qualities 3
specification 2
visualization 2
Model-View-Controller architectural pattern 117, 118
multiple inheritance 29
allowable values 27
and associations 27
and attributes 79
examples 28
MVC pattern 117

N-ary association 26
navigation 27
defined 126
examples 126, 127
notation 126
defined 35
examples 36
notation 36

versus class 23
defined 21
essential aspects 21
notation 34
object diagram
defined 34
example 35
object flow
defined 94
examples 97
Object Management Group (OMG) xvii, 7
Object Modeling Technique (OMT) 5
Objectory process 4
OMG xvii, 7
defined 23
details 81
full form 80

versus component 121
defined 36
examples 37, 51, 73, 74, 87, 98, 110, 118, 128, 129
notation 37, 50
parameterized collaboration
defined 114
notation 115
defined 28
example 32
path name
defined 38
examples 38
architectural 117
defined 114
design 114
notation 115
Construction 12
defined 9
Elaboration 11
Inception 10
Transition 12
physical diagrams 128
polymorphism 29
private visibility
defined 78
examples 78
defined 96
stereotype 98
process view
analysis model 15
defined 8
design model 15
Product Release major milestone 12
protected visibility
defined 78
examples 78
prototyping 14, 51
Proxy design pattern
behavior 117
illustrated 116
structure 116
public visibility
defined 78
examples 78

defined 84, 112
examples 113, 123
notation 113
Requirements workflow
activities 13
prototyping 14
and Unified Process phases 14
defined 24
notation 25
return action
defined 60
example 61
notation 61
reverse engineering
defined 3
and use cases 51
robustness analysis
defined 53
example 59
rules 56
robustness diagram
defined 55
example 59
and packages 73
defined 27
examples 28
round-trip engineering 3
Rumbaugh, Jim xiii, xvi, 4, 5, 6

self-aggregation 30
defined 102
example 103
notation 102
send action
defined 63
example 64
notation 63
sequence diagram
defined 64
elements 65
example 69
timing constraint 72
sequence numbers 70
sequential property 80
sequential substate
defined 106
examples 107
notation 107
defined 63, 99
examples 65
notation 64
single inheritance 29
source state 101
Standard Template Library (STL) 85
defined 100
examples 101
notation 100
state diagram
defined 104
example 105
state machine 104
statechart diagram
defined 104
example 105
defined 81
examples 82
notation 81
Unified Process 82
STL 85
defined 28
examples 32
concurrent 109
defined 106
examples 107, 110
sequential 106
substitutability 29
defined 118
examples 119
notation 119
defined 28
example 32
defined 94
examples 96
synchronization bar
defined 92
examples 93
notation 92
defined 118
example 119
notation 119

table stereotype 123
tagged value
defined 83
examples 83
notation 83
target state 101
template class
defined 85
example 86
notation 86
test model
defined 16
Test workflow 17
and use case model 13
use cases 52
Test workflow
activities 16
and Unified Process phases 17
defined 96
stereotype 98
time event 99
time expression
defined 71
example 72
timeout message 72
timing constraint
defined 71
example 72
timing mark
defined 71
example 72
traceability 73
defined 92, 101
examples 102, 103
notation 101, 102
Transition phase
Analysis workflow 15
Design workflow 16
Implementation workflow 16
Requirements workflow 14
tasks 12
Test workflow 17
triggerless transition 94, 101

Unified Method xvi, 6
Unified Process
Analysis workflow 14
basic models 13
Construction phase 12
Design workflow 15
Elaboration phase 11
extensions 82
Implementation workflow 16
Inception phase 10
major milestones 10
and Objectory 5
phases 10
Requirements workflow 13
Test workflow 16
Transition phase 12
Unified Process-Specific Extensions 82
use case
alternate course of action 43
basic course of action 43
defined 40
examples 41, 43, 45
exceptional flow of events 43
and extend relationship 47
generalization 48
and include relationship 46
main flow of events 43
notation 41
and prototyping 51
use case diagram
defined 41
example 42
notation 42
use case driven 87, 98, 110
use case model
and architecture 14
contents 41
as contractual agreement 46
defined 13
and Requirements workflow 14
use case realization--analysis 112
use case view
defined 7
use case model 14
user manual 51

defined 7
types 8
defined 77
examples 78
levels 78

white-box testing 17, 59
work product component
defined 123
examples 124
Analysis 14
defined 13
Design 15
Implementation 16
Requirements 13
Test 16


Submit Errata

More Information

Unlimited one-month access with your purchase
Free Safari Membership