連載
Javaオブジェクトモデリング
第7回 静的モデル:リレーションシップ(1)
浅海智晴
2003/1/10
静的モデルの基本となるモデル要素は分類子(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と記述することにします。そのほかのリレーションシップもメタモデルの定義どおり英語の用語を用います。
リレーションシップ | ステレオタイプ | 接続 | 意味 | ||
ソース | ターゲット | ||||
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に示すものがあります。
図4 リレーションシップパス |
UMLノーテーションを軸にした切り口では、これらのパスをそれぞれリレーションシップの1種類を表していると考えることができます。つまり、UMLのノーテーションによるリレーションシップは以下の6種類に分けることができます。
- アソシエーション
- 集約
- 合成集約
- 汎化
- リアライゼーション
- ディペンデンシィ
これらのリレーションシップの関係は図5となります。
図5 リレーションシップの関係 |
メタモデルとの対応関係は表2となります。メタモデルとノーテーションがぴったりと対応するのはGeneralizationと汎化のみであり、そのほかのモデル要素は対応が微妙にずれています。Associationは、通常のアソシエーションに加えて集約や合成集約となる可能性があります。またDependencyは、通常のディペンデンシィに加えてリアライゼーションになる可能性があるわけです。
メタモデル | ノーテーション |
Association | アソシエーション |
集約 | |
合成集約 | |
Generalization | 汎化 |
Dependency | ディペンデンシィ |
リアライゼーション | |
表2 メタモデルとノーテーションの比較 |
このようなUMLのメタモデル(真の姿)とノーテーション(仮の姿)の微妙なずれはUMLのプロファイルを策定するうえで意識しなければならないポイントとなっています。ちょっと大げさな表現をすれば、UMLについて本格的な扱いをすればするほどメタモデルに近づいていきますが、ノーテーションからはどんどんずれていき、実用的には使いづらくなってしまいます。この間のバランスをどのように見極めていくのかという点がプロファイルを考える際のポイントとなるわけです。
Javaオブジェクトモデリングの筆者、浅海智晴氏の最新著書「UML&Javaオブジェクト指向開発
入門編」(ピアソン・エデュケーション)を3名様にプレゼントします。姉妹編「Javaオブジェクトモデリング やさしいUML入門」の内容を掘り下げ、メタモデルの解説まで踏み込でいます。 |
Javaオブジェクトモデリング INDEX |
IT Architect 連載記事一覧 |