My ongoing exploration of UML
Aggregation and Composition
Pick up a ball. That's aggregation. Aggregation is what you can carry, what you can contain. Thoughts are an aggregation of our brain. Furniture is an aggregation of my house. However, a confusion comes up when one divides the whole into its constituent parts. Is a wall an aggregation of my house? No, because without the wall the house would fall down, and without the house the wall is meaningless. Is my head an aggregation of my body? No, because my head needs the rest of my body to survive.
Composition is when the parts are so integrally tied to the whole that they require the whole to exist. Clappers in bells. Hearts in bodies. The importance is not whether the whole needs the part, but whether the part needs the whole. Without a bell, a clapper is useless. Without a body, a heart will die.
To a certain degree, the division between aggregation and composition depends on the specific implementation the programmer chooses. Take light bulbs in lamps. Light bulbs are pretty useless without their lamps, unless you are programming light bulb installation software. Then light bulbs must be interchangeable, and not dependent on their specific lamp for existence. The same goes for heart transplant programs. In those cases the bulb, and the heart would be aggregations.
But consider the switch on a lamp. Even with the most obvious fact that light bulbs are supposed to be unscrewed, it is generally clear that switches never need to be separated from their lamp. Unless you are programming lamp assembly software. One must consider how interchangeable and independent you want the constituent parts when deciding between aggregation and composition. Aggregations can be taken apart. Compositions can always be treated atomically. There is no rule saying which is right; even the atom can be nonatomic when split in a nuclear reaction.
Aggregation and Association
This one is almost completely subjective, yet can be determined once a specific situation is defined. Objects contain aggregations. Associations are not contained by objects. What's the issue then?
Associations are really a shortcut to messages. Instead of developing and sending a message interface between objects, one object can contain a reference to another object. A child to its parent. My fingers to the keyboard. Even though these objects are treated much the same way as aggregations, they are clearly not lesser parts of the whole.
To a certain extent, the difference between aggregation and association is an illusion. When we get in our cars and drive around, our sense of "self" extends to the car since we control it. You could say the car is an aggregation of the driver, but most drivers upon getting a fender-bender have been known to exclaim, "He hit me!" not "His car hit my car!" (McCloud, 1993). "The kettle is boiling," not "The water in the kettle is boiling." In grammar they call it metonymy. In programming, association.
The issue comes up when objects must be moved, converted, saved and restored. In writing an object to disk it becomes desirable to consider the object as atomic, as one indivisible thing, so as to ensure no data on the object will be lost. With composition, atomicity is ensured. But with aggregation, it requires specific programming practices to be maintained.
A programmer must include in their "cloning" "disk saving," or "duplication" routines, some code that will ensure that every aggregation also gets duplicated. Since aggregations are part of the whole it makes sense that creating a copy of the whole would also create a copy of the aggregation.
Not so with association. Associations should be effectively ignored in duplication routines. I am in the house implies nothing as to where my duplicate would be. My fingers are on the keyboard, but duplicating my fingers would not also have to duplicate the computer. Lamp switches as aggregations of lamps are obvious: to duplicate the lamp you must duplicate the switch. Associations on the other hand are initialized to default values during duplication processes.
If the programmer finds themself constantly adding code to duplicate objects that should be associations, they may have the model backwards. This room I'm in can be an association of the furniture it contains. Duplicating the furniture does not require duplicating the room. Thinking about it the other way, furniture is an aggregation of this room I'm in. Duplicating the room implies duplicating the furniture. Otherwise it wouldn't be the same room. So the reverse of an aggregation, if it exists, is an association. IF it exists.
Whether an aggregation or its corresponding association exist depend on the implementation of the programmer. Suppose one programmer duplicated a car in his code, but did not duplicate the passengers. Their interest was spawning empty automobiles to be piloted by already made drivers. Ey would use car as an association of driver, but not driver as an aggregation of car.
Suppose another programmer wanted to duplicate certain cars in a racing game to race against the player. Their interest was spawning automobiles ready to race upon creation. If ey used car as an association of driver, but not driver as an aggregation of car, ey would be in error. The drivers in these cars have become the car's responsibility to duplicate and are thus an aggregation of the car.
Bibliography --------------
Martin, Robert C. "UML Tutorial: Part 1 Class Diagrams" McCloud, Scott "Understanding Comics" HarperCollins Inc. 1993
Comment
Index
Previous
(Powergaming: Is Not Roleplaying, Is Ego-Tripping)
Next
(Miss Concerned Citizen)