MDA seems to be a technology that is either loved or hated. There has been an interesting discourse between Eric Newcomer from Iona, and Stefan Tilkov. Common ground was found. As is often the way, there is a place for many technologies.

It all started with Eric Newcomer's statement:

Many people look toward graphic arts, line drawings, boxes, circles and arrows to find the future of software.

But I can't really see it.

Software has been language based since the beginning. Proposing that in the future, software will be written using UML and MDA is, to me, like saying books will be written entirely with pictures.

Ok, so some books are entirely pictoral, and icons are important if not critical to human life as we know it. But I can't really see how it's possible to impart real knowledge without using language. Or create precise enough computer instructions.

I can't see that the drawing approach will really work. I don't know of any graphical software development tool that has yet to address the entire lifecycle; or that generates code of sufficient quality.

I think it's just a problem that isn't meant to be solved.

Since then the common ground was formed:

• Models can have common ui notation and be graphically driven
• Models can drive metadata
• The graphical notation and the resulting metadata are two completely different concepts and should be managed that way
• XML is a great way to drive a metadata approach

Read:

Jeff Schneider's round-up

Eric Newcomers original post: Graphically Yours

Stefan Tilkov in More MDA Critique

There's always some degree of overzealousness when evangelizing new methodologies. Here's an interesting quote from a recent article about offshore outsourcing by Joe Celko (the SQL guru):

For us, the particulars are new technologies and model-driven architecture. Any detail work can go to the developing nations.

He claims that those involved in construction/implementation are code monkeys, and their jobs will soon -- or should -- be outsourced, and those involved in the design (exemplified by MDA) are the new jobs of the future.

Personally, I disagree. Coding AND design aren’t necessarily disjoint activities. You can sometimes design or improve a design while you’re coding (XP/Agile), and sometimes you can do some coding while you’re designing (RUP) to make sure your design is feasible and isn’t a castle in the air.

Beware of "architects" that are allergic to code.

Beware of "architects" that are allergic to code.

Architects are well versed with designing the Application and focus more on the issues which can be noticed upfront and taken care of , and I believe the Architect definetly must have passed throught the coding phase? Dont you have the opinions matchining with mine , so let them foucus on the issues for which they are hired , ya design related issues .

Beware of "architects" that are allergic to code.

Architects are well versed with designing the Application and focus more on the issues which can be noticed upfront and taken care of , and I believe the Architect definetly must have passed throught the coding phase? Dont you have the opinions matchining with mine , so let them foucus on the issues for which they are hired , ya design related issues .

In our team we have designers who rarely have coded before. I don't mean analysts or architects, but designers who can't code really. Senior developers are good rooted in the hierarchy and they have more power, although their knowledge might be outdated in some important areas, like coding. Such a senior developer became project leader. He liked to work with a special junior coworker so much, so he let him rise up in the hierarchy nearly up to his level. This junior developer has nearly no experience in programming. But he designs the applications with the project leader, who also has nearly no experience in programming. As long as they can command the coders, they feel happy I think.

Beware of "architects" that are allergic to code.

Architects are well versed with designing the Application and focus more on the issues which can be noticed upfront and taken care of , and I believe the Architect definetly must have passed throught the coding phase? Dont you have the opinions matchining with mine , so let them foucus on the issues for which they are hired , ya design related issues .

In our team we have designers who rarely have coded before. I don't mean analysts or architects, but designers who can't code really. Senior developers are good rooted in the hierarchy and they have more power, although their knowledge might be outdated in some important areas, like coding. Such a senior developer became project leader. He liked to work with a special junior coworker so much, so he let him rise up in the hierarchy nearly up to his level. This junior developer has nearly no experience in programming. But he designs the applications with the project leader, who also has nearly no experience in programming. As long as they can command the coders, they feel happy I think.

I think your designers play just the role of Domian specialist , probabily capturing the function requirements and then delegating the techical work to the Developers.But to be the genuine architect one must have passed throught the coding phase extensively , that is my opinion

The major problem most developers have is a religious one. We, being a former hand-down developer, have been culturalized that hand-cranking code is the best way to create...or this one I get a lot..."I have my own libaries I maintain. I don't need it." Needless to say, the person maintain everything by hand..and nothing is documented! As part of the past expereince of trying CASE tools from 80s, the tools alway bound you to the architecture dicated by the software vendor. The primary difference between CASE and MDA is MDA gives the ability to take the change the architectual deployment targets.

The mind shift of communication of pictures from the PIM instead of the "verbal documentation". The cranking out of code w/out proper documentation has been the mainstay for our industry for the past 40 years. Now that you can have good workable code from a model, then on top of that...if you don't like it, you can change it in the PSM level. I always get a good chuckle when I hear some called "experts" say that MDA won't work...its too hard. I had to hear from industry experts 8-9 years ago that the web was a joke. Even Billy Gates said the web was not going to be taken seriously. Enough of the soap box.....

MDA/UML is the future of development. When you can approach 90%+ source code generation from a UML/PIM/PSM Model, it makes BUSINESS SENSE TO USE OR TRY MDA IN A COMPANY. MDA should and will have off-shore development quaking in their boots. If you own an off-shore development house...enjoy the time..because its short-lived. Its going to be a combination of Agile/MDA process moving forward.

My thought is that Aspect-Oriented Programming makes MDA feasible. Domain classes that implement the domain model are cleanly generated, then the other system functionality can be woven in via the aspects. The domain model itself is but one dimension in a multi-dimensional system.

Essentially aspects take care of the bi-directionality issue that has plagued efforts to implement MDA.

My thought is that Aspect-Oriented Programming makes MDA feasible... Essentially aspects take care of the bi-directionality issue that has plagued efforts to implement MDA.

My line of tought goes in the same direction as yours... AOP and MDA are very complementary. While it's possible to do the equivalent of AOP with code generation, it does not really solve the problem that AOP as been designed to solve. With MDA (without AOP), you still have to have to implements your cross-cutting concerns in your code generation templates. This complexify the templates for nothing and there will be duplicate code in different templates.

MDA alone is fine when you want to to transform a PIM into a PSM, like when you want to make some Entity class in the PIM an Entity Bean in the PSM. This kind of transformation is very difficult (probably impossible) with AOP. However cross cutting concerns like logging, fine-grained security, context management, transaction management are more easily (and cleanly) done using AOP.

BTW, we are in the infancy of MDA... Tools are just begining to appear on the market (and none of them are perfect). Architects, designer and (the most important) customers are just starting to get a grasp on how to implement the approach in real life projects. It will take some successes and a lot of faillures before the best practices are defined. I do beleive that the overall goals of MDA will be achieved and the software development industry will grow up as a result.

Emmanuel....MDA product have been around for 8+ years. This is not a new technology. I have been working in this space for 6 years. The only instance that I have found where MDA does not make a very good play is with building portals. Portals require very little transaction management, generally just push content. When it comes to building a system, or having to integrate a group of systems across an enterprise..MDA scales and the technology delivers. The problems that I have seen, because companies usually get themselves into trouble...which they hire me to bail them out...is that they underestimate the impact of MDA within an organization...from Key Intiatives all the way down to operational maintenance. That is the falicy of package software..thinking that package software will get you there quicker...but it doesn't. Its usually about 4X more expensive to implement a package software than customize development. Now with MDA, pending the application, package software is about 8-9x more expensive than a MDA approach.

Remember all....You still have to design anyway...why not use a PIM/UML for the communication module with an org. It works great.

With MDA (without AOP), you still have to have to implements your cross-cutting concerns in your code generation templates. This complexify the templates for nothing and there will be duplicate code in different templates.

The claim above in bold is a myth. Templates can be normalized by refactoring out common code into template utility methods. Cross cutting concerns were addressed in model compilation decades ago. Eg, Shlaer/Mellor 'coloring'.

Stan, your points are spot on!

What I often hear most is that MDA/Code Generation/etc
cuts out my creativity! Yeah right. How much "creativity"
is there in writing a DAO?

This sort of thing is monkey code and automatable.

This is a circumstance of our creation. It is called *PATTERNS*.

I have been in IT since the mid-1980s. I have written more
lines of code in various languages then I care to think
about. After a while the code patterns become pretty damn obvious.

MDD (Model Driven Development) properly utilised, allows
me and my team to generate the 80% of the grunt, repetitive
crap code and focus on the 20% that actually has some
meaning. *Thats* where we get creative!

Can anyone give an example of non-trivial Enterprise System developed and maintained using MDA tool? What kind of software development methodology work well with MDA? Which MDA tools are available in market that go well with large applications?
 - Parag

To answer your question directly...its best to get an MDA Practioner. Someone to guide an IT Team through the process. MDA is a different paradigm shift for IT teams, however the greater shift is with the operations and business people.
Here is a link of a project I did to replace a Fortune 1000 company's ERP system with MDA.

http://www.omg.org/mda/mda_files/NationalServicesIndustries.htm
http://www.omg.org/mda/mda_files/11-03_Sewall_MDA_paper.pdf

Remember "A Fool with a tool is still a fool".

Stan Sewall

Thanks foy your inputs. Surely your success stories on OMG site are very valuable.

MDA has been around for quite a few years and has been proven in large enterprise-strength applications. Ofcourse, it is not a silver bullet; and, ofcourse it will continue to evolve and improve.

In our establishment, we have a long term vision of increasing average IT-employee productivity by 25% each year, with the help of MDA, AOP and UML. We realize this will be true only for new development, not for maintenance work.

Currently, we have about 120 analysts, architects, developers working on new development. Assuming we acheive our goal of 25% annual productivity improvement, in 4 years, we hope to get the same work done with just 60 people.

Does that mean 60 people will lose their jobs? No. They will join the 800 IT people who are assigned to xisting (a.k.a. legacy) systems.

In our establishment, we have a long term vision of increasing average IT-employee productivity by 25% each year, with the help of MDA, AOP and UML. ... Does that mean 60 people will lose their jobs? No. They will join the 800 IT people who are assigned to xisting (a.k.a. legacy) systems.

Legacy maintenance, the last refuge for hand coders.

That's a cheeky response...but an accurate one.

Think about this....anything that does not have a model/PIM attached to it will be a legacy system. Including non-MDA J2EE systems built!!

I have been developing J2EE applications for about 2 years using MDA and I constantly read these discussions about how silly MDA is because you could never build a system using entirley visual models!

Well, if you read the MDA standard it actually does not specify that you must model your system using a visual model. It does say that your PIM and PSM should be expressed in a formal language (ie, one that a computer can parse and understand).

The thing that is starting to make MDA popular is the availability of languages that are both formal and visual (ie UML).

In the MDA projects I work on, the PIM and PSM models are about 50% visual (ie using UML. The other 50% of the model is made up of property extensions and formally expressed business rules (eg if, then, else etc)

The real importance of MDA is not the visual use of UML at all. It is about mapping the business requirements to appropriate levels of abstraction. In MDA this is done by having a Platform Independent Model, A Platform Specific Model, A Code Model, a method to transform between your models and a way to preserve detail changes to each model.

We laugh at the very idea of writing Assembler by hand these days, once upon a time Assembler writers laughed at the ridiculous notion of a compiler!

4GL's were one step up from 3gl code, however these have been too specific to certain kinds of applications, proprietary and sometimes inflexible.

MDA has a better hope at long term success at raising the level of abstraction and Software Development because it is efficient, flexible and based entirely on open standards.

Chris Young:

In our company we don't even get the time to make an analysis modell. Now you expect companies to abstract even further, to create a platform independent model and then a platform specific model.

I don't know if the company I work for is thinking in short terms and neglecting the long terms and the big picture. But I could imagine, that there are some more companies, who just use one model, the design model (because of time to market and intitial production costs).

Someone talked that MDA contains a platform independent language. We already have that: Java. So what do you suggest? Leaving Java and learning that MDA programming language? Of course there are differences, but basically I think that trading Java for MDA language is just the same thing in pink color.

Now you expect companies to abstract even further, to create a platform independent model and then a platform specific model.

Ideally the PSM would be automaticly generated, so the human is responsible for only one model. This is akin to writing Java once and having it automaticly translated to machine language by a variety of platform-specific JVMs at no additional cost.

Chris Young:In our company we don't even get the time to make an analysis modell....Someone talked that MDA contains a platform independent language. We already have that: Java. So what do you suggest? Leaving Java and learning that MDA programming language? Of course there are differences, but basically I think that trading Java for MDA language is just the same thing in pink color.

Perhaps if you did spend more time on the analysis and you used MDA principals, then you would spend less time hand coding, then have more time for analysis on the next project :-)

Actually, you make a good point about Java being platform independent already. Sure it is, if you already have written a java application you expect it will run independent of the hardware you choose (as long as there is a JVM or Application Server for that platform). But will it automatically be Independant of the Architecture?, ie, will it run 2-tier or 3-tier? Will it be a web application or a SWING application, or SWT? Most Java is written to a "Platform Specific Architecture", which means you have to re-write a 2-tier application if you want it to use EJB's properly within an application server.

In MDA terms a true "Platform Independent Model" is what which expresses the pure business rules, and is completely, as far as possible, removed from the contraints of a particular hardware/implementation architecture.

If you are clever about it, nothing stops you expressing your PIM using the formal syntax of the Java language to define loops, conditionals, business object references, business attributes etc. This PIM can then be transformed automatically to multiple platform specific models (eg Web Model, EJB model, DBMS model, Web Services model, CORBA model, .Net model, Cobol Model etc).

There is some up front work to write your PSM transformations, but this is akin to spending time building an assembly line for a Car factory. Your factory will take longer to build than a factory without an assemly line. But who will put who out of business in the end?

For a long time developers have been looking for the holy grail of re-use in the Components themselves, many now realise that the re-use is in building the correct assembly lines. These days we call them "transformation patterns".

Eventually, traditional "code cutters" will decline, and new 21st century jobs will be created: "Pattern Developer", "Transformation Engineer", "Platform Independent Modeler", "Platform specific modeler" ... Don't scoff - these jobs are already here!

Software has been language based since the beginning

That statement was enough for me to decide not to read the article. UML is a language. Java is a language. Assembler is a language. Object code is a language. Just different levels of abstraction.

For specific domain, applications can already be built visually.

One quite nice example is Lego robots. You can write advanced programs and even use subroutines (abstracted as blocks). My 9 year old son does it all the time. It's REAL programming, just visual.

But I can't really see how it's possible to impart real knowledge without using language.

XMI is a language. Eric is a fool.

Eric seems to lack the knowledge required to make any conclusions on the subject of software design (and whether or not we need graphical models for it).

His article "Graphically Yours", is just a tad bit naive (and vague - hence he isn't really saying anything new or relevant). Perhaps Eric needs to read books such as "Building J2EE Applications with RUP" (assuming he hasn't read it already) and he should also read Eric Evan's book on Model Driven Design.

After reading his blog it seems to me that
Eric's frequent references to "...I can't really see it"
and "...I can't really see how..." that he is *not*
a visually oriented person. This in not a bad thing
just an observation.

For him, modelling or "...the drawing approach..." does not
work for him. He writes "Software has been language based
since the beginning". I could construe that "language based"
is more like "text"(?).

I am not saying his view of the UML/MDA landscape is
wrong, maybe different from mine.

For me, I think in pictures. So modelling (UML) is natural
It allows me to *communicate* what I see in my head.

MDA (for me) is a reasonable extention to transform those
pictures into working code.

I am not suggesting that MDA is some "silver bullet" to
some how graphically (magically) write 100% working code.

I will say that if MDA technologies can generate from
models 80% working code with some degree of efficency
than I am all for it! That leaves me and my team the
20% to focus on the business logic.

After reading his blog it seems to me that Eric's...*not*a visually oriented person. This in not a bad thing just an observation.

Actually, it *is* a bad thing to be an engineer with trouble visualizing. 90% of the human sensorium is visual. An architect who can't sketch is handicapped.

Text procedures predominate since they're suited to very primitive editors (vi, emacs). That's an historical bias towards editing text. Don't assume that what's entrenched is inherently best.

I will say that if MDA technologies can generate from models 80% working code with some degree of efficencythan I am all for it! That leaves me and my team the 20% to focus on the business logic.

In my eyes, using UML starts to get cumbesome and unproductive after covering maybe 33% of your application's design/implementation with UML/MDA. Now imagine how cumbersome MDA would be if 80% could be covered by it. Executable UML? I don't believe in such a ultimate goal.

Do you know that gold can be created artificially? Don't ask me how, a teacher told it to us many years ago. But its many times more expensive than digging for the gold. Now apply this example to xx% MDA and you know what I mean.

I have another example against MDA and too much UML.

The Germans built the biggest railroad gun ever. It is called "Dora". They thought, guns are good, so lets make them bigger, then they must be even better. This sounds logical, but it wasn't. It didn't "scale". The sideeffects scaled much more than the effects.

In my eyes, executable UML and MDA is an attemt like "Dora". The sideeffects of it will scale much more than the effects.

By the way, the even invented a rifle which could shoot around the corner (really). That would be an analogy to Entity Beans ...

Hans...the problem with your statement is the fundamental premise of UML. To say that UML would be too cumbersome once you reach a certain level...

Well my response is that you still have to design in UML/PIM. Almost all of the vendors only require you to use between 4 - 6 of the fundamental designs of the UML standard. Now you actually have a working bridge between the design and code. The problem with the industry is that developers don't like to document what they do....or, this is the biggy....there has never been a value placed on design, because it was seen as a seperate function. Now...the design=code bridge is mature enough to work mission-critical application in the org.

Yes you are right, the Germans developed on a gun to shoot around the corner. In 1944, because of constant village fighting with Allied forces against Germany, the US Army developed a device that fits on the end of the M-1 rifle to shoot bullets from around the corner as well.

The analogy is, "It doesn't hurt to copy a good idea."

I can't really see that there's no room for
an approach that saves me work and lets me focus on
keeping my customers happy (that's supposed to be
the end result isn't it?). Certainly no generator can
assume what doStuff() means to my application, I need
to code that. Why is it so wrong if plumbing and/or
persistance are handled for me provided I can control
and modify the output to my satisfaction?

Most people who are continually facing real development issues
don't want to keep rewriting the exact same code in a different situation.
Otherwise there'd be no Xdoclet or other tools of it's type.
If the tools actually let me draw 40-80% of the grunt work,
with a reasonable measure of control, what's the problem?
No one is suggesting a drag-n-drop world, but it seems
pretty feasable (even if the tools aren't mature enough
today) to model the obvious stuff with enough success
that I can save valueable time for me and my customers.