Standards and Infrastructure Required for Template-based Code Generation

In addition to a consistent object and persistence model that exhibits patterns, it was found that a number of standards and infrastructure pieces were required for successful code generation. Following are some of the more important standards and infrastructure pieces we identified.

Naming Standards: Naming standards were a critical item for the code generation. A large part of the template selection process is based on the name of the method (or portions of the name). Some local variables were given fixed names. For example, the return value from the method is always named "retVal".. ClassName, methodName, and other items had standardized names so they could be used as parameters in templates. In addition, since some of the code generation we did was C++ interfaces into Smalltalk, the method naming structure allowed parsing for Smalltalk method signatures.

Exit Points for Methods: Since we had preprocessing and postprocessing patterns as well as patterns that fell into the body of the method, it was important to be sure that all pieces of code would have the opportunity to execute. We made a standard that the method return must happen as the very last line of the method (either "return (retVal);" or "return();"). All code had to support "fall through" to the bottom of the method. Exit before the last line could only be done if throwing an exception.

Exception Handling: In many applications, more code is dedicated to exception handling than to the business logic. We found that standardizing exception handling reduced the overall amount of code and provided patterns that we could implement in the generator. Specifically, we created a single error structure and defined it as a "throws" on all methods. The structure contained the data fields: a criticality indicator (ex. warning, error, critical), a type indicator (ex. ruleViolation), a format indicator (ex. string, two dates and a string), and a string field that contained the detailed exception data, parseable based on the format indicator. After each call that had the potential for throwing an exception, we placed a "checkException" macro call with the reaction to an exception based on the needs of the template.

Memory Management: Memory leaks can easily bring a system down. With our exception handling patterns and the possibility of jumping out of a method, memory management was challenging. Our solution was to create a set of classes that would keep a list of objects that should be released if you left the scope of the method. If exception handling chose to leave in the middle of the method, the releases would take place before exiting. If you reached the natural end of the method, the releases would take place prior to return. The classes could do shallow or deep releases depending on the need.

Instance and Transaction Management: The OTM frameworks that we used took responsibility for instance and transaction management. We had to generate the code that hooked the framework to the database, but this was 100% generatable from patterns.

Factories: We made heavy use of both concrete and abstract factories. A naming service allowed us a consistent way of finding a factory. Within the factory, we placed specialized creator methods that forced the inclusion of the minimum required data items for a valid object. We also allocated all query methods to the factory.

Standardized Date Handling: Many of our objects had date dependencies on whether they existed or applied to a time period. To minimize possible problems in maintenance, we chose to apply standard date management too all objects. In this way, all queries could handle object selection by time period in a common way.

Constraint Rules and Edits: We found that constraints and edits tended to ask the same questions with different parameters(ex. is this number within a valid range, is this string from a valid list, etc.) We created 20 common rules that could be invoked in a parameterized manner using a framework. The code to trigger these rules was generated based on keywords and predefined locations. The reaction to the failure of the rules was part of the exception handling.