「UMLはMDDにとって最悪の事態です。幸いなことに、多くの人々がこれを認識しています...」
私はその主張の背後にある理由を知りたい（明らかに、彼の個人的な意見に言及していない）。
私は、世の中の多くの人々がUMLをそれほど好きではないことに気付きました。また、UMLが効果的な設計とモデリングの聖杯である学界にいることを言及する価値があります。
回答:
さて、私は元のツイートを投稿した学者です。ツイートは学術記事を意図したものではありません。それらは広告であり、議論の余地があると思う。フォローアップのツイートは次のとおりです。
1）UMLはオブジェクト指向設計をモデル化するために作成されました。これは、システムの動作ではなく、システムのコードをモデリングしていることに影響します。UMLのレベルが間違っています。
2）UMLの7（または13）図形式がすべてをカバーできるという考えはおかしい。GUI、Webワイヤフレーム、認証などはどうですか????
3）UMLは、モデルはグラフィカルでなければならないという考えを奨励しています。とんでもない！テキストモデルとグラフィックモデルはどちらも有用であり、しばしば互換性があります
4）UMLは一度に大きすぎて複雑であると同時に、非常に制限されています。ステレオタイプとプロファイルは、使用可能な拡張機能には効果的ではありません。
UMLが必ずしも悪いと言っているわけではないことに注意してください。私は単に「モデル駆動型開発」の目標に役立たないと言っているだけです。これは私が興味を持っていることです。「聖杯」についてのコメントは理解できません。
UMLは、ドライバーとハンマーを取り、それらを一緒にテーピングし、「ユニバーサルファスニングツール」と呼ぶことに相当します。理論的には、多くの事柄を非常に詳細に表すために使用できます。実際には、単一のツールであると主張する不十分に統合されたツールの束であり、最初に適切なツールを持つよりも1つのタスクを実行するのがはるかに難しくなります。
MDDがUMLに起こった最悪の事態であるというケースもあると思います（他にUML2があるのはなぜですか？）が、現時点ではそれを無視しています...
MDD =モデル駆動型<設計|開発>。アイデアは、問題領域に適した抽象化レベルでソリューションを開発できるようにすることです。つまり、問題に対するソリューションを、それらのソリューションを表現するための最も自然な構文で表現する試みです。問題ドメイン自体は、運用モデル（つまり、コンピューターで実行できるモデル）によって特徴付けられます。したがって、MDDは非常に魅力的なアプローチになりますが、2つの主要な要件があります。
おそらく、UMLの工業的な経験から、問題ドメインの大部分のサブセットでポイント2が満たされていると考えられていたため、UML2の取り組みはポイント1に対処することを意図していたと思います。残念ながら、これがウィリアムクックが得ていたと思うことです。UMLは、考えられていた問題の範囲に近いポイント2を満たしていません。私は個人的な経験から話をしませんが、MDDをUMLで使用する産業経験には2つの共通の結果があると思います。
いずれの場合でも、MDDの約束は果たされていません。UMLは、MDDツール開発者の注意を実際に機能する可能性のあるモデル（ソフトウェアの問題の数は少ないものの）の除外に集中させたため、MDDに起こった最悪の事態と見なされる可能性があります。
UMLは、単なるモデリング言語である限り優れています。グラフィカルビューを取得するためにMDDをUMLに接続しようとすると、役に立ちません。MDDはUMLなしでも、MDDなしのUMLでも素晴らしいでしょう。
UMLとMDDが今日一緒にいないより良い生活をするために今日離婚したとしましょう:-)