On the face of it, model-driven code generation should be easier and
safer than hand generation using a high-level language.
Also, David Glaser's estimate of a ratio of 20 to one in model-driven
vs. handwritten code sounds good enough to justify the costs of moving
to model-driven code. If the 5% or so of the system that is
hand-generated does not consume resources very disproportionately, the
economics of model-driven code generation should surely cause it to
overrun other methods.
Why is this not happening? Or not happening faster? I'm inclined to
think that most workers are not achieving that 20:1 level yet. Workers
who are achieving that level may be deserving of study (but not
dissection!).
Anyhow, the temptation to give it a try is getting stronger.
-Eric
Re: (ROSE) RE: Code is not design!
David Glaser wrote:
>
> I have been doing Model Driven Code Generation for a good while now.
> I got my start in compiler development in the early 1980s and since then
> I use code synthesis to deal with the repetitive parts of the system.
>
> In the last 8 years, I have used the modelers sold by Platinium , Rational,
> and Select Software to provide the data required to generate the boiler
> plate part the system.
>
> Depending on how well the architects can specify the repetitive behavioral
> patterns, one can generate substantial portions of the system. I have seen
> projects where everything was generated, except for the business logic.
> The ratio of generated code to hand written code was about 20 to 1.
> The ultimate result was a system that had very few bugs.
>
> It is not rocket science, just a different way of thinking.
>
> -David
>
> At 01:45 PM 4/7/2001 -0400, you wrote:
> >
> >The real world development cycle is:
> >
> > (lying, trial-and-error, brute force, and violence)
> >
> >Seriously, code is obviously a model of the system. Each set of UML
> >diagrams of a given type is also a model of the system. As Yourdon
> >types might say, the models exist in different spaces.
> >
> >The Holy Grail for us as analysts and designers is a model, or elegant
> >set of models, that translates domain knowledge into machine language.
> >We don't know how difficult this translation is, but I do get a sense of
> >convergence in progress. This is far off enough, though, so that the
> >discussion is out-of-place in a practical list like this one.
> >
> >As a matter of best practices, code is unlikely to be the best model for
> >the repository of A&D, because it was not designed for that. Code is
> >designed to impose a language representation of data and operations that
> >translates into machine language. The goals of the design are not
> >understandable in terms of code, and relatively simple code is a deep
> >mystery unless you are given a description of the design that shaped
> >it. The code structures are practically impossible to translate back
> >into a design, much less a set of requirements. Meaningful names for
> >classes, attributes, and operations may give the code some appearance of
> >comprehending the design, but even that is deceptive, because the
> >meanings themselves are not useful to the machine -- for instance, they
> >can't be used by the machine (or by any of the models that we currently
> >make) to create novel operations in the problem domain.
> >
> >Finally, the practical result of letting the code drive the design is
> >that the architecture tends to degenerate into a heap of patches. This
> >is entropy for systems.
> >
> >-Eric
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
