どの程度標準的なのか 標準UMLとは？

(マーティン・ファウラーのコラムより。元々は1999年春号の『Distributed Computing』誌に掲載)

数年前、私のコンサルティング生活で最もうんざりする側面の一つは、方法論論争でした。どの表記法を使うかについての激しい議論です。これらの論争は常に多くの熱気を生み出し、ほとんどの場合無駄でした—どれを選んでも問題なかったのです。UMLのおかげで、そのほとんどは忘れ去られました。今では標準表記法があります。しかし、人々が気づいているように、標準はすべての疑問を解決するわけではありません。

現在浮上している疑問は、より詳細な問題になりがちです。UMLモデルで特定のものをどのように表現するか、あるいは特定のUML構成要素が私たちの開発環境で何を意味するかなどです。多くの人を驚かせるのは、これらの問題の多くには、明確な答えがないということです。

なぜでしょうか？その大きな理由は、伝統です。OOであろうとなかろうと、モデリング方法は決して非常に形式的なものではありませんでした。定義は直感に委ねられ、多くのギャップがありました。形式手法のバックグラウンドを持つ人々は、この点を批判しました。彼らは、厳密さが欠けているということは、モデルに曖昧さが入り込む余地が多すぎることを意味すると主張しました。しかし、実際には、多くの人々が、この形式の欠如にもかかわらず、非形式的な方法が形式的な方法よりも一般的に有用であることを発見しました。実際には、非形式性が有利であるようです。

UMLには形式的な要素があります。その中心はメタモデルです。UMLの構造を記述するUMLモデルです。しかし、メタモデルでさえ多くのギャップを残しています。属性を、型が分類子である一種の構造的特徴として定義することはできますが、Javaでプログラミングする際には、それは実際に何を意味するのでしょうか？フィールドを意味するのでしょうか、getとsetの操作のペアを意味するのでしょうか、それとも操作のパラメータを意味するのでしょうか？この質問に対する答えを10人のUML専門家に尋ねても、合意できるのは「それは状況による」という言葉を含むということだけです。メタモデルの主な目的は、CASEツールがいつか通信できるように、整形式のモデルを定義することです。真に厳密なアプローチからはほど遠いものです。
 

複数の解釈への対処

では、これはあなたにとって何を意味するのでしょうか？まず、UMLのいくつかの解釈を見つけるということです。これらの解釈は、書籍、トレーニングコース、プロジェクトドキュメントに現れます。あなたはこれを認識する必要があります。過去の手法間の違いほど大きな違いはありませんが、違いは存在します。チーム内では、これらの問題が発生したときに、より標準的なコンセンサス解釈を考案する必要があります。そうする際には、ある解釈が正しくて間違っていることを断言する人に注意してください。いくつかのことはかなり明確ですが、多くのことはそうではありません。

どのように解釈を選択するのでしょうか？最優先の原則は、UMLを何のために使用しているかを理解することです。CASEツールを使用してコードを生成している場合は、使用する解釈は必然的にCASEツールのコードジェネレータの解釈になります。そうでない場合は、最優先の目的はコミュニケーションになります。したがって、他の人と最も効果的にコミュニケーションをとることができる解釈を選択する必要があります。これは標準に関する重要な点であり、図の共通の解釈を促進します。

ここでは、解釈の問題は、定義された言語（ANSI Cなど）よりも自然言語（英語など）と並行していると考えます。UMLの解釈について判断する単一の機関はありません。そのような機関が存在するならば、それはOMGです。その分析と設計タスクフォースを通じて。彼らはUML標準の鍵を握っています。しかし、彼らは決してすべての問題について判断することはありません。そして、彼らが判断した場合でさえ、一般的な慣習は公式見解と異なる可能性があります。「ショッピングをする」という表現を禁止したフランス語アカデミーの役割に似ています。しかし、それが一般的な慣用句になるのを止めることはできませんでした。

したがって、英語と同様に、共通の使用法を導く重要な部分は、UMLの専門家、つまり正しくて洗練されたUMLについてコメントすることを自ら引き受けている人々によって行われます。この図では、3人のアミーゴスが特に重要な専門家になります。彼らの著作は大きな影響力を持つでしょうが、絶対的なものではありません。

解釈の変動に加えて、まったく異なる表記法も見つかります。多くの人々はUMLに重要なギャップがあると認識し、問題を解決するために新しい拡張機能を提案します。これらのいくつかは、UML拡張機能（ステレオタイプなど）を通じてスムーズに適合しますが、その他はOMGドキュメントからの明らかな逸脱となります。繰り返しますが、これらは、他の人々がそれらを採用するかどうかによって増減します。

解釈の選択

自然言語としてのUMLの見方は、それがどのように進化する可能性があるかを示唆しています。自然言語は、人々がさまざまな方向に言語を押し進めることによって進化します。有用なものは共通の使用法に入り込み、徐々に標準化されます。そうでないものは記憶から消えていきます。今後数年間で、UMLの端をかなり押し進める様子が見られると思います。これは良いことであり、UMLを活気のあるものにし、発展させることができます。この端の押し進めは、UML以前の方法でも起こり、多くのアイデアがUMLに取り入れられました。バリエーションに共通の基盤があるという事実は、このプロセスを容易にし、UMLをさらに加速させる可能性があります。したがって、静的であるとは期待せず、公式標準が最高の使用方法よりも数歩遅れていることを期待してください。
CASEツールへの影響

CASEツールはこの標準の世界で特定の役割を果たしており、その決定はUMLの使用方法に影響を与えます。基本的に、CASEツールはUMLゲームをどのようにプレイするかについて選択する必要があります。CASE業界にとってUMLの大きな利点は、複数の方法をサポートする必要がないことです。彼らは、UMLで何か有用なことをすることに力を集中できるようになりました。

UMLをサポートするには、UMLメタモデルをサポートする必要がありますが、すべての解釈の問題は依然として適用されます。例として、コードジェネレータで異なる決定が行われることがわかります。異なるコードを生成するだけでなく、生成するコードの意図についても異なる決定を行います。そのため、あるCASEツールでのUMLは、別のCASEツールでのUMLと同じではないことがわかります。

CASEツールは、図をチェックして間違いを防ぐ機能について説明しています。彼らはそれを機能と考えていますが、私はそうは思いません。私は自分がしたいことを知っており、CASEツールが自分の必要なことができない場合、非常にイライラします。人々はそれを経験の浅い開発者にとっての恩恵と考えていますが、私は良いレビュープロセスの方が機械的なチェックよりもはるかに価値があると思います。ツールはコミュニケーションの微妙さを理解できません。したがって、CASEツールが何を描くかの仲裁者にならないようにしてください。あなたの脳はいつでもCASEツールを打ち負かすことができます。