UML中級講座 第40回 コネクタの表記

本日は、コンポーネント図中で用いられるコネクタの表現方法について解説します。

コネクタの表記

委譲コネクタ

図G12

委譲コネクタは、図G12で示されるように、ソース側ポートからターゲット側のパートに向けて引かれます。要求インターフェース（またはポート）の場合は、向きが逆になります。

アセンブリコネクタ

図G１３

アセンブリコネクタは、提供インターフェースと要求インターフェースが噛み合った形で表現されます。図G13は、「オーダー」と「製品」という二つのコンポーネントが、OrderableItemと言うインターフェースを使って接続される様を描いています。

図G14

複雑なコンポーネント図を表すために、アセンブリコネクタを、個々に描くのではなくまとめて表示することも認められています。（図G14参照）

UML中級講座 第39回 コンポーネント図のコネクタ

４−２−２ コネクタ

コンポーネント図で用いるコネクタは、複合構造図のコネクタを元に拡張し、次の二種類があります。

委譲コネクタ

委譲コネクタは、外部の契約（ポートにより規定される）と、コンポーネントの内部のパートにより実現される振る舞いとを結びつけます。
委譲コネクタは、ポートに到着したシグナル（操作（オペレーション）の要求やイベント）を、ターゲットに転送します。

アセンブリコネクタ

アセンブリコネクタは、二つのコンポーネント（サービスの要求側コンポーネントと提供側コンポーネント）の間を結びつけます。
アセンブリコネクタは、提供インタフェース（もしくはポート）と要求インターフェース（もしくはポート）を結びつけます。

委譲コネクタは別の見方をしますと、コンポーネントの振る舞いはコンポーネント自体が実現しているのではなく、他の互換性を持つものによって実現していると言う宣言とも言うことが出来ます。

また、委譲コネクタは、内部の複数のコンポーネント、複数のポートに接続することがでます。
そして、シグナルは内容に応じて適切な経路が選択され転送されます。

UML中級講座 第38回 コンポーネントの拡張

本日は、第35回、36回で取り上げた、ストア コンポーネントを題材に、インターフェースを用いたコンポーネントの拡張について議論しましょう。

コンポーネントの拡張

図G11 ストア コンポーネントの拡張

図G11は、図G08のストア コンポーネントを、インターフェースを利用して拡張したものです。
OrderableItemインタフェースを経由して製品のほかにサービスが加わり、人インターフェースを利用して顧客や組織ともインタラクションが発生します。
人インターフェースの条件が守られる限り、相手は顧客などの自然人に限らず、組織などの法人もコミュニケーションが可能である点に注意してください。
（インターフェース条件さえ合致すれば、どのようなコンポーネント間の接続も可能です。）

図G08（拡張前）

UML中級講座 第37回 PIM型表現

本日はPIM、プラットフォーム独立モデリング型、表現を見て行きたいと思います。


PIM（プラットフォーム独立モデリング）型表現
図G10

図G10では、コンポーネントのインターフェース間をアセンブリコネクタではなく依存関係で結んでおり、PIM（プラットフォーム独立モデリング）型の表現と呼ばれます。
また、図G09では、この三つのコンポーネント間の一般的な依存関係が示されています。
図G09

インターフェースは、直接的か、（ポートを経由した）間接的かによらず、何らかの上位のコンポーネントの特性を継承した場合があります。その場合、インターフェース名の前に’／’を付けて表します。図G10の/orderedItem は、コンポーネント「製品」の上位のコンポーネント（スーパークラス）を継承していることを意味しています。

UML中級講座 第36回 コンポーネントの理解（続き）

前回（第35回）の最後に示しました図Ｇ０８について、引き続き解説をして行きたいと思います。

コンポーネントの中のコンポーネント

図Ｇ０８ ストア コンポーネント

図G08はコンポーネントの中にコンポーネントが入れ子になっている状態を表しています。
この図では、オーダー、顧客、 製品の3つのコンポーネントはパート名が省略されています。
また、提供インターフェースと要求インターフェースは、通常では依存関係で結びますが、それをかみ合わせた形で表現されていて、間の依存関係を示す波線矢印がない表現があります。（形状としては図G01の(d))

これをアセンブリコネクタと呼びます。
ポートとパートのインターフェース間に、＜＜ delegate ＞＞というステレオタイプがついたコネクタがありますが、これを委譲コネクタと呼びます。（意味するところは、コンポーネントのインターフェースの実現の権限を別の分類子に委譲するというところから来ています。）

「ダ・ビンチ・コード」とUML

本日は、今話題の映画「ダ・ビンチ・コード」とUMLの関係（？）についてお話しましょう。

「ダ・ビンチ・コード」の小説の重要なモチーフの１つに、西洋文明の根底に流れるシンボリズム、紋章学の伝統があります。
このシンボリズムの起源は、キリスト教誕生のはるか以前、古代エジプト文明、メソポタミア文明にまで遡ります。
小説中、教会の構造が黄金分割で構成されている云々、の話が出てきますが、この黄金分割や五芒星の問題は、紀元前500年ごろのギリシャの数学者ピタゴラスにより既に知られていました。


また、現在、十字クロスは、キリスト教の専売特許の様な状態になっていますが、キリスト教誕生以前の紀元前5000年ごろのエジプトにおいて、既に、（キリスト教の十字架とは全く異なる意味で）、神聖なシンボルとして使用されていました。

ちなみに、クロスは、ヨーロッパ人にとっては、かなりメッセージ性の強い図形であるようです。
先日、二人のフランス人が日本を訪れた折、筆者は彼らを湯河原にある古風な温泉旅館に連れて行きました。
時代劇に出てきそうな佇まいの旅館に彼らは大喜びで、翌日は京都に行くべく、車で熱海に向かっておりました。
ところが、街角の交差点を曲がったあたりで、彼らは突然無言となり、車内に異様な緊張感が走りました。まるで、空気が凍ってしまった様です。
私は、驚いて、どうしたんだと聞くと、一人が前方を指さして、あれはなんだと訪ねました。見ると、そこにはお寺の所在を示す「卍（まんじ）」のマークがありました。
彼らにとっては、この鉤十字の記号は極めて不気味なシンボルだった様です。二人とも戦後生まれで、直接ナチスドイツを見聞きしたことはないのですが、私は、彼らの反応に驚きました。
ヨーロッパでは、法律や社会的コンセンサスにより、鉤十字の使用が禁止されている国が多いそうです。


キリスト教以外の分野でも、シンボリズムは大きな影響を与えています。
有名な秘密結社フリーメーソンは、元々は石工の同業者組合を意味し、職業柄、幾何学の造詣が深く、あちこちに謎めいた記号を残しています。
一ドル紙幣に描かれるピラミッドと目の記号は、フリーメーソンのシンボルだと言われています。


さて、UMLの話題に戻りましょう。UMLは、ご存知の通り、図形をシンボルとして使用する言語です。そして、シンボリズムの影響は、陰に日なたに表れています。版を重ねる度に、むしろ、その影響は洗練された形で強まっているように思えます。
一例を挙げてみましょう。下の図は、シーケンス図の例です。この図の左上隅の表題部分は、五角形が描かれ、その中にインタラクション名（UserAccepted)が記されています。
五角形は、元来、生命体などの生き生きとした動きを象徴する図形として知られ、UMLで用いられる五角形は対象の振舞いを表象していると言われています。

UML中級講座 第35回 コンポーネントの理解

４ー２ コンポーネントの理解


４−２−１ 役割レベルのコンポーネント図

先に述べましたようにコンポーネントはカプセル化クラスのサブクラスであり、内部にコラボレーションを表現できます。
そして、インスタンスレベルでの詳細化や、パートやコネクタを使用して役割レベルでの記述が可能です。
例えば、パート名を明示することで、一つの分類子が、複数の役割を演じる様を表現することが可能です。
コラボレーションに基づくコンポーネント表記をすることで（つまり構造化分類子であることにより）以下の表現が可能になります。

１. 1つの分類子から複数のインスタンスを生成

1つの分類子が複数のパート（役割）を演じる

1つの関連が複数のコネクタを演じる

２．インスタンスレベルでの表現が可能（インスタンススペシフィケーション）


図G08

UML中級講座 第34回 コンポーネントの表現

東京では、5月初頭から梅雨入りしたかの様な空模様が続きます。
青空が恋しい今日この頃、いかがお過ごしですか？ 

コンポーネントの振る舞いを実現する内部の分類子を表現する方法としては、依存関係を用いることも出来ます。

図G０６

図G06は、コンポーネント「Customer」の振る舞いを実現するための3つの分類子、CustomerImple、CostomerColl、CustomerDefが依存関係でコンポーネントと結ばれています。これらの分類子は、コンポーネントの長方形の箱の中に記述することも可能です。

図G０７

図G07は、コンポーネント「オーダー」を構成する2つのクラス「オーダー見出し」と「オーダー項目」を内部に記述し、この二つの間にある関係コンポジット集約を表現しています。

UML中級講座 第33回 コンポーネントの内観表現

雨の日が続きますが、いかがお過ごしですか？
前回までは、外観表現について解説しましたが、本日は内観表現（ホワイトボックス表現）について、議論したいと思います。

内観表現（ホワイトボックス表現）

コンポーネントは、ブラックボックス表記のほかに、内部のプロパティやインターフェースを実現する分類子を表記したホワイトボックス表記が可能です。
このホワイトボックス図では、外部の振る舞いが、内部でどのように実現されているかを表現します。
なお、外部と内部の関係づけは、従属関係やコネクタで表現されます。

図G0５

図G０５はホワイトボックス表現の例です。コンポーネントの内部構造を示したもので、「OderEntry」「人」などのインターフェースを示す以外に、内部を構成するプロパティ（この図では、「オーダー見出し」や「オーダー項目」）や、このコンポーネントを具現化するための成果物（この図では、Order.Jar）（注）などが記述されています。

図G05に示される各区画は、コンパートメントと呼ばれ、パートやコネクタ、そして成果物を記入することが可能です。

（注： 成果物（Artifact）は配備図のところで詳しく触れます。）

UML中級講座 第32回 インターフェース

コンポーネントには欠かせないインターフェースの表現について見て行きます。
インターフェースは、ご存知の通り分類子の一種ですので、分類子を表象する四角形で表すことができ、その際、ステレオタイプ ＜＜ interface ＞＞を使用してインターフェースであることを宣言します。
インタフェースを、単にボール（提供インターフェース）やソケット（要求インターフェース）の記号で表すと詳しい情報が書き切れない場合には、この分類子の四角形を用いて表します。
図G04は、インターフェースの表現例です。 「OrderEntry」は提供インターフェース、「人」は要求インターフェースを表しています。

図G04

この図では、２つのインターフェースと真中の「オーダー」クラスの関係を示す図形として、2種類の矢印が使用されています。
通常、クラスの提供インターフェースはクラス自身が実装することに責任を持ち、実現の関係を示す白抜きの矢を持つ破線で示され（図中の「OrderEntry」と「オーダー」間の記号）、それに対し、要求インターフェースは、他のクラスによって実現されたインターフェースを使うだけの関係ですので、依存関係＜＜Use＞＞で結びます。
また、それぞれのインターフェースには、オペレーションが記述されていますが、この形式も、外観表現（ブラックボックス表現）の一種です。

UML中級講座 第31回 コンポーネントの外観表現

昨日に引き続き、コンポーネントの外観表現（External View)について見て行きたいと思います。


外観表現（ブラックボックス表現）

図G02

ブラックボックス表現とは、可視性がパブリックであるプロパティや操作（オペレーション）のみを、表示するものです。
また、オプションとして、コンポーネントの外観をより詳細に記述する為に、インターフェース、ポートあるいはコンポーネントそれ自体に、プロトコルステートマシン等で振る舞いを指定することも可能です。

図G03

図G02はブラックボックス表現ですが、図G03もブラックボックス表現です。（拡張性の為に、ツールによってはこのリスト形式のみをサポートしている場合もあります。）

UML中級講座 第30回 コンポーネントの表記

本日は、コンポーネントの表記法について、解説致します。

４−１−２ コンポーネントの表記

図G01

コンポーネントの表記法は、従来からのUML1.Xでの書き方とは異なっています。
コンポーネントは基本的にクラスの一種ですので分類子を表す四角形を用い、その中にステレオタイプ ＜＜Component＞＞ を記入して表現されます。
また、オプションとして、従来使用してたコンポーネントのアイコンを、四角形の右上に記入して、表示することも出来ます。
図G01の (a) は、コンポーネントの表示例です。
図(a)は、要求インターフェースをポートなしに一つ持つコンポーネントを表しています。
図(b)は、ポート経由で一つの提供インターフェースを持つコンポーネントを表し、図(c)では、一つのポートに3つの提供インターフェースが接続されています。
図(a) (b) (c)に示されているように、ポートは省略可能です。
なお、この表現は、コンポーネントの内部情報を示さないので、外観表現（External View ) もしくはブラックボックス表現と呼ばれます。

UML中級講座 第29回 第4章 コンポーネント図

本日から、第4章コンポーネント図に入って行きます。
初回の今日は、コンポーネント図の概要についてお話致します。

第4章 コンポーネント図
４−１ コンポーネント図概要

４−１−１ コンポーネントとは

コンポーネントは、単純なものから複雑なものまで、様々な規模のシステムを規定することが出来ます。
コンポーネントは、第3章で扱ったカプセル化クラスを継承します（サブクラスです）。
つまり、ポートやインターフェースを用いて内部構造を持つことが可能です。
そして、コンポーネントは、構造化分類子と同様に、インターフェースの規定する条件さえ合えば、どのような環境下でも活動することが可能です。
逆に言いますと、構造化プログラミングが一般的になる以前の、スパゲッティのようにこんがらがったソフトウエアの内部構造を記述するには不向きともいえます。
これは、コンポーネントという概念そのものに、モジュラー構造が前提としてあり、オブジェクト指向開発の根本概念にカプセル化あるいは情報隠蔽があることからも、当然の帰結といえます。

また、現在のシステム開発の前提として、契約に基づく開発（CBD: Contract Based Development)の考え方ありますが、その2つのスローガン、「変更はクローズに」と「拡張はオープンに」を忠実に再現するための手段という位置づけもあります。

CBD(契約に基づく開発）
▼ ❑ 「変更はクローズに」：
変更は内部だけで行い、外部環境に影響を及ぼしてはならない
▼ ❑ 「拡張はオープンに」：
拡張は外部環境に対し、上位互換性を保つ形で行う

コンポーネントは大きく分けて2種類あり、1つは論理的コンポーネント（ビジネスコンポーネント、プロセスコンポーネント）で、もう一つは物理的コンポーネント（EJBコンポーネント、CORBAコンポーネント、.NETコンポーネント等々）です。
通常これら二種類のコンポーネントを混在させて使うことはなく、論理的コンポーネントは主にシステム開発の上流工程やビジネスモデリングに用いられ、物理的コンポーネントは、実装モデルの設計段階で主に作成されます。
また、コンポーネントは内部に、数多くのステート（状態）や振る舞いを持つ分類子を包含します。
そして、インターフェースを通じて顧客側にサービスを提供したり、またサービスを受け取ったりします。
さらに、インターフェースの条件さえ満たせば、設計時もしくは実行時にコンポーネントを交換することが可能です。（上位互換性）

UML中級講座 第28回 カプセル化クラス

本日は、第3章 「複合構造図」の最後のセクションです。
実際の構造図で最もよく使用されるカプセル化クラスを定義します。
また、ポートに設定出来るトリガーと、呼び出しアクションの関係を示すメタモデルを紹介します。

３−３−４ カプセル化クラス

図０９−０５

カプセル化分類子が持つポートを所有する性格を継承したクラスです。
複合構造図中のクラスは、この形で拡張されており、ポートを持つことが可能です。
定義はいたって簡単で、前回解説しましたカプセル化分類子を単にクラスに特化したものになります。


３−３−４ 呼び出しアクションとトリガー

図０９−０８

トリガーは、特定の振る舞いを呼び出すきっかけとなるイベントを意味します。
ポートに対し指定することができます。

UML中級講座 第27回 ポートのメタモデル

本日は、ポートのメタモデル図についてです。
通常の複合構造図でよく使用するカプセル化クラスは、特化の階層で言うと、
分類子 → 構造化分類子（第25回で解説） → カプセル化分類子（本日解説）→ カプセル化クラス
の順で、特化されて行きます。

そして、構造化分類子とカプセル化分類子の違いは、一言で言うと「ポートを持つ」という性質があるか無いかの差です。

３−３−３ ポート

図０９−０４

ポートを持つ分類子をカプセル化分類子（EncapsulatedClassifier)と呼びます。ポートを所有する性質以外は、元の構造化分類子と全く同じです。ポートには、インターフェースを付けることが可能です。

UML中級講座 第26回 コネクタのメタモデル図

昨日に引き続いて、コネクタのメタモデル図を見て行きましょう。
メタモデル図を学習する上で一つ厄介な点は、１つずつの図が完結しているわけではなく、
お互いに参照し合って全体を構成している点です。
そのために初めて学ぶ人にとっては、未知の概念が次々に出てきて、それを説明するメタモデル図について、ものによっては、かなり後で学習することになる点です。

この傾向は、メタモデル図だけの問題ではなく、オブジェクト指向型設計・分析においては、高度なものになるにつれてその傾向が顕著になってきます。
（注： 通常のモデル図では、全体像を把握する上で、デザインパターンに関する知識が強力なツールになります。）

従って、始めのうちは、あまり詳細にとらわれず、大まかなポイントだけを押さえて行き、後で全体を見直す、と言うアプローチで臨む方が良いと思います。

３ー３ー２ コネクタ

図０９−０３

コネクタは、両端にコネクタ端を持ち多重度指定が可能であるとともに、各コネクタ端は、ポートやパートなどのプロパティと関連を持ちます。
また、コネクタは、場合により関連（Association）を意味することもあります。 （昨日触れましたように、ConnectableElementはコラボレーションと関係付けるために使用されています。）

UML中級講座 第25回 複合構造図のメタモデル

ゴールデンウイークは、いかがでしたか？ 本日より職場復帰の方も多いと思います。
今回から、複合構造図のメタモデル図を解説して行きたいと思います。
メタモデル図は、最初は取っ付き難いのですが、徐々に勘所が分かってくると思います。
最初のうちはピンと来なくても、一部分だけでも分かれば良いと言うつもりで、眺めて見てください。


３ー３ 複合構造図のメタモデル
３ー３ー１ 構造化分類子

図０９ー０２

この図は構造化分類子(Structured Classifier)の構造を示しています。
構造化分類子は、プロパティ（パート、ポート）とコネクタを内部に持ちます。
なお、ConnectableElementは、コラボレーションと関係付けるために使用されています。
（中級コースでは詳しく触れませんが、コラボレーションはConnectableElement間の振る舞いとして定義付けられています。）

UML中級講座 第24回 構造化分類子 コンストラクタ表現

行楽地はどこも混雑の様子ですが、皆さんはどちらから、このページにアクセスされておられますか？
本日は、構造化分類子の例として、コンストラクタ表現を例示致します。

コンストラクタ

図F19

図F19中の ＜＜ create ＞＞ とかかれた点線矢印は、クラスのコンストラクタと戻り値の関係が示されており、make(...)オペレーションで theW:Windowと言うインスタンスが生成されたことを表しています。
(戻り値として、theW オブジェクトが渡されています。）

図F20

構造化分類子でも、同じ表現が可能です。
図F20は、車クラスのコンストラクタを表現しています。
このコンストラクタでは、パラメータで"brand"と言う値を指定しており、その値がインスタンス化の初期値で使用されています。

UML中級講座 第23回 構造図の例

３ー２ー２ 構造図の例

図F16

図F16は車と車輪の２つのクラスを表しています。
車輪クラスは、車クラスに所有される4つの車輪インスタンスのタイプであることが示されています。
また、車クラスのインスタンスが生成されると、４つの車輪インスタンスが生成され、2個ずつ前車軸コネクタと後車軸コネクタで接続されることを示しています。

図F17 （コネクタとパートに多重度を指定）

図F17は、図F16と同等の表現を多重度の組み合わせで行っています。

図F18

図F18は、車クラスのインスタンスの内部を示しています。
4つの車輪インスタンスはそれぞれ初期値が設定され、タイプ名が省略されています。
また、左側の車輪にのみインスタンス名が付けられています。（l1 とl2）
コネクタ名にもインスタンスであることを示す下線が引かれていることに注意してください。

UML中級講座 第22回 構造化分類子

連休中ですが、皆さんいかがお過ごしでしょうか？ 本日から、構造化分類子について解説して行きます。

３ー２ 構造化分類子（Structured Classifier)
前節で、複合構造図は、単なるクラス図の入れ子ではなく、コラボレーションを示す図であると述べましたが、この表現を可能にするために、従来の分類子を元にさらに構造が拡張された分類子が定義され、これを構造化分類子と呼びます。

• 構造化分類子は、コラボレーションによって規定された振る舞いを持つ抽象メタクラスで、内部にプロパティ（パートやポート）とコネクターを持ちます。（詳細な定義は、次回以降のメタモデル図の解説を参照）

３ー２ー１ 構造化分類子の多重度

構造化分類子のパートやコネクタ端に指定された多重度は、親の分類子が生成される時に、生成されるインスタンスの数を意味します。
また、親のインスタンスが消滅すると内部の入れ子になったインスタンスもすべて再帰的に消滅します。

多重度表現の例

図F14

図F14の(i)のパート表現は、インスタンスレベルの表現では(ii)で示されるスター型になります。なお、インスタンス・スペシフィケーションでの、各名前の表示ルールは、
名前／役割名：分類子名 と記述します。
また、インスタンスが役割を演じる場合には、パート名を役割名とします。なお、インスタンスであることを示す下線も合わせて引きます。

図F15

図F15の（i)の多重度表現の場合は、(ii)のアレー型になります。
図F14、図F15の両ケースとも、多重度で接続の形態（トポロジー）が決定されますが、一般的には、多重度表現から必ずしも一意にトポロジーが決まるとは限りません。