連載

2003年1月10日

静的モデル：リレーションシップ（1）：Javaオブジェクトモデリング（7）

[浅海智晴，＠IT] PC用表示関連情報

LINE

Hatena

静的モデルの基本となるモデル要素は分類子（classifier）とリレーションシップ（relationship、関係）です。その分類子の中でも特に重要な分類子であるクラス、インターフェイス、データ型について第3回から第6回までの4回にわたって取り上げてきました。静的モデルにおいて重要な役割を持つ分類子として、パッケージの解説が残っていますが、これは後回しにして今回から2回にわたって、リレーションシップを検討していきます。

1.リレーションシップとは何か

　UMLではリレーションシップは以下のように定義されています。

　「モデル要素間の意味上のコネクション」

　リレーションシップの日本語訳は「関係」です。本連載では、関係という用語の多義性を排除するためにリレーションシップという用語を採用しています。リレーションシップの理解のためには、分類子と分類子の間の関係がリレーションシップであると考えると分かりやすいでしょう。

　分類子は四角形やだ円などの図形による2Dシンボルによって表現されます。それに対して、リレーションシップは実線や破線などの線であるパスによって表現されます。

　つまり図形（分類子）と図形（分類子）の間を線（リレーションシップ）でつないだ図がUMLにおける静的モデルの図となるわけです。

　この静的モデルのイメージを図にしたものが図1です。

図1 分類子とリレーションシップ

　分類子とリレーションシップは、いずれもメタモデルの中の抽象モデルであり、具体的な2Dシンボルとして表示されることはありません。あくまでもイメージとしてとらえてください。

　UMLのメタモデルの中で分類子の具象クラスとしてさまざまなものがあることを、「第3回静的モデル：クラスにおけるUMLとJavaのマッピング（1）」にご紹介しました。もちろん、その最も代表的な分類子が「クラス」です。

　このクラスとクラスの間に実線を1本引くと図2となります。この線はリレーションシップの一種であるアソシエーションを表現しています。

図2 クラスとアソシエーション

　最もシンプルな2Dシンボルである四角がクラスに、最もシンプルなパスである実線がアソシエーションに割り当てられています。この例から分かるようにUMLではクラスとアソシエーションが最も基本的な、分類子およびリレーションシップと考えられているわけです。

　もう1つ分類子とリレーションシップの具体例をご覧いただきましょう。

　図3はパッケージとディペンデンシィによって構成されている静的モデルです。分類子を示す2Dシンボルとリレーションシップを示すパスの形が異なっており、図2のクラスとアソシエーションとは異なる静的構造を持っていることが一目瞭然です。

図3 パッケージとディペンデンシィ

2.UMLのリレーションシップ

　分類子に多彩なモデル要素が定義されていたように、リレーションシップにもさまざまなモデル要素が存在します。

　UMLのメタモデルでは表1に示すリレーションシップが定義されています。

　本節では、UMLのメタモデルの議論っぽく、リレーションシップをRelationship、アソシエーションをAssociationと記述することにします。そのほかのリレーションシップもメタモデルの定義どおり英語の用語を用います。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　この表から分かるとおり、UMLでは非常に多彩なRelationshipが用意されています。整理すると、UMLのRelationshipは以下のものに分類できます。

・Association

・Generalization

・Flow

・Dependency

2.1 Association

　Associationは、分類子のインスタンス間にコネクションがあることを示すRelationshipです。

　Associationは最も重要なRelationshipです。Associationは、ステレオタイプとしてImplicitしか定義していませんが、Associationの意味を修飾するためのさまざまな機能が用意されています。結果として、非常に高い表現力を持つRelationshipとなっています。

2.2 Generalization

　Generalizationは、汎用的なモデル要素と固有的なモデル要素の間の分類上の関係を示すRelationshipです。集合における集合と部分集合の関係に相当するRelationshipをモデル要素の間に定義します。

2.3 Flow

　Flowは、同一オブジェクト間の異なったバージョンのオブジェクト、あるいは複製元オブジェクトと複製先オブジェクトを表すRelationshipです。ステレオタイプbecomeの場合はバージョン間のRelationship、ステレオタイプcopyの場合は複製前オブジェクトと複製後オブジェクトのRelationshipとなります。

2.4 Dependency

　Dependencyとは、Association、Generalization、Flow、メタ関係（metarelationship）以外のあらゆるRelationshipを総称した用語です。

　Dependencyは以下の4種類に分類できます。

・Abstraction

・Binding

・Permission

・Usage

　Abstractionは、同一概念を異なった抽象化レベルあるいは異なった視点からモデル化した2つまたは複数のモデル要素間のRelationshipです。derive、realize、refine、traceの4つのステレオタイプが定義されています。

　Bindingは、テンプレートとテンプレートを基に生成されたインスタンスの間のRelationshipです。ステレオタイプは定義されていません。

　Permissionは、あるモデル要素から異なった名前空間内にあるモデル要素に対するアクセスの権利のRelationshipです。access、friend、importの3つのステレオタイプが定義されています。

　Usageは、1つのモデル要素の実装においてほかのモデル要素を必要としているというRelationshipです。call、create、instantiate、sendの4つのステレオタイプが定義されています。

3.UMLノーテーションから見たリレーションシップ

　前節で説明したメタモデルはUMLの構造を定めた仕様であり、UMLの真の姿といえます。ただ、このメタモデルは普段UML利用者の目に直接入ってくることはないため、あまりなじみがあるものではありません。一般のUML利用者がこのメタモデルを意識しながらクラス図やシーケンス図を書くことは現実的にはないでしょう。

　それでは、UML利用者の意識するUMLとは何でしょうか。もちろん、これはUMLのグラフィカル言語としての仕様を定めたノーテーションです。

　そこで、今度はノーテーションをベースにリレーションシップについて考えてみましょう。

　UMLのグラフィカルな文法として用意されているパスには図4に示すものがあります。

図4 リレーションシップパス

　UMLノーテーションを軸にした切り口では、これらのパスをそれぞれリレーションシップの1種類を表していると考えることができます。つまり、UMLのノーテーションによるリレーションシップは以下の6種類に分けることができます。

・アソシエーション

・集約

・合成集約

・汎化

・リアライゼーション

・ディペンデンシィ

　これらのリレーションシップの関係は図5となります。

図5 リレーションシップの関係

　メタモデルとの対応関係は表2となります。メタモデルとノーテーションがぴったりと対応するのはGeneralizationと汎化のみであり、そのほかのモデル要素は対応が微妙にずれています。Associationは、通常のアソシエーションに加えて集約や合成集約となる可能性があります。またDependencyは、通常のディペンデンシィに加えてリアライゼーションになる可能性があるわけです。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　このようなUMLのメタモデル（真の姿）とノーテーション（仮の姿）の微妙なずれはUMLのプロファイルを策定するうえで意識しなければならないポイントとなっています。ちょっと大げさな表現をすれば、UMLについて本格的な扱いをすればするほどメタモデルに近づいていきますが、ノーテーションからはどんどんずれていき、実用的には使いづらくなってしまいます。この間のバランスをどのように見極めていくのかという点がプロファイルを考える際のポイントとなるわけです。

　Javaオブジェクトモデリングの筆者、浅海智晴氏の最新著書「UML＆Javaオブジェクト指向開発

入門編」（ピアソン・エデュケーション）を3名様にプレゼントします。姉妹編「JavaオブジェクトモデリングやさしいUML入門」の内容を掘り下げ、メタモデルの解説まで踏み込でいます。

　プレゼントの応募は締め切らせていただきました。ありがとうございました。

「Javaオブジェクトモデリング」バックナンバー