Home » Modeling » UML2 » org.eclipse.uml2.uml.Type::createAssociation
| org.eclipse.uml2.uml.Type::createAssociation [message #760371] |
Fri, 02 December 2011 08:19  |
Eclipse User |
|
|
|
Hello,
i'm confused a little bit with the strange behaviour, which method
createAssociation has. It's signature is:
Association createAssociation(boolean end1IsNavigable,
AggregationKind end1Aggregation,
java.lang.String end1Name,
int end1Lower,
int end1Upper,
Type end1Type,
boolean end2IsNavigable,
AggregationKind end2Aggregation,
java.lang.String end2Name,
int end2Lower,
int end2Upper)
I want to explain, what i found strange, using example from this tutorial:
http://wiki.eclipse.org/MDT/UML2/Getting_Started_with_UML2
There, classes Supplier and PurchaseOrder are in an association, which
is created with the following call:
createAssociation(supplierClass, true,
AggregationKind.COMPOSITE_LITERAL, "orders", 0,
LiteralUnlimitedNatural.UNLIMITED, purchaseOrderClass, false,
AggregationKind.NONE_LITERAL, "", 1, 1);
If we map actual arguments to formal params of the createAssociation
method, we get
end1 = supplierClass, end1Name = "orders"
end2 = purchaseOrderClass, end2Name = ""
supplierClass.createAssociation(..., end1Name, ..., purchaseOrderClass,
....);
As I understand, it should create an association, where one of the ends,
end1, which represented with supplierClass, has name(role) "orders". But
if we look at the class diagram, we see, that "orders" is assigned to
the another end of the association, end2, that is to purchaseOrderClass.
So, everything get's "inverted" when we think in terms of
createAssociation method.
Now, the question is, is that really so, is my observation right or wrong?
Thanks in advance
|
|
|
| Re: org.eclipse.uml2.uml.Type::createAssociation [message #760391 is a reply to message #760371] |
Fri, 02 December 2011 09:17  |
 Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Emil,
Are you getting confused by the fact that the labels are displayed at
the far end of the arrow rather than the near end?
On 02/12/2011 9:19 AM, Emil Huseynli wrote:
> Hello,
>
> i'm confused a little bit with the strange behaviour, which method
> createAssociation has. It's signature is:
>
> Association createAssociation(boolean end1IsNavigable,
> AggregationKind end1Aggregation,
> java.lang.String end1Name,
> int end1Lower,
> int end1Upper,
> Type end1Type,
> boolean end2IsNavigable,
> AggregationKind end2Aggregation,
> java.lang.String end2Name,
> int end2Lower,
> int end2Upper)
>
>
> I want to explain, what i found strange, using example from this
> tutorial:
>
> http://wiki.eclipse.org/MDT/UML2/Getting_Started_with_UML2
>
> There, classes Supplier and PurchaseOrder are in an association, which
> is created with the following call:
>
> createAssociation(supplierClass, true,
> AggregationKind.COMPOSITE_LITERAL, "orders", 0,
> LiteralUnlimitedNatural.UNLIMITED, purchaseOrderClass, false,
> AggregationKind.NONE_LITERAL, "", 1, 1);
>
> If we map actual arguments to formal params of the createAssociation
> method, we get
>
> end1 = supplierClass, end1Name = "orders"
> end2 = purchaseOrderClass, end2Name = ""
>
> supplierClass.createAssociation(..., end1Name, ...,
> purchaseOrderClass, ...);
>
> As I understand, it should create an association, where one of the
> ends, end1, which represented with supplierClass, has name(role)
> "orders". But if we look at the class diagram, we see, that "orders"
> is assigned to the another end of the association, end2, that is to
> purchaseOrderClass.
>
> So, everything get's "inverted" when we think in terms of
> createAssociation method.
>
> Now, the question is, is that really so, is my observation right or
> wrong?
>
> Thanks in advance
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: org.eclipse.uml2.uml.Type::createAssociation [message #760400 is a reply to message #760391] |
Fri, 02 December 2011 09:53 |
| Eclipse User |
|
|
|
yes, position of label in fact, but...
same happens with multiplicities, and with isOrdered, isNavigable flags
On 02.12.2011 10:17, Ed Merks wrote:
> Emil,
>
> Are you getting confused by the fact that the labels are displayed at
> the far end of the arrow rather than the near end?
>
>
> On 02/12/2011 9:19 AM, Emil Huseynli wrote:
>> Hello,
>>
>> i'm confused a little bit with the strange behaviour, which method
>> createAssociation has. It's signature is:
>>
>> Association createAssociation(boolean end1IsNavigable,
>> AggregationKind end1Aggregation,
>> java.lang.String end1Name,
>> int end1Lower,
>> int end1Upper,
>> Type end1Type,
>> boolean end2IsNavigable,
>> AggregationKind end2Aggregation,
>> java.lang.String end2Name,
>> int end2Lower,
>> int end2Upper)
>>
>>
>> I want to explain, what i found strange, using example from this
>> tutorial:
>>
>> http://wiki.eclipse.org/MDT/UML2/Getting_Started_with_UML2
>>
>> There, classes Supplier and PurchaseOrder are in an association, which
>> is created with the following call:
>>
>> createAssociation(supplierClass, true,
>> AggregationKind.COMPOSITE_LITERAL, "orders", 0,
>> LiteralUnlimitedNatural.UNLIMITED, purchaseOrderClass, false,
>> AggregationKind.NONE_LITERAL, "", 1, 1);
>>
>> If we map actual arguments to formal params of the createAssociation
>> method, we get
>>
>> end1 = supplierClass, end1Name = "orders"
>> end2 = purchaseOrderClass, end2Name = ""
>>
>> supplierClass.createAssociation(..., end1Name, ...,
>> purchaseOrderClass, ...);
>>
>> As I understand, it should create an association, where one of the
>> ends, end1, which represented with supplierClass, has name(role)
>> "orders". But if we look at the class diagram, we see, that "orders"
>> is assigned to the another end of the association, end2, that is to
>> purchaseOrderClass.
>>
>> So, everything get's "inverted" when we think in terms of
>> createAssociation method.
>>
>> Now, the question is, is that really so, is my observation right or
>> wrong?
>>
>> Thanks in advance
|
|
|
| Re: org.eclipse.uml2.uml.Type::createAssociation [message #760417 is a reply to message #760400] |
Fri, 02 December 2011 10:19 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Emil,
All information about the property (except for the diamond I suppose) is
shown at the far end of the arrow (far from the end that owns the property).
On 02/12/2011 10:53 AM, Emil Huseynli wrote:
> yes, position of label in fact, but...
>
> same happens with multiplicities, and with isOrdered, isNavigable flags
>
> On 02.12.2011 10:17, Ed Merks wrote:
>> Emil,
>>
>> Are you getting confused by the fact that the labels are displayed at
>> the far end of the arrow rather than the near end?
>>
>>
>> On 02/12/2011 9:19 AM, Emil Huseynli wrote:
>>> Hello,
>>>
>>> i'm confused a little bit with the strange behaviour, which method
>>> createAssociation has. It's signature is:
>>>
>>> Association createAssociation(boolean end1IsNavigable,
>>> AggregationKind end1Aggregation,
>>> java.lang.String end1Name,
>>> int end1Lower,
>>> int end1Upper,
>>> Type end1Type,
>>> boolean end2IsNavigable,
>>> AggregationKind end2Aggregation,
>>> java.lang.String end2Name,
>>> int end2Lower,
>>> int end2Upper)
>>>
>>>
>>> I want to explain, what i found strange, using example from this
>>> tutorial:
>>>
>>> http://wiki.eclipse.org/MDT/UML2/Getting_Started_with_UML2
>>>
>>> There, classes Supplier and PurchaseOrder are in an association, which
>>> is created with the following call:
>>>
>>> createAssociation(supplierClass, true,
>>> AggregationKind.COMPOSITE_LITERAL, "orders", 0,
>>> LiteralUnlimitedNatural.UNLIMITED, purchaseOrderClass, false,
>>> AggregationKind.NONE_LITERAL, "", 1, 1);
>>>
>>> If we map actual arguments to formal params of the createAssociation
>>> method, we get
>>>
>>> end1 = supplierClass, end1Name = "orders"
>>> end2 = purchaseOrderClass, end2Name = ""
>>>
>>> supplierClass.createAssociation(..., end1Name, ...,
>>> purchaseOrderClass, ...);
>>>
>>> As I understand, it should create an association, where one of the
>>> ends, end1, which represented with supplierClass, has name(role)
>>> "orders". But if we look at the class diagram, we see, that "orders"
>>> is assigned to the another end of the association, end2, that is to
>>> purchaseOrderClass.
>>>
>>> So, everything get's "inverted" when we think in terms of
>>> createAssociation method.
>>>
>>> Now, the question is, is that really so, is my observation right or
>>> wrong?
>>>
>>> Thanks in advance
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: org.eclipse.uml2.uml.Type::createAssociation [message #760527 is a reply to message #760371] |
Fri, 02 December 2011 17:24 |
Carsten Reckord
Messages: 139
Registered: July 2009 |
Senior Member |
|
|
Emil,
That method signature sure is a bit confusing...
> As I understand, it should create an association, where one of the ends,
> end1, which represented with supplierClass, has name(role) "orders". But
> if we look at the class diagram, we see, that "orders" is assigned to
> the another end of the association, end2, that is to purchaseOrderClass.
What it does is create one end that is _owned_ by supplierClass and has name
"orders" and type purchaseOrderClass. The other end in turn will be named ""
and have the "inverse" type supplierClass, and since it's not navigable,
will be owned by the association.
> So, everything get's "inverted" when we think in terms of
> createAssociation method.
I find that instead of looking at association ends in terms of their owner
or "near" and "far" ends, it's better to look at them from the association's
perspective. Their name and cardinality are always displayed where the end
points to, i.e. the end's type. So "orders" and "0..*" are displayed next to
PurchaseOrder, which is where that end points to. (This way of looking at it
also extends to n-ary assocs, where you don't have a near or far end per se).
Again, the problem with the factory method in the example is that it isn't
very clear about what end will end up having what type...
I think the example would have been much clearer had the Java code followed
the same procedure as the manual example above, which is my personally
preferred way for programmatically creating associations. I find this way to
be much clearer (and it extends much better to n-ary associations which
you've asked about earlier). Let's take a look at the example.
First, let's create an association, for example in supplierClass's package.
Sadly there's no createOwnedAssociation(), but since Associations are types
in UML, we can do:
Association association =
(Association)supplierClass.getPackage().createOwnedType("A_orders_supplier",
UMLPackage.Literals.ASSOCIATION);
Now for the ends:
You want one end named "orders" that allows you to navigate from a Supplier
to a PurchaseOrder. The type that an end points to (PurchaseOrder) will be
that end's type. To be navigable, the end should be owned by the type at
which the navigation starts, i.e. Supplier [1][2].
Property ordersEnd = supplierClass.createOwnedAttribute("orders",
purchaseOrderClass);
ordersEnd.setAssociation(association);
The other end is non-navigable and unnamed in the example. Non-navigable
ends are always owned by the association itself (there's no start point for
any navigation, so no need for any class to own it). It "points to" the
other direction, so its type is Supplier.
Property supplierEnd = association.createOwnedEnd("", supplierClass);
(Note: I'd prefer giving non-navigable ends sensible names, too)
Now we can quickly set the other properties of the two ends like
multiplicity and aggregation kind:
ordersEnd.setAggregation(AggregationKind.COMPOSITE_LITERAL);
ordersEnd.setLower(0);
ordersEnd.setUpper(LiteralUnlimitedNatural.UNLIMITED);
supplierEnd.setLower(1);
supplierEnd.setUpper(1);
And with that we are done. Surely a bit more work than that one method call,
but I find it much less confusing...
And you can go on from here and create n-ary associations just as easily by
adding more ends. There's just one little pitfall to that: So far I've said
that navigable ends should be owned by the class where the navigation
starts. But where does the navigation start in, say, an association with 3
ends? For that reason the UML demands that all ends of an n-ary association
with n > 2 must be owned by the association and not its end classes. But as
we've just seen above, regular owned ends of an association are considered
non-navigable. So, in order to create an n-ary association with navigable
ends, we need another way. In comes Association::navigableOwnedEnds:
Association ternaryAssoc = model.createOwnedType("A_ternary",
UMLPackage.Literals.ASSOCIATION);
ternaryAssoc.createNavigableOwnedEnd("foo", fooClass);
ternaryAssoc.createNavigableOwnedEnd("bar", barClass);
ternaryAssoc.createOwnedEnd("baz", bazClass);
would create a ternary assoc with two navigable and one non-navigable owned
end. With such an association, it would be possible to navigate from a tuple
(foo,baz) to Bar or from a tuple (bar,baz) to Foo, but not from (foo, bar)
to Baz.
HTH,
Carsten
[1] This is the usual case for binary associations - you could of course
also choose to make it a navigableOwnedEnd of the association...
[2] A note about order: It's not terribly important, but the order in which
you add properties to the association determines its "reading direction",
i.e. the little filled arrow you sometimes see next to the association's
name always points toward the last end in its list of ends. Therefore, to
strictly match the association from the example, you should create
supplierEnd first.
|
|
|
| Re: org.eclipse.uml2.uml.Type::createAssociation [message #760594 is a reply to message #760527] |
Sat, 03 December 2011 10:00 |
| Eclipse User |
|
|
|
It's just amazing! You've really throught a light to all that stuff.
Thanks a lot for such a detailed explanation!
On 02.12.2011 18:24, Carsten Reckord wrote:
> Emil,
>
> That method signature sure is a bit confusing...
>
>> As I understand, it should create an association, where one of the ends,
>> end1, which represented with supplierClass, has name(role) "orders". But
>> if we look at the class diagram, we see, that "orders" is assigned to
>> the another end of the association, end2, that is to purchaseOrderClass.
>
> What it does is create one end that is _owned_ by supplierClass and has name
> "orders" and type purchaseOrderClass. The other end in turn will be named ""
> and have the "inverse" type supplierClass, and since it's not navigable,
> will be owned by the association.
>
>> So, everything get's "inverted" when we think in terms of
>> createAssociation method.
>
> I find that instead of looking at association ends in terms of their owner
> or "near" and "far" ends, it's better to look at them from the association's
> perspective. Their name and cardinality are always displayed where the end
> points to, i.e. the end's type. So "orders" and "0..*" are displayed next to
> PurchaseOrder, which is where that end points to. (This way of looking at it
> also extends to n-ary assocs, where you don't have a near or far end per se).
>
> Again, the problem with the factory method in the example is that it isn't
> very clear about what end will end up having what type...
>
> I think the example would have been much clearer had the Java code followed
> the same procedure as the manual example above, which is my personally
> preferred way for programmatically creating associations. I find this way to
> be much clearer (and it extends much better to n-ary associations which
> you've asked about earlier). Let's take a look at the example.
>
> First, let's create an association, for example in supplierClass's package.
> Sadly there's no createOwnedAssociation(), but since Associations are types
> in UML, we can do:
>
> Association association =
> (Association)supplierClass.getPackage().createOwnedType("A_orders_supplier",
> UMLPackage.Literals.ASSOCIATION);
>
> Now for the ends:
>
> You want one end named "orders" that allows you to navigate from a Supplier
> to a PurchaseOrder. The type that an end points to (PurchaseOrder) will be
> that end's type. To be navigable, the end should be owned by the type at
> which the navigation starts, i.e. Supplier [1][2].
>
> Property ordersEnd = supplierClass.createOwnedAttribute("orders",
> purchaseOrderClass);
> ordersEnd.setAssociation(association);
>
> The other end is non-navigable and unnamed in the example. Non-navigable
> ends are always owned by the association itself (there's no start point for
> any navigation, so no need for any class to own it). It "points to" the
> other direction, so its type is Supplier.
>
> Property supplierEnd = association.createOwnedEnd("", supplierClass);
>
> (Note: I'd prefer giving non-navigable ends sensible names, too)
>
> Now we can quickly set the other properties of the two ends like
> multiplicity and aggregation kind:
>
> ordersEnd.setAggregation(AggregationKind.COMPOSITE_LITERAL);
> ordersEnd.setLower(0);
> ordersEnd.setUpper(LiteralUnlimitedNatural.UNLIMITED);
>
> supplierEnd.setLower(1);
> supplierEnd.setUpper(1);
>
> And with that we are done. Surely a bit more work than that one method call,
> but I find it much less confusing...
>
> And you can go on from here and create n-ary associations just as easily by
> adding more ends. There's just one little pitfall to that: So far I've said
> that navigable ends should be owned by the class where the navigation
> starts. But where does the navigation start in, say, an association with 3
> ends? For that reason the UML demands that all ends of an n-ary association
> with n> 2 must be owned by the association and not its end classes. But as
> we've just seen above, regular owned ends of an association are considered
> non-navigable. So, in order to create an n-ary association with navigable
> ends, we need another way. In comes Association::navigableOwnedEnds:
>
> Association ternaryAssoc = model.createOwnedType("A_ternary",
> UMLPackage.Literals.ASSOCIATION);
> ternaryAssoc.createNavigableOwnedEnd("foo", fooClass);
> ternaryAssoc.createNavigableOwnedEnd("bar", barClass);
> ternaryAssoc.createOwnedEnd("baz", bazClass);
>
> would create a ternary assoc with two navigable and one non-navigable owned
> end. With such an association, it would be possible to navigate from a tuple
> (foo,baz) to Bar or from a tuple (bar,baz) to Foo, but not from (foo, bar)
> to Baz.
>
>
> HTH,
> Carsten
>
> [1] This is the usual case for binary associations - you could of course
> also choose to make it a navigableOwnedEnd of the association...
>
> [2] A note about order: It's not terribly important, but the order in which
> you add properties to the association determines its "reading direction",
> i.e. the little filled arrow you sometimes see next to the association's
> name always points toward the last end in its list of ends. Therefore, to
> strictly match the association from the example, you should create
> supplierEnd first.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 01:00:44 GMT 2024
Powered by FUDForum. Page generated in 0.02381 seconds |
] 
Search
Help
Register
Login
Home
