筆者はこのブログをアップル社のパワーブックを使って書いているのですが、インターネットユーザーの大部分はマイクロソフト社のインターネット・エクスプローラーを使用して見ているとのことですので、時々確認のために手持ちの古いIBM/PCや、マックOSの上でWindows環境をエミュレートするVirtualPCを立ち上げて見ています。
ところが、前者は持ち運びができず、後者はスピードが非常に遅いので、何か良い方法がないかと思っていたところ、先日発売開始されたMacBookとその上でWindows環境をエミュレートするParallelsと言うソフトの組み合せがなかなか評判が良いということで、早速、手に入れて走らせてみました。
結果は、スピードの点で全く申し分なく、VirtualPCは言うに及ばず、実機であるIBM/PCの速度を凌駕し（多分機械が古いせいでしょう）、またWindowsだけでなく、Linuxもインストールでき、なかなか快適なワーキングベンチが実現出来ました。
ところが、後になって気付いたのですが、モバイルで使っているPHSモデム（WillcomのAH-F401Uと言う機種です）がintelMac に対応しておらず、昨日は一日中オフラインの状況になってしまいました。
かつて、携帯電話が出回り始めたころ（十数年前）は、携帯電話でいつ呼び出されるかも知れないと言う状況が１つのストレス源でしたが、今や逆にオフライン下におかれることがストレスになってしまったようで、落ち着かない一日でした。
さて、前回に引き続き、オブジェクトアクションの１つ、DestroyObjectActionを解説します。
５−４−２ DestroyObjectAction
入力ピンのオブジェクトを消滅させるアクションであり、初期値やリンクを設定したり、ステートマシンの遷移を引き起こしたりと言った副作用を全く伴いません。
また、オブジェクトとしてリンクオブジェクトも対象になり、その場合DestroyLinkActionの定義に沿って処理されます。（DestroyLinkActionの項を参照。）
【属性】
このアクションは2つの属性、isDestroyLinksとisDestroyOwnedObjectsを持っており、意味は次の通りです。
❑ isDestroyLinks 初期値はfalse
• この属性がtrueの場合、対象のオブジェクトが関わっているリンクもすべて消滅させる。
❑ isDestroyOwnedOwnedObject 初期値はfalse
• この属性がtrueの場合、対象のオブジェクトが所有するオブジェクトもすべて消滅させる。
【制約】
• i 入力ピンの多重度は１
図１１−０６
先日、たまたま仕事上で、このブログを時々覗きに来ているとおっしゃる方とお会いした折、「制約条件に反した状況が発生した場合は、UMLはどういう風に振る舞うのか？」というご質問を頂きました。
皆様の参考にもなるかと思いますのでので、ここにその点をコメント致します。
UMLの仕様上、一般的に、制約条件に違反した場合の振舞いは規定されておりません。
例えば、本日取り上げるCreateObjectActionは、指定された分類子（クラス）からオブジェクトを生成するアクションですが、当然の事ながら、指定された分類子（クラス）は具象分類子（具象クラス）で有る必要があります。
仮に、その制約を破って、抽象分類子が指定された場合、処理方法は規定されておらず、結果は予想不能の状態になります。
文法と言う観点からいえば、明らかに文法違反であるため、わざわざ規定する必要がないので無規定としているわけです。
５−４−１ CreateObjectAction
CreateObjectActionは、指定された分類子に適合するオブジェクトを生成し、それを出力ピンに置くアクションです（オブジェクトそのものが戻り値になります）。
このアクションは、単にオブジェクトを生成するだけであり、初期値やリンクを設定したり、ステートマシンの遷移を引き起こしたりと言った副作用を全く伴いません。
【制約】
• i 分類子は抽象クラスではあってはならない。
• ii 分類子は関連クラスであってはならない。
• iii 出力ピンの多重度は１。
図１１−０６
前回、適用アクションのお話をした時に、このメタクラスは標準化の過程で無くなってしまった、と言うお話をしました。
標準化の過程で仕様が変更されていくのは、ある意味当たり前のことですが、時と場合によっては非常にはた迷惑な現象を引き起こすことがあります。
世の中には、様々な分野に数あまたの標準化の組織があり、中には無能としか呼びようのない団体も事実存在します。（心当たりのある関係者の方、ごめんなさい。他意はございません。個々人に対する個人的な批難ではありません。）
そして、UMLの標準化を行なっているOMGと言う団体の評価はと言うと、私の知る限り、世界の最高水準にある良い団体だと思います。
市場や社会に混乱を巻き起こすダブルスタンダードを生み出さず、適度に早く、また優れたプロセス・コントロールでマネージされています。
私の感じる所は、技術的水準の高さもさることながら、そのマネジメント能力の高さです。
往々にして、標準化団体は、テクノロジー・マネジメントに関する能力に関して疑問符がつく場合があり（国内外を問わず公務員主導型の場合は、特にそういう気がします）、策定された多くの標準が低い評価のまま終わってしまっています。
前回取り上げた適用アクションは、標準化プロセス上、Final Versionの１つ前のFinal Adaptation版と呼ばれるバージョンの仕様に掲載されていました。
この版は、一般にはツールベンダー・レディのバージョンとして知られ、これは、この版を元にツールベンダーは開発を開始しても良いと言うバージョンにあたります。その後の変更は、極めてマイナーな変更に限定されます。
そして、このFinal Adaptation版の発行以降は、変更要求は、次のバージョン（UMLの場合だと、UML第2.1版）で議論されることになります。
ちなみに今回の適用アクションに関する変更は、ツールベンダーに僅かな影響を与えただけで、ユーザーレベルでは、なんの違いもありません。（ツールベンダーレベルで吸収可能な変更です。）
さて、前置きが長くなりました。
本日から、オブジェクトアクションを議論して行きましょう。
5-4 オブジェクトアクション
図 １１−０６
オブジェクトアクションは、図１１−０６に示される4つのアクション、CreatObjectAction、DestroyObjectAction、TestIdentityAction、ReadSelfActionの総称です。
ただし、これらの４つのアクションには構造上の共通性がないので、特段共通のスーパーメタクラスは定義されていません。
次回以降、個別にこれらのアクションを見てゆきます。
本日は、特殊なアクションについてお話します。
どういう意味で特殊かと言いますと、OCUPインターミディエート資格試験が始まった時点では、「適用アクション」と言うメタクラスが存在していたのですが、その後の改定作業で最終版の言語仕様から除かれてしまったのです。
と言いましても、言語が大きく変わった訳ではありません。
たとえて言いますと、システム設計の最中に、「猫用の餌」クラスのサブクラスとして、「オス猫用の餌」クラスと「メス猫用の餌」クラスを作ったが、設計が進むにつれて、わざわざ区別する必要がなくなったので、これら2つのサブクラスを後になって削除したようなものです。
ただ、本講座の想定水準としておりますOCUP資格試験のカバレッジ・マップ上にはまだ残っておりますので一応解説をしておきます。
5-3 適用アクション
適用アクションは、OCUPインターミディエート資格試験の試験範囲が発表された時点では存在していたのですが、最終仕様からは削除されております。
しかしながら、今の時点で、出題される可能性が残っておりますので、概要を触れます。
5-3-1 ApplyFunctionAction
適用アクションに属する具体的なアクションは、このApplyFunctionActionの1つだけです。ApplyFunctionActionは、入力情報のみを使って出力を計算するアクションで、メモリー等へのアクセスもなく全く副作用の発生しないものです。
元々は、モデル化対象のシステムの外側にある振る舞いを呼び出すために導入が検討されましたが、パッケージのスキーム変更により、特段定義する必要がなくなり、最終版仕様書からは除かれました。
注意すべき点としては、適用アクションそのものが存在しなくなったのではなく、名前を付けて区別する必要性がなくなったと言う点です。
昨日は、来日中のOMG会長、マーク・ソーリー博士が、OCRESの説明をされると言うことで、会場の大手町まで行ってきました。
今回の来日スケジュール中には、BPM(ビジネス・プロセス・マネジメント）やSOA(ソリューション・オリエンテッド・アークテクチャ）の会合も開催されておりましたが、私自身の都合が付かず、OCRESの説明会にのみ参加してきました。
ソリーさんは、これまでもよく日本に来られておられましたが、特にこのOCRES（リアルタイム系、組み込み系スペシャリストの資格試験）は、日本の要望に焦点を当てたものであり、今後ますます日本で彼の姿を見ることができることでしょう。
さて、本日はInvocationActionの最後として、BroadcastSignalActionを取り上げます。
５−２−４ BroadcastSignalAction
BroadcastSignalActionは、シグナルのインスタンスを生成し、システム内のすべてのオブジェクト（＊）に送信するアクションです。（その結果、ステートマシンの遷移が起こったり、アクティビティの実行が開始されたりしますが、それらについては、ステートマシン図およびアクティビティ図の章を参照してください。）
このアクションは送信が終了すると直ちに完了し、ターゲットオブジェクトからのリプライメッセージや戻り値は、全く無視されます。
（＊注： 何をもって、すべてのターゲットオブジェクトとするかは、前提とするシステムのセマンティクスに依存します。）
図１１−０５
深夜のワールドカップの観戦後、つい深酒をしてしまい、今朝が辛かった方もいらっしゃるのではないでしょうか？（私も、その一人です。）
さて、本日は、昨日のSendSignalActionに続き、SendObjectActionについて解説します。
このSendObjectActionの典型的な例としては、アクティビティ図中のオブジェクトフローが挙げられます。
SendSignalActionでは、Signalの分類子が入力になり、それをインスタンス化してターゲットに送りますが、SendObjectActionでは、インプットがオブジェクトであり、それをターゲットに送ります。
従って、もし既にインスタンス化されたSignalを送りたい場合は、このSendObjectActionを用います。
５−２−３ SendObjectAction
SendObjectActionは、オブジェクトをターゲットオブジェクトに送信するアクションです。（その結果、ステートマシンの遷移が起こったり、アクティビティの実行が開始されたりしますが、それらについては、ステートマシン図およびアクティビティ図の章を参照してください。）
このアクションは送信が終了すると直ちに完了し、ターゲットオブジェクトからのリプライメッセージや戻り値は、全く無視されます。
オブジェクトおよびターゲットオブジェクトは、入力ピンで与えられます。
また、入力ピンのオブジェクトをそのまま送るケースもあれば、コピーを作成して送るケースもありますので（オブジェクトフロー参照）、入出力のオブジェクト間のアイデンティティは保証されません。
図１１−０５
ワールドカップが始まり、今夜はいよいよ日本対オーストラリア戦です。
５−２−２ SendSignalAction
SendSignalActionは、シグナルのインスタンスを生成しターゲットオブジェクトに送信するアクションです。（その結果、ステートマシンの遷移が起こったり、アクティビティの実行が開始されたりしますが、それらについては、ステートマシン図およびアクティビティ図の章を参照してください。）
このアクションは送信が終了すると直ちに完了し、ターゲットオブジェクトからのリプライメッセージや戻り値は、全く無視されます。
【制約】
❑ i 引数ピンの数、順番、タイプ、多重度は、シグナルの属性と一致
図１１−０４
