[gmt-dev] [modeling-dev] EMF Feature Modeling / Active Models

[Miles Parker <milesparker@xxxxxxxxx>]

[apologies in advance for a bit more cross-posting..]

Great, Marc -- I will take some time and check out the links closely. I also thought that MXF was pretty much not happening, but didn't want to make assumptions. You might also take a look at AMP.. specifically of interest might be http://eclipse.org/amp/documentation/contents/Modeler_Guide.html#Actions_2 which discusses the execution / action semantics. Note that the actual execution modality is completely unspecified as is yours I think. This is very important as it means that we can target completely arbitrary platforms in fact, up until now all of those targets are non-EMF dependent and only one of them has Eclipse dependencies. 

Because of the domain, I've been especially focussed on runtime performance, which together with need for complete target independence is why the emphasis on code generation as opposed to more dynamic/open-ended approaches. But the approach could be implemented pretty easily dynamically. I've also been working on a DSL for it in XText (on and mostly off again for the last two year!) that has a Model Query and Transformation flavor as I think you'll see the backing Actions meta-model does. But I think for model execution you will also need the ability to support existing GPLs and query languages and that is something it looks as though you have focussed on. I think M2M is an interesting way to look at this through a slightly different lens. Actually, in some twisted way :), M2M could actually be thought of as a target for an Action specification, so you could have an M2M from AMF to your M2M specification! So the bottom line is that we probably have some orthogonal but complimentary concerns and may also have some areas where we are working toward the same functionality.


I'm realizing that I haven't done a good job at clarifying how AMF fits in with and complements the other EMF based approaches to the Modeling Project (cc'd in for this) as a whole. ("What the hell is this AMP project?") While the Raison d'être for AMP is Agent-Based Modeling, I've always had the idea in the back of my head that it would be applicable to generic modeling and specifically for people creating ecore models.  But there are clearly pieces missing that are needed to make it more general. I actually avoided using EMF as the original target meta-model and developed a purpose built meta-model for a few reasons.. a) The Semantics for the specific "agenty" / ModSim domain are different..we're concerned with spatial relationships, explicit containment hierarchies, etc.. b) EMF was actually too over-specified WRT to implementation architecture (for example with attribute typing) and c) it was strongly recommended by Ed and others not to try to hack / extend Ecore, d) I didn't have enough imagination or time to figure out how to support both. But...all that said, I think that has really unnecessarily limited the potential user base to a very small subset of potential users and there is no deep reason that all or most of the functionality it could not be provided for EMF models.

Getting back to the original query, that's what has motivated my question about feature modeling. My current strategy is to create versions of AMF agents that wrap and advise existing EMF models much in the way say that genmodel or EEF works -- it's sort of fragile and makes things harder on users, but it is the best solution I can come up with. It doesn't really make sense to extend EMF meta-classes like EClass and EAttribute or their AMF counterparts.  And annotations are not the way to go here. So my hope was that perhaps Feature support would allow me to mix-in the stuff that I need into EMF definitions and/or vice-versa.

cheers,

Miles

On Oct 6, 2010, at 2:36 PM, Marc Pantel wrote:

> Hi,
> 
> No, we were interested to participate in MXF but we never managed to arrange a meeting with the german leaders of the project. The current state and liveness of the project is not really clear for us.
> 
> We have proposed and experimented some methods, metamodeling patterns and generative tools for defining the execution semantics and associated tools of DSML. These experiments were conducted in the TOPCASED project and led to the current model animator prototypes in the TOPCASED project : http://gforge.enseeiht.fr/projects/topcased-ms.
> 
> The metamodeling pattern is used to extend the usual language metamodel to express the various execution consideration (model state, execution events and traces). Then, a classical programming language using the EMF API, or better a model transformation language can be used to define the event handling function that compute the next model state. We have experimented the use of Java, SmartQVT, ATL, Kermeta and MediniQVT. The TOPCASED prototypes rely on SmartQVT. Many experiments have also been done with Kermeta.
> 
> You can find some informations in : http://www.irisa.fr/triskell/perso_pro/combemale/research/2010/ecmfa10-CCPFP.pdf and http://www.irisa.fr/triskell/perso_pro/combemale/research/phd/2008/erts08-CCGMP.pdf
> 
> Of course, do not hesitate in asking for more details.
> 
> We are interesting in cooperating with any initiative on the subjects and would be glad to discuss and exchange around your proposal of "active models".
> 
> Best regards,
> Marc & cie
> 
> Le 6 oct. 2010 à 22:57, Miles Parker a écrit :
> 
>> 
>> Cool! M2M is an interesting lens to think about this stuff through. Are you the folks who were working on the MXF stuff? We could discuss here or move it to AMP-dev as you prefer.
>> 
>> On Oct 6, 2010, at 12:55 PM, Raphael FAUDOU wrote:
>> 
>>> 
>>> 
>>> Le 06/10/2010 20:29, Miles Parker a écrit :
>>>> 
>>>> OK, I'll wait to hear from Holger. I'm definitely an interested party as well -- there is definitely some overlap / cross-pollinazation potential there -- at the very least I could really use some of this functionality as I think about how to make the fit between the AMF meta-model and Ecore tighter.
>>>> 
>>>> While I'm on the subject, if anyone in Eclipse modeling community is interested in Model Execution and/or "Modeling" in the Modeling and Simulation sense please let me know.
>>> Sure we are. With "Topcased simulation" we now have some experience of possible simulation by extending the initial model with "token", "events" and "transitions" concepts through a M2M transformation. It was instanciated with success on UML statecharts with interactive injection of events, diagram animation, recording of simulation scenarii and replay capabilities. Now we would like to explore the activity diagrams and potentially other languages...
>>> 
>>>> I am working on some ideas to get the value that is in the AMP stuff to support what I'm going to call for now at least "Active Models" and if there is existing or contemplated work that might be related it would be good to work toward that now rather than try to fit it all back together later. :)
>>> We would be very pleased to have some discussions with you about that.
>>> Cheers
>>> TOPCASED team
>>>> 
>>>> cheers,
>>>> 
>>>> Miles
>>>> 
>>>> On Oct 6, 2010, at 11:19 AM, Kenn Hussey wrote:
>>>> 
>>>>> Miles,
>>>>> 
>>>>> I'm not actually personally working on it, but I'm certainly interested in its status as well. Details on the project can be found at http://www.eclipse.org/projects/project_summary.php?projectid=modeling.emft.featuremodel and the wiki page reference therein. It was tentatively scheduled to release something last week, so perhaps Holger can give us an update...
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Kenn
>>>>> 
>>>>> On Wed, Oct 6, 2010 at 1:09 PM, Miles Parker <milesparker@xxxxxxxxx> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I'm wondering what the status is with EMF Feature Modeling effort (now there is a set of words that are almost impossible to google on a meaningful way!) that Kenn and others have been working on. The proposal page goes to EMFT, where I couldn't find any mention.
>>>>> 
>>>>> thanks,
>>>>> 
>>>>> Miles
>>>>> _______________________________________________
>>>>> modeling-dev mailing list
>>>>> modeling-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/modeling-dev
>>>>> _______________________________________________
>>>>> emf-dev mailing list
>>>>> emf-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/emf-dev
>>>>> 
>>>>> _______________________________________________
>>>>> modeling-dev mailing list
>>>>> modeling-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/modeling-dev
>>>>> _______________________________________________
>>>>> tmf-dev mailing list
>>>>> tmf-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/tmf-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> modeling-dev mailing list
>>>> 
>>>> modeling-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/modeling-dev
>>>> 
>>>> _______________________________________________
>>>> emft-dev mailing list
>>>> 
>>>> emft-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/emft-dev
>>> 
>>> -- 
>>> <ao_ioc_sign2.gif> 	Raphaël FAUDOU
>>> Responsable cellule Innovation / bureau méthodes 
>>> Head of Innovation & Method Definition 
>>> Embedded systems & critical systems 
>>> Atos Origin 
>>> 
>>> Tel     : +33 (0)5 34 36 32 89
>>> Tel     : +33 (0)6 10 53 50 44
>>> Mail   : raphael.faudou@xxxxxxxxxxxxxx
>>> Atos Origin 
>>> 6, Impasse Alice Guy 
>>> BP 43045 
>>> 31024 Toulouse Cedex 3, France 
>>> 
>>> P Avant d'imprimer cet e-mail, pensez à l'environnement. Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. 
>>> P Please consider your environmental responsibility before printing this e-mail. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. _______________________________________________
>>> emft-dev mailing list
>>> emft-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/emft-dev
>> 
> 
> Marc Pantel
> Maître de Conférences en Informatique
> Assistant Professor in Computer Science
> IRIT - Institut de Recherche en Informatique de Toulouse - CNRS
> N7 - INPT - Université de Toulouse - France - Europe
> phone +(33) 534 32 2185
> fax +(33) 534 32 2157
> cell +(33) 676 221 687
> 
> 
> 
> 

_______________________________________________
modeling-dev mailing list
modeling-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-dev