UML: Sequence, Activity & State Diagrams

Modeling Behavior: An Overview

18 min Lesson 1 of 10

Modeling Behavior: An Overview

Up to this point in the course you have learned to ask what exists: what data the system stores, what entities relate to which, what actors need which use cases. Those are structural questions. Now we shift to a different and equally important set of questions: what happens, in what order, under what conditions? These are behavioral questions, and UML gives us a dedicated family of diagrams to answer them.

This lesson maps that landscape — the full UML diagram taxonomy — so that every diagram you build in the coming lessons has a clear place in the picture. Think of it as the navigator's chart before you sail into any one territory.

Structural vs Behavioral Diagrams

The fourteen standard UML diagram types split neatly into two camps.

Structural diagrams describe the static architecture of a system: its building blocks and the permanent relationships among them. They answer: "What does the system consist of?" The analyst uses these to model data, classes, components, and deployment topology. The key examples you have already met are:

Class diagram — entities, attributes, operations, and relationships.
Use case diagram — actors and the functional capabilities they interact with.
Component / Deployment diagrams — how code modules and hardware nodes are organized.

Behavioral diagrams describe how a system moves through time. They answer: "What does the system do, and how does it do it?" This tutorial concentrates on the three most useful behavioral diagrams in everyday analysis work:

Sequence diagram — the precise back-and-forth of messages between participants over time.
Activity diagram — the flow of control and data through a process, including branches and parallel work.
State machine diagram — the discrete states an object passes through and the events that drive transitions.

Why three diagrams for behavior? Each one illuminates a different dimension. A sequence diagram shows who talks to whom. An activity diagram shows how work flows. A state machine shows how an object changes. A complete behavioral specification of any non-trivial process typically needs all three.

The UML Diagram Map

The diagram below organizes the full UML taxonomy. The three diagrams covered in this tutorial are highlighted in green.

The UML diagram taxonomy. Structural diagrams (blue) answer "what exists"; behavioral diagrams (green) answer "what happens". The three starred diagrams are the focus of this tutorial.

The Question Each Diagram Answers

Choosing the wrong diagram is one of the most common mistakes junior analysts make. The following table gives you a fast decision rule. Commit it to memory — you will use it every time you sit down to model.

Diagram            | Core Question                          | Best Used When
-------------------+----------------------------------------+--------------------------------
Class              | What data exists and how is it related?| Designing the data model
Use Case           | Who does what with the system?         | Capturing functional requirements
Sequence           | Who sends what message, in what order? | Documenting a specific scenario
Activity           | How does work flow from start to end?  | Mapping a business process
State Machine      | What states can this object be in?     | Modeling an object with a lifecycle
Communication      | Which objects collaborate on a task?   | Auditing object interactions

Analyst tip: In an interview or workshop, listen for the word clues. If a stakeholder says "the order goes through several stages," reach for a state machine. If they say "first the patient submits, then the receptionist checks, then the system confirms," reach for a sequence diagram. If they say "we need to map out the whole checkout process," reach for an activity diagram.

A Running Example: The Online Bookstore

Throughout this tutorial we will model the same system from three behavioral angles: an online bookstore where customers browse, order, and pay for books. This lets you directly compare the three diagram types side by side.

Here is a quick snapshot of the same "Place Order" scenario told three different ways:

Sequence diagram view: Customer sends addToCart() to Cart; Cart sends checkStock() to Inventory; Inventory replies; Cart replies to Customer with confirmation.
Activity diagram view: Customer browses catalogue → selects item → system checks stock → [in stock?] yes → adds to cart → customer checks out → payment processed → order confirmed.
State machine view (Order object): Order starts in Draft → on payment: transitions to Confirmed → on dispatch: transitions to Shipped → on delivery: transitions to Delivered → on return request: transitions to Returned.

Each view is correct. Each is incomplete on its own. Together they give you, and any developer or tester reading the specification, a complete behavioral picture.

How Structural and Behavioral Diagrams Work Together

The two families are not rivals — they are complementary layers of the same model. A well-written system specification pairs them deliberately:

The class diagram tells you that an Order has attributes status and total. The state machine tells you the legal values of status and the rules for changing it.
The use case diagram tells you that a Customer can Place Order. The sequence diagram tells you the exact messages exchanged to make that happen.
The class diagram identifies the PaymentService component. The activity diagram shows when and why it is invoked in the order workflow.

Key principle: Structural diagrams define the vocabulary of the model (classes, actors, components). Behavioral diagrams write the sentences — the stories of what happens at runtime. You cannot write good sentences without a solid vocabulary, and a vocabulary with no sentences tells no story.

When Does the Analyst Draw Behavioral Diagrams?

In a typical project lifecycle the behavioral diagrams appear at these moments:

During requirements analysis — draft activity diagrams to agree on the as-is business process and the to-be process with stakeholders. These are communication tools first, precision tools second.
During system design — draw sequence diagrams for every significant use case scenario. This is where the analyst hands off a precise, unambiguous contract to developers.
Whenever an object has a lifecycle — draw a state machine for any entity that can be in one of several clearly distinct states (Order, Appointment, Library Book, Patient Record).
During review and testing — use sequence diagrams to trace a defect back through the message chain; use state machines as test oracles to verify that illegal state transitions are blocked.

Common pitfall: Analysts sometimes skip behavioral diagrams entirely and jump straight to a written narrative or a list of steps. This leaves ambiguities that only surface during development — at the worst possible moment. A sequence diagram takes twenty minutes to draw and saves days of rework.

With this map in hand you are ready to go deep. The next lesson introduces sequence diagrams: their core notation, lifelines, messages, and activation boxes — the machinery behind the most widely used behavioral diagram in professional systems analysis.