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

» 2003年01月10日 12時00分 公開
[浅海智晴，＠IT]

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

リレーションシップ ステレオタイプ 接続 意味
ソース ターゲット
Association なし 分類子 分類子と分類子の間の意味上の関係
Implicit 分類子 分類子と分類子の間に概念的なAssociationがある関係
Generalization なし 汎化可能なモデル要素 汎化可能なモデル要素 モデル要素とモデル要素の間の一般的な汎化の関係
implementation 汎化可能なモデル要素 汎化可能なモデル要素 モデル要素とモデル要素の間の実装の継承
Flow become 分類子のインスタンス 分類子のインスタンス 分類子インスタンスの変換前と変換後
copy 分類子のインスタンス 分類子のインスタンス 複製前の分類子インスタンスと複製後の分類子インスタンス
Dependency Abstraction derive モデル要素 モデル要素 クライアントがサプライヤから派生する関係
realize モデル要素 モデル要素 仕様モデルを実装モデルで実現する関係
refine モデル要素 モデル要素 異なったセマンティクスレベルの間の抽象／具象の関係
trace モデル要素 モデル要素 異なったモデル間のモデルの追跡
Binding なし テンプレート モデル要素 テンプレートとテンプレートインスタンスの間の関係
Permission access モデル要素 名前空間 ソース名前空間内のモデル要素からターゲット名前空間内の公開されたモデル要素にアクセスする関係
friend モデル要素 名前空間 ソースパッケージ内のモデル要素からターゲットパッケージ内のモデル要素をターゲットパッケージの可視性を拡張して行える関係
import モデル要素 名前空間 ターゲットパッケージの公開されたモデル要素がソースパッケージに移入される関係
Usage call オペレーション オペレーション ソースのオペレーションからターゲットのオペレーションに対する呼び出しの関係
create 分類子 分類子 クライアントからサプライヤを生成する関係
instantiate 分類子 分類子 クライアントのオペレーションがサプライヤを生成する関係
send オペレーション シグナル ソースのオペレーションがターゲットのシグナルを送信する関係
表1 UMLメタモデル

　この表から分かるとおり、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に示すものがあります。

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

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

・アソシエーション

・集約

・合成集約

・汎化

・リアライゼーション

・ディペンデンシィ

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

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

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

メタモデル ノーテーション
Association アソシエーション
集約
合成集約
Generalization 汎化
Dependency ディペンデンシィ
リアライゼーション
表2 メタモデルとノーテーションの比較

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

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

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

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


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

Copyright © ITmedia, Inc. All Rights Reserved.