|
|
Code generation! Hooray! No more programming, the computer will do it all! Just push a button and watch an entire system be written right before your eyes. Satisfaction guaranteed.
Is this for real?
One of the eternal quests over the last decade has been the creation of a computer program which will create other computer programs. Sounds pretty nifty, huh? Yet, if you stop and think about it, this is really the function of a source language compiler. The compiler is simply taking a higher level language (such as COBOL) and turning it into a lower level language (machine code). Modern day code generators are taking an even higher level language (action diagrams, defined pseudo-code, etc.) and turning it into a lower level language (COBOL, C, Pascal, etc.). Hopefully, if the decision was made to utilize one of these currently available code generation products, the technical design was highly focused on creating the proper deliverables for making the generation process possible and productive.
The construction approach taken from this point forward is very dependent on the definition and code generation approach taken by the selected product:
Screen/Report Definition Approach
This type of approach requires the application builder to "paint" the layout of each individual screen or report. Generally, these products provide a "what you see is what you get" method of designing each system component. In conjunction with creating the layouts, the application builder must also define each of the individual data elements as they are placed on the screens or reports. Finally, the action codes which will be utilized on each screen are usually chosen from a predefined set of standard actions supplied with the code generator.
This type of product is excellent if the team plans to use prototyping sessions during the design stage. Painting each screen and then generating a working version for review, not only increases the confidence of the business clients who attend the sessions, but it can also enhance the quality of their feedback. The only real drawback to these products is that the application builders and business clients have to live with the default look and feel of the generated screens.
CASE Based Approach
Many case tools utilize diagrams created within the workstation themselves as a basis for generating source language programs for later compiling. Utilizing this approach, the application builder spends time creating detailed procedural (action) diagrams which record all of the required database accesses, the decision logic, and the final program inputs/outputs (reports and files). These diagrams are then interrogated and used as the basis for generating the chosen source language statements.
Pseudo Code Based Approach
This approach is very similar to the CASE method except that instead of using graphical action diagrams, a high-level pseudo code definition is used.
Skeleton Based Approach
A significant number of code generators are simply skeleton programs (sometimes referred to as models) which are prewritten to perform specific on-line or batch functions. In order to customize the skeletons, the application builder is required to define the screen layouts (maps) and to utilize predefined user exit routines to enhance the screen or batch program processing. This entails adding additional source code statements within the users exits to perform unique tasks to meet the specific program design requirements.
