By Martin Fowler

Why Bother with the UML?

Their primary value is in communication and understanding. UML has become not only the dominant graphical notation within the OO world but also a popular technique in non-OO circles.

Chapter 1.  Introduction
What Is the UML?
Ways of Using the UML

Three modes in which people use the UML: sketch, blueprint, and programming language.

The essence of sketching is selectivity.

UML as blueprint is about completeness.

UML as programming language. In this environment, developers draw UML diagrams that are compiled directly to executable code, and the UML becomes the source code.

Model Driven Architecture and Executable UML

Essentially, MDA is a standard approach to using the UML as a programming language

Almost all the time, my use of the UML is as sketches. I find the UML sketches useful with forward and reverse engineering and in both conceptual and software perspectives.

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
Where to Find Out More


Chapter 2.  Development Process
Iterative and Waterfall Processes

The waterfall style breaks down a project based on activity. To build software, you have to do certain activities: requirements analysis, design, coding, and testing.

The iterative style breaks down a project by subsets of functionality.

Predictive and Adaptive Planning

The difference between a predictive project and an adaptive project surfaces in many ways that people talk about how the project goes. When people talk about a project that’s doing well because it’s going according to plan, that’s a predictive form of thinking. You can’t say "according to plan" in an adaptive environment, because the plan is always changing. This doesn’t mean that adaptive projects don’t plan; they usually plan a lot, but the plan is treated as a baseline to assess the consequences of change rather than as a prediction of the future.

Agile Processes
Rational Unified Process
Fitting a Process to a Project
Fitting the UML into a Process
Choosing a Development Process
Where to Find Out More
Chapter 3.  Class Diagrams: The Essentials


Programming Interpretation of Properties
Bidirectional Associations
Notes and Comments
Constraint Rules
When to Use Class Diagrams

The trouble with class diagrams is that they are so rich, they can be overwhelming to use. Here are a few tips.

  • Don’t try to use all the notations available to you. Start with the simple stuff in this chapter: classes, associations, attributes, generalization, and constraints. Introduce other notations from Chapter 5 only when you need them.

  • I’ve found conceptual class diagrams very useful in exploring the language of a business. For this to work, you have to work hard on keeping software out of the discussion and keeping the notation very simple.

  • Don’t draw models for everything; instead, concentrate on the key areas. It is better to have a few diagrams that you use and keep up to date than to have many forgotten, obsolete models.

The biggest danger with class diagrams is that you can focus exclusively on structure and ignore behavior. Therefore, when drawing class diagrams to understand software, always do them in conjunction with some form of behavioral technique. If you’re going well, you’ll find yourself swapping between the techniques frequently.

Where to Find Out More
Chapter 4.  Sequence Diagrams

One of the main goals of good design is to localize the effects of change. Data and behavior that accesses that data often change together. So putting the data and the behavior that uses it together in one place is the first rule of object-oriented design.

Creating and Deleting Participants
Loops, Conditionals, and the Like
Synchronous and Asynchronous Calls
When to Use Sequence Diagrams

You should use sequence diagrams when you want to look at the behavior of several objects within a single use case. Sequence diagrams are good at showing collaborations among the objects; they are not so good at precise definition of the behavior.

CRC Cards

One of the most valuable techniques in coming up with a good OO design is to explore object interactions, because it focuses on behavior rather than data. CRC (Class-Responsibility-Collaboration) diagrams have stood the test of time as a highly effective way to do this.


                                         A sample CRC card

Chapter 5.  Class Diagrams: Advanced Concepts
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
Active Class
Chapter 6.  Object Diagrams
When to Use Object Diagrams
Chapter 7.  Package Diagrams
Packages and Dependencies
Package Aspects
Implementing Packages
When to Use Package Diagrams
Where to Find Out More
Chapter 8.  Deployment Diagrams
When to Use Deployment Diagrams
Chapter 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
Chapter 10.  State Machine Diagrams
Internal Activities
Activity States
Concurrent States
Implementing State Diagrams
When to Use State Diagrams
Where to Find Out More
Chapter 11.  Activity Diagrams
Decomposing an Action
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
Chapter 12.  Communication Diagrams
When to Use Communication Diagrams
Chapter 13.  Composite Structures
When to Use Composite Structures

Composite structures are new to UML 2, although some older methods had some similar ideas. A good way of thinking about the difference between packages and composite structures is that packages are a compile-time grouping, while composite structures show runtime groupings. As such, they are a natural fit for showing components and how they are broken into parts; hence, much of this notation is used in component diagrams.

Chapter 14.  Component Diagrams

Components are not a technology. Technology people seem to find this hard to understand. Components are about how customers want to relate to software. They want to be able to buy their software a piece at a time, and to be able to upgrade it just like they can upgrade their stereo. They want new pieces to work seamlessly with their old pieces, and to be able to upgrade on their own schedule, not the manufacturer’s schedule. They want to be able to mix and match pieces from various manufacturers. This is a very reasonable requirement. It is just hard to satisfy.

When to Use Component Diagrams

Use component diagrams when you are dividing your system into components and want to show their interrelationships through interfaces or the breakdown of components into a lower-level structure.

Chapter 15.  Collaborations
When to Use Collaborations
Chapter 16.  Interaction Overview Diagrams

Interaction overview diagrams are a grafting together of activity diagrams and sequence diagrams.

When to Use Interaction Overview Diagrams
Chapter 17.  Timing Diagrams
When to Use Timing Diagrams
Appendix Changes between UML Versions
Revisions to the UML
Changes in UML Distilled
Changes from UML 1.0 to 1.1
Changes from UML 1.2 (and 1.1) to 1.3 (and 1.5)
Changes from UML 1.3 to 1.4
Changes from UML 1.4. to 1.5
From UML 1.x to UML 2.0