Model Driven Architecture / 秋梦无痕

Model Driven Architecture

Model Driven Architecture
2 February, 2004

Some people think that Model Driven Architecture(MDA) will be biggest shift in software development since the move from assembler to the first high level languages. Others think that it's nothing more than Night of the Living Case Tools. I'm in the latter camp but feel the need for more than a slick saying.

Much of what's being said now for MDA was the same things that the CASE tool community talked about in the 80's. I think CASE tools failed for a number of reasons, but underlying it all was the fact that they couldn't come up with a coherent programming environment that would allow people to build general enterprise applications more effectively than the alternatives. Certainly CASE tools can help, often considerably, for particular tasks. I'd rather draw up a database schema with a graphical schema designer than typing SQL into TextPad. But too many things were either not possible or much harder with CASE environments.

So my question is whether MDA alters this. The UML grew out of notations that are pretty reasonable for sketching to convey design ideas. I use UmlAsSketch heavily, but the degree of formality and cohesion that's required to turn UML into the complete solution that's needed for MDA to work is much tougher. Certainly with UML 2 many people have worked hard to try to make the UML computationally complete. But much of this is done on paper, without clear examples and experience of what a platform using the UML would be like in practice. Even if the UML is computationally complete, it has to be a more effective environment for software development than the alternatives. As one who is familiar with both the UML and the alternatives, I have to say I don't see this.

As an example, consider behavioral logic. I can't see that drawing sequence diagrams or activity diagrams is as good, let alone better, than writing code in a modern language. I find this is true even when I have to write code to a greater degree of precision than the diagrams, as I do if I want to execute and test them.

Even if the UML forms an effective programming environment, it still needs to become a popular one. As an ex-Smalltalker I know only too well that even the best languages don't always make it into the mainstream.

Other arguments for the MDA are secondary, but also unconvincing.
·Having an OMG standards stack is certainly something that the 80's CASE tools lacked, but we'll see how well people stick to it. One thing that's struck me is how many MDA fans seem to see UML as the UnwantedModelingLanguage.
·MDA proponents talk about platform independence, but I've already dismissed this as a PlatformIndependentMalapropism.
·I've heard about how MDA will simplify development by allowing automatic generation of patterns. But I don't see a difference between what you can do in UML and what can be done with good libraries and frameworks. (As well as the fact that generating pattern implementations is missing at least half the point of patterns.)
·Much of the boosting of UML seems to be based on the statement that pictures are better than text. In cases this is true, but I see no evidence for that in general - anyone who has compared flow charts to pseudo code can form their own conclusions.

In many ways I'd love to be wrong about this. I would really like to see software development raised by a level of abstraction. (Not to mention that the UML's success would be good for me personally.) But I don't see that the UML provides this abstraction jump - and without it the MDA will not succeed.

Interestingly there is a growing sense that a broader group of people want to do MDA without the OMG standards. I'm hearing more about Model Driven Development using tools other than the OMG's MDA stack.

Here's some other thoughtful criticism of the MDA:

·Steve Cook talks about Microsoft's views on MDA and the broader issues of Model Driven Development. Steve was a central contributer to the UML as well as a leader in the early days of OO in the UK.
·"Bedarra" Dave Thomas gave a spectacular display of energetic skepticism at the MDA panel at OOPSLA 2003. Sadly I don't have a video of his performance, but an older jot column captures some of the depth of his argument.

-----------------------------------------------------------------------
Rickard Oberg关于MDA的看法：

摘自Rickard Oberg的weblog。

MDA: into the twilight zone
15 September, 2003

As the JavaZone conference is due this week (with me doing two talks about AOP), I was reading up on MDA (Model Driven Architecture) today which is the panel debate topic. I was initially supposed to be included in the panel, but just heard that I had been cut. Which considering my findings is probably a good thing. What disturbs me the most with MDA is not the "silver bullet" heraldry of it being the final solution to how we can now finally program using models, something which has been said before and never happened properly due to the complexities of round-robin modifications between models and code. No, what disturbs me the most is the view of reality that one must adopt in order to accept its, almost religious, promises.

MDA centers around the idea that it is possible to create models of an application that are platform and implementation neutral, and which can then through a series of transformations (largely automated) be converted into code, thus allowing the developer to ignore the details involved with architectures that are used to implement the models. Right there I think most developers' BS meters are triggered. The assumptions are that a) it is possible to create models that capture the requirements of the application and b) these models are better than writing code. Personally, my experience is that neither are correct, at least not for any so-called serious application (Note to self: I wonder how many MDA tools are implemented using MDA).

Most MDA papers and articles that I have read to date state that these transformations are to be done by highly skilled individuals (aka "architects"), which will then allow lesser mortals (aka "developers") to create applications by doing models which are then transformed into code. It is explicitly noted that creating such transformations is difficult. It is then said that individuals with specialized coding skills are going to become obsolete since one can now let cheap off-shore developers use MDA to create applications. Comparisons with the computer- and car-industry are common in MDA articles and literature.

This is the scary part. Individuals are effectively pigeonholed based on their title ("architect" or "developer"), and there seems to be little incentive for individuals in the "developer" slot to learn more and work towards acquiring "architect" status. Why? Since all they are doing, with the wonders of MDA, is to create models which they use to build the applications. In other words, there does not seem to be any natural knowledge transfer, and teams will become even more hierarchically tied to the title one has acquired.

To me this is a fucked up view of reality. It is encouraging a mentality that I believe is elitistic and contrary to the spirit of both OpenSource and XP programming. It also encourages developers to not understand what they are doing, since such details are dealt with by the transformations created by the architects. This obviously lowers the demands on the knowledge that developers using MDA needs, and as such I have no doubt that it will become immensely popular in certain circles, and will no doubt help rationalize many developer organizations. However, I'm also pretty certain that I myself, and anyone I work with, will never ever use MDA. I hope this one will rest in peace in the not too distant future.