Home » Modeling » OCL » Problem with OCL interactive console.
| Problem with OCL interactive console. [message #69340] |
Mon, 30 March 2009 11:55  |
 Toñi Reina
Messages: 209
Registered: July 2009 |
Senior Member |
|
|
Hi all,
I'm just starting with mdt-ocl, and I'm trying to follow some
tutorials in order to understand and learn to use the tool, and also I'm
reading the Eclipse "Modeling Project: A Domain-Specific Language (DSL)
Toolkit".
I have different Eclipse versions and plugins installed: on of them
is the Eclipse Modeling Tools (includes Incubating components) that can
be downloaded from the download section in the Eclipse main site, and
other one is the Domain-Specific Language (DSL) Toolkit from the
Modeling Amalgamation Project. Both of them are supposed to include the
mdt-ocl-sdk packages, aren't they?
My problem arises when I'm trying to test the Interactive OCL console.
I'm following this tutorial
( http://sdqweb.ipd.uka.de/wiki/Evaluate_OCL_Constraints_for_M odel_Instances)
.. I switch on the Console, but when I try to switch on the "Interactive
OCL console" (Figure 2 in the tutorial), the drop down menu does not
show any item named Interactive OCL. I have tried the same thing in both
Eclipse versions (the EMT and DSL previously mentioned), but it doesn't
work in either of them.
Am I missing something?
Thanks in advance,
Toñi
|
|
|
| Re: Problem with OCL interactive console. [message #69377 is a reply to message #69340] |
Mon, 30 March 2009 17:58  |
Mark Melia
Messages: 142
Registered: July 2009 |
Senior Member |
|
|
Hi Toni,
The OCL console is generated when you run
org.eclipse.emf.ocl.examples.interpreter example. To do this, go to file -
new - examples - OCL Interpreter. This will create the plugin code for the
OCL console in your workspace. If you then run this as an eclipse app, in
the runtime the OCL console should be there.
HTH,
Mark
Toñi Reina Quintero wrote:
> Hi all,
> I'm just starting with mdt-ocl, and I'm trying to follow some
> tutorials in order to understand and learn to use the tool, and also I'm
> reading the Eclipse "Modeling Project: A Domain-Specific Language (DSL)
> Toolkit".
> I have different Eclipse versions and plugins installed: on of them
> is the Eclipse Modeling Tools (includes Incubating components) that can
> be downloaded from the download section in the Eclipse main site, and
> other one is the Domain-Specific Language (DSL) Toolkit from the
> Modeling Amalgamation Project. Both of them are supposed to include the
> mdt-ocl-sdk packages, aren't they?
> My problem arises when I'm trying to test the Interactive OCL console.
> I'm following this tutorial
> ( http://sdqweb.ipd.uka.de/wiki/Evaluate_OCL_Constraints_for_M odel_Instances)
> .. I switch on the Console, but when I try to switch on the "Interactive
> OCL console" (Figure 2 in the tutorial), the drop down menu does not
> show any item named Interactive OCL. I have tried the same thing in both
> Eclipse versions (the EMT and DSL previously mentioned), but it doesn't
> work in either of them.
> Am I missing something?
> Thanks in advance,
> Toñi
|
|
|
| Re: Problem with OCL interactive console. [message #69437 is a reply to message #69377] |
Tue, 31 March 2009 14:56 |
Toñi Reina
Messages: 209
Registered: July 2009 |
Senior Member |
|
|
Thanks Mark, now it works. Just two little questions more.
1. Why has not the OCL Interpreter been included as an Eclipse plugin?
2. If I create a jar file with the
org.eclipse.emf.ocl.examples.interpreter project that has been created
when running the example, this jar file could be included as a plugin
and as a consequence, I don't need to have two Eclipse instances
running to be able to use the interpreter. Am I right?
Regards,
Toñi
Mark Melia escribió:
> Hi Toni,
>
> The OCL console is generated when you run
> org.eclipse.emf.ocl.examples.interpreter example. To do this, go to file
> - new - examples - OCL Interpreter. This will create the plugin code for
> the OCL console in your workspace. If you then run this as an eclipse
> app, in the runtime the OCL console should be there.
>
> HTH,
> Mark
>
> Toñi Reina Quintero wrote:
>
>> Hi all,
>
>> I'm just starting with mdt-ocl, and I'm trying to follow some
>> tutorials in order to understand and learn to use the tool, and also
>> I'm reading the Eclipse "Modeling Project: A Domain-Specific Language
>> (DSL) Toolkit".
>
>> I have different Eclipse versions and plugins installed: on of them
>> is the Eclipse Modeling Tools (includes Incubating components) that
>> can be downloaded from the download section in the Eclipse main site,
>> and other one is the Domain-Specific Language (DSL) Toolkit from the
>> Modeling Amalgamation Project. Both of them are supposed to include
>> the mdt-ocl-sdk packages, aren't they?
>
>> My problem arises when I'm trying to test the Interactive OCL
>> console. I'm following this tutorial
>> ( http://sdqweb.ipd.uka.de/wiki/Evaluate_OCL_Constraints_for_M odel_Instances)
>>
>> .. I switch on the Console, but when I try to switch on the
>> "Interactive OCL console" (Figure 2 in the tutorial), the drop down
>> menu does not show any item named Interactive OCL. I have tried the
>> same thing in both Eclipse versions (the EMT and DSL previously
>> mentioned), but it doesn't work in either of them.
>
>> Am I missing something?
>
>> Thanks in advance,
>> Toñi
>
>
|
|
|
| Re: Problem with OCL interactive console. [message #69457 is a reply to message #69437] |
Tue, 31 March 2009 19:01 |
Mark Melia
Messages: 142
Registered: July 2009 |
Senior Member |
|
|
Hi Toñi
answers inline...
> Thanks Mark, now it works. Just two little questions more.
> 1. Why has not the OCL Interpreter been included as an Eclipse plugin?
I would think that this is an example of how you could implement an
interpreter using the OCL API. I think Christian, or one of the guys on
the project, might have more details on this?
> 2. If I create a jar file with the
> org.eclipse.emf.ocl.examples.interpreter project that has been created
> when running the example, this jar file could be included as a plugin
> and as a consequence, I don't need to have two Eclipse instances
> running to be able to use the interpreter. Am I right?
AFAIK if you export it as a deployable plug-in it should work as described
above.
HTH,
Mark
> Regards,
> Toñi
> Mark Melia escribió:
>> Hi Toni,
>>
>> The OCL console is generated when you run
>> org.eclipse.emf.ocl.examples.interpreter example. To do this, go to file
>> - new - examples - OCL Interpreter. This will create the plugin code for
>> the OCL console in your workspace. If you then run this as an eclipse
>> app, in the runtime the OCL console should be there.
>>
>> HTH,
>> Mark
>>
>> Toñi Reina Quintero wrote:
>>
>>> Hi all,
>>
>>> I'm just starting with mdt-ocl, and I'm trying to follow some
>>> tutorials in order to understand and learn to use the tool, and also
>>> I'm reading the Eclipse "Modeling Project: A Domain-Specific Language
>>> (DSL) Toolkit".
>>
>>> I have different Eclipse versions and plugins installed: on of them
>>> is the Eclipse Modeling Tools (includes Incubating components) that
>>> can be downloaded from the download section in the Eclipse main site,
>>> and other one is the Domain-Specific Language (DSL) Toolkit from the
>>> Modeling Amalgamation Project. Both of them are supposed to include
>>> the mdt-ocl-sdk packages, aren't they?
>>
>>> My problem arises when I'm trying to test the Interactive OCL
>>> console. I'm following this tutorial
>>>
( http://sdqweb.ipd.uka.de/wiki/Evaluate_OCL_Constraints_for_M odel_Instances)
>>>
>>> .. I switch on the Console, but when I try to switch on the
>>> "Interactive OCL console" (Figure 2 in the tutorial), the drop down
>>> menu does not show any item named Interactive OCL. I have tried the
>>> same thing in both Eclipse versions (the EMT and DSL previously
>>> mentioned), but it doesn't work in either of them.
>>
>>> Am I missing something?
>>
>>> Thanks in advance,
>>> Toñi
>>
>>
|
|
|
| Re: Problem with OCL interactive console. [message #69476 is a reply to message #69457] |
Tue, 31 March 2009 21:38 |
Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
Hi, Mark,
Yes, the official purpose of this example is to illustrate how to use
the OCL API. It is not supported as a component of the SDK or the
run-time, as that was always beyond the team's resources. However, it
has been sufficiently popular that Rich includes it in the Amalgamation
DSLTK package.
There is a bugzilla, linked a few times already in previous postings,
that has an in-progress next generation example that illustrates more of
the OCL API's capabilities:
http://bugs.eclipse.org/259922
Let's see whether the new OCL team develops that any further, or what
other cool editing/debugging features they dream up!
Cheers,
Christian
Mark Melia wrote:
> Hi Toñi
> answers inline...
>
>> Thanks Mark, now it works. Just two little questions more.
>> 1. Why has not the OCL Interpreter been included as an Eclipse plugin?
>
> I would think that this is an example of how you could implement an
> interpreter using the OCL API. I think Christian, or one of the guys on
> the project, might have more details on this?
>
>> 2. If I create a jar file with the
>> org.eclipse.emf.ocl.examples.interpreter project that has been created
>> when running the example, this jar file could be included as a plugin
>> and as a consequence, I don't need to have two Eclipse instances
>> running to be able to use the interpreter. Am I right?
>
> AFAIK if you export it as a deployable plug-in it should work as
> described above.
>
> HTH,
> Mark
>
>> Regards,
>> Toñi
>
>
>> Mark Melia escribió:
>>> Hi Toni,
>>>
>>> The OCL console is generated when you run
>>> org.eclipse.emf.ocl.examples.interpreter example. To do this, go to
>>> file - new - examples - OCL Interpreter. This will create the plugin
>>> code for the OCL console in your workspace. If you then run this as
>>> an eclipse app, in the runtime the OCL console should be there.
>>>
>>> HTH,
>>> Mark
>>>
>>> Toñi Reina Quintero wrote:
>>>
>>>> Hi all,
>>>
>>>> I'm just starting with mdt-ocl, and I'm trying to follow some
>>>> tutorials in order to understand and learn to use the tool, and also
>>>> I'm reading the Eclipse "Modeling Project: A Domain-Specific
>>>> Language (DSL) Toolkit".
>>>
>>>> I have different Eclipse versions and plugins installed: on of
>>>> them is the Eclipse Modeling Tools (includes Incubating components)
>>>> that can be downloaded from the download section in the Eclipse main
>>>> site, and other one is the Domain-Specific Language (DSL) Toolkit
>>>> from the
>>>> Modeling Amalgamation Project. Both of them are supposed to include
>>>> the mdt-ocl-sdk packages, aren't they?
>>>
>>>> My problem arises when I'm trying to test the Interactive OCL
>>>> console. I'm following this tutorial
> ( http://sdqweb.ipd.uka.de/wiki/Evaluate_OCL_Constraints_for_M odel_Instances)
>
>>>>
>>>> .. I switch on the Console, but when I try to switch on the
>>>> "Interactive OCL console" (Figure 2 in the tutorial), the drop down
>>>> menu does not show any item named Interactive OCL. I have tried the
>>>> same thing in both Eclipse versions (the EMT and DSL previously
>>>> mentioned), but it doesn't work in either of them.
>>>
>>>> Am I missing something?
>>>
>>>> Thanks in advance,
>>>> Toñi
>>>
>>>
>
>
|
|
| |
| Re: Problem with OCL interactive console. [message #69573 is a reply to message #69536] |
Thu, 02 April 2009 17:55 |
|
--=-DTTF+/mfJ1/w3zTHgeSg
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Achilleas,
See some replies in-line, below.
HTH,
Christian
On Thu, 2009-04-02 at 13:17 +0000, Achilleas wrote:
> Hi Christian,
>
> I have searched the newsgroup and from what I concluded from the postings
> is that the ocl console does not support validation at the M1 level? Am I
> correct on this?
That's right. It only parses them and reports whether the parse was
successful.
The next generation of the example (in progress) addresses that problem
by providing access to all of the capabilities of the environment
including evaluation of M1 constraints on dynamic instances (Ecore
metamodel) or InstanceSpecifications (UML metamodel). See the patch
attached to:
http://bugs.eclipse.org/259922
> If we assume that we have a class "A" in our metamodel with an attribute
> "name" then we can write the following constraints:
>
> M2: context A: self.name (this will return the name we assign for the
> model)
>
> M1: context A: self.name (and this will again return the name we assign to
> the model) Am I write on this?
No. The M1 level only makes sense for metamodels that OCL understands
as modeling languages that are compatible with MOF. That is, if A
represents the notion of a "class" and is related to some other
metaclass "B" that represents the notion of a "property" or "attribute",
then you can plug in support for OCL expressions in terms of your
metamodel. That is, if your model can be used for describing models as
Ecore and UML can, then you can also use OCL to define constraints in
those models. *These* constraints are the M1 constraints.
The M2/M1 naming is relative to the metamodel (Ecore or UML). As your
model isn't really a metamodel, it is already an M1 instance.
Effectively, the Ms all slide down a level, so that what the interpreter
calls "M2" is really M1 as far as your models are concerned. The
labeling is, perhaps, unfortunate.
> Moreover, if we assume now that we have a class "A" and a class "B" in our
> 2nd metamodel with a containment "hasBs" from "A" to "B" and "B" having an
> attribute "name". Then:
>
> M2: context A: self.hasBs->select(b:B | b.name = 'Achilleas').name (this
> will return the instance of B that has the name Achilleas, so "Achilleas"
> will be returned)
Correct.
> M1: How should the constraint be written at this level to return the name
> "Achilleas" ? Can it be written in the form:
>
> context A: self.name ??? What if there are multiple Bs contained in A??
As I mentioned, this isn't really applicable to your case.
> Could you explain to me what is the difference in writing these
> constraints? Or point me to a tutorial that can help me grasp the
> difference.
M2 constraints are metamodel constraints: they are well-formedness
rules for the instances of your model. The classical case is where your
model is a metamodel (like Ecore or UML) in which case M2 constraints
determine what a valid model looks like.
M1 constraints are elements of your model that constrain the structure
of run-time instances of the system that you are modeling. This only
really applies when your model is a MOF-compatible model of a
class-oriented system (i.e., a metamodel).
As a concrete example, consider the Library model. An "M2
constraint" (as labeled in the console) in the Library model might
determine what a valid Book looks like. This really is an M1 constraint
with respect to Ecore, which is your metamodel. The library package is
not a metamodel. If it were, then an instance of a Book might represent
some class of things in your system. But, you can't "instantiate" Moby
Dick, for example. It isn't a classifier, but is just an object,
representing itself. It can't define constraints that describe what a
valid moby-dick is because there aren't moby-dicks; there's just Moby
Dick.
I hope that's as clear as mud. ;-)
>
> Sorry if I overwhelmed you with this post!
>
> Thanks a lot,
>
> Achilleas
>
--=-DTTF+/mfJ1/w3zTHgeSg
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, Achilleas,<BR>
<BR>
See some replies in-line, below.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Thu, 2009-04-02 at 13:17 +0000, Achilleas wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,
I have searched the newsgroup and from what I concluded from the postings
is that the ocl console does not support validation at the M1 level? Am I
correct on this?
</PRE>
</BLOCKQUOTE>
<BR>
That's right. It only parses them and reports whether the parse was successful.<BR>
<BR>
The next generation of the example (in progress) addresses that problem by providing access to all of the capabilities of the environment including evaluation of M1 constraints on dynamic instances (Ecore metamodel) or InstanceSpecifications (UML metamodel). See the patch attached to:<BR>
<BR>
<TT> </TT><TT><FONT COLOR="#000000"><A HREF="http://bugs.eclipse.org/259922">http://bugs.eclipse.org/259922</A></FONT></TT><BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
If we assume that we have a class "A" in our metamodel with an attribute
"name" then we can write the following constraints:
M2: context A: self.name (this will return the name we assign for the
model)
M1: context A: self.name (and this will again return the name we assign to
the model) Am I write on this?
</PRE>
</BLOCKQUOTE>
<BR>
No. The M1 level only makes sense for metamodels that OCL understands as modeling languages that are compatible with MOF. That is, if A represents the notion of a "class" and is related to some other metaclass "B" that represents the notion of a "property" or "attribute", then you can plug in support for OCL expressions in terms of your metamodel. That is, if your model can be used for describing models as Ecore and UML can, then you can also use OCL to define constraints in those models. *These* constraints are the M1 constraints.<BR>
<BR>
The M2/M1 naming is relative to the metamodel (Ecore or UML). As your model isn't really a metamodel, it is already an M1 instance. Effectively, the Ms all slide down a level, so that what the interpreter calls "M2" is really M1 as far as your models are concerned. The labeling is, perhaps, unfortunate.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Moreover, if we assume now that we have a class "A" and a class "B" in our
2nd metamodel with a containment "hasBs" from "A" to "B" and "B" having an
attribute "name". Then:
M2: context A: self.hasBs->select(b:B | b.name = 'Achilleas').name (this
will return the instance of B that has the name Achilleas, so "Achilleas"
will be returned)
</PRE>
</BLOCKQUOTE>
<BR>
Correct.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
M1: How should the constraint be written at this level to return the name
"Achilleas" ? Can it be written in the form:
context A: self.name ??? What if there are multiple Bs contained in A??
</PRE>
</BLOCKQUOTE>
As I mentioned, this isn't really applicable to your case.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Could you explain to me what is the difference in writing these
constraints? Or point me to a tutorial that can help me grasp the
difference.
</PRE>
</BLOCKQUOTE>
M2 constraints are metamodel constraints: they are well-formedness rules for the instances of your model. The classical case is where your model is a metamodel (like Ecore or UML) in which case M2 constraints determine what a valid model looks like.<BR>
<BR>
M1 constraints are elements of your model that constrain the structure of run-time instances of the system that you are modeling. This only really applies when your model is a MOF-compatible model of a class-oriented system (i.e., a metamodel).<BR>
<BR>
As a concrete example, consider the Library model. An "M2 constraint" (as labeled in the console) in the Library model might determine what a valid Book looks like. This really is an M1 constraint with respect to Ecore, which is your metamodel. The library package is not a metamodel. If it were, then an instance of a Book might represent some class of things in your system. But, you can't "instantiate" Moby Dick, for example. It isn't a classifier, but is just an object, representing itself. It can't define constraints that describe what a valid moby-dick is because there aren't moby-dicks; there's just Moby Dick.<BR>
<BR>
I hope that's as clear as mud. ;-)<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Sorry if I overwhelmed you with this post!
Thanks a lot,
Achilleas
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-DTTF+/mfJ1/w3zTHgeSg--
|
|
|
| Re: Problem with OCL interactive console. [message #69615 is a reply to message #69573] |
Fri, 03 April 2009 17:39 |
Achilleas
Messages: 88
Registered: July 2009 |
Member |
|
|
Christian W. Damus wrote:
> Hi, Achilleas,
> See some replies in-line, below.
> HTH,
> Christian
> On Thu, 2009-04-02 at 13:17 +0000, Achilleas wrote:
>> Hi Christian,
>>
>> I have searched the newsgroup and from what I concluded from the postings
>> is that the ocl console does not support validation at the M1 level? Am I
>> correct on this?
> That's right. It only parses them and reports whether the parse was
> successful.
> The next generation of the example (in progress) addresses that problem
> by providing access to all of the capabilities of the environment
> including evaluation of M1 constraints on dynamic instances (Ecore
> metamodel) or InstanceSpecifications (UML metamodel). See the patch
> attached to:
> http://bugs.eclipse.org/259922
>> If we assume that we have a class "A" in our metamodel with an attribute
>> "name" then we can write the following constraints:
>>
>> M2: context A: self.name (this will return the name we assign for the
>> model)
>>
>> M1: context A: self.name (and this will again return the name we assign to
>> the model) Am I write on this?
> No. The M1 level only makes sense for metamodels that OCL understands
> as modeling languages that are compatible with MOF. That is, if A
> represents the notion of a "class" and is related to some other
> metaclass "B" that represents the notion of a "property" or "attribute",
> then you can plug in support for OCL expressions in terms of your
> metamodel. That is, if your model can be used for describing models as
> Ecore and UML can, then you can also use OCL to define constraints in
> those models. *These* constraints are the M1 constraints.
> The M2/M1 naming is relative to the metamodel (Ecore or UML). As your
> model isn't really a metamodel, it is already an M1 instance.
> Effectively, the Ms all slide down a level, so that what the interpreter
> calls "M2" is really M1 as far as your models are concerned. The
> labeling is, perhaps, unfortunate.
>> Moreover, if we assume now that we have a class "A" and a class "B" in our
>> 2nd metamodel with a containment "hasBs" from "A" to "B" and "B" having an
>> attribute "name". Then:
>>
>> M2: context A: self.hasBs->select(b:B | b.name = 'Achilleas').name (this
>> will return the instance of B that has the name Achilleas, so "Achilleas"
>> will be returned)
> Correct.
>> M1: How should the constraint be written at this level to return the name
>> "Achilleas" ? Can it be written in the form:
>>
>> context A: self.name ??? What if there are multiple Bs contained in A??
> As I mentioned, this isn't really applicable to your case.
>> Could you explain to me what is the difference in writing these
>> constraints? Or point me to a tutorial that can help me grasp the
>> difference.
> M2 constraints are metamodel constraints: they are well-formedness
> rules for the instances of your model. The classical case is where your
> model is a metamodel (like Ecore or UML) in which case M2 constraints
> determine what a valid model looks like.
> M1 constraints are elements of your model that constrain the structure
> of run-time instances of the system that you are modeling. This only
> really applies when your model is a MOF-compatible model of a
> class-oriented system (i.e., a metamodel).
> As a concrete example, consider the Library model. An "M2
> constraint" (as labeled in the console) in the Library model might
> determine what a valid Book looks like. This really is an M1 constraint
> with respect to Ecore, which is your metamodel. The library package is
> not a metamodel. If it were, then an instance of a Book might represent
> some class of things in your system. But, you can't "instantiate" Moby
> Dick, for example. It isn't a classifier, but is just an object,
> representing itself. It can't define constraints that describe what a
> valid moby-dick is because there aren't moby-dicks; there's just Moby
> Dick.
> I hope that's as clear as mud. ;-)
>>
>> Sorry if I overwhelmed you with this post!
>>
>> Thanks a lot,
>>
>> Achilleas
>>
Hi Christian,
Thanks for the detailed explanation. It clarified and verified a lot of
things.
Just to re-clarify what I understood though ;-)
Assuming that we have the following metalevels:
M3: Ecore meta-metalanguage
M2: Ecore metamodel (which I include)
M1: Ecore-based model (which I also include)
M0: Java code (which I also include)
At level M3 we have the constraints defined for the Ecore
meta-metalanguage that ensure the integrity of the Ecore metamodels - like
the one I have defined. Correct?
At level M2 we have the constraints defined for the Ecore metamodel (in
gmfmap - shown as notes on the metamodel diagram picture included) that
ensure the integrity of the Ecore-based models - like the one I have
defined. Correct?
At level M1 we have the Interactive OCL console that allows to validate
the same constraints as the ones defined at level M2 (in the .gmfmap) - as
shown on the model diagram picture included.
> M1 constraints are elements of your model that constrain the structure
> of run-time instances of the system that you are modeling. This only
> really applies when your model is a MOF-compatible model of a
> class-oriented system (i.e., a metamodel).
Therefore from what you set above if my model contained a "value" property
(i.e. "16") for the "age" property then I could define M1 constraints
[i.e. self.classProperties->any(p:Property | p.name = 'age').value > 18 ]
in my understanding. But my model would not be a MOF-compatible model of a
class-oriented system. Do you agree with this?
Otherwise if there is no "value" property then the constraints can only be
enforced on run-time instances of the system that I am modeling; i.e. in
the Java code generated. Then my model would be a MOF-compatible model of a
class-oriented system. Do you agree with this?
Therefore the library example in my understanding is not a MOF-compatible
model of a class-oriented system since it specifies instance values (i.e.
"Mobby dick") but rather a (run-time) instance of the system. Do you agree
with this reasoning?
http://privatewww.essex.ac.uk/~aachila/links.htm
I hope that's clear also. ;-)
Thanks,
Achilleas
|
|
|
| Re: Problem with OCL interactive console. [message #69634 is a reply to message #69615] |
Sun, 05 April 2009 01:05 |
| Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
Hi, Achilleas,
Replies in-line, below.
Cheers,
Christian
Achilleas wrote:
-----8<-----
>
> Hi Christian,
>
> Thanks for the detailed explanation. It clarified and verified a lot of
> things.
>
> Just to re-clarify what I understood though ;-)
>
> Assuming that we have the following metalevels:
>
> M3: Ecore meta-metalanguage
> M2: Ecore metamodel (which I include)
> M1: Ecore-based model (which I also include)
> M0: Java code (which I also include)
>
> At level M3 we have the constraints defined for the Ecore
> meta-metalanguage that ensure the integrity of the Ecore metamodels -
> like the one I have defined. Correct?
There is only one Ecore metamodel. It is Ecore. There are extensions
of it, of course, like OCL-for-Ecore ...
I see Ecore as a metamodel at M2. In the OMG modeling stack, M3 is
(E)MOF, which is used to define metamodels (the M2s). Metamodels are
the primary instances of "modeling languages" such as UML, BPMN, CWM,
IMM, etc. that we use to describe software systems, business systems,
information systems, etc.
Effectively, Ecore is an implementation of EMOF, so it resides at both
the M3 and M2 levels. By induction, this demonstrates that Ecore is a
self-describing metamodel and, therefore, resides at *every* level (it
depends on the role of any particular Ecore instance in any particular
situation).
Constraints at M3 specify what a valid modeling language (i.e.,
metamodel) looks like.
> At level M2 we have the constraints defined for the Ecore metamodel (in
> gmfmap - shown as notes on the metamodel diagram picture included) that
> ensure the integrity of the Ecore-based models - like the one I have
> defined. Correct?
Correct. These constraints specify what a valid Ecore model looks like,
that can correctly describe a system of classes in a software system
(usually targeting Java, but cf. the EMF run-time for .Net).
> At level M1 we have the Interactive OCL console that allows to validate
> the same constraints as the ones defined at level M2 (in the .gmfmap) -
> as shown on the model diagram picture included.
The console doesn't reside in any particular modeling level. It is on a
sliding scale, depending on what kind of model it is working on. This
is because the metamodels that it is based on (Ecore and UML) are
self-describing, so they reside on all levels, as I mentioned already.
M1 constraints are elements of a model of a software system that specify
what are the valid run-time states of that system. Like anything else
in a model at the M1 level, they describe instances of the level below.
In the case of M1, the level below is M0 which is the running system.
>> M1 constraints are elements of your model that constrain the structure
>> of run-time instances of the system that you are modeling. This only
>> really applies when your model is a MOF-compatible model of a
>> class-oriented system (i.e., a metamodel).
>
> Therefore from what you set above if my model contained a "value"
> property (i.e. "16") for the "age" property then I could define M1
> constraints [i.e. self.classProperties->any(p:Property | p.name =
> 'age').value > 18 ] in my understanding. But my model would not be a
> MOF-compatible model of a
> class-oriented system. Do you agree with this?
In your model, you can only define M1 constraints, because your model is
at level M1. This particular constraint uses a fictitious reflection
capability "classProperties" to cross meta-levels to M2 to perform
reflection on the class of "self", then a fictitious "value" capability
of the metamodel to return to M1 (I would have expected it rather to be
an operation call "value(self)", otherwise how would it know which
instance that has the property from which to get the value?).
For a constraint in the model (M1) it would be much simpler just to do:
self.age > 18
> Otherwise if there is no "value" property then the constraints can only
> be enforced on run-time instances of the system that I am modeling; i.e.
> in the Java code generated. Then my model would be a MOF-compatible
> model of a
> class-oriented system. Do you agree with this?
But, that is the point of constraints in your model (M1): they specify
valid states of the run-time system (M0). It simply doesn't make sense
to attempt to specify constraints on the structure of the model within a
model, itself (M2 constraints).
> Therefore the library example in my understanding is not a
> MOF-compatible model of a class-oriented system since it specifies
> instance values (i.e. "Mobby dick") but rather a (run-time) instance of
> the system. Do you agree with this reasoning?
Yes, this is how I see it. The Library model describes classes in a
software system that tracks library inventory. It is entirely
consistent with the modeling-stack notion of what an M1 instance is.
The fact that the M0 objects in the running Java system themselves only
represent real-world libraries, books, lenders, etc. is not relevant.
The Library model could just as easily have included classes such as
LibraryManagementSystem, AccountInfoUIPanel, and others that have no
real-world analogues but are "just" constituents of the software.
> http://privatewww.essex.ac.uk/~aachila/links.htm
>
> I hope that's clear also. ;-)
>
> Thanks,
>
> Achilleas
>
>
>
|
|
| |
| Re: Problem with OCL interactive console. [message #69674 is a reply to message #69654] |
Mon, 06 April 2009 12:49 |
|
--=-S5AJFn4YlcHh6I/fZa4L
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Achilleas,
I'm glad I was able to help! It helps me to think these issues through
from time to time, also, to make sure that I still understand the
subject and can discuss it coherently. :-)
cW
On Mon, 2009-04-06 at 09:50 +0000, Achilleas wrote:
> Hi Christian,
>
> Thanks for the comments. It helped me clarify many aspects on OCL
> constraints and ensure that my understanding is appropriate.
>
> In some cases my questions were not perfectly clear but you still provided
> me the answers I was seeking.
>
> Thanks once again for our discussion.
>
> Regards,
>
> Achilleas
>
--=-S5AJFn4YlcHh6I/fZa4L
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, Achilleas,<BR>
<BR>
I'm glad I was able to help! It helps me to think these issues through from time to time, also, to make sure that I still understand the subject and can discuss it coherently. :-)<BR>
<BR>
cW<BR>
<BR>
<BR>
On Mon, 2009-04-06 at 09:50 +0000, Achilleas wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,
Thanks for the comments. It helped me clarify many aspects on OCL
constraints and ensure that my understanding is appropriate.
In some cases my questions were not perfectly clear but you still provided
me the answers I was seeking.
Thanks once again for our discussion.
Regards,
Achilleas
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-S5AJFn4YlcHh6I/fZa4L--
|
|
|
Goto Forum:
Current Time: Fri Apr 19 20:09:10 GMT 2024
Powered by FUDForum. Page generated in 0.03875 seconds |
] 
Search
Help
Register
Login
Home
