Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Navigating from Interface to typed ports.
Navigating from Interface to typed ports. [message #25516] Tue, 29 May 2007 15:01 Go to next message
Juan Pedro Silva is currently offline Juan Pedro SilvaFriend
Messages: 258
Registered: July 2009
Senior Member
Hi everybody.
I'm quite new in the newsgroup, and I haven't written so far because I
was able to find all my answers within you (very interesting) ports so
far. However, I am facing one issue I couldn't deal with or find the
answer until now.

The issue is the following: for a Stereotype constraint on a stereotype
applicable to the "Interface" class, I have to get to the typed Port to
check its applied stereotypes.

According to the OCL spec, I can't: this is a non-navigable association
with no rolename and an ambiguous type name (Interface has provided and
required associations to Port, so you couldn't tell which ones to get by
just saying "port").

I also wasn't able to find within the Eclipse API a method such as
"getAllTypedPorts()" or similar that would allow me to get those ports
(I'm particularly interested in the ones the interface provides, just in
case). Truth is I wasn't able to find much of use while searching
through the API javadocs.

I would really appreciate any hints/pointers that could help me get
there. I thank you in advance for you replies.
Regards,
Juan Pedro
Re: Navigating from Interface to typed ports. [message #25633 is a reply to message #25516] Tue, 29 May 2007 15:37 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Juan Pedro,

You can define "additional operations" in your OCL environment using either
OCL or Java. Doing it the latter way, you could add a getAllTypedPorts()
operation to the Interface metaclass and implement it using the
Element.getRelationships(EClass) API.

See the Programmer's Guide topic "Customizing the Environment" in the OCL
SDK documentation for an example of how to define a Java-implemented
additional operation in your environment (the example adds a regex-matching
operation to the String class, but the idea works the same).

HTH,

Christian


Juan Pedro Silva wrote:

> Hi everybody.
> I'm quite new in the newsgroup, and I haven't written so far because I
> was able to find all my answers within you (very interesting) ports so
> far. However, I am facing one issue I couldn't deal with or find the
> answer until now.
>
> The issue is the following: for a Stereotype constraint on a stereotype
> applicable to the "Interface" class, I have to get to the typed Port to
> check its applied stereotypes.
>
> According to the OCL spec, I can't: this is a non-navigable association
> with no rolename and an ambiguous type name (Interface has provided and
> required associations to Port, so you couldn't tell which ones to get by
> just saying "port").
>
> I also wasn't able to find within the Eclipse API a method such as
> "getAllTypedPorts()" or similar that would allow me to get those ports
> (I'm particularly interested in the ones the interface provides, just in
> case). Truth is I wasn't able to find much of use while searching
> through the API javadocs.
>
> I would really appreciate any hints/pointers that could help me get
> there. I thank you in advance for you replies.
> Regards,
> Juan Pedro
Re: Navigating from Interface to typed ports. [message #25698 is a reply to message #25633] Tue, 29 May 2007 16:00 Go to previous messageGo to next message
Juan Pedro Silva is currently offline Juan Pedro SilvaFriend
Messages: 258
Registered: July 2009
Senior Member
Thanks Christian for you reply.
From it, I deduce that there isn't any other current means of getting
to the ports from within the interface, am I right?.
I asked again basically because I'm using the IBM's RSA modeling
environment (required by the current project) which I'm not much
interested in extending.
Anyhow, if that is so, I will have to.
Thank you again.
Regards,
Juan Pedro

Christian W. Damus escribió:
> Hi, Juan Pedro,
>
> You can define "additional operations" in your OCL environment using either
> OCL or Java. Doing it the latter way, you could add a getAllTypedPorts()
> operation to the Interface metaclass and implement it using the
> Element.getRelationships(EClass) API.
>
> See the Programmer's Guide topic "Customizing the Environment" in the OCL
> SDK documentation for an example of how to define a Java-implemented
> additional operation in your environment (the example adds a regex-matching
> operation to the String class, but the idea works the same).
>
> HTH,
>
> Christian
>
>
> Juan Pedro Silva wrote:
>
>> Hi everybody.
>> I'm quite new in the newsgroup, and I haven't written so far because I
>> was able to find all my answers within you (very interesting) ports so
>> far. However, I am facing one issue I couldn't deal with or find the
>> answer until now.
>>
>> The issue is the following: for a Stereotype constraint on a stereotype
>> applicable to the "Interface" class, I have to get to the typed Port to
>> check its applied stereotypes.
>>
>> According to the OCL spec, I can't: this is a non-navigable association
>> with no rolename and an ambiguous type name (Interface has provided and
>> required associations to Port, so you couldn't tell which ones to get by
>> just saying "port").
>>
>> I also wasn't able to find within the Eclipse API a method such as
>> "getAllTypedPorts()" or similar that would allow me to get those ports
>> (I'm particularly interested in the ones the interface provides, just in
>> case). Truth is I wasn't able to find much of use while searching
>> through the API javadocs.
>>
>> I would really appreciate any hints/pointers that could help me get
>> there. I thank you in advance for you replies.
>> Regards,
>> Juan Pedro
>
Re: Navigating from Interface to typed ports. [message #25724 is a reply to message #25698] Tue, 29 May 2007 16:34 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Juan Pedro,

You are correct: given that the UML metamodel does not specify names for
these non-navigable association ends and the class name is ambiguous, it's
basically hobbled as far as defining OCL expressions is concerned.

This would be a good issue to raise with the OMG if it hasn't been raised
already: all of the association ends in the UML Metamodel should be named.

BTW, if I'm not mistaken, RSA is based on MDT OCL 1.0.x and implements UML
support in a completely different way than MDT OCL 1.1. The directions in
the 1.1 programmer's guide for extending the environment should map fairly
obviously to the 1.0 API.

Cheers,

Christian


Juan Pedro Silva wrote:

> Thanks Christian for you reply.
> From it, I deduce that there isn't any other current means of getting
> to the ports from within the interface, am I right?.
> I asked again basically because I'm using the IBM's RSA modeling
> environment (required by the current project) which I'm not much
> interested in extending.
> Anyhow, if that is so, I will have to.
> Thank you again.
> Regards,
> Juan Pedro
>
> Christian W. Damus escribió:
>> Hi, Juan Pedro,
>>
>> You can define "additional operations" in your OCL environment using
>> either
>> OCL or Java. Doing it the latter way, you could add a getAllTypedPorts()
>> operation to the Interface metaclass and implement it using the
>> Element.getRelationships(EClass) API.
>>
>> See the Programmer's Guide topic "Customizing the Environment" in the OCL
>> SDK documentation for an example of how to define a Java-implemented
>> additional operation in your environment (the example adds a
>> regex-matching operation to the String class, but the idea works the
>> same).
>>
>> HTH,
>>
>> Christian
>>
>>
>> Juan Pedro Silva wrote:
>>
>>> Hi everybody.
>>> I'm quite new in the newsgroup, and I haven't written so far because I
>>> was able to find all my answers within you (very interesting) ports so
>>> far. However, I am facing one issue I couldn't deal with or find the
>>> answer until now.
>>>
>>> The issue is the following: for a Stereotype constraint on a stereotype
>>> applicable to the "Interface" class, I have to get to the typed Port to
>>> check its applied stereotypes.
>>>
>>> According to the OCL spec, I can't: this is a non-navigable association
>>> with no rolename and an ambiguous type name (Interface has provided and
>>> required associations to Port, so you couldn't tell which ones to get by
>>> just saying "port").
>>>
>>> I also wasn't able to find within the Eclipse API a method such as
>>> "getAllTypedPorts()" or similar that would allow me to get those ports
>>> (I'm particularly interested in the ones the interface provides, just in
>>> case). Truth is I wasn't able to find much of use while searching
>>> through the API javadocs.
>>>
>>> I would really appreciate any hints/pointers that could help me get
>>> there. I thank you in advance for you replies.
>>> Regards,
>>> Juan Pedro
>>
Re: Navigating from Interface to typed ports. [message #25840 is a reply to message #25724] Wed, 30 May 2007 10:45 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: firstname.name.gmail.com

In the last post, on 05/29 about 06h, "Christian" (Christian W Damus) wrote:

Christian> You are correct: given that the UML metamodel does not specify
Christian> names for these non-navigable association ends and the class
Christian> name is ambiguous,

Hello,

I was facing with same problem and asked to OMG people. Their answer was that
OCL allows "navigating non-navigable associations". According to UML
specification (2007-02-03) page 655, association end (to the non-navigable
stereotype) should named as extension_stereotypeName

--
F. Lagarde
Re: Navigating from Interface to typed ports. [message #25881 is a reply to message #25840] Wed, 30 May 2007 16:21 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, François,

Right, that is the case for stereotypes and is the
extension_<stereotypeName> is the recommended default name for an
ExtensionEnd. I'm not sure, though, whether this should be considered as
the implicit name if the ExtensionEnd name is null, or whether the spec
requires that this be explicitly set as the name.

If this name is supposed to be implicit, then feel free to raise a feature
request against MDT OCL to recognize this implicit name for extension ends.

While you're at it, you might raise a request also for MDT OCL to recognize
the OCL-specified default name for unnamed association ends (using the
classifier name with the initial lower case). This is not currently
implemented.

Cheers,

Christian


François Lagarde wrote:

> In the last post, on 05/29 about 06h, "Christian" (Christian W Damus)
> wrote:
>
> Christian> You are correct: given that the UML metamodel does not
> specify Christian> names for these non-navigable association ends
> and the class Christian> name is ambiguous,
>
> Hello,
>
> I was facing with same problem and asked to OMG people. Their answer was
> that OCL allows "navigating non-navigable associations". According to UML
> specification (2007-02-03) page 655, association end (to the
> non-navigable stereotype) should named as extension_stereotypeName
>
> --
> F. Lagarde
Previous Topic:Re: ocl constraint on an enumeration
Next Topic:[Announce] MDT OCL 1.1.0 1.1RC2 is available
Goto Forum:
  


Current Time: Thu Mar 28 16:17:02 GMT 2024

Powered by FUDForum. Page generated in 0.02993 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top