Background
Information
Generative Programming – From Theory to Practice
|
Here you will find the following Information:
|
|
|
Abstract What does
Generative Programming mean? Fundamentally, the usage of software in order to design software is apparent. On the other hand, fully automatic generation of entire application systems cannot be achieved in a short-range; moreover, it seems to be implausible to be attained in the future as well. Below this high demand, many potential variants of tools are imaginable that are able to create software systems and components in a more or less automatically manner. The automation of software production is not only to serve the speeding up of software development and the reduction of the development costs; it furthermore improves the quality as well as it causes less error liability. Finally, yet importantly, maintenance expenditure and the costs resulting from it will be also reduced. Of course, these considerations aren't new, but somehow in between, the idea arose, that the usage of object-oriented techniques became superfluously. Anyway, on the one hand, the object-oriented programming triggers off, if used correctly, a higher degree of abstraction but, on the other hand, hardly provides automation. This can be verified e.g., in the widely spread design pattern by Gamma [GHJV 95]. They became a de facto standard for most of the OO- programmer and it can be assumed, that they are used thousandfold. But what its really about is the question, how can this innovative and challenging principle be implemented in individually? Hardly ever by the usage of tools and, for sure, the object-orientation itself does not provide any help. The preferred tool is still CPA (copy-paste-adapt) – this is downright barefoot software development. Hence, it does not astonish anyone at all that throughout the last few years the concepts of automated programming became increasingly significant.
|
|
|
The basic idea is represented by the following quotation [CE99] in an utmost simple manner: The automation assumption: In this context, the term Generative Programming (GP) arose for the first time about five years ago. Last year, the same-named book by Czarnecki and Eisenecker was published [CE00]. |
 |
|
GP is considered to be a new paradigm in software development that does not compulsory compete with the current paradigms, especially with the object-orientation, but supplements them. Besides the automation of software development, it is mainly the realisation of software families, which is in the focus of the contemplation. Conventional development is about developing components or even entire systems with similar characteristics individually. For the most parts in these cases, there is only the previously referenced, ancient CPA method available – even on design level. On the contrary, the GP principle assumes that it is possible to generate the members of a system family, namely on the base of a common model of the system family, the Generative Domain Model. This model consists of three elements:
This is similar to ordering a car: There is an order form to purchase a car, components from which the car is assembled of and somebody who knows the way the car can be built as per order. Instead of the term system family, the term product line, which is of slightly different meaning, is being used as well. This difference is not relevant for the considerations presented in here, so the term product line might likewise be used. Modelling and specification of system families is processed with techniques such as Domain Engineering, Feature Modelling and Domain Specific Languages (DSL's). We will not go deeper into that here. The realisation of the modules and the implementation of the configurations, i.e. the transcription of the specifications into software systems and components requires adequate generative tools. The concept of a new generator tool, resp. of an entire tool family and the experiences gained with it will be presented subsequently. The Generator
Principle There are many different ways to realise this within a concrete generator. Many generators are specialised for particular tasks. For example: GUI Wizards, DBMS pre-compilers or UML transformers. These generators work highly efficient in their areas of responsibilities. On the other hand, due to their specialisation, they are not very flexible and cannot be adapted to individual tasks, which on the other hand is one main condition for the GP.
|
|
| Another generator approach are macro processors or template mechanisms in compilers. They are a sort of "Do-it-yourself" generators with high flexibility, that attributes to their principle; but without any individual intelligence, which causes a great deal of usage expenditure. |
 |
|
In addition to this, there are generators that are a combination of those two principles. They comprise pre-defined specialised core functions for various task designations on the one hand, and are individually extensible by macro modules on the other hand. Delta Software Technology used this principle for its generators ever since.
|
 |
|
With the intention of being successfully used in a GP environment, real innovative generators have to comprise even more efficient performance. ANGIE - A New
Generator Engine A Frame-Based Generator Architecture
|
|
| Delta Software Technology already used this standard on programming languages ten years ago. For instance, the Y2K problem was tackled with tools based on this technique. Extensive program systems have been examined and corrected – amongst them were programs with hundreds of thousands (!) code lines. Some other time interfaces of legacy applications have been interpreted and converted into object-oriented implementations automatically. |
 |
|
Frames are code fragments, similar to classes and objects in object-oriented languages. Any number of copies (instances) can be created and being modified as well as being stored in a repository in the course of the generation process. Slots within the frames receive names or variables and additional sub-frames. This leads to tree structures, alike abstract syntax trees, with any depth and complexity. They can be created, evaluated and modified by generator scripts. These scripts do only have to know the frames and frame variables; the content of the frames (the code fragment) is usually invisible for the scripts. During the final export, the abstract memory and repository contents will become concrete source code. In general, it is sufficient to exchange the frame definitions in order to support another programming language by the usage of the same set of generators and scripts. The Extensible Generator Language
The script language is realised as an "embedded language". This means for instance, script instructions recognizable by a particular flag, can be interspersed into the coding of the target language without the constraint of altering it. Besides, a special editor available identifies the ANGIE constructs and displays the difference between script and target language chromatically (see also figure 4). As a distinction to ordinary generator systems there are not two different languages for the development of the core functions (generators or processors) and for the configuration and adaptation (macros, templates and the like) required. The script language is both: uncomplicated and powerful so it can be used for all levels equally. As a result of compiling the ANGIE scripts, a loss of performance is being avoided right from the very beginning. In cooperation with the University of Paderborn, an efficient compiler has been developed. It runs so fast that it compiles most of the scripts just-in-time. In addition to prefabricated generators, being created from compiled scripts and also pre- defined standard scripts, which can be adapted to the individual projects, you are of course provided with the possibility to supplement any individual scripts to the projects as well.
The Generator Technique as a Component
|
|
|
In comparison, ANGIE was designed as a real component that can be integrated into any other tools such as interactive design tools. Hence, the generation function is considered as a service, which can be called on demand whenever there is something to be compiled. This enables a successive and sectional software development, perhaps hidden below an interactive user interface. |
 |
|
In combination with the possibility to differentiate between construction and final code production that arises from the frame architecture, a new more up-to-date process scheme is being created:
The XML Repository Basis All current tools of Delta Software Technology use an XML-based repository format. The XML standard enables a smooth exchange of data. Furthermore, there are plenty of tools for evaluation and modification obtainable. The XML interface of ANGIE admits the inquiring of information from the repository from the scripts directly and to modify and create them. Practice Yet, with the previous tools of Delta Software Technology in particular large-scale users and software houses created extensive systems for a configurable and individually extensible application generation. This led to the realisation of real product lines and system families even tough these terms were not familiar at the time of the creation of most of these applications. A noteworthy challenge for the new generator technique was the conception of the Generated Adaptive Frameworks architecture and their realisation within the integration tool SCORE Integration Suite. |
|
|
Central element of the adaptive framework is a layer architecture with strict separation between the necessary semantically and syntactically mappings on the one hand, and the linkage to middleware, system and language platforms on the other hand. The modules of this framework are generated; on the one hand as separate layers, on the other hand as an implementation of technical aspects to be woven into those layers. The generators were realised with ANGIE and have been afterwards integrated into an interactive tool, the Component Manager. An XML repository serves as the information memory (see also "The XML Repository Basis"). The principle of a generator as a service, as expounded in section "The Generator Technique as a Component" is also used in here. The generator functions are centrally controlled by the Component Manager and assist, amongst others, for example: |
 |
|
|
|
The generators may be supplemented by scripts in an almost unlimited way and, as well, be adapted to the individual requirements. SCORE Integration Suite, being used in various extensive projects since last year, proves its reliability especially while being used in combination with current object-oriented and component-based technologies like Java, J2EE and EJB. |
 |
|
Result and Prospects Just a few years ago, terms like Generative Programming, System Families and Product Lines were only familiar to a small number of software specialists. Meanwhile, these subjects are a permanent part of high-ranking events such as this year's OOP in Munich or of the CDUF in Frankfurt. Nowadays, numerous enterprises deal with GP. Concurrently to the theoretical and methodical discussions, tools are being designed that help to realise the latest innovative ideas practically. One example is the new generator technique ANGIE provided by Delta Software Technology. This doesn't mean we've already reached the end of the road but a first important step was done. Primarily it is to be pointed out, that this technique has proven itself within various important projects. |
 |
|
Several further developments are based on these
results. Initially it is about supporting the modelling process for system
families, e.g. by editors for Feature Models. To that end, there is an active cooperation with the
University of Applied Sciences at Kaiserslautern.
A beta version of this tool is already freely
available. Literature |
|
