Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Pros and Cons of MDA Code Generators?

Cliff posted more than 8 years ago | from the code-writing-code dept.

Programming 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?"

cancel ×

62 comments

Sorry! There are no comments related to the filter you selected.

Acronym dependency... (4, Funny)

avalys (221114) | more than 8 years ago | (#14764794)

The first step to recovery is admitting you have a problem...

Re:Acronym dependency... (4, Funny)

meburke (736645) | more than 8 years ago | (#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-)

Re:Acronym dependency... (1)

dynamo (6127) | more than 8 years ago | (#14765264)

funny, mod up

Re: AD (0)

Anonymous Coward | more than 8 years ago | (#14765258)

IANAAD (I am not an Acronym Dependent) but, the FSTR is admitting YHAP...

O.K.?

Re:Acronym dependency... (1)

wiggles (30088) | more than 8 years ago | (#14768807)

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 (4, Interesting)

QuantumFTL (197300) | more than 8 years ago | (#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!

Re:MDA - for gaming (2, Funny)

ratnerstar (609443) | more than 8 years ago | (#14765401)

Yes, MDA [wikipedia.org] is great for games. However, I find the tweaking to be a serious downside.

Borland's ECO (4, Informative)

Mr_Tulip (639140) | more than 8 years ago | (#14764841)

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... (2, Interesting)

malraid (592373) | more than 8 years ago | (#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.

Re:My advise... (0)

porkchop_d_clown (39923) | more than 8 years ago | (#14765047)

Your "advise" is that he should wear a costume while coding?

How can you master a computer architecture if you can't master grammar?

Re:My advise... (0)

QuantumG (50515) | more than 8 years ago | (#14765072)

I never do that, but if you'd like to see me in a costume you have only to ask.

Re:My advise... (0)

dorkygeek (898295) | more than 8 years ago | (#14765175)

Oh, so you have l337 n4k3d sk1llz, or what?

Re:My advise... (1)

malraid (592373) | more than 8 years ago | (#14767462)

Grammar? Spelling? Leave that to the documentation guys.

By the way, English is not my native language, and I live in a non-English speaking country. So yes, I sometimes make mistakes

MDA Tools (0)

Anonymous Coward | more than 8 years ago | (#14764960)

I've always considered MDA tools as a good way to bootstrap your project. Once I'm moving along, I'll usually stop using the tools except for things like persistance layer mapping.

Mmmm, MDA (3, Funny)

RedDirt (3122) | more than 8 years ago | (#14765130)

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.

Re:Mmmm, MDA (1, Funny)

Anonymous Coward | more than 8 years ago | (#14765638)

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] .

Re:Mmmm, MDA (1)

Shag (3737) | more than 8 years ago | (#14765936)

I'd better turn in my geek license, since I first parsed it as something having to do with Jerry's kids.

Re:Mmmm, MDA (1)

BillX (307153) | more than 8 years ago | (#14772130)

Crap, was I the only one whose first thought was Missile Defense Agency?

Fundamental disconnect: data model vs. user tasks (1)

plsuh (129598) | more than 8 years ago | (#14765214)

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 underlying data model and automatically generate either a web application or a Java Swing application for you, customizable via a set of conditional rules. However, every time that I've done so I have ended up either re-doing the application via a more conventional WebObjects implementation, or the amount of customization has ended up being so great that the level of effort was roughly the same as if I had started from scratch.

Don't believe the snake oil salesmen, and don't let your management believe them either.

--Paul

MDA vs MDD (2, Informative)

r.jimenezz (737542) | more than 8 years ago | (#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 (3, Insightful)

-ryan (115102) | more than 8 years ago | (#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.

Re:MDA vs MDD (1)

angel'o'sphere (80593) | more than 8 years ago | (#14766438)

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 does in his spare time. When Linus was on College/University he programmed a unix like kernel in his spare time.

Most of what you use will be from experience gained after you graduated. Probbaly true for the most ppl, i got most of my experiance before I graduated, as I worked 15 years already in that job.

You won't necessarily be a good programmer just because you made good grades either. True of course. But you don't make a good comment by bashing some one who is introducing his thesis here. If he had introduced a OSS/FSS project he likely had get great applause by you?

Anyway, I fully agree with teh rest of your comment ;D

angel'o'sphere

Re:MDA vs MDD (1)

Intron (870560) | more than 8 years ago | (#14769153)

"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.

Re:MDA vs MDD (1)

ray-auch (454705) | more than 8 years ago | (#14784214)

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 (2, Interesting)

vrmlguy (120854) | more than 8 years ago | (#14766751)

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 Fred Smith (FedEx). Those companies all started out as college term papers.

Re:MDA vs MDD (1)

computational super (740265) | more than 8 years ago | (#14767292)

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.

Re:MDA vs MDD (0, Flamebait)

Marxist Hacker 42 (638312) | more than 8 years ago | (#14767724)

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 (2, Informative)

r.jimenezz (737542) | more than 8 years ago | (#14768131)

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 stumbled upon.

I thoroughly enjoyed your comment. My main beef with AndroMDA is trying to go straight from model to code. IMHO there should be an intermediate step (something that MDA, with PIM->PSM transformation, somehow contemplates). Then again UML within AndroMDA is mostly used as a detailed design language, not an architectural description language.

AndroMDA does NOT go "straight from model to code" (0)

Anonymous Coward | more than 8 years ago | (#14846715)

"My main beef with AndroMDA is trying to go straight from model to code. IMHO there should be an intermediate step (something that MDA, with PIM->PSM transformation, somehow contemplates)."

AndroMDA has the intermediate PSM, they are called "meta-facades".

AndroMDA anyone? (2, Informative)

PopCultureDiva (844267) | more than 8 years ago | (#14765476)

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.

AndroMDA anyone?-Tools (0)

Anonymous Coward | more than 8 years ago | (#14769168)

GME: The Generic Modeling Environment [vanderbilt.edu]

"The Generic Modeling Environment is a configurable toolkit for creating domain-specific modeling and program synthesis environments. The configuration is accomplished through metamodels specifying the modeling paradigm (modeling language) of the application domain. The modeling paradigm contains all the syntactic, semantic, and presentation information regarding the domain; which concepts will be used to construct models, what relationships may exist among those concepts, how the concepts may be organized and viewed by the modeler, and rules governing the construction of models. The modeling paradigm defines the family of models that can be created using the resultant modeling environment."

StarUML: The Open Source UML/MDA Platform [staruml.com]

"StarUML - The Open Source UML/MDA Platform
StarUML is an open source project to develop fast, flexible, extensible, featureful, and freely-available UML/MDA platform running on Win32 platform. The goal of the StarUML project is to build a software modeling tool and also platform that is a compelling replacement of commercial UML tools such as Rational Rose, Together and so on."

Recommended book:
The Laws of Software Process: A New Model for the Production and Management of Software [corvusintl.com]

"Phil's first book covers in depth the issues he has been exploring in his The Business of Software column in Communications of the ACM, namely that software is best thought of as a knowledge storage medium and software development as a knowledge acquisition activity."

Re:AndroMDA anyone?-Tools (1)

anomalous cohort (704239) | more than 8 years ago | (#14788994)

Has anyone here tried Open Architecture Ware [openarchitectureware.org] ?

I use it. (1)

RingDev (879105) | more than 8 years ago | (#14765577)

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 time going over business req and fine tuning applications, with out having to bother with data interaction.

-Rick

Good for CRUD, not so good for business logic (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14765676)

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.

ArgoUML + EMF + Hibernate (3, Interesting)

infra j (905848) | more than 8 years ago | (#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.

Better data encapsulation (0)

Anonymous Coward | more than 8 years ago | (#14765903)

To put this in English... MDA is basically a system for auto-generating data access routines and/or syncing data schema with access routine changes?

Shifting paradigms (1)

mwvdlee (775178) | more than 8 years ago | (#14765992)

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 generators, one would expect less skillfull people to be able to use them; is this the case?

Shifting paradigms not quite there yet. (1)

beofli (584044) | more than 8 years ago | (#14766090)

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 themselves?

In the meantime they invent these code generation tools, which are in my opinion the worst way to go because as soon as you have to edit the non-source code, you loose the connection with your 'graph'.

Therefore I stick to text as source, from which the objects, libraries and application are created in a consistent way.

Re:Shifting paradigms (1)

ObsessiveMathsFreak (773371) | more than 8 years ago | (#14767512)

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.

Re:Shifting paradigms (1)

jgrahn (181062) | more than 7 years ago | (#14779705)

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 anything which doesn't use full sentences. Meanwhile, I've noted that many people just blank out when they receive a mail containing more than one paragraph ...

Shifting cultures. (0)

Anonymous Coward | more than 8 years ago | (#14769428)

"If it were really easier to use code generators, one would expect less skillfull people to be able to use them; is this the case?"

So does tools like Maya and Lightwave mean that "less skillful people" are creating more mediocrity, and does that mean we shoud go back to "hand drawn methods" because it will raise the quality, and keep out the undesirables?

How about programmimg? Real men do it all in machine language, and tools like compilers, and other high-level languages allow the "less skillful" to invade the programming profession, lowering our high standards.

"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."

That's *assuming* two things. One the audiance is the same. e.g. programmer. And two that both are saying the same thing. e.g. "a picture is worth a thousand words".

Re:Shifting cultures. (1)

mwvdlee (775178) | more than 8 years ago | (#14774915)

Way to turn an argument upside down and inside out, but that's probably why you've entered your comment as an "Anonymous Coward".

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 (1)

TERdON (862570) | more than 8 years ago | (#14772230)

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, at least with Omron PLCs (the ones I use), the development today is going towards including more of the textual languages, more similar to traditional computer languages. They are a lot more suitable for the general purpose programming that PLCs increasingly have to do.

Basically, some problems lend themselves to a graphical description (boolean expressions, sequences), some not (mathematical calculations). Probably the golden middle (some of each) is the road to choose to be choosing "right".

MDA = Mass Destruction of Application (4, Interesting)

ahodgkinson (662233) | more than 8 years ago | (#14766114)

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 MDA will fade. The memory will be that MDA had failed. Few people will remember the useful spin-offs. With strong CASE, we ended up with improvements to diagramming techniques and better acceptance of (and techniques for) top-down design. In MDA's case, we might get better techniques for mapping between the OO and Relation worlds, and possibly improvements in automatic generation of system libraries.

Re:MDA = Mass Destruction of Application (1)

angel'o'sphere (80593) | more than 8 years ago | (#14766520)

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 really a point whcih is bad in itself. Would it be significantly less code if you had written it yb hand instead of generating it?

* The resulting code was so large and complex that any meaningful analysis of it was virtually impossible.
I assume it wsa not only the size of the code but its structure. Likely lack of abstarction and lack of architecure.

* It was also impossible to try out quick changes or do any kind of rapid prototyping.
Definitley a sign of lack of architecture. In a well designed system it does not matter where a component comes from, wether it is generated or hand written, you only should either need to exchange the Jar file and/or the line where the facade class for that component is instanciated. Usually this is in a deployment describing file.

* The architecture and tools were so complex that new staff required long training periods in order to be productive
Unfortunately you can' really do anything against that. Mind you had written your own Generator, same problem. You have to train others in using it.

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). Nope, it is not, that would be rather pointless. MDA means in general that you have oen core odel and lots of situation depending mappings, thats all. its not restricted to DB code, that would be silly.

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.

Thats a difficult issue. If the whoel application like you state above is already a mess, mapping it 1 : 1 from OO to relatinoal will just add to the mess.

However your feeling is completely wrong. GUIs are usually programmed in OO concepts because all widgets have lots in common. But you don't modell a GUI in OO terms, at least you do so only very rarely. What would be the point? All relations are usually compositions ... pretty boring. OO modelling is only interesting if you model data relations and behaviour with it.

And the OO modeling concepts seemed to confuse the business domain experts, who tended to think in relational model terms.
There is not much difference!!!! If he is indeed a business domain expert then OO is much easyer than relational modeling anyway! Because the domain expert only needs to think in objects: account, customer, policy, payment terms etc. The modelling is mainly concerned around: is "payment terms" related to "customer"? Or to "account"? Or to the "policy"? As you see here is no UI involved.
The next question is: if I create a new "policy" do I always need to create a "payment term" as well imediatly? Then its a composition, or can I create it later, because I probably have different 'classes' of "payment terms" then its likely an aggregation, or can the "payment term" stay missing until I descide the policy is now sold or activated? Then its likely an simple association.
This is a HUGHE difference in the coding of the programmers, and a hughe diffrence in the way your business processes will work later.
However as long as I only have a 1 : 1 relation here, I can describe all that with the same DB schema!!!! Except for giving or leaving a NOTNULL statement.

If he is already one step deeper in the matter, then he is a data analyst/database analyst/modeller. If that is the case then he should be familiar with OO terms anyway. Modelling in pure (old term ER) relational terms is ancient. Modern variants of ER modelling also use more expressive ways and are very similar to OO modelling except for the exact way how to notate it in a graphical way. And last but not least, he will have to cope with programmers who deliever material described in UML in his dayly work. So he has to understand it and to cope with it. If he can't, he is at the wrong position!!

angel'o'sphere

Qualification is often the problem (1)

Slayer (6656) | more than 8 years ago | (#14769289)

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", "system people, generally well qualified programmers, had little or no interest", "application programmers, on the other hand, had absolutely no understanding", "OO modeling concepts seemed to confuse the business domain experts".

I can literally see some PHB there telling his peers: "Great, lets get rid of all this command line stuff and text editing, spend x amount of money on fancy software, get the same result faster and overall save a bundle!" Unfortunately a person who knows how to design a great software architecture is hard to find but still required, whether you use MDA or whether you have cheap code monkeys for the grudge work.

And if you compare the likely output from one genius + MDA versus a similar genius + many code crunchers, chances are the second choice works out better. While the many code crunchers may not be geniuses, they usually do contribute useful thoughts and feedback, something an MDA doesn't! Have you ever seen a GUI design tool which told you straight in your face: "Don't put this menu item here, nobody would find it there!" ?

You may need fewer people but a much greater genius to make a project fly with MDA. Unfortunately it's just those geniuses who are so hard to find in the job market. The reason why PHBs are willing to spend big money on MDA is because they want to save the money spent on the big genius!

If you've seen many projects (as I'm sure you have), you've seen even more people who are in the wrong position but the only people available at the time. And sometimes it still works out, especially if they are able to learn their way into the project internals. This, of course requires hiring smart people. The use of MDA was most likely not the reason for said project to fail (at least not technically), but chances are that the marketing of MDA caused the business guys at the responsible company to make poor hiring decisions.

While the late 90s were the time of the software gods (usually some social misfits with great coding skills and even more attitude, think dotcom), the last few years have tried to completely do without them. Evidently this way doesn't work so well either ...

Re:Qualification is often the problem (1)

angel'o'sphere (80593) | more than 7 years ago | (#14780421)

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, only his "toolchain" is more sophisticated.

However: if you wanted, you could use MDA or similar related approaches quite successfully. Only the current official OMG approach called MDA is kinda overkill.

angel'o'spehre

Re:Qualification is often the problem (1)

Slayer (6656) | more than 8 years ago | (#14783617)

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 application system development starts with business owners zero in on idea followed by marathon meeting with IT specialists end result being business owners/Managers are left grappling with some incomprehensible technical documentation and not with a tangible solution.

Great! Tell managers to buy and use MDA so they don't have to put up with these pathetic "computer experts" any longer! They can just go ahead and "design" their own business software, it has become so easy now!

Or look at the following quote from this source [omg.org] :

The required skill set and the depth of technical knowledge is reduced, which lowers labor costs.

The idea is to save an expensive software team and exactly that leads to the failures people experienced with MDA (or any new technology that was supposed to make life so much easier). Those vendors sell their software to PHBs who then let their "business solution" be written by code monkeys who are not only unable to complete the task but don't even realize they never had a chance with their skill set (But they offered it for almost no money, so they got the contract!).

MDA is best served with a large mountain of salt (4, Insightful)

_flan (156875) | more than 8 years ago | (#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

Re:MDA is best served with a large mountain of sal (1)

jlowery (47102) | more than 8 years ago | (#14769266)

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. Once you find yourself writing/designing your business objects and logic to be compatible with the tool, you've gone too far. Drop the tool, stop looking at the schematics and start focusing on the mechanics.

Re:MDA is best served with a large mountain of sal (1)

cratermoon (765155) | more than 8 years ago | (#14781130)

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 development requirement is its ability to sell for $kilobucks.

MDA: use it wisely (3, Insightful)

barries (15577) | more than 8 years ago | (#14766591)

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

MDA promises, Domain-Specific Modeling delivers (3, Insightful)

stevek_mcc (444668) | more than 8 years ago | (#14766703)

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 (1)

Anonymous Coward | more than 8 years ago | (#14769318)

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.

Re:LISP promises, Domain-Specific Modeling deliver (2, Insightful)

stevek_mcc (444668) | more than 8 years ago | (#14783049)

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 representation, with a line to the other node. Good modeling tools also let you refer directly to another object, e.g. in UML the data type of an Attribute could be a reference to another Class you have created. The Attribute refers directly to the Class, rather than just copying its name, so if the name is later changed in the Class, the Attribute still points to the right thing (and sees the right name).

Alloy isn't MDA - that's an OMG trademark (and not a very good description: in what way is the architecture model-driven?). It looks like Alloy is a DSL, and it may be that the Alloy Analyzer extends that to a graphical DSM language. If I'm reading right, though, the Analyzer simply shows an analysis of a textual Alloy program in a graphical format - I haven't spotted anything that says you can build the graphical models first.

In any case, your point was presumably that you think Alloy is a good solution for improving the software development process (in some situations). That's great, and there are loads of things like it. None has yet had a major effect on the way the whole community builds software. Certainly a major reason for that is the "cowboy programming" you mention. Most organisations are at that level, but there is a growing number who are moving up the SEI's CMM maturity scale (or even some more realistic measure of maturity).

Most IT systems and game engines are developed from scratch plus copy-paste from old systems, with some 3rd party frameworks and in-house components. For other kinds of systems, like embedded systems, companies tend to have a larger number of programmers working on a larger number of products, but with more similarities between those products, and longer lifespans for these product families. This situation has pushed them to improve their software development processes, making reuse more systematic and paring down the new work needed for each product to a minimum. Those are the industries that are first to reap the benefits of Domain-Specific Modeling.

DSM will do to code what code did to assembler, what assembler did to machine code, and what chips and machine code did to building your own hardware. The industry as a whole will always need the lower levels, and there will still be advances in them, but most developers will be insulated from them and can work at a higher level of abstraction and productivity.

LISP promises, Domain-Specific Modeling deliver-Mu (0)

Anonymous Coward | more than 8 years ago | (#14786925)

I recommend [slashdot.org] the book at the end of that list. He really does have some good insights on the software development process, and a possible future.

In the end, do you want to be a programmer? (1)

Marxist Hacker 42 (638312) | more than 8 years ago | (#14767809)

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, as well as just plain art of coding. But if your ends justify your means, and profit/cost is the overriding factor in all that you do, well, memory, hard drives, and microprocessors are cheap in comparison to good code.

Magicdraw and AndroMDA (0)

Anonymous Coward | more than 8 years ago | (#14769312)

Having come from a company where we had built everything ourselves in the past (dbconnectivity, caching, logging, etc) I wanted to move in the right direction with a new startup and new product. Spring and hibernate were a must and leveraging existing libraries was key as well. I came upon AndroMDA and while the learning curve was a bit steep (banging head on desk for a week), eventually it became extremely useful. Additionally, the small handful of guys who 'are AndroMDA' are incredible with support and help.

1) You can describe your entire system with a model and validate it in MagicDraw.
2) You focus more on the design of the system rather than the monkey coding.
3) It allows changes in the system to be made without much headache. You simply provide the business logic in the Spring service Impls.
4) Adding OCL (Object Constraint Language) allows you to explicity put your queries in the model and get them validated as well. OCL will translate to HQL in code which will ultimately get translated to SQL during runtime.

Ultimately, will I use MDA again?
* Definitely!

What are the problems?
* In my opinion, it's a steep learning curve. I wasn't a pro in UML design, so that may been a problem at first. Additionally, you have to learn to understand how the models are designed and how they interact with other diagrams.

There's a number of good books about this:

"MDA Distilled" - great overview and how MDA can help you
"Enterprise Patterns and MDA" - a GREAT selection of existing patterns for the MDA world
"The Object Contraint Language" - a great reference for understanding OCL

Drawbacks? (1)

ivan256 (17499) | more than 8 years ago | (#14770295)

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't your tool becomes the ball and chain. Make sure the tool you pick has the features you need, and make sure there isn't a zealot in charge of tool selection.

Code generation (1)

ZeroConcept (196261) | more than 8 years ago | (#14771756)

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, it simplifies your life incredibly. Note that for some operations you still need to write stored procedures (bulk processing).

Writing your own code generator very, very fun and a great learning experience but chances are there is something better out there that already works, remember that you are writing an application not a code generator.

If it's an area you don't have a lot of experience with, estimating can be very hard. Do some research but be prepared to do it the conventional way if time is a limiting factor.

AndroMDA is special! (3, Insightful)

trudy_cool (956151) | more than 8 years ago | (#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 with the arrival of TomCat in 2000. I spent the intervening time, up until a year ago, in UML work and project management. In early 2005 I was faced with teaching a badly obsolescent development team Eclipse, Ant, xDoclet, Subversion, Spring, Hibernate, Tiles, Struts and jBoss, with only scanty knowledge of any of them myself! I had to find a better way. Now I'm working very successfully with all of those, with the same scanty knowledge I started with! I can depend on the AndroMDA team's vastly superior knowledge to have created the right templates in the right patterns for the right tools, where I couldn't if I had five times as much time as I have. I merely have to ensure that my UML properly reflects the problem domain and I see eminently sensible code being generated for me.




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 work on a P4 2.8GHz 500MB winduhs machine. A project with about 20 use cases and 10 persistent entities has about a 2 minute complete loop time, from an edit to the UML, to testing the up-dated web-site. That's without taking advantage of any of the switches for selective build control. Furthermore, that is about an appropriate size for a "project". Any larger and one can split the problem up and share jars between the pieces.

AndroMDA's generated code is only slightly bulkier than the hand-written code of an ordinary development team. A very experienced team might have a class library that merges into one tight set of classes what AndroMDA generates in many small variations. While this may result in a much smaller ear, the benefits of their class library accrue at development time, not at runtime, so the AndroMDA decision to live with a proliferation of similar generated files and gain the benefit of simpler, tighter templates has a large up-side (understandable code) and a tiny down-side (somewhat larger ears, wars and jars).

AndroMDA is great for quick prototypes -- once you are skilled with it. Admittedly, getting that skill is not quick. It took me at least a month to get confident. If you are already a Spring / jBoss wizard with a mature architecture then the pay-off may seem remote. But, if you inherit such a wizard's architecture you'll most likely end up hating him. On the other hand, if you inherit an AndroMDA wizard's project you'll be in heaven. Maintenance will be quite straightforward, and all the deeper complexities will be supported in the AndroMDA team's very responsive forum. You won't be all alone in the jungle.

As I say, AndroMDA does take time to learn; but it takes a LOT less effort to learn than becoming proficient with EJBs or with Spring/Hibernate.



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.

This is not applicable in the case of AndroMDA. Most of the development team will be generating business focussed apps sucessfully using AndroMDA as-is. Existing Struts developers will become faster Struts developers. Existing Hibernate developers will become faster Hibernate developers. Existing Web Services developers will become faster Web Services developers. You may want one wizard off in the corner performing special tweaks to templates and metafacades, but for the bulk of the code of the business, it's un-necessary.



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.

Obviously, there are (at least) two types of maintenance problem: application maintence and infrastructure maintenance. The whole point of AndroMDA is that the UML so thoroughly describes the code that no further documentation is necessary. When you've understood the model you've understood the application code. Infrastructure code, the 'donkey work' that AndroMDA handles so expertly, conforms to best-practice patterns such that no system developer should have any difficulty understanding all of it.

AndroMDA builds on all the benefits of many dozens of OSS projects, Maven especially. Maven, among many other things, is a tool for continuous build, continuous test. The load and stress testing you should already be doing applies unchanged to an AndroMDA project, and can be run automatically from your Maven scripts.



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.

In other words, the "MDA guru", a snake-oil merchant with a home-brew MDA, was *also* touting a home-brew O.R. mapping layer. X-( String him up by his short and curlies!



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 worked with those stinking things and you are absolutely right, they caused more problems than they solved, not to mention costing the earth. The real problem was, when they went sour on you, you hadn't a hope in hell of figuring out what went wrong.

Aside from being free as a bird, AndroMDA is wide open, so tracking down a problem is a question of educational exploration (seeing Java patterns well implemented) than guessware and "shots in the dark".



Where codegen MDA starts to fall over is ... where you need to spend extra effort installing and describing the modelling tools for downstream maintenance organizations.

This again is an appropriate criticism of roll your own MDA. My experience is that AndroMDA reduces the need for documentation almost to zero. The UML is a *very* thorough description of the system. It is also complete, consistent and tested UML, because the developers will not get through a cycle of iterative development of their piece of the problem while the UML is defective. The UML is the project documentation and, unlike UML done to plan a project, it is never obsolete.

It's worth adding that AndroMDA encourages a clear and strong separation between presentation layer, service layer and persistence layer. This becomes, in effect, a kind of "positional notation" (in the mathematical sense), that documents implicitly an artifact's role and purpose as a function of its logical location.



And if you compare the likely output from one genius + MDA versus a similar genius + many code crunchers, chances are the second choice works out better. While the many code crunchers may not be geniuses, they usually do contribute useful thoughts and feedback, something an MDA doesn't!

Wrong.

AndroMDA permits short spells of very productive work on isolated bits of a large project without any risk of losing sight of the big picture, and very little effort needed to step into the code, understand what it is doing, and implement the fix, new feature or whatever. This means that a Web Service expert can do a thorough professional job on a service, while fleshing out a Stuts prototype of how the service should be accessed and a Hibernate prototype of the persistence upon which the service would depend. He can hand off those two bits to a Hibernate expert and a Struts expert, who can apply all their expertise to getting them exactly right, maximally efficient and conformant with existing persistence-layer artifacts and presentation-layer best-practice. And, I don't mean that they would look at the rough draft, understand it, and then start again, they would easily alter it and elaborate upon it, without confusion or wasted effort.

Each of those three experts would continuously up-grade his/her professional skills as contributor to the corresponding AndroMDA cartridge forum.

In my experience the AndroMDA team will turn around a submitted valid patch to a template or cartridge, in a version SNAPSHOT, in less than a week! This means that every time your team encounters a needed improvement to an AndroMDA artifact, it quickly becomes part of the shared code-base of all AndroMDA projects and is party to all the corrective measures, on an equal footing with the rest of the AndroMDA, of the entire AndroMDA community. In other words, your problem domain logic remains an in-house venture, while your architecture becomes an Open Source collaborative venture. This means that the more of your architecture you see successfully assimilated into AndroMDA, the less of it you will have to maintain! (And if you can't get it assimilated you should probably throw it out and use the AndroMDA equivalent.)




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. Once you find yourself writing/designing your business objects and logic to be compatible with the tool, you've gone too far. Drop the tool, stop looking at the schematics and start focusing on the mechanics.


It's hard to respond to this kind of dogmatism, but I'll try.

AndroMDA's BPM4Struts cartridge uses UML Activity diagrams to describe the 'conversation' between the end-user and the Struts server. Each server-side Action State represents a single data call to a Controller function. Each client-side Action State represents a single web page. Each transition from the former to the latter represents an HTTP response. Each transition from the latter to the former represents an HTTP request. You can include decision points, tagged values and parameters as necessary to completely describe what a Struts application would do. BPM4Struts generates a complete working Struts application with sample data for all fields, breadcrumbs, help links, menus, cascading style sheets, tiles, news & events sidebars, etc. All of these are provided in such a way that you can replace them when the time is right to do so. Meanwhile your customers can tinker with a realistic working use-case within a day of requesting it, even though there is as yet neither a persistence layer nor a service layer behind it.

Furthermore, all of the goodies I mention come from templates, so the cascading style sheets, the tiles definitions, the sidebars etc, will conform to you institution's standards as you refine them to do so.

The overall experience is like describing in Activity diagrams what you want a Struts expert to develop for you ... but he does it in two minutes!



AndroMDA's Spring/Hibernate cartridge uses UML Class diagrams to describe your service layer and the persistent entities the service layer manages. Aggregation dependencies, composition dependencies, whether one-one, many-one, one-many or many-many can be described completely. The resulting code contains interfaces, base classes and implementation classes for each entity, as well as interfaces, base classes and implementation classes for the DAO for each entity. If you model a class, apply a <<Value Object>> stereotype to it and make an <<Entity>> dependant upon it, the DAO will generate further Find and Load functions that can return the entity itself, a collection of those entities or a VO for the entity or a collection of those VOs. In the latter two cases, automatic transforms are generated to cause the creation of default run-time value objects. Those transforms defer to no-action 'impl' classes to which you can add special transform functionality if the defaults are inadequate.

This doesn't even scratch the surface of the 'donkey work' the cartridge gets out of the way. Like I said the same way above ... the overall experience is like describing in Class diagrams what you want a Hibernate expert to develop for you ... but he does it in two minutes.!

All comments gratefully received.

Hasan

Four years ago... (0)

Anonymous Coward | more than 8 years ago | (#14787243)

Four years ago, a friend of mine
Asked me to write this rhyme...
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?