You can use composite and aggregate associations in class diagrams to show ownership in your domain and control what must happen to related objects when an object is deleted.

Choose the relationship that matches ownership

An association connects two classes. For example, a Car can have four Wheel objects. Use the aggregation setting on an association end when the relationship expresses more than navigation: it states how the objects form a larger unit and what their lifecycle means.

Relationship	UML notation	Meaning in the domain	Expected deletion behavior
Composite	Filled diamond at the owner end	The owner and its parts form a whole. The parts are normally created with the owner and are not meaningful on their own.	Deleting the owner cascades deletion to its parts.
Aggregate	Hollow diamond at the owner end	The owner has a strong, common ownership relationship to the parts, but the parts may be treated separately.	The owner should not be deleted while its parts remain.

Both notations tell the reader that one class owns the other in the domain. In the Car–Wheel example, the diamond is at the Car end: it communicates that a car owns its wheels, not the reverse.

Model a composite when the part ends with its owner

Use a composite association when deleting the owner must also delete every part.

For example, model Car as composite owner of Wheel when a scrapped car and its wheels are discarded together. A Model-Driven Development framework should then cascade deletion from the car to its wheels.

A composite also communicates that the part is expected to belong to an owner. You may therefore consider a multiplicity of 1 Car at the wheel's association end rather than 0..1 Car. Do this only when a wheel without a car is invalid in the domain.

Composite gotcha: do not leave a required part floating

If the association is composite, removing a wheel from its car without deleting the wheel can leave a floating object: a wheel that has no required Car association. MDriven reports this as a validation error.

For example, if a wheel must always belong to a car, do not clear the car relationship as a way to dispose of the wheel. Delete the wheel instead.

Model an aggregate when parts can be separated

Use an aggregate association when ownership is strong but the parts can outlive, or be handled independently from, the whole.

For example, a garbage-sorting system may represent a car and its wheels as an aggregate. The car commonly owns the wheels, but workers can take the aggregate apart and handle valuable wheels separately. In this case, deleting the car while wheels are still attached should be prevented; remove or otherwise handle the wheels first.

Configure deletion in MDriven Designer

Each association end in MDriven Designer has a Delete Action property. MDriven recommends that you leave Delete Action set to <Default> and use the association's aggregation setting to express both the domain meaning and the deletion behavior.

1. In the class diagram, select the relevant association end.
2. Decide which class is the owner. In the Car–Wheel example, select the Car end.
3. Set the aggregation to Composite if parts must be deleted with the owner, or Aggregate if the owner cannot be deleted while parts remain.
4. Leave Delete Action as <Default> unless you have a specific reason to override the aggregation-driven behavior.
5. Check the multiplicities. Set the part-to-owner multiplicity to 1 only when a part is never valid without its owner.

One-to-one associations need one embedded end

A one-to-one association has no inherent answer to where the database key belongs. MDriven must choose one embedded end so that the database does not contain foreign keys in both tables. Two keys can allow inconsistent crosswise references—for example, one object points to one partner while that partner points to another.

Set one end to not be embedded when the relationship is not ownership. When the relationship is ownership, making the appropriate end composite gives MDriven the information it needs to choose the embedded key. Confirm that only one end is embedded.

For example, if a Technician owns a related system-user record and deleting the technician should delete that record, model that ownership as a composite at the Technician end. If neither object owns the other, explicitly choose one end that is not embedded.

Delete parts versus unlink parts in OCL

OCL lets you either delete related objects or remove their links. These operations are different.

Assume the current context is a Car and its wheel association is named Wheels.

Intent	OCL	Result
Delete all wheels	this.Wheels.delete	Deletes the wheel objects; it does not only remove their association to the car.
Unlink all wheels	this.Wheels->clear	Removes the links between the car and wheels, while retaining the wheel objects.

Use delete when the wheels must cease to exist. Use ->clear only when the wheels remain valid after removal. With a composite association that requires every wheel to have a car, ->clear creates invalid floating wheels.

Fetch a composite graph before a large delete

Deleting an object with many composite associations can require loading many related objects. If the objects are loaded lazily during the delete action, this can cause repeated fetches.

Use CascadeFetch in an OCL column before deleting a large composite graph. CascadeFetch follows composite associations, ensures that the aggregate is loaded, and returns the number of objects included. MDriven's query planner can then fetch the graph in as few roundtrips as possible.

For example, add a column that evaluates CascadeFetch for a selected top-level object before an action deletes that object. This is relevant when a root object owns many nested composite parts.

Design checklist

• Use a composite when the part is deleted with its owner.
• Use an aggregate when ownership is strong but parts must be removed or handled before the owner can be deleted.
• Put the diamond at the owner end of the association.
• Use a required multiplicity only if a part without an owner is invalid.
• Keep Delete Action at <Default> when the aggregation setting should determine lifecycle behavior.
• Distinguish deleting objects from unlinking objects in OCL.
• For a large composite graph, use CascadeFetch before deletion.
• For many-to-many relationships that need data of their own, use a link object association class rather than treating either side as an owned part.

See also

• Documentation:Class diagrams
• Documentation:OCLOperators CascadeFetch
• Documentation:Part 8 Link Objects association classes
• Documentation:State Diagrams
• Training:Polymorphism