Best practices for writing a code generator

[Juergen Weber]

Hi,

I wonder how one would start to write a code generator based on an EA model.

* export to XMI, parse the XMI, build an in-memory model of the UML model and generate with an engine like stringtemplate.org

* use an EA SQL Repository instead and grab the model from there (ouch ;-) via JDBC and Hibernate

* create a MOF model, export to XMI and use Eclipse EMF and friends?

Has anybody tried one of these or a better idea?

Thanks,
Juergen

[Geert Bellekens]

Juergen,

You forgot:
* Use the API to build a tool independent UML model in memory

Which is the best option IMHO.

Geert

[beginner]

Yep. Geert is right. I do it this way.

b.

[Frank Horn]

Be aware of one drawback though: there may be things within your UML model which the API does not expose, e.g. tagged values on parameters or connector ends linked to a feature. If you want to be sure that all information is available, you may want to consider using xmi (or the database) as source for code generation.

[Geert Bellekens]

Yes, Frank is right, the API has its blind spots.
Luckily it also provides a SQLQuery() and Execute() methods that you can use as a backdoor to access the database directly.
If designed properly these "dirty" direct database calls can be isolated enough to avoid a messy implementation ridden with random SQL calls.
I certainly prefer this approach iso having to parse XMI (which is as "standard" as your average SQL syntax :-/)

A while ago I've written some of my thoughts about this subject down into an article about Modelling Tooling and the general pattern for a Modelling Tooling Framework
You might find those interesting, and I'd love some feedback about those articles.

Geert

[Juergen Weber]

Thanks, I tried the Java API sample. The sample has a bug, it tries to read all IDs as short, whereas in my model they are at least int. I changed the sample to read the IDs as int, now it looks better.

Still, I'll also have a look at the MOF way ..

Thanks,
Juergen

[Frank Horn]

Geert,

of course your concept of a Modelling Tooling Framework is much more powerful than my little XSLT based code generation, and if I had more time and/or colleagues I would certainly love to set up something along these lines. For the time being I have to live with the situation you very aptly summarize:

Most tools start as a quickly hacked together script to solve an immediate problem, but then get used more general, and before you know it they become an essential part of the companies operations.

Our use of xmi came along because we already had our UML-inspired, but manually written xml for code generation when we introduced EA, and writing an xsl transformation from xmi to our xml was fairly easy.

Anyway though, the xmi approach has its virtues. XSLT transformations can be seperated into general and EA specific parts, and switching the tool case would only require inclusions of new xsl templates specific to another tool. No COM interop or bridge involved, no database access.

In my dreams I have one object model for metacode, one for uml, transformations (C# and/or XSLT) between the two, and various implementations to fill the uml model from different sources like EA-XMI, EA-API, ArgoUML-XMI a.s.o.

Frank

[Geert Bellekens]

Frank,

Don't we all whish we had more time or (competent) colleagues  
As a freelancer I witnessed the situation of I described a few times with several clients, so when I started at my current client I was kind of happy they had virtually no tooling at all. (actually they did, but it had already become such a mess that they didn't even use it anymore).
That meant I could start over fresh, keeping in mind all the lessons learned with previous clients.
So now all of the tools on and Addins on EA use the same framework, which is getting quite complete by now.

If you are interested, in my free time I started over the framework for my own purposes. One of the results is the EA navigator I published on the community site a while ago including the (C#) code.
It's not near as complete as my clients project, but I hope to add more features in the future.

In this setup I would consider XMI as just another source, much like EA or RSA would be.

Geert

[beginner]

Geert,
...
In my dreams I have one object model for metacode, one for uml, transformations (C# and/or XSLT) between the two, and various implementations to fill the uml model from different sources like EA-XMI, EA-API, ArgoUML-XMI a.s.o.

Frank

I have the same dream but it will likely not come from Sparx. It's just the *NIX way: have small tools that do their work well and combine them to do complex tasks. EA is more the all-in-one approach.

b.