Do you use MDA/MDD/MDSD, any kind of model-driven approach? Will it be the future?

Question

Programming languages had several (r)evolutionary steps in their history. Some people argue that model-driven approaches will be The Next Big Thing. There are tools like openArchitectureWare, AndroMDA, Sculptor/Fornax Platform etc. that promise incredible productivity boosts. However, I made the experience that it is either rather easy in the beginning to get started but as well to get stuck at some point when you try something that was unanticipated or pretty hard to find enough information that tells you how to start your project because there may be a lot of things to consider.

I think an important insight to get anything out of model-driven something is to understand that the model is not necessarily a set of nice pictures or tree model or UML, but may as well be a textual description (e.g. a state machine, business rules etc.).

What do you think and what does your experience tell you? Is there a future for model-driven development (or whatever you may want to call it)?

Update: There does not seem to be a lot of interest in this topic. Please let me know, if you have any (good or bad) experience with model-driven approaches or why you think it's not interesting at all.

Answer 1

I think perhaps there isn't a definitive answer - hence the lack of "interest" in this question.

But I have personally had mixed experience with MDA. The only time it was good experience was with great tools - I used to use TogetherSoft (I believe they somehow ended up at borland) - they were one of the first to introduce editing which was not "code generation" but actually editing the code/model directly (so you could edit code, or the model, it was all the one thing). They also had refactoring (which was the first time I remember it post smalltalk environments).

Since that time I haven't seen MDA grow any more in popularity, at least in the mainstream, so in terms of popularity it doesn't appear to be the future (so that kind of answers it).

Of course popularity isn't everything, and things to have a tendency to come back, but for the time being I think MDA+tools is viewed by many as "wizard based code generation" tools (regardless of what it really is) so I think it will be some time or perhaps never that it really takes off.

Answer 2

Please let me know, if you have any (good or bad) experience with model-driven approaches or why you think it's not interesting at all.

I think the contributors here are part of the "No Silver Bullet" camp (I am definitely). If MDA worked (equals to "huge savings"), we would know it, that is for sure. The question is: how far "meta" can you go while keeping your system manageable? This was the turning point in UML 2.0 when they introduced a more formal meta-meta-model. So far, I haven't seen a real world usage of the modelisation power of UML 2.0 (but my world is rather limited). Besides, you have only two choices with a model-driven approach: generate code, or having a runtime exploiting your model. The ultimate constraint-free code generator is called "human", whereas the ultimate runtimes where found in the 4GLs (what is the current number nowadays?). Maybe that would explain the lack of enthousiasm.

Answer 3

We, at itemis (www.itemis.com) use model-driven Software Development alot. So far we had really good experiences. Shure it isn't a silver bullet, but it helps improving software quality hence more use for our customers.

Answer 4

One of the problems of MDD is that, since it works on an higher abstraction level, it requires developers that can go up on the abstraction level too. That greatly reduces the universe of developers who can understand and use such methodologies.

Answer 5

I think, it will take time, till the tools get more refined, more people gain experience with MDD. At the moment if you want to get something out of MDD you have to invest quite a lot, so its use remains limited.

Looking at openArchitectureWare for example: While it is quite robust and basic documentation exists, documentation on the inner workings are missing and there are still problems with scalability, that are undocumented - maybe that will get better when Xtext and Xpand get rewritten.

But despise those limitations the generation itself is quite easy with oAW, you can navigate your models like a charm in Xtend and Xpand and by combining several workflows into bigger workflows, you can also do very complex things. If needed you can resort to Java, so you have a very big flexibility in what you can do with your models. Writing your own DSL with Xtext in oAW, too, is quickly done, yet you get your meta-model, a parser and a very nice editor basically for free. Also you can get your models basically from everywhere, e.g. a component that can convert a database into a meta-model and corresponding models can be written without big effort.

So I would say, MDD is still building up, as tools and experience with it increases. It can already used successfully, if you have the necessary expertise and are ready to push it within your company. In the end, I think, it is a very good thing, because a lot of glue code (aka copy paste) can and should be generated. Doing that with MDD is a very nice and structured way of doing this, that facilitates reusability, in my opinion.

Answer 6

Disclaimer: I am a developer of business applications. The following view is certainly shaped by my experiences in trenches of enterprise IT. I am aware, that there are other domains of software development. Especially in industrial and/or embedded systems development the world might look different.

I think MDSD is still too much tied to code generation.

Code generation is only useful, when your code contains a lot of noise and/or is very repetitive. In other words, when your code can not mainly focus on the essential complexity, but is polluted with accidental complexity.

In my opinion the trend in current platforms and frameworks is exactly to remove accidental complexity and letting the application code focus on essential complexity.

So these new platforms/frameworks take a lot of the wind out of the sails of the MDSD movement.

DSLs (textual ones) are another trend that tries to enable the sole focus on essential complexity. While DSLs can be used as source for code generation, they are not primarily tied to code generation. DSLs (especially internal DSLs) basically let it open to be interpreted/executed at runtime. [runtime code generation is somewhere in between].

So even if DSLs are often mentioned together with MDSD, I think they are really an alternative to MDSD. And given the current hype, they also take the momentum out of the MDSD movement.

If you have reached the goal of ultimately removing accidental complexity out of your code (I know this is fictitious), then you have arrived at a textual model of your business problem. This cannot be further simplified!

Nice boxes and diagrams do not offer another simplification or elevation of the abstraction level! They may be good for visualization, but even that is questionable. A picture is not always the best representation to grasp complexity!

Further more, the current state of the tooling involved in MDSD adds another level of accidental complexity (think: synchronization, diffing/merging, refactoring ...) which basically nullifies the ultimate goal of simplification!

Look at the following ActiveRecord model, as an illustration of my theory:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

I dont think that this can be any more simplified. Also any graphical representation with boxes and lines would be no simplification, and would not offer any more convenience (think about layouting, refactoring, searching, diffing ...).

Answer 7

Model Driven development has been around for a very long time.

The most succesfull of the early attempts was James Martins Integrated Engineering Facility" which is still around and marketed by CA under the seriously uncool "Coolgen" brand name.

So why didnt it take over the world if it was so good?

Well these tools are good at making the simple stuff simpler, but, they dont make the hard stuff any easier, and in many cases make the hard stuff harder!

You can spend hours trying to persuade a graphic 4GL modeling language to "do the right thing" when you know that coding the right thing in Java/C/SQL or whatever would be trivial.

Answer 8

Model Driven Development will be the future if and only if the models that it uses can be as flexible as writing the code that it's supposed to be generating. I think the reason why it's not doing so well right now is that you it's difficult to do the same "round-tripping" that text-based programming languages have been doing for decades.

With text-based programming languages, changing the model is as simple as changing a few lines of code. With a graphical programming language (aka an MDD-diagram like UML), you have to find a way to translate that model all the way back down to its text-based equivalent (which was already expressively efficient in the first place) and it can be very, very messy.

IMHO, the only way MDD can ever be useful if it's built from the ground up to be as expressive and as flexible as its text-based counterpart. Attempting to use existing top-down graphical design languages (such as UML) for tools that are inherently built from the bottom-up using layered abstractions (such as programming languages) poses a huge impedance mismatch. I can't quite put my finger on it, but there's still something missing in MDD that would make it as useful as people would claim it to be...

Answer 9

This is a very late reply, but I am currently searching for MDD tools to replace Rose RT, which is unfortunately being supplanted by Rhapsody. We are in the real-time, embedded and distributed C++ space and we get a LOT out of MDD. We are trying to move on to a better tool and get more widespread use of the tool in our very large company. It is an uphill battle because of some of the fine reasons mentioned here.

I think of MDD as just one level above the compiler, just as the compiler is above assembly. I want a tool that lets me, as the architect, develop the application framework, and extensively edit the code generation (scripts) to use that framework and whatever middleware we are using for message passing. I want the developers making complete UML classes and state diagrams that include all the code needed to generate the application and/or library.

It is true that you can do anything with code, but I would roughly summarize the benefits of MDD as this:

1. A few people make the application framework, middleware adapters and glue that to the MDD tool. They build the "house".
2. Other people create complete classes, diagrams, and state machine transition code. This lets them focus on the application in stead fo the "house".
3. Its easy to see when peopel have wierd design since the diagram is the code. We don't have all expert developers and its nice to bring junior people up this way.
4. Mostly its the nasty state machine code that can happen in something like a mobile robotics project. I want people making state diagrams that I can understand, criticize and work on them with.
5. You can also have nice refactoring like dragging operation and attributes up inheritence chains or to other classes, etc. I like that better than digging in files.

Even as I type this I realize that you can do everything in code. I like a thin tool jsut on top of the code to enforce uniformity, document the design, and allow a bit easier refactoring.

The main problem I encounter that I don't have a good answer for is that there is no standard set of functionality and file format for such models. People worry about the vendor going away and then being stuck. (We bascially had that happen with Rose RT.) You don't have that with source code. However, you would have the latest version of the tool and the course code that you generated last :). I'm willing to bet that the benefit outweighs the risk.

I have yet to find the tool like this, but I am trying to get a few vendors to listen to me and maybe accept money to make this happen.