Dear All,
we need a GUI for rFSM that, given the description on rFSM, shows a
cool graphical window with the currents state and the events
exchanged.
In my lab there is a student that can works on it so there are
suggestions to start?
Regards
Fabrizio Boriero
GUI for rFSN
Hi Fabrizio,
On Mon, Jul 02, 2012 at 11:29:14AM +0200, Fabrizio Boriero wrote:
> we need a GUI for rFSM that, given the description on rFSM, shows a
> cool graphical window with the currents state and the events
> exchanged.
We too :-)
> In my lab there is a student that can works on it so there are
> suggestions to start?
Great! It depends on how far you would like to push it. The quick and
dirty way would be to use a graphviz based solution. In rFSM there is
already rfsm2uml.lua that can "dump" rFSM instances to graphviz dot
format. The output of this is in general more or less readable and
(certainly) better than nothing.
More work, but with a potentially much better result would be to
implement a real statechart layout algorithm (google for "automatic
statechart layout". Unfortunately, I couldn't find any code for this
so far.
Alterantively, the KIELER project promises to extend Eclipse editors
with automatic layout. Thinking of it, they're likely to have usable
(licensewise) layout algorithm code.
If you start anything regarding this, it would be great if you could
keep this list updated...
Markus
GUI for rFSN
On Mon, Jul 2, 2012 at 12:43 PM, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> Hi Fabrizio,
>
> On Mon, Jul 02, 2012 at 11:29:14AM +0200, Fabrizio Boriero wrote:
>
>> we need a GUI for rFSM that, given the description on rFSM, shows a
>> cool graphical window with the currents state and the events
>> exchanged.
>
> We too :-)
>
>> In my lab there is a student that can works on it so there are
>> suggestions to start?
>
> Great! It depends on how far you would like to push it. The quick and
> dirty way would be to use a graphviz based solution. In rFSM there is
> already rfsm2uml.lua that can "dump" rFSM instances to graphviz dot
> format. The output of this is in general more or less readable and
> (certainly) better than nothing.
>
> More work, but with a potentially much better result would be to
> implement a real statechart layout algorithm (google for "automatic
> statechart layout". Unfortunately, I couldn't find any code for this
> so far.
>
> Alterantively, the KIELER project promises to extend Eclipse editors
> with automatic layout. Thinking of it, they're likely to have usable
> (licensewise) layout algorithm code.
>
> If you start anything regarding this, it would be great if you could
> keep this list updated...
>
> Markus
>
On the Eclipse side:
You could use XCore to implement an Ecore based model for the state charts.
Then use Graphiti to build the editor.
Google for "automatic layout of diagrams" or something similar.
The icing on the cake would be to have real time updates of the
diagram by updating the model using either a TCP/IP port for in memory
or direct file manipulation of the model which would update the
graphical representation. You could also use CORBA to communicate to
TaskContexts... and this has been implemented already.
http://wiki.eclipse.org/Xcore
http://www.eclipse.org/graphiti/
http://www.eclipse.org/forums/index.php/m/840078/?srch=diagram+layouts#m...
GUI for rFSN
On Wed, Jul 04, 2012 at 10:10:41PM +0200, Hugo Garcia wrote:
> On the Eclipse side:
>
> You could use XCore to implement an Ecore based model for the state charts.
> Then use Graphiti to build the editor.
> Google for "automatic layout of diagrams" or something similar.
> The icing on the cake would be to have real time updates of the
> diagram by updating the model using either a TCP/IP port for in memory
> or direct file manipulation of the model which would update the
> graphical representation. You could also use CORBA to communicate to
> TaskContexts... and this has been implemented already.
>
> http://wiki.eclipse.org/Xcore
> http://www.eclipse.org/graphiti/
> http://www.eclipse.org/forums/index.php/m/840078/?srch=diagram+layouts#m...
Yet another idea is to look at the following project: http://www.yakindu.org/
It seems, that a model-driven Eclipse GUI for state machines is already there.
And there is an even bigger initiative here:
http://eclipse.org/proposals/tools.damos/
GUI for rFSN
On Tue, 17 Jul 2012, Piotr Trojanek wrote:
> On Wed, Jul 04, 2012 at 10:10:41PM +0200, Hugo Garcia wrote:
>> On the Eclipse side:
>>
>> You could use XCore to implement an Ecore based model for the state charts.
>> Then use Graphiti to build the editor.
>> Google for "automatic layout of diagrams" or something similar.
>> The icing on the cake would be to have real time updates of the
>> diagram by updating the model using either a TCP/IP port for in memory
>> or direct file manipulation of the model which would update the
>> graphical representation. You could also use CORBA to communicate to
>> TaskContexts... and this has been implemented already.
>>
>> http://wiki.eclipse.org/Xcore
>> http://www.eclipse.org/graphiti/
>> http://www.eclipse.org/forums/index.php/m/840078/?srch=diagram+layouts#m...
>
> Yet another idea is to look at the following project: http://www.yakindu.org/
> It seems, that a model-driven Eclipse GUI for state machines is already there.
Yes, but missing out on the "meta modelling" :-( That is: it is yet another
model-level only effort, meaning that one has to take or leave the Yakindu
semantics, together with the _implementation_. Correct me if I am wrong!
> And there is an even bigger initiative here:
> http://eclipse.org/proposals/tools.damos/
I definitely hope this proposal comes out of the proposal phase!
GUI for rFSN
> >Yet another idea is to look at the following project:
> >http://www.yakindu.org/ It seems, that a model-driven Eclipse GUI for state
> >machines is already there.
>
> Yes, but missing out on the "meta modelling" :-( That is: it is yet another
> model-level only effort, meaning that one has to take or leave the Yakindu
> semantics, together with the _implementation_. Correct me if I am wrong!
The underlying meta-models seem to be defined in Ecore (for example
http://code.google.com/a/eclipselabs.org/p/yakindu/source/browse/#svn%2F...).
I guess, that one can just pickup those meta-models, tune them and propagate
the modifications into the tools.
> >And there is an even bigger initiative here:
> >http://eclipse.org/proposals/tools.damos/
>
> I definitely hope this proposal comes out of the proposal phase!
These tools are developed by itemis company (founded 2003, ± 145 people) that
has a strong position in the Eclipse/Modelling community. It seems, that there
is already a working prototype. I think, that an initial release is just a
matter of 3-4 months.
GUI for rFSN
On Wed, 18 Jul 2012, Piotr Trojanek wrote:
>>> Yet another idea is to look at the following project:
>>> http://www.yakindu.org/ It seems, that a model-driven Eclipse GUI for state
>>> machines is already there.
>>
>> Yes, but missing out on the "meta modelling" :-( That is: it is yet another
>> model-level only effort, meaning that one has to take or leave the Yakindu
>> semantics, together with the _implementation_. Correct me if I am wrong!
>
> The underlying meta-models seem to be defined in Ecore (for example
> http://code.google.com/a/eclipselabs.org/p/yakindu/source/browse/#svn%2F...).
Of course, because it is Eclipse. But:
- ecore is not sufficient as a meta model (where is "behaviour" for
example?)
- it's too linked to the Eclipse ecosystem
> I guess, that one can just pickup those meta-models, tune them and propagate
> the modifications into the tools.
You will be surprised how much Eclipse lock-in you will encounter... :-(
>>> And there is an even bigger initiative here:
>>> http://eclipse.org/proposals/tools.damos/
>>
>> I definitely hope this proposal comes out of the proposal phase!
>
> These tools are developed by itemis company (founded 2003, ± 145 people) that
> has a strong position in the Eclipse/Modelling community. It seems, that there
> is already a working prototype. I think, that an initial release is just a
> matter of 3-4 months.
> Piotr Trojanek
Herman
GUI for rFSN
On Wed, Jul 18, 2012 at 11:28:26AM +0200, Herman Bruyninckx wrote:
> Of course, because it is Eclipse. But:
> - ecore is not sufficient as a meta model (where is "behaviour" for
> example?)
I am not sure what kind of "behaviour" do you mean, but if you are talking
about execution semantics (?), then it is should NOT be defined by the
meta-model. The goal of meta-modeling is to capture the concepts of a domain
and their relationships. Nothing more.
If one want to attach some "meaning" to the meta-model, then the way to go is
the model transformation - preferably into a domain with already defined
"meaning" (i.e., translational semantics).
For example, the "behaviour" of C++ is not specified by its syntax tree. It is
(formally) specified by a compiler, which translates C++ into assembler.
> - it's too linked to the Eclipse ecosystem
The Ecore is aligned with OMG MOF. It is not the fault of Eclipse that nobody
else even try to follow this standard :(
Alternatives like GOPPR (the metameta-model of MetaEdit+) in my opinion are
even worse. On the other hand EBNF grammars (like in the case of GenoM) fail to
capture a lot of information and must rely on logic that is "hidden" inside a
"compiler." Can you recommend some alternative solution to efficaciously
capture what the Ecore is capturing, but without locking to a particular
ecosystem?
> >I guess, that one can just pickup those meta-models, tune them and propagate
> >the modifications into the tools.
>
> You will be surprised how much Eclipse lock-in you will encounter... :-(
AFAIK none of the textual/graphical editors use the Ecore directly, but rely on
a set of Java classes generated from the Ecore by "genmodel." One can just take
these classes in implement whatever you want with them. In general, it is also
possible to develop Ecore->C++/C#/whatever transformation and continue in
another programming language... (but it is not the main focus of Eclipse
Modeling Project).
The reason to "lock-in" with Eclipse is that it provides some nice tools for
building a complete toolset (including model edition, validation and
transformation). If one can afford building such a toolset by mixing various
technologies, then there is no reason for not doing so. The "Eclipse-way" is to
do it faster and cheaper (and probably also cleaner).
GUI for rFSN
On Wed, 18 Jul 2012, Piotr Trojanek wrote:
> On Wed, Jul 18, 2012 at 11:28:26AM +0200, Herman Bruyninckx wrote:
>> Of course, because it is Eclipse. But:
>> - ecore is not sufficient as a meta model (where is "behaviour" for
>> example?)
>
> I am not sure what kind of "behaviour" do you mean, but if you are talking
> about execution semantics (?), then it is should NOT be defined by the
> meta-model.
Why not....? The meta model should not only be about "structure", should
it?
> The goal of meta-modeling is to capture the concepts of a domain
> and their relationships. Nothing more.
Many of these relationships are about "behaviour". For example: you won't
get far modelling the domain of robot control without having meta models
for dynamics :-)
> If one want to attach some "meaning" to the meta-model, then the way to go is
> the model transformation - preferably into a domain with already defined
> "meaning" (i.e., translational semantics).
Model2model transformations only work with a decent meta-model, so that's
another good reason ito also have the "behavioural" "meaning" there.
> For example, the "behaviour" of C++ is not specified by its syntax tree. It is
> (formally) specified by a compiler, which translates C++ into assembler.
No! This is an example of "grounding" of behaviour by providing an
_implementation_ that people have agreed to that it 'does the right thing'
without an explicit model :-)
BTW: it is a _good_ example!
>> - it's too linked to the Eclipse ecosystem
>
> The Ecore is aligned with OMG MOF. It is not the fault of Eclipse that nobody
> else even try to follow this standard :(
It is: looking at the mere size of the standard says enough. Only Microsoft
is doing worse, with 6000+ pages of standard documentation for their Office
XML... :-)
> Alternatives like GOPPR (the metameta-model of MetaEdit+) in my opinion are
> even worse. On the other hand EBNF grammars (like in the case of GenoM) fail to
> capture a lot of information and must rely on logic that is "hidden" inside a
> "compiler." Can you recommend some alternative solution to efficaciously
> capture what the Ecore is capturing, but without locking to a particular
> ecosystem?
No! This is definitely a "gap" in the domain...
>>> I guess, that one can just pickup those meta-models, tune them and propagate
>>> the modifications into the tools.
>>
>> You will be surprised how much Eclipse lock-in you will encounter... :-(
>
> AFAIK none of the textual/graphical editors use the Ecore directly, but rely on
> a set of Java classes generated from the Ecore by "genmodel."
Well, _indirect_ dependency is not better than _direct_...
> One can just take
> these classes in implement whatever you want with them. In general, it is also
> possible to develop Ecore->C++/C#/whatever transformation and continue in
> another programming language... (but it is not the main focus of Eclipse
> Modeling Project).
One _can_, yes, indeed. But how practical is it? Because you will have to
do it for _everything_ in the standard.
> The reason to "lock-in" with Eclipse is that it provides some nice tools for
> building a complete toolset (including model edition, validation and
> transformation). If one can afford building such a toolset by mixing various
> technologies, then there is no reason for not doing so. The "Eclipse-way" is to
> do it faster and cheaper (and probably also cleaner).
That's the theory, for now. Eclipse (and many of its EMF projects) is
great, but by far not yet perfect. We are finding out this every day in the
BRICS project, sigh.
GUI for rFSN
On Wed, Jul 18, 2012 at 02:05:58PM +0200, Herman Bruyninckx wrote:
> >I am not sure what kind of "behaviour" do you mean, but if you are talking
> >about execution semantics (?), then it is should NOT be defined by the
> >meta-model.
>
> Why not....? The meta model should not only be about "structure", should
> it?
Properly speaking, the meta-modeling is related to DSMLs (M means Modeling),
"whose type systems formalize the application structure, behavior, and
requirements within particular domains" [1].
To goal is "to formalize" the behaviour of an application, which does not mean
"to describe how it works" and the meta-modeling is just about "type systems".
It is the job of semantics to specify how the language should be executed as it
is the job of notation to specify the concrete syntax.
> >The goal of meta-modeling is to capture the concepts of a domain
> >and their relationships. Nothing more.
>
> Many of these relationships are about "behaviour". For example: you won't
> get far modelling the domain of robot control without having meta models
> for dynamics :-)
In this particular case I would stop the meta-modeling as soon, as I can map
individual concepts of the robot control domain to the concepts of the
dynamical systems domain.
Another example: when developing a meta-model related to the domain of the
'make' utility I would stop with concepts such as 'dependency file', 'target
file' and 'rule'. It is enough to formalize the behaviour and the exact
definition of how these concepts "work" should be defined separately.
> >If one want to attach some "meaning" to the meta-model, then the way to go is
> >the model transformation - preferably into a domain with already defined
> >"meaning" (i.e., translational semantics).
>
> Model2model transformations only work with a decent meta-model, so that's
> another good reason ito also have the "behavioural" "meaning" there.
"Behavioural" (concepts) yes, "meaning" (of these concepts) no :-)
> >For example, the "behaviour" of C++ is not specified by its syntax tree. It is
> >(formally) specified by a compiler, which translates C++ into assembler.
>
> No! This is an example of "grounding" of behaviour by providing an
> _implementation_ that people have agreed to that it 'does the right thing'
> without an explicit model :-) BTW: it is a _good_ example!
Hmm... C++ is not so fortunate example, since there is no 'reference
implementation' for it (but there is such implementation for Java) :)
> >Alternatives like GOPPR (the metameta-model of MetaEdit+) in my opinion are
> >even worse. On the other hand EBNF grammars (like in the case of GenoM) fail
> >to capture a lot of information and must rely on logic that is "hidden"
> >inside a "compiler." Can you recommend some alternative solution to
> >efficaciously capture what the Ecore is capturing, but without locking to a
> >particular ecosystem?
>
> No! This is definitely a "gap" in the domain...
I agree. The Ecore/MOF (or EMOF - the "Essential MOF" part of the standard) is
not perfect. In particular, it is not based on mathematical foundations. But I
see no better alternative in the open-source community and I have never faced
any serious problem directly related to Ecore itself.
> >AFAIK none of the textual/graphical editors use the Ecore directly, but rely
> >on a set of Java classes generated from the Ecore by "genmodel."
>
> Well, _indirect_ dependency is not better than _direct_...
With this attitude one should not use Orocos-RTT to deliver any component,
because it would be (in)directly dependent on this particular framework :-(
I am afraid, that for any practical piece of software you have to depend on
some platform (let it be OS/programming language/abstraction framework).
> >One can just take
> >these classes in implement whatever you want with them. In general, it is also
> >possible to develop Ecore->C++/C#/whatever transformation and continue in
> >another programming language... (but it is not the main focus of Eclipse
> >Modeling Project).
>
> One _can_, yes, indeed. But how practical is it? Because you will have to
> do it for _everything_ in the standard.
I think that this approach would be reasonably practical. In most of the
applications that I have seen, only a small subset of the Ecore was actually
used - I mean not really much more than it is directly visible on the Ecore
diagrams (only few additional properties such as Ekeys).
> >The reason to "lock-in" with Eclipse is that it provides some nice tools for
> >building a complete toolset (including model edition, validation and
> >transformation). If one can afford building such a toolset by mixing various
> >technologies, then there is no reason for not doing so. The "Eclipse-way" is to
> >do it faster and cheaper (and probably also cleaner).
>
> That's the theory, for now. Eclipse (and many of its EMF projects) is
> great, but by far not yet perfect. We are finding out this every day in the
> BRICS project, sigh.
I agree.
[1] Schmidt, D.C. "Model-driven engineering," IEEE Computer, Vol. 36-2, 2006.
GUI for rFSN
On Wed, 18 Jul 2012, Piotr Trojanek wrote:
> On Wed, Jul 18, 2012 at 02:05:58PM +0200, Herman Bruyninckx wrote:
>>> I am not sure what kind of "behaviour" do you mean, but if you are talking
>>> about execution semantics (?), then it is should NOT be defined by the
>>> meta-model.
>>
>> Why not....? The meta model should not only be about "structure", should
>> it?
>
> Properly speaking, the meta-modeling is related to DSMLs (M means Modeling),
> "whose type systems formalize the application structure, behavior, and
> requirements within particular domains" [1].
[1] is a typical publication by a _software engineer_, who has never been
exposed to other than digital "behaviour", sigh... :-)
> To goal is "to formalize" the behaviour of an application, which does not mean
> "to describe how it works" and the meta-modeling is just about "type systems".
So...?
> It is the job of semantics to specify how the language should be executed as it
> is the job of notation to specify the concrete syntax.
Postponing the behaviour (meta) modelling to "somewhere else" or "sometimes later"
does not make it go away... :-)
>>> The goal of meta-modeling is to capture the concepts of a domain
>>> and their relationships. Nothing more.
>>
>> Many of these relationships are about "behaviour". For example: you won't
>> get far modelling the domain of robot control without having meta models
>> for dynamics :-)
>
> In this particular case I would stop the meta-modeling as soon, as I can map
> individual concepts of the robot control domain to the concepts of the
> dynamical systems domain.
And what do you think the "dynamical systems domain" is getting its formal
behaviour models from? It is a key domain where meta modelling was adapted
a very long time ago already: Bond graphs, multi-physics modelling, etc.
And robotics _has_ to incorporate these results, sooner or later.
> Another example: when developing a meta-model related to the domain of the
> 'make' utility I would stop with concepts such as 'dependency file', 'target
> file' and 'rule'. It is enough to formalize the behaviour and the exact
> definition of how these concepts "work" should be defined separately.
"defined separately" = create a meta model.
>>> If one want to attach some "meaning" to the meta-model, then the way to go is
>>> the model transformation - preferably into a domain with already defined
>>> "meaning" (i.e., translational semantics).
>>
>> Model2model transformations only work with a decent meta-model, so that's
>> another good reason ito also have the "behavioural" "meaning" there.
>
> "Behavioural" (concepts) yes, "meaning" (of these concepts) no :-)
"meaning" = meta modelling + modelling!
>>> For example, the "behaviour" of C++ is not specified by its syntax tree. It is
>>> (formally) specified by a compiler, which translates C++ into assembler.
>>
>> No! This is an example of "grounding" of behaviour by providing an
>> _implementation_ that people have agreed to that it 'does the right thing'
>> without an explicit model :-) BTW: it is a _good_ example!
>
> Hmm... C++ is not so fortunate example, since there is no 'reference
> implementation' for it (but there is such implementation for Java) :)
>>> Alternatives like GOPPR (the metameta-model of MetaEdit+) in my opinion are
>>> even worse. On the other hand EBNF grammars (like in the case of GenoM) fail
>>> to capture a lot of information and must rely on logic that is "hidden"
>>> inside a "compiler." Can you recommend some alternative solution to
>>> efficaciously capture what the Ecore is capturing, but without locking to a
>>> particular ecosystem?
>>
>> No! This is definitely a "gap" in the domain...
>
> I agree. The Ecore/MOF (or EMOF - the "Essential MOF" part of the standard) is
> not perfect. In particular, it is not based on mathematical foundations. But I
> see no better alternative in the open-source community and I have never faced
> any serious problem directly related to Ecore itself.
Because you have not yet tried to let your robots sort it out at runtime,
without human help :-)
>>> AFAIK none of the textual/graphical editors use the Ecore directly, but rely
>>> on a set of Java classes generated from the Ecore by "genmodel."
>>
>> Well, _indirect_ dependency is not better than _direct_...
>
> With this attitude one should not use Orocos-RTT to deliver any component,
> because it would be (in)directly dependent on this particular framework :-(
> I am afraid, that for any practical piece of software you have to depend on
> some platform (let it be OS/programming language/abstraction framework).
Of course you have to depend, but switching dependencies should be a lot
easier than what current practice supports.
>>> One can just take
>>> these classes in implement whatever you want with them. In general, it is also
>>> possible to develop Ecore->C++/C#/whatever transformation and continue in
>>> another programming language... (but it is not the main focus of Eclipse
>>> Modeling Project).
>>
>> One _can_, yes, indeed. But how practical is it? Because you will have to
>> do it for _everything_ in the standard.
>
> I think that this approach would be reasonably practical. In most of the
> applications that I have seen, only a small subset of the Ecore was actually
> used - I mean not really much more than it is directly visible on the Ecore
> diagrams (only few additional properties such as Ekeys).
Again, Ecore does _not_ do behaviour...
>>> The reason to "lock-in" with Eclipse is that it provides some nice tools for
>>> building a complete toolset (including model edition, validation and
>>> transformation). If one can afford building such a toolset by mixing various
>>> technologies, then there is no reason for not doing so. The "Eclipse-way" is to
>>> do it faster and cheaper (and probably also cleaner).
>>
>> That's the theory, for now. Eclipse (and many of its EMF projects) is
>> great, but by far not yet perfect. We are finding out this every day in the
>> BRICS project, sigh.
>
> I agree.
>
> [1] Schmidt, D.C. "Model-driven engineering," IEEE Computer, Vol. 36-2, 2006.
>
GUI for rFSN
On Wed, Jul 18, 2012 at 06:32:21PM +0200, Herman Bruyninckx wrote:
> >Properly speaking, the meta-modeling is related to DSMLs (M means Modeling),
> >"whose type systems formalize the application structure, behavior, and
> >requirements within particular domains" [1].
>
> [1] is a typical publication by a _software engineer_, who has never been
> exposed to other than digital "behaviour", sigh... :-)
I guess that you prefer a definition like in [2], i.e., something like
"metamodel is a language that is used to describe models." It also seems, that
you are talking about modealling all the "robotics domain" while I am talking
just about the part of a control system (?).
I see no reason to include "behavioural aspects" in generic, domain-
-independent metameta-models like Ecore. In [2] you can also find some reasons
for making the (meta)meta-models static (p. 18).
> >To goal is "to formalize" the behaviour of an application, which does not mean
> >"to describe how it works" and the meta-modeling is just about "type systems".
>
> So...?
So the goal of the metamodelling (as defined by the software engineering
community) is just a formalization of the domain concepts and their
relationships. If you prefer to define metamodelling as "developing languages
for describing models of a domain" (e.g., Bond graphs in the case of dynamical
systems) then it is much broader definition...
I prefer to stick with the former one and say that metamodel is just one
element of a _modelling language_ (that is mostly related to its abstract
syntax), while other elements like notation (i.e., concrete syntax) and
semantics are clearly separated.
> >It is the job of semantics to specify how the language should be executed as it
> >is the job of notation to specify the concrete syntax.
>
> Postponing the behaviour (meta) modelling to "somewhere else" or "sometimes later"
> does not make it go away... :-)
But it makes the (meta) model is more clear, since it does not mix different
concerns. Moreover, static (meta) models are easier to analyse and reason about
[2]. (In a similar way people tend to separate data from algorithms.)
> And what do you think the "dynamical systems domain" is getting its formal
> behaviour models from? It is a key domain where meta modelling was adapted a
> very long time ago already: Bond graphs, multi-physics modelling, etc. And
> robotics _has_ to incorporate these results, sooner or later.
I would say that these "formal behavior models" are modelling languages and not
meta-models. It seems, that we rely on different definitions of these terms...
> >Another example: when developing a meta-model related to the domain of the
> >'make' utility I would stop with concepts such as 'dependency file', 'target
> >file' and 'rule'. It is enough to formalize the behaviour and the exact
> >definition of how these concepts "work" should be defined separately.
>
> "defined separately" = create a meta model.
Not really, "defined separately" = complement the definition of a modelling
language by providing its semantics (e.g., translational, operational,
denotational). I would not say, that an defining an operational semantics is
creating a meta model...
> >>>If one want to attach some "meaning" to the meta-model, then the way to go is
> >>>the model transformation - preferably into a domain with already defined
> >>>"meaning" (i.e., translational semantics).
> >>
> >>Model2model transformations only work with a decent meta-model, so that's
> >>another good reason to also have the "behavioural" "meaning" there.
> >
> >"Behavioural" (concepts) yes, "meaning" (of these concepts) no :-)
>
> "meaning" = meta modelling + modelling!
I think that we have different "meanings" of the work "meta-modelling"...
> >I agree. The Ecore/MOF (or EMOF - the "Essential MOF" part of the standard)
> >is not perfect. In particular, it is not based on mathematical foundations.
> >But I see no better alternative in the open-source community and I have
> >never faced any serious problem directly related to Ecore itself.
>
> Because you have not yet tried to let your robots sort it out at runtime,
> without human help :-)
I am not sure it I understand correctly. I have never asked my robots to work
with Ecore. I have just used it to model some aspects of the control system.
> >With this attitude one should not use Orocos-RTT to deliver any component,
> >because it would be (in)directly dependent on this particular framework :-(
> >I am afraid, that for any practical piece of software you have to depend on
> >some platform (let it be OS/programming language/abstraction framework).
>
> Of course you have to depend, but switching dependencies should be a lot
> easier than what current practice supports.
I agree.
> >>One _can_, yes, indeed. But how practical is it? Because you will have to
> >>do it for _everything_ in the standard.
> >
> >I think that this approach would be reasonably practical. In most of the
> >applications that I have seen, only a small subset of the Ecore was actually
> >used - I mean not really much more than it is directly visible on the Ecore
> >diagrams (only few additional properties such as Ekeys).
>
> Again, Ecore does _not_ do behaviour...
If I understand correctly - you expect the metamodel to capture the dynamics of
the domain concepts (right?). I think that any serious, domain-independent
meta-metamodel will ever aim to do this... It should then include concurrency,
non-determinism and all the stuff that makes our world so unpredictable... and
the robotics so interesting! :)
PS It is possible to work with Ecore from the outside of the Eclipse/Java
ecosystem (C++): http://code.google.com/p/emf4cpp/
[2] Jean Be?zivin. On the unification power of models. Software and Systems
Modeling, 4(2):171–188, May 2005.
GUI for rFSN
On Thu, 19 Jul 2012, Piotr Trojanek wrote:
> On Wed, Jul 18, 2012 at 06:32:21PM +0200, Herman Bruyninckx wrote:
>> >Properly speaking, the meta-modeling is related to DSMLs (M means Modeling),
>> >"whose type systems formalize the application structure, behavior, and
>> >requirements within particular domains" [1].
>>
>> [1] is a typical publication by a _software engineer_, who has never been
>> exposed to other than digital "behaviour", sigh... :-)
>
> I guess that you prefer a definition like in [2],
Definitely :-)
> i.e., something like
> "metamodel is a language that is used to describe models." It also seems, that
> you are talking about modealling all the "robotics domain" while I am talking
> just about the part of a control system (?).
My scope is indeed all-encompassing! Because a more restricted view is
almost guaranteed to make one take decisions that "close the world" too
much, sooner or later. And the simplest way to fight the "closed world
assumption" is to provide lots of "URIs" in your (meta) models, allowing
you later extend your model with new models developed independently. The
Collada standard is a very nice example of this.
> I see no reason to include "behavioural aspects" in generic, domain-
> -independent metameta-models like Ecore. In [2] you can also find some reasons
> for making the (meta)meta-models static (p. 18).
Fine for me, if you want to close your world to static "behaviour" :-)
But I prefer my robots to be able to work in, and reason about, dynamic
worlds and interactions.
>> >To goal is "to formalize" the behaviour of an application, which does not mean
>> >"to describe how it works" and the meta-modeling is just about "type systems".
>>
>> So...?
>
> So the goal of the metamodelling (as defined by the software engineering
> community) is just a formalization of the domain concepts and their
> relationships. If you prefer to define metamodelling as "developing languages
> for describing models of a domain" (e.g., Bond graphs in the case of dynamical
> systems) then it is much broader definition...
And _robotics_ _needs_ that broader definition. The digital/discrete world
software engineering is not going to help us solving the _real_ remaining
challenges in robotics :-)
> I prefer to stick with the former one and say that metamodel is just one
> element of a _modelling language_ (that is mostly related to its abstract
> syntax), while other elements like notation (i.e., concrete syntax) and
> semantics are clearly separated.
Well, let's finish this "discussion", since we keep on repeating
ourselves...
>> >It is the job of semantics to specify how the language should be executed as it
>> >is the job of notation to specify the concrete syntax.
>>
>> Postponing the behaviour (meta) modelling to "somewhere else" or "sometimes later"
>> does not make it go away... :-)
>
> But it makes the (meta) model is more clear, since it does not mix different
> concerns. Moreover, static (meta) models are easier to analyse and reason about
> [2]. (In a similar way people tend to separate data from algorithms.)
I am all for _separation of concerns_. But that does not prevent us from
_having_ to tackle the problem of formally modelling _all_ the concerns.
>> And what do you think the "dynamical systems domain" is getting its formal
>> behaviour models from? It is a key domain where meta modelling was adapted a
>> very long time ago already: Bond graphs, multi-physics modelling, etc. And
>> robotics _has_ to incorporate these results, sooner or later.
>
> I would say that these "formal behavior models" are modelling languages and not
> meta-models. It seems, that we rely on different definitions of these terms...
>> >Another example: when developing a meta-model related to the domain of the
>> >'make' utility I would stop with concepts such as 'dependency file', 'target
>> >file' and 'rule'. It is enough to formalize the behaviour and the exact
>> >definition of how these concepts "work" should be defined separately.
>>
>> "defined separately" = create a meta model.
>
> Not really, "defined separately" = complement the definition of a modelling
> language by providing its semantics (e.g., translational, operational,
> denotational). I would not say, that an defining an operational semantics is
> creating a meta model...
Here is the clue that you miss, I guess! What else then, is defining operational
semantics other than creating another modelling stack? (Stack = meta meta
model, + meta model)
It's time that you get constructively concrete, instead of keeping saying
"no, I don't like them " to my arguments: please, make a concrete suggestion of an
alternative, so that I can learn, instead of repeating myself.
>> >>>If one want to attach some "meaning" to the meta-model, then the way to go is
>> >>>the model transformation - preferably into a domain with already defined
>> >>>"meaning" (i.e., translational semantics).
>> >>
>> >>Model2model transformations only work with a decent meta-model, so that's
>> >>another good reason to also have the "behavioural" "meaning" there.
>> >
>> >"Behavioural" (concepts) yes, "meaning" (of these concepts) no :-)
>>
>> "meaning" = meta modelling + modelling!
>
> I think that we have different "meanings" of the work "meta-modelling"...
>
>> >I agree. The Ecore/MOF (or EMOF - the "Essential MOF" part of the standard)
>> >is not perfect. In particular, it is not based on mathematical foundations.
>> >But I see no better alternative in the open-source community and I have
>> >never faced any serious problem directly related to Ecore itself.
>>
>> Because you have not yet tried to let your robots sort it out at runtime,
>> without human help :-)
>
> I am not sure it I understand correctly. I have never asked my robots to work
> with Ecore. I have just used it to model some aspects of the control system.
So, you are still living in the old world in which one only expects the
humans to be able to reason about what the robots are doing, while in the
new world of robotics, the robots should be able to start doing that
self-introspection-based reasoning themselves.
>> >With this attitude one should not use Orocos-RTT to deliver any component,
>> >because it would be (in)directly dependent on this particular framework :-(
>> >I am afraid, that for any practical piece of software you have to depend on
>> >some platform (let it be OS/programming language/abstraction framework).
>>
>> Of course you have to depend, but switching dependencies should be a lot
>> easier than what current practice supports.
>
> I agree.
>
>> >>One _can_, yes, indeed. But how practical is it? Because you will have to
>> >>do it for _everything_ in the standard.
>> >
>> >I think that this approach would be reasonably practical. In most of the
>> >applications that I have seen, only a small subset of the Ecore was actually
>> >used - I mean not really much more than it is directly visible on the Ecore
>> >diagrams (only few additional properties such as Ekeys).
>>
>> Again, Ecore does _not_ do behaviour...
>
> If I understand correctly - you expect the metamodel to capture the dynamics of
> the domain concepts (right?).
Sure! Modelica is a nice example, covering the dynamics of physical
systems. StateCharts/PLCs are other exampless, covering the dynamics of
event-based logical systems.
> I think that any serious, domain-independent
> meta-metamodel will ever aim to do this...
????
> It should then include concurrency,
> non-determinism and all the stuff that makes our world so unpredictable... and
> the robotics so interesting! :)
> PS It is possible to work with Ecore from the outside of the Eclipse/Java
> ecosystem (C++): http://code.google.com/p/emf4cpp/
Sure it is _possible_.
> [2] Jean Be?zivin. On the unification power of models. Software and Systems
> Modeling, 4(2):171–188, May 2005.
>
GUI for rFSN
On Thu, Jul 19, 2012 at 05:53:52AM +0200, Herman Bruyninckx wrote:
> >I guess that you prefer a definition like in [2],
>
> Definitely :-)
Let's stick to this author: "The word 'ontology' will be used here in an
interchangeable way with 'meta-model' for defining a set of concepts and
relations between these concepts" [3].
The "definitions" like in [2] only makes that people do not see (and do not
understand!) the differences between meta-models, UML profiles and EBNF
grammars... Moreover, it makes that they see no difference between a language
and its grammar/notation/semantics...
> My scope is indeed all-encompassing! [...]
My scope to :-) I think, that we can agree at this point, since it seems
that you simply use the term "metamodel" where I use "modeling language."
Obviously, Ecore is just a one piece of your "metamodel" as it is just a one
piece of my "modeling language". For both of us this piece deals only with a
static aspect of a model and obviously this aspect does not cover all the
complexity of the robotics domain.
> >But it makes the (meta) model is more clear, since it does not mix different
> >concerns. Moreover, static (meta) models are easier to analyse and reason
> >about [2]. (In a similar way people tend to separate data from algorithms.)
>
> I am all for _separation of concerns_. But that does not prevent us from
> _having_ to tackle the problem of formally modelling _all_ the concerns.
I agree. Separation of concerns does not prevent from this. It only helps :)
> >>>Another example: when developing a meta-model related to the domain of the
> >>>'make' utility I would stop with concepts such as 'dependency file',
> >>>'target file' and 'rule'. It is enough to formalize the behaviour and the
> >>>exact definition of how these concepts "work" should be defined
> >>>separately.
> >>
> >>"defined separately" = create a meta model.
> >
> >Not really, "defined separately" = complement the definition of a modelling
> >language by providing its semantics (e.g., translational, operational,
> >denotational). I would not say, that an defining an operational semantics is
> >creating a meta model...
>
> Here is the clue that you miss, I guess! What else then, is defining operational
> semantics other than creating another modelling stack? (Stack = meta meta
> model, + meta model)
> It's time that you get constructively concrete, instead of keeping saying
> "no, I don't like them " to my arguments: please, make a concrete suggestion of an
> alternative, so that I can learn, instead of repeating myself.
I guess that the difference is only in naming - but while I have already seen
a couple of books/articles about "defining semantics of modelling languages,"
I have never seen any paper about "creating modelling stacks" :(
> >I am not sure it I understand correctly. I have never asked my robots to
> >work with Ecore. I have just used it to model some aspects of the control
> >system.
>
> So, you are still living in the old world in which one only expects the
> humans to be able to reason about what the robots are doing, while in the
> new world of robotics, the robots should be able to start doing that
> self-introspection-based reasoning themselves.
The problem is that I have never seen any robot to do any "reasoning" that was
NOT programmed into the control system. Oops, I have seen it once - but it was
"A long time ago in a galaxy far, far away..." :(
[3] Bézivin, Jean. “Meta-Model Technology: Concepts And Applications.” XML'99
Conference, Philadelphia, Pennsylvania, Dec 1999.
GUI for rFSN
On Thu, 19 Jul 2012, Piotr Trojanek wrote:
> On Thu, Jul 19, 2012 at 05:53:52AM +0200, Herman Bruyninckx wrote:
>> >I guess that you prefer a definition like in [2],
>>
>> Definitely :-)
>
> Let's stick to this author: "The word 'ontology' will be used here in an
> interchangeable way with 'meta-model' for defining a set of concepts and
> relations between these concepts" [3].
>
> The "definitions" like in [2] only makes that people do not see (and do not
> understand!) the differences between meta-models, UML profiles and EBNF
> grammars... Moreover, it makes that they see no difference between a language
> and its grammar/notation/semantics...
>
>> My scope is indeed all-encompassing! [...]
>
> My scope to :-) I think, that we can agree at this point, since it seems
> that you simply use the term "metamodel" where I use "modeling language."
ontology = meta model = modelling language?
Fine for me. It all depends on _how_ you do it :-)
> Obviously, Ecore is just a one piece of your "metamodel" as it is just a one
> piece of my "modeling language". For both of us this piece deals only with a
> static aspect of a model and obviously this aspect does not cover all the
> complexity of the robotics domain.
Agreed.
In the BRICS and Rosetta projects, we focus a lot on _composition_ of
ontologies/meta models/modelling languages, because we believe this is a
more scalable way than to _enrich_ one ontology by adding more an more
concepts and relationships in it. The composition itself is something that
should get a meta model, in the best case :-)
>> >But it makes the (meta) model is more clear, since it does not mix different
>> >concerns. Moreover, static (meta) models are easier to analyse and reason
>> >about [2]. (In a similar way people tend to separate data from algorithms.)
>>
>> I am all for _separation of concerns_. But that does not prevent us from
>> _having_ to tackle the problem of formally modelling _all_ the concerns.
>
> I agree. Separation of concerns does not prevent from this. It only helps :)
>
>> >>>Another example: when developing a meta-model related to the domain of the
>> >>>'make' utility I would stop with concepts such as 'dependency file',
>> >>>'target file' and 'rule'. It is enough to formalize the behaviour and the
>> >>>exact definition of how these concepts "work" should be defined
>> >>>separately.
>> >>
>> >>"defined separately" = create a meta model.
>> >
>> >Not really, "defined separately" = complement the definition of a modelling
>> >language by providing its semantics (e.g., translational, operational,
>> >denotational). I would not say, that an defining an operational semantics is
>> >creating a meta model...
>>
>> Here is the clue that you miss, I guess! What else then, is defining operational
>> semantics other than creating another modelling stack? (Stack = meta meta
>> model, + meta model)
>> It's time that you get constructively concrete, instead of keeping saying
>> "no, I don't like them " to my arguments: please, make a concrete suggestion of an
>> alternative, so that I can learn, instead of repeating myself.
>
> I guess that the difference is only in naming - but while I have already seen
> a couple of books/articles about "defining semantics of modelling languages,"
> I have never seen any paper about "creating modelling stacks" :(
Yes, which shows this is a still a mostly unexplored domain....
<shameless plug>
BTW, in one of my new efforts, the European PhD School in Robotics, we want
to investigate this unexplored domain further, based on a set of initial
ontologies that we have created in the last two-three years.
<shameless plug>
>> >I am not sure it I understand correctly. I have never asked my robots to
>> >work with Ecore. I have just used it to model some aspects of the control
>> >system.
>>
>> So, you are still living in the old world in which one only expects the
>> humans to be able to reason about what the robots are doing, while in the
>> new world of robotics, the robots should be able to start doing that
>> self-introspection-based reasoning themselves.
>
> The problem is that I have never seen any robot to do any "reasoning" that was
> NOT programmed into the control system.
Here you should make the following important difference: nowadays, the
reasoning is indeed "programmed" and then executed on-line, while we should
evolve towards a situation where the reasoning software is programmed, but
the materialit is working on is stored/created/updated in formal _models_,
and the context of the reasoning is provided by _meta models_. :-)
> Oops, I have seen it once - but it was
> "A long time ago in a galaxy far, far away..." :(
I am rich enough to travel that far... :-(
>
> [3] Bézivin, Jean. “Meta-Model Technology: Concepts And Applications.” XML'99
> Conference, Philadelphia, Pennsylvania, Dec 1999.
I would be very thankful if you could send this publication to me, in case
you have it in electronic form...
> Piotr Trojanek
Herman
GUI for rFSN
On Thu, Jul 19, 2012 at 02:48:52PM +0200, Herman Bruyninckx wrote:
> >My scope to :-) I think, that we can agree at this point, since it seems
> >that you simply use the term "metamodel" where I use "modeling language."
>
> ontology = meta model = modelling language?
>
> Fine for me. It all depends on _how_ you do it :-)
Whew, it is great that we have finally agreed about this! :-) (I do not want to
start another war, but this is where WikiPedia points to in the case of
ontology vs meta-model, http://infogrid.org/trac/wiki/Reference/PidcockArticle;
here the difference is even less clear for me so I will definitely not fight
about this).
> In the BRICS and Rosetta projects, we focus a lot on _composition_ of
> ontologies/meta models/modelling languages, because we believe this is a more
> scalable way than to _enrich_ one ontology by adding more an more concepts
> and relationships in it. The composition itself is something that should get
> a meta model, in the best case :-)
I am all for it!
> >I guess that the difference is only in naming - but while I have already
> >seen a couple of books/articles about "defining semantics of modelling
> >languages," I have never seen any paper about "creating modelling stacks" :(
>
> Yes, which shows this is a still a mostly unexplored domain....
>
> <shameless plug>
> BTW, in one of my new efforts, the European PhD School in Robotics, we want
> to investigate this unexplored domain further, based on a set of initial
> ontologies that we have created in the last two-three years.
> <shameless plug>
Great! The more modelling in the robotics community the better :-)
> Here you should make the following important difference: nowadays, the
> reasoning is indeed "programmed" and then executed on-line, while we should
> evolve towards a situation where the reasoning software is programmed, but
> the material it is working on is stored/created/updated in formal _models_,
> and the context of the reasoning is provided by _meta models_. :-)
This is an extremely generic statement, so of course I can only fully agree :)
Unfortunately I have never seen any "reasoning" system, that would be even a
little bit smarter than Turing machine :( But what I have seen is that there is
a big difference when programing a control system in C++/Simulink/Lisp (in the
last case the difference is even so big, that people tend to call the program a
"plan"). In the end it is always "just" a piece of software, but what I mean is
that the "software language" can make a big difference...
I believe that to make the shift you are talking about we should find some
better "languages" for storing the models and also another "languages" for
manipulating them. (The former are probably much closer to modeling than
programming, while the latter are probably more declarative than imperative.)
To make the whole process more science than art, my guess is that we should
tackle the problem from the language engineering point of view. (And that is
why I am a little bit obsessive about naming related to this field, sorry).
> I would be very thankful if you could send this publication to me, in case
> you have it in electronic form...
I have found this reference here:
http://www.infoloom.com/gcaconfs/WEB/philadelphia99/biezivin.HTM
The same text is also repeated here [4]: http://tinyurl.com/chb9eek
[4] J. Bézivin, "New trends in model engineering"; in Proc. IRMA Conference,
2000, pp.1185-1187.
GUI for rFSN
On Thu, 19 Jul 2012, Piotr Trojanek wrote:
> On Thu, Jul 19, 2012 at 02:48:52PM +0200, Herman Bruyninckx wrote:
>>> My scope to :-) I think, that we can agree at this point, since it seems
>>> that you simply use the term "metamodel" where I use "modeling language."
>>
>> ontology = meta model = modelling language?
>>
>> Fine for me. It all depends on _how_ you do it :-)
>
> Whew, it is great that we have finally agreed about this! :-) (I do not want to
> start another war, but this is where WikiPedia points to in the case of
> ontology vs meta-model, http://infogrid.org/trac/wiki/Reference/PidcockArticle;
> here the difference is even less clear for me so I will definitely not fight
> about this).
A short try to help you out: every (good) meta model is an ontology, but
not the other way around.
>> In the BRICS and Rosetta projects, we focus a lot on _composition_ of
>> ontologies/meta models/modelling languages, because we believe this is a more
>> scalable way than to _enrich_ one ontology by adding more an more concepts
>> and relationships in it. The composition itself is something that should get
>> a meta model, in the best case :-)
>
> I am all for it!
>
>>> I guess that the difference is only in naming - but while I have already
>>> seen a couple of books/articles about "defining semantics of modelling
>>> languages," I have never seen any paper about "creating modelling stacks" :(
>>
>> Yes, which shows this is a still a mostly unexplored domain....
>>
>> <shameless plug>
>> BTW, in one of my new efforts, the European PhD School in Robotics, we want
>> to investigate this unexplored domain further, based on a set of initial
>> ontologies that we have created in the last two-three years.
>> <shameless plug>
>
> Great! The more modelling in the robotics community the better :-)
I don't think so... Because the motto of the Schools is "more with less".
That is, we want to teach that one needs only a very limited number of
really fundamental concepts to understand all of the developments in all
sub-domains of robotics.
>> Here you should make the following important difference: nowadays, the
>> reasoning is indeed "programmed" and then executed on-line, while we should
>> evolve towards a situation where the reasoning software is programmed, but
>> the material it is working on is stored/created/updated in formal _models_,
>> and the context of the reasoning is provided by _meta models_. :-)
>
> This is an extremely generic statement, so of course I can only fully agree :)
>
> Unfortunately I have never seen any "reasoning" system, that would be even a
> little bit smarter than Turing machine :( But what I have seen is that there is
> a big difference when programing a control system in C++/Simulink/Lisp (in the
> last case the difference is even so big, that people tend to call the program a
> "plan"). In the end it is always "just" a piece of software, but what I mean is
> that the "software language" can make a big difference...
>
> I believe that to make the shift you are talking about we should find some
> better "languages" for storing the models and also another "languages" for
> manipulating them. (The former are probably much closer to modeling than
> programming, while the latter are probably more declarative than imperative.)
Absolutely! Correct analysis.
> To make the whole process more science than art, my guess is that we should
> tackle the problem from the language engineering point of view. (And that is
> why I am a little bit obsessive about naming related to this field, sorry).
No reason to apologize :-)
>> I would be very thankful if you could send this publication to me, in case
>> you have it in electronic form...
>
> I have found this reference here:
> http://www.infoloom.com/gcaconfs/WEB/philadelphia99/biezivin.HTM
>
> The same text is also repeated here [4]: http://tinyurl.com/chb9eek
>
> [4] J. Bézivin, "New trends in model engineering"; in Proc. IRMA Conference,
> 2000, pp.1185-1187.
Thanks!
> Piotr Trojanek
Herman
GUI for rFSN
Dear all,
> On Wed, Jul 18, 2012 at 11:28:26AM +0200, Herman Bruyninckx wrote:
>> Of course, because it is Eclipse. But:
>> - ecore is not sufficient as a meta model (where is "behaviour" for
>> example?)
>
> I am not sure what kind of "behaviour" do you mean, but if you are talking
> about execution semantics (?), then it is should NOT be defined by the
> meta-model. The goal of meta-modeling is to capture the concepts of a domain
> and their relationships. Nothing more.
>
> If one want to attach some "meaning" to the meta-model, then the way to go is
> the model transformation - preferably into a domain with already defined
> "meaning" (i.e., translational semantics).
Ecore is good and expressive enough to define the "primitives" of a
language. Nothing more. It's just one representation approach.
One way to attach "meaning" is to use those primitives in a
operational semantic specification as done for many programming
languages.
Nico
>
> For example, the "behaviour" of C++ is not specified by its syntax
> tree. It is
> (formally) specified by a compiler, which translates C++ into assembler.
>
>> - it's too linked to the Eclipse ecosystem
>
> The Ecore is aligned with OMG MOF. It is not the fault of Eclipse that nobody
> else even try to follow this standard :(
>
> Alternatives like GOPPR (the metameta-model of MetaEdit+) in my opinion are
> even worse. On the other hand EBNF grammars (like in the case of
> GenoM) fail to
> capture a lot of information and must rely on logic that is "hidden" inside a
> "compiler." Can you recommend some alternative solution to efficaciously
> capture what the Ecore is capturing, but without locking to a particular
> ecosystem?
>
>> >I guess, that one can just pickup those meta-models, tune them and
>> propagate
>> >the modifications into the tools.
>>
>> You will be surprised how much Eclipse lock-in you will encounter... :-(
>
> AFAIK none of the textual/graphical editors use the Ecore directly,
> but rely on
> a set of Java classes generated from the Ecore by "genmodel." One
> can just take
> these classes in implement whatever you want with them. In general,
> it is also
> possible to develop Ecore->C++/C#/whatever transformation and continue in
> another programming language... (but it is not the main focus of Eclipse
> Modeling Project).
>
> The reason to "lock-in" with Eclipse is that it provides some nice tools for
> building a complete toolset (including model edition, validation and
> transformation). If one can afford building such a toolset by mixing various
> technologies, then there is no reason for not doing so. The
> "Eclipse-way" is to
> do it faster and cheaper (and probably also cleaner).
>
> --
> Piotr Trojanek
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
GUI for rFSN
On Wed, Jul 18, 2012 at 01:20:01PM +0200, Nico Hochgeschwender wrote:
> Ecore is good and expressive enough to define the "primitives" of a
> language. Nothing more. It's just one representation approach.
I agree, provided that you substitute "language" with "domain" and "primitives"
with "concepts" :-)
> One way to attach "meaning" is to use those primitives in a
> operational semantic specification as done for many programming
> languages.
Probably the operational semantics approach can be used in the case of FSMs.
However, I doubt whether it can be applied to domains not related to
programming languages. In my opinion the translational semantics approach is
better for attaching meanings such as threads, processes, components, service
calls, etc.
GUI for rFSN
On Wed, Jul 04, 2012 at 10:10:41PM +0200, Hugo Garcia wrote:
> The icing on the cake would be to have real time updates of the diagram by
> updating the model using either a TCP/IP port for in memory or direct file
> manipulation of the model which would update the graphical representation.
> You could also use CORBA to communicate to TaskContexts... and this has been
> implemented already.
Another idea is to support breakpoints/watchpoints. I am not sure whether it
can be done on top of the Eclipse Debugging Framework, but the idea is quite
similar to debugging.
GUI for rFSN
On Wed, Jul 04, 2012 at 11:41:37PM +0200, Piotr Trojanek wrote:
> On Wed, Jul 04, 2012 at 10:10:41PM +0200, Hugo Garcia wrote:
> > The icing on the cake would be to have real time updates of the diagram by
> > updating the model using either a TCP/IP port for in memory or direct file
> > manipulation of the model which would update the graphical representation.
> > You could also use CORBA to communicate to TaskContexts... and this has been
> > implemented already.
>
> Another idea is to support breakpoints/watchpoints. I am not sure whether it
> can be done on top of the Eclipse Debugging Framework, but the idea is quite
> similar to debugging.
Yes, good point. It can, for instance the Lua Koneki plugins support a
remote debugger. Internally it just uses the Lua debug library, that
could be used to define breakpoints on states.
Markus
GUI for rFSN
On Mon, 2 Jul 2012, Markus Klotzbuecher wrote:
> Hi Fabrizio,
>
> On Mon, Jul 02, 2012 at 11:29:14AM +0200, Fabrizio Boriero wrote:
>
>> we need a GUI for rFSM that, given the description on rFSM, shows a
>> cool graphical window with the currents state and the events
>> exchanged.
>
> We too :-)
>
>> In my lab there is a student that can works on it so there are
>> suggestions to start?
>
> Great! It depends on how far you would like to push it. The quick and
> dirty way would be to use a graphviz based solution. In rFSM there is
> already rfsm2uml.lua that can "dump" rFSM instances to graphviz dot
> format. The output of this is in general more or less readable and
> (certainly) better than nothing.
>
> More work, but with a potentially much better result would be to
> implement a real statechart layout algorithm (google for "automatic
> statechart layout". Unfortunately, I couldn't find any code for this
> so far.
>
> Alterantively, the KIELER project promises to extend Eclipse editors
> with automatic layout. Thinking of it, they're likely to have usable
> (licensewise) layout algorithm code.
>
> If you start anything regarding this, it would be great if you could
> keep this list updated...
And I would be willing to hire you for the Summer to work on that in Leuven! :-)
> Markus
Herman