'MDA From a Developer's Perspective' Article Posted on TSS

Discussions

News: 'MDA From a Developer's Perspective' Article Posted on TSS

  1. A new article, by Stefan Tilkov, focuses on the benefits a developer can gain from applying an MDA (Model Driven Architecture) approach to application development. It discusses technologies such as UML, XMI (XML Metadata Interchange), and MOF (the Meta-Object Facility) and takes an interesting look at the '10 Myths About Code Generation'.

    Read 'MDA From a Developer's Perspective' by Stefan Tilkov

    Threaded Messages (68)

  2. I've started to play around with Eclipse's EMF and so far it has been pretty interesting. I've been interested of late in implementing a JMI version of the CWM (Common Warehouse Metamodel) that we can tie into an app server like JBoss via JCA, persist it to a database like SAP DB (or whatever) and so to get a feel for everything, I've implemented a rough cut of the model and a corresponding editor to play with. I have a suspicion of code-generating tools, but thus far I have been reasonably impressed. I'll see where it takes me.

    Cheers
    Ray
  3. In the four layer metamodel, the more high you go, more
    difficult it becomes to do code generation. Typically
    people concentrate most on layer 2 and drive codegen from
    the model in layer 2.

    Soumen Sarkar
  4. I've just started a new open source project called Jeeglue that shares some of the ideas with this approach.

    Visit http://www.sourceforge.net/jeeglue for more informations.
    The whitepaper can be found at http://sourceforge.net/docman/display_doc.php?docid=14346&group_id=69134
  5. I personally agree with many of the points in the article.

    However, I think the article would have benefitted from a more complete discussion of MDA. In particular, the article concentrated solely on the "static" relationships, and completely omitted the "dynamic" behaviour. In MDA the dynamic behaviour is specified in terms of Harel StateCharts (i.e. FSMs), plus the actions taken in response to input events. Or, to be more precise, the semantics of what happens is defined, and it is up to different tool manufacturers to define the synatax in which the semantic actions are specified.
    Personally I like that division of responsibilities.

    So, when developing applications, it is clearly desirable to specify the dynamic behaviour, and how well a tool translates that into code is of considerable importance.
  6. Tom,

    you are of course right in that the dynamic aspect has been largely ommitted. The reason is simply that I wanted to keep the size in reasonable borders, not at all that I consider it unimportant.

    There is also the upcoming (product-wise, that is) Action Semantics extension to UML, which could (in theory) allow for full semantic models. Whether this is a desirable goal can of course be argued.

    Stefan
  7. <stefan>
    you are of course right in that the dynamic aspect has been largely ommitted. The reason is simply that I wanted to keep the size in reasonable borders, not at all that I consider it unimportant.
    </stefan>

    Understood; I suspected as much. Stating this explicitly would help avoid any accusations that "you haven't explained/understood MDA, or that "you're just pushing the bits of MDA that a particular tool does well".

    (Tangent: I've often found it valuable to explicitly state what I'm <b>not</b> saying, so as to avoid subsequent disappointments based on misapprehensions)

    <stefan>
    There is also the upcoming (product-wise, that is) Action Semantics extension to UML, which could (in theory) allow for full semantic models. Whether this is a desirable goal can of course be argued.
    </stefan>

    Some products already claim they do that, and well.. See http://www.kabira.com for one example!
  8. I have been using "Model Driven Programming" paradigm in
    our J2EE based Network Management System (NMS) using XML/
    XSLT based code generation. Currently in our project, 66%
    of *.java is generated. If you are interested in the
    paper that I have authored from experience gained, it
    is at:

    Model Driven Programming, published in XML journal of SYS-
    CON media, August 2002, Volume 3, Issue 8. The article
    proposed an extension of Model View Controller (MVC)
    architecture and showed how to implement in software
    development projects. The online version could be found at

    http://www.sys-con.com/xml/pdf/trees.pdf

    I have a few points to add:

    1. It is possible to keep generated code and hand written
       code separate yet allow functional cohesion. This is
       achieved through "implementation inheritance" feature
       of object oriented languages. Furthermore technologies
       like "Java Dynamic Proxy" and "Interceptor Design
       Pattern" helps in adding orthogonal code.

    2. Code generation from domain specific model is far more
       effective than code generation from UML models.
  9. Soumen,

    thanks for the link, I'll definitely follow up on that. To address your points:

    ad 1 (use of code generation in conjunction with implementation inheritance etc.): This is definitely a valid strategy; my only concern with this that the fact you are using code generation directly influences the architecture with this approach. If this is no problem in a given scenario, fine.

    ad 2 (domain specific models instead of UML): I couldn't agree more - that's why I'm really looking forward to MOF-based (instead of UML-based) CASE tools.

    Stefan
  10. 2. Code generation from domain specific model is far more
       effective than code generation from UML models.

    It is not clear why that has to be the case. Or to be more accurate, since
      "MDA == a small subset of UML + Action Semantics (Language)"
    I believe the effectiveness of code generation will depend largely on exactly which subset has been chosen.

    The theoretical underpinnings of MDA have a long and honourable pedigree. Within defined limits, FSMs have been proven to be useful and effective over three decades to my knowledge, and Harel StateCharts have been around for 15 years.

    To me the interesting question is thus whether, in any specific application domain, those MDA techniques adequately represent the modelling and design of your required system. I suspect, and would like confirmation or refutation, that (presuming that MDA is useful in the domain) code generation techniques can be practical and effective.
  11. Can model transformation and code generation techniques be effective ?

    If you get a object domain model at first, some high level modelling language ( may be UML ) and application domain semantic extension ( UML profiles or else ) then MDA approach is working.

    For example a changeability property or a persistence stereotype set on some object attribute can help to generate DAO or DTO components or using struts patterns.

    Is it practical ? We'll have do to a lot of transformation model building, maybe using a specific language, XLST, MTRANS or Language J etc...
  12. It's not new. In fact, the MDA only states the obvious (but I can understand why it took so long to get there) - the design is the code :).
    If you look at this, almost no-one programms in assembler these days. What are our higher level programming languages if not assembler generators?

    The main drawback with MDA I see now is that it is relying on UML - i.e. on diagrams. I would say that through history shows that written language is much more powerful in conveying _exact_ meaning than diagrams. I think it has something to do with the fact that diagrams that describe everything get cluttered easily and while you're still aware that there's bigger picture. With text you have to focus on a paragraph and the text must "flow" (adding to the mix an awareness of time). Not to mention that creating/changing the text is easier than editing diagrams (might change with a good drawing recognition sw, which is still few years away). How long before people will edit XMI directly? ;)

    Also, I worry about The Next Silver Bullet Promise.
    I just can hear "Use MDA and it will cure common cold, estabilish world peace, make you rich in a day and by the way, it will also solve this small business problem you have."
    The article touches this in (10), but the sales people are already out there, talking to the managers and the image of Wormtongue whispering "Saruman is friend of Rohan" creeps into my mind (sorry, can't resist, just came from screening of the Two towers.. :) ).
    "Faster, cheaper, more reliable!" - well, yes, for some of today's problems. But tomorrow's one will be ten times as complex and you will need at least as skilled, if not more, people as you do now.

    Regards,
    Vlad
  13. UML is NOT diagram[ Go to top ]

    I am shocked by the suggesstion that UML is diagram. I
    honestly do not know what that means. UML is for modeling
    -- for example "inheritance", "classification",
    "composition". It is a different matter that these
    ontological concepts can be represented by diagrams.
    However, a visually impaired person can still understand
    UML and form whatever visualization of the concepts. In
    other words notations are not the essence of the matter.

    Do not get me wrong. I do NOT follow UML in my work
    rigorously. I would hate to do UML as a matter of
    "code visualization" -- what a waste of productivity.

    Modeling, structuring of ontological concepts and relations
    should be 10,000 feet from code. At least one should start
    from 10,000 feet and gradually come down by layering of
    models.

    I am a big fan of "Domain Specific Modeling" -- if you are
    interested, please go through the following paper from
    MetaCase consulting (http://www.metacase.com)

    DOMAIN-SPECIFIC MODELLING: 10 TIMES FASTER THAN UML

    http://www.metacase.com/papers/Domain-specific_modelling_10X_faster_than_UML.pdf

    Soumen Sarkar.
  14. UML is NOT diagram[ Go to top ]

    UML is a language. It has it even in its name. Diagrams are its form (at least the commonly known) - in the same way as English is based on Latin alphabet. That it expresses modellin g ideas is its _purpose_, not its _means_ of expression. I could express the same ideas in English, Java, Smalltalk, C++. So UML is a _form_.
    Yes, notation are not the essence, but then UML is not the _essence_. It's means of conveying it. The essence existed before UML, and can exist independently of it. The fact you can say "inheritance" and I can understand of what you're saying is the proof of this.
    What I'm saying is that this particular form is IMNSHO less efficient than other forms (means).

    Also, I disagree that modelling should be different from "code". Modelling _is_ code. Most people just have a very specific view of what "code" is. Code is a means of encoding information - either explicit (what you tell your tool), or implicit (what your tool knows).
    How can you find that your model indeed models what you want? (=meeting the requirements). You test it. At the moment, there are only three means of the testing a model.
    - mental simulation (=peer review). That's what most projects do. Invariably, for all but the simplest things it fails, as every human being has a limit on what complexity they can deal with at any given time, and it's generally quite low.
    - formal proof. You can model, and express your requirements in a formal language, such as Z, and prove your model meets them. (functional languages belong here as well - sort of).
    - compile your model and run it against some real tests. Similar to formal proof, but easier, as it deals with lower level of abstractions (Turing machine being the simplest thing = highest level of abstraction, Java being more complex, with syntactical and semantical extras = less abstract).

    It's not about "how do I do persistence?" It's about "how am I sure that what I do is what I should be doing?" The fact that I don't have to worry about persistence is just one thing about it, but from my view it's about the same importance (ultimately) as how to optimize the use of internal CPU registers and the first and second level caches.
    Regards,
    Vlad
  15. UML is NOT diagram[ Go to top ]

    Well the first thing is "a Model IS A MODEL". Agreed UML is a language, but a MODELING language. So how can a model become a product? Now given this, how much of this model can be converted into actual implementation (with great tools offcourse!). I believe a percent of your implementation can come from a model, but trying to get everything from the model is unnecessary(not impossible). Because at a detailed level, flowing text is better than modeling text(assuming you can represent these models in symbolic text like xmi). And you need to find new modeling entities everytime you face new types of solutions. So I thing it is better to find an optimal percent that can live as a model and the rest should be plain code. Hope it makes sense.
  16. UML is NOT diagram[ Go to top ]

    UML is definitely not tied to the diagrams - what form of visualization you use is purely a matter of tool support. There are CASE tools that support browsing through models by using some sort of tree-oriented model browser, e.g. Paradigm Plus (an otherwise crappy tool last time I used it - does if even exist anymore?). There is also a new OMG specification that deals with expressing model information in a human readable way called HUTN, available at OMG.

    On the issue of domain-specific modeling: As long as it can be expressed in MOF, it's perfectly MDA compliant (or it would probably be if there were such a thing) to use a domain specific meta-model. Not using UML is a perfectly reasonable option.

    Stefan
  17. UML is NOT diagram[ Go to top ]

    The standard UML metamodel are diagrams (section 3 of the spec). In quite a few places in the spec they refer to diagrams or "graphical language" (for example 2.3.1. Levels of formalism section "... Sometimes, especially when the language has a graphical syntax").
    You are right that meta-metamodel is not diagrams and it does not force people to use the diagram instance. It's just the most common one, and the most encouraged one (at the moment). Even the OMG Introduction to OMG UML states "UML defines twelve types of diagrams, divided into three categories".
    It's similar as J2EE is not spelled EJB, but ...
    V.
  18. UML is NOT diagram[ Go to top ]

    Anybody knows how is the book

    Building and Managing the Meta Data Repository:A Full Lifecycle Guide

    by David Marco

    I have been doing "Model Driven Programming" in our J2EE
    based NMS for last two years. I am planning to formalize
    my experience along four-layer meta model. Basically from
    now on in my application software development projects,
    I would like to do the following:

    1. Follow four layer meta modeling as much as it is
       doable within schedule

    2. Use XSLT for code generation. Last project it was 66%
       of *.java.

    Soumen Sarkar.
  19. "It's not new. In fact, the MDA only states the obvious (but I can understand why it took so long to get there) - the design is the code :). If you look at this, almost no-one programms in assembler these days. What are our higher level programming languages if not assembler generators?"
    -- Vlad

    Indeed, but automatic translation isn't specified as an absolute requirement, and OMG's MDA allows for an entirely manual process.
  20. The problem with manual process is that you can make errors.
    Granted, you can (indeed will) do it with tools as well - they would have been built by humans only after all. But at least they will do always the same errors and once corrected (hopefully) won't do the error again.
    In the same analogy, even though we have quite high level languages, no one is stopping you from writing assembler code (or even do machine code directly if you wish).
    V.
  21. There is a lot of scope to apply "Model Driven" paradigm.
    The idea that we have high level languages and thus
    "the design is the code" faith is misplaced. I will give
    a concrete example from past experience:

    ====================== begin ======================
    SNMP is used for Network Management. Java is a object
    oriented high level language. Typically people write
    Java programs as per SNMP operations (GET, GET-NEXT, SET)
    to exchange data as per Management Information Base (MIB).
    MIB is data-contract specified in a ASN.1 like language.

    See the irony here -- if there is a data-contract like MIB,
    why should I write "protocol oriented" Java programs to
    exchange data. Instead what should happen is that Java
    interfaces/classes should get generated from MIB. The
    generated interfaces/classes hide the "protocol oriented"
    program and exposes "data-contract oriented"
    APIs/implementations. I know, from my netework management
    experience, that majority of people do "protocol oriented"
    SNMP programming and very few follow "MIB oriented" SNMP
    programming. The reason being "MIB driven codegen" requires
    some degree of sophistication and different ways of going
    about in the job of programming.

    Similar thing happened in CORBA in a standradized way. In
    CORBA the data-contract is IDL. IDL compiler generates
    TCP programs from the data-contract exposing OO APIs/
    implementation. In SNMP there is no such standardized
    APIs yet.
    ====================== end ======================

    Hope, I could convince you why we need to go "model driven"
    way inspite of beautiful high level languages such as
    Java.
  22. We must have missed somewhere, because I'm not against MDA.

    I do think that the total abstracting of all services won't work, just because all of them have some pre-requisites, but I think it's an entirely different topic - but then, as I see it MDA doesn't (wisely) attempt to solve this.

    I'm not sure I understand your SNMP/CORBA example either.
    Somehow, somewhere, I need to describe semantic of what happens if. I can do it declaratively (formal specs like Z, functional languages), or imperatively (standard 3G languages like C++, Java).
    My design cannot stop with just saying "this is the contract". I'm not talking now about "how do I persist this" but "What do I do when customer creates new order?"
    If I stop at declaring "then you will call createOrder method on XYZ", that's not a design IMO. How can I actually verify that it does what the requirements want me to do?

    Codegen can do something here for me (for example, make sure that my order is a transaction, or that it can be called as a web service etc..), but it doesn't guarantee that it meets the business requirements. And that what it's all about.

    Eventually, all software is written because of some requirements (that can be as simple as "because I feel like doing this"), a lot of the software I develop is because business wants to improve. If they could do the same w/o software, and cheaper, they would.
    Therefore, my first goal is to satisfy business requirements. If I can do it using RDBMS, or OODB, or what, business doesn't care ( - in theory, in practice nothing lives in isolation and as such there are other requirements, but they are still ultimately business requirements).
    It does care whether the system I'm going to write does a credit check immediately w/o hassling a customer or not, as it gives it competitive advantage.

    I want to model this, and I want to make sure that the effort I spend is in the right direction. I don't want to find out that something is wrong with my ideas in the acceptance testing (if possible).
    The more steps I take encoding the information from the requirements to the implementation, the more chances of chinese whispers and me fixing something down the track. I want the model to be understandeable by the computer as soon as possible. That does not mean the model is Java or C++ or Smalltalk. That means I can run and validate my model formaly (which may mean just runnig it against a suite of tests). Java's not important (except as the means of persuading people that they already use code generation).
    Verification of the model is.
    Regards,
    Vlad
  23. Design is the code[ Go to top ]

    Something I left from the previous post - I'm not saying "code is the design" (the mantra often associated with XP) but "design is the code" and I think that while the difference is subtle, it is a very important one.
    V.
  24. <Vlad Ender>
    The main drawback with MDA I see now is that it is relying on UML - i.e. on diagrams.
    </Vlad Ender>

    I don't think so.

    <Vlad Ender>
    I would say that through history shows that written language is much more powerful in conveying _exact_ meaning than diagrams.
    </Vlad Ender>

    While I know what you're getting at, you are overstating the case. Diagrams are excellent for showing "random" connectivity: examples: FSMs and analogue/digital hardware are much more easy to understand than the text equivalents.
    Use diagrams to mitigate text's weaknesses, and vice versa.

    MDA makes good use of FSM/Harel State Charts; the article didn't mention those.

    <Vlad Ender>
    I think it has something to do with the fact that diagrams that describe everything get cluttered easily and while you're still aware that there's bigger picture.
    </Vlad Ender>

    Only too true; I seen some truly horrible attempts at using diagrams to represent everything. "Software Through Pictures" (I hope that isn't a product name :) just doesn't work!

    <Vlad Ender>
    Also, I worry about The Next Silver Bullet Promise. I just can hear "Use MDA and it will cure common cold, estabilish world peace, make you rich in a day and by the way, it will also solve this small business problem you have."
    </Vlad Ender>

    You don't have to listen very hard :( I've already been subjected to this oversell by a commercial tools vendor and an external consultant (that was rumoured to have a financial "relationship" with the tool vendor). Fortunately the divisional director had tried to sell 4GL tools many years ago, and knew it was hogwash :)

    <Vlad Ender>
    "Faster, cheaper, more reliable!" - well, yes, for some of today's problems. But tomorrow's one will be ten times as complex and you will need at least as skilled, if not more, people as you do now.
    </Vlad Ender>

    Agreed. And having a very sharp power tool doesn't mean that a user understands design nor that they can use the tool effectively. I'm continually amazed by the number of people that think a powerful tool will remive the need for design, when in practice they just allow you to amputate your leg painlessly.
  25. I love learning about new paradigms in software. Your article was interesting but I have a question.

    <quote1>
    You will have to make modifications to the customer bean's remote interface because of the new getters and setters (or, if you're following a value object pattern, to the value object associated with it); you'll need to apply the same change to your DAO, as well as to any other class somehow affected by that change. Adding an attribute is not what I would term a complex change.
    </quote1>

    <quote2>
    It's the rules, the mapping from logical to physical model that change, forcing you to touch each and every single software artefact related to persistence.
    </quote2>

    If we have to make all these changes as a result of adding a single attribute, it seems our original design should be suspect, right? I'm not an EJB expert and will probably always be just a student of OO design, but it seems that we've not done a very good job of encapsulation if we're having to make all these changes systemwide as the result of a single attribute change.

    The idea of MDA still sounds attractive, but does this example really provide the motivation?

    Paul Carter
  26. Paul,

    You asked

    <quote>
    If we have to make all these changes as a result of adding a single attribute, it seems our original design should be suspect, right? I'm not an EJB expert and will probably always be just a student of OO design, but it seems that we've not done a very good job of encapsulation if we're having to make all these changes systemwide as the result of a single attribute change.
    </quote>

    I don't think so. I believe there are two major ways to enable your application code to be adaptable to change, one being a generic solution, the other one using code generation. Taking the attribute change as an example, in a typical J2EE architecture there will be multiple places where an attribute from your logical model will be represented physically - e.g. in some RDBMS table, in an EJB's persistence schema, a value object, a struts bean etc. The generic solution would be to have a list of attributes as objects, allowing you to add new attributes without breaking the contracts. (This would also imply using a table of attributes in the RDBMS - shudder). The generative solution would be to generate the code in multiple places based on a single specification (in MDA, this would be a model).

    Of course this contrast is not as hard as I described. In every system I know of that has been developed with an MDA approach, there was a combination of generic frameworks and code generation, with the goal of finding a balance between aesthetically pleasing and performant, readable and concise, maintainable and tuned, etc.

    Stefan
  27. <stefan>
    In every system I know of that has been developed with an MDA approach, there was a combination of generic frameworks and code generation, with the goal of finding a balance between aesthetically pleasing and performant, readable and concise, maintainable and tuned, etc.
    </stefan>

    I'm in violent agreement with that. I would like to see articles that indicate the specific balance that was used on specific projects, and why.
  28. And I thought the article was about 3, 4-methylenedioxyamphetamine!
    Duh!
  29. MDA is a crap. Well, it'll take some to me for people to get it.
  30. Well, it'll take some to me for people to get it.


    I dont get it...
  31. I disagree with a lot of points made in the article. Mainly because it is totally missing the dynamic aspects of code generation.

    Even in the overly simple example stated, in the real world, the generated EJBs will contain a lot of logic that is very hard to express with a model. Also I suspect that the point some discussion items made is extremely valid: UML - being diagrams or not - is very bad in properly defining and maintaining dynamic relationsships between objects.

    The types of artifacts it presents are just not enough. Ever tried to model a couple of nested loops with some conditions that affect a couple of objects at the same time over a fair number of - logical - software tiers? Hard! Tried to maintain it? Have fun! Yet these are the problems of the real world.

    If you aim at doing something like MDA I would suggest to provide a full blown character oriented touring complete language. Oh, and one other thing you will probably need is some execution environment that actually _runs_ the generated program _before_ its get generated to the relevant platform.

    Karl
  32. <quote>
    The types of artifacts it presents are just not enough. Ever tried to model a couple of nested loops with some conditions that affect a couple of objects at the same time over a fair number of - logical - software tiers? Hard! Tried to maintain it? Have fun! Yet these are the problems of the real world.
    </quote>

    I have used an MDA approach several times, and as yet have never tried modeling the way you imply. As I tried to explain in the article (obviously not well enough ;-)), nobody says you have to model everything. What I have found to work best is to express structural aspects in the UML model and generate code skeletons, where the implementation is programmed in e.g. Java. (Of course the code generator will have to support re-generation, but almost all available ones, including our own, do so. Alternatively, as Soumen points out, you have to take care of separting generated from manually created code by other means.)

    Stefan
  33. <quote>
    I have used an MDA approach several times, and as yet have never tried modeling the way you imply. As I tried to explain in the article (obviously not well enough ;-)), nobody says you have to model everything.
    <snip/>
    (Of course the code generator will have to support re-generation, but almost all available ones, including our own, do so.)
    </quote>

    In the end (and in my opion) this is a non-value-adding approach. While I can quite agree that it might be fun to work in this way, I very much doubt that a code regeneration approach that truely works without the dynamics of the application being in the model can work.
    In my opionion and experience this will only work out for the most basic problems. That does not say that you cannot save a lot of work by generating some code for some architecture. You might even be able to regenerate - sometimes at least. Will you be able to use such a technique repeatedly and steadily in your development cycle. I have very strong doubts.
  34. It's a bidirectional process. When you are writing
    a model and you can't express what you need to
    express then you create an implementation and then
    add it to your toolbox. If you are implementing
    new things then you can make these available to the
    model as well.

    Your nested loop construct may be implemented outside
    the model, but it could be callable from the model.

    For example, classes like task, semaphore, memmory management, the database, etc could be implemented
    outside the model, yet are available for other code
    defined within the model. It's a layered approach.
    What you include at each layer is what you feel comforable
    with.
  35. <quote>
    In my opionion and experience this will only work out for the most basic problems. That does not say that you cannot save a lot of work by generating some code for some architecture. You might even be able to regenerate - sometimes at least. Will you be able to use such a technique repeatedly and steadily in your development
    cycle. I have very strong doubts.
    </quote>

    From my own experience, I was involved in a project that used Java and CORBA (pre J2EE days, about 3 years ago), used an MDA approach (before it was called that) with a handwritten code generator, and involved about 120 developers at peak level. Being of that size, it hat *lots* of problems, none of which had anything to do with the fact code was generated.

    In fact, there is a rather illuminating story about this project: When it started, the people who designed the initial architecture made everything a CORBA object - absolutely everything. (Anyone remember the Intergalactic Object stuff? Those were the days ;-)). Of course, performance was horrible. So after about 2 years of code writing (and generating), the architecture was changed so that only the server-side controller objects (those communication with the Swing client) were CORBA objects. The whole existing code base was switched to this approach by 4 people during a week. Without being able to modify the generator and regenerating everything (which was part of the daily build process, anyway), there would have been no chance to do this in any reasonable amount of time.

    Stefan
  36. Karl wrote:
    >
    >Even in the overly simple example stated, in the real world,
    >the generated EJBs will contain a lot of logic that is very
    >hard to express with a model.

    Difficult, yes, but not as difficult as writing code by hand. Hand-coding is the most difficult alternative. Hence the push to minimize or eliminate it.

    >UML - being diagrams or not - is very bad in properly
    >defining and maintaining dynamic relationsships between
    >objects.

    This isn't a problem with UML 2, which includes Turing-complete action semantics.
  37. Separate the model from code generation.
    You don't to accept a vendor's generated code,
    nor imho should the vendor provide any generated
    code.

    Instead, write the framework yourself and then write
    the model in terms of your framework. That way many developers can write models and some developers can
    write the code that binds to the model. This way all
    the complaints about sucky code drop away. It's your
    code that's being executed. Without control of the
    code i don't think it will work. Tools should make
    available very rich interfaces for access to the
    parse trees.

    Having done this on several projects it works well
    and is very powerful. It's just another abstraction
    layer up the chain.
  38. <quote>
    Separate the model from code generation.
    You don't to accept a vendor's generated code,
    nor imho should the vendor provide any generated
    code.
    </quote>

    I agree completely - a code generation tool should never force anyody to use a particular architecture, set of frameworks, etc.

    <quote>
    Instead, write the framework yourself and then write
    the model in terms of your framework.
    </quote>

    And again, I strongly agree. Basically, you create a UML profile with stereotypes that match your framework, and reflect changes made to one with the appropriate changes in the other.

    Stefan
  39. This article is crap. I agree that MDA and the associated tools are truly the latest "silver bullet".

    In the article the author states "...Imagine that you introduce a few new attributes to your customer object. You will have to make modifications to the customer bean's remote interface because of the new getters and setters (or, if you're following a value object pattern, to the value object associated with it); you'll need to apply the same change to your DAO, as well as to any other class somehow affected by that change. Adding an attribute is not what I would term a complex change. So why would I have to edit 3-5 different files for a change as simple as that?"

    Adding new attributes to an n-tier, OO, Java system are a piece of cake. What is so difficult about making changes to the parts of the app where the attributes are exposed? Because the system is OO, Java and n-tier, changes like these are easy to understand, easy to communicate and easy to do.

    Think of all of the attribute changes that could be made in the time that it takes to research an MDA tool, learn how to use it, and have multiple egg-headed discussions on the subject.

    Object oriented, Java systems are about as simple as one can get. Ignore the hype.
  40. <quote>
    Adding new attributes to an n-tier, OO, Java system are a piece of cake. What is so difficult about making changes to the parts of the app where the attributes are exposed? Because the system is OO, Java and n-tier, changes like these are easy to understand, easy to communicate and easy to do.
    </quote>

    It's not that black and white. Of course it's not a complex task but it is work. Stupid work. Stupid work is always work that reduces productivity.
    Changing an attribute's name means that you edit several files (some Java code, some XML, some resource bundles,...).
    I think some people dislike MDA approaches just because of the failed CASE hype a long time ago. In fact code generation is already present. Even the worst IDE can generate getters and setters.
    Writing down meta info is a very easy task. Once you have it you can do very nice things.
  41. I'm not against MDA, in some situations, in small controlled doses. But I think that CASE tools and MDA can very easily lead to people worrying too much about "The Big Picture" and not enough about their actual code. What I deliver my client is code that runs and does what they want, and the ability to keep the code running and doing what they want. The rest is just tactics to achieve that end.

    Look, for example, at the example code from Stefans article (I've reproduced it below). This doesn't even come close to compiling! The methods make no sense semantically!

    public class ExampleValueObject {
    private long value;
    private boolean valueNull;

    public boolean isValueNull() {
    return valueNull;
    }

    public String getValue() {
    return value;
    }

    public String setValue(boolean value) {
    this.value = value;
    }
    }

    As for 'idioms' - idioms are useful, but are also very, easily overused. Get/Set methods for attributes are often appropriate. But if I had a dollar for every unnecessary get/set method pair that exposes in public an attribute which should be private then I'd be richer than Bill Gates. The fact that tools will now generate these methods for you automatically has fed the epidemic of over-use of that idiom. Templates to generate code for other common idioms can also be good. But they can lead to bad OO design because it's easy to generate common code repeatedly instead of encapsulating it (expect to see that illness spead soon as MDA tools become more widespread).

    MDA may be able to sometimes reduce the grunt-work a developer has to do. But they increase (not decrease!) the developer's need for thought, care, attention to detail, and an educated awareness of what their running code does.

    Sean Broadley
  42. <quote>
    Look, for example, at the example code from Stefans article (I've reproduced it below). This doesn't even come close to compiling! The methods make no sense semantically!
    </quote>

    You're right, and I'm embarrased and apologize.
    The correct code would be
    public class ExampleValueObject {
    private long value;
    private boolean valueNull;
    public class ExampleValueObject {
      private long value;
      private boolean valueNull;

      public boolean isValueNull() {
        return valueNull;
      }

      public long getValue() {
        return value;
      }

      public void setValue(long value) {
        this.value = value;
      }
    }

    That'll teach me to add code to a text without compiling it.

    Stefan
  43. Will I ever get it right?

    public class ExampleValueObject {
      private long value;
      private boolean valueNull;

      public boolean isValueNull() {
        return valueNull;
      }

      public long getValue() {
        return value;
      }

      public void setValue(long value) {
        this.value = value;
      }
    }

    Damn.
  44. Stefan,

    I apologize for using such a harsh term like "crap". Thanks for the excellent post to get a very good discussion going.
  45. <quote>
    I apologize for using such a harsh term like "crap". Thanks for the excellent post to get a very good discussion going.
    </quote>
    Accepted, and thanks.

    To quote from your original post:

    <quote>
    Adding new attributes to an n-tier, OO, Java system are a piece of cake.
    </quote>

    Could you please elaborate a bit on that? If you look at the last system you implemented - how many places do you have to touch to add a field to one of your dialogs (or HTML pages) that needs to be persisted to the RDBMBS (or whatever data storage you use)?

    I'm really curious; I would be surprised if a non-trivial system with a typical layered architecture would not at least require the developer to touch 3 or 4 different files.

    Stefan
  46. .NET and code generation[ Go to top ]

    The following PDF links are useful read:

    1. Runtime Code Generation with JVM and CLR

    http://www.dina.dk/~sestoft/rtcg/rtcg.pdf

    2. Accelerate Web Application Development with
       Application Generation Software

    http://www.ironspeed.com/pdf/IronSpeed_AppGeneration.PDF

    3. Code Generation Comes of Age: Automatically
       Generate .NET Applications Instead of Hand-Coding

    http://www.ironspeed.com/pdf/IronSpeed_GeneratedotNETApps.PDF
  47. Your example is still incorrect. What do you mean by
    valueNull on a primitive type long? Value 0 is a valid
    value. I beleive your example should read:

    public class ExampleValueObject {
      private Long value;

      public boolean isValueNull() {
        return (value == null);
      }

      public long getValue() {
        // what if the value is null, probably clients check it
        return value.longValue();
      }

      public void setValue(long value) {
        this.value = new Long(value);
      }
    }

    Regrettably, incorrect code is becoming distracting.

    I have faced a issue during my codegen experience. Based
    on the XML model we had in our project, a certain Java
    (initialization) method compiled bytecode size become more
    than 65K. JVM refused to load the class. Since the "model
    driven" setup was "cutom to project", this issue was
    resolved by me by doing XSLT code generation script change.
    I would like to pose a question now:

    How does MDA tools address this kind of issues?

    I am fan of "XSLT based codegen" because of this kind of
    issues. I beleive the MDA case tools should show and allow
    modification of the "transformation program" that they
    generate. In other words:

    MODEL TRANSFORMATION LOGIC AND PROGRAM SHOULD BE OPEN TO
    CLIENTS FOR ANY UNFORESEEN MODIFICATIONS

    Soumen Sarkar.
  48. Soumen,

    The reasoning behind the example (updated now in the article, BTW - thanks, Nitin) was that the object might have a value set to some long, or not set at all. So basically yours is a different implementation of mine.
    Anyway, I think we agree that this is not the major point; what we have here is an example of a (very simple) pattern that should probably be the same for every business object in the system. Let's assume we both are working on the same project. With a non-MDA approach, we would end up with two different implementations - yours and mine. With an MDA approach (and I consider yours to be one, as well - see below), we could argue what is the better implementation and change the pattern in a single place, reflecting the change in all of the code after re-generation.

    <quote>
    I am fan of "XSLT based codegen" because of this kind of
    issues. I beleive the MDA case tools should show and allow
    modification of the "transformation program" that they
    generate. In other words:

    MODEL TRANSFORMATION LOGIC AND PROGRAM SHOULD BE OPEN TO
    CLIENTS FOR ANY UNFORESEEN MODIFICATIONS
    </quote>

    I absolutely, violently agree with this, and this *is* IMNSHO a key characteristic of MDA tools.

    Here is a snippet of what the template for iQgen might look like for the example:

        /**
         * Returns the attribute <%=attrName%>
         * <%=getMetaModel().getDocumentation(attribute)%>
         * @return Value of <%=attrName%>
         */
        public <%=attrType%> get<%=attrNameFU%>() {
            <iqgen:usercode id="<%=\"get\"+attrNameFU%>">
            return <%=instName%>;
            </iqgen:usercode>
        }
        /**
         * Sets the attribute <%=attrName%>
         * <%=getMetaModel().getDocumentation(attribute)%>
         * @param p<%=attrNameFU%> New value of attribute <%=attrName%>
         */
        public void set<%=attrNameFU%>(<%=attrType%> p<%=attrNameFU%>) {
            <iqgen:usercode id="<%=\"set\"+attrNameFU%>">
            this.<%=instName%> = p<%=attrNameFU%>;
            </iqgen:usercode>
        }

    which would generate something like

        /**
         * Returns the attribute value
         *
         * @return Value of value
         */
        public long getValue() {
            //==> Begin Protected Area getValue

            return value;
            //==> End Protected Area getValue
        }

        /**
         * Sets the attribute value
         *
         * @param pValue New value of attribute value
         */
        public void setValue(long pValue) {
            //==> Begin Protected Area setValue

            this.value = pValue;
            //==> End Protected Area setValue
        }

    Other tools work in a similar way. The basic idea is that you have access to your model via a rich API (in our case accessed via 'getMetaModel()') which you can then use to turn into code (or anything else) in whatever way you prefer. The differences between this approach and the XSLT approach you described are mainly the type of language used (declarative vs. OO/imperative) and the fact that - unless you are quite creative - it's not easy to generate the same file(s) multiple times when your model changes with XSLT and preserve the manual changes (in case of iQgen this is done with "user code" sections that are merged into the result). This can be accounte for in the framework, as you described, but violates a sensible constraint: Code generated should not be that much different from hand-written code - ideally, not at all different.

    Stefan
  49. <quote>
    As for 'idioms' - idioms are useful, but are also very, easily overused. Get/Set methods for attributes are often appropriate. But if I had a dollar for every unnecessary get/set method pair that exposes in public an attribute which should be private then I'd be richer than Bill Gates.
    </quote>

    The example was intended to be just that: an example. Getters and Setters alone are definitely not enough justification for using an MDA tool.

    I also agree that exposing every attribute via get/set methods is a bad idea, but this can easily be accounted for by generating those methods only for public attributes, and the set methods only for those that are not read-only.

    Stefan
  50. I must agree. The example code looks horrible. It did not
    make sense to me. However, instead of criticizing this
    aspect of article, I shared my "model driven programming"
    experience with the community.

    As I said earlier, our J2EE based Network Management
    System has 66% of *.java generated due to application of
    "Model Driven Programming" paradigm.

    Soumen Sarkar.
  51. May I summarize this as: if I choose the langauges to program, then UML won't be on the top of the list :)

    We complain that C++ is difficult, Java is too restrictive etc. Now just think about UML! What a terrible task to program in UML. No way, gentlemen!

    UML is nice a nice language to convey design concepts. However, it's totally inappropriate neithor for a detailed design, nor specification. The problem is that it's not well defined. When I've been preparing to take IBM's OOA&D exam, I thought that the best source is three amigos' books. So, I bought three books on UML: reference, guide and process. I had a hard time reconciling the definitions between these three books! What would you expect from the tool which generates the code out of UML definition of the system?!

    C'mon! UML is not for programming. Programming is a communication between people and machines. UML is for communication between people. That's why MDA is a crap.
  52. <Argyn Kuketayev>
    UML is nice a nice language to convey design concepts. However, it's totally inappropriate neithor for a detailed design, nor specification. The problem is that it's not well defined.
    <snip/>
    C'mon! UML is not for programming. Programming is a communication between people and machines. UML is for communication between people. That's why MDA is a crap.
    </Argyn Kuketayev>

    I agree with the first paragraph.

    The second paragraph leads me to suspect you haven't read much about MDA. The key point is that MDA is a relatively well-defined subset of some of the UML diagrams, plus some *semantics* of what happens when input events occur (the *syntax* of ASL is undefined).

    MDA has a sound theoretical pedigree in that its principal concepts have been found useful over the *decades* in multiple different engineering disciplines. But, IMHO, it isn't going to be adequately expressive for all application domains (but nothing is). MDA is not a silver bullet; but it is a bullet.
  53. <quote>
    The key point is that MDA is a relatively well-defined subset of some of the UML diagrams, plus some *semantics* of what happens when input events occur (the *syntax* of ASL is undefined).
    </quote>

    I suppose you meant to write "ASL is a relatively ...", not MDA, right?
  54. Let me ask a simple question (I admit I haven't read all the MDA docs yet).

    In Stefan's article Fig. 1, there's a 1-to-N relation between Customer and Order. While a line with 1 at one end and 0..* at the other seems adequate enough for a business analyst's perspective, it's quite vague for me as a developer. E.g. (1) Is the relationship read-only? (2) For reading, is there a method to fetch all the Customer's orders (eg from the database) OR is there an iterator to retrieve them one by one? The choice of lazy/eager fetching is transparent for business, but I know that it has a huge effect on me.

    Thinking more specifically of Java, the possibilities grow further. It seems reasonable to expect a getOrders() method in Customer but what would it return: Iterator, List? Even with JDK 1.2 container classes, there are several alternatives, and with generics coming up in JDK 1.5 we're looking at even more!

    So the question is, where does this stuff go - which of the 3-letter acronyms?
  55. <quote>
    Thinking more specifically of Java, the possibilities grow further. It seems reasonable to expect a getOrders() method in Customer but what would it return: Iterator, List? Even with JDK 1.2 container classes, there are several alternatives, and with generics coming up in JDK 1.5 we're looking at even more!
    </quote>

    An excellent question. In my experience, in a trivial system it might be enough to agree *once* on how you want 1-to-N relations to be managed, e.g. as Collections of a specific type. In a more realistic system, there'll likely be a number of different patterns - say e.g. three: One for associations that are displayed in the user interface, one for a small number of values (e.g. for populating drop-down listboxes), and for large sets. So in this particular case you would design three different transformations, and extend the model by using a stereotype on the association to select the one appropriate. This is, of course, rather limiting. But I would consider this to be a good thing, since I would not want to have the same problem (managing relations) in 30 different ways in one system.

    <quote>
    So the question is, where does this stuff go - which of the 3-letter acronyms?
    </quote>

    Your framework and its patterns are the basis for a project or company specific modeling language. Using UML, this would be called a profile; in the future, you might want to specify a "real" meta-model using MOF.
  56. <quote>
    As for 'idioms' - idioms are useful, but are also very, easily overused. Get/Set methods for attributes are often appropriate. But if I had a dollar for every unnecessary get/set method pair that exposes in public an attribute which should be private then I'd be richer than Bill Gates. The fact that tools will now generate these methods for you automatically has fed the epidemic of over-use of that idiom. Templates to generate code for other common idioms can also be good. But they can lead to bad OO design because it's easy to generate common code repeatedly instead of encapsulating it (expect to see that illness spead soon as MDA tools become more widespread).
    </quote>

    MDA is definitely not a silver bullet. MDA won't turn a bad design into a good system. The key points are that an MDA approach, if used correctly, will enable you
    - to evolve your business model and your technical architecture independently from each other
    - to reduce the amount of work required to conform to your framework's usage patterns
    - and thereby increase your productivity, reduce costs, and protect your investments, and bla bla bla ... the usual marketing stuff (which I actually happen to believe in in this particular case).
  57. "Look, for example, at the example code from Stefans article (I've reproduced it below). This doesn't even come close to compiling!"
    -- Sean

    Well, I think we've just seen the true nature of hand-coding.
  58. From a theoretical standpoint, modelling is closely related to semiotics. We have a sign (the thing we are modelling), a symbol (the notational representation of the sign) and mapping the two is a HUMAN observer.

    Modelling is a human process, although computers can be involved, they do not understand conceptual models, but can be really useful for TRANSLATING different notations (and are of course great tools for aiding the modelling process). For example; translating diagramatic notations into source code - the underlying conceptual models are the same, it is irrelevant whether we use boxes to model objects or 'public class MyObject {}'

    Languages like UML contain extensive conceptual models that describe the actual underlying concepts and 'things' that are being modelled - objects, actors, processes, etc etc. In terms of diagramming we are really talking about a standardised notation for the underlying conceptual framework. The symbols we use are not as remotely important as the concepts they represent. In fact, it is part of the UML specification that the actual symbols used to represent the different concepts can be changed - as long as everyone agrees as to the symbols being used, any diagramatic notation can be negotiated.

    The UML spec also contains information for business modelling, which many people are not aware of - the conceptual model at the business level looks at at objects at much higher levels of abstraction: dealing with domain level business objects and entities. Code-level UML models the actual programmatic representations of these domain objects. However, the standardised diagrammitc notations for business objects is exactly the same as program objects - as long as the HUMANS reading the diagrams understand at which level they are dealing, they can apply the correct conceptual model and understand the thing being represented.
  59. For the last one year I have working with a tool that auto-generates EJB and .NET components from a platform-independent model. And I completely agree with Stefan's arguments and believe that MDA is definitely a the way of the future.
    However, having also developed applications using MDA, I feel that unless there are some really good, stable tools supporting it, it will be difficult to build large scale complex applications.
  60. I find discussions like this to be interesting. Not due to the merits of the product discussed, but because it shows that people tend to gravitate to the latest, newest thing. The hype surrounding MDA has been tremendous but many people just don't realize that this is NOT a new idea or innovation.

    If you really want to see how it is done, check out Project Technologies (www.projtech.com). They developed a methodology years ago for doing model driven development. I remember taking a class from them about 12 years ago teaching these very concepts. Yes, it did not use UML at the time (since UML wasn't in favor back then). The method has been update to use the UML diagram notations now.

    It seems to me that MDA is just the bastard child of the Project Technology principal's ideas.
  61. Can't comment on ProjTech, since I don't know them, but it's definitely true that MDA is not revolutionary or even new. But that does not turn it into something bad - on the contrary. In my opinion the benefit is that standards are now emerging which will allow people to choose from different implementations, while keeping their existing investment.

    I very much prefer a standard based on something that has been tried and tested than one that is really new and revolutionary.
  62. <Stefan Tilkov>
    Can't comment on ProjTech, since I don't know them, but it's definitely true that MDA is not revolutionary or even new. But that does not turn it into something bad - on the contrary. In my opinion the benefit is that standards are now emerging which will allow people to choose from different implementations, while keeping their existing investment.

    I very much prefer a standard based on something that has been tried and tested than one that is really new and revolutionary.
    </Stefan Tilkov>
     I emphatically agree with that; indeed it is one of the reasons I bothered to learn Java (unlike Delphi, C++, VB, ...).
    In the original Java whitepaper I could see (a) what features were included (b) why they were included (c) what was excluded (and why) (d) how all the features played well together and, most importantly (e) that there was nothing new.

    Gosling et al actually knew the practical and theoretical experience gained over the previous decades, and applied it.

    I get the same feeling with MDA, but I'm not yet convinced that its limitations are understood.
  63. Ronald wrote:
    >
    >If you really want to see how it is done, check out Project
    >Technologies (www.projtech.com). They developed a methodology
    >years ago for doing model driven development. I remember
    >taking a class from them about 12 years ago teaching these
    >very concepts.

    About 10 years ago I also took their class, met their development team, and went on to successfully use and extend their BridgePoint tool. We demoed as a customer success story for Ivar Jacobsen, a co-inventor of UML. Now UML has MDA. Surprise, surprise.

    >It seems to me that MDA is just the bastard child of the
    >Project Technology principal's ideas.

    Immitation is the most sincere flattery.
  64. A lot of the doubters of the MDA approach
    - refer back to previous experience ('don't believe code generation works')
    - or believe UML is too imprecise.

    Our experience with the JeeWiz generator is that this whole approach does work, dramatically well.

    A key difference with 'MDA' - i.e. in common usage, as a way of mapping models to code - compared to previous generation approaches is that code generation is being based on a 'model'.
    This gives you the rich environment you need to build code that expresses fairly complex artifacts.
    Actually, it's not just code you can produce - any artifact that references an attribute from the model should be autogenerated, including build jobs, deployment descriptors etc.

    A lot of people don't carry UML through to the generation stage because

    - there are no standard extension to specify the extra information needed to generate real code.
      But that's a good thing: stereotypes and tagged values can be added to give this extra information, and these can carry forward

    - the XMI interface is not standard enough to support direct manipulation by code generators.
      For this reason, we use an XML format of the model - described by a meta-model of course - which is simpler and more specific than XMI.
      We have a semi-automated way of generating the XSL-T transforms to map the various XMI styles into the simpler XML.
      Of course, you can also enter the XML directly (or generate it...)

    By using the simpler XML format of the model as the basis for generation, some neat features fall out.
    Let's say we have an entity defined in the UML, and we're going to the J2EE platform:

    - we can add the standard CRUD methods as additional XML on the fly - we just slip some XML into the model before the generation stage
    - we can also implement many standard patterns in exactly the same way - the J2EE home/local/remote interfaces, PK classes, value objects
    - the artifact generation stage can the turn these various classes into the type of code for the environment, and also generate a range of proxies and wrappers for various tiers of usage.

    In other words, the same type of tools you use to generate artifacts (we use Velocity, which works really well) can be used to generate on-the-fly extensions to the model.
    (We prefer to do this on-the-fly rather than generate a real PSM - you don't want people to start editing it).

    The end-game is very important: it is possible for the MDA tool to generate all the infrastructure in such a way that the target interface the application programmer uses is platform-independent - just depending on Java, not on J2EE, JDO, etc.
    As Stefan said, this allows you to change the architecture without impacting the business logic, which is a huge benefit for project management.
    We've discussed this in terms of J2EE applications, but the principle applies to any type of programming where there is a pattern.

    Any programmers who think this is likely to do them out of a job will be OK - they'll end up doing the meta-programming, building the templates to realise the architecture.

    Nice article Stefan.
  65. On the database-oriented projects I have worked on over the last few years, the modelling, persistence, etc portions comprised only a small percentage of the development effort. The bulk (at least 70%) of the time was on the UI (either Swing or JSP). So while MDA may help some, it will not significantly affect delivery dates.
  66. Hi,

    I've been using Oracle's "Headstart" for years, and it DOES work, although it basically generates the view (using an MVC analogy), the model, and much of the controller ... leaving you to code data centric business rules and data activity rules in most cases.

    The true problem with it, is that the learning curve is HUGE and it's highly proprietary ... and I can't see any other code generation approach changing that very much.

    I'm still a big fan of generated approaches, but "Model Driven" is a much better way to think of it. Abstraction is one of the best tools we have, and dealing with our technical and functional problems at a level away from the code does (I think) produce better solutions.

    My experience has been that any development method that is not simply "coding", asks increasingly more of your development team, and there basically aren't enough good people around to carry that kind of thing in any convincing manner. I'm still looking for a something that's both simple and effective, and I haven't come accross it yet, but I think the collision of MDA and Java might be a rich field of endeavour if anyone can introduce any standards to it. The particular problem will be the RE-generation, not the generation.

    Dan.
  67. What I see as a problem with code generation (and which IMHO cannot be solved) is what was recently discussed under "Leaky abstractions":

    1. You might very well design your system in a model in a way that the generated code will do, _what_ the system is supposed to do. The generated code will fulfill the primary purpose of the system (e.g. transform some input parameters into some expected output params)

    2. However, in a typical project there are always more requirements than what the system is doing, restricting the number of potential solutions for the problem domain into a few number of possible solutions. An example of such an additional requirement is a performance restrictions. So, it is not only about _what_ the system will do but also _how_ it will do it.

    This second type of restriction means, that the developer who designs the model exactly knows, what implications his design have on the generated code. However, this knowledge is usually not available from the product, that translates the model into executable code, hence the word "leaky abstractions".
  68. An good example of MDA--OptimalJ[ Go to top ]

    Has anybody heard about OptimalJ, a commercial MDA tool? I have tested OptimalJ and it has achieve a lot of functions of MDA already. you can download a free trial version and find more details for yourself. Very interesting.

    http://www.compuware.com/products/optimalj/
  69. Another good product that is worth looking at is ArcStyler, from Interactive Objects. It goes a lot further than products such as OptimalJ and can be really said to be MDA-compliant. Interactive Objects have some good examples (customer stories) on their web site too. You can download a test copy find also lots of information about MDA and code generation. There's a big difference between "traditional" code generation tools and the correct MDA approach ;-)and it's well worth taking a look.

    http://www.io-software.com