Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Programming Technology

Pros and Cons of MDA Code Generators? 62

Posted by Cliff
from the code-writing-code dept.
amartel asks: "Four years ago, Ask Slashdot asked if anyone was using a Model-Driven Architecture. The number of MDA tools are now almost overwhelming, and I strongly believe that comments to the same questions would be rather different nowadays. What are the drawbacks, difficulties and limitations of MDA? What percentage of code can actually be generated? I would like to add a few more: is it realistic to create a custom GUI rather than CRUD operations with these tools? Finally, what about Microsoft, the new competitor on the scene, and their DSL Tools?"
This discussion has been archived. No new comments can be posted.

Pros and Cons of MDA Code Generators?

Comments Filter:
  • by avalys (221114) on Monday February 20, 2006 @08:56PM (#14764794)
    The first step to recovery is admitting you have a problem...

    • by meburke (736645) on Monday February 20, 2006 @10:19PM (#14765106)
      Yup-

      I quit using drugs and alcohol 21 years ago, and I laugh at some of the beer-driven and pot-driven architecture of some of my early code. I didn't generate any MDA-driven code, generally because when I was doing MDA I got too horny and went looking for women. MDA is somewhat passe now, though. I think cPanel is a good example of Ecstacy-driven architecture, although I think there is some crack influence, also....8-)
    • From Good Morning, Vietnam [imdb.com]:
      [Lt. Steven Hauk uses Army jargon to refer to a press conference to be given by former Vice-President Nixon]
      Adrian Cronauer: Excuse me, sir. Seeing as how the V.P. is such a V.I.P., shouldn't we keep the P.C. on the Q.T.? 'Cause if it leaks to the V.C. he could end up M.I.A., and then we'd all be put out in K.P.
  • MDA - for gaming (Score:5, Interesting)

    by QuantumFTL (197300) * <justin DOT wick AT gmail DOT com> on Monday February 20, 2006 @08:56PM (#14764795)
    I really like MDA for game creation because it allows me to focus on game mechanics (great for simulation/conquest games) rather than coding. With all the tweaking of game mechanics and in-game entities, code changes can be very tedious. Having auto-generated database and XML mappings doesn't hurt either!
  • Borland's ECO (Score:5, Informative)

    by Mr_Tulip (639140) on Monday February 20, 2006 @09:06PM (#14764841) Homepage
    I have previously used Borland ECO [borland.com] to create some simple MDA applications, and overall, found it a useful tool.

    The implementation of said tool was unfortunately fairly mediocre, and I finally gave up on trying anything non-trivial using ECO, after the third time that the source code and model became 'out of synch' and my 1000's of lines of generated code would not compile.

    If I had the time, I would like to try an updated version of ECO, or perhaps another alternative, but overall, I still prefer the safety net of being in control of the coding process, and actually understanding what is going on under the hood.

  • My advise... (Score:3, Interesting)

    by malraid (592373) on Monday February 20, 2006 @09:47PM (#14764951)
    Pick a tool that you are comfortable with, code with it. It should be fast to code. Once you have your application working, it might become obvious that you need more control over your architecture. Then you are at square one, writing a costume MDA that works for you. At least that's how it happened to me. It might sound like re inventing the wheel, but I feel there's a time and a place to REALLY tweak your code to make something great. I've been migrating my application to my own architecture, and while it still needs some tweaking and optimizing, the product is quite nice. In fact right now it does a couple of things that some experts believed that were impossible.
  • Mmmm, MDA (Score:4, Funny)

    by RedDirt (3122) * on Monday February 20, 2006 @10:26PM (#14765130) Homepage
    Oh, wait ... you mean Model Driven Architecture as opposed to Monochrome Display Adaptor. And here I though I could make a killing unloading all the old Hercules cards in my closet. Nuts.
    • by Anonymous Coward
      Oh, wait ... you mean Model Driven Architecture as opposed to Monochrome Display Adaptor. And here I though I could make a killing unloading all the old Hercules cards in my closet. Nuts.

      ...and I was so sure you were talking about Methylenedioxyamphetamine [erowid.org].

      • I'd better turn in my geek license, since I first parsed it as something having to do with Jerry's kids.
    • Crap, was I the only one whose first thought was Missile Defense Agency?
  • There's always been a fundamental disconnect between the underlying model (data and their relationships to one another) and the tasks that users need to perform. Nearly always, users need to bring together data from disparate parts of the model to perform their tasks, generally in the same context (e.g on the same web page or in the same window).

    I'm a WebObjects hacker, and I've tried to use the Direct-to-Web and Direct-to-Java Client technologies as the basis for an application many times. These read the u
  • MDA vs MDD (Score:3, Informative)

    by r.jimenezz (737542) <rjimenezh@FREEBSDgmail.com minus bsd> on Monday February 20, 2006 @10:59PM (#14765287)
    I'm all for model-driven development (MDD). My MSc thesis was about extending an Eclipse plug-in that supports an architectural description language (see http://www.aadl.info./ [www.aadl.info] When I learned what the realtime industry (particularly avionics) were used to doing with MetaH, I instantly begun searching for ways to apply this on other domains. Two years later I feel I'm getting closer, but not quite there yet :)

    However, I really don't like OMG's MDA. There's an article on the Web by David Frankel that explains very well why UML isn't quite up to the task (see http://www.bptrends.com/publicationfiles/01-04%20C OL%20Dom%20Spec%20Modeling%20Frankel-Cook.pdf [bptrends.com], and see also http://www.martinfowler.com/ieeeSoftware/mda-thoma s.pdf [martinfowler.com]).

    This is not to say I fully agree with Microsoft's DSL and Software Factory concepts. I certainly see more debate is needed. In a sense, MDA is bad because I feel it will stall the debate, as vendors rush to implement their tools around a model some considered flawed, and a great many just plain hard to use in practice.

    • Re:MDA vs MDD (Score:4, Insightful)

      by -ryan (115102) on Monday February 20, 2006 @11:49PM (#14765482)
      My MSc thesis ...

      I wish you guys still in school or freshly graduated knew how often the rest of us roll our eyes every time we hear "my thesis" or "my prof". Your college education will be of marginal vaule to you as a programmer. Most of what you use will be from experience gained after you graduated. You won't necessarily be a good programmer just because you made good grades either.

      However, I really don't like OMG's MDA. There's an article on the Web by David Frankel that explains very well why UML isn't quite up to the task (see http://www.bptrends.com/publicationfiles/01-04%20C [bptrends.com] OL%20Dom%20Spec%20Modeling%20Frankel-Cook.pdf, and see also http://www.martinfowler.com/ieeeSoftware/mda-thoma [martinfowler.com] s.pdf).

      I have an immense amount of professional respect for Martin Fowler. I'd like to qualify some of his and others informed statements about MDA and UML. There are a number of folks out there that tend to take casaul connections to the extreme (i.e. what works for some will work for all). I beleve that Martin was trying to guard his hearers against such thoughts. I think what he meant was that UML in it's entirety is not declarative enough (or just plain flexible enough) to serve as the sole language by which to holistically describe computer programs. This is an easy pill to swallow, because in fact, UML (plus OCL) is (in my humble experience) declarative enough to at least describe the entities of a system, the roles they play, their values, and the relationships betweent them. I wouldn't push for more however... really... I don't even see a benefit.

      What makes *that* example usable or unusable however, really boils down the implemenation of the given MDA tool.

      I for instance have had great success with a tool called AndroMDA [andromda.org]. The code it generates is quite well formed and organized. I am so happy and impressed with the code it generates that I have actually learned a few things just by reading the generated code. This is a far cry from the "yuck" days of Rational Rose 1.0.

      • My MSc thesis ...

        I wish you guys still in school or freshly graduated knew how often the rest of us roll our eyes every time we hear "my thesis" or "my prof".

        I fullheartly don't agree!

        First of all Mr. Parent has a thesis where he is working on that matter. So, how would you want to refer to it? Like: well, there is a paper from a dude 'insert link' that I find intreresting?

        Your college education will be of marginal vaule to you as a programmer. That only depends on the quallity of his college and what he d
        • "When Linus was on College/University he programmed a unix like kernel in his spare time."

          And that's what he will be remembered for, not his thesis (if he wrote one) or his grades. So you actually tend to prove the parent's point.
          • And that's what he will be remembered for, not his thesis (if he wrote one) or his grades ...and of course with a good prof [ Tannenbaum ], Linux would have got Linus a "fail" grade at college.

      • Re:MDA vs MDD (Score:3, Interesting)

        by vrmlguy (120854)
        I wish you guys still in school or freshly graduated knew how often the rest of us roll our eyes every time we hear "my thesis" or "my prof". Your college education will be of marginal vaule to you as a programmer. Most of what you use will be from experience gained after you graduated. You won't necessarily be a good programmer just because you made good grades either.

        Yeah, tell that to Larry Page and Sergey Brin (Google), Scott McNealy, Andy Bechtolsheim, Bill Joy and Vinod Khosla (Sun Microsystems) and

      • Your college education will be of marginal vaule to you as a programmer. ... You won't necessarily be a good programmer just because you made good grades either.

        You could be right - in the end, he'll probably end up settling for a lowly CTO or CIO position.

        • With a Master's in COMPUTER SCIENCE? No, they want MBAs for those positions, people who know how to destroy projects. For an MSc if he graduated from an American school and is white, his new phrase should be "You want fries with that"?
      • Re:MDA vs MDD (Score:3, Informative)

        by r.jimenezz (737542)
        Sorry, -ryan. I didn't mean to imply my MSc thesis gave me any kind of edge :) Just to bring the next sentence into context.

        You are indeed right. I've been programming for seven years now, and the vast majority of what I know came from the trenches, not from any of my degrees.

        Indeed, I found that I enjoyed my MSc a lot more because I had about four years of experience when I went into it. Otherwise I'm afraid it'd only be a lot of useless knowledge, instead of answers to questions I had naturally stumbl

  • AndroMDA anyone? (Score:2, Informative)

    AndroMDA could be worth a look. Works with Poseidon and some expensive UML tools. You'd better be up on your UML if you want to do some MDA. One of the best code generation strategies I've worked with was using XDoclet tags to generate mappings and Hibernate's schema export to take those mappings and generate DDL.
  • My entire datalayer is designed arround some of this theory. It takes me about 2 minutes to create a data object for a predefined table, or about 15-30 for custom views. But that is a fraction of the total time spent developing. Because pretty much ever thing I do depends on the data layer, and much of my higher level code can use multiple data object, the ratio of functional code to generated code in use is tiny, while that relationship is inverted for development time. Which means I can spend a lot of tim
  • by Anonymous Coward
    I've used an ORM to code the data-layer CRUD operations on a data model with 1200 tables, which probably saved at least a man-year of effort.

    I've also struggled trying to use UML to generate business logic. That just didn't work.
  • by infra j (905848) on Tuesday February 21, 2006 @01:42AM (#14765833)
    I'm using a conglomeration of tools to develop a tiered application that uses Eclipse as the primary client.

    The model is developed using ArgoUML [tigris.org]. The output is a zipped XMI file that I convert to a EMF ecore model using the argo2ecore [sourceforge.net] Eclipse plug-in. From there I generate the model and editor code using EMF [eclipse.org]. After that, I use the Elver [elver.org] plugin to generate the corresponding hibernate mappings.

    So from the UML source, I can generate EMF model and edit code to serve the presentation and hibernate mappings for persistence to an RDBMS -- all using free software.

    There are a couple of big challenges, namely distributed object persistence (including transactions). For this we're attempting to use the EMF SDO (Service Data Objects) implementation. Also implementing business behavior is a bit of a challenge since ideally we'd be able to mark certain EMF methods as "biz logic" such that the factory generates a stub for the client, and I could fill in real business logic for the server side.

  • I'm wondering; is all this model driven code generation just a paradigm shift from text-based programming to graph-based programming?

    Seems to me that the amount of knowledge of the tools required for these code generators closely matches the amount of knowledge of a language required to create a decent app.

    Replacing one set of syntax (that of code) with another (that of the graph "language", reflected in it's file format), without taking away any of the complexity.

    If it were really easier to use code genera
    • I agree with you that graph-based programming has the same complexity as text-bases programming. On the other side: a couple of years ago I used Labview, a 'graph'-based programming language/environment. It was incredible how fast I could implement something and debug it.

      I still wonder why we still code in text files (as I do myself today). We invent dedicated databases for other to use, but we fail to use them ourselves for our main task. Would you go to a doctor if you knew doctors never go to doctors th
    • I'm wondering; is all this model driven code generation just a paradigm shift from text-based programming to graph-based programming?

      I don't know about you, but when I program in text, I'm thinking in terms of some kind of graphical structure. Code indentation helps lots here.
      • I don't know about you, but when I program in text, I'm thinking in terms of some kind of graphical structure.

        And I think in terms of text, as in a textbook or a story. I suspect this varies a lot between different people.

        I nearly got into an argument with a tool vendor recently. He couldn't imagine someone feeling productive when programming manually, using a text editor.

        I have a hard time getting anything useful out of looking at colorful pictures, sequence diagrams and PowerPoint slides; basically any

    • Graph based programming is OLD too. It just didn't surface in the area of traditional computing first. PLCs [wikipedia.org] have been using graphical programming languages for a LONG time (>20years). These include ladder diagrams, sequential flow charts and function block diagrams. The probable reason PLCs started with evolving in this direction probably is because they started with targeting electricians (who are very used to circuit diagrams) and not university educated professors (ie math wizards).

      As a matter of fact
  • by ahodgkinson (662233) on Tuesday February 21, 2006 @03:30AM (#14766114) Homepage Journal
    Please forgive the provocative subject line. :)

    My experience with Model Driven Architecture left me with a bad feeling about it. While the theory and goals are admirable, I worry that practical implementations don't meet expectations. Basically, I think that MDA is presented as a silver bullet, and the type of companies likely to by 'targeted' by MDA (e.g. those that must 'fix' their development methodology) are the least likely to benefit from it. I am willing to accept that highly skilled and well managed project teams will experience massive productivity gains using MDA, but such project teams (unfortunately rare in our industry) would probably succeed using pretty much any methodology.

    I worked one summer on a Java based project whose goal was to develop a system for managing health insurance policies. The company and project were flawed for a number of reasons, not directly related to MDA, but the choice of MDA made the situation much worse. The end of this story is that the company went out of business because it was unable to deliver the software it had promised.

    Near the start of the project, the company had hired an MDA guru, who designed the MDA and, I belive implemented most of its core. Over time the MDA core portion expended in into a massive code generator that took hours to run and required tons and tons of memory.

    The state of the project when I arrived (which was to implement optimizations to one of XML based parts of the code generator) was:

    • The application required many many hours to generate/compile.
    • The resulting code was so large and complex that any meaningful analysis of it was virtually impossible.
    • It was also impossible to try out quick changes or do any kind of rapid prototyping.
    • The architecture and tools were so complex that new staff required long training periods in order to be productive,

    I think the worst result of MDA, was that the nature of the MDA process caused a large divide to develop between the 'system' programmers, maintaining the underlying MDA library, and the 'application' developers.

    The system people, generally well qualified programmers, had little or no interest in the end application. The were fascinated by the tools and viewed the production of a functioning application as 'an exercise for the application programmers'.

    The application programmers, on the other hand, had absolutely no understanding (though through necessity they had interest) of the underlying architecture and no ability to predict the performance implications of their design choices.

    The result was a massive resource hog. The two system programmers, truly interested in ensuring the that MDA system could actually be used create an salable application had to work overtime to try to hold everything together. Unfortunately, they failed, though not for want of trying.

    The main technical problem, beyond the complexity of the tools, was their attempt to map the MDA's OO data model to a relational database. (I'm not sure if this is a core principal of MDA, so I welcome your feedback). While OO data modeling might be good for user interfaces. I don't feel it's that suitable for modeling typical business data, like insurance policies. And the OO modeling concepts seemed to confuse the business domain experts, who tended to think in relational model terms.

    It may well have been that this particular implementation of MDA was badly flawed. That said, the nature of MDA, that of hoping to implement your application by 'drawing pictures', and then filling in snippets of code to complete the it, seems naive. It reminds me of the early 90s when 'strong CASE' was the rage and the CASE proponents said all application design would be done using diagramming tools and then filling in the bodies of the subroutines.

    I suspect that over the years, MDA will generate a minor following, like strong CASE did, but then a new fashion will emerge and interest in MD

    • Hm,

      I'm not a fan of MDA like it is defined by OMG; however i use the primary prinziple a lot with AndroMDA, http://www.openarchitectureware.org/ [openarchitectureware.org] and I'm playing with mdr.netbeans.org/

      However I liek to comment on a few of your points:

      * the application required many many hours to generate/compile.
      So, what was the probelm here? To much generation time? Why? Generating by extracting from a slow versioning system? Generation on a network drive? Simply to much code?
      If its only "lots of code" then this is not real
      • You correctly point out that poor or inadequate qualification contributed to the downfall of the project. Which leads to the point: What was the purpose of MDA for this project?

        IMHO there exists the theory in PHB's minds that if you can do something graphically, it's much easier and you can hire less qualified people to accomplish great feats. The whole description of the project had this written all over and in big letters.

        Just think of joice quotes from the GP like "caused a large divide to develop", "sys
        • Hehe,

          I agree with most what you say.

          Interesting is your description about eh feedback other developers give.

          To be honest, MDA is: code (the generator), compile (start generator, get lots of source code, compile it), "check if it works".

          For me that is just shifted the lowest level of programming habits: write some code, compile it, run it, check manually if the program behaves good, up to the level of CASE + MDA generator.

          So a you describe: yes there is a kind of genius, but he is working like a beginner, on
          • You are right, MDA certainly appears to encourage this strategy. However, I don't think anyone using a graphical interface to build an application can actually work with this write/draw, compile, verify strategy without risking big time failure.

            And that's the point. MDA is perceived as something which makes the task of developing software easier. It doesn't,it just takes away some of the grudge work (i.e. coding standard blocks).

            I quote from a technical whitepaper found here [omg.org]:

            Today, process of applic

  • by _flan (156875) on Tuesday February 21, 2006 @05:44AM (#14766407)

    I have had (am having) the displeasure of being part of a pilot project for an in-house MDA utility based on Rose and Eclipse. In a nutshell: it sucks.

    There are two general problems that I've encountered:

    • Poor granularity
    • Crappy tools

    The granularity problem is that you have to spend a lot of time specifying fine-grained details in the model that are more easily expressed in code. Examples are: method calls, persistence, behavior parameters, etc. Often these details don't even show up on the screen. This makes them almost useless for someone trying to understand what is going on. This is a big problem and not going away.

    The tool problem is that if the tools don't help you work effectively, the whole process fails. Using Rose is like sticking pins under your toenails and kicking a wall. Rose seems to get in your way on purpose with a hideous interface. Sure, this problem is tool-related, but its impact is huge. It can turn what should be simple into a marathon of pain.

    So far, we've spent weeks on a toy application that should have taken two days. Perhaps these in-house tools will evolve to the point of usability, but somehow I doubt it.

    Ian
    • The granularity problem is that you have to spend a lot of time specifying fine-grained details in the model that are more easily expressed in code.

      And this corroborates my experience: defining a model that is detailed and correct enough to generate release code (as opposed to prototype code) is every bit as hard as writing the code itself.

      MDA's are great for quick prototyping, but once you get into the optimization and functional peculiarities of the business domain, the modeling tools get in the way.

      • defining a model that is detailed and correct enough to generate release code (as opposed to prototype code) is every bit as hard as writing the code itself.

        Harder, because you have to waste all that time and effort getting the shelfware the boss got from Big Company to try to actually work. Am I implying that the tools are buggy? No, I'm saying that MDA tools are created to fulfill a marketing need and aren't ever intended to actually work beyond what the sales engineer shows you. The primary product dev

  • MDA: use it wisely (Score:4, Insightful)

    by barries (15577) on Tuesday February 21, 2006 @06:54AM (#14766591) Homepage
    We use "lightweight" MDA to codegen code for limited scope portions of an overall design, like communications protocols, state machines (for UIs and embedded systems), data models, and data flow engines. We use models to generate SQL, C (dialects for 8-bit SOC through Win32, .NET and Linux), C++, C#, Perl, HTML, and XML.

    We often use diagrams to design our models, but the models themselves are (to date) are written in textual forms (XML, text outlines, or custom mini-languages) rather than graphical editors. The textual forms are useful because we can use any text editor (like your favorite IDE or programmer's editor or sometimes even notepad.exe or a wiki) to maintain them anywhere. Also, it takes a lot of time to build a graphical editor and tools like Eclipse, Visio, etc. still take too long to whip up a GUI in unless you're already a guru in that tool. Implementing and tweaking ad-hoc extension in to a text-based modelling tool is also relatively easy. I'd much prefer to be able to use graphical model editors, but haven't had the time to roll our own and haven't found a tool that makes rolling our own that easy.

    Tool-based MDA offers better return than raw coding does under a few conditions: (1) where the model's structure represents the solution more intuitively or concisely than source code (state machines and dataflow, for instance), (2) where the model can be used to generate repetetive code and reduce the chances of human error (all of the examples listed above), (3) where many artifacts can be created from one model, and thus kept in sync automatically, for instance in data modelling (SQL schema, SQL queries and C++/Perl/etc. wrapper codegen from 1 model, multiple endpoints of a comms channel), (4) where a team can build an MDA tool *once* and then apply it to many problems.

    In some sense, you can think of item 1 in that list as being true when the model you've chosen is also one of the best ways to document the implementation.

    Where codegen MDA starts to fall over is (1) when the implementation requires a number of different "one-off" solutions that can't easily and naturally be incorporated in the model (for instance, where the model is based on an early, simplistic view of how the application should behave; late-arriving requirements can clobber a model's utility), (2) where developing or installing, configuring and customizing the modelling tool is more work than writing the code (when the developer can whip up the code faster than you can install, configure and customize the modelling tools for your application), and (3) where you need to spend extra effort installing and describing the modelling tools for downstream maintenance organizations.

    (3) doesn't prevent MDA, but it does place extra emphasis on having the model generate maintainable code so you can cut away from the modelling tool at some point.

    MDA is quite useful, but like every other TLA and FLA (SOAP?, XML?, COM?, SQL?, REST?) or four letter word (Java? Perl?), you should only use it where it helps meet your needs.

    - Barrie
  • by stevek_mcc (444668) on Tuesday February 21, 2006 @07:38AM (#14766703) Homepage

    MDA's central failing is that current implementations use UML. As Booch et al. say "the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts." (MDA Manifesto [bptrends.com], Grady Booch, Alan Brown, Sridhar Iyengar, Jim Rumbaugh, Bran Selic, MDA Journal, May 2004). In other words, MDA is the OMG's attempt to copy something that has been going strong for over a decade: Domain-Specific Modeling.

    Domain-Specific Modeling is about creating modeling languages whose concepts map to your problem domain concepts, rather than everybody's solution domain concepts. UML concepts - at least those from which code is generated - are from the solution domain: classes, attributes, operations. DSM concepts are different for each domain - buttons and icons for digital watches, menus and text message sending for phones, mouse buttons and cacodemons for FPS games. Models are thus at a significantly higher level of abstraction, and independent of any particular implementation technology. They capture just enough (and no more) detail to enable full code generation - and of course the code generators too are domain-specific.

    As always, the more specific a tool is for a job, the more productive it can be for that job. It turns out it's best to create a modeling language and generator specific to a single range of products for a single company: the cost of creating the language is more than offset by the higher productivity, providing you're building more than a couple of products. Industrial cases of DSM [dsmforum.org] consistently show productivity increases of 500-1000%. Compare that with MDA, where even vendor-sponsored studies show only 35% [theserverside.com].

    Whilst it's early days yet for the Microsoft DSL tools, other mature DSM tools [dsmforum.org] exist, both for commercial and research use. I've been involved with one for 13 years, so a) you should suspect me of being biased, and b) I have some small experience of how this stuff actually works in the real world. One key thing is that with a decent DSM tool, building your language, code generator and modeling tool support has to be easy - both at the start and as you evolve the language based on experience. Even our largest customer - with several hundred users and the biggest modeling language we've seen - only has one person assigned part time to that task.

    • So how do you feel about the argument that LISP's power comes from the ease in which one can create inline DSL's (Macros)

      "MDA's central failing is that current implementations use UML. "

      MIT's Alloy Analyzer [mit.edu] doesn't, and yet here we are several years later. IMHO I simply think that we're not ready for anything beyound "cowboy programming" level. Just read all the responses to this "ask slashdot", and read between the lines.
      • I've never used LISP on a big enough project to be sure, but others' experience is certainly like you say. Smalltalk is similar. Both are great. One downside is that you are constrained by the original syntax of the language. Smalltalk is somewhat better than LISP there, since it reads more like natural language. Another downside is the textual format itself: any time you want to refer to something else, you have to do it by typing the same series of characters. It's much more intuitive to use a graphical r
  • Or do you want to be a manager? MDA tools are great for managers who want to get code done quickly, with no art, exactly to specs. These people are the type who played Nintendo growing up instead of getting their parents to buy a real computer- people who care about end results more than the process of getting to those end results. MDA is just the latest version of RAD- and while RAD has it's place, you sacrifice something for getting the program done fast in terms of useability and resource utilization,
  • What are the drawbacks, difficulties and limitations of MDA?

    I wish I had a dollar for every time somebody in charge of "the model" (multiple people from different projects at different companies) told me that the requested change wasn't possible because the tool didn't support that, leading the feature to be devloped by a macro around the generated code, or in duplication of hand generated accessor transformation across a large code base, or worse.

    If you have a cookie cutter project, it's great. If you don'
  • Automate the repetitive parts, like the code that wraps a stored procedure into a language specific call (If you have lots of stored procedures), and maybe some of the UI if it follows a very clear pattern (which you find after writing the same thing with a number of variants, like the number and type of fields in a record).

    You can also generate automated tests for the generated code, to test for build consistency, etc.

    Avoid writing your own database access layer and use a proven o/r mapper like hibernate,
  • by trudy_cool (956151) on Tuesday February 21, 2006 @06:19PM (#14772264)
    I've been working with AndroMDA for about a year and, while I sympathise with the dire experiences recounted above, my reaction is, "But that isn't the case with AndroMDA!"

    If your development team has already gone down the widely accepted route of -- Eclipse / Ant / xDoclet / Subversion / Spring / Hibernate / Tiles / Struts / jBoss -- you would be crazy not to give AndroMDA a chance. It permits you to continue doing exactly what you do now, but takes over the donkey work. If Maven is like Ant on steroids; AndroMDA is like xDoclet on steroids.

    This SlashDot topic was sent to me by a colleague worried about my push for MDA where we work. Rather than comment privately just to him, I thought I'd make my views public. I hope you find the following helpful ...



    ... , but overall, I still prefer the safety net of being in control of the coding process, and actually understanding what is going on under the hood.

    I've had the same experience in the past with products that make all the easy bits easier -- and the hard bits impossible.

    AndroMDA generates established best-practice Java patterns in a clear and concise structure. All the generated code is visible and available for editing (I refresh my Eclipse project and see all changes). Code that you need to alter is kept in separate directories and written there once. On the rare occasions in which you need to substitute 'unalterable' generated code with something special, you specify a substitution directory that precedes the targets directory in the build path. Due to the very consistent and sensible pattern adherence, there are a lot of very small java files. When you do need to substitute, the likelihood of your substitution AND the original both needing edits is low.

    My experience is that I am completely in control of the coding process. A key thing about AndroMDA is that it actually tries to do very little . The yet-to-be-generated code resides in Velocity templates. AndroMDA loads UML into an object map (metafacade) that Velocity scripts traverse while filling in template fields as they go. Those many Velocity scripts are orchestrated with Maven. By leveraging so many best-in-class OSS projects the AndroMDA team keeps its own efforts very tightly focussed.

    I have only looked briefly at xDoclet, but if you are concerned about "being in control of the coding process" AndroMDA is scarcely more invasive than xDoclet.



    Then you are at square one, writing a custom MDA that works for you.
    ... and ...
    Near the start of the project, the company had hired an MDA guru, who designed the MDA and, I belive implemented most of its core. Over time the MDA core portion expended in into a massive code generator that took hours to run and required tons and tons of memory.

    That is about as necessary and sensible as creating your own http server. If you have someone breathing down your neck for results, don't even think about creating your own MDA. If you have that much time on your hands &/or a special need, create a new cartridge for AndroMDA that takes over where its existing cartridges leave off.



    Seems to me that the amount of knowledge of the tools required for these code generators closely matches the amount of knowledge of a language required to create a decent app.

    In the case of AndroMDA that's about right. However, developing an n-tier J2EE &/or .NET corporate architecture goes immensely beyond that. There is an AndroMDA .NET suite underway. AFAIK, at this time it is not possible, but in the mid-term you will be able to generate a J2EE and a .NET system simultaneously from a single UML model. This is incredible leverage of the "amount of knowledge of a language required to create a decent app"

    My J2EE development experience ended more or less

The only problem with being a man of leisure is that you can never stop and take a rest.

Working...