Google

Application Generators

Abstract
Rapid Application Development (RAD) is the need today. Many automated tools are available for this
purpose. Application Generator is one such tool. It reduces the application development time, besides
other advantages. In this paper, design considerations of an application generator are discussed. In the
end, case study of application generator for High Level Architecture (HLA) based simulations is presented.
Keywords: HLA, RAD
1 Introduction
An application generator is a RAD tool. It not only generates source code but
also provides facility to build (compile and link) and execute the generated
application. An application generator may either be generic or may relate to
particular domain. Most of the application generators fall into later category.
The following sections bring out the need and advantages of an application
generator. This is followed by design issued involved and implementation
issues are highlighted using case study of an application generator.
1.1 Need and Advantages of an Application Generator
The application generators offer following advantages:-
1. Being a RAD tool, the application development time is considerably
reduced. This increases throughput and productivity.
2. The generated code is less error-prone compared to manual writing of
code.
3. It saves the developer from tedious routine programming.
4. In some cases, it saves the developer from having expertise in particular
domain. For example, if application generator generates code
corresponding to usage of particular Application Programming Interface
(API), then developer may need not know the API in great depth.
He can concentrate mainly on application logic.
5. Developer need not know the intricacies of compilation and launching
process.
The need of an application generator can be judged from the above cited
advantages.
1
2 Design of an Application Generator
The main issues are the areas which needs application generators, customization
parameters, templates design and application building. The subsequent
paragraphs address these issues. a) Areas requiring Application Generators
As obvious, the intended areas are those which have fixed and well-defined
solution to a problem. So, the code can be automatically generated for these
solution steps. b) Customization parameters Basically, these are the identified
parameters to be taken as user inputs. Essentially, these inputs should
satisfy following criteria: i) The number of user inputs should be as minimum
as possible. ii) The inputs should be specific to task for which code generation
is required. iii) The inputs should not be ridiculous. iv) It should have
proper labeling, data-type and range. It may also have default values as well.
v) They only serve the purpose of customization of underlying templates.
c) Template Design This task involves identification of design-pattern of
the application. Design-pattern means the steps required to solve a particular
problem. The templates should have well-placed and well-marked containers
for user input substitution i.e. the part of templates that will be replaced by
user-inputs. d) Code Generation The inputs fed by user and the appropriate
templates become the source for code generation. The task involves fitting
the user-input into the template and generating the code in a programming
language. The generated code should have meaningful comments which will
help the application developer in later stages. e) Extending and Building the
Generated Code The developer should be able to add application-specific
code to the generated code. He should then convert this source code into
executable one and launch the generated application from within the application
generator itself.
3 Implementation Issues
While implementing the above design, following considerations must be taken
into account:- a) Portability: If application generator is needed to be portable
then Java is most preferred programming language. Java uses the concept
of byte-codes and is an interpreted language. So, Java programs run both
in Windows and Unix-Variant environments and on both RISC and CISC
processor based systems. b) Targeted Language: This is the language in
which source code is generated by application generator. The choice entirely
2
depends on the particular application. An application generator should generate
code for more than one language. This requires templates to be provided
for all supported languages. c) Code generation Strategies: Broadly
speaking, all code generation strategies employ ”if-then-else and find-replace”
paradigm. More specifically, these strategies are: i) Hard-coded approach:
The code to be outputted is hard-coded into the source code of application
generator itself. The approach is simple and straight-forward but has following
disadvantages:- * Code maintenance is difficult * Usually, supports
one target language only. ii) Template-based approach: The code to be outputted
(called template) is separate from the code of application generator.
The code is generated as a modification of template as per user input. It
has following advantages: * Code maintenance is easy * Can easily support
multiple target languages. And the disadvantage is: * Overhead of reading
template files. But this is not a significant problem. iii) Visual application
design: The customization parameters are in form of so called components
or controls. The developer chooses the available controls, interconnect them,
set their properties and attach callback functions. The code is then generated
in accordance with the visual design. The main advantage is: * Appealing to
model the application visually And disadvantage is: * May use proprietary
software solutions like Java Beans and ActiveX technologies.
d) Extending the generated code: The application generator must implement
a minimal source code editor. It should have support of basic editing
operations like copy, cut, paste etc.
e) Building and Launching the Application: The implementation language’s
feature of calling system commands should be efficiently exploited.
To build an application, invocation of appropriate compiler is required. Any
error in build process must be provided to the developer in meaningful manner
and should indicate possible cause and solution of the occurred error.
f) Configurability: The implementation of an application generator must
have configurable feature. Some of the configurable parameters are: i) Choosing
directories like where to place the generated code. ii) Target language in
which output source code is required iii) Path and name of compiler to be
used g) Installation: Ideally, should self-extracting installation executable.
The installation process should create different directories to put the code
into. Facility may be there to add it to Start Menu, Desktop and Quick
Launch Bar. Third-party freely available software can be used for this purpose.
The application generator may provide the facility to wrap the generated
application into an installation executable.
3
CASE STUDY: HLAAppGen - Application Generator for HLA based
simulations
First a brief introduction to HLA is given. This is followed by the design
and implementation of the application generator. Main issues discussed are
the implementation of design considerations described in preceding sections.
Overview of High Level Architecture (HLA) HLA is a framework for integrating
distributed simulations. The standard was initially proposed by US
Department of Defense and later standardized by IEEE as standard 1516.
The main aim of HLA is reusability and inter-operability of simulations irrespective
of their development and execution environments. The HLA terms
used in this paper are defined below: Federate: Any HLA-complaint simulation
Federation Object Model (FOM): This is description of all the data
exchanges that are going to take place among different federates Run-Time
Infrastructure (RTI): Support software that provides communication between
federates Federation: Federates, FOM and RTI constitutes a federation To
achieve the aim, HLA specifies following six groups of services:
Service Functionality Federation Management * Creation & Destruction
of federation * Join and Resign of federate * Save and Restore synchronization
points Declaration Management * Publish data for other federates *
Subscribe to required data Object Management * Creation and Destruction
of objects * Attribute Update and Reflect Ownership Management * Allows
sharing of an attribute among federates * Follows principle of mutual exclusion
* PUSH or PULL ownership technique is used Data Distribution Management
* Refinement of Declaration Management Service * Receiver federates
receive only particular instances of interactions (transient messages) or
attribute updates * Thus provide reduces unnecessary network traffic Time
Management * Time co-ordination among participating simulations
Need of Application Generator for HLA based simulations HLA is new
technology and hence like other fields requires automated tools. Application
generator is one of the obvious choice. Moreover, the RTI software provides
an API of functions implementing HLA services. Also, there is a well-defined
fixed procedure of HLA-complaint simulations. So, code for this can be
automatically generated. Finally, we get all advantages mentioned in earlier
sections. Although the application generator developed by me supports all
six group of services but here only the essential Federation Management and
Declaration Management code generation is illustrated.
Customization Parameters For Federation Management, the identified
user inputs are:- a) RTI Host - Hostname where central component of RTI is
4
running b) RTI Port - Port to which central component of RTI is bind c) RTI
Type - To support multiple RTI (US DoD and IEEE standards) d) FOM File
- Name of the FOM file used e) Federation Name f) Federate Name These
inputs are fed through Graphical User Interface (GUI)
Template Design The main steps in HLA-complaint simulation are: *
Create federation * Join federation * Publish data * Subscribe data * Process
and send published data * Receive and process subscribed data
The template is basically source code for above steps in target language.
There are templates for both HLA 1.3 and HLA 1516. The target language
is Java.
Code Generation Earlier mentioned ”if-then-else and Find-Replace” paradigm
is adaopted. The template code is modified as per user input. Suitable comments
for developer are inserted and the final code is written into a file with
its name corresponding to federate name.
Extending the generated code The generated code is written into a file
and same is shown in source code editing area of the application generator’s
main GUI. Basic editing operations like cut, copy and paste are implemented.
For this Java Swing and Abstract Window Toolkit (AWT) are used.
Building and Launching the Generated Application The source code can
be compiled and application can be launched through menu items of main
GUI and also through shortcut buttons. javac ¡filename.java¿ and java ¡filename
¿ commands are executed internally. The application generator captures
and shows the messages related to Build process to aid the developer
to check and correct if any bug is present.
Other Features Time-stamping: The generated code contains time-stamp
by putting the system time at the time of code generation at the beginning of
the generated code. Version Control: For managing different versions of same
application. Successive numbers are appended to filename to keep different
versions. Launching RTI: Federation execution needs RTI software to run at
first. This can be launched from within the application generator, thereby,
saving the user from knowing how to start RTI.
5