Misuse of association, aggregation, and composition is a recurring source of ambiguity in Sparx UML models. Teams often select uml relationships by appearance rather than semantics, producing EA UML diagrams that imply ownership, sharing, or lifecycle effects that the implementation cannot honor. The most persistent misconception is that aggregation conveys ownership and deletion semantics; in UML it does not—only uml composition does.
This article provides a precise, UML‑focused treatment of these relationships: when a plain association is sufficient, when a whole–part pattern is appropriate, and when uml composition is required to model exclusive ownership and lifecycle. The goal is a testable model whose semantics align with analysis, design, and generated code.
Standardize modeling with Enterprise Architect—proven, scalable, and ready for teams. Get licenses with expert onboarding.
What is an Association in UML Modeling?
An association in UML models a structural relationship between classifiers indicating knowledge or interaction without implying ownership or lifecycle control. In EA, associations carry role names, multiplicities, and navigability on their association ends. Use it when two concepts collaborate or reference each other, independent of whole–part semantics or deletion effects.
EA UML Diagrams support association ends with role names, multiplicities, qualifiers, constraints, and navigability. Direction can be unspecified, one-way, or bidirectional; code engineering commonly maps a navigable end to an attribute or collection in generated code. Prefer association by default, strengthening to aggregation or composition only when domain semantics justify whole–part modeling.
What is Aggregation in UML?
Aggregation in UML is a shared whole–part association indicated by a hollow diamond at the whole end. It groups parts without exclusive ownership or cascade deletion. Parts may exist independently and be referenced by multiple aggregates. Use it to express organizational or physical grouping rather than lifecycle control or containment.
In Sparx UML Diagrams, choose Association and set Aggregation to Shared to render the hollow diamond at the whole. The tool doesn’t enforce lifecycle semantics; use multiplicities and constraints to define sharing rules. Many teams’ reserve aggregation for clarity where grouping adds meaning; otherwise, a plain association is usually sufficient.
What is Composition in UML Models?
UML Composition is composite aggregation: a whole–part association with exclusive ownership and coincident lifecycles, shown by a filled diamond at the whole end. A part belongs to at most one composite at a time; if the composite is destroyed, its parts are destroyed. Use it for strong containment and lifecycle management.
In Sparx EA, set UML Aggregation to Composite on the part end; EA draws a filled diamond at the whole. Model exclusive ownership with multiplicity 1 or 1..* at the part end, avoid reusing the same instance elsewhere, and document deletion effects. Use Diagram Legends and reviews to keep composites consistent.
Comparison Table: Association vs Aggregation vs Composition
| Aspect | UML Association | UML Aggregation (shared) | UML Composition (composite) |
|---|---|---|---|
| Meaning/Intent | Generic relationship; collaboration/knowledge between classifiers | Whole groups parts without owning lifetime | Whole owns parts’ lifecycle; deletion cascades |
| UML/EA Notation | Line (optionally directed) | Hollow diamond at whole | Filled diamond at composite |
| Ownership & Lifecycle | None implied | Parts independent; no cascade on delete | Exclusive ownership; parts deleted with whole |
| Part Exclusivity | N/A | Parts may be shared across wholes | Part belongs to one composite only |
| Typical Multiplicity | Any | Whole 0..1 or 1; part often 0..* | Part commonly 1..*; avoid sharing |
| Navigability | Either/both ends as needed | Either/both ends as needed | Either/both ends as needed |
| Examples | User—Credential, Service—Client | Team—Player, Library—Book | Order—OrderLine, House—Room |
| EA UML Modeling Tips | Name roles, set multiplicities, use qualifiers if needed | Place hollow diamond at whole; clarify sharing rules | Place filled diamond at composite; avoid reusing the same part |
E‑Commerce Example: Association, Aggregation & Composition in One Class Diagram
This single Sparx UML Class diagram uses five classes—Customer, Order, OrderLine, Catalog, Product—to demonstrate all three connector semantics clearly and consistently.
1) Customer — Order (Association)
Use a plain association to express collaboration without ownership. A Customer (1) places 0..* Orders. Keep the association navigable from Customer to Order only (optional), with role names customer and orders. No diamonds: this is knowledge/reference, not containment or lifecycle control.
2) Order ◆— OrderLine (Composition)
UML Composition models exclusive ownership and coincident lifecycles. Order (1) composes 1..* OrderLines. The filled diamond is on the Order end (the whole). Deleting an Order implies deleting its OrderLines. Good refinements: a qualifier on the line end (e.g., [lineNo]) and an invariant on Order such as {total = Σ(lines.quantity × product.price)}.
3) OrderLine — Product (Association)
Each OrderLine must point to exactly one Product (1), while a Product can be referenced by 0..* lines. This remains a plain association (no diamond). It shows that a composed part (OrderLine) can still reference shared, independent elements (Product) outside its composite.
4) Catalog ◊— Product (Aggregation, Shared)
UML Aggregation communicates grouping without lifecycle control. Catalog (1) aggregates 1..* Products; the hollow diamond sits on Catalog. Products exist independently, may appear in multiple Catalogs, and are unaffected if a Catalog is deleted. Prefer UML aggregation here to make the grouping semantics explicit to reviewers.
Enterprise Architect UML Diagram hygiene & review tips
- Multiplicity: Customer–Order 1 — 0..*; Order–OrderLine 1 — 1..*; OrderLine–Product * — 1; Catalog–Product 1 — 1..*.
- Navigability (suggested): Customer→Order, Order→OrderLine, OrderLine→Product, Catalog→Product.
- Readability: Turn on role names and multiplicities; keep arrows minimal to avoid visual noise.
- Governance in EA: Use a Diagram Legend to color Association/Aggregation/Composition differently, and a Relationship Matrix to ensure every Order has at least one OrderLine and no OrderLine links to multiple Orders.
Level up quickly with hands-on UML training delivered by certified Sparx EA experts—real projects, clear outcomes.
FAQs on Choosing Between Association, Aggregation & Composition
1) How do I decide between association, aggregation, and composition?
Use association for collaboration without whole–part relationship. Use UML aggregation when a whole groups parts that can exist independently and may be shared. Use UML composition when the whole owns parts’ lifecycle, parts belong to one whole, and deletion cascades. Start with association; strengthen only when your domain truly requires it, strictly.
2) What do the diamonds mean in EA UML diagrams?
In enterprise architect uml diagrams, a hollow diamond on the whole end denotes aggregation (shared). A filled diamond denotes composition (composite). No diamond is a plain association. Place the diamond at the whole/composite end. Remember: UML Composition implies exclusive ownership and deletion cascade; UML aggregation indicates grouping without enforced lifecycle control, typically only.
3) Does UML Composition always delete parts in EA?
UML defines composite aggregation so that a part belongs to one composite; if the composite is deleted, its parts are deleted. Practically, treat that as a modeling rule. EA won’t force runtime deletion but the semantics guide design, code, and generation. Document exceptions explicitly if your domain needs survivable parts.
4) How do multiplicity and navigability affect these relationships in EA?
Multiplicity conveys how many parts or peers participate (1, 0..1, 1..). Navigability shows which direction knowledge flows. They’re orthogonal to relationship kind: you can have navigable or non‑navigable uml associations, aggregations, or compositions. Model accurate multiplicities and role names; make only necessary ends navigable to avoid accidental coupling in code.
5) What EA features help review these UML relationships at scale?
Use Diagram Legends to color‑code uml associations, aggregations, and compositions for quick visual checks. The Relationship Matrix helps audit whole–part coverage across packages. Search by connector type to find misplaced links. Validation and custom stereotypes/constraints further enforce rules. Together, these features keep large sparx uml models consistent, accurate, and highly readable.
