Article Discussion
The Real Meaning of Model-Driven Architecture
Summary: In this interview with Artima, Andrius Strazdauskas, Gary Duncanson, and Daniel Brookshier of No Magic discuss the goals of Model Driven Architecture, or MDA, and explain why they think it can improve programmer productivity and software quality.
15 posts.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: March 8, 2008 4:21 AM by Ivan
    Bill
     
    Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
    The Real Meaning of Model-Driven Architecture
    June 27, 2007 0:00 PM      
    In this interview with Artima, Andrius Strazdauskas, Gary Duncanson, and Daniel Brookshier of No Magic discuss the goals of Model Driven Architecture, or MDA, and explain why they think it can improve programmer productivity and software quality.

    Please check out this JavaOne 07 interview:

    http://www.artima.com/lejava/articles/javaone_2007_no_magic.html

    What is your opinion of Model-Driven Architecture and the technique of code generation in general? In what ways have you used MDA or code generation in the past that has, or has not, worked out well?
    • Sumant
       
      Posts: 2 / Nickname: sutambe / Registered: September 8, 2006 7:43 AM
      Re: The Real Meaning of Model-Driven Architecture
      June 28, 2007 4:46 AM      
      My general understanding is that MDA can be easily used to automate code generation of the 'technical concerns'. Some technical concerns are harder than others. For example, generating thread-safe code from a model would be much
      harder than generating code that does one well-defined task really well e.g., object/process liveliness monitoring code. Once you decide upon a general technique you want to use to monitor liveliness of a process, the same code can be generated again and again taking configuration parameters from the model. Note that this is not a library, in which case you include headers, link with it and so on. When MDA is applied in this style, you don't think about the process monitoring concern while coding your business logic. A recently published research paper talks about monitoring code generation in the context of component oriented systems, where the idea of a 'container' fits very well with the idea of abstracting away technical concerns.

      http://www.dre.vanderbilt.edu/~sutambe/documents/pubs/isas07.pdf
      • Jules
         
        Posts: 2 / Nickname: jules2 / Registered: March 4, 2006 9:24 AM
        Re: The Real Meaning of Model-Driven Architecture
        June 28, 2007 5:54 AM      
        Generating thread safe code isn't hard at all, just don't use global mutable state, e.g. a sane concurrency model.
    • nes
       
      Posts: 9 / Nickname: nn / Registered: July 11, 2004 6:19 AM
      Re: The Real Meaning of Model-Driven Architecture
      June 29, 2007 5:57 AM      
      1. Graphical interfaces are not necessarily better than textual ones. I work with an ETL tool that is graphical: IBM WebSphere DataStage. The nice thing about it is that understanding programs written in it is easy. A screenshot of a program gives you an instantaneous high-level view of what it is doing. The bad thing is that the tools to manipulate the code are worse than windows notepad for code editing. Many of these GUI tools look fancy on the outside but lack good copy and paste, search, replace, refactoring, formatting, etc. At a more fundamental level they usually don’t support much abstraction either. You can’t just say: this thing is the same as over there just use that. You have to recreate everything again.

      2. Model-Driven Architecture. I am a believer in Model-Driven Development and Architecture in the sense that you define your terms first and create a good relational database with that. The rest is usually just CRUD with various degrees of presentation fanciness.

      BTW does anybody know of a good tool that can automatically generate good CRUD code given a database schema? I am talking about a tool that understands the whole relationship graph of a database and allows creating edit and display of data from multiple tables at the same time in a sensible way. Most of business systems I have seen start out as basic CRUD and evolve from there. It would be nice to be able to have good tools specialized in generating maintainable code and reverse engineering for just that.
      • James
         
        Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
        Re: The Real Meaning of Model-Driven Architecture
        June 29, 2007 6:56 AM      
        > 1. Graphical interfaces are not necessarily better than
        > textual ones. I work with an ETL tool that is graphical:
        > IBM WebSphere DataStage. The nice thing about it is that
        > understanding programs written in it is easy. A screenshot
        > of a program gives you an instantaneous high-level view of
        > what it is doing. The bad thing is that the tools to
        > manipulate the code are worse than windows notepad for
        > code editing. Many of these GUI tools look fancy on the
        > outside but lack good copy and paste, search, replace,
        > refactoring, formatting, etc. At a more fundamental level
        > they usually don’t support much abstraction either. You
        > can’t just say: this thing is the same as over there just
        > use that. You have to recreate everything again.

        Exactly. The sometimes stated assumption that GUI tools inherently improve productivity is patently false. Often I find GUIs to cause very significant productivity decreases. Usually development in GUIs ends up requiring a much larger amount of mindless drudgery.

        We have a GUI based tool that we use right now and not only does it slow me down a lot, it's really hard to figure out what things do because everything is buried in stupid little text boxes and dialogs. Instead of just scanning a developers work for errors, you must click on a billion little buttons to see what they've done. I ended up writing a style-sheet to convert their inscrutable XML export into something that we could work with. Actually, once exported to a usable format, I was able automate a lot of what is done in reviews.

        GUIs have their place but it's clear to me that they should play a secondary role to text representations. The idea that GUI is always better is an outdated idea that's as stale as the slogan "the power of GUI at the speed of DOS" on an old software box near my desk.
        • nes
           
          Posts: 9 / Nickname: nn / Registered: July 11, 2004 6:19 AM
          Re: The Real Meaning of Model-Driven Architecture
          June 29, 2007 9:05 AM      
          > idea that GUI is always better is an outdated idea that's

          If GUIs were so supperior to text we would be writing in Egyptian hieroglyphic logograms instead of the Latin alphabet.
    • Guilherme
       
      Posts: 1 / Nickname: guilhermau / Registered: August 27, 2007 1:12 PM
      Re: The Real Meaning of Model-Driven Architecture
      August 27, 2007 6:20 PM      
      The main goal of the MDA is generate code from a model designed from CASE framework.

      There are several frameworks that can do this job , but i really want to know which functionalities a MDA Framework must have to be consider a good one .
    • Alfredo
       
      Posts: 1 / Nickname: cheesy / Registered: October 21, 2005 7:01 PM
      Re: The Real Meaning of Model-Driven Architecture
      September 15, 2007 0:01 AM      
      First, I think MDA is highly overrated. I believe it is useful in situations where the model and what the generated code is supposed to do is fairly straightforward. The often quoted example of hibernate, Spring DAO, domain object falls into this category. But for more complex things, MDA is completely useless. If the model gets complex it is hardly understandable, especially with graphical models. MDA works for things that are fairly declarative in nature. As soon as imperative stuff sneaks in, the model becomes overloaded.

      A huge disadvantage I see with all MDA tools I've seen is diff support. With code I can make a diff between two versions and immediately understand what has changed. With a graphical model (that is probably stored in XML on disk) this is much harder, sometimes even possible.

      Additionally, in some cases code generation is superfluous. I worked at a company that has a graphical designer for (business) processes. Instead of generating code from the model, the model was executed (interpreted) directly.

      One advantage of the model-driven approach (whether using code generation or not) is that the documentation stays up-to-date with the code. In the example I've mentioned this was a huge advantage because before the documentation was always hopelessly updated. I do not blame anybody for that. Updating twice the same thing (at least semantically) is just too much to demand of developers.

      And I don't believe this marketing talk that the developer has to write almost no code and that his life gets easier. In many cases the life gets harder, because he has to learn yet another programming environment (the model editor).
    • Burkhard
       
      Posts: 1 / Nickname: hephaistos / Registered: June 28, 2007 5:38 PM
      Re: The Real Meaning of Model-Driven Architecture
      June 28, 2007 10:53 PM      
      > I think the key thing about MDA, Model Driven Architecture,
      > is the model represents the code, and the code is produced. > It's generated.
      So far I agree. But as not all code is created equal, he developer's task now is to define the rules that generate code from models.
      But this is an area where support is almost nonexistant. You could write your on XSLT to transform XMI to Code. But XMI spec is huge and concrete XMI varies from tool vendor to vendor (it's great to have standards, isn't it ;-) so this is hard work.
      Or you could wait until some tools support QVT (which has OMG's blessing). But QVT is as spec is also huge [see http://www.omg.org/docs/ptc/05-11-01.pdf](and not finalized as far as I know) so I doubt that this will be much easier.

      My solution so far:
      use my own small (textual) modelling language
      and write my own code generators (I use Lisp/Scheme).
      I know this approach does not scale to large projects but for the small to medium sized projects I found it very productive.

      B. Neppert
      • Ivan
         
        Posts: 3 / Nickname: ivanko98 / Registered: March 7, 2008 9:35 PM
        Re: The Real Meaning of Model-Driven Architecture
        March 8, 2008 4:00 AM      
        ATL - Atlas Transformation Language (I think thats what it stands for) is pretty elegant and it might not have been approved by the MDA Group but then again who cares, they're being accepted as the model-to-model transformation language in the Eclipse modeling project.

        There are a lot of transformations already created for various metamodels so its examples to learn from, and it also means its debugged more than other frameworks.

        Its not just a language however but a model transofmration virtual machine, with its own model oriented instruction set, so it not only runs ATL but can also run other transormation languages that MDA ends up accepting for their QVT request for proposal. Very flexible, and a more longterm outlook which is great.

        language is cool to work with, and not too complicated. sufficient plug-in for eclipse available as well for debugging and coding. talks of a modeling environment being put together as well, so you can model other model-transformations (talk about abstraction ;) ).

        XMI is not something that I personally take very seriously. Its overrated, and something that I think missed its goal. Just the fact that there are a bunch of slight variations between most tool vendors kills the point. ECore is safe and productive, and evolves on need as oppose to a bureaucracy moving like a grandmother thats not in shape.
    • James
       
      Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
      Re: The Real Meaning of Model-Driven Architecture
      June 28, 2007 6:10 AM      
      > What is your opinion of Model-Driven Architecture and the
      > technique of code generation in general? In what ways have
      > you used MDA or code generation in the past that has, or
      > has not, worked out well?

      The biggest problem I've seen in the past was that round trip engineering was non-existent or very weak/unstable. The code that was generated was unreadable.

      I've seen so many classes that have roseid comments but rose is no longer used. The short of it was that using the tool was more trouble than it was worth.

      It's encouraging to hear that MDA is no longer trying to do eliminate code but I still have a couple of concerns.

      1. My experience is that sequence diagrams are a monumental waste of developer time. It's the slowest way I can think of to write code.

      2. Raising the abstraction does not imply graphical representation. This seems to be the biggest flaw in the MDA theology. I have a related comment here:
      http://www.artima.com/lejava/articles/javaone_2007_david_intersimone.html

      I know there is a standard file structure for UML (more than one probably) but is it something people go into an edit? GUI is not alway better than text based. I use a graphical file view for most normal file management tasks. But if I have to do one thing to 10,000 files, I'm not going to do it in a GUI. Text based languages are, in general, much more powerful than GUI based representations. I don't know if this has to be the case but whenever I've used a tool that had limited or no support for text based editing, I end up clicking clicking clicking all day long to accomplish a task that could be done with a short script or command. A long time ago, I spent an entire day with a whiteout container taped to the O on my keyboard. I'm not saying this will happen with these MDA tools but I want a text based representation anyway.
      • Giancarlo
         
        Posts: 1 / Nickname: giancarlo / Registered: February 12, 2007 11:12 PM
        Re: The Real Meaning of Model-Driven Architecture
        June 29, 2007 2:49 PM      
        > The code that was generated was unreadable.

        The Model is your 'source' code while the code is generated.
        The goal of MDA is that you may generate your business rules independently by the platform/application committed.
        A class diagram will be transformed into a POJO object, EJB, copy cobol, xml schema etc. you may redefine you framework without rewrite a hundred of business rules by hand, you have only to change the transformer.
        Through uml paradigms static/dynamic diagrams, you trace the behavior of entire system.
        You give to the business unit the power of define rules themselves.
        The MDA approach is good both in small than in large application domain with different features of course (you have to justify the work of MDA development), but first model you application, model the data, keep MDA in mind. Use simple xml or your own model files definition or XMI or a model framework (EMF), but the concept is the same.

        Yes, the generated code will be unreadable but as the definition it is generated, untouchable (despite you may use jmerge for merging generated and hand-modified code).
        • James
           
          Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
          Re: The Real Meaning of Model-Driven Architecture
          July 2, 2007 4:55 AM      
          > > The code that was generated was unreadable.
          >
          > The Model is your 'source' code while the code is
          > generated.
          > The goal of MDA is that you may generate your business
          > rules independently by the platform/application
          > committed.
          > A class diagram will be transformed into a POJO object,
          > EJB, copy cobol, xml schema etc. you may redefine you
          > framework without rewrite a hundred of business rules by
          > hand, you have only to change the transformer.
          > Through uml paradigms static/dynamic diagrams, you trace
          > the behavior of entire system.
          > You give to the business unit the power of define rules
          > themselves.
          > The MDA approach is good both in small than in large
          > application domain with different features of course (you
          > have to justify the work of MDA development), but first
          > model you application, model the data, keep MDA in mind.
          > Use simple xml or your own model files definition or XMI
          > or a model framework (EMF), but the concept is the same.
          >
          > Yes, the generated code will be unreadable but as the
          > definition it is generated, untouchable (despite you may
          > use jmerge for merging generated and hand-modified code).

          Yeah, I get the theory. The problem is when you need to debug the system or realize that your MDA tool is crap, as we did.
          • Raoul
             
            Posts: 20 / Nickname: raoulduke / Registered: April 14, 2006 11:48 AM
            Re: The Real Meaning of Model-Driven Architecture
            July 13, 2007 4:35 PM      
            James, thanks for always keeping it real. I wish I were rich so I could put you in charge. ;-)
          • Ivan
             
            Posts: 3 / Nickname: ivanko98 / Registered: March 7, 2008 9:35 PM
            Re: The Real Meaning of Model-Driven Architecture
            March 8, 2008 3:53 AM      
            well yes that is the theory, and debuging support in many tools is horrible (and I have my doubts about companies making it difficult on purpose so that they can charge for consulting services instead of the client being able to do it all himself, but thats a whole new discussion) but I see a few possible solutions that could improve the ease of debugging.

            If you could target the source node/object in the model (Ecore,or some other) you would know at which location to look for:
            1. logical/semantic errors in the model/metamodel
            2. errors in the code generator templates (bad code being generated)

            so on system exceptions or when you see something wrong (or have doubts about the state of the running application) you would need a link to the state/location in the model that the generated code is executing at (this is the target of the source node in the model that I mentioned above).

            to do that you would embed ID's of model objects attributes/classes/instances in the code and then get to it either through log mining (building a Lucene index up for example and then harvesting) or through message sending (for real-time, analysis), or if you want to be fancy do some code injection when compiling the code (in case of java and JVM bytecodes).

            Text/code wise this can easily be embeded in every generated class/method via the templates when the code is generated; code injection I havent messed with in practice but Im sure there are frameworks/tools that are simple to utilize.

            once you get this match you just query the model for that match and then highlight the nodes in the model.

            Im guessing a variation of this method is what is used in MetaEdit+ which has a cool feature that you can run the application and the model diagram will highlight the nodes/elements that are currently being executed (when the relation with the real code is used)

            please if you find false assumptions in my thinking above let me know, as I havent gotten to this part of the archtiecture for my own toolset but its coming up, Im working on other core parts and a few metamodels first, to automate some of my development.
      • Ivan
         
        Posts: 3 / Nickname: ivanko98 / Registered: March 7, 2008 9:35 PM
        Re: The Real Meaning of Model-Driven Architecture
        March 8, 2008 4:21 AM      
        <<<The biggest problem I've seen in the past was that round trip engineering was non-existent or very weak/unstable. The code that was generated was unreadable.>>>

        well this too depends on how you do it.
        agreed i thought about it too and if the level of abstraction and the code level are too far from each other, sure, it would be very difficult to match between them in a fast intutitive way. but thats why you have transformations, you transform your own super-hight abstraction level layer into an intermediate (more implementation layer) and than add stuff to that to define more how it works, and then you translate that to UML, which is 1:1 with the code, so its a direct translation.

        sure you can go directly from the abstraction to UML, which is fine too, but its more mental work then going at it with inbetween levels where you have time to progressively dig deeper into the implementation, so its easier on the frustration ;). Later to ease maintenance (or reduce complexity) you could merge some of these inbetween metamodels, but then again, this could very easily increase the complexity since now you would have larger metamodels to deal with, hence more complicated transformation programs.

        <<<I've seen so many classes that have roseid comments but rose is no longer used. The short of it was that using the tool was more trouble than it was worth.>>>

        not so.
        yes it takes longer for the learning curve to happen, and to setup tools, write transformation programs, and code generation programs, and to define the metamodels, than to just jump into code and start hacking. But its crystal clear that code writing is by far the smallest part of any but the most basic projects, and instead debugging is the major time -consumer. With code generation refactoring becomes trivial comparing to regular hand coding since you're just tweaking a limited set of code generatiors as oppose to going through the entire code base (even if you're using plugins that help with searching). Also matching requirements and other configuration oriented work becomes transparent, and a much richer set of domain specific tools can be built on top of a well defined model than on top of pure code without a clear source model.

        Its a tools problem, not a concept problem. As tools get better the approach will make more sense.
        its interesting that the avionics industry is driving a lot of innovation in this area. For example 70% of any military/civil airplane project goes on building/debugging its software, and so modeling is getting bigger and bigger there. dig and you'll see that lockeedMarting is pushing a lot of model oriented resaerch, since it can affect debugging so much.

        Its much easier to debug and logically check different models, and progressively decrease the abstraction, through intermediate metamodels. that way when you get to concrete code level the only thing that could go wrong is bugs in the API's, or in the code generators. those are relativelly easy to fix. The main logical and bad-architecture bugs were uncovered in the modeling stage, and thats why the concept is correct