The Model Driven Software Network
Raise your level of abstraction
Have Models Filed?
Jean Bezivin said (here)
Are there any comments for this?“Models have filed, at least temporarily. [...]The deployment of MDE seems today to have reached a standstill.”
Views: 561
Replies to This Discussion
-
Permalink Reply by Rui Curado on -
It's now generally accepted that MDA has failed to reach wide adoption. Because MDA was the most visible form of MDE, this failure has dragged MDE as a whole to the "mud".
Many people is now skeptical because what they knew as "MDE" (actually MDA) was heavy and badly supported.
When I presented ABSE to Dean Wampler two years ago he wrote: "I have to tell you that I'm somewhat skeptical of MDSD, based on my past experience at Rational Software. Of course, Rational tried to use UML for MDSD. I would love for someone to make MDSD work efficiently and effectively."
-
Permalink Reply by Angelo Hulshout on -
Hmmmm.... I'm not sure I agree. Actually, I know a number of companies who are actually picking up on MDE and MDSD right now. It may not be as visible as it was a few years ago, but the fact that companies like IBM and Borland are no longer bragging about their coming achievements doesn't mean that nothing is happening.
-
Permalink Reply by Andreas Leue on -
> Models have failed
Agreeing to Rui, it obviously depends on what you declare as "models"
> MDA has failed
In it's pure form (without additions and modifications) I'd say yes, too.
Nevertheless, I wonder a little, since MDA is now about 10 years old and for at least 5 years it is a more or less known fact...
> We consequently propose the view that the current iteration may not be the last one.
I agree, and would like to add that a) it can be shown why and b) the "next iteration" is already running, for several years now. To be specific:
a) Why another iteration is necessary
MDx's history can be devided in four phases
- phase 0: PCG (plain code generation, pre 90ies)
Early experiences, using preprocessors, macro expanders, maybe lex/yacc/flex/bison and alike. Applied everywhere, not confined to specific languages or abstraction layers
- phase 1: CASE ('90 - '00)
Trying to paint THE model (OOD, ERD,...) and generating THE application from it.
Failed fantastically. :-)
Either the model became heavily overcomplex, or the application was an oversimplified toy (or both).
- phase 2: MDA ('00 - '10)
Introduction of an intermediate model to mediate between both sides. Better than MDA, but still problem not solved: far too much manual "postprocessing"
But since noone wants to work on two abstraction layers, and since the benefits of MDA are rather small if not the vast majority (99%) of information is contained in one place, single source, the approach falls too short.
- phase 3: (name to come, '10 - '20)
The MDx stack from sea bottom (current xGL languages) must reach the sea surface to be useful. Several issues must be addressed:
-- "domain" models are sill too complex for domain experts -> additional pre-transformation with DSLs; but not DSLs alone, then again it's kind of back to pre-MDA-age (many projects tried that)
-- technology must be agile and fun to work with (instead of being clumsy) to be able to experiment and to be adaptive in real-world-projects -> many better tools are already out there now (transformators, generators)
-- standard (or at de facto standard) languages and transformators are required at the intermediate levels; unfortunately, we're still far from this stage and the community is seamingly not yet interested in cooperating, most vendors still try to push "their" solution (this refers not to the tools, but to specific lanugages and specific transformations built with these tools)
-- standard (or de facto standard) and usable (!) formats are required to give people an absolute minimum of trust into that technology; here is progress, but it's not yet sufficient (the current set of open standards available for the Java world from OMG/eclipse is imho too bulky)
-- independent and well crafted editors (visual or textual) are required; this of course relies on standard formats, since otherwise each vendor has to write it's own editor
-- completeness of domain models is required, i.e. BL as well as UI and DB layer, as well as possibly a service layer, data exchange, analysis, reporting and all the stuff must be contained or at least being seamlessly integratable; here we progress, too, but not widespread
-- process models must be contained or seamlessly fit to MDx models (I recommend UBPML.org for that purpose); still the awareness for that integration necessity is low
-- social capabilities will be required more and more for domain model specification (modelling in wiki, discussing requirements in a structured form, easy integration of workflows etc.)
-- much increased flexibility of the output is required, and many, many possibilities of customizing at the appropriate abstraction level, including UI customisation as well as DB backend(s), service interfaces, etc.
b) The "next iteration" is already running
As the above list shows, there are many things to do, compared to MDA, but many, many things are already inprogress or even already available.
An additional problem is that there are many issues to consider and some people work here, some there, and - naturally - everyone considers his own work as the most important one (which is of course driven by marketing necessities) - but successful MDx might require the big picture, at least it must address a lot of the above issues.
-
Permalink Reply by Lee Riemenschneider on -
The timeline and MDA commentary completely ignores the Shlaer-Mellor / Executable UML contributions. The companies selling MDA solutions based on Shlaer-Mellor / Executable UML have reported an increase in business, but still hold a small share of the MDx market.
Adoption of Shlaer-Mellor / Executable UML has always been slower due to developer resistance of going to the next abstraction level, and the cost of the translation engine (model compiler). There have also been misinterpretations of the viability to various markets. (I have seen claims that it is only viable for embedded systems and claims that it is not viable for embedded systems.)
I don't think MDx will ever go away, because pictures are much more expressive than text; pictures are capable of abstracting away details not relevant to the problem under consideration. The problem is that when the pictures don't abstract encompass those irrelevant details, then they become less expressive; the usefulness becomes one of tool support. i.e., which tool lets you develop at that abstraction level faster and cheaper. The text editor wins this battle.
-
Permalink Reply by Andreas Leue on
-
I apologize, it was not my intent to ignore Executable UML.
In fact, the timeline above is way too coarse, and many things listed in the 10-20 period started already between 00-10 or even earlier under the radar. I just took the two most visible milestones (CASE & MDA) for laziness' sake to mark the landscape, being unfair to the new millenium.
That said, I tried to address the executability-issue with "...completeness of domain models is required, i.e. BL as well as UI and DB layer...".
-
Permalink Reply by Juha-Pekka Tolvanen on -
I don’t agree with Jean Bezivin’s talk title, but I believe I need to hear his talk first. Perhaps tomorrow (http://coomp.org/2011/program.html) I learn what he means by the failure. Looking the abstract of the talk (http://coomp.org/2011/program.html#jb), it seems to be about MDA and as Rui already wrote, the idea of models transformations between CIM, PIM, PSM and code has not happened. It seems that nothing has happened even for the initiative MDA guide from 2001 from OMG. I believe we can agree on failure of the idea of model to model transformation chains where you edit the models during the process?
Other talks in that even actually show different results than Jean + there is also 5 or so cases at the same time for a 2 day Domain-Specific Modeling workshop (http://www.dsmforum.org/events/DSM11/index.html).
-
Permalink Reply by Andriy Levytskyy on -
Quote: I believe we can agree on failure of the idea of model to model transformation chains where you edit the models during the process?
What is the alternative of this extremity? :)
-
Permalink Reply by Andreas Leue on
-
Hi Juha,
did you attend the talk?
-
Permalink Reply by Michael Osmond on -
I would say where I am in Australia there's not much talk about MDSE so maybe its failed to get traction with large projects as a way to deliver systems. However, when I look at some of the tools that we use every day they look a lot like MDSE at a low level.
One example is the WIX tool set, where we use XML to describe an MSI installer, it is then processed to compile into an MSI package. But the tool set provides a number of abstractions to simplify the problem space. There is also a tool chain that goes with it so that you can generate installer information from the Visual Studio environment. It may not be called MDSE, but it has a lot of similarities.
There are a few other cases where I have seen DSLs used to solve particular domain problems, be they simply the building of a development environment. There are some deployment automation tools such as Pupet that are talking about Model Driven Deployment (or operations).
It seems to me there are pieces of the puzzle being put in place in small ways.
-
Permalink Reply by Jeppe Cramon on -
I agree with Rui - it's MDA that has failed (mostly), but Models in general have it hard from the start. Management is not interested (yet) and developers fear or recent them.
When we approach potential customers, the first thing we have to convince them of is that MDSD is NOT MDA and it's not CASE tools.
Model driven is not a buzz word with management in general and hence it's not something that companies specifically go after. However we see an increased interest in modeling and defining enterprise level models and this is where we see an opportunity to help companies bring these models to life, so they're not just an artifact of some misunderstood architecture department but actually can be used for development. Other times we see software projects being asked to document their models in UML which is a clear opportunity for automation and introducing a higher abstraction level. Few projects are directly interested in DSL's, but mostly as an internal DSL level.
So I would say Models are alive, but they're not a central player for companies and you have to convince them that electrifying their models (and thereby also taking steps to abstract and improve them). The main focus is on documenting things, but this is IMO better than no models at all.
So there's a long way from the current state to a place here we can say that MDD is alive in companies, but as we work with them we see an increasing interest in moving towards MDD. But we're talking about small incremental steps (which is probably good) with very vendor specific tools.
-
Permalink Reply by Andriy Levytskyy on
-
In my opinion models have failed (for now) because they failed to be relevant to companies. I see two main causes behind this failure:
1) MDE community has been too focused on the technical side, and too little on showing its relevance and advantages in as concrete as possible ways. MDE is just one of possible means to solve (communication) problems within an organization and organizations often choose for more familiar alternatives, including scrapping problematic activities all together (e.g. via outsourcing of development, streamlining/simplifying product, etc..).
2) In general organizations simply lack semantics/experience to understand what MDE can mean for them. This lack of understanding is due to MDE not being mainstream. And the same lack of immediate understanding reinforces the negative effect of cause 1.
In my experience, the best way to sell models/MDE is not to mention them at all in the beginning. It is easier to sell information architecture, process improvement, documentation simplification, etc.. (depending on the situation) to management, and later introduce models/transformations as means to projects's goals.
-
Permalink Reply by Jeppe Cramon on
-
Good points Andriy - I agree.
We also try not to sell MDD/MDE, but instead talk about their problems and how improved process, communication and automation can help them.
On a side note: IMO point 1 is also valid for most SOA implementations, whereas point 2 is not (since SOA has management attention). Due to point 1 SOA often fails - it's only technology and none business... Maybe we can learn from this?
/Jeppe
© 2013 Created by Mark Dalgarno.
Powered by
