Re: [emf-dev] UML2 Statechart model import and code generation faciliti

[Kenn Hussey <kenn.hussey@xxxxxxxxx>]

This sounds like a great potential contribution to the Papyrus
project, especially given the prior work in Topcased...

Cheers,

Kenn


On 8/26/09, Joerg von Frantzius <joerg.von.frantzius@xxxxxxxxxxxxx> wrote:
> Hi Jacob,
>
> possibly you already heard about it, but just to make sure in case you
> didn't: within Topcased there is the experimental SMUC project for
> generating code from UML2 state machines. Please see this PDF
> <http://gforge.enseeiht.fr/frs/download.php/1241/tuto_pres_SMUC.pdf> for
> an overview, and http://gforge.enseeiht.fr/projects/smuc/ for the
> project page (but please don't let yourself get scared away by the
> horrible Gforge website..)
>
> The UML2 statechart editor and SMUC already went a good way, but they
> surely could need some love to make them really usable.
>
> Regards,
> Jörg
>
> Jacob Beard wrote:
>> Hi Ed and others on EMF-dev,
>>
>> GSoC has ended, and I'm now ready to revisit the idea of creating a
>> Statechart compiler based on UML2Tools that integrates with EMF.
>>
>> It looks like a good entry-point into solving this problem may be via
>> SCXML[0] and the Apache SCXML Commons library[1]. I've only just
>> started looking into it, but it seems like leveraging SCXML Commons
>> would eliminate the need to create from scratch a Statechart-to-Java
>> compiler and statechart execution environment. In order to leverage
>> SCXML Commons, it seems like it will be necessary to export a
>> UML2Tools statechart to SCXML, rather than XMI. This could probably be
>> achieved either by writing a custom generator that exports SCXML
>> directly from the EMF model, or by writing an XSLT script that
>> converts the Statechart serialized as XMI to SCXML. This second option
>> seems like it would be the more portable, reusable solution of the
>> two.
>>
>> I have two quick questions for the EMF list:
>> * Would it be better to have this discussion here on EMF-dev mailing
>> list, or would it be better to start a thread on UML2Tools?
>> * Is anyone aware of any work that has been done on generating
>> executable code from UML2Tools Statecharts since I originally brought
>> this up in March?
>>
>> I'd appreciate any guidance you can offer. Thanks,
>>
>> Jake
>>
>> [0] http://www.w3.org/TR/scxml/
>> [1] http://commons.apache.org/scxml/
>>
>> On Mon, Mar 23, 2009 at 8:20 AM, Ed Merks<ed.merks@xxxxxxxxx> wrote:
>>
>>> Jake,
>>>
>>> I'm not aware of this having been done.  It sounds like it would make
>>> another interesting GSoC proposal for the wiki!
>>>
>>> With the work on declaratively specifying behavior of derived features
>>> we've
>>> also been looking at similar things for the behavior of EOperations.   It
>>> would be awfully cool in the long term if one could invoke operations
>>> even
>>> on dynamic models and that it would invoke whatever type of interpreter
>>> is
>>> associated with the operation's behavior description....
>>>
>>> Cheers,
>>> Ed
>>>
>>>
>>> Jacob Beard wrote:
>>>
>>> Hi all,
>>>
>>> I am currently beginning to explore what is possible with Ecore and the
>>> UML2
>>> project. I understand that it is possible to import a UML2 model to
>>> Ecore.
>>> In the UML2.0 OMG standard, it is also possible to associate a Classifier
>>> with a component that describes its Behaviour, so either an Action,
>>> Activity, Interaction, or State Machine diagram. State Machine diagrams
>>> are
>>> especially useful because you can easily generate code from them. This is
>>> the workflow that I imagine might be possibe:
>>>
>>> 1. Create your UML model using UML2 Tools. For each Class, you associate
>>> a
>>> State Machine which describes its behaviour.
>>> 2. Transform your UML model to Ecore using the mdl-to-ecore importer.
>>> 3. Generate Java code from your new Ecore model.
>>> 4. Use generated Java code to instantiate M0-level entities.
>>> 5. Send events into the objects' generic Behaviour API (for example,
>>> Statechart.event(Event evt) ). For each class, the associated statechart
>>> should have been compiled down to executable code, which then determines
>>> how
>>> the event is to be handled at the instance level.
>>>
>>> Does a facility for this already exist? Specifically, is it possible to
>>> compile the state machines designed using UML2 Tools down into executable
>>> Java code?
>>>
>>> If this facility does not already exist, is this something that EMF might
>>> also be interested in as another GSoC project idea? This is not for
>>> myself,
>>> but for a colleague of mine who has done similar work in this domain,
>>> although I could definitely see my proposed project leveraging this
>>> facility, for example, for creating a web-based Statechart editor and
>>> simulator.
>>>
>>> I would greatly appreciate it if you would let me know what you think.
>>> Thanks,
>>>
>>> Jake
>>>
>>> ________________________________
>>> _______________________________________________
>>> emf-dev mailing list
>>> emf-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/emf-dev
>>>
>>>
>> _______________________________________________
>> emf-dev mailing list
>> emf-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/emf-dev
>>
>>
>
>
> --
> ____________________________________________________________________
> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
> UST-Id. DE 217652550
>
>

-- 
Sent from my mobile device