Friday, September 24, 2004

When did Grady Booch become such an airhead?

I can't remember where I got the reference to Grady Booch's MDA manifesto... but having had a look, it's so full of boosterism and nonsense, one wonders what planet Booch is living on.

Some specifics. Booch says:

    I’d like to clear up any fear, uncertainty and doubt surrounding MDA and present seven important reasons why organizations should consider its adoption:
    1. MDA practitioners don’t need to be highly skilled UML modelers.
    2. ...
    3. ...
    4. Business stakeholders will be able to use a Platform-Independent Model (PIM) because it transcends implementation dependencies and is easy to understand.
    5. ...
    6. MDA-based applications allow more sophisticated automated testing.
    7. MDA users won’t become locked into a single vendor.

Firstly: What exactly do "MDA practitioners" do if the don't need to be highly skilled UML modellers? Maybe the hidden meaning is that they need to be highly skilled EDOC modellers, beacuse using UML to model large apps is like using chips and wire and breadboards to build computers.

Then, even though the MDA practitioners only have low/moderate UML skills, the Business stakeholders are gonna be able to understand the PIM (in UML one presumes?) because it's platform independence makes it "easy to understand". Really?

He goes on to elaborate about how Use-case centric design, or RM-ODP viewpoints will help. Well I can see that... and then...

    In an MDA development project, this separation of concerns becomes even clearer. Each stakeholder views the application from a unique point of view (business, architecture, development, infrastructure) and contributes to the project from a specific area of expertise using an easy-to-learn subset of UML to visualize a specific domain and ensure that its requirements are clearly stated and well met.
...but the way he's talking MDA comes with built-in viewpoint integration techniques.. in UML. Rubbish!

On to "patterns are good". Yeah, yeah.

Then some hype about available tools:

    ... If your domain doesn’t have the specialized tools already available for some industries (for example, telecommunications network management and fighter-jet avionics are documented on the OMG’s Web pages), you can use general tools for your business apps. Or, if your company uses its own patterns for competitive advantage, this won’t even be an issue.
yeah - if you want to build a CRUD application, based only on a data-model, and build to J2EE or .NET, then you have tools available now. Build a fighter-jet avionics app with "general tools", and use your own patterns without issues? Get real.

Then automated testing.

    ... UML 1.5 includes Object Constraint Language with its pre-conditions and post-conditions as well as behavior diagrams optimized for testing. Still, support will improve in UML 2.0, which has features designed for automated testing built in from the start.
Yes, but it's still all in a research phase. There are NO COTS tools to exploit the UML testing profile. I'm involved in a 3 year UQ ITEE ARC grant application to investigate this. There scant few papers, let alone any robust results. It's gonna be years Grady.

Then we get into real fantasy land:

    The Heavy-Duty Strength of MDA

    MDA offers organizations at least three other distinct advantages:

    1. Interoperability and portability. The platform independence of the first stages of MDA development makes it easier to interoperate with, or even move to, different middleware. Given that the middleware space is crowded with Enterprise JavaBeans, CORBA, Web Services, SOAP, C#, .NET and others, this represents a huge savings in time and cost.
    2. ...
    3. A consistent metamodel. A company’s software archive is based on a consistent metamodel, built in UML. This allows its applications to be brought into tools as needed for integration, examination (for duplicate or inconsistent functionality, for example), or other business or technical needs. And that’s just scratching the surface of what a domain-specific metamodel can enable over the long term.
Addressing (1): Interoperability between PSMs generated on different platforms from the same PIM isn't even close to becoming a reality. In my mind this is one of the great tradeoffs of MDA... you get a reusable design, but you generate to each platform in a way that produces the best implementation for that platform... so you may not even recognise the exact form of a PIM atrifact in the implementation - much less be able to interact with the same feature generated for another platform.

As for (3): We're gonna bring in applications (not designs for applications) to "tools [unspecified] as needed... for integration, examination... or other business or technical needs". Great! I'm glad that using UML has so many side benefits. I can't wait to see domain-specific metamodels bringing about world peace over the long term.

Pah!

posted by Keith Duddy at 1:12 pm

2 Comments:

Blogger Jim said...

Keith, when was the last time that you were seriously impressed with something from one or all of the amigos? This is almost a rhetorical question, but on the other hand it would be interesting to know.

5:29 pm  
Blogger RedDragon1229 said...


Grady Booch offers nothing but cool aid. When you open his book, he makes you believe, "Ok. Here I am going to tell you everything you ever need to know about Software Engineering". He starts categorizing, naming, organizing things as if he is going to part the skies and things will become as clear as algebra :) You will be impressed beyond belief, "Why in hell, nobody wrote such a holistic book?".

Then, after dozen pages, the effect wears off, if you are lucky. If you do not get confused after 20 pages, you better change your profession. I would not seriously consider you as a Software Engineer. He starts talking about Object relations such as References, Has-A, Is-A, Agrregate, Points-to-A, Inherits-From-A, Contains-A, ... and dozens of such terms ... using them freely ... and pretending as if there is a real, concrete, observable, scientific difference between them!!

When constructing S/W, you will never get the super obvious Car-Has-A-Engine kind of design. And trying to find abstractions from real world objects often leads to grandiose designs that have no purpose in s/w construction/maintenance. You will quickly learn that, behind every decision of design, there is a solid "Requirement (of now Or of near future)". It is never about "Oh. That is the way it makes sense .. in english ... is it a IS-A or HAS-A .. hmm .. may be I should write the sentence in another language and see what design it suggests .. is it a Verb or a Noun".

You will realize, you did not learn one single concrete technique in software construction or maintenance. It took me around 2 years to cut through his thick mud and come to the realizations (And I do pride my intelligence. I have years of experience of "seeing through crap". But I did still fell for him). A lot of my collegues as well read his books with devotion. We used to even borrow books from others to read them. Now all those books are sitting on shelves. I vouch that nobody has read more than 10% of any of his books.

I think he prides himself being "thorough, comprehensive", giving hundreds or sometimes thousands of references of other books and studies to make him look very very important. I have seen it in academic environments.

9:52 am  

Post a Comment

<< Home