I was creating a class diagram and I realised I wasn't certain about multiplicity.
If a class holds two objects of another type of class does that make the multiplicity 2 to 1 or just 1 to 1?
Example:
Hope the question makes sense.
Thanks in advance.
With multiplicities, you simply set all possible alternatives. For example, if your Customer can have either one or two Addresses, then it's 1..2. If a Customer can have either no address or 1 or 2 addresses, then it's 0..2 and so on
We can suppose that class Customer has 2 fields to navigate to two instances of class Address. These navigations have different semantics and maybe different purposes. So we should to use two assotiations with multiplicities of "0..1 - 1" or "1 - 1".
Related
I have three classes:
-User class
-Role class
-UserRole class : to join both classes
Each user can have multiple roles.
So, I made this class diagram:
Is the composition relationship between classes and the cardinalities correct?
No. When the relationship goes away, you don't want the other things to get deleted. The pointy ends must also be 1's.
You can safely omit the composition diamonds as they add no real semantic to the model. Compositions are used on a metaphoric level and are more food for philosophers than anyone else.
Now for the multiplicities. A UserRole binds exactly one user to one role. You can have multiple UserRoles to reflect different roles for single or multiple users. So you should place a 1 to the left and right multiplicities.
I have the following classes:
Article
Address
The relationships of those two classes are:
Article 1->2 Address (1 and 2 are the multiplicities, so an article has two addresses (a pickup & delivery address).
How can I show in the class diagram that those two associations to the address are implemented by an object called pickupAddress and handoverAddress and that handoverAddress is optional? Is that even possible?
You must draw two associations between Article and Address. Role of address for the first association is pickup and for the second one is delivery.
If handover address is optional, multiplicity of association should have lower bound set to zero and upper bound 1. Pickup Address is multiplicity 1 according to your question (i.e. mandatory & exactly one).
Implicitly, association is implemented by classes at the association ends or by association instance (link). There is possible to define, what element owns association end, Association or Class at the association end.
Read UML Superstructure document to get more info. See property at association end chapter.
The solution is something like this:
Depending if the addresses are shared by articles or not, you should change the aggregation type. You could make a copy and edit this model there
Let's say I have class Foo that has an association to some thing(s) that fulfill(s) a role. This role could be fulfilled by either (strictly) one Bar xor any number of Baz. Similarly, the role might be fulfilled by either any number or Bar xor any number of Baz (but a mixed collection is intolerable). Are there reasonable ways to represent these in a class diagram using only associations, classes, and interfaces? I would (really) like to avoid using OCL or constraint elements.
(The reason I would like to avoid these is because we are generating code from our UML. We have already implemented generation that handles associations, classes, and interfaces. Dealing with OCL would be quite the task. Constraint elements wouldn't be so bad but still quite a lot of work.)
I would start with the picture below and create several different versions before deciding which one generates best code (junior-40).
The yellow blocks represent necessary "glue code" needed to straighten your example against your other requirements
Consider creating an abstract class Thing and derive Bar and Baz from it. It abstract the whole role, can contain some own atts and methods if needed and is quite flexible and extendible.
Now Account has an association only with AccountOwner (role "role", as Jim L. has explained in his comment, a role name must be unique in this context).
Note that this does not eliminate the need of some additional restrictions. For example, all linked "roles" should be of the same type. Sometimes is not easy (or even possible) to remove all restrictions. Otherwise we would make complete systems out of class diagram. I agree though, that as much information as possible should be contained in classes, their taxonomies and features (atts, assocs and methods).
EXAMPLE:
EXAMPLE 2 (after comments):
This version overcomes the need to use OCL ant yet keeps the simplicity and flexibility:
Multiplicities are now also derived and refined for each concrete "role". No OCL needed. :)
You add a constraint on the class in OCL:
(self.role->exists(r|r.oclIsType(Bar)) and self.role->notexists(r|r.oclIsType(Baz)) ) or
(self.role->exists(r|r.oclIsType(Baz)) and self.role->notexists(r|r.oclIsType(Bar)))
You can try this out with MDriven Designer.
The reason for introducing OCL (object constraint language) in the UML specification was just this; ability to add constraint not possible or practical to convey with simple cardinality and type information
Could this image help you ? It is extracted from the norm.
Are you thinking of something like the following:
(source: uml-diagrams.org)
Where Account is your Foo, Person is your Bar, and Corporation is your Baz.
You can then specify multiplicity on each of the two associations: [1] for Bar (Person) and [1..*] for Baz (Corporation).
I have one object, call it type A which has four data members of another object type, call it B. How do I show this in a UML class diagram so that its clear there are four B objects type in every A object?
Is the only solution to put "4" next to the arrow head pointing to class B?
It depends on what you want to achive, in sense of how you need to distinguish between those objects in context of their association/link, that is - what kind of role they play:
if there are all equal, no special differences in their role in context of A, them a multiplicity 4..4 will do the job, naming the association end properly (for example my_Bs)
If these object play different role in connection with A, then you can use separate associations with lower multiplicities each one, 2, 3 or even 4 pieces (for example, if B is a Wheel and A is Car, then you can put 2 associations with multiplicities 2..2 each, and call then "front" and "rear", or even 4 associations "front_left", "front_right"...)
Here is how the both cases look like. On the second one I showd different possible options (with max. 5 elements of B), just to give you an idea.
It's probably clear by now, but the fundamental concept here is the role of the association end.
Aleks answer is the best. However you can also represent the multiplicity in one box like this :
You cal also use composite structure diagram. See example below:
From my point of view, myBs defined as an attribute of type B on class A has a different meaning of myBs defined as a association's role between A and B (which is also different as defining it as a composition/aggregation).
If it is an attribute, then it's not a role. In that case, there is only a simple dependency relation between A and B, which must appear in the diagram.
I think that problem comes from unconsciously think from a "Relationnal Data (BMS)" and/or a "Object Oriented Programming" point of view, but UML is not intended for that.
:)
If I am modelling in a UML Object Diagram (also known as an "instance diagram") of a Year class which has a field which is a list of Months, should I explicitly create an box for the List instance as well? To me, it seems, like if I draw lines connecting the instance of Year to the 12 Month instances directly, then I expect to see 12 fields on Year like month1, month2, etc.
If you do connect them directly, then how do you in the diagram make it clear that the relationship is not direct but through a list? Or is this diagram more conceptual and the precise nature of these relationships ambiguous?
tl;dr: In a UML Object Diagram, do collections like lists get their own boxes through which your models connect? If not, how to represent this?
In fact, you should first determine your class diagram. An object diagram will then derive naturally.
I would represent the class diagram this way:
And with this class diagram, what you say yourself for an object diagram is correct (drawing lines connecting the instance of Year to the 12 Month instances) because each connecting line is itself an instance of the arrow in the class diagram. (in UML terminology, a Link is an instance of an Association)
Of course, if you class diagram instead just exposes an attribute months : List, the answer will be different. But it does not seem suitable.
Note1: you see in my class diagram that there is no hint that it is actually a List. It's because to my mind it is merely an implementation detail. It could as well be an array, for example, but the important point is the multiplicity 12, which means that it is a multiple value.
Note2: do not worry about ehat you say about 12 fields in the ckass Year, it is not the case. In an object diagram, field values are represented directly in the class instance, like attributes in the class diagram
Edit:
If you want to make the distinction absolutely clear, you may name the arrow tip months for every month instance, thus stating that all correspond to a unique same months field. They would be named month1, month2, ... in the other case. The same way, you would name the arrow tip in the class diagram as well.