In this post we provide a detailed description of the possible associations among classifiers and how they are modeled in the Eclipse Modeling Framework through Papyrus
The UML Superstructure (see http://www.omg.org/spec/UML) defines the Association meta-class as aClassifier (it extends both the Classifier and Relationship meta classes from Kernel) which “ declares that there can be links between instances of the associated types. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end”. As an association is a link it consists of two ends each one having its own characteristics.
As it represents a link, an association has two ends. An association’s end is modeled by means of a UML Property which can be owned by the classifier involved at the related end of the association, in that case the association is said to be navigable as the source classifier can directly refer to the target instance (the instance at the other end of the association) by means of that property. Otherwise the property representing the association end may be owned by the association instance itself (see the following example).
Figure 1 depicts an example of association between two UML classes (Class1 and Class2). The association is called class1_class2_1 (the label close to the edge). In the depicted example the association first end is named class1 while the second end is named class2. Those two names are the roles each instance plays in the association. So a Class1 instance will have a class2 property typed as Class2 (and named as the association second end) by means of which navigating the association.
The arrow at the association second end in fact means that the association can be navigated from a Class1 instance to a Class2 instance but not the vice viceversa.
This is depicted in the Figure 2 UML model, which corresponds to the Figure 1 diagram. It shows the Class1 owns a class2 named attribute (typed as Class2). Because of the one way navigation the association owns the second end (see the class1_class2_1 ownedEnd compartment) as a class1 named property (typed Class1). A reference to both the association ends is contained in the association’s memberEnd compartment.
In Figure 3 we added two ways navigation. There is thus one arrow at each end of the association edge. Moreover, as you can see in the related model both the association ends are owned (as properties) each by its related Classifier (Class1 owns the class2 property while Class2 owns the class1 property). A reference to each association end is contained in the association end’s memberEnd compartment.
Figure 4 depicts the same association in which we have set the secondEnd’s aggregation meta-attribute to composite. We have also set the end’s multiplicity to 1..*. This means each Class1 instance owns from one to any number of Class2′s instances which are accessible through the Class1::class2 property which has lowerBound=1 and upperBound = -1.
The UML model depicted in figure which corresponds to the diagram shows again the association first end is actually owned by the association itself. This is due to the fact the association’s navigability is one way again; from Class1 to Class2. The composite aggregation means that the Class2′s instance owned by a Class1′s instance via such association are deleted if the Class1′s instance is deleted.
An association may be ordered (isOrdere = true). In that case it means that the the collection of elements targeted by the association end is ordered.
If the association end is marked as unique (isUnique = true) the collection shall be considered a set. Which means it does not allow duplicated elements.
If you have found this post useful please consider to share it with your friends
thank you !!!