What do you think of Model-driven Software Development? [closed]

Question

I'm really interested to hear what you think about Model-driven Software Development for Java and/or .NET.

Does it save time? Does it improve quality?

Answer 1

I am using MDSD in a project with IBM Rational Rhapsody for C++. The model is pretty close to UML, so there we do not really have a Domain-Specific-Language. But still I would claim to use MDSD. From my experience, there are many benefits with MDSD:

a) Using MDSD helps to bring a SW architecture to a sophisticated level. You always work on a very abstract level, thinking about the big picture. Cowboy coding software usually lacks a good architecture, because a developer is stuck in details. With MDSD, I see a tendency in my work, to solve problems with adequate sized classes, nice patterns, or simply better code.

b) Big picture documentation of the SW tends to be better with MDSD. Of course, there are tools that automatically generate a class diagram out of your code. But these diagrams consists of 1000 classes and you do not see the aspect of interest. With MDSD, you specifically draw one aspect of the system, and the very same diagram is also used to generate a part of your code.

c) Modelling helps to deal with an inherent system complexity. I would say, some systems are just too complex to be built without support from computer-aided design. Nobody would design a CPU without the help of huge SW tools. Use SW to help you write even more complex SW.

d) Using MDSD helps to adhere to coding style guidelines. There is no better way to get coherent code style than letting the code be generated by a rule set.

There are of course also some downsides of MDSD: d) If you have a model, you want every line of code to come from that model. And it may be difficult to include external libraries to a project. So either you live with the fact, that your system is based on external components or you reinvent the wheel to get it into your model.

e) Modelling tools might suffer from problems using versioning tools. Source code is usually simpler to merge than a model diagram. This forces a team to move from the copy-edit-merge to a lock-edit-merge workflow.

Answer 2

MDA is a bit of an overloaded concept. Sometimes it means turning UML or another type of diagrams in to executable code. I've never seen this work out well with the tools available nowadays. It usually causes projects to get results really fast and then cause a maintanance nightmare because the tools available don't really support big teams working on visual diagrams and because people start working in the diagrams as well as the generated code.

I've seen something that looked a lot like domain driven design being referred to as MDA, if you mean that I'm all for it :-)