UML Notation for depicting relationship - uml

Can someone please explain to me what do the highlighted elements mean in a snapshot of a UML class diagram shown below:
The plus symbol
The text inside the curly braces
The image above has been taken from the UML specifications at http://www.omg.org/spec/UML/
on further reading I found
The curly braces are called "adornments", which in this case have been placed on relationship. In this case they have been used to place constraints on the elements that are part of the relationship.
Still no clue about the + symbol.

Adornments are everything added to the connectors, namely text labels. The curly brackets are constraints. These can be either plain text or OCL. The subsets is a keyword within UML. P. 17 of the UML spec says
Association Ends: each specified by its name, type, and multiplicity, any additional properties such as {union}, and a link to its opposite end. If the association end subsets or redefines others, this is shown in the additional properties as {subsets } or {redefines }, where is a link to the applicable end. This is followed by a textual description of the purpose and meaning of the association end. If an association end is derived, the name will be preceded by a forward slash. If the association end is a composition, this is indicated by a small black diamond adjacent to the name of the end.
The plus says the attribute (which the role name ownedTemplateSignature is) has public visibility. P. 60 of the specs:
public
A Named Element with public visibility is visible to all elements that can access the contents of the Namespace that owns it.
private
A NamedElement with private visibility is only visible inside the Namespace that owns it.
protected
A NamedElement with protected visibility is visible to Elements that have a generalization relationship to the Namespace that owns it.
package
A NamedElement with package visibility is visible to all Elements within the nearest enclosing Package (given that other owning Elements have proper visibility). Outside the nearest enclosing Package, a NamedElement marked as having package visibility is not visible. Only NamedElements that are not owned by Packages can be marked as having package visibility.
And on p. 111:
<visibility> is the visibility of the Property. (See VisibilityKind - sub clause 7.4.)
<visibility> ::= ‘+’ | ‘-‘ | ‘#’ | ‘~’
(in the order of the list above, e.g. '+' is public)
And to extend as suggested by #granier, the little dot (which had been introduced with 2.1.1) at the end of the associations has this meaning: (p. 200)
Ownership of Association ends by an associated Classifier may be indicated graphically by a small filled circle, which for brevity we will term a dot. The dot is to be drawn integral to the graphic path of the line, at the point where it meets the Classifier, inserted between the end of the line and the side of the node representing the Classifier. The diameter of the dot shall not exceed half the height of the aggregation diamond, and shall be larger than the width of the line. This avoids visual confusion with the filled diamond notation while ensuring that it can be distinguished from the line. The dot shows that the model includes a Property of the type represented by the Classifier touched by the dot. This Property is owned by the Classifier at the other end. In such a case it is normal to suppress the Property from the attributes compartment of the owning Classifier.
Actually the whole page is talking about ownership and navigability. But basically the dot means that the class at the opposite end owns the relation which means it can navigate towards the dotted class. Dots at either side mean that both classes know of each other.

Related

Questions regarding directed association link in class diagram

I have three questions on directed association link inside a class diagram.
here is a screenshot of what i did. i am using modelio.
Description of screenshot:
The screenshot shows a class "Dress" linked by a directed association link to an enumeration named "TypeOfClothes".
On the arrowhead side (near the enumeration) there is a multiplicity of 1 and public attribute named "TypeOfDress" is specified
On the non arrowhead part of the association there is a multiplicity of *
Under the class Dress, the public attribute "typeOfDress" of type "TypeOfClothes" is also specified
here are my questions:
1: When two class or a class and an enumeration are linked together with a directed association link like here what does the multiplicity under the none arrowhead part of the association means ?
2: From what I understand, the attribute above the association means the same thing as the attribute under the class typeOfDress. however there is no attribute created in the model when given only with association. Am i wrong somewhere ?
3: If I had an attribute given on the none arrowhead side of the association what would that means ?
I hope it's understandable, if not, please tell me what I can improve :)
Thank you for your help and have a nice day!
1: When two class or a class and an enumeration are linked together with a directed association link like here what does the multiplicity under the none arrowhead part of the association means ?
the fact the relation is not navigable from TypeOfClothes to Dress does not imply it is not possible to have a restriction on the number of instances of Dress associated to TypeOfClothes. So the multiplicity is given and being here * that means any number from 0.
2: From what I understand, the attribute above the association means the same thing as the attribute under the class typeOfDress. however there is no attribute created in the model when given only with association. Am i wrong somewhere ?
it is legal to show both an association and an attribute having the same name in the class diagram, even this is redundant and only one of them is enough. From the standard formal/2017-12-05 page 206 :
Figure 11.31 shows that the attribute notation can be used for an Association end owned by a Class, because an
Association end owned by a Class is also an attribute. Although it would typically be suppressed on grounds of
redundancy, this notation may be used in conjunction with the association notation to make it perfectly clear that the
attribute is also an Association end.
An attribute is an owned property, so if your class own the property you have the attribute even you do not mention it in the attribute compartment
3: If I had an attribute given on the none arrowhead side of the association what would that means ?
the relation is not navigable in that direction, so if you add a name near * it is just informative, it is not a property of TypeOfClothes, so better to not have it
Out of that typeOfDress is public because of the +, are you sure you want that ?

"EffectiveName" and "OtherEnd" structure in MDriven

Backround to the problem: I have connected two classes to each other in UML, both of them being regular classes and one of them is named "League".
In the "miscellaneous" menu in MDriven, I found that the following “EffectiveName": "League_children” as well as "OtherEnd": "League_parent".
This was confusing in three ways:
There is not a class named "League" in "OtherEnd"
The terms "League_children” and "League_parent" were created automatically
It says "League_children" not "LeagueChildren" with the latter one I thought was more correct becuase of how you write in code, and also everywere else in the diagrams and menus in MDriven's workspace.
I read about the terms "children" and "parent" in the official book (https://www.capableobjects.com/xdownloads/MDrivenTheBook/MDrivenTheBook-Part2-Design.pdf ) and obviously these are used when you have superclasses and subclasses to those. However, neither "League" or any other class in my diagrams as of now are superclasses", so why are these names created then?
Furthermore, "OtherEnd" is not called "League" and therefore shouldn't have be called "League_parent".
I searched through my different classes and found no hidden associations that I had acidentally/falsely deleted.
I recognize the _Parent _Children pattern as what MDriven does when adding an association from a class back to the same class.
If you check the Class in the tree I bet you will find an association pointing back to self. If this was added by mistake - delete it.
Normally MDriven leaves the name of association ends blank - then the effective name will be the name of the Class in the end. Name - if set - overrides this.
When creating associations back to self - MDriven sets the names of the ends appending _Parent and _Children.

visual paradigm reverse java code, class diagram

Using this tool the classes corresponding to my code were created.
Each class has attributes with its getter and setter methods.
The attributes are created in the diagram but with the label << Property >> Without the corresponding methods, as you can see from the image.
Moreover, lists are not attributed to the type List , even if I change the association into aggregation.
  The label << Property >> tells you precisely an attribute which correspond getter and setter?
I could not find anything about this label in the UML documentation
What you call label is a stereotype. Attributes with a <<Property>> stereotype are usually marked this way to tell a code generator that appropriate getter and setter methods shall be created if the target language supports (or requires) that.
Lists do not depend on the composition symbol but on the multiplicity which is barely readable, but I guess the dots near the associations are asterisks (for any multiplicity). The dots at the end of the associations are isOwned attributes (saying the the dot-marked class owns the association).

UML default visibility

is there a default visibility in UML2 if I don't (want to) add one of the four reserved visibilities?
As I know there is + for public, - for private, # for protected and ~ for package.
Or is the default depend on the implementation language that should be used, e.g. package for Java or private for C++?
Thanks so far.
If you don't add it then it's a don't care. Languages itself have their own rules and UML does not know how a language will treat it. The same goes for tools. They place one of the symbols (either public or private) as default and you eventually can change a default to something else. But again UML does not care.
Depending on how you use it you can tell the reader that a missing symbol will mean this or that.
Edit 1: Thanks to #xmojmr digging into the UML spec and the great critic uml-diagrams.org here are two statements. OMG first (SS2.4.1):
7.3.38 Package (from Kernel)...The query makesVisible() defines whether a Package makes an element visible outside itself. Elements
with no visibility and elements with public visibility are made
visible" and "7.3.39 PackageableElement (from Kernel)...
visibility...Default value is public
and from http://www.uml-diagrams.org/property.html
Note, that there is no default visibility. Also, visibility may be suppressed from being displayed on a diagram, even if it has some value in the model (e.g. stored by UML tool). So, if visibility is not shown on a diagram, it was either not specified or suppressed
Please also note that my original statement was just an expression of my experience from using UML in the real world. Feels good to see that my experience seems to be in synch with the theories ;-)
Edit 2: Looking into the 2.5 specs I found this in chap. 7.8 Classifier Descriptions on p. 48:
Attributes
- visibility : VisibilityKind [0..1] = public
A PackageableElement must have a visibility specified if it is owned by a Namespace. The default visibility is public.
Constraints
- namespace_needs_visibility
A PackageableElement owned by a Namespace must have a visibility.
inv: visibility = null implies namespace = null
So it says the default is public. But the constraint says it must have a visibility. Which to me means that you need to specify it?
If you don't understand definition, read the definition for definition :-/

How to draw a relationship between a property and a class in ArgoUML?

In ArgoUML, I have the ability to put a class Type to any property of a class. For example, I can declare a customer property with a Customer type in the Order class.
I can also easily draw a relationship from class to class:
But I can't figure out how to "draw" the link from the customer property to the Customer class. The link is never really connected to the property, but rather to the entire Order class.
I can move the position of the link manually:
But it's never really "locked" to the customer property, and can be moved automatically by the software at any moment.
Is there a way to do this?
You can not have an association in UML which is not connecting the entire two classes. It is not possible to touch the property inside the class.
Workarounds are:
add a note linked to the property
add an icon to the property which would be designed like an association.
I don't know if this advanced icons customization is available in this free tool but it is in other tools.
I found a flash demo which shows the association attribute with an icon. Look at : http://www.download-omondo.com/show_association_member.swf
If you need to understand what mean an association in UML and code generation in Java then have a look at this demo: http://www.download-omondo.com/association.swf
Hope this help.
ArgoUML follows the UML specification. Associations are drawn from one class to another. Attributes are drawn inside the 2nd compartment of a class.
The association type closest in meaning to an attribute is composition, but they are not equivalent.
You should never portray something AND as an attribute of a class, AND as a separate class associated to it.
E.g. 1. an Order may have a Number, that may be used by the customer to identify his Order. The Number is best portrayed as an attribute (in the 2nd compartment of the class).
E.g. 2. an Order may be associated to the Customer who placed the order. The Customer is best portrayed as a separate class, since it has its own lifespan (behavior), associated with the Order. This allows to show multiplicities and roles at both ends of the association line.

Resources