Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


Articles
Lifecycle
Design
Programming
Soapbox
Reviews
Cthulhu

Java Swing
Swing's greatest threat isn't SWT, it's Flash
Swing Survival Guide


 
Check out our ageing Reviews Section


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:



Programming

Automated Code Generation (Page 7)

<< Introduction & Message Forum

<< Page 6 (Generators and Agile Projects)


Conclusion

Code generators are especially useful for large scale projects that are collapsing under the weight of their own code. Instead of having to maintain a 500,000 line program, the team can instead maintain a 40K properties file.

Effectively, generators shift the emphasis of project deliverables. Suddenly, most of the source code is an intermediate, machine-generated step in the overall build process.

Used properly, generators can massively improve the following aspects of your project:

Timescale ("crank out" 90% of your codebase in minutes or even seconds!)
Defect count (machines don't make nearly as many mistakes during repetitive tasks as us humans)
Agility (adaptiveness to changing requirements)
Design consistency (the design patterns used by the generator are applied consistently throughout the project)
Design quality (assuming the design patterns chosen by the generator authors are good ones)
No refactoring required! (At least, not on the generated code)
Even large-scale projects can be handled with agile gloves

Potential risks of code generators include:

Vendor lock-in (don't go for any generator tool that doesn't give you the full generator source code)
Design lock-in (subjects your project to the code designs prescribed by the generator authors)
Might not always save time (the generator must be written or configured first)

None of these are unavoidable risks. In fact, with the right generator, the opposite to design lock-in happens: the generator should give you a choice of designs to solve the same problem.

The ideal project would be one in which the team's mindset is not so much one of: "Now let's set about coding this module," but one of "Now let's set about generating this module!"

At every stage of the project, the developers should be thinking about how to apply automated generation techniques. Pretty soon, they should become very good at quickly identifying what areas can be generated, and in configuring (or customising) the appropriate generator to do the job.

To achieve this, the generator must be very flexible. It must be possible to both configure the generator (e.g. tell it which tables and relationships to generate) and to customise it (e.g. to plug in your own writer classes and tell it to use those for certain tables).

Customisation actually gives us the power to apply code generation techniques to new areas of the project, as and when they are identified.

The generator should also be scriptable, so that you can hook together all the generated parts of your project, and crank out the whole lot in a single build process.

The generator should be fast. You don't want to have to wait a whole hour (or even five minutes) just to try out a change to the database.

The generator should, of course, be robust and well tested. Your entire project will be dependent on the code that it generates. Therefore, you cannot afford for the generator to be buggy.

The generator should cut out as many production stages as possible. Say you are producing an EJB layer for a database: it is better to point the generator at the database itself than (say) at the design tool from which the physical database was derived. Then there's a better chance that the generator is producing up-to-date, relevant code. Even better, generate both the SQL that creates the database and the EJB code from the same source: and run both generators from the same build script.

Currently there are as many approaches to code generation as there are code generators. Code can be generated directly from a database, or from a UML diagram, or an ER physical database design. As previously mentioned, there are few (if any) formal standards in the code generation world. Is this necessarily a bad thing? At this stage, generators are still evolving at a rapid pace. Imposing a standard too early might stifle the innovation that we are currently seeing.

Once things settle down a bit, then standards will be a welcome addition.

Code Generators

JGenerator, enterprise-grade application generator - empowers architects to build custom architectures, rather than work around existing frameworks (Javelin Software Ltd)

XDoclet, an extended JavaDoc doclet engine that can generate source code or other files. Mainly used for EJB generation. (http://xdoclet.sourceforge.net/)

The Alchemist, from "Cut the Crap Software" (cool name!). Uses a simple XML file to generate a persistent object model, javadocs, a standalone graphical application and a Struts and Tiles based servlet. Also see this Personal History article which has some good ideas that relate to code generation - worth a read.

TopLink, object-relational mapping tool (WebGain)

OCL Compiler, an OSS code generator

ModelRun, run prototypes directly from models (BoldSoft)

LowRoad, J2EE and Struts generator sourced from XML files (Tall Software)

EJBGen, an EJB 2.0 generator that uses the Java help system (JavaDoc). You need the beans compiled (Cedric Beust)

JET Tools, uses XSLT and creates fairly basic EJBs
(When I checked, this link wasn't working)

Castor, an open source data binding framework between Java objects, XML documents, SQL & OQL databases and LDAP directories (Exolab)

WMEE, generates J2EE code out of UML models (Sygel)

EJBWizard, a graphical EJB 1.1 generator

 


References

Javelin Software: JGenerator, November 2001 (http://www.javelinsoft.com/)

Javelin Software: JBeans White Paper, November 2001 (http://www.javelinsoft.com/jbeans/)

Agile Modeling: Toward Executable UML, January 2002 (http://www.sdmagazine.com/documents/s=2279/sdm0201h/0201h.htm)

Mark Pollack: Code Generation Using JavaDoc, August 2000 (http://www.javaworld.com/javaworld/jw-08-2000/jw-0818-javadoc.html)

Michael J. Rettig, Martin Fowler: Reflection vs. Code Generation, November 2001 (http://www.javaworld.com/javaworld/jw-11-2001/jw-1102-codegen.html)

David Churchville, Meta-Data Based Code Generator, April 2002 (http://www.theserverside.com/patterns/thread.jsp?thread_id=13243)

Soumen Sarkar, Craig Cleaevland: Code Generation Using XML Based Document Transformation, November 2001 (http://www.theserverside.com/resources/article.jsp?l=XMLCodeGen)

Craig Cleaveland: Program Generators With XML and Java, February 2001 (Amazon)

Krzysztof Czarnecki, Ulrich Eisenecker: Generative Programming: Methods, Tools and Applications, June 2000 (Amazon)

Leon Starr: Executable UML How to Build Class Models, December 2001 (Amazon)

Marc Balcer, Stephen J. Mellor: Executable UML: A Foundation for Model-Driven Architecture, Not Yet Published (Amazon)


Of course, this is by no means an exhaustive list! If you know of any other generators (or are a code generator author), please let me know (or post a message on the forum).



<< Back to Programming

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.