The ArgoPrint project provides support for pluggable templating engines, and currently supports Velocity and XSLT. A similar approach to code generation would make the process of creating templates more approachable by the average developer with a few hours to spare.

The [http://argoprint.tigris.org/ ArgoPrint] project provides support for pluggable templating engines, and currently supports Velocity and XSLT. A similar approach to code generation would make the process of creating templates more approachable by the average developer with a few hours to spare.

ArgoPrint uses a class called DiagramUtils that makes it easier to access elements of the diagram from within the template. A similar set of utility methods would be needed to support code generation templates.

[http://argoprint.tigris.org/ ArgoPrint] uses a class called [http://argoprint.tigris.org/source/browse/argoprint/trunk/src/org/argoprint/util/DiagramUtil.java?revision=327&view=markup DiagramUtils] that makes it easier to access elements of the diagram from within the template. A similar set of utility methods would be needed to support code generation templates.

Another option to consider is to generate code using the MDA standard, possibly with some Action Language for [http://en.wikipedia.org/wiki/Executable_UML xUML/xtUML]. ArgoUML works together with [http://andromda.org/ AndroMDA] to solve the MDA-part. We could go further in this. The funny thing here is, that they use Velocity as their default template engine, e.g. see the [http://galaxy.andromda.org/index.php?option=com_content&task=blogcategory&id=35&Itemid=77&limit=1&limitstart=7 sample templates] in their tutorial, so modeling for AndroMDA is a high sophisticated way to use a Velocity driven generator approach.

Another option is to use a UML model as the template language for code generators. A UML model could contain all information needed to determine a generator, e.g. code fragments (with placeholders) in tagged values. In comparison to Velocity we'd have the following: instead of reading a VTL file and let Velocity create a generator from it, we read some XMI file into some piece of software that creates a generator from it. The disadvantage: we need to develop that piece of software and define a keen UML code generator template profile. The advantage: we can use ArgoUML to model code generators.

== what's going in ==

1. user selection
The user selects elements to generate, for example: classes or packages. If baseclasses are not selected this will result in not compilable code. This is currently implemented and the selected elements are passed to the generator's interface. it's up to the generator to find the contained elements(like methods for a class) to generate.

2. whole project
Activates the generator and the generator decides what to generate by choosing all elements it can handle of the current project to generate code. This is currently available but it works like the user selection by passing a list of elements to the generator.

== how it's going in ==

1. argouml calls the generator with the elements to generate. this is currently implemented.

2. argouml provides access to the model of the current project and the generator traverses through it. this is currently implemented, but intented only to find the necessary elements for generating the selected elements.

3. argouml provides access to(or feeds into the generator) the xmi of the whole project. this would open the way for xslt-based code generators.

== options ==
the generator should provide options to the user to tune the result of the code generation. from the generator side there must not be gui-elements for doing this. there is a mechanism for the generator-side to use descriptions of options, although it's not heavily used yet.

== profiles ==
profiles are a great thing to handle specific patterns. for example, classes to be used with your favourite or-mapper can be stereotyped as this, using a specific profile for that orm. the code generator should be able to recognize these stereotypes.

normally the profile and the code generator are independent things, but if the generator should handle stuff from the profile, it has to know it of course.

== Use Cases ==

=== Class/Class List Generation ===
The user should be able to select a subset of classes to be generated.

=== Project Code Generation ===
The user should be able to generate code for an entire project as specified in the UML model. There are two types of code generation scenarios: straight code generation, RAD environment code generation.

==== Straight Code Generation ====
In this scenario a user selects an output directory, and a template and the generator iterates through all of the class diagrams, and generates classes for each diagram & package found.

==== RAD Environment Code Generation ====
Tools like Rails and Grails use convention, to determine where particular types of classes reside. For example, Grails uses a "$app_root/grails-app/controllers" directory to contain all controllers used in the application, a "$app_root/grails-app/domain" for domain objects, etc.

When generating files for a RAD environment, the tool must know the conventions used by the RAD environment and place the generated code in the appropriate directory.

To create a model suitable for use in a Grails project, the user would:
1. Select the Grails profile which would contain stereotypes such as "Controller", "Service", "Domain", and "Page".
2. The user would create a class diagram (or set of diagrams) to model the domains, controllers and services to be used in the project.
3. The user could create a deployment diagram containing the webflow for the project.
4. The user would select "Generate Project", and the ProjectGenerator would identify the profile being used, and generate the classes in the appropriate directories. The profile would contain tagged values indicating the appropriate directories for classes of a given stereotype. The profile would also indicate which template should be used for classes of a given stereotype.

=== Code Generation for Non-Class Diagrams ===
There are other diagrams for which a user might want to generate code.

==== State Diagrams ====
For example, generating a state machine from a state diagram would be very useful for projects which need to expose state machine rules to users. [http://commons.apache.org/scxml/ Apache's SCXML] project is an example of one such state machine. A user could generate an SCXML file, including JavaScript code directly from a model.

==== Deployment Diagrams ====
It would be useful to be able to generate deployment descriptors for EJB projects from a deployment diagram. It might also be useful to convert a deployment diagram into an application monitoring page in SVG. The user would then be able to monitor the state of the application using a combination of SVG/JavaScript/REST and JMX.

= Design =
["Templated Code Generation Design"]

Introduction

The purpose of this page is to collect the ideas for improving ArgoUML's code generation capabilities. A number of discussions

The current approach to code generation has a number of shortcomings:

The templates are not accessible by users, and therefore not customizable by them. Generated code must often be "processed" to include company file headers.

The templating language is specific to the ArgoUML project and is not likely to be familiar to developers experienced with Velocity and Freemarker.

By exposing the templates, it makes it possible for ArgoUML to more easily support code generation for additional languages.

Ideas

The ArgoPrint project provides support for pluggable templating engines, and currently supports Velocity and XSLT. A similar approach to code generation would make the process of creating templates more approachable by the average developer with a few hours to spare.

ArgoPrint uses a class called DiagramUtils that makes it easier to access elements of the diagram from within the template. A similar set of utility methods would be needed to support code generation templates.

Another option to consider is to generate code using the MDA standard, possibly with some Action Language for xUML/xtUML. ArgoUML works together with AndroMDA to solve the MDA-part. We could go further in this. The funny thing here is, that they use Velocity as their default template engine, e.g. see the sample templates in their tutorial, so modeling for AndroMDA is a high sophisticated way to use a Velocity driven generator approach.

Another option is to use a UML model as the template language for code generators. A UML model could contain all information needed to determine a generator, e.g. code fragments (with placeholders) in tagged values. In comparison to Velocity we'd have the following: instead of reading a VTL file and let Velocity create a generator from it, we read some XMI file into some piece of software that creates a generator from it. The disadvantage: we need to develop that piece of software and define a keen UML code generator template profile. The advantage: we can use ArgoUML to model code generators.

what's going in

user selection

The user selects elements to generate, for example: classes or packages. If baseclasses are not selected this will result in not compilable code. This is currently implemented and the selected elements are passed to the generator's interface. it's up to the generator to find the contained elements(like methods for a class) to generate.

whole project

Activates the generator and the generator decides what to generate by choosing all elements it can handle of the current project to generate code. This is currently available but it works like the user selection by passing a list of elements to the generator.

how it's going in

argouml calls the generator with the elements to generate. this is currently implemented.

argouml provides access to the model of the current project and the generator traverses through it. this is currently implemented, but intented only to find the necessary elements for generating the selected elements.

argouml provides access to(or feeds into the generator) the xmi of the whole project. this would open the way for xslt-based code generators.

options

the generator should provide options to the user to tune the result of the code generation. from the generator side there must not be gui-elements for doing this. there is a mechanism for the generator-side to use descriptions of options, although it's not heavily used yet.

profiles

profiles are a great thing to handle specific patterns. for example, classes to be used with your favourite or-mapper can be stereotyped as this, using a specific profile for that orm. the code generator should be able to recognize these stereotypes.

normally the profile and the code generator are independent things, but if the generator should handle stuff from the profile, it has to know it of course.

Use Cases

Class/Class List Generation

The user should be able to select a subset of classes to be generated.

Project Code Generation

The user should be able to generate code for an entire project as specified in the UML model. There are two types of code generation scenarios: straight code generation, RAD environment code generation.

Straight Code Generation

In this scenario a user selects an output directory, and a template and the generator iterates through all of the class diagrams, and generates classes for each diagram & package found.

RAD Environment Code Generation

Tools like Rails and Grails use convention, to determine where particular types of classes reside. For example, Grails uses a "$app_root/grails-app/controllers" directory to contain all controllers used in the application, a "$app_root/grails-app/domain" for domain objects, etc.

When generating files for a RAD environment, the tool must know the conventions used by the RAD environment and place the generated code in the appropriate directory.

To create a model suitable for use in a Grails project, the user would:

Select the Grails profile which would contain stereotypes such as "Controller", "Service", "Domain", and "Page".

The user would create a class diagram (or set of diagrams) to model the domains, controllers and services to be used in the project.

The user could create a deployment diagram containing the webflow for the project.

The user would select "Generate Project", and the ?ProjectGenerator would identify the profile being used, and generate the classes in the appropriate directories. The profile would contain tagged values indicating the appropriate directories for classes of a given stereotype. The profile would also indicate which template should be used for classes of a given stereotype.

Code Generation for Non-Class Diagrams

There are other diagrams for which a user might want to generate code.

State Diagrams

For example, generating a state machine from a state diagram would be very useful for projects which need to expose state machine rules to users. Apache's SCXML project is an example of one such state machine. A user could generate an SCXML file, including ?JavaScript code directly from a model.

Deployment Diagrams

It would be useful to be able to generate deployment descriptors for EJB projects from a deployment diagram. It might also be useful to convert a deployment diagram into an application monitoring page in SVG. The user would then be able to monitor the state of the application using a combination of SVG/?JavaScript/REST and JMX.