Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » OCL Query with Stereotype as context
OCL Query with Stereotype as context [message #29416] Fri, 22 June 2007 05:53 Go to next message
Eclipse User
Originally posted by: firstname.name.gmail.com

Hello

I would like to use the nice query given by Christian in the thread "Re:
constraint on abstract stereotype" to fetch all inherited constraints.

Since I need to query the parents stereotype, I have to work at the Meta level,
and use the Stereotype metaclass as context (right?). I looked at some examples
(in the test package). My program looks like:

Classifier metaClass = getMetaclass("Stereotype");
oclHelper.setContext(metaClass);
OCLExpression<Classifier> expr=null;
try {
expr = oclHelper.createQuery("the Christian's query..")
}catch (ParserException e1){
...
}
List<?> result = (List<?>) ocl.evaluate(stereotype, expr);

but, I am certainly missing something because I get
[OCL] variableExpCS: Variable Expression: self

If I do not use the self keyword, I have:
org.eclipse.ocl.SemanticException: illegal operation signature: (allParents())

thanks.
--
F. Lagarde
Re: OCL Query with Stereotype as context [message #29525 is a reply to message #29416] Sat, 23 June 2007 02:20 Go to previous messageGo to next message
Eclipse User
Originally posted by: asma.charfi.com

Hi fran
Re: OCL Query with Stereotype as context [message #29555 is a reply to message #29525] Sat, 23 June 2007 08:58 Go to previous messageGo to next message
Eclipse User
Originally posted by: firstname.name.gmail.com

In the last post, on 06/23 about 08h, "charfi" (charfi asma) wrote:

hi,
charfi> I used an Ecore Environement (when defining my ocl)
I certainly missed something, why do we have to use an Ecore environment to
query UML models.

charfi> if you use an UML one you should modify the query
charfi> (self.base_Class.allParents instead of self.allParents (when
charfi> context is the stereotype))
It sounds odd. When the context is the stereotype, self.base_Class is the
stereotyped element. I do not want to gather constraints defined in the
stereotyped element, but the inhereted constraints from the stereotype itself...

charfi> I hope that it help you

I will try it as soon as possible, thanks ;-).

by the way, do you know why we cannot access to the "extension_MyStereotype" in
the interactive console. I mean, i am in the context of a stereotyped element,
at M2 level, and I query something like:

"self." completion, I expected to find extension_MyStereotype


--
F. Lagarde
Re: OCL Query with Stereotype as context [message #29582 is a reply to message #29555] Sat, 23 June 2007 19:14 Go to previous messageGo to next message
Eclipse User
Originally posted by: asma.charfi.com

Hi fran
Re: OCL Query with Stereotype as context [message #30045 is a reply to message #29416] Mon, 25 June 2007 12:20 Go to previous messageGo to next message
Eclipse User
Originally posted by: firstname.name.gmail.com

In the last post, on 06/22 about 11h, "François" (François Lagarde) wrote:

François> but, I am certainly missing something because I get [OCL]
François> variableExpCS: Variable Expression: self

Ok, I was wrong. I used the stereotype as context. Now I can successfully parse
my constraint (with the self.allParents()).

But I have a something strange. My OpaqueExpression is not evaluated as an
OpaqueExpression. I have the same behavior with the interactive OCL console.

I select my constraint, and do the following queries:

Evaluating:
self.name
Results:
MySpecialConstraint

Evaluating:
self.specification
Results:
Opaque Expression SpecialExpression

Evaluating:
self.specification.oclIsKindOf(OpaqueExpression)
Results:
false


--
F. Lagarde
Re: OCL Query with Stereotype as context [message #30182 is a reply to message #30045] Mon, 25 June 2007 16:38 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, François,

This is a bug in the UML environment implementation. The
UMLEvaluationEnvironment::isKindOf(...) method sees the OpaqueExpression as
a kind of ValueSpecification, and so handles it differently than it does
other metaclasses. It does this to support object models, for evaluation
of OCL expressions on InstanceSpecifications, which model the values of
properties as ValueSpecifications owned by Slots.

In evaluating

self.specification.oclIsKindOf(OpaqueExpression)

the interpreter is actually testing that the specification's type conforms
to OpaqueExpression. Naturally, your OCL expression is not going to
compute an OpaqueExpression as its value.

The special handling of ValueSpecifications should only be applied when the
ValueSpecification is the value of a Slot (more specifically, when we are
evaluating M1 expressions on object models). Would you mind raising a bug
for that?

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=MDT& version=1.1.0&component=OCL

Cheers,

Christian


François Lagarde wrote:

> In the last post, on 06/22 about 11h, "François" (François Lagarde) wrote:
>
> François> but, I am certainly missing something because I get [OCL]
> François> variableExpCS: Variable Expression: self
>
> Ok, I was wrong. I used the stereotype as context. Now I can successfully
> parse my constraint (with the self.allParents()).
>
> But I have a something strange. My OpaqueExpression is not evaluated as an
> OpaqueExpression. I have the same behavior with the interactive OCL
> console.
>
> I select my constraint, and do the following queries:
>
> Evaluating:
> self.name
> Results:
> MySpecialConstraint
>
> Evaluating:
> self.specification
> Results:
> Opaque Expression SpecialExpression
>
> Evaluating:
> self.specification.oclIsKindOf(OpaqueExpression)
> Results:
> false
>
>
Re: OCL Query with Stereotype as context [message #30250 is a reply to message #29582] Mon, 25 June 2007 16:48 Go to previous message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Asma, François,

Actually, self.base_Class always refers to the Class element to which the
stereotype is applied. In the context of the Stereotype, self.allParents()
gets all of the stereotype's general classifiers. Note that profiles and
stereotypes are metamodeling extensions, so OCL constraints in this context
are metamodel (M2) constraints (constraining the well-formedness of UML
models) rather than model (M1) constraints (constraining the
well-formedness of the modeled system).

The reason why the content-assist does not suggest the
extension_MyStereotype end is that it is not a property of the type of the
sub-expression before the ".". Providing non-navigable association ends as
content-assist suggestions would probably be a valuable enhancement; feel
free to raise a feature request in Bugzilla.

Prior to the 1.1 M7/RC0 build, the console example used only an Ecore
environment. However, in that build, it was considerably enhanced to
support both Ecore and UML environments, particularly for the purpose of
testing M1-level OCL constraints in the UML environment. Have a look at
the accompanying updates to the Examples Guide for details.

Cheers,

Christian


charfi asma wrote:

> Hi fran�is,
>
> "It sounds odd. When the context is the stereotype, self.base_Class is the
> stereotyped element. I do not want to gather constraints defined in the
> stereotyped element, but the inhereted constraints from the stereotype
> itself..."
>
> when you click,you do it on your model not the stereotype ,so
> self.base_class will refer to stereotype and not to the model
> and self.base_Class.allparents() will returns the stereotypes parents of
> course.
>
> "by the way, do you know why we cannot access to the
> "extension_MyStereotype" in
>> the interactive console. I mean, i am in the context of a stereotyped
>> element,
>> at M2 level, and I query something like:"
>
> The interactive console (the interpreter example) use an ecore
> environnement (I saw it in the code).
> However, using the UML environment, you can use OCL's ability to navigate
> non-navigable association ends (a metaclass Extension is an Association):
> (self.extension_mystereotype)
>
> This is what I think (hope it 's helpfull for you)
> asma
> ""Fran�is" Lagarde" <firstname.name@gmail.com> a �rit dans le message de
> news: 874pkyygi5.fsf@is003308.saclay.cea.fr...
>> In the last post, on 06/23 about 08h, "charfi" (charfi asma) wrote:
>>
>> hi,
>> charfi> I used an Ecore Environement (when defining my ocl)
>> I certainly missed something, why do we have to use an Ecore environment
>> to
>> query UML models.
>>
>> charfi> if you use an UML one you should modify the query
>> charfi> (self.base_Class.allParents instead of self.allParents
>> (when charfi> context is the stereotype))
>> It sounds odd. When the context is the stereotype, self.base_Class is the
>> stereotyped element. I do not want to gather constraints defined in the
>> stereotyped element, but the inhereted constraints from the stereotype
>> itself...
>>
>> charfi> I hope that it help you
>>
>> I will try it as soon as possible, thanks ;-).
>>
>> by the way, do you know why we cannot access to the
>> "extension_MyStereotype" in
>> the interactive console. I mean, i am in the context of a stereotyped
>> element,
>> at M2 level, and I query something like:
>>
>> "self." completion, I expected to find extension_MyStereotype
>>
>>
>> --
>> F. Lagarde
Previous Topic:OCL expression
Next Topic:OCL Interpreter Example
Goto Forum:
  


Current Time: Thu Apr 24 06:20:43 EDT 2014

Powered by FUDForum. Page generated in 0.19372 seconds