When I started with this software I choose to use DBase as the database format. At that time there just were no feasible alternatives since cost for a good relational database would have been a problem and the PC-computers of that time were not fast enough anyway. All the time I had been troubled by the fact that DBase isn't very safe to use. There is no transaction support. Table restructuring was troublesome. Database corruption happened too often and so on. I was longing for a chanse to change.

Late in the year 2004 I had to start working on my software for managing the swedish VHF-contest results again. A number of changes to the rules had been announced so there had to be some changes. The changes required some database restructuring. Firebird had also appeared as an offspring of Borlands Interbase database engine and this was now a very feasible alternative to the old DBase stuff. So now that I do some rework, why not switch sooner rather than later.

I had been working intensively the whole year with analysis modelling and code generation from xtUML models. This was indeed inspiring work and in order to get a good structure of the new database I had to get a modelling tool. After downloading and testing some tools I found ArgoUML to be the one with the fewest shortcomings. After a few days of work I had a class model that I thought matched by problem pretty well. Unfortunately I have not put the diagram under source control so I don't have this one any more.

Since the new model contained 12 or more classes, I dont remember exacly, it felt like a lot of work to do all the coding by hand. Especially since we so successfully were using code generation where I work. Not nice at all. ArgoUML does contain some functions for code generation but there were no generators for Delphi available. Adding new translators also has to be done by writing Java code. I know too little java to do this. However there is an XMI export function and since I had been doing a little XSLT hacking I went down this trail. Bad choice!

After a few hours of studying XMI I almost gave up. These files are not nice at all. So more internet searches. This time UMT was found. This was a code generator framework providing an XMI to XMI-Light transformation that could be run before the final code generation. XMI-light was so much easier to work with so I grabbed it and started hacking.

So, by writing one database access class by hand, adding funcionality in small steps, I developed useable classes. After doing the hand coding I updated the xslt-file to generate exactly the same output. But running it gave me not just the hand coded class back, but also the files for all other classes. As more and more functionality was added it also became apparent that each time I had to change the model extremely little work had to be put into updating the software. It was just a matter of exporting the XMI-file, running UMT on it and copying the generated code into the right directory.

Today a couple of years have gone. I still occasionally have to change the data model. Mostly adding attributes to the classes. Updating the code is still as simple. Just a few buttonpresses and the DB classes are updated.
But in fact I have started looking at implementing state machines aswell. Unfortunately these are of little use without an action language which ArgoUML despite good progress has not added. UMT and XML-Light neither supports these. I have done some changes to the XMI2XMILight XSLT transformers but so far progress is slow.

If you are interested in the model compiler, send me a mail. You can have it for free. I won't share my data model but it likely won't describe your problem anyway.