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.
Thanks for reading this post. Follow me on twitter here to be notified about updates and other posts I write. Or, subscribe to my RSS feed here
Trackbacks & Pingbacks
Share your thoughts, post a comment.
Additional comments powered by BackType
First of all, thanks for tracking back to my article. I would like to comment on some of the points since I obviously didn’t state them clear enough
. I have been using model driven techniques for several years now and I’m an advocate of using these techniques, so most of my reasonings come from practical usage and are not prejudices.
1) I have not used the word “complicated” at all. The aim is of course to make it easier as a whole. And it is for the end-user of your DSL, if your whole toolchain and your metamodel is matured and almost bug-free. BUT the whole process is a lot more abstract, you have model transformations, several code-generation steps and debugging of those processes. My point was that to actually debug, extend and manage the whole process developers need to work differently. To change a specific part of generated code for example you cannot just change it, but must follow all the way up to where it originates. This requires re-thinking when introducing MDSD at the first time.
2) I also do not believe in the fairy tale that business users will ever be able to “write software” or even should, besides maybe specifiying run-time rules with a specific language. I prefer textual DSLs too, but I am a developer. When working with clients who are used to graphical representations it is often useful to have a partial graphical representation that is synronized and shows a birds-eye view of the whole thing. In my experience you end up using multiple partial models for the same application to descripe the particular details of a part more concretely. Event trying a one:one mapping is pointless as you state.
3) Versioning means a lot more and has a lot more potential than having a copy of you model in your version control repository: As soon as your system is in production you are able to track change on a semantic level since you’re using a model. Not only in a diff between two textual representations of your model. What I refer to is for example the simplest of cases of adding a field to an entity. If your model supports semantic versioning you can do all sorts of things with this information, like generating the database migration scripts, automatically handling changed versions of an external (web-)service interface and so on. I have not seen this yet, but have been using it internally quite successfully.
I can only fully agree with your conclusion and will extend my post on certain spots.
More from authorHi Peter,
the business users will not only discuss – there are some parts of business work where they also USE the (graphical) editors,
in my case these parts are Business Processes and Business Rules:
Business users will enter Processes and Rules, Developers will enrich these models and generate different artifacts and code.
In the long sight, I think MDSD and DSLs will not only bring quality to your software, but also more time.
To start with MDSD / DSLs I know from my own experiences it needs much more time then traditional programming,
but so many times I later changed some decisions (new ideas, new tools, new frameworks, new technology,…) and then
the power of MDSD allows to do this: change some templates and generate
I would never start a new project without using MDSD and DSLs (with all these good products like openArchitectureWare
ekke
More from authorPeter,
Yet another excellent post. I so disagree with Magnus’ conclusion even if speed were the most important consideration. Likely I read too much into the conclusion, which I think is based on the premise that MDSD means “design a DSL and use that” whereas for me it also includes design an Ecore/UML/XML Schema model of your data and use that to help jump start your larger application. Even in the DSL case, the flexibility of a DSL is likely to save time and money in the long term if not immediately in the short term.
More from authorEd,
as Peter points out in the first paragraph, my only conclusion really was that the question if MDSD is faster does not necessarily have a yes / no answer and is not the most important consideration, because there are so many more other benefits on top.
Sure long-term it is faster and if you have everything in place, your next project will be finished in almost no time. Even short-term you might save a lot of time if you have done this kind of development before and know the traps.
And of course, just spitting out a DSL and using only that wouldn’t get you very far, you need to design a alot more.
I’m kind of amused that my post produced so many strong reactions as I just wanted to indicate that time-to-market (most important and quantifyable argument for the management) is not hitting the spot in many cases.
Anyways, nice to have this discussion guys.
(My first comment is still pending)
Hi Magnus,
thanks for taking the time to comment!
When I was writing about prejudices, I didn’t mean to express that these were YOUR prejudices, but instead common misunderstandings of many developers out there. And indeed, you never wrote “complicated”. I derived “complicated” from the following piece in your post: “Higher level of abstraction: Developing on this conceptual level is very different to traditional development.”
My post is not so much a criticism of your post, but rather a contribution to the discussion whether MDSD is a feasible development technology.
(PS: don’t know why I had to approve your presious comments, as I didn’t have to approve Ed’s and Ekke’s, but I do hope your future comments will appear immediately)
More from author