Ivar Jacobson（Ivar Jacobson International）
Steve Cook（Microsoft）
（訳 チェンジビジョン 平鍋健児、大田緑、中原慶、近藤寛喜）
UML（Unified Modeling Language: 統一モデリング言語）に関して最もよく聞く苦情の一つは、大きすぎ、複雑すぎるというものです。
通常は仕様の2割しか使わない
UMLを使用するプロジェクトでは通常、プログラムコードやその他の納品物の80％を作成するために、UML仕様のわずか20％しか使っていません。この20％がどのようなものかは、「リアルタイムシステム」や「テレコミュニケーション」、「Webアプリケーション」、「ビジネスアプリケーション」といったプロジェクトの種類によって異なります。
何が本質的な関心事になるかは、プロジェクトの種類によって異なるかもしれません。ただ、どのプロジェクトでも、UMLの仕様で未使用になっている80％が本質を曖昧で、かつ複雑にしているのです。
この苦情に対応するためには、UMLを複数の異なるユーザーのグループを意識して、別々に記述する必要があることは明らかです。一般的なUMLユーザーとしては、分析者、設計者、Webサイト構築者、データベース設計者、開発者、オペレーター、アーキテクト、テスターなどが挙げられます。
こうしたUMLユーザーは、それぞれ異なる観点でUMLのサブセットを使っています。実際には、それらのサブセットは重複している部分が多くあります。
依存関係が多く、分割定義が困難
ユーザーの中でも、UML自身の設計者とUMLツールの開発者は特別な存在です。UMLが複雑になればなるほど、これらの設計者を苦しめることになるでしょう。完全で、矛盾が無く、拡張可能で、かつ他の言語と統合することができるように言語を設計する作業はとても難しくなり、結果的に仕様に潜む不具合の数が増えてしまいます。
図は、UML2の主要な構成要素（メインコンポーネント）とそれらの依存関係を表しています。いくつかの階層で構成していますが、全体的な構造は多くの循環参照を含んでいます。このため、言語を使いやすいサブセットに分割定義するのを難しくしているのです。
