Introducing Active Code Templates

Overview of Active Code Templates

Active code templates (ACTs) are used to implement and/or customize advanced code generation from a UML model.

This chapter covers the concept of code generation using the ACT engine, the syntax of templates, type libraries and other elements, and common techniques used to make the most of the flexibility and customization capabilities of the ACT engine.

ACT concepts

Code generation using Active Code Templates is based on the following concepts:

· Generation session: The user initiates a generation session, either requesting the generation of code for a PTM (Project & Target Management) project that manifests a number of model elements such as packages and classes, or requesting the generation of code for a particular element (using the context menu).

· Generation products and product definition file: For each particular model element being processed, the product definition file is considered. This XML file contains the definitions of the generation products that should be generated for a particular type of model element. A typical generation product is a file whose contents are based on a certain template. Another common type of product is a subproduct, which is basically an instruction to navigate to some other model elements (typically owned by the current element) and to repeat the product generation process recursively. For more information and an example of a product definition file, see "Product file syntax".

· Active code templates: An active code template (ACT) is an XML document, similar in concept to ASP/JSP. It generally follows the text that needs to be generated, with injections of control markup that drives the navigation through the UML model, extraction of the information from it into the result text, looping, and so on.

Active code templates can refer to each other, include each other, and contain symbolic macro definitions (thus improving clarity), as well as numerous other advanced capabilities. For information on the syntax of templates and an example of a simple active code template, please see "Template syntax".

· Template libraries: Templates are typically organized into libraries, which allow the referencing of a template by its symbolic ID, as well as the overloading of templates with the same names in different libraries, and other advanced capabilities. A file generation product defines which template to use for the file contents by referencing a template ID. Similarly, a template can include another template, referencing it by its ID. The template with the requested ID will be searched for in the current library path, which can be dynamically controlled during the generation process. Typically, a PTM project defines the default library to use. This can be overridden on each model element level. This way, certain templates can have different definitions in each library, and can be overridden for each model element during the generation session.

· Anonymous templates: In some cases, a template can be created on the fly and used without an ID (for example, a UML note whose content is interpreted as an ACT), or can be a part of some higher-level entity (for example, a type definition).

· Compilation of templates: The XML representation of an ACT is compiled into a form of J language script, which navigates the model, extracts the required information from it and concatenates it with the text from the template, thus forming the resulting text. The compiled J code of the templates is cached in the memory, and can be dumped into files for debugging. Templates also allow the direct injection of J code into their constructs.

Besides the named templates, ACT libraries can contain several other kinds of entity, namely type definitions, mappings and patterns. These elements also have IDs that are unique within a library, and can be overridden using the same mechanism as the templates.

· Type definitions: A type definition is an XML document that contains additional meta-information for better translation of UML constructs to respective programming language constructs. A typical example is the translation of a UML type into a programming language type. The type definition mainly contains a type expression template that can be used to declare variables for the type in question, as well as several important meta-attributes that are used during generation to find the best matching representation (type definition) for a UML construct, based on its multiplicity and other more advanced characteristics. For an example of an ACT type definition, please see "Type definition syntax".

· Mappings: A mapping is an auxiliary entity, which allows different kinds of associative transitions to be defined. For example, a mapping can be used to associate each type of model element with the ID of the template that should be used to preview code.

· Patterns: A pattern is a "model-level template", in other words, an entity that defines how a UML model should be transformed, with a given element as a starting point. A typical example of a pattern application is the automated creation of constructors for a class, or the automated creation of accessor operations for an attribute.

Currently, ACT patterns are supported in the form of J language scripts. For an example of an ACT pattern, please see "Pattern syntax".

· Template libraries, type libraries and platform libraries: Though any ACT library can contain any of the elements described above, ACT libraries are still classified according to their primary purpose.

A template library contains mostly named templates that form the "basis" of the code being generated.

A type library typically contains type definitions (for example, corresponding to a certain general-purpose library that exists for a programming language) and overrides a minimum of "core" templates where necessary, in order to integrate the library more smoothly.

A platform library typically overrides a required minimum of templates, types and mappings to customize generated code for a certain compilation platform (for example, MS VS or gcc, …).

This classification is also important for the ACT engine UI, which basically allows you to choose a template library, a type library and a platform library separately, before forming a library path from these three elements. For an example of a library definition, please see "Library file syntax".