JP4637175B2 - 二次的に実行されるプロセスにおけるデッドロックを検出する方法 - Google Patents

Description

本発明は、リアクティブシステムのオブジェクト指向で記述されたシステムモデルに関して、或る状態にある少なくとも１つのオブジェクトが所定の状態にある異なるオブジェクトを待機する、二次的に実行されるプロセスにおけるデッドロック（Deadlocks）を検出する方法に関する。

リアクティブシステムの開発および構築のために、いわゆる統一モデリング言語ＵＭＬがオブジェクト指向の設計の領域における標準モデリング言語になった。このグラフィック的なオブジェクト指向のコンピュータ実装言語を用いることによりソフトウェアプログラムだけではなく、例えば自動車や飛行機のような複雑な技術システムも記述することができ、またそれらの機能性も検査することができる。これらの分野においては高い安全性が要求されるので、設計段階において既に誤動作を確実に識別できるようにするために、標準モデリング言語と形式的な方式とを組み合わせることが所望されている。その種のシステムにおいては、周期的なプロセスにおいてデッドロックが生じる可能性もある。デッドロックとは情報科学において、少なくとも２つのプロセスがそれぞれ異なるプロセスに対応付けられている動作手段を相互に待機するプロセスの状態を表す。これによって２つのプロセスが相互にブロックし合う。デッドロックは個々のプロセスの終了またはシステムの再始動によってしか解消することができない。これらのプロセスの終了およびシステムの再始動は安全性が重要なシステムにおいて非常に問題になる可能性がある。

デッドロックは、複数のプロセスを並行して実行することができ（マルチタスクシステム）、また動作手段の割り当ての順序が規定されていないシステムにおいて生じる可能性がある。

例えば、Electronic Notes in Theoretical Computer Science 47 (2001)、第１〜１３頁におけるT. Schaefer、A. KnappおよびS. Merzらによる「Model Checking UML State Machines and Collaborations」には、比較的小さいシステムに関するデッドロックからの解放ならびに他のモデル特性をモデルチェック方式により検査する方法が記載されている。これらは不利なことにシステムのモデルチェッカ入力言語への変換を必要とする特殊化されたコンピュータプログラムである。この場合状態マシンの各状態が個々のプロセスによってモデリングされる。ＵＭＬシステムモデルの各状態マシンに関して、イベント待ち行列に記憶されているイベントを出力し、また遷移を処理するための２つの付加的なプロセスが使用される。しかしながらオブジェクト指向のシステムモデルを検査するために、能力が非常に制限されたモデリングによる利用可能なモデリング言語への煩雑な変換が必要とされる。非常に大きい状態空間となるオブジェクト指向のモデルのデータタイプの考慮も大きな問題である。これによって検査可能なシステムモデルの大きさは制限されている。

したがって本発明の課題は、リアクティブシステムのオブジェクト指向で記述されたシステムモデルに関して二次的に実行されるプロセスにおけるデッドロックを検出するための改善された方法を提供することである。

この課題は以下のステップにより解決される：
ａ）オブジェクト指向のシステムモデルの全てのアクティブなオブジェクトを抽出する。
ｂ）アクティブなオブジェクトによって消費されるイベントおよび／または生成されるイベント、オブジェクトの間の遷移、およびオブジェクトの状態振る舞いを記述するシステムモデルを記述するためのＵＭＬシステムモデルの状態マシンのガード条件を少なくとも識別する。
ｃ）所定の状態にある別のオブジェクトを所定の状態において待機するオブジェクトのリストとして、イベントからアクティブなオブジェクト間の状態・待機関係を形成する。
ｄ）相互に待機している２つまたは複数の異なるオブジェクトのインスタンスの周期としての考えられるデッドロック状況を求める。ここで各デッドロック状況に関して、この周期においては１つ以上の状態を持つオブジェクトは包含されておらず、また、この周期のいずれのオブジェクトも周期外のオブジェクトを待機しない。
ｅ）求められた考えられるデッドロック状況の到達可能性を分析するために、求められたデッドロック状況に繋がり且つＵＭＬシステムモデルの状態マシンから導出される全ての考えられるパスを、イベントおよびアクティブな遷移を考慮して、ＵＭＬシステムモデルをシミュレーション的に実施することによって検査する。

そのような方法を用いることにより複雑なデータタイプを考慮しながら、複数の並列なコンポーネントを有する技術的なリアクティブシステムのオブジェクト指向の大きなシステムのモデルに関するデッドロックからの解放を証明することができる。

本発明によれば複数段階式の検査方法が提案される。ステップａ）およびｂ）により、システムモデルのデッドロックに関連する特性が抽出され、これに基づきステップｃ）において状態待ち図が形成され、この状態待ち図をアクティブなオブジェクト間にどのような待機関係が存在するかを発見するために統計的に分析することができる。この際アクティブなオブジェクトの中間状態が表される。

第２の段階においては考えられるデッドロック状況が求められる。デッドロック状況が発見されなかった場合には方法は終了され、結果を表すことができる。そうでない場合には第３の段階において、先行する段階において発見された識別されている潜在的なデッドロック状況において考えられるパスを探索アルゴリズムを用いて計算することにより、求められた考えられるデッドロック状況の到達可能性の分析が行われる。続いてこれらのパスが発見的なシミュレーションによって実施できるか否かが分析される。

本発明の範囲におけるアクティブなオブジェクトとは、プロセスを表すためにシステムモデリング言語において使用される言語手段である。オブジェクト指向のモデルにおけるアクティブなオブジェクトはモデル化された技術的なリアクティブシステムの二次的に実行されるプロセスに相当する。二次的に実行されるプロセスは状況によっては周期的なものでもよい。このことはリアクティブシステムにおいてはしばしば生じる場合であるが、本方法を使用するための必須の条件ではない。

有利には、全てのアクティブなオブジェクトを抽出するステップａ）においては、アクティブなオブジェクトがシステムモデルの静的および動的な構造態様から抽出され、オブジェクトリストに記憶される。

各アクティブなオブジェクトに対して、対応付けられているクラスがクラスリストに記憶され、クラスリストにおける各クラスに対して所属の状態図が状態マシンを特定するために評価される場合には有利である。特定された状態マシンを状態マシンリストに記憶することができる。

このようにして数学的なリスト構造が供給され、このリスト構造により効率的で分析的な評価が実現される。

有利には、それ自体公知の深さ優先探索方式を用いて、考えられるデッドロック状況が求められる。

求められた考えられるデッドロック状況の到達可能性の検査は有利には、システムモデルの初期状態に基づいて、その都度のアクティブな遷移が求められ、且つシステムモデルをデッドロックイベントに近付けるアクティブな遷移が選択されることによって発見的に行われる。

アクティブな遷移は例えば、対応付けられているオブジェクトに関するガード条件が真であり、且つオブジェクトのイベントが入力待ち行列にある場合に存在する。

有利には、各デッドロック状況に関して考えられる全てのパスを検査するステップｅ）（段階Ｃ）は、デッドロック状況に到達したか、全てのパスが所定回数実行されるまで繰り返し実施される。

システムモデルは殊に有利には統一モデリング言語ＵＭＬで記述されている。

さらに本発明の課題は、コンピュータプログラムが計算機上で実行される場合に、上述の方法を実施するためのプログラムコード手段を有するコンピュータプログラムによって解決される。

以下では本発明を例示的な図面に基づき詳細に説明する。ここで：
図１はデッドロックを検出する本発明による方法のフローチャートを示し、
図２は例示的な測定システムモデルの静的なシステム構造（クラス図）を示し、
図３は図２による例示的な測定システムモデルの動的なシステム構造を示し、
図４は例示的な測定システムモデルのコントローラの振る舞いの詳細図を示し、
図５は例示的な測定システムモデルの第１のセンサの振る舞いの詳細図を示し、
図６は例示的な測定システムモデルの第２のセンサの振る舞いの詳細図を示し、
図７は例示的な測定システムモデルのクロックの振る舞いの詳細図を示し、
図８は例示的な測定システムのユーザの振る舞いの詳細図を示し、
図９は潜在的なデッドロックを識別するための例示的な実行の状態待ちグラフを示し、
図１０は測定システムモデルを例とした本発明による方法の分析結果を表すシーケンス図を示す。

図１は二次的に実行されるプロセスにおけるデッドロックを検出するための本発明による複数段階式の方法のフローチャートを示す。

出発点は統一モデリング言語ＵＭＬを用いてグラフィック的にオブジェクト指向で記述されたシステムモデルであり、これを以下ではＵＭＬシステムモデルと称する。本方法は、技術システムをオブジェクト指向で記述する他の記述言語にも同様に適している。

第１の段階ａ）においては、ＵＭＬシステムモデルのアクティブなオブジェクト、ならびにそのオブジェクトの特性および関係が抽出される。ＵＭＬシステムモデルのデッドロックに関連する特性が抽出され、数学的な構造、例えばリスト、セット、組の形で記憶され、これにより後続の段階における効果的なアルゴリズムを用いた評価が実現される。

抽出の際にＵＭＬシステムモデルの全てのアクティブなクラスがそのコミュニケーション特性に関して分析される。このことは具体的には、それぞれのアクティブなクラスに関して、生成されるイベントおよび消費されるイベントのレコードが計算され、生成イベントリストおよび消費イベントリストとして記憶されることを意味している。これに関しては、呼出イベントが消費イベントと見なされ、呼出動作が生成イベントと見なされる。イベントは、その生成と消費が適切に関連付けされている場合にのみ考慮される。

第２の段階ｂ）においては、潜在的なデッドロックイベントを識別するための分析が行われる。この分析は、アクティブなオブジェクト間にどのような待ち関係が存在するかを発見するために、ＵＭＬ状態図を静的に評価することによって行うことができる。このために、典型的な待ちグラフとは異なりアクティブなオブジェクトの内部状態を表す状態待ちグラフが挿入される。状態待ちグラフにおける周期の検出により、潜在的なデッドロックの存在および場所が明らかになる。

潜在的なデッドロックは、それぞれが特定の状態にあるシステムの競合的または並列的なコンポーネント間の周期的な待ち状況である。潜在的なデッドロックを状態待ちグラフにおいて識別することができる。このグラフは指向性のグラフであり、このグラフにおいては各ノードが（対応付けられている状態図の）特定の状態にあるアクティブなオブジェクトを表し、また各エッジが「待機」関係を表す。状態待ちグラフの頂点数は、アクティブなクラスに対応付けられている、モデルの全ての状態図の状態の数に等しい。エッジの数はこの状態図において定義されている遷移に依存する。各エッジのヘッドは特定のイベントを待つノードと繋がっている。エッジの終端部と繋がっているノードはこの特定のイベントの潜在的な発起点である。

潜在的なデッドロック状況の分析は状態待ちグラフの形成により開始される。このことは、アクティブなオブジェクトおよびその特性および関係を抽出する段階における計算、例えば消費リストおよび生成リストの計算によって実施される。システムの全ての状態待ちグラフを形成した後には、潜在的なデッドロック状況を検出することができる。潜在的なデッドロック状況とは、それぞれが特定の状態にある２つまたは複数のオブジェクトが相互に所定のイベントの発生を待つ状況である。

ここで本発明による方法においては、段階ｂ）において状態待ちグラフにおける全ての周期が検出され、関連する周期が選別される。この際周期は潜在的なデッドロックではなく、周期の全てのノードは同一のオブジェクトである相応の状態図内の論理的なエラーである。これに対して、１つ以上の状態を有するオブジェクトが周期に包含されていない場合に、異なるオブジェクトの２つまたは複数のノードを有する周期は潜在的なデッドロック状況である。他方では、「過関与」のオブジェクトを有する周期も問題である。状態待ちグラフにおける全ての周期の検出は、それ自体公知の改善された深さ優先探索アルゴリズム（Depth-First-Search Algorhythm）を用いて実施され、この深さ優先探索アルゴリズムはグラフの全ての周期および個々の実行の分布を計算する。論理的なエラーおよび「過関与」のオブジェクトを有する周期は集合演算を用いて実施される。続いて残りの潜在的なデッドロック状況が出力エッジに関して検査される。このことはグラフを横断することによって、また各ノードの開始等級を計算することによって実施される。開始等級はノードから出るエッジの数である。全てのノードが１の開始等級を有する場合には、本発明の範囲において潜在的なデッドロック状況が存在する。１より大きい開始等級を有するノードが存在する場合には、検査される周期が潜在的なデッドロックであるか否かは、周期から外部を示すエッジの目標オブジェクトに依存する。目標オブジェクトが考察される周期に包含されていない場合には、検査される周期はデッドロックではない。他方では、エッジが同一のオブジェクトの２つの状態と繋がっているか否かを検査する必要がある。この検査においてエッジが同一のオブジェクトの２つの状態と繋がっていることが確認されると、潜在的なデッドロックは論理的なエラーと組み合わされる。またこの論理的なエラーはデッドロックの識別が継続される前に訂正されることが望ましい。さもなければ、状態待ちグラフにおける後に評価されるべき別の周期が識別される。この場合には後続の段階ｃ）を開始することができる。何故ならば、全ての周期が発見されており、潜在的なデッドロック状況の到達可能性のさらなる分析において別個に処理されることが周期検出により保証されているからである。

潜在的なデッドロック状況とは、デッドロックが生じることが統計的に考えられるということを意味している。しかしながらデッドロックイベントが実行時間中に実際に生じるか否かは、潜在的なデッドロック状況を識別するための分析の段階ｂ）とは別個に、潜在的なデッドロック状況の到達可能性の分析に続く段階ｃ）において検査されるシステムモデルの動的な態様に依存する。

段階ｂ）において潜在的なデッドロック状況が発見されない場合にはシステムにデッドロックは存在していないので、後続の段階ｄ）にスキップすることができる。

段階ｃ）においては、潜在的なデッドロック状況の到達可能性の分析が行われる。ここで、潜在的なデッドロック状況において考えられるパスが探索アルゴリズムを用いて計算され、続いて発見的なシミュレーションアプローチを用いてこれらのパスは実行可能であるか否かが分析されることによって、段階ｂ）において識別された潜在的なデッドロック状況がそれぞれ検査される。探索アルゴリズムは関連する各状態図に対して特別な深さ探索を実施し、潜在的なデッドロック状況についての全てのパスをパスリストに記憶する。各パスリストはそれぞれのパスの全ての状態および遷移を包含する。

パスリストは後続の発見的なシミュレーションのための入力データとして使用される。シミュレーションにおいてはＵＭＬシステムモデルの状態マシンがシミュレータを用いて実施されており、このシミュレータはＯＭＧ標準（www.omg,org）による正確なＵＭＬ意味論（セマンティック）を実施する。待ち行列の長さおよび意味論において定義されている表現の検査順序のような非常に特殊な特徴の他に、モデルの以下の態様を考慮する必要がある：
ガード条件、イベントパラメータ値および属性値。

１つまたは複数のパスが潜在的なデッドロック状況に存在する場合には、実施可能なパスをシミュレーションの間に発見すれば十分である。別の場合には実質的により煩雑である。パスリストの全てのパスが一度実施され、その際に実施可能なパスが発見されなかった場合には、実施可能なパスが存在するか否かを推量することはできない。また論理的に無限数の実施後であっても、次の実施では潜在的なデッドロック状況が生じないと確実に言うことはできない。したがってシミュレーションを設定可能な回数ｎ回実施した後に中断することが提案される。

この発見的なシミュレーションアプローチの欠点は、段階ｃ）においては到達できない潜在的なデッドロック状況が存在する場合、すなわちｎ回のシミュレーション後に実施可能なパスを発見できなかった場合にはデッドロックの不存在を証明することができないということである。この例外的な場合には、完全に展開された状態空間にわたる煩雑な探索のみがモデル検査の助けとなる。

最後の段階ｄ）においては分析結果が表示される。このことは例えば拡張されたＵＭＬシーケンス図を用いて行うことができる。

以下では本発明による方法を測定システムモデルの例に基づき説明する。この測定システムモデルは第１のセンサSensor1および第２のセンサSensor2、制御ユニットControllerならびにクロックClockから構成されている。センサSensor1，Sensor2は測定ユニットを有し、この測定ユニットが実際の測定を実施し、また測定システムモデルにおけるその測定の振る舞いが抽象化される。クロックはタイミング装置を有し、このタイミング装置は時間の経過をモデリングし、呼出時には目下の時点をフィードバックする。クロックの正確な機能からも測定システムモデルにおいて抽象化が行われる。クロックはタイムスタンプを有する測定値を提供するためにセンサSensor1，Sensor2によって要求とされる。制御ユニットControllerはコンポーネントの開始に関して権限を有しており、またシステムの実行時間の間に２つのセンサSensor1，Sensor2に繰り返し問合せを行う。ユーザはシステムを開始および停止することができる。分析を目的としてユーザの振る舞いをモデリングすることができる。

図２は測定システムの静的なシステム構図をクラス図として示す。

クラス図において使用されている符号＋および−は後ろに付いている要素の可視性を表す。「＋」でもって注釈が付けられている全ての要素（動作および／または属性）はパブリック（ｐｕｂｌｉｃ）として宣言されている。これらの要素は該当するクラスと関連付けられている他の全てのクラスに対して可視である。「−」でもって注釈が付けられている要素はプライベート（ｐｒｉｖａｔｅ）であり、したがって該当するクラス内でのみ可視である。すなわち、プライベート要素を例えば所属の状態図においてそのクラス自体から呼び出すことができるが、他のクラスから呼び出すことはできない。この実施例においては、クラスの全ての動作がパブリックであり、したがって「＋」が付されて宣言されている。値を記憶するために使用される属性のみがプライベートであり、「−」が付されて宣言されている。このことはオブジェクト指向のモデリングにおける秘密原理に相当し、またクラスの属性の値をそのクラスの動作によってのみ処理できるように機能し、したがって二次的な作用の危険を制限する。

ユーザが２つの値、すなわちValue1，Value2に関するリクエスト「Give_Measured Value」を行い、ユーザはこれらの値をコントローラからパラメータとして受け取ることが見て取れる。コントローラは測定プロセスを命令「+Start()」により開始し、また第１のセンサSensor1および第２のセンサSensor2の測定値を要求する（Give_Measured Value_Sensor1、Give_Measured Value_Sensor2）。

リクエストはコンポーネントSensorを介して実際の測定を実施する測定ユニットMeasureing unitに転送され、この際タイムスタンプが測定時のクロックからの命令「Give_Time Stamp」により各センサSensor1，Sensor2に対して問い合せられる。測定値はセンサSensor1，Sensor2を介してタイムスタンプと共にコントローラControllerに返送され、またこのコントローラControllerを介してユーザUserに返送される。

図３は測定システムモデルの動的なシステム構造のブロック図を示す。コントローラがクロックClockのパラメータ化のために使用され、このクロックClockはセンサSensor1，Sensor2による測定の際の時間測定Time Measurement1，Time Measurement2を実施することが見て取れる。測定値はタイムスタンプと共に、信号Measurement1，Measurement2としてコントローラControllerに返送され、このコントローラControllerを介してユーザUserの環境に返送される。

個々のシステム要素の振る舞いは以下の通りである。

図４はコントローラControllerの振る舞い図を示す。初期化の後にコントローラControllerはクロックClockをパラメータ化し、このクロックClockを命令「Start／Clock.Start」によりスタートさせる。さらには第１の測定（Measurement1）が命令「Sensor.Request_Measured Value」により開始される。続いて第１のセンサ（Sensor1）の測定値がリクエストされ（Ｇｉｖｅ_Measured Value_Sensor1 (Measured Value)／Measured Value1:=Measured Value）、また第２のセンサ（Sensor2）による第２の測定（Measurement2）が命令「Sensor2.Request_Measured Value」により開始される。第２の測定（Measurement2）から第１の測定（Measurement1）へのフィードバックが、命令「Sensor1.Request_Measured Value」による第１のセンサSensor1における測定値の新たなリクエストのリクエスト「Give_Measured Value_Sensor2(Measured Value)/Measured Value2:=Measured Value」により行われ、また必要に応じて測定のユーザへの転送が命令「User.Give_Measured Value(Measured Value1, Measured Value2)」により行われる。

このループはクロックClock、第１のセンサSensor1および第２のセンサSensor2に対するストップ信号（Stop/Clock.Stop/）;Sensor1.Stop; Sensor2.Stopが出力されるまで継続される。

図５は第１のセンサSensor１の振る舞い図を示す。初期化後に、命令「Request_Measured Value/Clock.Request_Time stamp_Sensor1」を用いたクロックClockにおけるタイムスタンプのリクエストにより測定が行われる。状態Fetch_Timeの結果は測定値Sensor1（Give_Time Stamp/Current:=Measuring unit.Measurement();Controller.Give_Measured Value_Sensor1(Current)）と結合するための第１のセンサSensor1へのタイムスタンプの転送である。

ストップ信号「Sensor1.Stop」を受け取ると、状態「Measure」は終了する。

図６は第２のセンサSensor2の相応の振る舞い図を示す。説明に関しては前記を参照されたい。

図７はクロックClockの振る舞い図を示す。初期化後にコントローラControllerによりクロックClockのパラメータ化が開始され、また信号「Start」により実行状態「current」が開始される。この状態はタイムスタンプを第１のセンサSensor1に転送し（Sensor1,Give_Time Stamp(Time stamp)）、またタイムスタンプをタイマの目下の時刻にセットすることによって第２のセンサSensor2によるタイムスタンプのリクエストに応答する（Request_Time Stamp_Sensor2/Time stamp:=Timer.Current_Time()）。状態「Request_1」が依然としてセンサSensor1，Sensor2のいずれか１つによるタイムスタンプのリクエストを確認すると、命令「Request_Time Stamp_Sensor2/Time stamp:=Timer.Current_Time」でもって第２のセンサSensor2についてのタイムスタンプが確認され、また第２のセンサSensor2には命令「Sensor2.Give_Time stamp(Time stamp)」が対応付けられる。

そうでない場合には命令「Stop」でもって状態が停止される。

ユーザUserの振る舞い図が図８に示されている。
初期化後に状態「Start」において命令「Controller.Start」によって制御ユニットが始動され、イベント「Give_Measured Value」が制御ユニットから要求されることによって状態「Observer」が呼び出される。続く状態「Observer2」においては制御ユニットによって測定値が待機され、またループにおいては制御ユニットからのリクエスト「Give_Measured Value」によってさらなる測定が要求される。状態は制御ユニットへの命令「Controller.Stop」によって終了される。

この例示的な測定システムモデルに関して、図１を参照しながら段階ａ）からｄ）について詳細に説明する。

特徴を抽出する段階ａ）においては、デッドロック検出のために必要とされる特徴がＵＭＬシステムモデルから抽出され、以下説明する構造に記憶される。

先ず、静的な構造および動的な構造態様（クラス図およびオブジェクト図）を使用して、分析の際にシステムのどのコンポーネントが考慮されるべきかが求められる。これはＵＭＬシステムモデルの種類に依存するので、ＵＭＬシステムモデルは特殊な形態（ＵＭＬダイアレクト）として存在する必要がある。この例においては、システムの個々のコンポーネントの形成によって抽象化が行われる。システム全体を始動する際に全てのアクティブなオブジェクトが形成され、またこのオブジェクトがクラス図において所属のクラスに関してモデル化された全ての特性を有することを前提とする。オブジェクト間のリンク（クラス間のアソシエーションのインスタンス）はクラス図において所属のインスタンスを持つ特性を有する。

さらにはオブジェクトをインスタンスと見なす場合に、コンポジション関係によってこれらに対応付けられているオブジェクトも同様にインスタンスと見なされることを前提とする。したがってオブジェクト図に示されている全てのオブジェクトはまさに検出時に考慮すべきオブジェクトである。

統一モデリング言語ないし相応のＵＭＬプロフィールの使用分野に応じて、特徴抽出のこの部分を種々に実施することができる。しかしながらこのことは本発明の対象ではない。

オブジェクト図から全てのアクティブなオブジェクトが抽出されてオブジェクトリストに記憶された後には、このリストが一度だけ実行され、各オブジェクトに対して所属のクラスがクラスリストに記憶される。クラスリストの長さはNumber_Classesとして記憶される。続いてクラスリストにおける各クラス、すなわちアクティブなクラスに関して所属の状態図が分析され、またそこにおいて特殊化された状態マシンが状態マシンリストに記憶される。

続いて、全てのオブジェクトがクラスリスト内の対応付けてられているクラスに基づき、その生成されるアクションに関して検査される。このために適切な状態マシンを状態マシンリストからその都度選択し、全ての遷移を順番に検査する必要がある。各遷移は０〜ｎ＝任意の複数のアクションをトリガすることができる。ＵＭＬ言語において定義されている種々のアクションのタイプのうち、本方法によっては呼出アクション（Call Action）のみが考慮される。さらに本方法は選択的にシグナルアクション（Send Action）も考慮することができる。通常の場合モデリングの種類に応じて２つのアクションのタイプの内の一方のみが使用されるので、本方法を以下では呼出しアクションについてのみ言及する。

発見された呼出アクションはアクションテーブルに記憶され、このアクションテーブルは以下のように構築されている：
Object Action
Object 1 {[state, target object, target event],...}
ここでアクションテーブルにおいては、エントリObjectの下にオブジェクト名を発見することができ、またエントリActionの下に０〜ｍ個の複数のアクションを発見することができ、これらのアクションはそれぞれコンポーネントstate，target object，target eventから構成されている。個数ｍは遷移によってトリガすることができるアクションの数である。stateは、所属の遷移が切り替えられたときにオブジェクトがアクションを生じさせることができる状態マシンの状態である。target objectは呼出アクションがアドレッシングするオブジェクトである。target eventは、イベントの際に生じ、且つ入力待ち行列に置かれるtarget objectのイベントである。

続いて待機セットテーブルが形成される。このテーブルは、オブジェクトリストからの各オブジェクトに対して、クラスリストからの所属のクラスを介して状態マシンリストから所属の状態マシンが選択され、またオブジェクトがどのような状態においてどのイベントを待機し、またどのオブジェクトがそれぞれのイベントを発生させることができるかを確認することによって求められる。それぞれのイベントをどのオブジェクトが発生させることができるかという情報はアクションテーブルから取得される。

待機セットテーブルは以下の形態を有する：
Object Wait set
Object 1 [State 1, (Object 2. State 1, Object 2. State 2)], [State 2, (Object 3. State 2)]...
ここではアクションテーブルと同様にエントリObjectの下にオブジェクト名が記されている。待機セットは、オブジェクトの状態マシンの各状態に関して、複数のオブジェクト・状態組み合わせを記憶することができるように構成されている。オブジェクト・状態組み合わせは「Object.State」の形式を取り、ここで「Object」は待機されるオブジェクトを表し、「State」は待機される状態を表す。

上記のテーブルにおいては、例えばState1にあるObject1はState1にあるObject2とはState2にあるObject2を待機する。数学における他のあらゆるセットと同様に、この待機セットも重複していない。

待機セットテーブルの作成後に特徴抽出の全てのイベントが構造「Model features」に統合され、この構造は全ての特徴への効率的なアクセスを可能にし、また他の段階ｂ）、ｃ）およびｄ）においても使用することができる。

例示的な測定システムモデルに関して特徴抽出の結果は以下の通りである：
クラス数＝５
オブジェクトリスト ＝ [User -> Object, Con -> Object, Sn1 -> Object, Sn2 -> Object, U -> Object]
クラスリスト ＝ [User -> Class, Controller -> Class, Sensor1 -> Class, Sensor -> Class, Clock -> Class]
アクションテーブル
Object Action
User ([Start, Con, Start])
Con ([Parameterizing, U, Start], [Measurement1, Sn2, Request_Measured Value], [Measurement2, User, Give_Measured Value], [Measurement2, Sn1, Request_Measured Value], [Measurement2, Clock, Stop], [Measurement2, Sn1, Stop], [Measurement2, Sn2, Stop])
Sn1 ([Measure, U, Request_Time Stamp_Sensor1], [Fetch_Time, Con, Give_Measured Value_Sensor1])
Sn2 ([Measure, U, Request_Time Stamp_Sensor2], [Fetch Time, Con, Give_Measured Value_Sensor2])
U ([current, Sn1, Give_Time Starnp], [Request_One, Sn2, Give_Time Stamp])
待機セットテーブル：
Object Wait set
User [Observe, (Con.Measurement2)], [Observe2, (Con.Measurement 2)]
Con [Parameterizing, (User.Start)], [Measurement1, (Sn1.Fetch_Time)], [Measurement2, (User.Observe2)]
Sn1 [Measure, (Con.Measurement2)], [Fetch_Time (U.Current)]
Sn2 [Measure, (Con.Measurement1)], [Fetch_Time, (U.Request_One)]
U [Parameterizing, (Con.Perametering)], [Current, (Sn2.Measure)], [Request_One, (Sn2.Measure, Con.Measurement2)]

待機セットテーブルの作成後にこれらの特徴が構造「Model features」に統合され、また本方法の他の段階ｂ）、ｃ）およびｄ）においても使用される。これによって種々の特徴への効率的なアクセスが実現される。

段階ｂ）「潜在的なデッドロック検出」においては待機セットテーブルからいわゆる状態待ち図が形成される。これは、ノードがオブジェクト・状態組み合わせを表し、またエッジが「待機関係（Wait-For-Relations）」を表すグラフである。このグラフから、Object 1はState 1においてState 1にあるObject 2を待機などの結論を導き出すことができる。待機セットと同様にグラフのエッジセットは重複していない。これによりグラフへのアルゴリズムの適用が簡単になり、またその複雑性が低減される。

本発明の範囲における潜在的なデッドロック状況とは、何らかの別の特性を有する周期的な「待機」関係である。

潜在的なデッドロック状況を識別するための分析の段階ｂ）は２つのステップで機能する。第１のステップにおいては状態待ち図に基づき周期識別が実施される。結果は多数の潜在的なデッドロック状況である。第２のステップにおいては、以下の特性を有する潜在的なデッドロック状況が潜在的なデッドロックのセットから選別される：
ａ）１つのオブジェクトが複数の状態を有し、デッドロックに関与している。
ｂ）デッドロックに関与しないオブジェクトについてのエッジが存在する。
ｃ）ただ１つのオブジェクトのみがデッドロックに関与している。

選別されなかった全てのデッドロック状況が潜在的なデッドロックの最終的なセットを形成する。

周期を識別する本方法は一般的に周知の深さ優先探索方式を基礎とする。

図９は測定システムモデルに関する例示的な状態待ち図を示す。

周期識別後の潜在的なデッドロックのセットは以下の通りである：
((User.Observe2, Con.Measurement2), (Con.Measurement1, Sn1.Fetch_Time, U.Current, Sn2.Measure))

選別後の潜在的なデッドロックのセットは以下のように低減されている：
((Con.Measurement1, Sn1.Fetch_Time, U.Current, Sn2.Measure))

エッジは状態待ち図においてCon.Measurement2からSn2.Fetch_Timeに存在し、したがってこのエッジに関して上記の条件ｂ）が充足されている、すなわちデッドロックに関与していないオブジェクトについてのエッジが存在するので、潜在的なデッドロック状況（User.Observe2, Con.Measurement2）が選別された。

潜在的なデッドロックの最終的なセットは、潜在的なデッドロックイベントの達成可能性を分析する後続のステップｃ）に引き渡される。

デッドロック到達可能性分析は、発見された潜在的なデッドロックがシステムの実行時に到達する可能性があることを検査するために使用される。ここでもまた、到達可能性分析のために使用することができる種々の標準的な方法が存在する。デッドロック到達可能性分析の段階においては、非常に好適な時間複雑性によりもたらされる実行時間に関する利点も損なわれないということは本方法にとって殊に重要である。必要とされる時間は状態待ち図のノードおよびエッジの数に対して恐らく線形の特性を有する。

この理由から段階ｃ）における到達可能性分析においては発見的な方法が使用される。遷移の際のイベントおよびアクションの他に、状態マシンのガード条件も考慮される。

潜在的なデッドロックイベントの到達可能性を分析する第１のステップは、関連するオブジェクトのローカルパスの計算である。このために、モデルの状態マシンから導出することができるいわゆるパスリストが構成される。続いて、モデルの初期状態から出発して、どの遷移がその都度アクティブであるか、すなわちどの遷移を切り替えることができるかが検査されることによってモデルの実施がシミュレートされる。ガード条件が真であり、且つイベントが入力待ち行列にある場合には、遷移を正確に切り替えることができる。続いて適切な発見的方法従い、モデルを潜在的なデッドロック状況により近付ける遷移がその都度選択される。

潜在的なデッドロック状況に到達したか、全てのパスが所定数ｎ回実行されても、デッドロックの潜在的な状態に到達できなかった場合にはシミュレーションが中断される。後者の場合には、デッドロックの潜在的な状態にまだなお到達する可能性があるか否かについて言及することはできない。

到達可能性分析の際にはパスリストおよびトレースセットが形成される。パスリストは以下の形態を有する：
パスリスト = {[(Z1, Z2),...,(Zi, Zj)],...},
ここで（Z1，Z2）は対応付けられた組であり、Z1は遷移の起源状態であり、Z2は遷移の目標状態を表し、Zjは潜在的なデッドロック状況のセットにある。

複数のオブジェクトを有するモデルに関するモデル状態は
<O_1.Z,...,O_n.Z, O_1.A_1,...,O_n.A_m, ES_1,... ES_n>
によって与えられており、ここでO_i, 1< i <n, m >= nはそれぞれのオブジェクトを表し、またZはオブジェクトのその都度の目下の状態を表す。
A_j, 1 <= j <= mは該当するオブジェクトのその都度の属性の目下の値であり、また
ES_iはO_iの入力待ち行列である。

すなわち各モデル状態には、全てのオブジェクトの状態（全ての属性値）ならびに入力待ち行列が属する。

トラックセットは全てのシーケンスのセットである。
{[M_a, (O.Z_a, O.Z_b), M_z]},
ここでM_aはモデルの初期状態であり、M_zはシミュレーションの中断前の最後の状態であり、(O.Z_a, O.Z_b)はオブジェクトのZ_a,からZ_bへの遷移を表す。

アクションの実施、イベントの発生など共には記録されずに、モデル状態の変化時に識別することができる。

測定システムモデルを例とする到達可能性分析の結果は以下の通りである：
入力：
選別後の潜在的なデッドロック状況のセット ＝ {{Con.Measurement1, Sn1.Fetch_Time, U.Current, Sn2.Measure}}
出力：
Path List_User = {(Start, Observe)}
Path List_Con = ({Parameterizing, Measurement1)}
Path List_Sn1 = {(Measure,Fetch_Time)}
Path List_Sn2 = {}
Path list_U = {(Parameterizing, Current)}
Trace_Set = {<User.Start, Con.Parameterizing, Sn1.Measure, Sn2.Measure, U.Parameterizing, Con.A.Measured value1 = 99.9, Con.A.Measured value2 = 99.9, Sn1.A.Current = 999, U.A.Time stamp = 999, User.ES = [], Con.ES = [], Sn1.ES = [], Sn2. ES = [], U.ES = []>, (User.Start, User.Observe), <User.Observe, Con.Parameterizing, Sn1.Measure, Sn2.Measure.U.Parameterizing, Con.A.Measured value1 = 99.9, Con.A.Measured value2 = 99.9, Sn1.A.Current = 999, U.A.Time stamp = 999, User.ES = [], Con.ES = [Start], Sn1.ES = [], Sn2.ES = [], U.ES = []>, (Con.Parameterizing, Con.Measurement1), > User.Observe, Con.Measurement1, Sn1.Measure, Sn2.Measure, U.Parameterizing, Con. A.Measured value1 = 99.9, Con.A.Measured value2 = 99.9, Sn1.A.Current = 999, U.A Time stamp = 999, User.ES =[], Con.ES = [], Sn1.ES = [Request_Measure Value], Sn2.ES = [], U.ES = [Start] >, (U.Parameterizing.U.Current), <User.Observe, Con.Measurement1, Sn1.Measure, Sn2.Measure, U.Current, Con.A.Measured value1 = 99.9, Con.A.Measured value2 = 99.9, Sn1.A.Current = 999, U.A.Time stamp = 999, User.ES = [], Con.ES = [], Sn1.ES = [Request_Measured Value], Sn2.ES = [], U.ES = [] >, (SN1.Measure, Sn1.Fetch_Time), <User.Observe, Con.Measurement1, Sn1.Fetch_Time, Sn2.Measure, U.Current, Con.A.Measured value1 = 99.9, Con.A.Measured value 2 = 99.9, Sn1.A.Current = 999, U.A.Time stamp = 999, User.ES = [], Con.ES = [], Sn1.ES = [], Sn2.ES = [], U.ES = [Request_Time Stamp_Sensor1]>}

段階ｄ）においては分析結果が表される。方法結果の視覚化は、基礎となるＵＭＬ知識およびシステムモデリングにおける経験を有するシステム開発者に向けられている。この際実際の表示手段は公知のシーケンス図であり、このシーケンス図においてはメッセージのどのシーケンスによりデッドロック状況が生じるかを非常に良好に表すことができる。

図１０は検査された例示的な測定システムモデルに基づく到達可能性分析の結果に関するシーケンス図を示す。

この例においては、デッドロック状況に関与するメッセージを表すために図形記号←←----------が使用され、この記号はステレオタイプ<<deadlock>>を表す。

角が丸まっている枠は、デッドロックに関与するメッセージを光学的に統合するために使用される。付加的に、メッセージボックスにおいてはデッドロックに関与するオブジェクトの状況が表されている。

デッドロックを検出する本発明による方法のフローチャート。 例示的な測定システムモデルの静的なシステム構造（クラス図）。 図２による例示的な測定システムモデルの動的なシステム構造。 例示的な測定システムモデルのコントローラの振る舞いの詳細図。 例示的な測定システムモデルの第１のセンサの振る舞いの詳細図。 例示的な測定システムモデルの第２のセンサの振る舞いの詳細図。 例示的な測定システムモデルのクロックの振る舞いの詳細図。 例示的な測定システムのユーザの振る舞いの詳細図。 潜在的なデッドロックを識別するための例示的な実行の状態待ちグラフ。 測定システムモデルを例とした本発明による方法の分析結果を表すシーケンス図。

Claims (10)

1. リアクティブシステムのオブジェクト指向で記述されたシステムモデルに関して、或る状態にある少なくとも１つのオブジェクトが所定の状態にある異なるオブジェクトを待機する、二次的に実行されるプロセスにおけるデッドロックを検出する方法において、
   コンピュータが以下のステップ、すなわち、
   ａ）オブジェクト指向の前記システムモデルの全てのアクティブなオブジェクトを抽出するステップ、
   ｂ）アクティブな前記オブジェクトの状態振る舞いを記述するために、オブジェクトに所属する状態マシンにおいて、アクティブな前記オブジェクトによって消費されるイベントおよび／または生成されるイベント、前記オブジェクトの間の遷移、前記消費されるイベントおよび／または生成されるイベントのオブジェクト・状態組み合わせおよび状態を少なくとも識別するステップ、
   ｃ）所定の状態にある別のオブジェクトを所定の状態において待機するオブジェクトのリストとして、イベントから前記アクティブなオブジェクト間の状態・待機関係を形成するステップ、
   ｄ）２つまたは複数の異なるオブジェクトがそれぞれ特定の状態において相互に所定のイベントの発生を待機する周期としての考えられるデッドロック状況を求めるステップ、この際、前記周期においては１つ以上の状態を有するオブジェクトは包含されておらず、且つ前記周期のいずれのオブジェクトも前記周期外のオブジェクトを待機せず、
   各デッドロック状況に関して、
   ｅ）求められた前記考えられるデッドロック状況の到達可能性を分析するために、求められたデッドロック状況に繋がり且つ前記システムモデルの前記状態マシンから導出される全ての考えられるパスを、前記イベントおよびアクティブな前記遷移を考慮して、前記システムモデルをシミュレーションすることによって検査するステップ
   を実施することを特徴とする、二次的に実行されるプロセスにおけるデッドロックを検出する方法。
2. 全てのアクティブなオブジェクトを抽出する前記ステップａ）において、前記アクティブなオブジェクトを前記システムモデルの静的および動的な構造態様から抽出し、オブジェクトリストに記憶する、請求項１記載の方法。
3. 各アクティブなオブジェクトに対して、対応付けられているクラスをクラスリストに記憶し、前記クラスリストにおける各クラスに対して、状態マシンを特定するために所属の状態図を評価し、特定された前記状態マシンを状態マシンリストに記憶する、請求項１または２記載の方法。
4. 公知の深さ優先探索方式を用いて、前記考えられるデッドロック状況を求める、請求項１から３までのいずれか１項記載の方法。
5. 求められた前記考えられるデッドロック状況の到達可能性の検査を、前記システムモデルの初期状態に基づいて、その都度のアクティブな遷移を求め、且つ前記システムモデルを前記デッドロック状況に近付けるアクティブな遷移を選択することによって発見的に行う、請求項１から４までのいずれか１項記載の方法。
6. 前記ステップｂ）における識別を２つのステップで実施し、第２のステップにおいては、以下の特性、すなわち：
   ａ）１つのオブジェクトが複数の状態を有し、デッドロックに関与している、
   ｂ）考えられるデッドロックに関与しないオブジェクトについての状態待ち関係において待ち関係が存在する、
   ｃ）ただ１つのオブジェクトのみが考えられるデッドロックに関与している、
   を有する潜在的なデッドロック状況を潜在的なデッドロックのセットから選別する、請求項１から５までのいずれか１項記載の方法。
7. 前記状態およびオブジェクト・状態組み合わせを待機セットテーブルに記憶する、請求項１から６までのいずれか１項記載の方法。
8. 待機セットテーブルにおいて、前記所属のオブジェクトに関する前記消費されるイベントおよび／または生成されるイベントの待機状態が真であり、且つ前記オブジェクトの前記イベントが入力待ち行列にある場合にアクティブな遷移が存在する、請求項１から７までのいずれか１項記載の方法。
9. 各デッドロック状況に関して考えられる全てのパスを検査する前記ステップｅ）を、デッドロック状況に到達するか、全てのパスが所定数（ｎ）実行されるまで反復的に実施する、請求項１から８までのいずれか１項記載の方法。
10. 前記システムモデルは統一モデリング言語で記述されている、請求項１から９までのいずれか１項記載の方法。

Images