Well, I would say that effective code generation requires that it be incorporated into the project from the very beginning and that the architects be very good at detecting patterns - no matter how subtle.
I just finished a business object code generator that did 100% code generation from a model. However, we had problems with code bloat and solved the problem with a common runtime library. The business objects are used by the device drivers of an ATM Switch. The programmers love it because the generated code hides all interaction with the underlying RDBMS - Polyhedra in this case. Right now I'm in the middle of developing a code generator targeted to the C++/ATL environment. If emits the implementation for business objects whose persistent representation can be in XML files or in a RDBMS. This generator will output all of the attribute accessor functions, association accessor functions, the implementation of the IPersistXXX load and save functions, the .RC files, the .rgs files and the Makefiles. The only thing that the programmer has to write are the explicitly modeled operations. Even in this case, the programmer's job is facilitated by the presence of the accessor functions and the generated runtime support functions - load, save, check security, ... General use of the above techniques is not magic or rocket science. All it requires is education. I was lucky in that I cut my teeth on compiler work 20 years ago so the "invention" of model driven code generation was a no-brainer. I can say that model driven code generators are much simpler than code generators for programming languages and is certainly doable by a programmer with a BSCS. All it requires is education. -David At 12:15 AM 4/8/2001 +0000, Eric D. Tarkington wrote: >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 * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
