Lucent Owl logo Lucent Owl

UML Diagram Notation

Last updated:

2 related guides
uml diagrams class-diagrams sequence-diagrams state-machines modeling

Three Perspectives on One Class

Structure

One Order class as concept, as interface, and as code.

Three Perspectives on One Class The same Order class drawn as a domain concept, as an interface, and as the code, with detail added at each step. CONCEPTUAL domain concepts, no types Order placed on total lines SPECIFICATION the interface, no implementation Order + PlacedOn : DateTime + Total : Money + AddLine(item, qty) : void + Cancel() : void IMPLEMENTATION mirrors the code Order - _id : Guid - _lines : List<OrderLine> - _placedOn : DateTime + Total : Money { get; } + Order(Guid id) + AddLine(CatalogItem, int) : void - Recalculate() : void + Cancel() : void The perspective decides how much detail belongs on the diagram. Implementation views drift from the code within weeks, so generate them or draw at one of the other two perspectives instead.

Class Notation

Structure

The compartments, visibility markers, and parameter directions of a class box.

Class Notation What each compartment of a class box holds, what the visibility markers mean, and how a parameter states its direction. CatalogItem + Sku : string - _price : Money # Category : string ~ Warehouse : string + Reprice(in Money newPrice) : void + TrySplit(out CatalogItem half) : bool + Merge(inout Stock level) : void the class name attributes, each with a visibility marker: + public − private # protected ~ package operations, whose parameters can state a direction: in, out, or inout Leave out any compartment, and any member, that does not serve the point the diagram is making.

Class Relationship Notation

Rules

The six relationship lines and their arrowheads and diamonds.

Class Relationship Notation The six lines that carry most of a class diagram’s meaning, drawn with the arrowhead or diamond that distinguishes each one. Order Customer 1 0..* Association one type holds or references the other CardPayment Payment Generalization the child is a kind of the parent CardPayment IPayable Realization the class implements the interface Order PriceRule Dependency one uses the other without holding it OrderLine Basket Aggregation parts can exist without the whole OrderLine Order Composition the part dies with its one whole The specification leaves aggregation’s meaning open, so readers read the hollow diamond differently.

Class Diagram for the Order Domain

Structure

The order domain with all six relationship kinds.

Class Diagram for the Order Domain One subsystem drawn with all six relationship kinds, showing only the members that matter to the point the diagram makes. «interface» IPayable + Authorize(Money) : bool Payment {abstract} + Amount : Money + Authorize(Money) : bool CardPayment + Last4 : string «entity» Customer + Id : Guid + Name : string «entity» Order + PlacedOn : DateTime + Status : OrderStatus + Total() : Money «entity» OrderLine + Quantity : int + UnitPrice : Money CatalogItem + Sku : string + Price : Money Basket + AddedOn : DateTime «uses» 1 0..* 1 1..* 0..* 1 1 0..* 1 0..1 Stereotypes such as «entity» and «interface» mark the role a class plays, and an italic name marks an abstract class.

Component Notation

Structure

Lollipop, socket, and port notation on one component.

Component Notation The lollipop, socket, and port notation that says which interfaces a component provides, which it requires, and where they attach. «component» Terminal SafetyInspection «component» Staff «component» Defect «component» Map «component» provided interface (lollipop) «IInspection» required interface (socket) «IStaffDirectory» port: where an interface meets the component boundary A delegation connector routes a port through to the part inside that implements the interface. Where one component’s socket meets another’s lollipop, the dependency is satisfied.

Component Diagram for Online Store

Structure

Five components of the Online Store and their interfaces.

Component Diagram for Online Store Five replaceable parts of one system and the interfaces that connect them, which is the design decision a component diagram exists to record. «component» StoreFront customer-facing UI «component» Checkout basket and payment «component» Catalogue products and prices «component» OrderSystem places and tracks orders «component» PaymentAdapter wraps the gateway SDK «ICatalogue» «IOrders» «IAuthorize» A socket meeting a lollipop means the required interface is satisfied. Ports are where an interface attaches to the boundary.

Deployment Diagram for Online Store

C4 · Deployment

Artifacts on nodes, with protocols and network zones.

Deployment Diagram for Online Store Which artifacts run on which nodes, the protocol on every communication path, and the network zone each node sits in. PUBLIC INTERNET PRIVATE SUBNET «device» Client device «artifact» store.spa.js «execution environment» App server × 3 «artifact» orders-api.dll «artifact» worker.dll «device» Database server «artifact» orders.schema «device» Cache node × 2 redis.conf «HTTPS» «TCP/IP, TLS» «TCP» Nodes are devices or execution environments. Artifacts are what gets deployed onto them. Naming the protocol on each path and marking the network zones adds more than drawing every node.

Sequence Diagram for Checkout

C4 · Dynamic

One checkout scenario with activations, fragments, and a destroyed lifeline.

Sequence Diagram for Checkout One checkout scenario in message order, with activations, a self message, loop and alt fragments, and a lifeline created and destroyed. :Customer :Checkout :OrdersApi :PaymentGw :Order checkout() POST /orders validate() «create» loop [each order line] addLine(item, qty) alt [funds available] authorize(total) approved [declined] «destroy» 201 Created confirmation page A filled arrowhead is a synchronous call, a dashed line a reply, a dashed line to a new head a creation, and an X the end of a lifeline. One scenario per diagram, including the error path that prompted it.

Activity Diagram Notation

Rules

The glyphs of an activity diagram, including decision versus merge.

Activity Diagram Notation The glyphs an activity diagram is built from, and the distinction between a decision and a merge, and between a fork and a join. initial node Receive order decision [in stock] [else] Reserve stock Backorder item merge Charge card fork Pack items Email receipt join activity final A diamond is a decision when one flow enters and guarded flows leave, and a merge when alternatives rejoin. A bar is a fork when it splits one flow into parallel flows, and a join when it waits for all of them. Using a join where the branches are alternatives describes a process that never completes.

Activity Diagram for Order Fulfilment

Flow

Order fulfilment with a decision, a fork, and a join.

Activity Diagram for Order Fulfilment One business workflow with a decision, a parallel fork and join, and every path reaching an end. Receive order Check stock [else] Backorder and notify [in stock] Reserve stock Charge card Pack and ship Every action names what is done, not who does it. The partitioned version of this same flow adds the roles to it. A merge passes along whichever branch arrives; a join waits for all of its parallel inputs.

The Same Flow, Partitioned

Flow

The same flow in partitions, one per role.

The Same Flow, Partitioned The order fulfilment flow divided into partitions, so that every action says which role performs it and every handoff is visible. CUSTOMER SERVICE WAREHOUSE FINANCE Receive order Check stock [in stock] Reserve stock [else] Backorder and notify Charge card Pack and ship Handoffs between partitions are where delays and errors concentrate, which is what the lanes make visible.

State Machine for an Order

State machine

The states of an order and the events between them.

State Machine for an Order The states an order moves through, the events that move it, and the transitions that are deliberately absent. place order Pending Paid entry / reserveStock Shipped Cancelled Delivered paymentReceived [stock available] / reserveStock dispatched / notifyCustomer cancel cancel / refundPayment delivered No cancel transition leaves Shipped, so an order cannot be cancelled after dispatch. The diagram shows as much by what is missing. Each transition reads trigger [guard] / effect, and each one maps to a test.

Use Case Notation

Structure

Actors, use cases, and the system boundary.

Use Case Notation Actors, the goals the system serves for them, and the boundary that says which goals are inside the system being scoped. ONLINE STORE Browse catalogue Place order Track shipment Customer Courier API «system actor» An actor is a role, not a person: one human may play several, and an external system can be an actor. The ovals are a table of contents. The requirements live in the written use case behind each one.

Include, Extend, and Generalization

Rules

Which way include, extend, and generalization each point.

Include, Extend, and Generalization Which way each of the three use case relationships points, and what the arrow direction means in each case. Place order Authenticate «include» points to the behaviour the base always performs Place order Apply coupon «extend» [discount code entered] points to the use case being extended, under a condition Pay Pay by card generalization the specialized one points at the general one The arrows for include and extend point in opposite directions, which is the most common error on these diagrams.

Found this useful? Share it:

Share on LinkedIn