UML Distilled: A Brief Guide to the Standard Object Modeling Language / Edition 3

by Martin Fowler

Overview

More than 300,000 developers have benefited from past editions of UML Distilled . This third edition is the best resource for quick, no-nonsense insights into understanding and using UML 2.0 and prior versions of the UML.

Some readers will want to quickly get up to speed with the UML 2.0 and learn the essentials of the UML. Others will use this book as a handy, quick reference to the most common parts of the UML. The author delivers on both of these promises in a short, concise, and focused presentation.

This book describes all the major UML diagram types, what they're used for, and the basic notation involved in creating and deciphering them. These diagrams include class, sequence, object, package, deployment, use case, state machine, activity, communication, composite structure, component, interaction overview, and timing diagrams. The examples are clear and the explanations cut to the fundamental design logic. Includes a quick reference to the most useful parts of the UML notation and a useful summary of diagram types that were added to the UML 2.0.

If you are like most developers, you don't have time to keep up with all the new innovations in software engineering. This new edition of Fowler's classic work gets you acquainted with some of the best thinking about efficient object-oriented software design using the UML--in a convenient format that will be essential to anyone who designs software professionally.

Product Details

ISBN-13:	9780321193681
Publisher:	Pearson Education
Publication date:	09/15/2003
Series:	Addison-Wesley Object Technology Series
Edition description:	Third Edition
Pages:	208
Product dimensions:	6.95(w) x 9.15(h) x 0.70(d)

About the Author

Martin Fowler is an independent consultant who has applied objects to pressing business problems for more than a decade. He has consulted on systems in fields such as health care, financial trading, and corporate finance. His clients include Chrysler, Citibank, UK National Health Service, Andersen Consulting, and Netscape Communications. In addition, Fowler is a regular speaker on objects, the Unified Modeling Language, and patterns.

Read an Excerpt

Two years ago, Addison-Wesley approached me to write a book about the then-new UML. At that time, there was a lot of interest in the UML, but only a standards document from which to learn about it. We broke many records to quickly produce a short introductory guide to the new UML, something that would provide some guidance until the more detailed and official books were to appear later that year.

We didn't expect this book to last after more detailed books appeared. Most people believed that given the choice between a slim overview and a detailed text, everyone would pick the detailed text. Although that was the general view, I believed that even in the presence of detailed books, there was still room for a concise summary.

Two years later, my hopes have been realized more than I could have wished. UML Distilled has been, in computer industry terms, a best-seller. Even though good detailed books have appeared on the UML, the book still sells well. Better than that, more slim books have appeared, confirming my belief that in a world with so much information, there is value in well-chosen brevity.

Now, that's all very well, but should you buy this book?

I'm going to assume you've heard about the UML. It has become the standard way to draw diagrams of object-oriented designs, and it has also spread into non-OO fields. The major pre-UML methods have all died out. The UML has arrived and is here to stay.

If you want to learn about the UML, this book is one way to do it. The main reason for starting with this book is that it's a small book. Buying a big book will give you more information, but it will also take you longer to read. I've selected the most important parts of the UML so that you don't have to. With this book, you'll pick up the key elements of the notation and what they mean. If you want to move further, you can move to a more detailed book later.

If you want a longer tutorial to the UML, I suggest the Unified Modeling Language User Guide (Booch, Rumbaugh, and Jacobson 1999). The User Guide is able to cover a lot more ground. It's well written and organized in a way that explains how to apply the UML to various modeling problems.

Both this book and the User Guide assume that you know something about OO development. Although many people have told me that this book is a good introduction to objects, I didn't write it with that in mind. If you're looking for an introduction to objects with the UML, you should also consider Craig Larman's book (Larman 1998).

Although the main point of this book is the UML, I've also added material that complements the UML material. The UML is a relatively small part of what you need to know to succeed with objects, and I think that it's important to point out some of the other things here.

The most important of these is software process. The UML is designed to be independent of process. You can do anything you like; all the UML does is say what your diagrams mean. However, the diagrams don't make much sense without a process to give them context. I also believe that process is important and that a good process doesn't need to be complicated.

So, I've described a lightweight outline process for OO software development. This provides a context for the techniques and will help to get you going in using objects.

The other topics include patterns, refactoring, self-testing code, design by contract, and CRC cards. None of these are part of the UML, yet they are valuable techniques that I use regularly.

Structure of the Book

Chapter 1 looks at what the UML is, the history of its development, and the reasons why you might want to use it.

Chapter 2 discusses the object-oriented development process. Although the UML exists independent of process, I find it hard to discuss modeling techniques without talking about where they fit in with object-oriented development.

Chapters 3 through 6 discuss the three most important techniques in the UML: use cases, class diagrams, and interaction models. The UML is a large beast, but you don't need all of it. These three techniques are the core that almost everyone needs. Start with these and add the others as you need them. (Note that since class diagrams are so complicated in themselves, I've put the key parts of class diagrams in Chapter 4 and the advanced concepts in Chapter 6.)

Chapters 7 through 10 explore the remaining techniques. All of these are valuable, but not every project needs every technique. So these chapters provide enough information to tell you what the technique is and whether you need it.

For all of these techniques, I describe the notation, explain what the notation means, and provide tips about using the techniques. My philosophy is to make clear what the UML says and, at the same time, to give you my opinions on how best to use it. I've also added pointers to other books that provide more detail.

Chapter 11 gives a small example to show how the UML fits in with programming using (of course) Java.

The inside covers summarize the UML notation. You may find it useful to refer to these as you are reading the chapters so that you can check on the notation for the various modeling concepts.

If you find this book interesting, you can find other information on my work related to using the UML, patterns, and refactoring at my home page (see page xxi).

Changes for the Second Edition

As the UML evolved, and I received feedback about the first edition of the book, I continually updated it. We reprinted every two or three months; nearly every printing contained updates, which resulted in considerable strain on the processes of the publishing industry.

With the change from UML 1.2 to 1.3, we decided to do a more thorough overhaul of the book, enough to produce a second edition. Since the book has been so popular, I've tried not to change the essential spirit of the book. I've carefully tried to not add much, and to see whether there are things I can take away.

The biggest changes are in Chapter 3, about use cases, and Chapter 9, about activity diagrams, which have each received a severe rewrite. I've also added a section on collaborations to Chapter 7. Elsewhere, I've taken the opportunity to make a host of smaller changes, based on feedback and my experiences over the last couple of years.

Martin Fowler

Melrose, Massachusetts

April 1999

[e-mail]

Table of Contents

Preface.

Why bother with the UML?

Structure of the book.

Changes for the Third Edition.

Acknowledgements.

1. Introduction.

What Is the UML?

Ways of Using the UML.

How We Got to the UML.

Notations and Meta-Models.

UML Diagrams.

What is Legal UML?

The Meaning of UML.

UML is not enough.

Where to Start with the UML.

Looking for More Information.

2. Development Process.

Iterative and Waterfall Processes.

Predictive and Adaptive Planning.

Agile Processes.

Rational Unified Process.

Fitting a Process to a Project.

Fitting the UML into a process.

Understanding Legacy Code.

Choosing a Development Process.

Where to Find Out More.

3. Class Diagrams: The Essentials.

Properties.

Attributes.

Associations.

Multiplicity.

Programming Interpretation of Properties.

Bi-directional Associations.

Operations.

Generalization.

Notes and Comments.

Dependency.

Constraint Rules.

When to Use Class Diagrams.

Where to Find Out More.

4. Sequence Diagrams.

Creating and deleting participants.

Loops, conditionals and the like.

Synchronous and Asynchronous Calls.

When to use Sequence Diagrams.

5. Class Diagrams: Advanced Concepts.

Keywords.

Responsibilities.

Static Operations and Attributes.

Aggregation and Composition.

Derived Properties.

Interfaces and Abstract Classes.

Read Only and Frozen.

Reference Objects and Value Objects.

Qualified Associations.

Classification and Generalization.

Multiple and Dynamic Classification.

Association Class.

Template (Parameterized) Class.

Enumerations.

Active Class.

Visibility.

Messages.

6. Object Diagrams.

When to use Object Diagrams.

7. Package Diagrams.

Packages and Dependencies.

Package Aspects.

Implementing Packages.

Where to Find Out More.

When to Use Package Diagrams.

8. Deployment Diagrams.

When to use deployment diagrams.

9. Use Cases.

Content of a Use Case.

Use Case Diagrams.

Levels of Use Cases.

Use cases and features (or stories).

When to Use Use Cases.

Where to Find Out More.

10. State Machine Diagrams.

Internal Activities.

Activity States.

Superstates.

Concurrent States.

Implementing State Diagrams.

When to Use State Diagrams.

Where to Find Out More.

11. Activity Diagrams.

Decomposing an action.

Partitions.

Signals.

Tokens.

Flows and Edges.

Pins and Transformations.

Expansion Regions.

Flow Final.

Join Specifications.

And there's more.

When to Use Activity Diagrams.

Where to Find Out More.

12. Communication Diagrams.

When to use Communication Diagrams.

13. Composite Structures.

When to Use Composite Structures.

14. Component Diagrams.

When to use Component Diagrams.

15. Collaborations.

When to Use Collaborations.

16. Interaction Overview Diagrams.

When to use Interaction Overview Diagrams.

17. Timing Diagrams.

When to use Timing Diagrams.

Appendix A Changes between UML Versions.

Revisions to the UML.

Changes in UML Distilled.

Changes from UML 1.0 to 1.1.

Type and Implementation Class.

Complete and Incomplete Discriminator Constraints.

Composition.

Immutability and Frozen.

Returns on Sequence Diagrams.

Use of the Term "Role".

Changes from UML 1.2 (and 1.1) to 1.3 (and 1.5).

Use Cases.

Activity Diagrams.

Changes from UML 1.3 to 1.4.

Changes from UML 1.4. to 1.5.

From UML 1.x to UML 2.0.

Class Diagrams (Basic).

Interaction Diagrams.

Class Diagrams (Advanced).

State Diagrams.

Activity Diagrams.

Bibliography.


Index.

Preface

I've been lucky in a lot of ways in my life; one of my great strokes of fortune was being in the right place with the right knowledge to write the first edition of this book in 1997. Back then, the chaotic world of object-oriented (OO) modeling was just beginning to unify under the Unified Modeling Language (UML). Since then, the UML has become the standard for the graphical modeling of software, not just for objects. My fortune is that this book has been the most popular book on the UML, selling more than a quarter of a million copies.Well, that's very nice for me, but should you buy this book?

I like to stress that this is a brief book. It's not intended to give you the details on every facet of the UML, which has grown and grown over the years. My intention is to find that fraction of the UML that is most useful and tell you just that. Although a bigger book gives you more detail, it also takes longer to read. And your time is the biggest investment you'll make in a book. By keeping this book small, I've spent the time selecting the best bits to save you from having to do that selection yourself. (Sadly, being smaller doesn't mean proportionately cheaper; there is a certain fixed cost to producing a quality technical book.)

One reason to have this book is to begin to learn about the UML. Because this is a short book, it will quickly get you up to speed on the essentials of the UML. With that under your belt, you can go into more detail on the UML with the bigger books, such as the User Guide Booch, UML user or the Reference Manual Rumbaugh, UML Reference.

This book can also act as a handy reference to the most common parts of the UML. Although the book doesn't cover everything, it's a lot lighter to carry around than most other UML books.

It's also an opinionated book. I've been working with objects for a long time now, and I have definite ideas about what works and what doesn't. Any book reflects the opinions of the author, and I don't try to hide mine. So if you're looking for something that has a flavor of objectivity, you might want to try something else.

Although many people have told me that this book is a good introduction to objects, I didn't write it with that in mind. If you are after an introduction to OO design, I suggest Craig Larman's book Larman.

Many people who are interested in the UML are using tools. This book concentrates on the standard and on conventional usage of the UML and doesn't get into the details of what various tools support. Although the UML did resolve the tower of Babel of pre-UML notations, many annoying differences remain between what tools show and allow when drawing UML diagrams.

I don't say much in this book about Model Driven Architecture (MDA). Although many people consider the two to be the same thing, many developers use the UML without being interested in MDA. If you want to learn more about MDA, I would start with this book to get an overview of the UML first and then move on to a book that's more specific about MDA.

Although the main point of this book is the UML, I've also added bits of other material about techniques, such as CRC cards, that are valuable for OO design. The UML is just a part of what you need to succeed with objects, and I think that it's important to introduce you to some other techniques.

In a brief book like this, it's impossible to go into detail about how the UML relates to source code, particularly as there is no standard way of making that correspondence. However, I do point out common coding techniques for implementing pieces of the UML. My code examples are in Java and C#, as I've found that these languages are usually the most widely understood. Don't assume that I prefer those languages; I've done too much Smalltalk for that!

Why Bother with the UML?

Graphical design notations have been with us for a while. For me, their primary value is in communication and understanding. A good diagram can often help communicate ideas about a design, particularly when you want to avoid a lot of details. Diagrams can also help you understand either a software system or a business process. As part of a team trying to figure out something, diagrams both help understanding and communicate that understanding throughout a team. Although they aren't, at least yet, a replacement for textual programming languages, they are a helpful assistant.

Many people believe that in the future, graphical techniques will play a dominant role in software development. I'm more skeptical of that, but it's certainly useful to have an appreciation of what these notations can and can't do.

Of these graphical notations, the UML's importance comes from its wide use and standardization within the OO development community. The UML has become not only the dominant graphical notation within the OO world but also a popular technique in non-OO circles.

Structure of the Book

Chapter 1 gives an introduction to the UML: what it is, the different meanings it has to different people, and where it came from.

Chapter 2 talks about software process. Although this is strictly independent of the UML, I think that it's essential to understand process in order to see the context of something like the UML. In particular, it's important to understand the role of iterative development, which has been the underlying approach to process for most of the OO community.

I've organized the rest of the book around the diagram types within the UML. Chapters 3 and 4 discuss the two most useful parts of the UML: class diagrams (core) and sequence diagrams. Even though this book is slim, I believe that you can get the most value out of the UML by using the techniques that I talk about in these chapters. The UML is a large and growing beast, but you don't need all of it.

Chapter 5 goes into detail on the less essential but still useful parts of class diagrams. Chapters 6 through 8 describe three useful diagrams that shed further light on the structure of a system: object diagrams, package diagrams, and deployment diagrams.

Chapters 9 through 11 show three further useful behavioral techniques: use cases, state diagrams (although officially known as state machine diagrams, they are generally called state diagrams), and activity diagrams. Chapters 12 through 17 are very brief and cover diagrams that are generally less important, so for these, I've only provided a quick example and explanation.

The inside covers summarize the most useful parts of the notation. I've often heard people say that these covers are the most valuable part of the book. You'll probably find it handy to refer to them as you're reading some of the other parts of the book.

Changes for the Third Edition

If you have earlier editions of this book, you're probably wondering what is different and, more important, whether you should buy the new edition.

The primary trigger for the third edition was the appearance of UML 2. UML 2 has added a lot of new stuff, including several new diagram types. Even familiar diagrams have a lot of new notation, such as interaction frames in sequence diagrams. If you want to be aware of what's happened but don't want to wade through the specification (I certainly don't recommend that!), this book should give you a good overview.

I've also taken this opportunity to completely rewrite most of the book, bringing the text and examples up to date. I've incorporated much that I've learned in teaching and using the UML over the past five years. So although the spirit of this ultrathin UML book is intact, most of the words are new.Over the years, I've worked hard to keep this book as current as is possible. As the UML has gone through its changes, I've done my best to keep pace. This book is based on the UML 2 drafts that were accepted by the relevant committee in June 2003. It's unlikely that further changes will occur between that vote and more formal votes, so I feel that UML 2 is now stable enough for my revision to go into print. I'll post information any further updates on my Web site (http://martinfowler.com).

Martin Fowler
Melrose, Massachusetts
http://martinfowler.com

Editorial Reviews

The Barnes & Noble Review
UML 2 represents the most significant overhaul to UML since it was first agreed upon. One thing hasn’t changed, though: UML Distilled is the place to begin.

Over the years, Martin Fowler’s short book has collected raves from folks who know...folks like Jim Rumbaugh and Stephen J. Mellor. It’s just so accessible, clear, realistic -- and so well-focused on the essence of UML. This edition’s no exception.

Many folks treat UML as a tool for informal, collaborative “sketching”: roughing out issues and alternatives or clarifying a legacy system’s behavior. This may be the only UML book they’ll ever need. Others use it to build exhaustive blueprints for coding. Some are even trying to compile UML diagrams directly to executable code: The UML is the source. Blueprinters and “executable XML” types will eventually need to go beyond this book’s 170 pages, but Fowler does a superb job of getting them started.

After a thoughtful essay on integrating UML into your workflow, he introduces each “official” UML diagram type. He begins with class diagrams -- from the basics through advanced topics such as parameterization. There’s a solid introduction to use cases: the diagrams, when to use them, and how they relate to features and “user stories.” There’s expert coverage of state machine diagrams, from internal activities to concurrent states.

Among the many UML 2 updates: a new chapter on composite structures for describing classes hierarchically (very helpful in managing complexity). There’s also far more coverage of activity diagrams, which have been extensively enhanced to permit the modeling of complex processes. If you’re new to UML, you’ll admire this slim volume -- as you use it to start getting results, fast. Bill Camarda

Bill Camarda is a consultant, writer, and web/multimedia content developer. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks for Dummies, Second Edition.

bn.com

A pioneer in the field provides software developer users of this industry standard with a foundation for integrating the Unified Modeling Language into the object-oriented development process, in the context of its history. Appends modeling techniques and their uses, and changes between UML versions. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Booknews