UML: Activity, State & Component Diagrams — Practical Use

Activity Diagrams: Workflow & Process Logic

[Start] --> (Submit Order) --> <Order value > $1000?>
                                    |Yes            |No
                                    v                v
                          (Manager Approval)  (Auto-Approve)
                                    |                |
                                    +------>[End]<---+

# Conceptually a standardized flowchart -- decision points,
# branches, start/end nodes -- part of the UML notation family

State Machine Diagrams: Object Lifecycle

[Pending] --ship--> [Shipped] --deliver--> [Delivered]
    |
    +--cancel--> [Cancelled]

# Makes valid transitions explicit -- a Delivered order cannot
# transition back to Pending -- useful for design AND for catching
# invalid-transition bugs

Component & Package Diagrams: Architectural View

Component diagrams show a system's larger modules/services and their interfaces/dependencies -- coarser granularity than a class diagram. Package diagrams show how classes organize into namespaces/modules and can surface problematic dependencies, like a 'reporting' package unexpectedly depending on 'billing' internals.

Using UML Pragmatically

• Sketch during active design discussions (whiteboard) to catch problems early and cheaply, before implementation.

• Choose the diagram type that matches what you're communicating -- structure (class), flow (sequence), process (activity), lifecycle (state).

• Exhaustive, always-synchronized documentation for an entire codebase tends to go stale -- many teams focus UML on genuinely complex or hard-to-understand-from-code parts of a system instead.

• UML class diagrams model object-oriented structure (classes + behavior + inheritance); ER diagrams model relational database structure -- related but distinct tools for different paradigms.