Rearchitecting or rebuilding existing applications with code generation
may happen for several reasons, such as changing part of the
original technology or adding a new architectural layer.
Independently of the reason, in most cases a key requirement
concerns the existing databases: if their performance has been
satisfactory, it is required that they be used without changes as
the foundation for the new or rearchitected applications.
In some cases, a project of this kind also provides an
opportunity for rearranging the architectural style originally
applied, and to build a new model that extends the expected life
span of the applications.
This article describes a model generation scheme
that allows model architects to
effectively acquire knowledge and gain control of existing
The analysis of the intermediate CSV files and the new or extended
architecture provide the guidelines for the second stage of model
generation. These guidelines have been realized in our case in the form of
Tefigel scripts to be applied on the CSV files. Outcome of
these scripts can be XML, EF (Somusar Entity Files - see
examples), or both.
If the software generator chosen for the actual development
project is SoProMach, as in our case, then the obvious choice
is EF, that provides robust type-checking and flexible entity
aggregation mechanisms. But XML is an excellent metadata exchange
medium, so in our case it was decided to generate an EF model,
and export XML metadata from EF at software-generation time.
The numbers in the figure correspond to the steps described
below. Steps 1 to 7 (continuous lines) are project-independent;
steps 8-10 (dashed lines) are project-specific.
The Model Architect runs the desired metadata extraction job on the desired schema(s). Note that the Model Architect could be an automated tool;
SoProMach generates on the fly a set of scripts, similar to the queries that an Oracle DBA would type into a SQL*Plus console;
SoProMach submits each script to SQL*Plus;
SQL*Plus interacts with the RDBMS and retrieves the metadata;
The raw metadata is written by SQL*Plus into a set of text files;
SoProMach parses the raw metadata, understanding the required amount of SQL code output by SQL*Plus; note that steps 2 to 6 are automatically repeated to fetch metadata about tables, views, and stored procedures (and possibly more);
The interesting part of the metadata is rearranged and stored into CSV files;
CSV files can be examined and analyzed by the Model Architect as plain spreadsheets, or processed by record-oriented tools such as "awk";
Depending on the project target, the Model Architect runs SoProMach to generate new software, or to produce a new model (XML, or .ef, for instance) for later processing;
According to the target of step #9, SoProMach transforms the uniform metadata into more complete metadata, or directly into software.