3) UML has encouraged the idea that models must be graphical. Ridiculous! Text and graphic models are both useful and often interchangeable

4) UML is at once too large and complex and at the same time very limiited. Stereotype and profiles are not effective for usable extensions.

Note that I'm not necessarily saying UML is bad. I'm simply saying that it is not helping the goal of "model-driven development", which is what I'm interested in. I don't understand the comment about "holy grail".

+1 for finding and answering a question on prog.SE about your own tweet!
–
Warren PJun 20 '12 at 22:59

So Model-driven development always seemed to me to be about having a visual model. And if not UML, then what? (note, I've never liked MDD, and I hate UML. But I'm willing to give MDD-sans-UML a shot. What should I try?
–
Warren PJun 20 '12 at 23:00

1

@Warren P : what do you dislike about MDD , and UML ?
–
dan_lJun 21 '12 at 2:20

1

I've removed my answer because clearly I was wrong about what you meant. But I stand by the statement that UML, like any language, is a communication tool, not a design tool. You responded that 'Many programming languages have the word "language" in their name, but that does not mean they are only for communication, not execution' - I think you miss the point that execution IS communication with a computer. You wouldn't use COBOL as a design tool either.
–
pdrJun 21 '12 at 7:57

I think the "holy grail" comment is in reference to frequency of being taught.
–
GlenH7Jun 21 '12 at 18:04

I think there's also a case to be made that MDD is the worst thing that happened to UML (why else would we have the UML2 that we have?), but ignoring that for the moment...

MDD = Model Driven <Design|Development>. The idea is to be able to develop solutions at a level of abstraction appropriate to the problem domain - that is, it is an attempt to express solutions to problems in the most natural syntax for expressing those solutions. The problem domain itself is characterized with an operational model (that is, by a model that can be executed by computer). So, MDD can be a very attractive approach, albeit one with two major requirements:

One must be able to compile that language into a form suitable for computer execution (the model must be operational); and

One must create a modeling language for the problem domain.

It's my understanding that the UML2 effort was intended to address point 1, probably under the belief that industrial experience with UML showed that point 2 was satisfied for some large subset of problem domains. Unfortunately, and this is what I think William Cook was getting at, UML does not satisfy point 2 for anywhere near the scope of problems that was thought. I don't speak from personal experience, but I think the industrial experience of using MDD with UML has two common outcomes:

Either the source code generated from the UML needs to be tweaked to resolve those small gaps between the UML design and the program requirements (forcing developers to work with generated code that has different standards for maintainability and reducing the applicability of the UML artifacts to the implementation); OR

The UML gets cluttered up with a lot of detail that reduces its usability as a language for communicating about the design.

In either case, the promise of MDD is unfulfilled. UML might be considered the worst thing that happened to MDD because it occupied the attention of MDD tool developers to the exclusion of models that might actually work (albeit for a smaller set of software problems).

UML is the equivalent of taking a screwdriver and a hammer and taping them together and calling it a "Universal Fastening Tool." In theory it can be used to represent a ton of things in great detail, in practice its a bunch of poorly integrated tools claiming to be a single tool, that makes doing any one task far more difficult than having a proper tool to begin with.