Java Code Generation

By using a simple mapping from UML model elements to Java fragments, Java sources can be generated automatically from the model.

The mapping
In case of Java the following obvious simple mapping is used: and so on. That's used by the code generation feature for now, when traversing the model tree.
 * map UML packages to Java packages
 * map UML classifiers to Java classes and interfaces
 * map UML attributes to Java class member variables
 * map UML operations to Java methods

Template-based code generation
The purpose of the Template-based code generation framework is to provide users with an easy-to-use, customizable means of generating code from ArgoUML models.

Requirements
The code generator should:
 * Allow users to use a default set of language-specific templates for generating code (which ship with ArgoUML).
 * Allow users to specify a common code header, without having to modify the templates themselves.
 * Allow users to clone the default argouml templates, to create their own customized versions of the templates.
 * Allow users to specify some common shared directory, or web server where code templates will reside.
 * Allow users to easily modify the templates through an editor (without having to leave ArgoUML to edit the template).
 * Allow users to generate Test Case stubs for classes.
 * Allow users to generate code for specific types
 * Support the generation of classes that use enums, annotations, generics.
 * Support the generation of projects which use specific directory structures. In Grails, for example, you want to be able to designate that classes with a <> stereotype are generated in the project/services directory; classes marked as <> should be generated in the project/controllers directory, etc
 * Support the use of Lists (not Vectors) as the default mechanism for aggregation. Perhaps this could be specified in the aggregation line itself between two classes.
 * Support the generation of javadoc comments when generating java code. This means support for @params, @author and other annotations in a comment block.
 * Minimize the amount of work required to support a new language. There should be a minimal number of templates that a user must modify in order to support a new language.
 * Allow users to generate code for the classes on a diagram, or in a package, in addition to generating classes for the entire project.
 * Provide progress feedback when generating the code.
 * Support a pluggable templating mechanism. If the user feels that they want to use Freemarker instead of Velocity, they should be able to plugin a new templating engine.