九州は昨日梅雨入りしたそうですが、皆さんのお住まいの地域はいかがでしょうか？
東京地方は、朝から雨が静かに降り続いています。
さて、 本日は、CallBehaviorActionについて、解説致します。
５−２−１−２ CallBehaviorAction
CallBehaviorActionは、昨日解説したCallOperationActionが呼び出し要求をオブジェクト（自分自身のオブジェクトを含む）に送るのに対し、直接振る舞いを呼び出すアクションです。
典型的にはアクティビティの呼び出しがこれに当たります（アクティビティ図の章を参照）。
非同期型の場合、振る舞いの呼び出しを行なった時点でアクションそのものは完了し、その後の振る舞いは並列処理になり、仮に呼び出された側に戻り値が発生したとしても呼び出した方には渡されません。
同期型の場合は、呼び出した振る舞いからリプライが戻るまで待機し、戻り値は結果ピンに置かれます。
例外が発生した場合は、呼び出した側に例外が送られます。
【制約】
❑ i 引数ピンと、呼び出される振る舞いのinおよびin-out型のパラメータの数は等しい。
❑ ii 結果ピンと、呼び出される振る舞いのoutおよびin-out型のパラメータの数は等しい。
❑ iii 引数ピン、結果ピンのタイプ、順番、多重度は、呼び出される振る舞いのパラメータに等しい。
図１１−０４
本日は、CallOperationAction、いわゆる操作の呼び出しに相当するアクションのメタモデルの解説をします。
５−２−１−１ CallOperationAction
CallOperationActionは、操作を呼び出す要求を、ターゲットのオブジェクトへ送るアクションです。
引数の値は、呼び起こされた振る舞いによって使用されます。
同期型の場合は、呼び起こされた振る舞いが完了し、リプライが呼び出し側に返ってくるまで待機します。
またリプライの値は、結果ピンに置かれます。呼ばれた側に例外が発生した場合は、呼び出した側に例外が送られます。
非同期型では、操作の呼び出しのあと、呼び出し側と呼び出された側の振る舞いは、並列処理になり、仮に呼び出された側の操作に戻り値があったとしても、呼び出し側には渡されません。
【制約】
❑ i 引数ピンと、操作のinおよびin-out型のパラメータの数は等しい。
❑ ii 結果ピンと、操作のoutおよびin-out型のパラメータの数は等しい。
❑ iii ターゲットピン（ターゲットオブジェクトを指定する入力ピン）は、操作の所有者のタイプと同一。
図１１−０４
6月になって、清々しい日々が続いております（東京地方）。
今週から、リアルタイム系もしくは組込み系システムの資格制度である、OCRESのパイロット試験が開始されました。
当面、試験内容は英語のみですが、受験費用が60％ディスカウントされるそうです。
さて、本日は、呼び出しアクション（ InvocationAction )の１つCallActionのメタモデルについて解説致します。
５−２−１ CallAction
CallActionは、振る舞いを呼び起こすアクションで、CallBehaviorActionとCallOperationActionの2種類があります。
CallActionの動きとして、同期と非同期の二通りがあり、同期の場合には、戻り値を受け取るまで待機します。
図11-04のCallActionの属性、isSynchronous、が同期・非同期を示すブーリアン値で、' true ' が同期、'false' が非同期であることを示します。
図１１−０４
同期：
呼び起こした振る舞いが完了するまで待ちます。
非同期：
振る舞いを呼び起こすだけで、戻り値を待ちません。
【制約】
( i) 同期型のCallActionのみが、結果ピン（図11-04の 'OutputPin' メタクラス）を、持つことが可能です。
( ii ) 入力ピン（図11-04の argumentと言う役割名がついた方の' InputPin' メタクラス）の引数の数、順番、タイプ、多重度は（注＊）、呼び起こす振る舞い、もしくは振る舞い特性のパラメータと一致しなければなりません。
（注＊）振る舞いや操作のパラメータは、順序付きのリストとなります。
アクションは、振舞いの基本単位であり、本章では、メタクラスの解説を中心に行なって行きたいと思います。
5-2 呼び出しアクション ( Invocation Action )
図１１−０４
図１１−０５
呼び出しアクション ( InvocationAction ) は、振る舞いを呼び起こす様々なアクションの総称です。これ自体は抽象メタクラスであり、具体的な事柄はCallAction、SendSignalAction、SendObjectAction、BroadcastSignalActionの4つのサブクラスで規定されています。
今回から、第5章アクションです。
5章 アクション
5-1 アクション概説
アクションは、振る舞いを規定する上での最も基礎的な単位であり、通常はいくつかの入力と出力から構成されます。
メタモデル図では、これらの入力や出力がそれぞれ入力ピン（InputPin)、出力ピン（OutputPin）という分類子によって表されます。
大部分のアクションは、実装から独立した振る舞いを定義しています。
これらのアクションは、１）計算をする、もしくは２）対象のオブジェクトのメモリーへアクセスする、のどちらか一方だけを行う極めて原始的なレベルまでブレークダウンされています。
これにより、振る舞いの定義の、精密性・正確性を維持する為の下部構造（インフラストラクチャ）の定義が可能となります。
通常のコンピュータ言語はこれらを組み合わせたもう少し複雑な体系をしておりますが、これは、アクションパッケージで定義されたごく原始的なアクションを組み合わせることにより構築できます。
昨日に引き続き、コンポーネント図で用いられるコネクタのメタモデルについて解説致します。
モデリングの手法として、最初に形式やパターンを決め、その後に意味を細かく定義するというアプローチがあります。
これは、ソフトウエアのモデリングだけではなく、ビジネスモデリングにも用いられる普遍的なアプローチです。
そして、コンポーネントの定義にもこのアプローチが用いられます。
最初に複合構造図で、フレームワーク（形式）を定義し、コンポーネントはそれを継承して意味を付け加えて行きます。
なお、コンポーネントの最終的な表現対象は契約（別の言い方をするとサービス）です。
インターフェース条件さえ合致すれば、コンポーネントは契約（サービス）を実現します。
コンポーネントの章の始めにCBD「契約に基づく開発」のお話をしましたが（第29回参照）、この契約はソフトウエアコンポーネントだけではなく、ビジネスコンポーネントも視野に入れた形で定義されています。
以前「SOAについて」と言う表題で、SOAの4つのレイヤーに触れましたが、上から2つ目のレイヤー、「ビジネス・サービス・レイヤー」の主役はビジネス・コンポーネントです。このコンポーネントは、UMLのコンポーネントを拡張して定義されます。
４−２−２ コネクタのメタモデル
図０８−０３
コネクタは基本的に複合構造図で述べたものと同じですが(第26回参照）、コネクタの種類として（ConnectorKind)、アセンブリと委譲の2種類が追加されています。
本日と次回の2回で、コンポーネント図のメタモデルを解説します。
４−２ コンポーネントのメタモデル
４−２−１ コンポーネント
図０８−０２
先に述べたとおり、コンポーネントは複合構造図で触れたカプセル化クラスを継承しています。
そして、提供インターフェースと要求インターフェースを持つことができ、実現のための分類子を所有しています。
図０８−０２の中の「realization」は、提供インターフェースや要求インターフェースと言う名前で規定される契約（別の言い方をするとサービス）を、分類子を用いて「実現する」と言う概念です。
このrealizationは、サービスを実現するために内部に包含する分類子（プロパティやコネクタ、本講座第25回参照）とカプセル化クラス自身との所有関係の間に挿入された形で表現されます。
つまり、カプセル化クラスは、単に、内部にプロパティやコネクタと言った分類子を所有していると定義され、コンポーネントでは、さらに、それら内部分類子との間に、（契約やサービスを）実現するための関係（「realization」の関係）を結んでいるという言い方が出来ます。
「realization」は、UMLモデル図上では、依存関係の一種として扱われます。
