Fowler M., UML Distilled (2004)

 |  Book Reviews

UML is a must-have tool for modeling, designing software, for communicating and accumulating knowledge about software within teams and across time.

Contents

Summary

[IMPORTANT] Create or update models in UML 1 is 10-100 times faster than updating models in code. Modeling eliminates similar amounts of waste work. Unlike code models 2, UML models are easily understood by non-technical people after a brief introduction. Coarse modeling, with UML or other tools drastically improves the speed of product development and getting a customer value right from the first time.

Not all the UML diagrams are equally often used in the modeling process. Here is the map of diagrams that marks the mostly used diagrams and denotes the order of their appearance in the new software system modeling process.

UML Diagrams Hierarchy

UML diagrams break down into 2 categories: behavioral and structural. Behavioral represent the modeled system behaviors (elements interaction), structural represent a static snapshot of the system (including stable relationships) at some point in time.

Begin with diagrams marked with white bubbles, use them in the order denoted by numbers in parens. See more on this in "Fitting the UML into a Process" (p. 29).

UML Diagrams Hierarchy

Chapter 2: Development Process

[VS]: The chapter is a great overview of what the effective development process must consist of, irrespective of being called 'agile', 'scrum', or any other way. The above two are organizational flavors; the substance - core engineering work - is always (common sense applied) Waterfall.

Note the difference between Predictive and Adaptive Planning (p. 23), then consider Agile (p. 24) as adaptive process example and RUP (p. 25) as mostly predictive process example (now RUP is mostly obsolete).

When to Use Basic Diagrams

The remaining chapters practically describe each UML diagram. Here is the brief overview for when to use basic diagrams. Refer to the respective chapter's "When to Use" section for details.

Use Case Diagram

Captures the functional requirements of a system by illustrating interactions between actors (users or external systems) and the system itself. It is best used during the requirements gathering phase to define what a system should do from the user's perspective. This diagram helps stakeholders visualize system functionalities, identify key user roles, and clarify system boundaries without delving into implementation details.

use case

Class Diagram

Represents the static structure of a system by modeling classes, their attributes, methods, and relationships (such as inheritance, associations, and dependencies). It is most useful during the system design phase to define the architecture of an object-oriented system. Developers rely on class diagrams to plan code structure, database schemas, and the relationships between different components before implementation begins.

class

Sequence Diagram

Depicts interactions between objects or components in a time-ordered sequence, showing how messages are exchanged to achieve a specific functionality. It is particularly valuable when modeling runtime behavior, such as how different parts of a system collaborate to execute a use case. This diagram helps developers understand the flow of control, method calls, and the lifespan of objects during execution.

sequence

Activity Diagram

Models workflows, business processes, or algorithmic steps, emphasizing the flow from one activity to another. It is ideal for visualizing parallel processes, decision points, and sequential operations, making it useful in both business process modeling and system design. Activity diagrams are often employed to clarify complex workflows, such as user registration flows or multi-step transaction processing.

activity

State Machine Diagram

A State Machine Diagram describes the various states an object can be in and the transitions between those states triggered by events. It is most effective when modeling event-driven behavior, such as the lifecycle of an order (e.g., "Pending" → "Shipped" → "Delivered") or the behavior of a UI component. This diagram is essential for systems where objects exhibit state-dependent behavior with clear transitions.

state

Footnotes

  1. This is true for other coarse models, e.g. UI wireframes or ERD;

  2. Code is just another, executable, model of the real-life systems to be automated.