View source for JET FAQ Should I write my JET code generator directly against UML2?

= Question =
I understand the JET can read UML2 models. Is it a good practice to do this?

= Answer =
We think not. The reasons:
* Code generators (at least JET-based code generators) work best with models tuned to the structure of the output (you could call this an Intermediate Model). Things like 'flattened' package structures, and simplifications of UML constructs (have you ever looked at how UML handles documentation of an Element) are common.
* Often, an Intermediate Model is developed 'bottom up' from the artifacts that need to be generated. In our experience, all but the most UML literate have trouble mapping code generation requirements directly to UML. Indeed, there are often multiple validate representations.

== Recommendation ==
To turn this around, this is the best practice we recommend:
# Separate the concerns of code generation from the concern of representing the code generation abstractions to the user.
# Create a code generator specific 'Intermediate Model' that represents concepts needed to produce the desired artifacts. 
# Build a JET transformation that consumes this model. Once done, you have a code generator that can be validated, and an abstraction of the code generator concepts (the intermediate model). For many users, this is enough!
# (If necessary) Establish a UI representation of the code generator abstractions (as expressed in the intermediate model). Since you are thinking UML, this would be a mapping from UML constructs to the intermediate model. But, UML is not the only possibility. The ambious might choose to implement a domain specific language (DSL) using GMF. Or, a wizard might be the right tool.
# Implement a mapping transformation from the UI representation to the intermediate model, and then chain in the JET transformation as the last step (so that user's do not have to see, or be aware of the JET transformation).

== A real work example: EMF codegen ==
The EMF code generator works of of an ECore file (and its trusty companion, the GenModel file). But, very few people actually build ECore models directly. Instead, they use annotated Java classes, Rose models, Rational Software Architecutre (UML2) files or an XML Schema. By separating the code generator model from the visual representation, the EMF architects have enabled a rich set of tools for developing EMF models. Some of these did not even exist when EMF and ECore were first developed!

= See Also =



Back to the [[M2T-JET-FAQ]]

[[Category:Modeling]][[Category:M2T]]