The Types of UML Diagrams: Structural vs Behavioral
UML has fourteen diagram types split into two families: structural diagrams for what a system is, and behavioral diagrams for what it does. This guide maps them all and helps you pick.
The fourteen UML diagram types can feel like an arbitrary list to memorize, but they are organized around one clean idea: some diagrams describe the static structure of a system, and others describe its dynamic behavior. Once you internalize that split, the whole language becomes navigable, because the first question for any modeling task becomes simply "am I describing what exists, or what happens?" The answer points you at half the catalog immediately.
This guide maps both families, gives a one-line purpose for every diagram, and then focuses on the practical question of which handful you actually need. If you want to try any of them, the editor at /diagrams supports UML shapes, and the tool pages under /diagram-tools cover the most common types in depth. The goal here is orientation: a mental map you can carry into any design conversation.
The two families
Structural diagrams model the things that exist in a system and how they are arranged, frozen in time. If you took a photograph of the system's design, structural diagrams describe what is in the frame: the classes, components, packages, and nodes, and the relationships between them. They are the nouns of your system.
Behavioral diagrams model what the system does over time: how it responds to events, how its parts collaborate, how an object's condition changes. If structural diagrams are a photograph, behavioral diagrams are a film. They are the verbs. A subset of behavioral diagrams, the interaction diagrams, focuses specifically on how participants exchange messages, and includes the sequence and communication diagrams. Every one of the fourteen types falls cleanly into one of these two families.
The seven structural diagrams
The structural family describes what exists. Some members you will use constantly and others you may never draw, but knowing the full set means you always have the right tool available.
- Class diagram: classes, their attributes and methods, and the relationships among them. The most-used structural diagram.
- Object diagram: a snapshot of specific instances at one moment, illustrating a class diagram with concrete values.
- Component diagram: the system's major building blocks and the interfaces they provide and require.
- Deployment diagram: the physical topology of nodes and the artifacts deployed on them.
- Package diagram: the grouping of model elements into namespaces and the dependencies between packages.
- Composite structure diagram: the internal parts and connectors within a class or component.
- Profile diagram: a way to extend UML with custom stereotypes for a specific domain.
The seven behavioral diagrams
The behavioral family describes what happens. This is where most of the day-to-day value of UML lives, because behavior is harder to hold in your head than structure and therefore benefits most from being drawn.
The seven are: the use case diagram (who uses the system and to do what), the activity diagram (workflow and control flow), the state machine diagram (an object's states and transitions), and the four interaction-oriented ones. Of those, the sequence diagram (ordered message exchange over time) is by far the most used; the communication diagram shows the same interactions emphasizing links rather than time; the timing diagram plots behavior against a real time axis for embedded and real-time work; and the interaction overview diagram stitches interaction fragments into a high-level flow. The sequence, activity, use case, and state machine diagrams are the four you will actually reach for; the tool pages at /diagram-tools/sequence-diagram and /diagram-tools cover them further.
Choosing the right diagram
The practical skill is matching the diagram to the question, and you do not need all fourteen for that. Start by asking whether you are describing structure or behavior. If structure, ask whether you care about classes (class diagram), building blocks (component), or physical hosting (deployment). If behavior, ask whether you care about user goals (use case), a process (activity), an object's lifecycle (state machine), or a runtime conversation (sequence).
That decision tree covers the overwhelming majority of real modeling needs with just seven diagrams, and four of them do most of the work. The remaining specialized types, package, composite structure, profile, object, communication, timing, and interaction overview, are worth knowing by name so you recognize them, but you should learn each one only when a concrete problem calls for it. Resist the urge to model comprehensively; model to answer a specific question, and stop when it is answered.