UML Explained

Paperback (Print)
Buy Used
Buy Used from
(Save 41%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 94%)
Other sellers (Paperback)
  • All (22) from $1.99   
  • New (5) from $18.69   
  • Used (17) from $1.99   


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.


Read More Show Less

Editorial Reviews

From Barnes & Noble
The Barnes & Noble Review
There are 70-plus books on UML, almost all aimed at programmers, software engineers, and software architects. Of course, many "less technical" people are also involved in modeling and designing software: domain specialists, requirements specialists, and managers, to name a few. What's more, understanding UML gives you insight into all your processes, even those that aren't translated into software. There's a huge need for a UML beginner's book for "the rest of us."

Enter UML Explained. Kendall Scott cowrote one of the world's most honored UML books, UML Distilled. He brings nearly two decades of experience as a writer, trainer, and mentor to the task of explaining UML to novices. He's done a splendid job.

The chapter headings tell you how accessible this book will be. "Identifying Relevant Real-World Things." "Expressing how Things Work Together." "Refining the Structure of Things." "Describing how Things Will Be Built." And the chapters behind the headings don't disappoint. By the time you're finished, you'll be comfortable with all of UML's key components. You'll know how to capture requirements and define use cases. You'll know how to model the details of object behavior, components, and deployment. In short, you'll be effective with UML. (Bill Camarda)

Bill Camarda is a consultant and writer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

A non-technical introduction to the Unified Modeling Language (UML), the standard graphical notation for modeling the elements, structure, and behaviors, or object-oriented software systems. The author explains the basic concepts of objects and classes, and shows how the UML integrates within an iterative and incremental process. Annotation c. Book News, Inc., Portland, OR (
Read More Show Less

Product Details

  • ISBN-13: 9780201721829
  • Publisher: Addison-Wesley
  • Publication date: 3/27/2001
  • Pages: 176
  • Product dimensions: 7.40 (w) x 9.00 (h) x 0.40 (d)

Meet the Author

Kendall Scott is a UML trainer and consultant. With more than sixteen years of experience as a technical writer, he is skilled in converting complex, technical material into understandable and easy-to-use manuals.

Read More Show Less

Read an Excerpt

Chapter 1: Why the UML?

Let's start off by looking at why you should learn about the Unified Modeling Language (UML).

Why Model Software?

Software just isn't getting any easier to develop, despite the best efforts of computer language inventors, tool developers, and process gurus. Even relatively small systems tend to have large amounts of complexity. This is what leads people to develop models, which are simplifications of reality that help them understand the complexity inherent in software.

Of course, a wide variety of models have been in use within various engineering disciplines for a long time. Aerospace engineers rely heavily on models that describe the forces acting on an airplane; electrical engineers use very large models in designing telephone switching systems; civil engineers would be lost without their blueprints. Models taking other forms, such as the simulations used in high finance and the storyboarding that Hollywood directors use, also play very important roles.

The UML has been designed to help the participants in software development efforts build models that will enable the team to visualize the system, specify the structure and behavior of that system, construct the system, and document the decisions made along the way.


Models help a software development project team visualize the system they need to build that will satisfy the various requirements imposed by the project's stakeholders. The aphorism "A picture is worth a thousand words" holds especially true when it comes to the work involved in developing software: much of what's interesting about a given system lends itself to visual modeling better than plain text does.

The UML is specifically designed to facilitate communication among the participants in a project. Some aspects of the language are focused on the communication involving customers and developers; others, on that among system architects and database designers; still others, on that among developers working on different pieces of the system. By offering a set of well-defined diagrams, and precise notation to use on those diagrams, the UML gives everyone on the team the ability to understand what's going on with the system at any point in time with minimal risk of misinterpretation.


To specify a model, in UML terms, means to build it so that it's precise, unambiguous, and complete. Various aspects of the UML address the specification of the many decisions that have to be made as a system evolves.
  • Models built early in the project help focus the thought processes of the stakeholders and enable them to explore their options with little risk and at relatively little cost.
  • As work proceeds, the initial models get fleshed out as knowledge increases and a greater degree of precision is required. These intermediate models focus on the key concepts of the system and the mechanisms by which those concepts will be embodied.
  • UML models with large amounts of detail generally serve as fairly complete descriptions of the most important features of the final system. If the modeling efforts have been rigorous, viewers will be able to trace the elements of the later-stage models to their initial incarnations in the rough sketches.
  • UML models can also be constructed from an existing system to assist people in their efforts to maintain and extend the system's functionality.


Of course, the ultimate goal of a development project is working code. A healthy number of the UML's constructs have direct or indirect relationships with constructs offered by the most popular programming languages, including C++ and Java; other UML elements lend themselves nicely to tasks such as physical database modeling and network layout.

A technique called forward engineering involves generating code from models. Visual modeling tools such as Rational Rose make it easy to get code started from UML models. Reverse engineering, the construction (or reconstruction) of models from code, can also be very useful. Ideally, a project team will practice round-trip engineering, which encompasses both forward engineering and reverse engineering with the goal of keeping models and code in synch to maximum effect.


The combination of UML models and the other kinds of work products that come out of a development effort generally forms a solid set of project documentation. For instance, a complete set of use cases (see Chapter 4) can serve as a strong foundation for user guides and related training materials, and the realizations of those use cases, as described in Chapter 5, lend themselves nicely to use by quality assurance people performing white-box testing.

In addition to helping people who weren't involved understand the thought processes underlying the development project, properly produced models and related documents will often be reusable, in part or wholesale, in the context of other projects.

What Makes a Good Software Model?

At the heart of the philosophy that underlies the UML are a set of qualities that, taken together, identify a model as useful and valuable.
  • A good model suits the plan of attack that the team takes toward solving part or all of the problem at hand. A model that captures essential abstractions and ignores nonessential ones is likely to go a long way toward offering a high degree of enlightenment.
  • A good model allows different viewers to see different levels of detail at different times. The stakeholders of a project come at a system being developed from varying viewpoints; a good model lends itself to inspection at levels ranging from the executive summary to the gritty low-level details.
  • A good model is connected to reality. Rigorous development and continuous improvement of a model are likely to result in behavior that closely resembles what the team can expect to see when the real system is unveiled.
  • A good model works well with other models in capturing all of the essential elements of the system. As discussed later in this chapter, and also in Chapter 2, the UML encourages the creation of several kinds of models that are, for the most part, independent, yet offer ample opportunities to trace the likes of data flows and control flows....
Read More Show Less

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.



Read More Show Less


When I started seriously considering writing a proposal for a book about the Unified Modeling Language (UML), 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 ( and the UML Resource Center ( 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

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)