hide all comments

DSM-tech

Re: Processing of MetaEdit Models with oAW

August 28, 2009 14:49:21 +0300 (EEST)

Heiko Kern has written a great set of information on how to process MetaEdit+ models with oAW (the openArchitectureWare model transformation tools for Eclipse). The integration he's built is a great example of how easy it is to integrate MetaEdit+ with other tools:

  • You can export models or metamodels from MetaEdit+ as XML. The format is an extension of the open Graph eXchange Language standard, GXL, supported by over 40 tools.
  • You can quickly write a little generator to output your models in whatever XML or other text format you want.
  • MetaEdit+ can call other tools from its generators, e.g. for build integration.
  • Other tools can call MetaEdit+ with command-line parameters to specify a series of actions to run.
  • Other tools can call MetaEdit+ through its WebServices / SOAP API, to create/read/update/delete any data in models, and for control integration, e.g. to animate models for model-level debugging.
  • You can import models or metamodels as XML.
  • You can import text in any format and convert it to models via reverse engineering generators.

At last year's OOPSLA DSM workshop, Heiko had an article about his MetaEdit+ / Eclipse integration. We had a good discussion about it, in particular about his reasons for building it. His paper gave the impression that he wanted to use oAW rather than MetaEdit+'s own MERL generator language, because he needed some specific features in oAW. It turned out though that he hadn't actually used MERL, and didn't realise that MERL and oAW's XPand are actually very similar in terms of approach and functionality.

MERL tends to be a little more succint: here is the MERL generator to output simple Java classes for a UML Class Diagram, as in Heiko's example:

subreport '_translators' run

foreach .Class [UML]
{  filename id '.java' write
      'public class ' id ' {' $cr2

      do :Attributes
      {  '   ' :Visibility ' ' :Data type; ' ' :Name ';' $cr2

         '   public void set' :Name%firstUpper '(' :Data type; ' ' :Name ') {' $cr
         '      this.' :Name ' = ' :Name ';' $cr
         '   }' $cr2

         '   public ' :Data type; ' get' :Name%firstUpper '() {' $cr
         '      return this.' :Name ';' $cr
         '   }' $cr2
      }
      '}'
   close 
}

Heiko's oAW XPand code is 65% longer. Even ignoring the extra loop over all Class Diagrams that Heiko needs (MetaEdit+ offers that automatically in the UI or via the forAll:run: command-line parameter), oAW is still over 20% longer. The actual difference isn't that important: I'm sure both could be made shorter for this example, but the current code is typical of what is generally written. My point is that there's no real saving to be had by using XPand instead of MERL. If your models are in MetaEdit+, use MERL; if they're in Eclipse, use oAW. Having integration is great, but if you can avoid using it then that's even better.

Edit:Since MERL and Xpand are quite similar, I've made a MERL primer for Xpand users. I find it fascinating (and somewhat reassuring) that two languages created from scratch for the same task, and evolving for many years before encountering each other, should have chosen or converged on such similar approaches and solutions.

Comments

Re: Re: Processing of MetaEdit Models with oAW

[Heiko Kern] September 02, 2009 20:36:46 +0300 (EEST)

Hi Steven, thank you for your response to my article. I agree with you in many points. Nevertheless, I would like to address some issues. The (re-)implementation of the UML-to-Java example in MERL is really nice and shows the expressiveness of MERL. However, your comparison between my oAW variant and your MERL variant doesn't consider the following two facts. Firstly, in my oAW example, the model structure is the result of the M3B between MetaEdit+ and Eclipse EMF. Hence, I need some additional (select/query) operations. Secondly, your MERL variant uses a loop over all attributes, instead my variant uses the EXPAND mechanism. Both facts blow up the code unnecessarily. A solution to the first problem could be the implementation of generic operations that are equivalent to MetaEdit+ operations (e.g. the loop over all diagrams of a certain type). These operations could be implemented as an additional feature of the M3B and could be reused in different EMF-based tools. A solution to the second point is the use of oAW's «FOREACH»«ENDFOREACH» expression. These two changes should be enough in order to achieve the same code length as your MERL transformation.

Furthermore, I want to say something about my motivation for building the MetaEdit-EMF-Bridge. My research interests are in DSM/MDD and especially in metamodeling and model interoperability. I investigate an approach that I call M3-level-based Bridge or Metametamodel-based Transformation. This approach allows me to achieve model interoperability between model hierarchies consisting of three levels. The MetaEdit-EMF-Bridge is one application of this M3B approach. The use of this bridge, the discussion about this bridge, and so on gives me valuable feedback and experience for my research work. In my opinion the MetaEdit-EMF-Bridge is an interesting case because both tool spaces cover equal DSM/MDD tasks. The functionality of MetaEdit+ and of EMF-based tools are very similar. But maybe there are other reasons for using EMF-based tools instead of MetaEdit+. I think from a practical view, our articles provide a good conclusion. If both tool spaces complement each other then the bridging concept is very useful. Conversely this means, if both tool spaces are almost equal then it is less useful.

Re: Re: Processing of MetaEdit Models with oAW

[Steven Kelly] September 08, 2009 17:30:58 +0300 (EEST)

Thanks Heiko, I'd imagined that it should be possible to make your code a little shorter. I'm not sure why in Xpand it is common to use EXPAND rather than just FOREACH - maybe because there tend to be many generators in one file/window, so there is more need to split things up to stop it becoming one big long mess? In MetaEdit+ each generator is seen on its own, classified by graph type and generator name.

I'd agree that MetaEdit+'s MERL and oAW's Xpand are close enough that in general bridging in either direction isn't necessary. However, I don't agree that "the functionality of MetaEdit+ and of EMF-based tools are very similar". And nor does Markus Voelter: he'd much rather have the "really cool" Diagram Editor of MetaEdit+ than GMF's "awful" editors.

Maybe the real solution is just to do your model editing and processing in MetaEdit+, and simply link to it from your favourite IDE - as many of our users in both Eclipse and VisualStudio do. You can open repositories and/or individual models by clicking on them in the source tree in your IDE, and generation in MetaEdit+ can add files to the source tree in your IDE (if you want), or you can run generation from the IDE or whatever your favourite build tool is.

[Dex Fischer] February 05, 2010 11:47:57 +0200 (EET)

Guys, I thank both of you for the most informative posts. I read and downloaded both articles [dubious comment link removed. -Ed] and understood the main idea. The only question arises. Can we transform an EPC model, such as the one in Figure 3 after the transformation of the metamodel from MetaEdit to EMF?

Re: Re: Processing of MetaEdit Models with oAW

[Steven Kelly] February 05, 2010 11:59:47 +0200 (EET)

Dear Dex,

It's great to see entities like you taking an interest in meta-metamodels. Admittedly your question is a rather simple transformation of a line from Heiko's article:

"After the transformation of the metamodel from MetaEdit to EMF, we can transform an EPC model, such as the one in Figure 3"

Of course that line answers your question, which is a bit of a giveaway that you don't yet pass the Turing Test. But still I'm impressed.

Yours sincerely,
Steve's automated spam detecter.