Hi Arnel,


> 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.

Yes. And there is a caveat: typically not all in-house developed frameworks are
of high value. Not differentiating between currently valuable frameworks and
legacy that has become a burden only fuels needless debates between framework
developers and MDD proponents. Valuable domain-specfic frameworks and
model-driven
transformation/generation are two sides of the same coin.
Transformations and generation take care of automating the production
of framework completion code.

> From that point of view, the use case for MDD

becomes "how to provide extensible models that framework users can

manipulate to make applications" .

Even in small frameworks the source code and additionally available framework
documentation is often not sufficient for framework users to quickly gain the
necessary insight into "correct" framework usage, i.e. usage as intended by the
framework developer.

Ensuring correct framework usage is one of the real strengths of MDD. After
creating a small example application, framework authors extract code templates
to automate the generation of framework completion code. At the same time
framework users are shielded from framework implementation details. Of course
there are those who argue that this not beneficial but rather dangerous,
amounting to a dumbing down of application developers. However, this line of
reasoning is suspiciously similar to the line of defense taken in favor of
assembler programming against the use of higher level programming languages.
Open MDD tools (those that allow users to specify tranformations and templates)
enable framework developers to do a "proper job". It is time to raise the bar of
framework quality expectations

> 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.

There is no need for a "re-write". MDD starts with a manually developed
reference implementation (which can be an existing application) that covers all
architectural layers. The reference implementation already includes the bindings
to appropriate commercial or Open Source frameworks. Abstracting framework
integration code from the reference implementation, and capturing the results in
the form of code templates only increases the costs of developing a
proof-of-concept prototype by about 15%-25%. Considering the amount of
repetitive framework integration code in typical enterprise applications, it is
easy to see that using a model-driven approach can save a lot of work.

Interestingly, the act of distilling transformations and templates from a
reference implementation often uncovers minor flaws in the design of the
reference implementation and underlying frameworks. Here lies one of the real
quality benefits of MDD.

The final step before using newly built transformations and generator templates
to build real applications, is the definition of a non-trivial test application
that covers interesting boundary conditions, which for economical reasons were
not covered in the reference implementation. The test application model is used
to provide a broad and realistic test of the entire architecture. This test will
very effectively uncover most errors that may have slipped in during the
generalization (derivation of code templates) of the reference implementation.
The technique of using a test model to validate the architecture on a broad
basis is a significant advantage over traditional software development, and is
very much in the spirit of agile and iterative approaches, where early risk
minimization is a high priority.


> 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?

See above. If the frameworks that an organisation has developed are really of
high value, no transformation engine vendor will have matching out-of-the-box
transformation and templates. However, a framework vendor should not reinvent
the wheel in the form of creating yet another transformation engine, and should
exploit available commercial and Open Source options.

Jorn Bettin

www.sofismo.ch - Software is Models
Sägestrasse 50, 5600 Lenzburg, Switzerland

Tel +41 62 891 0987
Mob +41 79 543 3767
Email jbe@...


----- Original Message ----
From: arnel_periquet <Arnel.Periquet@...>
To: mda-discussion@yahoogroups.com
Sent: Tuesday, November 13, 2007 10:11:46 PM
Subject: [mda-discussion] Re: Hurdles to MDA adoption













--- 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.pathfind ermda.com

> blog: http://pathfinderpe ople.blogs. com/hslahman

> "Model-Based Translation: The Next Step in Agile Development" .

Email

> info@... for your copy.

> Pathfinder is hiring:

http://www.pathfind ermda.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














<!--

#ygrp-mkp{
border:1px solid #d8d8d8;font-family:Arial;margin:14px 0px;padding:0px 14px;}
#ygrp-mkp hr{
border:1px solid #d8d8d8;}
#ygrp-mkp #hd{
color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px 0px;}
#ygrp-mkp #ads{
margin-bottom:10px;}
#ygrp-mkp .ad{
padding:0 0;}
#ygrp-mkp .ad a{
color:#0000ff;text-decoration:none;}
-->



<!--

#ygrp-sponsor #ygrp-lc{
font-family:Arial;}
#ygrp-sponsor #ygrp-lc #hd{
margin:10px 0px;font-weight:bold;font-size:78%;line-height:122%;}
#ygrp-sponsor #ygrp-lc .ad{
margin-bottom:10px;padding:0 0;}
-->



<!--

#ygrp-mlmsg {font-size:13px;font-family:arial, helvetica, clean, sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99% arial, helvetica, clean,
sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;}
#ygrp-vitnav{
padding-top:10px;font-family:Verdana;font-size:77%;margin:0;}
#ygrp-vitnav a{
padding:0 1px;}
#ygrp-actbar{
clear:both;margin:25px 0;white-space:nowrap;color:#666;text-align:right;}
#ygrp-actbar .left{
float:left;white-space:nowrap;}
.bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;font-size:77%;padding:15px 0;}
#ygrp-ft{
font-family:verdana;font-size:77%;border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px;}

#ygrp-vital{
background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;}
#ygrp-vital #vithd{
font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:upp\
ercase;}
#ygrp-vital ul{
padding:0;margin:2px 0;}
#ygrp-vital ul li{
list-style-type:none;clear:both;border:1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-ri\
ght:.5em;}
#ygrp-vital ul li .cat{
font-weight:bold;}
#ygrp-vital a{
text-decoration:none;}

#ygrp-vital a:hover{
text-decoration:underline;}

#ygrp-sponsor #hd{
color:#999;font-size:77%;}
#ygrp-sponsor #ov{
padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;}
#ygrp-sponsor #ov ul{
padding:0 0 0 8px;margin:0;}
#ygrp-sponsor #ov li{
list-style-type:square;padding:6px 0;font-size:77%;}
#ygrp-sponsor #ov li a{
text-decoration:none;font-size:130%;}
#ygrp-sponsor #nc{
background-color:#eee;margin-bottom:20px;padding:0 8px;}
#ygrp-sponsor .ad{
padding:8px 0;}
#ygrp-sponsor .ad #hd1{
font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%\
;}
#ygrp-sponsor .ad a{
text-decoration:none;}
#ygrp-sponsor .ad a:hover{
text-decoration:underline;}
#ygrp-sponsor .ad p{
margin:0;}
o{font-size:0;}
.MsoNormal{
margin:0 0 0 0;}
#ygrp-text tt{
font-size:120%;}
blockquote{margin:0 0 0 4px;}
.replbq{margin:4;}
-->







[Non-text portions of this message have been removed]