UML中級講座 第101回 ステートマシンのメタモデル

最近は、組込み系のソフトウエアが話題に多くのぼるようになってきました。
自動車の開発コストも、既にソフトウエアの方がハードウエアを凌駕してしまい、品質・コストにおける重要度は増す事はあっても、当面減ずることはないでしょう。
かつては、自動車のエンジンはアナログ技術のかたまりであり、今では信じられない事ですが、1970年代になって、エンジンの制御をマイクロ・プロセッサで行なう試みが為された時も賛否両論が渦巻いたと聞きます。

何を持って時代の推移を最も感じるかは人によって異なると思いますが、アナログからデジタルへの移行は、ここ数十年のテクノロジーの時代変化を象徴する一つのエポックだと思います。

筆者は、70年代を、関西の港町で過ごしましたが、街に初めてシンセサイザーがやってきた時のときめきは今でも忘れ難いものがあります。
あの頃のシンセサイザーは巨大で、訳の分からない電線がのたくって繋がっており、真空管のほのかな光りは、当時の高校生の目には神秘的にさえ映りました。
その当時、年長者の方は、電子楽器そのものを嫌う人が多かったのですが、我々の世代だとあまり抵抗がありません。
しかし、シンセサイザーも真空管から半導体になって小型化し、アナログだったものがすべてコンピュータ制御になった今、アナログ式、真空管式のシンセサイザーに郷愁を感じるのも事実です。
筆者の自宅にも一台、キーボード型のシンセサイザーがあり、たまに弾いてみたりするのですが、音や機能に何の不足もないのですが（恐らく、高校時代初めて遭遇したシンセサイザーの数百倍の機能があると思います）、あの頃感じたときめきは残念ながらよみがえって来ません。

ステートマシンのメタモデル

図15-02はステートマシンのメタモデル図です。
各項目は、既に取り上げたものが多いので、本日は、このメタモデル図上のエレメントで、本講座で触れなかった点を中心に解説したいと思います。

ステートマシンは、最低１つの領域（リージョン）を持ち、領域内にはいくつかの状態や疑似状態を持ちますが、メタモデル中では、状態と疑似状態をまとめて頂点（Vertex)と呼んでいます。
各頂点は遷移で結ばれており、遷移は、トリガー、ガード条件（Contraint)、アクション（Behavior）を持ちます。また、状態には、入場アクション、出場アクション、Doアクティビティなどの振舞いを伴う事が可能です。

疑似状態に関しては、ターミネートを除いて、全て解説しましたので、ここではターミネート(terminate)のみを解説します。

ターミネート疑似状態

ターミネートは特殊な疑似状態であり、ターミネート疑似状態に入ると言うことは、ステートマシンの実行が終了してしまう、あるいは実行主体のオブジェクトが終了してしまう事を暗示し、いかなる状態へも遷移せず、出場アクションも実行されません。
ターミネート疑似状態に入る事は、以前解説したDestroyObjectActionを呼び出す事と等価に扱われます。
ターミネート疑似状態は、図D19の(h)で示される記号" × "で示されます。


図１５−０２

図D19

UML中級講座 第100回 選択（チョイス）疑似状態

先月の終わり頃に、携帯電話の番号ポータビリティがスタートし、携帯電話の話が職場でも盛んに行われるようになりました。
筆者も、以前電話会社に勤務していた事もあり、今でも電話には関心が高い方です。
しかしながら、筆者のまわりは、携帯電話に無頓着な人が多く、中には自分が使っている電話会社が分からないと言う人までいます。
何でも、昔、祭りの縁日か何かで携帯電話を只で貰い、その後、電話会社の名前がころころ変わって行って、覚えられなくなってしまったそうです。
どのキャリアを選ぶかは、極めて個人的な好みや条件の問題であり、たとえ世間的に評判が良くても、自宅など自分が使いたいと思った所で使えなければ無価値です。
筆者の場合は、繋がりやすさはもちろんの事、比較的、音声の品質や遅延の小ささにも拘る方ですが、元電話会社社員として、決してカタログや仕様は鵜呑みにせず、実地に比較しないと気が済まない方です。

以前は、普通の携帯電話とPHSを両方使っていたのですが、最近はPHSしか使わなくなりました。
これは、筆者のオフィスや自宅が、電波の混み合う都心に近いせいであり、PHSが比較的電波の混雑に強い特性を持つ結果だと思います。
また、ワイヤレス電話機を出発点として簡易電話としてスタートしたPHSが、様々な悪条件を技術的に克服して行き、以前は移動体上では殆ど使えなかったものが、今では十分に実用に耐えるようになり、また、電波の密集する地域での技術的チャレンジを克服して行く姿は、まるで「プロジェクトX」のノンフィクション版を見るようで、思わず応援したくなります。
事実、特定の方向にしか電波を送らない方式など、広い地域に渡って強い電波を発して周波数帯を占領してしまう一般の携帯電話に比べ、日本の国土事情に合ったテクノロジーだと思います。
と、書いて行くうちに思わずPHSをべた褒めしてしまいましたが、先に書きましたように、携帯電話の選択は、個人的な好みと条件の問題ですので、ここに書いた事は、あくまで参考意見程度に。

選択（チョイス）疑似状態

選択疑似状態は、出力側のガード条件を動的に評価し次の状態が決定されます。
これは、動的条件分岐と呼ばれ、第98回で触れたジャンクションとは、異なった振舞いをします。
選択（チョイス）疑似状態では、出力側の複数のガード条件が満たされた場合には、次にどのパスをたどるのかは非決定的であるのに対し、ジャンクションでは、条件が満たされる全てのパスが有効になり、複数の状態へ遷移します。
また、選択（チョイス）では、出力側の全てのガード条件が満たされない場面は許されず、必ず一つは条件が満たされる必要があります。（そのために、elseと言うキーワードを使用する事が可能です。）
図D22は、選択疑似状態の表記例です。
右側が、通常の表記方法ですが、この例のようにガード条件のオペランドが共通の場合は、左図の様に、共通するオペランド（この例では Id )を、選択疑似状態シンボルの中に記入し、ガード条件でオペランドの記載を省略する書き方も許されます。


図D23

UML中級講座 第99回 フォークとジョイン

随分前になりますが、このブログで、Intel Macのお話をした事がありました。
その時に、モバイル用のPHSモデムがIntelMacに対応しておらず、オフラインの状態になってしまったと書きました。
実は、筆者もそのことをほとんど忘れていたのですが、先日お会いしたある方に、その後どうなりましたかと聞かれ、多少はこのブログの読者のお役に立つのではないかと思い、後日談をお話したいと思います。
と言うのも、その方も、IntelMacとPHSモデムの問題に直面し、ネットで解決方法を検索しているうちに、偶然このブログを発見し、それ以降、時々覗くようになったそうあり、他にもそう言う方が多そうな気がします。
ネットの統計資料を見ると、各種サーチエンジンで、IntelMacとかPHSモデムの名前で検索した結果、このブログにたどりついたと言う方が、筆者の事前の予想を超えて、結構いらっしゃいます。

さて、IntelMacとPHSモデムAH-F401Uの問題ですが、モデム側でIntelMacをサポートする気配がないため（本日再度確認したのですが、サポートはまだのようです）、結局、このモデムを使うのをやめ、手持ちのPHS電話WX300KをパソコンにUSB接続して使っています。
こちらも、実はメーカーやキャリアの正式サポートがある訳ではなく、個人の方がネット上に公開されているドライバーを見つけて、ダウンロードして使わせてもらっています。
この個人のサイトへ直接リンクを張るのは憚れるのですが、ネット上で検索して行くとすぐに見つかると思います。
公式なものでもサポート付きでもないのですが、何の問題もなく、非常に良くできたソフトだと思います。改めて、作者の方に感謝申し上げます。（と言っても、作者の方は、このブログを見てないと思いますが。）

フォークとジョイン

フォークとジョインは、アクティビティ図でも同じ記号、同じ名称で使われていますので、直感的にも捉えやすいと思います。

フォーク

フォークは、入力側の遷移を、複数の直交領域、即ちコンポジット・ステートの異なるリージョンへの遷移に転換します。
出力側には、ガード条件やトリガーを付ける事はできません。

ジョイン

複数の直交領域からの遷移をまとめます。入力側にはガード条件やトリガーを設定する事は許されません。


D22

UML中級講座 第98回 ジャンクション

秋もだんだんと深まり、今日の東京地方は快晴で、紅葉にはまだ早いものの、久しぶりに秋らしい一日でした。
先ほど乗ったタクシーの運転手さんが青森県の出身で、車中、十和田湖の紅葉の素晴らしさを熱弁されておられたせいもあり、筆者もそぞろ紅葉の映える風景を見たくどこかへ行きたくなって来ました。
残念ながら、青森県地方はもう紅葉のシーズンは終わってしまい、初冬となってしまったようですが、皆様の中には紅葉を愛でながら過ごされている方も多いと思います。

さて、紅葉で思い出したのですが、今から十数年前、秋のカナディアンロッキーを訪れた際の紅葉は、日本のとは随分趣が異なり、暴力的とも感じるほどの力で、大自然が紅葉する姿に圧倒され、しばしぼう然として見とれてしまいました。
迫力ある紅葉に加え、秋のつるべ落としもすさまじく極端で、まわりに街灯が全くないせいもあって、日没後はあっという間に真っ暗闇になってしまい、ほとんど這うようにして駐車場までもどり、やっとの思いで車までたどりついた時は、心底ほっとしました。

ジャンクション

ジャンクションは、遷移を表す辺の合流・分岐点で、図D21の様に小さな黒丸で表します。
遷移は、トリガー、ガード条件、アクションから構成されます。
図中のState0からジャンクションへの遷移を例として見てみると、e2が遷移を引き起こすトリガーとなるイベントを示し、b<0がガード条件となります。この図では、遷移に伴うアクションはありません。


図D21

UML中級講座 第97回 入場/出場ポイント

昨日、お話しました物作りに強く関係しますが、OMGでは現在、組込み系の資格試験であるOCRESの準備をしております。
組込み系の試験と言っても、現在様々なものが実施もしくは実施予定されていますが、OCRESは、基本的にアーキテクチャ中心の試験であり、他の試験のカバレッジとは、ほとんどかぶりません。

良く言われるように、システム開発は、複雑度が増すにつれて、次のような3段階を経ます。

１）コーディング中心、コーディングが全ての世界
２）デザインが必要な段階、デザインの良し悪しが重大なインパクトを与える
３）アーキテクチャ的アプローチが必要な段階、アーキテクチャが品質を決めてしまう段階

そして、OCRESは、２）と３）の段階のデザイナーやアーキテクトに必要な能力を評価する試験です。

入場/出場ポイント

入場ポイント、出場ポイントは、図D18の(a)や(c)のように、ステートマシン図やコンポジットステートの境界線上に描き、入場もしくは出場の遷移を表します。
また、図D18の(b)や(d)の様な書き方も許されます。（(a)と（ｂ）、（ｃ）と（ｄ）は等価です。）


図D18

UML中級講座 第96回 疑似状態

海外へ行くと痛感するのが、日本の強い経済力のありがたさです。
様々な国籍の人々が行き交う中、同じような能力を持ちながら、国による貧富の差が如実に出て来てしまうのも国際社会の現実です。
現在、日本人が国際社会の中で豊かな部類に属するのは、決して経済学者や政治家が優秀な訳ではなく、畢竟、物作りの強さである事は、万人の認める所です。
しかしながら、その物作りの面でも、後進の国々に追いせまられています。

有名な韓国企業の経営者の講演を聞く機会があったのですが、韓国のその企業は長年、日本企業に追いつこうと日本企業のまねを一生懸命やっていたそうですが、アナログの世界では、いくら一生懸命やっても中々追いつけなかったそうです。
しかしながら、時代が移り、ディジタルの世界になった途端、あっという間に日本の背中が見えてきたそうです。

疑似状態

疑似状態は、ステートマシンの中での様々な遷移を抽象化したものです。
本日から数回に分けて、疑似状態を見て行きたいと思います。

図D19

開始疑似状態

図D19の(a)は、開始疑似状態のシンボルです。コンポジット・ステートでのデフォルト状態への遷移を表します。また、この遷移にアクションを定義する事も可能です。（入場アクション）
一つの領域（リージョン）は、最大1個の開始疑似状態を持ちます。

履歴

図D19の(b)と(c)は、履歴を表す疑似状態です。

深い履歴
深い履歴は、コンポジット・ステートの最後にアクティブであった状態（もしくはその組み合せ）への遷移を意味します。
当該コンポジット・ステートが、一度もアクティブになった事がない場合は、デフォルト状態へ遷移します。
コンポジット・ステートは、最大一個の深い履歴を持ちます。
また、他の遷移と同様に、入場アクションを定義できます。

浅い履歴
浅い履歴は、コンポジット・ステートの最後にアクティブであった直近の下部状態（サブステート）もしくは、その組み合せへの遷移を意味しますが、直近のサブステートの更に下にあるサブステートは無視されます。（場合に応じ、サブステートのサブステートはデフォルト状態へ遷移します。その下も同様。）
他の条件は、深い履歴と同じです。

UML中級講座 第95回 終了状態

昨日のブログで、高層ビルの最上階にあるフィットネス・クラブの話を書きましたが、そのプールの窓の真下に、TBSと言う放送局があります。
関東平野にお住まいの方以外には、放送波が伝播しないので、なじみがないかも知れませんが、筆者の年代ですと、ウルトラＱやウルトラセブンと言った往年の名作を放送した放送局であり、こういう形の再会には、中々感慨深いものがあります。
恐らく、数十年前、ウルトラＱを非常に斬新に感じていた頃の日本では、プールの窓越しに放送局を見下ろす風景は、未来都市そのものだったと思います。（放送局のビルそのものも、決して低い建物ではありません。）

終了状態



終了状態は、図D17のシンボルで表されます。
この記号は、アクティビティ図のアクティビティ終了ノードと同一です。（意味は、もちろん違います。）
歴史的に言いますと、アクティビティ図は、元々、状態遷移図風に定義されていたのが、UML2.0になって、状態遷移図から完全に離れた経緯があります。
従って、終了状態以外にも、ステートマシン図とアクティビティ図では、非常に良く似たシンボルが使われています。
終了状態は、属する領域（リージョン）が完了している事を示しています、全ての領域が完了している場合は、それを包含する状態は、完了していると見做されます。

図D17

UML中級講座 第94回 遷移

最近は、書き物系の仕事が多く、生活が深夜帯のデスクワーク中心になってきたために、以前にも増して運動不足の状態に陥ってしまっております。
幸いにも、先日、オフィスの近所にフィットネス・クラブがあるのを偶然見つけ、さっそく入会しました。
以前ですと、このような出費は、馬鹿馬鹿しく感じ、飲み代に廻した方がましだと考えていたのですが、年のせいか、周囲に身体の不調を嘆く人も出始めて来ており、病院代だと思えば安いと、素直に払う気になりました。
入会したフィットネス・クラブは、都市部のそれらしく、高層ビルの最上階にあり、プールで泳ぎながら、外の風景を見下ろしたりしていると、一種不思議な感じがします。

遷移

遷移は、「遷移を引き起こすトリガー」、「ガード条件」、「遷移に伴うアクティビティ」の3つの要素によって定義され、一般的に、ステートマシーン図中では、トリガー名［ガード条件］/アクティビティ名の形で表現されます。
しかしながら、図D15の様に、トリガーをシグナルの表現で表す事も可能です。（プレゼンテーション・オプション）
また、同図のように、遷移に伴うアクティビティを、アクションを示す4角形や、シグナル送信（通常は、イベントの発生を意味し、そのイベント発生が他の遷移を引き起こすトリガーになる事ができます）の形で表現する事が可能です。


図D15

遅延可能トリガー

遅延可能トリガーは、トリガーの発生が保存され、別の状態への遷移があった時に再現される特殊なトリガーです。（遅延トリガーがさらに遅延される事も可能）
そして、遅延トリガーが受け入れ可能になり、遷移を引き起こすまでプールされます。
遅延トリガーは、トリガー名の後ろに、'/'とキーワード’Defer'を付けて表現します。
図D16は、［明かりが消える」トリガーは、2度遅延され、「コーヒーを注ぐ」状態への遷移を引き起こすまで、プールされる事を示します。


図D16

UML中級講座 第93回 ステートマシーンの拡張

先月末に、新しい街にオフィスを移転したのですが、ようやく慣れて来た感じです。
本来は、都内の別の場所に移る予定だったのですが（お茶の水近辺が第一候補でした）、いくつかの偶然の結果、最後の最後に赤坂に移る事になりました。
六本木や渋谷、新宿に比べ、赤坂は何となくマイナーな感じがしていたのですが、住めば都で、移転して一月も経つと、なかなか住みやすい街だな、と思えるようになってきました。
そのうちに、赤坂の紹介記事も書いて見たいと思っております。

ステートマシーンの拡張

一般の分類子と同じ様に、ステートマシーンも般化が可能です。
特化されたステートマシーンでは、元のステートマシーンの全てのエレメントを引き継ぎながら、かつ、遷移や状態、領域（リージョン）の追加や再定義が行われます。これによって、シンプルなステートマシーンを、（リージョンの追加、再定義により）コンポジット・ステートマシーンに特化する事も可能です。
同じように、内部のサブマシーンを別のサブマシーンに入れ替える事も可能です。その場合は、少なくとも、元の入口点/出口点と同一の互換性を維持する必要があります。（入口点/出口点の追加は可能）

ステートマシンの特化の事を、拡張（Extend)と呼び、拡張されたステートマシーンである事を、指し示すために、キーワード"Extended"が使われます。

図D13は、元のステートマシーン（ATM)、図D14は拡張ステートマシーン（ ATM{Exteded})を表しています。
図D13の中で、キーワード{final}が付いた状態がありますが、これは、これらの状態が最終形である事を示し、拡張や再定義ができない事を示しています。
図D14では、Ｄ１３のステートマシーン「金額読取」に状態と遷移が付け加えられ、金額の選択だけではなく、入力も可能なように、拡張されています。

図D13

図D14

ディズニーランドとOMG

先週末より、OMG総会出席のため、USに来ております。
今回の総会の開催地は、カリフォルニアのディズニーランドに隣接するホテルであり、週末は他に行く所がなく、自然と2つのテーマパークに入り浸る形になってしまいます。

ディズニーランドは、いち早くMDA(Model Driven Architecture)の採用を決め、OMGのスポンサーにもなっており、今回の総会に対しても様々な便宜を提供してくれています。
昨日は、OMGのChairman's Dinnerがディズニーランド内の特別なレストランで開催されましたが、これもその便宜の一環です。

ディズニーランドの魅力の一つは、テーマパークの内外に謎や秘密がちりばめられていることです。
ご存知の通り、テーマパーク内では、アルコール類は一切販売されておらず、持ち込むことができませんが、一ヶ所だけ例外があり、それがこのレストランです。
ディズニーランドは、今から50年前に開設されましたが、このレストランはその当時からある建物の中にあります。
実は、テーマパーク建設の頃ディズニーランドは大変な資金難に陥り、外部の投資家の資金援助を仰ぐため、その投資家達を饗応するためにこのレストランが建てられたのだそうです。
外部から見ると、他の建物となんら見分けがつかないのですが、テーマパークを行き来する人たちを見おろすテラスに、ワインなど飲み物を持ち出すことは厳禁されています。
調度品も、ウオルト・ディズニー氏ゆかりのものが置かれています。

風景的には、全く溶け込んでおり、そこにレストランがある事さえ気がつかないのではないかと思います。（少なくとも、筆者は、前日にそのレストランのある建物の前を何度も通ったのですが、全く気付きませんでした。）

2006年9月27日

UML中級講座 第92回 サブマシン状態

最近は、身辺慌ただしく、たまにはのんびりと、普段読めないような種類の本を持って温泉にでも行きたいなと思っていた所、来週、OMG総会出席のためアメリカに出張することになりました。

願望として持っていた旅と１７０度くらい違っているタイプの旅ですが、場所がディズニーランドの中と言うことで、多少息抜きができると、心密かに期待しております。（ここに書いた以上、密かではなくなってしまいますが）

また、OMG総会の様子も、今後触れたいと思っております。

サブマシン状態

サブマシン状態は、他の状態マシンを参照して表される状態です。
図D09は、サブマシン状態の例を示しています。
サブマシン状態の状態名は、状態名：参照されたサブマシン名 の形式で記述され、図D09で４は、状態名が［失敗処理」、参照されたサブマシン名が「失敗SM」であることが示されています。
サブマシン状態には、入口点（entry point)、出口点（exit point）をつけることができ、入口点、出口点の名前は、参照されたサブマシンの入口点、出口点と一致する必要があります。
また、図D09のエラー３の様に、無名の入口点（もしくは出口点）が示された場合は、サブマシンのデフォルトの入口点（出口点）を、意味することになります。
この図の出口点、SubEndから出た場合は、修復１を実行することになります。
また、これらの表現は、コンポジット状態にも使用可能です。（ただし、サブマシン名への参照は、当然の事ながら除きます）

サブマシンの表記

図D10と図D11は、サブマシンの表記です。
通常の状態マシンと同じ表現を取ります。
また、出口点は、状態マシン内に記述したり、境界線上に記述したり（Ｄ11）できます。

図 D09

図 D11

UML中級講座 第91回 直交状態

直交状態 (Orthogonal State)

複合状態には２種類あります。
１つは単純状態（Simple State)と呼ばれ、前回の図D05の様に、リージョンが１つしか存在しないものです。
もう一つは、直交状態(Orthogonal State)と呼ばれ、複数のリージョンを持ちます。
図D08は、直交状態の例です。

図D08

なお、この直交状態(Orthogonal State)という名称ですが、他の分野では、恐らく、量子力学か幾何学でしか使わない単語だと思います。（先ほどWebでちょっと検索してみたのですが、正式な用語としてはこの２つの分野だけしかなさそうでした。）
語源的には、恐らく、量子力学の方が直接の親だと思いますが、数学と量子力学は用語がクロスオーバーして使用されていますので、これ以上の詮索は意味がないように思います。
何れにせよ、直交状態と言うのは、状態の集合が直交している、あるいは、任意の状態は、一つのイベントにより次の状態がただ一つだけ定義されていることを意味します。

UML中級講座 第90回 複合状態

今週は、にいがた産業創造機構の高度IT人材育成支援のための研修で、新潟市内に滞在しております。
新潟県は、IT分野における先進の人材育成に大変熱心な県であり、筆者もここ3年連続して、講師を務めております。
昨年までは、新潟に来るタイミングが、台風の水害の直後であったり、大地震の直後であったりと、災害の直後に訪問するパターンが続いており（前回の研修の時は新幹線が止まっており、大きく迂回して新潟にたどりつきました）、今年も、来る前は、実は内心心配だったのですが、今回は天候にも恵まれ素晴らしい新潟を満喫することができました。

新潟県人と言いますと、まず思い浮かぶののは、その勤勉性です。事実、東京では、銭湯を経営している方の大部分が新潟出身であったと言う話を聞いたことがあります。（風呂屋は、かつては重労働できつい仕事として有名でした。）
また、個人的な体験としても、以前、越後湯沢にスキーに行った折、居酒屋で出会った人が、夏は農業を営んでいるが、冬場は、昼間スキー場でインストラクターをやり、夜は知り合いの店で皿洗いのバイトをしたあと、さらにコンビニの店番までやっていると言うのを聞いて、つくづく、その勤勉さに感心した事があります。
前回の研修では、地震の直後だったにも関わらず、被災地の方からも受講生の方がお越しになり、熱心に受講される姿を見て、感銘を受けました。
新潟県の企業も、粘り強く、社内にUMLを浸透させようと、毎年多くの受講生を送り込んで来られる所があります。

さて、勤勉性の話ばかりになりましたが、新潟県は食べ物も美味しい所です。
まず、日本酒が最高に美味しく、様々な種類のものが楽しめます。有名な所では八海山や越の寒梅などから、小さな蔵元が少量を出荷しているだけの（東京では）幻に近い銘柄のものまで、数多く存在します。

魚も、東京では出回らない「のど黒」が今旬であり、刺し身、焼き物、煮物と最高です。また、下越の村上市は、鮭の料理の種類が多いことでも有名です。

複合状態（コンポジット・ステート）

図D05は、複合状態の例を示しています。
ダイヤリングと言う状態の中に、さらにスタートとダイヤル途中と言う2つの下位状態（サブステート）を持っています。

図06は、内部のサブステートを記述するかわりに、隠されたサブステートが存在することを示す記号（数学の∞に似た形状のシンボル）を使って、複合状態であることを示しています。

また、図D07は、リージョンの表記例で、状態 S は、リージョン毎に別々の独立した下位状態と遷移を持ちます。

UML中級講座 第89回 状態

状態

UMLで扱うステートマシンは、有限の離散的な状態をもつものに限定されます。（状態を無限に持ったり、連続的な状態を扱うことはできません。）
また、UMLでは、振舞いステートマシーンとプロトコル・ステートマシーンの2種類がありますが、本講座では振舞いステートマシーンの方を主に取り扱います。

状態には、次の3種類があります。

シンプルステート ： 下位状態を持たない単純な状態です

コンポジット・ステート： 状態の中に複数の区画（リージョン）があり、それぞれが状態（下位状態）を持ちます。

サブマシーン・ステート： ステート・マシーンの中に、さらにステートマシーンがあります。セマンティックス的には、コンポジット・ステートと同等です。

状態の表記

状態は、図D02のように角の丸い四角形として表します。また、図D03のように、状態名をタブで表記することも可能です。

図D02

図D03

コンパートメント表記

状態は、図D04の様に、コンパートメント表記することが可能です。
コンパートメント部分は、トリガー / アクションの形で表します。
トリガー名として、前回触れましたように、entry、exit、doがあらかじめ予約語として定義されています。
図D04

UML中級講座 第88回 第8章 ステートマシン図

第8章 ステートマシン図
本日から、第8章 ステートマシン図に入ります。
ステートマシン図は、昔から良く使われている状態遷移図をオブジェジェクト指向風に再定義した物で、直感的にも非常に解りやすい図です。
図D-01は、ステートマシン図の例です。
角の丸い四角形は状態を表しており、図中には「活動状態」と「待機状態」の2つの大きな状態があり、「活動状態」はさらに複数の下位の状態（サブステート）を持っています。
矢印は、状態の遷移を示しており、トリガー［ガード条件］/ アクションと言う表記を行ないます。
また、状態の中をさらにコンパートメントに分解することができ、トリガー/アクションと言う形で細かいアクションの指定が可能です。
図中の［タイムアウト」の状態では、do/メーッセージ案内 と言う記述がありますが、このdoは、一種の予約語で、その状態にある間は指定のアクションを取り続けなさいという意味になります。
他の予約語として、entry(その状態に入った時に取るべきアクションを指定）と、exit(その状態から出る時に取るべきアクションを指定）などがあります。
また、状態を示す四角形以外に黒丸の図形がありますが、これは疑似状態と呼ばれ、厳密には状態ではなく制御記号であり、黒丸は開始状態と呼ばれ、開始時に取る状態を指し示すために用いられます。
また、二重黒丸は終了状態で、これは疑似ではなく本物の状態です。（終了状態は、ステートマシンの終了を意味し、これ以降終了以外のいかなる状態へも状態遷移しません。）

図 D-01

UML中級講座 第87回 インタラクション・ユースのメタモデル

インタラクション・ユース

インタラクション・ユースは、インタラクション・フラグメントの一種です。
インタラクション・ユースは、C言語などのファンクション・コールと同じように、記法の省略形と見なす事ができ、インタラクション・ユースを用いないで等価のインタラクションとして書き表す事が可能です。
また、参照する共通のインタラクションを複数の場所から呼び出す事が可能です。
その場合は、引き渡す引数により参照されるインタラクションの動きや結果が変わってきます。
図14-０９は、インタラクション・ユースのメタモデルで、参照するインタラクション（実際のセマンティックスを決定します）と引き渡す引数を持っています。（図中のアクションは、引数を引き渡すためのアクション）

また、生存線のパート分解は、インタラクション・ユースの一種です。

図14-０９

UML中級講座 第86回 ゲートのメタモデル

ゲート

ゲートは、インタラクション・フラグメント間をつなぐ接続点で、メッセージ端の特別な形です。
ゲートは、役割に応じ、フォーマル・ゲート、アクチャル・ゲート、エクスプレッション・ゲートの3種類があります。

フォーマル・ゲート ：
インタラクション（フラグメント）のゲートです。

アクチャル・ゲート ：
インタラクション・ユースのゲートです。インタラクション・ユースのゲートは、それを参照するインタラクションの（同名の）フォーマル・ゲートに対応します。

エクスプレッション・ゲート ：
コンバインド・フラグメントのゲートです。

ゲート名は、省略する事が可能です。

図14-08

UML中級講座 第85回 インタラクション図のメタモデル

インタラクション・フラグメント

インタラクション・フラグメントは、直感的にはインタラクション図そのものを示す包括的な抽象メタクラスです。
セマンティクス的には、イベントのトレースと同等のものになります。
図14-07は、インタラクション・フラグメントを定義するメタモデルのうち、コンバインド・フラグメントを説明する部分だけを切り出したものです。
コンバインド・フラグメントは、インタラクション・フラグメントの一種であり、インタラクション・オペレータと言う属性を持ちます。（属性は、alt、opt等の値を取ります。）
また、コンバインド・フラグメントは、インタラクション・オペランドを持ち、オペランドは、インタラクション・フラグメント（つまりあらゆるインタラクション）とインタラクション制約を持つ事が可能です。
オペランド自身が、インタラクション・フラグメントを所有するので、あらゆる形の入れ子が可能になります。
また、テクニカルなモデリングですが、Continuationもインタラクション・フラグメントの一種として定義されています。

図14-07

UML中級講座 第84回 コラボレーションとインタラクション図(2)

日本人は資格好きと言われますが、確かに歴史能力検定とか漢字能力検定とかの話を聞くといかにもと言う気がします。
一般的に、儒教の影響が強い国は資格好きだと言われていますが、欧米でも社員の採用の際には資格は大きな力を発揮します。
その資格として最も有名で顕著な例が、MBAです。
MBAと言っても、ある一定レベルの大学院以上でないとあまり効果は発揮しませんが、筆者が見聞きした例でお話ししたいと思います。
例えば、マーケティングマネジャーを外部から採用する際、ほとんどの会社ではMBAは必要条件の一つとされ、持っていないと書類選考の段階でどんどん落とされて行きます。
MBAを持っているから優秀だとは誰も思っていませんが、不適格の人材を採用するリスクを軽減するための措置で、その証拠に、内部からの登用ではあまりMBAは重視されず実績第一で審査されます。
また、80年代のMBAがまだ希少価値があった時代と違い、MBAだからと言ってエリートコースを歩める保証はありません。
純粋に入場切符を手に入れたに過ぎません。
そして、入り口切符としてのMBAの威光が効くのはせいぜい３０代半ばまでであり、それ以降は経歴の方が重要視されて行きます。

筆者は以前シリコンバレーの会社でマーケティングの仕事をしていた事がありますが、その当時の上司はハーバードのビジネス・スクール出身で、また、同僚達の大部分はスタンフォードやMIT等の有名大学のビジネス・スクールの出身者達でした。
マーケティング部門では、MBAを持っている事自体はエリートでも何でもなくただの入社資格だったのです。
そして、面白い事にほぼ全員が理工系くずれでした。
理学部や工学部を卒業し、何年か会社勤めをした後、ビジネススクールに入ったと言う人ばかりで、それが一種の標準パターンでした。（ビジネススクール側も、実務経験者の入学を歓迎しています。）

コラボレーション・ユースとインタラクション・ユース

前回、コラボレーションとインタラクション図の関係をお話しましたが、本日はその具体例を見てみましょう。
図C13では、コラボレーションの例として”売買”を示しています。
買い手の法人組織Aと売り手の法人組織Bが、それぞれ小売店と卸業者にバインドされています。
下の図では、それらがインタラクション・ユースの形で表現されています。

図C13

UML中級講座 第83回 コラボレーションとインタラクション図

最近は、IT業界も活況を呈してきており、どこの会社も大忙しのようです。
しかしながら、この好景気もかつてIT産業が経験してきたものと少し性質が違ってきているようです。
IT業界はかつては好不況の景気の波の影響をほとんど受けない業界として有名でした。
以前は、売上など毎年上がるのが当たり前で、前年を割り込むなんて言う事態は想像の外でしたが、しかしながら、今では珍しい事ではなくなって来ています。
そして、その好不況の波に最も影響を受けているのが、システム・インテグレーターの様です。
システム・インテグレーターは（日本では特に定額請負が多く）プロジェクト自体のリスクが高い上に、少し景気が悪くなると一番最初にストップするのが新規開発案件であるため、業態そのものが高リスクな体質になっています。
また、ハードウエアに続き、最近ではソフトウエアも値段が下がりつつあり、ものによってはただで、通常の商品より良いと言うものまで出回ってきております。
従って、どこのシステム・インテグレーターも生き残り策を熱心に巡らしているようですが、すべてに共通して見られる現象は、サービスに対する強い志向と言えるでしょう。

コラボレーションとインタラクション図

インタラクション・ユースは、コラボレーション・ユースと強い関係があると述べましたが、本日は、その表記例を見て行きましょう。

図C12は、コラボレーションが分類子に適用される様を表現しています。
コラボレーションWは、superAとsuperBと言う二つのクラスからなるパート（xとy）を持っており、クラスEの内部構造に示されるクラスAとBは、それぞれクラスsuperA、クラスsuperBを特化したものです。
クラスEは、コラボレーションWを適用したコラボレーション・ユースw1を持っており、ｘとｙの二つのパートが
クラスのインスタンスである:Aと:Bに結びつけられています。
下の図は、それをインタラクション図で表現したものです。

図C12

UML中級講座 第82回 複合構造図とインタラクション図

複合構造図とインタラクション図

複合構造図が導入されるまではクラスは単純な形をしていましたので、必然的にインタラクション図も単純ですんだのですが、UML2.0以降になって、インタラクションに内部構造を持った分類子が参加して来るようになり、表記も変わってきました。

パート分解

パート分解は、生存線の内部構造を表現するインタラクション・ユースの特殊形で、コネクタブル・エレメントがインタラクションの参加者として登場します。
（コネクタブル・エレメントは、複合構造図の開設時にほんの少し触れましたが、コラボレーションは、コネクタブル・エレメント間の関係として定義されます。）

図C11は、パート分解の例で、(a)で AC_UserAccessと言う名前のパート分解を呼び出しています。
図(b)のp1とp2は内部のコネクタブル・エレメントを表し、そして、直接"Please Enter"と言うメッセージをインタラクション・ユースの外側に送信しています。
（参考： この様なフラグメントを、エクストラーグローバル コンバインド・フラグメントと呼びます。）

図C11

UML中級講座 第81回 インタラクション・ユース（２）

昨日に引き続き、インタラクション・ユースについて解説致します。

図C09は、インタラクション・ユースを呼び出す例です。
Establish Access("不正なピン番号”）と言う風に、インタラクション・ユースに入力パラメータを渡す事が可能です。
この図の場合、不正なピン番号を渡していますので、オプションのコンバインド・フラグメントは実行されずドアは開かれません。（ただし、厳密には、この図ではオプションの実行条件が明示されていませんので、曖昧な形になっています。）

また、出力パラメータの結果の値や、インタラクション・ユースが値を返す場合の戻り値を、コロン（:）の後ろに書く事が可能です。

図C09

図Ｃ１０は、結果の戻り値が記述された例です。
まず、a_op_ｂ自身がインタラクション・ユースであり、戻り値を返すことに注意して下さい。（戻り値の型Verdictは、判定結果（合否もしくはpassとfailを表すタイプです）
そして、戻り値自身が生存線としてインタラクションに参加しています。

動きとしては、まずa_util_bというインタラクション・ユースを呼び出す際、s1とｗの2つの入力パラメータを渡しており、さらにwは出力パラメータとしても働き（入出力パラメータ）、その結果が12である事が示されており、さらにa_util_bの戻り値が９で返され、その値がxx.xcに代入されます。
その次の代替コンバインド・フラグメント（”alt"のオペレータを持つコンバインド・フラグメント）では、結果に応じて、a_op_bに値がセットされる事が示されています。

図C10

UML中級講座 第80回 インタラクション・ユース

本日は、インタラクション・ユースについて解説します。

インタラクション・ユース

以前は、インタラクション・ユースは、インタラクション・オカランスと呼ばれていましたが、用語の一貫性の観点から改められました。
語感的には、オカランスは、イベント・オカランスに代表されるように、メッセージの送受信など、事象の発生に焦点を当てたものに使用され、ユースは、ユース・ケースやコラボレーション・ユースなどのように、役割に焦点を当てた場面で使用されます。
インタラクション・ユースは、感の鋭い方はお気付きと思いますが、コラボレーション・ユースと深い関係があります。
さらに言うと、コラボレーションの別の表現と見なす事が出来ます。
インタラクション・ユース内の参加者は、個々のインスタンスを表現しているのではなく、参加者の役割を表現しています。

図C08

図C08の図(b)は、インタラクション・ユースの表現例です。
この図のインタラクション・ユース"N"の参加者、":B"や":C"は、個別のインスタンスを表しているのではなく、インスタンスの役割を表象しています。
従って、インタラクション・ユース"N"が複数回呼び出された場合、登場するインスタンスは、呼び出される度ごとに異なっている可能性があります。（もちろん同一の場合もあります。）
個々のインスタンスは、呼び出す側が決定する形になります。

UML中級講座 第79回 Continuation

このブログに掲載している図は筆者が書いたものではなく、以前弊社に勤務していたモンゴルからの留学生の方にまとめて書いておいてもらったものを使用しています。
現在、彼女はアメリカ留学中ですが、最近になってつくづく書いておいてもらって良かったと感謝しています。
ブログも７０回を超えると、だんだん書く事が負担に感じつつも、読んで下さる方がいらっしゃる事を唯一の励みとして続けておりますが、図まで自分で書いていたら、きっと15回目ぐらいでやめていたと思います。

Continuation

Continuationは、代替コンバインド・フラグメント（”alt ”のついたコンバインド・フラグメント）中で用いられるラベルで、アクティビティ図中のコネクターと同じように、同じラベルが付いたContinuationに制御がジャンプします。
従って、完全に表記法上の問題と言えるでしょう。
図C07は、Continuationの使用例で、図(a)のQestionは、図(b)で表されるインタラクション・ユースを呼び出し、図(b)の代替コンバインド・フラグメントの"OK"から、図(a)の"OK"へ制御がジャンプし、図(b)の"notOK"から図(a)の"notOK"へジャンプする事を示しています。
図(c)は、(a)と(b)をまとめたもので、全く等価の振舞いをします。

図C07

UML中級講座 第78回 Par / Critical

突然梅雨前線が消滅したと言う事で、本格的な夏がやってきたようです。
筆者は神戸市（兵庫県）で生まれ育ったせいか、海と山が同時に見えない風景になんとなく圧迫感を感じますが、夏は特にその傾向が強いようです。

どういう風景に安心感を感じるかは、十代をどこで過ごしたかによって大きく左右される様な気がします。
筆者の知り合いで、以前は都会で暮らしていましたが、今は信州の八ケ岳に住み着いている人がおります。
その人の子供たちは既に成人しておりますが、幼年期をビル街で過ごした割には、十代を過ごした雪を頂いた高山の風景がないと落ち着かないと言っております。

図 C06

Par

Parは、オペランドの並列処理を意味しています。
各オペランドは、互いにインターリーブされて処理されます。
イベントの発生の観点から言いますと、各オペランドのイベントは次々に混在して発生して見えますが、しかし、一つ一つのオペランド内では、General Orderingのルールは守られます。

Critical

Criticalは、コンバインド・フラグメントが、クリティカル・リージョンである事を示しています。
クリティカル・リージョンでは、それを内包するインタラクション・フラグメントのイベントがインターリーブする事が出来ません。
図C06は、クリティカル・リージョンの例で、メッセージm5の受信後、m6の送受信が終了するまでは、クリティカル・リージョンの上位のフラグメントのイベントがインターリーブする事は出来ません。

UML中級講座 第77回 Consider / Ignore

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}も不変定数と呼ばれる制約で、実行時に評価され偽となるトレースは誤りである事を意味します。

UML中級講座 第76回 コンバインド・フラグメント

昨日に引き続いて、コンバインフラグメントの解説を行ないます。

コンバインド・フラグメント

opt

optは、コンバインド・フラグメント自身を実行するかしないかの選択がある事を示します。
セマンティクス的には、オペレータが”alt”で、2つ目の（elseの方の）オペランドが空っぽである状態と同値になります。

図 C03は、その表示例です。

図 C03

break

breakは、コンバインド・フラグメント中にブレーク・ポイントがある事を示します。
通常は、ガードと共に用いられ、ガード条件が成り立てば（真になれば）後続部分は全く無視され、成り立たなければ（偽になれば）後続部分が実行されます。
breakオペレータを持つコンバインド・フラグメントは、内包する生存線を最後までカバーする必要があります。

図 C04

また、breakオペレータを持つコンバインド・フラグメントで、ガードがない場合の振舞いについては規定されていません。（どのように振る舞うかは、非決定的）

UML中級講座 第75回 第7章 相互作用図

本日から、第7章の相互作用図に入ります。
インターミディエート試験では、相互作用図の扱いは比較的軽く、

コンバインド・フラグメント、
ゲート、
インタラクション・ユース（以前は、インタラクション・オカランスと呼ばれていたもの）

の３つが主な範囲になります。

第7章 相互作用図
7ー1 コンバインド・フラグメント

7-1-1 コンバインド・フラグメント例 alt

図C01

図C01は、コンバインド・フラグメントの1例で、コンバインド・オペレータが ”alt”であるケースを示しています。
コンバインド・フラグメントは、種類を示すオペレータ部分と、動作を示すオペランド部の2つからなります。
また、オペランドが複数ある場合は、セパレータ（図中の点線）で区画を分けて表示されます。

図C02は、オペレータが”alt”のケースのコンバインド・フラグメントのフレームを示しており、何らかの条件が成り立つ時はオペランド①を実行し、成り立たない時は②を実行します。

図C02

UML中級講座 第74回 例外のメタモデル

まだ梅雨が終わらない様で、東京地方は朝からずっと雨です。
涼しくて過ごしやすいと言えば言えなくないのですが、梅雨が終われば、八ケ岳か北アルプスなどに出かけようと思っている身には、普段にもまして、夏の太陽が恋しく感じられます。

さて、本日は例外を扱うためのメタモデルを解説致します。

ExceptionHandler メタモデル

図１２−２３

ExceptionHandlerは、前回示しましたように、ジグザグの矢印で表現されます。
図12 - 23は、ExceptionHandlerのメタモデルを表しており、2つの実行可能ノード(ExecutableNode)と関係を持ち、１つが保護ノード（protectedNode)で、もう一方がhandlerBodyの役割を持ちます。

Bodyの入出力
Bodyに対する入出力を示すエッジを明示的に表現する必要はありません。
例外が発生した時には、保護ノードに対する入力と同じものをHandlerBodyが受け取り、例外処理が終わった後のBodyの出力が、保護ノードの出力として後続ノードへ渡されます。
従って、後続ノードの立場では、Bodyでの例外処理が終わった時点では、保護ノードでの処理が終わった状態と全く同じ様に見えます。

メタモデル図上の、ExceptionTypeは、例外の型を示す分類子です。（桁あふれや0による除算など）

UML中級講座 第73回 例外

梅雨の末期、彼方此方で豪雨のニュースを耳にします。
皆様のお住まいの地域はご無事でしょうか？
本日は、例外について解説致します。

6-7 例外

例外処理の表記を図A11(a)にします。
保護ノードで例外が発生した場合は、直近の構造化（アクティビティ）ノード内のすべてのトークンは終了し、例外のタイプに応じて、HandlerBodyが実行されます。
もし、直近のノード内に該当するHandlerがない場合は、より上位のノードに処理が渡されて行きます。
最上位のシステムレベルへ行っても該当するHandlerが見つからない場合のシステムの振舞いは無規定です。（プロファイルでこのようなケースが発生した場合の処理を指定する事ができます。）

(a)のジグザグ線の表記は、(b)で示される形で表記する事が可能です。

HandlerBodyの処理終了後は、保護ノードの後続ノードに処理が渡ります。（この指定を行なうためのエッジは記述する必要はありません。）

図（c)は、ExceptionHandlerの例です。
X/Yを計算する際、０による割り算が発生した場合は、右上のHandlerBodyが呼ばれ、Zに”無限”を代入後、印刷のノードへ処理が渡ります。
X とＹのかけ算の際、桁あふれ例外が発生した場合も同様に、例外処理後は、保護ノードの次のノードである印刷のノードへ処理が渡ります。


図 A11

UML中級講座 第72回 構造化アクティビティノード

本日は、構造化アクティビティノードについて解説致します。

6-6 構造化アクティビティノード
構造化アクティビティノードは、内部にアクティビティを含むノードです。

図 A10

内部のアクティビティの形式によって、コンディショナルノード、ループノード、シーケンスノードの3種類があります。
内部の従属するノードは、必ず１つだけの構造化アクティビティノードに所属し、他の構造化アクティビティノードと従属ノードを共有する事はできません。
また、エッジに関しても、ソース側、ターゲット側の両端は必ず同一の構造化アクティビティノード内で有る必要があります。

コンディショナルノード

図A10(a)は、コンディショナルノードで、複数の節（clause)から構成され、１つの節は テスト ： ボディーの形をしており、テスト部分に指定された条件が成り立つ時のみボディー部分が実行されます。
複数のテストが真を返した場合でも、実行されるボディーは一つだけですが、どのボディーが実行されるかは特段の条件がない限り（例えばテストの実行順序の指定など）予測出来ません（非決定的）。
またすべてのテストが偽を返した場合には、ボディーは実行されません。
複数のテストが真を返したり、すべてのテストが偽を返したりするする事態は、セマンティクス上の誤りである可能性はありますが、文法的には許されます。

コンディショナルノードのメタモデル

属性

isAssured : trueの場合は、 モデラーが少なくとも１つのテストが真を返すことを保証した状態を示す。
isDeterminate : trueの場合は、モデラーが最大１つのテストのみが真を返し、どのボディーが実行されるかが決定的である事を保証した状態です。

節(Clause)の間の関連（predecessorClauseとsuccessorClause)は、テストの実行順序を指定した場合の前後関係を示します。

ループノード

図A10(b)は、ループノードの形式を示しており、セットアップ、テスト、ボディーの三つの部分（アクティビティ）からなっています。セットアップ部分は、ループノードにトークンが入った時点で一度だけ実行され、その後は、テスト条件が真である限りボディーが実行されます。

ループノードのメタモデル

属性
isTestedFirst : trueの場合、最初のボディーの実行前にテストが実行されます。falseの場合、最初のテスト前にボディーが一度実行されます。

シーケンスノード

図A10(b)は、シーケンスノードを示しており、指定された順番にアクティビティが実行されるノードです。

図 １２−２１ 構造化アクティビティノードのメタモデル

図 １２−２２

UML中級講座 第71回 パーティションのメタモデル

本日は、パーティションのメタモデルについて解説します。

６−５−２ パーティションのメタモデル構造

❑ 図１２−１０

図１２−１０は、パーティションのメタモデル図です。（図中のActivityPartitionがパーティションを意味するメタクラスです。）
ActivityPartitionは、ActivityGroupを継承していますが、このActivityGroupは、ノードとエッジからなるグループです。
この図では、そのエッジとノードの関係を関連で再定義しています。
また、パーィティションは、内部にパーティションを含むことが出来ます。（サブパーティション）

【属性】
• isDimensionがtrueの場合、パーティション自身が他のパーティションに含まれていないことを意味します。
• isExternalがtrueの場合、パーティションが対象のシステムの外側の存在であることを意味します。

エッジ（ActivityEdge)に所有されるValueSpecificationはいわゆるガード条件です。デフォルト値はtrueで、即ち、無条件でエッジを通過すると言うのがデフォルトの解釈となります。

UML中級講座 第70回 パーティション

このブログは、時々外出先で書く事があり、本日は城山ガーデンにある緑茶専門の喫茶店で書いております。
本日の東京地方は朝から30度を超え、ようやくたどりついたこの店で、コンクリートを歩く男女をガラス越しに眺めながら、冷たい緑茶を飲んでほっと一息入れているところです。

さて、今回と次回はパーティションについて解説致します。
今回は、表記法をカバーし、次回はパーティションのメタモデルに触れる予定です。

６−５ パーティション
６−５−１ パーティションの表記

図A09

UML1.Xのアクティビティ図において、誰が各アクションを行うかを表示する手段として、スイムレーンが導入されましたが、UML2.0では、この表記方法がさらに拡大されパーティションと呼ばれるようになりました。
図A09の(a)は、パーティションを用いて、従来のスイムレーンの表記のを行った例です。各アクションの実行主体、グループはパーティションと呼ばれます。
パーティションはさらに細かいレベルまで分割することができ、サブパーティションと呼ばれます。図中のA,Bは、サブパーティションの名前です。
また、パーティションは、対象となるシステムの外側にいる人や組織なども表すことができ、それを示す記号としてステレオタイプ、<>が導入されました。図（a)のパーティション Cは該当システムの外側の存在であることを示しています。
UML2.0では、スイムレーン表記だけではなく、図(b)で示されるような多次元スイムレーン表記も可能となり、図(c)で示されるように各アクションノード内にパーティション名を記入することも可能になりました。なお、アクション内に記入する場合は、図のようにパーティション名を（ ）で括ります。
図(d)は、(b)と(c)の表記が混在した表現を取っています。この例では、実行主体として二つのクラス、「注文プロセッサ」と「会計係」が登場しますが、それぞれのパーティションが、「東京」と「大阪」の二つの地域に分けられています。この図で注意しなければいけないのは、東京の会計係のパーティション内に表示されている「支払い」アクションノードです。このアクションの実行主体は、東京の会計係ではなく、対象システムの外側にいる「顧客」であることが、ステレオタイプ<>から分かります。

なお、オブジェクトノードをパーティション間の境界線上に置くことは可能ですが、アクションノードを境界線上に書いてパーティション間で共有する形の表記は出来ません。（本来パーティションは、アクションの実行主体、グループを明記する為に導入されたものです。）

UML中級講座 第69回 コントロールノード

コントロールノードは、主に初級レベルでカバーされる分野ですで、本講座では、表記法の確認と、デシジョンノードの振舞いについて解説致します。

6-4 コントロールノード
❑ 図 １２−０９

図 A08


図１２−０９は、コントロールノードのメタモデル図を示しています。また、図A08は、各コントロールノードの表示例です。
• 各シンボルの名称は、(a)開始ノード (b)フロー終了ノード (c)フォークノード (d) ジョインノード (e)ディシジョンノード（分岐ノード） (f)マージノード（合流ノード）(g) アクティビティ終了ノード です。各ノードの振る舞いは、ファンダメンタルでカバーされる内容ですので、ここではメタモデル上に特徴のあるディシジョンノードについて解説します。

６−４−１ ディシジョンノード

ディシジョンノードは、一つの入力エッジと複数の出力エッジを持つコントロールノードです。
入力側、出力側のフローは、ともにコントロールフローであるか、もしくはともにオブジェクトフローであるかのどちらか一方であって、同一種類のフローが流れている必要があります。
また、出力側は必ず一つの経路のみが有効になるようセットしておくことが必要です。
図１２−０９のメタモデル図に表示されているように、ディシジョンノードには振る舞いが関連づけられています。
ディシジョンノードには振る舞いが対応しており、入力のデータトークンは、この振る舞いに渡され、この振る舞いの出力が各ガードに渡されます。
各ガードは、条件が満たされるときのみトークンを出力エッジに流します。（ガードの語源は、各出力エッジをガード(守護）しているところから来ています。）

UML中級講座 第68回 アクションノード

６−３ アクションノード
アクションノードはファンダメンタル資格試験でも扱われており、ここではファンダメンタルでは扱わない特殊なものを解説します。
❑ 図 A07

図（a)は、シグナルの受信アクション、図（ｂ）はシグナルの送信アクションを示しています。
通常のコントロールフローと異なり、シグナルは受信者側の都合に合わせて処理され、シグナルが届いたからと言って必ずしも後続アクションが直ちに開始されるとは限りません。
• 図（ｂ）は、時間に起因して起動するアクションで、入力側にエッジを持たないのが特徴です。
• 図（e)左は、アクティビティ呼び出しアクションを表しおり、右手のアクティビティを呼び出している様を示しています。
アクティビティ呼び出しアクションは、５章で触れたCallBehaviorActionの一種で、アクションノード内に熊手のようなシンボル（レーキ）を書いて表示します。

UML中級講座 第67回 ピン、セントラルバッファーノード

今回は、表記法に関する部分が大部分です。

６−２−２ ピンの表記

❑ 図A05

図(a)はピンの標準的な表記例です。
図（ｂ）（ｃ）のようにピンの内部に矢印を書き、インプットピン、アウトプットピンと明示的に表現することが可能です。

ストリーミングの表現

ストリーミングは、アクションを一々止めることなく継続的にオブジェクトが発信し続けられるオブジェクトフローの状態を指します。
図(d) (e) (f)はすべて、オブジェクトフローがストリーミングであることを示しています。
また、図（ｇ）では、一部のオブジェクトフロー、設計図、がストリーミングと指定されています。

パラメータセット

６−１節で述べましたように、アクティビティ図は基本的にジョイン的な振る舞いを原則とします。
従ってピンにおいても、すべての入力情報が到着したあとにアクションが実行され、また出力ピンはすべて同時に出力されます。
しかしながら、場合によっては、一部の入力ピンに入力があった時点でアクションを開始したい場合や、特定の出力ピンにのみオブジェクトを送りたい場合があります。
このようなときの為に、UML2.0では、パラメータセットという表記が導入されました。
パラメータセットは、図（h）のように、特定のピンの組み合わせを四角形で囲むことで表します。

６−２−３ セントラルバッファーノード

❑ 図 A06 （a)

すべてのオブジェクトノードにはバッファー機能が付いていますが、セントラルバッファーノードは、非常に特殊な機能を持ちます。
図A06(a)で示されているように、セントラルバッファーノードは複数の入力エッジと複数の出力エッジを持つことが可能であり、この図では二つの工場で製造された部品を蓄積し、一部の部品はそのまま使用し、使わない部品は箱詰めしている状態を表しています。

図 １２−０８ メタモデル図（セントラルバッファーノード）

このように、セントラルバッファーノードは、通常のオブジェクトノードを特化し、キューイングとフロー間の競合に新たな機能を付け加えています。