「関連」や「関係」の落とし穴（前編）：UML BASIC LECTURE（2/4 ページ）

[羽生田栄一（豆蔵 取締役会長）, 岡村敦彦（豆蔵），＠IT]

そのほかの「関係」

　では関連のほかは「どういう関係」なのでしょうか。汎化関係は、オブジェクト指向を特徴付ける概念なので、分かりやすいと思います。つまり、物事を分類するときに用いる関係で、ある概念に対してより一般的な概念がある場合、それらを汎化関係にある、とします。親子関係、スーパークラスとサブクラス、祖先と子孫などの用語が使われることもあります。

　次に実現ですが、実は意味的には依存の一種になります。実現の意味は「仕様とその実装の関係」なので、仕様が変わればもちろん実装は影響を受ける、つまり依存していることになります。ですので、依存関係のステレオタイプで<>としても同様ですが、表記法としては独立したものを持っていますので、このようにしておきます。具体的には、例えば、インターフェイスとそれを実装するクラスをイメージすれば良いでしょう。ユースケースとユースケースの実現、などにも使われますが、意味としては同様です。

　さて、一番分かりにくいのが依存ではないでしょうか。UMLユーザーガイドを見ても、「片方の変更が、もう一方のもののセマンティクスに影響を与える可能性のある場合」となっているだけです。例えば、あるクラスを修正したら、ほかにも修正しなければならないという場合を意味しているようなのですが、そうだとすると、汎化や関連との違いがよく分かりません。親クラスを変更すれば、当然子クラスにも影響が出るはず。そうなると何が依存で何が依存ではないのでしょう？

　あまり難しく考えないことにしましょう。実は、全部依存なんです。その中で、関連と汎化に関しては（一応実現も）独立した表現方法があるので、それを使いましょう、そして、汎化、関連、実現以外のものを依存という形でまとめましょう、というだけの話です。要は、依存はある特別な関係を表しているのではなく、ある特別な関係「以外」のものを表しているわけです。なので、「どういう関係」なのかが漠然として分かりにくいんですね。その「どういう関係」かをステレオタイプで表現して明確にすることもできるのですが、それはまた別の機会の話にしましょう。

　依存関係の例としては、

（1）	あるクラスから、それが利用するインターフェイスへの依存関係
（2）	あるクラスから、そのメソッドの引数の型になっているクラスへの依存関係
（3）	あるクラスから、そのメソッド内で動的に生成するオブジェクトの属するクラスへの依存関係
（4）	2つのパッケージがそれぞれ含むクラス同士に依存関係があることから生じるパッケージ間の依存関係

といったものがあります。どの例もちょっと一言でいいづらい関係ですよね。