Behavioral and Interaction UML Diagrams: Types, Notation and a Worked Order Flow

Learn how activity, state machine, sequence and communication diagrams answer different questions by tracing the same order, payment and stock values.

KnowledgeGate Team

Exam prep & CS education

Updated 26 Oct 20266 min read

Activity, state machine, sequence and communication diagrams can all describe the same system, which makes their boundaries easy to blur. In one checkout trace, the four questions are workflow, object lifecycle, time-ordered messages and collaboration network. Product P42, quantity 2, unit price 750, stock 3 and coupon KG10 produce order O-104, payment 1350 and remaining stock 1. Class and object structure is a separate view; broader CS foundations sit in KnowledgeGate's Coding & Skill Development Courses.

Behavioral versus interaction diagrams: build the family tree first

Behavioral diagrams show systems, processes or objects responding over time. Interaction diagrams specialize it for messages among participants. Every interaction diagram is behavioral; activity and state machine diagrams are outside that subset.

UML family

Diagram

Main question

Behavioral

Use case

Which actors pursue which goals?

Behavioral

Activity

What workflow, decisions or parallel paths occur?

Behavioral

State machine

How does one object move through its lifecycle?

Interaction

Sequence or communication

Who sends messages, in what order or network?

Interaction

Timing or interaction overview

How do states vary with time or interactions connect?

Sequence and communication diagrams show what happens among participants. A structural class diagram instead asks what entities and relationships exist, while these diagrams ask what happens. Object Oriented Technology Explained gives class, object and OOP context.

Read the notation by asking action, state or message

Classify the text before memorising symbols. Validate stock is an activity action because work is being performed. AwaitingPayment is an order state because it can persist. charge(1350) is an interaction message because one participant requests work from another.

An activity diagram uses an initial node, rounded actions, decision or merge diamonds, guards such as [stock >= 2], fork or join bars, and an activity-final node. A state machine uses named states and transitions in the form event [guard] / effect, for example, submit [stock=3 >= 2] / reserve 2.

A sequence diagram has participants, vertical lifelines, activations, call and return messages, and top-to-bottom time. An alt fragment separates mutually exclusive results. A communication diagram places connected participants first and carries order through message numbers such as 1, 2 and 3. Thus the same checkout can be recognised as work, persistent condition or exchanged request, depending on the chosen view.

Worked activity diagram: calculate the checkout path exactly

Fix the inputs before drawing: P42, quantity 2, unit price 750, available stock 3, coupon KG10 worth 10%, and order O-104. The calculation is:

  1. subtotal = 2 x 750 = 1500

  2. discount = 10% of 1500 = 150

  3. payable = 1500 - 150 = 1350

The success flow starts in the Customer swimlane with submitting the cart. The Store creates draft O-104, checks stock, takes [3 >= 2], reserves 2, changes stock from 3 -> 1, calculates 1350, and requests a charge. The Payment Service charges 1350. On [approved: TX91], the Store marks O-104 paid and sends confirmation before the activity ends.

Each action sits in the swimlane of the participant responsible for performing it, not the participant that merely receives its result.

The stock decision also needs [stock < 2], leading to Show out of stock and an end without a charge. The payment decision needs [payment declined], leading the Store to release 2 units, restore stock from 1 -> 3, mark O-104 as PaymentFailed, offer retry, and end this attempt. A diamond chooses a route by guard. It does not store a persistent state.

Worked state machine: follow order O-104, not the whole workflow

The state machine follows O-104. Its persistent states are Draft, AwaitingPayment, Paid, Packed, Shipped, PaymentFailed and Cancelled. The successful path is initial to Draft, then submit [stock=3 >= 2] / reserve 2 to AwaitingPayment, paymentApproved(TX91) / record 1350 to Paid, pack to Packed, and dispatch to Shipped. deliver / mark delivered can take Shipped to a final node when delivery completion belongs to the lifecycle.

Alternatives must agree with the activity flow. paymentDeclined / release 2 moves AwaitingPayment -> PaymentFailed. retry [stock >= 2] / reserve 2 returns it to AwaitingPayment. cancel / release 2 moves AwaitingPayment -> Cancelled, while plain cancel moves Draft or PaymentFailed -> Cancelled. Cancellation is not allowed from Shipped.

The activity diagram follows work across three responsible parties. The state machine follows one order across events. Actions use verb phrases, while states name stable conditions or noun phrases.

Aligned O-104 panels: Customer, Store and Payment Service activity swimlanes show P42 x 2, [3 >= 2], stock 3 -> 1, 2 x 750 = 1500, KG10 discount 150, payable and charge 1350, [approved: TX91], [stock < 2] ending uncharged, and [payment declined] releasing 2, stock 1 -> 3; the state machine shows Draft -> AwaitingPayment -> Paid -> Packed -> Shipped via submit [stock=3 >= 2] / reserve 2, paymentApproved(TX91) / record 1350, pack, dispatch, plus the stated decline, retry and cancel paths.

Worked sequence diagram: trace who sends each checkout message

Place six lifelines left to right: Customer, StoreUI, OrderService, Inventory, Pricing and Payment. Read these calls from top to bottom:

  1. Customer -> StoreUI: checkout(P42, 2, KG10)

  2. StoreUI -> OrderService: createDraft(P42, 2), returning O-104

  3. StoreUI -> Inventory: reserve(P42, 2), returning reserved, stock=1

  4. StoreUI -> Pricing: quote(2, 750, KG10), returning subtotal=1500, discount=150, total=1350

  5. StoreUI -> Payment: charge(1350), returning approved, TX91

  6. StoreUI -> OrderService: markPaid(O-104, TX91), returning Paid

  7. StoreUI -> Customer: confirm(O-104, 1350)

An alt frame begins around the result of message 5. Its [approved] operand performs messages 6 and 7. Its [declined] operand instead sends 6a StoreUI -> Inventory: release(P42, 2), returning stock=3, followed by 7a StoreUI -> OrderService: markPaymentFailed(O-104).

Three reading rules matter. Vertical position establishes order. A lifeline identifies a participant, not a class hierarchy. Return values show how O-104, the reserved stock and the calculated total propagate through the trace. These are request and response calls, so asynchronous notation is unnecessary.

Sequence lifelines Customer, StoreUI, OrderService, Inventory, Pricing, Payment carry messages 1 to 7 and returns O-104, reserved, stock=1, subtotal=1500, discount=150, total=1350, approved, TX91 and Paid; an alt frame sends approval to markPaid(O-104, TX91) and confirm(O-104, 1350), or decline to release(P42, 2) returning stock=3 and markPaymentFailed(O-104).

Communication diagram: preserve the messages, change the emphasis

Redraw the successful trace as a network. Connect Customer to StoreUI, then connect StoreUI to OrderService, Inventory, Pricing and Payment. Label the links 1: checkout(P42,2,KG10), 2: createDraft(P42,2), 3: reserve(P42,2), 4: quote(2,750,KG10), 5: charge(1350), 6: markPaid(O-104,TX91) and 7: confirm(O-104,1350).

Sequence and communication diagrams can model the same interaction. Sequence makes time easiest to scan. Communication makes collaboration paths and participant links easiest to scan. Without message numbers, however, a communication diagram loses its execution order.

The links also reveal which participants must communicate directly, a relationship that is less prominent in a tall sequence trace.

Choose activity for an end-to-end workflow, state machine for one object's lifecycle, sequence for a time-ordered call trace, and communication for the collaborating object network. Learners ready to implement such object interactions can continue with the Java Course covering concepts, MCQs and coding questions.

Common traps and how exam-style questions expose them

First, sequence and communication are sometimes called structural diagrams. Use the subset rule: they are interaction diagrams, and interaction diagrams are behavioral. Second, Validate stock is sometimes written as a state. It is an action; AwaitingPayment is a state. Third, a decision diamond is treated as stored status. It only routes a token using guards. The order's persistent status belongs in its state machine.

Test the distinctions with three checks:

  • Classification: Among activity, class, sequence and communication, the interaction diagrams are sequence and communication.

  • Trace: After submit, paymentDeclined, retry [stock=3 >= 2] and paymentApproved(TX91), O-104 ends in Paid. Stock is 1 because decline restored it to 3, then retry reserved 2.

  • Consistency: quote(2,750,KG10) returns 1350, not 1400, because 10% of 1500 is 150 and 1500 - 150 = 1350.

Practise all three checks: classify the diagram, execute the trace, then test cross-diagram consistency. Software Engineering for CS Teaching Exams: SDLC to Testing connects UML notation to requirements, design and testing.

Short version and the next study step

Ask four questions. Are you showing a workflow, one object's state, ordered messages, or a collaboration network? Choose activity, state machine, sequence or communication respectively. When several diagrams describe one scenario, their identifiers, guards, messages, totals and end states must agree.

For practice, add Packed -> Cancelled only if a stated rule permits it, then update the activity and sequence views with the resulting refund and stock effects. For a broader foundation, continue with the Zero to Hero Complete CS Course.