I mentioned also, aggregation and composition. Using aggregation in particular is very common in UML class diagrams. You often want to say that one class is related to many instances of another class. And you use the aggregation association to do this. It’s still an association, it’s just adorned with an open diamond to indicate that it’s a particular kind of association called an aggregation. I want to say a word, though, about the difference between aggregation and composition. It’s somewhat subtle, and it gets to the point that aggregation doesn’t really say much about the semantics of the relationship. In particular, it doesn’t say much about the lifetimes of the participant objects. For example, let’s say you had a house class and room classes. Clearly, a house has rooms so you’d expect there to be an aggregation there. But think further, if you destroy the house you’re also destroying the rooms. Therefore, instead of using aggregation, we would use composition. That is, we’d fill in that diamond. In compositions, there is a responsibility for managing the lifetime of the constituent objects. That further says that a particular constituent can only belong to one composition. Compositions also have the transitive property. That is, a house can have room and a room can have closets. For aggregations there’s no rules like this. Aggregations are general situations. We might say, for example, that a room has a table. Now this is an aggregation situation, because we could certainly destroy the room after taking the table out. They have separate lifetimes, and therefore we’d use aggregation instead of composition.