Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Multiplicity
Multiplicities answer the following question: "How many objects of each class take part in the relationships?" The most common multiplicities are shown in Figure 5.
)
Figure 5 Common multiplicities and their meanings.
We have seen what the 0..1 multiplicity might look like in Java, and you may have already guessed that the 1 multiplicity means our code should not allow the reference in Class A to be null (maybe the reference is set in a constructor, and any relevant set methods reject attempts to modify the value to null).
The 1..* and 0..* multiplicities are a little more complicated. One way of implementing them in Java is to use some sort of collection class, such as a Vector, to hold the multiple references that might be needed.
ClassA
{
...
Vector classB; // a vector holding references to objects of class B
...
}
The 1..* multiplicity requires us to write code to ensure the Vector always has at least one item in it.
In some relationships, a more precise range or a precise number is appropriate. For instance, a child has a maximum of two living biological parents, and this could be represented as a multiplicity of 0..2. Again, extra source code is required to constrain the number of parent objects in the relationship to two or fewer.
A single UML association with multiplicity, role, and direction can convey a good deal of information that might take a dozen or more source code statements. It does not tell us exactly how the relationship is implemented, but it does give us a good overall idea of what the relationship is and what it is for. For this reason, a business analyst or customer is far more likely to be able to understand and verify the UML relationship than if they are shown the equivalent Java source code.