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.
-
It's not clear from your question, if the change in multiplicity is part of the (not foreseeable and non-desginable) evolution of your app/system or if it's known (like 0..5 on Fridays, and 0..3 the remaining time) and part of the requirements? – Gerd Wagner Aug 16 '19 at 10:46
-
Thanks for your reply. In current stage, I think it is the first case. But no matter it is first case or later case, I just want to know whether there is a UML solution on this question. If there is not, then tell me what's your solution; if there is, still tell me what's your solution. Thanks a lot. – newman Aug 16 '19 at 11:08
-
Hi, Wagner, thanks for your edit, thanks a lot. – newman Aug 16 '19 at 12:06
2 Answers
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.

- 5,481
- 1
- 22
- 41
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.

- 35,448
- 8
- 62
- 86