• The Code Generation Dialog

The Developer Edition of Poseidon offers the possibility of adapting the templates used for code generation, allowing you to modify the formatting of the generated code. You can easily change the indentation, the signature format, the sequence of items in the generated code, etc. For further information on the template language, please refer to the Velocity documentation.

It is also possible to create your own code generation templates and add these to the system. Poseidon can then generate code using your custom templates instead of the standard templates. This way you could generate entirely different types of code such as XML, JSP, RMI stubs, etc. Adding a new template involves creating a Plugin that registers the new template with Poseidon. This is described below.

Another way - perhaps the most powerful way - of adapting the code generation process is to customize the Preparation stage. This is achieved by modifying or extending the code generation framework. By doing so, you can feed Velocity with different data, using the full power of Java and all the information of the UML metamodel.

Code generation is split into a preparation phase, a checking phase and a generation phase. You may have noticed: We simplified our approach earlier on when we stated that code generation consisted of two phases, preparation and generation. Technically the checking phase is part of the preparation, however, and you can only modify the checking phase by changing the classes used for preparation. For clarity, we will describe the checking phase separately here, but we will abandon this distinction later on.

In the preparation phase, one prepared element is created for each selected model element. The preparation is delegated to the corresponding ElementPreparator. The element preparator knows which preparation class to use for which model elements. A prepared element is a container for a part of the element's information. It is called a prepared element because it can be used directly by the templates, by simply reading out values and inserting them into the templates in the right place. Using this approach, the template itself can be kept much simpler, because part of the logic (esp. navigation through the model) can be done in the preparation classes. The templates can focus on layout and structure instead of string formatting and iteration through UML model elements.

In the checking phase, the prepared information will be checked for consistency. This phase is also delegated to the ElementPreparator. Error messages will be written to the dialog. Checking is based on methods of the prepared elements.

In the generation phase, source code files for each choosen model element will be created, and the context for the template interpretaion will be filled. The Generator creates the new files, retrieves the prepared elements, and adds them to the context. Last not least, the interpretation of the template is started: all placeholders in the templates will be replaced by information from the prepared elements or directly from the model. If the option to compile the generated code was choosen, a call to the specific compiler, along with all the files to be compiled, is generated and processed. Any occuring error messages will be displayed in the CodeGenerationDialog.

Within Poseidon you start the code generation process by calling up the code generation dialog and selecting the model elements for which code is to be generated.

In this dialog, the current project model is represented as a tree with nodes for the contained elements (packages, classes, interfaces). Each element can be checked or unchecked to determe whether code should be generated for it. Packages can be checked or unchecked completely.

Below the tree are a number of settings that can be used to specify the code generation process:

• Compile generated source: Check this option if you want to compile the code after it is generated.

• Clear destination directory: If you check this option, the target directory will be cleared of any files that do not belong to the current project. You will be asked for confirmation before the files are deleted - nevertheless please be cautious when using this option. Please note that the code for unchecked model elements will not be deleted, only code that is not useful for the current project at all.

• Language selection: Choose the target language (and language extensions) you want to generate code for.

  The list of available languages and language extensions will vary depending on the plugins you have installed. A language extension is a plugin or an enhancement for an existing language; every language extension will show a check box or a radio button below its language. The code generation dialog shown above has the OCL-to-Java plugin enabled. This plugin provides the language addition of OCL constraints to Java, so that it is possible to enhance the generated Java code with additions for executable and testable OCL constraints. (When you write a language addition for Java code generation, or write a plugin for a new language, you should insert your check boxes here; how to do this is described below.)

• Settings: The Settings button opens the code settings dialog for the chosen language. You can set certain properties here, depending on the language you have choosen. For example, the settings dialog for Java has a tab "General" containing the used classpath and the Java compiler to be used if you compile the code directly. There is also a tab for every language extension installed for the chosen language. The possible entries in each tab, as well as the number of tabs, will vary depending on the language and the enabled language extensions.

  A custom language extension can design its own tabs for the settings it requires, and insert them here. How this is done is described below.