Rants, Strikes, Planes and Wheels

It seems OOPSLA has its way in causing many to rant about reinventing wheels, not buying the latest book, airlines, stupid business decisions, blatant tool marketing and what have you. I suppose it's the "lovely" autumn weather and returning darkness that triggers our emotional outbursts.

The good side of it all: the DSM Workshop (6th time) at OOPSLA keeps on growing in size, a clear indicator that we're making progress in our market creation activities. Also the media are now clearly picking-up on the issue on a larger scale, so are the analysts..... so are businesses, and good for it!

With the new MetaEdit+ on its way to being officially released soon, MetaCase is making it significantly easier and definitely more convenient for businesses of any size to start developing software more effectively (faster, less complex, better quality, less cost, less testing, less development time) than with all-purpose UML.

Despite the ugly weather and everybody's rants, I am delighted to see this happening.

MDD & Product Lines Conference review

Markus Völter, one of Germany's most respected consultants in the area of software engineering and software technology, also founder of Software Engineering Radio posted some comments about the recently held Model-Driven Development and Product Lines Conference in Leipzig, that I blogged about earlier.

He comments about using MetaEdit+ being a great tool for building modeling languages and his wish to use MetaEdit+ as a front-end to Open Architecture Ware (oAW) generators. This is something that one of our contacts is actually working on right now, his comments were that "currently the process of assembling a working and useful editor with GMF is quite painful and time consuming. It's just not feasible for larger models." and that “Modeling with MetaEdit+ was indeed quite convenient and a lot easier to accomplish than trying to achieve the same results with Eclipse GMF.”

MetaEdit+ already provides the ability to plug oAW into it, via the model and meta-model import/export facility in XML format, which oAW accepts. Alternatively, there is also the SOAP/Web Services-based API that MetaEdit+ provides. There should thus be nothing stopping Markus from using MetaEdit+ more intensively :)

DSM @ DevWeek 2007 in the UK

Juha-Pekka has been invited to speak about defining domain-specific modeling languages and generators at DevWeek 2007, the UK's biggest conference for developers. On Thursday, March 1, JP will "demystify DSM, open the lid on OMG's MDA and shine a light on Microsoft's Software Factories".

Besides showing why UML-based MDA is generally a bad idea (do notice that not a single session in the whole conference deals with UML-based MDA anymore....hmmm maybe JP should just leave the lid where it is and focus on stuff that works), he will discuss the steps developers can take toward defining their own modeling languages - those that suit the work to be done better and therefore making them more effective - and generators, making sure that whatever it is the generator spits out, is what they want it to spit out.

From a guy with over 15 years of experience in this field, you can expect the session to be enlightning, well worth a visit.

The problem with language templates

When the idea behind DSM and MetaEdit+ has just settled in the minds of many people I talk to - these usually include developers, their bosses, magazine editors and analysts - I regularly get the question about language and generator templates: "Do you offer any ready-made templates?"

Although this would seemingly make adopting DSM faster by offering a "more-ready" solution that users would only need to tweak a little, it actually falls into the "one-size fits all" trap that UML offers. Ready-made templates try to do what ready-made templates try to do: offer one solution to many, which is what DSM tries to avoid for productivity reasons. A solution that needs to work for many, even if they are all active in the same horizontal or vertical, has to make compromises in the design of the modeling language and therefore the code generators, which negatively affects the productivity boost that DSM seeks to offer.

What we at MetaCase see, is that there are huge differences between problem domains, even between companies in the same vertical that make the same product. They benefit from DSM just because they can design the modeling language to fit exactly the way they wish to design their products/systems: Not surprisingly, the desing languages they use differ completely from one another in terms of the concepts they use, the rules that apply to them....the abstraction level they work on.
Providing them with a ready-made language template would:

• Get them started on the wrong path: They would not think carefully about their problem domain and attempt to create a language that would fit it. Instead, they would take the ready-template and try to fit it to their problem domain via all kinds of complex adaptations (similar to the UML profiles approach): Let's do it quick and ugly.
• Because of this, limit the possibilities and flexibility to generate the code they need, leading to a need to reverse engineer and round-trip: A road to nowhere...

The problem with language templates is that they exclude the much better solutions that exist for an individual problem domain. Although the idea seems a good one at first thought, once the idea of DSM matures however, providing or using ready-made templates seems a lot less attractive.

DSL: How to start creating your own language

This is becoming a more important issue for many, since modeling with DSL's or DSM languages is clearly picking up steam. Some stuff has been written about it but I feel it's definitely something that deserves more focus since it is such an important aspect of DSM. Sure, many experts, evangelists and even MDA-guru's speak about meta-models and, if you're living life on the OMG matrass, the good and bad of MOF. This is mostly the "WHY". I've seen only few give advise on the "HOW".

It seems that once you get into a serious session of DSM language creation, the tendency is to push it as far as you can....which often is the wrong thing to do: You're re-inventing UML.

Some time ago, Juha-Pekka wrote a great article on DSM language definition (for Software Factory aficionado's and Gareth J: This is the more correct acronym for a graphical DSL) and he's got another one coming soon in Methods and Tools.

Business before Pleasure

With Model-based development based on domain-specific modeling languages getting more interest from businesses, I have noticed several times now that teams blindly decide to build their own DSM tool using freely available frameworks, like the one offered by Eclipse, only to realize a few weeks (or months) later that the effort this requires is more than they initially hoped for.

There are many facets involved with building your own MDD tool like providing the ability to define your own modeling languages and generators, defining and associating the visual representation to the defined language, defining tool behavior, providing the means to immediatley test your languages and generators while defining them simultaneously, sharing your languages, generators and models with others, possibly even on hetrogeneous platforms, providing integration with other development tools, supporting different DSM languages at the same time etc. Building your own DSM tool does not end with your first version of it.

It's highly unlikely for one that developers will get their first DSM language right the first time, or that this will be a good DSM language. Furthermore, it is very likely that even a good DSM language will need to change over time, which will have its effects on the models that have been created with it. Normally, defining a DSM mechanism requires developers to concentrate on both language definition and generator definition simultaneously. If those developers also need to concentrate on making sure there is reliable tool support for their continuously changing definitions, the effort becomes very complex, very time consuming and very costly.

In order to make DSM a success, developers need to put the goals of business before the pleasure and challenge of building their own DSM tool from scratch....which is what it comes down to, really, when using free frameworks.

At MetaCase, our vision is that developers should be allowed to focus on building good DSM languages and generators, where the environment helps them in doing so by making the effort convenient and transparent. Developers should not be bothered with the intricacies of creating tool support for their own languages and generators, a good environment automatically provides the tool support for them. Not just for the "using them" part, but also for the "defining them", "sharing them", "maintaining them" and "integrating them" parts.

You don't want to spend man-years in developing a tool that in the end will make you a lot faster just until it inevitably becomes obvious that you need to make a change to the language, generator or tool...........and you can start all over again. This may be nice for people that like to build stuff, just for the fun of building stuff, it completely offsets the benefits the DSM approach has for the business goals.

Thankfully, some people have realized this in time, before having wasted precious time on building from scratch:

“Modeling with MetaEdit+ was indeed quite convenient and a lot easier to accomplish than trying to achieve the same results with Eclipse GMF,”
Ulf Hesselbarth, SIEMENS Communications.

"MetaEdit+ provides convenient tool support for domain (meta-)modeling as well as for the definition of concrete instance data, which is simplified by a domain-specific graphical user interface. Easy to learn — easy to use!"
Cord Giese, Research Analyst, Delta Software Technology.

"MetaEdit+ is the most sophisticated DSM tool,"
Scott Ambler, Ambysoft

"Even as a beginner with MetaEdit+, I could define a domain-specific activity language in about six hours - design, testing and one failed trial included,"
Laurent Safa from Matsushita Electric Works, Ltd., Japan.

"MetaEdit+ was the most flexible tool, allowed us to define our own design syntax quickly, and make fast experiments while developing the method,"
David Narraway from Nokia.

Struggling with Microsoft's wording

GarethJ is wondering if MS's "DSL" tools might make people think MS is targeting textual languages. Remarkable.....especially when knowing that DSL's have for decades been textual languages. It remains a mystery to me why MS have not opted for the more correct "DSM languages", with the "M" representing Modeling. I suppose some marketing buff up in Redmond decided "DSL" to "sound" better and of course......it would save some ink.