MDA Explained: The Model Driven Architecture: Practice and Promise (Addison-Wesley Object Technology) [Englisch] [Taschenbuch]

The authors of this book are either visionaries or unrealistic dreamers, and at this point I am not sure which it is. MDA is an acronym for Model Driven Architecture and it is a framework based on the Unified Modeling Language (UML) and other standards for representing software designs. Their main premise is that software development will eventually start with a Platform Independent Model (PIM) which represents the design of a solution to a problem. As the name implies, this is a model that does not incorporate anything that is specific to any platform.
After the PIM is created, it is transformed into one or more Platform Specific Models (PSMs), each of which is specific to a particular platform. Each of the PSM's is then acted on by a platform specific conversion tool that will create the coded solution for that platform that conforms to the PSM specifications. They argue that since this step will be electronically executed, the point will eventually be reached where code is no longer written by humans.
The authors are quite correct in pointing out the historical sequence of software development, which started with programming and constructing the computer being simultaneous events. This was followed by the development of assembly language and then the compiler, which raised the level of abstraction and caused a great deal of the code creation process to be automated. They use this background to argue that the MDA is several layers above that and a natural step in the upward movement of abstraction.
While I certainly agree that the movement in programming has been to higher levels of abstraction and more code being automatically generated, I did not find their arguments convincing. They use several examples of automatic code generation that can proceed from a model, one of which is the generation of setter and getter functions. The problem as I see it is that creating setter and getter functions for private instance variables is the easiest programming task of all. In my opinion, going from this to creating code to solve complex tasks is not a difference in degree, but a difference in kind.
Granted, the authors admit that the MDA is still in the preliminary stages, but all of us have heard stories about how tools such as web page creators continue to fail in many ways. Abstraction and automation of software have allowed developers to write programs with millions of lines of code, but there is every reason to believe that there is a limit as to how high the level of abstraction can go before it exceeds the capacity of humans to understand. Furthermore, if the tools that go from the MDA to the code do not create the precise solution, it is quite likely that the level of detail that one can write into the MDA will not be fine enough to represent all possible desired alterations from the automatically generated code. One simply cannot write all of what could be an enormous number of options into any conversion tool.
Finally, if there are errors in the code generated from the MDA, debugging it would probably be impossible. The software development community finds it very difficult to write bug-free software, even when it is written by hand and meticulously examined. Since the conversion tools would be software that would most likely contain errors, then anyone debugging the code from an MDA would be looking through software that was automatically generated from a model that may be flawed by a program that is most certainly flawed.
To conclude, I did find the book interesting and believe that some of what the authors envision will come true. However, at this time, it is clear that most of it will not happen in the near future. Our understanding of the software process is still too primitive to have the entire project successfully generated electronically from a model. There is also reason to believe that it is impossible.

The MDA looks like a very promising solution to big problems.

Big problems, almost by definition, have lots of parts. Today, that means databases, network protocols, incompatible languages, distributed processing on disparate platforms, and more. Building any one part on any one platform is easy enough. The problem is to guarantee that the database, the Enterprise Bean interfaces, the HTML forms, and everything else match each other. There are two ways to make matching work. First, you can spend the rest of your life running around and looking at all interacting pairs of things, hoping that nothing changed while you weren't looking. Second, you can derive all those parts automatically from a common source. That's what the MDA is about.

The MDA defines hierarchies of meta- and meta-meta-models. If you read between the lines, you'll probably see that each level of meta-abstraction requires a successively more knowledgeable, capable developer. This book works at the highest levels, so probably won't make much sense to entry-level staff with a more concrete and immediate view. (I shudder to think about maintenance of high-level tools by entry-level staff, and it will happen, somewhere some day.) The MDA approach assumes complete fluency with the UML, MOF, OCL, and other alphabet soup. That is necessary because the MDA half-defines transformation rules that convert a specification, in successive steps, into code. It's a bit like the filter approach of XSLT.

The good news is that one specification can be transformed into a database schema, a Java Bean, a web form, and more, by applying different transformations to the spec. Consistency is ensured, at least to the extent that the different transformation rules are correct and consistent.

There are a few problems with the MDA approach. First, the authors point out that it's just not there. It's a blue-sky spec, with no underlying implementations. A few vendors have declared their products MDA-compatible. I'm reminded that a block of wood with two nails driven in wass compatible with the electrical safety specs from the old Ma Bell days. Non-interference is a form of compatibility, just not a very interesting one.

Second, if you have a small problem, though, you're stuck. The only apparent way for MDA to handle a small problem is first to turn it into a big problem, then solve that. Victims of heavy-weight CASE tools in light-weight projects will have some experience of that already.

Third, and most critical, is that it just isn't complete enough. The transformation rules, at least as shown here, don't really have the expressive power needed for generating compilable code. That operation, the one that matters, seems to be "implementation dependent", i.e. jungle rules. Also, despite the authors' assurance (sec 12.1.3) that MDA really will generate code that doesn't need manual involvement, they have no shown that. Quite the opposite. The sample application (p.120) shows how the model generates a business-rule method, but gives no indication how that method's body is to be defined!

The MDA is interesting, but perhaps not the "paradigm shift" that the authors claim. In many ways, it's like the common code-generating CASE tools writ large. Getting to the authors' ultimate vision will take years, many incremental steps, and probably a good bit of pain on the developers' part.

Still, software is getting bigger and software problems are getting bigger. They need to be tamed somehow, and maybe the MDA will address important parts of the problems. I'm watching and waiting, but getting on with my business in the mean time.

//wiredweird

After having read this book back to back i'm left with both an eagerness to to know more about MDA and a sensation to try what is already there. The subtitle of the book really is a giveaway of its content: "Practice and promise". Practice in that it clearly describes where we stand as of now. Promise in that it gives you a feeling of what is yet to come. Maybe the best news is that it does this in slightly over 150 pages.
The combination of the two gives the reader the opportunity to actually compare the merits of the tools claiming support for MDA, what kinds of transformations they support, how much and how these can be influenced, what kinds of PSM's they support and how well they support round-trip engineering. It even goes so far to indicate what never to expect from tooling.
On the promise side, it walks you through the many OMG standards, readily explaining the gist of them and more importantly their interconnections. I wouldn't be surprised to find myself browsing through OMG standards in the near future, just to get a firmer grasp of the full bearing of their views on the nearby future of application development.
As an example of how the book may affect you: I felt rather disappointed having read through about three quarters of the book. As I realized this was not because of the book, but by the current state of affairs. I got made clear that though MDA may be a great step forward, in standardizing a thing which has been subject of research for so many years, there is still so much left to be done.
All in all not bad for a book which can easily be read in one undisturbed evening. (It actually took me two, but then again I've been doing some home improvement inbetween).