突然梅雨前線が消滅したと言う事で、本格的な夏がやってきたようです。
筆者は神戸市（兵庫県）で生まれ育ったせいか、海と山が同時に見えない風景になんとなく圧迫感を感じますが、夏は特にその傾向が強いようです。
どういう風景に安心感を感じるかは、十代をどこで過ごしたかによって大きく左右される様な気がします。
筆者の知り合いで、以前は都会で暮らしていましたが、今は信州の八ケ岳に住み着いている人がおります。
その人の子供たちは既に成人しておりますが、幼年期をビル街で過ごした割には、十代を過ごした雪を頂いた高山の風景がないと落ち着かないと言っております。
図 C06
Par
Parは、オペランドの並列処理を意味しています。
各オペランドは、互いにインターリーブされて処理されます。
イベントの発生の観点から言いますと、各オペランドのイベントは次々に混在して発生して見えますが、しかし、一つ一つのオペランド内では、General Orderingのルールは守られます。
Critical
Criticalは、コンバインド・フラグメントが、クリティカル・リージョンである事を示しています。
クリティカル・リージョンでは、それを内包するインタラクション・フラグメントのイベントがインターリーブする事が出来ません。
図C06は、クリティカル・リージョンの例で、メッセージm5の受信後、m6の送受信が終了するまでは、クリティカル・リージョンの上位のフラグメントのイベントがインターリーブする事は出来ません。
Consider / Ignore
ConsiderとIgnoreは、｛ ｝で囲まれたメッセージ（群）と合わせて表示され、Ignoreは、これらのメッセージは重要でなく無視されていることを示しています。（メッセージのシンボルそのものが図中から省略されている場合もあります。）
また、Considerは、逆にこれらのメッセージが極めて重要である事を示しています。
Considerは、指定されたメッセージ（群）以外のメッセージがIgnoreされた状態とセマンティクス的に同じ意味になります。
また、assertは強調の意味を持ち、Consider / Ignoreと合わせて使われる事が多いオペレータです。（例 assert consider など）
図Ｃ０５
図Ｃ０５は、Consider / Ignoreオペレータの使用例です。
Ignore {t,r} で、メッセージ t と r はこのインタラクション M図上では、重要ではなく省略されている事を示します。
Consider { q, v, w } のフラグメント内では、メッセージ q , v, w のみが重要な意味を持つ事を示しています。
従って、このフラグメント内で記述のないメッセージ tとかrが発生してもトレースとしては正しい状態ですが、仮にメッセージwが発生したとすると、トレースは偽となります。
また、図中のmystateと言う名前がついた状態記は状態不変定数( State Invariant)と呼ばれ、制約条件（もしくは制約条件の集まり）となります。
mystateは、生存線Y上で実行時に評価され、偽となるトレースは誤り出る事を意味します。
また、{Y.p == 15}も不変定数と呼ばれる制約で、実行時に評価され偽となるトレースは誤りである事を意味します。
昨日に引き続いて、コンバインフラグメントの解説を行ないます。
コンバインド・フラグメント
opt
optは、コンバインド・フラグメント自身を実行するかしないかの選択がある事を示します。
セマンティクス的には、オペレータが”alt”で、2つ目の（elseの方の）オペランドが空っぽである状態と同値になります。
図 C03は、その表示例です。
図 C03
break
breakは、コンバインド・フラグメント中にブレーク・ポイントがある事を示します。
通常は、ガードと共に用いられ、ガード条件が成り立てば（真になれば）後続部分は全く無視され、成り立たなければ（偽になれば）後続部分が実行されます。
breakオペレータを持つコンバインド・フラグメントは、内包する生存線を最後までカバーする必要があります。
図 C04
また、breakオペレータを持つコンバインド・フラグメントで、ガードがない場合の振舞いについては規定されていません。（どのように振る舞うかは、非決定的）
本日から、第7章の相互作用図に入ります。
インターミディエート試験では、相互作用図の扱いは比較的軽く、
コンバインド・フラグメント、
ゲート、
インタラクション・ユース（以前は、インタラクション・オカランスと呼ばれていたもの）
の３つが主な範囲になります。
第7章 相互作用図
7ー1 コンバインド・フラグメント
7-1-1 コンバインド・フラグメント例 alt
図C01
図C01は、コンバインド・フラグメントの1例で、コンバインド・オペレータが ”alt”であるケースを示しています。
コンバインド・フラグメントは、種類を示すオペレータ部分と、動作を示すオペランド部の2つからなります。
また、オペランドが複数ある場合は、セパレータ（図中の点線）で区画を分けて表示されます。
図C02は、オペレータが”alt”のケースのコンバインド・フラグメントのフレームを示しており、何らかの条件が成り立つ時はオペランド①を実行し、成り立たない時は②を実行します。
図C02
まだ梅雨が終わらない様で、東京地方は朝からずっと雨です。
涼しくて過ごしやすいと言えば言えなくないのですが、梅雨が終われば、八ケ岳か北アルプスなどに出かけようと思っている身には、普段にもまして、夏の太陽が恋しく感じられます。
さて、本日は例外を扱うためのメタモデルを解説致します。
ExceptionHandler メタモデル
図１２−２３
ExceptionHandlerは、前回示しましたように、ジグザグの矢印で表現されます。
図12 - 23は、ExceptionHandlerのメタモデルを表しており、2つの実行可能ノード(ExecutableNode)と関係を持ち、１つが保護ノード（protectedNode)で、もう一方がhandlerBodyの役割を持ちます。
Bodyの入出力
Bodyに対する入出力を示すエッジを明示的に表現する必要はありません。
例外が発生した時には、保護ノードに対する入力と同じものをHandlerBodyが受け取り、例外処理が終わった後のBodyの出力が、保護ノードの出力として後続ノードへ渡されます。
従って、後続ノードの立場では、Bodyでの例外処理が終わった時点では、保護ノードでの処理が終わった状態と全く同じ様に見えます。
メタモデル図上の、ExceptionTypeは、例外の型を示す分類子です。（桁あふれや0による除算など）
梅雨の末期、彼方此方で豪雨のニュースを耳にします。
皆様のお住まいの地域はご無事でしょうか？
本日は、例外について解説致します。
6-7 例外
例外処理の表記を図A11(a)にします。
保護ノードで例外が発生した場合は、直近の構造化（アクティビティ）ノード内のすべてのトークンは終了し、例外のタイプに応じて、HandlerBodyが実行されます。
もし、直近のノード内に該当するHandlerがない場合は、より上位のノードに処理が渡されて行きます。
最上位のシステムレベルへ行っても該当するHandlerが見つからない場合のシステムの振舞いは無規定です。（プロファイルでこのようなケースが発生した場合の処理を指定する事ができます。）
(a)のジグザグ線の表記は、(b)で示される形で表記する事が可能です。
HandlerBodyの処理終了後は、保護ノードの後続ノードに処理が渡ります。（この指定を行なうためのエッジは記述する必要はありません。）
図（c)は、ExceptionHandlerの例です。
X/Yを計算する際、０による割り算が発生した場合は、右上のHandlerBodyが呼ばれ、Zに”無限”を代入後、印刷のノードへ処理が渡ります。
X とＹのかけ算の際、桁あふれ例外が発生した場合も同様に、例外処理後は、保護ノードの次のノードである印刷のノードへ処理が渡ります。
図 A11
本日は、構造化アクティビティノードについて解説致します。
6-6 構造化アクティビティノード
構造化アクティビティノードは、内部にアクティビティを含むノードです。
図 A10
内部のアクティビティの形式によって、コンディショナルノード、ループノード、シーケンスノードの3種類があります。
内部の従属するノードは、必ず１つだけの構造化アクティビティノードに所属し、他の構造化アクティビティノードと従属ノードを共有する事はできません。
また、エッジに関しても、ソース側、ターゲット側の両端は必ず同一の構造化アクティビティノード内で有る必要があります。
コンディショナルノード
図A10(a)は、コンディショナルノードで、複数の節（clause)から構成され、１つの節は テスト ： ボディーの形をしており、テスト部分に指定された条件が成り立つ時のみボディー部分が実行されます。
複数のテストが真を返した場合でも、実行されるボディーは一つだけですが、どのボディーが実行されるかは特段の条件がない限り（例えばテストの実行順序の指定など）予測出来ません（非決定的）。
またすべてのテストが偽を返した場合には、ボディーは実行されません。
複数のテストが真を返したり、すべてのテストが偽を返したりするする事態は、セマンティクス上の誤りである可能性はありますが、文法的には許されます。
コンディショナルノードのメタモデル
属性
isAssured : trueの場合は、 モデラーが少なくとも１つのテストが真を返すことを保証した状態を示す。
isDeterminate : trueの場合は、モデラーが最大１つのテストのみが真を返し、どのボディーが実行されるかが決定的である事を保証した状態です。
節(Clause)の間の関連（predecessorClauseとsuccessorClause)は、テストの実行順序を指定した場合の前後関係を示します。
ループノード
図A10(b)は、ループノードの形式を示しており、セットアップ、テスト、ボディーの三つの部分（アクティビティ）からなっています。セットアップ部分は、ループノードにトークンが入った時点で一度だけ実行され、その後は、テスト条件が真である限りボディーが実行されます。
ループノードのメタモデル
属性
isTestedFirst : trueの場合、最初のボディーの実行前にテストが実行されます。falseの場合、最初のテスト前にボディーが一度実行されます。
シーケンスノード
図A10(b)は、シーケンスノードを示しており、指定された順番にアクティビティが実行されるノードです。
図 １２−２１ 構造化アクティビティノードのメタモデル
本日は、パーティションのメタモデルについて解説します。
６−５−２ パーティションのメタモデル構造
❑ 図１２−１０
図１２−１０は、パーティションのメタモデル図です。（図中のActivityPartitionがパーティションを意味するメタクラスです。）
ActivityPartitionは、ActivityGroupを継承していますが、このActivityGroupは、ノードとエッジからなるグループです。
この図では、そのエッジとノードの関係を関連で再定義しています。
また、パーィティションは、内部にパーティションを含むことが出来ます。（サブパーティション）
【属性】
• isDimensionがtrueの場合、パーティション自身が他のパーティションに含まれていないことを意味します。
• isExternalがtrueの場合、パーティションが対象のシステムの外側の存在であることを意味します。
エッジ（ActivityEdge)に所有されるValueSpecificationはいわゆるガード条件です。デフォルト値はtrueで、即ち、無条件でエッジを通過すると言うのがデフォルトの解釈となります。
このブログは、時々外出先で書く事があり、本日は城山ガーデンにある緑茶専門の喫茶店で書いております。
本日の東京地方は朝から30度を超え、ようやくたどりついたこの店で、コンクリートを歩く男女をガラス越しに眺めながら、冷たい緑茶を飲んでほっと一息入れているところです。
さて、今回と次回はパーティションについて解説致します。
今回は、表記法をカバーし、次回はパーティションのメタモデルに触れる予定です。
６−５ パーティション
６−５−１ パーティションの表記
図A09
UML1.Xのアクティビティ図において、誰が各アクションを行うかを表示する手段として、スイムレーンが導入されましたが、UML2.0では、この表記方法がさらに拡大されパーティションと呼ばれるようになりました。
図A09の(a)は、パーティションを用いて、従来のスイムレーンの表記のを行った例です。各アクションの実行主体、グループはパーティションと呼ばれます。
パーティションはさらに細かいレベルまで分割することができ、サブパーティションと呼ばれます。図中のA,Bは、サブパーティションの名前です。
また、パーティションは、対象となるシステムの外側にいる人や組織なども表すことができ、それを示す記号としてステレオタイプ、<>が導入されました。図（a)のパーティション Cは該当システムの外側の存在であることを示しています。
UML2.0では、スイムレーン表記だけではなく、図(b)で示されるような多次元スイムレーン表記も可能となり、図(c)で示されるように各アクションノード内にパーティション名を記入することも可能になりました。なお、アクション内に記入する場合は、図のようにパーティション名を（ ）で括ります。
図(d)は、(b)と(c)の表記が混在した表現を取っています。この例では、実行主体として二つのクラス、「注文プロセッサ」と「会計係」が登場しますが、それぞれのパーティションが、「東京」と「大阪」の二つの地域に分けられています。この図で注意しなければいけないのは、東京の会計係のパーティション内に表示されている「支払い」アクションノードです。このアクションの実行主体は、東京の会計係ではなく、対象システムの外側にいる「顧客」であることが、ステレオタイプ<>から分かります。
なお、オブジェクトノードをパーティション間の境界線上に置くことは可能ですが、アクションノードを境界線上に書いてパーティション間で共有する形の表記は出来ません。（本来パーティションは、アクションの実行主体、グループを明記する為に導入されたものです。）
コントロールノードは、主に初級レベルでカバーされる分野ですで、本講座では、表記法の確認と、デシジョンノードの振舞いについて解説致します。
6-4 コントロールノード
❑ 図 １２−０９
図 A08
図１２−０９は、コントロールノードのメタモデル図を示しています。また、図A08は、各コントロールノードの表示例です。
• 各シンボルの名称は、(a)開始ノード (b)フロー終了ノード (c)フォークノード (d) ジョインノード (e)ディシジョンノード（分岐ノード） (f)マージノード（合流ノード）(g) アクティビティ終了ノード です。各ノードの振る舞いは、ファンダメンタルでカバーされる内容ですので、ここではメタモデル上に特徴のあるディシジョンノードについて解説します。
６−４−１ ディシジョンノード
ディシジョンノードは、一つの入力エッジと複数の出力エッジを持つコントロールノードです。
入力側、出力側のフローは、ともにコントロールフローであるか、もしくはともにオブジェクトフローであるかのどちらか一方であって、同一種類のフローが流れている必要があります。
また、出力側は必ず一つの経路のみが有効になるようセットしておくことが必要です。
図１２−０９のメタモデル図に表示されているように、ディシジョンノードには振る舞いが関連づけられています。
ディシジョンノードには振る舞いが対応しており、入力のデータトークンは、この振る舞いに渡され、この振る舞いの出力が各ガードに渡されます。
各ガードは、条件が満たされるときのみトークンを出力エッジに流します。（ガードの語源は、各出力エッジをガード(守護）しているところから来ています。）
６−３ アクションノード
アクションノードはファンダメンタル資格試験でも扱われており、ここではファンダメンタルでは扱わない特殊なものを解説します。
❑ 図 A07
図（a)は、シグナルの受信アクション、図（ｂ）はシグナルの送信アクションを示しています。
通常のコントロールフローと異なり、シグナルは受信者側の都合に合わせて処理され、シグナルが届いたからと言って必ずしも後続アクションが直ちに開始されるとは限りません。
• 図（ｂ）は、時間に起因して起動するアクションで、入力側にエッジを持たないのが特徴です。
• 図（e)左は、アクティビティ呼び出しアクションを表しおり、右手のアクティビティを呼び出している様を示しています。
アクティビティ呼び出しアクションは、５章で触れたCallBehaviorActionの一種で、アクションノード内に熊手のようなシンボル（レーキ）を書いて表示します。
今回は、表記法に関する部分が大部分です。
６−２−２ ピンの表記
❑ 図A05
図(a)はピンの標準的な表記例です。
図（ｂ）（ｃ）のようにピンの内部に矢印を書き、インプットピン、アウトプットピンと明示的に表現することが可能です。
ストリーミングの表現
ストリーミングは、アクションを一々止めることなく継続的にオブジェクトが発信し続けられるオブジェクトフローの状態を指します。
図(d) (e) (f)はすべて、オブジェクトフローがストリーミングであることを示しています。
また、図（ｇ）では、一部のオブジェクトフロー、設計図、がストリーミングと指定されています。
パラメータセット
６−１節で述べましたように、アクティビティ図は基本的にジョイン的な振る舞いを原則とします。
従ってピンにおいても、すべての入力情報が到着したあとにアクションが実行され、また出力ピンはすべて同時に出力されます。
しかしながら、場合によっては、一部の入力ピンに入力があった時点でアクションを開始したい場合や、特定の出力ピンにのみオブジェクトを送りたい場合があります。
このようなときの為に、UML2.0では、パラメータセットという表記が導入されました。
パラメータセットは、図（h）のように、特定のピンの組み合わせを四角形で囲むことで表します。
６−２−３ セントラルバッファーノード
❑ 図 A06 （a)
すべてのオブジェクトノードにはバッファー機能が付いていますが、セントラルバッファーノードは、非常に特殊な機能を持ちます。
図A06(a)で示されているように、セントラルバッファーノードは複数の入力エッジと複数の出力エッジを持つことが可能であり、この図では二つの工場で製造された部品を蓄積し、一部の部品はそのまま使用し、使わない部品は箱詰めしている状態を表しています。
図 １２−０８ メタモデル図（セントラルバッファーノード）
このように、セントラルバッファーノードは、通常のオブジェクトノードを特化し、キューイングとフロー間の競合に新たな機能を付け加えています。
前回述べましたようにアクティビティ図はフローチャートを起源としており、セマンティクス上もフローチャートとほとんど同じように解釈されますので（特にコントロールフローにおいて）、直感的に解りやすい図です。
しかし、一点注意する必要があるのがオブジェクトノードです。
前回のトークンの説明の際、コントロールノード内ではトークンは停滞しないと述べましたが、逆に言いますとオブジェクトノード内ではトークンは停滞する事が可能です。
コンピュータの言葉で言いますと、オブジェクトノードはバッファリングの機能を持ち、１つのオブジェクトノードで複数のインスタンスを表す事が可能です。
６−２ オブジェクトノード
オブジェクトノードの理解
❑ 図A02
オブジェクトフロー
オブジェクトフロートは、オブジェクトやデータが流れることのできるエッジ（アクティビティ・エッジ）のことであり、オブジェクトノードへ向けた矢印、もしくはオブジェクトノードから発信される矢印として表現されます。
図A02の例で言いますと、注文書というオブジェクトノードの入力側および出力側エッジはともにオブジェクトフローを表しており、ｂ図の発注と受注のピン間のエッジもオブジェクトフローです。
❑ 図 A０３
オブジェクトフローはまた、選択の振る舞いを持つことが可能です。
図A03の(a)図の例では、発注後の注文書を優先度別に並べ替えて発送に回し、(b)図の例では、注文処理されたオーダーの顧客情報（Order.Customerで表示）のみを、「項客へ通知」アクションノードへ送っています。
６−２−１ オブジェクトノードの表記
❑ 図 A04
図A04(a)は、標準的なオブジェクトノードの表記であり、名前は通常オブジェクトノードのタイプを表します。また、図A04（b）はシグナルを意味するオブジェクトノードです。
また、［ ］内に、オブジェクトの状態を指定することも出来ます。（図（ｃ））
図（ｄ）(e)で示されるように、｛ ｝内に制約を記述してオブジェクトノードに付加することができ、図（ｄ）では、オブジェクトノード内の上限が２個であることを示し、図（e)では、並べ方が通常のFIFO（先入れ先出し）ではなくLIFO（後入れ先出し）であることを示しています。
アクティビティ図の基本はトークンの概念です。
OCUPの資格試験では、トークンの概念を直接問うものはないようですが、アクティビティ図のベースの概念ですので、この講座では解説しておきたいと思います。
トークンの運ぶもの
アクティビティ図のセマンティックスは、トークンのフローに基づき決定されます。
そして、トークンはオブジェクト、データ、または制御ポイントを運びますが、これらは値（バリュー）とも呼ばれます。
また、値のないトークンも許されており、これをヌルトークンと呼びます。
日常会話では、値というとデータの一部を意味する言葉として使わることが多いのですが、アクティビティ図では、オブジェクトなどを含む包括的な意味で使われますので注意が必要です。
たとえば、「アクティビティが終了するケースとして、アクティビティ終了ノードに制御が到達する場合の他、アクティビティの中に値が無くなったときにも、アクティビティは終了する。」という言い方をします。
（図A01-a参照）
• ❑ Fig. A-1
要点
トークンのフローの原則：（詳細の動きについては、個々のノードの定義に依存。）
各ノードは、入力出力に関し、トークンのフローをコントロールするルールを持ち、エッジは、ソースノードからターゲットへトークンが流れる際に守るべきルールを持っている。
トークンは、ソースノード、ターゲットノード、エッジのすべてのルールが満たされたときのみ、ソースからターゲットに向って流れる。（図A01-c参照）
トークンは、コントロールノード上では、停滞しない。
UML1.Xでは、アクティビティの複数の入力フローをマージ的に扱っていたが、UML2.0では、暗黙的なジョインで扱っている。（図A01-b参照）（＊注）
❑ （＊注）各ノードは、基本的に、ノードの実行が可能になるまで、入力側のトークンが集まるまで待つことになります。しかし、暗黙的な表現になってしまって意味が捉えにくくなりますので、コントロールノードのマージやジョインを明示的に使用して、トークンの動きを明確に書き記すことをお勧めします。
インターミディエート試験の出題範囲
アクティビティ図に関するインターミディエート試験の範囲は、ファンダメンタル試験の範囲と重なる部分があります。
本書では、以下の順番に、インターミディエートレベルでの理解に必要な問題について解説してゆきます。
❑ 1 オブジェクトノード
❑ 2 アクションノード
❑ 3 コントロールノード
❑ 4 パーティション
❑ 5 構造化アクティビティノード
早いもので、このUML中級講座を開始して3ヶ月経ちました。
もともとは、1ヶ月ほどで完了する予定でしたが、やり始めるとついつい筆が滑り、項目数で数えると、ようやく半分を終えた状況です。
今後取り上げる話題としては、次の５項目があります。
6章 アクティビティ図
7章 相互作用図
8章 ステートマシン図
9章 配備図
10章 プロファイル
これらのうち、10章を除く4項目、アクティビティ図、相互作用図、ステートマシン図、配備図に関しては、モデル図の書き方に関するものが大部分であり、この講座では、コンセプト的に面白い所を中心に解説します。
最後のプロファイルは、OCUPインターミディエート資格試験では、出題の比重としてはさほど高くないようですが、アドバンス資格試験では必ず出題される分野であり、またMDAやメタモデル構造を理解する上でのキーポイントで、かつ、コンセプト的にも面白いと思いますので、少し紙面を割きたいと思います。
６−１ アクティビティ図概要
アクティビテ図のルーツ
アクティビティ図のルーツは、コンピュータの黎明期に出現したフローチャートにまでさかのぼります。
従って、UML図の中でも、概念の発祥の最も古いものの１つとなります。
もちろん当時のフローチャートと現在のアクティビティ図では、表記法やその解釈も大きく違っていますが、根本的な部分ではかなりの共通性を持っています。
フローチャートもアクティビティ図もともに、コンピュータ・アルゴリズムやビジネスプロセス、手続きやワークフローなどを表現するのに用いられます。
従来、フローチャートは主に制御の流れを中心に記述されましたが、アクティビティ図では、制御の流れ（コントロール・フロー）とともに、データの流れ（オブジェクト・フロー）も合わせて記述されます。
現実の使用形態を見ますと、アクティビティ図を用いてコンピュータ・アルゴリズムを記述することは、初学者を除くとむしろ稀で、多くの場合、データや業務の流れを記述するために用いられています。
このため、UML2.0では、オブジェクトフローや手続き、業務フローを正確に記述できるよう拡張がなされています。
状態遷移図からトークンのフローチャートへ
以前のUML（UML １．X版）のアクティビティ図に比べ、UML2.0では、その形式や意味が大きく変わりました。
従来のアクティビティ図が、制御の流れに重きを置いた一種の状態遷移を表す図であったのに対し、UML２．０版のアクティビティ図では、状態遷移ではなくトークンの流れに焦点を当てます。
また、フロー終了やピン、パラメータなど、新しい記法が追加され、省略時解釈も大きく変わってきています。従って、これからOCUP受験準備に取り掛かる方は、以前の慣習的解釈や類推にとらわれず、むしろ新しい図として捉えた方が効率的でしょう。
しかしながら、UML１．X版のアクティビティ図に関する知識が全くの無駄になってしまうのかというとそうではありません。
UML２．０版だけの知識を持つ方に比べると、両者の違いを知ることができ、オブジェクト指向技術の方法論の進化・変遷を深いレベルで理解することができます。
この講座でも、折に触れ、文法や表記法の表面上の違いだけでなく、なにゆえそのような形式を取ったのか、その根幹の理由、目的についても解説したいと思います。
UMLは言語ですので今後も変化を続けてゆきます。
その中で、その変化をもたらす大きな潮流を理解することは、オブジェクト指向技術を使いこなし今後の方向性を決定する上で大きく役立つでしょう。
SOA(Service Orientred Architecture)やOCRES(リアルタイム系、組み込み系）を学習する上では、MDA(Model Driven Architecture)の理解が一つのキーポイントになります。
そして、MDAの基礎を支えているのがメタモデルの考え方です。
本日は、第５章アクションの最後、変数アクションについて解説します。
5-7 変数アクション
図 １１−１７
変数アクションは、変数を扱うためのアクションで、ReadVariableAction、WriteVariableAction、ClearVariableActionの3つから構成されます。
（注）変数は、一度に複数の値を持つことが可能です。
５−７−１ ReadVariableAction
変数の値を読み取って、出力ピンに置きます。変数の多重度と出力ピンの多重度は一致している必要があります。
５−７−２ WriteVariableAction
変数の値を変更するアクションで、AddVariableValueActionとRemoveVariableActionの2種類からなります。
５−７−２−１ AddVariableValueAction
変数の指定された場所に値を付け加えるアクションです。insertAtが１である場合、先頭に値を挿入する意味になり、＊は末尾に付け加える意味になります。
• 属性isReplaceAllがtrueの場合、変数から既存のすべての値を取り去った後に、値を付け加えます。
５−７−２−２ RemoveVariableValueaction
変数から、指定された値を取り除きます。
属性isRemoveDuplicatesがtrueの場合は、指定された値と同一のすべての値が変数から取り除かれます。（例え多重度の下限を下回る結果になろうとも取り除かれます。）
また、isRemoveDuplicateがfalseの場合は、何番目の値を取り除くのかをremoveAtで指定する必要があります。（removeAtは正整数、UnlimitedNaturalです。）
５−７−３ ClearVariableAction
ClearVariableActionは、変数から値をすべて取り除くアクションです。（例え、多重度の下限を下回る結果になろうとも、取り除かれます。）
７月になり、いよいよ蒸し暑くなって来ました。
筆者は、学生時代から山登りが好きで、昔はひと夏を山で過ごした事もありましたが、最近はなかなかそう言う訳にもいかなくなって来ました。
そして、あまり行けなくなったかわりに、部屋の壁には、山の絵や写真を飾って多少とも気持ちを慰めています。
山好きにも様々なタイプがいるようですが、筆者は以前は比較的オーソドックスに、沢登と共に、標高の高さは別としてピークを次々と踏破して行くのが好みのスタイルでした。
しかしながら、二十代最後の年に、カナディアンロッキーに登り、見渡す限り無限に続く大海原のように波打っている雪と氷で覆われた巨大な山塊に囲まれて以降、ピーク・ハンターはやめてしまいました。
その当時（多分今でも）カナディアンロッキーには、未踏峰が山ほどあり、道がないためにピークどころか麓にもたどりつけない山々が延々と連なっていました。
こういった山々の風景の写真を見ると、心に多少涼風を感じることができます。
５−６−３ WriteLinkAction
図 １１−１０
WriteLinkActionは、リンクを生成したり消滅させたりする抽象メタクラスです。生成はCreateLinkAction、消滅はDestroyLinkActionによって規定されます。
５−６−３−１ CreateLinkAction
CreateLinkActionは、リンクを生成します。直接LinkEndDataを用いず、それを特化したLinkEndCreationDataを用いるのは、順序づけされた関連をサポートするためです。LinkEndCreationDataは、重複するリンクが存在する場合に何番目にリンクを挿入するかを指定する値（insertAt)を持っています。
５−６−３−２ DestroyLinkAction
DestroyLinkActionは、リンクを消滅させます。直接LinkEndDataを用いず、それを特化したLinkEndDestructionDataを用いるのは、順序づけされた関連をサポートするためです。
LinkEndDestructionDataは、重複するリンクが存在する場合に何番目のリンクを消滅させるかを指定する値（insertAt)を持っています。
５−６−4 ClearAssociationAction
ClearAssociationActionは、リンクアクションではありませんが、関連が深いのでここで解説致します。
入力ピンで指定されたオブジェクトの、指定された関連に属するすべてのリンクを消滅させるアクションです。
5-6 リンクアクション
リンクアクションは、リンクの生成や消滅、リンク情報の読み書きを行うためのアクションです。
具体的には、ReadLinkAction、WriteLinkActionと言う2つのサブクラスで規定されておりますが、最初にその2つの共通のスーパーメタクラスであるLinkActionを解説し、その後、個々のアクションについて触れてゆきます。
５−６−１LinkAction
図 １１−０８
リンクの特定
LinkActionはReadLinkActionとWriteLinkActionの共通のスーパーメタクラスであり、対象のリンクを特定するための情報構造を持っています。
図１１−０８に示されるとおり、LinkEndDataはリンク端を意味し、LinkActionは2つ以上のLinkEndDataを持ち、それぞれが対応する関連端（図中のProperty)と関係づけられています。
入力ピン(InputPin)は、サブクラスで規定されるアクションによって使い方が変わってきます。
一例としてWriteLinkActionの場合、リンクを形成する関連端ごとに、接続対象のオブジェクトもしくは値が指定されている必要があります。
５−６−２ ReadLinkAction
図 １１−０９
ReadLinkActionは、対応する関連に沿って1つのリンク端へ誘導し、入力ピンに指定されていないリンク端（オープンエンドと呼びます）のオブジェクトを出力ピンに置きます。
オープンエンドにたいし、誘導可能性がなかったり、可視性が適切でない場合は、アクションのセマンティックスは定義されていません。
入力ピンは、リンク端のソース側を指定し、ターゲット側をオープン（指定しない状態）にします。
なお、３項関連以上のn項関連では、１つのリンク端をオープンにします。
