Integrating source code generation into a project

1 Reusability

IT people is convinced about the importance of reusability, which is applied to designs, source codes, technical and functional components:

Some points are relative to the concept of reusability, considering the capitalization of skills, the IT knowledge, independently of the Business, but have no satisfying answers today:

CodeWorker proposes an answer for each of these points.

2 The interest of controlling the format of the design

The first interest of controlling the format of the design is to be able to acquire data into the source code generator obviously.

The second one is to allow adapting a modeling language to specific needs. It may be to enrich a UML (Unified Modeling Language) design with some features that are necessary to a better mapping to implementation, if you consider that UML isn't expressive enough to allow a source code generation as fine as expected and not depending on the target language. Today, thanks to Rational ROSE, some more detailed information can be added to an UML design, but they are depending on the target language. For instance, if a method's parameter has to be given by reference, the designer has to know that he wants to generate C++ and then, he writes std::string& explicitly as the correct translation. Then, the design cannot be taken out for a JAVA code generation after. Finally, there is a strong dependency between the design and the language which will be used for generation.
So, some extensions might be brought on UML for remaining free from the choice of the target language:

The advantage of enriching UML is that one can draw the design into a modeler, under RATIONAL Rose for instance, and to put extensions into. It becomes less readable and the project cannot be generated with the modeler anymore, but classes and relationships are built and displayed in a very convenient way. Of course, the design's file must be readable by CodeWorker and that's the case for "*.mdl" files, which are produced by RATIONAL Rose (This isn't advertising!). See the script repository on for taking the adapted parsing script back.

If the readability has suffered too much of adding all these features in a graphical modeler or if the data you want to handle are far from a UML representation, you can develop your own modeling language or to adapt one of those proposed into the script repository.

Just a point to notice: we don't care about the syntax of the designs to parse, but the structure of the parse tree is very important to warrant the reusability. So, if you want to improve a modeling language provided into the script repository, be careful about changes you'll made on the parse tree. Adding new attributes on nodes have no impact on the existing generation scripts, but removing or renaming some attributes of the parse tree will change the generated text (some expected attributes will not be found).

So, an effort must be made to document as much as possible the structure of the parse tree, to avoid diverging, so as to allow the reusability of your work or to reuse the work of somebody else.

3 Driving the implementation with CodeWorker

CodeWorker provides a scripting language where the syntax is adapted for parsing and code generation tasks. It proposes an easy way to navigate along parse trees too. These three main aspects allow both acquiring data and generating any kind of free text in a very convenient way (adapted syntax and data structures).

CodeWorker offers some basic functionalities for handling files and directories, which avoid using shell or Perl scripts, while building development/test environments within a team for generating/compiling/debugging/sharing source code. The data structure of tree and the foreach...cascading statement (see foreach) provide a very convenient way to visualize/navigate along directories.