Home » Modeling » EMF » EMF Statechart support for generating state machine codes
| | |
| Re: EMF Statechart support for generating state machine codes [message #425893 is a reply to message #425886] |
Thu, 11 December 2008 09:21   |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: EMF Statechart support for generating state machine codes [message #425926 is a reply to message #425893] |
Fri, 12 December 2008 04:34 |
 Leonard J. Reder
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 |
|
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
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Tue Apr 16 04:14:03 GMT 2024
Powered by FUDForum. Page generated in 0.06589 seconds |
] 
Search
Help
Register
Login
Home
