Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EMF Statechart support for generating state machine codes
EMF Statechart support for generating state machine codes [message #425886] Thu, 11 December 2008 07:13 Go to next message
Leonard J. Reder is currently offline Leonard J. RederFriend
Messages: 9
Registered: July 2009
Junior Member
Hello All,
I spent about a day looking at EMF and working through the tutorials and
still cannot easily answer this question. Can the EMF be used to build
a tool to parse XMI Statechart models and generate state machine
implementation code in the forms of various design patterns using
various languages like C and C++?

We presently have a Java tool that reads XMI created using MagicDraw UML
based CASE tool and generates C or C++ or Promela implementations of the
Startchart model. I am interested in moving our tool toward an EMF
implementation but so fare it looks like EMF is intended more for
modeling generic class structures and does not include the OMG
Statechart representations yet. Can someone please set me straight on this?

Is there a straight forward path to building the sort of tools I
described above in EMF, if so can some point me to the documents I need
to review in order to quickly prototype something?
Regards,
Len
--
____________________________________________________
Leonard J. Reder
Jet Propulsion Laboratory
Flight Software Applications & Data Product Management,
Section 316D
Email: reder@jpl.nasa.gov
Phone (Voice): 818-354-3639
Mail Address:
Mail Stop: 198-138
4800 Oak Grove Dr.
Pasadena, CA. 91109
---------------------------------------------------
Re: EMF Statechart support for generating state machine codes [message #425888 is a reply to message #425886] Thu, 11 December 2008 08:08 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 676
Registered: July 2009
Senior Member
Leonard J. Reder wrote:
> ... EMF is intended more for
> modeling generic class structures and does not include the OMG
> Statechart representations yet.

You're right. And it never will support this. Its 'metalanguage' is
called ECore, which is basically class models. This reduces the
complexity of the heavyweight OMG specs such as UML. Nevertheless, it
can be used to build similar things:

http://www.eclipse.org/articles/Article-FromFrontendToCode-M DSDInPractice/article.html

There's more than just EMF used in this article, but EMF sits at the
very core of the technologies mentioned there. For simplification, the
article uses a custom statechart meta-model defined with EMF. If you
need to support OMG (UML?) Statechart models, I guess you should have a
look at UML2 (www.eclipse.org/uml2). This should definitely support
statecharts. Once you have your model in memory, you have a thousand
ways to generate code from that, e.g.

- StringTemplate
- XText
- JET (used by emf itself to generate code for ecore models)


Hope this helps a bit.
Felix
Re: EMF Statechart support for generating state machine codes [message #425891 is a reply to message #425888] Thu, 11 December 2008 08:47 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 676
Registered: July 2009
Senior Member
Felix Dorner wrote:

> - XText

I guess this should be xPand.
Sorry.
Re: EMF Statechart support for generating state machine codes [message #425893 is a reply to message #425886] Thu, 11 December 2008 09:21 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6482
Registered: July 2009
Senior Member
Len,

Let me start a bit general. For the straight approach to model-based
code generation you're asking for you basically need 3 things:

1) Input models
2) Templates (or other model to text transformations)
3) Generator configuration to define which parts of the input models are
to be passed into which templates

Input models are instances of input meta models. Templates can be seen
as instances of a template language. And even the generator
configuration is often an instance of a generator configuration meta
model. Each model is an instance of some meta model, including these
meta models (a meta meta model and so on, Ed will hit me!).

EMF provides the following (wrt. the above categories):

a) a meta meta model called Ecore, which is recursively defined by
itself (thereby limiting the meta meta... chaining at the top)
b) a template language called JET (Java Emitter Templates), which is
basically like JSP
c) a set of concrete JET templates to transform instances of the Ecore
meta meta model into Java classes
d) a generator configuration mechanism which is (IIRC) bound to the
extension registry

Personally I believe that the strength of EMF is a), but the most
important point is that you can take any part of EMF, particularly a)
and b), and combine it with any other technology that fits your
requirements.

One common scenario is that you use Ecore to define your own meta model
(a DSL), for example a meta model that describes the concepts of a
finite state machine. With the default JET templates you can generate
Java code to represent instances of this meta model and the EMF runtime
provides for XML/XMI persistence of these instances. The you can write
your own JET templates to generate whatever sort of text you like. I'm
currently not sure how good EMF is to define generator configurations
for such custom models and templates, but in the worst case it's quite
easy to do it yourself, i.e. load your input model, instantiate your
templates, call the templates with your input model and save the
resulting text to files.

To sum up in terms of the first enumeration:

ad 1) EMF is a *must* for all the modeling aspects (input models, their
meta models and so on)
ad 2) EMF is a *can* for the model-to-text aspects. There exist
alternatives: Xpand, MofScript, Acceleo, XSL and many others
ad 3) EMF won't help much for generator configuration if custom DSLs are
involved. There exist alternatives: Sympedia GenFW, EMFT MWE, oAW (=MWE?)

Often the developer front-ends (e.g. MagicDraw) already exist and
produce models in a certain format. If that format is XML and you have
the associated XML schema (XSD) at hand, then it's easy to
convert/import this schema into Ecore and generate Java code to deal
with instances of this model, i.e. load them and make them available for
any sort of generator technology like JET.

The whole area is end-less, so you might be further interested in
certain topics. I hope this helped a bit to start ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com



Leonard J. Reder schrieb:
> Hello All,
> I spent about a day looking at EMF and working through the tutorials and
> still cannot easily answer this question. Can the EMF be used to build
> a tool to parse XMI Statechart models and generate state machine
> implementation code in the forms of various design patterns using
> various languages like C and C++?
>
> We presently have a Java tool that reads XMI created using MagicDraw UML
> based CASE tool and generates C or C++ or Promela implementations of the
> Startchart model. I am interested in moving our tool toward an EMF
> implementation but so fare it looks like EMF is intended more for
> modeling generic class structures and does not include the OMG
> Statechart representations yet. Can someone please set me straight on
> this?
>
> Is there a straight forward path to building the sort of tools I
> described above in EMF, if so can some point me to the documents I need
> to review in order to quickly prototype something?
> Regards,
> Len


Re: EMF Statechart support for generating state machine codes [message #425926 is a reply to message #425893] Fri, 12 December 2008 04:34 Go to previous messageGo to next message
Leonard J. Reder is currently offline Leonard J. RederFriend
Messages: 9
Registered: July 2009
Junior Member
Thank you both for the replies. I will look into it further
although it may not be the correct solution immediately.

I think we are presently implementing what you call the
meta-model for state machines as ad-hoc JAVA classes and I want to see
this get more standard so it can plug into other implementations.

The EMF definitely sounds like a direction to achieving this but
it seems like a significant learning curve as well.
Regards,
Len


Eike Stepper wrote:
> Len,
>
> Let me start a bit general. For the straight approach to model-based
> code generation you're asking for you basically need 3 things:
>
> 1) Input models
> 2) Templates (or other model to text transformations)
> 3) Generator configuration to define which parts of the input models are
> to be passed into which templates
>
> Input models are instances of input meta models. Templates can be seen
> as instances of a template language. And even the generator
> configuration is often an instance of a generator configuration meta
> model. Each model is an instance of some meta model, including these
> meta models (a meta meta model and so on, Ed will hit me!).
>
> EMF provides the following (wrt. the above categories):
>
> a) a meta meta model called Ecore, which is recursively defined by
> itself (thereby limiting the meta meta... chaining at the top)
> b) a template language called JET (Java Emitter Templates), which is
> basically like JSP
> c) a set of concrete JET templates to transform instances of the Ecore
> meta meta model into Java classes
> d) a generator configuration mechanism which is (IIRC) bound to the
> extension registry
>
> Personally I believe that the strength of EMF is a), but the most
> important point is that you can take any part of EMF, particularly a)
> and b), and combine it with any other technology that fits your
> requirements.
>
> One common scenario is that you use Ecore to define your own meta model
> (a DSL), for example a meta model that describes the concepts of a
> finite state machine. With the default JET templates you can generate
> Java code to represent instances of this meta model and the EMF runtime
> provides for XML/XMI persistence of these instances. The you can write
> your own JET templates to generate whatever sort of text you like. I'm
> currently not sure how good EMF is to define generator configurations
> for such custom models and templates, but in the worst case it's quite
> easy to do it yourself, i.e. load your input model, instantiate your
> templates, call the templates with your input model and save the
> resulting text to files.
>
> To sum up in terms of the first enumeration:
>
> ad 1) EMF is a *must* for all the modeling aspects (input models, their
> meta models and so on)
> ad 2) EMF is a *can* for the model-to-text aspects. There exist
> alternatives: Xpand, MofScript, Acceleo, XSL and many others
> ad 3) EMF won't help much for generator configuration if custom DSLs are
> involved. There exist alternatives: Sympedia GenFW, EMFT MWE, oAW (=MWE?)
>
> Often the developer front-ends (e.g. MagicDraw) already exist and
> produce models in a certain format. If that format is XML and you have
> the associated XML schema (XSD) at hand, then it's easy to
> convert/import this schema into Ecore and generate Java code to deal
> with instances of this model, i.e. load them and make them available for
> any sort of generator technology like JET.
>
> The whole area is end-less, so you might be further interested in
> certain topics. I hope this helped a bit to start ;-)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> Leonard J. Reder schrieb:
>> Hello All,
>> I spent about a day looking at EMF and working through the tutorials and
>> still cannot easily answer this question. Can the EMF be used to build
>> a tool to parse XMI Statechart models and generate state machine
>> implementation code in the forms of various design patterns using
>> various languages like C and C++?
>>
>> We presently have a Java tool that reads XMI created using MagicDraw UML
>> based CASE tool and generates C or C++ or Promela implementations of the
>> Startchart model. I am interested in moving our tool toward an EMF
>> implementation but so fare it looks like EMF is intended more for
>> modeling generic class structures and does not include the OMG
>> Statechart representations yet. Can someone please set me straight on
>> this?
>>
>> Is there a straight forward path to building the sort of tools I
>> described above in EMF, if so can some point me to the documents I need
>> to review in order to quickly prototype something?
>> Regards,
>> Len


--
____________________________________________________
Leonard J. Reder
Jet Propulsion Laboratory
Flight Software Applications & Data Product Management,
Section 316D
Email: reder@jpl.nasa.gov
Phone (Voice): 818-354-3639
Mail Address:
Mail Stop: 198-138
4800 Oak Grove Dr.
Pasadena, CA. 91109
---------------------------------------------------
Re: EMF Statechart support for generating state machine codes [message #425928 is a reply to message #425926] Fri, 12 December 2008 06:51 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6482
Registered: July 2009
Senior Member
Leonard J. Reder schrieb:
> Thank you both for the replies. I will look into it further
> although it may not be the correct solution immediately.
>
> I think we are presently implementing what you call the
> meta-model for state machines as ad-hoc JAVA classes and I want to see
> this get more standard so it can plug into other implementations.
>
> The EMF definitely sounds like a direction to achieving this but
> it seems like a significant learning curve as well.
Both are true. After going through this initial learning phase you will
not want to live without EMF anymore ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com


> Regards,
> Len
>
>
> Eike Stepper wrote:
>> Len,
>>
>> Let me start a bit general. For the straight approach to model-based
>> code generation you're asking for you basically need 3 things:
>>
>> 1) Input models
>> 2) Templates (or other model to text transformations)
>> 3) Generator configuration to define which parts of the input models
>> are to be passed into which templates
>>
>> Input models are instances of input meta models. Templates can be
>> seen as instances of a template language. And even the generator
>> configuration is often an instance of a generator configuration meta
>> model. Each model is an instance of some meta model, including these
>> meta models (a meta meta model and so on, Ed will hit me!).
>>
>> EMF provides the following (wrt. the above categories):
>>
>> a) a meta meta model called Ecore, which is recursively defined by
>> itself (thereby limiting the meta meta... chaining at the top)
>> b) a template language called JET (Java Emitter Templates), which is
>> basically like JSP
>> c) a set of concrete JET templates to transform instances of the
>> Ecore meta meta model into Java classes
>> d) a generator configuration mechanism which is (IIRC) bound to the
>> extension registry
>>
>> Personally I believe that the strength of EMF is a), but the most
>> important point is that you can take any part of EMF, particularly a)
>> and b), and combine it with any other technology that fits your
>> requirements.
>>
>> One common scenario is that you use Ecore to define your own meta
>> model (a DSL), for example a meta model that describes the concepts
>> of a finite state machine. With the default JET templates you can
>> generate Java code to represent instances of this meta model and the
>> EMF runtime provides for XML/XMI persistence of these instances. The
>> you can write your own JET templates to generate whatever sort of
>> text you like. I'm currently not sure how good EMF is to define
>> generator configurations for such custom models and templates, but in
>> the worst case it's quite easy to do it yourself, i.e. load your
>> input model, instantiate your templates, call the templates with your
>> input model and save the resulting text to files.
>>
>> To sum up in terms of the first enumeration:
>>
>> ad 1) EMF is a *must* for all the modeling aspects (input models,
>> their meta models and so on)
>> ad 2) EMF is a *can* for the model-to-text aspects. There exist
>> alternatives: Xpand, MofScript, Acceleo, XSL and many others
>> ad 3) EMF won't help much for generator configuration if custom DSLs
>> are involved. There exist alternatives: Sympedia GenFW, EMFT MWE, oAW
>> (=MWE?)
>>
>> Often the developer front-ends (e.g. MagicDraw) already exist and
>> produce models in a certain format. If that format is XML and you
>> have the associated XML schema (XSD) at hand, then it's easy to
>> convert/import this schema into Ecore and generate Java code to deal
>> with instances of this model, i.e. load them and make them available
>> for any sort of generator technology like JET.
>>
>> The whole area is end-less, so you might be further interested in
>> certain topics. I hope this helped a bit to start ;-)
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>> Leonard J. Reder schrieb:
>>> Hello All,
>>> I spent about a day looking at EMF and working through the tutorials
>>> and
>>> still cannot easily answer this question. Can the EMF be used to build
>>> a tool to parse XMI Statechart models and generate state machine
>>> implementation code in the forms of various design patterns using
>>> various languages like C and C++?
>>>
>>> We presently have a Java tool that reads XMI created using MagicDraw
>>> UML
>>> based CASE tool and generates C or C++ or Promela implementations of
>>> the
>>> Startchart model. I am interested in moving our tool toward an EMF
>>> implementation but so fare it looks like EMF is intended more for
>>> modeling generic class structures and does not include the OMG
>>> Statechart representations yet. Can someone please set me straight
>>> on this?
>>>
>>> Is there a straight forward path to building the sort of tools I
>>> described above in EMF, if so can some point me to the documents I need
>>> to review in order to quickly prototype something?
>>> Regards,
>>> Len
>
>


Previous Topic:EMF+GWT status?
Next Topic:[CDO/EMF] Missing serialized package: myPackage.ecore
Goto Forum:
  


Current Time: Sat Feb 22 07:22:18 GMT 2020

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

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

Back to the top