Login | Register
My pages Projects Community openCollabNet

argouml
Wiki: Diff for "Ideas for improving code generation"

Edit this page | Links to this page | Page information | Attachments | Refresh page

 

Differences between revisions 15 and 16 (spanning 2 versions)

Deletions are marked like this. Additions are marked like this.
Line 25: Line 25:
  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.   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.
Line 28: Line 28:
  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.   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.
Line 77: Line 77:

= 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

  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.