Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [emf-dev] UML2 Statechart model import and code generation facilities

Joerg,

I had not heard of this project, so thanks for the link! I'll drill
down into it a bit and see if it might be possible for me to make a
contribution.

Thanks,

Jake

On Wed, Aug 26, 2009 at 4:06 AM, 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 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
>
> _______________________________________________
> emf-dev mailing list
> emf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emf-dev
>
>


Back to the top