Uml 2

第７回　メタモデル構造の理解 UML が他のオブジェクト指向型言語と異なる点は、UML 自身のメタモデルを、UML 自身で記述・定義で きると言う点にあります。 型は厳密に言うと集合とは異なる集まりの概念です。 集合（Set)では、要素の重複が許されないのに対し、 型はいくらでも重複が許されます。 データ型以外の型として、代表的なものがクラスという概念です。 クラスのインスタンスはオブジェクト です。 すべてのインスタンスが必ずどれかのサブクラスのインスタンスになってしまうもの、つまり 間接的にし かインスタンスを持ち得ないクラスを抽象クラスと呼びます。

第８回　インスタンスの概念 リンクは関連のインスタンスと呼ぶことになります。 型の性質を持つもの（つまりインスタンスを持つと言う性質を持つもの ）を総称して、UML では分類子 （Classifier)と呼んでいます。

第 9 回 メタモデル、メタクラス UML は構造と振る舞いを持つ対象をモデル化する言語です。そして、UML 自身も構造と振る舞いを持ちま す。すなわち、UML は自分自身をモデル化することができ、その自分自身のモデルのことをメタモデルと 呼びます。 個々のオブジェクトの集まりをクラス としてまとめたように、個々のクラスをさらにまとめたものをメタ クラスと呼びます。 図 2－１

図２−１の例で示される様に、「人」クラスや「車」クラスは「Class」というメタクラスのインスタンス の関係になります。 また注意を要する点として、モデル作成で使用される要素は、メタモデル化されるとすべてメタクラスと なります。つまり、モデル作成で用いられる関連「所有する」は、メタモデルでは「Association（関連）」 メタクラスとなります。 そして、通常のモデル図の世界とメタモデル図の世界は別のレイヤー （層）として区別され、モデル作成 を行うレイヤーのことをモデルレイヤー、メタモデルのレイヤーをメタモデルレイヤーと呼び、レイヤー 間の個々の要素の関係はインスタンスの関係となります。 BPM：ビジネス・プロセス・モデリング SOA：サービス・オリエンティッド・アーキテクチャ

第 10 回 メタモデリング メタモデルは、モデル言語を定義、設計するものです。 UML2.0 では、クラス図に加えオブジェクト図が正式な形で登録されましたので（より正確に言いますと、 インスタンス図が正式に表現することができるようになり、オブジェクト図はインスタンス図の一つの形式 となります）、オブジェクト図に登場する要素すべて に対し、メタモデル層のなかで対応するメタクラス が存在します。

図 2－2

モデルレイヤーで記述される図には、必ず対応するメタモデルが存在します。 図２−２は、「人」クラスのインスタンスである「太郎」オブジェクトをモデル表現し、そのメタクラスで ある「InstanceSpecification」と＜＜instanceOf＞＞の関係があることを示しています。 この関係は、オブジェクト図、インスタンス図に限らず、UML で表現されるすべての要素（図示されるも のだけではなく、明示されないものも含めて）に関して存在します。

第 11 回 言語アーキテクチャ 図２−３

第 12 回 コア・パッケージ UML では、各レイヤーに共通する言語仕様を一ヶ所でまとめて定義し、それをコアパッケージと呼んで、 各レイヤーで共通利用しています。

第 13 回　メタ構造 すべてのクラスを集めてしまうと、もはやクラスではなくなってしまいます。 UML の言語仕様には、デー タレイヤー→メタデータレイヤー→メタモデルレイヤー→メタメタモデルレイヤーという厳密なレイヤー構 造が適用されます。

第 14 回 メタモデル図の読み方 一方向にのみ誘導可能性のマーク（矢印）が付いている関連は、その方向に誘導可能 であることを意味す る。マークが付いている方の関連端は、分類子によって所有され 、マークがついていない方の関連端は関 連によって所有されている。 誘導可能性のマーク（矢印）が付いていない関連は、両方向に誘導可能であり 、関連端はそれぞれ反対側 の分類子によって所有されている。（関連には所有されていない。） 関連端に付けられた制約｛subsets endA} ：関連端 endA が特化されたことを示す。 関連端に付けられた制約｛redefines endA} ：関連端 endA が特化され再定義されたことを示す。 多重度の表記が省略された場合、多重度は１。 パッケージ間の指定されていない依存関係は包含関係（＜＜include＞＞)を意味する。

第 15 回　第 3 章　複合構造図 複合構造図は、UML2.0 で付け加えられた図で、この図によって、内部構造を何段にもわたって階層的に記 述することが可能になりました。この新たな図の追加に伴い、 内部の構成要素を示すパート（もしくはパ ーツ）と、パート間の接続を表すコネクタ、外部と内部の相互作用の接点を示すポート などの新しい概念 が登場して来ました。 図 3－1－1

図 3－1－1FM ラジオとそのインターフェース群を書き出しています。そして内部構造はまだ表現されてい

ません。UML2.0 になって、インターフェースは、提供インターフェース（ボール）と要求インターフェー ス（ソケット）の２種類になりました。ルールとしては、 サービスを提供する側が提供インターフェース 、 サービスを受ける側が要求インターフェース であり、通常、提供インターフェース側がインターフェース の実現を行ないます。（この図では、「アンテナ」が要求インターフェースで、それ以外の「選局」「電 源スイッチ」「ボリューム」「音声」はすべて提供インターフェースとして表現しています） インターフェースが、提供インターフェースと要求インターフェースの２種類に分かれた背景には、この２ 種類がペアになって接続される状態を示したいと言う表現上の意図があります。 図Ｆ０４

図 F04 参照：この図では２つのインターフェースが、依存関係で結ばれており、FM ラジオとアンテナがコ ミュニケーションしている状態を示しています。 インターフェースの表現としては、ボールやソケットで表す方法以外に、図 F02 の様にクラス内に＜＜ provided interface＞＞ と＜＜required interface＞＞というステレオタイプを使ってリスト表記するこ とも出来ます。 図Ｆ０２

次に、内部構造を記述する前に、外部と内部の相互作用の接点であるポートをクラスの境界線上に記述 し ます。 図Ｆ０３

そ し て 最 後 に 、 図 F05 で 示 さ れ て い る よ う に 、 内 部 構 造 を 記 入 し ま す 。 この図では、「チューナー」「アンプ」「スピーカー」「電源部」の 四つのプロパティが、内部構成要素 として記入されそれぞれがコネクタで結ばれています。 図Ｆ０５

SOA について 図１

SOA のアーキテクチャ図の右の欄は、SOA の各レイヤーを支える OMG テクノロジーが記述されています。

この図でお解りの通り、UML は、最下層の「運用資源」のレイヤーを除いた 3 つのレイヤーに登場します。

第 16 回　複合構造図の例　続き プロパティは図上で四角形で表されることから分かるように、何らかの分類子（もしくはインスタンスの 集まり）を示しています。ただし普通のクラス図と違い、プロパティは 分類子の役割の方に重点を置いて おり、役割を重視してこれをパートと呼びます。（パートは役割名と解釈しても良いでしょう。） F05 図に表される「FM ラジオ」のような、内部構造を持った分類子（注：構造化分類子と呼ばれます）は、 実は分類子の内部のコラボレーションを表している図として定義されています。 複合構造図は単にクラス図が入れ子になった図ではなく、 役割と役割間の相互作用に焦点を置いたコラボ レーションを表した図として理解する必要があります。

第 17 回 ポートの理解 ポートは、対象の分類子（構造化分類子）のインスタンスと外部環境の間、あるいは分類子（構造化分類子） と内部分類子のインスタンス間のインタラクション （相互作用）の接点を表し、これ自身がプロパティの 一種です。 図Ｆ０６

ポートの特徴： インタラクションの接点 1. 構造化分類子のインスタンスと外部環境 2. 構造化分類子のインスタンスと内部分類子のインスタンス　 要求インターフェースは、分類子が外部環境に対して期待しているサービスを性格付けおり 、分類子のイ ンスタンスは、外部環境のインスタンスからインターフェースによって規定された振る舞い特性を要求 し ています。提供インターフェースは、分類子が外部環境に提供するサービスの振る舞い特性を性格付けし ます。 インタラクションの接点オブジェクト は、通常、提供インターフェースを実現する側の分類子のインスタ ンスです。 ポートは、ポートに到達するすべてのリクエストが分類子のインスタンスによって適切に扱われるよう指 定する能力をもちます。（単に、任意の内部の分類子のインスタンスにばらまくだけではありません。） 内部のプロパティとポートがコネクタで接続されている場合は 、ポートに到達したすべてのリクエストは、 コネクタに沿って転送されます。