Pros and Cons of MDA Code Generators? 62
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?"
Acronym dependency... (Score:5, Funny)
Re:Acronym dependency... (Score:5, Funny)
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-)
Re:Acronym dependency... (Score:2)
Re:Acronym dependency... (Score:2)
MDA - for gaming (Score:5, Interesting)
Re:MDA - for gaming (Score:2, Funny)
Borland's ECO (Score:5, Informative)
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)
Re:My advise... (Score:1)
How can you master a computer architecture if you can't master grammar?
Re:My advise... (Score:1)
Re:My advise... (Score:1)
Re:My advise... (Score:2)
By the way, English is not my native language, and I live in a non-English speaking country. So yes, I sometimes make mistakes
Mmmm, MDA (Score:4, Funny)
Re:Mmmm, MDA (Score:1, Funny)
Re:Mmmm, MDA (Score:2)
Re:Mmmm, MDA (Score:2)
Fundamental disconnect: data model vs. user tasks (Score:2)
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)
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)
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.
Re:MDA vs MDD (Score:2)
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
Re:MDA vs MDD (Score:2)
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.
Re:MDA vs MDD (Score:2)
Re:MDA vs MDD (Score:3, Interesting)
Yeah, tell that to Larry Page and Sergey Brin (Google), Scott McNealy, Andy Bechtolsheim, Bill Joy and Vinod Khosla (Sun Microsystems) and
Re:MDA vs MDD (Score:2)
You could be right - in the end, he'll probably end up settling for a lowly CTO or CIO position.
Re:MDA vs MDD (Score:1, Flamebait)
Re:MDA vs MDD (Score:3, Informative)
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)
Re:AndroMDA anyone?-Tools (Score:2)
Has anyone here tried Open Architecture Ware [openarchitectureware.org]?
I use it. (Score:2)
Good for CRUD, not so good for business logic (Score:1, Insightful)
I've also struggled trying to use UML to generate business logic. That just didn't work.
ArgoUML + EMF + Hibernate (Score:3, Interesting)
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.
Shifting paradigms (Score:2)
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
Shifting paradigms not quite there yet. (Score:1)
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
Re:Shifting paradigms (Score:2)
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.
Re:Shifting paradigms (Score:1)
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
Re:Shifting cultures. (Score:2)
I didn't say unskilled people used these tools or that people using these tools are unskilled. I merely asked the question why people using these tools still need to be as skilled as text programmers to use their tools if these tools were really simpler to use.
Re:Shifting paradigms (Score:2)
As a matter of fact
MDA = Mass Destruction of Application (Score:5, Interesting)
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:
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
Re:MDA = Mass Destruction of Application (Score:2)
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
Qualification is often the problem (Score:1)
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
Re:Qualification is often the problem (Score:2)
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
Re:Qualification is often the problem (Score:1)
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]:
MDA is best served with a large mountain of salt (Score:4, Insightful)
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:
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.
IanRe:MDA is best served with a large mountain of sal (Score:2)
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.
Re:MDA is best served with a large mountain of sal (Score:2)
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)
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
MDA promises, Domain-Specific Modeling delivers (Score:3, Insightful)
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.
LISP promises, Domain-Specific Modeling delivers (Score:1)
"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.
Re:LISP promises, Domain-Specific Modeling deliver (Score:2, Insightful)
In the end, do you want to be a programmer? (Score:2)
Drawbacks? (Score:2)
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'
Code generation (Score:2)
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,
AndroMDA is special! (Score:3, Insightful)
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
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.
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
My J2EE development experience ended more or less