Use when modeling software systems using the Unified Modeling Language (UML) standard. Covers structural and behavioral diagram types, notation, relationships, multiplicity, visibility, and stereotypes.
USE FOR: class diagrams, sequence diagrams, activity diagrams, state machine diagrams, use case diagrams, component diagrams, deployment diagrams, package diagrams, object diagrams, UML notation reference, relationship types, multiplicity, visibility modifiers, stereotypes
DO NOT USE FOR: text-based diagram rendering (use mermaidjs, plantuml, or d2), enterprise architecture views (use togaf or archimate), data modeling (use erd)
Use when modeling software systems using the Unified Modeling Language (UML) standard. Covers structural and behavioral diagram types, notation, relationships, multiplicity, visibility, and stereotypes.
USE FOR: class diagrams, sequence diagrams, activity diagrams, state machine diagrams, use case diagrams, component diagrams, deployment diagrams, package diagrams, object diagrams, UML notation reference, relationship types, multiplicity, visibility modifiers, stereotypes
DO NOT USE FOR: text-based diagram rendering (use mermaidjs, plantuml, or d2), enterprise architecture views (use togaf or archimate), data modeling (use erd)
license
MIT
metadata
{"displayName":"UML","author":"Tyler-R-Kendrick"}
compatibility
claude, copilot, cursor
references
[{"title":"OMG Unified Modeling Language (UML) Specification","url":"https://www.omg.org/spec/UML/"},{"title":"UML — Wikipedia","url":"https://en.wikipedia.org/wiki/Unified_Modeling_Language"}]
UML — Unified Modeling Language
Overview
UML (Unified Modeling Language) is a standardized visual modeling language maintained by the Object Management Group (OMG). It provides a comprehensive set of diagram types for describing the structure, behavior, and interactions of software systems. UML is tool-agnostic — it defines notation and semantics, not rendering. For text-based rendering of UML diagrams, see the , , or skills.
mermaidjs
plantuml
d2
Diagram Categories
UML defines two broad categories: structural diagrams (static aspects) and behavioral diagrams (dynamic aspects).
Structural Diagrams
Diagram
Purpose
Class
Classes, attributes, operations, and relationships
"Has-a" (weak ownership, part can exist independently)
Composition
Solid
Filled diamond
"Owns-a" (strong ownership, part destroyed with whole)
Inheritance (Generalization)
Solid
Open triangle
"Is-a" (subclass extends superclass)
Realization (Implementation)
Dashed
Open triangle
Class implements an interface
Dependency
Dashed
Open arrow
"Uses temporarily" (parameter, local variable)
Visual Notation
Association: A ──────────── B
Directed: A ─────────> B
Aggregation: A ◇────────── B (A has B, B can exist alone)
Composition: A ◆────────── B (A owns B, B dies with A)
Inheritance: A ────────▷ B (A extends B)
Realization: A - - - -▷ B (A implements B)
Dependency: A - - - -> B (A depends on B)
Multiplicity
Multiplicity indicates how many instances participate in a relationship.
Notation
Meaning
1
Exactly one
0..1
Zero or one (optional)
* or 0..*
Zero or more
1..*
One or more
n
Exactly n
n..m
Between n and m
Example:
Customer 1 ──────── 0..* Order
(One customer places zero or more orders)
Order 1 ──────── 1..* OrderItem
(One order contains one or more items)
A snapshot of instances and their relationships at a specific point in time. Uses the same notation as class diagrams but shows objects (instances) instead of classes.
Constraints are boolean expressions enclosed in curly braces {} that restrict model elements.
{ordered} - Collection is ordered
{unique} - No duplicates allowed
{readOnly} - Cannot be modified after initialization
{frozen} - Cannot be changed after creation
{xor} - Exactly one of the associations applies
{subset} - One collection is a subset of another
Notes
Notes are attached to any UML element with a dashed line.
┌──────────────┐
│ Order │ ─ ─ ─ ┐
├──────────────┤ │
│ + total: Dec │ ┌────┴──────────────┐
└──────────────┘ │ total must be >= 0 │
│ {total >= 0} │
└───────────────────┘
Best Practices
Choose the right diagram for the audience. Use case diagrams for stakeholders, class diagrams for developers, deployment diagrams for operations.
Do not model everything. UML is a communication tool, not a code generation specification. Model only what adds clarity.
Keep diagrams focused. One diagram, one concern. A class diagram should not try to show every class in the system.
Use consistent naming. Class names in PascalCase, operations in camelCase, constants in UPPER_CASE.
Show multiplicity on all associations. Omitted multiplicity is ambiguous and forces readers to guess.
Distinguish aggregation from composition. Use composition (filled diamond) when the part cannot exist without the whole; use aggregation (open diamond) when it can.
Use stereotypes sparingly. Only add stereotypes that convey meaning your audience needs. Do not decorate every element.
Combine structural and behavioral diagrams. A class diagram shows what exists; a sequence diagram shows how it behaves. Together they tell the full story.
Use packages to manage complexity. For systems with many classes, organize them into packages first, then detail individual packages.
Validate against code. If your UML diverges from the actual code, the diagrams become misleading. Keep them synchronized or clearly label them as aspirational.
Prefer text-based tools. Use Mermaid, PlantUML, or D2 to write UML diagrams as code so they can be version-controlled and reviewed in pull requests.
