You can model ownership between classes and control what happens when related objects are deleted by choosing the appropriate UML aggregation and MDriven Delete Action setting.

Choose the relationship that matches the domain

An association connects two classes. For example, a Car can have four Wheel objects.

Aggregation decorations state whether one object is a meaningful whole made from other objects:

Relationship	UML notation	Meaning in the domain	Expected deletion intent
Plain association	No diamond	The objects are related, but neither is described as the other's whole.	Do not infer ownership or cascading deletion from the association.
Aggregate	Hollow diamond at the whole/owner end	The association is strong and common. It is more natural to say that a Car owns Wheels than that a Wheel owns a Car.	The parts can be treated separately. Removing the whole should not discard valuable parts without handling them.
Composite	Filled diamond at the whole/owner end	The whole owns its parts. The whole and its parts form one entity for the purpose of the model.	Deleting the whole deletes its associated parts.

The diamond is placed at the whole end of the association. In a Car–Wheel relationship, place it at Car when the Car is the whole that owns its Wheels.

Model a composite when the parts have the whole's lifetime

Use a composite relationship when a part is created and destroyed with its owner and is not meaningful independently in the modeled domain.

For example, if a Car is scrapped and its Wheels must also be discarded, model the Car–Wheel association as composite. In MDriven, a composite association implies cascading deletion of the associated Wheels when the Car is deleted.

A composite also communicates the intended cardinality. If every Wheel must belong to one Car, use a multiplicity of 1 at the Car end. If a Wheel can temporarily exist without a Car in your domain, keep the end optional, such as 0..1. Do not make it mandatory only because the association is composite; make the choice from the domain rules.

Use aggregate when the whole and parts can be separated

Use an aggregate relationship when the objects commonly form a larger unit, but the parts may need to remain available on their own.

For example, a garbage-sorting facility can receive a Car with Wheels attached, while later handling the Wheels as separate items. The Car is still the natural owner in the description of the assembled vehicle, but deleting the Car while Wheels remain attached would lose information or inventory that still matters.

Aggregation signals that the connection is strong and that the owner direction is meaningful. It is weaker than composition because the parts can be separated from the whole.

Configure deletion in MDriven

Each association end in MDriven Designer has a Delete Action property. The recommended approach is to leave Delete Action set to <Default> and use the association's aggregation setting to express both:

• the ownership rule that readers of the UML model need to understand; and
• the intended deletion behavior.

Follow these steps:

1. Select the relevant association end in MDriven Designer.
2. Decide which class is the whole or owner. For example, select the end at Car when Car owns Wheel.
3. Set the aggregation to Composite if the owner and parts share a lifetime, or Aggregate if the parts can be handled separately.
4. Leave Delete Action as <Default> unless you have a specific reason to override the behavior implied by the aggregation.
5. Check the multiplicity at the owner end. Use 1 only when a part must always have an owner; otherwise use an optional multiplicity that reflects permitted detached states.

In a one-to-one association, setting the appropriate end to Composite can also provide MDriven with ownership information that helps it decide which side contains the embedded key. This avoids the ambiguous situation where both objects could otherwise reference each other.

Delete objects and unlink objects are different operations

When the current context is a Car, use an OCL delete operation to delete the Wheel objects:

this.Wheels.delete

This deletes the Wheels; it does not merely remove their connection to the Car.

To remove the links while retaining the Wheel objects, clear the association instead:

this.Wheels->clear

Be careful when clearing a composite association. If the Wheel-to-Car end requires a Car, clearing the association creates detached, or "floating," Wheel objects. Those objects have a validation error because their required Car association is no longer set. Use clear only when detached parts are valid in the model or when your action assigns each part to another valid owner.

Plan deletion of large composite graphs

Deleting an object with many composite associations can require MDriven to load its complete composite graph. In a ViewModel, consider using CascadeFetch before the delete action. CascadeFetch follows composite-marked associations and loads the included objects through the query planner, which can avoid repeated lazy-loading round trips during deletion.

For example, if deleting a root object also deletes many composite children, evaluate CascadeFetch in an OCL column before running the delete action. CascadeFetch returns the number of objects included in the aggregate.

Checklist

Before marking an association as Aggregate or Composite, ask:

• Which class is the whole, and which class is the part?
• Should deletion of the whole delete the parts? If yes, use Composite.
• Can a part exist or be processed independently after separation? If yes, consider Aggregate and an optional owner multiplicity where appropriate.
• Are you deleting objects, or only removing links? Use delete for deletion and ->clear for unlinking.
• Will a delete action traverse a large composite graph? If yes, consider CascadeFetch in the ViewModel.

See also

• Documentation:OCLOperators CascadeFetch
• Documentation:Derived attributes & associations
• Training:Polymorphism
• Documentation:Custom OR Mapping