What Do UML’s Solid Lines, Dashed Lines, Hollow Triangles, and Diamonds Actually Represent?

Class Diagram Relationships

Class diagrams convey both the classes in a system and the relationships between them. Six line symbols are required:

Solid line – Association (stable, long‑term structural relationship). Example: User ↔ Order, Product ↔ Category, Order ↔ PaymentRecord.

Dashed line with arrow – Dependency (temporary use). Example: OrderService calls SmsService only after an order is placed successfully.

Solid line + hollow triangle – Generalization / Inheritance. Example: MemberUser and EnterpriseUser inherit from User.

Dashed line + hollow triangle – Realization (class implements an interface). Example: AlipayPayment and WechatPayment realize PaymentInterface, which defines pay, refund, and queryStatus.

Hollow diamond + solid line – Aggregation (weak ownership; part can exist independently). Example: Class‑Room ↔ Student or ShoppingCart ↔ Product.

Solid diamond + solid line – Composition (strong ownership; part’s lifecycle depends on the whole). Example: Order ↔ OrderItem.

Summary table:

Solid line – Association.

Dashed line with arrow – Dependency.

Solid line + hollow triangle – Generalization / Inheritance.

Dashed line + hollow triangle – Realization.

Hollow diamond – Aggregation.

Solid diamond – Composition.

Use‑Case Diagram Relationships

Three relationship types are added beyond the basic actor‑use‑case connections:

include – A mandatory, reusable step that every execution of a base use case must perform. Example: Placing an order includes login verification; payment includes identity verification.

extend – An optional step that occurs only under certain conditions. Example: Using a coupon during order placement or retrying payment after a failure.

generalization – “Is‑a” relationship between a specialized use case and a more general one. Example: OnlinePayment is a kind of Payment.

Distinguishing include from extend: ask whether the step must happen every time (include) or only when a condition is met (extend).

Sequence Diagram

Sequence diagrams emphasize time. Read from top to bottom for chronological order, horizontally for participants, and arrows for messages. Example e‑commerce order flow:

User → OrderService: submit order.

OrderService → InventoryService: check inventory.

InventoryService → OrderService: inventory result.

OrderService → PaymentService: create payment.

OrderService → Kafka: publish order event.

OrderService → User: return order result.

Thus a sequence diagram describes the ordered exchange of messages between objects.

Activity Diagram vs State Diagram

Activity diagram models business processes: steps, decisions, and branches. Example flow: select product → add to cart → submit order → check inventory → if sufficient, proceed to payment; otherwise, show failure.

State diagram models an individual object's lifecycle: states and transitions. Example order states: Pending Payment → Paid → Shipped → Completed, with possible transitions to Cancelled or Refunded.

Component Diagram vs Deployment Diagram

Component diagram shows software components and their dependencies. Example: OrderService depends on InventoryService, PaymentService, Kafka, and a common authentication component.

Deployment diagram shows where software artifacts are deployed on server nodes. Example: OrderService on an application‑server cluster, Redis on a cache server, Kafka on a message‑broker cluster, and the order database on a database server.

Mnemomic for UML Diagram Purposes

Use‑case – actors & functions.

Class – classes & relationships.

Sequence – time & messages.

Activity – business flow.

State – object lifecycle.

Component – software dependencies.

Deployment – server nodes.

Practice Question (Exam‑style)

In an e‑commerce class diagram, identify the relationships:

Order ↔ OrderItem (OrderItem cannot exist without Order) – Composition (solid diamond).

AlipayPayment and WechatPayment implement PaymentInterface – Realization (dashed line + hollow triangle).

OrderService temporarily calls SmsService – Dependency (dashed line with arrow).

Self‑Test

Solid line in a class diagram represents Association.

Dashed line with arrow represents Dependency.

Solid line + hollow triangle represents Generalization / Inheritance.

Dashed line + hollow triangle represents Realization.

Hollow diamond vs. solid diamond distinguishes Aggregation (weak ownership) from Composition (strong ownership).

Include vs. Extend: mandatory common step vs. optional conditional step.

Read a sequence diagram top‑down for time, horizontally for participants, arrows as messages.

Activity diagram shows process flow; State diagram shows object state changes.

Component diagram shows software component dependencies; Deployment diagram shows physical node placement.

Order ↔ OrderItem is a Composition relationship.