Responding to Arnel_periquet...

>
>The problem I see is that some organizations have a substantial
>commitment to their frameworks. In some cases, the frameworks _are_
>the business which means the non-functional part of the work is where
>much of the value lies. From that point of view, the use case for MDD
>becomes "how to provide extensible models that framework users can
>manipulate to make applications". Of course, we'd like the models
>that users extend to map to the non-functional work already done.
>There appears to be two options: (1) re-engineer _all_ models from
>the existing framework to be MDD generative (2) reverse engineer
>_some_ models from the existing framework to (re)generate a selected
>cross section of 3G code.
>
>

Hmm. Unfortunately I see the role of frameworks -- either for
development tools or in the customer domain -- to be orthogonal to both
MDD and the issues in your original post. As far as frameworks are
concerned I basically agree with Bettin.

But your original post seemed to be trying to compare MDD with OOP-based
agile development approaches. Those approaches are apples & oranges
because they approach development from opposite ends of the development
spectrum. There is overlap in that one can use agile practices for 4GL
MDD and the agile 3GL refactoring practices represent a distillation of
the same basic OOA/D of MDD. But one needs to decide which approach one
is going to use in a shop and the cost of switching approaches is likely
to be substantial.

FWIW, I think some version of translation-based MDD is inevitable
because the productivity and reliability benefits of the automation and
4GL abstraction are just too large. I was around in the early '60s when
the shift to 3GLs from BAL occurred. That paradigm shift was hard-fought
but inevitable for exactly the same reasons. It has just taken the 4GL
shift longer to materialize because the optimization problems are much
more complex and code generators with competitive performance for
general use simply hadn't been engineered until the late '90s.

>It seems you're saying MDD would supplant OO frameworks, i.e. the new
>frameworks are 4G. This is option 1.
>
>

I think the OO frameworks remain the same. The OOA/D applied in MDD is
exactly the same as it is in any OO A&D methodology. In addition, all
the same object-based technologies (e.g., Java beans, MVC, etc.) are
still used by the code generator. What modern development frameworks
have brought to the table is the ability of these elements to play
together at all levels of abstraction. So all that is changing is the
level of abstraction of application development and the creation of a
new breed of tool developers.

>For MDD "holdouts", option 2 may be a desirable choice. To capitalize
>on their pre-existing value, the idea would be to provide selected
>OOA/D models that "map into" a legacy framework using a re-write
>strategy. This is clearly a re-engineering effort whose cost is a
>gamble versus starting from the top down with a 4G framework.
>
>

There are three cases:

Case 1: the legacy is non-OO. If this case prevails one has a serious
problem trying to integrate it with any OO development approach. IOW,
MDD will be no more difficult than any other approach and they are all
high risk.

Case 2: the legacy is well-formed OO. If this case prevails there should
be no problem using MDD at all.

Case 3: the legacy is ill-formed OO. If this case prevails there will be
problems to the extent of how ill-formed the legacy is. However, that
would also be true for any other OO approach.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@...
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@... for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH