I am an ERP Project Manager for 7 years within a big company which has many subsidiary companies. As ERP team, we are not only implementing ERP software but also writing our own ERP with the target that we sell this product in the future. Our platform is Java and our applications are web-based. Ibrahim has posted 11 posts at DZone. View Full User Profile

Code Generators: Robots of the Software Factory

03.03.2009
| 6117 views |
  • submit to reddit

There are many analogies between software development and manufacturing. The “Software Factory” methodology utilizes these similarities. Another analogy is possible for the construction industry. As an interdisciplinary study, these similarities are beneficial to understand our own software problem.

In the manufacturing industry, robots replaced the workers in some product lines and workers did the controlling and managing of these robots. Robots are great examples of automation. They are configured for the current assembly-line product specifications. They don’t have to be artificially intelligent to do the job. The analogy is that code generators have similar features with industrial machinery robots. You program the generators according to your application specification and your software developers use these tools to produce the software (this is also called Generative Programming). In this way, we can automate software development.

There are many types of code generators and techniques. Some of them are low-level techniques that help achieving some specific tasks. One example is language abstraction. Your high-level language is automatically translated - generated into low-level machine code. One example in the Java world is JSP transformation into a servlet. These generators are generally invisible to the developers and can’t be considered as automation in development.

The generators that provide automation are those that generate final software that the software team develops. In business applications, final software is composed of elements like GUI, business logic code and database code. Every element of software may be taken into generators if you can capture the template or pattern. Templates are some specification patterns that depend on your API set. Let’s say templates are meta-descriptions of your coding standards.

“To build a generator or use an existing one” is one of the most discussed issues in a software team. Could we utilize the advantages of generators or could it be a wrong investment that would ruin a clean code base? The critical question lies behind the meaning of generated code for your team. If the value of generated code is high, and would shorten development time by removing tedious repetitive tasks, then it would be a worthwhile investment.


Code generation can be applied in following way:

Determine what to generate

To find repetitive task is not hard in your development environment. If the same things are done more than three times it is a candidate for generation. For example, generator experts recommend code generation for CRUD code.

Capture meta-level coding structure

Capturing your meta-coding structure is important. Your coding structure should have a pattern that is shared among applications. What are the variable parts that would be parameterized by generator? How is your GUI constructed? In which way do you access database? How does your controller code manage object states? Capturing is the hardest part of the whole job. It requires a deep understanding of the current development API set.

Build or configure your generator

There are many generators available, but if not satisfied with them you can write it yourself. After building it should be tested against current code to check if anything is wrong. Generated code should be complete, concise and error-proof. Otherwise leaky generators make it impossible to benefit generation technology. Your coders would prefer manual way instead of wrestling your generators.

My generator recommendations

  • Generators should not change generated code a lot. Otherwise, the “coding standards are maintained” benefit would be lost.
  • If we find an abstraction area, we should ask if this abstraction is done via code generator or a new API.
  • Generated code should as short as possible. It should be supported with a high-level API set to reduce produced code.
  • Every part of software can be generated. There is no limit. Limit is your capturing ability in your environment.
  • I don’t like “Your code is here” generators. IMHO, generated code can be changed in every way. Changing it should be safe as well. Dynamic generators that can change code base after customizations may restrict this. Static generators may provide much more freedom with the re-generation overwrite problem. If we change it, it should be readable and understandable.
  • More intelligent generated code means more intelligent generators. A generator's complexity should be manageable. Here MDA rescues. Models are a way to achieve sophisticated generation in a meaningful way. Generators should use models (i.e. database models).
  • Code generation should not be made a rocket science. Begin with small steps than make improvements. It should serve you, not tie you.
  • Code generation speeds prototyping and thus serves for Agile development. Any change in the software specification can be easily reflected into prototype without a heavy re-write.

    Links:
    http://www.codegeneration.net
    Code Generation in Action
    Generative Programming: Methods, Tools, and Applications
  • References
    Published at DZone with permission of its author, Ibrahim Levent. (source)

    (Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)