By Peter Bell

Domain Specific Modeling - Key Vendors (and last nights deck)

If you're interested in code generation and/or domain specific modeling, there are some vendors you really need to check out - if only to understand how comprehensive the tooling offerings are starting to become and what it takes to do DSM well.

This post lists some of the key DSM vendors together with a very quick summary of why you might want to check each one out . . .

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.

If you're mainly doing Visual Studio development, you'll want to look at the tooling available in Visual Studio. The first version was pretty painful. I know the latest version is being used in a good number of substantial projects, so I'm sure it is improving. To be honest I haven't looked at the Microsoft offerings in over 18 months, so it's probably worth looking through to see how close it's coming to MetaEdit+ and oAW.

I was surprised to read that JetBrains MPS is now in beta. It was directly inspired by Martin Fowlers classic article on Language WorkBenches and looks well worth checking out.

Also, Intentional continue to be "the company to watch next year" for another year. I know they were doing some real world tests in 2008 with a major consulting firm. It'll be interesting to see if they can deliver a beta this year as it certainly promises to be a revolutionary approach if they can deliver on the goals of the project.

Also, I said at my preso last night that I'd upload the deck. Here is the presentation as a pdf. It's pretty sparse as it was meant to stimulate discussion rather than to be detailed instructional material, but hopefully it'll be a useful aide memoire for anyone who turned up.

Comments
Hi Peter

I am interested in your strategies for merging markup of previously generated items during regeneration.
I am generating using JET only and my own custom xpath and tags.
Currently I am generating a large chunk of my flex app, merging code is pretty easy by makig certain that you define user areas, mxml (and I would imagine the markup with cf as well) is slightly more tricky.
Obviously any mxml file is a xml file, which means that if previously generated I can use xpath to query the generated item and get the user defined attributes and write them back into generation.
the problem arrises (and I suspect this is more of a mxml issue (but i don't know cf at all) when I generate controls. These controls could be contained in other nodes after a designer has changed the layout of a view, and here the problem gets more complex. I don't really want to go to deep into the sollutions i have been playing with, but I was wondering if you have some pointers, links , articles that deal with merging dom based files.

Johan
# Posted By johannes | 1/9/09 3:24 AM
@Johan,

In general that's a pretty specialized topic. Usually I recommend not mixing generated and hand coded script in the same file - it's much better to use inheritance, mixins, AOP or anything else to keep generated and custom code separately. Perhaps putting generated code into components even - anything that'll put them into different files.

If you really do want to mix, as you said, you're probably going to want to load up the XML and walk the dom to apply appropriate transformations. The general space you might want to look into is that of "Model to Model" (or M2M) transformations as that's about the closest field and may have some useful techniques or tooling. In addition to stuff like XSLT there are also M2M tools like ATLAS, but it is still a fairly under developed and specialized field.

Hope that is of *some* help, but my general rule of thumb is to make code gen as dumb as possible - typically the smarter it needs to be, the more likely it is to be brittle and/or hard to debug.

Good luck!
# Posted By Peter Bell | 1/9/09 1:45 PM
i should prob qualify a bit more on the topic, but would prefer to take it offline. if you are interested in the approaches i have been using with mxml specifically i would love to hear your thoughts on the subject. code wise delegation is the better method, but a workflow between dev and designer is also important.
# Posted By johannes | 1/10/09 6:30 AM
Taken offline :-)
# Posted By Peter Bell | 1/12/09 3:25 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.005.