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