--- In mda-discussion@yahoogroups.com, "H. S Lahman" <h.lahman@...>
wrote:
>
> Responding to Arnel_periquet...
>
>>> Point Summary
>
> code ... is an order of magnitude less compact than an OOA/D model
> ...
> An OOA/D model is supposed to be a complete, precise, and
unambiguous specification of what the software implementation must
do. So there shouldn't be a need for more formalization and the
models aren't teaching anything because they /are/ the solution.
> ...
> It is that rigor that allows model level simulation to validate
that the design has satisfied the functional requirements prior to
committing to code. IOW, the big gain is not dealing with 3GL code.
>...
> I would have to argue that the main advantage of MDD code
generation is that one /can/ re-generate the code rather than mucking
with it at the 3GL level. That ensures that the OOA/D models are
always in synch with the actual code and it removes the need for
worrying about things like maintainability refactoring.
>...
> One thing to note is that UML combined with a compliant abstract
action language is a 4GL. IOW, when one is creating an MDD model one
is programming in the same sense that 3GL programmers do; it is just
at a higher level of abstraction and resolving nonfunctional
requirements has been delegated to a different trade union (the
transformation engine tool vendors).>
>
> *************
> 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
>

------------------------
Thanks for the response.

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.

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

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.

Under the MDD world order, would a current OO framework vendor
transition to the new trade union (i.e., transformation engine
vendor) in offering an OOA/D model compiler that targets its
legacy nonfunctional competencies? Or, should the framework vendor
rise to the 4G world of domain frameworks teasing out its platform
vagaries and focusing on application design alternatives?

-Arnel