MDA revisited
Martin Fowler has an excellent piece about MDA on his blog. Also be sure to check out Fowler’s link to Dave “Bederra” Thomas’ article on UML.
It seems like quite a few people who are knowledgeable about MDA dislike Fowler’s article quite a bit. I thought it was time someone who knows MDA and is not starry-eyed about it chipped in. Yeah, that would be me, your humble host ;-). I have worked quite a bit with Compuware’s tool OptimalJ, and presented this tool in many forums.
I think MDA’s concept of the Platform Independent Model (PIM) and Platform Dependent Model (PSM) captures a very important point. Application development involves both domain knowledge (platform-independent), and technical architecture (platform dependent). It is a Good Thing if the platform independent model could be created independent of the platform specific model. This is especially true for the numerous applications whose most substantial effort is in creating CRUD (Create Retrieve Update Delete) behaviour for straight-forward datatypes. This is not too much more advanced than the basic “powerbuilder way”. For applications where it is appropriate, it is extremely beneficial. So far, MDA is right on the money, and probably the smartest available investment you could make (IMHO, of course).
However, the next transformation in MDA is from the Platform Specific Model to the Code Model (or just code). Now this seems to me to be very wrong. The transformation from the PIM to the PSM is a change in semantics, as an application gets mapped to an architecture. But the transformation from PSM to code is just a different view of essensially the same model. This is the Together/Intentional Programming/Jackpot idea, and I think it is an idea that is going to be significant long MDA is forgotten. During the evolution of modern programming tools the logical structure of a program has become more and more visible as a part of the coding process. For a simple example of this, just notice how no self-respecting IDE would come without and outline view in this day and age. The tree structure contains a lot of the same information as an UML class diagram would. And it maps one-to-one to the code.
I get the impression that MDA and UML researchers are often too far removed from the day-to-day struggle of programmers to see what kind of tools and ideas catch on. I also get the feeling that focus on visual models that they tend to forget that the programming language source code is also a model. This is of course only partially true, as witnessed by tools like Eclipse’s Modeling Framework, which can use Java code as a PIM in MDA-like transformations. The book “MDA Explained” explicitly describes code as a model. I still feel MDA only pays lip service to the code model.
I do not share MDA’s enamorment with visual models. There are some things that can be adequately expressed visually, but many things that can’t. Martin Fowler has pointed repeatedly to the issue of visually representing behavior. Dave Thomas does the same in “UML2, OCL, MOF, EDOC - The Emperor Has Too Many Clothes”. I won’t belabor the point, but I want to remark that visual programming languages are by no means new. I have here a picture of topological sort in ProGraph. ProGraph was first developed in 1982 and is not in widespread use today. Looking at the example side by side with the same code in a textual language, this does not surprise me. On the other hand, a class model - or a tree navigator - can give an excellent overview of the structural relationships within a program.
My claim is then that visual languages are good at only a subset of the elements that makes up a complete program. At others, it is a step back relative to the precise textual description of source code. This is the most important reason why MDA as it is currently described will not be where we end up in ten years from now.
There are a few points I still want to make:
- When you generate some code from any (visual) model, and then edit that code, the complexity that you have to deal with might be far greater than with “hand-written” code. This should be considered before choosing an MDA approach: If the amount of change necessary to the code model is substantial, the added cost could be greater than the aquired benefit from using MDA. This depends upon your program, of course.
- MDA’s goal of moving software development to a higher level is laudable. Equating higher level with visual programming like the UML is extremely naive. I think this conception witnesses that the MDA drafters are bad architects [1].
- MDA’s goal of separating business code (PIM) and technical code (PSM) is a laudable one. It seems to me that the assumption is that transformations and target architectures will become commodities, however, and I am not sure how realistic this is.
- The real goal is creating better programming languages and libraries. I believe any viable language will have a textual form, although for many tasks, programmers would find the visual form faster to work with. This is my understanding of the idea of Simonyi’s Intentional Programming.
In closing, I must express that I am somewhat frustrated with intelligent people who criticize MDA without having seen it in action. Mostly, my frustration is in the fact that valid points get dismissed because said intelligent people don’t have enough knowledge about MDA. If you are such a person, and are in or around Oslo, Norway - or you’re coming to rOOts 2004 - I am more than willing to give you a lightning-quick demonstration of MDA so you can criticize it with some authority. Mail me at johannes (at) brodwall (dot) com. Thank you.