Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » How to check the types of containment?
How to check the types of containment? [message #485315] Fri, 11 September 2009 10:55 Go to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Hello,
imagine I have class defined (CompositionModel) in my meta model which
has a containment reference (1..*) to an abstract class (AbstractModel).
I have several concrete classes (ModelA, ModelB, ...) inheriting from
that abstract class. Now I want to write an ocl constraint for
CompositionModel expressing that every concrete class can only be
contained once in the CompositionModel class. How can I express this? I
have to count the contained types for every ModelA, ModelB, ... anyway.
Can you help me?

best regards,
Gilbert
Re: How to check the types of containment? [message #485349 is a reply to message #485315] Fri, 11 September 2009 13:22 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-K714bR8dVcNUtJJGi5Ee
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Gilbert,

You can either wait for the MDT OCL release that the excellent new
committer team is working on that will support OCL 2.1 spec with with
the new oclType() operation:

context CompositionModel
inv: containedModel->unique(oclType())

(assuming your containment reference is named "containedModel") or, with
the latest release, you can use set the "implicit root class" parser
option to EObject and do this:

context CompositionModel
inv: containedModel->unique(eClass())

Either way, you are checking that the members of the collection are of
unique classes.

HTH,

Christian


On Fri, 2009-09-11 at 12:55 +0200, Gilbert Mirenque wrote:

> Hello,
> imagine I have class defined (CompositionModel) in my meta model which
> has a containment reference (1..*) to an abstract class (AbstractModel).
> I have several concrete classes (ModelA, ModelB, ...) inheriting from
> that abstract class. Now I want to write an ocl constraint for
> CompositionModel expressing that every concrete class can only be
> contained once in the CompositionModel class. How can I express this? I
> have to count the contained types for every ModelA, ModelB, ... anyway.
> Can you help me?
>
> best regards,
> Gilbert

--=-K714bR8dVcNUtJJGi5Ee
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Gilbert,<BR>
<BR>
You can either wait for the MDT OCL release that the excellent new committer team is working on that will support OCL 2.1 spec with with the new oclType() operation:<BR>
<BR>
&nbsp; context CompositionModel<BR>
&nbsp; inv: containedModel-&gt;unique(oclType())<BR>
<BR>
(assuming your containment reference is named &quot;containedModel&quot;) or, with the latest release, you can use set the &quot;implicit root class&quot; parser option to EObject and do this:<BR>
<BR>
&nbsp; context CompositionModel<BR>
&nbsp; inv: containedModel-&gt;unique(eClass())<BR>
<BR>
Either way, you are checking that the members of the collection are of unique classes.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
&nbsp; <BR>
On Fri, 2009-09-11 at 12:55 +0200, Gilbert Mirenque wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hello,
imagine I have class defined (CompositionModel) in my meta model which
has a containment reference (1..*) to an abstract class (AbstractModel).
I have several concrete classes (ModelA, ModelB, ...) inheriting from
that abstract class. Now I want to write an ocl constraint for
CompositionModel expressing that every concrete class can only be
contained once in the CompositionModel class. How can I express this? I
have to count the contained types for every ModelA, ModelB, ... anyway.
Can you help me?

best regards,
Gilbert
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-K714bR8dVcNUtJJGi5Ee--
Re: How to check the types of containment? [message #485359 is a reply to message #485349] Fri, 11 September 2009 13:41 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Hi Christian,
didn't you mean the containedModel->isUnique(..) method?

> context CompositionModel
> inv: containedModel->unique(eClass())

eClass() is emf specific and not pure ocl spec isn't it?
Re: How to check the types of containment? [message #485360 is a reply to message #485359] Fri, 11 September 2009 13:47 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010706060308010200010008
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Gilbert,

Yes, eClass() is Ecore specific.


Gilbert Mirenque wrote:
> Hi Christian,
> didn't you mean the containedModel->isUnique(..) method?
>
>
>> context CompositionModel
>> inv: containedModel->unique(eClass())
>>
>
> eClass() is emf specific and not pure ocl spec isn't it?
>

--------------010706060308010200010008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Gilbert,<br>
<br>
Yes, eClass() is Ecore specific.  <br>
<br>
<br>
Gilbert Mirenque wrote:
<blockquote cite="mid:h8dk26$f1s$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Christian,
didn't you mean the containedModel-&gt;isUnique(..) method?

</pre>
<blockquote type="cite">
<pre wrap=""> context CompositionModel
inv: containedModel-&gt;unique(eClass())
</pre>
</blockquote>
<pre wrap=""><!---->
eClass() is emf specific and not pure ocl spec isn't it?
</pre>
</blockquote>
</body>
</html>

--------------010706060308010200010008--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: How to check the types of containment? [message #485372 is a reply to message #485359] Fri, 11 September 2009 13:59 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-80CJtH/WYzeQwmY4IgVZ
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Gilbert,

Oops, yes, I did. I always get confused by the fact that this is the
one boolean-valued iterator that uses "is" in the name. Unlike exists,
forAll, one. :-)

Until OCL 2.1 is implemented, the Ecore-specific eClass() is the only
work-around available to the problem of access to the type of an object
(unless, of course, you define an operation or an attribute in your
model that gets the object's type, but I can't recommend that). OCL 1.x
had the OclAny::oclType attribute, OCL 2.0 removed it, and OCL 2.1 will
restore it in the form of an operation: OclAny::oclType().

Cheers,

Christian

On Fri, 2009-09-11 at 15:41 +0200, Gilbert Mirenque wrote:

> Hi Christian,
> didn't you mean the containedModel->isUnique(..) method?
>
> > context CompositionModel
> > inv: containedModel->unique(eClass())
>
> eClass() is emf specific and not pure ocl spec isn't it?

--=-80CJtH/WYzeQwmY4IgVZ
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Gilbert,<BR>
<BR>
Oops, yes, I did.&nbsp; I always get confused by the fact that this is the one boolean-valued iterator that uses &quot;is&quot; in the name.&nbsp; Unlike exists, forAll, one.&nbsp; :-)<BR>
<BR>
Until OCL 2.1 is implemented, the Ecore-specific eClass() is the only work-around available to the problem of access to the type of an object (unless, of course, you define an operation or an attribute in your model that gets the object's type, but I can't recommend that).&nbsp; OCL 1.x had the OclAny::oclType attribute, OCL 2.0 removed it, and OCL 2.1 will restore it in the form of an operation:&nbsp; OclAny::oclType().<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
On Fri, 2009-09-11 at 15:41 +0200, Gilbert Mirenque wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,
didn't you mean the containedModel-&gt;isUnique(..) method?

&gt; context CompositionModel
&gt; inv: containedModel-&gt;unique(eClass())

eClass() is emf specific and not pure ocl spec isn't it?
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-80CJtH/WYzeQwmY4IgVZ--
Re: How to check the types of containment? [message #485382 is a reply to message #485372] Fri, 11 September 2009 15:05 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

And how could I realize it that generically all sub types of
AbstractModel will be checked? I can't do the test for every type
because it can be that the metamodel will be extended.
Re: How to check the types of containment? [message #485402 is a reply to message #485382] Fri, 11 September 2009 15:22 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-2ORX0iR4eSBN957L8tLN
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Gilbert,

How about something like this:

context CompositionModel
inv: let epkg : ecore::EPackage = self.eClass().ePackage,
supertype : ecore::EClass =
epkg.getEClassifier("AbstractModel"),
concreteTypes : Set(ecore::EClass) =
epkg.eClassifiers->select(c |
not c.isAbstract and
supertype.isSuperClassOf(c))->asSet()
in
containedModel->unique(eClass()) and
containedModel.eClass()->asSet() = concreteTypes

The idea is to find all of the concrete subclasses of AbstractModel and
then check that the elements in the containedModel collection are all of
different types and that all of the concrete types are instantiated.
Thus, unique instances of every type.

HTH,

Christian


On Fri, 2009-09-11 at 17:05 +0200, Gilbert Mirenque wrote:

> And how could I realize it that generically all sub types of
> AbstractModel will be checked? I can't do the test for every type
> because it can be that the metamodel will be extended.

--=-2ORX0iR4eSBN957L8tLN
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Gilbert,<BR>
<BR>
How about something like this:<BR>
<BR>
&nbsp; context CompositionModel<BR>
&nbsp; inv: let epkg : ecore::EPackage = self.eClass().ePackage,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; supertype : ecore::EClass = epkg.getEClassifier(&quot;AbstractModel&quot;),<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; concreteTypes : Set(ecore::EClass) = epkg.eClassifiers-&gt;select(c |<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; not c.isAbstract and supertype.isSuperClassOf(c))-&gt;asSet()<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; in<BR>
&nbsp;&nbsp;&nbsp; containedModel-&gt;unique(eClass()) and<BR>
&nbsp;&nbsp;&nbsp; containedModel.eClass()-&gt;asSet() = concreteTypes<BR>
<BR>
The idea is to find all of the concrete subclasses of AbstractModel and then check that the elements in the containedModel collection are all of different types and that all of the concrete types are instantiated.&nbsp; Thus, unique instances of every type.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Fri, 2009-09-11 at 17:05 +0200, Gilbert Mirenque wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
And how could I realize it that generically all sub types of
AbstractModel will be checked? I can't do the test for every type
because it can be that the metamodel will be extended.
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-2ORX0iR4eSBN957L8tLN--
Re: How to check the types of containment? [message #485481 is a reply to message #485402] Fri, 11 September 2009 21:50 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Gilbert, Christain

I think the double argument forAll idiom should suit

context AbstractModel
inv: containedModel->forAll(a, b |
a <> b implies a.oclType() <> b.oclType())

Regards

Ed Willink

Christian W. Damus wrote:
> Hi, Gilbert,
>
> How about something like this:
>
> context CompositionModel
> inv: let epkg : ecore::EPackage = self.eClass().ePackage,
> supertype : ecore::EClass =
> epkg.getEClassifier("AbstractModel"),
> concreteTypes : Set(ecore::EClass) =
> epkg.eClassifiers->select(c |
> not c.isAbstract and
> supertype.isSuperClassOf(c))->asSet()
> in
> containedModel->unique(eClass()) and
> containedModel.eClass()->asSet() = concreteTypes
>
> The idea is to find all of the concrete subclasses of AbstractModel and
> then check that the elements in the containedModel collection are all of
> different types and that all of the concrete types are instantiated.
> Thus, unique instances of every type.
>
> HTH,
>
> Christian
>
>
> On Fri, 2009-09-11 at 17:05 +0200, Gilbert Mirenque wrote:
>> And how could I realize it that generically all sub types of
>> AbstractModel will be checked? I can't do the test for every type
>> because it can be that the metamodel will be extended.
Re: How to check the types of containment? [message #485526 is a reply to message #485481] Sat, 12 September 2009 13:57 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Hi Ed,

> context AbstractModel
> inv: containedModel->forAll(a, b |
> a <> b implies a.oclType() <> b.oclType())

that's a nice solution :)
Re: How to check the types of containment? [message #485685 is a reply to message #485481] Mon, 14 September 2009 13:19 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-T5TUmtUfH6w5hUltUnWj
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Ed,

Yes, that's a good way to do the uniqueness condition, but there is
still the covering condition to consider: the other requirement was to
check that all concrete subclasses of AbstractModel are instantiated in
the containedModel collection.

Cheers,

Christian


On Fri, 2009-09-11 at 22:50 +0100, Ed Willink wrote:

> Hi Gilbert, Christain
>
> I think the double argument forAll idiom should suit
>
> context AbstractModel
> inv: containedModel->forAll(a, b |
> a <> b implies a.oclType() <> b.oclType())
>
> Regards
>
> Ed Willink
>
> Christian W. Damus wrote:
> > Hi, Gilbert,
> >
> > How about something like this:
> >
> > context CompositionModel
> > inv: let epkg : ecore::EPackage = self.eClass().ePackage,
> > supertype : ecore::EClass =
> > epkg.getEClassifier("AbstractModel"),
> > concreteTypes : Set(ecore::EClass) =
> > epkg.eClassifiers->select(c |
> > not c.isAbstract and
> > supertype.isSuperClassOf(c))->asSet()
> > in
> > containedModel->unique(eClass()) and
> > containedModel.eClass()->asSet() = concreteTypes
> >
> > The idea is to find all of the concrete subclasses of AbstractModel and
> > then check that the elements in the containedModel collection are all of
> > different types and that all of the concrete types are instantiated.
> > Thus, unique instances of every type.
> >
> > HTH,
> >
> > Christian
> >
> >
> > On Fri, 2009-09-11 at 17:05 +0200, Gilbert Mirenque wrote:
> >> And how could I realize it that generically all sub types of
> >> AbstractModel will be checked? I can't do the test for every type
> >> because it can be that the metamodel will be extended.

--=-T5TUmtUfH6w5hUltUnWj
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Ed,<BR>
<BR>
Yes, that's a good way to do the uniqueness condition, but there is still the covering condition to consider:&nbsp; the other requirement was to check that all concrete subclasses of AbstractModel are instantiated in the containedModel collection.<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Fri, 2009-09-11 at 22:50 +0100, Ed Willink wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Gilbert, Christain

I think the double argument forAll idiom should suit

context AbstractModel
inv: containedModel-&gt;forAll(a, b |
a &lt;&gt; b implies a.oclType() &lt;&gt; b.oclType())

Regards

Ed Willink

Christian W. Damus wrote:
&gt; Hi, Gilbert,
&gt;
&gt; How about something like this:
&gt;
&gt; context CompositionModel
&gt; inv: let epkg : ecore::EPackage = self.eClass().ePackage,
&gt; supertype : ecore::EClass =
&gt; epkg.getEClassifier(&quot;AbstractModel&quot;),
&gt; concreteTypes : Set(ecore::EClass) =
&gt; epkg.eClassifiers-&gt;select(c |
&gt; not c.isAbstract and
&gt; supertype.isSuperClassOf(c))-&gt;asSet()
&gt; in
&gt; containedModel-&gt;unique(eClass()) and
&gt; containedModel.eClass()-&gt;asSet() = concreteTypes
&gt;
&gt; The idea is to find all of the concrete subclasses of AbstractModel and
&gt; then check that the elements in the containedModel collection are all of
&gt; different types and that all of the concrete types are instantiated.
&gt; Thus, unique instances of every type.
&gt;
&gt; HTH,
&gt;
&gt; Christian
&gt;
&gt;
&gt; On Fri, 2009-09-11 at 17:05 +0200, Gilbert Mirenque wrote:
&gt;&gt; And how could I realize it that generically all sub types of
&gt;&gt; AbstractModel will be checked? I can't do the test for every type
&gt;&gt; because it can be that the metamodel will be extended.
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-T5TUmtUfH6w5hUltUnWj--
Re: How to check the types of containment? [message #485774 is a reply to message #485685] Mon, 14 September 2009 21:55 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Hi Christian,

> still the covering condition to consider: the other requirement was to
> check that all concrete subclasses of AbstractModel are instantiated in
> the containedModel collection.

no - not all concrete sublasses have to isntantiated but this who are
only must be instantiated once.

cheers
Gilbert
Re: How to check the types of containment? [message #485889 is a reply to message #485774] Tue, 15 September 2009 13:06 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-clCxHl51g8vJDpDwfD98
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Gilbert,

Ah! I see ... I misunderstood your original statement on that subject.
I see that Ed has the correct context declaration, then. So the
following is, perhaps, the most succinct definition:

context AbstractModel
inv: containedModel->isUnique(oclType())

or, until OCL 2.1 is implemented,

context AbstractModel
inv: containedModel->isUnique(eClass())

cW


On Mon, 2009-09-14 at 23:55 +0200, Gilbert Mirenque wrote:

> Hi Christian,
>
> > still the covering condition to consider: the other requirement was to
> > check that all concrete subclasses of AbstractModel are instantiated in
> > the containedModel collection.
>
> no - not all concrete sublasses have to isntantiated but this who are
> only must be instantiated once.
>
> cheers
> Gilbert

--=-clCxHl51g8vJDpDwfD98
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Gilbert,<BR>
<BR>
Ah!&nbsp; I see ... I misunderstood your original statement on that subject.&nbsp; I see that Ed has the correct context declaration, then.&nbsp; So the following is, perhaps, the most succinct definition:<BR>
<BR>
<TT><FONT COLOR="#000000">context AbstractModel</FONT></TT><BR>
<TT><FONT COLOR="#000000">inv: containedModel-&gt;</FONT></TT><TT>isUnique</TT><TT ><FONT COLOR="#000000">(oclType())</FONT></TT><BR>
<BR>
or, until OCL 2.1 is implemented,<BR>
<BR>
<TT><FONT COLOR="#000000">context AbstractModel</FONT></TT><BR>
<TT><FONT COLOR="#000000">inv: containedModel-&gt;</FONT></TT><TT>isUnique</TT><TT ><FONT COLOR="#000000">(</FONT></TT>eClass<FONT COLOR="#000000">())</FONT><BR>
<BR>
cW<BR>
<BR>
<BR>
On Mon, 2009-09-14 at 23:55 +0200, Gilbert Mirenque wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,

&gt; still the covering condition to consider: the other requirement was to
&gt; check that all concrete subclasses of AbstractModel are instantiated in
&gt; the containedModel collection.

no - not all concrete sublasses have to isntantiated but this who are
only must be instantiated once.

cheers
Gilbert
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-clCxHl51g8vJDpDwfD98--
Re: How to check the types of containment? [message #485943 is a reply to message #485889] Tue, 15 September 2009 15:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

I have another problem now. Until now I took an evaluation copy of
Together for designing my ocl constraints in the ocl editor and just
pasted them into my ecore model annotations. But as my copy ran out now
I can't use it anymore and I wanted to try to create my constraints like
described in [1] with the OCL console. Now the problem is if I select M2
as modeling level I can use expressions like eClass(). But with the
statement

self.model->isUnique(eClass())

I get the message "Unrecognized variable: (model)". So I activated level
M1 and now I can access self.model for example but not eClass() anymore.
Am I doing something wrong? Or how do you create your ocl expressions?

best regards,
Gilbert

[1]
http://help.eclipse.org/galileo/topic/org.eclipse.ocl.doc/re ferences/examples/oclInterpreterExample.html
Re: How to check the types of containment? [message #485944 is a reply to message #485943] Tue, 15 September 2009 15:22 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-Wsv8x9CA8MMGZhj4m17z
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Gilbert,

Update the interpreter example code to set the "implicit root class"
parser option to EcorePackage.Literals.EObject in the initialization of
the M1 environment. This is required to access the EObject features in
models that do not explicitly extend EObject.

HTH,

Christian


On Tue, 2009-09-15 at 17:07 +0200, Gilbert Mirenque wrote:

> I have another problem now. Until now I took an evaluation copy of
> Together for designing my ocl constraints in the ocl editor and just
> pasted them into my ecore model annotations. But as my copy ran out now
> I can't use it anymore and I wanted to try to create my constraints like
> described in [1] with the OCL console. Now the problem is if I select M2
> as modeling level I can use expressions like eClass(). But with the
> statement
>
> self.model->isUnique(eClass())
>
> I get the message "Unrecognized variable: (model)". So I activated level
> M1 and now I can access self.model for example but not eClass() anymore.
> Am I doing something wrong? Or how do you create your ocl expressions?
>
> best regards,
> Gilbert
>
> [1]
> http://help.eclipse.org/galileo/topic/org.eclipse.ocl.doc/re ferences/examples/oclInterpreterExample.html

--=-Wsv8x9CA8MMGZhj4m17z
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Gilbert,<BR>
<BR>
Update the interpreter example code to set the &quot;implicit root class&quot; parser option to EcorePackage.Literals.EObject in the initialization of the M1 environment.&nbsp; This is required to access the EObject features in models that do not explicitly extend EObject.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Tue, 2009-09-15 at 17:07 +0200, Gilbert Mirenque wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
I have another problem now. Until now I took an evaluation copy of
Together for designing my ocl constraints in the ocl editor and just
pasted them into my ecore model annotations. But as my copy ran out now
I can't use it anymore and I wanted to try to create my constraints like
described in [1] with the OCL console. Now the problem is if I select M2
as modeling level I can use expressions like eClass(). But with the
statement

self.model-&gt;isUnique(eClass())

I get the message &quot;Unrecognized variable: (model)&quot;. So I activated level
M1 and now I can access self.model for example but not eClass() anymore.
Am I doing something wrong? Or how do you create your ocl expressions?

best regards,
Gilbert

[1]
<A HREF=" http://help.eclipse.org/galileo/topic/org.eclipse.ocl.doc/re ferences/examples/oclInterpreterExample.html"> http://help.eclipse.org/galileo/topic/org.eclipse.ocl.doc/re ferences/examples/oclInterpreterExample.html</A>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-Wsv8x9CA8MMGZhj4m17z--
Re: How to check the types of containment? [message #485955 is a reply to message #485944] Tue, 15 September 2009 16:04 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Sorry Christian,
I don't understand what you mean.
> Update the interpreter example code to set the "implicit root class"
> parser option to EcorePackage.Literals.EObject in the initialization of
> the M1 environment. This is required to access the EObject features in
> models that do not explicitly extend EObject.
I meant that I found the posted link and wanted to create some ocl
expressions with at least a little kind of editor. I don't use the
example described in the link. What is the "implicit root class" parser
option? I have a meta model based on ecore. What do I have to change
that I can invent some ocl expressions?
Another question: Under [1] I found in the last snippet the following line:

self.allOwnedElements()

But allOwnedElements() can't be found here. Is this an old snippet? I
want to check if all referenced events of a model element are contained
in its own hierarchy are and not events of model elements outside its
own hierarchy. That means the referenced events mustn't be events of
sibling model elements. So I tried to do something like this:

self.exportedEvents ->forAll(ev|
self.allOwnedElements()
->select(x|
x.oclIsTypeOf(MyMetaModel::Event))
->includes(ev)
)

Sorry for the annoying questions but for a novice it's just an ocl
jungle. A central documentation with what is possible in MDT OCL and how
would be nice. Hope you can help.

best regards,
Gilbert

[ http://wiki.eclipse.org/OCLSnippets#Finding_all_classifiers_ that_specialize_an_arbitrary_classifier_named_.27foo::Bar.27]
Re: How to check the types of containment? [message #485966 is a reply to message #485955] Tue, 15 September 2009 17:53 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-z2QICUAgTQ3+qb1sbXfh
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Gilbert,

See some replies in-line, below.

HTH,

Christian


On Tue, 2009-09-15 at 18:04 +0200, Gilbert Mirenque wrote:

> Sorry Christian,
> I don't understand what you mean.
> > Update the interpreter example code to set the "implicit root class"
> > parser option to EcorePackage.Literals.EObject in the initialization of
> > the M1 environment. This is required to access the EObject features in
> > models that do not explicitly extend EObject.
> I meant that I found the posted link and wanted to create some ocl
> expressions with at least a little kind of editor. I don't use the
> example described in the link. What is the "implicit root class" parser


But, you said in your post that you were getting error messages from
expressions and "activated level M1" etc. If you weren't doing this in
the OCL interpreter example (the "interactive console") then I don't
know what you were using. AFAIK, the only UI that uses labels like "M2"
and "M1" is that example.

The MDT OCL SDK provides a "New Example" wizard that creates the
interpreter/console example as a source project in your workspace. You
can edit the code to customize the parser behaviour, if you need to, as
in this case.

The implicit root class option is a customization option for the parser:
the details of the API escape me now, it's been so long since I've
worked with the OCL code. Look for the ParserOptions type in the OCL
source. This option is used to tell the parser to assume that all
classes in your model that don't have an explicit superclass have the
given class (in this case, EObject) as a superclass. This covers the
case in Ecore models where on a Java level all generated classes extend
EObject whether your Ecore model makes it explicit or not.



> option? I have a meta model based on ecore. What do I have to change
> that I can invent some ocl expressions?


You don't necessarily have to do anything special to work with Ecore
models. It's just that, in your case, you need to do reflection on the
meta-model level of a sort that OCL (the language) does not support, so
we need to pull a trick to work around it in the MDT implementation.



> Another question: Under [1] I found in the last snippet the following line:
>
> self.allOwnedElements()
>
> But allOwnedElements() can't be found here. Is this an old snippet? I


No, this snippet pertains to the UML metamodel. In UML models you can
use allOwnedElements because it is defined by the uml::Element
metaclass. The only thing similar in the Ecore metamodel is
eAllContents(), but it returns a data type (an iterator) which isn't of
any use in OCL.



> want to check if all referenced events of a model element are contained
> in its own hierarchy are and not events of model elements outside its
> own hierarchy. That means the referenced events mustn't be events of
> sibling model elements. So I tried to do something like this:
>
> self.exportedEvents ->forAll(ev|
> self.allOwnedElements()
> ->select(x|
> x.oclIsTypeOf(MyMetaModel::Event))
> ->includes(ev)
> )


Try this:

self.exportedEvents ->forAll(ev |
ev->closure(eContainer())->contains(self))

Unfortunately, this again requires that either you explicitly extend
EObject in your model or you use the implicit root class option, in
order to access the eContainer()) operation. Alternatively, perhaps
your model already has some feature that generically returns the
containing element?


> Sorry for the annoying questions but for a novice it's just an ocl
> jungle. A central documentation with what is possible in MDT OCL and how
> would be nice. Hope you can help.
>
> best regards,
> Gilbert
>
> [ http://wiki.eclipse.org/OCLSnippets#Finding_all_classifiers_ that_specialize_an_arbitrary_classifier_named_.27foo::Bar.27]

--=-z2QICUAgTQ3+qb1sbXfh
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Gilbert,<BR>
<BR>
See some replies in-line, below.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Tue, 2009-09-15 at 18:04 +0200, Gilbert Mirenque wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Sorry Christian,
I don't understand what you mean.
&gt; Update the interpreter example code to set the &quot;implicit root class&quot;
&gt; parser option to EcorePackage.Literals.EObject in the initialization of
&gt; the M1 environment. This is required to access the EObject features in
&gt; models that do not explicitly extend EObject.
I meant that I found the posted link and wanted to create some ocl
expressions with at least a little kind of editor. I don't use the
example described in the link. What is the &quot;implicit root class&quot; parser
</PRE>
</BLOCKQUOTE>
<BR>
But, you said in your post that you were getting error messages from expressions and &quot;activated level M1&quot; etc.&nbsp; If you weren't doing this in the OCL interpreter example (the &quot;interactive console&quot;) then I don't know what you were using.&nbsp; AFAIK, the only UI that uses labels like &quot;M2&quot; and &quot;M1&quot; is that example.<BR>
<BR>
The MDT OCL SDK provides a &quot;New Example&quot; wizard that creates the interpreter/console example as a source project in your workspace.&nbsp; You can edit the code to customize the parser behaviour, if you need to, as in this case.<BR>
<BR>
The implicit root class option is a customization option for the parser:&nbsp; the details of the API escape me now, it's been so long since I've worked with the OCL code.&nbsp; Look for the ParserOptions type in the OCL source.&nbsp; This option is used to tell the parser to assume that all classes in your model that don't have an explicit superclass have the given class (in this case, EObject) as a superclass.&nbsp; This covers the case in Ecore models where on a Java level all generated classes extend EObject whether your Ecore model makes it explicit or not.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
option? I have a meta model based on ecore. What do I have to change
that I can invent some ocl expressions?
</PRE>
</BLOCKQUOTE>
<BR>
You don't necessarily have to do anything special to work with Ecore models.&nbsp; It's just that, in your case, you need to do reflection on the meta-model level of a sort that OCL (the language) does not support, so we need to pull a trick to work around it in the MDT implementation.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Another question: Under [1] I found in the last snippet the following line:

self.allOwnedElements()

But allOwnedElements() can't be found here. Is this an old snippet? I
</PRE>
</BLOCKQUOTE>
<BR>
No, this snippet pertains to the UML metamodel.&nbsp; In UML models you can use allOwnedElements because it is defined by the uml::Element metaclass.&nbsp; The only thing similar in the Ecore metamodel is eAllContents(), but it returns a data type (an iterator) which isn't of any use in OCL.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
want to check if all referenced events of a model element are contained
in its own hierarchy are and not events of model elements outside its
own hierarchy. That means the referenced events mustn't be events of
sibling model elements. So I tried to do something like this:

self.exportedEvents -&gt;forAll(ev|
self.allOwnedElements()
-&gt;select(x|
x.oclIsTypeOf(MyMetaModel::Event))
-&gt;includes(ev)
)
</PRE>
</BLOCKQUOTE>
<BR>
Try this:<BR>
<BR>
&nbsp; self.exportedEvents -&gt;forAll(ev |<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ev-&gt;closure(eContainer())-&gt;contains(self))<BR >
<BR>
Unfortunately, this again requires that either you explicitly extend EObject in your model or you use the implicit root class option, in order to access the eContainer()) operation.&nbsp; Alternatively, perhaps your model already has some feature that generically returns the containing element?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Sorry for the annoying questions but for a novice it's just an ocl
jungle. A central documentation with what is possible in MDT OCL and how
would be nice. Hope you can help.

best regards,
Gilbert

[<A HREF=" http://wiki.eclipse.org/OCLSnippets#Finding_all_classifiers_ that_specialize_an_arbitrary_classifier_named_.27foo::Bar.27"> http://wiki.eclipse.org/OCLSnippets#Finding_all_classifiers_ that_specialize_an_arbitrary_classifier_named_.27foo::Bar.27</A>]
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-z2QICUAgTQ3+qb1sbXfh--
Re: How to check the types of containment? [message #486096 is a reply to message #485966] Wed, 16 September 2009 11:03 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Hi Christian,
thanks for your patience

>
> But, you said in your post that you were getting error messages from
> expressions and "activated level M1" etc. If you weren't doing this in
> the OCL interpreter example (the "interactive console") then I don't
> know what you were using. AFAIK, the only UI that uses labels like "M2"
> and "M1" is that example.
I was doing it in the console but I'm not using the example.

>
> The MDT OCL SDK provides a "New Example" wizard that creates the
> interpreter/console example as a source project in your workspace. You
> can edit the code to customize the parser behaviour, if you need to, as
> in this case.
Ok thanks for the hint with the wizard. I will have a look. But at the
moment I don't need any code for running OCL statements or so. I just
need a way for developing some ocl expressions for my meta model. After
creating correct expressions I want to add them as EAnnotations on my
meta model elements in hope that the bug 255786 [1] will be solved soon.
And therefore I thought that I can use the OCL console just to see if
the expressions are correct - not more. And that's why I don't
understand why I have to switch M2 and M1 if I want to get code
completion in the console for this element or for that element. Thought
when I develop a new ecore meta model I am on the M2 level because it's
a meta model for my DSL.

> No, this snippet pertains to the UML metamodel. In UML models you can
> use allOwnedElements because it is defined by the uml::Element
> metaclass.
Ok I assumed that.

> self.exportedEvents ->forAll(ev |
> ev->closure(eContainer())->contains(self))
>
Neither on level M1 nor M2 the code assist shows me the closure(..) on
ev. The same with contains(..). And if I let this expression interprete
by the console in level M1 I get this output:

illegal operation signature: (eContainer())

and in level M2:

Unrecognized variable: (exportedEvents)

It's just not very comprehensible for me why I have to switch always.

> Unfortunately, this again requires that either you explicitly extend
> EObject in your model or you use the implicit root class option, in
> order to access the eContainer()) operation.
Thought that when I create a new ecore meta model all the elements
inherit from EObject. At least the generated classes extend EObject. But
one does not have to generate classes at all. Isn't it possible at all
to use the OCL console in this case because no classes are generated?
Can't imagine.

> Alternatively, perhaps
> your model already has some feature that generically returns the
> containing element?
Ok I can consider this. Until now I don't have any operations in my meta
model because I wanted to let it open if it will be used with Eclipse or
any other platform.

Thanks in advance Christian.

best regards,
Gilbert

[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
Re: How to check the types of containment? [message #486100 is a reply to message #485966] Wed, 16 September 2009 11:11 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

I little other question just because it looks so nice. What editor is
this one in the example overview:
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .ocl.doc/references/examples/exampleOverview.html
?

My editor looks like this (it's the Ecore Diagram Editor):

http://www.reimone.net/extlibrary.gif
Re: How to check the types of containment? [message #486135 is a reply to message #486096] Wed, 16 September 2009 13:35 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-MKRiOzOr3EZFTMSvvb90
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Gilbert,

See some more comments in-line.

HTH,

Christian


On Wed, 2009-09-16 at 13:03 +0200, Gilbert Mirenque wrote:

> Hi Christian,
> thanks for your patience
>
> >
> > But, you said in your post that you were getting error messages from
> > expressions and "activated level M1" etc. If you weren't doing this in
> > the OCL interpreter example (the "interactive console") then I don't
> > know what you were using. AFAIK, the only UI that uses labels like "M2"
> > and "M1" is that example.
> I was doing it in the console but I'm not using the example.


Ah, but you are. The interactive console *is* the example. :-)



> > The MDT OCL SDK provides a "New Example" wizard that creates the
> > interpreter/console example as a source project in your workspace. You
> > can edit the code to customize the parser behaviour, if you need to, as
> > in this case.
> Ok thanks for the hint with the wizard. I will have a look. But at the
> moment I don't need any code for running OCL statements or so. I just
> need a way for developing some ocl expressions for my meta model. After
> creating correct expressions I want to add them as EAnnotations on my
> meta model elements in hope that the bug 255786 [1] will be solved soon.


Yes, the console example is primarily intended as a scratchpad for
development and testing of OCL constraints, in the manner that you
intend to use it.



> And therefore I thought that I can use the OCL console just to see if
> the expressions are correct - not more. And that's why I don't
> understand why I have to switch M2 and M1 if I want to get code
> completion in the console for this element or for that element. Thought
> when I develop a new ecore meta model I am on the M2 level because it's
> a meta model for my DSL.


In the "M2" mode, your expressions are in the Ecore (metamodel) context,
so they are generally expected to be queries on the model that you are
editing. The context of any expression that you type is the metaclass
of the selected element. Thus, in "M2" mode you have expressions on
EClass, EDataType, EReference, EPackage, etc. The idea is that you can
query your model to analyze its structure (e.g., are there any abstract
EClasses that have no concrete subclasses?).

In the "M1" mode, your expressions are boolean constraints in the
context of your model (as an Ecore instance). The kind of constraint
depends on the selected element: when an EClass is selected, the
console treats your expression as an invariant constraint. When an
EOperation is selected, as a postcondition (as its syntax is a superset
of the possible operation constraints). When an EStructuralFeature is
selected, as a derivation expression. You want to use "M1" mode to
author the model constraints for your annotations and eventual execution
at run-time.

Note that, for "M1" mode, the interpreter only parses the constraints
and reports syntax problems if necessary, because there is no model
instance to evaluate the constraint on. In "M2" mode, you are really
defining queries on your model as an Ecore instance, so the console
evaluates them on your model.

You can create a dynamic instance of any EClass in your model, of
course, and then evaluate expressions on that. These might be
invariants that you parsed in "M1" mode in the model, but then you need
"M2" mode on the dynamic instance because it is at a lower meta-level.
This is why the M1/M2 labeling in the UI is unfortunate.



> > No, this snippet pertains to the UML metamodel. In UML models you can
> > use allOwnedElements because it is defined by the uml::Element
> > metaclass.
> Ok I assumed that.
>
> > self.exportedEvents ->forAll(ev |
> > ev->closure(eContainer())->contains(self))
> >
> Neither on level M1 nor M2 the code assist shows me the closure(..) on
> ev. The same with contains(..). And if I let this expression interprete
> by the console in level M1 I get this output:


Sorry ... too much Java. This should, of course, be "includes" instead
of "contains."

Content assist may not show you the "closure" iterator because it is not
OMG-standard OCL. However, it should parse.



> illegal operation signature: (eContainer())


That is only because you need to update the console to set EObject as
the implicit root class when parsing, unless your EClasses explicitly
extend EObject (which I generally wouldn't recommend).



> and in level M2:
>
> Unrecognized variable: (exportedEvents)


Because EClass does not have an exportedEvents feature. Your model
class does. You need the M1 setting to author model constraints.



> It's just not very comprehensible for me why I have to switch always.


It's just a way to tell the parser whether the context of an expression
is the *metaclass* of the selected element (M2 case) or the selected
element, itself (M1). For what you are doing, M2 is not interesting.

For background on this nomenclature, you might read the chapter on the
OMG's MDA architecture and the 4-layer modeling stack (M0 through M3) in
the Meta-Object Facility (MOF) 2.0 specification.



> > Unfortunately, this again requires that either you explicitly extend
> > EObject in your model or you use the implicit root class option, in
> > order to access the eContainer()) operation.
> Thought that when I create a new ecore meta model all the elements
> inherit from EObject. At least the generated classes extend EObject. But


Yes, the Java *implementation* of your model extends EObject, but in
abstract terms your model classes do not. The EMF run-time requires the
features of EObject but your business logic does not. OR, if it does,
then your model may benefit from explicitly extending EObject. The
point is whether your EClasses actually list EObject as an eSuperClass
or not.


> one does not have to generate classes at all. Isn't it possible at all
> to use the OCL console in this case because no classes are generated?
> Can't imagine.


Yes, it works equally well with dynamic EMF as with generated models.
You can try it right in the model editor on a dynamic instance!
Evaluate one of your invariant constraint expressions on a dynamic
object and you'll see.



> > Alternatively, perhaps
> > your model already has some feature that generically returns the
> > containing element?
> Ok I can consider this. Until now I don't have any operations in my meta
> model because I wanted to let it open if it will be used with Eclipse or
> any other platform.
>
> Thanks in advance Christian.
>
> best regards,
> Gilbert
>
> [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786

--=-MKRiOzOr3EZFTMSvvb90
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Gilbert,<BR>
<BR>
See some more comments in-line.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Wed, 2009-09-16 at 13:03 +0200, Gilbert Mirenque wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,
thanks for your patience

&gt;
&gt; But, you said in your post that you were getting error messages from
&gt; expressions and &quot;activated level M1&quot; etc. If you weren't doing this in
&gt; the OCL interpreter example (the &quot;interactive console&quot;) then I don't
&gt; know what you were using. AFAIK, the only UI that uses labels like &quot;M2&quot;
&gt; and &quot;M1&quot; is that example.
I was doing it in the console but I'm not using the example.
</PRE>
</BLOCKQUOTE>
<BR>
Ah, but you are.&nbsp; The interactive console *is* the example.&nbsp; :-)<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
&gt; The MDT OCL SDK provides a &quot;New Example&quot; wizard that creates the
&gt; interpreter/console example as a source project in your workspace. You
&gt; can edit the code to customize the parser behaviour, if you need to, as
&gt; in this case.
Ok thanks for the hint with the wizard. I will have a look. But at the
moment I don't need any code for running OCL statements or so. I just
need a way for developing some ocl expressions for my meta model. After
creating correct expressions I want to add them as EAnnotations on my
meta model elements in hope that the bug 255786 [1] will be solved soon.
</PRE>
</BLOCKQUOTE>
<BR>
Yes, the console example is primarily intended as a scratchpad for development and testing of OCL constraints, in the manner that you intend to use it.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
And therefore I thought that I can use the OCL console just to see if
the expressions are correct - not more. And that's why I don't
understand why I have to switch M2 and M1 if I want to get code
completion in the console for this element or for that element. Thought
when I develop a new ecore meta model I am on the M2 level because it's
a meta model for my DSL.
</PRE>
</BLOCKQUOTE>
<BR>
In the &quot;M2&quot; mode, your expressions are in the Ecore (metamodel) context, so they are generally expected to be queries on the model that you are editing.&nbsp; The context of any expression that you type is the metaclass of the selected element.&nbsp; Thus, in &quot;M2&quot; mode you have expressions on EClass, EDataType, EReference, EPackage, etc.&nbsp; The idea is that you can query your model to analyze its structure (e.g., are there any abstract EClasses that have no concrete subclasses?).<BR>
<BR>
In the &quot;M1&quot; mode, your expressions are boolean constraints in the context of your model (as an Ecore instance).&nbsp; The kind of constraint depends on the selected element:&nbsp; when an EClass is selected, the console treats your expression as an invariant constraint.&nbsp; When an EOperation is selected, as a postcondition (as its syntax is a superset of the possible operation constraints).&nbsp; When an EStructuralFeature is selected, as a derivation expression.&nbsp; You want to use &quot;M1&quot; mode to author the model constraints for your annotations and eventual execution at run-time.<BR>
<BR>
Note that, for &quot;M1&quot; mode, the interpreter only parses the constraints and reports syntax problems if necessary, because there is no model instance to evaluate the constraint on.&nbsp; In &quot;M2&quot; mode, you are really defining queries on your model as an Ecore instance, so the console evaluates them on your model.<BR>
<BR>
You can create a dynamic instance of any EClass in your model, of course, and then evaluate expressions on that.&nbsp; These might be invariants that you parsed in &quot;M1&quot; mode in the model, but then you need &quot;M2&quot; mode on the dynamic instance because it is at a lower meta-level.&nbsp; This is why the M1/M2 labeling in the UI is unfortunate.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
&gt; No, this snippet pertains to the UML metamodel. In UML models you can
&gt; use allOwnedElements because it is defined by the uml::Element
&gt; metaclass.
Ok I assumed that.

&gt; self.exportedEvents -&gt;forAll(ev |
&gt; ev-&gt;closure(eContainer())-&gt;contains(self))
&gt;
Neither on level M1 nor M2 the code assist shows me the closure(..) on
ev. The same with contains(..). And if I let this expression interprete
by the console in level M1 I get this output:
</PRE>
</BLOCKQUOTE>
<BR>
Sorry ... too much Java.&nbsp; This should, of course, be &quot;includes&quot; instead of &quot;contains.&quot;<BR>
<BR>
Content assist may not show you the &quot;closure&quot; iterator because it is not OMG-standard OCL.&nbsp; However, it should parse.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
illegal operation signature: (eContainer())
</PRE>
</BLOCKQUOTE>
<BR>
That is only because you need to update the console to set EObject as the implicit root class when parsing, unless your EClasses explicitly extend EObject (which I generally wouldn't recommend).<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
and in level M2:

Unrecognized variable: (exportedEvents)
</PRE>
</BLOCKQUOTE>
<BR>
Because EClass does not have an exportedEvents feature.&nbsp; Your model class does.&nbsp; You need the M1 setting to author model constraints.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
It's just not very comprehensible for me why I have to switch always.
</PRE>
</BLOCKQUOTE>
<BR>
It's just a way to tell the parser whether the context of an expression is the *metaclass* of the selected element (M2 case) or the selected element, itself (M1).&nbsp; For what you are doing, M2 is not interesting.<BR>
<BR>
For background on this nomenclature, you might read the chapter on the OMG's MDA architecture and the 4-layer modeling stack (M0 through M3) in the Meta-Object Facility (MOF) 2.0 specification.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
&gt; Unfortunately, this again requires that either you explicitly extend
&gt; EObject in your model or you use the implicit root class option, in
&gt; order to access the eContainer()) operation.
Thought that when I create a new ecore meta model all the elements
inherit from EObject. At least the generated classes extend EObject. But
</PRE>
</BLOCKQUOTE>
<BR>
Yes, the Java *implementation* of your model extends EObject, but in abstract terms your model classes do not.&nbsp; The EMF run-time requires the features of EObject but your business logic does not.&nbsp; OR, if it does, then your model may benefit from explicitly extending EObject.&nbsp; The point is whether your EClasses actually list EObject as an eSuperClass or not.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
one does not have to generate classes at all. Isn't it possible at all
to use the OCL console in this case because no classes are generated?
Can't imagine.
</PRE>
</BLOCKQUOTE>
<BR>
Yes, it works equally well with dynamic EMF as with generated models.&nbsp; You can try it right in the model editor on a dynamic instance!&nbsp; Evaluate one of your invariant constraint expressions on a dynamic object and you'll see.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
&gt; Alternatively, perhaps
&gt; your model already has some feature that generically returns the
&gt; containing element?
Ok I can consider this. Until now I don't have any operations in my meta
model because I wanted to let it open if it will be used with Eclipse or
any other platform.

Thanks in advance Christian.

best regards,
Gilbert

[1]<A HREF="https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786">https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786</A>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-MKRiOzOr3EZFTMSvvb90--
Re: How to check the types of containment? [message #486194 is a reply to message #486135] Wed, 16 September 2009 16:58 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Hi Christian

> Ah, but you are. The interactive console *is* the example. :-)
Ohh :)

> That is only because you need to update the console to set EObject as
> the implicit root class when parsing, unless your EClasses explicitly
> extend EObject (which I generally wouldn't recommend).

Ok I now have the code from the example wizards. I now searched like
hell for something about the ParserOptions as you mentioned before.
Couldn't find anything. But fortunately I searched "implicit root class"
and found a little test suite of yourself [1]. There to see that its
name isn't PerserOptions but ParsingOptions ;) Now I could solve the
problem. In the class ModelingLevel in the method setContext(..) I added
those two lines in the M1 case:

OCL ocl = helper.getOCL();
ParsingOptions.setOption(ocl.getEnvironment(),
ParsingOptions.implicitRootClass(ocl.getEnvironment()),
EcorePackage.Literals.EOBJECT);

Now it works finally :) Thanks a lot again for your patience Christian.
Now I just need to export the modified plugin and add it into my eclipse.

best regards,
Gilbert

[1]
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org .eclipse.ocl/tests/org.eclipse.ocl.ecore.tests/src/org/eclip se/ocl/ecore/tests/ParsingOptionsTest.java?root=Modeling_Pro ject&view=co
Re: How to check the types of containment? [message #486200 is a reply to message #486135] Wed, 16 September 2009 17:22 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Hi Christian,
only for completeness...

> Content assist may not show you the "closure" iterator because it is not
> OMG-standard OCL. However, it should parse.
....this result comes:
Usage of non-standard "closure" iterator

Can you please explain a little bit this expression:

self.exportedEvents->forAll(ev|
ev->closure(eContainer())->includes(self)
)


Especially closure(eContainer())does what exactly? Does it return all
elements contain ev? Then it should only be one and self should be
included in this closure, right. Do I understand this correctly?

Just for curiosity. The following expressions parses correctly

self.exportedEvents ->forAll(ev|
self.eContents()
->select(x|
x.oclIsTypeOf(CRUISeMetaModel::Event))
->includes(ev)
)

But I wonder about self.eContents(). Is the semantic like I used it here?

best regards,
Gilbert
Re: How to check the types of containment? [message #486204 is a reply to message #485943] Wed, 16 September 2009 17:58 Go to previous messageGo to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo HerreraFriend
Messages: 260
Registered: July 2009
Senior Member
Gilbert Mirenque escribió:
> I have another problem now. Until now I took an evaluation copy of
> Together for designing my ocl constraints in the ocl editor and just
> pasted them into my ecore model annotations. But as my copy ran out now
> I can't use it anymore and I wanted to try to create my constraints like
> described in [1] with the OCL console.

Gilbert,

OCL's Team is trying to integrate an OCL Editor in the Helio's release
which currently resides in the Eclipse's M2M-QVTDeclarative CVS. You
could try downloading it and play a little bit with it. It may be
helpful to you ;)

Cheers,
Adolfo.
Re: How to check the types of containment? [message #486372 is a reply to message #486194] Thu, 17 September 2009 13:20 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-KbtoLmtfA+RaEcD1Ux3x
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Gilbert,

Thanks for your patience in dealing with my inaccuracies ... I hope the
process has led you to an even better understanding of things than if I
had been more accurate! ;-) I've been away from the code so long,
now, that probably I should add a disclaimer to every message!

Cheers,

Christian


On Wed, 2009-09-16 at 18:58 +0200, Gilbert Mirenque wrote:

> Hi Christian
>
> > Ah, but you are. The interactive console *is* the example. :-)
> Ohh :)
>
> > That is only because you need to update the console to set EObject as
> > the implicit root class when parsing, unless your EClasses explicitly
> > extend EObject (which I generally wouldn't recommend).
>
> Ok I now have the code from the example wizards. I now searched like
> hell for something about the ParserOptions as you mentioned before.
> Couldn't find anything. But fortunately I searched "implicit root class"
> and found a little test suite of yourself [1]. There to see that its
> name isn't PerserOptions but ParsingOptions ;) Now I could solve the
> problem. In the class ModelingLevel in the method setContext(..) I added
> those two lines in the M1 case:
>
> OCL ocl = helper.getOCL();
> ParsingOptions.setOption(ocl.getEnvironment(),
> ParsingOptions.implicitRootClass(ocl.getEnvironment()),
> EcorePackage.Literals.EOBJECT);
>
> Now it works finally :) Thanks a lot again for your patience Christian.
> Now I just need to export the modified plugin and add it into my eclipse.
>
> best regards,
> Gilbert
>
> [1]
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org .eclipse.ocl/tests/org.eclipse.ocl.ecore.tests/src/org/eclip se/ocl/ecore/tests/ParsingOptionsTest.java?root=Modeling_Pro ject&view=co

--=-KbtoLmtfA+RaEcD1Ux3x
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Gilbert,<BR>
<BR>
Thanks for your patience in dealing with my inaccuracies ... I hope the process has led you to an even better understanding of things than if I had been more accurate!&nbsp; ;-)&nbsp;&nbsp; I've been away from the code so long, now, that probably I should add a disclaimer to every message!<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Wed, 2009-09-16 at 18:58 +0200, Gilbert Mirenque wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian

&gt; Ah, but you are. The interactive console *is* the example. :-)
Ohh :)

&gt; That is only because you need to update the console to set EObject as
&gt; the implicit root class when parsing, unless your EClasses explicitly
&gt; extend EObject (which I generally wouldn't recommend).

Ok I now have the code from the example wizards. I now searched like
hell for something about the ParserOptions as you mentioned before.
Couldn't find anything. But fortunately I searched &quot;implicit root class&quot;
and found a little test suite of yourself [1]. There to see that its
name isn't PerserOptions but ParsingOptions ;) Now I could solve the
problem. In the class ModelingLevel in the method setContext(..) I added
those two lines in the M1 case:

OCL ocl = helper.getOCL();
ParsingOptions.setOption(ocl.getEnvironment(),
ParsingOptions.implicitRootClass(ocl.getEnvironment()),
EcorePackage.Literals.EOBJECT);

Now it works finally :) Thanks a lot again for your patience Christian.
Now I just need to export the modified plugin and add it into my eclipse.

best regards,
Gilbert

[1]
<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org .eclipse.ocl/tests/org.eclipse.ocl.ecore.tests/src/org/eclip se/ocl/ecore/tests/ParsingOptionsTest.java?root=Modeling_Pro ject&amp;view=co"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org .eclipse.ocl/tests/org.eclipse.ocl.ecore.tests/src/org/eclip se/ocl/ecore/tests/ParsingOptionsTest.java?root=Modeling_Pro ject&amp;view=co</A>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-KbtoLmtfA+RaEcD1Ux3x--
Re: How to check the types of containment? [message #486385 is a reply to message #486200] Thu, 17 September 2009 13:28 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

--=-I4t1+fFEDydCrJQswETF
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Gilbert,

See some replies in-line, below.

cW


On Wed, 2009-09-16 at 19:22 +0200, Gilbert Mirenque wrote:

> Hi Christian,
> only for completeness...
>
> > Content assist may not show you the "closure" iterator because it is not
> > OMG-standard OCL. However, it should parse.
> ...this result comes:
> Usage of non-standard "closure" iterator
>
> Can you please explain a little bit this expression:
>
> self.exportedEvents->forAll(ev|
> ev->closure(eContainer())->includes(self)
> )


What this is intended to do is to use the closure() iterator to compute
the set of container elements (recursively) of the element and check
that "self" is in it. This is one way of testing whether an object is
contained in self's subtree; another would be to iterate that sub-tree
looking for "ev."



> Especially closure(eContainer())does what exactly? Does it return all
> elements contain ev? Then it should only be one and self should be
> included in this closure, right. Do I understand this correctly?


Almost. The closure iterator computes the transitive closure of the
body expression evaluated on the elements of the source collection (in
this case, the singleton set "Set{ev}"). So, it finds the eContainer()
of ev, and the eContainer() of that, etc. until it finds no more new
eContainers.



> Just for curiosity. The following expressions parses correctly
>
> self.exportedEvents ->forAll(ev|
> self.eContents()
> ->select(x|
> x.oclIsTypeOf(CRUISeMetaModel::Event))
> ->includes(ev)
> )
>
> But I wonder about self.eContents(). Is the semantic like I used it here?


I don't understand your question. One point to note is that eContents()
is not recursive: it computes only the immediately contained elements.
The problem that the closure-of-eContainer approach addresses is that
EObject does not provide a variant of eAllContents() that yields a
collection; the tree iterator result is useless in OCL.



> best regards,
> Gilbert

--=-I4t1+fFEDydCrJQswETF
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Gilbert,<BR>
<BR>
See some replies in-line, below.<BR>
<BR>
cW<BR>
<BR>
<BR>
On Wed, 2009-09-16 at 19:22 +0200, Gilbert Mirenque wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,
only for completeness...

&gt; Content assist may not show you the &quot;closure&quot; iterator because it is not
&gt; OMG-standard OCL. However, it should parse.
....this result comes:
Usage of non-standard &quot;closure&quot; iterator

Can you please explain a little bit this expression:

self.exportedEvents-&gt;forAll(ev|
ev-&gt;closure(eContainer())-&gt;includes(self)
)
</PRE>
</BLOCKQUOTE>
<BR>
What this is intended to do is to use the closure() iterator to compute the set of container elements (recursively) of the element and check that &quot;self&quot; is in it.&nbsp; This is one way of testing whether an object is contained in self's subtree; another would be to iterate that sub-tree looking for &quot;ev.&quot;<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Especially closure(eContainer())does what exactly? Does it return all
elements contain ev? Then it should only be one and self should be
included in this closure, right. Do I understand this correctly?
</PRE>
</BLOCKQUOTE>
<BR>
Almost.&nbsp; The closure iterator computes the transitive closure of the body expression evaluated on the elements of the source collection (in this case, the singleton set &quot;Set{ev}&quot;).&nbsp; So, it finds the eContainer() of ev, and the eContainer() of that, etc. until it finds no more new eContainers.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Just for curiosity. The following expressions parses correctly

self.exportedEvents -&gt;forAll(ev|
self.eContents()
-&gt;select(x|
x.oclIsTypeOf(CRUISeMetaModel::Event))
-&gt;includes(ev)
)

But I wonder about self.eContents(). Is the semantic like I used it here?
</PRE>
</BLOCKQUOTE>
<BR>
I don't understand your question.&nbsp; One point to note is that eContents() is not recursive:&nbsp; it computes only the immediately contained elements.&nbsp; The problem that the closure-of-eContainer approach addresses is that EObject does not provide a variant of eAllContents() that yields a collection; the tree iterator result is useless in OCL.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
best regards,
Gilbert
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-I4t1+fFEDydCrJQswETF--
Re: How to check the types of containment? [message #486570 is a reply to message #486372] Fri, 18 September 2009 09:13 Go to previous message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Hi Christian,

> Thanks for your patience in dealing with my inaccuracies ... I hope the
> process has led you to an even better understanding of things than if I
> had been more accurate! ;-)

Yes, the process helped a lot to come more into it :)

best regards,
Gilbert
Previous Topic:Query for not all elements of a model
Next Topic:Navigating over eContainer()
Goto Forum:
  


Current Time: Thu Mar 28 12:44:21 GMT 2024

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

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

Back to the top