Suppose I have A ---r1 {bag} [1..2]--> B in a UML class diagram (that is, r1 is an association from A to B and is annotated with {bag} and multiplicity [1..2].
My Question: if a:A is an instance of A, is the following collection valid?
a.r1={(b1,1),(b1,2),(b2,1)} //collection contains two copies of b1 and one b2
In other words, multiplicity bounds (i.e., [1..2]) apply to the association when it is interpreted purely as r1:A --> B, or it applies to r1: A --> Bag(B)? In the former interpretation, the above collection is valid, since r1 contains at most two instances of B, but in the latter it is not, since r1 contains three elements of Bag(B)! which interpretation is correct?
Multiplicity constraints in UML are explained in Chapter 7.5.3 of UML document as I am referred to in this question.
p.s.1: A similar question arises when we substitute {bag} with {seq}.
p.s.2: I added haskell tag to get comment from large haskell community here as #xmojmr suggested. Thanks to #peter that nicely draw the pictures in his answer.
As stated in specs, Bag is unordered, nonunique collection.
However this describes the relation between the elements you are pointing to.
So your example can be expressed in either way:
This means that A has reference to one to two B instances, and those references are stored in a Bag (or any nonunique, unsorted collection; but that is implementation detail).
To answer your question: no, because the Bag contains three instances of B, whilst the allowed maximum is two B's.
Related
Is it possible to connect a1 with b1 twice on (object diagram), while A has only one B object and it is {nonunique}?
nonunique constraint has sense only if upper multiplicity is higher than zero (while of course you are still allowed to use it anyway). It means that in a particular association with a specific object the same object on the other side can be used more than once.
I believe that's what you wanted to achieve, however the constraint should be on the other end of the association (the one with multiplicity *).
Your diagram shows just classes. Objects have an underlined name and usually do not show compartments.
The {nonunique} constraint in the multiplicity just tells that B must not be unique.
The double association between a1 and b1 is absolutely legal. However, without a role name it's rather pointless and a single association would be enough.
I have this class/object diagram:
I don’t understand why that object diagram is invalid according to the given class diagram.
In the object diagram, one C object has two links with two T objects, alpha relationship with a T object and beta relationship with another T. So I don’t think it violates the multiplicity constraints.
Could you please explain me why the object diagram is invalid?
Yours is the most interesting question I've seen here in a long time. It is pretty tricky!
The simple reason your instances are incorrect is that every instance of type T must be associated with one C. The top instance of type T in your diagram violates the constraint in association beta. (The multiplicity on the left end of the association.)
There are two faults in the object diagram.
There is only a formal fault in the object diagram, the lines in the objects diagrams between the instances are links, i.e., instances of the associations shown in the class diagram. As the links are instances, the same rules for instance naming apply as to class instances. So change alpha to :alpha and underline it, it is correct. Same for beta.
Further the links are not correct, as there is an beta link from the uppermost T instance missing. Each object of A, and as C is a specialization of A, also C (and B) objects need an alpha link to an S instance. As S is a generalized T, an alpha link between A (or one of its specializations) and S (or one of its specializations) is needed. Further each S (or T) might have arbitrary alpha links to A objects.
Each C object needs to have zero or one beta links to T instances. In the other direction, each T instance needs exactly one C instance via a beta link. This is missing for the uppermost T instance.
Leaving my prior answer below, but thinking twice, the answer is that your class diagram is incomplete.
The two alpha and beta associations have no association-end names. The fact that they have different multiplicities leads to the conclusion that they must be different associations. With names it would look like this:
Expanding the inheritance will make this:
Based on this assumption, my original answer stands like this:
The reason is that a :C has two associations alpha and beta each to another :T object. Not a single alpha to one and a single beta to another. So you need to add a beta to the alpha and vice versa.
Edit And yes, JimL. is correct. Having two alpha-links violates the constraint from the class diagram. So actually you can only have one T linked to C. Which again makes the class model very strange.
The C class has a beta-association to T. C inherits from A and T inherits from S. Since there is a alpha-association from A t0 S this is also inherited. So you have:
A few days ago a friend pointed out to me that I had a wrong idea of composition in UML. She was completely right, so I decided to find out what more I could have been wrong about. Right now, there is one more thing that I have doubts about: I have a circular dependency in my codebase that I would like to present in UML form. But how.
In my case the following is true:
Both A and B have a list of C
C has a reference to both A and B to get information from.
C cannot exist if either A or B stops to exist
Both A and B remain to exist after C is deleted from A and/or B
To model this, I've come up with the following UML (I've ommited multiplicities for now, to not crowd the diagram.)
My question is, is this the right way to model such relations?
Problems
Some facts to keep in mind:
Default multiplicity makes your model invalid. A class may only be composed in one other class. When you don't specify multiplicity, you get [1..1]. That default is sad, but true.
The UML spec doesn't define what open-diamond aggregation means.
Your model has many duplicate properties. There is no need for any of the properties in the attribute compartments, as there are already unnamed properties at the ends of every association.
Corrections
Here is a reworking of your model to make it more correct:
Notice the following:
The exclusive-or constraint between the associations means only one of them can exist at a time.
Unfortunately, the multiplicities allow an instance of C to exist without being composed by A or B. (See the reworked model below.)
The property names at the ends of all associations explicitly name what were unnamed in your model. (I also attempted to indicate purpose in the property names.)
The navigability arrows prevent multiple unwanted properties without resorting to duplicative attributes.
Suggested Design
If I correctly understand what your model means, here is how I would probably reverse the implementation into design:
Notice the following:
Class D is abstract (the class name is in italics), meaning it can have no direct instances.
The generalization set says:
An instance cannot be multiply classified by A and B. (I.e., A and B are {disjoint}.)
An instance of D must be an instance of one of the subclasses. (I.e., A and B are {complete}, which is known as a covering axiom.)
The subclasses inherit the ownedC property from class D.
The composing class can now have a multiplicity of [1..1], which no longer allows an instance of C to exist without being composed by an A or a B.
Leave away the open diamonds and make them normal associations. These are no shared aggregations but simple associations. The composite aggregations are ok.
In general there is not much added value in showing aggregations at all. The semantic added value is very low. In the past this was a good hint to help the garbage collection dealing with unneeded objects. But nowadays almost all target languages have built-in efficient garbage collectors. Only in cases where you want an explicit deletion of the aggregated objects you should use the composite aggregation.
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.
:)
An association defines a semantic relationship between classifiers. The instances of an association are a set of tuples relating instances of the classifiers. Eachtuple value may appear at most once. The Association represents a set of connections among instances of the Classifiers. An instance of an Association is a Link, which is atuple of Instances drawn from the corresponding Classifiers
I wonder if there is someone helps me understand every word of the association definition especially the highlighted ones?because I read about it from different resources but all of them say the same words but I would like a more elaborated definition
semantic relationship
This means there's a structural relationship between the things being associated that arises from the problem space. For example: the association Person owns Dog. In a dog licensing application, this relationship is the central concept; the application exists to manage the links between people and dogs. It's a 'semantic' relationship because it has meaning which originates from the problem space.
set of tuples relating instances of the classifiers
A tuple is 'an ordered set of elements' (wikipedia). An example of the Dog-Ownership association could be ("Fido", "Fred") where "Fido" represents a Dog and "Fred" a Person. An association can be represented as a set of tuples in that there is one tuple for each combination of Dog & Person for which the relation holds; e.g.
[("Fido", "Fred"), ("Angel", "Chuck Norris"), ("Boatswain", "Lord Byron")]
Note there are no tuples for pairs where the relationship doesn't hold; e.g. ("Fido", "Lord Byron").
each tuple value may appear at most once
It's not possible for the set to contain duplicates as this would just be saying the same thing twice. So there's no point adding ("Fido", "Fred") again to the list above; we already know Fred owns Fido.
The Association represents a set of connections among instances of the Classifiers
This is just another way to think about the relationship. For each tuple in the set, you can think of a link - or connection - between the related objects.
An instance of an Association is a Link, which is a tuple of Instances
See above. Each tuple represents one linked pair of objects. Links are to Associations as Objects are to Classes. Classes have many objects; Associations have many Links.
Fundamentally associations exist to show where things are systematically linked to other things. Tuples and sets are a way to think about and/or represent those linked things. (In fact I'd quibble somewhat with the definition in your OP: the links in an association can be represented as as a set of tuples: but that's not what they are, it's how they're modelled. The same information could equally be modelled by a Graph, where each object was represented by a vertex (node) and each association an edge.
hth.
EDIT:
Responding to your questions. Looks like you understand it pretty well; some observations.
First, here's how I would model it:
Now to each of your points:
Name: is the name of Association relationship(optional,you can give it a name or not)
I prefer verb phrase based naming as it brings out the meaning of the relationship. My model can be read directly as:
Each Person owns many Dogs (where 'many' means 0 or more)
Each Dog is owned by exactly one Person
Doing so removes the need to name the association explicitly, although you can still do so if you want.
visibility(I am not care about it,at least for now, I didn't realize its importance until now).
I would agree. Personally, I never annotate models with visibility.
Name:(here is the name of MemberEnd ),so,I left its default name in the screenshot
See comment about association naming above. I prefer verb-based naming to role-based: 'owns' is much more explicit in describing the purpose of a relationship than naming the association end 'dog' or 'dogs'.
the owner of memberEnd [...]
Personally: I don't use this. There's a whole other discussion about this that tbh I don't believe has a material impact in most cases.
Navigable [...]
Again I don't use this personally. In reality navigability should be derived from the underlying behaviour. Does it require navigating one way/both? Then set navigability accordingly. However some people like to specify it explicitly, on basis it makes the implementation clearer (If only navigable one way it can be implemented with reference(s) in one class only; if bi-directional it needs references in both directions - with attendant logic to keep things consistent).
Multiplicity
I agree with your selection.
Hope that helps.