Steven Kelly on DSM

MERL and openArchitectureWare's Xpand languages are rather similar in approach and functionality. The main differences are in syntax and keywords, so learning one if you know the other is easy. In the MetaEdit+ forum I've posted a quick primer on how to translate from Xpand to MERL. The primer is below, with comments after the respective row where necessary.

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.

It was a nice start to my New Year to see kind words about us in Peter Bell's blog. You might have had the pleasure of meeting Peter at OOPSLA or Code Generation, but what you may not know is what a "rock star" guru he is in the ColdFusion community. In our terms, ColdFusion is a DSL solution for dynamic web sites -- like Ruby on Rails, but since 1995. Peter is thus well acquainted with the issues of DSL evolution: in ColdFusion, and in his own DSLs around it. And, as anyone who has met him will attest, he's also a truly great guy to be with: rare in someone with that level of technical skill. (And I so wish I'd said this about him earlier, before having to blog about him saying nice things about us!)

Domain Specific Modeling: Key Vendors

"I'd strongly recommend anyone interested in DSM check out MetaEdit+ and openArchitectureWare.

The commercial (but affordable) MetaEdit+ is still for me the reference implementation for DSM tools and has solved problems such as being able to load old models after upgrading the metamodel that most other vendors haven't come to grips with yet. It doesn't work for every use case, but if it works for you it is a very mature offering and the team has a great deal of technical experience. If nothing else, check it out just to know the questions to ask any other vendor you may be considering!

openArchitectureWare is an open source set of tools for developing DSM solutions within Eclipse. It has really matured recently with better tooling for easily generating plug-ins for textual DSLs based on a meta-model and constraints and it also has good tooling for visual modeling. It isn't as polished or seamless as MetaEdit+ but with the team behind it, it is again one of the products you have to consider if you're going to be doing any DSM and if you use Eclipse it's probably a really strong contender."

openArchitectureWare (oAW to its friends) is a set of little languages for manipulating models: model checking (Check), transformation of models to text (Xpand), models to models (Xtend), and text to models (Xtext). It's most commonly used on Eclipse EMF models, but can work on other models too. The fascinating thing for me is the Xpand language. It's remarkably similar to our MERL, even though there is no shared history: neither party knew about the other until much later on.

MERL and Xpand are both true DSLs for the task of turning models into code or other text. That makes them IMHO much easier to use for creating and maintaining your generators, compared with more simplistic templating languages like JET or T4. It also means that once you have learned to use one, switching to the other is largely just changing the keywords and punctuation.

From: Ivan Porres <iporres@abo.fi>

The Center for Reliable Software Technology CREST at Åbo Akademi University in Turku, Finland is looking to expand its research team on model driven software and system engineering with one new post-doctoral researcher position and one doctoral student position in the area of software modeling languages and tools.

CREST is a research center at the Department of Information Technologies at Åbo Akademi University. Its research is focused on the development and analysis of software intensive systems and on the use of software based research paradigms in systems modeling and development.

We are looking for post-doctoral and PhD. researchers interested in working on a research project focusing in the definition of software and system modeling languages, including domain-specific modeling languages, modeling tools supporting these languages, and the validation of software modeles and languages. The work will be developed under the supervision of Ivan Porres.

Post-doctoral Position

Candidates for a post-doctoral position should have a doctoral degree in software engineering or a closely related field and research experience in topics such as the definition of the UML, definition of domain-specific modeling languages, metamodeling, description logics and tools such as EMF and Alloy. We offer full-time employment for 1 year, ideally starting from Janurary 2009. The employment and salary will be based on the standard agreement and conditions at Åbo Akademi University. In practice, the monthly salary for a postdoctoral researcher is around 2500-3000 euro before taxes depending on experience.

PhD. Position

Candidates for a PhD. position should have a MSc in Mathematics, Computer Science, Electrical engineering and good communication and writing skills in English. PhD. students are expected to defend their doctoral thesis within 4 years. We offer full-time employment for 4 years, with an intermediate evaluation after the first year.

Application Procedure

If you are interested in one of the previous positions please send an email to iporres@abo.fi including the following attachments:

• a motivation letter
• short description of your research interests
• full C.V.
• list of publications (Post doc position)
• a copy of your M.Sc. degree certification together with your course program and corresponding grades, and (PhD. student position)
• Contact information for 2 referees.

Please send your attachments in pdf format. The vacancies will be filled on demand, and next deadline is November 30 for starting on January 2009. The following deadline will be February 28 2009. Do not hesitate to contact Ivan Porres (iporres@abo.fi) if you have any questions about the application procedure.

Spotted in Claudio Perrone's Monologues

It is realistic to assume that experienced developers/architects who fully understand the domain and have been involved in the development of enterprise frameworks are the natural candidates for authoring well thought DSLs for an individual organization. On the other hand, there is a danger that such authors might treat DSLs exactly like class frameworks, without realizing that the forces at work are significantly different. ...

Using this tactic for DSLs would lead us to create “flexible” implementations of a language through the introduction of (superfluous) configuration/customization options to our models, without considering that every time we add an extra element, attribute or connection to a DSL we arguably make the language more difficult to use and, ironically, less adaptable.

Yep. As Claudio and I discussed earlier, it's all too easy to build your first modeling language at the same level of abstraction as the code you used to write, and therefore miss out on 90% of the benefits of DSM. As developers we're taught that making something more general -- expanding its range of application -- is a virtue. Even in building a framework, though, this can be taken to extremes. Anybody who has programmed with Windows file dialogs or used DirectX will be familiar with the problem of having to supply 17 parameters or do 10 steps to complete one simple action. On the issue of Humane vs. Minimalist interfaces, I side with Jeroen's basic conclusion: both minimalism and humaneness are virtues, so we want both. One way to get that is his suggestion of a humane interface wrapping a minimal implementation. Another is imply to strive for the most efficient balance: the Minimal Humane interface.

A DSM language aims to minimize the time needed to create the desired range of applications. That's a long way from the Minimalist argument: a minimalist won't bat an eyelid at the >300,000,000 calls to aList.get(aList.size -1) in Java programs. (If you don't believe my figure, go count them yourself :->). But just think of the extra time it took each time to write that rather than aList.last(): one is 24 characters, the other 12. With my typing, that's 10 seconds vs. 5 seconds, so a cost to the global economy of >500,000 man-hours. And how often does somebody make the mistake of aList.get(aList.size)? Even if it's only a one in a thousand mistake, that's still >300,000 bugs that have to be found and corrected.

Now tell me, what is the cost of creating an operation called last()? Probably all of 50 seconds, including documentation. And what is the cost to users in terms of learning another operation, and having to scan over it when looking for something else? Even my boldness doesn't stretch to estimating that! But surely, for a class as frequently used as Array/List, and for an operation as obvious as last, the cost of having that extra operation is offset by the saving in having simpler code?

That simplicity is a key factor in the increase in productivity with DSM. Unfortunately, there's no easy way to measure simplicity. 17 arguments for a file dialog operation is not simple. Having an extra operation for last may well increase simplicity. The trick is to look not from the language creator's point of view, but from the language user's point of view. If 90% of file dialog calls vary in only 3 of the 17 arguments, there should be at least a utility call for that case, with just those 3 arguments. In DSM, you may even decide to drop the other 14 arguments altogether: if anyone wants to use them, they can drop down to hand-code that part. That might even make the application's use of file dialogs more consistent -- how many times did someone choose a different value for a parameter just because they couldn't remember what the "company standard" way of using them was?

Part of the beauty of DSM is that the language can evolve, and the models update automatically (at least with a decent tool). If you find you actually need 4 arguments, you just add that 4th argument to the File Dialog object type, and all instances will automatically be updated with that 4th argument containing its default value. No need to update all your existing file dialog calls by hand, or to maintain both the new and old file dialog calls in the framework. One change by the language creator, in a few seconds, rather than a similar change by every developer, in every file dialog call, in every one of his models. Now that's both Humane and Minimal!