Home » Modeling » OCL » Traversing associations that own their ends in OCL
| Traversing associations that own their ends in OCL [message #9613] |
Tue, 06 March 2007 15:49  |
Eclipse User |
|
|
|
Originally posted by: maiera.de.ibm.com
Hi,
in the UML profile for CIM, we map CIM associations to UML association
classes that own their ends. (Note: I do understand and appreciate the
change in UML 2.1 that started distinguishing between navigability and
ownership of the ends).
The reason we decided to map it this way is naming ambiguity in CIM. In
CIM, the ends are always owned by the association classes, and so quite
naturally, over time, the CIM schema (i.e. the standard user model)
evolved such that naming conflicts would prevent the ends from being
owned by the associated classes, in many cases.
In UML user models using this CIM profile, we want to be able to write
OCL statements that traverse such UML association classes. However, it
seems to me that current OCL only allows to do such traversal from
within the context of an associated class if that class owns the end,
but not if the association class (or association) owns that end.
1. Can you please confirm that this understanding is correct ?
2. If so, given the fact that in CIM, the association classes have to
own the ends, this essentially prevents us from doing _any_ association
traversal in CIM user models.
3. If so, can we get an extension in OCL that allows us to do
association traversal even when the ends are owned by the association
(class) ?
One idea on how to address the above mentioned naming ambiguity in such
an extension would be to code the traversal in two steps in OCL: First
traverse to the association, then to the far end. Alternatively, an OCL
operation could be provided that performs the traversal and gets the
right scoping arguments to avoid the ambiguity, such as the association
class name, or role names of the ends.
Andy
|
|
|
| Re: Traversing associations that own their ends in OCL [message #9680 is a reply to message #9613] |
Tue, 06 March 2007 21:27  |
| Eclipse User |
|
|
|
Originally posted by: Ericson_George.EMC.com
More detail on the first suggested solution. The assertion being made is
that the two sets of associated classes in the attached diagram are
equivalent. And, therefore OCL should allow traversal from self, via an
association class to the opposite end class by the general algorithm:
self.<associationClassName>.<oppositeEndRoleName>
Note that this example illustrates the CIM issue that Andy referenced.
George
"Andreas Maier" <maiera@de.ibm.com> wrote in message
news:esk2jh$fau$1@utils.eclipse.org...
> Hi,
> in the UML profile for CIM, we map CIM associations to UML association
> classes that own their ends. (Note: I do understand and appreciate the
> change in UML 2.1 that started distinguishing between navigability and
> ownership of the ends).
>
> The reason we decided to map it this way is naming ambiguity in CIM. In
> CIM, the ends are always owned by the association classes, and so quite
> naturally, over time, the CIM schema (i.e. the standard user model)
> evolved such that naming conflicts would prevent the ends from being
> owned by the associated classes, in many cases.
>
> In UML user models using this CIM profile, we want to be able to write
> OCL statements that traverse such UML association classes. However, it
> seems to me that current OCL only allows to do such traversal from
> within the context of an associated class if that class owns the end,
> but not if the association class (or association) owns that end.
>
> 1. Can you please confirm that this understanding is correct ?
>
> 2. If so, given the fact that in CIM, the association classes have to
> own the ends, this essentially prevents us from doing _any_ association
> traversal in CIM user models.
>
> 3. If so, can we get an extension in OCL that allows us to do
> association traversal even when the ends are owned by the association
> (class) ?
>
> One idea on how to address the above mentioned naming ambiguity in such
> an extension would be to code the traversal in two steps in OCL: First
> traverse to the association, then to the far end. Alternatively, an OCL
> operation could be provided that performs the traversal and gets the
> right scoping arguments to avoid the ambiguity, such as the association
> class name, or role names of the ends.
>
> Andy
Attachment: test.jpg
(Size: 26.83KB, Downloaded 249 times)
|
|
|
| Re: Traversing associations that own their ends in OCL [message #9702 is a reply to message #9613] |
Wed, 07 March 2007 22:29 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Andy,
You are correct, currently the OCL parser does not support the navigation
of non-navigable association ends.
However, you can extend the Environment implementation for UML
(UMLEnvironment) to provide the non-navigable end when the parser looks up
a property name (using the Environment::lookupProperty method), even using
the implied name for unnamed ends. A corresponding extension of the
UMLEvaluationEnvironment would implement the navigation in the
EvaluationEnvironment::navigateProperty method). Probably EMF's inverse
cross-referencing capabilities (CrossReferencer, ECrossReferenceAdapter)
would be useful here.
Actually, this really ought to be done right in the OCL component's Ecore
and UML environments. Perhaps you could raise an enhancement request?
This would be a good contribution :-)
HTH,
Christian
Andreas Maier wrote:
> Hi,
> in the UML profile for CIM, we map CIM associations to UML association
> classes that own their ends. (Note: I do understand and appreciate the
> change in UML 2.1 that started distinguishing between navigability and
> ownership of the ends).
> The reason we decided to map it this way is naming ambiguity in CIM. In
> CIM, the ends are always owned by the association classes, and so quite
> naturally, over time, the CIM schema (i.e. the standard user model)
> evolved such that naming conflicts would prevent the ends from being
> owned by the associated classes, in many cases.
> In UML user models using this CIM profile, we want to be able to write
> OCL statements that traverse such UML association classes. However, it
> seems to me that current OCL only allows to do such traversal from
> within the context of an associated class if that class owns the end,
> but not if the association class (or association) owns that end.
> 1. Can you please confirm that this understanding is correct ?
> 2. If so, given the fact that in CIM, the association classes have to
> own the ends, this essentially prevents us from doing _any_ association
> traversal in CIM user models.
> 3. If so, can we get an extension in OCL that allows us to do
> association traversal even when the ends are owned by the association
> (class) ?
> One idea on how to address the above mentioned naming ambiguity in such
> an extension would be to code the traversal in two steps in OCL: First
> traverse to the association, then to the far end. Alternatively, an OCL
> operation could be provided that performs the traversal and gets the
> right scoping arguments to avoid the ambiguity, such as the association
> class name, or role names of the ends.
> Andy
|
|
|
| Re: Traversing associations that own their ends in OCL [message #9713 is a reply to message #9702] |
Wed, 07 March 2007 23:46 |
| Eclipse User |
|
|
|
Originally posted by: maiera.de.ibm.com
Christian,
this is very good information. Thanks much!
However, as I understand it, the proposal basically makes an end owned
by the association appear as if it were a (virtual?) member of the
associated class. Simply using such a virtual member creates an
ambiguity problem (potentially), since the uniqueness of the name of
that end is only guaranteed within the scope of the association, but not
within the scope of the associated class. For ends that are owned by the
associated class, the name of the end is guaranteed to be unique within
that class, that is why the ambiguity problem does not exist in that case.
We need something to disambiguate the end's name in the first case, for
example by inserting the association's name into the OCL statement as an
additional step, as in:
self.<assoc-name>.<far-end-name>
where the context is the class associated at the near end.
If we do it like that, I think the mechanism for inverse
cross-referencing you mentioned could be used to traverse from self to
the association, and then the existing traversal mechanism would be used
to do the second traversal step, i.e. to the associated class at the far
end, since the far end which is owned by the association now is a simple
pointer in the direction of traversal.
Do you see any obstacles with this ?
Andy
Christian W. Damus wrote:
> Hi, Andy,
>
> You are correct, currently the OCL parser does not support the
> navigation of non-navigable association ends.
>
> However, you can extend the Environment implementation for UML
> (UMLEnvironment) to provide the non-navigable end when the parser looks
> up a property name (using the Environment::lookupProperty method), even
> using the implied name for unnamed ends. A corresponding extension of
> the UMLEvaluationEnvironment would implement the navigation in the
> EvaluationEnvironment::navigateProperty method). Probably EMF's inverse
> cross-referencing capabilities (CrossReferencer, ECrossReferenceAdapter)
> would be useful here.
>
> Actually, this really ought to be done right in the OCL component's
> Ecore and UML environments. Perhaps you could raise an enhancement
> request? This would be a good contribution :-)
>
> HTH,
>
> Christian
>
>
> Andreas Maier wrote:
>
>> Hi,
>> in the UML profile for CIM, we map CIM associations to UML association
>> classes that own their ends. (Note: I do understand and appreciate the
>> change in UML 2.1 that started distinguishing between navigability and
>> ownership of the ends).
>
>> The reason we decided to map it this way is naming ambiguity in CIM.
>> In CIM, the ends are always owned by the association classes, and so
>> quite naturally, over time, the CIM schema (i.e. the standard user
>> model) evolved such that naming conflicts would prevent the ends from
>> being owned by the associated classes, in many cases.
>
>> In UML user models using this CIM profile, we want to be able to write
>> OCL statements that traverse such UML association classes. However, it
>> seems to me that current OCL only allows to do such traversal from
>> within the context of an associated class if that class owns the end,
>> but not if the association class (or association) owns that end.
>
>> 1. Can you please confirm that this understanding is correct ?
>
>> 2. If so, given the fact that in CIM, the association classes have to
>> own the ends, this essentially prevents us from doing _any_
>> association traversal in CIM user models.
>
>> 3. If so, can we get an extension in OCL that allows us to do
>> association traversal even when the ends are owned by the association
>> (class) ?
>
>> One idea on how to address the above mentioned naming ambiguity in
>> such an extension would be to code the traversal in two steps in OCL:
>> First traverse to the association, then to the far end. Alternatively,
>> an OCL operation could be provided that performs the traversal and
>> gets the right scoping arguments to avoid the ambiguity, such as the
>> association class name, or role names of the ends.
>
>> Andy
>
|
|
|
| Re: Traversing associations that own their ends in OCL [message #11236 is a reply to message #9713] |
Thu, 08 March 2007 00:15 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Andy,
That is how the navigation of non-navigable ends works in OCL. The
assumption is that the end name would be unambiguous despite not being in
the namespace of the classifier at that end. This normally isn't a
problem, but the OCL provides no means to disambiguate the reference in
case of a name clash. The OCL also prescribes a means of addressing a
non-navigable end that has no name, by using the name of the classifier at
the other end with an initial lower-case letter.
Association-class navigation should work (at least in parsing) already.
The association class is navigated by the same convention of using its
name with the initial letter lower-cased. Note that the UML support for
OCL (in 1.1 M5) supports this association-class navigation at run-time
only on object models in the UML model (represented using
InstanceSpecifications). It will not work with UML- or EMF-generated
code, as EMF does not have association classes.
Have a look at the AssociationClassTest test case in the
org.eclipse.ocl.uml.test plug-in for examples of the kinds of
association-class navigation expressions that are supported, including
navigation qualified by association end role.
HTH,
Christian
Andreas Maier wrote:
> Christian,
> this is very good information. Thanks much!
> However, as I understand it, the proposal basically makes an end owned
> by the association appear as if it were a (virtual?) member of the
> associated class. Simply using such a virtual member creates an
> ambiguity problem (potentially), since the uniqueness of the name of
> that end is only guaranteed within the scope of the association, but not
> within the scope of the associated class. For ends that are owned by the
> associated class, the name of the end is guaranteed to be unique within
> that class, that is why the ambiguity problem does not exist in that case.
> We need something to disambiguate the end's name in the first case, for
> example by inserting the association's name into the OCL statement as an
> additional step, as in:
> self.<assoc-name>.<far-end-name>
> where the context is the class associated at the near end.
> If we do it like that, I think the mechanism for inverse
> cross-referencing you mentioned could be used to traverse from self to
> the association, and then the existing traversal mechanism would be used
> to do the second traversal step, i.e. to the associated class at the far
> end, since the far end which is owned by the association now is a simple
> pointer in the direction of traversal.
> Do you see any obstacles with this ?
> Andy
<snip>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:02:27 GMT 2024
Powered by FUDForum. Page generated in 0.03425 seconds |
] 
Search
Help
Register
Login
Home
