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 ?
Related
I am trying to implement the UML class diagram for the first time. This is the class diagram which I have been work through:
This is the requirement:
I do not expect anyone do it for me, but I think I need someone help to check where I can improve or I anything is missing. Thank You.
A class diagram is a structural diagram. Behaviors (e.g. adding, deleteing, etc...) shall not appear therein, except if you decide to make them operations of one class.
Here how to understand the requirements:
R1. Classes GroceryList, Item and User. Association between 0..n GroceryList and 0..n Item. Association class with property Quantity
R2. Class ItemType
R3. Association between 0..n Item and 1 ItemType. Both classes have a property Name
R6. Association class also has property CheckOff
R10. Association between 1 User and 0..n GroceryList. GroceryList has a property Name
Assumption: User has a property Name
If your teacher never told you what an association class is, then use a class ListItem instead, with an association of 0..n ListItems with 1 Item, and a coposition link from GroceryList to ListItem
Remove any other box in your diagram, because these are either behaviors, or a duplicate of an existing class.
For the operations, it is not clear to me because it depends on the architecture of your application (e.g. will you use repository classes?).
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.
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).
Quite new to OCL, thanks for the help.
So I have a profile with the stereotypes as shown:
Can someone tell me how to write an invariant constraint that says any association that is Coloured means that all connected classes must have the same colour value in their colour property?
I had this so far:
Context UML::InfrastructureLibrary::Core::Constructs::Association
inv: Association.allInstances() -> forAll(a:Association|a.oclIsTypeOf(Coloured) implies
a.associatedElement.colour = a.colour)
Pretty sure this is wrong because a.associatedElement does not exist.. but I do not understand how to access this 'all connected classes' or what that means. Perhaps I need something like
a.[association].colour ?
Thanks
From the UML spec (2.4.1 Superstructure, Sec. 7.3.3):
memberEnd : Property [2..*] Each end represents participation of instances of the classifier connected to the end in links of the association. This is an ordered association. Subsets Namespace::member.
So, something like this:
(...) -> forAll(a:Association|a.oclIsTypeOf(Coloured))->forAll(memberEnd->colour() = a.colour)
I doubt that's the exact statement, but it should get you started in the right direction.
Your diagram should specify the constraint as well. Just attach a note to your Coloured stereotype saying if the instance is an association both connected class objects have to have the same colour property.
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.