Several innoQ employees maintain a public weblog. This virtual weblog is a view onto these weblogs specific to entries that are related to MDA and code generation in general, or iQgen in particular. The virtual weblog also has an RSS newsfeed for usage with feed readers.
Ah, not that again. I don’t know whether it’s really worth fighting that battle anymore, but there is a fourth camp in the MDA space: Those who simply apply it to existing projects, without waiting for academic long-term benefits, while realizing a significant ROI in the first project and within the first few months.
If you want to find out more, check out this old entry or check out the design considerations section of our product’s documentation.
One of the (very few) sessions I attended at JAOO was the one recommend to me by Steven Kelly: Juha-Pekka Tolvanen from MetaCase introduced Domain Specific Modeling based on some case studies where MetaCase’s tooling is used. It was a good presentation; I found myself nodding in agreement most of the time.
One of the things I disagreed with, though, was the predictable UML bashing. Interestingly, Juha-Pekka used one of the arguments I use all of the time as well, only with a slightly different pitch: We agree that when you use UML to visualize low-level language constructs, for example create a UML class diagram containing all of your low-level technical J2EE artifacts, there’s little benefit and nothing domain-specific. You essentially provide a different view on your source code, at exactly the same level of abstraction.
The difference is that — at least in his talk — Juha-Pekka’s generalized this to UML in general, while I use this to criticize tools such as Together. We use UML in a number of projects in a way very, very similar to the way DSM is used in his examples. I’m the first to admit that UML is far from perfect, and I concede that using a “real” DSM approach such as MetaCase’s may often be superior to the poor man’s DSL available in UML (UML profiles). The benefit, of course, is the increased level of interoperability, both when communicating with humans as well as when exchanging information between tools.
In any case, it was funny to see that the MDA track at JAOO drew very little attention while the DSL track was packed, when in fact the presentations’ contents were very similar. It seems that MDA has now entered a massive anti-hype cycle.
We’ve released a new version of our software generation tool, iQgen, with a couple of improvements. Most notably, its Eclipse support has been upgraded to 3.0; this was definitely the most requested feature. For the sole reason that I was sick of looking at a semi-cool UI on my platform of choice, we also now have a Mac OS X version. This means that the menu bar is where it makes sense (at the top of the screen), the look and feel is Aqua, Preferences, About box and Help are where you’ll expect them to be, everything is packaged as a Mac OS X application package … all in all, supporting this was trivially easy to do. I did most of the work based on these instructions; the only thing a little tricky was figuring out how to bundle the application with Ant. In the end, though, the building of a new product release (which is done on Win2K or WinXP boxes) now builds the Mac OS X installer as well.
(iQgen, in case you’re wondering, reads in model information in XMI format, and transforms it into output files based on templates that have been written as JSPs. It is very, very stable, works with almost any CASE tool in the market, and has command line, Ant, Swing and Eclipse interfaces. Essentially, it does only a small amount of things, but our aim has been to make it do those things extremely well. You can find more information here.)
Today I've done some experiments that I envision for quite some time.
Applying Model Driven Architecture or a simple model-based generative approach to real world projects forces you to follow strict processes in order to ensure that your development steps stay repeatable.
While in early stages of development the forward engineering approach is extremely powerful, it becomes somewhat inappropriate when going to latter phases of projects. The temptation to abandon the generative approach and do all changes in the code increases. (For more information of forward engineering you could consider this short introductory part of the iQgen doc.)
The reason for that is a shift of scope in the development activities. While the common approach follows a push model (commonly model changes are pushed into code through generators), it would be more appreciated to use a pull model (that is, "update code fragments x, y, z from model with current transformation-rules").
In order to move into that direction I've extended iQgen a little bit to track metadata according to transformations and their execution.
With this it's possible to query dependencies between model elements of various abstraction levels (PSM / PIM), code and iQgen templates.
The following picture shows a part of iQgen's GUI with the (first) simple dialogs which can be invoked on model elements or generated files in order to query the thing I've called Transformation Repository.
As you can see it's very beta. But the infrastructure would allow to execute subsets of transformations. For the ease of model driven development in latter stages it's now possible to start generation directly from the code point-of-view.
I wonder if this is considered useful or even necessary and appreciate any feedback.
I have to whole-heartedly agree with Jeff Schneider: While SOA and Web services and REST are all exciting, they don’t exist on their own. My personal interest is to find ways to combine MDA (whether UML-based or not) and SOA (whether REST-based or not) — leading to a metadata-driven, efficient process for designing, creating and managing services as IT assets.
Jim Steel on UML 2.0:
I pity any UML tool vendor who takes it upon themselves to implement UML 2. I have read more coherent binaries than the UML 2 specification, which seems to have been inspired by the “Choose Your Own Adventure” books that I read as a child, but 10 times as long, and split across multiple books. It was cool when I was 7, but now its just a bloody nuisance.
I couldn’t agree more. When Phillip explained the <<combine>> concept to me, I wasn’t sure whether my problem was that I was simply too dumb to grasp it, or too wary to be bothered with something like that. I don’t claim to understand UML inside and out, as I have not wasted years of my life wrestling with its internal structure; but given that convincing people about MDA is one of the things I do for a living, I believe I know more about it than the average user. If I don’t get this, how can the authors expect somebody who just wants to use UML, but whose core competence is in some business aspect, to be able to use it?
I came across Jim Steel's blog in one of my ego-centric Technorati searches -- great blog, lots of things to agree and disagree with. Subscribed ...
Gavin King, maintainer of Hibernate and member of the EJB 3.0 Expert Group, writes about some of EJB 3.0’s designated features. Sounds reasonable to me, and shows that isolating your business domain information from technical implementations still is a good idea.
This little sample was developed just as an sample to show iQgen's capabilities with behavioral models. I used iQgen 2.0 for this, but it might be running with other versions as well.
The model was created with a trial version of Enterprise Architect 4.0 - a highly recommended CASE tool. Although there are some constraints in modelling state machines with EA in order to generate from theese with iQgen, this sample might be a good starting point.
All you have to do is to download and extract the zip-file, read the Readme.txt, and then just start generating and see the result. If you want to play around with other CASE tools, the state machines might be exported in a different way.
Maybe I'm able to show the usage of other diagram types near soon.
I got into a very interesting discussion a few days ago: Where exactly can you find a PIM and a PSM in both in the MDA vision as such as well as in existing tools such as iQgen. My view on this issue is:
In MDA:
In “Pragmatic MDA” or “MDA light” or “MDA as it exists today” …
So is there a PSM in the second approach? If so, where?
In my opinion, the PSM, if you insist on finding it, is the code itself. How can the code be a model? A model, in general, is a simulation of some concept or aspect from a specific point of view, intended to enable reasoning about it for a particular purpose. If I take the resulting code in the second approach from above, I can look at it in an IDE, the purpose being to edit in its textual form. If I read the same code into a 1:1 CASE tool such as Together, I see a visual rendering; the purpose of which might be to manipulate it visually or explain it to somebody else.
This is an illustration of the code generation process when using iQgen. I uploaded it here because I wanted to point to it from an email I sent, so I might as well spend some time describing it in more detail:
While I'm in a blogging mood, I might as well finally write about something I found quite interesting: A long term customer of ours who has been using MDA for quite some time, was recently more or less forced to outsource part of its development work to an offshore IT shop. The approach they have taken is quite interesting.
Their development infrastructure relies heavily on modeling, in their case using Innovator, a modeling tool very popular here in Germany. Innovator is very powerful, but also pretty complex. In addition to this, they use our product, iQgen, with a huge set of custom templates that drive the code generation. While they have achieved a high degree of automation — they can generate close to 100% of their backend code in most cases — it's not an environment that is well known, nor is it easy to learn in a short time.
So the problem was: How does one address this in the context of offshore development? Should they train the offshore developers in the usage of the toolset?
My recommendation was different: Continue to do the modeling on site, and ship the generated skeleton code to the offshore IT shop. This has the major advantage of agreeing on a specification that is as close to code as you can get, because it is code. In case you're wondering what the offshore IT developers have to do then, it's about implementing those parts of the code that cannot (or rather: are not) generated, which in this case includes the Swing client UI and those business logic elements that don't lend themselves to be modeled in UML easily.
The customer has taken this approach and exercised it for 3-4 months now, and it seems to work very well.
Jack Herrington has put up an interview with me about iQgen on his excellent Code Generation Network.
Back in December, I wrote an article for TSS, trying to introduce concepts from OMG's Model Driven Architecture (MDA) to developers. I'm reproducing it here (with some minor editorial corrections), with the goal of elaborating on some of the things in more detail, as well as addressing some of the comments posted in the the TSS discussion, as well as in other places around the web.
[ more >> ]