Model Driven Architecture and Code Generation

I have been using Model Driven Architecture and code generation for some time. In this short blog post I have tried to summarise some of the lessons I have found useful. I have included an example using Sparx EA.  Happy to share the code but I haven't yet been bothered to package it up!

1. Code Generation - Use Appropriately

Code generation is old hat of course ... for a long time designers have wanted (and often succeeded) to transform their detailed architectural models into physical implementations. The aim of model driven code generation is increasing productivity and to better document or communicate the details of the system in question.

The danger is you end up really just creating ... well ... 1970's flow diagrams, large pictures of program logic. Time consuming to produce and giving no additional insight; much easier to code in a good productive modern language.

What I am saying is that generating Java EJB (for example) code from a hand crafted UML model of all the required J2EE classes is just pointless. What you need to do is transform a simpler logical "technology independent" model into implementation "physical" models.

2. Conceptual is not the same as Technology Neutral

Another mistake is to try to automatically transform conceptual models into models that can be the target for code generation. Conceptual is not the same as technology neutral, a conceptual model is designed to help develop and communicate how a system works. To aid understanding unnecessary and confusing details will have been missed out, and relationships between components will be "idealised" ... lies designed to elucidate if you like. On the other hand a technology neutral model needs to be exact if it is going to be the root source for code generation.

Conceptual models have a purpose, don't ruin them ...

3. Keep Generated Code Simple and Readable

Generated code is hard to debug and fix. Changing code involved changing your code generator; the code generator will inevitably become complex and ugly. Tracking causes between the generated code, input model and the generator logic will be frustrating ... especially if it has been sometime since you have looked in detail at the generator logic.

Some users of your generated code may not have access to the generator (or more to the point may NOT want access to it). Of course changing the code manually is a mistake, but nethertheless they should be able to understand the code. In a way it should look like manually generated code.

Generated code should be made to be simple and clean ... use object oriented encapsulation (not quite the right word but you know what I mean) or libraries to separate the handcrafted, involved and complicated plumbing from the automatically generated simple if repetitive and large code base. 

Example - Google App Engine Datastore

My UML tool of choice is Sparx EA, and this has good MDA capabilities:

• A two stage generating methodology. First to transform from a technology neutral model to technology specific model, secondly to generate code (Java, C#, SQL DDL etc) from the corresponding technology specific model. 
• A common templating engine for transformations and code generation.
• A simple Domain Specific Language (DSL) to describe the model to be generated (this is a really important but almost hidden Sparx EA capability).
• Out of the box templates for transformation and generation - both working and as accelerators to create your own.

I suggest you start with this white paper for more details.

Now Google App Engine (GAE) has a database system - Datastore - quite simple to use but inevitably you will end up using or rolling a framework. I rolled my own and for each entity I need to create a number of simple classes each extending complicated base classes:

• A Controller to CRUDL entities
• A Factory to get the Controller
• An Entity interface
• A Server implementation designed to be used on the server side (wraps the Datastore Entity)
• A Client implementation design to be used on the client side. I use it with Google Web Toolkit (GWT). This is a Plain Old Java Object.
• I also need to generate GWT RMI Classes. 

This is a typical requirement for most frameworks (and I much prefer build time creation rather than SLOW runtime introspection etc.) This would be very boring to handcraft ... so I created a MDA transformation to a Java physical model. Then the actual Java code generation was done by the out-of-the-box Sparx EA templates.

Screenshots ... feel free to ask for more details.

This is an example of a logical model

This is a bit of the generated Java model just showing the client/shared classes

And this is some generated code examples - boring code to write manually ...