Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » ENUMERATION Literal and OCL
ENUMERATION Literal and OCL [message #43925] Thu, 22 November 2007 04:25 Go to next message
Eclipse UserFriend
Originally posted by: asma.charfi.com

hello,
I have defined an Enumeration DirectionKind in a profile P
literals are inout and out.
DirectionKind is used as the type of a property caled direction in a
stereotype Port in the same profile.
In an OCL constraint with context Port, I would like to access the name of
the enumeration literal currently set in property direction. I want to
compare it against a string.

I tried as it was explained in How to access name of EnumerationLiteral
17/03/2007:

let array : Set(Tuple(s : String, d : P::DirectionKind)) = Set{Tuple{s =
'inout', d =P::DirectionKind::inout },Tuple{s = 'out', d
=P::DirectionKind::out}} in
array->exist(t|t.s='out' and
t.p=self.getValue(self.getAppliedStereotype('P::Port'),'dire ction'))

but I get this error message: 2:16:2:16 "::" expected instead of "|"

what is the problem?

thank you
Re: ENUMERATION Literal and OCL [message #44093 is a reply to message #43925] Wed, 21 November 2007 22:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Asma,

It looks like the problem is the missing "s" in the "exists" iterator.
Without that, the OCL parser thinks that "array->exist(...)" is an
operation call, and operation calls don't have "|" in them as iterator
expressions do.

Of course, the error message isn't exactly clear on this point ;-)

cW

charfi asma wrote:

> hello,
> I have defined an Enumeration DirectionKind in a profile P
> literals are inout and out.
> DirectionKind is used as the type of a property caled direction in a
> stereotype Port in the same profile.
> In an OCL constraint with context Port, I would like to access the name of
> the enumeration literal currently set in property direction. I want to
> compare it against a string.
>
> I tried as it was explained in How to access name of EnumerationLiteral
> 17/03/2007:
>
> let array : Set(Tuple(s : String, d : P::DirectionKind)) = Set{Tuple{s =
> 'inout', d =P::DirectionKind::inout },Tuple{s = 'out', d
> =P::DirectionKind::out}} in
> array->exist(t|t.s='out' and
> t.p=self.getValue(self.getAppliedStereotype('P::Port'),'dire ction'))
>
> but I get this error message: 2:16:2:16 "::" expected instead of "|"
>
> what is the problem?
>
> thank you
Re: ENUMERATION Literal and OCL [message #44151 is a reply to message #44093] Thu, 22 November 2007 08:05 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: asma.charfi.com

Hi,
You were right! but this expression always return false (after adding the
missing s)
in fact, when I parse
self.getValue(self.getAppliedStereotype('P::Port'),'directio n') alone, it
returns Enumeration Literal out
and when I parse P::DirectionKind::out alone, it returns EEnum Literal out
so it returns always false cause EEnum <> Enumeration
how can I do to get only one?
thanks

"Christian W. Damus" <cdamus@ca.ibm.com> a
Re: ENUMERATION Literal and OCL [message #44275 is a reply to message #44151] Thu, 22 November 2007 14:32 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Right, the UML2 API is a little inconsistent in this respect. For access to
enumeration properties, it returns EnumerationLiterals (the models for
enumeration values) but for string properties, for example, it returns
Strings instead of LiteralStrings (which would be the models for string
values).

Try this, instead:

self.extension_Port->any().direction

to get the direction property of the stereotype application. Remember that
metaclass extensions are just associations, which OCL can navigate in
reverse, and stereotypes are classes just like metaclasses. So, in fact,
your whole expression would be:

let array : Set(Tuple(s : String, d : P::DirectionKind)) =
Set{Tuple{s = 'inout', d = P::DirectionKind::inout},
Tuple{s = 'out', d = P::DirectionKind::out}} in
self.extension_Port->notEmpty() and
array->exists(t | t.s = 'out' and t.p = self.extension_Port.direction)

HTH,

Christian

charfi asma wrote:

> Hi,
> You were right! but this expression always return false (after adding the
> missing s)
> in fact, when I parse
> self.getValue(self.getAppliedStereotype('P::Port'),'directio n') alone, it
> returns Enumeration Literal out
> and when I parse P::DirectionKind::out alone, it returns EEnum Literal
> out so it returns always false cause EEnum <> Enumeration
> how can I do to get only one?
> thanks

-----8<-----
Re: ENUMERATION Literal and OCL [message #44430 is a reply to message #44275] Fri, 23 November 2007 01:25 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: asma.charfi.com

hi,

My stereotype derivate from another colled P1, so I have not extension
called extension_P nor extension_P1
In the profile (exported from MagicDraw) I get this extension:
<Extension> A_extension__base_Port
<Extension End> extension_: P
I aloso wse M2 and Ecore in the console so I have not propoerty colled
extension_P applied to the port stereotyped P.

can you help me?

"Christian W. Damus" <cdamus@ca.ibm.com> a
Re: ENUMERATION Literal and OCL [message #44491 is a reply to message #44430] Thu, 22 November 2007 17:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Asma,

I assumed the UML's convention for naming extension ends, which is

extension_<stereotype-name>

The problem with the "extension_" name supplied by MagicDraw is that it will
not be unique. For any metaclass that is extended by more that one
stereotype (from one or more profiles), the name "extension_" will be
ambiguous because OCL won't know which stereotype's extension end to
choose.

If you can possibly rename the extension end as "extension_P" (assuming your
stereotype name is "P"), I would recommend doing that.

Navigating non-navigable association ends is a capability implemented by the
UML binding only, because Ecore doesn't have associations. So, in the
console, you should use M2 and UML instead of Ecore.

If you can't rename the extension end, then you can probably still use
UML2's non-standard API for stereotypes like this:

let array : Set(Tuple(s : String, d : P::DirectionKind)) =
Set{Tuple{s = 'inout', d = P::DirectionKind::inout},
Tuple{s = 'out', d = P::DirectionKind::out}} in
let stereo : Stereotype = self.getAppliedStereotype('P::Port') in
not stereo.oclIsUndefined() and
let port : P::Port =
self.getStereotypeApplication(stereo).oclAsType(P::Port) in
array->exists(t | t.s = 'out' and t.p = port.direction)

HTH,

Christian


charfi asma wrote:

> hi,
>
> My stereotype derivate from another colled P1, so I have not extension
> called extension_P nor extension_P1
> In the profile (exported from MagicDraw) I get this extension:
> <Extension> A_extension__base_Port
> <Extension End> extension_: P
> I aloso wse M2 and Ecore in the console so I have not propoerty colled
> extension_P applied to the port stereotyped P.
>
> can you help me?
>
> "Christian W. Damus" <cdamus@ca.ibm.com> a �rit dans le message de news:
> fi43tv$po4$1@build.eclipse.org...
>>
>> Right, the UML2 API is a little inconsistent in this respect. For access
>> to
>> enumeration properties, it returns EnumerationLiterals (the models for
>> enumeration values) but for string properties, for example, it returns
>> Strings instead of LiteralStrings (which would be the models for string
>> values).
>>
>> Try this, instead:
>>
>> self.extension_Port->any().direction
>>
>> to get the direction property of the stereotype application. Remember
>> that
>> metaclass extensions are just associations, which OCL can navigate in
>> reverse, and stereotypes are classes just like metaclasses. So, in fact,
>> your whole expression would be:
>>
>> let array : Set(Tuple(s : String, d : P::DirectionKind)) =
>> Set{Tuple{s = 'inout', d = P::DirectionKind::inout},
>> Tuple{s = 'out', d = P::DirectionKind::out}} in
>> self.extension_Port->notEmpty() and
>> array->exists(t | t.s = 'out' and t.p = self.extension_Port.direction)
>>
>> HTH,
>>
>> Christian

-----8<-----
Re: ENUMERATION Literal and OCL [message #44584 is a reply to message #44491] Sat, 24 November 2007 01:34 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: asma.charfi.com

thank you christian,

I chose now org.eclipse.ocl.uml extension cause it is easier and I can write
shorter constraint: for the same constraint,
I simply put "self.direction=::P::DirectionKind::out"
how can I use only ecore properties or uml properties to write my
constraints (I dont want to use both emf and uml concept)
for example, getappliedStereotype() is an uml property but I find it in
ecore also?
thank you

asma
"Christian W. Damus" <cdamus@ca.ibm.com> a
Re: ENUMERATION Literal and OCL [message #44609 is a reply to message #44584] Fri, 23 November 2007 19:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Asma,

I'm glad this is helping. I think the UML binding is a better fit, anyway.
I thought perhaps you had some other need to use the names (string values)
of the enumeration literals.

I don't understand what you're asking about ecore and uml properties. The
UML environment finds the getAppliedStereotype() operation because it is
defined in the Element Class in UML.metamodel.uml. The Ecore environment
also finds it because it is also defined in the Element EClass in
UML.ecore.

If the problem you're having is that you want to avoid attributes and
operations defined by MDT UML2's metamodel that are not specified by OMG,
then this OCL implementation isn't really in a position to help with that,
yet.

HTH,

Christian

charfi asma wrote:

> thank you christian,
>
> I chose now org.eclipse.ocl.uml extension cause it is easier and I can
> write shorter constraint: for the same constraint,
> I simply put "self.direction=::P::DirectionKind::out"
> how can I use only ecore properties or uml properties to write my
> constraints (I dont want to use both emf and uml concept)
> for example, getappliedStereotype() is an uml property but I find it in
> ecore also?
> thank you
>
> asma

-----8<-----
Re: ENUMERATION Literal and OCL [message #44703 is a reply to message #44609] Mon, 26 November 2007 11:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: asma.charfi.com

HI,
thank you Christian!

I find the method getAppliedStereotype() in the Element interface (Method in
interface org.eclipse.uml2.uml.Element)
but in the interface Eclass org.eclipse.emf.ecore I did not fint it.
Is there a document that gives all method to write ocl expressions using
org.eclipse.ocl.uml ?
and another that gives all method to write ocl expression using only
org.eclipse.ocl.ecore ?
(in fact, my boss tell me "you mixed ecore and uml operations, you should
write constraints using one of them and not both")
for example, this constraint self.ownedAttribute-> select (s|
s.eClass().name='Property')->isEmpty
uses ownedAttribut which come from UML and eClass() which comes from Ecore.
He want that I rewrite this constraint using only methods coming from ecore.
is this possible?

thank you very much

"Christian W. Damus" <cdamus@ca.ibm.com> a
Re: ENUMERATION Literal and OCL [message #44759 is a reply to message #44703] Mon, 26 November 2007 15:25 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Asma,

See some replies in-line, below.

Cheers,

Christian


charfi asma wrote:

> HI,
> thank you Christian!
>
> I find the method getAppliedStereotype() in the Element interface (Method
> in interface org.eclipse.uml2.uml.Element)
> but in the interface Eclass org.eclipse.emf.ecore I did not fint it.

Of course getAppliedStereotype() isn't defined by the EClass metaclass.
It's a UML construct. A more appropriate analogue in Ecore for UML's
Element interface would be either EObject or EModelElement, not EClass.


> Is there a document that gives all method to write ocl expressions using
> org.eclipse.ocl.uml ?

I don't understand what you're asking for, here. The UML metamodel (as
expressed in the UML.metamodel.uml resource in the
org.eclipse.uml2.uml.resources plug-in) is the definitive source for what
properties and operations your OCL constraints can use, in UML models.


> and another that gives all method to write ocl expression using only
> org.eclipse.ocl.ecore ?

Likewise the Ecore.ecore resource in the org.eclipse.emf.ecore plug-in.


> (in fact, my boss tell me "you mixed ecore and uml operations, you should
> write constraints using one of them and not both")
> for example, this constraint self.ownedAttribute-> select (s|
> s.eClass().name='Property')->isEmpty
> uses ownedAttribut which come from UML and eClass() which comes from
> Ecore. He want that I rewrite this constraint using only methods coming
> from ecore. is this possible?

I would not expect this to work, as UML2's representation of the Ecore
metamodel (Ecore.metamodel.uml), which its UML metamodel references,
defines the eClass() operation as a non-query (potentially having
side-effects). This means that it is not valid for an OCL expression to
call eClass(). Try this, instead:

self.ownedAttribute->select(s | s.oclIsTypeOf(Property))->isEmpty()

for a "pure UML" solution to select those owned attributes that are exactly
of the Property metaclass and not some specialization such as Port or
ExtensionEnd.

It is important to note, also, that the UML metamodel as implemented by the
MDT UML2 component *extends* the Ecore metamodel, so some capabilities that
you might consider as being "ecore" are, in fact, "uml" capabilities also.
For example, because the Element metaclass from UML2 extends EModelElement,
it can have EAnnotations. However, all of the EOperations inherited by
Element from EObject (via EModelElement) are represented as non-queries, so
they are not available.

-----8<-----
Re: ENUMERATION Literal and OCL [message #44812 is a reply to message #44759] Tue, 27 November 2007 02:20 Go to previous message
Eclipse UserFriend
Originally posted by: asma.charfi.com

thank u Christian :-)

but the constraint "self.ownedAttribute-> select
(s|s.eClass().name='Property')->isEmpty()" works perfectly. when I chose M2
and Ecore in the console's action bar, but of course it did not works when I
put UML instead;

asma

"Christian W. Damus" <cdamus@ca.ibm.com> a
Re: ENUMERATION Literal and OCL [message #44843 is a reply to message #44812] Mon, 26 November 2007 18:00 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Asma,

Ah! Right. Of course. I'm always assuming too much :-)

This works with the Ecore environment because Ecore doesn't have the concept
of "query operation", so it permits access to any EOperation, even though
it may have side-effects.

cW

charfi asma wrote:

>
>
> thank u Christian :-)
>
> but the constraint "self.ownedAttribute-> select
> (s|s.eClass().name='Property')->isEmpty()" works perfectly. when I chose
> M2 and Ecore in the console's action bar, but of course it did not works
> when I put UML instead;
>
> asma
Previous Topic:Invalid vs. OCLInvalid
Next Topic:Re: [OCL Tools] downloads?
Goto Forum:
  


Current Time: Fri Mar 29 08:27:12 GMT 2024

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

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

Back to the top