UML中級講座 第60回 ClearStructuralFeatureAction

昨日触れましたモチベーションに関しては別途議論したいと思いますが、今回は構造化特性アクションのうち残った最後の項目、ClearStructuralFeatureActionについて解説致します。


５−５−３ ClearStructuralFeatureAction

入力ピンで指定されたオブジェクトから、構造化特性の値をすべて一度に取り去るアクションです。（例え構造化特性の多重度の下限を下回っしまっても、取り去ってしまいます。）
指定された構造化特性に値が全くなかった場合は、何も起こらないことを意味します。
図 １１−０７

UML中級講座 第59回 RemoveStructuralFeatureAction

このブログは、"プロマネBlog"と名乗る割にはプロマネの話を殆どしないではないかという、友人達の心無い批判(?)に応えるため、本日は組織とモチベーションについてお話したいと思います。

最近は、(J)SOX法関連の話題が多くなってきました。
このSOX法は、広く知られておりますように、アメリカのエンロン社やワールドコム社の巨大粉飾疑惑と破綻がきっかけで制定されることになりました。
実は筆者は、９０年代にワールドコム社と多少関わり合いをもっており、従業員の年金基金が破綻して実質上年金が受け取れなくなったであるとか、経営幹部が謎の自殺を遂げたと言った話を聞くたびに当時の同僚達の顔が浮かび、心が揺るがされる人間の一人です。
会計学に詳しい人に聞くと、これらの会社で行われた会計操作は、手法としてはむしろ在り来たりなものばかりだそうですが、何しろその規模が桁近いに大きく、当の会社だけでなく、アメリカ資本市場へ拭いがたい不信感を生み、アメリカ社会そのものにも大きな影響を与えました。
では、なぜこのような巨大な粉飾が行われたのでしょうか？
筆者は、ワールドコムとの経験を通じて、犯行はCEOを含む少数のトップグループによるものだと考えています。
何故かというと、それ以外の人間にとっては、それだけの巨大粉飾を行なうモチベーションが働かないからです。
従来から、会計操作はどの会社でもあったと思いますが、今回の犯罪の背景としては、９０年代の株式市場中心主義があったと思います。
この株式市場中心主義においては、経営者の能力は、時価総額を上げる事、つまり株価を上げる事であるという考え方が支配的であり、エンロンやワールドコムの経営者達は事実ストックオプション等を通じて、巨額の利益を得る事ができました。
もちろん、利益を粉飾するというは、税額が上がるという負帰還（Negative Feedback)が働きますが、株式市場で得られる巨額の利益に比べれば、モチベーションに対する抑止力としては極めて弱いものです。
今回制定されたSOX法においては、従来の市場中心的なコーポレートガバナンスの手法ではなく、不正に関しては、経営者に対する責任を厳格に問うという姿勢がいっそう強化されています。
この株式市場中心主義的なアプローチは、日本においても、数年のタイムラグはあっても、確実に浸透して来ていました。
昨今、「村上ファンドが阪神ファンの逆鱗に触れ（？）、撤退を余儀なくされている云々」と言うニュースが流れていますが、その一端を象徴していると思います。

さて、組織の話を少ししたいと思います。
組織内に新しいルールを導入する際、最も注意しなければならないのはメンバーのモチベーションの問題です。
人をコントロールするという事は、端的にはモチベーションをコントロールする事です。
よく、新しいルールを導入したけども上手く行かないと言う話を聞きますが、圧倒的にモチベーションがコントロールされていない場合が多いようです。
人間は、機械ではないためルールだけ決めても、モチベーションが弱いとなかなか動きません。
また、不正に対する誘惑に対しても、罰則だけ強化しても無駄であり、不正が確実にあばかれうると言うことを、（少なくとも）思い込ませておく必要があります。
人は欲望や恐怖と言った原始から変わらぬ強い活力源を持ち、それを効果的かつ有効に、そして平和的に利用する事が、現代のマネジメントに要求されるスキルでしょう。

５−５−２−２ RemoveStructuralFeatureValueAction

入力ピンで指定されたオブジェクトから構造化特性の値を取り去るアクションです。
取り去る値を入力ピンで指定することも可能ですし、除去する場所をremoveAt（removeAtは整数値を取る）で指定することも可能です。
値を指定した場合、構造化特性中に該当する値が存在しない場合は、何も起こらないことを意味します。
指定された構造化特性が関連端であった場合、意味的にはリンクを消滅させることと同じ意味になります。
また、属性isremoveDuplicatesがtrueの時は、指定した値が複数ある場合はその重複する値すべてが取り除かれます。

図 １１−０７

UML中級講座 第58回 WriteStructuralFeatureAction

昨日、中野長者の話をしましたが、筆者のオフィスのあるこの街には、様々な長者伝説が伝わっています。
おそらく、他の伝承と同じく、長い年月の間に複数の話が重奏して現在の伝説になったのだと思いますが、筆者なりに原風景をたどってみました。

現在、新宿区、中野区、渋谷区の３つの区の境界が住宅地の細い路地を縫うように交錯するこの辺りは、かつては神田川の氾濫原であり、普段は神田川が細流として流れる荒れ地であったようです。
そして、人跡まばらなこの辺り一帯は、総称として漠然と「なかの」と呼ばれていました。
そこに、今から６００年以上前、鈴木九郎さんと言う人が紀州から移り住んできました。
鈴木氏は馬を商う事をなりわいとしており、今でも良馬を産み育てることは難しい事業ですが、おそらく優れた技術の持ち主だったのでしょう、後年、大変な大金持ちになったそうです。
しかしながら、現在この地には鈴木氏の子孫は全く伝わっておりません。
彼には、一人娘がいたようですが、（おそらく皮膚病だと思われる）難病を患い、若くして亡くなってしまったようです。
最愛の一人娘を失った悲嘆は、いくら巨万の富があっても癒すことができないのは、今も昔も変わりません。
彼は、全財産を仏法に委ね、屋敷を寺院としました。
最近の改修の際、成願寺の仏像の胎内から出てきた骨片を調べたところ、老人男性と若い娘の骨だと解りました。
おそらく、鈴木氏父娘だと言われています。

５−５−２ WriteStructuralFeatureAction

入力ピンで指定されたオブジェクトの構造化特性の値を変更するための抽象メタクラスで、具体的なアクションは、AddStructuralFeatureValueActionとRemoveStructuralValueActionの２つのサブクラスが規定しています。
歴史的には、UML1.5のWriteAttributeActionを一般化したもので、当然のことながらクラスの属性の更新を行なうこともできます。
なお、属性は複数の値を着けることができ、内部的には順序付のリスト構造の形で保持されます。

５−５−２−１ AddStructuralFeatureValueAction

構造化特性の値を付け加える為のアクションで、値の置き換えを行うことも可能です。
構造化特性は、複数の値が順序づけられて並べてある構造をしており、挿入点(insertAt)を指定して新しい値を挿入します。
属性isReplaceAllがtrueの場合、新しい値の挿入前に古い値がすべて取り除かれ、値の入れ替えが可能です。
指定された構造化特性が関連端であった場合、意味的にはリンクを形成することと同じ意味になります。

（注）挿入点（insertAt)は、整数値を取り、１は先頭を意味し、＊は末尾に付け加えることを意味します。

図 １１−０７

UML中級講座 第57回 ReadStructuralFeatureAction

現在使っている西新宿のオフィスは、駅からさほど遠くなく、周りも下町情緒が残っており、何といっても静かですので気に入っております。
近くには神田川が流れ、ぶらぶら散歩するにもなかなか良いところです。（足を伸ばせば、南こうせつとかぐや姫の歌碑もあるとか聞きます。）
歴史的にも古くから開けたところのようで、中野長者の伝説が伝わります。
この中野長者は相当の大金持ちであったらしく、成願寺という長者の屋敷跡に立てられたお寺の山号は多宝山と言い、立派な伽藍が残っています。
また、このオフィスをかつて借りていた会社（２社）は、後年上場をはたしたと言うことで、近所では縁起ビルとしても知られています。
しかしながら、最近はだんだんと手狭になってきたので、近々引っ越そうかと考え始めております。

さて、本日はReadStructuralFeatureActionを解説します。
UML1.Xの時代は、クラス構造が単純でしたので、単に属性を読み書きすれば良かっただけでしたが、UML2.0になって、構造化分類子が登場し、オブジェクトが内部構造を持つようになった結果、その内部構造を読むためのアクションが必要になってきました。それが、ReadStructuralFeatureActionです。

５−５−１ ReadStructualFeatureAction

入力ピンに置かれた対象オブジェクトのSturcturalFeatureで指定された値を読んで出力ピンに置くアクションです。
例えば、カプセル化クラス A１ の中にクラスA2が存在し、A2の属性Ｂをアクセスしたい場合、入力ピンにはA1のインスタンスを置き、SAtructuralFeatureは A1中のA2中のＢを指定します。

歴史的には、UML1.5のReadAttributeActionを一般化したものです。
従って、対象オブジェクトの属性を読んで出力ピンに置くことも当然出来ます。（その場合、StrructuralFeatureは、属性名を指定します。）


図 １１−０７

UML中級講座 第56回 構造化特性アクション

日本とアメリカで企業文化が異なるのは周知の事実ですが、日本でも会社によって随分と文化が違うのと同じように、アメリカでも会社によってかなり異なります。
有名な例としては、東海岸（ボストンやニューヨークがある方）と西海岸（ロスアンジェルスやシリコンバレーがある方）の文化的違いです。
筆者は両方の企業での勤務経験があるのですが、これからお話します事は非常に印象的な光景として脳裏に残っています。

今から十数年前、シリコンバレーのベンチャー企業に勤めていた折、その会社の経営幹部のX氏（その当時55歳ぐらいでした）が、エンジニア達と雑談していた時に、話題が、X氏が昔立ち上げた企業の話になりました。
その企業は、比較的順調に成長して最終的にIBMに買収されることになり、Ｘ氏はIBM社にVP（バイスプレジデント）として迎えられる事になりました。
Ｘ氏がIBMのVPになると言う話を聞いて、当時存命中であった彼のご母堂はたいへん喜んだそうです（IBMは、その頃、東部エスタブリシュメントを代表する企業でした）。
さて、X氏が、IBM本社で開催される経営会議に初めて参加した時の事です。
彼は、張り切って、会議室に一番乗りで向かい、他のメンバーが来るのを待っていました。
ちなみ、X氏は特異な風貌をしており、靴下は真っ赤で、大柄のジャケットを着け、ネクタイはいつもミッキーマウス柄のものが好みで、一見するとサーカスのピエロのようなフレンドリーな印象を与えます。
この日は、彼はいつもよりもさらに（彼の流儀で）粧し込んで会議に臨んだそうです。
ところが、ダークスーツ姿の他のVP達は、入室するやX氏を見ると驚いたように目を背け、誰も彼には声を掛けず、まるでX氏がその場に居ないかのような態度を取ったそうです。
ここまでの話は、筆者にとってもさほど驚く話ではなかったのですが、驚いたのは、むしろこの話を聞いていたエンジニア達の反応です。
X氏が、「VP達が全員席につき、CEOがお付の人間を従えて厳かに入場してきた。そして、CEOが議長席に着き、おもむろに話を始めると、驚いたことに、全員がノートを取り出し、いっせいにメモを取り始めたんだ。」と言うと、聞いていたエンジニア達は大爆笑し、中には机を叩いて苦しそうに身もだえするほど笑っている人もいました。

次にお話する話も、90年代初頭の昔話です。

東部と西部で企業文化が変わると言いましたが、西部地域の同じシリコンバレーであっても、企業文化はまちまちです。
最も東部的だと言われたのは、CPUを作っているインテル社です。
今は知りませんが、当時はインテル社のマネージャは（驚いたことに）いつもネクタイをしていると言うことで有名でした。
一般的に言って、大きな工場を持つハードウエア中心の会社の経営者やマネージャ達は、俺は金を持っているんだと言わんばかりのキンキラの格好をしていないと社員になめられると言われています。
フォーマルさを基準として数直線を引くと、最も厳格なのがインテル社になり、シスコ・システムズあたりがその真ん中の中点辺りに位置し、ソフトウエア中心の企業になればなるほど、カジュアルな会社になって行き、アップル社はかなりくだけた部類に属しました。
そして、その当時最もくだけた会社として最右翼にランクされた会社がタンデム社であり、くだけた事で有名なカリフォルニア人たちをして、「もはや、会社の体をなしてない」と言わしめたほどでした。
タンデム社は、その後、他社に買収されて行きました。

5-5 構造化特性アクション

図 １１−０７

UML1.Xでは、オブジェクトは単純な構造でしたので、属性を読み取ったり（ReadAttributeAction)、書き込んだり（WriteAttributeAction)という簡単なアクションで済んでいたのですが、UML2.Xで構造化分類子が登場し、単に属性の読み書きでは不十分になった結果、この構造化特性アクションが導入されました。
基本的には、対象のオブジェクトにたいし、その構造的特性を読み書きするためのアクションですが、具体的には、ReadStructualFeatureAction、WriteStructualFeatureAction、ClearStructualFeatureActionの３つのサブクラスが意味を与えています。

UML中級講座 第55回 TestIdentityAction

昨日、Mac OSの上でWindowsを走らせる話をしましたが、さっそく友人から、そんなややこしい事をせずに、初めからWindowsを使って書けばいいじゃないかと言う指摘を受けました。
当初から予想されたリアクションですが、それに対して答えるのは難しい問題です、と言うよりも、Windows使いの方に納得してもらえるような答え方がない、と言った方が正確でしょう。

筆者は、学生時代に、いくつかのパソコンを経て、往年の名機Apple IIにたどり着き、その素晴らしい設計思想に感動したくちです。
そして、卒業後入社したところで、これも名機として名高い初代IBM-PCに遭遇しました。
IBMは、現在ではPCを作るのを止めてしまったようですが、この初代IBM-PCは、その後20年以上にわたって、PC産業に多大なる影響を残しています。
Apple IIやIBM-PCには、単なる機械を超えた何かがあり、20数年経って登場したMacOSにも、その息吹を感じると言ったら、Windows使いの方には、納得して頂けるでしょうか？（無理ですね、すみません）

５−４−３ TestIdentityAction

入力ピンに置かれた2つのオブジェクトが同一のものかどうかを調べます。同一であればtrue、そうでなければfalseを出力ピンに置きます。

５−４−４ ReadSelfAction

すべてのアクションは、振る舞いもしくは振る舞いの一部であり、振る舞いは何らかの分類子の特徴です。（例えば、操作は何らかのクラスの特徴）
このReadSelfActionは、アクションが行われる主体（ホスト・インスタンスと呼ばれます）を、出力ピンに置くアクションです。
これは、パラメータの情報だけではアクションの主体が特定できない時などに、ホスト・インスタンスにアクセスするために付け加えられたアクションです。

また、親のオブジェクトが存在しないときは、振る舞いそのものがホスト・インスタンスとなります。
図11−06

UML中級講座 第54回 DestroyObjectAction

筆者はこのブログをアップル社のパワーブックを使って書いているのですが、インターネットユーザーの大部分はマイクロソフト社のインターネット・エクスプローラーを使用して見ているとのことですので、時々確認のために手持ちの古い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中級講座 第53回 CreateObjectAction

先日、たまたま仕事上で、このブログを時々覗きに来ているとおっしゃる方とお会いした折、「制約条件に反した状況が発生した場合は、UMLはどういう風に振る舞うのか？」というご質問を頂きました。
皆様の参考にもなるかと思いますのでので、ここにその点をコメント致します。
UMLの仕様上、一般的に、制約条件に違反した場合の振舞いは規定されておりません。
例えば、本日取り上げるCreateObjectActionは、指定された分類子（クラス）からオブジェクトを生成するアクションですが、当然の事ながら、指定された分類子（クラス）は具象分類子（具象クラス）で有る必要があります。
仮に、その制約を破って、抽象分類子が指定された場合、処理方法は規定されておらず、結果は予想不能の状態になります。
文法と言う観点からいえば、明らかに文法違反であるため、わざわざ規定する必要がないので無規定としているわけです。

５−４−１ CreateObjectAction

CreateObjectActionは、指定された分類子に適合するオブジェクトを生成し、それを出力ピンに置くアクションです（オブジェクトそのものが戻り値になります）。
このアクションは、単にオブジェクトを生成するだけであり、初期値やリンクを設定したり、ステートマシンの遷移を引き起こしたりと言った副作用を全く伴いません。

【制約】

• i 分類子は抽象クラスではあってはならない。
• ii 分類子は関連クラスであってはならない。
• iii 出力ピンの多重度は１。


図１１−０６

UML中級講座 第52回 オブジェクトアクション

前回、適用アクションのお話をした時に、このメタクラスは標準化の過程で無くなってしまった、と言うお話をしました。
標準化の過程で仕様が変更されていくのは、ある意味当たり前のことですが、時と場合によっては非常にはた迷惑な現象を引き起こすことがあります。
世の中には、様々な分野に数あまたの標準化の組織があり、中には無能としか呼びようのない団体も事実存在します。（心当たりのある関係者の方、ごめんなさい。他意はございません。個々人に対する個人的な批難ではありません。）
そして、UMLの標準化を行なっているOMGと言う団体の評価はと言うと、私の知る限り、世界の最高水準にある良い団体だと思います。
市場や社会に混乱を巻き起こすダブルスタンダードを生み出さず、適度に早く、また優れたプロセス・コントロールでマネージされています。
私の感じる所は、技術的水準の高さもさることながら、そのマネジメント能力の高さです。
往々にして、標準化団体は、テクノロジー・マネジメントに関する能力に関して疑問符がつく場合があり（国内外を問わず公務員主導型の場合は、特にそういう気がします）、策定された多くの標準が低い評価のまま終わってしまっています。
前回取り上げた適用アクションは、標準化プロセス上、Final Versionの１つ前のFinal Adaptation版と呼ばれるバージョンの仕様に掲載されていました。
この版は、一般にはツールベンダー・レディのバージョンとして知られ、これは、この版を元にツールベンダーは開発を開始しても良いと言うバージョンにあたります。その後の変更は、極めてマイナーな変更に限定されます。
そして、このFinal Adaptation版の発行以降は、変更要求は、次のバージョン（UMLの場合だと、UML第2.1版）で議論されることになります。
ちなみに今回の適用アクションに関する変更は、ツールベンダーに僅かな影響を与えただけで、ユーザーレベルでは、なんの違いもありません。（ツールベンダーレベルで吸収可能な変更です。）

さて、前置きが長くなりました。
本日から、オブジェクトアクションを議論して行きましょう。

5-4 オブジェクトアクション

図 １１−０６

オブジェクトアクションは、図１１−０６に示される4つのアクション、CreatObjectAction、DestroyObjectAction、TestIdentityAction、ReadSelfActionの総称です。
ただし、これらの４つのアクションには構造上の共通性がないので、特段共通のスーパーメタクラスは定義されていません。
次回以降、個別にこれらのアクションを見てゆきます。

UML中級講座 第51回 適用アクション

本日は、特殊なアクションについてお話します。
どういう意味で特殊かと言いますと、OCUPインターミディエート資格試験が始まった時点では、「適用アクション」と言うメタクラスが存在していたのですが、その後の改定作業で最終版の言語仕様から除かれてしまったのです。
と言いましても、言語が大きく変わった訳ではありません。

たとえて言いますと、システム設計の最中に、「猫用の餌」クラスのサブクラスとして、「オス猫用の餌」クラスと「メス猫用の餌」クラスを作ったが、設計が進むにつれて、わざわざ区別する必要がなくなったので、これら2つのサブクラスを後になって削除したようなものです。
ただ、本講座の想定水準としておりますOCUP資格試験のカバレッジ・マップ上にはまだ残っておりますので一応解説をしておきます。

5-3 適用アクション

適用アクションは、OCUPインターミディエート資格試験の試験範囲が発表された時点では存在していたのですが、最終仕様からは削除されております。
しかしながら、今の時点で、出題される可能性が残っておりますので、概要を触れます。

5-3-1 ApplyFunctionAction

適用アクションに属する具体的なアクションは、このApplyFunctionActionの1つだけです。ApplyFunctionActionは、入力情報のみを使って出力を計算するアクションで、メモリー等へのアクセスもなく全く副作用の発生しないものです。
元々は、モデル化対象のシステムの外側にある振る舞いを呼び出すために導入が検討されましたが、パッケージのスキーム変更により、特段定義する必要がなくなり、最終版仕様書からは除かれました。
注意すべき点としては、適用アクションそのものが存在しなくなったのではなく、名前を付けて区別する必要性がなくなったと言う点です。

UML中級講座 第50回 BroadcastSignalAction

昨日は、来日中のOMG会長、マーク・ソーリー博士が、OCRESの説明をされると言うことで、会場の大手町まで行ってきました。
今回の来日スケジュール中には、BPM(ビジネス・プロセス・マネジメント）やSOA(ソリューション・オリエンテッド・アークテクチャ）の会合も開催されておりましたが、私自身の都合が付かず、OCRESの説明会にのみ参加してきました。
ソリーさんは、これまでもよく日本に来られておられましたが、特にこのOCRES（リアルタイム系、組み込み系スペシャリストの資格試験）は、日本の要望に焦点を当てたものであり、今後ますます日本で彼の姿を見ることができることでしょう。

さて、本日はInvocationActionの最後として、BroadcastSignalActionを取り上げます。

５−２−４ BroadcastSignalAction

BroadcastSignalActionは、シグナルのインスタンスを生成し、システム内のすべてのオブジェクト（＊）に送信するアクションです。（その結果、ステートマシンの遷移が起こったり、アクティビティの実行が開始されたりしますが、それらについては、ステートマシン図およびアクティビティ図の章を参照してください。）

このアクションは送信が終了すると直ちに完了し、ターゲットオブジェクトからのリプライメッセージや戻り値は、全く無視されます。
（＊注： 何をもって、すべてのターゲットオブジェクトとするかは、前提とするシステムのセマンティクスに依存します。）


図１１−０５

UML中級講座 第49回 SendObjectAction

深夜のワールドカップの観戦後、つい深酒をしてしまい、今朝が辛かった方もいらっしゃるのではないでしょうか？（私も、その一人です。）
さて、本日は、昨日のSendSignalActionに続き、SendObjectActionについて解説します。
このSendObjectActionの典型的な例としては、アクティビティ図中のオブジェクトフローが挙げられます。

SendSignalActionでは、Signalの分類子が入力になり、それをインスタンス化してターゲットに送りますが、SendObjectActionでは、インプットがオブジェクトであり、それをターゲットに送ります。
従って、もし既にインスタンス化されたSignalを送りたい場合は、このSendObjectActionを用います。


５−２−３ SendObjectAction

SendObjectActionは、オブジェクトをターゲットオブジェクトに送信するアクションです。（その結果、ステートマシンの遷移が起こったり、アクティビティの実行が開始されたりしますが、それらについては、ステートマシン図およびアクティビティ図の章を参照してください。）

このアクションは送信が終了すると直ちに完了し、ターゲットオブジェクトからのリプライメッセージや戻り値は、全く無視されます。

オブジェクトおよびターゲットオブジェクトは、入力ピンで与えられます。
また、入力ピンのオブジェクトをそのまま送るケースもあれば、コピーを作成して送るケースもありますので（オブジェクトフロー参照）、入出力のオブジェクト間のアイデンティティは保証されません。


図１１−０５

UML中級講座 第48回 SendSignalAction

ワールドカップが始まり、今夜はいよいよ日本対オーストラリア戦です。

５−２−２ SendSignalAction

SendSignalActionは、シグナルのインスタンスを生成しターゲットオブジェクトに送信するアクションです。（その結果、ステートマシンの遷移が起こったり、アクティビティの実行が開始されたりしますが、それらについては、ステートマシン図およびアクティビティ図の章を参照してください。）
このアクションは送信が終了すると直ちに完了し、ターゲットオブジェクトからのリプライメッセージや戻り値は、全く無視されます。

【制約】
❑ i 引数ピンの数、順番、タイプ、多重度は、シグナルの属性と一致


図１１−０４

UML中級講座 第47回 CallBehaviorAction

九州は昨日梅雨入りしたそうですが、皆さんのお住まいの地域はいかがでしょうか？
東京地方は、朝から雨が静かに降り続いています。

さて、 本日は、CallBehaviorActionについて、解説致します。

５−２−１−２ CallBehaviorAction

CallBehaviorActionは、昨日解説したCallOperationActionが呼び出し要求をオブジェクト（自分自身のオブジェクトを含む）に送るのに対し、直接振る舞いを呼び出すアクションです。
典型的にはアクティビティの呼び出しがこれに当たります（アクティビティ図の章を参照）。

非同期型の場合、振る舞いの呼び出しを行なった時点でアクションそのものは完了し、その後の振る舞いは並列処理になり、仮に呼び出された側に戻り値が発生したとしても呼び出した方には渡されません。

同期型の場合は、呼び出した振る舞いからリプライが戻るまで待機し、戻り値は結果ピンに置かれます。
例外が発生した場合は、呼び出した側に例外が送られます。

【制約】
❑ i 引数ピンと、呼び出される振る舞いのinおよびin-out型のパラメータの数は等しい。
❑ ii 結果ピンと、呼び出される振る舞いのoutおよびin-out型のパラメータの数は等しい。
❑ iii 引数ピン、結果ピンのタイプ、順番、多重度は、呼び出される振る舞いのパラメータに等しい。


図１１−０４

UML中級講座 第46回 CallOperationAction

本日は、CallOperationAction、いわゆる操作の呼び出しに相当するアクションのメタモデルの解説をします。

５−２−１−１ CallOperationAction

CallOperationActionは、操作を呼び出す要求を、ターゲットのオブジェクトへ送るアクションです。
引数の値は、呼び起こされた振る舞いによって使用されます。
同期型の場合は、呼び起こされた振る舞いが完了し、リプライが呼び出し側に返ってくるまで待機します。
またリプライの値は、結果ピンに置かれます。呼ばれた側に例外が発生した場合は、呼び出した側に例外が送られます。
非同期型では、操作の呼び出しのあと、呼び出し側と呼び出された側の振る舞いは、並列処理になり、仮に呼び出された側の操作に戻り値があったとしても、呼び出し側には渡されません。

【制約】
❑ i 引数ピンと、操作のinおよびin-out型のパラメータの数は等しい。
❑ ii 結果ピンと、操作のoutおよびin-out型のパラメータの数は等しい。
❑ iii ターゲットピン（ターゲットオブジェクトを指定する入力ピン）は、操作の所有者のタイプと同一。


図１１−０４

UML中級講座 第45回 CallAction

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' メタクラス）の引数の数、順番、タイプ、多重度は（注＊）、呼び起こす振る舞い、もしくは振る舞い特性のパラメータと一致しなければなりません。

（注＊）振る舞いや操作のパラメータは、順序付きのリストとなります。

UML中級講座 第44回 呼び出しアクション

アクションは、振舞いの基本単位であり、本章では、メタクラスの解説を中心に行なって行きたいと思います。

5-2 呼び出しアクション ( Invocation Action )

図１１−０４

図１１−０５

呼び出しアクション ( InvocationAction ) は、振る舞いを呼び起こす様々なアクションの総称です。これ自体は抽象メタクラスであり、具体的な事柄はCallAction、SendSignalAction、SendObjectAction、BroadcastSignalActionの4つのサブクラスで規定されています。

UML中級講座 第43回 第5章 アクション

今回から、第5章アクションです。

5章 アクション
5-1 アクション概説

アクションは、振る舞いを規定する上での最も基礎的な単位であり、通常はいくつかの入力と出力から構成されます。
メタモデル図では、これらの入力や出力がそれぞれ入力ピン（InputPin)、出力ピン（OutputPin）という分類子によって表されます。
大部分のアクションは、実装から独立した振る舞いを定義しています。
これらのアクションは、１）計算をする、もしくは２）対象のオブジェクトのメモリーへアクセスする、のどちらか一方だけを行う極めて原始的なレベルまでブレークダウンされています。
これにより、振る舞いの定義の、精密性・正確性を維持する為の下部構造（インフラストラクチャ）の定義が可能となります。
通常のコンピュータ言語はこれらを組み合わせたもう少し複雑な体系をしておりますが、これは、アクションパッケージで定義されたごく原始的なアクションを組み合わせることにより構築できます。

UML中級講座 第42回 コネクタ（コンポーネント図）のメタモデル

昨日に引き続き、コンポーネント図で用いられるコネクタのメタモデルについて解説致します。
モデリングの手法として、最初に形式やパターンを決め、その後に意味を細かく定義するというアプローチがあります。
これは、ソフトウエアのモデリングだけではなく、ビジネスモデリングにも用いられる普遍的なアプローチです。

そして、コンポーネントの定義にもこのアプローチが用いられます。
最初に複合構造図で、フレームワーク（形式）を定義し、コンポーネントはそれを継承して意味を付け加えて行きます。
なお、コンポーネントの最終的な表現対象は契約（別の言い方をするとサービス）です。
インターフェース条件さえ合致すれば、コンポーネントは契約（サービス）を実現します。
コンポーネントの章の始めにCBD「契約に基づく開発」のお話をしましたが（第29回参照）、この契約はソフトウエアコンポーネントだけではなく、ビジネスコンポーネントも視野に入れた形で定義されています。
以前「SOAについて」と言う表題で、SOAの4つのレイヤーに触れましたが、上から2つ目のレイヤー、「ビジネス・サービス・レイヤー」の主役はビジネス・コンポーネントです。このコンポーネントは、UMLのコンポーネントを拡張して定義されます。

４−２−２ コネクタのメタモデル

図０８−０３

コネクタは基本的に複合構造図で述べたものと同じですが(第26回参照）、コネクタの種類として（ConnectorKind)、アセンブリと委譲の2種類が追加されています。

UML中級講座 第41回 コンポーネントのメタモデル

本日と次回の2回で、コンポーネント図のメタモデルを解説します。

４−２ コンポーネントのメタモデル

４−２−１ コンポーネント

図０８−０２

先に述べたとおり、コンポーネントは複合構造図で触れたカプセル化クラスを継承しています。
そして、提供インターフェースと要求インターフェースを持つことができ、実現のための分類子を所有しています。
図０８−０２の中の「realization」は、提供インターフェースや要求インターフェースと言う名前で規定される契約（別の言い方をするとサービス）を、分類子を用いて「実現する」と言う概念です。
このrealizationは、サービスを実現するために内部に包含する分類子（プロパティやコネクタ、本講座第25回参照）とカプセル化クラス自身との所有関係の間に挿入された形で表現されます。
つまり、カプセル化クラスは、単に、内部にプロパティやコネクタと言った分類子を所有していると定義され、コンポーネントでは、さらに、それら内部分類子との間に、（契約やサービスを）実現するための関係（「realization」の関係）を結んでいるという言い方が出来ます。
「realization」は、UMLモデル図上では、依存関係の一種として扱われます。