Reputation: 448
I am trying to understand this certain case:
--------- ---------
| |0..* 0..*| |
|CLASS A |------------->| CLASS B |
| | | |
--------- ---------
--------- ---------
| |1..* 0..*| |
|CLASS A |------------->| CLASS B |
| | | |
--------- ---------
What I understand from the first example is: One Object from Class A has a relationship to zero or more Objects from Class B. That makes sense, because Class A knows Class B. But what exactly does the other multiplicity mean? Class B doesn't know Class A, so it doesn't seem to make sense to put a multiplicity there.
Same goes for the second example.
If someone has a good explanation, I would be very thankfull.
Greetings, john
Upvotes: 4
Views: 2453
Reputation: 13711
In fact it makes sense as it expresses a constraint on your (data)model.
By setting the multiplicity to [1..*]
on the A
side, you state that there should always be at least 1 or more instances of A
that have a relationship to B.
When writing (or generating) business code this constraint is usually not enforced, but that is only one application for a UML model.
It also serves as functional documentation, where I'm definitely interested in the multiplicities on both sides.
This type of information is also crucial when designing a database. It will determine if the FK
field will be nullable or not.
Upvotes: 2
Reputation: 96
It means that an instance of B can be targeted by many instances of A through your association.
But usually I do not set multiplicities for non-navigable roles on uml associations, since it is not used for code generation (there is usually no implementation for this multiplicity information...).
Upvotes: 0
Reputation: 36305
The fact that B
does not know about A
will not hinder multiple A
s to connect to B
. For example taking B
to be an address. And A
companies know a number of addresses. But then these companies hand addresses to other companies - and B
does not know about that.
Upvotes: 0