(57)【特許請求の範囲】
【請求項１】
複数のコンポーネントを有するシステムの診断装置であって、
コンポーネント毎の状態遷移を示す状態遷移モデルから、前記コンポーネント間のメッセージ送受信に関わる記述を抽出し、該記述に基づき前記コンポーネント毎の状態遷移モデルを抽象化した抽象化済状態遷移モデルを生成する状態抽象化手段と、
メッセージを送受信した履歴の有るコンポーネントを検証範囲として抽出する検証範囲抽出手段と、
前記検証範囲抽出手段により抽出された検証範囲に含まれるコンポーネントの抽象化済状態遷移モデルを結合し、システム状態遷移モデルを生成する結合手段と、
前記システム状態遷移モデルから、遷移先状態が存在しない状態をデッドロックとして検出するデッドロック検出手段と、
を有することを特徴とする診断装置。
【請求項２】
前記状態抽象化手段が、前記状態遷移モデルから所定のシステム単位間のメッセージ送受信による相互作用に関わる記述を抽出して、抽象化済状態遷移モデルを生成することを特徴とする請求項１に記載の診断装置。
【請求項３】
前記システム単位が、プロセス、スレッド、タスク、レイヤ、ドメイン、パッケージのいずれかであることを特徴とする請求項２に記載の診断装置。
【請求項４】
前記検証範囲抽出手段が、特定の条件を満たす通信履歴のあるコンポーネントを抽出することを特徴とする請求項１乃至３のいずれか１項に記載の診断装置。
【請求項５】
複数のコンポーネントを有するシステムの診断方法であって、
状態抽象化手段が、コンポーネント毎の状態遷移を示す状態遷移モデルから、前記コンポーネント間のメッセージ送受信に関わる記述を抽出し、該記述に基づき前記コンポーネント毎の状態遷移モデルを抽象化した抽象化済状態遷移モデルを生成する状態抽象化工程と、
検証範囲抽出手段が、メッセージを送受信した履歴の有るコンポーネントを検証範囲として抽出する検証範囲抽出工程と、
結合手段が、前記検証範囲抽出手段により抽出された検証範囲に含まれるコンポーネントの抽象化済状態遷移モデルを結合し、システム状態遷移モデルを生成する結合工程と、
デッドロック検出手段が、前記システム状態遷移モデルから、遷移先状態が存在しない状態をデッドロックとして検出するデッドロック検出工程と、
を有することを特徴とする診断方法。
【請求項６】
複数のコンポーネントを有するシステムを診断するプログラムであって、
コンポーネント毎の状態遷移を示す状態遷移モデルから、前記コンポーネント間のメッセージ送受信に関わる記述を抽出し、該記述に基づき前記コンポーネント毎の状態遷移モデルを抽象化した抽象化済状態遷移モデルを生成する状態抽象化工程と、
メッセージを送受信した履歴の有るコンポーネントを検証範囲として抽出する検証範囲抽出工程と、
前記検証範囲抽出工程で抽出された検証範囲に含まれるコンポーネントの抽象化済状態遷移モデルを結合し、システム状態遷移モデルを生成する結合工程と、
前記システム状態遷移モデルから、遷移先状態が存在しない状態をデッドロックとして検出するデッドロック検出工程と、
をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
大規模ソフトウェアシステムのデッドロックを検出する技術に関わる。
【背景技術】
【０００２】
近年、製品機能の増大に伴いソフトウェア規模が急激に増加しており、ソースコードの総行数が数百万行、数千万行に及ぶソフトウェアも珍しくない。従って、開発現場ではソフトウェアをドメイン、レイヤ、パッケージ、コンポーネント等のシステム単位に分割し、それぞれの開発を分担し、分散並行開発することによって開発効率の向上を図っている。
【０００３】
分散並行開発を行う上では、各コンポーネントの動作仕様を設計図面として形式的に表現し、それを元に設計・実装を進めることが必要である。組み込みソフトと呼ばれるハードウェア組み込み型のソフトウェアの開発においては、特に状態遷移図でコンポーネントの動作仕様を表現することが多い。状態遷移図はソフトウェア設計モデル記法の標準であるＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）仕様にも含まれ、一般に広く流通している。
【０００４】
並行して開発された多数のコンポーネントを結合してシステム全体の構築する際、各コンポーネントの状態遷移記述の間に不整合があると、各コンポーネントが互いに他方のアクションを待機する状態になり、行き詰まりの状況に陥ることがある。このような状況はデッドロックと呼ばれ、それ以上処理が進行しなくなりシステムがフリーズしてしまう事がある。
【０００５】
分散並行開発を行う大規模なソフトウェアシステムでは、メッセージ通信のイベント待ちに起因するデッドロックの割合が高いため、この種のデッドロックを正確に検出する技術が求められている。
【０００６】
また、コンピュータ資源の割り当て時に資源とその消費者、獲得待ち資源の間の有向グラフに閉ループが存在する場合に、デッドロックとして検出する方法が知られている（特許文献１参照）。
【０００７】
また、システム全体の状態遷移を構成して、遷移先のない状態（行き詰まり状態）がないか網羅的にチェックする方法がある。この方法は形式モデル検証と呼ばれ、ＳＰＩＮ、ＳＭＶ等の既存ツールも存在する。（特許文献２参照）
【特許文献１】特登録０３６８１４１５
【特許文献２】特開平０４−２７１４３９
【発明の開示】
【発明が解決しようとする課題】
【０００８】
特許文献１の方法は多くのオペレーションシステムに実装されている一般的な手法であるが、オペレーションシステムの管理下にある資源の競合状態についてのみ検出可能であり、コンポーネント間のメッセージ通信には用いることが出来ない。
【０００９】
一方、特許文献２の方法を大規模なシステムの検証に用いる場合、システム全体を網羅的に検証しようとするので、検証アルゴリズムの計算量が膨大になり現実的な時間で結果が得られないことがある。
【００１０】
以上の問題を鑑みて、本発明は実用可能な計算量でメッセージ通信のイベント待ちに起因するデッドロックを検出するシステム診断方法および装置、プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
以上の課題を解決するための、本発明の請求項１に係る構成は、
複数のコンポーネントを有するシステムの診断装置であって、コンポーネント毎の状態遷移を示す状態遷移モデルから、前記コンポーネント間のメッセージ送受信による相互作用に関わる記述を抽出し、該記述に基づき前記コンポーネント毎の状態遷移モデルを抽象化した抽象化済状態遷移モデルを生成する状態抽象化手段と、前記抽象化済状態遷移モデルを結合し、システム状態遷移モデルを生成する結合手段と、前記システム状態遷移モデルから、遷移先状態が存在しない状態をデッドロックとして検出するデッドロック検出手段と、を有することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、メッセージ通信に関わる記述を加えた状態遷移図を作成し、これに対してデッドロックをチェックする為、実際のシステム稼動時には実行されない可能性の高い状態の組み合わせやメッセージのやり取りに対するチェックを省略できる。従って、メッセージ通信のイベント待ちに起因するデッドロックの検出に要する計算量を削減できる。
【００１３】
さらに本発明によれば、メッセージ通信に関わる記述を加え、メッセージ通信ログを用いて抽象化した遷移図を作成し、これに対してデッドロックをチェックする為、システム稼動時に実行されなかった状態の組み合わせやメッセージのやり取りに対するチェックを省略できる。従って、メッセージ通信のイベント待ちに起因するデッドロックの検出に要する計算量を効率的に削減できる。
【発明を実施するための最良の形態】
【００１４】
以下、添付の図面に沿って本発明の一実施形態を説明する。
【００１５】
＜実施形態１＞
図１は、本発明の一実施形態が動作する装置の構成である。図１において、１００、１１２は各々ノードを表しており、ネットワークを介して接続されている。
【００１６】
ノード１００において、１０１はＣＰＵであり、以下に説明する１０３〜１１１を１０２で示したバスを介してアクセスし制御する。１０３はバス１０２を介してＣＰＵ１０１からアクセス可能な読み出し専用メモリ（ＲＯＭ）であり、１０４は読み書き可能なメモリ（ＲＡＭ）である。
【００１７】
メッセージ通信仲介プログラム（１０４ａ）、状態抽象化プログラム（１０４ｄ）、検証範囲抽出プログラム（１０４ｅ）、結合プログラム（１０４ｆ）、デッドロック検出プログラム（１０４ｇ）は何れもソフトウェアである。通常、これらのソフトウェアは実行時にＲＯＭ１０３からＲＡＭ１０４にロードされるが、ＲＯＭ１０３上に配置したまま実行することも出来る。外部記憶装置１１０から外部記憶装置インターフェース１０９を通じてロードしても良い。また、他にもＲＡＭ１０４上には、ソフトウェアコンポーネント（１０４ｈ、１０４ｉ）、メッセージ通信ログ（１０４ｂ）、状態遷移モデル（１０４ｃ）が格納される。１０４ａ〜１０４ｉの詳細説明は後述（図２）する。
【００１８】
１０５は入力インターフェースであり、１０６で示したキーボード、マウス、タブレット等の入力装置を介してなされる入力を受け取る。１０７は出力インターフェースであり、１０８で示したＣＲＴ，ＬＣＤ等の表示媒体、更にはプリンタ、プロッタ等の出力装置に対し、データの表示や出力を行う。
【００１９】
外部記憶装置インターフェース１０９は外部記憶装置１１０に対するデータの入出力を行う。外部記憶装置１１０としてはハードディスク、フレキシブルディスク、光ディスク、光磁気ディスク、ＭＤ、ＤＶＤ、不揮発性のメモリカードなどを用いる事ができる。また、１１１はネットワークインターフェースであり、既存のネットワークプロトコルを用いて外部機器との通信を行う。
【００２０】
ノード１１２において、１１３はＣＰＵでありバス１１４を介して以下に説明する１１５〜１１７にアクセスし制御する。１１５は読み出し専用メモリ（ＲＯＭ）であり、１１６は読み書き可能なメモリ（ＲＡＭ）である。ＲＡＭ１１６上にはソフトウェアであるメッセージ通信仲介プログラム（１１６ａ）、ソフトウェアコンポーネント（１１６ｂ、１１６ｃ）が格納され、実行時にＲＯＭ１１５からＲＡＭ１１６にロードされる。ただし、ＲＯＭ１１５上に配置したまま実行することも出来る。各ノードはマルチプロセッサ構成でもかまわない。ここで、ソフトウェアコンポーネント（１１６ｂ、１１６ｃ）とは、システムを構成するソフトウェアの部品の１つである。
【００２１】
図２は、本実施形態のソフトウェア構成図である。図２において、ノード１は図１中の１００に、ノード２は１１２に対応している。ノード１上に配置されるコンポーネント＿１（２０１）とコンポーネント＿２（２０３）、ノード２上に配置されるコンポーネント＿Ｎ（２０５）は、それぞれメッセージ通信用のポート１（２０２）、ポート２（２０４）、ポートＮ（２０６）を有している。そして各コンポーネントはメッセージ通信仲介プログラム（２０７、２０８）を介してメッセージの送受信を行う。本実施例では通信モデルとして「ＣＯＲＢＡ」（登録商標）を用いて説明する。メッセージ通信仲介プログラムは、ノード内あるいは異なるノード間に跨るメッセージ通信を仲介し、メッセージ通信履歴をメッセージ通信ログ（２０９）として蓄積する。状態遷移モデル（２１０）はコンポーネント設計図面の一部であり、コンポーネント開発時に作成され、各コンポーネントのソースに対応する情報が記述されている。状態抽象化プログラム（２１１）は状態遷移モデル（２１０）の抽象化を行い、抽象化済状態遷移モデル（２１３）を作成する。検証範囲抽出プログラム（２１２）はメッセージ通信ログ（２０９）と状態遷移モデル（２１０）を用いて検証範囲（２１４）を抽出する。結合プログラム（２１５）は抽象化済状態遷移モデル（２１３）と検証範囲（２１４）からシステム状態遷移モデル（２１６）を作成する。デッドロック検出プログラム（２１７）はシステム状態遷移モデル（２１６）に対してデッドロック検出を行い、検出結果（２１８）を出力する。以下に各データ（２０９、２１０、２１３、２１４、２１６、２１８）の内容と各プログラム（２１１、２１２、２１５、２１７）の動作の詳細を記述する。
【００２２】
状態遷移モデル（２１０）は図７に示すパッケージ図、図４に示すコンポーネントクラス図、図５に示す状態遷移図、図６に示すアクション記述コードから構成される。パッケージ図はソフトウェアシステムのパッケージ構成を示している。通常大規模なシステムではパッケージが更に階層化され入れ子になっており、コンポーネントは最下層のパッケージに含まれる。コンポーネントの設計モデルは、コンポーネントクラス図、状態遷移図、アクション記述コードで表現される。コンポーネントクラス図はコンポーネント毎の変数／操作と、コンポーネント間の静的関連が記述される。図４中の４０１、４０５、４０６はそれぞれコンポーネント＿１、コンポーネント＿２、コンポーネント＿Ｎを表しており、領域４０２、４０３にはコンポーネント＿１の持つ変数と操作（イベント）の型が定義されている。なお変数やイベントには可視性も設定することが出来る。図４の例では変数ＸＸ＿ＣｏｕｎｔとＹＹ＿Ｎｕｍｂｅｒは自コンポーネント内のみから参照可能なプライベート変数である。また、イベントＩｎｉｔ、Ｓｔａｒｔ、Ａｂｏｒｔ、Ｒｅｓｕｍｅ、Ｔｅｒｍｉｎａｔｅ、Ｅｎｄは他コンポーネントから送信可能なパブリックイベント、イベントＩｎｉｔＯＫは自コンポーネント内でのみ送受信可能なプライベートイベントである。４０４、４０７はコンポーネント＿１／コンポーネント＿２とコンポーネント＿２／コンポーネント＿Ｎの間の関連を表しており、それぞれ１：１の多重度を持つ。また状態遷移図は個々のコンポーネントの状態モデルを記述する。図５にコンポーネント＿１の状態遷移を示す。５０２、５０４、５０６、５０８、５１２はそれぞれ名前つきの状態を表し、５０１は初期状態、５０２は終了状態である。接続線５０３、５０５、５０７、５０９、５１０、５１１、は状態間の遷移を表しており、各接続線に記載されているイベントを受信すると矢印の方向に遷移することを示している。遷移５１１の括弧内の式は、遷移するための条件を表している。アクション記述コードは状態遷移時に実行される遷移アクションを記述したもので、図６は、図５中のＳｔａｒｔｅｄ状態に関するアクションを表している。６０１はＳｔａｒｔｅｄ状態への入場時に実行される入場アクション、６０２は退場時に実行される退場アクション、６０３は状態における継続的なアクションである。６０４、６０６は変数の参照による条件分岐と変数への代入であり、６０５、６０７はコンポーネント＿２へのイベント送信を表す。これらのパッケージ図、コンポーネントクラス図、状態遷移図は「ＭＤＡ（Ｍｏｄｅｌ  Ｄｒｉｖｅｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ）」（登録商標）ツールを用いてＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）で記述される。また、共通形式であるＸＭＩ（ＸＭＬ  Ｍｅｔａｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ）で保存されるため、各種市販ツールによって作成された図面の内容を参照、解析することができる。
【００２３】
メッセージ通信ログ（２０９）の例を図３に示す。タイムスタンプ（３０１）、イベント名称（３０２）、送信元コンポーネント（３０３）、送信先コンポーネント（３０４）、送信結果（３０５）、パラメータ（３０６、３０７、３０８）の情報を含む。メッセージ通信ログ（２０９）のフォーマットはＣＳＶ／ＸＭＬ／その他のテキスト形式でも良いし、容量削減のためにバイナリ形式で圧縮して保持しても構わない。
【００２４】
次に図１３を用いて状態抽象化プログラム（２１１）の動作フローを説明する。状態抽象化プログラム（２１１）は図５の状態遷移図と図６のアクション記述コードを入力とし、これらを抽象化した抽象化済態遷移モデル（２１３）を出力する。ステップＳ１３０１において、状態遷移図中からメッセージ受信記述のみ抜き出す。図５の状態遷移図の場合、遷移５１１の遷移条件においてコンポーネントの変数を参照しているが、これを捨象してメッセージ受信記述のみによる状態遷移（図８）を作成する。ステップＳ１３０２において、アクション記述からメッセージ送信のみ抜き出す。図６のアクション記述の場合、６０５、６０７のみ抽出してメッセージ送信記述のみによるアクション記述（図９）を作成する。ステップＳ１３０３において、アクション記述のＥｎｔｒｙアクション／Ｄｏアクション中のメッセージ送信箇所を状態遷移中の該状態に追加する。図９の場合、メッセージ送信記述９０３を図８のＳｔａｒｔｅｄ状態に追加する（図１０の１０１５）。ステップＳ１３０４において、アクション記述のＥｘｉｔアクション中のメッセージ送信箇所を状態遷移後の状態に追加する。全てのＥｎｔｒｙアクション／Ｄｏアクション／Ｅｘｉｔアクション記述について処理ステップＳ１３０３、ステップＳ１３０４を行って図１０を得る。ステップＳ１３０５において、１つの状態で自己遷移イベントの送受信のみ行っている場合はコンポーネント間の相互作用に関係がないため、その状態を省略する。図１０の場合、Ｉｎｉｔｉａｌｉｚｉｎｇ状態１００４は自己遷移イベントＩｎｉｔＯＫの送受信のみ行っているので省略し、図１２を得る。ここで自己遷移イベントであるかどうかは、コンポーネントクラス図（図４）のイベント定義を参照することによって判断することが出来る。また自己遷移イベントの送信箇所は、他のパブリックイベント同様にアクション記述を参照することによって特定できる（図１１）。以上の処理によって生成される図１２の示す状態遷移図が抽象化済状態遷移モデル（２１３）に相当する。
【００２５】
次に図１４を用いて検証範囲抽出プログラム（２１２）の動作フローを説明する。検証範囲抽出プログラム（２１２）はメッセージ通信ログ（２０９）と状態遷移モデル（２１０）を入力とし、デッドロックの検証範囲（２１４）を出力する。ステップＳ１４０１において、状態遷移モデル中の各コンポーネントを頂点とするグラフを作成する。ステップＳ１４０３において送信元コンポーネントを抽出し、ステップＳ１４０４において送信先コンポーネントを抽出する。図３のメッセージ通信ログの場合、送信元コンポーネントは３０３欄、送信先コンポーネントは３０４欄より抽出する。ステップＳ１４０５において、ステップＳ１４０１で作成したグラフをチェックし、送信元コンポーネントと送信先コンポーネントの間に無向辺がない場合にのみ、ステップＳ１４０６において送信元コンポーネントと送信先コンポーネントの間に無向辺を置く。ステップＳ１４０２〜１４０７において全てのログについて処理を行うが、その際に送信結果３０５がＳＵＣＣＥＳＳの通信ログだけに限定しても良い。図３に示す通信ログと図４に示す状態遷移モデルから作成したグラフを、図１５に示す。無向辺１５０１は通信ログ３０９に、無向辺１５０２は通信ログ３１０に対応して作成されたものである。検証範囲抽出プログラム（２１２）はステップＳ１４０８において、グラフ中の全ての連結グラフ成分を出力し、各連結グラフ成分が検証範囲となる。図１５の例では連結グラフ成分１と連結グラフ成分２が出力される。
【００２６】
次に図１６を用いて結合プログラム（２１５）の動作フローを説明する。結合プログラム（２１５）は、抽象化済状態遷移モデル（２１３）と、検証範囲抽出プログラム（２１２）によって抽出された検証範囲（２１４）の１つの連結グラフ成分から、システム状態遷移モデル（２１６）を出力する。ステップＳ１６０１で検証範囲（２１４）に含まれる各コンポーネントの初期状態の直積を作成する。ステップＳ１６０２は直積状態から次の直積状態への遷移を構成する次状態構成処理であり、サブルーチンステップＳ１６０３で定義される。ステップＳ１６０４において次状態を既に作成している（Ｙｅｓ）場合はサブルーチンステップＳ１６０３は終了する。一方、次状態を未作成（Ｎｏ）の場合にはステップＳ１６０５において次状態を作成する。次状態の作成はサブルーチンステップＳ１６１０で定義される。直積状態の要素状態Ｓｉと、Ｓｉからの遷移で受信しているイベントＥｊについて、ステップＳ１６１３でＥｊを送信する要素状態Ｓｎが存在するかチェックを行い、存在する場合にはステップＳ１６１４でＳｉで受信後に別の状態Ｓ’ｉに遷移するかチェックを行う。更にステップＳ１６１５、ステップＳ１６１９においてＳｎで送信後に別の状態Ｓ’ｎに遷移するかチェックを行う。それぞれのチェック結果の組み合わせから、ステップＳ１６１６、１６１７、１６１８、１６２０において現直積状態から次直積状態への遷移を設定する。以上の処理を直積状態の各要素状態Ｓｉと各イベントＥｊについて行う。次状態作成（ステップＳ１６０５）が終ると、次状態構成処理はステップＳ１６０６において各次状態について再帰的に次状態構成処理を行う。以上に示した結合プログラム（２１５）の動作フローに従って、システム状態遷移モデル（２１６）が作成される。図１２に示すコンポーネント＿１の抽象化済状態遷移と、図１７に示すコンポーネント＿２の抽象化済状態遷移を結合すると、図１８に示すシステム状態遷移モデルが出力される。
【００２７】
次に図１９を用いてデッドロック検出プログラム（２１７）の動作フローを説明する。デッドロック検出プログラム（２１７）の入力は、結合プログラム（２１５）によって作成されたシステム状態遷移モデル（２１６）であり、デッドロックの有無を検出結果（２１８）として出力する。ステップＳ１９０１において、結合済状態遷移の初期状態からスタートし、ステップＳ１９０２において状態のデッドロックチェックを行う。このチェックはサブルーチン１９０３によって行われる。該状態がデッドロックチェック済でない場合に、ステップＳ１９０４において該状態からの遷移があるかチェックを行う。もし遷移先状態がない場合には該状態がデッドロック状態と判定し、ステップＳ１９１０において結果出力を行う。一方遷移がある場合には、各遷移先の次状態について再帰的に状態のデッドロックチェックを行う。このとき無限ループを避けるために、遷移先が自状態である場合には状態のデッドロックチェックを行わずにスキップする。次状態の中にデッドロック状態が存在することがわかった時点でデッドロック状態有りと判定し、ステップＳ１９１０において結果出力を行う。なおステップＳ１９１０においてデッドロックの有無だけではなく、デッドロックがある場合には直積状態の各要素状態等のより詳細な情報を出力しても良い。図１８のシステム状態遷移モデルを入力としてデッドロック検出プログラム（２１７）を起動すると、直積状態１８０９がデッドロックであることを検出する。
【００２８】
以上に示した構成により、従来の技術における課題を解決することが出来る。
【００２９】
なお本実施形態では、通信モデルとしてＣＯＲＢＡを例に挙げて説明したが、ＪＩＮＩ（登録商標）など他の通信モデルについても、同様に実施できる。
【００３０】
また本実施形態では２つのノード間での通信について説明したが、単一のノード内、あるいは３つ以上のノード間でのメッセージ通信についても同様に実施可能である。
【００３１】
また本実施形態でノード１に配置したソフトウェア及びメッセージ通信ログ２０９、状態遷移モデル２１０、結合済状態遷移２１６は、専用のノードを別途用意して処理を行っても良い。またこれらを全て遠隔サーバに配置して、オフラインで処理を行っても良い。
【００３２】
また本実施形態では、メッセージ通信ログ２０９がメッセージ通信仲介プログラム２０８によって一元的に蓄積される場合を説明したが、メッセージ通信ログ２０９を複数ノードに分散して蓄積し、必要に応じてそれら複数のログをマージしても良い。
【００３３】
また本実施形態では、各コンポーネント間のメッセージ通信が同期チャネルを用いて行われる場合について、結合プログラム２１３の動作フローを記述したが、バッファを持つ非同期チャネルを用いた場合にも同様に実施可能である。
【００３４】
また本実施形態では、各コンポーネントの初期状態を出発点として結合プログラム２１３の動作フローを記述したが、デッドロック検証を開始する時点の各コンポーネントの状態を出発点としても良い。各コンポーネントの状態は、それらを把握しているメッセージ通信仲介プログラム２０７、２０８に問い合わせることによって知ることが出来る。また状態遷移モデル２１０とメッセージ通信ログ２０９を用いて別途算出することも可能である。
【００３５】
また本実施形態では、メッセージ通信ログ２０９の全体から検証範囲（２１４）を抽出するとしたが、メッセージ通信ログ２０９中の一定期間内のログや機能シーケンスに関わるログなど、特定の条件を満たすログについて検証範囲（２１４）を抽出しても良い。
【００３６】
また本実施形態では、結合プログラム（２１５）とデッドロック検出プログラム（２１７）が異なる別個のプログラムであるとして説明を行ったが、これらは状態遷移の結合とデッドロックの検出の両方を行う一つのプログラムであっても良い。
【００３７】
また本実施形態では、状態遷移モデル（２１０）、抽象化済状態遷移モデル（２１３）、システム状態遷移モデル（２１６）はＵＭＬで、検証範囲（２１４）は無向グラフで表現されるとして説明を行ったが、その他の表現形式であっても良い。
【００３８】
また本実施形態では、結合プログラム（２１５）とデッドロック検出プログラム（２１７）は深さ優先探索アルゴリズムに基づき、デッドロックを検出するとして説明を行ったが、探索の効率化、最適化を行う他のアルゴリズムを併用しても良い。
【００３９】
＜実施形態２＞
実施形態１では、メッセージ通信ログ（２０９）を用いて状態遷移モデル（２１０）中の全てのメッセージ送受信についてデッドロック検証を行ったが、本実施形態ではパッケージ間のメッセージ送受信に限定してデッドロック検証を行う。
【００４０】
実際のソフト開発プロセスでは、パッケージ単位に異なる開発者／開発チームが担当することが多い。このためパッケージ内部の状態不整合に起因するデッドロックはパッケージ単位の単体テストフェーズで除去できるが、パッケージ間の状態不整合に起因するデッドロックは結合フェーズで発生することが多く、大きな手戻りにつながる。従ってパッケージ間のデッドロック検出を可能にすることは、実際のソフトウェア開発において非常に有用である。
【００４１】
本実施形態は、実施形態１と同様の構成によって実現できるが、状態抽象化プログラム（２１１）、検証範囲抽出プログラム（２１２）は以下のように動作する。
【００４２】
図２０に状態抽象化プログラム（２１１）の動作フローを示す。ステップＳ２００１〜２００５は実施形態１のステップＳ１３０１〜１３０５（図１３）と同様である。ステップＳ２００６において同一パッケージ内のイベント送受信を無条件遷移に置き換え、ステップＳ２００７において無条件遷移のみを含む状態を削除して、隣接状態間の遷移に置き換える。ステップＳ２００７における処理は、図２２に示す状態遷移図を図２３に示す状態遷移図に変換する。
【００４３】
図２１に検証範囲抽出プログラム（２１２）の動作フローを示す。実施形態１の動作フロー（図１４）に加えて、ステップＳ２１０５において送信元コンポーネントと送信先コンポーネントが同一のパッケージに属する場合を除外している。この処理によって、ステップＳ２１０６とステップＳ２１０７を省略し、処理負荷の軽減を図っている。
【００４４】
なお本実施形態では、パッケージ間でのメッセージ送受信のみに限定して各々処理を行うとして説明を行ったが、プロセス、レイヤ、ドメイン、スレッド、タスク等、所定のシステム単位間のメッセージ送受信についても実施可能である。また、予めデッドロックの発生箇所に予測が付く場合は、このシステム単位を利用者が指定するようにすると、更に検証範囲を狭め検出をより短時間に出来る。
【００４５】
また、前記実施形態のシステム診断プログラムは前記ソフトウェアシステムの一部であって、前記ソフトウェアシステムの稼動中に実施される形態であってもよいし、前記ソフトウェアシステムから独立して存在する形態であってもよい。
【００４６】
また、システムあるいは装置のＣＰＵ（またはＭＰＵ）が、前述した実施形態のフローに対応するコンピュータ読み取り可能なプログラムコードを記憶した記憶媒体からプログラムコードを読み出し実行する場合も考えられる。
【００４７】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００４８】
さらに、コンピュータに接続された機能拡張ユニットが、記憶媒体からプログラムコードを読み出し、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが前述の実施形態のフローに対応する処理を行う事もできる。
【００４９】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【図面の簡単な説明】
【００５０】
【図１】本実施形態に係る診断装置の構成ブロック図である。
【図２】本実施形態に係る診断装置のソフトウェア構成図である。
【図３】本実施形態におけるメッセージ通信ログの例である。
【図４】本実施形態におけるコンポーネントクラス図の例である。
【図５】本実施形態における状態遷移図の例である。
【図６】本実施形態におけるアクション記述の例である。
【図７】本実施形態におけるパッケージ図の例である。
【図８】本実施形態における状態遷移図の例である。
【図９】本実施形態におけるアクション記述の例である。
【図１０】本実施形態における状態遷移図の例である。
【図１１】本実施形態におけるアクション記述の例である。
【図１２】本実施形態における状態遷移図の例である。
【図１３】本実施形態における状態抽象化プログラムの動作フローチャートである。
【図１４】本実施形態における検証範囲抽出プログラムの動作フローチャートである。
【図１５】本実施形態における検証範囲の例である。
【図１６】本実施形態における結合プログラムの動作フローチャートである。
【図１７】本実施形態における状態遷移図の例である。
【図１８】本実施形態における状態遷移図の例である。
【図１９】本実施形態におけるデッドロック検出プログラムの動作フローチャートである。
【図２０】本実施形態における状態抽象化プログラムの動作フローチャートである。
【図２１】本実施形態における検証範囲抽出プログラムの動作フローチャートである。
【図２２】本実施形態における状態遷移図の例である。
【図２３】本実施形態における状態遷移図の例である。
【符号の説明】
【００５１】
１００  ノード１
１０１  ＣＰＵ
１０２  バス
１０３  ＲＯＭ
１０４  ＲＡＭ
１０４ａ  メッセージ通信仲介プログラム
１０４ｂ  メッセージ通信ログ
１０４ｃ  状態遷移モデル
１０４ｄ  状態抽象化プログラム
１０４ｅ  検証範囲抽出プログラム
１０４ｆ  結合プログラム
１０４ｇ  デッドロック検出プログラム
１０４ｈ  コンポーネント＿１
１０４ｉ  コンポーネント＿２
１０５  入力インターフェース
１０６  キーボード、ボタン、マウス、ダイアル
１０７  出力インターフェース
１０８ａ  ＣＲＴ、ＬＣＤ
１０８ｂ  プリンタ、プロッタ
１０９  外部記憶装置インターフェース
１１０  外部記憶装置
１１１  ネットワークインターフェース
１１２  ノード２
１１３  ＣＰＵ
１１４  バス
１１５  ＲＯＭ
１１６  ＲＡＭ
１１６ａ  メッセージ通信仲介プログラム
１１６ｂ  コンポーネント＿Ｍ
１１６ｃ  コンポーネント＿Ｎ
１１７  ネットワークインターフェース
【図１】
0004939448.tif 000002
【図２】
0004939448.tif 000003
【図３】
0004939448.tif 000004
【図４】
0004939448.tif 000005
【図５】
0004939448.tif 000006
【図６】
0004939448.tif 000007
【図７】
0004939448.tif 000008
【図８】
0004939448.tif 000009
【図９】
0004939448.tif 000010
【図１０】
0004939448.tif 000011
【図１１】
0004939448.tif 000012
【図１２】
0004939448.tif 000013
【図１３】
0004939448.tif 000014
【図１４】
0004939448.tif 000015
【図１５】
0004939448.tif 000016
【図１６】
0004939448.tif 000017
【図１７】
0004939448.tif 000018
【図１８】
0004939448.tif 000019
【図１９】
0004939448.tif 000020
【図２０】
0004939448.tif 000021
【図２１】
0004939448.tif 000022
【図２２】
0004939448.tif 000023
【図２３】
0004939448.tif 000024