JP2005122560A - デッドロック事前検出プログラム - Google Patents
デッドロック事前検出プログラム Download PDFInfo
- Publication number
- JP2005122560A JP2005122560A JP2003358268A JP2003358268A JP2005122560A JP 2005122560 A JP2005122560 A JP 2005122560A JP 2003358268 A JP2003358268 A JP 2003358268A JP 2003358268 A JP2003358268 A JP 2003358268A JP 2005122560 A JP2005122560 A JP 2005122560A
- Authority
- JP
- Japan
- Prior art keywords
- access
- processing
- procedure
- deadlock
- order
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/524—Deadlock detection or avoidance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
- G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Abstract
【課題】 デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出する。
【解決手段】 コンピュータに、複数のデータベースのうちのいずれかへのアクセスを伴うアクセスステップを含む複数の処理ステップにより構成される業務ロジック設計情報を読み込ませる第１手順、前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される処理ルートを生成する第２手順、前記処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得する第３手順、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する第４手順、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、予め定められたアクセス順序から逸脱した旨を報知する第５手順、を実行させるためのデッドロック事前検出プログラム。
【選択図】図１
【解決手段】 コンピュータに、複数のデータベースのうちのいずれかへのアクセスを伴うアクセスステップを含む複数の処理ステップにより構成される業務ロジック設計情報を読み込ませる第１手順、前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される処理ルートを生成する第２手順、前記処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得する第３手順、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する第４手順、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、予め定められたアクセス順序から逸脱した旨を報知する第５手順、を実行させるためのデッドロック事前検出プログラム。
【選択図】図１
Description
本発明は、デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出するための技術に関する。
従来、デッドロック検出方法として、デッドロック検出の対象となる手続き（処理ステップ等）を実行、又はシミュレートして得られたデータアクセスシーケンスを分析することでデッドロックの検出を行う技術が提案されている。
この従来のデッドロック検出方法の例について図１７に示す。同図は、実行中のアプリ
ケーションがデータベースに対してアクセスした履歴（図中ＳＱＬ履歴）を履歴抽出器（図中ＳＱＬ履歴抽出器）により記録し、このアクセス履歴に基づいて、デッドロック検出器が所定処理を実行することにより、デッドロック検出結果を出力することを示している（例えば、特許文献１、及び特許文献２等参照）。
特開２０００−２２２２２８号公報
特開平１０−４９３８９号公報
ケーションがデータベースに対してアクセスした履歴（図中ＳＱＬ履歴）を履歴抽出器（図中ＳＱＬ履歴抽出器）により記録し、このアクセス履歴に基づいて、デッドロック検出器が所定処理を実行することにより、デッドロック検出結果を出力することを示している（例えば、特許文献１、及び特許文献２等参照）。
しかしながら、従来のデッドロック検出方法によれば、デッドロックを検出するには、デッドロック検出対象のプログラムを実際に実行する必要がある。このため、以下の問題点がある。
（１）実際に動作させた部分についてしかデッドロックを検出できない。換言すれば、全てのケース（全ての処理ルート）についてデッドロックを検出したこと(網羅性)の証明が難しい。特に多重アクセス時のプログラム検証を行う場合、全ての可能性をチェックするのは事実上不可能に近い。
（２）既にプログラムができてからチェックを行うため、デッドロック解消のためにプログラムを修正するためのコストが大きくなる（設計段階での修正の10倍〜100倍程度）
。
。
（３）各業務ロジックを分担して開発する場合、担当者によってデータベースアクセス順序の実装にばらつきがあるためデッドロックを起こし得るが、プログラムができてからチェックする方法ではこの問題を解消できない。
本発明の第１の課題は、デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出することにある。また、本発明の第２の課題は、そのように検出されたデッドロック可能性回避のための方策等について利用者に対して報知することにより、デッドロック可能性回避のための方策等を採ることできるようにすることにある。
本発明は、上記の課題を解決するために次のように構成した。コンピュータに、複数のデータベースのうちのいずれかへのアクセスを伴うアクセスステップを含む複数の処理ステップにより構成される業務ロジック設計情報を読み込ませる第１手順、前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される処理ルート
を生成する第２手順、前記処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得する第３手順、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する第４手順、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、予め定められたアクセス順序から逸脱した旨を報知する第５手順、を実行させるためのデッドロック事前検出プログラム。
を生成する第２手順、前記処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得する第３手順、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する第４手順、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、予め定められたアクセス順序から逸脱した旨を報知する第５手順、を実行させるためのデッドロック事前検出プログラム。
本発明によれば、業務システムを構成するプログラムを設計する段階（即ち業務ロジック設計書作成段階）で、デッドロックの可能性を検出することが可能となる。即ち、デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出することが可能となる。
このように、事前にデッドロックの可能性を検出することが可能となるため、デッドロック解消のためにプログラムを修正するためのコストが大きくなることもない。また、業務ロジックを分担して開発する場合、担当者によってデータベースアクセス順序の実装にばらつきが生ずることによるデッドロックの可能性を低減できる。
また、上記デッドロック事前検出プログラムにおいては、例えば、前記業務ロジック設計情報は、前記アクセスステップ及び分岐条件ステップを含む複数の処理ステップにより構成され、前記第２手順は、前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される少なくとも２つの処理ルートを生成し、前記第３手順は、各処理ルートごとに、その処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得し、前記第４手順は、各処理ルートごとに、前記第１及び第２アクセスステップによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する。
このようにすれば、分岐条件ステップの各分岐先を経由することで複数の処理ルートが生成されたとしても、これら全処理ルートについて網羅的にデッドロックの可能性を検出することが可能となる。
また、上記デッドロック事前検出プログラムにおいては、例えば、前記複数のデータベース相互間の対応関係を表す対応関係データを読み込ませる第６手順、前記対応関係データに基づいて、前記予め定められたアクセス順序を生成する第７手順、をさらに備える。
これは、予め定められたアクセス順序をどのようにして得るかについての一例を示したものである。利用者等により入力（設定）されたものアクセス順序を、予め定められたアクセス順序としてもよい。
これは、予め定められたアクセス順序をどのようにして得るかについての一例を示したものである。利用者等により入力（設定）されたものアクセス順序を、予め定められたアクセス順序としてもよい。
このようにすれば、予め定められたアクセス順序を自動的に生成することが可能となる。
また、上記デッドロック事前検出プログラムにおいては、例えば、前記第３手順は、前記処理ルートから、第１アクセスステップ、及び該第１アクセスステップの次の第２アクセスステップを取得し、第４手順は、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定し、前記第５手順は、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、前記第１アクセスステップによるデータベースへのアクセスが、前記第２アクセスステップによるデータベースへのアクセスよりも先に行われている旨を報知する。
また、上記デッドロック事前検出プログラムにおいては、例えば、前記第３手順は、前記処理ルートから、第１アクセスステップ、及び該第１アクセスステップの次の第２アクセスステップを取得し、第４手順は、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定し、前記第５手順は、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、前記第１アクセスステップによるデータベースへのアクセスが、前記第２アクセスステップによるデータベースへのアクセスよりも先に行われている旨を報知する。
このようにすれば、記第１アクセスステップによるデータベースへのアクセスが前記第２アクセスステップによるデータベースへのアクセスよりも先に行われている旨、即ち、
デッドロック可能性回避のための方策等について、利用者に対して報知されることになる。
デッドロック可能性回避のための方策等について、利用者に対して報知されることになる。
従って、この報知を受けた利用者は、そのデッドロック可能性回避のための方策等を採ることが可能となる。また、業務システムを構成する各業務ロジック、たとえば見積依頼伝票や購買依頼伝票の発行、承認といった業務ロジックにおける標準的なデータアクセス順序を決め、各業務ロジックにおいてデータアクセス順序を統一することも可能となる。
また、上記デッドロック事前検出プログラムにおいては、例えば、多重アクセス記述と前記処理ルートを読み込ませる第８手順、前記多重アクセス記述と処理ルートに基づいて、前記複数の処理ステップにより構成される業務ロジックを同時実行する場合に、デッドロックが発生する可能性の情報を生成する第９手順、をさらに備える。
このようにすれば、多重アクセス時におけるデッドロックの可能性を検出し、デッドロック回避の対策をとることができる。
また、本発明は、上記デッドロック事前検出プログラムを記録したコンピュータ読み取り可能な記録媒体として特定することもできる。
また、本発明は、上記デッドロック事前検出プログラムを記録したコンピュータ読み取り可能な記録媒体として特定することもできる。
デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出することが可能となる。また、そのように検出されたデッドロック可能性回避のための方策等について利用者に対して報知することにより、デッドロック可能性回避のための方策等を採ることが可能となる。
以下、本発明の一実施形態であるプログラムが適用されるデッドロック防止システムについて図面を参照しながら説明する。
（デッドロック事前検出システムの概略システム構成）
図１は、本実施形態のデッドロック事前検出システムの概略システム構成について説明するための図である。図１に示すように、本実施形態のデッドロック事前検出システムは、処理シーケンス生成装置Ｍ１、標準アクセスシーケンス生成装置Ｍ２、デッドロック事前検出装置Ｍ３、多重アクセス時デッドロック事前検出装置Ｍ４、及びこれらの各装置Ｍ１〜Ｍ４に読み込まれる各種データ（業務ロジック設計情報Ｄ１１、データ仕様データ相関Ｄ２１、及び多重アクセス操作系列記述Ｄ４等）が格納されたハードディスク装置等の記憶装置を備えている。これら各装置Ｍ１〜Ｍ４は、例えば、パーソナルコンピュータ等の既存の情報処理端末が所定のプログラムを読み込み、これを実行することにより実現される。
（処理シーケンス生成装置）
処理シーケンス生成装置Ｍ１は、記憶装置から業務ロジック設計情報Ｄ１１を読み込み、その業務ロジック設計情報Ｄ１に基づいて、後述の処理（図３及び図４参照）を実行する。これにより、処理シーケンス生成装置Ｍ１は、各ルートの処理シーケンス（処理ルート）を生成する。
（業務ロジック設計情報）
業務ロジック設計情報Ｄ１１は、複数の処理ステップにより構成される。これら複数の処理ステップ全体により特定業務のロジック（例えば購買依頼伝票の一覧を取得するための業務ロジック）が構成される。処理ステップとしては、複数のデータベース（又は、テーブルともいう）のうちのいずれかへのアクセスを伴うアクセスステップ、分岐条件ステップ、開始ステップ、及び終了ステップ等がある。
（デッドロック事前検出システムの概略システム構成）
図１は、本実施形態のデッドロック事前検出システムの概略システム構成について説明するための図である。図１に示すように、本実施形態のデッドロック事前検出システムは、処理シーケンス生成装置Ｍ１、標準アクセスシーケンス生成装置Ｍ２、デッドロック事前検出装置Ｍ３、多重アクセス時デッドロック事前検出装置Ｍ４、及びこれらの各装置Ｍ１〜Ｍ４に読み込まれる各種データ（業務ロジック設計情報Ｄ１１、データ仕様データ相関Ｄ２１、及び多重アクセス操作系列記述Ｄ４等）が格納されたハードディスク装置等の記憶装置を備えている。これら各装置Ｍ１〜Ｍ４は、例えば、パーソナルコンピュータ等の既存の情報処理端末が所定のプログラムを読み込み、これを実行することにより実現される。
（処理シーケンス生成装置）
処理シーケンス生成装置Ｍ１は、記憶装置から業務ロジック設計情報Ｄ１１を読み込み、その業務ロジック設計情報Ｄ１に基づいて、後述の処理（図３及び図４参照）を実行する。これにより、処理シーケンス生成装置Ｍ１は、各ルートの処理シーケンス（処理ルート）を生成する。
（業務ロジック設計情報）
業務ロジック設計情報Ｄ１１は、複数の処理ステップにより構成される。これら複数の処理ステップ全体により特定業務のロジック（例えば購買依頼伝票の一覧を取得するための業務ロジック）が構成される。処理ステップとしては、複数のデータベース（又は、テーブルともいう）のうちのいずれかへのアクセスを伴うアクセスステップ、分岐条件ステップ、開始ステップ、及び終了ステップ等がある。
業務ロジック設計情報Ｄ１１は、各種の方法で作成することが可能である。本実施形態では、複数の処理ステップを、情報処理端末が処理可能なスクリプト言語等の簡易言語で記述する。なお、スクリプト言語で記述された業務ロジック設計情報Ｄ１１は、実行形式のプログラムにコード化することで実行可能となる。
次に、業務ロジック設計情報Ｄ１１の具体例として、購買依頼伝票の一覧を取得するための業務ロジックを説明する。図２は、購買依頼伝票の一覧を取得するための業務ロジックについて説明するための図である。
この業務ロジック設計情報Ｄ１１は、開始ステップＳ１、データベースへのアクセスステップＳ２、Ｓ４、Ｓ５、Ｓ７、フラグ設定ステップＳ３、分岐条件ステップＳ６、及び終了ステップＳ８等の複数の処理ステップＳ１〜Ｓ８により構成される。
次に、各ステップの処理内容の詳細、及び各ステップ（例えば動作や動作対象等により表される）をスクリプト言語で記述した例について説明する。
開始ステップＳ１では、処理内容が「購買伝票の検索開始」、記述例が「start」とな
る。アクセスステップＳ２では、処理内容が「承認フロー検索（業務ロジック実行者が所属する組織における承認フロー情報を、承認フローデータベースから検索(データベース
に対しては参照系のアクセス)）」、記述例が「read承認フローデータベース」となる。
この記述例は、承認フローデータベースに対するアクセスが発生することを表している。
開始ステップＳ１では、処理内容が「購買伝票の検索開始」、記述例が「start」とな
る。アクセスステップＳ２では、処理内容が「承認フロー検索（業務ロジック実行者が所属する組織における承認フロー情報を、承認フローデータベースから検索(データベース
に対しては参照系のアクセス)）」、記述例が「read承認フローデータベース」となる。
この記述例は、承認フローデータベースに対するアクセスが発生することを表している。
フラグ設定ステップＳ３では、処理内容が「承認フローがＳ２の検索で見つかった場合、承認フローフラグをONに設定」、記述例が「set apr＿flow-flag」となる。この記述例は、apr＿flow-flagがセットされることを表している。
アクセスステップＳ４では、処理内容が「購買依頼伝票の検索(データベースに対して
は参照系のアクセス)」、記述例が「read購買伝票本体データベース」となる。この記述
例は、購買伝票本体データベースに対するアクセスが発生することを表している。
は参照系のアクセス)」、記述例が「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が真であればＳ７を実行し、一方、check apr＿flow-flagが偽であればＳ８を実行することを表している。
アクセスステップＳ７では、処理内容が「承認フローフラグ（check apr＿flow-flag）がONの場合は、Ｓ４で検索された伝票に対する承認履歴情報データベースを検索（データベースに対しては参照系のアクセス）」、記述例が「read承認履歴情報データベース」となる。この記述例は、承認履歴情報データベースに対するアクセスが発生することを示している。
最終ステップＳ８では、処理内容が「検索結果(購買依頼伝票、品目情報、承認フロー
フラグがONの場合は承認履歴情報も含む)を返却」、記述例が「end」となる。
（処理ルート情報を生成する処理）
次に、処理シーケンス生成装置Ｍ１が、業務ロジック設計情報Ｄ１１に基づいて、処理ルート情報（各ルートの処理シーケンス）を生成する処理について説明する。図３は、処
理ルート情報を生成する処理について説明するためのフローチャートである。処理手順は以下のとおりである。
フラグがONの場合は承認履歴情報も含む)を返却」、記述例が「end」となる。
（処理ルート情報を生成する処理）
次に、処理シーケンス生成装置Ｍ１が、業務ロジック設計情報Ｄ１１に基づいて、処理ルート情報（各ルートの処理シーケンス）を生成する処理について説明する。図３は、処
理ルート情報を生成する処理について説明するためのフローチャートである。処理手順は以下のとおりである。
処理シーケンス生成装置Ｍ１は、業務ロジック設計情報Ｄ１１を構成する処理ステップＳ１〜Ｓ８に対して以下の処理を実行する。
処理シーケンス生成装置Ｍ１は、業務ロジック設計情報Ｄ１１から、一つずつ処理ステップを取り出し（Ｓ１００：Ｙｅｓ、Ｓ１０１）、その取り出した処理ステップが条件分岐ステップか否かを判定する（Ｓ１０２）。そして、処理シーケンス生成装置Ｍ１は、その取り出した処理ステップが条件分岐ステップでなければ（Ｓ１０２：Ｎｏ）、その取り出した処理ステップを現在の処理ルート情報Ｒ１に格納（追加）する（Ｓ１０３）。
処理シーケンス生成装置Ｍ１は、業務ロジック設計情報Ｄ１１から、一つずつ処理ステップを取り出し（Ｓ１００：Ｙｅｓ、Ｓ１０１）、その取り出した処理ステップが条件分岐ステップか否かを判定する（Ｓ１０２）。そして、処理シーケンス生成装置Ｍ１は、その取り出した処理ステップが条件分岐ステップでなければ（Ｓ１０２：Ｎｏ）、その取り出した処理ステップを現在の処理ルート情報Ｒ１に格納（追加）する（Ｓ１０３）。
図２を参照すると、業務ロジックの最初の処理ステップＳ１〜Ｓ５までは、条件分岐ステップではない。このため、処理シーケンス生成装置Ｍ１は、最初の処理ステップＳ１〜Ｓ５を、現在の処理ルート情報Ｒ１に格納（追加）する（Ｓ１００〜Ｓ１０３）。
次に、処理シーケンス生成装置Ｍ１は、業務ロジック設計情報Ｄ１１から処理ステップＳ６を取り出す（Ｓ１００：Ｙｅｓ、Ｓ１０１）。この処理ステップＳ６は条件分岐ステップ(if文)であるので（Ｓ１０２：Ｙｅｓ）、処理シーケンス生成装置Ｍ１は、現在の処理ルート情報R1のコピーR2（処理ステップＳ１〜Ｓ５が格納されている）を生成する（Ｓ１０４）。
そして、処理シーケンス生成装置Ｍ１は、処理ルート情報R1に対しては条件が成立する場合（図２ではＳ６：Ｙｅｓ）の処理ステップ（図２ではＳ７）を格納（追加）する処理を実行する（Ｓ１０５）。これにより、処理ルート情報Ｒ１の格納内容は、処理ステップＳ１〜Ｓ５、及びＳ７となる。一方、処理ルート情報R2に対しては条件が成立しない場合（図２ではＳ６：Ｎｏ）の処理ステップ（図２ではＳ８）を格納（追加）する処理を実行する（Ｓ１０６）。これにより、処理ルート情報Ｒ２の格納内容は、処理ステップＳ１〜Ｓ５、及びＳ８となる。これは、一方のルート（以下ルート２という）の処理シーケンスを表す。
次に、処理シーケンス生成装置Ｍ１は、業務ロジック設計情報Ｄ１１から処理ステップＳ８を取り出す（Ｓ１００：Ｙｅｓ、Ｓ１０１）。この処理ステップＳ８は条件分岐ステップでないため、処理シーケンス生成装置Ｍ１は、この処理ステップＳ８を現在の処理ルート情報Ｒ１に追加する（Ｓ１０３）。これにより、処理ルート情報Ｒ１の格納内容は、処理ステップＳ１〜Ｓ５、Ｓ７、及びＳ８となる。これは、他方のルート（以下ルート１という）の処理シーケンスを表す。
上記各ルート１、２の処理シーケンスそれぞれに対しては、図４に示すシーケンス抽出処理が実行される。
図４は、各処理ルート（各ルート１、２の処理シーケンス）に対するデータアクセスシーケンス（図６参照）を抽出する処理について説明するためのフローチャートである。処理手順は以下のとおりである。
図４は、各処理ルート（各ルート１、２の処理シーケンス）に対するデータアクセスシーケンス（図６参照）を抽出する処理について説明するためのフローチャートである。処理手順は以下のとおりである。
処理シーケンス生成装置Ｍ１は、各処理ルートに対して以下の処理を実行する。
処理シーケンス生成装置Ｍ１は、アクセスシーケンス（データベースアクセスシーケンス）として空のシーケンスを生成する。そして、処理シーケンス生成装置Ｍ１、処理ルート１から、処理ステップを一つづつ取り出し（Ｓ２００：Ｙｅｓ、Ｓ２０１）、その取り出した処理ステップを解析する。具体的には、その処理ステップの復帰値、手続き名、及び引数等（又は、readやwrite等、データベースに対する操作や、承認フローデータベー
ス等、その操作対象データベース）を解析する。
処理シーケンス生成装置Ｍ１は、アクセスシーケンス（データベースアクセスシーケンス）として空のシーケンスを生成する。そして、処理シーケンス生成装置Ｍ１、処理ルート１から、処理ステップを一つづつ取り出し（Ｓ２００：Ｙｅｓ、Ｓ２０１）、その取り出した処理ステップを解析する。具体的には、その処理ステップの復帰値、手続き名、及び引数等（又は、readやwrite等、データベースに対する操作や、承認フローデータベー
ス等、その操作対象データベース）を解析する。
その解析の結果、処理ステップがデータベースへのアクセスの場合（Ｓ２０３：Ｙｅｓ）、処理シーケンス生成装置Ｍ１は、アクセスシーケンスに、そのアクセス対象データベース（テーブル）とそのアクセス内容（Read/Writeの区別、又はＲ／Ｗモードの区別）の対を格納（追加）する（Ｓ２０４）。例えば、処理ルート１については、図５に示すように、このルートを構成する処理ステップのうちＳ２、Ｓ４、及びＳ５がデータベースへのアクセスを伴う。一方、ルート２については、このルートを構成する処理ステップのうちＳ２、Ｓ４、Ｓ５、及びＳ７がデータベースへのアクセスを伴う。
従って、処理シーケンス生成装置Ｍ１は、ルート１については、アクセスシーケンスに、アクセス対象データベースとその操作内容の対として、承認フローデータベース(Read)→購買伝票本体データベース(Read)→品目情報データベース(Read)の順に格納（追加）する（Ｓ２０３：Ｙｅｓ、Ｓ２０４）。また、処理ルート２については、別のアクセスシーケンスに、アクセス対象データベースとそのアクセス内容の対として、承認フローデータベース(Read)→購買伝票本体データベース(Read)→品目情報データベース(Read)→承認履歴情報データベース(Read)の順に格納（追加）する（Ｓ２０３：Ｙｅｓ、Ｓ２０４）。
一方、処理ルート１、２のいずれについても、図５に示すように、これらのルートを構成する処理ステップのうちＳ１、Ｓ３、Ｓ６、及びＳ８は、データベースへのアクセスを伴わない（Ｓ２０３）。この場合、他手続きの呼び出しもないため（Ｓ２０５：Ｎｏ）、処理シーケンス生成装置Ｍ１は、Ｓ２００以下の処理を繰り返す。
以上述べたように、各処理ルート１、２のアクセスシーケンスには、アクセス対象データベースとそのアクセス内容の対が順に格納（追加）される。従って、このアクセスシーケンスを参照することにより、各処理ルート１，２のアクセス対象データベース、及びそれら各データベースへのアクセス順序を把握することが可能となっている。
一方、Ｓ２０２での解析の結果、処理ステップがデータベースへのアクセスでない場合（Ｓ２０３：Ｎｏ）、処理シーケンス生成装置Ｍ１は、その処理ステップが手続き呼び出しか否かを判定する（Ｓ２０５）。その判定の結果、その処理ステップが手続き呼び出しの場合は（Ｓ２０５：Ｙｅｓ）、処理シーケンス生成装置Ｍ１は、呼び出す手続きについてこの手続きを再帰的に実行し、得られたアクセスシーケンスを追加する（Ｓ２０６〜Ｓ２０８）。なお、呼び出しの可能性がある各手続きについて、その手続きを呼び出した際に実行されるアクセスシーケンスを予め用意しておき、手続き呼び出しに対して直接対応するアクセスシーケンスを取得して追加する方法を取ることもできる。
なお、業務ロジック設計情報から取り出した処理ステップが条件分岐ステップであるか否かについては、Ｓ１０２でその取り出した処理ステップがif文であるか否かにより判定するように説明したが、これに限定されない。例えば、同処理ステップがswitch文（又はその他の条件分岐命令）であるか否かにより判定するようにしてもよい。
なお、If文による条件判定がN回ある場合には、2のN乗とおりの処理ルート情報が生成
される。多値分岐がある場合は、各分岐における選択肢の数を掛け合わせた数の処理ルート情報が生成される。たとえばif文が4回、値4通りの多値分岐と値５通りの多値分岐が現れる場合は24×4×５=320通りの処理ルート情報が生成される。
される。多値分岐がある場合は、各分岐における選択肢の数を掛け合わせた数の処理ルート情報が生成される。たとえばif文が4回、値4通りの多値分岐と値５通りの多値分岐が現れる場合は24×4×５=320通りの処理ルート情報が生成される。
なお、図６は、図２に示した業務ロジック設計情報から生成される処理ルート情報のうちの、一つの処理ルートにおけるデータアクセスシーケンス図である。図６では図５に示した２つの処理ルートのうち、承認フローフラグがOFFの場合のデータアクセスシーケン
ス図である。メインの業務ロジックは図６の左端にある「購買伝票一覧取得」である。
ス図である。メインの業務ロジックは図６の左端にある「購買伝票一覧取得」である。
図６においては、承認ルートを参照するときには承認フローAPI、承認フロー本体操作
の２つの手続きを経由して承認ルートのデータベースを参照する。購買伝票本体を参照するときには購買伝票API、購買伝票本体操作の２つの手続きを経由して購買伝票本体のデ
ータベースを参照する。品目情報を参照するときには購買伝票API、品目情報操作の２つ
の手続きを経由して品目情報のデータベースをアクセスする。
（標準アクセスシーケンス生成装置）
標準アクセスシーケンス生成装置Ｍ２は、記憶装置からデータ仕様データ相関Ｄ２１を読み込み、そのデータ仕様データ相関Ｄ２１に基づいて、後述の処理（図１０参照）を実行することにより、標準アクセスシーケンスＤ２２を生成する。
（データ仕様データ相関）
図７は、データ相関図の例を説明するための図である。ここでは、説明の便宜上、図２に示した各データベースとは異なる複数のデータベースを取り上げて説明する。このデータ相関図は、複数のデータベースに対する標準的なアクセス順序を決定するために、複数のデータベース相互間の対応関係を可視的に表したものである。なお、この対応関係を表す対応関係データの例については図８、及び図９に示している（詳細については後述）。
の２つの手続きを経由して承認ルートのデータベースを参照する。購買伝票本体を参照するときには購買伝票API、購買伝票本体操作の２つの手続きを経由して購買伝票本体のデ
ータベースを参照する。品目情報を参照するときには購買伝票API、品目情報操作の２つ
の手続きを経由して品目情報のデータベースをアクセスする。
（標準アクセスシーケンス生成装置）
標準アクセスシーケンス生成装置Ｍ２は、記憶装置からデータ仕様データ相関Ｄ２１を読み込み、そのデータ仕様データ相関Ｄ２１に基づいて、後述の処理（図１０参照）を実行することにより、標準アクセスシーケンスＤ２２を生成する。
（データ仕様データ相関）
図７は、データ相関図の例を説明するための図である。ここでは、説明の便宜上、図２に示した各データベースとは異なる複数のデータベースを取り上げて説明する。このデータ相関図は、複数のデータベースに対する標準的なアクセス順序を決定するために、複数のデータベース相互間の対応関係を可視的に表したものである。なお、この対応関係を表す対応関係データの例については図８、及び図９に示している（詳細については後述）。
図７では複数のデータベースとして８つのテーブル、即ち購買伝票本体テーブル、発注品目情報テーブル、購買申請者情報テーブル、販売担当者情報テーブル、商品情報テーブル、価格情報テーブル、購買企業情報テーブル、及び販売企業情報テーブルを示している。
これらテーブル相互間の対応関係は、２つのテーブルを結ぶ矢印によって示される。即ち、矢印の先端で指されたカラムが、その矢印の基端のカラムよりも後にアクセスするカラムになる。例えば、購買伝票本体テーブルのslipID(Primary Key)が基端、かつ、発注
品目情報テーブルのslipIDが先端の矢印により、両テーブルは結ばれている。これは、矢印の先端で指された発注品目情報テーブルのslipIDが、その矢印の基端の購買伝票本体テーブルのslipID(Primary Key)よりも後にアクセスされることを意味する。即ち、購買伝
票本体と発注品目情報では、購買伝票本体のslipID(Primary Key)を取得し、発注品目情
報テーブルに対して矢印の先端が指すslipIDが購買伝票本体のslipIDと同じ、という条件での検索を行う。
品目情報テーブルのslipIDが先端の矢印により、両テーブルは結ばれている。これは、矢印の先端で指された発注品目情報テーブルのslipIDが、その矢印の基端の購買伝票本体テーブルのslipID(Primary Key)よりも後にアクセスされることを意味する。即ち、購買伝
票本体と発注品目情報では、購買伝票本体のslipID(Primary Key)を取得し、発注品目情
報テーブルに対して矢印の先端が指すslipIDが購買伝票本体のslipIDと同じ、という条件での検索を行う。
また、テーブル相互間の対応関係としては、次のようなものもある。図７を参照すると、発注品目情報テーブルのカラムslipidは購買伝票本体テーブルのカラムslipid(プライ
マリキー)の値を持ち、発注品目情報と購買依頼伝票の対応関係はN:1となっている(１件
の購買依頼伝票に対してN件の発注品目情報が対応する)。同様に、価格情報テーブルのproductIdは商品情報のプライマリキーidの値であり、価格情報と商品情報の対応関係はN:1となっている(１件の商品情報に対してN件の価格情報が対応)。また、発注品目情報のproductIdは商品情報のidの値で、発注品目情報と商品情報の対応は1:1(１件の発注品目情報に対し、１件の商品情報が対応)となっている。これらＮ：１や１：１も、テーブル相互
間の対応関係を表すためのものである。
マリキー)の値を持ち、発注品目情報と購買依頼伝票の対応関係は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＿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を一つづつ順に取り出す（Ｓ４０１：Ｎｏ、Ｓ４０２）。なお、全てのデータアクセスＡｒを取り出した場合は処理を終了する（Ｓ４０１：Ｙｅｓ）。
デッドロック事前検出装置Ｍ３は、ある一つの処理ルートRに対して既に出現済のデー
タアクセスを格納する格納庫Sを空にする（Ｓ４００）。デッドロック事前検出装置Ｍ３
は、その処理ルートＲの中のデータアクセスArを一つづつ順に取り出す（Ｓ４０１：Ｎｏ、Ｓ４０２）。なお、全てのデータアクセスＡｒを取り出した場合は処理を終了する（Ｓ４０１：Ｙｅｓ）。
次に、デッドロック事前検出装置Ｍ３は、格納庫Sに、既に取出し済のデータアクセス
Ａｒがあるか否かを判定する（Ｓ４０３）。その結果、データアクセスＡｒがない場合（Ｓ４０３：Ｎｏ）には、格納庫SにデータアクセスArを格納（追加）し、Ｓ４０１に戻る
（Ｓ４０４）。
Ａｒがあるか否かを判定する（Ｓ４０３）。その結果、データアクセスＡｒがない場合（Ｓ４０３：Ｎｏ）には、格納庫SにデータアクセスArを格納（追加）し、Ｓ４０１に戻る
（Ｓ４０４）。
一方、Ｓ４０３の判定の結果、既に取出し済のデータアクセスＡｒがある場合には（Ｓ４０３：Ｙｅｓ）、格納庫Sからチェック対象のデータアクセスAsを読み出して（Ｓ４０
６）、標準のデータアクセス順序を参照して、データアクセスArがデータアクセスAsより先か否かを判定する（Ｓ４０７）。その結果、データアクセスArがデータアクセスAsより
先であれば（Ｓ４０７：Ｙｅｓ）、デッドロック事前検出装置Ｍ３は、データアクセスArがデータアクセスAsより先に実行されているという警告を作成する（Ｓ４０８）。
６）、標準のデータアクセス順序を参照して、データアクセスArがデータアクセスAsより先か否かを判定する（Ｓ４０７）。その結果、データアクセスArがデータアクセスAsより
先であれば（Ｓ４０７：Ｙｅｓ）、デッドロック事前検出装置Ｍ３は、データアクセスArがデータアクセスAsより先に実行されているという警告を作成する（Ｓ４０８）。
そして、デッドロック事前検出装置は、その旨の警告が既に出力済か否かを判定（例えば後述のフラグに基づく判定）し（Ｓ４０９）、その結果、出力済でなければ（Ｓ４０９：Ｎｏ）その旨の警告を出力して（Ｓ４１０）、その警告は出力済であることを示すフラグをセットする（Ｓ４１１）。
なお、警告の出力形態としては各種のものが考えられるが、ここでは、図１３に示すように、ログ（例えばログファイル）として出力（報知）される。以上のＳ４０６〜Ｓ４１１の処理は、格納庫Sに格納されている全てのデータアクセスAsに対して行われる（Ｓ４
０５）。全てのデータアクセスＡｓに対する処理が完了すると（Ｓ４０５：Ｙｅｓ）、デッドロック事前検出装置Ｍ３は、格納庫SにデータアクセスArを格納（追加）し、Ｓ４０
１に戻る（Ｓ４０４）。
０５）。全てのデータアクセスＡｓに対する処理が完了すると（Ｓ４０５：Ｙｅｓ）、デッドロック事前検出装置Ｍ３は、格納庫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)の順になっている。
用者の種別が購買管理者の場合の処理ルート」では、(1)承認フロー取得(Read)、(2)購買依頼伝票検索(Read)、(3)発注品目情報検索(Read)、(4)商品情報取得(Read)、(5)価格情
報検索(Read)、(6)承認履歴情報検索(Read)、(7)購買依頼伝票更新(Write)、(8)承認履歴情報更新(Write)の順になっている。
標準的なテーブルのアクセス順序と比較すると、承認フロー情報が、購買伝票情報、品目情報、商品情報、価格情報の４つのテーブルより前にアクセスされるようになっているところが異なる。従って警告では承認フロー情報と、これら４つのテーブルのアクセス順序が標準のテーブルアクセス順序と異なることに対してそれぞれ警告を出している。
（多重アクセス時デッドロック事前検出装置）
多重アクセス時デッドロック事前検出装置Ｍ４は、各ルートの処理シーケンスＤ１２、及び多重アクセス操作系列記述Ｄ１１に基づいて、後述の処理（図１６）を実行することにより、多重アクセスデッドロック可能性情報Ｄ４を生成する。
（多重アクセス記述）
図１４は、多重アクセス記述、即ち業務ロジックの実行順序、及び同時実行される業務ロジックの実行系列を表現する情報の例である。
（多重アクセス時デッドロック事前検出装置）
多重アクセス時デッドロック事前検出装置Ｍ４は、各ルートの処理シーケンスＤ１２、及び多重アクセス操作系列記述Ｄ１１に基づいて、後述の処理（図１６）を実行することにより、多重アクセスデッドロック可能性情報Ｄ４を生成する。
（多重アクセス記述）
図１４は、多重アクセス記述、即ち業務ロジックの実行順序、及び同時実行される業務ロジックの実行系列を表現する情報の例である。
図１４において、操作系列T1は以下の業務ロジックを以下の順序で実行する。(1)販売
支援でログインする。(2)見積・受注メニューを選択する。(3)見積回答を選択する。(4)
見積伝票一覧表示を選択する。(5)一覧表示の中から１つ、見積依頼伝票を選択する。(6)選択した見積依頼伝票に対して見積回答を実行する。(7)販売支援からログアウトする。
支援でログインする。(2)見積・受注メニューを選択する。(3)見積回答を選択する。(4)
見積伝票一覧表示を選択する。(5)一覧表示の中から１つ、見積依頼伝票を選択する。(6)選択した見積依頼伝票に対して見積回答を実行する。(7)販売支援からログアウトする。
以上にあげた業務ロジックのうち、実際にデータベースに対してアクセスを行うのは(1), (4), (5), (6), (7)である。(2)、(3)は画面遷移のみの実行で、データベースに対し
てアクセスは行わない。従って、これから述べるデッドロックチェックでは(2)、(3)はチェックの対象外となる。
てアクセスは行わない。従って、これから述べるデッドロックチェックでは(2)、(3)はチェックの対象外となる。
また、(4)の見積伝票一覧表示では、以下の４通りのルートが存在する。
ルートA001：利用者が特定の購買企業を担当し、任意のカテゴリの商品を取り扱う。データアクセス順序は、販売担当情報→見積依頼伝票→見積依頼品目情報の順である。ルートA002：利用者が全購買企業を担当し、任意のカテゴリの商品を取り扱う。
ルートA001：利用者が特定の購買企業を担当し、任意のカテゴリの商品を取り扱う。データアクセス順序は、販売担当情報→見積依頼伝票→見積依頼品目情報の順である。ルートA002：利用者が全購買企業を担当し、任意のカテゴリの商品を取り扱う。
データアクセス順序は、見積依頼伝票→見積依頼品目情報の順である。
ルートA003：利用者が特定の購買企業を担当し、特定のカテゴリの商品を取り扱う。データアクセス順序は、販売担当情報→見積依頼伝票→見積依頼品目情報→商品情報の順である。
ルート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においてデッドロック発生の可能性が出る。
において、処理ルート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に含
まれるデータアクセスでデッドロックの可能性があると判断し、デッドロックの可能性を警告するメッセージを出力する（既に出力済かどうかをチェックして、出力済でなければ出力する）。
(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)各操作系列(または業務ロジック、業務ロジックの中の処理ルート)に対して発生頻
度情報(単位時間あたりの発生数)を持たせる。発生頻度が一定の閾値以下であればその操作系列(または、業務ロジック、業務ロジックの中の処理ルート)はチェックの対象からはずす。
(A)各操作系列(または業務ロジック、業務ロジックの中の処理ルート)に対して発生頻
度情報(単位時間あたりの発生数)を持たせる。発生頻度が一定の閾値以下であればその操作系列(または、業務ロジック、業務ロジックの中の処理ルート)はチェックの対象からはずす。
(B)発生頻度情報がない場合、データテーブルに対してデッドロックのチェックを行う/行わないのフラグ情報を設定し、データアクセスの対に対してデッドロックのチェックを行うときに、対象となるテーブルがいずれもデッドロックを行うフラグがONになっている
場合のみチェックを行う。
場合のみチェックを行う。
以上述べたように、本実施形態のデッドロック防止システム（プログラム）によれば、次の効果を奏する。
(1) 業務システムの保守性向上 データアクセス処理系列を、全ての業務ロジックで遵守することにより業務システムを構成する業務ロジックの作りを統一することができる。業務ロジックの作りが統一されることにより、業務ロジックを記述するプログラムの見通しが良くなる。すなわち業務システム全体としての保守性が向上する。
(1) 業務システムの保守性向上 データアクセス処理系列を、全ての業務ロジックで遵守することにより業務システムを構成する業務ロジックの作りを統一することができる。業務ロジックの作りが統一されることにより、業務ロジックを記述するプログラムの見通しが良くなる。すなわち業務システム全体としての保守性が向上する。
(2) 業務システムの品質確保 多重アクセス環境下で使用される業務システムにおいて、デッドロックの可能性を設計段階で網羅的に検出し、設計段階で業務システム全体にわたって、発生の可能性があるデッドロックをすべた洗い出し、洗い出したデッドロックに対する防止策をとることができる。したがって、設計段階でデッドロック防止に関する品質の作りこみを可能にする。
(3) 業務システム開発期間の短縮 テスト段階でデッドロックを逐一見つけて対策をとる方式にくらべて作業の手戻りを少なくすることができる。このため、設計から開発、テストを含めた業務システムの開発期間を2/3〜1/2近くまで短縮することができる。
本発明は、以下の分野にも適用可能である。
複数のデータ集合体から構成されるデータ格納庫を利用して業務処理を実行する装置において、複数の業務処理が同時に同じデータをアクセスすることによる資源競合(デッド
ロック)を運用前の設計段階で事前に検出するために適用される。
複数のデータ集合体から構成されるデータ格納庫を利用して業務処理を実行する装置において、複数の業務処理が同時に同じデータをアクセスすることによる資源競合(デッド
ロック)を運用前の設計段階で事前に検出するために適用される。
データ格納庫の例としては、関係データベース(データ集合体がテーブル、各データが
レコード)やオブジェクト指向データベース(データ集合体がオブジェクトの集まり、各データがオブジェクトと呼ばれるデータ構造)が考えられる。装置の例としては、電子商取
引システムや会計システム、取引情報管理システム、電子カタログ管理システムなどが考えられる。
レコード)やオブジェクト指向データベース(データ集合体がオブジェクトの集まり、各データがオブジェクトと呼ばれるデータ構造)が考えられる。装置の例としては、電子商取
引システムや会計システム、取引情報管理システム、電子カタログ管理システムなどが考えられる。
電子商取引システムの場合、データ集合体としてたとえば利用者情報、企業情報、見積依頼伝票、購買依頼伝票、購入実績情報、商品情報、価格情報などのテーブルを持つ。これらのデータをアクセスする業務ロジックとしては見積依頼や購買依頼伝票の発行、見積依頼や購買依頼伝票に対する承認、見積回答や受注回答などが挙げられる。
本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施することができる。このため、上記の実施形態は、あらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。
本発明によれば、デッドロック検出対象のプログラムを実際に動作させることなく、事前にデッドロックの可能性を検出することが可能となる。また、そのように検出されたデッドロック可能性回避のための方策等について利用者に対して報知することにより、デッドロック可能性回避のための方策等を採ることが可能となる。
Ｍ１ 処理シーケンス生成装置
Ｍ２ 標準アクセスシーケンス生成装置
Ｍ３ デッドロック事前検出装置
Ｍ４ 多重アクセス時デッドロック事前検出装置
Ｄ１１ 業務ロジック設計情報
Ｄ１２ 処理シーケンス
Ｄ２１ データ仕様データ相関
Ｄ２２ 標準アクセスシーケンス
Ｄ３ 逸脱情報
Ｄ４ 多重アクセスデッドロック可能性情報
Ｍ２ 標準アクセスシーケンス生成装置
Ｍ３ デッドロック事前検出装置
Ｍ４ 多重アクセス時デッドロック事前検出装置
Ｄ１１ 業務ロジック設計情報
Ｄ１２ 処理シーケンス
Ｄ２１ データ仕様データ相関
Ｄ２２ 標準アクセスシーケンス
Ｄ３ 逸脱情報
Ｄ４ 多重アクセスデッドロック可能性情報
Claims (5)
- コンピュータに、
複数のデータベースのうちのいずれかへのアクセスを伴うアクセスステップを含む複数の処理ステップにより構成される業務ロジック設計情報を読み込ませる第１手順、
前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される処理ルートを生成する第２手順、
前記処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得する第３手順、
前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する第４手順、
前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、予め定められたアクセス順序から逸脱した旨を報知する第５手順、
を実行させるためのデッドロック事前検出プログラム。 - 前記業務ロジック設計情報は、前記アクセスステップ及び分岐条件ステップを含む複数の処理ステップにより構成され、
前記第２手順は、前記業務ロジック設計情報に基づいて、少なくとも２つのアクセスステップにより構成される少なくとも２つの処理ルートを生成し、
前記第３手順は、各処理ルートごとに、その処理ルートから、第１アクセスステップ、及び第２アクセスステップを取得し、
前記第４手順は、各処理ルートごとに、前記第１及び第２アクセスステップによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定する、
請求項１に記載のデッドロック事前検出プログラム。 - 前記複数のデータベース相互間の対応関係を表す対応関係データを読み込ませる第６手順、
前記対応関係データに基づいて、前記予め定められたアクセス順序を生成する第７手順、
をさらに備える、
請求項１に記載のデッドロック事前検出プログラム。 - 前記第３手順は、前記処理ルートから、第１アクセスステップ、及び該第１アクセスステップの次の第２アクセスステップを取得し、
前記第４手順は、前記第１及び第２アクセスステップそれぞれによるデータベースへのアクセス順序が予め定められたアクセス順序か否かを判定し、
前記第５手順は、前記アクセス順序が予め定められたアクセス順序でないと判定された場合に、前記第１アクセスステップによるデータベースへのアクセスが、前記第２アクセスステップによるデータベースへのアクセスよりも先に行われている旨を報知する、
請求項１に記載のデッドロック事前検出プログラム。 - 多重アクセス記述と前記処理ルートを読み込ませる第８手順、
前記多重アクセス記述と処理ルートに基づいて、前記複数の処理ステップにより構成される業務ロジックを同時実行する場合に、デッドロックが発生する可能性の情報を生成する第９手順、
をさらに備える、
請求項１に記載のデッドロック事前検出プログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003358268A JP2005122560A (ja) | 2003-10-17 | 2003-10-17 | デッドロック事前検出プログラム |
| US10/800,612 US7519965B2 (en) | 2003-10-17 | 2004-03-15 | Computer-readable medium recorded with a deadlock pre-detection program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003358268A JP2005122560A (ja) | 2003-10-17 | 2003-10-17 | デッドロック事前検出プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005122560A true JP2005122560A (ja) | 2005-05-12 |
Family
ID=34509850
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003358268A Pending JP2005122560A (ja) | 2003-10-17 | 2003-10-17 | デッドロック事前検出プログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7519965B2 (ja) |
| JP (1) | JP2005122560A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008282165A (ja) * | 2007-05-09 | 2008-11-20 | Toshiba Mitsubishi-Electric Industrial System Corp | バッチ制御装置及びバッチ制御方法 |
| JP2009032197A (ja) * | 2007-07-30 | 2009-02-12 | Fujitsu Microelectronics Ltd | ソフトウェアのシミュレーション方法、ソフトウェアのシミュレーションのためのプログラム、及びソフトウェアのシミュレーション装置 |
| CN101425070B (zh) * | 2008-08-11 | 2011-04-20 | 深圳市金蝶中间件有限公司 | 一种死锁定位的方法、死锁定位装置和数据系统 |
| US8001098B2 (en) | 2006-12-26 | 2011-08-16 | International Business Machines Corporation | Database update management |
| JP2014167674A (ja) * | 2013-02-28 | 2014-09-11 | Ntt Data Corp | データベースアクセス検証方法、データベースアクセス検証装置、及びプログラム |
| CN112363846A (zh) * | 2021-01-11 | 2021-02-12 | 北京金山云网络技术有限公司 | 数据库事务的死锁检测方法、装置及电子设备 |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7410899B2 (en) * | 2005-09-20 | 2008-08-12 | Enthone, Inc. | Defectivity and process control of electroless deposition in microelectronics applications |
| US8060880B2 (en) * | 2007-05-04 | 2011-11-15 | Microsoft Corporation | System using backward inter-procedural analysis for determining alternative coarser grained lock when finer grained locks exceeding threshold |
| US8375367B2 (en) * | 2009-08-06 | 2013-02-12 | International Business Machines Corporation | Tracking database deadlock |
| US20110067007A1 (en) * | 2009-09-14 | 2011-03-17 | Red Hat, Inc. | Automatic thread dumping |
| CN102053861B (zh) * | 2009-10-30 | 2014-03-12 | 国际商业机器公司 | 并行程序中死锁检测的方法和系统 |
| US8769496B2 (en) * | 2010-08-13 | 2014-07-01 | Accenture Global Services Limited | Systems and methods for handling database deadlocks induced by database-centric applications |
| US10528400B2 (en) * | 2017-06-05 | 2020-01-07 | International Business Machines Corporation | Detecting deadlock in a cluster environment using big data analytics |
| CN111090528B (zh) * | 2019-12-25 | 2023-09-26 | 北京天融信网络安全技术有限公司 | 死锁确定方法、装置及电子设备 |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0814800B2 (ja) | 1987-09-11 | 1996-02-14 | 株式会社日立製作所 | データベース排他制御方法 |
| JPH0594290A (ja) | 1991-09-30 | 1993-04-16 | Shimadzu Corp | データフロー図検証装置 |
| JPH06103091A (ja) | 1992-09-18 | 1994-04-15 | Hitachi Ltd | 並列排他制御命令翻訳方法及びその装置とデータ処理装置 |
| US5694539A (en) * | 1994-08-10 | 1997-12-02 | Intrinsa Corporation | Computer process resource modelling method and apparatus |
| GB9424699D0 (en) * | 1994-12-07 | 1995-02-01 | Int Computers Ltd | Deadlock detection mechanism |
| US6601048B1 (en) * | 1997-09-12 | 2003-07-29 | Mci Communications Corporation | System and method for detecting and managing fraud |
| US5668988A (en) * | 1995-09-08 | 1997-09-16 | International Business Machines Corporation | Method for mining path traversal patterns in a web environment by converting an original log sequence into a set of traversal sub-sequences |
| US5742811A (en) * | 1995-10-10 | 1998-04-21 | International Business Machines Corporation | Method and system for mining generalized sequential patterns in a large database |
| US6029002A (en) * | 1995-10-31 | 2000-02-22 | Peritus Software Services, Inc. | Method and apparatus for analyzing computer code using weakest precondition |
| JPH09233150A (ja) | 1996-02-27 | 1997-09-05 | Toshiba Corp | シーケンスチャート作成装置 |
| JPH1049389A (ja) | 1996-08-07 | 1998-02-20 | Casio Comput Co Ltd | プログラム管理装置 |
| JPH10228387A (ja) | 1997-02-14 | 1998-08-25 | Hitachi Ltd | 仕様検証方式 |
| CA2220612C (en) * | 1997-11-03 | 2001-04-24 | Ibm Canada Limited-Ibm Canada Limitee | Method and apparatus for inter-node deadlock avoidance on a parallel processing system |
| JPH11259350A (ja) * | 1998-03-09 | 1999-09-24 | Kokusai Zunou Sangyo Kk | デッドロックを事前検知可能なデータベース管理システム |
| US6581052B1 (en) * | 1998-05-14 | 2003-06-17 | Microsoft Corporation | Test generator for database management systems |
| US6138112A (en) * | 1998-05-14 | 2000-10-24 | Microsoft Corporation | Test generator for database management systems |
| JP2000222228A (ja) | 1999-01-29 | 2000-08-11 | Hitachi Ltd | リソース占有順序の検証によるデッドロック防止方法 |
| US6816874B1 (en) * | 1999-09-10 | 2004-11-09 | International Business Machines Corporation | Method, system, and program for accessing performance data |
| US7475405B2 (en) * | 2000-09-06 | 2009-01-06 | International Business Machines Corporation | Method and system for detecting unusual events and application thereof in computer intrusion detection |
| US20030041315A1 (en) * | 2001-08-21 | 2003-02-27 | International Business Machines Corporation | Debugger with automatic detection of control points influencing program behavior |
| US7194475B2 (en) * | 2001-10-30 | 2007-03-20 | International Business Machines Corporation | Method, system, and program for performing an impact analysis of program statements in at least one source code file |
-
2003
- 2003-10-17 JP JP2003358268A patent/JP2005122560A/ja active Pending
-
2004
- 2004-03-15 US US10/800,612 patent/US7519965B2/en not_active Expired - Fee Related
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8001098B2 (en) | 2006-12-26 | 2011-08-16 | International Business Machines Corporation | Database update management |
| JP2008282165A (ja) * | 2007-05-09 | 2008-11-20 | Toshiba Mitsubishi-Electric Industrial System Corp | バッチ制御装置及びバッチ制御方法 |
| JP2009032197A (ja) * | 2007-07-30 | 2009-02-12 | Fujitsu Microelectronics Ltd | ソフトウェアのシミュレーション方法、ソフトウェアのシミュレーションのためのプログラム、及びソフトウェアのシミュレーション装置 |
| CN101425070B (zh) * | 2008-08-11 | 2011-04-20 | 深圳市金蝶中间件有限公司 | 一种死锁定位的方法、死锁定位装置和数据系统 |
| JP2014167674A (ja) * | 2013-02-28 | 2014-09-11 | Ntt Data Corp | データベースアクセス検証方法、データベースアクセス検証装置、及びプログラム |
| CN112363846A (zh) * | 2021-01-11 | 2021-02-12 | 北京金山云网络技术有限公司 | 数据库事务的死锁检测方法、装置及电子设备 |
| CN112363846B (zh) * | 2021-01-11 | 2021-04-13 | 北京金山云网络技术有限公司 | 数据库事务的死锁检测方法、装置及电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| US7519965B2 (en) | 2009-04-14 |
| US20050086031A1 (en) | 2005-04-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Henard et al. | Bypassing the combinatorial explosion: Using similarity to generate and prioritize t-wise test configurations for software product lines | |
| US11106626B2 (en) | Managing changes to one or more files via linked mapping records | |
| Chen et al. | Detecting performance anti-patterns for applications developed using object-relational mapping | |
| US9672578B2 (en) | Catalog-based software license reconciliation | |
| Küster et al. | Detecting and resolving process model differences in the absence of a change log | |
| US7328428B2 (en) | System and method for generating data validation rules | |
| US8060532B2 (en) | Determining suitability of entity to provide products or services based on factors of acquisition context | |
| US20160357663A1 (en) | Software defect reporting | |
| US9836389B2 (en) | Test data generation utilizing analytics | |
| US10360603B2 (en) | Creation and use of constraint templates | |
| JP2005122560A (ja) | デッドロック事前検出プログラム | |
| JP2017514218A (ja) | サードパーティアプリケーションの実行 | |
| US20160162539A1 (en) | Computer executable method of generating analysis data and apparatus performing the same and storage medium for the same | |
| Molka et al. | Conformance checking for BPMN-based process models | |
| US20100161676A1 (en) | Lifecycle management and consistency checking of object models using application platform tools | |
| JP2007079705A (ja) | 部材属性情報の不正抽出方法、およびオブジェクト属性情報の不正抽出システム | |
| CN116594683A (zh) | 一种代码注释信息生成方法、装置、设备及存储介质 | |
| US20130060546A1 (en) | Visual modeling language for requirements engineering | |
| US10241899B2 (en) | Test input information search device and method | |
| JP6120607B2 (ja) | 要件検出装置及び要件検出プログラム | |
| García-García et al. | NDT-merge: a future tool for conciliating software requirements in MDE environments | |
| Corea et al. | A taxonomy of business rule organizing approaches in regard to business process compliance | |
| US8825609B2 (en) | Detecting wasteful data collection | |
| JP2018028776A (ja) | ソフトウェア資産管理装置、ソフトウェア資産管理方法、および、ソフトウェア資産管理プログラム | |
| Dautovic et al. | Automated quality defect detection in software development documents |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050413 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071225 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080527 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080728 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090106 |