When class is associated with another, like Flight in the linked image, which has zero or one Plane associated with it, should this not be reflected in the class' attributes?
That is, shouldn't class Flight in this example have an assignedPlane field alongside its flightNumber, departureTime and so on... otherwise how can Flight be said to 'be aware' of its associated Plane?
No.
Showing an association in diagram is equivalent to having an attribute of a specific class. If there is an association(with a role) then this role is an attribute of respective Class.
For reference please see the Figure 9.12 (with description) in section 9.5.5 of UML 2.5 specification.
If you would have an attribute 'assignedPlane : Plane' in class Flight, then the role 'assignedPlane' on the association would be redundant. But merely having the role 'assignedPlane' on the association does not imply that class Flight is aware of it. If Flight would be implemented as a Java class or a class in any other OO programming language, it is not clear from your class diagram whether or not class Flight has any reference to (or knowledge of) the assignedPlane.
If you want to communicate to your audience that class Flight owns a reference called 'assignedPlane' to zero or one instance of Plane, then you could add a thick dot (or a small filled circle) at the end of the association. Here is an example from the UML 2.5 specification:
In this example, 'size' is an attribute of Window, although it is displayed as an association. If you would have a class diagram that shows all attributes of Window, then 'size : Area' would be one of them.
The dot notation is a relatively new notation and it is not widely used. Instead, many designers use the arrow notation, also shown in figure 9.12. According to UML, this so-called navigability arrowhead specifies that the associated instance of Area can be accessed efficiently from Window, irrespective of how and why this is the case. Most designers would assume that it means that Window has an attribute 'size : Area', but strictly speaking, this is not what the UML specification says.
Using both the arrow and the dot, as in figure 9.12, is valid, but redundant.
Related
In UML, is it possible to draw an aggregation where the component object can access the composite object? Like in this image, but with only one association line, so the association end touching A would have a diamond and an arrow.
If that isn't possible, the diagram I drawn is valid? If not, why?
Another point of view, navigability is important to show how is it possible to navigate in the model and how to access to instances.
Another point is about OCL, if navigability is not defined some OCL queries will be hard to write.
Specification describes (p 198): Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.
And about Property class (p 149): The query isNavigable() indicates whether it is possible to navigate across the property. body: not classifier->isEmpty() or association.navigableOwnedEnd->includes(self).
So to model or not navigability is important.
If you want to have navigability in both side, the following image shows that:
But in section 6 of the specifiation, it is written:
An association with neither end marked by navigability arrows means that the association is navigable in both directions.
Arrow notation is used to denote association end navigability. By definition, all class-owned association ends are navigable. By convention, all association owned ends in the metamodel are not navigable.
So the following schema is the same than the above one. This is tricky but it seems true.
Of course that's possible.
If you want to save space, you can use a single line for the association:
Here's my personal opinion about navigability: The navigational arrow is not needed as the existence of the property owner implies that already.
P. 110 of the specs:
When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.
P. 200:
Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the Association whereas navigable ends were assumed to be owned by the Classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are separate concepts, each with their own explicit notation. Association ends owned by classes are always navigable, while those owned by associations may be navigable or not.
But what is an association that is just named? It's a useless construct so far. What you intend is to finally create attributes in either classes - by means of properties in which case you add this (new) dot. To me this is simply over-constructed and impractical. Who is really using those dots? In EA you have to open sub-menus to make them appear. For me (and probably most UML readers) a role name represents a property and this an attribute in the other side. That's just "(my) human logic" behind that proposition. So, my practical approach:
Use simple connectors for association
Eventually add (non-) navigability (crosses and) arrows
Later add role names to indicate the use of attributes at the other end (rather than adding a typed attribute to the class' list).
And that's it. Just forget that silly dot that's a) hard to produce (in EA) and b) even harder to recognize.
Once again: this last part here is my recommendation for practical modeling.
I read the posts in
association owned by classifier and association owned by relationship in UML
Setting the association end ownership in UML: What does it mean with respect to generated code in visual paradigm (or in other UML tools)?
http://www.uml-diagrams.org/association.html
but the difference between "navigation" and "ownership" of associations of UML class diagrams is still unclear to me. Moreover, UML 2.5 was released in the meantime.
The specification states the following:
Association ends owned by classes are always navigable, while those
owned by associations may be navigable or not.
This means, that the example c below is invalid. Examples a and b are valid, in both cases the right end is navigable. However, in example b the left end is not navigable.
Am I right?
What is the semantic difference between navigation and ownership? Is navigation a "generic" way of accessing the opposite class while ownership enforces a class to have an attribute?
The specs say
Dot notation is used to denote association end ownership, where the dot shows that the Class at the other end of the line owns the Property whose type is the Class touched by the dot.
So a and b are valid and c is strange. Assuming left begin class A and right being class B. In case a A owns a property that is of type B and thus it can navigate to it. Case b explicitly adds the information that A can navigate to B which is already obvious by using the dot. In case c B owns a property of type A (and therefore can navigate). Additionally you indicate navigation from A to B without showing ownership. So that's strange.
Ownership just says there is something (a pointer) to navigate to the other object. To cite the specs (p. 126):
Navigation arrows may be shown, but if shown, they shall agree with the navigation of the Association’s ends.
and later (p. 201):
In practice, it is often convenient to suppress some of the arrows and crosses that signify navigability of association ends. A conforming tool may provide various options for showing navigation arrows and crosses. As with dot notation, these options apply at the level of complete diagrams.
Show all arrows and crosses. Navigation and its absence are made completely explicit.
Suppress all arrows and crosses. No inference can be drawn about navigation.
Suppress all crosses. Suppress arrows for Associations with navigability in both directions, and show arrows only for Associations with one-way navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no navigation at all; however, the latter case occurs rarely in practice.
Navigation does not have a real use (in most cases). You show navigation by adding role names which make clear that A sees B as role. There's a notation with a cross near the end which explicitly forbids navigation. This might be useful in some cases.
It might be noted that the specs are rather silent about "navigation" (just grep the occurrences) compared to "ownership" (which is used quite a bit more). This is probably to account to the fact that the ownership had been introduced recently.
I have 2 classes in UML and now need to create a constraint for this part - attribute1:String is in class1, and attribute2:int is in class2, connection between classes is generalization - can be changed to association.
I need to write this somehow
if attribute1 contains 'First year',
then attribute2 have multiplicity [1..2],
else if attribute1 contains 'Second year',
then attribute2 have multiplicity [3..4], and so on.
I know all values that attribute1 can take defined as enumeration(12 values, but only 4 if conditions is needed because every 3 have same part of text at begin).
I am creating UML in enterprise architect if its important.
Here is the picture of classes
or
There are several ways to model that
Put a constraint on association
This is a simplest and most obvious solution. Put a constraint describing logic in a note symbol in curly brackets {} and link it to the association. The constraint can have any form, e.g. natural language or formal language like OCL
Note that in such case your multiplicity on a constraint will range from 1 to the achievable maximum for all possible values of each enumeration value.
The drawback is that the information is purely textual and might be difficult to comprehend.
Create subclasses (solution earlier suggested by Jim L. in his answer)
Subclass can redefine an attribute, e.g. changing the multiplicity. On a parent level the class would have a multiplicity with a maximum achievable maximum while each "year specific" subclass will have a multiplicity matching requirements for that year.
You also need to anyway model a constraint for each of subclasses defining which enumeration values are available for that particular subclass.
The drawback of this solution is that when you have a possibility to change from one year to another, it'll not be a simple attribute change but rather a whole replacement of one subtyped object into another one with a different subclass as a type.
Multiplicity as variables
The idea is that you handle a logic of mapping between the possible values and related multiplicities and on association you represent the multiplicity using attributes of that mapping rather than specific numbers.
This approach builds a bunch of possible detailed solution but I group them together as they all follow the same approach with just slight differences on how to handle the multiplicity values. I'll give just one detailed solution example (more to follow if someone asks)
One of solutions here is to use data type rather than enumeration. The data type will have in its structure a name (which can still be using the enumeration as a base) and two values (lower and upper multiplicity values). Then your attribute1 will be of that data type and your multiplicities will reference the attribute1 and it's specific properties.
Your date type might for example contain properties name, minM and maxM and then on attribute you'll have a multiplicity minM..maxM.
Of course you need to add constrains ensuring that {0<=minM<=maxM} on data type and it's good to specify a set of possible values for a data type somewhere in a documentation as e.g. a table.
A drawback of this solution is that the relationship between specific value and its multiplicity restrictions is not directly on a diagram. Yet this is balanced by a much stronger flexibility of a solution.
Multiplicity as a formula
If there is a simple logic between e.g. year and number of related elements that can be written as a formula such formula can also be used in a multiplicity. This is especially useful if you split your enumeration into two separate numeric attributes (hey, you've got a class, when choosing you can still use enumeration, just map it inside the class!). I'll make this assumption in my example.
Let's say that instead of attribute1 you have two attributes: yearNo and yearType. Moreover lets say that in first year you can have 1 or 2 objects of class2 in your class 1 object, in second year you have 3 or 4, and so on. In general you have in n-th year 2n-1 to 2n elements so your multiplicity will be 2*yearType-1..2*yearType
A drawback of this approach is that it is possible only if there is a formula behind.
Additional remarks:
I believe the mentioned in solution 4 split of your attribute1 is a good solution regardless which solution you choose.
Generalization has no multiplicity. This type of relationship shows that object of a subclass is at the same type an object of a supertype. In my opinion you should not use this type of relationship here. Most probably you were thinking of shared/composite aggregation rather than generalization (but it has a different arrow head - a diamond, not triangle. Of course it can be quite safely replaced with association.
Don't use association to the Enumeration (in general to a data type). If you put an attribute as a textual attribute in a class, link it with a type through a dependency (a dashed line with an open arrow). For enumeration (data type in general) this is the only relationship. For normal classes as an attribute type you can exchange inline attribute with an (graphically shown) association (with a role name to make it fully replaceable).
I think you need to replace the enumeration with explicit subclasses under Class2. Each class can then redefine multiplicity for attribute2. While you could express this in OCL about the enumeration, few people would understand it.
I was reading through a tutorial on UML Class diagrams and I'm having problems understanding Association Classes and why this MileageCredit class isn't part of the FrequentFlyer class in the below example (taken from figure 11 of the tutorial here):
Assuming that it's a one-to-one relation between FrequentFlyer and MileageCredit (if a person had two FrequentFlyer memberships they'd still have different frequentFlyerNumber numbers) then I would just put these baseMiles and bonusMiles properties in the FrequentFlyer Class itself.
Could someone please explain why this is wrong?
MileageCredit is an AssociationClass, which means this is simultaneously an Association (linking) Flight and FrequentFlyer) and a class that describes this Association. This fact is depicted by a dashed line connecting the class and the association. Note that acording to the UML specification those class and association together create one entity.
In your example there is Association (that is called MileageCredit) between FrequentFlyer and a Flight. You may assume that this shows a Flight taken by a FrequentFlyer. As for these Association you need additional information (number of award and bonus miles that are awarded to the FrequentFlyer for this Flight) this association has this extra Class describing this information.
If you created baseMiles and bonusMiles on FrequentFlyer that would have absolutely no relationship to the Association - it would be only information about total points awarded to the FrequentFlyer.
Does double association exist in UML? Let's say, for example that i have two classes: User and Account with their own attributes which are not important and that in the User class there should be exactly two attributes of type Account.
In this type of scenario when making the UML class-diagram should there be a double association or is there another way to emphasise the fact that there are two attributes of that type?
Thanks
In fact to model "a double association", I would use two associations which are useful to speficy a different role for each association as depicted below .