The Model Driven Software Network

Raise your level of abstraction

OK, so Ed says that controversy is "interesting" and Vlad says "I think that the MDA, model driven etc... market is currently dying."


Views: 365

Reply to This

Replies to This Discussion

We shouldn't confuse the market with the technology. Open source is a disruptive force and was intended to be a disruptive force. After all, why would a corporation invest billions of dollars in Linux with no hope of ever seeing a return on that investment? It seems clearly an effort to commoditize the operating system market. Certainly hundreds of millions of dollars invested in Eclipse was initially intended as a way to ensure Java's strong position as a development platform, but it was also intended to commoditize and disrupt the IDE market. Both these open source efforts have worked wonderfully well. Many will argue they've worked too well. There have certainly been unforeseen consequences.

In my opinion, MDA promised too much and delivered too little too late. This has left a bad impression. So much of modeling is seen as too heavy, too complex, too onerous, too inflexible, too grandiose, and just plain too impractical. This leaves us with an uphill battle to overcome negative preconceptions. But my impression from an Eclipse Modeling perspective is that the space for pragmatic model driven software development is thriving and growing rapidly. In terms of the market for it, I think the amount of free technology is leading folks to focus primarily on what's free, and to spend their dollars on services around the open technology. It leaves them in a more secure position because such clients are looking to invest in technology that has lasting value and that avoids the Teflon programmer effect. Being in a secure position that's safe from the whims of software vendor driven changes designed to funnel money from client pockets to vendor coffers has become an important decision factor.
I will have to disagree with you here, Vlad.

The model driven and the iterative approach are not compatible.

It is much easier to do iterative development in the model driven approach. Model-driven development means that changes in business requirements and technical decisions can be dealt with in a much less costly way than manual development.

. Many users in the past started a modeling project. They just delivered a first iteration and then stopped using UML because the team was already codding and it was too painful to model again. So they stop using UML just after the first model driven generation. This is why UML has such a bad reputation today.

Sorry, but that is not model-driven development. Model-driven implies model-centric. In true MDD, changes in requirements or technical decisions are reflected in the models and/or templates, and the code regenerated. Of course, that only works if either there is no need to touch the generated code after it is generated, or that the code generation tool can preserve hand-written code when regenerating.
"Sorry, but that is not model-driven development. Model-driven implies model-centric. In true MDD, changes in requirements or technical decisions are reflected in the models and/or templates, and the code regenerated. [...]"

"The problem doing that way was that changing core and merging with existing code was introducing many many new bugs. Each year the upgrade to the latest Eclipse release was easy but the tool stability was very poor. It was also almost impossible to expand the architecture and each evolution or changed was very difficult to implement because the code generation was then unstable."

This is clearly an issue. At NT/e we have taken a different approach for JeeWiz by having a two-stage generation. We first transform the information in the Eclipse model to a simplified, minimal XML format, which remains consistent however the modelling tool changes. When a new version of Eclipse or XMI comes out, we only need to reprogram the first stage of the generation so any introduced bugs are few and localized. It also gives us the advantage that the same intermediate XML is used for multiple modelling tools and the subsequent transform code is the same.

In normal use, the transform starts from the UML model as that's easier to get verified by the business (and the XML isn't even seen), but when developing the transform in the first place, the developers often use the XML directly for the test cases rather than any particular UML tool.

I agree with the consensus that having a separate iterative modelling stage is pointless when you can just generate a skeleton application for the users to play with. How long does it take to regenerate from a model throughout the lifecycle? Perhaps it was a symptom of when codegen tools simply weren't up to snuff, and the fact that this paradigm is dying should be seen as a good thing.

Agreed, Rafael.
Model driven development goal was since its very origin, to go from model to code; to make the development into the model. It implies that iterations must be made trough the model. If it isn´t possible, it shouldn´t be considered as MDD. Moreover, it should be viewed as an issue the fact that behavior be added as hand made code (If it is so, is reasonable what Vlad states: model is abandoned after the first iteration).
In order to guarantee productivity, MDD must be multiplatform, iterable, and developed at high level. If some variant of MDD fails to fulfil its goals, it does not implies an impossible goal.
¿Could MDD go back? I can´t realize a large project coded by hand, and, worst, maintained by hand.

Apart, this discussion becomes hard to follow. Maybe it should be ordered by date + thread (in a visual tree) ¿Is it possible?
I think that MDD as it is currently applied suffers from a few problems that limit its adoption:

- Huge training investment, not only on the tools to use, but also to achieve a "MDD" mindset.

The regular "Joe Developer" or the "Teflon Programmers" identified by Ed have a limited vision of development as a whole. They see MDD as an academic, research subject, still years away from any serious commoditization.

- Most MDD approaches are complex

I've learned that to successfully apply MDD, people need to learn three or more subjects from DSLs, transformation languages, UML, MOF, xUML, XMI, then EMF, etc, etc... That's a steep learning curve from technologies that are constantly evolving. How to keep the pace? How to reach proficiency?

- UML is unproductive, counter-Agile

UML suffers from the same problems as software documentation itself: Two separate tasks, needed to be maintained synchronized. As Vlad said, as soon as you have performed the first generate cycle, the UML model suddenly loses most of its value. So easy to add more code and so boring to maintain the model.. oh, the temptation!.... The model -> generate -> adapt cycle does not work. UML suffers even more problems that most of you surely know already.

So yes, I think MDD (specially OMG's MDA) is dying (will die) in its current format.

In my opinion, to succeed, Model-Driven Software Development must:

- Be accessible to the average developer without a specialized CS degree, or with no CS degree at all (like me)
- Use simple principles
- Generate complete systems (no chain of tools needed)
- Use the model as the one and only source (forbid any kind of edition in the generated system)
- Make generated and custom code happily co-exist.
- Focus on reuse

For some, this may seem impossible, but I managed, based on my own research over the years, to develop a new way to apply MDSD in such a way. So it's possible. I called it ABSE (Atom-Based Software Engineering).

I've submitted a proposal for a CG2009 session regarding this subject.
Rui Curado said:
I think that MDD as it is currently applied suffers from a few problems that limit its adoption:

So yes, I think MDD (specially OMG's MDA) is dying (will die) in its current format.

OK, so maybe I was too harsh. I am sure all current MDD approaches have and will continue have their place, but probably will continue to be small islands in the world's software development ocean.

For those in doubt, I am a strong MDD believer...
It would be convenient to make visible the implicit assumptions in this discussion as developed until now:
1. It has been mentioned MDA and UML. MDA and UML does not implies all MDD.
2. Not all developments are Open Source. Should be interesting to widen the discussion to any product/theory.
3. As Ed says, it should be convenient to separate market from technology.
May be this way the discussion could drive to different results.
Well said, MDD also includes Shlaer-Mellor OOA/RD which is where many of the original ideas for MDA originated. However, trying to apply MDA to UML in its current form is where things are going wrong in my opinion. UML is too complicated, too configurable, not yet executable, does not have a working interchange format (XMI is a joke) and is committee driven (by self interested tool vendors). My preference is to go back to Shlaer-Mellor OOA/RD and finish its development as an MDD platform while providing UML notational support in the form of Executable UML (xtUML). And that is exactly what I have been doing for some time now...
I think model-driven development is not dying. It is rather taking an evolutionary path, where some forms of appearances become extinct, some live in a niche and a few spread accross the biosphere.

A few years ago, I was working in a big project (modernization of an enterprise resource planning system, 400 entities being used), where the MDA/MDSD approach was applied. At that time, for more than three years, I experienced the effects of using modeling and generation and a set of related tools. I have seen visions and realities to get together. Some of the conclusions I took from that time are:

- Model Driven Software Development can make you getting somewhere, where you else would have never been able to get to. And that's such a comfortable place that you may want to go there again and again.
- The more different languages you use in a project, the steeper is the learning curve and the less flexible becomes the team.
- Applying MDA/MDSD can only be _one_ part of a project's success. It cannot solve problems that arise from the utilization of certain technologies or frameworks in the software architecture of the generated application. Also, it doesn't prevent you from making mistakes on the management level or in the area of requirements engineering. All this is somehow obvious. My point here is: being too focused on MDA/MDSD issues may obstruct your view.
- Generation performance is crucial, not only for the efficiency of application modeling and application generation, but even more so for the development of generation logic.

The time I spent in that project and the experiences I made throughout it, brought me to develop new tools and to found Generative Software.

Meanwhile, the evolutionary process has went on. New tools and new approaches have emerged, just to mention a few of them:
- Meta Programming System
- openArchitectureWare
- Eclipse Modeling Framework
- The Programming Machine
- MetaEdit
- Mia-Studio,

... will be interesting to see what the future brings.

P.S.: one of the session proposals I made for Code Generation 2009 covers the experiences I made in the aforementioned MDA/MDSD project
I use modeling along with iterative design, so they don't seem incompatible to me. Modeling != UML as Jorge suggests, so any comment directed at UML does transitively apply to modeling in general. There are few things in life that are actually free. So while downloading open source software might be free, the knowledge investment required to use it effectively is most certainly not. But that's true regardless of whether the software itself is free, so it seems a moot point. Quite a few companies provide EMF training, e.g., itemis, Obeo, Anyware, just to name a few. There's also an EMF book. I think EMF is a lot less complicated than JEE, so I'm not sure how arguments that can be equally well applied to JEE are valid. I really didn't quite follow the rest of the logic behind the expected death, but in my experience, where there is rapid growth there is life.

I agree with most of what Rui says, though I don't have the same separation anxiety about hand written and generated code. I think the focus on simple, small, and complete is definitely the key. Building tools and technology you use yourself every day, as we do with EMF, helps a great deal too. I think Marcus too hits the nail on the head: I'm able to do things today, that I could not manage any other way, so I'm addicted.
Jorge Ubeda said:
Apart, this discussion becomes hard to follow. Maybe it should be ordered by date + thread (in a visual tree) ¿Is it possible?

Hi Jorge, it was ordered by thread + date. I've now changed it to date only. We only have these two options. Let me know which you find easier to follow.




© 2018   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service