evelopers usually agree that it does not make sense to write all code character-by-character. After coding some features, they usually start to find similarities in the code, patterns that seem to be repeatable. Because nobody wants to write routine code, the idea of code automationgenerating the repeatable portions automaticallyarises both naturally and repeatedly. The obvious benefits of generators, such as productivity, quality, complexity hiding, and having more time to solve real domain problems, further boost the desire to seek automation.
Varied opinions exist concerning what kinds of code one can generate, and with what level of quality. For example, automation to produce static declarative definitions from common designs such as interfaces or database schemas has been a reality for ages, so multiple off-the-shelf generators are available. However, the situation is different when it comes to generating behavioral, functional code. I would like to emphasize that by generation I mean automatically producing code that is complete from the modelers' perspective. This means that the code is complete, executable and of production quality from the modeler's perspective; in other words, after generation, the code needs no manual rewriting or additions. Although it is possible
to edit the generated code, you should avoid doing so. Editing generated code is (or should be) analogous to manually editing machine code after C compilationtypically unnecessary. I'm a strong believer that you should treat generated code simply as an intermediate by-product. That has been the recipe of success for compilers, and code generators can achieve the same objective.
Many developers have bad experiences with third party generators, because the generator vendor has fixed the method of code production. Despite the existence of multiple ways to write code for a certain behavior, the vendor has chosen just one of them. The vendor's chosen way is not always likely to be ideal for your specific contingency, taking into account the target language generated, the programming model used, memory use, etc. Third-party generators often don't know enough about an organization's specific requirements to generate ideal code, so it is not surprising that many have found generated code unsatisfactory. Because modifying the generated code is usually not a realistic option, organizations end up throwing away generated code. The value of the generated code is then limited to prototyping and requirements gathering.
|Not having to give up control of the code generation process, from design to output format, to a faceless tool vendor makes a big difference in the acceptance of generated code. This is exactly the promise of Domain-Specific Modeling.|
Because of these disappointing experiences, developers show little confidence in generated code. This lack of confidence, however, changes radically when developers are asked if they trust generators they have made themselves. Not having to give up control of the code generation process, from design to output format, to a faceless tool vendor makes a big difference in the acceptance of generated code. This is exactly the promise of Domain-Specific Modeling (DSM). With DSM, an experienced developer can define the automation process and output for the rest of the developers in that team.
This automation works because the generator (and specification language) is made to satisfy the demands of a narrow application domainusually inside one company. It should be clear that you can't have a general purpose generator or specification language in model-based code generationeven if it would be nice to have a standard. Perhaps the most notable attempt is the Object Management Group's (OMG's) Model-Driven Architecture (MDA), which uses UML as the specification language. Unfortunately, 10 years of UML use have proven its code generation possibilities to be modest, and the role of UML models has stayed at the sketching level.
It's useful to look at some real-life cases where models have gone beyond sketches to generate full code. After having shown that full code generation can work, I'll address some guidelines for generator design that I have found useful.
While there's insufficient room in this article to cover everything, the example cases should suffice to show that code generation isn't just for one particular niche. The cases cover various generator approaches and various target languages, including XML, Python, C and Assembler. Each example produces fully working code and contains both the application logic and behavior, not just the easier-to-create static structures.