The Software Chef

Recently a colleague asked me if model driven software development (MDSD if you like acronyms) is really faster than traditional development. The question is hard to answer because that really depends on the specific set of tools you use, the abilities of your team and so on. Although development time in one of the key arguements for model driven development, the question might be wrongly put. Other factors like software quality and vertical consistency (accross all layers of the application) outweight the time to market argument in my opinion.

Model driven development is often still seen as gray theory by a lot of people but once you experienced it you never want to go back. A lot of the modern web frameworks like ruby on rails, django, cakephp, grails etc. utilize to some extend code-generation methods borrowed from model driven development. Those frameworks are making these techniques more popular and familiar with developers. Stil, those frameworks focus on providing aid for the mundane tasks like generating O/R mappers and scaffolding user interfaces but are not as extensive as a well-tailored model driven development process which goes far beyond just generating certain artefacts.

When doing MDSD you basically have few choices
A) Buy-In: Buy either one of the so called 4GL development environments from another vendor, or buy one toolset of the several CASE-Tool developers (eventually OMG MDA compliant)
B) Roll-your-own: Define your own DSL (domain specific language) for the problem domain and either complety roll your own toolchain (model editor, code generators, validators, …) or use one of the mature open source frameworks like openArchitectureWare or AndroMDA and build on those

Approach A: Buy-In

Pros

• Development time is indeed lower than traditional development if the metamodel fits your problem domain
• You can buy trainings
• You benefit from the experience of the vendor that is put in the toolchain

Cons

• Vendor lock-in: The lack of standards for templating languages ties you to the vendor. Changing gets expensive and if the vendor goes out of business you are in trouble. Even basic things like the XMI format for UML diagrams is not 100% interoperable
• Steep learning curve: The developers are required to learn yet another set of technologies.

Approach B: Roll-your-own

Pros

• Very flexible: You can design the development process excactly as you see fit
• The quality of the open source frameworks is high, no vendor lock-in
• You can evolve your meta-model or your DSL perpetually during the project. All team members get familiar with the new language and concepts

Cons

• Slower: you have to develop the developer tool chain as well

General Properties

Pros

• Overal vertical consistency if done right: Constraints are enforced in every tier, fields are named consistently, the user interface doen’t have local quirks. Developers can only to a certain degree deviate from the coding standards.
• It lessens the burden of mudane tasks like writing yet another xml file to configure a object relational mapping or a deployment descriptor.
• A bug that is introduced by a code generation step can easily removed from all parts of the application.
• Adding aspects to parts of applications is very easy and just require the code generation or your (meta-)model to be changed.
• Higher level of abstraction: Developing on this conceptual level is a lot easier as soon as the team got used to it.

Cons

• MDSD is only applicable if the project is large enough
• The project must have enough internal recurring structures.
• Higher level of abstraction: Developing on this conceptual level is very different to traditional development. Not every developer feels comfortable with it and during the first MDSD project it requires re-thinking of habits.
• Debugging modelling errors is a pain: You have to debug the problem in the actual code and follow all the way up to the actual problem (model or code generator), fix it there, re-generate the code, test, debug and eventually start over again.

Textual DSLs vs. UML / Graphical DSLs

Developers are used to working with text files and prefer textual DSLs. Textual DSLs can noadays easily be created using for example the XText project from the openArchitectureWare framework. Business Users are used to graphical languages and prefer those. To satisfy both ends it might be worthwile to have a graphical as well as a textual representation of the model that is fully synchronized.

Open Problems

• (Semantic) versioning can be tough. Manually merging XMI files is no fun, textual DSLs in most cases lack semantic versioning information. I do not refer to storing a textual DSL in a version control system but rather storing model changes as part of the model that can be utilized for let’s say generating database migration scripts or versioning external (web-)services.
• Collaborative editing is only evailable in enterprise versions of UML tools
• Proprietary template languages for code generation
• Debugging generic problems is slower than just fixing a bug in-situ. I haven’t yet seen any good tools that support debugging of the actual model.

Conclusion

Model driven development is only faster if applied to a family of software applications. In most cases the first application developed with the new methodology will have a longer time-to-market but developing is a lot more rewarding in terms of quality, consistency and general developer happyness. If done right additional advantages like semantic versioning arise.