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.

Doug Schmidt on DSM

Software Engineering Radio recently interviewed Doug Schmidt, a professor of computing at Vanderbilt University. The interview became interesting for me from minute 33:30 onwards, where Doug explains DSM, as he also did in his article on Model-Driven Engineering last year.

Doug clearly is an expert in this area and I enjoyed hearing how much his thoughts are similar to the ones I have about Model-Driven Development.

What my experiences with the media and many developers on conferences are, is that further introductions of the idea however, are no longer really necessary. I do not think anyone is anxiously awaiting another book or another article that introduces Domain-Specific Modeling or modeling with DSLs. Instead, we need the minds, expertise and experience of people like the Schmidts, Tolvanens, Kelly's, Dimitrievs, Greenfields, Cooks, Fowlers and so on to focus on:

HOW

Mainly:
How do I best create a DSM language?
How do I make sure I can easily update it later?

But definitely as important are:
How does the DSM tool best support updating the language?
How does it best update and distribute changes?
How does it best integrate generators with metamodels?
How do we best exchange metamodels?

Juha-Pekka has made a significant contribution here in his recent articles on DevX and he will no doubt touch the subjects during his classes on Architecture and Design World. Many of his ideas are naturally part of MetaEdit+ of which the 4.5 version is scheduled for later this year.

MS NS-DSL

Just listened to the ArCAST 7 podcast with Steven, Martin Danner and Jack Greenfield. It sure is worth taking the first 12 minutes or so to listen to, before a bit of a sour Jack Greenfield comes in to start spoiling all the fun with awkward comparisons between monocycles and Ferrari's, axes and scalpels, wine and vinegar (that last one is kind of a meta one, describing the actual podcast). Possibly, the repetative slips in the DSL tool release schedule made Jack a bit edgy...

I do think I get his point though and again it comes down to the focus area of MS, which - all things considered - really is not so domain-specific: Enterprise applications (presumably based purely on dotNet). No wonder Jack does not believe in fully generating applications from models, something that - by the way - is being done already for over 12 years! Key to achieve it is to make the modeling language very domain-specific: I am talking company-specific-product-line-specific-kind-of-specific here: You need to be able to specify products completely and accurately with it. When you realize that some info is repetitive you can either encapsulate that in the generator or the framework code. Now then, if all the needed info is the models, then why Jack, would you not be able to generate the full application from them??

Jack further disagrees with Martin's claim that UML is an OO-specific modeling language (read: DSM focused on OO software development) and coins the term "General Purpose Language" that he suggests in "The Book" (He NEVER misses an opportunity to mention "The Book", you have got to give him that...). Come on Jack, can't you see that the example Martin provides is a rather excellent way for people to get the idea of "Domain-Specific"? Besides, may I suggest that the term you coin in "The Book" is not completely correct? Since we are busy anyway of making sure we do things entirely correct, a better description would be "General Purpose Modeling Language".

Then again, would you call a DSL to describe "web services" - an example I have seen in one of your slides at OOP - a DSL? I'd say it also qualifies as a rather general purpose modeling language or a Not-So-Domain-Specific-Language, a NS-DSL.

My take on the thing is that Jack seems to be missing the point and has recently started to focus on details in comparisons that no one really cares about. Before long people will get tired of hearing exactly how, where, when, why, what for, where not, and from what viewpoint SF differs from MDA and exactly how DSM differs from both SF and MDA, whether we should call DSM languages DSLs or Not-So-DSL or Not So General Purpose or whether we should call MDD MDA or SF or MDSD or DSM....yawn...as Markus Völter said on the recent OOP "Dass ist doch Alles Quatsch" and I fully agree with him.

Point is that we wish to use modeling to raise abstraction, make software development less complex, make it faster, make it more convenient more accurate and more reliable. MDA seems to miss a number of these goals, SF is still shrouded in mystery to many and DSM is clear on this: It achieves them all.

Factory Factory Factory Factory

I noted in GarethJ's weblog that Microsoft uses its own DSL tool for making its own DSL tool. This is an interesting approach as no doubt will it allow them to renew or vary its DSL tool REALLY REALLY fast.

At MetaCase with MetaEdit+, as Steve noted in his interview with Codegeneration.net: "DSM is useful when you are building a range of similar products. We have just the one, so it makes no sense for us in general." I wonder therefore why Microsoft has taken the Factory Factory Factory Factory approach in making its own Factory.

You can only make a Factory Factory if you know enough about the types of Factory the Factory will be ehr...factoring. This makes me think of the direction Redmond is going with their Software Factory: Enterprise Applications, an area I personally do not see all that well suitable for a domain-specific modeling language-based approach (whether you call it Software Factories or DSM), since the variation space is so wide. Hence it is no wonder that Microsoft does not expect their tool will generate 100% of the code. In order to make it work you need to narrow down the domain in some way and this is tricky when it comes to enterprise apps. You could think of a platform like hmmmmmmm .NET or a subdomain of it, but it means at the same time you restrict yourself to just that.

Would the rumor I heard about the Microsoft DSL tool license agreement be true?

Defining DSLs, Best Practices

Juha-Pekka is writing a series of articles on domain-specific modeling for DevX.com. With 15(!) years of experience in this area I suppose he definitely is an authority when it comes to DSLs, more correctly referred to as DSM languages. His second in the series deals with defining DSLs. Over the years involving many workshops, pilot projects and close co-operation with customers he has identified a number of best practices for teams in order to come to good DSM languages, as not every DSL is neccesarily a good one!

Defining DSLs based on RUP

Evgeny Rahman and Jarrod Bellmore from the Worcester Polytechnic Institute have investigated a method for defining DSLs based on the Rational Unified Process. Hats off for their thesis work. While I will not argue the suitability of RUP for defining DSL's (I can imagine a whole future battle between DSL-RUP aficionado's contra Agile DSL guerilla's), I do have much respect for the topic choice they decided on for their thesis work. Defining DSL's certainly will be a key issue. Now that the technology is there and more vendors announcing support for DSM, the next obstacle that those wanting to adopt DSM will be faced with, will be "Ehrrrrrr.....so how do we actually define our own modeling language"?

Next-generation DSM tools may even offer support for various DSL definition processes, including the creation of all documentation for decision making processes during the DSL definition and maintenance. Remember that like developers today, language designers will change jobs in the future and for those that replace them good documentation about the choices made by their predecessors about the DSLs in use and their evolution over time, will help in making future decisions on where to go with the languages in use.

You already speak DSL!

Often a first reaction of prospects - when confronted with domain-specific modeling - is: "So we have to define and learn a whole new language?".

Actually, this is not correct.

I dare say that virtually every developer already speaks DSL! When discussing about the problem domain of the software under development, each development team has their own jargon in which they speak about the software or system. No one speaks about the software in Java, C or, mind you, in Cobol or Assembler. Developers all speak about their software in a language that uses terms and rules from the problem domain he or she works in. Usually, the expert developer speaks that language best and DSM gives him (or her) the means to make each "less fluent" developer "speak" that language fluently.

The idea of course: Give the expert a tool to efficiently create modeling tool support for his/her DSM language and provide this language to the rest of the developers.

Unlike with UML, with DSM developers do not have to learn a new language, that, all things considered, is never really optimal to "discuss" about the software. Instead, with DSM the expert provides them with the language they already know so that "discussing" about the software in your verbal DSL comes closer to developing the software in your visual DSL.