Can the multiplicity of an association vary over time?

Question

I have a requirement on UML: the multiplicity of an association can be vary according to time. I have some opinions on it, for example, use a list to store multiplicity history, create a new association once multiplicity will change. But it seems that they are all not good choices. So can anyone give me some suggestions? Thanks a lot.

Answer 1

Well, it's rather simple: just assign a multiplicity to the association. If lower and upper bounds are not specified it would be 0..*. If you have a minimum of e.g. 1 it would be 1..*. The same goes for the upper limit (replace the * with what it should be).

How you implement that is completely to the coder. You just specify the constraints here in UML. E.g. if you have a multiplicity of 0..* the coder will likely choose a variable length array/collection. If it's 1..2 it might end up with name1, name2 as single variables.

Answer 2

There are two cases to consider: a change in multiplicity may happen as part of the (not foreseeable and non-desginable) evolution of a software system or if it may be known (like 2..5 on Fridays, and 1..3 the remaining time) and be part of the requirements of a system to be designed and built.

If a change in multiplicity is part of the (not foreseeable) evolution of a software system, then you cannot make a desgin for it and, consequently, you can only accommodate it in your system's model, when it occurs. The evolution of a software system is essentially due to the evolution of its requirements. But when you model the systen, you only have the current requirements as a basis for making an information model with classes, associations and multiplicities. The evolution of the requirements implies a corresponding evolution of the information model, including the association multiplicities. So, over time, you'll get a historical sequence of models describing/defining your system.

If temporal changes in multiplicity are known at design time, then the only way you can catch that in a model ist to use the least generous multiplicity constraint that allows for the variation (e.g., 1..5) and describe the variation (in plain English) in a constraint box attached to the association end concerned.

Answer 3

The multiplicity is a constraint expressed in a model. UML only knows fixed multiplicities, because these will be implemented when the system is build.

If you know already now that the multiplicity may change, and you want your system to cope with it, it means that:

• your model must foresee the widest multiplicity possible (the minimum of all the possible minima, and the maximum all the possible maxima, in worst case 0..*)
• your implementation must allow to define at runtime the the constraints to be enforced at a given moment. You could for example use a class MultiplicityConstraint with a minimum and a maximum and a date interval that will be used to validate the objects that are created, modified or deleted.

You must also think about dealing with inconsistencies when the multiplicities change. This will probably be the most challenging in your implementation. For example, if the dynamic multiplicity is 3..10, and the constraint is changed to 5..7, what would you do with instances that have only 3 or already 8 linked instances?