Home » Modeling » OCL » transitive closure
| transitive closure [message #33983] |
Wed, 25 July 2007 08:52  |
Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------060208070001040402050706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
--------------060208070001040402050706
Content-Type: text/xml;
name="classes.ecore"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="classes.ecore"
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="classes"
nsURI="www.unibw.de/inf2/classes" nsPrefix="">
<eClassifiers xsi:type="ecore:EClass" name="Class">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="generalization" upperBound="-1"
eType="#//Generalization" eOpposite="#//Generalization/child"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="specialization" upperBound="-1"
eType="#//Generalization" eOpposite="#//Generalization/parent"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="parents" upperBound="-1"
eType="#//Class" changeable="false" volatile="true" transient="true" derived="true">
<eAnnotations source="http://www.eclipse.org/ocl/examples/OCL">
<details key="derive" value="self.generalization->collect(gen|gen.parent)"/>
</eAnnotations>
</eStructuralFeatures>
<eStructuralFeatures xsi:type="ecore:EReference" name="allParents" upperBound="-1"
eType="#//Class" changeable="false" volatile="true" transient="true" derived="true">
<eAnnotations source="http://www.eclipse.org/ocl/examples/OCL">
<details key="derive" value="self.parents->union(self.parents->collect(ge|ge.allParents)) "/>
</eAnnotations>
</eStructuralFeatures>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Generalization">
<eStructuralFeatures xsi:type="ecore:EReference" name="child" lowerBound="1" eType="#//Class"
eOpposite="#//Class/generalization"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="parent" lowerBound="1"
eType="#//Class" eOpposite="#//Class/specialization"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="ClassDiagram">
<eStructuralFeatures xsi:type="ecore:EReference" name="classes" upperBound="-1"
eType="#//Class" containment="true"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="generalizations" upperBound="-1"
eType="#//Generalization" containment="true"/>
</eClassifiers>
</ecore:EPackage>
--------------060208070001040402050706--
|
|
|
| Re: transitive closure [message #34029 is a reply to message #33983] |
Wed, 25 July 2007 10: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 11:42 |
| Eclipse User |
|
|
|
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 08:39 |
| Eclipse User |
|
|
|
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 09: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 10:20 |
| Eclipse User |
|
|
|
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 May 20 13:33:25 EDT 2025
Powered by FUDForum. Page generated in 0.03964 seconds |
Home