13章 並行・実時間システムの分析とモデリング
（後半：13.6〜）
Analysis and Modeling for Concurrent and Real-Time Systems
（前節のようにして）問題領域でのオブジェクトがモデル化されたら、オブジェクトがサポートする、あるいはこれらのオブジェクトと作用する関数をモデル化しなければならない。
この節では挙動モデルで必要な典型的な関数の分類について述べる。
l ある種の関数はオブジェクトとの結びつきは自明だが、一方どのオブジェクト（オブジェクト群）と関連するかが自明でない関数もある。
l 状態依存のあるシステムにおいては関数の起動は状態遷移を引き起こす。
l さらに実時間システムでは、関数に関してタイミングに関す複雑さが追加される（オブジェクトに関してタイミングは間接的な関連しかない。）。
l 各関数は逐次的に動作するが、他のオブジェクトや関数によって並行に実行され得る。
l 関数はデータ・フロー/制御フロー図では変換で表す。
l オブジェクトがサポートする操作はオブジェクトに関連付けられた関数にマップされる。
l COBRAではオブジェクトで表現されたデータ変換はそのオブジェクトがサポートする関数（これら自身もデータ変換として表現される）へと分解される。
関数はデバイスI/Oオブジェクトに対する読み書きを扱う。
図13.9(a) モーターデバイスの3操作： 回転数上げ、回転数下げ、停止。（モーターのオブジェクト指向的描写）
図13.9(b) 3つの関数への分解（モーターの関数による描写）
図13.9(c) イベント・フローに関する記法：(a)図のように、呼ばれる関数が明示されない場合はイベント・フローに名前を付し、(b)図のように、どの関数が呼ばれるかが明らかになっている場合は、イベント・フローから名前を省略して”Trigger”で置き換えてよい。
l 他のオブジェクトや関数から呼ばれてある動作をする。
l しばしばデバイス入力オブジェクトにより起動される。
データ・フロー/制御フロー図では：
他の（オブジェクトや関数が表している）データ変換からの離散的なデータ・フローとイベント・フローのどちらによっても起動されるデータ変換として表される。
例：
データ・フロー/制御フロー図（13.10）でMileage Reset Buttonによってイベント・フローMPG Resetを通じて起動されるInitialize MPG関数
l コントロール・オブジェクトに呼び出されて与えられたしごとを果たす。
l 通常、単発動作して自発的に停止。
l 概念的にはこのような関数はコントロール・オブジェクトの状態遷移に伴う動作を実行。
データ・フロー/制御フロー図では：
コントロール・オブジェクト（コントロール変換）からのイベント・フローによって起動されるデータ変換として表される。
例：
データ・フロー/制御フロー図（13.7）で、コントロール・オブジェクトCruise Controlから呼び出されるSelect Desired Speed関数は、データ・ストアCurrent Speedから現在のスピードを読み取ってDesired Speedの値として蓄えるという単発動作を行って自発的に停止する。
この関数は、Cruiseコントロールの状態遷移図（13.6）でAcceleratingからCruiseに移る際に呼び出されている。
l 一定間隔で呼ばれてある動作をする。
l どのくらいの頻度で呼ばれるかは用途に依存する。
データ・フロー図/制御フロー図では：
タイマー・イベントで定期的に引き起こされるデータ変換として表現される。
例：
データ・フロー/制御フロー図（13.11）で、タイマー・イベントによって定期的に起動され走行距離を計算するDetermine Distance関数。
タイマー・イベントがデータ変換を引き起こすことを、データ・フロー図上で明示しておかねばならないことに注意。
l コントロール・オブジェクトによって定期的な仕事のために呼び出される。
l コントロール・オブジェクトがある状態に入ると呼ばれ始め、ある状態から出ると呼ばれなくなる（これらの状態は通常同一。）。
l 殆どの場合、ある状態（状態群）にある間中呼ばれつづける。
データ・フロー図/制御フロー図では：
状態に依存するかどうかが単なる定期的な関数との違い。
例：
データ・フロー/制御フロー図（13.7）で、コントロール・オブジェクトCruise Controlから呼び出されるMaintain Speed関数は、データ・ストアDesired Speedから現在の設定スピードを読み取ってスロットルの値を調整するという動作を定期的に行う。
この関数は、Cruiseコントロールの状態遷移図（13.6）で状態がCruiseにある間（イベント・フローEnableからイベント・フローDisableまでの間）中は定期的に呼ばれつづける。
挙動分析（Behavioral Analysis）はサブシステム内部のオブジェクトや関数がどのように相互作用するかを決定することを支援する。
l 外部イベント・シーケンスのためのシナリオを作成する。
l シナリオは外部イベントの列を示すと同様に、各外部イベントに応じて引き起こされる内部イベントの列も示す。結果として（しばしば状態依存の）システムの応答も示す。
l 挙動分析的なアプローチは反復的である。最初にサブシステムについて行ったら、次はサブシステム内の各オブジェクトや関数について行う。
l 挙動分析によってさらにオブジェクトや関数が必要なことが判ることがある。
l 挙動分析によって、あるイベントが祖結合なために別々のサブシステムによって処理されるべきであることが示される場合もある。
l 挙動分析によって、当初は別々のサブシステムで処理されていたイベントが、密結合なために単一のサブシステム中で処理されるべきであることが示される場合がある。
l 状態依存な分析も状態非依存な分析もある。
l システムが出会う典型的な外部イベントの列として認識されるもの。
l 各外部イベントに対して発生する内部イベントの列を決定するために人力（ウォーク・スルーなどによる）で実行される。
l イベント・シーケンスは番号付けされ、イベント・シーケンス図として参照されるデータ・フロー/コントロール・フロー図のある版に示される。
l イベントは制御/データ変換に対する離散的な入力と考える。
l （よって）あるイベントはイベント・フローあるいは離散データ・フローとなる。
l 離散データ・フローはメッセージに対応し、メッセージはデータ・フローの到着を表す（イベント・シーケンス図においては、そこに関連付けられたデータよりむしろ重要な）イベントである。
デバイスI/Oオブジェクト、制御オブジェクトとそれらが実行する状態遷移図、それらの制御オブジェクトに制御されるオブジェクトや関数との間の相互作用を決定すること。
シナリオの作成：
a. 初期オブジェクトの決定： オブジェクト構成規準を用いて、システムやサブシステム内のオブジェクトを決定する。
b. システムあるいはサブシステムのための状態遷移図の作成： システム/サブシステムを外部から見た場合の状態を決定するために必要。外部から直接/間接に届いたイベントによってこの状態は変化する。状態遷移図を実行する制御オブジェクトを作成する。
c. 外部イベント・シーケンスの定義： このシステム/サブシステムに対する外界の各実体とのインターフェースを考え、それらが生成したり受け取ったりするものとして外部イベントを考える。ここで、（１）イベントの発生源となる実体はシステムの状態変更を引き起こすかもしれない。（２）外部の実体は少なくとも1つの外部イベントを発生させているはず。（さもなければ、このサブシステムに対して何の役割も果たしていない。）
d. シナリオの作成： 状態遷移図と外部イベントのリストから1つ以上のシナリオを作成する。各シナリオはシステムが受け取る外部イベントの列からなる。
各シナリオの実行：
a. 状態遷移を引き起こす各イベントについて、このイベントの原因となった外部からの入力を決定する（この入力を読み取るために必要なデバイスI/Oオブジェクトを決定し、制御オブジェクトに状態遷移を起こさせるための制御フローとして適切なトリガを生成する。）。
b. 各状態遷移について、この状態遷移に伴う全ての動作を決定する（全てのオブジェクトと状態依存の関数を実行する。オブジェクトである場合、そのオブジェクトがサポートする内で必要だと思われる動作を実行する関数を実行する。関数の場合、単発起動か動作可か動作不可かを決定する必要がある。）。
c. 起動されたり動作可とされたりした各オブジェクトや関数について、それらが生成する出力（データ・ストアへの書き出し、外部環境への出力、別のオブジェクトや関数への受け渡し）を決定する。
d. 外部イベントとそれに引き続く内部イベントを、イベント・シーケンス図（＝状態遷移図及び部分的なデータ・フロー/制御フロー図）として示す。イベントには実行順を示すために番号を振る。
シナリオの完成：
状態遷移図の全状態、それぞれの各動作が最低各一度実行されて、全ての状態依存関数が少なくとも一度、単発起動、動作可-動作不可されるようにシナリオを完成させる。
以下、クルーズ・コントロール・サブシステムについて、この方法の主要な点を示す。
l 制御： Cruise Control
l デバイスI/O： Cruise Control Lever, Engine, Brake（←外界からの入力として）。Throttle（←外界への出力として）。Shaft（←自明でないため、当初は省略される）。
l これ以外のオブジェクトは後で決定される。
l 13.12図はCruise Controlの簡単化された状態遷移図。主だった状態、頻繁に起こる遷移と遷移を引き起こすイベントが示されているが、遷移に伴って起こる動作は含まれていない。
l Cruise Controlオブジェクトの状態は全て外部から観測できる状態であり、車の運転者は各状態を知っており、運転者の直接/間接の一連のアクションによって状態を表せる。
1. Idle エンジンが切れている。
2. Initial エンジンを始動すると、車は初期状態に。
3. Accelerating クルーズ・コントロール・レバーをACCEL位置に入れる（遷移Accel）。車は加速状態になり自動的に加速する。
4.
Cruising レバーを放す（遷移Cruise）。現在の速度が巡航速度として保存され、車は巡航状態になり、車は自動的に巡航速度に維持される。
5.
Cruising Off ブレーキを踏む（遷移Brake Pressed）。車は非巡航状態になり、自動制御は中止されて手動操作される状態になる。
6.
Resuming クルーズ・コントロール・レバーをRESUME位置にする（遷移Resume）。車は自動的に加速/減速して直前の巡航速度に戻る。巡航速度になるとCruising状態になる（遷移Reached Cruising）。
外部イベントとしては、システム・コンテキスト図上ではソース終端として表されるような実世界の実体からくるものが定義される。
例： ソース終端であるCruise Control Lever, Brake, Engine等の外部の実体について、それらの実体に対応するソフトウェア・オブジェクトが定義される。
ブレーキが踏まれたり放されたり⇒Brakeオブジェクトからイベントが発生。
クルーズ・コントロール・レバーが操作される（Accel, Cruise, Resume）⇒Cruise Control Leverオブジェクトからイベントが発生。
典型的なシナリオ：（行為者は運転手）
1. 加速： クルーズ・コントロール・レバーをACCELに入れる。
2. 巡航： クルーズ・コントロール・レバーを放す。
3. 解除： ブレーキを踏む。
4. 巡航再開： クルーズ・コントロール・レバーをRESUMEに入れる。
以上に加えて、状態遷移図から、シナリオの初期状態としてInitialを仮定。
l イベント・シーケンス図： 13.13図はデータ・フロー/制御フロー版。13.14図は状態遷移図版。
l データ・フロー/制御フロー版と状態遷移図版を見ながら最初のイベント「加速」からのイベント・シーケンス（Accel Input→<CruiseControl Lever>→Accel→<Cruise Control>→Enable→<Increase Speed> ）を追ってみる。
l その結果起こること（状態遷移Initial→Accelerating、状態依存関数Increase Speedの起動）を考える。起動される関数が単発の関数か定期的な関数かどうかを決定するには状態遷移図を見る必要がある。
以下同様にして、外部イベントを順に追う・・・。
l イベント・シーケンス図は外部イベントに対するシステムの挙動を内部イベントの列の形で表している。(例： 内部イベントReached Cruisingも間接的には運転手がレバーをRESUMEに入れた結果。)
l 状態遷移図の全ての状態について全ての遷移を確認するにはシナリオを継続する必要がある。
l さらに調べていくとEngineオブジェクトとClear Desired Speed関数を追加するように導かれる。
l この解析に基づいて最終的な全ての関連オブジェクトと関数を図13.13では示してある。
デバイス入力オブジェクト： Cruise Contorol Lever, Brake, Engine
制御オブジェクト： Cruise Control
デバイス出力オブジェクト： Throttle
データ・ストア： Current Speed, Desired Speed
データ変換で表される状態依存関数：＜不定期的な状態依存関数＞ Select Desired Speed, Clear Speed＜定期的な状態依存関数＞Increase Speed, Maintain Speed, Resume Cruising
l ここでは（クルーズ・コントロール・システムの一部だけを扱っていて規模も小さいので）変換は同一レベルで分解されたオブジェクトと関数を表しているが、システムを判り易くするために必要に応じて階層的に挙動分析することもできる。
l 状態のないサブシステムにおいては、サブシステムと接している外部実体から生成されたイベントは確定している（状態にかかわりないので、シナリオ不要。）。
l 各イベントについてオブジェクトや関数が（状態に拠らず）イベントを処理すると考えられる。
l 外部入力の受け入れに際しては、データI/Oオブジェクトがデータをデータ・ストアに書き出したり、引き続く処理のために内部オブジェクトへ送ったりしている。
l 定期的な動作（例：定期的な報告）については、システムが出力を生成するためのタイマー・イベントに関する考慮が必要。
l 各々の重要な出力（例：レポート）について、データを生成するオブジェクトや関数が必要で、これらは典型的にはデバイス出力オブジェクトにデータを送る。
例： Average Mileageサブシステム（Monitoringサブシステム中にある。）
デバイス入力： Mileage Reset Buttons（MPHリセットとMPGリセットを発生し、それぞれのリセットボタンに対応。）, Gas Tank（ガスタンクの実体に対応。Fuel Levelで燃料残量を読み出せる。）
デバイス出力： Mileage Display（実世界にデータを出力）
制御： （状態がないので）なし
不定期： MPG Reset（図13.15： Cumulative DistanceとFuel Levelデータ・ストアを読んでInitial Distance and Fuel Levelデータ・ストアに保存するInitialize MPG関数を呼び出す。）, MPH Reset（Fuel Levelの代わりに現在時刻を見ることを除いてInitial MPG関数と類似する Initial MPH関数を呼び出す。）
定期： MPG Timer（図13.16： Initial Distance and Fuel Level、 Cumulative DistanceとFuel Levelデータ・ストアを読んでAverage MPGを計算するComputing Average MPG関数を呼び出す。）, MPH Timer（Fuel Levelの代わりに現在時刻を見ることを除いてComputing Average MPG関数と類似する Computing Average MPH関数を呼び出す。）
図13.17は図13.15と図13.16を結合したもの。
|
対RTSA |
類似点 |
記法、状態遷移図の利用 |
|
相違点 |
並行性及び問題領域のオブジェクトの強調 |
|
|
対JSD |
類似点 |
並行オブジェクトと並行関数を用いてモデル化を行う |
|
相違点 |
問題領域におけるオブジェクト構築の規準、状態遷移図による制御オブジェクトの定義（実時間システムではしばしばJSDの実体構造図より有用） |
|
|
対OOA |
類似点 |
オブジェクト構築の規準 |
|
相違点 |
並行性の強調、情報モデルというよりむしろ有限状態機械であることを強調、挙動分析に対する包括的な取り組み |
前半目次：
l システム・コンテキスト図の作成
l サブシステム・コンテキスト図
l システムの分解について
l サブシステムの特徴
l サブシステム構築規準
l システム分解の例
l 実時間構造化分析（RTSA）の記法
l 状態遷移図
l イベント・フロー図
l 制御変換図
l データ変換図
l ミニ仕様
l データ定義
問題領域における並行オブジェクトを決定する規準。
（オブジェクトとそれに関連した関数としてシステムとサブシステムを構築することを助ける。）
l 外部デバイスI/Oオブジェクト
l ユーザー役オブジェクト
l 制御オブジェクト
l データ抽象オブジェクト
l アルゴリズム・オブジェクト