Summary of the EEL Compiler Project using Demeter/Java

Within the SIGS project at GTE Laboratories, there exists a subsystem
in charge of mapping a high-level language description of hundreds of
validation rules into C++ code that fits a validation engine
framework. This high-level language is called EEL (Edit Engine
Language) and the compiler for it EELC (EEL Compiler). This report
describes the results of using Demeter/Java and adaptive object
oriented programming to implement the second iteration of EELC (a
complete rewrite).

The first iteration of the EEL Compiler project took us about 5
man-months to complete. Traditional programming tools & languages were
used. More specifically, C++, Lex/Yacc. The resulting system consisted
of approximately 2300 lines of code split in 12 different files. This
iteration was deemed to be succesful and was completed by two
experienced software engineers.

The second iteration of the compiler was done using adaptive object
oriented programming and the Demeter/Java system. One experienced
software engineer (trained mostly in C++) was assigned to the
project. No previous knowledge of Demeter was present. The second
iteration of the process took about 2 weeks to complete, including the
time required to install and learn how to use the new tools. The new
system consists of about 1000 lines of code split into only two files
(.cd and .beh). Furthermore, the code generated by the second
iteration of the compiler is substantially more complex than that of
the first iteration.

Execution time, as expected, grew substantially. There are several
reasons for this phenomenon. First, the first iteration of the
compiler is a native binary image and the second is compiled to Java
bytecodes and interpreted. Secondly, no optimization whatsoever was
attempted on the second iteration of the compiler. As a matter of
fact, no reorganization of the code was done at all, in hopes to test
the true adaptability of the approach. Sure enough, the development
time fell abruptly but the resulting compiler is slower than
necessary. It is expected that a careful redesign of the system would
bring the execution time down substantially.

The adaptability of the system was put to the test in different
occasions. The original design was changed after the first iteration
and the class structure was modified. Later on, a rather major
overhaul took place to replace relatively 'lazy' code generation
(ie. relying on microcode) for 'working' code generation. Last, an
optimization was necessary to reduce the runtime of the generated
code. It is at this latest stage when the biggest execution time
penalty was introduced, as several subtraversals were reused over and
over. This optimization (on the generated code) was almost trivial to
implement (less than an hour) but increased the execution time two or
three-fold.

In conclusion, the use of Demeter/Java allowed us to drastically
reduce development time and resulting software complexity. Considering
this was our first encounter with adaptive programming, the results
seem even more impressive. It is important to note that this project
fit Demeter/Java's target audience almost perfectly. Demeter/Java's
automatic parsing capabilities were a bonus for we almost did not have
to write a parser. Furthermore, generating code is by definition
moving around in a parse tree and, for this task, Demeter's
"traversals" were priceless. Demeter's perceived inefficiency in
execution time might be the cause of the programmer's lack of training
in proper adaptive programming. 

For more detailed information, visit:
      http://www.blando.info/luis/eelc/

Luis Blando 
Principal Investigator
GTE Laboratories
November 1997