12
CHAPTER 1
O
VERVIEW
as if it were a user, and load the test data through the JSP interface. This provides a
convenient system test that will check the entire technology stack from end to end.
Figure 1.10 shows how the user agent generator connects through the user interface
into the system.
1.1.5
Step 5: integrating a technical change
After two weeks of testing, we discover a bug that involves the storage and display of
very large numeric values. After some direct debugging against the generated code,
we find that the fix requires a change to the definition of 90 percent of the fields in
the database, as well as changes to the corresponding type definitions in the majority
of the Java classes.
Altering the templates within the generator takes a day. Running the generators
requires four minutes. Unit and manual testing consumes two more days.
We calculate that manually making these fixes across all of the Java classes and
across the database schema definition would take six months of work and that the
code we would have at the end of the process would be of questionable quality.
As you can guess, we are pleased with the difference in outcomes between code
generation and hand-coding when it comes to altering the entire code base.
1.1.6
Step 6: integrating a design change
Using code generators has accelerated development to the point where we are able to
show some reasonably useful demos early in the process. The demos give both the
engineering team and the product marketing group insight into the shortcomings
with the original application specification. It is obvious that extra functionality is
necessary, to the tune of about 20 new tables. Substantial changes are also required in
the structure of some of the existing tables.
Figure 1.10 0 The user agent generator builds robots that test the application using the 
JSP interface.
Pdf compression - Compress reduce PDF size in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
C# Code & .NET API to Compress & Decompress PDF Document
best way to compress pdf; pdf form change font size
Pdf compression - VB.NET PDF File Compress Library: Compress reduce PDF size in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
VB.NET PDF Document Compression and Decompression Control SDK
change font size pdf; adjust size of pdf
GENERATION
CASE
STUDY
13
We are able to react to these changing business requirements by altering our
schema definition files and regenerating. After a few iterations and some alterations
to the templates, we are able to demo the rudiments of the new schema and refine the
feature set even further.
It’s almost impossible to calculate how far we would have progressed toward
project completion if we had been hand-coding. Discovering the flaws in the design
would have necessitated making a serious business decision: either rewrite major por-
tions or maintain the faults in the design. Using code generation, we are able to
quickly react to customer demands and make large-scale changes to the structure of
the software.
1.1.7
Step 7: building an RPC layer
One of the items on the “wish list” for the project is a Remote Procedure Call (RPC)
layer. This had originally fallen off the list because of schedule pressures. Now that
we are ahead of schedule, we decide on the fly to take the next step of building a Sim-
ple Object Access Protocol (SOAP) layer on top of our application. The RPC layer
will go on top of our database access layer. Using the API definitions file that is
already being generated for the user interface generator, we create another RPC gen-
erator that builds not only the server side of the SOAP layer but also client adapters
for Visual Basic and C++, which makes it easy for our customers to use our APIs.
Figure 1.11 1 We’ve added an RPC generator that builds not only the server code but the client 
stub code for both Visual Basic and C++.
C# PDF Convert to Tiff SDK: Convert PDF to tiff images in C#.net
zoomValue, The magnification of the original PDF page size. override void ConvertToDocument(DocumentType targetType, ImageCompress compression, String filePath).
change page size pdf; pdf page size may not be reduced
C# Create PDF from Tiff Library to convert tif images to PDF in C#
Description: Convert to PDF with specified compression method and save it on the disk. Parameters: Name, Description, Valid Value.
pdf compression; adjust pdf page size
14
CHAPTER 1
O
VERVIEW
Figure 1.11 shows the entire RPC layer. This includes the RPC generator, which
in turn builds the SOAP layer, the Visual Basic code, and the C++ stubs.
To test the RPC layer, we use a derivative of the user agent test system. This new
robot uses Perl and SOAP::Lite to talk to the SOAP layer to implement the test
data-loading.
1.1.8
Step 8: building documentation
The final engineering task before deployment is to build documentation both for the
RPC layer as an external resource and for the internal APIs as a programmer refer-
ence. Using a documentation generator, we build RPC documentation using a defi-
nition file that is output as part of the RPC layer generation. The internal API
documentation is built using standard JavaDoc tools. Figure 1.12 shows our com-
pleted system (the JavaDoc output is implied in this figure).
Figure 1.12 2 The documentation generated for the RPC layer by the RPC generator. The Java-
Doc output for the other layers is not shown here.
C# PDF Convert to Word SDK: Convert PDF to Word library in C#.net
zoomValue, The magnification of the original PDF page size. override void ConvertToDocument(DocumentType targetType, ImageCompress compression, String filePath).
optimize scanned pdf; change font size pdf fillable form
C# Create PDF from PowerPoint Library to convert pptx, ppt to PDF
Description: Convert to PDF/TIFF with specified compression method and save it on the disk. Parameters: Name, Description, Valid Value.
change font size in pdf comment box; pdf custom paper size
B
ENEFITS
OF
CODE
GENERATION
FOR
ENGINEERS
15
1.1.9
Case study conclusions
We can make several assertions from this hypothetical case study:
• Code generation has a dramatic impact on development time and engineer-
ing productivity.
• The application is amenable to change on a large scale.
• The business rules are abstracted into files that are free of language or frame-
work details that would hinder portability.
• The code for the application is of consistently high quality across the code base.
In the chapters that follow, we describe the techniques we used in this case study in detail.
The case study uses a lot of generation. You may find that your application doesn’t
need to use that much. Not to worry—this book covers both small and large code
generation implementations.
1.2
B
ENEFITS
OF
CODE
GENERATION
FOR
ENGINEERS
As the case study shows, code generation techniques provide substantial benefits to
software engineers at all levels. These benefits include:
• Quality—Large volumes of handwritten code tend to have inconsistent quality
because engineers find newer or better approaches as they work. Code generation
from templates creates a consistent code base instantly, and when the templates
are changed and the generator is run, the bug fixes or coding improvements are
applied consistently throughout the code base.
• Consistency—The code that is built by a code generator is consistent in the
design of the APIs and the use of variable naming. This results in a no-surprises
interface that is easy to understand and use.
• A single point of knowledge—Using the case study as an example, a change in the
schema file percolates through all of the cascading generators to implement the
change across the system. Even in the best hand-coded systems, a table name
change would involve individual manual changes to the physical schema, the
object layer and its documentation, and the test bed. A code generation archi-
tecture allows you to change a table name in a single location and then regener-
ate the schema, the object layer, the documentation, and the test bed to match
the new naming requirement.
• More design time—The schedule for a code generation project is significantly
different than for a hand-coded project. In the schedule for hand-coding large
sections, little room exists for analyzing the best use of the system and the
APIs. When faulty assumptions are made about use of the framework APIs,
then either those decisions are retained or large sections of code have to be
C# Create PDF from Excel Library to convert xlsx, xls to PDF in C#
Description: Convert to PDF/TIFF with specified compression method and save it on the disk. Parameters: Name, Description, Valid Value.
change pdf page size; change paper size in pdf
C# Create PDF from Word Library to convert docx, doc to PDF in C#.
Description: Convert to PDF/TIFF with specified compression method and save it on the disk. Parameters: Name, Description, Valid Value.
change font size in pdf text box; acrobat compress pdf
16
CHAPTER 1
O
VERVIEW
rewritten to use the API appropriately. With code generation, engineers can
rewrite the templates to modify how APIs are used and then run the generator
to produce the fixed code.  
In addition, because code generation compresses time on certain projects,
more time can be spent doing adequate design and prototype testing to avoid
downstream rework.
• Design decisions that stand out—High-level business rules are lost in the minu-
tiae of implementation code. Code generators use abstract definition files to
specify the design of the code to be generated. These files are much shorter and
more specific than the resulting code. Small exceptions stand out much more
clearly in a five-line definition file than in the resulting five hundred lines of
implementation code.
To sum up, when you can work smarter rather than harder and use the computer to
offload some of your work, your project will be better off. 
1.3
B
ENEFITS
OF
CODE
GENERATION
FOR
MANAGERS
Many of the advantages to the engineer should be important to engineering manage-
ment, such as increased productivity and quality. There are certain aspects, however,
that are uniquely important at the business level. Let’s take a look at these business-
level advantages:
• Architectural consistency—The code generator used for a project is the realization
of the architecture decisions made upfront in the development cycle. This has
three advantages:
• The generator encourages programmers to work within the architecture. 
• When it is difficult to “get the generator to do what I want it to do,” it is a good
indication that the new feature does not work within the existing architecture.
• A well-documented and -maintained code generator provides a consistent
structure and approach, even as team members leave the project.
• Abstraction—The architectures of the code generators presented in this book
have the application logic (business logic, database schema definition, user inter-
face definition, etc.) in language-independent definition files. This abstraction of
the semantics of the application from the code that implements the semantics
has profound benefits:
• Engineers will be able to build new templates that translate the logic into other
languages, or onto other platforms, much more easily than the equivalent port
of handwritten code.
• Business analysts can review and validate the design in the abstract.
C# TIFF: How to Use C#.NET Code to Compress TIFF Image File
When you create a TIFFPage with an image source, you can choose the type of image compression you want to use. C# Demo Code for TIFF File Compression.
pdf text box font size; change font size in fillable pdf
C# Create PDF from CSV to convert csv files to PDF in C#.net, ASP.
Description: Convert to PDF/TIFF with specified compression method and save it on the disk. Parameters: Name, Description, Valid Value.
change page size pdf acrobat; change font size pdf form reader
T
HE
CODE
GENERATION
PROCESS
17
• Capturing the application semantics at the abstract level can aid in the develop-
ment of work products outside implementation code. These can include vari-
ous forms of documentation, test cases, product support materials, and so forth.
• High morale—Long projects can be tough on teams, and long projects with
large amounts of tedious coding can be even worse. Code generation reduces
project schedules and keeps the engineers focused on the interesting, unique
work, as opposed to grinding through large volumes of tedious code. In addi-
tion, because the quality of generated code is uniformly high, the engineering
team will have confidence and pride in the code base.
• Agile development—A key feature of generated code bases is their malleability.
We discussed this topic at a technical level earlier; at the business level, this
means that the software will be easier to change and upgrade over the long run.
1.4
T
HE
CODE
GENERATION
PROCESS
In upcoming chapters, we discuss the development lifecycle and how to build a gen-
erator. In this section, we provide a roadmap for the development and deployment of
a generator within the engineering organization.
The sections that follow outline the entire lifecycle of the generator—from assess-
ing the need, to development, to maintenance.
1.4.1
Assessing the need
The first step in getting help is admitting you have a problem. So it is with code gen-
eration. You first need to see the problem you have at hand and then decide if
code generation is the right solution to that problem.
In the case study, the first clue that we needed a code generation solution was the
schedule impact of writing 1,050 Java files. The second clue was the monotony of the
task of writing the Java code. Both of these are strong indicators for using code gen-
eration. If you need a lot of Java files, and writing them is monotonous work, you will
want to generate those files.
Once you have assessed the need, you must decide for yourself how you want
to present the case to engineering and management. You can choose from three
basic strategies: the formal method, the Skunkworks method, and the “my own
tool” method.
The formal method
This method involves turning the generator into a full-fledged project from the
beginning and following whatever process your company has for the design and
implementation of software engineering projects.
The first phase of software design is the requirements phase, in which you gather
information about what the generator needs to do. In this phase, you want to agree
18
CHAPTER 1
O
VERVIEW
on the scope of the work handled by the generator. In particular, you must clarify
these issues:
• How much will the generator do in the first release? The scope should be very
clear on this issue.
• How much will the generator do in the subsequent releases? This will help
define the long-term architecture of the generator.
• For what is the generator responsible? Having clear lines of responsibility will
allow you to ensure that key features are implemented and that extraneous fea-
tures are left out. 
• For what is the generator not responsible? Going through the exercise of catalog-
ing what a piece of software is and is not responsible for is very valuable.
• From an outside perspective, is there anything unusual about what it covers or
does not cover? Make sure you catalog the areas of responsibility that could be
considered unusual to someone just coming into the project.
In addition to clarifying the scope of the project, make sure you establish some basic
goals about the development process for the generator. Here are some points you may
want to clarify:
• How will the generator fit into the development cycle?
• Will the generator go to the customer or stay in-house?
• What style of generation will it use? It’s important to get a consensus on what
type of generator to build. This book will present many types of generators as
we go along.
• How and when will an engineer use the generator?
• Is it a permanent or temporary solution?
• Who will maintain the generator?
• Who is the arbiter of features for the generator?
• Is the first release of the generator prototype code or production code?
• What development tools will be used?
These types of questions have to be answered in addition to the standard feature
specifications.
The advantage of the formal method is that if the project goes forward, it has every-
one’s blessing. The disadvantage is that the generator project may fail through bad
project management, or by having too many features, or by having too little clarity
around the feature set.
T
HE
CODE
GENERATION
PROCESS
19
The Skunkworks method
The term Skunkworks is used when an engineer goes off on her own time and imple-
ments a solution and then returns with it to the team. At this point the question of
deployment and maintenance becomes an issue for the team to resolve.
The value of this technique is the elimination of all external influences from the
process. You think up the project and then build it. If the generator project fails, then
nobody knows but you.
Of course, the disadvantage is that you can frighten or alienate other engineers
or managers, and you may lose your work if they decide not to use your generator.
The “my own tool” method
The directive comes down on high that all your methods must now have X by next
week to conform to the new architectural standard. What do you do? You can either
get typing, or you can make a tool to do the work for you. This is the type of scenario
that breeds the “my own tool” generator.
The my-own-tool method is the same as the Skunkworks model except that, at the
end, the tool remains yours. You don’t present it to the team, because they might say
it shouldn’t be used. As long as the tool is yours, you can use it as you wish, and
nobody will be the wiser.
You may find that you have a perception problem if people find out. It’s not good
being “that nut with that tool nobody understands.”
That being said, there is nothing stopping the my-own-tool generator from
becoming a Skunkworks generator or being promoted to a formal method generator.
All you need to do is tell people about it and do a little educating. 
1.4.2
Laying down the infrastructure
After figuring out what problem you are solving and how you are going to solve it,
the next step is to get your tools ready. This process involves several steps. The most
important is to control and track versioning across the development team. You will
also need to set up a test environment, select the full suite of tools that your team will
use, and communicate those choices clearly.
Ensure source-code control
Source-code control is so important that I will mention it many times. Source-code
control is vital when working with code generators because large blocks of code are
rewritten in the blink of an eye.
Make sure that you are familiar with the command-line interface of your source-
code control system. Also, be familiar with any check-in or checkout automation facil-
ity the system may have. Using the automation facility may be an easy way to integrate
your generator into the development workflow. For example, you could have your
20
CHAPTER 1
O
VERVIEW
documentation generator automatically build documentation upon source code
check-in.
You should also check the Internet to see if a wrapper is available for your source-
code control system. Perforce, for example, has Perl modules on CPAN that give you
access to all of the Perforce functionality through convenient Perl functions.
Build your sandbox
You should use your source-code control system to build a sandbox for the generator
and the code it creates—particularly when integrating a generator into an existing
system to replace existing code. This allows you to run and test the generator in
isolation without worrying about corrupting the main branch and interrupting
anyone else’s work.
Standardize your development tools
If you are using different development tools for the generator than you are for the
application, you will want to spend a little time preparing those tools for deploy-
ment. In particular, you should take the time to create an installation kit with just the
executables and extra modules required to support the generator. Be sure to docu-
ment the installation procedure; nothing kills the enthusiasm of an engineering tool
deployment quite like installation problems.
This also means locking in the version of the development tool you use. You
should look at the versioning of these tools with the same skepticism that you would
an update to your C, C++, or Java compiler. Each compiler, interpreter, or plug-in
module you use should be frozen at the deployment version and then upgraded
with care. 
Buy it or build it
At this point, you’ve laid the groundwork for the development. Now you need to
decide whether to buy or build the generator. 
Buying a generator is not the end of the game; it is just the beginning. First, you
must test and customize the generator against the code you would like to build.
Remember, the generator is just a tool. Because you must assume complete responsi-
bility for the code that it generates in production, you should feel completely confi-
dent about the behavior of the generator and the code that it creates. Also, standardize
the installation of the base package and any customizations that you have made—just
as you would with any development tool you use.
The emphasis of this book is on building generators. This approach provides you
with full control and also allows you to understand what an off-the-shelf generator is
doing for you.
T
HE
CODE
GENERATION
PROCESS
21
1.4.3
Documenting it
Once the generator is finished with its first release, you should concentrate on docu-
mentation. You have to create this documentation regardless of whether you buy or
build the generator.
Two basic forms of documentation go along with the generator. The first is the
architectural document and will be used by the maintainers of the generator. This doc-
ument should include:
• The design goal of the generator
• Pros and cons of the generator approach as it applies to the problem at hand
• The block architecture diagram for the generator (see figure 1.5 for example) 
• Information about the tools used (e.g., versions, links, installation guidelines,
good resources)
• The directory organization
• The format of any input files
• The purpose of every file associated with the generator
• The unit test process
• The installer build process
• Information required to explain the special cases covered by the generator
• Behaviors of the generator that would not be apparent at first glance to some-
one unfamiliar with the generator
• Contact information for the current maintainers
• Known bugs
The second document is aimed at the end user. It describes how the system is to be
used and should address the following:
• What the generator does and does not do
• Installing the generator
• Testing the installation
• Running the generator
• Deciding who should run it
• Determining when it should be run
You should also include:
• A warning about altering the output of the generator by hand
• A graphic that shows the input and output files and the flow of the generation
process
Documents you may be interested
Documents you may be interested