MDSD Today 2008 Recap
From October 15 to October 17, MDSD Today 2008 took place at the Nordakademie in Elmshorn near Hamburg, Germany. The conference, which had been organized by Frank Zimmermann (Nordakademie), Simon Zambrovski and yours truly, was intended to bring together practioners, researchers and people from both industry and business.
We were fortunate enough to aquire a number of well-known speakers, most notably Axel Uhl (SAP) and Ed Merks (of EMF fame).
On the first day, Axel and Ed delivered their excellent keynotes on the current state of affairs in modeling.
Ed commented on a number of misconceptions he has been confronted with during the last few years such as "modeling is too complicated", "modeling will just get into my way" or "modeling will limit my creativity". The bottom line of his talk was that although you might not realize it, models drive most software (just think of all the data models you're dealing with in business applications). However, using source code as a representation for your models might not always be the best solution - to gain both a better overview of your software and be more efficient with respect to software development, you should think about raising the level of abstraction, e.g. by using domain specific modeling tools that let you focus on the structure of your model instead of having to deal with (basically irrelevant) syntactical details of the target language. If working at a higher level of abstraction makes things more complicated for you, you're doing something wrong.
Axel picked up this idea in his keynote on "Current Challenges for Industrial Software Development Tools and Languages" stating that any computer program can be conceived as a model. Since models are independent of their visual representation, they can be represented in various different forms, the most common being text, trees and diagrams of any kind. The question, however, whether to choose text or the abstract model as the primary artifact for storing. A textual representation clearly has advantages with respect to diffing and merging and can be handled with commonly used tools such as CVS nd plain text editors. Using the abstract model as the primary artifact allows for overlapping partial views. Since this model can persisted in some kind of repository, access to the model very much feels like working with a database. In particular, there's no need to parse any text back and forth between the model and an editor. The decision whether to store models as text or in a repository largely depends on boundary decisions, like the availability of the repository technology, the robustness of the mapping between the textual representation and the model, language characteristics, the number of developers who need to work on the model in parallel, the size of the software system built with the model and the life cycle of the software. Axel concluded that on one hand, modeling is not that much different from coding and that, on the other hand, DSLs are becoming increasingly important due to the complexity of UML.
One of the nice thing about conferences is you get to talk to people who are interested in the same topics as you are. MDSD Today has been no different - during the breaks you could see people involved in all kinds of discussions.
Later that day, Stefan Reichert and Birger Garbe of Lufthansa Systems shared their experiences regarding model driven software projects with us. The topic of their talk was "Model Driven Software Development in Business Projects: Chance or Risk?" Their anwser to this question was that if've got the right tools, MDSD is a chance and can help you to build better software.
Thomas Stahl of b+m concluded the day with his talk on how MDSD, BMP and SOA fit together:
The second and third day of the conference were crammed with hands-on tutorials on MDSD tools like EMF, Xtext, Xpand and GMF. Quite a lot of people attended the tutorials as you can see from the pictures.
Arno had to overcome the hardship of a broken beamer, so he had to use arms and legs to explain:
Overall, the conference was a real success and I am looking forward to seeing you all again at MDSD Today 2009!
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.
