(57)【要約】【課題】  デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出する。【解決手段】  コンピュータに、複数のデータベースのうちのいずれかへのアクセスを伴うアクセスステップを含む複数の処理ステップにより構成される業務ロジック設計情報を読み込ませる第１手順、前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される処理ルートを生成する第２手順、前記処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得する第３手順、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する第４手順、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、予め定められたアクセス順序から逸脱した旨を報知する第５手順、を実行させるためのデッドロック事前検出プログラム。【選択図】図１
2005122560.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
複数のデータベースのうちのいずれかへのアクセスを伴うアクセスステップを含む複数の処理ステップにより構成される業務ロジック設計情報を読み込ませる第１手順、
前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される処理ルートを生成する第２手順、
前記処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得する第３手順、
前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する第４手順、
前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、予め定められたアクセス順序から逸脱した旨を報知する第５手順、
を実行させるためのデッドロック事前検出プログラム。
【請求項２】
前記業務ロジック設計情報は、前記アクセスステップ及び分岐条件ステップを含む複数の処理ステップにより構成され、
前記第２手順は、前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される少なくとも２つの処理ルートを生成し、
前記第３手順は、各処理ルートごとに、その処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得し、
前記第４手順は、各処理ルートごとに、前記第１及び第２アクセスステップによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する、
請求項１に記載のデッドロック事前検出プログラム。
【請求項３】
前記複数のデータベース相互間の対応関係を表す対応関係データを読み込ませる第６手順、
前記対応関係データに基づいて、前記予め定められたアクセス順序を生成する第７手順、
をさらに備える、
請求項１に記載のデッドロック事前検出プログラム。
【請求項４】
前記第３手順は、前記処理ルートから、第１アクセスステップ、及び該第１アクセスステップの次の第２アクセスステップを取得し、
前記第４手順は、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定し、
前記第５手順は、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、前記第１アクセスステップによるデータベースへのアクセスが、前記第２アクセスステップによるデータベースへのアクセスよりも先に行われている旨を報知する、
請求項１に記載のデッドロック事前検出プログラム。
【請求項５】
多重アクセス記述と前記処理ルートを読み込ませる第８手順、
前記多重アクセス記述と処理ルートに基づいて、前記複数の処理ステップにより構成される業務ロジックを同時実行する場合に、デッドロックが発生する可能性の情報を生成する第９手順、
をさらに備える、
請求項１に記載のデッドロック事前検出プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出するための技術に関する。
【背景技術】
【０００２】
従来、デッドロック検出方法として、デッドロック検出の対象となる手続き（処理ステップ等）を実行、又はシミュレートして得られたデータアクセスシーケンスを分析することでデッドロックの検出を行う技術が提案されている。
【０００３】
この従来のデッドロック検出方法の例について図１７に示す。同図は、実行中のアプリ
ケーションがデータベースに対してアクセスした履歴（図中ＳＱＬ履歴）を履歴抽出器（図中ＳＱＬ履歴抽出器）により記録し、このアクセス履歴に基づいて、デッドロック検出器が所定処理を実行することにより、デッドロック検出結果を出力することを示している（例えば、特許文献１、及び特許文献２等参照）。
【特許文献１】特開２０００−２２２２２８号公報
【特許文献２】特開平１０−４９３８９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のデッドロック検出方法によれば、デッドロックを検出するには、デッドロック検出対象のプログラムを実際に実行する必要がある。このため、以下の問題点がある。
【０００５】
（１）実際に動作させた部分についてしかデッドロックを検出できない。換言すれば、全てのケース（全ての処理ルート）についてデッドロックを検出したこと(網羅性)の証明が難しい。特に多重アクセス時のプログラム検証を行う場合、全ての可能性をチェックするのは事実上不可能に近い。
【０００６】
（２）既にプログラムができてからチェックを行うため、デッドロック解消のためにプログラムを修正するためのコストが大きくなる（設計段階での修正の10倍〜100倍程度）
。
【０００７】
（３）各業務ロジックを分担して開発する場合、担当者によってデータベースアクセス順序の実装にばらつきがあるためデッドロックを起こし得るが、プログラムができてからチェックする方法ではこの問題を解消できない。
【０００８】
本発明の第１の課題は、デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出することにある。また、本発明の第２の課題は、そのように検出されたデッドロック可能性回避のための方策等について利用者に対して報知することにより、デッドロック可能性回避のための方策等を採ることできるようにすることにある。
【課題を解決するための手段】
【０００９】
本発明は、上記の課題を解決するために次のように構成した。コンピュータに、複数のデータベースのうちのいずれかへのアクセスを伴うアクセスステップを含む複数の処理ステップにより構成される業務ロジック設計情報を読み込ませる第１手順、前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される処理ルート
を生成する第２手順、前記処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得する第３手順、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する第４手順、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、予め定められたアクセス順序から逸脱した旨を報知する第５手順、を実行させるためのデッドロック事前検出プログラム。
【００１０】
本発明によれば、業務システムを構成するプログラムを設計する段階（即ち業務ロジック設計書作成段階）で、デッドロックの可能性を検出することが可能となる。即ち、デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出することが可能となる。
【００１１】
このように、事前にデッドロックの可能性を検出することが可能となるため、デッドロック解消のためにプログラムを修正するためのコストが大きくなることもない。また、業務ロジックを分担して開発する場合、担当者によってデータベースアクセス順序の実装にばらつきが生ずることによるデッドロックの可能性を低減できる。
【００１２】
また、上記デッドロック事前検出プログラムにおいては、例えば、前記業務ロジック設計情報は、前記アクセスステップ及び分岐条件ステップを含む複数の処理ステップにより構成され、前記第２手順は、前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される少なくとも２つの処理ルートを生成し、前記第３手順は、各処理ルートごとに、その処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得し、前記第４手順は、各処理ルートごとに、前記第１及び第２アクセスステップによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する。
【００１３】
このようにすれば、分岐条件ステップの各分岐先を経由することで複数の処理ルートが生成されたとしても、これら全処理ルートについて網羅的にデッドロックの可能性を検出することが可能となる。
【００１４】
また、上記デッドロック事前検出プログラムにおいては、例えば、前記複数のデータベース相互間の対応関係を表す対応関係データを読み込ませる第６手順、前記対応関係データに基づいて、前記予め定められたアクセス順序を生成する第７手順、をさらに備える。
これは、予め定められたアクセス順序をどのようにして得るかについての一例を示したものである。利用者等により入力（設定）されたものアクセス順序を、予め定められたアクセス順序としてもよい。
【００１５】
このようにすれば、予め定められたアクセス順序を自動的に生成することが可能となる。
また、上記デッドロック事前検出プログラムにおいては、例えば、前記第３手順は、前記処理ルートから、第１アクセスステップ、及び該第１アクセスステップの次の第２アクセスステップを取得し、第４手順は、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定し、前記第５手順は、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、前記第１アクセスステップによるデータベースへのアクセスが、前記第２アクセスステップによるデータベースへのアクセスよりも先に行われている旨を報知する。
【００１６】
このようにすれば、記第１アクセスステップによるデータベースへのアクセスが前記第２アクセスステップによるデータベースへのアクセスよりも先に行われている旨、即ち、
デッドロック可能性回避のための方策等について、利用者に対して報知されることになる。
【００１７】
従って、この報知を受けた利用者は、そのデッドロック可能性回避のための方策等を採ることが可能となる。また、業務システムを構成する各業務ロジック、たとえば見積依頼伝票や購買依頼伝票の発行、承認といった業務ロジックにおける標準的なデータアクセス順序を決め、各業務ロジックにおいてデータアクセス順序を統一することも可能となる。
【００１８】
また、上記デッドロック事前検出プログラムにおいては、例えば、多重アクセス記述と前記処理ルートを読み込ませる第８手順、前記多重アクセス記述と処理ルートに基づいて、前記複数の処理ステップにより構成される業務ロジックを同時実行する場合に、デッドロックが発生する可能性の情報を生成する第９手順、をさらに備える。
【００１９】
このようにすれば、多重アクセス時におけるデッドロックの可能性を検出し、デッドロック回避の対策をとることができる。
また、本発明は、上記デッドロック事前検出プログラムを記録したコンピュータ読み取り可能な記録媒体として特定することもできる。
【発明の効果】
【００２０】
デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出することが可能となる。また、そのように検出されたデッドロック可能性回避のための方策等について利用者に対して報知することにより、デッドロック可能性回避のための方策等を採ることが可能となる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の一実施形態であるプログラムが適用されるデッドロック防止システムについて図面を参照しながら説明する。
（デッドロック事前検出システムの概略システム構成）
図１は、本実施形態のデッドロック事前検出システムの概略システム構成について説明するための図である。図１に示すように、本実施形態のデッドロック事前検出システムは、処理シーケンス生成装置Ｍ１、標準アクセスシーケンス生成装置Ｍ２、デッドロック事前検出装置Ｍ３、多重アクセス時デッドロック事前検出装置Ｍ４、及びこれらの各装置Ｍ１〜Ｍ４に読み込まれる各種データ（業務ロジック設計情報Ｄ１１、データ仕様データ相関Ｄ２１、及び多重アクセス操作系列記述Ｄ４等）が格納されたハードディスク装置等の記憶装置を備えている。これら各装置Ｍ１〜Ｍ４は、例えば、パーソナルコンピュータ等の既存の情報処理端末が所定のプログラムを読み込み、これを実行することにより実現される。
（処理シーケンス生成装置）
処理シーケンス生成装置Ｍ１は、記憶装置から業務ロジック設計情報Ｄ１１を読み込み、その業務ロジック設計情報Ｄ１に基づいて、後述の処理（図３及び図４参照）を実行する。これにより、処理シーケンス生成装置Ｍ１は、各ルートの処理シーケンス（処理ルート）を生成する。
（業務ロジック設計情報）
業務ロジック設計情報Ｄ１１は、複数の処理ステップにより構成される。これら複数の処理ステップ全体により特定業務のロジック（例えば購買依頼伝票の一覧を取得するための業務ロジック）が構成される。処理ステップとしては、複数のデータベース（又は、テーブルともいう）のうちのいずれかへのアクセスを伴うアクセスステップ、分岐条件ステップ、開始ステップ、及び終了ステップ等がある。
【００２２】
業務ロジック設計情報Ｄ１１は、各種の方法で作成することが可能である。本実施形態では、複数の処理ステップを、情報処理端末が処理可能なスクリプト言語等の簡易言語で記述する。なお、スクリプト言語で記述された業務ロジック設計情報Ｄ１１は、実行形式のプログラムにコード化することで実行可能となる。
【００２３】
次に、業務ロジック設計情報Ｄ１１の具体例として、購買依頼伝票の一覧を取得するための業務ロジックを説明する。図２は、購買依頼伝票の一覧を取得するための業務ロジックについて説明するための図である。
【００２４】
この業務ロジック設計情報Ｄ１１は、開始ステップＳ１、データベースへのアクセスステップＳ２、Ｓ４、Ｓ５、Ｓ７、フラグ設定ステップＳ３、分岐条件ステップＳ６、及び終了ステップＳ８等の複数の処理ステップＳ１〜Ｓ８により構成される。
【００２５】
次に、各ステップの処理内容の詳細、及び各ステップ（例えば動作や動作対象等により表される）をスクリプト言語で記述した例について説明する。
開始ステップＳ１では、処理内容が「購買伝票の検索開始」、記述例が「start」とな
る。アクセスステップＳ２では、処理内容が「承認フロー検索（業務ロジック実行者が所属する組織における承認フロー情報を、承認フローデータベースから検索(データベース
に対しては参照系のアクセス)）」、記述例が「read承認フローデータベース」となる。
この記述例は、承認フローデータベースに対するアクセスが発生することを表している。
【００２６】
フラグ設定ステップＳ３では、処理内容が「承認フローがＳ２の検索で見つかった場合、承認フローフラグをONに設定」、記述例が「set apr＿flow-flag」となる。この記述例は、apr＿flow-flagがセットされることを表している。
【００２７】
アクセスステップＳ４では、処理内容が「購買依頼伝票の検索(データベースに対して
は参照系のアクセス)」、記述例が「read購買伝票本体データベース」となる。この記述
例は、購買伝票本体データベースに対するアクセスが発生することを表している。
【００２８】
アクセスステップＳ５では、処理内容が「検索の結果見つかった各伝票の品目情報検索(データベースに対しては参照系の検索)」、記述例が「read品目情報データベース」となる。この記述例は、品目情報データベースに対するアクセスが発生することを表している。
【００２９】
分岐条件ステップＳ６では、処理内容が「承認フローフラグを参照し、フラグがONか否かの判定」、記述例が「check apr＿flow-flag if true S7 if false S8」となる。この
記述例は、check apr＿flow-flagが真であればＳ７を実行し、一方、check apr＿flow-flagが偽であればＳ８を実行することを表している。
【００３０】
アクセスステップＳ７では、処理内容が「承認フローフラグ（check apr＿flow-flag）がONの場合は、Ｓ４で検索された伝票に対する承認履歴情報データベースを検索（データベースに対しては参照系のアクセス）」、記述例が「read承認履歴情報データベース」となる。この記述例は、承認履歴情報データベースに対するアクセスが発生することを示している。
【００３１】
最終ステップＳ８では、処理内容が「検索結果(購買依頼伝票、品目情報、承認フロー
フラグがONの場合は承認履歴情報も含む)を返却」、記述例が「end」となる。
（処理ルート情報を生成する処理）
次に、処理シーケンス生成装置Ｍ１が、業務ロジック設計情報Ｄ１１に基づいて、処理ルート情報（各ルートの処理シーケンス）を生成する処理について説明する。図３は、処
理ルート情報を生成する処理について説明するためのフローチャートである。処理手順は以下のとおりである。
【００３２】
処理シーケンス生成装置Ｍ１は、業務ロジック設計情報Ｄ１１を構成する処理ステップＳ１〜Ｓ８に対して以下の処理を実行する。
処理シーケンス生成装置Ｍ１は、業務ロジック設計情報Ｄ１１から、一つずつ処理ステップを取り出し（Ｓ１００：Ｙｅｓ、Ｓ１０１）、その取り出した処理ステップが条件分岐ステップか否かを判定する（Ｓ１０２）。そして、処理シーケンス生成装置Ｍ１は、その取り出した処理ステップが条件分岐ステップでなければ（Ｓ１０２：Ｎｏ）、その取り出した処理ステップを現在の処理ルート情報Ｒ１に格納（追加）する（Ｓ１０３）。
【００３３】
図２を参照すると、業務ロジックの最初の処理ステップＳ１〜Ｓ５までは、条件分岐ステップではない。このため、処理シーケンス生成装置Ｍ１は、最初の処理ステップＳ１〜Ｓ５を、現在の処理ルート情報Ｒ１に格納（追加）する（Ｓ１００〜Ｓ１０３）。
【００３４】
次に、処理シーケンス生成装置Ｍ１は、業務ロジック設計情報Ｄ１１から処理ステップＳ６を取り出す（Ｓ１００：Ｙｅｓ、Ｓ１０１）。この処理ステップＳ６は条件分岐ステップ(if文)であるので（Ｓ１０２：Ｙｅｓ）、処理シーケンス生成装置Ｍ１は、現在の処理ルート情報R1のコピーR2（処理ステップＳ１〜Ｓ５が格納されている）を生成する（Ｓ１０４）。
【００３５】
そして、処理シーケンス生成装置Ｍ１は、処理ルート情報R1に対しては条件が成立する場合（図２ではＳ６：Ｙｅｓ）の処理ステップ（図２ではＳ７）を格納（追加）する処理を実行する（Ｓ１０５）。これにより、処理ルート情報Ｒ１の格納内容は、処理ステップＳ１〜Ｓ５、及びＳ７となる。一方、処理ルート情報R2に対しては条件が成立しない場合（図２ではＳ６：Ｎｏ）の処理ステップ（図２ではＳ８）を格納（追加）する処理を実行する（Ｓ１０６）。これにより、処理ルート情報Ｒ２の格納内容は、処理ステップＳ１〜Ｓ５、及びＳ８となる。これは、一方のルート（以下ルート２という）の処理シーケンスを表す。
【００３６】
次に、処理シーケンス生成装置Ｍ１は、業務ロジック設計情報Ｄ１１から処理ステップＳ８を取り出す（Ｓ１００：Ｙｅｓ、Ｓ１０１）。この処理ステップＳ８は条件分岐ステップでないため、処理シーケンス生成装置Ｍ１は、この処理ステップＳ８を現在の処理ルート情報Ｒ１に追加する（Ｓ１０３）。これにより、処理ルート情報Ｒ１の格納内容は、処理ステップＳ１〜Ｓ５、Ｓ７、及びＳ８となる。これは、他方のルート（以下ルート１という）の処理シーケンスを表す。
【００３７】
上記各ルート１、２の処理シーケンスそれぞれに対しては、図４に示すシーケンス抽出処理が実行される。
図４は、各処理ルート（各ルート１、２の処理シーケンス）に対するデータアクセスシーケンス（図６参照）を抽出する処理について説明するためのフローチャートである。処理手順は以下のとおりである。
【００３８】
処理シーケンス生成装置Ｍ１は、各処理ルートに対して以下の処理を実行する。
処理シーケンス生成装置Ｍ１は、アクセスシーケンス（データベースアクセスシーケンス）として空のシーケンスを生成する。そして、処理シーケンス生成装置Ｍ１、処理ルート１から、処理ステップを一つづつ取り出し（Ｓ２００：Ｙｅｓ、Ｓ２０１）、その取り出した処理ステップを解析する。具体的には、その処理ステップの復帰値、手続き名、及び引数等（又は、readやwrite等、データベースに対する操作や、承認フローデータベー
ス等、その操作対象データベース）を解析する。
【００３９】
その解析の結果、処理ステップがデータベースへのアクセスの場合（Ｓ２０３：Ｙｅｓ）、処理シーケンス生成装置Ｍ１は、アクセスシーケンスに、そのアクセス対象データベース（テーブル）とそのアクセス内容（Read/Writeの区別、又はＲ／Ｗモードの区別）の対を格納（追加）する（Ｓ２０４）。例えば、処理ルート１については、図５に示すように、このルートを構成する処理ステップのうちＳ２、Ｓ４、及びＳ５がデータベースへのアクセスを伴う。一方、ルート２については、このルートを構成する処理ステップのうちＳ２、Ｓ４、Ｓ５、及びＳ７がデータベースへのアクセスを伴う。
【００４０】
従って、処理シーケンス生成装置Ｍ１は、ルート１については、アクセスシーケンスに、アクセス対象データベースとその操作内容の対として、承認フローデータベース(Read)→購買伝票本体データベース(Read)→品目情報データベース(Read)の順に格納（追加）する（Ｓ２０３：Ｙｅｓ、Ｓ２０４）。また、処理ルート２については、別のアクセスシーケンスに、アクセス対象データベースとそのアクセス内容の対として、承認フローデータベース(Read)→購買伝票本体データベース(Read)→品目情報データベース(Read)→承認履歴情報データベース(Read)の順に格納（追加）する（Ｓ２０３：Ｙｅｓ、Ｓ２０４）。
【００４１】
一方、処理ルート１、２のいずれについても、図５に示すように、これらのルートを構成する処理ステップのうちＳ１、Ｓ３、Ｓ６、及びＳ８は、データベースへのアクセスを伴わない（Ｓ２０３）。この場合、他手続きの呼び出しもないため（Ｓ２０５：Ｎｏ）、処理シーケンス生成装置Ｍ１は、Ｓ２００以下の処理を繰り返す。
【００４２】
以上述べたように、各処理ルート１、２のアクセスシーケンスには、アクセス対象データベースとそのアクセス内容の対が順に格納（追加）される。従って、このアクセスシーケンスを参照することにより、各処理ルート１，２のアクセス対象データベース、及びそれら各データベースへのアクセス順序を把握することが可能となっている。
【００４３】
一方、Ｓ２０２での解析の結果、処理ステップがデータベースへのアクセスでない場合（Ｓ２０３：Ｎｏ）、処理シーケンス生成装置Ｍ１は、その処理ステップが手続き呼び出しか否かを判定する（Ｓ２０５）。その判定の結果、その処理ステップが手続き呼び出しの場合は（Ｓ２０５：Ｙｅｓ）、処理シーケンス生成装置Ｍ１は、呼び出す手続きについてこの手続きを再帰的に実行し、得られたアクセスシーケンスを追加する（Ｓ２０６〜Ｓ２０８）。なお、呼び出しの可能性がある各手続きについて、その手続きを呼び出した際に実行されるアクセスシーケンスを予め用意しておき、手続き呼び出しに対して直接対応するアクセスシーケンスを取得して追加する方法を取ることもできる。
【００４４】
なお、業務ロジック設計情報から取り出した処理ステップが条件分岐ステップであるか否かについては、Ｓ１０２でその取り出した処理ステップがif文であるか否かにより判定するように説明したが、これに限定されない。例えば、同処理ステップがswitch文（又はその他の条件分岐命令）であるか否かにより判定するようにしてもよい。
【００４５】
なお、If文による条件判定がN回ある場合には、2のN乗とおりの処理ルート情報が生成
される。多値分岐がある場合は、各分岐における選択肢の数を掛け合わせた数の処理ルート情報が生成される。たとえばif文が4回、値4通りの多値分岐と値５通りの多値分岐が現れる場合は24×4×５=320通りの処理ルート情報が生成される。
【００４６】
なお、図６は、図２に示した業務ロジック設計情報から生成される処理ルート情報のうちの、一つの処理ルートにおけるデータアクセスシーケンス図である。図６では図５に示した２つの処理ルートのうち、承認フローフラグがOFFの場合のデータアクセスシーケン
ス図である。メインの業務ロジックは図６の左端にある「購買伝票一覧取得」である。
【００４７】
図６においては、承認ルートを参照するときには承認フローAPI、承認フロー本体操作
の２つの手続きを経由して承認ルートのデータベースを参照する。購買伝票本体を参照するときには購買伝票API、購買伝票本体操作の２つの手続きを経由して購買伝票本体のデ
ータベースを参照する。品目情報を参照するときには購買伝票API、品目情報操作の２つ
の手続きを経由して品目情報のデータベースをアクセスする。
（標準アクセスシーケンス生成装置）
標準アクセスシーケンス生成装置Ｍ２は、記憶装置からデータ仕様データ相関Ｄ２１を読み込み、そのデータ仕様データ相関Ｄ２１に基づいて、後述の処理（図１０参照）を実行することにより、標準アクセスシーケンスＤ２２を生成する。
（データ仕様データ相関）
図７は、データ相関図の例を説明するための図である。ここでは、説明の便宜上、図２に示した各データベースとは異なる複数のデータベースを取り上げて説明する。このデータ相関図は、複数のデータベースに対する標準的なアクセス順序を決定するために、複数のデータベース相互間の対応関係を可視的に表したものである。なお、この対応関係を表す対応関係データの例については図８、及び図９に示している（詳細については後述）。
【００４８】
図７では複数のデータベースとして８つのテーブル、即ち購買伝票本体テーブル、発注品目情報テーブル、購買申請者情報テーブル、販売担当者情報テーブル、商品情報テーブル、価格情報テーブル、購買企業情報テーブル、及び販売企業情報テーブルを示している。
【００４９】
これらテーブル相互間の対応関係は、２つのテーブルを結ぶ矢印によって示される。即ち、矢印の先端で指されたカラムが、その矢印の基端のカラムよりも後にアクセスするカラムになる。例えば、購買伝票本体テーブルのslipID(Primary Key)が基端、かつ、発注
品目情報テーブルのslipIDが先端の矢印により、両テーブルは結ばれている。これは、矢印の先端で指された発注品目情報テーブルのslipIDが、その矢印の基端の購買伝票本体テーブルのslipID(Primary Key)よりも後にアクセスされることを意味する。即ち、購買伝
票本体と発注品目情報では、購買伝票本体のslipID(Primary Key)を取得し、発注品目情
報テーブルに対して矢印の先端が指すslipIDが購買伝票本体のslipIDと同じ、という条件での検索を行う。
【００５０】
また、テーブル相互間の対応関係としては、次のようなものもある。図７を参照すると、発注品目情報テーブルのカラムslipidは購買伝票本体テーブルのカラムslipid(プライ
マリキー)の値を持ち、発注品目情報と購買依頼伝票の対応関係はN:1となっている(１件
の購買依頼伝票に対してN件の発注品目情報が対応する)。同様に、価格情報テーブルのproductIdは商品情報のプライマリキーidの値であり、価格情報と商品情報の対応関係はN:1となっている(１件の商品情報に対してN件の価格情報が対応)。また、発注品目情報のproductIdは商品情報のidの値で、発注品目情報と商品情報の対応は1:1(１件の発注品目情報に対し、１件の商品情報が対応)となっている。これらＮ：１や１：１も、テーブル相互
間の対応関係を表すためのものである。
【００５１】
図７に示したテーブル相互間の対応関係は、これら対応関係を表す対応関係データとして、情報処理端末により保持される。図８は、テーブル相互間の対応関係を表す対応関係データ（データ仕様データ相関）の例について説明するための図である。
【００５２】
ここでは、説明の便宜上、図７に示した複数のテーブルとは異なるテーブル（CT＿TUSRPARテーブル）を取り上げて説明する。なお、実際には、図７に示した各テーブルそれぞ
れに対して、図８に示したテーブル相互間の対応関係を表す対応関係データに相当するデータが存在する。図９は、図８の対応関係データをＸＭＬ言語で記述した例である。なお
、図８の対応関係データについては、ＸＭＬの他、ＪａｖａやＣ＋＋等の様々の言語で記述することが可能である。
【００５３】
図８は、利用者情報を格納するCT＿TUSRPARテーブルに対する対応関係データ（データ
仕様）である。このデータ仕様は、CT＿TUSRPARテーブルとCT＿TCMPCOMテーブル間の対応関係を表す対応関係データを含む。この対応関係データとしては、図８中段部分の"CORRESPONDS CT＿TCMPCOM.COMID（改行）TYPE=1:1（改行）ACCESS-SQUESNCE USRCOMP->CT＿TCMPCOM.COMID（改行）"が相当する。これは、矢印の先端で指されたCT＿TCMPCOMテーブルのカラムCOMIDが、その矢印の基端のCT＿TUSRPARテーブルのカラムUSRCOMPよりも後にアク
セスされることを意味する。また、"TYPE=1:1"の部分が、CT＿TCMPCOMとCT＿TCMPCOMとが1:1の関係にあることを表している。
【００５４】
なお、CT＿TUSRPARテーブルは、テーブル名がCT＿TUSRPAR、レコード数の想定値が3000レコードで、カラムとして利用者管理番号USERNUM、利用者名USERNAME、パスワードUSRPWD、利用者の所属企業USRCOMP、利用者所属事業所USROFFICE、利用者所属組織USRBELONG、利用者メールアドレスMAILADDR、利用者の電話番号PHONENUMBER、利用者のFAX番号FAXNUMBERを持ち、レコードを一意に決めるプライマリキーはUSERNUMとなっている。
（標準アクセス順序を生成する処理）
次に、標準アクセスシーケンス生成装置Ｍ２が、標準アクセスシーケンスＤ２
を生成する処理について説明する。図１０は、標準データアクセスシーケンスを生成する処理について説明するためのフローチャートである。処理手順は以下のとおりである。
【００５５】
標準アクセスシーケンス生成装置Ｍ２は、図７に示した各テーブルTAごとに、そのテーブルＴＡとそのテーブルＴＡとは別の各テーブルＴＢとの関係で、以下の処理を実行する。
【００５６】
標準アクセスシーケンス生成装置Ｍ２は、図７に示した複数のテーブルの中から、処理対象のテーブルＴＡを一つ選択し、そのテーブルTAのカラムのうち、カラムの値が各テーブルTBのカラムの値になっているカラムの数N1、及びテーブルTBのカラムのうち、カラムの値がテーブルTAのカラムの値になっているカラムの数N2を求める（Ｓ３００、Ｓ３０１）。
【００５７】
次に、標準アクセスシーケンス生成装置Ｍ２は、Ｎ１とＮ２を比較し、Ｎ１＞Ｎ２か否かを判定する（Ｓ３０２）。その結果、N1がN2より大であれば（Ｓ３０２：Ｙｅｓ）、テーブルTAをテーブルTBよりも前のアクセス順序にする（Ｓ３０３）。例えば、リスト上の配置順序を変える。又はテーブルTAに対するアクセス優先度を増やし、テーブルTBに対するアクセス優先度を減らす。
【００５８】
一方、Ｓ３０２の判定の結果、N1=N2の場合は（Ｓ３０２：Ｎｏ、Ｓ３０４：Ｙｅｓ）
、標準アクセスシーケンス生成装置Ｍ２は、テーブルＴＡの平均レコード数（図９に示したデータ仕様のヘッダ部分から得られる）とテーブルＴＢの平均レコード数とを比較し、テーブルＴＡの平均レコード数＜＝テーブルＴＢの平均レコード数か否かを判定する（Ｓ３０５）。
【００５９】
その結果、テーブルＴＡの平均レコード数＜＝テーブルＴＢの平均レコード数であれば（Ｓ３０５：Ｙｅｓ）、平均レコード数の少ない方のテーブルＴＡを、平均レコード数の多いテーブルＴＢより前のアクセス順序にする（Ｓ３０６）。例えば、リスト上の配置順序を変える。又は、平均レコード数の少ないテーブルＴＡの優先度を上げ、平均レコード数の多いテーブルＴＢの優先度を上げる。
【００６０】
一方、Ｓ３０４の判定の結果、N1がN2より小であれば（Ｓ３０２：Ｎｏ、Ｓ３０４：Ｎｏ）、テーブルTBをテーブルTAより前のアクセス順序にする。例えばリスト上の配置順序を変える。又は、テーブルTBに対するアクセス優先度を増やし、TAに対するアクセス優先度を減らす。
【００６１】
なお、Ｓ３０４の判定の結果、N1とN2が等しく（Ｓ３０２：Ｎｏ、Ｓ３０４：Ｙｅｓ）、Ｓ３０５の判定の結果、平均レコード数も等しい場合には、例えば、テーブルTAのカラム値がテーブルTBのプライマリキーの値である場合にテーブルTAをテーブルTBより前のアクセス順序にする。又は、テーブルTAに対するアクセス優先度を増やし、テーブルTBに対するアクセス優先度を減らす。
【００６２】
標準アクセスシーケンス生成装置Ｍ２は、図７に示した複数のテーブルの中から、選択できるテーブルがなくなるまで、処理対象の次のテーブルＴＡを一つ選択し、上記Ｓ３００〜Ｓ３０７の処理を繰り返す。
【００６３】
以上の処理により、最終的に得られるテーブルの順序（又は優先度の高い順にテーブルを並べたもの）が、標準的なテーブルのアクセス順序になる。
図１１は、標準データアクセスシーケンスの例を説明するための図である。図１１は、図７に示した複数のテーブルへの標準的なアクセス順序が、購買依頼伝票テーブル、品目情報テーブル、購買申請者情報テーブル、販売担当者情報テーブル、商品情報テーブル、価格情報テーブル、購買企業情報テーブル、販売企業情報テーブルであることを示している。
（デッドロック事前検出装置）
デッドロック事前検出装置Ｍ３は、各ルートの処理シーケンス、及び標準アクセスシーケンスに基づいて、後述の処理（図１２参照）を実行することにより、標準アクセス系列からの逸脱情報Ｄ３を生成する。
（逸脱情報生成処理）
次に、デッドロック事前検出装置Ｍ３が、各ルートの処理シーケンスＤ１２、及び標準アクセスシーケンスＤ２２に基づいて、標準アクセス系列からの逸脱情報Ｄ３を生成する処理について説明する。図１２は、図６に示した業務ロジックのあるルートにおけるアクセスシーケンスとの逸脱情報を抽出する処理について説明するためのフローチャートである。処理手順は以下のとおりである。
【００６４】
デッドロック事前検出装置Ｍ３は、各処理ルート（各ルートのアクセスシーケンス）に対して以下の処理を実行する。
デッドロック事前検出装置Ｍ３は、ある一つの処理ルートRに対して既に出現済のデー
タアクセスを格納する格納庫Sを空にする（Ｓ４００）。デッドロック事前検出装置Ｍ３
は、その処理ルートＲの中のデータアクセスArを一つづつ順に取り出す（Ｓ４０１：Ｎｏ、Ｓ４０２）。なお、全てのデータアクセスＡｒを取り出した場合は処理を終了する（Ｓ４０１：Ｙｅｓ）。
【００６５】
次に、デッドロック事前検出装置Ｍ３は、格納庫Sに、既に取出し済のデータアクセス
Ａｒがあるか否かを判定する（Ｓ４０３）。その結果、データアクセスＡｒがない場合（Ｓ４０３：Ｎｏ）には、格納庫SにデータアクセスArを格納（追加）し、Ｓ４０１に戻る
（Ｓ４０４）。
【００６６】
一方、Ｓ４０３の判定の結果、既に取出し済のデータアクセスＡｒがある場合には（Ｓ４０３：Ｙｅｓ）、格納庫Sからチェック対象のデータアクセスAsを読み出して（Ｓ４０
６）、標準のデータアクセス順序を参照して、データアクセスArがデータアクセスAsより先か否かを判定する（Ｓ４０７）。その結果、データアクセスArがデータアクセスAsより
先であれば（Ｓ４０７：Ｙｅｓ）、デッドロック事前検出装置Ｍ３は、データアクセスArがデータアクセスAsより先に実行されているという警告を作成する（Ｓ４０８）。
【００６７】
そして、デッドロック事前検出装置は、その旨の警告が既に出力済か否かを判定（例えば後述のフラグに基づく判定）し（Ｓ４０９）、その結果、出力済でなければ（Ｓ４０９：Ｎｏ）その旨の警告を出力して（Ｓ４１０）、その警告は出力済であることを示すフラグをセットする（Ｓ４１１）。
【００６８】
なお、警告の出力形態としては各種のものが考えられるが、ここでは、図１３に示すように、ログ（例えばログファイル）として出力（報知）される。以上のＳ４０６〜Ｓ４１１の処理は、格納庫Sに格納されている全てのデータアクセスAsに対して行われる（Ｓ４
０５）。全てのデータアクセスＡｓに対する処理が完了すると（Ｓ４０５：Ｙｅｓ）、デッドロック事前検出装置Ｍ３は、格納庫SにデータアクセスArを格納（追加）し、Ｓ４０
１に戻る（Ｓ４０４）。
【００６９】
以上の処理により、図１３下段に示した逸脱情報が得られる。業務システムの設計者等は、この逸脱情報を参照することで、標準のデータアクセス順序に従っていない業務ロジックのデータアクセス順序を修正して、業務ロジックにおけるデータアクセス順序が標準のデータアクセス順序になるようにすることが可能となる。
【００７０】
図１３は、標準データアクセスシーケンスに対する、ある業務ロジックのあるルートにおけるデータアクセスシーケンスの逸脱情報の例である。図１３においては標準的なテーブルのアクセス順序が、(1)購買伝票本体、(2)品目情報、(3)商品情報、(4)価格情報、(5)承認フロー情報、(6)承認履歴情報、(7)利用者情報、(8)企業情報の順になっている。
【００７１】
これに対して業務ロジック01050「購買依頼伝票の承認」の処理ルート01050-0001「利
用者の種別が購買管理者の場合の処理ルート」では、(1)承認フロー取得(Read)、(2)購買依頼伝票検索(Read)、(3)発注品目情報検索(Read)、(4)商品情報取得(Read)、(5)価格情
報検索(Read)、(6)承認履歴情報検索(Read)、(7)購買依頼伝票更新(Write)、(8)承認履歴情報更新(Write)の順になっている。
【００７２】
標準的なテーブルのアクセス順序と比較すると、承認フロー情報が、購買伝票情報、品目情報、商品情報、価格情報の４つのテーブルより前にアクセスされるようになっているところが異なる。従って警告では承認フロー情報と、これら４つのテーブルのアクセス順序が標準のテーブルアクセス順序と異なることに対してそれぞれ警告を出している。
（多重アクセス時デッドロック事前検出装置）
多重アクセス時デッドロック事前検出装置Ｍ４は、各ルートの処理シーケンスＤ１２、及び多重アクセス操作系列記述Ｄ１１に基づいて、後述の処理（図１６）を実行することにより、多重アクセスデッドロック可能性情報Ｄ４を生成する。
（多重アクセス記述）
図１４は、多重アクセス記述、即ち業務ロジックの実行順序、及び同時実行される業務ロジックの実行系列を表現する情報の例である。
【００７３】
図１４において、操作系列T1は以下の業務ロジックを以下の順序で実行する。(1)販売
支援でログインする。(2)見積・受注メニューを選択する。(3)見積回答を選択する。(4)
見積伝票一覧表示を選択する。(5)一覧表示の中から１つ、見積依頼伝票を選択する。(6)選択した見積依頼伝票に対して見積回答を実行する。(7)販売支援からログアウトする。
【００７４】
以上にあげた業務ロジックのうち、実際にデータベースに対してアクセスを行うのは(1), (4), (5), (6), (7)である。(2)、(3)は画面遷移のみの実行で、データベースに対し
てアクセスは行わない。従って、これから述べるデッドロックチェックでは(2)、(3)はチェックの対象外となる。
【００７５】
また、(4)の見積伝票一覧表示では、以下の４通りのルートが存在する。
ルートA001：利用者が特定の購買企業を担当し、任意のカテゴリの商品を取り扱う。データアクセス順序は、販売担当情報→見積依頼伝票→見積依頼品目情報の順である。ルートA002：利用者が全購買企業を担当し、任意のカテゴリの商品を取り扱う。
【００７６】
データアクセス順序は、見積依頼伝票→見積依頼品目情報の順である。
ルートA003：利用者が特定の購買企業を担当し、特定のカテゴリの商品を取り扱う。データアクセス順序は、販売担当情報→見積依頼伝票→見積依頼品目情報→商品情報の順である。
【００７７】
ルートA004：利用者が全購買企業を担当し、特定のカテゴリの商品を取り扱う。データアクセス順序は、販売担当情報→見積依頼伝票→見積依頼品目情報→商品情報の順である。
【００７８】
図１５は、図１４の多重アクセス記述と図４，５のアクセスシーケンス情報から検出されるデッドロック可能性の例である。図１５においては操作系列T1の中の業務ロジックL1において、処理ルートR1が存在し、テーブルをTable1(Read)→Table2(Read/Write)→Table3(Write)→Table4(Read)の順にアクセスする。一方、操作系列T2の中に業務ロジックL2
において、処理ルートR2が存在し、テーブルをTable1(Read)→Table3(Write)→Table2(Write)→Table4(Read)の順にアクセスする。ここで、R1とR2が同時に実行される場合、Table2とTable3においてデッドロック発生の可能性が出る。
【００７９】
図１６は、図１４の多重アクセス記述と、図５、６のアクセスシーケンス情報から図１５に示す多重アクセス時のデッドロックを検出するアルゴリズムである。処理手順としては、全ての操作系列T1,T2の組み合わせに対して以下を実行する。
(1)   T1の各業務ロジックL1、T2の各業務ロジックL2に対して以下を実行する。
(2)   L1の各処理ルートR1、L2の各処理ルートR2に対して以下を実行する。
(3)   R1に出現するデータアクセスから任意の２個を選んだ組み合わせC1を生成する。
(4)   R2に出現するデータアクセスから任意の２個を選んだ組み合わせC2を生成する。
(5)   C1の各データアクセスの対P1に対して、以下を実行する。
(6)   C2の各データアクセスの対から、P1と同じデータアクセスを持つデータアクセスの対P2を取り出す。
(7)   P1とP2においてデータアクセスの順が逆になっていたら、R1とR2の間でP1,P2に含
まれるデータアクセスでデッドロックの可能性があると判断し、デッドロックの可能性を警告するメッセージを出力する（既に出力済かどうかをチェックして、出力済でなければ出力する）。
【００８０】
全ての組み合わせに対してチェックするコストが大きい場合は、たとえば以下のようにしてチェックする操作系列を絞り込むことができる。
(A)各操作系列(または業務ロジック、業務ロジックの中の処理ルート)に対して発生頻
度情報(単位時間あたりの発生数)を持たせる。発生頻度が一定の閾値以下であればその操作系列(または、業務ロジック、業務ロジックの中の処理ルート)はチェックの対象からはずす。
【００８１】
(B)発生頻度情報がない場合、データテーブルに対してデッドロックのチェックを行う/行わないのフラグ情報を設定し、データアクセスの対に対してデッドロックのチェックを行うときに、対象となるテーブルがいずれもデッドロックを行うフラグがONになっている
場合のみチェックを行う。
【００８２】
以上述べたように、本実施形態のデッドロック防止システム（プログラム）によれば、次の効果を奏する。
(1) 業務システムの保守性向上  データアクセス処理系列を、全ての業務ロジックで遵守することにより業務システムを構成する業務ロジックの作りを統一することができる。業務ロジックの作りが統一されることにより、業務ロジックを記述するプログラムの見通しが良くなる。すなわち業務システム全体としての保守性が向上する。
【００８３】
(2) 業務システムの品質確保  多重アクセス環境下で使用される業務システムにおいて、デッドロックの可能性を設計段階で網羅的に検出し、設計段階で業務システム全体にわたって、発生の可能性があるデッドロックをすべた洗い出し、洗い出したデッドロックに対する防止策をとることができる。したがって、設計段階でデッドロック防止に関する品質の作りこみを可能にする。
【００８４】
(3) 業務システム開発期間の短縮  テスト段階でデッドロックを逐一見つけて対策をとる方式にくらべて作業の手戻りを少なくすることができる。このため、設計から開発、テストを含めた業務システムの開発期間を2/3〜1/2近くまで短縮することができる。
【００８５】
本発明は、以下の分野にも適用可能である。
複数のデータ集合体から構成されるデータ格納庫を利用して業務処理を実行する装置において、複数の業務処理が同時に同じデータをアクセスすることによる資源競合(デッド
ロック)を運用前の設計段階で事前に検出するために適用される。
【００８６】
データ格納庫の例としては、関係データベース(データ集合体がテーブル、各データが
レコード)やオブジェクト指向データベース(データ集合体がオブジェクトの集まり、各データがオブジェクトと呼ばれるデータ構造)が考えられる。装置の例としては、電子商取
引システムや会計システム、取引情報管理システム、電子カタログ管理システムなどが考えられる。
【００８７】
電子商取引システムの場合、データ集合体としてたとえば利用者情報、企業情報、見積依頼伝票、購買依頼伝票、購入実績情報、商品情報、価格情報などのテーブルを持つ。これらのデータをアクセスする業務ロジックとしては見積依頼や購買依頼伝票の発行、見積依頼や購買依頼伝票に対する承認、見積回答や受注回答などが挙げられる。
【００８８】
本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施することができる。このため、上記の実施形態は、あらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。
【産業上の利用可能性】
【００８９】
本発明によれば、デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出することが可能となる。また、そのように検出されたデッドロック可能性回避のための方策等について利用者に対して報知することにより、デッドロック可能性回避のための方策等を採ることが可能となる。
【図面の簡単な説明】
【００９０】
【図１】本実施形態のデッドロック事前検出システム（デッドロック事前検出プログラムが適用される）の概略システム構成について説明するための図である。
【図２】購買依頼伝票の一覧を取得するための業務ロジックについて説明するための図である。
【図３】処理ルート情報を生成する処理について説明するためのフローチャートである。
【図４】シーケンス抽出処理について説明するためのフローチャートである。
【図５】処理ルート情報の例である。
【図６】データアクセスシーケンス図の例である。
【図７】データ相関図の例である。
【図８】データ仕様の記述例である。
【図９】データ仕様の記述例である（ＸＭＬ表記）。
【図１０】標準データアクセスシーケンスを生成する処理について説明するためのフローチャートである。
【図１１】標準データアクセスシーケンスの例である。
【図１２】逸脱情報を生成する処理について説明するためのフローチャートである。
【図１３】逸脱情報等の例である。
【図１４】多重アクセスのための操作系列記述の例である。
【図１５】図１４の多重アクセス記述と図４、５のアクセスシーケンス情報から検出されるデッドロック可能性の例である。
【図１６】多重アクセス時のデッドロックを検出するアルゴリズムである。
【図１７】従来のデッドロック検出方法について説明するための図である。
【符号の説明】
【００９１】
Ｍ１      処理シーケンス生成装置
Ｍ２      標準アクセスシーケンス生成装置
Ｍ３      デッドロック事前検出装置
Ｍ４      多重アクセス時デッドロック事前検出装置
Ｄ１１    業務ロジック設計情報
Ｄ１２    処理シーケンス
Ｄ２１    データ仕様データ相関
Ｄ２２    標準アクセスシーケンス
Ｄ３      逸脱情報
Ｄ４      多重アクセスデッドロック可能性情報
【図１】
2005122560.tif 000003
【図２】
2005122560.tif 000004
【図３】
2005122560.tif 000005
【図４】
2005122560.tif 000006
【図５】
2005122560.tif 000007
【図６】
2005122560.tif 000008
【図７】
2005122560.tif 000009
【図８】
2005122560.tif 000010
【図９】
2005122560.tif 000011
【図１０】
2005122560.tif 000012
【図１１】
2005122560.tif 000013
【図１２】
2005122560.tif 000014
【図１３】
2005122560.tif 000015
【図１４】
2005122560.tif 000016
【図１５】
2005122560.tif 000017
【図１６】
2005122560.tif 000018
【図１７】
2005122560.tif 000019