Microsoft have a new DSL Tools Lab for beginners to learn how to use DSL Tools in one day. Full marks to Jean-Marc Prieur for starting off by explaining that modeling languages should be based on the problem domain, not the solution domain:

[Y]ou want to create a vertical language that is suitable for your business, and from the models that the language manipulates, generate the code for your business Framework. Nevertheless, because it is difficult to ensure that everyone who takes this training knows the professional tasks that are addressed by the targeted business Framework, we will settle for a horizontal (that is, technical) DSL.

The example language is thus a simple state machine (why is it always a state machine?!). The part that interested me is Part 3, Validation and coherence of the model. Let's look first at how to display the label for a transition. A transition specifies an Event that causes it, a guard Condition that must be true for it to be followed, and an Action that is taken when it is followed. All of these are written in the example as C# code snippets (tut tut :->). They want to display them as one single label, formatted as "Event [Condition] / Action".

Here's how to do it in DSL Tools: four pages of dense (8 pt font!) instructions and code, total 242 lines:

And here's how to do it in MetaEdit+: three lines of MERL in the transition symbol's label:

:Event
if :Condition then ' [' :Condition ']' endif
if :Action then ' / ' :Action endif

About 10-15% of the DSL Tools solution is taken up by what I'd say is a really bad idea: storing the calculated label as a property in the transition alongside the Event, Condition and Action -- effectively duplicating that information. This also means they need to be able to parse the syntax of the label if it is edited, to update the other three properties.

Next, let's look at how to ensure there is only one Initial State. First, the DSL Tools way: just into the 4th page of 8pt instructions and code, total 200 lines:

And here's how to do it in MetaEdit+: a simple Occurrence Constraint for Initial State in graphs of type State Diagram:

Initial State may occur at most 1 time

The lab goes on to mention several other possible constraints and checks, but doesn't show you how to implement them (presumably since the intention is to finish it in one day). Here they are, along with how to implement them in MetaEdit+ -- I just tried, and it took just over a minute to do all five:

• Final States should not have an exit transition

  Normally this would just be in the Binding for Transition, which specifies for each role (end) of the relationship which objects it may connect to: Exit (State | Initial State), Enter (State | Final State).

  Another way would be a connectivity constraint: Final State may be in at most 0 roles of type Exit

• Entry and Exit actions of the States must have non-blank code

  The Value Regex for the code property in the Actions would be .+

  Actually, I think this is an unnecessary requirement: many states have no entry or exit action.

• Names of States must not be blank

  The same Value Regex as above.

• Names of States must be valid C# identifiers

  Change the Value Regex to something like [a-zA-Z_][a-zA-Z0-9_]*

  Again, I think this is a poor requirement: much better is to allow modelers to type whatever seems sensible, and then turn it into a valid identifier when outputting. In MERL you can use translators to do this, e.g. :Name%var. Using %var translates the :Name property's non-identifier characters into underscores; you can create your own similar translators, e.g. "%upper a-z A-Z" translates lowercase characters to uppercase.

• Names of States must be unique in a State Diagram

  A Uniqueness Constraint for State Diagrams: Property "Name" in State must have unique values

  Note that this is per diagram: if you want States to have unique names in the whole repository, you can mark the Name property in State as unique.

Hopefully this gives some idea of how easy it is to add constraints and checks in MetaEdit+. With experience from making hundreds of modeling languages over the last 15 years, we have a pretty good idea of what kinds of constraints you actually need. That allows us to offer you simple ways to define them, without having to resort to hundreds of lines of hand coding for each. And there's no "customization cliff": if you have something we haven't thought of, you can just write it in MERL, or in whatever language you want via the API.

One of the interesting questions about Oslo is its relationship to DSL Tools. Actually, we should say between Oslo and Software Factories (the marketing side), or between M and DSL Tools (the technical side). Technically it seems there is no link -- which means no integration and no upgrade path. On the marketing side, few people seem to have picked up on the fact that Keith Short, co-author of the Software Factories book, moved to work on Oslo nearly two years ago. Steve Cook and Alan Cameron Wills, co- authors of the DSL Tools book, have also left the team, but for UML and MSF respectively.

Of course, people move around, and it's more interesting to hear what people still in those teams say. An Oslo developer writes:

If I look around, I see people doing [declarative, model-driven programming] today in the form of XML schemas and dialects, various textual reps, and frameworks that encode a domain. We went down that path as well, using visual designers and XML. But at some point the pain was too much :) We evolved our approach into Oslo.

Microsoft's "visual designers and XML" presumably refers to DSL Tools, and the comment about the pain being too much is perhaps at least one answer to the question of why Oslo isn't being billed as an evolutionary step along the Software Factories / DSL Tools path. It sounds more like Microsoft have concluded that their DSL Tools are an evolutionary dead end, have taken a step back, and are now heading down a different path. That's the impression I get from Keith Short's blog entry: "both Oslo and the DSL Toolkit have grown from a common belief" in DSLs.

Microsoft are of course claiming both products will continue to be developed, but losing 3 out of 6 main figures from the DSL Tools team is hardly encouraging. Mind you, I think what is needed is even more radical: both Oslo and DSL Tools should be put on hold until Microsoft have figured out what you need for an industrial strength language for describing modeling languages. The resulting languages and tools have to scale to multiple simultaneous users, multiple representational paradigms (graphical, textual, matrix, tabular), multiple platforms (not very likely that one!), integration between multiple modeling languages and multiple models, and evolution through multiple versions of the languages. There are a few more multi's I could add (look at slide 15 from my keynote to the OOPSLA DSM Workshop), but you get the picture. And if you want more than just the picture, get the tool!

I've been invited to speak at a couple of events in Cambridge, UK, on 20th November. You can see the full details and register at the event links below, but here's a quick overview.

The first talk is to the Cambridge Wireless Software SIG, in an event on Tackling Diversity in the mobile space. If you're in the area and in the mobile space, the event could well be a good way to use an afternoon: other speakers are Qualcomm's John Scott and Pure-Systems' Danilo Beuche. Here's the blurb for my talk:

15:40 “De-clawing Diversity with Domain-Specific Modeling”

As mobile developers you’ve had to make the right decisions about new technologies more often than most: rejecting those that are duds, waiting on those that are still more hype than substance, but quick to start using those that really work. It’s no surprise then that the mobile industry has been one of the first to show widespread use of Domain-Specific Modeling: early adopters have consistently seen productivity improve by hundreds of percent. With DSM, applications are specified once at a high level of abstraction, and code generators take care of producing all necessary versions for different handsets, networks etc. Since you own the generators, you can easily adjust for new platforms or their versions: no interminable waiting for tool vendors to release an update. In this talk you will see how DSM works to tackle diversity in the mobile space, and learn how you can join those already using it and reap the same benefits

(I've since found out from our resident expert on the canine world what "de-clawing" actually involves. I was thinking more of a light manicure than the rather debatable surgical procedure, so please forgive the title!)

The second event is part of the new Software East initiative of Mark Dalgarno's Software Acumen. The talks are again by myself and Danilo, but at a more introductory level and applicable to any domain, not just mobile. Even better, it's only £15 and you get food! The event is in the evening, and I'll be talking about Moving from Coding to Model-Driven Development:

Everybody would like the productivity benefits of modelling with full code generation, but the upgrade path from coding to modelling seems a closely guarded secret. This session will demystify Domain-Specific Modelling, open the lid on the OMG’s MDA, and shine a light on Microsoft’s Software Factories. We will show which bits of Model-Driven Development (MDD) work, which might work, and which don’t, and explain where they can be applied and where not. Most importantly, we will show the steps to define your own modelling languages and generators to start using models effectively, road-tested in dozens of projects over a decade.

Overall, it looks like Oslo is primarily just a way to provide configuration information for Microsoft applications. If you want to model and generate Java, or something running on Linux, or a standalone Windows program, or embedded software, it's not for you. If you're building in-house IT applications in the Microsoft stack, it could be useful at some point in the future.

From Aali Alikoski , who ran the DSM workshop at XP with me, knows the DSL Tools well, and is at PDC:

"Oslo" initially seems like a disappointment for me. I continue wondering what is the relationship between it and DSL Tools. It seems that there is no relationship at all, which seems odd since Oslo has many of the same features as DSL Tools (a couple of years later), although in a more limited way in my opinion. It looks from outside like Don Box et al haven't synched their thoughts with Jack Greenfield, which they should have done.

Paraphrased from Martin Fowler , who got a pre-PDC showing of Oslo from Don Box et al., based on further input from Sam Gentile and what I can glean from playing around for an hour with the SDK:

Oslo has three main components:

• a language (M) for textual DSLs, with three sub-languages:
  • MGrammar: defines grammars for Syntax Directed Translation.[think BNF]
  • MSchema: defines schemas for a Semantic Model [think C structs]
  • MGraph: is a textual data format for representing instances of a Semantic Model [think JSON]
• a design surface (Quadrant) for graphical DSLs
• the "Oslo" repository that stores semantic models in a relational database

You could define a semantic model with MSchema. You could then populate it (in an ugly way) with MGraph. A better way to populate it would be to build a decent DSL using MGrammar, and pass the result to the general parser mechanism that Oslo provides, along with some input in that DSL.The parser gives you a syntax tree, but that's often not the same as a semantic model. So usually you'll write code to walk the tree and populate a semantic model defined with MSchema. Once you've done this you can easily take that model and store it in the repository.

For me, that "write code" is the worst part. If Martin's right, that means that there is no good way to just specify your DSL syntax with your schema, and have statements in that DSL saved to the repository. That seems a step back from what I'm used to in other tools like XText or MPS.

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.

There's an interesting discussion on the name DSM in the DSM Forum discussion group (join the DSM Forum group on LinkedIn for free to see it). Stefan Hägglund started it, and his questions and my answers are below:

@Stefan: "I've always viewed DSM as belonging to the problem domain. However, recently I've seen DSM being positioned in the solution domain [too]. What do you guys think?"

DSM is all about raising the level of abstraction higher than the level on which we currently build solutions. We always aim at modeling the problem domain: the more we include solution domain information in the models, the leakier the abstraction becomes. If the modeling language concepts are entirely from the solution domain, it has not raised the level of abstraction.

Some people like to build DSM languages starting from a solution framework and abstracting upwards. I find that's often less successful than starting from the problem domain and working downwards, but it is still possible to arrive at a decent problem domain modeling language.

@Stefan: "[If we take] the acronym purely from a semantic perspective, DSM means Domain Specific Modeling, period. If we wanted it to be specifically Problem Domain Specific Modeling, why didn't we call it PSM?"

I think I can speak to that, since I'm one of the guilty parties behind the name. First some background in terms of semantics: no word contains its meaning. That's a fundamental, and should be clear: there's nothing in the sound "cat" that is particularly cat-like. (Since onomatopoeia is unlikely for DSM, let's skip that exception!). We should of course strive in a name for something that uses existing concepts to help get the point across, but it has to be short enough to be used: the name can't be the full explanation.

Why DSM then? Back when we were looking for a name, we looked at existing names and fields. Our own background was in CASE, in particular metaCASE, but that term was only familiar in Europe, and "CASE" worldwide had bad connotations from the overly hyped failures of tools around 1990. DSL was clearly similar, but we needed to distinguish what was different: we were talking about graphical modeling languages. Since some of the languages were matrix-based, we preferred "visual" to "graphical", and the first BOF and workshops at OOPSLA were called "Domain-Specific Visual Languages". That was already a bit of a mouthful, and tended to make people think of "Visual Programming", something else which in most people's minds had been seen to fail. We thus shortened the name to "Domain-Specific Modeling", which also used the widely accepted semantics of the word "modeling" in our community. As shown by all the MD* names, modeling was seen as a key element in moving our field forward. The key differentiator from the other MD* approaches was domain-specificity: the focuses on problem domains, visual languages, code generation, domain frameworks, tooling etc. were important elements, but not as important to DSM as domain specificity, and not as useful in distinguishing it from other approaches.

The term DSM had already been used early on by the GME guys at Vanderbilt, although they had later moved to calling it "model integrated computing". Overall, as a term I think DSM has done OK, although of course something shorter and containing more information would have been better :-). Part of the problem is its very success: remember when O-O was the buzzword, and everything had to be O-O? Back then I remember an advert talking about an "object-oriented user interface", and predicted that DSM will have reached a tipping point when we see the first mention of a "domain-specific user interface" (where D-S is used more for its buzz than its semantics). That happened last year, and Google now has nearly 100 hits for that phrase! When something becomes a buzzword, people want to apply it to their own work even if it doesn't quite fit. There's not much anyone can do about that other than accept it as the price of success: rather that, than that nobody else ever mentions DSM.

However, what we should IMHO try to avoid is accepting those uses of "DSM" as changing its core meaning. If we do that, it becomes devalued and diluted, and most importantly when people apply these other non-DSM approaches, thinking they are DSM, and find no productivity improvements, they will perceive DSM as having failed. To my knowledge, no "pseudo-DSM" has raised productiviy by a factor of 5-10, or even close, whereas for true problem-domain based DSM this is common.

So, I don't want to be the language police here, but if as Stefan says, we have "always viewed DSM as belonging to the problem domain", let's stick to our guns and continue to promote what we know works.

The latest issue of IEEE Software has an interesting article by Simon Helsen (of ArcStyler MDA fame, now with SAP), Arthur Ryman (IBM, Rational Application Developer), and Diomidis Spinellis (Athens University). They look at the history of software development tools over the last 40 years, and bemoan the lack of major progress since the move up from assemblers. Tools have improved, but slowly, and "silver bullets" have often turned out to be filled with hot air.

"Software factory tooling, computer-aided software engineering, and model-driven development tools, to name just a few buzzwords, clearly haven’t lived up to their proponents’ sometimes-inflated promises."

Looks like we're going to get bashed here, doesn't it? But no: while the authors agree with us that some companies have hyped their tools and approaches beyond what they could deliver, they say MetaCase isn't one of them. Here's the first figure from the article, a 40-year history of "exemplary well-known development tools" and their level of abstraction:

Levels of abstraction of well-known software development tools over 40 years -- look who's top!

Even the original version of MetaEdit, from 1993, is ranked higher than Microsoft's Visual Studio 2003 (with their DSL Tools) or Eclipse (with EMF+GMF). Hopefully we've moved on a little since 1993, keeping MetaEdit+ ahead of XMF Mosaic. The graph doesn't show which tools are still around, or how long things lasted: Xactium, the company behind XMF Mosaic, sadly stopped development of it this year. Last I heard they intended to release the source code into the GMT project in Eclipse, to join the several existing prototype modeling tools there. At least so far it's not appeared, although the source code can be found from the web. It would be a shame if the GMT project became the open source equivalent of Computer Associates (who bought up many dead and dying modeling tool companies, but seemed more interested in collecting maintenance fees, leaving the tools to languish with no further development).

The article is not without its faults: it mistakes "text" and "XML" as universally readable formats, as if by having your software described in one of those formats means it will be readable by other tools or later versions. For the record, opening the proprietary, binary format of a Word 97 document in Word 2007 works fine, and the document will be upgraded if desired when saving. Contrast that with opening a Java program from 1997 in a Java IDE today: the program almost certainly won't compile, or will give many errors. The underlying storage format, text or binary, hasn't changed in either case; what changes is the actual syntax, structure or in XML terms the schema. Whether the content can be read and updated to match schema updates depends on the tool, not the underlying storage format.

In many ways, text is worse than binary or XML as the underlying storage format: the latter imply that the storage format is already close to the structure of the program -- its abstract syntax tree. Or to take a more pragmatic view, the work needed to turn the storage format into whatever the development tool natively works with in memory is fastest for binary, somewhat slow for XML, and slowest for text. Of course text has its advantages: you can open it in any editor (at the cost of losing the IDE's power), and the diff algorithms and displays are more mature (but show changes at the character level, not the language concept level -- rename a function in a refactoring IDE and your diff shows hundreds of changes).

I can't resist one last comment on the chart above: look at the development tools that are ahead of the curve, i.e. furthest above the diagonal. Written in Smalltalk, all three of them. If you think Smalltalk = old, go take a look at MetaEdit+, Seaside, or DabbleDB -- or jump straight to the source, Cincom's VisualWorks Smalltalk.

Johan den Haan agreed in his comment with most of my thoughts on Microsoft's odd new DSLs + UML approach, and wrote an interesting article of his own on the topic. I agree with him that there are situations where framework-based DSLs make sense, and that one of the major criteria in such situations is the cost-benefit analysis. Given a choice of no MDD, MDD with your own DSL, and MDD with an existing third party DSL, just look at how much it costs to develop your apps in each case, and how much to develop or buy the DSL and its tooling.

If you decide to create your own DSL, there's normally no question: it should be made for your problem domain, not your solution domain. That gives higher productivity, more flexibility and more future-proofing (you can change solution domain by one person changing the generator, no need to update the models or language).

The possible exception is when, like Johan, you decide you want to sell your DSL as a tool, rather than use it to make your own apps. In that case you need to factor expected selling price against expected market size and the work required to create the solution:

• Expected selling price is largely a measure of the productivity increase. It is thus higher for problem-domain specific DSLs, and increases the more specific the DSL is.
• Expected market size is greater the less specific the DSL is. As many development organizations see themselves as "J2EE developers" rather than "webstore developers", it may be easier to market solution-domain specific DSLs. Similarly if you already have a captive market, as Microsoft does with Visual Studio users, it makes sense to sell solution-domain specific DSLs.
• The work needed to support an extra solution domain is mostly the cost of becoming proficient in the new framework or language. Since we're assuming the solution domain language or framework isn't perfect, and is probably a pain to use (increasing the marketability of the DSL), that's probably quite a large amount of work. Also, developers will judge a DSL by the quality and familiarity of the code it outputs. This means you have to reach a good standard of proficiency in that solution domain, and also offer significant tailorability in the code that will be output, so you can suit a larger number of potential customers.

As you can see, the factors and their weights are very different if you want to sell your DSL rather than use it yourself. When selling, many of the benefits of DSM are reduced: the broader DSL leads to lower productivity for your customers, and the broader solution domain support leads to higher costs for you in terms of learning and generator development. Building a DSL for your own use is a lot easier and cheaper, and gives greater benefits.