Associative Reality

Aggregation (white diamonds), composition (black diamonds), simple associations, directed associations, and ownership(containers) are steak and potatoes of object oriented structures and our favorite modeling language, UML. I recently worked with a client that used composition for parts of a configuration rather than aggregation which seems logical given the reuse of parts between configurations. This was SysML, but the standard used the common UML concepts and meaning. The customer used composition for configuration relationships because the concept itself was light weight, i.e. the car configuration was a configuration of car, not a true car.

You might say an illusion owns elephant, thus when the illusion dissipates, so does the elephant.  Or for you dessert rats, the water in the mirage is gone when the mirage is gone. In a car, the parts are created and destroyed like arms and legs, but when we stop creating a model of car, it ceases to own the responsibility for those parts. Another model of car may be composed of the same radio, but they are not shared nor does deleting one car model destroy the other's parts.

It may be that we are always struggling to pin our hopes and dreams on our ability to control our destiny through these concepts when they are the wrong hopes. Take for instance, directionality of relationship. This is pure software isolation, not system engineering. What if I know your name, but you do not know mine... yet? Is that bidirectional? Does an engine know the transmission it is connected to and vis versa? Yet both have effects on each other via linkage.

Aggregate/composite/owns are software terms and perhaps not as applicable to the real world. It would be interesting if we dug into the haggis of software concepts to find why and where these terms originated. They certainly loose their shine when applied to systems engineering.