Read the symbol before the direction of the line
A connector is a statement about a design. Its head, line style, endpoint roles, and multiplicities have different jobs. Moving a head to the top or bottom of a class can make the drawing clearer, but does not turn an ownership relationship into inheritance or change which class is the whole.
Use this table to choose among the six relationship kinds in Erd Go. The From and To fields in the Inspector determine which class plays each role. The hollow triangle points toward a general type or an implemented interface; a diamond sits next to a whole. They are not interchangeable arrow decorations.
| Relationship | Example | Read the head |
|---|---|---|
| Association | Customer places Order | Plain line; optional navigation belongs to the association. |
| Inheritance | CardPayment specializes Payment | Solid line, hollow triangle at Payment. |
| Realization | CardPayment implements Payable | Dashed line, hollow triangle at Payable. |
| Aggregation | Team groups Member | Hollow diamond at Team, the whole. |
| Composition | Order owns OrderItem | Filled diamond at Order, the whole. |
| Dependency | Checkout uses TaxService | Dashed line, open arrow toward TaxService. |
Use association for a structural link
An association connects instances that participate in a relationship. A Customer placing Orders is a useful example. The name places describes the link, while endpoint role names describe how each side is used. Role names are especially valuable when the same pair of classes has two different links.
For example, Order can refer to Address as billingAddress and shippingAddress. Keep those associations separate and give their ends distinct roles. Changing only a multiplicity or a drawing style does not explain why two otherwise identical connectors exist. If the design permits both references to point at the same address object, record that rule separately.
Navigability describes traversal of an association, not execution order. An arrow from Order toward Customer can express navigation toward the customer. An unadorned association leaves navigability unspecified; it should not automatically be read as bidirectional. Navigation arrows do not turn the line into a dependency.
Read multiplicity from the opposite instance
The bound printed next to Order answers: for one Customer, how many Orders may participate? The bound next to Customer answers the reverse question. With Customer 1 — 0..* Order, each order has one customer, and a customer may have no orders or many.
Multiplicity counts instances, not classes, database columns, or the number of lines on the canvas. A 1..* item bound is inappropriate if a newly created draft order is allowed to contain no items. Discuss the lifecycle state or put the qualified rule in a note rather than choosing a lower bound only because the example happens to contain items.
| Notation | Meaning at that end |
|---|---|
| 1 | Exactly one instance. |
| 0..1 | No instance or one instance. |
| 0..* | Zero or more instances. |
| 1..* | One or more instances. |
Distinguish shared grouping from composition
Aggregation uses a hollow diamond for a whole/part grouping. The detailed meaning of shared aggregation depends on the domain and modeling convention; explain it when an ordinary association would otherwise communicate the same thing. A Team grouping Members does not by itself define how accounts are stored or deleted.
Composition is a stronger ownership statement. A part can belong to at most one composite owner at a time. The model ties the lifetime of parts still contained in the whole to that whole. Do not reduce this to a claim that a part can never be detached: removing a part from a composition before deleting the whole is a separate case.
For Order and OrderItem, use a filled diamond next to Order when an item is a line belonging to that order. A shared Product catalog entry is a different concept: several order lines may reference one Product, so making Product a composed part of each Order would misstate the design. Neither diamond automatically installs SQL delete cascades.
Separate specialization, contracts, and temporary use
Inheritance says that a specialized type is a kind of its general type. If CardPayment specializes Payment, draw the hollow triangle at Payment. Consider whether callers can use the subtype where the general type is expected, rather than inheriting merely to reuse a convenient field.
Realization connects an implementation to a specification such as an interface. CardPayment realizing Payable uses a dashed line with the triangle at Payable. An operation like pay(amount: Decimal): Boolean describes a contract; the class diagram does not contain the payment algorithm.
Dependency expresses use or reliance without requiring a stored structural association. Checkout depending on TaxService for a calculation is an example. Point the dashed open arrow at the supplier. A parameter, operation call, or implementation decision may motivate a dependency, but drawing it does not establish runtime call order.
Check meaning before adjusting the route
In Class Diagram, select a connector to review its kind, From/To classes, roles, and multiplicities. Keep names close to the ends they describe. Use the label for the relationship itself and a note for a rule that cannot be expressed by one endpoint count.
Curved is the default. View → Connection paths switches all links to Curved or rounded Elbow paths; the selected relationship can override its Line path individually. Automatic heads adapt as classes move. Pin only an end whose side you want to fix, or return it to Auto when the surrounding layout changes.
Checks can reveal malformed bounds and structural issues, but a diagram can pass those checks and still misrepresent the business. Review one real scenario in both directions, verify every triangle and diamond, then export a view with enough context to understand the rules.
References and further reading
Try the model in Class Diagram
Start with a blank model or explore the order-system template.