innoQ Releases iQgen 1.0 MDA Code Generation Tool


News: innoQ Releases iQgen 1.0 MDA Code Generation Tool

  1. innoQ has just released the final 1.0 version iQgen, its MDA code generation tool. iQgen is a code generation engine following OMG's MDA principles. It reads model information in XMI format and transforms it into any kind of textual code representation based on rules formulated in JSP templates.


    More info
    innoQ has just released the final 1.0 version of its MDA code generation tool, iQgen. iQgen supports model driven software development by allowing developers to separate business models (PIM, or Platform Independent Models) from architecture definitions that specify the mapping to a specific PSM (Platform Specific Model).

    iQgen's aim is to allow developers to get rid of repetitive, uncreative work by specifying architectural patterns in an easy way, using templates written in JSP syntax. Model information that has been exported from leading case tools in XMI format, as well as existing code, is used as the input for the generation process. iQgen does not aim to provide a standard architecture; rather, it enables architects to turn their own architectural rules into a part of an automated software generation process.

    iQgen's output includes, but is not limited to, anything from Java, C++ or C# code to deployment descriptors, database DDL files, or HTML GUIs.

    iQgen is a commercial product, but free for educational and other non-commercial use. An evaluation version can be downloaded from

    Stefan Tilkov
  2. Certainly iQgen's use of JSP as part of a design tool is a refreshing departure from J2EE's customary mission as a deployment platform. But iQgen isn't a turn-key model translator for MDA, since iQgen lacks any inherent notion of such crucial MDA concepts as UML profiles or pervasive services.

    The notion of a J2EE container contract is an apt metaphor for portable translation of models. Either OMG or JCP could readily specify such an MDA contract for Java, so that vendor-neutral translation of models into Java would be possible. Only then could modeling establish itself as part of mainstream Java development.
  3. Brian,

    you are right that iQgen is not a turn-key solution for all of MDA's aspects, at least not yet ;-) But it doesn't claim to be; one of our goals was to make it small and easily understandable, and have a clear separation between the core engine and the mapping rules/templates.

    Could you elaborate a bit about the features you miss in iQgen?

    I'm not sure about your second point, though. Is the EJB UML profile developed under JSR 26 what you are looking for? If so, I would claim that this profile can only be the result of a model mapping, not the source, since it is way too low-level for my taste.

    Stefan Tilkov

  4. Stefan wrote:
    >Could you elaborate a bit about the features you miss in

    Turn-key model translation has two prerequisites: completed code-generation scripts and a runtime library. Maybe iQgen expects the user to create these himself. At least, those are the core features needed for me to embrace a model compiler.

    >Is the EJB UML profile developed under JSR 26 what you are
    >looking for?

    Slightly. I want a simple Java UML profile, one that doesn't require J2EE. The intent is that modeling could supplant much Java hand coding. I think it would be of immense value to the software industry.

    I don't understand what you mean by "...this profile can only be the result of a model mapping...".
  5. OK, I think I get your points. Yes, iQgen expects the user to write code-generation templates and the supporting run-time framework(s)/library(ies) himself. Its aim is to enable a development team to turn formal rules into part of an automated development process. This is the result of our view that there can be no single best-match architecture for all projects. Nevertheless, we are working on a J2EE-based solution that is appropriate for a number of cases (and can be flexibly adapted). That is going to be a different product, though.

    I also see your point about the pure Java UML profile, though I expect that the problem is more about general issues in modeling dynamic aspects (since iQgen, as well as most CASE tools used stand-alone, do a pretty good job of generating Java code). A simple example illustrating this comes with iQgen. Of course, this is not based on any standard.

    What I meant by "the [UML profile for EJB] can only be the result" is that we consider it to be so low-level that it doesn't offer much abstraction above the hand-coded J2EE implementation. A typical business model should not be cluttered by remote interfaces and bean implementation classes, for instance. Thus, it will be created at a higher, more abstract level and then transformed into a model based on the EJB UML profile.

    Stefan Tilkov
  6. A "modeling profile" worth looking into is the set of stereotypes used by IBM's WebSphere Business Components framework.

    They use concepts/steretypes like:

    AdvancedComponent = Enterprise Application (EAR)
    ACFunctionGroup = Session Bean
    ACFunction = method on a session bean
    ACInterfaceModel = input/output data structure
    ACException = an exception
    ACEvent = pub/sub message to JMS

    In all they have about 12 stereotypes that cover the session bean facade "black box" space.

    They use a custom template based code generator to turn these concepts into J2EE code.

    As said above by other posters this is the level to work at rather than the low-level EJB UML profile.

    I am going to start investigating using iQgen as a replacement for the AC generator from IBM.

    I see great potential here in translating some high level modeling language into all of the artifacts needed for a J2EE based application (code, deployment descriptors, EAR/JAR packaging etc.), and even greater potential for migrating my generation templates once, as the technology changes, rather than migrating all of my applications by hand every time the specs change.

  7. "Yes, iQgen expects the user to write code-generation templates and the supporting run-time framework(s)/library(ies) himself." -- Stefan

    The revolutionary benefits of MDA are primarily labor saving and de-skilling. A tool which expects the user to write his own code-generation templates and runtime library has probably not saved labor and certainly not de-skilled.

    That's why I consider iQgen by itself not to be a ready-to-use model compiler. Rather, iQgen's core value seems to be as a model parser with an extensible interface as a placeholder for possible code generation. An analogy familiar to hand-coders would be of a C parser lacking standard header files (like stdio.h), lacking an object file format, and lacking the standard C runtime library. It would be innacurate to call this a compiler, and newcomers (as most are to model translation) would be disappointed or confused at its unreadiness. Perhaps to an experienced MDA architect with spare time, its utility would be more apparent.

    But clearly, your team is laying a sound foundation in a very green field, and I look forward to your future products.
  8. This may be obvious but I think it is worth saying, that the "labor saving" benefit happens every time you generate. You write the templates and frameworks once, and generate many many times.

    We just went throught the very labor intensive process of migrating a single project from VAJ 3.5 to WSAD 4.0 (also ejb 1.0 to 1.1). Now we have to migrate the other dozen or so projects.

    If we had generated the EJB code (and artifacts) from templates, we would only have to migrate the templates once, and reap the benefits of regenerating many times.

    This process will have to be repeated when we move to WSAD 5.0 and EJB 2.0, and is not something we are looking forward to.

    The de-skiling happens when the template writers become the only ones who have to understand the complexities of the target platform, not everyone across all project teams.

    If something can be automated, why do it by hand?

    I appreciate the fact that this tool does not push another framework on me. I want to generate to my frameworks, or to frameworks we are already using, like J2EE itself.

  9. Brian,

    I see your point and I don't want to start arguing about the correct descriptive phrase for what iQgen is and isn't, since I'm pretty sure that we agree on facts, if not on words. I think currently iQgen might meed Ken's needs, and it oviously doesn't meet yours. We have used products that forced us to use a specific set of architectural patterns and frameworks in the past, and felt we were forced to accept something we didn't really need. That's why we decided to implement the engine first, specific template sets later.

    Anyway, thanks for your comments, and thanks for taking the time to look at iQgen.

    Stefan Tilkov
  10. Is anyone interested in sharing templates based created for iQgen? I have integrated it into JBuilder successfully now, even if it is only a partial integration. If anyone would like to help building a template repository... email me at rvowles at sew dot
  11. Hi, Richard!

    Yes, indeed. We have created a community site for discussions and for building up a template repository.
    You can find the link to the iQgen community site on the left navigation at

    Join now and contribute your templates!