Reputation: 27
I have a confusion in UML class diagram Multiplicity. To ask my question , first i need to give you an example of a situation; Consider this requirement: "Sections shall have many topics." I can make the classes for Section and Topic with their multiplicity as follows :
The above relation can be read as : "One or more sections has many topics".
But consider this design also :
Example 2)
The above relation can be read as "One section has many topics , and one topic is in only one section."
Question 1 is : What is the correct design?
Because for me i think the Example 2 design is the correct one, because i am considering only ONE instance at that particular time. But in Example 1 , they considered the Section class as a very high view! (Of course i can make infinity number of instances of any class...)
Question 2 is : In Example 2, do we say that there exists only one Section in the whole system, that's why we write it as in Example 1? Also in Example 1, This relation is Many to Many, so we need to make an association class to handle it.
I hope you understood my confusion, thanks in advance :D
Upvotes: 0
Views: 1638
Reputation: 3707
In example 1 there are two independent statements:
Every instance of a section can have any number of topics and
every instance of a topic must have at least one section. I don‘t know whether this is what you meant.
PS: The composition, shown by the filled diamond, implies exclusivity. Therefore, the multiplicity can at maximum be 1, not 1..*.
An Association Class is not needed. Many to many relationships are just normal Associations.
Upvotes: 1
Reputation: 36333
Q1: In fact it depends on the requirements. A Topic
can appear in many Section
s as being discussed under different aspects. If you require that a topic must be completely covered in one section then your 2nd approach would be right. Anyhow, I think that the first is the more common way of doing things.
Q2: No. You only say that a Topic
can have only one Section
. To tell that there's only one section allowed you'd probably need a constraint. (I used a <<singleton>>
stereotype for such purposes which is no UML standard, though.)
BTW: you multiplicity in ex. 2 is wrong. To the left you must only have 1..*
and to the right only one 1
.
Upvotes: 2