| 二章 リアルタイムのためのUML 使用する根本のコンセプトは何か？ Abstract： エンジニア達がますます直面している困難な問題がある。マーケットに出るまでの時間とコストの制約がますます増している中で、もっと精巧なリアルタイムシステムの開発を行わなければいけないことである。リアルタイムの領域でオブジェクト指向モデリングを採用することは、急速に変わる市場条件に直面するために必要不可欠といえる。主な障害は標準モデルが確立していないこととリアルタイムのニーズに対する誤解である。UMLの標準化で、一つ目の主な欠点はほぼ解決する。現在の仕事は、OMGによってリアルタイムの問題をまとめ、改良されているUML標準に乗っ取って行われており、主題への強い関心と、現在の提案では全く満たされず、互換性も無いことを示している。本章では、並列、動作および通信モデリングの支援としてUMLが何を提案するか、またさらに、量的リアルタイムの特徴(デッドライン、期間、特性のような)をどうすれば表現できるかを、詳細な項目ごとに説明することを目標とする。UMLとは別に、OMGは、リアルタイムに都合のいい2つの追加のグラフを指定した。予定、実行、時間グラフと、行動意味論グラフである。容量の都合により、この章ではそれらの内容について正確に記述するには至らず、両方のグラフの目的や内容を大まかに知るためにざっと目を通す事を目指す。最後にリアルタイムの記法によってUMLの根本的な可能性について詳しく述べた後、この章は大まかに、リアルタイムアプリケーション構築の為にどうやってその記法を使うかを示すための、予想される方法について説明する。 キーワード：UML、リアルタイム、同期、通信、動作 １．Introduction 数年前に、リアルタイムと組み込みシステムの市場は非常に独特で、 ｢機密の ｣部門と見なされていた。(ソフトウェアに基づいたシステムの国際市場の約5%)。今、ソフトウェア市場の発展に関して数々の研究がなされているが、それらは組み込みシステムが2003年を代表し、国際市場(パソコン、クライアントサーバおよび情報システムアプリケーションを含んで)の50％以上を占めるかもしれない事を考慮に入れている。 リアルタイムシステムの爆発的な市場と組み込みサービスの一定の増加によって、エンジニアたちはますます困難な問題に直面する事を強いられる。それはコンペから市場に出るまでの時間で精巧なリアルタイムシステムを開発せねばならず、また、コストの制約が日増しに増大していくことである。一方では、対象のハードウェアを前もって知ることができず、他方では、経済的な必要条件を満たすために、バージョンアップがますます速くなり、確実に市場への時間が徹底的に短くされるという社会において、ソフトウェアシステムの古典的なリアルタイム開発は限界に達している。再利用と発展性はモデル化する方法および開発技術にとって必須の必要条件になっている。そのような状況では、リアルタイムシステム開発は強い方法論的な支柱と付属のツールなしでは効率的に達成することができない。パラレルでは、オブジェクト指向の技術が、新しいアプリケーションから要求される柔軟性を首尾よく提供できる、十分なレベルに成熟した。しかしながら、リアルタイムのコミュニティーは今まで長い間このルビコンを横断することを拒んできた。主として次の二点の理由の為である。 ・オブジェクト指向の開発方法の状態は、方法やツールなどの解決策で十分に安定を提供できるほどには成熟していなかったこと。 ・リアルタイムの詳細は、一般的に既存の方法でうまく網羅されていなかったこと。 過去数年の間に、UMLは世界中のシステムモデラーの間で共通語になった。1997年のUML標準の出現で、多くのエディターが待っていたきっかけが現われ、そして新世代ツールの普及を可能にする第一歩が踏み出された。確かに、UMLのような標準の形式を備えたオブジェクト指向のモデリングは上で言及した問題に著しい解決策をもたらす。少なくとも、UMLはソフトウェア工学のための広範囲の基準、「デファクト」になっている。その上、オブジェクト指向の開発方法は、今はとてもよく以下の二つにニーズに適合している。 (1)コンポーネントに基づいた開発のために素晴らしいレベルのモジュラリティーを持っていること。 (2)サブシステムの再利用と保全性の特性を改善すること。 UMLとリアルタイムについては、OMG Platform Technology Commutteeはthe Analysis and Design PTF (AD PTF)とthe Realtime, Embedded, and Specialized Systems PTF (RTESS PTF)の両方の特別対策本部に関係がある。最初の特別対策本部はUML標準、SPEMやEDOCのようなUMLに直接関連した標準を担当している。後者の特別対策本部、RTESS PTFはOMG内で、リアルタイム、組み込み、フォールトトレラントシステムの必要条件のために既に標準化された技術を増大させ、リアルタイムの市場でCORBA技術を促進するために活動をしている。 UMLは方法ではなく言語である。本章の目的はリアルタイムの組み込みシステムをモデル化するためにUMLを使用する方法の紹介ではなく、あなたのアプリケーションのリアルタイムの特徴について記述する時に、UMLの中で利用できる特有の概念とは何かということだ。この後、本章の残りは4つの主だったセクションで構成されている。セクション2はリアルタイムの性質上のシステムの状況に取り組むことに費やす。しかし、セクション3では、UML標準において、あるアプリケーションのリアルタイムの量的特徴のモデル化をどうやって可能にするかを紹介する。セクション4ではACCORD/UMLと呼ばれる方法論を概説する。これはすべて、エンジニアが安全なリアルタイム組み込みシステムを構築することを可能にするという概念に基づいている。最後に、セクション5ではUML2.0やMDA方法論といった始まったばかりのUML革命を通して、OMGのリアルタイムの仕事と関係するある展望を提示する。 ２ QUALITATIVE REAL-TIME FEATURES このセクションでは、システムの質的な様相のモデル化のためにUML記法に注目します。この特徴たちは、測定されないかもしれないアプリケーションの全てのリアルタイム特性に関係があります。このため、それは並行性(並行処理とも呼ばれる)、コミュニケーション、振舞い、アクションに影響します。 ２．１ Concurrency Modeling 並行性の仕様は、これらのいくつかのものが本質的に同時に起こるため、リアルタイムのアプリケーションをモデル化する場合に取り組む重要な問題です。確かに、例題の[1]と[2]の定義によれば、“リアルタイム”は本来同時に起こる実世界とこのようなシステムが結び付けられることを暗示します。このセクションの焦点は、同時平行性のモデル化を支援するUMLの既成概念を記述することです。後に続くセクションに詳細が記述されていることから、本当に細かいレベル(オブジェクトの理論的枠組みを経由したクラスレベル)もしくは、並行性という特性の仕様を経由したオペレーションレベルのような細かいレベルにおいて、UMLによる並行性をモデル化することが先天的に可能であることが理解できる。 ２．１．１ Concurrency and Active Object アクティブオブジェクトの概念は、オブジェクト視点である[3],[4],および[5]を含む並行性の問題を統合するオブジェクト指向プログラミング言語のための方法である。このような研究の例は、[6]、Act++[7]、Hybrid[[8]、ABCL[9]、Argus[10]であり、もし、リアルタイムを統合したものが関係するならば、PRAT-RT[11]、DROL[12]、RTC++[13]、RTGOL[14]、TOM[15]、などである。 UMLでは、クラスが能動的かもしれないし、あるいは受動的かもしれない。メタモデルクラスは属性を能動的にしておきます（Class::isActive）。説明は以下のとおりです。 「Class::isActiveを指定すると、クラスのオブジェクト上でも自分自身のコントロールの道筋を維持して、同時に他のアクティブオブジェクトとともに実行することができる。もし、間違いがあれば、オペレーションは、アドレス空間の中で、および呼び出し側をコントロールするアクティブオブジェクトの管理化の下で実行される。」 UMLアクティブオブジェクトは活動的なクラスの例です。それらは、実行リソースを所有し、同時に呼び出されるような場合にオブジェクトの品質を保全するため、次に呼び出されるものをコントロールするためのメカニズムをもっている。 オブジェクトの図において、クラスや、オブジェクト（クラスの実例）のアクティブな特徴は、太線による長方形のシンボルで示すか、もしくはキーワードで直接示すかのいずれかである。（図２−１参照） さらに、UMLはアクティブクラスによって所有されていたコントロールの流れのタイプを指定するために他の2つのステレオタイプを定義します: <<process>>と<<thread>>。一つ目の<<process>>は、アクティブオブジェクトが‘コントロールの重い重量フロー’型のリソースを所有し、他のアクティブオブジェクトとリソースを共有しないで、それ自身のアドレス空間の中で実行されることを仕様とします。２つ目の<<thread>>は、アクティブオブジェクトが同じアドレス空間内で、他のアクティブオブジェクトが実行されるかもしれないことを仕様とする。 2.1.2 並行性およびステートマシン UMLでは、集合モデリングも並行合成状態とdo-activityの2つの方法によってステートマシン内で達成されるだろう。合成状態のメタクラスは並行性と呼ばれるメタ属性を保持している。真なら、これは直交の部分（いわゆるAND状態）で合成状態が直接分解されることを意味する。その振る舞いがAND状態によって記述されるモデル要素はそれらを同時に実行する。したがって、並行状態は、並列の実行を表現する手段と言える。 図2-2はステートマシン中の並行合成状態の使用を図解している。この場合、状態S1はS11とS12の直交の部分を同時に保持する。遷移t0が発火される場合、このステートマシンを保持するモデル要素は、並行中の状態S11かつS12に存在するだろう。 図2−2 並行合成状態の例 この章の目的はステートマシンの意味論について詳細な部分を記述することではないが、並行に関連することについて簡単に説明させてもらうと、UMLステートマシン意味論は、実行(RTC)から完成への仮定に依存する。要するに、後者のステートマシンは、一度に1つのイベントしか管理できないのである。しかし、並行状態に関連付けたことで、これらの意味論のニーズは明確にされた。UMLでは実際に、並行の部分の場合には、2つのケースが可能であると言われている:一つはRTCがすべてのステートマシンに適用されること。もう一つはこの強制がそれぞれの交わる部分で緩められ適用されるだろうということである。 do-ativityの概念を備えた可能な並行もまたステートマシン内で可能である。状態に入る場合、do-activityと呼ばれる特定の行為は、入る動作が実行を終えた後分岐される。この場合、2つの並行の起点が存在する: (1)一連の入れ子の状態に入る場合、do-activityシリーズは並行に分岐する。 (2)あるいはもし内部の遷移が「正常な」推移に対立するような特定の遷移のために発火された場合、do-activityシリーズはdo-activityを異常終了するべき状態出口を含んでいない。 図2-3の中で描かれた例において、State11が入力される場合に、状態1のdo-activityおよび状態11のdo-activityはどちらもそれぞれ分岐して、それぞれ手続きproc1とproc2の中で指定された動作を並行に実行する。 図2−3. 並行は複合したdo-activityの開始から発生する。 ２．１．３ Concurrency and Operation メタクラスオペレーションは、同じオブジェクトを同時に呼び出すという意味を指定する並行性を示す属性を持つ。この属性は、CallConcurrencyKind型であり、それは、一つの値(sequential, guarded, またはconcurrent)を持つことができます。クラスのオペレーションは、並行性を示す属性がもつ値によって3つのカテゴリーに分類することができる。 Sequential(連続)カテゴリーでは、１つのオペレーションだけが一度に（あるオブジェクトのために）実行することができる。しかし、システムはデフォルトによって、それらを保護しません。もし、二つの呼び出しが、二つのそのようなオペレーションに同時に行われる場合、オブジェクトの品質を保証することができません。しかしながら、むしろそれを実行するより、システムを設計するときには、このような仕様を指定することが役立つかもしれない。なぜなら、それを達成するために安全でも簡単でもないということがあるかである。 Guarded(保護)オペレーションでは、1つだけが、一度に（あるオブジェクトのために）実行することが許されます。しかし、制約はオブジェクト自体によって保護されている。これは、Guardedカテゴリーからオペレーションが実行されるときに、そのオブジェクトがGuardedオペレーションのための他全ての呼び出しを阻止することを意味します。どのようにこれを行うかというと、他のオペレーションをロックするために、それらを呼び出しているThreadをロックするか、UMLのセマンティクスに言及しないような役に立たないレスポンスを返すかする。UMLのGuardedオペレーションは、他の多くの平行性オブジェクトモデルに存在する保護状態であるメソッドと混同すべきではありません。 Concurrentカテゴリーでは、数多くのオペレーションが一度に活発であるかもしれません。また、オブジェクトの設計はオブジェクトの品質がこれによって破壊されないことを補償しなくてはなりません。 通常、このような特長は受動的なオブジェクトに関係があります。つまり、オブジェクトは、特性が”isActive=false”であるクラスから実例を挙げて説明する。アクティブオブジェクトは、かつてはそれらの振る舞いを指定する状態遷移機械にリンクされた。この場合、アクティブオブジェクトは関連する実行意味論により、同時呼び出しを処理することができる。 セクション2.3.1は詳細をこのポイントについて議論する。 2.1.4 並行および手続き 指定された並列の別の意味は、手続きの中で表される。これら後者はオペレーションやステートマシン遷移や、状態中の入る ･出る ･行うといった動作等の振る舞いを指定するのに使用される。アクションに関するUML教義は、並列の可能な限り最も高いレベルの許可に注目する。この原理によって、手続き中のすべてのアクションは、もし他の方法を指定されなかったならばデフォルトによって並行に走ると仮定される。その後、アクションは、データ・フロー明細によって暗黙に整列される。データ・フロー概念は、データ交換という2つのアクションが解釈によって順番に並べられることを意味する。消費者アクションは、実行されるために生産者アクションによって供給された入力データを必要とする。 2.1.5 Summary さて、UMLは様々な形式や異なるレベルの仕様で並行モデリングを支援する都合の良い言語である。並列は、オブジェクト間の並行によって保障されたシステムレベル（いくつかのオブジェクトが同時に並行に走る事が出来る）、あるいはさらにオブジェクトが一度に様々なものを実行できるオブジェクトレベルに導入されるかもしれない。前述された並行メカニズムを使用する上で一番の難所は、矛盾せずにそれらを一緒に使用することだ。そのような問題を解決するために、リアルタイムの領域に専心的な各方法論は、それらの間の選択を行なわなければならず、その選択が首尾一貫して適用されるために意味的な規則を明確にしなければならない。最後に、活発なオブジェクト概念ニーズは並行キャパシティーのステータスを固定するために明確にされる必要があり、つまり、それは一以上のコントロール用フローを有している。この問題についての私たちのポイントは、モデルができるだけ開くようにしておくべきということだ。また、並行がステートマシンにおいて可能なように、振る舞いがステートダイアグラムによって記述される実行可能なオブジェクトは、並行活動を内部で走らせることが出来るということになるそしてそのときそれぞれのコントロール用フローを所有しなくてはいけない。 ２．２ Communication Modeling 技術者が働くために使用するオブジェクト指向方法論が何であっても、開発されたアプリケーションは、タスク(またはInteractionと呼ばれる)を実現するためにさまざまなオブジェクトの相互作用から成り立っている。UMLによって提案されたコミュニケーションの総括的な概念は、パラダイムを渡す通常のメッセージに基づきます。UMLメッセージは、それらを生成するアクション・タイプに依存する異なる形式をとるかも知れない。それらは、信号発信か、オペレーションの呼び出しか、生成、アプリケーションのほかの目的の破壊かもしれません。 メッセージは同期、あるいは非同期かもしれません。また、パラメータを内部や外部さらには内外へつたえるかもしれない。メッセージは送信機および受信機を所有します。送信機は、特定のアクションを実行した後にメッセージを送信することを生成するクラス実例です。UMLは、実行がオブジェクト間のコミュニケーションを含んでいる２つの特定のタイプアクションを提案する。 CallAction：その実行はオペレーション呼び出しに依存するメッセージ交換を含んでいる。 SignalAction：そのじっこうは、信号を送ることを含んでいる。 2.2.1 Operation-based messaging オペレーション概念のUML定義は以下の通りである。 「オペレーションは振る舞いを達成するためにオブジェクトに要請することのできるサービスです。オペレーションは、可能な（可能な帰り値を含んで）実際のパラメータについて記述する署名を行っています。」 モデリングの視点から見て、クラスの構造の仕様は、そのオペレーションの宣言を含んでいる特定のコンパートメント(区画)を持っています。例えば、図2-4の中のクラスの調節装置は、それが二つのオペレーションを持っていることを明示します。（Integer形のパラメータであるsq を持つstarRegulatingとendRegulatingといったオペレーションのこと） 加えて、その平行性は後に続く制約｛concurrency = ‘sequential, guarded or concurrent’｝によってモデル化され特徴づけられている。また、オペレーションは’isQuery’と呼ばれる属性を持っている。この特徴は、状態が変わらないオペレーションの実行の影響力に対応します。一方で、誤りがあった場合には、オブジェクトの状態に何らかの副作用を与えるかもしれない。オペレーションの副作用の可能性をモデル化するために、ユーザは操作の名前の後にクラス仕様にタグ付けされた値{isQuery=’true or false’}を置かなければならない。例えば、実行されたとき、図2-5の中の調整装置クラスのオペレーションendRegulatingはその関連するオブジェクト特徴に副作用を全く持っていません。 オペレーション概念自体を詳しく述べた後に、オペレーション呼び出しをどう生成するかという質問に答えましょう。 オペレーションに基づいたメッセージを生成するために、CallAction型の特定のアクションを実行する必要がある。これは、与えられた実例である、コミュニケーションの目標へのオペレーションの呼び出しを送信することを含んでいる。このような呼び出し行為は、非同期かもしれないし、あるいは同期かもしれません。第1のケースでは、呼び出されたものが、起動されたオペレーションの実行の終了を待ちます。第2のケースでは、呼び出されたものは待たずに、自身の活動を継続します。 いくつかのオペレーション呼び出しには、特定の状態があります。 動作の実行から生じるオブジェクトの生成にかかわるものはCreateAction型 動作の実行から生じるオブジェクトの破壊にかかわるものはDestroyAction型 UMLでは、事前のオペレーションの呼び出しの同期パターンに関して、何も指定されない。したがって、使用される基本的なアプローチによって、それらは、同期となったり非同期となったりする。 コミュニケーションの受取側で直接的に複雑であったものは、オペレーションとCallEventおよびメソッドである。 オブジェクトがメソッド呼び出しのフォームにメッセージを受け取るとき、それは2つの方法でそれを解釈するかもしれません。 呼び出しイベント(CallEvent)は、受信側のオペレーション呼び出しの受取を特徴付けます。したがって、特定の状態でオペレーションの振る舞いを特徴付ける動作の系列実行することによってレシーバー・オブジェクトに振る舞いの影響を与える。呼び出しイベントとして、２つの特定の呼び出しアクション、CreatActionおよびDestroyActionに対応する２つの特定の型の呼び出しイベントが存在する。また、呼び出しイベントは実行の引き金となるオペレーションにリンクされている。呼び出しイベントには、呼ばれたオペレーションにあうパラメータのリストがあるだろう。UML仕様は呼び出しイベントを受信するパラメータとそのオペレーションの引き金に一貫性をもつ公式なルールが定義されていない。それゆえ、イベントと関連オペレーションの間のパラメータ通過に関してあいまいさをまったく持たないようにするために、いくつかの一貫性を保つための規則をはっきりさせる必要がある。さらに、動作の流れは、呼び出されたReturenAction(例えば、return(‘返り値’))によって実行されてきた。もし、オペレーションが値を返して、呼び出されたものがその返り値をもつならば、モデルが不適格であるとされる。 メソッド（Method）は、特定のオペレーションの実装のことである。それは、アルゴリズム、あるいはオペレーションの結果に影響する手続きを指定する。メソッドの特徴は、振る舞いについて記述するオペレーションのそれに似ていなければならない。UMLメタモデルでは、同様の振る舞いを実行するオペレーションである属性からメソッドを継承する。さらに、それは同じ特性である、並行性や、isQueryを持っている。二つの特徴値は保護されているか並行性をもっているかと等しい。 オペレーションの呼び出しに対する実例の反応は、UMLのセマンティクスにおいて曖昧なポイントである。また、オペレーション呼び出しの受け取りも状態遷移機械の遷移を引き起こす呼び出しイベントの形として解釈されるかもしれない。このような場合、レシーバーは、おそらく起きた遷移上で指定されたアクションのシーケンスを実行する。代わりに、受け取りは古典的なオブジェクト指向のオペレーション呼び出しとして認知される。つまり、呼ばれたオペレーションの振る舞いについて記述する与えられたメソッドの実行を引き起こす。 2.2.2 信号に基づいた通信 UMLでは、メッセージが2つの形式をとることが出来る。ちょうど上記の通り詳述されるようなオペレーションに基づいたメッセージか、あるいは、信号を伝えるか。信号は常に非同期通信をモデル化する。 SignalメタクラスはClassifierメタクラスの形式を継承する。その上、それはいくつかの属性を持つことが出来、つまり、結局は信号主体の通信のパラメータを表す。確かに、アレルの初期のステートチャート概念(18)中の信号と異なり、UML信号概念はパラメーターを伝えることができる。さらに、信号は継承木に特定化されるかもしれないし一般化されるかもしれない。信号は特定の分類子であるから、クラス、アクタークラスあるいは他の信号のように他の分類子とどんな操作や関連の関係も持つことができない。 信号は、一方では、それを発生させる行動の特徴(例えば、Operation)のセットにリンクされ、他方では、受信宣言(Reception)でそれを扱うように準備されるクラスにリンクされる。Receptionは与えられたクラスが信号を受信するかもしれないと指定する構造的な仕様であり、信号を受信した時のクラスの反応について説明するものではない。Receptionはステートマシンを通してクラスで記述される行動の中で行われるだろう。以下の二つの理由から、受信は演算と同様である。 まず最初に、Receptionは受信された信号のパラメタの宣言である署名を持つ。 そして、第二に、それは演算と同じ容量でクラスの構造的な仕様にかかわる。 モデル観点からすると、クラスの構造的な仕様は欲しいだけ多くの区画(Compartment)を持つことが出来る。特に、受信仕様に専念する特定の区画を導入することが可能であり、その結果、信号受信の仕様を必要とする各クラスが、それぞれの受け取れる信号を指定する<<Signals>>とステレオタイプされた区画を追加されるだろう。(図2-6) 図2-6 信号受信のための記法 信号概念自体を詳しく述べた後に、信号をどう発生させるか?という質問に答えることにする。 信号の送信は、 ｢SendAction ｣型とされた特定の基本のアクションを使うことで発生する。信号ベースのメッセージは明確な設定した目標の方か、不明確な未定義の目標の方に向けられるだろう。「ObjectSetExpression」は評価されると1セットのインスタンスを返すステートメントを定義する。送信動作の目標を指定するのに使用されたら、そのようなステートメントは ｢all」と言うキーワードだろう。この場合、ステートメントは、基礎となるランタイムシステムによって決定されるように、信号を受信できるすべてのインスタンスを評価する。例えば、例外は基本的なオペレーティングシステムによって受信側を決定される特殊な一種の信号である。 SendActionは何よりも動作で、引数を持っている。引数は、SendActionの実行で生じる、信号ベースの通信によって伝えられるパラメータとマッチせねばならず、また、引数の存在する属性を通じてSignal自身の側面に特定される。 信号の受信は何を意味するか？ 信号の受信は、 ｢SignalEvent ｣型とされるイベントのようなインスタンスによってみられる。イベントにおいて、 ｢SignalEvent ｣というインスタンスはパラメータを持っているかもしれず、専用の待ち行列に格納される。その待ち行列はクラスの振る舞いについて説明するステートマシンに扱われている。 しかし、信号がいったん送られると、何が起こるだろう? 信号の受信の次に来るクラスの、影響を受ける振舞いはまた、そのステートマシンの変遷の引き金となり、おそらく引き起こされた遷移上で指定されたセットの動作を実行する。 オペレーションコールを通る通信のように、信号ベースの通信はその特定の意味論に関する疑問を挙げる: ・受動的オブジェクトは信号を受信できるのか? ・信号宣言の属性と信号イベントのパラメタとの間に正式なつながりがあるか? ・信号の宣言の属性と送信アクションのパラメータの間に正式なつながりがあるか? ・どういうパラメータは信号を運ぶだろうか？In、Out、InOut? など。 これらの質問はUMLドキュメントでの明答を得ない。そのうえ、答えを考えるには位置が異なっているかもしれない。例えば、受動的オブジェクトが信号を受信する可能性に関する最初の質問で、我々はさまざまな観点を持つことができた。 UMLを使用する方法、すなわち、UMLベースの方法論を使用するか、または定義するとき、 どんな曖昧さもサポートされないリアルタイムシステムの為に、なおさらその意味論の論点ついて関係せねばならない。 2.2.3 概要 普通のOO言語のように、通信はUML内でメッセージパラダイムに基づく。この一方通行はともに型を持つ。それは、入出力のパラメータを持つ可能な同期、非同期通信を含む古典的なオペレーションコール、もしくは信号ベースの通信である。後者の場合、通信は非同期であり、オペレーティングコールのように二地点間か、マルチキャスティング、または同報ベースですらあるかもしれない。 2.3Behavior Modeling 今、アプリケーションの振る舞いモデリングに注目している。この様相は、主として状態遷移機械や相互作用、アクションといった概念から発展したUMLによるものである。 - 状態遷移機械は、状態に基づいた図形を使用して、１つの要素モデルの動的な振る舞いについて記述する。ローカルの振る舞い（例えば、クラスやユースケースなどの振る舞い）について記述することにより適当である。図形には2種類のバージョンがある。(State Diagram, Activity Diagram) - 相互作用はさまざまなオブジェクトが与えられた活動やタスクを実行するために交換する1セットのメッセージからなる。この概念は、全体的に記述されるシステムの振る舞いを保証する。相互作用図には２つの形式がある。(Collaboration Diagrams, Sequence Diagrams) - アクションは、UMLと共にモデル化するのにおいて可能な状態で、それが最も低いレベルの振る舞いであることを定義する。規格で定義されるオペレーションセマンティクスのおかげで、実行可能なUMLモデルをつくるのが可能となる。 2.3.1State Diagrams 状態遷移機械は、遷移を通じて互いに接続された状態で構成される。状態は単純になるか、複合されるかである。複合状態は、他のいくつかの複合状態および(または)、いくつかの単純な状態を包含する。複合状態は、さらに並行性をもっている。このような場合、並行に実行するためにリンクされた呼び出し領域である直交要素を二つ以上所有している。 状態遷移機械は、根状態と呼ばれる主要な状態がある。この状態は、状態遷移機械の可能な状態を全て包含する複合状態である。状態遷移機械の実例が作成される場合、それは遷移のリソース状態ではなく、少なくとも１つの特定の遷移だけが開始される初期状態を所有していなくてはならない。 遷移は、単純に構成されている。構成された遷移は、いくつかの単純な遷移を含んでおり、文脈に依存した異なるパスにより、構成されている遷移のきっかけが実行される。確かに、複合遷移の一部である異なる単純な遷移は、異なる起源(選択、フォーク、連結、DeepHistry、ShallowHistory)から来ることのできる、偽りの状態によって互いに接続されます。これらの偽りの状態では、きっかけとなる文脈に依存する異なったルートを与える変遷を組み込むことが可能である。 最後に、単純な遷移は、2つの別個の部分から構成されたラベルで飾られる。 左側は、遷移のきっかけを指定する。受取中のそれが遷移を引き起こすことは、1つのイベントタイプ仕様を含んでいるかもしれない。UMLには4種類のイベントがある。：オペレーション呼び出し(CallEvent)の受取、信号(SignalEvent)の受取、タイミングイベント(TimeEvent)、真になるブール状態(ChangeEvent)。それゆえ、イベントはパラメータを持っている(オブジェクトの値や、参照など)。イベント受取仕様に加えて、このきっかけ部分もまた論理式や保護を持っているだろう。 右側は、遷移の引き金に結果として生じる振る舞いを指定する。それは実行する1セットのアクションである手続きの形式である。 遷移のラベル構文は以下の通りである。：EventSignature ‘[‘guard’]’ ‘/’ ProcedureSignature 図2-7は状態遷移機械が含まれているさまざまな概念を検証する状態遷移図である。 運用上のスタイルに続く上で、UML状態遷移機械セマンティクスは指定された。そして、それらは状態遷移機械仕様を使用する仮想マシンのメカニズムで説明される。この仮想マシンの３つの主要コンポーネントがある。 (1)入ってくるイベント実例が送信されるまで、保持しているイベントキュー (2)選択と待機解除のイベント実例を送信するイベント (3)UMLセマンティクスによって、現在のイベントを処理するイベントプロセッサー。このコンポーネントは、単に「状態遷移機械」と呼ばれる。 UMLでは、待機解除に関する支持が定義されていない。異なった優先権を持つ待機解除スキーマをモデル化する可能性をユーザに任せているからである。イベント処理セマンティクスは、「実行から完成への」仮定(短いRTC中の)に基づいており、イベントの処理が完全に完成する場合にイベントを単にキューからはずし送信することができるというのを意味している。 様々なイベントによって引き起こされる処理を連続させることで、それらの間の対立を排除するので、実行から完成への仮定はUML状態機械の遷移機能を簡素化する。 イベント実例がいったん発生すると… 可能となる１つあるいは、いくつかの遷移を伴うだろう。あらゆる遷移は、右側で指定されている手順によって実行される。そして、いくつかの遷移が可能となる場合、部分集合が引き起こされることが選択され(以下で、説明される手順によって)、次に、実行が終わっているならば、遷移は「fired」と言われる。 現状の延期されたイベントのセットのなかでで指定されたイベントタイプと一致する間に、それが、現在のアクティブな状態配置の最初の遷移を引き起こさない場合は、保存される。この場合、イベント実例は待機解除にならない。また、それは次のステップの間に管理されるだろう。 そのほかの場合は、イベントは失われる。 状況が何であっても、状態機械は、“fully”が引き金となって起こったメソッドが完全に実行されたならば、「RTCステップ」を実行したといわれる。現状が同時発生であるなら、状態機械のアクティブな状態配置において並行に処理を行うのと同様に、同じときにいくつかの遷移は引き起こされるだろう。このような場合、イベント実例は、いったん全ての直交領域が安定した状態に達すれば、遷移が開始される。その後、状態機械の<RTCステップ>は終了されると考えられる。また、キューの中の次のようなイベントは取っ掛かりかもしれない。 遷移の開始は、通常アクション実行を含んでいる。これらのものの中で、同期のものもあるかもしれない。この場合、RTCステップの端は、あらゆる同期のアクションの結末に依存する。いくつかの特定の状況で、それは図2-9のようにデッドロック(行き詰まり)を作成するかもしれない。 前の例において、オブジェクトO１はe１というイベント実例を受け取るが、その現状はS１である。その時、それは外向的な遷移を開始させて、メッセージO２をオブジェクトに送る。その現状がS３であるなら、メッセージを受け取るときに、O２はS３から発する遷移を開始させて、また、メッセージgetValueをO１に送る。しかし、O１はO２からその以前に送られたメッセージであるreadValueに対する反応を待っているため、まだロックされている。このような時、デッドロック(行き詰まり)と呼ばれる特定の状況が発生する。これは、循環的な同時の呼び出しから発生する非常に典型的なケースである。 図2-10で解説されるモデルは、このデッドロック問題に打ち勝つ解決法である。直交した領域を使用して、そのような問題を回避することは可能である。状態機械が循環的な同時呼び出しのために、その直交領域のうちの１つのRTCステップの中でロックされ続ける場合、まだロックされていない別の直交領域で遷移のきっかけとなることが可能である。 通常、UMLに基づいた方法論は、全体の状態機械に適用されたRTC仮定に関連づけられるように意味的にUML状態機械に依存します。しかしながら、それは、まだ、状態機械のあらゆる直行領域のレベルに仮説の範囲を限定している。このような場合、状態機械のレベルにかわり並行状態を適用するため、連続規制は緩められるかもしれない。しかし、規格に従えば、それが可能な場合の、さらにRTC仮定を考慮する方法が全く述べられていない。 UMLでは、一つ以上の遷移が同時に開始されることも可能である。これが起こる場合、そのような遷移は互いに矛盾があるかもしれない。同じイベントが引き金となって、同じ状態からおこる２つの遷移がある場合に、異なるguard(保護)を持っていたならばどうだろうか。もし、両方のguard条件が真の場合、２つの向かう遷移間に矛盾がある。それらの１つだけが遷移されるに違いない。しかし、このような場合、どれ、またはどの基準は選択を行うために使用できるだろうか？ UML状態機械は完成遷移として知られる特定の遷移によって、ある種類の自動振舞いを指定する可能性がある。この遷移の特徴は、「完成イベント」と知られている特定の内部イベントによって引き起こされる明白でないことである。状態機械が、その都度そのようなイベントをそれとなく発生させるので安定状態に達する。すなわち、現在のアクティブな状態でのすべての遷移、エントリーオペレーション、及び、アクションが終了するということである。完成イベントは、発生するとすぐに処理される。つまり、この種のイベントは、状態機械のイベント待ち行列を迂回させて、それらが遷移させる、もしくは失われると直ちに、破壊しなくてはならない。状態機械の現在の状態配置が、向かうべき完成遷移をもっているならば、この遷移の開始は、その状態から向かう他の遷移の開始に対して優先権を持っている。 それゆえ、それらがすべて、同じタイプのイベント(完成イベント)が引き金となって起きるので、状態がいくつかの向かうべき完成遷移を持っているならば,それらは潜在的に全てを活性化することが出来る。また、そのすべては、相互に排他的であるに違いない。状態のそれぞれ向かうべき完成遷移の、それぞれのguard(保護)は、この相互排除状態を確実にする必要がある。いかなる解決策もモデルエラーとなるだろう。 2.3.2 アクティビティ図 アクティビティ図は、構成しているアクティビティの中で、制御フローとオブジェクトフローに関して、コンピュータの過程のモデリングを楽にするために導入された。それは、この種類のモデルに速記フォームを提供するステート図の特殊なケースのように見える。 「この図の目的は（外部のイベントと対照的に）内部の処理で動くフローに焦点を当てることだ。アクティビティ図は、すべてか大部分の出来事が、内部的に発生している動作(それはコントロールの手続き上の流れである)の完了を表現する状況で使用しなさい。普通のステート図は非同期イベントが起こる状況で使用しなさい。」(「OMG Unified Modeling Language Specification」から、バージョン1.5、2002年9月). 状態が、与えられた動作(ActionState)かサブ動作(SubactivityState)(結局個々の動作に分かれる入れ子にされた動作を表現する)に付属される所で、アクティビティ図はステートや遷移の点から説明される。 アクション状態は原子動作に付けられている。原始動作は操作が完了するときだけ残される。アクション状態はアクションの処理に相当する持続時間を持つ。また、それらがセットの状態の動作(または、オーダーサブ活動状態)から作られるように、サブ活動状態にもまた持続時間がある。 たとえ特定の正式な制限がなくても、この正確な瞬間のアクティビティ図での遷移の使用において、動作状態が内部遷移を持つべきでないことは一般的に熟慮され、外部遷移が明確なイベントか、exitアクションで引き起こされる。それは、遷移がいつも動作状態の暗黙の完了イベントによって引き起こされる事を意味する。しかしながら、図2-11で表現されるように、遷移がどの条件のもとで目標状態に達することができるかを指定するためにいくつかの要素を加えることができる。 ・普通の警備状態 ・オブジェクトフローの可用性 ・信号の発生この場合、原子動作が状態に付くように、特定の記法は信号の受信が定義される目標状態に付けられる。 さらに、アクティビティ図は、並行動作をモデル化させ、記法の為に与えられたステップで制御フローを複数の制御フローに分岐するか、複数の制御フローを同期する(大抵結合と呼ばれる)事を提供する。 図2-11 活動ダイヤグラムの記法に関する例 2.3.3 シーケンス図 シーケンス図は、システムのオブジェクトの中(もしくはもっと一般的には、モデルで定義されるクラス化の役割の中)に通信の明白な系列を示すのに使用される。このように、シーケンス図はシステムの構造モデルとの強いリンクを持っている: 2つの通信エンティティ間で定義される関係リンクによって通信は支持される事になっている。シーケンス図は相互作用(必要な操作か結果を生む、オブジェクトインスタンスの間のセットのメッセージ)を表す。 相互作用にかかわるオブジェクトは、メッセージの時間のシーケンスが縦軸沿いに相対オーダーによって示されている間、水平方向沿いの軸で識別される。いずれも含意しないで、この時間の過程(垂直な)軸はメトリックを含まない部分的なオーダーを表す。図中の各オブジェクトは生命線(点線の縦軸)を持ち、それは活動時間中に受け取るシーケンスのメッセージの明確な表示をさせる。我々が(自身が他のメッセージを送る引き金となれる)オブジェクト中で何らかの処理の引き金になるメッセージを見せたいとき、そのためにライフラインに垂直な小さな長方形を使う。入れ子にされた処理を示すためにそれらを入れ子にすることができる。オブジェクトのインスタンス間の矢はオブジェクト間で送られるメッセージをあらわす。メッセージは対応する信号かオペレーションコール名を通じて特定できる。 (図2-12参照) 図2-12 クラスダイヤグラムとのシーケンス図とリンクに関する例 リアルタイムのモデルに関して、長方形の周りに厚い境界を描くことによって、活動的なクラスのインスタンスが表現されるようにオブジェクトを特定することができる。さらに、同期、非同期通信モードはそれぞれ、先端を塗りつぶされた矢か、棒の矢で指定できる。同期通信が示されるとき、外側のレベルのシーケンスが再開する前にすべての入れ子にされたシーケンスは完了する。棒の矢がオペレーションコールの返事を表現しているとき、それは点線の矢と関連付けることができる。非同期通信が指定されるときは、送信側が刺激を急送して、すぐに実行における次のステップを続行する事を意味する。(図2-13) 図2-13 同時発生オブジェクトの中でモデル化される通信規約に関する例 コラボレーション図はオブジェクトの相互作用を表す別の(そして、同等の)方法である。この図の利点はオブジェクトを接続する関連リンクの上で、メッセージが発信されたことを明らかに示すことである。しかしながら、この図はシーケンス図での時間の重要性を失い、直感的でないが同等のレベルの情報を入手するためにメッセージに数字を振る事を必要とする。その結果、並行やリアルタイムシステムをモデル化する上で、コラボレーション図はシーケンス図に比べて使用されない。 ２．３．４ Action Modeling リアルタイムのアプリケーションを備えたdealinであるときに、モデリングの詳細まで、実行可能モデルをモデル化することができ、シミュレーションやプロトタイピングを作るのにとても有効である。このような目的のために、UMLはこの様相をモデル化する方法を詳細に定義しているアクション・パッケージを提供している。 UMLの他のモデル要素とリンクされているパッケージのより高いレベルの実装は、手続き施行である。「手続きは、1ユニットとして実行するためにもたらされる1グループのアクションである。」手続きは、具体的なプログラミング言語でメソッドの本文が指定する場合や、状態が入力されるか、出力される時、活動中のとき、遷移が開始される時などの影響を指定するために状態機械の文脈の中で使用される。 アクション・パッケージは、次のサブパッケージからなる。 基本となるアクション・パッケージは、アクションと手続き用の基礎を定義する。手続きは、InputPinとOutputPinによってデータフローを交換するアクションからなる。 複合アクション・パッケージは、より原始的なものから、より複雑なアクションを定義することが可能な、最適な構造を定義する。 アクション・パッケージを読み書きする、オブジェクトを生成する/削除する方法や、それらの特徴（つまり属性・変数・リンク）を調べる/修正する方法を定義する。 計算アクション・パッケージはデータを変更する方法を定義する。それは、本質的に数学的な機能をモデル化するために使用される。 収集アクション・パッケージは、オブジェクトが交換するメッセージ(同期・非同期・ブロードキャスティングなど)をどのように通信するかを定義する。 ジャンプ・アクション・パッケージは、コントロールの異なるフローの文脈で、連続するようにコントロールの主要なフローを中止する方法を定義する。 アクションセマンティクスは、非常に種々様々のプログラミング言語をサポートするために設計された。これは明らかに、JavaやC++のような通常のオブジェクト言語を含んでいる。しかし、本質的には、指示レベルで並行なプログラミングモデルをサポートしている。その結果、それらが、同時発生のプログラムモデルを保証することを可能をしている。しかしながら、時間の局面は、考慮に入れられず、特定の拡張を要求する。 全ての前段階であるサブパッケージ内での規格は、抽象構文を定義し、UMLアクション言語のセマンティクスの定義に注目している。それは、これが提案されている状態でセマンティクスを映し出す、少し具体的な(あるいは表面)言語を備えてない。もし、実行可能なUMLモデルを作りたいと思っているなら、記法(本文やグラフ)を選び/作成し、かつ、抽象構文の原理がサブパッケージの前のセクションで解説する様々なアクションでACCORD/UMLを提供するためのいくつかの提案がある。 2.3.5 概要 ステート図はステートマシン内で伝統的に利用可能な概念を供え、特にMealyとMooreの文法を混ぜている、すなわち、動作が状態や遷移上で可能である。UMステートマシンは、どんなモデル要素にもローカルの振る舞いを指定するのに使用され、常に離散時間型システムのモデリングを確実にする。しばしば批評されるが、ステートマシンはその内容を正式にするのを目的とする仕事をたくさん受ける。(23-25) アクティビティ図は一般的に、コンピュータの、または構成上の、局面のモデリングのために使用される。一方では、コンピュータの局面をモデル化するために、アクティビティ図はクラスの操作の詳細な振舞いを指定するだろう。事実上、この場合、アクティビティ図は操作を実行する方法の詳細な仕様を説明するのに使用される。他方では、構成上の局面において、クラシファイアの活動の連鎖を記述するために、アクティビティ図はユースケースやパッケージのようにシステムの広域レベルで用いることが出来る。しかし、それらはビジネスプロセス工学かワークフローモデリングにもまた使用される。(27.28) シーケンス図はオブジェクト間の相互通信を指定すると提言されている。強くシステムの構造モデルに関係すると、シーケンス図はそれにオブジェクト間の構造的リンクに沿って交換されるメッセージを明白にさせる。また、並行モデルのために、主な送信オブジェクトに影響するサイズを含んだ並行オブジェクト間の、同期、非同期通信の通信プロトコルの記述を確実にする。そして最終的にシーケンス図はそれらの時の次元(すなわち、縦軸)で、UMLで時の相互作用をモデル化するのに最も適切で直感的な図のひとつである。動作意味論は、エンジニアが実行可能なUMLモデルを確実に作れる、最も低いレベルの行動モデルを支持する。今日、UML規格のこの部分はほんの少ししか実現していない。したがってこの特徴はUML方法論とツールに広がっていない。これは確かに当然な事実です。 ｢統一化した記法がない ｣からなのですから！ ３． QUANTITATIVE REAL-TIME FEATURES 前のセクションは、リアルタイムの仕様においての質的な様相についてであった。（平行性、コミュニケーション、振る舞いおよびアクションといったもの）これからは、リアルタイムのアプリケーション・モデリングの量的様相について焦点を合わせる。 この目的のために、UMLは最初に、時間仕様のための２つのデータ型である、Time、およびTimeExpressionを定義する。 Time型は時間や空間において絶対的な、もしくは関連を示す移動に言及する値を定義する。 TimeExpression型は、それらが評価される時にTime値を返すことを宣言する。 このセクションの続きで、我々は、第一に状態図と第二にシーケンス図によって、タイミングの記述を使用する方法を理解するつもりである。 ３．１ RT modeling within state diagrams 状態機械の時間仕様については、UMLが、TimeEventと呼ばれる特定のイベントを定義する。このイベントは、参照時間に比例するものかもしれないし、絶対的なものかもしれない、特定のデッドラインをモデル化する。 TimeExpression型の表現や比例するデッドラインの指定の後に続くキーワードを経由して、相対的な時間イベントは状態機械の中でモデル化される。 相対時間のイベントはTime型の表現や絶対的なデッドラインの指定に続くキーワードを経由して、状態機械の中でモデル化される。 テーブル2-1は、UML状態機械中の時間イベントの異なる可能な用途を例証する。 全ての前の場合については、タイマーの期限が切れると、それは状態機械の待ち行列で毎回救われる時間のイベントを発生させる。これが、状態Sに丁度ある場合、時間イベントは消滅され、そして、時間イベントに関連している遷移は引き起こされる。もう片方の場合では、状態機械が別の外向きの変遷（すなわち、時間イベントに関連付けられるこれと異なったもの）を開始させるなら、時間イベントは消滅される。この方法によって、他の種類のイベントに反して、時間イベントを延期することが可能でなくなる。 その後、一時的なイベントの発生時間は、その受理時間と一致させるべきだ。しかしながら、ある遅れが時間イベントの受理おおび、取扱い時間の間で延長させることに気付くのは重要である。さらに、この遅れは可変であり、測定することが、最大を見つけることさえ非常に困難である。確かに、この遅れは、イベントの取り扱い[29-31]では、各ツールによって採用された管理方法に依存している。 3.2 シーケンス図の中でのRTモデリング 特にリアルタイムのシステム仕様に十分合った、UML図の二つ目のタイプはシーケンス図である。本当に、前述の通り、シーケンス線図には二つの次元がある: ・図によって説明される、相互作用に関連するオブジェクトと一緒の水平な軸 ・時間経過を表す縦軸 シーケンス図の中では、時間は縦軸沿いの上から下まで進んでいくが、量的な測定基準システムは全く定義されていない。したがって、シーケンス図でのリアルタイム制限モデリングはこのグラフィック特徴を当てにする。 一般にシーケンス図では、アプリケーションの他の活動と比べて、メッセージの伝送遅延は取るにたらないと仮定する。これはメッセージモデリングが水平な矢印を使用し終わっているという事実を説明する。しかしながら、必要であるなら、ユーザは、メッセージの伝達に時間がかかると指定することができる。そのためには矢を傾ける必要がある。すると、矢の先(メッセージの発信時間を作る)がその尾(メッセージの受信時間を作る)より低くなる。(図2-14) 図2-14 メッセージの伝達遅延指定 より簡単に時の規制モデルを作るために、シーケンス図で実現されるメッセージ交換中の時間調整のため、UMLは意図的に具体的な関数を導入する。関数sendTimeとreceiveTimeはそれぞれ、メッセージの送受信の瞬間を指定する。これらの関数は、時間の表現を構成するのに役立つ。その表現は特殊な、シーケンス図で説明された相互作用のメッセージのセットにつけられるだろう。これらのタイミング関数は、そのタイミング機能の1つを特徴付けるためにメッセージの名前に適用されます。例えば、"aMessage.receiveTime"という表現はaMessageと呼ばれるメッセージの送付瞬間を意味する。タイミング関数のセットはこれらの二つだけではない。ユーザは、自分の要件を満たすために他のものを定義することができる(例えば、完了時間、実行開始時間、待ち時間)。 シーケンス図でリアルタイムの規制を指定するために、UMLは2つの方法を提案する:タイミング・マークを通して、または、時間の表現によるUML規制の点から。 図2-15 シーケンス図による時間の仕様 最初のテクニックは、2本の点線でシーケンス図の縦軸(時間の進行を表す)に時間の長さを表現し、時間の制約を書き加えられた二重矢(⇔)によって接続する事から成る。上述の例で、時間の仕様はm1の受信で引き起こされたアクティビティO2の実行時間が1秒未満でなくてはいけないと指定する。タイムモデリングのこの方法は視覚的には魅力的だがUMLでは正式に定義されない。それは、単にUML規格の記法部分の一部であり、UMLの意味論で説明されるに値する概念を少しも持っていない。この可能性を提供するツールは、意味的にモデルに取り付ける前に、(以下で説明されるように)時間の制約の点から訳さねばならない。 シーケンス図の時間をモデル化する二つ目の方法もまた、上で説明されているように時間表現のあるUML制約を使う。図2-15に関する例で、"{b.sendTime - a.receiveTime < 1sec.}"という時間の制約は、m2の送信時間と、m1の受信時間の間が1秒未満でなければならないと規定する。この時間の制約は青写真のスタイルで表現されるものに相当する。 いかなるUMLベースの方法でも、単なる記法であるに過ぎないので、リアルタイム指向にこれらの時間の仕様の特徴が形式化されることを願う、それぞれの人にとって重要である。本当に、リアルタイムアプリケーションモデリングへ完璧に接近することで統一することをのぞいて、それらを使って満足することはありえない。 ３．3 UML Profile for Scheduling, Performance, and Time スケジューリング、パフォーマンス、およびTime(SPT)のためのUMLプロフィールは、アプリケーションのリアルタイムの局面をモデル化するのに必要である最小のセットを定義することを目標とする。これらの全ての概念が、タグ付けされたUMLモデルから実現、もしくは枠組みを作るために十分な情報でモデル化されるアプリケーションを確実なものとしなくてはならない。その目的のための、SPTは２つのパートによって組織される。(1)第一のものは、モデル化を確実にし、更に寝られた概念の定義のための基礎となるリアルタイムの特徴のモデリングを定義する。(2)前に定義された、概念の基礎に基づいた二番目のものは、UMLベースのアプリケーションのリアルタイムの働きを分析するのに必要な高いレベルの概念である。 SPTの第1のパートは３つのサブパッケージからなる。 一般的な資質モデリング(GMR)パッケージは、非常に総括的な用語の中で、資源の概念およびQoSの両方を定義する。それは、更に、他のものの中でアプリケーション力学の原因効果チェーンをはっきりさせる因果関係モデルを紹介する。 一般的な時間モデリングパッケージは、タイマーや時計などの時間に関連したメカニズムを定義する。 一般的な平行性モデリングパッケージは、アプリケーションにおける並行関係を指定するために基本概念を定義する。その目的のために、それは主に、事実上、他の同時発生の実体と同時に動作の系列を実行することができる実体である平行性ユニット概念に依存している。 これからは、SPTの第2のパートである、UMLに基づいたアプリケーションのリアルタイムの振舞いの分析技術に焦点をあてる。３つのサブパッケージで提案された拡張は、UML上で達成する能力が、RC-CORBAに関する文脈における、古典的なスケジューラビリティ分析(RMA,EDFなど[32])、実行分析およびスケジューラビリティ分析をモデル化することを保証すべきである。 STPが第一に1セットのステレオタイプを定義して、値にタグをつけて、そしてそれを抑制するので、高いレベルの仕様を必要とするリアルタイムのアプリケーションモデルを扱う時、最終的に、UMLプロフィールは非常に役立つかもしれない。しかし、また、このプロフィールは、必要であるならリアルタイムのモデル問題を解決するための、より専門化している概念を再定義するためによい枠組みを形成する。 4．記法から開発プラットホーム(一致/UMLアプローチ)まで: ソフトウェアドメインにおけるその存在は成功しているが、UMLはまだリアルタイムのシステムの一つのように特定のドメインにおいてその支配を許すような重要な意味論を欠いている。(33)そのようなシステムのリアルタイムの振る舞いの記述は現在のUML2.0提案でさえまだ完全に満足出来ているわけではない。これはリアルタイムの仕様のためのオブジェクト指向方法の妥当性の討論の継続につながる。特に、これはアプリケーションのリアルタイムの振る舞いの仕様のための、オブジェクト概念が汎用な実用レベル上に打ち立てたケースで、今まで広く紹介されていない。 少なくとも、現在の提案は以下の二点からまだ完全に満足できるものではない。 ・最初に、タイミングの特性(締め切り、期間、優先権、実行時間など)の表現の残りの欠陥や、ダイナミックモデルの意味論の要点がはっきりされねばならないこと。 ・2番目に、ユーザーのニーズは市場爆発のため急速に発展していること。特に、ますます非リアルタイムの専門家はリアルタイムのシステムモデリングに関心を持ち、明確にし、時に新しい組み込みサービスやシステムを開発するよう要求される。 最初のポイントは、リアルタイムモデリングに関連づけられた現在のUML概念の意味論を豊かにし、はっきりさせることによって、取り組むことができるが、2番目のポイントは、基本的な実装のテクニックと解決策を完全に隠す、より高いレベルでの新しいモデル概念を提案する必要性に導く。その結果、自動的にアプリケーションの実装を生み出すもっと綿密な手順（そしてツール）の規定を要求する 数年前に、オブジェクト指向プログラミングパラダイムを並行プログラミングに広げるための研究が前形成された。それらは活発なオブジェクト指向の、そして、統一されたモデルの定義である。それらは依然、開発者の為に低いレベルのリアルタイム実装のメカニズムを明確に保っている自動的なリアルタイムの実装と、リアルタイムの開発をたすけるリアルタイムオブジェクトパラダイムの定義に対して、土台となっている。 ACCORD/UMLアプローチはそのような試みの1つである。(24,34-36)その目的は古典的なオブジェクト指向方法にできるだけ近い枠組みをリアルタイムの開発のために提供することである。高いレベルの抽象化(すなわち、リアルタイム動的オブジェクト概念(15))のおかげで、リアルタイムモデリングは領域に特化した実装の問題との混同を避けて達成できる。それは、技術者が必要とする、アプリケーションのリアルタイムの特徴についての説明に答えることを狙っている。したがってこのアプローチの中では、リアルタイムの分野で十分な抽象化を提供するモデルでリアルタイムの特徴を統合するという考えとともに、オブジェクト志向のテクニックという周知の利点を未だに保とうとしている。 この目的を達成するために、ACCORD/UMLはリアルタイムの振舞い仕様の両方の局面(量的かつ質的)を支持するUMLの拡大を提案した。それに関して、ACCORD/UML方法によって導入される主なモデル機能は以下の通り。 ・アプリケーションに関係する並行性はリアルタイムオブジェクト(UMLアクティブオブジェクトの拡張)の識別を通じて定義され、指定される。ACCORD/UML方法は、以下の発見に基づいてそれらを定義すると提案している。それは「リアルタイムオブジェクトはいずれも、外部で特定の定期的活動を行うアプリケーションから来るイベントを管理する、アプリケ−ションのインタフェースオブジェクトである。」という発見である。これらのリアルタイムオブジェクトの実装は、タスク割り当て(オブジェクトの待ち行列管理とオブジェクト間通信)をサポートする実装に専念した枠組みの管理下で用いられる。さらに、この方法は様々なリアルタイムオブジェクトに共有される(「保護されたオブジェクト」と呼ばれる)受信側オブジェクトの定義を許可する。この場合、ACCORD実装枠組みは、様々なオブジェクトによる受信側オブジェクトの平行使用の並行性管理を、自動的に実装する。(37) ・モデル自体の量的なリアルタイムの規制の仕様(締め切り、期間、優先など)は、開発の前段階で型を決めることが出来、最終的な実装までのモデル強化中は維持される。リアルタイムオブジェクトの実行モデルやACCORD実装枠組みは、開発者が管理を実装するため、リアルタイム制約を低いレベルのメカニズムに翻訳するわずらわしさを無くす。(タイマ設定はそれほど必要でなく、スケジューリング方針は実装枠組みを通じて、自動的にアプリケーションに提供され、実施される)。同様に、並行性の制約もこのアプローチで管理される。つまり、業務計画レベルで宣言され(自身の実装仕様を当てにするので)、最終的なアプリケーションで自動的に管理される。スケジューリング方針はこれら2つのタイプの制約(すなわち、リアルタイムと並行の制約)を統合する。(38) ・オブジェクト内のコミュニケーションスキーマは、一連のオブジェクト指向プログラミング中で使用されるスキーマにとても近い物を残している。オブジェクト指向プログラミングでは、オブジェクトがともに操作呼び出し(必要ならパラメタを出力して)や信号の発信(この場合同報や匿名通信も許可される。送信側も受信側もお互いを知る必要はない。)を通じてメッセージを交換することができる。実行呼び出しと信号送信の実行モデルは同じである:目標がリアルタイムオブジェクトであるなら目標の処理リソースで処理され、目標が受動的オブジェクトであるときは送信側処理リソースで処理される。 ・通常のモデルのオブジェクト指向構造は、2つのレベルのステートマシンとともにオブジェクトの振舞いの仕様によって保存される。(26、39、40)まず最初に、オブジェクトレベルでは、ステートマシンはオブジェクトによって実行される操作と連鎖する、論理的なコントロールを指定するだけである(それはUML 1.xで定義され、UML 2.0でより正式に定義された「プロトコルステートマシン」に対応している)。このステートのマシンでは、遷移はオブジェクトインターフェースで定義される操作の処理の引き金となるだけである(動作はオブジェクトメソッドの部分的実施に制限される)。2番目に、オブジェクトの操作レベルでは、ステートマシンはこの操作を実行するために実行される動作の詳細を指定する。(このレベルで使用される動作はUMLの動作と一致しているものが選ばれる)。(41) たとえこのアプローチが実験段階の成果だとしても、C++コードで設計したステートマシーンからのオブジェクトのリアルタイムの動作の出力を考慮に入れた、セットのモジュールを含む構成上での完全な実装によって、この操作上の可能性は実証されている。そのうえ、専門化しているC++ジェネレータもまた、拡張アクティブオブジェクトの概念を支持するために開発された。最終的に、土台となるリアルタイム・オペレーティング・システム(RTOS)に関して、2つの層がアプリケーションとRTOSの間で定義された。すなわち、ACCORD/UML KernelとACCORD/UML Virtual Machineである。前者はアクティブオブジェクト意味論を支援するメカニズムや、(Earlist Deadline First(EDF)方針やHighest Priority First(HPF)方針などの)主な管理方針を重んじながらアプリケーションのタスクを管理する事を考慮した、上記のすべてのメカニズムを実行する。二番目のは土台のRTOSに関連する限り、アプリケーションを独立させる。後者は Solaris、Linux、VxWorksといったOSに順ずるPOSIXの為に存在する。 オブジェクト指向方法の中で、アクティブオブジェクトパラダイムを統合すると、単純で、完全かつ均一にモデル化することを可能にし、アプリケーション中の多重タスキングを必要とする。アプリケーション全治の開発サイクル間で、同じオブジェクトのパラダイムの使用は、いくつかのモデル化する段階で、モデルシームレスを強化する。リアルタイムまでUMLを拡張するためのACCORD/UML提案は、リアルタイムに関連して発展したパラダイムに基づく。これを根拠に、私たちは、普通のオブジェクト指向モデルで使用される、それらに非常に近くてほんのわずかに専門化した知的なアプローチと概念をえることができる。その上、この提案は設計において非常に遅い並列、リアルタイムおよび実行選択を延期させることを可能にする。従って、並列関係の詳細を変えるのは、全体のアプリケーションの再設計や再分析は引き起こさないだろうが、実行の選択やアプリケーションの最後のリアルタイムの設計の微調整を要求するだろう。アプローチは、最大限再利用を行なう。また、設計は、完全に他の領域の中で積まれたオブジェクト指向の経験から有益な情報をえるだろう。 モデル自体で、アプリケーションのマルチタスキングおよびリアルタイムの振舞いと関係する制限を表現することができるという事実による、質的な明白な利益に加えて、ACCORD/UMLアプローチの使用は、ユーザがマルチタスク・プログラミングの使用される高度な同期メカニズムについての深い知識を必要とすることを防ぐ。通常のオブジェクト指向プログラミングモデルとの類似点は、非リアルタイムの専門家によるその使用を認めることである。また、自動的にモデル中で指定されたリアルタイムの特徴を実行する能力は、それらがリアルタイムの開発技術について深い知識をもつ必要のないことを保証している。 この研究の一部は、AIT-WOODESプロジェクトに支援された。それは、自動車産業[44]のためにモデル化する組み込み型システムに専心的なUMLプロフィールに結び付けられた。このプロフィールに、OMGで、それを支援するのに必要となる基準の発展提案が贈られるだろう。 さらなる研究は、リアルタイムのアプリケーションの形式上のUMLモデルの生成を考慮する。このポイントにおいては、拡張UMLモデルを、非同期コミュニケーション・オートマトンに基づいたモデルに翻訳するために、CEA-LISTのLSP研究所で研究の進行途上にあります。それは、その時、既存のツールとモデルの照合の技術で自動的に築き上げられるこれらのオートマトンを分析するのにおいて可能であり、UMLモデルからアプリケーションの全ての可能な実行経路を自動的に抽出しそれぞれそれら[48]のテストケースを生成させることによって、技術者が自己のアプリケーションの振舞いを有効にするのを助ける。 5．OMG PERSPECTIVES OMGの進行中の研究で、4つのアクションが、リアルタイムの領域にとって特に重要なことが分かった。QoSやフォールトトレラントメカニズム[49]のためのUMLプロフィール、システム工学[50]のためのUMLプロフィール、MDA技術スペース[51]の状況でのモデル変形言語のための基準、そして最後にUML2.0である。 QoSとフォールトトレラントメカニズムのためのUMLプロフィールは、初めに、一般的なQoSの枠組みを定義して、また、サービスの質の個々の具体的なパラダイムを定義することを目的とする。提案は、スケジューリング、パフォーマンス、およびタイムのためのUMLプロフィールで定義されるQoSに関する抽象概念を再利用しなくてはならない。第二に、一般的なQoSに基づいて枠組みは提案して、また、規格は寛容メカニズムサポート用の総括的なフレームワークを定義しなくてはならない。 システム工学のためのUMLプロフィールはどんな種類のシステムモデルにUML拡張を全て供給することを目指します。このプロフィールは、システム、すなわちハードウェア、ソフトウェア、データ、人員、手続き、設備を扱うことを考慮するために、一つの手に様相の全てを包括しなくてはならないだろう。また、もう一方の手には、このプロフィールが、更に分析、設計、実行など全てのプロセス活動の支援を提供しなくてはならないだろう。 現在のOMG関係の中心に、MDAがある。この頭文字は、Model-Driven Architecture[52-54]を表す。MDAと関係する主要な目的は、開発プロセスの中心にモデル・パラダイムを入れることである。また、その後、アプリケーションを構築するのに必要な技術を全て供給するために、洗練されるモデルは、実行かのうな実行命令に達するステップまで進む。MDAに関連する主要な問題の一つは変形モデルの問題である。この問題に取り組むために、OMGはMOF2.0 Querry/View/Transportation RFT(要するにQVT)を始めた。すべてのOMGモデルが、Meta-Object Facility（要するにMOF）に関する文面で定義されるメタ・モデルに頼るという前提に基づいて、また、ことによると様々なメタモデルに基づいてRFPを確実にする要求は様々なモデルの間に現実を写像するのを確実に普遍的なモデル変化言語を持つことである。 最終的に、最後の、しかし、最大のポイントは新しい基準のUML2.0である。特に、この新しい規格における主要な新しいアイディアの一つはコンポーネント(構成要素)モデルに関連する。目的はコンポーネントをベースとしたソフトウェア工学のアプローチをサポートするためにより高いレベルのパラダイムを提案することである。さらに、UML2.0は、例を挙げるならば、より直接リアルタイムの問題に関連する改善/付加概念である。例１：振舞いの様相は、状態機械のプロトコルとアクティビティ図の両方を明確化を通じてより発展した。例2：SDLのハイレベルなメッセージシーケンス図の経験に基づいて、UMLシーケンス図は、大幅に変更された。 |