３ー１ー４ コネクタ
2つ以上のインスタンス間のコミュニケーションを可能にするリンクを意味します。
このリンクは関連のインスタンスである場合もありますが、必ずしもそれに限りません。
単純なものから複雑なコミュニケーション経路、例えば様々なネットワーク機器からなる連鎖まで、幅広い意味を持ちます。
コネクタの両端はコネクタ端と呼ばれ多重度を付けることが可能です。
2006年4月28日金曜日
UML中級講座 第21回 コネクタ
本日は、第16回の図中で少しだけ触れましたコネクタについて、解説いたします。
３ー１ー４ コネクタ
2つ以上のインスタンス間のコミュニケーションを可能にするリンクを意味します。
このリンクは関連のインスタンスである場合もありますが、必ずしもそれに限りません。
単純なものから複雑なコミュニケーション経路、例えば様々なネットワーク機器からなる連鎖まで、幅広い意味を持ちます。
コネクタの両端はコネクタ端と呼ばれ多重度を付けることが可能です。
３ー１ー４ コネクタ
2つ以上のインスタンス間のコミュニケーションを可能にするリンクを意味します。
このリンクは関連のインスタンスである場合もありますが、必ずしもそれに限りません。
単純なものから複雑なコミュニケーション経路、例えば様々なネットワーク機器からなる連鎖まで、幅広い意味を持ちます。
コネクタの両端はコネクタ端と呼ばれ多重度を付けることが可能です。
2006年4月27日木曜日
UML中級講座 第20回 プロパティの多重度
昨日に引き続き、プロパティの多重度のお話しです。
プロパティの多重度
プロパティの多重度は、図F13の左図のように、長方形の右上隅に表記するほか、右図のように範囲指定することも出来ます。
左図は車輪クラスのインスタンスが４つ存在し親の分類子のインスタンスにコンポジット所有されていることを意味し、右図では、1つ以上2つ以下のエンジンのインスタンスが、親の分類子のインスタンスと関連があることを示しています。
図F13
プロパティの多重度
プロパティの多重度は、図F13の左図のように、長方形の右上隅に表記するほか、右図のように範囲指定することも出来ます。
左図は車輪クラスのインスタンスが４つ存在し親の分類子のインスタンスにコンポジット所有されていることを意味し、右図では、1つ以上2つ以下のエンジンのインスタンスが、親の分類子のインスタンスと関連があることを示しています。
図F13
2006年4月25日火曜日
UML中級講座 第19回 プロパティ
３ー１ー３ プロパティ
プロパティは包含する側の分類子のインスタンスに所有されるインスタンスの集まりを意味し、具体的にはパートとポートが該当します。
親の分類子がインスタンス化された時には、そのプロパティに対応するインスタンスが、（即時的もしくは時間をおいて）生成されます。
これらのインスタンスは、プロパティのタイプに指定されている分類子のインスタンスです。（図F11はパートの表記法であり、このパートのインスタンスは、クラスのインスタンス（オブジェクト）となります）
図F11
パートでの表現は、親の分類子が子のプロパティをコンポジットで所有することを意味し、親のインスタンスが消滅すると、子のインスタンスも消滅します。
図F10 (i)では、車クラスが役割名が「後輪」である車輪クラスをコンポジットで所有し、エンジンクラスと役割名eで関連を結んでいます。
(ii)では、同じ状態が表されていますが、注意すべき点は、「後」および「e」は、(ii)図では、ともに車クラスの内部構造に属しており、単に車輪クラスとエンジンクラスを一般的に所有しているのではなく、「後」および「e」の役割の中で所有されていることです。
つまり、（i)図では、任意の車輪クラスとエンジンクラスが車クラスと関連を持つことが出来ますが、(ii)図では、「後輪」と「e」の役割を持つ車輪クラスのインスタンスとエンジンクラスのインスタンスが、車クラスの同一のインスタンスにリンクしていることを意味します。
パートは、長方形の中に（不特定の）クラス名を記述して表現しますが、図F11のように、パート名の後のコロン：の後にタイプとしてクラス名を指定して表現することも可能です。
また、コンポジット所有でないパートは、長方形を実線ではなく点線で表記します。
図F10
プロパティは包含する側の分類子のインスタンスに所有されるインスタンスの集まりを意味し、具体的にはパートとポートが該当します。
親の分類子がインスタンス化された時には、そのプロパティに対応するインスタンスが、（即時的もしくは時間をおいて）生成されます。
これらのインスタンスは、プロパティのタイプに指定されている分類子のインスタンスです。（図F11はパートの表記法であり、このパートのインスタンスは、クラスのインスタンス（オブジェクト）となります）
図F11
図F10 (i)では、車クラスが役割名が「後輪」である車輪クラスをコンポジットで所有し、エンジンクラスと役割名eで関連を結んでいます。
(ii)では、同じ状態が表されていますが、注意すべき点は、「後」および「e」は、(ii)図では、ともに車クラスの内部構造に属しており、単に車輪クラスとエンジンクラスを一般的に所有しているのではなく、「後」および「e」の役割の中で所有されていることです。
つまり、（i)図では、任意の車輪クラスとエンジンクラスが車クラスと関連を持つことが出来ますが、(ii)図では、「後輪」と「e」の役割を持つ車輪クラスのインスタンスとエンジンクラスのインスタンスが、車クラスの同一のインスタンスにリンクしていることを意味します。
パートは、長方形の中に（不特定の）クラス名を記述して表現しますが、図F11のように、パート名の後のコロン：の後にタイプとしてクラス名を指定して表現することも可能です。
また、コンポジット所有でないパートは、長方形を実線ではなく点線で表記します。
図F10
UML中級講座 第18回 ポートの表記
ポートの表記
図F12
ポートは小さい四角形で表され、分類子の長方形の境界線上に置かれた場合は可視性がパブリック、分類子の長方形の内側に置かれた場合は、ポートが隠されており可視性がプロテクトであることを示しています。
ポートには多重度を付けることが可能で、図F06の左図は、ポートPの多重度が１であることを示しています。
また、ポートにはタイプ名（型名）を付けることが可能であり、ポート名：タイプ名 で表記します。図F06の右図は、ポート名がP、タイプ名が伝動機構であることを示します。（伝動機構は提供インターフェースの名前でもある。）
図F06
振る舞いポート
図F07
分類子の内部の小さなステートシンボルにコネクタ接続されたポートは、振る舞いポートと呼ばれます。（図F07参照）
図中の小さなステートシンボルは分類子（この図の場合「エンジン」クラス）の振る舞いを表しています。
図F09
ポート名は省略可能です。また、カンマで区切って複数のインターフェースをリスト表現することが可能です。
図F09では、オンラインサービスと言うポートに、オーダー入力とトラッキングという２つの提供インターフェースが接続され、支払いという１つの要求インターフェースが接続されていることを示しています。
図F08
図F08の中の左上の図は、エンジンクラスにポートPがあり、伝動機構と言う名前の提供インターフェースと動力という名の要求インターフェースが接続されていることを示しています。
提供インターフェースはポートPで提供するサービスを指定しており、要求インターフェースは、外部環境に期待するサービスをしています。従って、両者は依存関係でもあります。（図F08の左下）
また、エンジンクラスは完全にカプセル化されおり、インターフェースの持つ条件さえ満たせば、どんな外部環境下でも適切に動作します。
図F08の右図は、エンジンクラスの2つの使われ方を示しています。
車クラスでは、エンジンクラスのポートPは後輪と車軸でつながり、ボートクラスでは、エンジンクラスのポートPはプロペラとシャフトで接続されていることを示しています。
両ケースとも、インターフェースの条件さえ満たせばエンジンは適切に作動します。（図F08右上で示されるように、コネクタとパートは必ずしもポート経由で接続されている必要はありません。
トリガー
あるイベントが発生した時に、特定の振る舞いを呼び出すことをポートに指定することが可能です。このイベントの指定をトリガーと言います。
図F12
ポートには多重度を付けることが可能で、図F06の左図は、ポートPの多重度が１であることを示しています。
また、ポートにはタイプ名（型名）を付けることが可能であり、ポート名：タイプ名 で表記します。図F06の右図は、ポート名がP、タイプ名が伝動機構であることを示します。（伝動機構は提供インターフェースの名前でもある。）
図F06
振る舞いポート
図F07
分類子の内部の小さなステートシンボルにコネクタ接続されたポートは、振る舞いポートと呼ばれます。（図F07参照）
図中の小さなステートシンボルは分類子（この図の場合「エンジン」クラス）の振る舞いを表しています。
図F09
図F09では、オンラインサービスと言うポートに、オーダー入力とトラッキングという２つの提供インターフェースが接続され、支払いという１つの要求インターフェースが接続されていることを示しています。
図F08
図F08の中の左上の図は、エンジンクラスにポートPがあり、伝動機構と言う名前の提供インターフェースと動力という名の要求インターフェースが接続されていることを示しています。
提供インターフェースはポートPで提供するサービスを指定しており、要求インターフェースは、外部環境に期待するサービスをしています。従って、両者は依存関係でもあります。（図F08の左下）
また、エンジンクラスは完全にカプセル化されおり、インターフェースの持つ条件さえ満たせば、どんな外部環境下でも適切に動作します。
図F08の右図は、エンジンクラスの2つの使われ方を示しています。
車クラスでは、エンジンクラスのポートPは後輪と車軸でつながり、ボートクラスでは、エンジンクラスのポートPはプロペラとシャフトで接続されていることを示しています。
両ケースとも、インターフェースの条件さえ満たせばエンジンは適切に作動します。（図F08右上で示されるように、コネクタとパートは必ずしもポート経由で接続されている必要はありません。
トリガー
あるイベントが発生した時に、特定の振る舞いを呼び出すことをポートに指定することが可能です。このイベントの指定をトリガーと言います。
2006年4月24日月曜日
UML中級講座 第17回 ポートの理解
３ー１ー２ ポートの理解
ポートは、対象の分類子（構造化分類子）のインスタンスと外部環境の間、あるいは分類子（構造化分類子）と内部分類子のインスタンス間のインタラクション（相互作用）の接点を表し、これ自身がプロパティの一種です。
図F06
ポートの特徴
❑ インタラクションの接点
１．構造化分類子のインスタンスと外部環境
２．構造化分類子のインスタンスと内部分類子のインスタンス
❑ 要求インターフェース： 要求インターフェースは、分類子が外部環境に対して期待しているサービスを性格付けおり、分類子のインスタンスは、外部環境のインスタンスからインターフェースによって規定された振る舞い特性を要求しています。
❑ 提供インターフェース： 提供インターフェースは、分類子が外部環境に提供するサービスの振る舞い特性を性格付けします。
❑ インタラクションの接点オブジェクトは、通常、提供インターフェースを実現する側の分類子のインスタンスです。
❑ ポートは、ポートに到達するすべてのリクエストが分類子のインスタンスによって適切に扱われるよう指定する能力をもちます。（単に、任意の内部の分類子のインスタンスにばらまくだけではありません。）
内部のプロパティとポートがコネクターで接続されている場合は、ポートに到達したすべてのリクエストは、コネクタに沿って転送されます。
ポートは、対象の分類子（構造化分類子）のインスタンスと外部環境の間、あるいは分類子（構造化分類子）と内部分類子のインスタンス間のインタラクション（相互作用）の接点を表し、これ自身がプロパティの一種です。
図F06
❑ インタラクションの接点
１．構造化分類子のインスタンスと外部環境
２．構造化分類子のインスタンスと内部分類子のインスタンス
❑ 要求インターフェース： 要求インターフェースは、分類子が外部環境に対して期待しているサービスを性格付けおり、分類子のインスタンスは、外部環境のインスタンスからインターフェースによって規定された振る舞い特性を要求しています。
❑ 提供インターフェース： 提供インターフェースは、分類子が外部環境に提供するサービスの振る舞い特性を性格付けします。
❑ インタラクションの接点オブジェクトは、通常、提供インターフェースを実現する側の分類子のインスタンスです。
❑ ポートは、ポートに到達するすべてのリクエストが分類子のインスタンスによって適切に扱われるよう指定する能力をもちます。（単に、任意の内部の分類子のインスタンスにばらまくだけではありません。）
内部のプロパティとポートがコネクターで接続されている場合は、ポートに到達したすべてのリクエストは、コネクタに沿って転送されます。
2006年4月23日日曜日
UML中級講座 第16回 複合構造図の例 続き
プロパティ
プロパティは図上で四角形で表されることから分かるように、何らかの分類子（もしくはインスタンスの集まり）を示しています。
ただし普通のクラス図と違い、プロパティは分類子の役割の方に重点を置いており、役割を重視してこれをパートと呼びます。（パートは役割名と解釈しても良いでしょう。）
例えば、図F05の内部構造に存在する４つのパート、即ち、「チューナー」「アンプ」[スピーカー」「電源部」は、何らかの電気回路を意味しています。
従って、これらの四角形はすべて「電気回路」という同一のクラスを表しているが、ただ、それぞれ役割が違うという風に解釈することも可能です。
さらに言うと、これらのクラスは、IC回路であっても、トランジスタ回路であっても、真空管回路であってもかまいません。
要は、この図は４つの役割を持つ分類子（プロパティ）から構成されていることを示しており、ここ数十年間の間に、真空管→トランジスタ→ICと構成部品は変遷して行ったが、基本的な役割間の関係や組み合わせ、パターンは共通であるいう風にも解釈されます。
図F05
プロパティは図上で四角形で表されることから分かるように、何らかの分類子（もしくはインスタンスの集まり）を示しています。
ただし普通のクラス図と違い、プロパティは分類子の役割の方に重点を置いており、役割を重視してこれをパートと呼びます。（パートは役割名と解釈しても良いでしょう。）
例えば、図F05の内部構造に存在する４つのパート、即ち、「チューナー」「アンプ」[スピーカー」「電源部」は、何らかの電気回路を意味しています。
従って、これらの四角形はすべて「電気回路」という同一のクラスを表しているが、ただ、それぞれ役割が違うという風に解釈することも可能です。
さらに言うと、これらのクラスは、IC回路であっても、トランジスタ回路であっても、真空管回路であってもかまいません。
要は、この図は４つの役割を持つ分類子（プロパティ）から構成されていることを示しており、ここ数十年間の間に、真空管→トランジスタ→ICと構成部品は変遷して行ったが、基本的な役割間の関係や組み合わせ、パターンは共通であるいう風にも解釈されます。
図F05
2006年4月21日金曜日
UML中級講座 第15回 第3章 複合構造図
本日から、UMLの個々の図を見て行きたいと思います。最初は、複合構造図（Composite Structures Diagram)です。
第３章 複合構造図
複合構造図は、UML2.0で付け加えられた図で、この図によって、内部構造を何段にもわたって階層的に記述することが可能になりました。
この新たな図の追加に伴い、内部の構成要素を示すパート（もしくはパーツ）と、パート間の接続を表すコネクタ、外部と内部の相互作用の接点を示すポートなどの新しい概念が登場して来ました。
３ー１ 内部構造の表現
３ー１ー１複合構造図の例
まず最初に「FMラジオ」という身近な例を取りだして、複合構造図の表記法を見てみます。
図F01は、FMラジオとそのインターフェース群を書き出しています。そして内部構造はまだ表現されていません。
UML2.0になって、インターフェースは、提供インターフェース（ボール）と要求インターフェース（ソケット）の２種類になりました。
ルールとしては、サービスを提供する側が提供インターフェース、サービスを受ける側が要求インターフェースであり、通常、提供インターフェース側がインターフェースの実現を行ないます。
どちらの表現をとるかは、モデラー（モデル作成者）が決めます。
この図では、「アンテナ」が要求インターフェースで、それ以外の「選局」「電源スイッチ」「ボリューム」「音声」はすべて提供インターフェースとして表現しています。
なお、インターフェースが、提供インターフェースと要求インターフェースの２種類に分かれた背景には、この２種類がペアになって接続される状態を示したいと言う表現上の意図があります。（図F04参照： この図では２つのインターフェスが、依存関係で結ばれており、FMラジオとアンテナがコミュニケーションしている状態を示しています。）
なお、ボール表現に関し、アメリカではその形状からロリポップ（棒つきキャンディ）と呼ぶことが多いので、併せて覚えておくと良いでしょう。
また、インターフェースの表現としては、ボールやソケットで表す方法以外に、図F02の様にクラス内に＜＜provided interface＞＞ と＜＜required interface＞＞というステレオタイプを使ってリスト表記することも出来ます。
次に、内部構造を記述する前に、外部と内部の相互作用の接点であるポートをクラスの境界線上に記述します。（図F03参照)
そして最後に、図F05で示されているように、内部構造を記入します。
この図では、「チューナー」「アンプ」「スピーカー」「電源部」の四つのプロパティが、内部構成要素として記入されそれぞれがコネクタで結ばれています。
第３章 複合構造図
複合構造図は、UML2.0で付け加えられた図で、この図によって、内部構造を何段にもわたって階層的に記述することが可能になりました。
この新たな図の追加に伴い、内部の構成要素を示すパート（もしくはパーツ）と、パート間の接続を表すコネクタ、外部と内部の相互作用の接点を示すポートなどの新しい概念が登場して来ました。
３ー１ 内部構造の表現
３ー１ー１複合構造図の例
図F01は、FMラジオとそのインターフェース群を書き出しています。そして内部構造はまだ表現されていません。
UML2.0になって、インターフェースは、提供インターフェース（ボール）と要求インターフェース（ソケット）の２種類になりました。
ルールとしては、サービスを提供する側が提供インターフェース、サービスを受ける側が要求インターフェースであり、通常、提供インターフェース側がインターフェースの実現を行ないます。
どちらの表現をとるかは、モデラー（モデル作成者）が決めます。
この図では、「アンテナ」が要求インターフェースで、それ以外の「選局」「電源スイッチ」「ボリューム」「音声」はすべて提供インターフェースとして表現しています。
なお、インターフェースが、提供インターフェースと要求インターフェースの２種類に分かれた背景には、この２種類がペアになって接続される状態を示したいと言う表現上の意図があります。（図F04参照： この図では２つのインターフェスが、依存関係で結ばれており、FMラジオとアンテナがコミュニケーションしている状態を示しています。）
また、インターフェースの表現としては、ボールやソケットで表す方法以外に、図F02の様にクラス内に＜＜provided interface＞＞ と＜＜required interface＞＞というステレオタイプを使ってリスト表記することも出来ます。
この図では、「チューナー」「アンプ」「スピーカー」「電源部」の四つのプロパティが、内部構成要素として記入されそれぞれがコネクタで結ばれています。
2006年4月20日木曜日
UML中級講座 第14回 メタモデル図の読み方
前回も言いましたが、メタモデル図とモデル図の文法はほとんど同じです。
しかしながら、メタモデル図固有の表記が多少ありますので、今回はそれをまとめておきたいと思います。
２−３ メタモデル図の表記
インターミディエート資格試験の出題範囲は対応するメタモデル図で指定されていますので、本講座では指定されたメタモデル図をすべて掲載して行きたいと考えております。
しかしながら、試験問題のレベルとしては直接メタモデル図が出題されることはなく、概要がわかれば良い程度です。
従って、このコースでのメタモデル図の解説も必要最小限にしておりますが、初めてメタモデル図を見た場合、多少の違和感を感じることもあると思いますので、ここに、メタモデル図の表記上の主立った特徴をまとめておきます。
（ほとんどの場合、モデル図での解釈と同じですが、ここで記述するものはメタモデル図固有のルールです。）
既存の言語を使って新しい言語を設計
このような差が生じる原因は、新たな言語（UML2.0)を設計する際に使用する設計言語が、これから作ろうと言う新しい言語ではなく、既存の古い言語（UML 1.X)であるためです。
従って、この記法はけっして、今後の推奨すべき方向を指し示すものでなく、むしろ逆に過去の文法に則った表記法です。
これからインターミディエート資格試験を受けようとする方にとっては、それほど気にするべきほどのものではありません。あくまで参考程度と考えてください。
メタモデル図固有の表記法
一方向にのみ誘導可能性のマーク（矢印）が付いている関連は、その方向に誘導可能であることを意味する。マークが付いている方の関連端は、分類子によって所有され、マークがついていない方の関連端は関連によって所有されている。
誘導可能性のマーク（矢印）が付いていない関連は、両方向に誘導可能であり、関連端はそれぞれ反対側の分類子によって所有されている。（関連には所有されていない。）
関連端に付けられた制約｛subsets endA} ： 関連端 endAが特化されたことを示す。
関連端に付けられた制約｛ redefines endA} ：関連端 endAが特化され再定義されたことを示す。
多重度の表記が省略された場合、多重度は１。
パッケージ間の指定されていない依存関係は包含関係（＜＜ include＞＞)を意味する。
しかしながら、メタモデル図固有の表記が多少ありますので、今回はそれをまとめておきたいと思います。
２−３ メタモデル図の表記
インターミディエート資格試験の出題範囲は対応するメタモデル図で指定されていますので、本講座では指定されたメタモデル図をすべて掲載して行きたいと考えております。
しかしながら、試験問題のレベルとしては直接メタモデル図が出題されることはなく、概要がわかれば良い程度です。
従って、このコースでのメタモデル図の解説も必要最小限にしておりますが、初めてメタモデル図を見た場合、多少の違和感を感じることもあると思いますので、ここに、メタモデル図の表記上の主立った特徴をまとめておきます。
（ほとんどの場合、モデル図での解釈と同じですが、ここで記述するものはメタモデル図固有のルールです。）
既存の言語を使って新しい言語を設計
このような差が生じる原因は、新たな言語（UML2.0)を設計する際に使用する設計言語が、これから作ろうと言う新しい言語ではなく、既存の古い言語（UML 1.X)であるためです。
従って、この記法はけっして、今後の推奨すべき方向を指し示すものでなく、むしろ逆に過去の文法に則った表記法です。
これからインターミディエート資格試験を受けようとする方にとっては、それほど気にするべきほどのものではありません。あくまで参考程度と考えてください。
メタモデル図固有の表記法
一方向にのみ誘導可能性のマーク（矢印）が付いている関連は、その方向に誘導可能であることを意味する。マークが付いている方の関連端は、分類子によって所有され、マークがついていない方の関連端は関連によって所有されている。
誘導可能性のマーク（矢印）が付いていない関連は、両方向に誘導可能であり、関連端はそれぞれ反対側の分類子によって所有されている。（関連には所有されていない。）
関連端に付けられた制約｛subsets endA} ： 関連端 endAが特化されたことを示す。
関連端に付けられた制約｛ redefines endA} ：関連端 endAが特化され再定義されたことを示す。
多重度の表記が省略された場合、多重度は１。
パッケージ間の指定されていない依存関係は包含関係（＜＜ include＞＞)を意味する。
2006年4月19日水曜日
UML中級講座 第13回 メタ構造
前回、メタモデルやメタメタモデルの言語仕様は、ほとんど同じだけれども、異なるレイヤーとして定義している、というお話をしました。
それでは、事実上同じ性質なのに、なぜクラスのクラスはクラスではなくメタクラスと呼ぶのでしょうか？
メタ構造
UMLの最終仕様書には全く振れられていませんが、言語設計の段階での設計者のコメントが、彼らの本音をかいま見せています。
仕様書の裏に見え隠れする事情について振れてみます。
クラスの集まり
以前クラスのインスタンスはオブジェクトである、つまりクラスはオブジェクトの集まりであるというお話をしました。
そして、オブジェクトとクラスは違う性質を持つために混同することはないと思います。
ところが、メタクラスとクラスは共に集まりの概念であり、基本的に全く同じ文法上のルールに従った振舞いと構造を持ちます。
従って、わざわざメタクラスなどと言う大仰なものを定義しなくてもいいではないかと言う疑問が湧いてきます。
そこで、今度は仮に、クラスの集まりもクラスである、つまりクラスはクラスのインスタンスであると仮定するとどうなるでしょうか？
すべての集合の集合
この場合、クラスはクラスに属することになります。
これを、集合論のアナロジーで考えてみたいと思います。
ここで、集合Aを｛すべての集合の集合｝とすると考えた場合、クラスがクラスに属する状態と同じ現象が発生し、A∈Aとなります。
ところが、自分自身を要素として含む集合は、論理的に矛盾を引き起こしてしまい、数学的に許されません。（☆：簡略版の証明を本日の投稿の末尾に掲げました）
ラッセルのパラドックス（集まり、集合に関する逆理）
集合論は、抽象的な事柄を議論するには非常に便利なツールであり、現代数学の基礎となっています。
しかし、そこには強い劇薬も含まれています。
そして、その影響は、様々な要素を集めて巨大な集合を作る際に顕著に表れてきます。
先ほど、述べましたように集合は、自分自身を要素として含むことが許されません。
そこで今度は、自分自身を含まない集合の集合を考えてみましょう。
ここでは、この集合をRと呼ぶことにします。
そうしますと、今度は「Rは自分自身を含むか？」と言う疑問がわいてきます。かりに、もし含まないとすると、定義からRは自分自身を含まない集合の集合ですから、Rは自分自身を含んでしまうことになります。
今度は逆に、Rは自分自身を含むとすると、定義からRは自分自身を含まないものの集合ですから、Rは自分自身を含まないことになり矛盾します。
この矛盾はいったいどこから来るのでしょうか？
実は、Rを集合だと考えたことに問題があったのです。
集合がどんどん大きくなると（例えばすべての集合の集合など）、もう集合ではなくなってしまうのです。
集合を超えた集まり
メタクラスもこのアナロジーが働きます。
すべてのクラスを集めてしまうと、もはやクラスではなくなってしまいます。
メタは、メタフィジックス（形而上学）のメタと同根で、「〜を超えた」「超越した」という意味があります。
メタモデルとメタメタモデルの関係も同様です。メタモデルを超越したモデルがメタメタモデルです。
そして、UMLの言語仕様には、データレイヤー→メタデータレイヤー→メタモデルレイヤー→メタメタモデルレイヤーという厳密なレイヤー構造が適用されます。
UML設計者たちは、これらの構造を集合の濃度の階梯に例えています。これについては、また後日解説したいと思います。
☆カントールのパラドックス
A={x : x=x} (Aはすべての集合の集合）とする。
すると、Aのベキ集合P(A)が存在し、 Aの濃度 < P(A)の濃度 となる。
しかし、P(A)の要素はすべて集合なので、 P(A) ⊂ A であり、Aの濃度 ≧ P(A)の濃度 となり、これは矛盾。
より詳しくは、集合論の本を参照してください。（例： 「数学のロジックと集合論」培風館 ）
それでは、事実上同じ性質なのに、なぜクラスのクラスはクラスではなくメタクラスと呼ぶのでしょうか？
メタ構造
UMLの最終仕様書には全く振れられていませんが、言語設計の段階での設計者のコメントが、彼らの本音をかいま見せています。
仕様書の裏に見え隠れする事情について振れてみます。
クラスの集まり
以前クラスのインスタンスはオブジェクトである、つまりクラスはオブジェクトの集まりであるというお話をしました。
そして、オブジェクトとクラスは違う性質を持つために混同することはないと思います。
ところが、メタクラスとクラスは共に集まりの概念であり、基本的に全く同じ文法上のルールに従った振舞いと構造を持ちます。
従って、わざわざメタクラスなどと言う大仰なものを定義しなくてもいいではないかと言う疑問が湧いてきます。
そこで、今度は仮に、クラスの集まりもクラスである、つまりクラスはクラスのインスタンスであると仮定するとどうなるでしょうか？
すべての集合の集合
この場合、クラスはクラスに属することになります。
これを、集合論のアナロジーで考えてみたいと思います。
ここで、集合Aを｛すべての集合の集合｝とすると考えた場合、クラスがクラスに属する状態と同じ現象が発生し、A∈Aとなります。
ところが、自分自身を要素として含む集合は、論理的に矛盾を引き起こしてしまい、数学的に許されません。（☆：簡略版の証明を本日の投稿の末尾に掲げました）
ラッセルのパラドックス（集まり、集合に関する逆理）
集合論は、抽象的な事柄を議論するには非常に便利なツールであり、現代数学の基礎となっています。
しかし、そこには強い劇薬も含まれています。
そして、その影響は、様々な要素を集めて巨大な集合を作る際に顕著に表れてきます。
先ほど、述べましたように集合は、自分自身を要素として含むことが許されません。
そこで今度は、自分自身を含まない集合の集合を考えてみましょう。
ここでは、この集合をRと呼ぶことにします。
そうしますと、今度は「Rは自分自身を含むか？」と言う疑問がわいてきます。かりに、もし含まないとすると、定義からRは自分自身を含まない集合の集合ですから、Rは自分自身を含んでしまうことになります。
今度は逆に、Rは自分自身を含むとすると、定義からRは自分自身を含まないものの集合ですから、Rは自分自身を含まないことになり矛盾します。
この矛盾はいったいどこから来るのでしょうか？
実は、Rを集合だと考えたことに問題があったのです。
集合がどんどん大きくなると（例えばすべての集合の集合など）、もう集合ではなくなってしまうのです。
集合を超えた集まり
メタクラスもこのアナロジーが働きます。
すべてのクラスを集めてしまうと、もはやクラスではなくなってしまいます。
メタは、メタフィジックス（形而上学）のメタと同根で、「〜を超えた」「超越した」という意味があります。
メタモデルとメタメタモデルの関係も同様です。メタモデルを超越したモデルがメタメタモデルです。
そして、UMLの言語仕様には、データレイヤー→メタデータレイヤー→メタモデルレイヤー→メタメタモデルレイヤーという厳密なレイヤー構造が適用されます。
UML設計者たちは、これらの構造を集合の濃度の階梯に例えています。これについては、また後日解説したいと思います。
☆カントールのパラドックス
A={x : x=x} (Aはすべての集合の集合）とする。
すると、Aのベキ集合P(A)が存在し、 Aの濃度 < P(A)の濃度 となる。
しかし、P(A)の要素はすべて集合なので、 P(A) ⊂ A であり、Aの濃度 ≧ P(A)の濃度 となり、これは矛盾。
より詳しくは、集合論の本を参照してください。（例： 「数学のロジックと集合論」培風館 ）
2006年4月18日火曜日
UML中級講座 第12回 コア・パッケージ
本日は、前回の言語アーキテクチャの続きで、コアパッケージにつて解説したいと思います。
コアパッケージ
UMLのアーキテクチャでは、モデル・レイヤーの上にメタモデル・レイヤーがあり、さらにその上に、メタメタモデル・レイヤーが存在すると言うお話をしました。
では、このメタメタモデルの言語仕様を定義する場としてメタメタメタモデルが存在するのかというと、そうではありません。
実は、M2レイヤーとM3レイヤーの言語仕様はほとんど同じなのです。
これは、M1レイヤーの言語使用に関しても、ほぼ同じことが言えます。
そのために、UMLでは、各レイヤーに共通する言語仕様を一ヶ所でまとめて定義し、それをコアパッケージと呼んで、各レイヤーで共通利用しています。
また、このコアパッケージは、UMLだけではなく、他の言語を定義する際にも利用されています。
（図２−４参照）
（なぜ、言語仕様が同じなのに、レイヤーを分けるのかは、次回触れたいと思います。)
図２−４
このコアパッケージは、抽象度は高いのですが、逆に内容は極めてシンプルです。
例えば、可視性には、プロテクト（＃）とかパッケージ（〜）がなく、単にパブリック（＋）とプライベート（ー）の２種類しかありません。
そして、メタモデル図の表記もモデル図よりもずっとシンプルです。
コアパッケージ
UMLのアーキテクチャでは、モデル・レイヤーの上にメタモデル・レイヤーがあり、さらにその上に、メタメタモデル・レイヤーが存在すると言うお話をしました。
では、このメタメタモデルの言語仕様を定義する場としてメタメタメタモデルが存在するのかというと、そうではありません。
実は、M2レイヤーとM3レイヤーの言語仕様はほとんど同じなのです。
これは、M1レイヤーの言語使用に関しても、ほぼ同じことが言えます。
そのために、UMLでは、各レイヤーに共通する言語仕様を一ヶ所でまとめて定義し、それをコアパッケージと呼んで、各レイヤーで共通利用しています。
また、このコアパッケージは、UMLだけではなく、他の言語を定義する際にも利用されています。
（図２−４参照）
（なぜ、言語仕様が同じなのに、レイヤーを分けるのかは、次回触れたいと思います。)
このコアパッケージは、抽象度は高いのですが、逆に内容は極めてシンプルです。
例えば、可視性には、プロテクト（＃）とかパッケージ（〜）がなく、単にパブリック（＋）とプライベート（ー）の２種類しかありません。
そして、メタモデル図の表記もモデル図よりもずっとシンプルです。
2006年4月17日月曜日
UML中級講座 第11回 言語アーキテクチャ
本日は、言語アーキテクチャについて概説したいと思います。
世の中には、様々なコンピュータ・アーキテクチャがありますが、その大部分はレイヤー構造・階層構造を持っています。
UMLも例外ではありません。4層からなる階層構造を持っています。
２−２ 言語アーキテクチャー
レイヤー構造
先に述べましたメタモデルには、さらに上位の構造、メタメタモデルが存在します。（図２−３参照）
図２−３
メタモデルを持つ言語は、UMLだけではありません。
JavaやCWMなどにもメタモデルが存在します。
そして、それぞれのメタモデル図を統一する場として、メタメタモデルが存在します。
このレイヤーのことを、メタメタモデルレイヤーあるいはM3レイヤーまたはMOF（Meta Object Facility)レイヤーと呼びます。
なお、M０レイヤーのことを、別名データレイヤーと呼び、M1レイヤーをデータレイヤーの上であることから、メタデータレイヤーと呼ぶこともあります。
世の中には、様々なコンピュータ・アーキテクチャがありますが、その大部分はレイヤー構造・階層構造を持っています。
UMLも例外ではありません。4層からなる階層構造を持っています。
２−２ 言語アーキテクチャー
レイヤー構造
先に述べましたメタモデルには、さらに上位の構造、メタメタモデルが存在します。（図２−３参照）
図２−３
JavaやCWMなどにもメタモデルが存在します。
そして、それぞれのメタモデル図を統一する場として、メタメタモデルが存在します。
このレイヤーのことを、メタメタモデルレイヤーあるいはM3レイヤーまたはMOF（Meta Object Facility)レイヤーと呼びます。
なお、M０レイヤーのことを、別名データレイヤーと呼び、M1レイヤーをデータレイヤーの上であることから、メタデータレイヤーと呼ぶこともあります。
2006年4月14日金曜日
UML中級講座 第10回 メタモデリング
第９回で、お話しましたメタモデリングの続きです。メタモデルは、モデル言語を定義、設計するものです。
メタモデリング（続き）
UML2.0では、クラス図に加えオブジェクト図が正式な形で登録されましたので（より正確に言いますと、インスタンス図が正式に表現することができるようになり、オブジェクト図はインスタンス図の一つの形式となります）、オブジェクト図に登場する要素すべてに対し、メタモデル層のなかで対応するメタクラスが存在します。
図２−２
モデルレイヤーで記述される図には、必ず対応するメタモデルが存在します。図２−２は、「人」クラスのインスタンスである「太郎」オブジェクトをモデル表現し（いわゆるオブジェクト図、UML2.0では正確にはインスタンス図と呼ばれる）、そのメタクラスである「InstanceSpecification」と＜＜ instanceOf ＞＞の関係があることを示しています。
この関係は、オブジェクト図、インスタンス図に限らず、UMLで表現されるすべての要素（図示されるものだけではなく、明示されないものも含めて）に関して存在します。
メタモデリング（続き）
UML2.0では、クラス図に加えオブジェクト図が正式な形で登録されましたので（より正確に言いますと、インスタンス図が正式に表現することができるようになり、オブジェクト図はインスタンス図の一つの形式となります）、オブジェクト図に登場する要素すべてに対し、メタモデル層のなかで対応するメタクラスが存在します。
図２−２
この関係は、オブジェクト図、インスタンス図に限らず、UMLで表現されるすべての要素（図示されるものだけではなく、明示されないものも含めて）に関して存在します。
2006年4月12日水曜日
UML中級講座 第9回 メタモデル、メタクラス
本日は、メタモデルとモデル図の関係、そしてメタクラスについて議論して行きましょう。
メタモデル、メタクラス
UMLは構造と振る舞いを持つ対象をモデル化する言語です。そして、UML自身も構造と振る舞いを持ちます。すなわち、UMLは自分自身をモデル化することができ、その自分自身のモデルのことをメタモデルと呼びます。
個々のオブジェクトの集まりをクラスとしてまとめたように、個々のクラスをさらにまとめたものをメタクラスと呼びます。
「ミケ」や「タマ」などの個々の「猫」オブジェクトをすべて集めたものを「猫」クラスと呼ぶように、「猫」クラス、「犬」クラスなどモデル作成で使用するクラスをすべて集めたもの、つまりクラスのクラスをメタクラスと呼びます。
図２−１メタモデリング
図２−１の例で示される様に、「人」クラスや「車」クラスは「Class」というメタクラスのインスタンスの関係になります。
また注意を要する点として、モデル作成で使用される要素は、メタモデル化されるとすべてメタクラスとなります。
つまり、モデル作成で用いられる関連「所有する」は、メタモデルでは「Association（関連）」メタクラスとなります。
そして、通常のモデル図の世界とメタモデル図の世界は別のレイヤー（層）として区別され、モデル作成を行うレイヤーのことをモデルレイヤー、メタモデルのレイヤーをメタモデルレイヤーと呼び、レイヤー間の個々の要素の関係はインスタンスの関係となります。（図２−１中の＜＜InstanceOf＞＞というステレオタイプで示された従属関係）
メタモデル、メタクラス
UMLは構造と振る舞いを持つ対象をモデル化する言語です。そして、UML自身も構造と振る舞いを持ちます。すなわち、UMLは自分自身をモデル化することができ、その自分自身のモデルのことをメタモデルと呼びます。
個々のオブジェクトの集まりをクラスとしてまとめたように、個々のクラスをさらにまとめたものをメタクラスと呼びます。
「ミケ」や「タマ」などの個々の「猫」オブジェクトをすべて集めたものを「猫」クラスと呼ぶように、「猫」クラス、「犬」クラスなどモデル作成で使用するクラスをすべて集めたもの、つまりクラスのクラスをメタクラスと呼びます。
図２−１メタモデリング
また注意を要する点として、モデル作成で使用される要素は、メタモデル化されるとすべてメタクラスとなります。
つまり、モデル作成で用いられる関連「所有する」は、メタモデルでは「Association（関連）」メタクラスとなります。
そして、通常のモデル図の世界とメタモデル図の世界は別のレイヤー（層）として区別され、モデル作成を行うレイヤーのことをモデルレイヤー、メタモデルのレイヤーをメタモデルレイヤーと呼び、レイヤー間の個々の要素の関係はインスタンスの関係となります。（図２−１中の＜＜InstanceOf＞＞というステレオタイプで示された従属関係）
2006年4月11日火曜日
UML中級講座 第8回 インスタンスの概念
前回に引き続いて、インスタンスについて議論して行きましょう。インスタンスは、メタモデルの中心的な概念で、体系の骨格をなすものです。
インスタンス
このインスタンスの概念は、非常に便利な概念で、様々な形で利用されます。
関連とリンク
「高校生」クラスと「大学」クラスの間の「受験する」という関連（Association)を考えて見ましょう。
「高校生」クラスに属する個々のオブジェクトは、それぞれ自分の志願校を受験します。
例えば、「橋本さん」は「東京大学」を受験、「小沢さん」は「慶応大学」を受験すると想定します。
この、「橋本さん」ー「東京大学」、「小沢さん」ー「慶応大学」と言った個々の具体的なオブジェクト間の関係をリンクと呼びます。
そうしますと、「高校生」クラスと「大学生」クラスの関係である関連とは、個々のオブジェクト間の関係であるリンクの集まりと見なすことが出来ます。
別の言い方をすると、リンクは関連のインスタンスと呼ぶことになります。
分類子
型の性質を持つもの（つまりインスタンスを持つと言う性質を持つもの）を総称して、UMLでは分類子（Classifier)と呼んでいます。UMLを定義する上で、この分類子は極めて重要な働きをします。モデル図に登場する要素の大部分が分類子に属します。（参考図参照）
インスタンス
このインスタンスの概念は、非常に便利な概念で、様々な形で利用されます。
関連とリンク
「高校生」クラスと「大学」クラスの間の「受験する」という関連（Association)を考えて見ましょう。
「高校生」クラスに属する個々のオブジェクトは、それぞれ自分の志願校を受験します。
例えば、「橋本さん」は「東京大学」を受験、「小沢さん」は「慶応大学」を受験すると想定します。
この、「橋本さん」ー「東京大学」、「小沢さん」ー「慶応大学」と言った個々の具体的なオブジェクト間の関係をリンクと呼びます。
そうしますと、「高校生」クラスと「大学生」クラスの関係である関連とは、個々のオブジェクト間の関係であるリンクの集まりと見なすことが出来ます。
別の言い方をすると、リンクは関連のインスタンスと呼ぶことになります。
分類子
型の性質を持つもの（つまりインスタンスを持つと言う性質を持つもの）を総称して、UMLでは分類子（Classifier)と呼んでいます。UMLを定義する上で、この分類子は極めて重要な働きをします。モデル図に登場する要素の大部分が分類子に属します。（参考図参照）
表記法の観点からも、分類子の概念は重要です。
クラス図等でクラスを表すときに用いられる四角形は、本来的には分類子を表象しています。
そして、どの分類子であるかを示すために、＜＜Interface＞＞や＜＜actor＞＞、＜＜class＞＞などのステレオタイプを使って区別しますが、＜＜class＞＞と言うステレオタイプのみが省略可能です。
従って結果として、クラス図で特に何も規定していない四角形はクラスであることを意味することになります。
クラス図等でクラスを表すときに用いられる四角形は、本来的には分類子を表象しています。
そして、どの分類子であるかを示すために、＜＜Interface＞＞や＜＜actor＞＞、＜＜class＞＞などのステレオタイプを使って区別しますが、＜＜class＞＞と言うステレオタイプのみが省略可能です。
従って結果として、クラス図で特に何も規定していない四角形はクラスであることを意味することになります。
2006年4月10日月曜日
UML中級講座 第7回 第2章 メタモデル構造の理解
本日から、オブジェクト指向言語の特徴であるメタモデル構造のお話をします。
メタモデルは、UMLと言う言語だけが持っていると思われている方がいらっしゃいますが、Javaなどのすべてのオブジェクト指向型言語は、メタモデルを持っています。
UMLが他のオブジェクト指向型言語と異なる点は、UML自身のメタモデルを、UML自身で記述・定義できると言う点にあります。
逆に言いますと、UMLはモデル記述言語として極めて強いパワーを持っていると言えます。
2章 メタモデル構造の理解
２−１メタモデリング
インスタンスと型（タイプ）について
インスタンスと型の関係はファンダメンタル資格試験でも問われる重要な問題であり、UML言語を語る上では絶対にはずせない話題です。
また、従来のコンピュータ言語、例えばJava等でも、根底にはこのインスタンスと型の関係が横たわっています。
さらにまた、メタモデルを理解する上でも、最も基本的な概念となります。ここでは復習の意味もかねて、この関係について考えてみましょう。
まず簡単な例としてデータ型を見てみましょう。実数や整数という型は、どんなコンピュータ言語にも必ずある型です。３．１４１６とかー２，ー３などはそれらの実例となります。
この実例とデータ型の関係がインスタンスという概念の原型です。
もう少し、見通しの良い言い方をすると、インスタンスと型の関係は、実例と、実例が集まったものとの関係と言うことが出来ます。
実数という型は個々の実数がすべて集まったもの、ストリング（文字列）型とは、様々な文字列がすべて集まったものと言う風に、中学校の数学で習った集合論と極めて似た概念で捉えることが出来ます。
（ 注： ただ一点注意しなければならないのは、型は厳密に言うと集合とは異なる集まりの概念です。集合（Set)では、要素の重複が許されないのに対し、型はいくらでも重複が許されます。
こういう集まりを、UMLでは、集合（Set)に対し、コレクション（Collection)と呼んでいます。以下、本書では、特に断らない限りは、集まりはコレクションのことを指し、集合を指す場合は明示的に「集合」という表現をします。）
データ型以外の型として、代表的なものがクラスという概念です。
クラスのインスタンスはオブジェクトです。つまり、クラスはオブジェクトの集まりと捉えることが出来ます。「猫」クラスと言うのは、個々に実在する「ミケ」や「タマ」などの「猫」オブジェクトの集まり概念、「人」クラスとは、「小渕さん」、「森さん」、「小泉さん」など実体、オブジェクトをインスタンスとして持つ集まりの概念です。
サブクラスとスパークラス
サブクラスとスーパークラスの関係も、部分集合（サブセット）の考え方と似ています。「男」クラスと「人」クラスは集合で言う包含関係にあります。つまり、すべての「男」オブジェクトは「男」クラスに属するとともに「人」クラスにも属します。同様に、「人」クラスは「霊長類」クラスに包含されます。別の言い方をすると、「人」クラスは「男」クラスに対しては、スーパークラスであるが、「霊長類」クラスに対してはサブクラスになり、極めて相対的な概念であることがわかります。
抽象クラス
ヒトの集まりである「人」クラス、類人猿の集まりを「類人猿」クラス、猿の集まりを「猿」クラスとし、これら３つのクラスを集めたものを、仮に「霊長類」クラスと呼ぶとしましょう。そうしますと、「霊長類」クラスは他の３つのクラスの共通のスーパークラスとなります。
そして、「霊長類」クラスに属するインスタンス、オブジェクトは、必ず何れかのサブクラスに属することになります。この「霊長類」クラスのように、すべてのインスタンスが必ずどれかのサブクラスのインスタンスになってしまうもの、つまり間接的にしかインスタンスを持ち得ないクラスを抽象クラスと呼びます。
また、たとえ一つであっても直接インスタンスを持つ場合は、抽象クラスとは呼びません。なお、抽象クラスとは反対に、直接インスタンスを持ちうるクラスのことを具象クラスと呼びます。
メタモデルは、UMLと言う言語だけが持っていると思われている方がいらっしゃいますが、Javaなどのすべてのオブジェクト指向型言語は、メタモデルを持っています。
UMLが他のオブジェクト指向型言語と異なる点は、UML自身のメタモデルを、UML自身で記述・定義できると言う点にあります。
逆に言いますと、UMLはモデル記述言語として極めて強いパワーを持っていると言えます。
2章 メタモデル構造の理解
２−１メタモデリング
インスタンスと型（タイプ）について
インスタンスと型の関係はファンダメンタル資格試験でも問われる重要な問題であり、UML言語を語る上では絶対にはずせない話題です。
また、従来のコンピュータ言語、例えばJava等でも、根底にはこのインスタンスと型の関係が横たわっています。
さらにまた、メタモデルを理解する上でも、最も基本的な概念となります。ここでは復習の意味もかねて、この関係について考えてみましょう。
まず簡単な例としてデータ型を見てみましょう。実数や整数という型は、どんなコンピュータ言語にも必ずある型です。３．１４１６とかー２，ー３などはそれらの実例となります。
この実例とデータ型の関係がインスタンスという概念の原型です。
もう少し、見通しの良い言い方をすると、インスタンスと型の関係は、実例と、実例が集まったものとの関係と言うことが出来ます。
実数という型は個々の実数がすべて集まったもの、ストリング（文字列）型とは、様々な文字列がすべて集まったものと言う風に、中学校の数学で習った集合論と極めて似た概念で捉えることが出来ます。
（ 注： ただ一点注意しなければならないのは、型は厳密に言うと集合とは異なる集まりの概念です。集合（Set)では、要素の重複が許されないのに対し、型はいくらでも重複が許されます。
こういう集まりを、UMLでは、集合（Set)に対し、コレクション（Collection)と呼んでいます。以下、本書では、特に断らない限りは、集まりはコレクションのことを指し、集合を指す場合は明示的に「集合」という表現をします。）
データ型以外の型として、代表的なものがクラスという概念です。
クラスのインスタンスはオブジェクトです。つまり、クラスはオブジェクトの集まりと捉えることが出来ます。「猫」クラスと言うのは、個々に実在する「ミケ」や「タマ」などの「猫」オブジェクトの集まり概念、「人」クラスとは、「小渕さん」、「森さん」、「小泉さん」など実体、オブジェクトをインスタンスとして持つ集まりの概念です。
サブクラスとスパークラス
サブクラスとスーパークラスの関係も、部分集合（サブセット）の考え方と似ています。「男」クラスと「人」クラスは集合で言う包含関係にあります。つまり、すべての「男」オブジェクトは「男」クラスに属するとともに「人」クラスにも属します。同様に、「人」クラスは「霊長類」クラスに包含されます。別の言い方をすると、「人」クラスは「男」クラスに対しては、スーパークラスであるが、「霊長類」クラスに対してはサブクラスになり、極めて相対的な概念であることがわかります。
抽象クラス
ヒトの集まりである「人」クラス、類人猿の集まりを「類人猿」クラス、猿の集まりを「猿」クラスとし、これら３つのクラスを集めたものを、仮に「霊長類」クラスと呼ぶとしましょう。そうしますと、「霊長類」クラスは他の３つのクラスの共通のスーパークラスとなります。
そして、「霊長類」クラスに属するインスタンス、オブジェクトは、必ず何れかのサブクラスに属することになります。この「霊長類」クラスのように、すべてのインスタンスが必ずどれかのサブクラスのインスタンスになってしまうもの、つまり間接的にしかインスタンスを持ち得ないクラスを抽象クラスと呼びます。
また、たとえ一つであっても直接インスタンスを持つ場合は、抽象クラスとは呼びません。なお、抽象クラスとは反対に、直接インスタンスを持ちうるクラスのことを具象クラスと呼びます。
2006年4月8日土曜日
UML中級講座 第6回 どんな人が中級レベルを目指すべき？
第一章の終わりとして、本日は、いったいどんな人がUMLの中級レベルのスキルを身に付けるべきか、別の言い方をすると、どんな人がOCUPインタミディエート資格試験の合格を目指すべきであるかを、お話したいと思います。
どういう人がインターミディエート資格試験を目指すべきか？
インターミディエート資格試験で問われる知識が必要となる役割は、一言で言いますと「正確で適切なモデリングを行う必要のある人」が該当します。
大まかな業務フローをスケッチ的にモデリングしたり（システム設計に関わらない業務アナリストなど）、他の設計者が作成した実装モデルに基づいてプログラミングするだけの人にとっては、ファンダメンタルレベルの知識でおそらく十分でしょう。
インターミディエート資格試験を持つべき代表的な職種を次の表に揚げてみます。
• ❑ 1 システム設計者、アーキテクト
• ❑ 2 システム分析者
• ❑ 3 品質保証部門、品質試験部門 （ソフトウエアやドキュメンテーション）
• ❑ 4 プロジェクトや組織内で、UMLスペシャリストとしてアサインされた者
• ❑ 5 プロジェクトや組織内で、文書化を指導する立場にある者
• ❑ 6 オブジェクト指向開発を指導する立場にある者（場合によっては、プロジェクトマネジャ自身）
• ❑ 7 組み込み系ソフトウエア開発者（設計者および上級プログラマ）
それでは、次回、2章以降で、UML2.0の各項目を見てゆきましょう。
どういう人がインターミディエート資格試験を目指すべきか？
インターミディエート資格試験で問われる知識が必要となる役割は、一言で言いますと「正確で適切なモデリングを行う必要のある人」が該当します。
大まかな業務フローをスケッチ的にモデリングしたり（システム設計に関わらない業務アナリストなど）、他の設計者が作成した実装モデルに基づいてプログラミングするだけの人にとっては、ファンダメンタルレベルの知識でおそらく十分でしょう。
インターミディエート資格試験を持つべき代表的な職種を次の表に揚げてみます。
• ❑ 1 システム設計者、アーキテクト
• ❑ 2 システム分析者
• ❑ 3 品質保証部門、品質試験部門 （ソフトウエアやドキュメンテーション）
• ❑ 4 プロジェクトや組織内で、UMLスペシャリストとしてアサインされた者
• ❑ 5 プロジェクトや組織内で、文書化を指導する立場にある者
• ❑ 6 オブジェクト指向開発を指導する立場にある者（場合によっては、プロジェクトマネジャ自身）
• ❑ 7 組み込み系ソフトウエア開発者（設計者および上級プログラマ）
それでは、次回、2章以降で、UML2.0の各項目を見てゆきましょう。
2006年4月7日金曜日
UML中級講座 第5回 OCUPインタミディエートの出題範囲
この中級講座は、OCUPインタミディエート資格試験の受験者レベルの方を想定した内容です。
本日は、前回に引き続き、OCUPインタミディエート資格試験の出題範囲について解説したいと思います。
インターミディエート資格試験の出題範囲
インターミディエートの出題範囲は次のようになっています。
出題範囲サマリー （パーセント表示は、出題される問題の割合）
• ❑ 1.0 コンポジット構造図 １５％
• ❑ 2.0 コンポーネント図 １５％
• ❑ 3.0 アクションモデル １０％
• ❑ 4.0 アクティビティ図 １５％
• ❑ 5.0 インタラクション図 １５％
• ❑ 6.0 ステートマシン図 １５％
• ❑ 7.0 配備図 ５％
• ❑ 8.0 プロファイル １０％
メタモデルも出題範囲
ファンダメンタル資格試験とは異なり、インターミディエート資格試験では、出題範囲の詳細情報としてメタモデル図が指定されています。（ 表中の＜＞内の数字は、本書掲載のメタモデル図の番号）
また、問題作成時に試験範囲とされているメタモデル図が、２００５年の最終版仕様書では削除されていたり、変更が加わっているものがあります。本講座で使用しているメタモデルはあくまで最終版仕様書のものを採用しています。
これは、最終版の知識を身につけて試験に臨むべきであると言う考えに基づいています。
なお、すでに対象のメタモデル図が削除されているものや、大幅な変更が発生しているものについては、下記の出題範囲詳細のなかで＜＞内にコメントとして記入してあります。
（概念整理の過程で必要性が無くなったと判断されたものや、他のメタモデル図に吸収されてしまったものが該当します。個々のケースについて、暫定版からの変更の説明が必要と判断したものに関しては、各メタモデル図の解説の中で振れます。）
出題範囲詳細
❑ １．０ コンポジット構造図
❑ １．１ 内部構造
• １ 構造化分類子 ＜０９−０２＞
• ２ コネクタ ＜０９−０３＞
❑ １．２ ポートのモデリング
• １ ポート ＜０９−０４＞
• ２ コネクタ端 ＜同上図＞
❑ １．３ 構造化クラス
• １ クラス ＜０９−０５＞
❑ １．４ 呼び出しのモデリング
• １ アクション呼び出し ＜０９−０８＞
• ２ トリガー ＜同上図＞
❑ ２．０ コンポーネント図
❑ ２．１コンポーネントの基礎 ＜０８−０３＞、＜０８−０３＞
• １ コンポーネント
• ２ コネクタ
• ３ 実現
• ４ 他の概念
❑ ３．０ アクションモデル
❑ ３．１ アクション言語
• １ アクション呼び出し（Invocation Actions) ＜最終版仕様書では１１−０４と１１−０５の二つ＞
• ２ アクションの適用 (Apply Actions) ＜該当する図は、最終版仕様書から削除されている＞
• ３ オブジェクト・アクション (Object Actions) ＜１１−０６＞
• ４ 構造特性アクション (Structure Feature Actions) ＜１１−０７＞
• ５ リンク識別 (Link Identification) ＜１１−０８＞
• ６ リンク読み取りアクション (Read Link Actions) ＜１１−０９＞
• ７ リンク書き出しアクション (Write Link Actions) ＜１１−１０＞
• ８ 変数アクション (Variable Actions) ＜１１−１７ 最終版仕様書では大幅に変更＞
• ９ 他の概念
❑ ４．０ アクティビティ図
❑ ４．１ アクティビティ図
• １ オブジェクトノード ＜１２−０８＞
• ２ コントロール ＜１２−０９＞
• ３ パーティション ＜１２−１０＞
• ４ 他の概念
❑ ４．２ 構造化アクティビティ図 ＜１２−２１＞、＜１２−２２＞、＜１２−２３＞
• １ 構造化アクティビティノード
• ２ 条件ノード
• ３ ループノード
• ４ 他の概念
❑ ５．０ インタラクション図
❑ ５．１ インタラクション・フラグメント
• １ 結合フラグメント ＜１４−０７＞
• ２ ゲート ＜１４−０８＞
• ３ インタラクション・オカレンス ＜１４−０９ インタラクション・オカレンスは最終版仕様書ではインタラクション・ユースに名前を変更＞
• ４ 他の概念
❑ ６．０ ステートマシン図
❑ ６．１ ステートマシンの振る舞い ＜１５−０２＞
• １ 状態と有限状態
• ２ 疑似状態と終了状態
• ３ 遷移
• ４ コネクションポイント参照
• ５ ステートマシン
• ６ 他の概念
❑ ６．２ １リージョンのステートマシン ＜最終版仕様書ではメタモデル図は削除されている＞
• １ リージョン
❑ ７．０ 配備図
❑ ７．１ アーティファクトとノード
• １ アーティファクト ＜１０−０２＞
• ２ ノード ＜１０−０３＞、 ＜１０−０４＞
❑ ８．０ プロファイル
❑ ８．１ プロファイル
• １ プロファイル
• ２ エクステンション
• ３ ステレオタイプとメタモデル
• ４ プロファイル・アプリケーション
• ５ 他の概念
暫定版仕様書と最終盤仕様書の差異
出題範囲が定められた段階と最終版仕様書が決定された段階では、主にアクションモデルに関しメタモデル図の変更が多くみられます。
本講義では、最終版仕様書での定義を中心に講義を行ってゆきます。
なお、上の表で、プロファイルに関して、メタモデル図が参照されていないのは、プロファイルがメタモデル自身を作成するためのメカニズムを提供するためです。（先走って言いますと、メタメタモデルでの話題です。）
本日は、前回に引き続き、OCUPインタミディエート資格試験の出題範囲について解説したいと思います。
インターミディエート資格試験の出題範囲
インターミディエートの出題範囲は次のようになっています。
出題範囲サマリー （パーセント表示は、出題される問題の割合）
• ❑ 1.0 コンポジット構造図 １５％
• ❑ 2.0 コンポーネント図 １５％
• ❑ 3.0 アクションモデル １０％
• ❑ 4.0 アクティビティ図 １５％
• ❑ 5.0 インタラクション図 １５％
• ❑ 6.0 ステートマシン図 １５％
• ❑ 7.0 配備図 ５％
• ❑ 8.0 プロファイル １０％
メタモデルも出題範囲
ファンダメンタル資格試験とは異なり、インターミディエート資格試験では、出題範囲の詳細情報としてメタモデル図が指定されています。（ 表中の＜＞内の数字は、本書掲載のメタモデル図の番号）
また、問題作成時に試験範囲とされているメタモデル図が、２００５年の最終版仕様書では削除されていたり、変更が加わっているものがあります。本講座で使用しているメタモデルはあくまで最終版仕様書のものを採用しています。
これは、最終版の知識を身につけて試験に臨むべきであると言う考えに基づいています。
なお、すでに対象のメタモデル図が削除されているものや、大幅な変更が発生しているものについては、下記の出題範囲詳細のなかで＜＞内にコメントとして記入してあります。
（概念整理の過程で必要性が無くなったと判断されたものや、他のメタモデル図に吸収されてしまったものが該当します。個々のケースについて、暫定版からの変更の説明が必要と判断したものに関しては、各メタモデル図の解説の中で振れます。）
出題範囲詳細
❑ １．０ コンポジット構造図
❑ １．１ 内部構造
• １ 構造化分類子 ＜０９−０２＞
• ２ コネクタ ＜０９−０３＞
❑ １．２ ポートのモデリング
• １ ポート ＜０９−０４＞
• ２ コネクタ端 ＜同上図＞
❑ １．３ 構造化クラス
• １ クラス ＜０９−０５＞
❑ １．４ 呼び出しのモデリング
• １ アクション呼び出し ＜０９−０８＞
• ２ トリガー ＜同上図＞
❑ ２．０ コンポーネント図
❑ ２．１コンポーネントの基礎 ＜０８−０３＞、＜０８−０３＞
• １ コンポーネント
• ２ コネクタ
• ３ 実現
• ４ 他の概念
❑ ３．０ アクションモデル
❑ ３．１ アクション言語
• １ アクション呼び出し（Invocation Actions) ＜最終版仕様書では１１−０４と１１−０５の二つ＞
• ２ アクションの適用 (Apply Actions) ＜該当する図は、最終版仕様書から削除されている＞
• ３ オブジェクト・アクション (Object Actions) ＜１１−０６＞
• ４ 構造特性アクション (Structure Feature Actions) ＜１１−０７＞
• ５ リンク識別 (Link Identification) ＜１１−０８＞
• ６ リンク読み取りアクション (Read Link Actions) ＜１１−０９＞
• ７ リンク書き出しアクション (Write Link Actions) ＜１１−１０＞
• ８ 変数アクション (Variable Actions) ＜１１−１７ 最終版仕様書では大幅に変更＞
• ９ 他の概念
❑ ４．０ アクティビティ図
❑ ４．１ アクティビティ図
• １ オブジェクトノード ＜１２−０８＞
• ２ コントロール ＜１２−０９＞
• ３ パーティション ＜１２−１０＞
• ４ 他の概念
❑ ４．２ 構造化アクティビティ図 ＜１２−２１＞、＜１２−２２＞、＜１２−２３＞
• １ 構造化アクティビティノード
• ２ 条件ノード
• ３ ループノード
• ４ 他の概念
❑ ５．０ インタラクション図
❑ ５．１ インタラクション・フラグメント
• １ 結合フラグメント ＜１４−０７＞
• ２ ゲート ＜１４−０８＞
• ３ インタラクション・オカレンス ＜１４−０９ インタラクション・オカレンスは最終版仕様書ではインタラクション・ユースに名前を変更＞
• ４ 他の概念
❑ ６．０ ステートマシン図
❑ ６．１ ステートマシンの振る舞い ＜１５−０２＞
• １ 状態と有限状態
• ２ 疑似状態と終了状態
• ３ 遷移
• ４ コネクションポイント参照
• ５ ステートマシン
• ６ 他の概念
❑ ６．２ １リージョンのステートマシン ＜最終版仕様書ではメタモデル図は削除されている＞
• １ リージョン
❑ ７．０ 配備図
❑ ７．１ アーティファクトとノード
• １ アーティファクト ＜１０−０２＞
• ２ ノード ＜１０−０３＞、 ＜１０−０４＞
❑ ８．０ プロファイル
❑ ８．１ プロファイル
• １ プロファイル
• ２ エクステンション
• ３ ステレオタイプとメタモデル
• ４ プロファイル・アプリケーション
• ５ 他の概念
暫定版仕様書と最終盤仕様書の差異
出題範囲が定められた段階と最終版仕様書が決定された段階では、主にアクションモデルに関しメタモデル図の変更が多くみられます。
本講義では、最終版仕様書での定義を中心に講義を行ってゆきます。
なお、上の表で、プロファイルに関して、メタモデル図が参照されていないのは、プロファイルがメタモデル自身を作成するためのメカニズムを提供するためです。（先走って言いますと、メタメタモデルでの話題です。）
2006年4月6日木曜日
UML中級講座 第4回 OCUPインタミディエート試験
本日は、2003年より始まりましたOCUPインタミディエート試験について、その試験の特質を解説したいとおもいます。
1.4 OCUPインターミディエート試験
２００３年秋に始まったOCUP( OMG-Certified UML Professional)資格試験ですが、現在の時点で、合格基準点は次の様になっています。
ファンダメンタル資格試験 ４６問以上正解（８０問）： 正答率 57.5％ 以上
インターミディエート資格試験 ３１問以上正解（７０問）： 正答率 44.3% 以上
アドバンスト資格試験 ２９問以上正解 （５８問）： 正答率 50% 以上
この表に示されているように、インターミディエート資格試験が、最も合格基準が低く、最低合格ラインが５０％を下回っており、非常に低い状態にあります。（念のために申しますと、採点は減点法ではなく、不正解の選択肢を選択しても減点はされません。）数ある資格試験のうち、合格水準が５０％以下にあるというのは、極めて特殊な状態とも言えます。
高得点が難しい理由
これにはいくつかの要因が考えられますが、次に主なものをあげてみます。
1. UMLをモデル言語としてではなく、JAVAやC++等のプログラム実装言語と見なす、あるいはそのレベルの知識で受験する。
2. UML1.Xの範囲内の知識で受験する。
3. 市場に、受験のための教材があまり出回っていなかった。
4. OCUPの問題作成時期が、UML2.0の最終仕様確定以前に行われたために（最終仕様は上部構造（Superstructure)に関しては、2005年夏に確定）、試験範囲の逸脱や古いモデル図に基づくものなどが散見される。
試験対策について
まず、１についてですが、これはインターミディエート資格試験だけではなく、ファンダメンタル資格試験でも言える傾向です。
UMLは、第一義的には、分析・設計のためのモデリング言語であり、実装モデルも当然扱いますが、主眼は概念モデルやビジネスモデルなどの抽象度の高い領域に置かれています。
従って、実装モデル以外は、他の実装言語のようにコンパイルして動作を確かめるというようなことが出来ません。また、無理に実装言語と関連付けを行なって理解しようとする人もいますが、概念モデル以上への適用が難しくなってきます。（概念操作を習得できず、プログラミング上の便法の域から脱するのが困難）
単なる文法上の規約の暗記にとどまることなく、概念的モデルの習得と心得て、UMLを学習することが合格の早道であり、かつ、将来的にも有用な知識となります。問題の傾向としても、単純な文法規約を問う出題は少なく、むしろ概念的な問題が多いのがOCUP資格試験の特徴です。
２の「UML1.Xの知識で受験する」は、３で指摘した教材の不足とも大きく絡んだ問題です。
端的に言って、UML1.Xのレベルの知識での合格はたとえ合格基準が４５％であっても難しいと言わざるを得ません。UML2.0での変更部分は大きく、かつ本質的な部分が含まれています。
UML2.0の仕様書は、ページ数も多く（約７００ページ弱）、順番が必ずしも通読に適した順番には並んでいません。そして、UMLのツール開発者以外は読んでも意味のない部分が混在しており、UMLを使用する立場の人間にとっては、教材としてはあまり適当でないと言わざるを得ません。本講座が、これからUMLを学習し、そして使用して行こうという方々に、お役立ていただけることを願っております。
４の問題は、特にインターミディエート資格試験では、大きな影響があります。OMGの出題範囲として指定されているメタモデル図が、最終版では無くなっていたり、問題作成時の暫定版のメタモデル図と変わってしまっているものが、いくつもあります。この講座では、適切と考えられる場合には、最終版だけではなく暫定版仕様書での定義や解釈にも振れました。
しかしながら、実際問題として、過去の暫定版仕様書を深く勉強する意味はあまりありません。受験と言う目的のためであれば、１００点を取ろうとすることは無駄な努力とも言えます。あくまでも、基本を確実に押さえれば、たとえトリッキーな問題や、奇問・難問に答えられなくとも十分合格できる試験だと言うことを肝に銘じ、本質的な部分、概念操作や体系の理解を心がけてください。
実際の試験では当面の正答率６０％ぐらいに目標と定め（もちろん４５％以上あれば合格できますが、確実度を上げるため）、それ以上の得点を稼ぐくらいであれば、アドバンスト資格試験などの、より上位の学習に力を注ぐ方が望ましいと思います。
なおこの問題は、バージョンアップや標準の改正の時期にみられる過渡的なものであり、今後の試験問題の改訂のタイミングで解消されるものです。
1.4 OCUPインターミディエート試験
２００３年秋に始まったOCUP( OMG-Certified UML Professional)資格試験ですが、現在の時点で、合格基準点は次の様になっています。
ファンダメンタル資格試験 ４６問以上正解（８０問）： 正答率 57.5％ 以上
インターミディエート資格試験 ３１問以上正解（７０問）： 正答率 44.3% 以上
アドバンスト資格試験 ２９問以上正解 （５８問）： 正答率 50% 以上
この表に示されているように、インターミディエート資格試験が、最も合格基準が低く、最低合格ラインが５０％を下回っており、非常に低い状態にあります。（念のために申しますと、採点は減点法ではなく、不正解の選択肢を選択しても減点はされません。）数ある資格試験のうち、合格水準が５０％以下にあるというのは、極めて特殊な状態とも言えます。
高得点が難しい理由
これにはいくつかの要因が考えられますが、次に主なものをあげてみます。
1. UMLをモデル言語としてではなく、JAVAやC++等のプログラム実装言語と見なす、あるいはそのレベルの知識で受験する。
2. UML1.Xの範囲内の知識で受験する。
3. 市場に、受験のための教材があまり出回っていなかった。
4. OCUPの問題作成時期が、UML2.0の最終仕様確定以前に行われたために（最終仕様は上部構造（Superstructure)に関しては、2005年夏に確定）、試験範囲の逸脱や古いモデル図に基づくものなどが散見される。
試験対策について
まず、１についてですが、これはインターミディエート資格試験だけではなく、ファンダメンタル資格試験でも言える傾向です。
UMLは、第一義的には、分析・設計のためのモデリング言語であり、実装モデルも当然扱いますが、主眼は概念モデルやビジネスモデルなどの抽象度の高い領域に置かれています。
従って、実装モデル以外は、他の実装言語のようにコンパイルして動作を確かめるというようなことが出来ません。また、無理に実装言語と関連付けを行なって理解しようとする人もいますが、概念モデル以上への適用が難しくなってきます。（概念操作を習得できず、プログラミング上の便法の域から脱するのが困難）
単なる文法上の規約の暗記にとどまることなく、概念的モデルの習得と心得て、UMLを学習することが合格の早道であり、かつ、将来的にも有用な知識となります。問題の傾向としても、単純な文法規約を問う出題は少なく、むしろ概念的な問題が多いのがOCUP資格試験の特徴です。
２の「UML1.Xの知識で受験する」は、３で指摘した教材の不足とも大きく絡んだ問題です。
端的に言って、UML1.Xのレベルの知識での合格はたとえ合格基準が４５％であっても難しいと言わざるを得ません。UML2.0での変更部分は大きく、かつ本質的な部分が含まれています。
UML2.0の仕様書は、ページ数も多く（約７００ページ弱）、順番が必ずしも通読に適した順番には並んでいません。そして、UMLのツール開発者以外は読んでも意味のない部分が混在しており、UMLを使用する立場の人間にとっては、教材としてはあまり適当でないと言わざるを得ません。本講座が、これからUMLを学習し、そして使用して行こうという方々に、お役立ていただけることを願っております。
４の問題は、特にインターミディエート資格試験では、大きな影響があります。OMGの出題範囲として指定されているメタモデル図が、最終版では無くなっていたり、問題作成時の暫定版のメタモデル図と変わってしまっているものが、いくつもあります。この講座では、適切と考えられる場合には、最終版だけではなく暫定版仕様書での定義や解釈にも振れました。
しかしながら、実際問題として、過去の暫定版仕様書を深く勉強する意味はあまりありません。受験と言う目的のためであれば、１００点を取ろうとすることは無駄な努力とも言えます。あくまでも、基本を確実に押さえれば、たとえトリッキーな問題や、奇問・難問に答えられなくとも十分合格できる試験だと言うことを肝に銘じ、本質的な部分、概念操作や体系の理解を心がけてください。
実際の試験では当面の正答率６０％ぐらいに目標と定め（もちろん４５％以上あれば合格できますが、確実度を上げるため）、それ以上の得点を稼ぐくらいであれば、アドバンスト資格試験などの、より上位の学習に力を注ぐ方が望ましいと思います。
なおこの問題は、バージョンアップや標準の改正の時期にみられる過渡的なものであり、今後の試験問題の改訂のタイミングで解消されるものです。
2006年4月5日水曜日
UML中級講座 第3回 モデル図の拡張
1.3 モデル図の拡張
UML2.0では、従来からあったモデル図に対しても変更が加わり、表現的にもセマンティック的にも拡張されています。本日は、これらのモデル図に加えられた拡張を概観してみます。
クラス図
単なる直感的な便法から、より概念的な一貫性を持った表現に変わりました。従来のバージョンでは、属性と関連は異なるものとされていましたが、UML2.0では、属性は、一方向の誘導可能性を持った関連と等価であると再定義されました。また、コンポジット構造図の登場に伴い、ポート、パートなど内部構造を記述するためのエレメントが追加されました。
インターフェースに関しても、従来は提供インターフェースのみであったのに対し、新たに要求インターフェースが付け加わり、さらに両インターフェースが接続された状態（アセンブリー・コネクタ）もコンポーネント図で使用されるようになりました。
また、多重度表現として従来許されていた”２,４,６” といった離散的表現がUML2.0では、認められなくなりました。
さらに、ステレオタイプの定義が厳密になり、ユーザーによる拡張の方法が提供されます。（プロファイル参照）
アクティビティ図
UML1.Xでは、アクティビティ図は、ステートマシン図とほとんど同じような扱いでしたが、UML2.0では、状態の遷移ではなく、トークンの流れとしてフローが独立して定義されました。また、アクションノードの形状が変わり、角の丸い四角形となりました。
従来、フォークとジョインは必ずペアで使用しなければならないなど、文法的制約の多かった記法が改められ、フォークノード、ジョインノード等すべてのアクティビティノードにそれぞれ固有の振る舞いが定義されて、単独で扱うことが可能になりました。（従来の文法は、構造化プログラミングの流れに沿うもので、アルゴリズムを表現する上では、極めて有益な（文法上の）制約でしたが、アクティビティ図の現実の使われ方は、初学者を除けばプログラミング・ロジックの表現に使われることはむしろまれで、圧倒的に業務フローの記述に使用されていることから、この制約は排除され、より自由な表現が可能となりました。）
トークンの流れも、UML1.Xでは、複数入力を暗黙的なマージとして扱っていたのに対し、暗黙的なジョインとして扱うように改訂されました。しかしながら、暗黙的な表現では誤解を招きやすいため、複数入力は、マージノードもしくはジョインノードを使用した明示的な記法が望ましいでしょう。ツールによっては、暗黙的な表現が許されないケースもあります。（これはあくまでツールが採用した制約であって、UMLの制約ではありません。）
また、シグナルの送受信、タイムイベント、パラメータ、パラメータセット、ピンなどの記法が拡張され、さらに、データストア、セントラルバッファーノードなど、業務フローを記述する際に有用なオブジェクトノードが付け加わりました。
従来からあったスイムレーンは多次元に拡張され、名前もパーティションに変更されました。
いずれの変更も、アクティビティ図が、プログラムのアルゴリズムを記述すると言ったミクロ的な使い方よりも、業務フローやビジネスモデルと言ったマクロ的な使用方法が圧倒的に多いという現状を踏まえた拡張と言えるでしょう。
シーケンス図
UML1.Xでは、生存線（ライフライン）のヘッダーは、オブジェクトに代表されるインスタンス表現でしたが、より一般的な形に変更され、参加者（participant)と呼ばれるようになりました。そして、結合フラグメントの採用により、並列処理、条件分岐、繰り返しなどの表現が出来るようになりました。
ステートマシン図
UML1.Xでは、継続時間の差から、アクション（継続期間が短い）とアクティビティ（継続期間が長い）という２種類を使い分けていましたが、UML2.0では、どちらもアクティビティと呼ぶようになりました。
UML2.0では、従来からあったモデル図に対しても変更が加わり、表現的にもセマンティック的にも拡張されています。本日は、これらのモデル図に加えられた拡張を概観してみます。
クラス図
単なる直感的な便法から、より概念的な一貫性を持った表現に変わりました。従来のバージョンでは、属性と関連は異なるものとされていましたが、UML2.0では、属性は、一方向の誘導可能性を持った関連と等価であると再定義されました。また、コンポジット構造図の登場に伴い、ポート、パートなど内部構造を記述するためのエレメントが追加されました。
インターフェースに関しても、従来は提供インターフェースのみであったのに対し、新たに要求インターフェースが付け加わり、さらに両インターフェースが接続された状態（アセンブリー・コネクタ）もコンポーネント図で使用されるようになりました。
また、多重度表現として従来許されていた”２,４,６” といった離散的表現がUML2.0では、認められなくなりました。
さらに、ステレオタイプの定義が厳密になり、ユーザーによる拡張の方法が提供されます。（プロファイル参照）
アクティビティ図
UML1.Xでは、アクティビティ図は、ステートマシン図とほとんど同じような扱いでしたが、UML2.0では、状態の遷移ではなく、トークンの流れとしてフローが独立して定義されました。また、アクションノードの形状が変わり、角の丸い四角形となりました。
従来、フォークとジョインは必ずペアで使用しなければならないなど、文法的制約の多かった記法が改められ、フォークノード、ジョインノード等すべてのアクティビティノードにそれぞれ固有の振る舞いが定義されて、単独で扱うことが可能になりました。（従来の文法は、構造化プログラミングの流れに沿うもので、アルゴリズムを表現する上では、極めて有益な（文法上の）制約でしたが、アクティビティ図の現実の使われ方は、初学者を除けばプログラミング・ロジックの表現に使われることはむしろまれで、圧倒的に業務フローの記述に使用されていることから、この制約は排除され、より自由な表現が可能となりました。）
トークンの流れも、UML1.Xでは、複数入力を暗黙的なマージとして扱っていたのに対し、暗黙的なジョインとして扱うように改訂されました。しかしながら、暗黙的な表現では誤解を招きやすいため、複数入力は、マージノードもしくはジョインノードを使用した明示的な記法が望ましいでしょう。ツールによっては、暗黙的な表現が許されないケースもあります。（これはあくまでツールが採用した制約であって、UMLの制約ではありません。）
また、シグナルの送受信、タイムイベント、パラメータ、パラメータセット、ピンなどの記法が拡張され、さらに、データストア、セントラルバッファーノードなど、業務フローを記述する際に有用なオブジェクトノードが付け加わりました。
従来からあったスイムレーンは多次元に拡張され、名前もパーティションに変更されました。
いずれの変更も、アクティビティ図が、プログラムのアルゴリズムを記述すると言ったミクロ的な使い方よりも、業務フローやビジネスモデルと言ったマクロ的な使用方法が圧倒的に多いという現状を踏まえた拡張と言えるでしょう。
シーケンス図
UML1.Xでは、生存線（ライフライン）のヘッダーは、オブジェクトに代表されるインスタンス表現でしたが、より一般的な形に変更され、参加者（participant)と呼ばれるようになりました。そして、結合フラグメントの採用により、並列処理、条件分岐、繰り返しなどの表現が出来るようになりました。
ステートマシン図
UML1.Xでは、継続時間の差から、アクション（継続期間が短い）とアクティビティ（継続期間が長い）という２種類を使い分けていましたが、UML2.0では、どちらもアクティビティと呼ぶようになりました。
2006年4月4日火曜日
UML中級講座 第2回 UML2.0でのモデル図の入れ替え
UML2.0では、従来のUMLで定義されていたモデル図に関して、入れ替えが発生しています。
本日は、その入れ替えについて、解説します。
1.2 モデル図の入れ替え
コラボレーション図の変更
UML1.Xの時代に、特に実装モデルのレベルで使われることの多かったコラボレーション図が、コミュニケーション図と名前を変え、また扱いが非常に軽くなりました。
これは、コラボレーション図の内容がシーケンス図で等価に記述できる上に、さらにシーケンス図の方が、より柔軟に情報の追加、機能の拡張ができ、また実際の使用者の数がコラボレーション図よりも多かったことに因ります。
そして、従来のコラボレーション図とは全く異なる図が新たに付け加えられ、この図がコラボレーション図と呼ばれることになりました。
この図は、OCUPのアドバンス資格試験で扱われるため、本コースではあまりふれませんが、オブジェクトやクラスよりも、役割パターンに焦点を置いたものです。
また、シーケンス図自身も拡張され、従来はオブジェクトなどのインスタンスレベルでのメッセージのやり取りのみを扱っていたものから、より広範なレベルでインタラクション（相互作用）を扱えるようになりました。
オブジェクト図とパッケージ図の追加
オブジェクト図とパッケージ図は、以前から使われており、非常にポピュラーな図でしたが、UML1.Xでは非公式な扱いでした。UML2.0では、この２つの図を取り入れ、特にパッケージ図に関しては、スーパーストラクチャ（上部構造）、インフラストラクチャ（基盤構造）の両方の仕様文書で重要な役割を演じるようになりました。
コンポジット構造図の登場
従来のクラス図等では記述が難しかった内部構造が、コンポジット構造図の登場により、容易に記述できるようになりました。これは、単にクラス図が拡張されただけではなく、構造化分類子の導入に伴い、分類子が登場する他の図においても内部構造が記述できることになります。
インタラクション概要図、タイミング図の登場
インタラクション概要図は、インタラクション図とアクティビティ図が合成された図です。また、タイミング図は、特に組み込み系などのハードウエア開発で要望の高かった表現形式です。これらは、実際のニーズが仕様に取り入れたものです。
本日は、その入れ替えについて、解説します。
1.2 モデル図の入れ替え
コラボレーション図の変更
UML1.Xの時代に、特に実装モデルのレベルで使われることの多かったコラボレーション図が、コミュニケーション図と名前を変え、また扱いが非常に軽くなりました。
これは、コラボレーション図の内容がシーケンス図で等価に記述できる上に、さらにシーケンス図の方が、より柔軟に情報の追加、機能の拡張ができ、また実際の使用者の数がコラボレーション図よりも多かったことに因ります。
そして、従来のコラボレーション図とは全く異なる図が新たに付け加えられ、この図がコラボレーション図と呼ばれることになりました。
この図は、OCUPのアドバンス資格試験で扱われるため、本コースではあまりふれませんが、オブジェクトやクラスよりも、役割パターンに焦点を置いたものです。
また、シーケンス図自身も拡張され、従来はオブジェクトなどのインスタンスレベルでのメッセージのやり取りのみを扱っていたものから、より広範なレベルでインタラクション（相互作用）を扱えるようになりました。
オブジェクト図とパッケージ図の追加
オブジェクト図とパッケージ図は、以前から使われており、非常にポピュラーな図でしたが、UML1.Xでは非公式な扱いでした。UML2.0では、この２つの図を取り入れ、特にパッケージ図に関しては、スーパーストラクチャ（上部構造）、インフラストラクチャ（基盤構造）の両方の仕様文書で重要な役割を演じるようになりました。
コンポジット構造図の登場
従来のクラス図等では記述が難しかった内部構造が、コンポジット構造図の登場により、容易に記述できるようになりました。これは、単にクラス図が拡張されただけではなく、構造化分類子の導入に伴い、分類子が登場する他の図においても内部構造が記述できることになります。
インタラクション概要図、タイミング図の登場
インタラクション概要図は、インタラクション図とアクティビティ図が合成された図です。また、タイミング図は、特に組み込み系などのハードウエア開発で要望の高かった表現形式です。これらは、実際のニーズが仕様に取り入れたものです。
2006年4月3日月曜日
UML中級講座 開始！（OCUPインタミディエート対応）
本日より、UMLの中級講座を開始します。 内容的には、OMGが主催しているOCUPインタミディエート資格試験に対応しています。
UMLは、 オブジェクト指向テクノロジーの核になる部分であり、また昨年OMGとBPMI(ビジネス・プロセス。マネジメント・イニシアティブ）が合併し、ビジネス モデリング分野でもキーとなる概念です。
機は熟しました。今から始めても決して遅くはありません。
今後、次の内容で、各 章を何回かに分けて順番にアップロードして行く予定です。
アジェンダ（予定）
第１章 UML2.0の新機能と、OCUPインタミディエート試験
第２章 メタモデル構造の理解
第３章 複合構造図
第４章 コンポーネント図
第５章 アクション
第６章 アクティビティ図
第７章 相互作用図
第８章 ステートマシン図
第９ 章 配備図
第10章 プロファイル
上記は、あくまでも予定ですので今後変わることもあります。それでは、第一章からスタートしま しょう。
１章 UML 2.0の新機能と、OCUPインターミディエート試験
1.1 UML 2.0での新機能ポイント
UML2.0 は、従来のUML1.X( 1.0 ~ 1.5までのバージョンを総称するときに、1.Xという記法をします。以下同様）に比べ、見た目も解釈も大きく異なってきています。
•UML2.0 の特徴は、なんといっても、MDA（モデル・ドリブン・アーキテクチャー）の採用に伴う、構造の厳密化、最適化にあります。
そして、メタモデル図 が大幅に変更されました。また、これに伴って、従来から問題となっていた解釈の曖昧さの解決も図られています。
さらに、従来のUMLで用いられた 図を見直し、重要度に応じて一部の図を入れ替え、全体として分析や設計などの概念モデルに関する拡張、パターンや役割に焦点を置いた機能面の追加がはから れています。
•従前のUML1.Xでは、解釈に直感的な部分が多く、また各リリース間、たとえば1.2から1.3へのリリースアップなど で、省略時解釈が１８０度反転してしまう等のことが何度か重なった結果、モデル図の解釈が人やグループによって異なってしまい、本来正確なコミュニケー ション手段として採用したはずのUMLが、かえって組織全体の記法として曖昧さが増大してしまったという深刻な問題を生み出して来ました。
さら に、異なるUMLツール間では事実上、情報の共有、交換が不可能といった事態も招きました。
UML2.0では、この問題を、UML自身の構造と振 る舞いを規定するメタモデル図の厳密化と、数学的ともいえる一貫した体系化、そして振る舞いを最小単位で定義し直すと言う作業で解決してきました。
• 以前から、UML図は単なるモデル表現の共通言語としての絵（図表）として使われるだけではなく、コードの自動生成などの機能を持った開発ツールにより使 用されて来ましたが、UML2.0になってMDAの考え方が積極的に採用されたことで、その動きがさらに加速されました。
2.0では、自動コード 生成だけではなく、１つの図から他の種類の図への自動変換や、ツール間のモデリング情報の交換を図るためのメカニズム、仕様が開発されています。
別 の見方をしますと、本来の分析・設計のためのモデル記述言語としての拡張を図りつつ、同時にプログラミング言語への拡張を行ったとも言えます。
2006 年4月 3日
UMLは、 オブジェクト指向テクノロジーの核になる部分であり、また昨年OMGとBPMI(ビジネス・プロセス。マネジメント・イニシアティブ）が合併し、ビジネス モデリング分野でもキーとなる概念です。
機は熟しました。今から始めても決して遅くはありません。
今後、次の内容で、各 章を何回かに分けて順番にアップロードして行く予定です。
アジェンダ（予定）
第１章 UML2.0の新機能と、OCUPインタミディエート試験
第２章 メタモデル構造の理解
第３章 複合構造図
第４章 コンポーネント図
第５章 アクション
第６章 アクティビティ図
第７章 相互作用図
第８章 ステートマシン図
第９ 章 配備図
第10章 プロファイル
上記は、あくまでも予定ですので今後変わることもあります。それでは、第一章からスタートしま しょう。
１章 UML 2.0の新機能と、OCUPインターミディエート試験
1.1 UML 2.0での新機能ポイント
UML2.0 は、従来のUML1.X( 1.0 ~ 1.5までのバージョンを総称するときに、1.Xという記法をします。以下同様）に比べ、見た目も解釈も大きく異なってきています。
•UML2.0 の特徴は、なんといっても、MDA（モデル・ドリブン・アーキテクチャー）の採用に伴う、構造の厳密化、最適化にあります。
そして、メタモデル図 が大幅に変更されました。また、これに伴って、従来から問題となっていた解釈の曖昧さの解決も図られています。
さらに、従来のUMLで用いられた 図を見直し、重要度に応じて一部の図を入れ替え、全体として分析や設計などの概念モデルに関する拡張、パターンや役割に焦点を置いた機能面の追加がはから れています。
•従前のUML1.Xでは、解釈に直感的な部分が多く、また各リリース間、たとえば1.2から1.3へのリリースアップなど で、省略時解釈が１８０度反転してしまう等のことが何度か重なった結果、モデル図の解釈が人やグループによって異なってしまい、本来正確なコミュニケー ション手段として採用したはずのUMLが、かえって組織全体の記法として曖昧さが増大してしまったという深刻な問題を生み出して来ました。
さら に、異なるUMLツール間では事実上、情報の共有、交換が不可能といった事態も招きました。
UML2.0では、この問題を、UML自身の構造と振 る舞いを規定するメタモデル図の厳密化と、数学的ともいえる一貫した体系化、そして振る舞いを最小単位で定義し直すと言う作業で解決してきました。
• 以前から、UML図は単なるモデル表現の共通言語としての絵（図表）として使われるだけではなく、コードの自動生成などの機能を持った開発ツールにより使 用されて来ましたが、UML2.0になってMDAの考え方が積極的に採用されたことで、その動きがさらに加速されました。
2.0では、自動コード 生成だけではなく、１つの図から他の種類の図への自動変換や、ツール間のモデリング情報の交換を図るためのメカニズム、仕様が開発されています。
別 の見方をしますと、本来の分析・設計のためのモデル記述言語としての拡張を図りつつ、同時にプログラミング言語への拡張を行ったとも言えます。
2006 年4月 3日
登録:
投稿 (Atom)