Modeling an Association
Look around the room you are in. You will see plugs and sockets. Some plugs are in service (plugged in to a socket) and some are not. Some sockets are being used (occupied by a plug) and some are not (except at the airport, where it seems _all_ of them are being used).
‘plug’ ‘is plugged in to’ zero-or-one ‘socket’. ‘socket’ ‘is occupied by’ zero-or-one ‘plug’.
This is a one-to-one bi-conditional association. For any instance of plug, we can find out if it is plugged in and to which instance of socket it is connected. If we have an instance of socket “in hand”, we can find the related plug if one is there. Association R1 gives us a lot information about the instance populations of ‘plug’ and ‘socket’.
Consider modeling current flow. In which class do we want to model the current flow?
Also called “ternary associations” and “link classes”, associative classes model relationships as data. Instead of just a line with role phrases, the full power of class, attributes and state modeling can be applied to clearly specify the relationship. Associative classes also can participate in other associations.
In our ‘plug’ and ‘socket’ model, we could have modeled ‘current_flow’ on either or both of ‘plug’ and ‘socket’, although it is more clear to model the flow of current through the connection since this flow is through both. ‘Resistance’ would not make sense on the ‘plug’ or the ‘socket’. The resistance to current flow is a function of a particular ‘plug’ being connected to a particular ‘socket’.
In complex systems, the relationships between resources in the system are often a focus on study. In such systems there are limited resources that must be allocated and shared. One object in a system will “want to be associated” with another object, but it is busy. Such patterns can leverage associative classes nicely.