In a new article, Wim Bast outlines the essence of Model Driven Architecture (MDA). He makes the usual claims: reduced cost and development time, improved application quality and increased "ROI". He goes on to discuss what MDA is NOT, and details the various specifications.

Conclusion

The core problem of software development is to reconcile increased productivity with flexibility and standardisation. Until the introduction of MDA, existing languages met one or two of these requirements, but never all three. With the advent of MDA, it becomes realistic to expect high productivity within a standard environment, while retaining full flexibility. Application quality is likely to improve too, as less code is written by hand and the use of patterns help to incorporate best practices.

While MDA is consistent with a high degree of automation, it will probably never be 100% automated. Tools -- such as those based on Executable UML -- that create models at the same level of abstraction as source code, may be useful but do not qualify as MDA products. Such models are unlikely to be truly platform-independent; they make it hard to attain the quality and productivity benefits of MDA; and they blur the necessary distinction between domain model and application model.

MDA is a philosophy, not a standard; but it depends on a whole array of standards, many of which are already available. Work continues at OMG, with UML 2.0 and MOF 2.0 approaching standardisation, and other specifications like the UML Profiles, CWM, and XMI already available. New specifications like MOF 2.0 Query/Views/Transformations will enhance the MDA infrastructure still further. "Rome was not built in a day" -- over the next few years MDA promises to deliver a quantum leap in software development technology through its combination of productivity, flexibility and standardisation.

Read the full article.

MDA is basiclly UML++, and UML is basically using E-R diagrams to model C++ programs. E-R diagrams worked really well to model database schemas because it was based the high level database objects. A RDDMS table is much richer than a C++ class. And E-R enriched this model -- relationships, identifying foreign keys and subtypes.

Conversely UML has generally been disappointing -- just putting C++ into diagrams gives you C++ in diagrams. Just changing sytax to the Action Semantics Language will just change the syntax.

The key is that the model somehow a richer, more abstract view of the underlying problem. Inevitably this will be somewhat domain specific. Eg. the E-R models model persistent data stores, not real time systems (say).

The key is not lots of vacuous architect-speak about ROI and nonsense about platform independence (ever tried to move between two J2EE servers?). The key is the strength of the model.

The article mentioned Compuware. They have a product called OptimalJ which grew directly out of the Uniface 4GL. They are re-birthing the tool in MDA-speak. But it actually looked very promising. The key was that its model was at the E-R level, not the UML level. It then uses that to model the user interfaces at a very high level. That is going back to the future to add real power to the specific task of adding form based UIs to database systems.

What other practial experience do people have with real tools that provide real power?

A RDDMS table is much richer than a C++ class. And E-R enriched this model -- relationships, identifying foreign keys and subtypes. Conversely UML has generally been disappointing -- just putting C++ into diagrams gives you C++ in diagrams.

I appreciate your point. You'd likely dig the Shlaer/Mellor methodology. It uses an E-R diagram for data modeling. Behavioral interface modeling isn't allowed to pollute this diagram. Shlaer/Mellor is also what inspired MDA.

ever tried to move between two J2EE servers

Yes. Pretty easy. What did you do wrong? :)

ever tried to move between two J2EE servers

Yes. Pretty easy. What did you do wrong? :)

Possibly tried to migrate from JBoss to Weblogic :)

SCNR,
Lars

Interesting point of view about UML and E-R diagram comparison.
Though I do agree that E-R diagram based tools are transforming into
MDA based tools because that’s how future system should be designed and built.

MDA is next step forward to transform design into code and take the abstraction to higher level. I have seen main argument against MDA is that you could never build a system using entirely visual standard models. There are lot of different standards like MOF,OCL,UML profilers which can be used as mentioned by author of this article to capture complete details in these visual models. MDA is not just another code generating standard as lot of people think but it is real attempt to take abstraction at design level and in process standardize your software development lifecycle by applying best suitable uniformly across different projects which are using similar technology like j2ee.

There has been various attempts to take abstraction at design level like usage of different case tools but unable to provide suitable infrastructure and industry wide participation. MDA has much wider industry participation and much better hope at long term success. They should also try to get more and more software companies on board which truly believe in the same concept.

What I also like about MDA is that it try to generate true "Plateform independent Model" which expresses pure business rules and is completely, as far as possible, removed from constraints of particular hardware implementation architecture.

The mind shift of communicating using PIM instead of "verbal documentation" is going to take some time. The maintenance nightmare happens on project because there has been never enough value placed on design because it was seen as separate function and not considered as very productive from client point of view which ultimately cause this maintenance nightmare on projects again and again. Cranking out code w/out proper documentation has been the mainstray for software industry for long time because software team was never given enough time for creating detailed design and documentation because of this mindset. Now by applying MDA philosophy there can be real value added in design and it will certainly narrow design code bridge by leaps and bounds by by generating majority of code from actual design.

As far as tools are concerned IBM rational XDE is nice tool which support MDA lifecycle development. Also here is the link to MDA success story which shows real benefit of using MDA and how it increase ROI on projects where MDA is used.

http://www.omg.org/mda/mda_files/NationalServicesIndustries.htm

Cranking out code w/out proper documentation has been the mainstray for software industry for long time because software team was never given enough time for creating detailed design and documentation because of this mindset. Now by applying MDA philosophy there can be real value added in design and it will certainly narrow design code bridge by leaps and bounds by by generating majority of code from actual design.

It seems to me that the mainstay of MDA is metadata management in the form of PIM etc. I agree with the first line that models and knowledge capture in the form of DSL based on MOF is going to help a lot. It would be interesting to build a domain-specific language - like 'Process patterns' - distilled from years of experience. I think DSL's will be more productive in the long run than just code generation. The business experience captured as a DSL - seems that Microsoft guys are into proprietary DSL defininition not based on UML - is more powerful than generation of code. Why are we always associating MDA with code generation ?

It is interesting that somehow UML promoters want to relate MDA specs to UML but if you read MDA specs carefully then you will find that it does not recomend that model your system using visual tools like UML. It does mention as I said before that your PIM should be completely, as far as possible, removed from constraints of particular hardware implementation architecture so that same PIM models can be used in future for different hardware implementation architecture as required.
MDA or any of it's implementation tool should not be tied up to any specific domain implementation that is really not the use of MDA capabilities.

Interesting point of view about UML and E-R diagram comparison.

UML's mixing of behavior and data on its primary diagram was Rumbaugh's mistake. This part of his Object Modeling Technique seems primarily interested in a visual summary of C++ header files. Software components evolved beyond this, but UML still retains the outdated OMT baggage. UML class diagram assumes components will be implemented as stateless objects, which is misleading and invites conflicts with behavioral models. An ER diagram makes no such assumption about component behavior. That's why ER diagram is the better choice for data whose lifecycle and message queing is also modeled (in other diagrams).

While reading his, in its own way, amusing article, I can't help asking myself why people try to create the perfect way to produce software.

The article is full of claims such as "offers such drastic improvements over conventional methods", and "almost every aspect of MDA is calculated to boost productivity", just to mention a few. However, there is nothing that comes near any kind of evidence that this really would be the case.

It starts with a Platform Independent Model, (PIM), which usually is referred to as business analysis. I really do not see the difference here. This is then interpreted to a specific platform called a Platform Specific Model, (PSM). Do OMG really think they have invented software architecture? Then it seems that the code is supposed to write itself, because there is no reference to actual development except code generation tools. Is this process platform independent? Yes, I guess so, business analysis requirements usually are platform independent to a very high degree. This is the very purpose of business analysis! Does this process/methodology/language improve productivity? Well, where is the evidence?

It wouldn't hurt if there is just one single example. Why not the security policy of the standard banking example? How would this be realised in MDA, so that the implementation would be automatic, or at least trivial, in Tomcat, WebLogic, and .Net?

I note that in MDA the model consists of "pure business logic and data definitions". In what way does MDA takes into account the difference in the error handling when using HTTP rather than tcp/ip?

These are five benefits of MDA Wim Bast say OMG lists:
Reduced cost
Reduced development time
Improved application quality
Increased return on investment
Rapid inclusion of emerging technologies

"Reduced cost" and "Increased return on investment" are pointless to comment upon in this context.
I have difficulties to see the reduced development time. Is the PSM (proved to be?) so much better than ordinary business requirements and architecture specifications? Or is the (yet to be developed) code generation apparatus? Already there are a lot of code generation tools already. Compilers, SQL generation tools, the EJB framework for example, not to mention software packages such as the JDK. As early as in -98, if not earlier, it was possible to generate Java code from UML class diagrams. It is interesting to note that for all of them works from the low-level technology and up, that is you don't have a Java code generating tool without a Java compiler. They seem to want to change this with the introduction of MDA.
Before a claim such as "improved quality" it is important to define what is meant by Quality. Low error frequency, scalability, fulfillment of the specifications, low maintenance cost per line of code and year, a user friendly user interface? I do not find any attempts to do this, and therefore this argument is pointless.
I have difficulties how there can be "Rapid inclusion of emerging technologies" in MDA. By definition the language must be a compromise of the supported technologies and involved vendors, and I doubt this process will be rapid. So far MDA has been far from being rapid.

MDA is not a solution for all your problems, this is for sure :-)

The idea of PIM - PSM - Implementation is not new, that's correct. We have seen this in the area of business analysist (e.g. ARIS Concept) for a long time ago. Also in computer science we already have the "seperation of concerns" since the first day of computer science :-) Also, the idea of generating sourcecode from the model is old, remember CASE tools? Using metamodels to define your own domain specific language is also not new. So, what's new in MDA? ;-)

Comparison with ARIS
- ARIS does not tell you: HOW you can move from PIM to PSM and to Implementation. MDA tells you how: use the transformation rules for this purpose.

* Benefits:
-> Your PIM and PSM and Implementation will stay synchronized!
-> The documentation of your system will be always up-to-date.

Comparison with CASE tools
- CASE tools did not standardize the language to define your own metamodels, the so called meta-metamodel. MDA standardizes this -> MOF (Meta Object Facility). Every single domain specific language you want to create should be based on MOF. This makes it easier to exchange your metamodels and thus also your models. You use XMI/JMI for this purpose.
- MDA offers a standardized language UML to define your models. If you don't need to use MOF, you can easily use UML Profiles to create your own domain specific metamodel.
- MDA will also have a standardized transformation rule language (not yet finished).
- In "old timer" CASE tools you cannot define you own metamodels. This has been corrected through the so called Meta CASE tools. But still Meta CASE tools are not standardized (no MOF, XMI, JMI).
- Open, and this is the most valuable thing in MDA, IMO. Thanks to the standards above you can see a lot of good MDA tools in Open Source area! In the time of CASE tools era you need to pay a lot for those tools. But now, you can get it with no cost and use it in your projects. This is very important since without such an activity, you will never ever reach different "layers of developers" and thus, this new methodology will never get accepted from any developers. This is very important, IMO. Can you imagine, if you need to buy JDK before you can downmload and use it? I don't think that Java can reach its position today, if we need to pay for the JDK...

* Benefits:
-> You are not dependent on any tools (as long as they support XMI).
-> You don't need to build your own XML schemas (there are already a lot of schemas available for each domains, so please not adding more schemas ;-)) Using MOF/XMI/JMI is the way to go.
-> Transform and generate what you need! Thanks to that openess, you don't have to accept what the tools can generate for you. Instead you can define your own generation and transformation rules. Very flexible.

To be able to use MDA optimally, you need to combine following subjects in computer science:
- Architecture and Design Patterns
- Component-based Software Engineering
- Programming techniques like:
  - Generative techniques
  - Meta Programming techniques

So, for me, MDA is "just" a container for all those techniques which gives us a possibility to write applications better than before. All the benefits we get from each "part" will also apply to MDA in general.

What about "Reduced cost" and "Increased return on investment"? If you check many professional research papers (not only case studies from TSS about MDA), you can see that this is not a dream. For more information, please search the papers on the LNCS (Lecture Notes in Computer Science). They have a lot of good papers in MDA:
http://www.springeronline.com/sgw/cda/frontpage/0,10735,1-164-2-73659-0,00.html

In my experience, yes, it makes me a lot more productive to implement my applications as soon as I have some adequate "cartridges" for my purpose.

From the developer's perspective: I must say, it's a long time ago since I had those funs with my TSR (Terminate and Stay Resident) programms and my first Boland Delphi applications. Using MDA tool, especially AndroMDA, gives me this feeling back :-)

Some infomation:
Use AndroMDA within your Enterprise (Open Source) Applications:
http://ejosa.sourceforge.net
Information how you can integrate your model into your compile-build development cycle:
http://ejosa.sourceforge.net/ejosa-images/ejosa-template-process-matrix.jpg
AndroMDA:
http://www.andromda.org

Just try (Andro)MDA and don't prejudice MDA before you try it.

Hope this helps,
Lofi.
http://ejosa.sourceforge.net

It’s nice to finally see comments from somebody who see value in MDA philosophy. I really appreciate all details in your response. I do agree with points you made.

- Open, and this is the most valuable thing in MDA, IMO. Thanks to the standards above you can see a lot of good MDA tools in Open Source area! In the time of CASE tools era you need to pay a lot for those tools. But now, you can get it with no cost and use it in your projects. This is very important since without such an activity, you will never ever reach different "layers of developers" and thus, this new methodology will never get accepted from any developers. This is very important, IMO. Can you imagine, if you need to buy JDK before you can downmload and use it? I don't think that Java can reach its position today, if we need to pay for the JDK...

I completely agree.

In my experience, yes, it makes me a lot more productive to implement my applications as soon as I have some adequate "cartridges" for my purpose.

I was quite impressed with MDA philosophy and some of the tools I tried. I have been trying to get on MDA bandwagon for my next project. What might be your recommendation if somebody don’t have existing “catridges” to become a part of this technology.

I think if somebody have clear understanding and strong belief in architecture provided by MDA should be still able to implement it effectively with experienced expert advice.

I will really appreciate you advice on this.

Sincerely,
yogesh

Hi Yogesh,

thanks for your comment :-)

<yogesh>
I have been trying to get on MDA bandwagon for my next project. What might be your recommendation if somebody don’t have existing “catridges” to become a part of this technology.
</yogesh>

In the world of AndroMDA you need to have those cartridges to execute the transformation PIM -> PSM -> Implementation. AndroMDA supplies you with
- General cartridge: Java (POJO)
- Business Layer cartridges: EJB 2.x (SSB - EB), Hibernate (SSB - Hibernate)
- Presentation Layer cartridge: Struts (BPM4Struts = Business Process Model for Struts)

1. As a "user" of those cartrigdes (= developers, who develop the business applications), you just need to use those cartridges. The learning process is as follow:
- Create the models with UML (class diagrams, use case diagrams, ...) -> PIM.
- Tag your models (your PIM) with stereotypes and tagged values.
- Compile your models using one of the cartridges above, so you get the skeletons of your application -> PSM (AndroMDA uses AST for the PSM) -> Implementation.
- Implement the application.
-> This is the development cycle for the application development.

2. As a "developer" of those cartridges (= developers, who develop and maintain the cartridges), you need to understand UML Metamodel and the structure of cartridge in AndroMDA:

- The most important thing is: understand the metamodel of UML if you want to use UML for your modelling language! I think, an article in this area is what we need to spread MDA to reach more developers at the moment, because there is no good and simple article about understanding metamodels...

To understand this in AndroMDA => see Metafacades:
http://www.andromda.org/docs/andromda-metafacades/index.html
To see the metamodel diagrams of UML 1.4:
http://www.andromda.org/docs/andromda-metafacades/resources/UML14Metamodel.pdf

IMO, this part is the most difficult part since you need to think in term of "Meta" model instead of the model itself.

- If you are already fit with those metamodels, you are ready to develop your own cartridges. In general you just extend an existent class diagram (metamodels) to develop your own. You will use the "Meta cartridge" of AndroMDA to generate the first skeleton of your own cartridge. Just "eat your own dog food" :-) This is cool, since you develop your cartridges with the help of another available cartridge...

- After implementing and deploy your cartridge you can give it to your application developers, so that they can use it (see above => "user" of the cartridges).

Although you can see that the there are 2 roles (user and developer of the cartridges) in this art of development, IMO, we need to integrate both, since it is almost impossible to create a perfect cartridge just in one shot. IMO, you need to integrate the cartridge development into your application development, at least as long as the cartridges are not stable yet.
Also in some cases you maybe want to develop your "domain specific cartridges" (like in the domain of eLearning, financial planning, etc. I'm doing a domain specific cartridge eLearning for OpenUSS for example). In this case you need to integrate the development of the cartridges within your application development. Therefore I added AndroMDA into EJOSA (Enterprise Java Open Source Architecture) :-)

At the moment I update EJOSA cartridges to use AndroMDA 3.x instead of 2.x and the process of migrating them is actually pretty easy. I'll release a new version of EJOSA as soon as I finished to migrate all those cartridges into AndroMDA 3.x. If you want to know more about the cartridges in EJOSA, you can read the complete docu:
http://prdownloads.sourceforge.net/ejosa/ejosa-revo-doc.pdf?download

Generally I divided them into following structure:
- model: to make the transformation from model to model (e.g.: language transformation cartridge -> If you want to translate your model to other languages: English, German, etc.)
- specification: API -> pure Java interfaces, EJB interface, Remote interface.
- business: EJB, Hibernate, JDO, ...
- presentation: JSP/Struts, XMLC/EAF, Swing, AWT, Midlet...

IMO, it is wise to seperate and classify the cartridges into the above structure.

Hope this helps!
Regards,
Lofi.
http://ejosa.sourceforge.net

Well, if you see MDA as a nice tool to model the application I guess it's ok. Then it would work a little like UML, but a level up in abstraction. That would be great contribution since there is a lack of formal tools in that area.

How much of the final coded application do you have to model in MDA in order to make it work? Don't say all of it, because I do not think it is possible. We are not talking about toy models here, but real applications of hundreds of thousands code lines. How would a real project use it?

Cheers,
Magnus

<magnus>
How much of the final coded application do you have to model in MDA in order to make it work? Don't say all of it, because I do not think it is possible. We are not talking about toy models here, but real applications of hundreds of thousands code lines. How would a real project use it?
</magnus>

In my experience with AndroMDA:
- You can generate 100% of the specification (please read my thread above about the separation of model, specification, business impl., presentation impl...) because your spec will be just Java interfaces, helper classes, no implementations.
- In business and presentation (also test) you can generate the "skeletons" of your architecture. This is great since you can determine your own "architecture". For your domain model (EB, Hibernate, whatever), it is also possible to generate 100%.
- You need to implement the "real" methods in Java (or any other programming languages), therefore as you can see in my EJOSA page (http://ejosa.sourceforge.net), I'm for the Integration of "Model Driven Architecture" and "Sourcecode Centric Development".

As I said, it is not about "draw your model and run it" (at least not with Open Source MDA) but this is about:
- Reuse and flexibility
- Faster development cycles
- Documentation
- Communication with your customers

After I upgrade my EJOSA with AndroMDA 3.x, we'll reverse engineer OpenUSS (step-by-step) to use the power of MDA. First would be the specification, then the business and the presentation, so that at the end we will have a nice UML documentation and faster development cycle (e.g. if we need to add a property, a page, etc.).

Cheers,
Lofi.

As I said, it is not about "draw your model and run it" (at least not with Open Source MDA)...

You seem blinded by Andro. The best-of-breed open source MDA tools indeed give an executable model. Eg, JavaGen, EMF, JAG.

Brian,

<brian>
You seem blinded by Andro. The best-of-breed open source MDA tools indeed give an executable model. Eg, JavaGen, EMF, JAG.
</brian>

What I actually meant is that you still need to implement your "more complex" business logic in Java (and I'm happy with that :-), because the support of coding with Open Source IDE is great and this is not the case with coding within your UML tools ;-), therefore Sourcecode Centric Development). All the CRUD stuffs can be automatically generated by AndroMDA as you can write your own cartridge and do whatever you like.

And this limitation is also apply to those other Open Source MDA frameworks. What I meant with executable model is some kind of Mellor Executable UML...

Check the AndroMDA cartridge: BPM4Struts from Wouter and you'll wonder that you can use not only Class diagrams but also Activity diagrams to make a runnable application. IMO, AndroMDA has the best breed functionalites to compare with other Open Source frameworks, because:
 
- it fully supports UMLMetamodel 1.4. You can also plug UMLMetamodel 2.0, whatever you like. AndroMDA is based on plugable architecture.

Please don't mix Eclipse EMF with AndroMDA. For me EMF is comparable with NetBeans MDR, which is used by AndroMDA. But again, AndroMDA 3.x is independent from NetBeans MDR, because this model (or metamodel) reader is now plugable. So, if you want to, you can surely plug Eclipse EMF instead NetBeans MDR in AndroMDA. EMF does not offer you a cartridge architecture just as the same as NetBeans MDR. So if you want to compare:

NetBeans MDR + UMLMetamodel 1.4 == Eclipse EMF + Eclipse UML2

and AndroMDA sits on the top of both :-)

- it offers a very nice cartridge architecture: see the Metafacade explanation in AndroMDA docu: http://www.andromda.org/docs.

- all the code generations (templates) are also plugable. At the moment AndroMDA uses Velocity, but you can plug whatever template mechanism you like ;-)

So, all in all, IMO, AndroMDA is at the moment the best MDA tool what you can get in Open Source area. And one point you should not forget, check out their community, all the developers are all very helpful (Chad, Wouter, Matthias, etc..)

For me it is not too much use if you model your models with the *same level* as your sourcecodes (only in two different views: Model View and Code View). What important for me is really to separate the PIM - PSM - Implementation. So, this is not only about two different views (model and code) but different abstraction levels.

Cheers,
Lofi.

This is a nice article from an MDA tool vendor. It is correct that currently the level of agreement between MDA tool vendors goes as far as MOF, and not any further. Many current "MDA" tools are not yet based on a MOF compliant meta meta model, so practical MDA tool interoperability is negligible at this point.

In the absence of standardisation, it is a hard ask for organisations to invest in proprietary MDA tools. The problems of MDA have been described two years ago in http://www.softmetaware.com/oopsla2002/positionstatement.html, and since then the situation of the vendors has not changed for the better.

We now see a growing number of Open Source model-driven generator toolkits, which possibly have a much higher chance at gaining widespread acceptance. Reality is, that software development tools, including meta modeling tools (to define domain-specific languages - this is where the real potential of MOF lies) and model-driven generators, are gravitating towards Open Source; they are becoming part of the commoditised software infrastructure.

This trend towards Open Source will have a healthy effect on standardisation efforts, and it is currently accelerated by the opposing positions taken by the OMG (MDA, MOF, UML) and Microsoft. The Microsoft roadmap does include support for domain-specific languages, but does not include compliance with OMG standards. A good spot to follow the debate between the OMG and Microsoft is Dave Frankel's MDA Journal at http://www.bptrends.com/search.cfm?keyword=MDA+Journal&gogo=1.

Model-Driven Software Development (MDSD) is an initiative to provide a collection of tool-independent best practices for model-driven approaches. The MDSD paradigm has its roots in software product line engineering. Domain analysis, meta modeling, model-driven generation, template languages, domain-driven framework design, and the principles for agile software development form the backbone of this approach. For more information on MDSD, see http://www.mdsd.info.

...
For more information on MDSD, see http://www.mdsd.info.
...

Nice idea Jorn,

you surely have to add AndroMDA, NetBeans MDR into your OS projects :-)

Cheers,
Lofi.