Microsoft excited about modeling

Microsoft seem to be quite excited about modeling these days. Just recently, they announced that they have joined the OMG. OMG does NOT stand for Old Modeling Guys, but for Object Management Group. This is the standards body that brought you specifications like CORBA, UML, MDA and BPMN, to name just a few.

But Microsoft does not just talk about modeling, they also put their money where their mouth is: during the last few years, a number of people including Steve Cook and Stuart Kent have been working on a toolchain which first has seen the light of day under the somewhat cryptic name VSX DSL Tools.

VSXDSL Tools are really good at rapidly creating (simple) graphical modeling tools. However, when it came to model transformations and code generation, you were stuck with a somewhat dated technology called T4 (Text Templating Transformation Toolkit) - a template language quite similar to JSP and ASP. T4 seriously lacks some important features, like polymorphic dispatch, support for multiple file output and - believe it or not - a decent editor. Well, you can get one from http://www.t4editor.net/, but who likes to shell out 99 dollars for just an editor?

Now, Microsoft seem to have listened to their users and are coming up with an updated and extended version of the DSL Tools, code-named Oslo.

So what is Oslo? Douglas Purdy states that Oslo is:

• A tool that helps people define and interact with models in a rich and visual manner
• A language that helps people create and use textual domain-specific languages and data models
• A relational repository that makes models available to both tools and platform components Looks to me like they are addressing all the issues MS DSL tools had.

At PDC 2008, the team will reveal Oslo and all its nice features.

Although I am an Eclipse fan and an openArchitectureWare committer, I am quite thrilled so see Microsoft make this move to embrace modeling. In my opinion, this will advance MDSD and DSLs quite a deal. A lot of people who may have never heard of DSLs and MDSD will now get in touch with those techniques due to the sheer marketing power of Microsoft. This will also bring some nice competition to the market, which always is a Good Thing (tm).

The press release states that "to make model-driven development a reality, Microsoft is focused on providing a model-driven platform and visual modeling tools [...]" - So, welcome to the modeling world, Microsoft!

Some thoughts on the merits of model driven software development

Scanning my RSS feeds today, I came across this post by Magnus Jungsbluth in which he deals with the question "Is Model Driven Development Faster?". As Magnus points out, the question whether you can be faster by using model driven development points in a wrong direction. Just being faster is not a major goal of model driven development. It's the quality that counts. Model driven development helps you to concentrate on the relevant parts of your software (i.e. the business logic) instead of having to care too much about the architectural plumbing around the business logic. Yes, using a code generator saves you some time. Precious time you will be able to invest into other parts of the software you build. This will amount to a higher quality of your software. Magnus mentions some more prejudices people have towards model driven software development. Here are a few:

"Higher level of abstraction = more complicated"

Now, this is plain wrong. Model driven approaches do not aim at making things more complicated. They aim at making things simpler and easier to achieve. This is what we mean by "raising the level of abstraction". I guess it's the word "abstract" which makes most people think things become more complicated. Wikipedia states that "Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." This definition makes clear that abstraction helps to simplify things in order to concentrate on only the relevant parts.

Consider a subway map: it is an abstraction of a geographical map, leaving out all the superfluous information, just retaining what is needed to find your way in the underground. The subway map is a domain specific map, explicitly aimed at a special purpose. If you need to find your way by car, you'd need a different kind of map.

Abstraction in the context of model driven software development means to leave out the superfluous details and concentrate on the relevant parts. Let me give you an example: If you are writing  a software for your HR department, you really shouldn't need to care about writing getters and setters and how exactly to write that m:n relationship mapping in hibernate. Instead, you should concentrate on the names and types of the attributes and the fact that a certain relationship indeed is an m:n relationship.

"MDSD / DSLs enable business users to write software"

... do business users (i.e. the people who are going to be using your software) want to write software on their own at all? I don't think so. Modern business live is organized by division of labour, which is a good thing because it allows us to do the things we're good at and specialize ourselves.

Although I don't think business users should programm their own software using MDSD or DSLs, I believe that using MDSD and DSLs will help to bridge the gap between developers and business users. Much is gained if a developer and a business user can look at a graphical or textual model and discuss the business requirements in  language both understand. It is the task of software architects to ensure that the models being used can be written in this very domain specific language.

Oh, and please resist the temptation to provide a graphical language that tries to mirror a textual DSL one-to-one. Graphical syntaxes and textual syntaxes are very different. Things that can very easily be expressed in a graphical language  might look very awkward when mapped to a textual language and vice versa. Don't get me wrong - there's nothing evil about using different concrete syntaxes to provide views on one common / shared model. However, graphical languages are better suited to provide an overview of a system or module, whereas textual languages are better suited to flesh out the details.

"Versioning is tough, DSLs do not support versioning"

While it certainly is true that traditional UML tools are not that well suited for collaborative work (much due to the fact that most tools store their models either in a proprietary format or in monster XMI files), this is not true for external textual DSLs.

When using a textual external DSL, your model is plain text. Thus, your models can now be very easily stored in a version control system such as Subversion or CVS. And of course they can be diffed and merged. Using textual DSLs feels very "natural" to programmers after all.

Conclusion

So, to sum up: model driven development is neither some kind of obscure art which takes you years to learn and understand. Nor does it make things more complicated. It aims at aking your life easier. It does not neccesarily save you time, but it will help you to better use your time to build better software. One of the reasons your software will be better than before is that your business users will be able to discuss with you using a language you both understand.

That's what model driven software development is about.