I'd like to know if it is correct to add an Association Class to a Composition relationship?
For example (see figure below), can I add an Association Class (i.e. NameValue class) to the composition relationship between Name class and Value class? One Name can have multiple Value and one Value can only be attached to one Name. NameValue class stores the name-value pairs.
The reason why I create the association class (i.e. NameValue class) is that I need to create associations/relationships between NameValue class and other classes such as Class A.
If the answer is yes, is it recommended to turn the association class into a normal class?
Many thanks!
I'd like to know if it is correct to add an Association Class to a Composition relationship?
yes in an association-class the association can have an owner-end property being a composition, in formal/2017-12-05 there is nothing in § 11.5.3.2 Association Classes starting page 200 nor in § 11.8.2 AssociationClass [Class] against that even association-class has some constraints
NameValue class stores the name-value pairs.
note this is absolutely not the goal of the class of an association-class in UML, and not necessary the case when you implement an association-class
The reason why I create the association class (i.e. NameValue class) is that I need to create associations/relationships between NameValue class and other classes such as Class A
because NameValue is used at implementation level to stores the name-value pairs and then to implement the association(-class), in UML the diagram you want is :
(NameValue does not exist at UML level but only at implementation level)
If the answer is yes, is it recommended to turn the association class into a normal class?
At UML level the association-class do not exist for nothing, they make the model clear, so I do not recommend to not use class-association (but this is of course opinion-based)
Related
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 ?
In a UML class diagram, the value of one of the attributes of a class is a (typed) dictionary. What is a proper UML type annotation? (Within the box; not as an association.)
For example, in Python I would annotate this attribute with Dict[A,B] or possibly Mapping[A,B]. I am not asking about Python; this is just one example of a somewhat generic attribute annotation. I am open to the possibility that UML does not offer a language agnostic equivalent to this, but I am hoping that is not true.
Comment: I am asking about generic attribute annotation, directly with the class box. I do not wish to add a separate class box for Dict to the diagram. Therefore this is not a duplicate of How can I represent a Python dictionary in UML?
In UML Dict is typically model as a template class with two template parameters for instance named key and value.
Let's say you want the class C has the attribute a being a Dict[A,B], so you have a binding having the template param substitutions key -> A and value -> B.
There are several ways to show that in a class diagram.
For instance using the class DictAB to model Dict[A,B] :
or if you prefer :
But it is also possible to not use the auxiliary class DictAB and to use the textual representation of the binding expression (see formal/2017-12-05 § 7.3.4 page 26) :
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?).
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).
In UML, I diagram class B extending class A. In my actual class implementation, class B's constructor sets default values for protected members of class A. I know how to diagram default values for a class's owned members, but how do I diagram default values for fields which are not owned by the class?
In other words, how do I diagram default values in class B for fields defined in class A?
(note: I'm unable to change the class structure; I'm only diagramming)
This should be the way:
In order to create the picture I used Sparx Systems Enterprise Architect and the "Features & Properties → Override Attribute Initializers" context menu operation applied to the inherited field1 attribute.
So I think that this notation is correct because:
there is a remarkable tool that supports it
this notation is also used when showing slots in object instances
I'm not aware of any counterargument
You can use redefinition of attribute from class A in class B. Redefinition should set default value in class B. Or you can define instance specification (instance of class B) with slots. Fill slot value of specific attribute in instance of class B.