# Modeling with UML > UML diagram types, notation and semantics (class, component, deployment, sequence, activity, state, use case, ...). ## UML basics, taxonomy and good practice - [Barriers to UML Adoption](https://arc.fuet.ch/concepts/modeling-uml/barriers-to-uml-adoption.md): People disagree about what UML is for, which explains much of the resistance to it. UML 2 became bulkier for sketch users, and informal use drifts from the standard. Lighter options such as C4 exist. - [Matching Diagram Type to System Aspect](https://arc.fuet.ch/concepts/modeling-uml/matching-diagram-type-to-system-aspect.md): No single diagram shows every aspect of a system. Pick the diagram type that fits the aspect you want to show and the audience, then combine a few complementary diagrams. - [Modeling Tool vs. Drawing Tool](https://arc.fuet.ch/concepts/modeling-uml/modeling-tool-vs-drawing-tool.md): A modeling tool keeps one shared model and draws diagrams from it. A drawing tool makes separate pictures. The choice decides how much work it takes to keep diagrams consistent and correct. - [UML 2.5 Diagram Taxonomy](https://arc.fuet.ch/concepts/modeling-uml/uml-diagram-taxonomy.md): UML 2 defines 14 diagram types, grouped in a taxonomy. Structure diagrams show the static makeup of a system. Behavior diagrams show what it does at runtime. Interaction diagrams are a subgroup of behavior diagrams. - [UML Behavioral Diagram](https://arc.fuet.ch/concepts/modeling-uml/behavior-diagram.md): UML behavior diagrams show how a system works while it runs: how users interact with it, which steps happen, which messages flow, and how states change. Structure diagrams show only the static parts. - [UML Modeling Anti-Pattern](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-anti-patterns.md): A UML modeling anti-pattern is a diagram that claims to be UML but breaks its rules or invents its own. Unexplained arrows and numbers are typical. Readers then guess the meaning, and the documentation loses value. - [UML Modeling Best Practice](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-best-practice.md): Good UML practice means agreeing on shared modeling standards, modeling together, and sharing models openly. Match the precision to how you use UML: quick sketches need less than blueprints. - [UML Perspectives: Conceptual, Specification, Implementation](https://arc.fuet.ch/concepts/modeling-uml/uml-views-conceptual-specification-implementation.md): UML diagrams can be read at three levels. Conceptual diagrams describe the real-world domain. Specification diagrams describe software through interfaces. Implementation diagrams describe code in a specific technology. - [UML Structure Diagram](https://arc.fuet.ch/concepts/modeling-uml/structure-diagram.md): UML structure diagrams show the static parts of a system and how they relate, without showing behavior over time. Different diagram types cover different levels, such as components and hardware. - [Unified Modeling Language (UML)](https://arc.fuet.ch/concepts/modeling-uml/uml-unified-modeling-language.md): UML is a standard graphical modeling language for software. It defines 14 diagram kinds, split into structure and behavior diagrams. It is not a method, so teams use it with a development method. - [Why Use UML in Architecture Documentation](https://arc.fuet.ch/concepts/modeling-uml/why-use-uml-in-architecture-documentation.md): UML is a standardized diagram notation. arc42 authors favor it because tools support it and its meaning is clear. It does not guarantee a better architecture, and any notation works only if stakeholders understand it. ## Class diagrams and relationships - [Aggregation vs. Composition](https://arc.fuet.ch/concepts/modeling-uml/composition-versus-aggregation.md): Aggregation and composition are UML ways to show that something is made of parts. Composition is strict: a part belongs to one whole. Aggregation is loose and adds little beyond a plain association. - [Common Class Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/common-class-diagram-modeling-mistakes.md): Class diagrams often repeat the same errors: impossible multiplicities, shared parts in a composition, missing multiplicity, and wrong arrows. Knowing them helps you review diagrams, even though tools catch some automatically. - [Instance Specification](https://arc.fuet.ch/concepts/modeling-uml/instance-specification.md): An instance specification is a UML model element that stands for one instance in a modeled system. It gives a concrete example, with attribute values, of something a class describes in general. - [UML Association](https://arc.fuet.ch/concepts/modeling-uml/association.md): A UML association is a solid line between two classes. It shows that objects of one class refer to objects of the other. Ends can carry role names, multiplicity and navigability arrows. - [UML Class Diagram](https://arc.fuet.ch/concepts/modeling-uml/class-diagram.md): A UML class diagram shows classes and how they relate. Use it as a selective sketch of the interesting classes, not as a full specification of every class. - [UML Class Diagram Relationship](https://arc.fuet.ch/concepts/modeling-uml/class-diagram-relationships.md): UML class diagrams use different relationship types to link classes. Pick the type that matches the real link: associations resemble fields, composition means single ownership, and aggregation adds no meaning beyond association. - [UML Generalization and Specialization](https://arc.fuet.ch/concepts/modeling-uml/generalization-and-specialization.md): Generalization links a specific class to a more general one. The specific class inherits the general class's characteristics and can add its own. Every instance of the specific class is also an instance of the general class. - [UML Interface](https://arc.fuet.ch/concepts/modeling-uml/uml-interface.md): A UML interface is a contract that lists operations without implementing them. Classes or components realize it. Clients rely on the contract, not on the implementation behind it. ## Component, package and deployment diagrams - [Common Component Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/component-diagram-modeling-mistakes.md): Two common component diagram mistakes are leaving artifacts unlinked to the components they embody, and letting components depend on each other in a cycle. Both are avoidable with manifestation links and acyclic dependencies. - [Component Connector (Assembly and Delegation)](https://arc.fuet.ch/concepts/modeling-uml/component-connector-assembly-and-delegation.md): A connector links parts inside a component design. An assembly connector joins parts so some provide services and others use them. A delegation connector links a component's outer contract to the inner parts that realize it. - [Delegation Connector](https://arc.fuet.ch/concepts/modeling-uml/delegation-connector.md): A delegation connector passes a component's external port inward to an internal part that does the real work. Outsiders see one contract, and the internal structure stays hidden. - [Deployment Diagram Modeling Mistake](https://arc.fuet.ch/concepts/modeling-uml/deployment-diagram-modeling-mistakes.md): Deployment diagrams go wrong in a few repeated ways: deploying the wrong kind of element, mixing up node types, leaving connections unnamed, and leaving configuration unattached. Each has a simple fix. - [Differences between Class, Component and Package Diagrams](https://arc.fuet.ch/concepts/modeling-uml/class-component-and-package-diagram-differences.md): Component and package diagrams both show building blocks and can express hierarchies, because components and packages can be nested. Each one connects or groups blocks in a different way. Both fit the arc42 building block view. - [Nested Components and Subsystems](https://arc.fuet.ch/concepts/modeling-uml/nested-components-and-subsystems.md): A component can contain smaller parts that work together inside it. Ports on its edge pass outside requests to those parts. This lets you describe a system level by level, from a coarse view to detail. - [Package Diagram](https://arc.fuet.ch/concepts/modeling-uml/package-diagram.md): A package diagram groups related model elements into packages, each a namespace with unique names. It shows how packages depend on each other, so you can see a system's structure, such as its layers, at a glance. - [Package Diagram Modeling Mistake](https://arc.fuet.ch/concepts/modeling-uml/package-diagram-modeling-mistakes.md): Package diagrams go wrong in a few typical ways: cycles between packages, unlabeled relationships, wrong containment, and misused merges. Avoiding them keeps the structure readable and easier to change. - [Package Relationships (Import, Access, Merge, Use)](https://arc.fuet.ch/concepts/modeling-uml/package-relationships-import-access-merge-use.md): Package relationships are directed links between packages that show how their contents are shared. Import and merge are covered here. A dependency with no label is read as an import, so label every one. - [Port](https://arc.fuet.ch/concepts/modeling-uml/component-port.md): A port is a named interaction point on the edge of a UML class, part, or component. It is where the owner offers services to its surroundings and makes requests of them. - [Provided and Required Interface](https://arc.fuet.ch/concepts/modeling-uml/provided-and-required-interface.md): A provided interface lists what a component offers. A required interface lists what it needs from others. UML draws them as a ball and a socket, which makes the dependencies between building blocks visible. - [Transfer Object Pattern as Package Template](https://arc.fuet.ch/concepts/modeling-uml/transfer-object-pattern-as-package-template.md): A Transfer Object bundles data so fewer remote calls are needed. In UML, you can document this pattern as a package template and reuse it by binding its parameters to concrete elements with a dashed «bind» arrow. - [UML Component Diagram](https://arc.fuet.ch/concepts/modeling-uml/uml-component-diagram.md): A UML component diagram shows the high-level structure of a software system. It shows the parts and the behavior they offer and use through interfaces. - [UML Deployment Diagram](https://arc.fuet.ch/concepts/modeling-uml/deployment-diagram.md): A UML deployment diagram shows where software runs. It assigns software artifacts to system elements, drawn as boxes called nodes. ## Sequence and use case diagrams - [Common Sequence Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/common-sequence-diagram-modeling-mistakes.md): Many sequence diagram errors come from arrow styles. Replies, asynchronous messages, and lost or found messages are the usual trouble spots. Knowing what each arrowhead and line style means helps you catch them. - [Common Use Case Diagram Errors](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram-modeling-mistakes.md): Use case diagrams often go wrong in repeatable ways: actors inside the boundary, actors named after job titles, technical parts shown as actors, and include or extend used without purpose. Fixing these makes the diagram clear. - [Message Types in Sequence Diagrams](https://arc.fuet.ch/concepts/modeling-uml/message-types-in-sequence-diagrams.md): A message in a sequence diagram is one step of communication between participants. The key distinction is whether the sender waits: a synchronous sender waits until the work is done, an asynchronous sender keeps going. - [UML Sequence Diagram](https://arc.fuet.ch/concepts/modeling-uml/sequence-diagram.md): A UML sequence diagram shows how participants exchange messages over time, read from top to bottom. arc42 recommends it for runtime scenarios because it shows what each building block is responsible for. - [Use Case Diagram](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram.md): A use case diagram gives an overview of what a system offers. It shows the actors who use it and which functions are in scope, without describing how the system works inside. - [Use Case Goal Hierarchy with Include Relationships](https://arc.fuet.ch/concepts/modeling-uml/use-case-goal-hierarchy-with-include-relationships.md): An include relationship links a base use case to another use case whose behavior it always runs as part of its own flow. Shared steps such as Authenticate are written once and reused by many goals. ## State machine diagrams - [Composite State](https://arc.fuet.ch/concepts/modeling-uml/composite-state.md): A composite state is a state that contains inner states in one or more regions. With two or more regions, the regions run at the same time. Each region can have its own start and end. - [Concurrent Region](https://arc.fuet.ch/concepts/modeling-uml/concurrent-region.md): A concurrent region is one of several parts of a composite state. An object in such a state sits in all its regions at once. Each region has its own start and end. - [State and Event](https://arc.fuet.ch/concepts/modeling-uml/state-and-event.md): A state machine describes a system as explicit states joined by transitions. Events are what the machine detects and processes, one at a time, and a guard can decide which transition fires. - [State Entry, Exit and Do Behavior](https://arc.fuet.ch/concepts/modeling-uml/state-entry-exit-and-do-behavior.md): A state can carry its own entry, do and exit behavior. Entry and exit run every time the state is entered or left. The do activity runs in between and can be aborted. - [State Machine Diagram](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram.md): A state machine diagram shows the states an object or behavior can be in. It also shows the events that move it between states, and what happens on each move. - [State Machine Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram-modeling-mistakes.md): State machine diagrams go wrong when start and end markers are misused, when completion transitions compete, or when guards overlap. Knowing these errors helps you build models with one clear behavior. - [State Machine Transition](https://arc.fuet.ch/concepts/modeling-uml/state-machine-transition.md): A state machine transition is the switch from one active state to another, triggered by an event. A guard can block it. Transitions can be external, local, or internal, which differ in whether they leave the state. - [Transition Syntax (Trigger, Guard, Behavior)](https://arc.fuet.ch/concepts/modeling-uml/transition-syntax.md): A UML transition moves a state machine from one state to another. Its label can name a trigger (the event), a guard (a condition in brackets), and a behavior (what runs after the slash).