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: 531
Replies to This Discussion
-
Permalink Reply by Mountriver TY Yu on -
It appears that most people not opposed to the view? like as Rui said: “MDA has failed to reach wide adoption.” and there are many excellent exploration or practice, are not MDA, at least as Michael said: “there are pieces of the puzzle being put in place in small ways.”
I like Andreas' detailed comment that gave a clear background for this topic, and Juha-Pekka's mention for more clues, looking forward to more...
@Jeppe and @Andriy, I also agree, this is a shift of position. I think there are at least three important positions should not be ignored: the position of software implementation (architect and programmer), the position of software development companies (business ad management), and the position of software users (the end users and the management).
-
Permalink Reply by Mountriver TY Yu on
-
InfoQ: Why did MDE Miss the Boat?
Posted by Jean-Jacques Dubray on Oct 27, 2011
Focuses onJean Bezivin‘s speec.
-
Permalink Reply by Andreas Leue on -
I agree largely to the list of reasons for failure:
> no... killer application ...
True - and understandable, provided that the list of "missing features" given
earlier in this thread holds.
> ...too many definitions and camps...
True, but intrinsically necessary, since it only reflects that MDE indeed is a
complex task, much more difficult than the former leaps from say C to C++.
> ...confusion about what MDE is...
True, but only on the branding level. Two MDE experts over a beer will soon
agree on 99% of the matter
> ...UML...
Sadly, true.
It started all so promising...
> ...lack of focus...
Disagree!
There are two main fractions, each with a clear focus.
Fraction 1 is still following the "holy grail" set up in the '90ies: describe
full enterprise apps in a single, consolidated, business oriented model.
Fraction 2 tries to levarage the various really cool technologies that were
developed while heading for goal 1. Admittedly, both are at present hard to
sell, (1) since it's not fully accomplished and (2) since it's effects are not
directly tracable to cash.
But focus is there!
> ...precision is not always obtained through execution...
don't get this (intended vice versa?)
> ...not always aim at creating executable models...
True - but it's not a problem to me.
> ...confusion between programming and modeling...
Hm, in whose mind?
There is of course an ongoing debate about abstractions, but this is just a
necessary part of solving goal (1)
> ...adding complexity...
Oh yes.
> ...lacks modularity...
True, but is's more a social issue than a technical one.
> ...portability...
So true. :(
> XMI was a failure
Even truer.
> ...platform model was never taken seriously...
It was :-)
> ...CIM/PIM/PSM was a false good idea...
Agree/disagree, depending.
To some extend, a modelling chain is an intrinsic necessity (complexity
management) if you want to reach goal (1)!
> ...focused...model of code, and not enough on the model of data...
don't get this
> ...focused too much...
> ...on solution models and not enough on problem models...
> ... Information System models ...not ...Business Models
> ... on modeling in the small ...not ... in the large
Hm, all three are true, but not a mistake, but instead a necessary
evolutionary step. Simple because you have to take step 1 before you can take step 2.
> ...mainly [causes]...
My priorities differ:
> UML, the main problem
> confusing modeling and programming languages
> No definition / evaluation of executable modeling
I regard these three more as a symptom than a cause;
the cause is lack of apt abstractions
> Too many camps
Yes, a social consequence rooted in the complexity of the task.
Maybe we can do something about it.
>... learned a lot in the last 20 years...
Yes, absolutely agree
> ...only traces remain: DSLs ... and UML ...
Partially agree. Under the surface of marketing buzz (which is presently
dominated by agility) there has never been more activity in the community and
more progress with respect to MDx than ever before. My impression is, that
we're not far from a breakthrough - nevertheless not as simple as it is
sometimes declared.
> ...starting to build programming languages that are not necessarily
> languages you program into, but languages that you generate to?
Sure. Or at least: use them only to specify snippets, but not to manage
the architectural structure anymore.
As for the comments:
> We just need that damn killer app!!!
We do our best :-)
Just these days, we completed a more or less amountful project with 95%
described in a model, including UI & DB. The 5% correspond to such snippets
mentioned above.
> Long live naked objects!
And I agree very much to the design principles behind naked objects, since
code generation alone without drastic improvements in target architecture
of our systems is doomed, imho.
-
Permalink Reply by Andreas Leue on
-
@complexity
To be fair, one should distinguish necessary complexity from unhandled complexity. I think there is an amount of required complexity in the solution which corresponds to the complextiy in the challenge. That part is not a reason for failure, it is unavoidable.
But this complexity must be adequately addressed with additional measurements, adding even more complexity to the MDx-system internally. The reason for failure is, that this shielding process is not completed and there is too much added complexity visible from the outside, so that customers ask rightfully, why they should burden themselves with this stuff while getting only limited benfits.
This amount of complexity is also the point of controversy, where the ways of people heading for goal (1) and people heading for goal (2) part: usually too much complexity is perceived as a sign for being on the wrong track (Occam again), but the crucial question is, how much complexity is too much complexity?
At least we shouldn't judge too early: if we consider the complexity of the software stack found on an average computer today, from firmware, drivers, operating system, library layers up to cooperating applications and distributed systems, the MDx stack on top is only a minor addition.
-
Permalink Reply by Mountriver TY Yu on
-
> I regard these three more as a symptom than a cause;
> the cause is lack of apt abstractions
I agree this, and I also think this is a main point, and in addition, IMO, the distinctions for different abstractions in different situations.
On other hand, of course, the complexity is another important issue. I once heard a comment: MDA didn't address (reduce) any essential complexity for the problem..
- ‹ Previous
- 1
- 2
- Next ›
© 2012 Created by Mark Dalgarno.
Powered by
