> Responding to H. S Lahman ...
>
> 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 think I understand how the approaches mirror at different
abstraction levels. You're take is that you either go 4G with an
optimized model compiler that automates the transformation, or you go
3G-agile. Ultimately the implementation technologies are the same, but
the real choice is compiler vs optimized code--just like the
3G-assembly analogy.

If I distinguish frameworks from architectures. Then I can put the
issue as "automatic compilation to architectures" versus "manual 3G
development of architectures". Frameworks, as you said, are an
orthogonal issue.

Does this sound right?






--- In mda-discussion@yahoogroups.com, "H. S Lahman" <h.lahman@...> wrote:
>
> 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
>