第7回この記事は「こちら」に移動しました。静的モデル:リレーションシップ(1)浅海智晴2003/1/10静的モデルの基本となるモデル要素は分類子(classifier)とリレーションシップ(relationship、関係)です。その分類子の中でも特に重要な分類子であるクラス、インターフェイス、データ型について第3回から第6回までの4回にわたって取り上げてきました。静的モデルにおいて重要な役割を持つ分類子として、パッケージの解説が残っていますが、これは後回しにして今回から2回にわたって、リレーションシップを検討していきます。1.リレーションシップとは何かUMLではリレーションシップは以下のように定義されています。「モデル要素間の意味上のコネクション」リレーションシップの日本語訳は「関係」です。本連載では、関係という用語の多義性を排除するためにリレーションシップという用語を採用しています。リレーションシップの理解のためには、分類子と分類子の間の関係がリレーションシップであると考えると分かりやすいでしょう。分類子は四角形やだ円などの図形による2Dシンボルによって表現されます。それに対して、リレーションシップは実線や破線などの線であるパスによって表現されます。図形(分類子)と図形(分類子)の間を線(リレーションシップ)でつないだ図がUMLにおける静的モデルの図となるわけです。この静的モデルのイメージを図にしたものが図1です。分類子とリレーションシップ分類子とリレーションシップは、いずれもメタモデルの中の抽象モデルであり、具体的な2Dシンボルとして表示されることはありません。イメージとしてとらえてください。静的モデル:クラスにおけるUMLとJavaのマッピング(1)」にご紹介しました。その最も代表的な分類子が「クラス」です。このクラスとクラスの間に実線を1本引くと図2となります。この線はリレーションシップの一種であるアソシエーションを表現しています。クラスとアソシエーション最もシンプルな2Dシンボルである四角がクラスに、最もシンプルなパスである実線がアソシエーションに割り当てられています。この例から分かるようにUMLではクラスとアソシエーションが最も基本的な、分類子およびリレーションシップと考えられているわけです。1つ分類子とリレーションシップの具体例をご覧いただきましょう。図3はパッケージとディペンデンシィによって構成されている静的モデルです。分類子を示す2Dシンボルとリレーションシップを示すパスの形が異なっており、図2のクラスとアソシエーションとは異なる静的構造を持っていることが一目瞭然です。パッケージとディペンデンシィ2.UMLのリレーションシップ分類子に多彩なモデル要素が定義されていたように、リレーションシップにもさまざまなモデル要素が存在します。UMLのメタモデルでは表1に示すリレーションシップが定義されています。本節では、UMLのメタモデルの議論っぽく、リレーションシップをRelationship、アソシエーションをAssociationと記述することにします。そのほかのリレーションシップもメタモデルの定義どおり英語の用語を用います。UMLメタモデルこの表から分かるとおり、UMLでは非常に多彩なRelationshipが用意されています。整理すると、UMLのRelationshipは以下のものに分類できます。Association■■Associationは、分類子のインスタンス間にコネクションがあることを示すRelationshipです。Associationは最も重要なRelationshipです。Associationは、ステレオタイプとしてImplicitしか定義していませんが、Associationの意味を修飾するためのさまざまな機能が用意されています。結果として、非常に高い表現力を持つRelationshipとなっています。Generalization■■Generalizationは、汎用的なモデル要素と固有的なモデル要素の間の分類上の関係を示すRelationshipです。集合における集合と部分集合の関係に相当するRelationshipをモデル要素の間に定義します。Flow■■Flowは、同一オブジェクト間の異なったバージョンのオブジェクト、あるいは複製元オブジェクトと複製先オブジェクトを表すRelationshipです。ステレオタイプbecomeの場合はバージョン間のRelationship、ステレオタイプcopyの場合は複製前オブジェクトと複製後オブジェクトのRelationshipとなります。Dependency■■Dependencyとは、Association、Generalization、Flow、メタ関係(metarelationship)以外のあらゆるRelationshipを総称した用語です。Dependencyは以下の4種類に分類できます。AbstractionBindingPermissionUsageAbstractionは、同一概念を異なった抽象化レベルあるいは異なった視点からモデル化した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に示すものがあります。リレーションシップパスUMLノーテーションを軸にした切り口では、これらのパスをそれぞれリレーションシップの1種類を表していると考えることができます。UMLのノーテーションによるリレーションシップは以下の6種類に分けることができます。リアライゼーションディペンデンシィこれらのリレーションシップの関係は図5となります。リレーションシップの関係メタモデルとの対応関係は表2となります。メタモデルとノーテーションがぴったりと対応するのはGeneralizationと汎化のみであり、そのほかのモデル要素は対応が微妙にずれています。Associationは、通常のアソシエーションに加えて集約や合成集約となる可能性があります。Dependencyは、通常のディペンデンシィに加えてリアライゼーションになる可能性があるわけです。メタモデルとノーテーションの比較このようなUMLのメタモデル(真の姿)とノーテーション(仮の姿)の微妙なずれはUMLのプロファイルを策定するうえで意識しなければならないポイントとなっています。大げさな表現をすれば、UMLについて本格的な扱いをすればするほどメタモデルに近づいていきますが、ノーテーションからはどんどんずれていき、実用的には使いづらくなってしまいます。この間のバランスをどのように見極めていくのかという点がプロファイルを考える際のポイントとなるわけです。入門編」(ピアソン・エデュケーション)を3名様にプレゼントします。やさしいUML入門」の内容を掘り下げ、メタモデルの解説まで踏み込でいます。プレゼントの応募は締め切らせていただきました。ありがとうございました。おいてデジタルマーケティングの成果を出すポイントとは。View」を提供LINEは、コミュニケーションアプリ「LINE」のトークリスト最上部に動画広告を配信できる...日本企業のデータ分析はIT部門依存が顕著——MicroStrategy調べ「グローバルエンタープライズアナリティクス調査2020」の結果です。Inc.著作権はアイティメディア株式会社またはその記事の筆者に属します。(著作権について)当サイトに掲載されている記事や画像などの無断転載を禁止します。@IT情報マネジメント」「JOB@IT」「@ITハイブックス」「ITmedia」は、アイティメディア株式会社の登録商標です。当サイトに関するお問い合わせは「@ITへのお問い合わせ」をご覧ください。