No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
Associations between classes are easy enough to understand; Car has 4 wheels | Associations between classes are easy enough to understand; Car has 4 wheels. | ||
[[File:Car4wheels.png|frameless|210x210px]] | [[File:Car4wheels.png|frameless|210x210px]] | ||
But in the information system we build it may be obvious that a Car owns all its Wheels; the car and all its wheels can be looked at as a complete entity of | But in the information system we build, it may be obvious that a Car owns all its Wheels; the car and all its wheels can be looked at as a complete entity of their own – a '''composite'''. If the Car is scrapped, the wheels are also implicitly thrown away. A Composite in UML is created by decorating the association with a filled diamond: | ||
[[File:Diamond.png|frameless]] | [[File:Diamond.png|frameless]] | ||
| Line 9: | Line 9: | ||
For any well-behaving MDD tool, this decoration should imply a cascading delete of all associated wheels when the Car is deleted. | For any well-behaving MDD tool, this decoration should imply a cascading delete of all associated wheels when the Car is deleted. | ||
A composite also signals to the UML reader that the Car and Wheels are created at the same time | A composite also signals to the UML reader that the Car and Wheels are created at the same time and may not be meaningful on their own. So some will argue that the model should be changed from “0..1 Car” to “1 Car” (i.e wheel must always belong to exactly one car): | ||
[[File:Diamond 2.png|frameless|124x124px]] | [[File:Diamond 2.png|frameless|124x124px]] | ||
On the other hand this might not be the best idea for | On the other hand, this might not be the best idea for the domain we are modeling now. If the system we build is one that describes a garbage sorting facility, we may want to say: “Yes a car often has wheels, and the car and its wheels can be looked at as an entity of their own (a composite), but we sometimes want to take this composite apart and treat the parts separately”. If this is the case, the '''aggregate''' decoration can be used: | ||
[[File:Aggregate.png|frameless|143x143px]] | [[File:Aggregate.png|frameless|143x143px]] | ||
The aggregation symbol signals to the UML reader that the connection between Car and Wheel is “strong and common” and that “Car owns wheels” is more appropriate to the domain than “Wheel owns Car” (this also applies to the composite symbol) . | The aggregation symbol signals to the UML reader that the connection between Car and Wheel is “strong and common” and that “Car owns wheels” is more appropriate to the domain than “Wheel owns Car” (this also applies to the composite symbol). | ||
A well behaving MDD tool should probably prohibit the deletion of a Car until the Wheels are gone | A well-behaving MDD tool should probably prohibit the deletion of a Car until the Wheels are gone - so that the scrap yard guys do not delete a car while the valuable wheels are still on it. | ||
'''To sum it up:''' Composite is stronger than Aggregate; both symbols imply that the domain sometimes | '''To sum it up:''' Composite is stronger than Aggregate; both symbols imply that the domain sometimes looks at the classes as a bigger unit. The symbols help the UML reader understand the larger compositions in the domain. The symbols imply specific destruction behavior to well-behaving model-driven development frameworks (MDD-Frameworks). | ||
==== What | ==== What Does MDriven Do ==== | ||
Each Association end in MDriven has the “Delete Action” property: | Each Association end in MDriven has the “Delete Action” property: | ||
| Line 48: | Line 48: | ||
|} | |} | ||
The recommendation is to leave the DeleteAction on <Default> and use the Aggregation setting to control the delete action AND help UML readers | The recommendation is to leave the DeleteAction on <Default> and use the Aggregation setting to control the delete action AND help UML readers understand the domain. | ||
==== Deleting | ==== Deleting Wheels Without the Car ==== | ||
Assuming that your context is the Car | Assuming that your context is the Car: | ||
this.Wheels.delete | this.Wheels.delete | ||
would delete the wheels. Note! Not only unlinking them. | would delete the wheels. '''Note!''' Not only unlinking them. | ||
If you would like to unlink them, you do | If you would like to unlink them, you do: | ||
this.Wheels->clear | this.Wheels->clear | ||
Note that if you use aggregation of type Composite, you would create "floating" objects that have a validation error of not having the Car association set. | |||
[[Category:UML]] | [[Category:UML]] | ||
[[Category:Associations]] | [[Category:Associations]] | ||
Revision as of 06:19, 13 March 2023
Associations between classes are easy enough to understand; Car has 4 wheels.
But in the information system we build, it may be obvious that a Car owns all its Wheels; the car and all its wheels can be looked at as a complete entity of their own – a composite. If the Car is scrapped, the wheels are also implicitly thrown away. A Composite in UML is created by decorating the association with a filled diamond:
For any well-behaving MDD tool, this decoration should imply a cascading delete of all associated wheels when the Car is deleted.
A composite also signals to the UML reader that the Car and Wheels are created at the same time and may not be meaningful on their own. So some will argue that the model should be changed from “0..1 Car” to “1 Car” (i.e wheel must always belong to exactly one car):
On the other hand, this might not be the best idea for the domain we are modeling now. If the system we build is one that describes a garbage sorting facility, we may want to say: “Yes a car often has wheels, and the car and its wheels can be looked at as an entity of their own (a composite), but we sometimes want to take this composite apart and treat the parts separately”. If this is the case, the aggregate decoration can be used:
The aggregation symbol signals to the UML reader that the connection between Car and Wheel is “strong and common” and that “Car owns wheels” is more appropriate to the domain than “Wheel owns Car” (this also applies to the composite symbol).
A well-behaving MDD tool should probably prohibit the deletion of a Car until the Wheels are gone - so that the scrap yard guys do not delete a car while the valuable wheels are still on it.
To sum it up: Composite is stronger than Aggregate; both symbols imply that the domain sometimes looks at the classes as a bigger unit. The symbols help the UML reader understand the larger compositions in the domain. The symbols imply specific destruction behavior to well-behaving model-driven development frameworks (MDD-Frameworks).
What Does MDriven Do
Each Association end in MDriven has the “Delete Action” property:
The DeleteAction can be set to one of these values:
| DeleteAction on the Wheels association | Calling Car.AsIObject().Delete() |
| Allow | will work even if you have wheels left on the car, but the wheels will be left dangling |
| Prohibit | will not work as long as you have wheels on the car |
| Cascade | will delete any remaining wheels |
| <Default> | If the association end is Composite treat as Cascade, if the association end is Aggregate treat as Prohibit, if the association end has aggregation==none treat as Allow |
The recommendation is to leave the DeleteAction on <Default> and use the Aggregation setting to control the delete action AND help UML readers understand the domain.
Deleting Wheels Without the Car
Assuming that your context is the Car:
this.Wheels.delete
would delete the wheels. Note! Not only unlinking them.
If you would like to unlink them, you do:
this.Wheels->clear
Note that if you use aggregation of type Composite, you would create "floating" objects that have a validation error of not having the Car association set.