What is the difference between structural and behavioural UML diagrams?

## Two families, and what the division is about UML's diagram types are not a flat list. The specification divides them into **structure diagrams** and **behaviour diagrams**, and the division is about *what is being modelled* — never about how detailed the drawing is, how formal it is, or who is allowed to draw it. A **structure diagram** describes what a system is made of and how the pieces are arranged. It is timeless: nothing in it happens, and no ordering can be read out of it. If you could freeze the system and photograph it, a structure diagram is a labelled description of that photograph — the parts, the connections between them, and the rules those connections obey. A **behaviour diagram** describes what the system does. Time, triggering and ordering are its content. Something occurs first and something else follows; a condition decides which way control goes; an outside party pursues a goal that the system exists to serve. | Family | Diagram | The question it answers | | --- | --- | --- | | Structure | Class | Which types exist, and what relationships and multiplicities constrain them? | | Structure | Object | At one moment, which instances exist and how are they linked? | | Structure | Package | How is the model grouped, and which group depends on which? | | Structure | Component | Which units exist, and what interfaces does each offer and require? | | Structure | Composite structure | What is inside one classifier — its parts, ports and connectors? | | Structure | Deployment | Which pieces of software run on which runtime node? | | Behaviour | Use case | Which outside parties pursue which goals against the system boundary? | | Behaviour | Activity | Through which steps, decisions and concurrent paths does control flow? | | Behaviour | State machine | Which lifecycle states may one object occupy, and which transitions are legal? | | Behaviour | Interaction — sequence, communication, timing, interaction overview | Who exchanges which messages with whom, and in what order? | ## Where the interaction family sits The last row matters and is the part most often got wrong. UML does not place sequence diagrams directly under the behavioural half; it nests an **interaction** sub-family there, and sequence, communication, timing and interaction-overview diagrams are all members of it. What the members share is the subject — an exchange of messages between named participants over time. What differs is the emphasis: one lays time out along an axis, one lays the participants out as a connected structure, one shows how a participant's condition changes against a time scale, and one stitches whole interactions together into a larger control flow. So the honest answer to *is a sequence diagram behavioural* is yes, at one remove: it is an interaction diagram, and interaction diagrams are behaviour diagrams. ## The four cases that trip candidates up - **Object diagrams are structural, not a run of the system.** A class diagram is type-level — the rules that hold for every instance. An object diagram is instance-level — one snapshot of particular instances and the links between them. Both are structural, because both describe an arrangement rather than an unfolding. - **Interaction diagrams draw objects but are not structural.** The participants along the top are context; the content is the ordered messages between them. Judge by what the diagram asserts, not by what symbols appear on it. - **Deployment diagrams are structural although they are about runtime.** They say which software sits on which runtime node — a device or execution environment. That is an arrangement, and it holds regardless of what happens next. - **Use-case diagrams are behavioural although they look static.** They carry no ordering and no messages, yet what they model is the behaviour the system offers to outside parties, expressed as goals. The family is decided by the subject, not by whether time is drawn. ## What the split does not decide The two families say nothing about detail, audience or lifespan. A structural diagram can be a thirty-second whiteboard sketch and a behavioural one can be a carefully kept model, or the reverse. Nor does the split ration you to one diagram: a single feature commonly deserves one from each half — a structural picture of what participates and a behavioural picture of what happens between them — and a design conversation that only ever produces diagrams from one half is usually leaving half the question unanswered. The practical payoff of knowing the taxonomy is routing. Someone asks a question in a design discussion; you decide which half it lives in before choosing a notation. *Arrangement, ownership, grouping and placement* are answered in the structural half; *ordering, triggering, permitted lifecycle and who wants what* in the behavioural half. Getting the half right is most of the work, because within a half only a handful of candidates remain and each is obviously about something different. There is a matching negative use, and in review it is the more valuable one. Each family has a permanent blind spot: a structural diagram can never establish that one thing happens before another, and one behavioural scenario can never establish an invariant holding across every scenario. A document leaning on one diagram to make a claim of the other kind has a defect, not a subtlety of notation.