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?

Heliogabalus

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.

Lohse

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 :-)

Island

Well MDA does not equal MDSD. I have seen large-scale codegen work in big projects. But it is its own profession. A codegenerator is software. Manipulating generated code is at the same level as manipulating data in tabels over using the apis in usual software. – Heliogabalus

Answer 3

Buzz.

What I believe in, OTOH, is modeling at runtime. Instead of generating code, keep the model alive at runtime and let your application be a runtime interpreter of these models.

I dont know if this has been done for Java. For Smalltalk see Magritte, which is used in Seaside.

Recipe

I agree, this is very powerful and not seen very much with the most prominent mainstream languages (though there's nothing about the languages that prevent it). – Enrica

If you are not afraid to resort to hashtable objects, and hashtable method lookup, I agree. (However, languages that allow you to recompile classes at runtime make life much easier with regard to that.) – Recipe

I doo that alot, too. But it's really hard for complex models. Debugging generated code is easier than finding a bug in your model by debugging the interpreter. It's all about tools. – Heliogabalus

Answer 4

I think it preferable. That is what I was trying to imply on this question about MVC-ARS rather than MVC. The ARS (Action/Representation/State) is contained within the model by design and prevents the overloading of controller or view.

Pritchard

Answer 5

Model-Driven Software Development isn't just about MDA, there are a set of other approaches including the, perhaps more popular, Domain-Specific Languages approach.

Sure, the code is 'a' model, but capturing a higher-level model in a DSL is an even more concise way of expressing the same intent. The key is to always generate your code from the model rather than allowing independent modification of generated code.

There's plenty of tooling available, and plenty of published material, including case studies, to tell you how to build your own generators if you're not happy buying an off-the-shelf generator. Arguably this gives you more control than working with a general-purpose programming language.

Outweigh

Answer 6

It sure sounds nice but I have yet to see it implemented in a practially working way.

I hold it like this: The Code is the model. That way your model and your code are always up to date :-)

Brennan

In the space of eclipse it is used quite a lot. I've seen it succeed in huge projects. – Heliogabalus

Answer 7

Just to throw in two books I found useful in understanding MDA as stated above it is a broad subject.

• MDA Distilled - Principles of Model-Driven Architecture. (Mellor)
• Real-life MDA: Solving Business Problems with Model Driven Architecture (Guttman)

You don't need to read all of the Guttman to get the idea as the case studies get boring, but the intro was pleasant to read.

Koestler

Answer 8

MDA usually make difficult to integrate the business rules inside the server side layer, as the model view mapping is handled by generated code and functional hooks are provided as event responders.

Still I've not seen a MDA tool as powerful as Forté (or UDS, now dead) + Express were. I imagine that a MDA with the Forté capabilities plus better pattern to achieve an independent service layer (as ActiveRecord, or EntityTransactionManager patterns) would be a killer app for whatever platform.

The problem with actual application aiming at the three tiered MDA approach is that those are terribly difficult to set up and adapt to specific requirements. Just think of ABAP and SAP rates

Joo