Home » Modeling » OCL » transitive closure
|
| Re: transitive closure [message #34029 is a reply to message #33983] |
Wed, 25 July 2007 14:01   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Steffen,
"Invalid Class" is the console example's clumsy way of displaying the
OclInvalid token, which signals an error in the evaluation of the OCL
expression (often an attempt to call some feature of a null value).
In the case allParents, I would expect to see this only when either
- a generalization has a null parent, so that parents includes
a null value
- there is a generalization cycle resulting in infinite recursion
and, consequently, stack overflow (though, that is an Error in
Java, so it would not be caught by OCL and signalled by an
OclInvalid)
To locate the problem, turn on evaluation tracing: in your launch config,
select "debug/evaluation" in the org.eclipse.ocl tracing options. The
console will print the value of every sub-expression as it is evaluated,
and you will see where the OclInvalid creeps in.
You may be interested to know that MDT OCL provides a non-standard "closure"
iterator expression for just this kind of scenario, which avoids the
circularity problem:
allParents = self->closure(parents)
Cheers,
Christian
Steffen Mazanek wrote:
> Hello,
>
> I have defined a classdiagram metamodel with just classes and
> generalizations between classes (ecore attached). Now I want to
> use ocl to derive the set of all superclasses.
>
> Therefore I have defined two derived references in the context Class:
> parents=self.generalization->collect(gen| gen.parent)
> allParents=self.parents->union(self.parents->collect(ge|ge.allParents))
>
> I have generated code as described in "Implementing Model Integrity in
> EMF with MDT OCL". No problems so far. However, in the OCL console of
> the runtime workbench I got "Invalid Class" as a result when calling
> allParents. In contrast, parents worked nice.
>
> How could I locate the problem? Or is the problem related to transitive
> closure in general?
>
> Best regards,
>
> Steffen
|
|
|
| Re: transitive closure [message #34063 is a reply to message #34029] |
Wed, 25 July 2007 15:42 |
 Steffen Mazanek
Messages: 40
Registered: July 2009 |
Member |
|
|
Thank you, Christian! I'll try this immediately.
Christian W. Damus wrote:
> Hi, Steffen,
>
> "Invalid Class" is the console example's clumsy way of displaying the
> OclInvalid token, which signals an error in the evaluation of the OCL
> expression (often an attempt to call some feature of a null value).
>
> In the case allParents, I would expect to see this only when either
> - a generalization has a null parent, so that parents includes
> a null value
> - there is a generalization cycle resulting in infinite recursion
> and, consequently, stack overflow (though, that is an Error in
> Java, so it would not be caught by OCL and signalled by an
> OclInvalid)
>
> To locate the problem, turn on evaluation tracing: in your launch config,
> select "debug/evaluation" in the org.eclipse.ocl tracing options. The
> console will print the value of every sub-expression as it is evaluated,
> and you will see where the OclInvalid creeps in.
>
> You may be interested to know that MDT OCL provides a non-standard "closure"
> iterator expression for just this kind of scenario, which avoids the
> circularity problem:
>
> allParents = self->closure(parents)
>
> Cheers,
>
> Christian
>
>
> Steffen Mazanek wrote:
>
>> Hello,
>>
>> I have defined a classdiagram metamodel with just classes and
>> generalizations between classes (ecore attached). Now I want to
>> use ocl to derive the set of all superclasses.
>>
>> Therefore I have defined two derived references in the context Class:
>> parents=self.generalization->collect(gen| gen.parent)
>> allParents=self.parents->union(self.parents->collect(ge|ge.allParents))
>>
>> I have generated code as described in "Implementing Model Integrity in
>> EMF with MDT OCL". No problems so far. However, in the OCL console of
>> the runtime workbench I got "Invalid Class" as a result when calling
>> allParents. In contrast, parents worked nice.
>>
>> How could I locate the problem? Or is the problem related to transitive
>> closure in general?
>>
>> Best regards,
>>
>> Steffen
>
|
|
|
| Re: transitive closure [message #34164 is a reply to message #34029] |
Thu, 26 July 2007 12:39 |
Steffen Mazanek
Messages: 40
Registered: July 2009 |
Member |
|
|
I just wanted to try the closure operator to get all super-classes of a
class in an emf model. I know that there is already a derived
eAllSupertypes thing, however, why do I get
illegal operation signature: (closure(OrderedSet(EClass)))
in the ocl console when calling
closure(eSuperTypes)
You told me how to debug the console in the runtime workbench, however,
I do not know how to switch debugging on when just checking an emf model
without a runtime workbench.
Best regards,
Steffen
Christian W. Damus schrieb:
> Hi, Steffen,
>
> "Invalid Class" is the console example's clumsy way of displaying the
> OclInvalid token, which signals an error in the evaluation of the OCL
> expression (often an attempt to call some feature of a null value).
>
> In the case allParents, I would expect to see this only when either
> - a generalization has a null parent, so that parents includes
> a null value
> - there is a generalization cycle resulting in infinite recursion
> and, consequently, stack overflow (though, that is an Error in
> Java, so it would not be caught by OCL and signalled by an
> OclInvalid)
>
> To locate the problem, turn on evaluation tracing: in your launch config,
> select "debug/evaluation" in the org.eclipse.ocl tracing options. The
> console will print the value of every sub-expression as it is evaluated,
> and you will see where the OclInvalid creeps in.
>
> You may be interested to know that MDT OCL provides a non-standard "closure"
> iterator expression for just this kind of scenario, which avoids the
> circularity problem:
>
> allParents = self->closure(parents)
>
> Cheers,
>
> Christian
>
>
> Steffen Mazanek wrote:
>
>> Hello,
>>
>> I have defined a classdiagram metamodel with just classes and
>> generalizations between classes (ecore attached). Now I want to
>> use ocl to derive the set of all superclasses.
>>
>> Therefore I have defined two derived references in the context Class:
>> parents=self.generalization->collect(gen| gen.parent)
>> allParents=self.parents->union(self.parents->collect(ge|ge.allParents))
>>
>> I have generated code as described in "Implementing Model Integrity in
>> EMF with MDT OCL". No problems so far. However, in the OCL console of
>> the runtime workbench I got "Invalid Class" as a result when calling
>> allParents. In contrast, parents worked nice.
>>
>> How could I locate the problem? Or is the problem related to transitive
>> closure in general?
>>
>> Best regards,
>>
>> Steffen
>
|
|
|
| Re: transitive closure [message #34191 is a reply to message #34164] |
Thu, 26 July 2007 13:08 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Steffen,
MDT OCL's "closure" is an iterator. Just doing
closure(eSuperTypes)
is equivalent syntax to
self.closure(eSuperTypes)
which looks to the parser like an operation call. You need to do
self->closure(eSuperTypes)
using the "->" operator to indicate the iterator.
For tracing without the run-time workbench, the org.eclipse.ocl.OCL class
has flags:
setParseTracingEnabled(boolean)
setEvaluationTracingEnabled(boolean)
HTH,
Christian
Steffen Mazanek wrote:
> I just wanted to try the closure operator to get all super-classes of a
> class in an emf model. I know that there is already a derived
> eAllSupertypes thing, however, why do I get
>
> illegal operation signature: (closure(OrderedSet(EClass)))
>
> in the ocl console when calling
>
> closure(eSuperTypes)
>
> You told me how to debug the console in the runtime workbench, however,
> I do not know how to switch debugging on when just checking an emf model
> without a runtime workbench.
>
> Best regards,
> Steffen
>
<snip>
|
|
|
| Re: transitive closure [message #34224 is a reply to message #34191] |
Thu, 26 July 2007 14:20 |
Steffen Mazanek
Messages: 40
Registered: July 2009 |
Member |
|
|
Ah, I see. Thanks a lot.
Christian W. Damus schrieb:
> Hi, Steffen,
>
> MDT OCL's "closure" is an iterator. Just doing
>
> closure(eSuperTypes)
>
> is equivalent syntax to
>
> self.closure(eSuperTypes)
>
> which looks to the parser like an operation call. You need to do
>
> self->closure(eSuperTypes)
>
> using the "->" operator to indicate the iterator.
>
> For tracing without the run-time workbench, the org.eclipse.ocl.OCL class
> has flags:
>
> setParseTracingEnabled(boolean)
> setEvaluationTracingEnabled(boolean)
>
> HTH,
>
> Christian
>
>
>
> Steffen Mazanek wrote:
>
>> I just wanted to try the closure operator to get all super-classes of a
>> class in an emf model. I know that there is already a derived
>> eAllSupertypes thing, however, why do I get
>>
>> illegal operation signature: (closure(OrderedSet(EClass)))
>>
>> in the ocl console when calling
>>
>> closure(eSuperTypes)
>>
>> You told me how to debug the console in the runtime workbench, however,
>> I do not know how to switch debugging on when just checking an emf model
>> without a runtime workbench.
>>
>> Best regards,
>> Steffen
>>
>
> <snip>
|
|
|
Goto Forum:
Current Time: Tue Apr 23 14:18:28 GMT 2024
Powered by FUDForum. Page generated in 0.03645 seconds |
] 
Search
Help
Register
Login
Home
