(57)【要約】【課題】プログラム開発におけるデバッグ作業を効率的に行うこと支援する。【解決手段】異常動作時のログとプログラムのソースコード変更履歴より、優先度の高い関数を選択し、あらかじめ定めたデバッグ対象特定ルールに基づいてその関数に関係する関数の優先度を求めて、それら関数とその関数の優先順位を示したデバッグ対象候補リストを作成し、デバッグ作業においてデバッグ対象候補リストを参照してデバッグ対象の絞り込みを行ってデバッグ作業を効率的に行うことを支援する。【選択図】図１
2009104252.tif 000002
【特許請求の範囲】
【請求項１】
プログラムの構成要素単位を指定できるプログラム言語で記述したプログラムのデバッグ支援装置であって、
前記プログラムの異常動作時の実行履歴を前記構成要素単位の情報を含むデバッグ情報とともに記憶する実行ログ記憶手段と、
前記プログラムのソースコードが記憶されるソースコード記憶手段と、
前記ソースコードの変更履歴を記憶するソースコードの変更履歴記憶手段と、
前記実行ログ記憶手段に記憶された実行ログの前記構成要素単位で、前記ソースコード記憶手段と前記ソースコードの変更履歴記憶手段から一番最近に変更された構成要素単位を選択するバージョン解析手段と、
デバッグ対象特定ルールを記憶するデバッグ対象特定ルール記憶手段と、
前記バージョン解析手段で選択された前記構成要素単位と、当該構成要素単位の前記デバッグ対象特定ルールに基づいて追加選択された構成要素単位とに対して、前記デバッグ対象特定ルールに基づき前記構成要素単位の優先度を求め、その優先度に基づいて前記構成要素単位の優先順位を定めて、前記構成要素単位とその構成要素単位の前記優先順位を含むデバッグ対象箇所候補リストを作成するデバッグ対象特定手段と
を有することを特徴とするデバッグ支援装置。
【請求項２】
前記ソースコードの前記構成要素単位が関数であることを特徴とする請求項１に記載のデバッグ支援装置。
【請求項３】
前記デバッグ対象特定ルールが編集可能であることを特徴とする請求項１に記載のデバッグ支援装置。
【請求項４】
プログラムの構成要素単位を指定できるプログラム言語で記述したプログラムのデバッグ支援方法であって、
前記プログラムの異常動作時の実行履歴を構成要素単位の情報を含むデバッグ情報とともに実行ログとして記憶するステップと、
前記プログラムのソースコードを記憶するステップと、
前記ソースコードの変更履歴を記憶するステップと、
前記実行ログに含まれる前記構成要素単位で、前記ソースコードと前記ソースコードの変更履歴から一番最近に変更された構成要素単位を選択するステップと、
デバッグ対象特定ルールを記憶するステップと、
前記選択された構成要素単位と、当該構成要素単位の前記デバッグ対象特定ルールに基づいて追加選択された構成要素単位とに対して、前記デバッグ対象特定ルールに基づき前記構成要素単位の優先度を求め、その優先度に基づいて前記構成要素単位の優先順位を定めて、前記構成要素単位とその構成要素単位の前記優先順位を含むデバッグ対象箇所候補リストを作成するステップと
を有することを特徴とするデバッグ支援方法。
【請求項５】
前記ソースコードの前記構成要素単位が関数であることを特徴とする請求項４に記載のデバッグ支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアのデバッグ支援装置およびデバッグ支援方法に係り、特にソフトウェアの修正時におけるデバッグ支援装置およびデバッグ支援方法に関する。
【背景技術】
【０００２】
近年、システムの機能変更を当該システムのコンピュータ上で稼動するプログラムの修正で実現されることが多く、またそのプログラムの修正作業に要する時間の短縮が求められている。
【０００３】
例えば、プログラムのソースコードに変更を加えたことで動作に不具合（異常動作）が生じた場合に、ソースコードの変更履歴を記録し管理するＣＶＳ（Concurrent Versions System）などの構成管理ツールを利用することで、正常に動作していた状態のソースコードまで遡り、異常動作時のソースコードと、正常動作時のソースコードとの差分を抽出してデバッグ作業を支援することができるものがある。この場合、従来では差異がある箇所全てがデバッグ対象範囲となるので、そのデバッグ対象中には動作上問題が無かった箇所や、実行されなかった箇所が含まれることになるので、デバッグ作業の効率が悪い問題があった。
【０００４】
また、プログラム実行時に、ソースコードがどのような順序で実行されたか分かるように、実行パスをログに記録して、正常動作時のログと異常動作時のログを比較することで差異がある箇所をデバッグ対象範囲とするものがある。この場合、異常動作時の不具合がさまざまな箇所に影響をおよぼし、例えば、不具合が含まれない部分の実行パスまで変化してログに記録されてしまうため、ログの差異から不具合箇所を特定するのは困難であった。
【０００５】
また、ユーザが指定した注目箇所に関係する箇所についてのみログを記録するようにし、そのログを使用することでデバッグ作業を効率よく支援する技術が提案されている（例えば、特許文献１参照。）。
【特許文献１】特開２０００−２０７２４６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１の発明のように、ユーザが指定した注目箇所に関係する箇所についてのみ実行過程を記録してデバッグで使用する情報を減らしてデバッグ作業を支援する方法は、ユーザの思い込みなどによって注目箇所の指定を誤ると正しい検査ができなくなり、注目箇所の指定が難しい問題がある。
【０００７】
本発明は、上記問題を解決するためになされたもので、異常動作時のログと、ソースコードの変更情報から異常動作との関連性の高さを判定するルールを適用してデバッグ対象範囲を自動的に絞り込むことでデバッグ作業の効率向上を実現するデバッグ支援装置およびデバッグ支援方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明のデバッグ支援装置は、プログラムの構成要素単位を指定できるプログラム言語で記述したプログラムのデバッグ支援装置であって、前記プログラムの異常動作時の実行履歴を前記構成要素単位の情報を含むデバッグ情報とともに記憶する実行ログ記憶手段と、前記プログラムのソースコードが記憶されるソースコード記憶手段と、前記ソースコードの変更履歴を記憶するソースコードの変更履歴記憶手段と、前記実行ログ記憶手段に記憶された実行ログの前記構成要素単位で、前記ソースコード記憶手段と前記ソースコードの変更履歴記憶手段から一番最近に変更された構成要素単位を選択するバージョン解析手段と、デバッグ対象特定ルールを記憶するデバッグ対象特定ルール記憶手段と、前記バージョン解析手段で選択された前記構成要素単位と、当該構成要素単位の前記デバッグ対象特定ルールに基づいて追加選択された構成要素単位とに対して、前記デバッグ対象特定ルールに基づき前記構成要素単位の優先度を求め、その優先度に基づいて前記構成要素単位の優先順位を定めて、前記構成要素単位とその構成要素単位の前記優先順位を含むデバッグ対象箇所候補リストを作成するデバッグ対象特定手段とを有することを特徴とする。
【０００９】
また、本発明のデバッグ支援方法は、プログラムの構成要素単位を指定できるプログラム言語で記述したプログラムのデバッグ支援方法であって、前記プログラムの異常動作時の実行履歴を構成要素単位の情報を含むデバッグ情報とともに実行ログとして記憶するステップと、前記プログラムのソースコードを記憶するステップと、前記ソースコードの変更履歴を記憶するステップと、前記実行ログに含まれる前記構成要素単位で、前記ソースコードと前記ソースコードの変更履歴から一番最近に変更された構成要素単位を選択するステップと、デバッグ対象特定ルールを記憶するステップと、前記選択された構成要素単位と、当該構成要素単位の前記デバッグ対象特定ルールに基づいて追加選択された構成要素単位とに対して、前記デバッグ対象特定ルールに基づき前記構成要素単位の優先度を求め、その優先度に基づいて前記構成要素単位の優先順位を定めて、前記構成要素単位とその構成要素単位の前記優先順位を含むデバッグ対象箇所候補リストを作成するステップとを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、プログラムの不具合原因の候補関数とその関数の優先順位を示したデバッグ対象箇所候補リストとが自動的に作成され、そのデバッグ対象箇所候補リストを参照してデバッグ対象箇所の漏れの無い絞り込みが行えるので、デバッグ作業を効率的に進めることができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施例を説明する。
【実施例】
【００１２】
本発明に係るソフトウェアのデバッグ支援装置およびデバッグ支援方法の実施例を、図１乃至図１４を参照して説明する。
【００１３】
図１は、実施例のデバッグ支援機能を有するソフトウェア開発システムのシステム構成図である。図２乃至図５は、デバッグ対象のソースプログラムのリストである。図６乃至図１１は、デバッグ支援装置で参照および生成されるファイルのデータ構成を示す図である。図１２は、候補関数を選択する処理手順を示すフローチャートである。図１３は、デバッグ対象箇所を特定する処理手順を示すフローチャートである。図１４は、ソフトウェア開発システムの表示装置の画面の様子である。
【００１４】
ソフトウェア開発システムのシステム構成を、図１を用いて説明する。
【００１５】
ソフトウェア開発システムは計算機を用いて動作するシステムであり、明示しないが通常の計算機システムの有する演算装置や記憶装置および入出力装置が使用される。ソフトウェアのソースプログラム１０は、図示していない編集プログラムで作成編集され、構成管理ツール４０でソースプログラム１０の編集履歴がバージョンで管理される。
【００１６】
編集されたソースプログラム１０は、コンパイラ１１でコンパイルされて実行プログラム１２が生成される。生成された実行プログラム１２は、プログラム実行部１３でシミュレーション動作が実行されて、実行履歴の実行ログ２０がファイル出力される。バージョン解析部３０は、構成管理ツール４０から出力された変更履歴一覧表４１を受け、そしてソースプログラム１０と実行ログ２０とを入力して、デバッグ対象となる候補関数リスト５０（詳細は後述する）を生成して出力する。デバッグ対象特定部６０は、バージョン解析部３０で生成された候補関数リスト５０とデバッグ対象特定ルール７０とソースプログラム１０と変更履歴一覧表４１を受けて、デバッグ対象箇所を抽出して（詳細は後述する）、それに基づくデバッグ対象箇所候補リスト８０を生成して出力する。
【００１７】
本発明のソフトウェア開発システムにあってもソフトウェア開発の基本手順は、通常のソフトウェア開発システムの手順と同様である。すなわち、ソースプログラム１０を作成編集し、編集したソースプログラム１０をコンパイラ１１でコンパイルして、実行プログラム１２を生成する。そして、生成された実行プログラム１２をプログラム実行部１３のシミュレータで実行して実行ログ２０を得る。そして、プログラムの機能を確認し、結果に不具合（バグ）があれば、実行ログ２０を参照して不具合の原因を調べて、ソースプログラム１０を修正編集する手順を実行して、不具合を解消する（デバッグ）。ソフトウェアの所望の機能が実現されるまで、このデバッグ作業が繰り返される。
【００１８】
また、最近ではソフトウェア開発が複数人で行われることなどから、ソースプログラム１０は構成管理ツール４０で管理されている。そして、ソフトウェア開発作業者に対し、構成管理ツール４０からソースプログラムの最新バージョンの組合せが提供されるようになっており、例えば古いバージョンのソースプログラムを誤って用いるような不具合を生じさせない仕組みとなっている。
【００１９】
また、明示していないがこれら一連のデバッグ作業を含む開発作業を統合した環境下で行えるＩＤＥツールプログラム（ＩＤＥ：Ｉｎｔｅｇｒａｔｅｄ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ｅｎｖｉｒｏｎｍｅｎｔ）がソフトウェア開発システムに使用されている。
【００２０】
すなわち、ソフトウェア開発作業者は、ＩＤＥツールのインターフェースを介してソースプログラム１０の編集プログラムによる編集作業、コンパイラ１１によるコンパイル作業、図示していないリンカーによるリンク作業、シミュレータによるシミュレーション作業、およびデバッガプログラムによるデバッグ作業などを行う。このような環境下では、開発するソフトウェアの環境情報（関連ファイル、配置後のメモリアドレス、デバッグの有無など）を設定すれば、個々のプログラムの起動オプション設定作業などが不要になり、設定ミスなどに起因する不具合を減らす仕組みが使用されている。
【００２１】
このような操作ミスによる不具合を減少させる仕組みがソフトウェア開発システムに使用されても、プログラムのアーキテクチャや記述が原因の不具合は解消されず、プログラムの実行結果を解析してデバッグ作業を行うことになる。以下に、このデバッグ作業を支援する本発明のデバッグ支援装置の動作を候補関数の選択とデバッグ対象箇所の選択の２つの処理ステップ（以下、フェーズと記す）に分けて図２乃至図１３を用いて説明する。
【００２２】
なお、本発明のデバッグ支援装置は、不具合が検出された時、デバッグ対象の絞り込みを関数単位としていて、ソースプログラム１０の不具合解析を関数単位で行えるようにしている。これは、本実施例がＣ言語で記述されたソースプログラム１０をデバッグ対象としているためである。Ｃ言語では関数が、ソースプログラムの見通しの良さや可読性を高めるプログラムの階層構造化の単位として用いられている。しかし、デバッグ作業でプログラム解析が行い易い機能単位などでまとめられているプログラム構成要素単位であれば、他の表現のまとまりを使用してもよく、例えばソースプログラム記述言語がアセンブラ言語であればサブルーチン単位としてもよい。
【００２３】
ここで図２乃至図５は、Ｃ言語で記述されたソースプログラムリストで、図２はＦｉｌｅ１．ｃのリストを示し、図３および図４はＦｉｌｅ２．ｃのリストを示し、図５はｇｌｏｂａｌ．ｈのリストを示すものであり、実施例の説明のためのプログラムである。図６は、デバッグ情報を出力するように指定してコンパイルした実行プログラム１２をプログラム実行部１３でシミュレーション動作を実行させて得られた実行ログ２０の一例である。
【００２４】
この図６の実行ログ２０は、全てのステップのデバッグ情報を記録するのではなく、実行プログラム１２を実行した時に、関数を呼び出す（コール）毎に、関数名とその関数定義記述を含むソースプログラム１０の「ファイル名」と、ソースプログラムファイルにおけるその関数定義記述の「先頭行の位置情報」とから構成されるログ情報を記録したもので、図６の上部より下部に向かって実行順に記録されている。例えば、第３行目は、実行プログラム１２の実行開始後に３番目にコールされた関数は、関数名が「Ｓｅａｒｃｈ＿ＭＩＮ」でソースプログラム記述はファイル名「Ｆｉｌｅ２．ｃ」に含まれ、ファイルＦｉｌｅ２．ｃの「３６」行目（図３の３Ａ行）から上記Ｓｅａｒｃｈ＿ＭＩＮの関数定義記述が始まることを示している。なお、この実施例では、関数定義記述の先頭行は、関数や変数の宣言文に続く、関数の実行プログラムのコードに対応するソースプログラム記述の開始行を指す。
【００２５】
図７は、構成管理ツール４０が出力するソースプログラム１０の変更履歴一覧表の一例を示すものである。例えば、図２に示したファイル名「Ｆｉｌｅ１．ｃ」のソースプログラム記述は、バージョン１．０のみが存在していることを示している。また、図３および図４に示したファイル名「Ｆｉｌｅ２．ｃ」のソースプログラム記述は、バージョン１．０〜バージョン１．５までの５つのバージョン（版）が存在し、バージョン１．５が最新バージョンであることを示している。また、図５に示したファイル名「ｇｌｏｂａｌ．ｈ」のソースプログラム記述は、バージョン１．０のみが存在していることを示している。
【００２６】
（第１フェーズ）：
第１フェーズとして、バージョン解析部３０で行われる候補関数選択の処理手順を、図２乃至図９および図１２を用いて説明する。図１２は、バージョン解析部３０による候補関数を選択する処理手順を示すフローチャートである。
【００２７】
最初に、ファイルされた実行ログ２０の先頭（実行順序の一番古いログ情報位置）へのポインタ設定（ｎ＝１）と、バージョン解析部３０内に設けられる関数確認リスト３０ａの初期化と、候補関数リスト５０の初期化が行われる（ステップＳ１００）。
【００２８】
次に、実行ログ２０のｎ（＝１）行目のログ情報を読み込む（ステップＳ１１０）。
【００２９】
次に、読み込まれたログ情報の関数Ｘが、関数確認リスト３０ａに登録済みのものであるか否か調べ（ステップＳ１２０）、登録済みであれば、実行ログ２０から次のログ情報を読み込むためにステップＳ１８０に進み、ポインタｎが１増加させられる。
【００３０】
ステップＳ１２０で読み込まれたログ情報の関数Ｘが関数確認リスト３０ａに登録されていなければ、関数確認リスト３０ａに当該ログ情報の関数Ｘを登録し、その関数定義記述を含むソースプログラム１０の最新バージョンを読み込む（ステップＳ１３０）。
【００３１】
次に、そのソースプログラム１０の変更履歴一覧表４１より、一つ前の古いバージョン（一世代前）の有無を調べ（ステップＳ１４０）、古いバージョンが無ければ関数Ｘの記述変化が無いことを、図８の関数確認リスト３０ａに記録する（ステップＳ１７０）。
【００３２】
一方、ステップＳ１４０で古いバージョンがあった場合、一世代前のソースプログラム１０を読み込み、最新バージョンの関数定義の記述と一世代前のソースプログラム１０における同箇所の関数Ｘの定義記述を比較する（ステップＳ１５０）。その比較において、関数定義の記述が一致すれば関数Ｘの記述変化が無いことを図８の関数確認リスト３０ａに記録する（ステップＳ１７０）。
【００３３】
ステップＳ１５０の比較において、一世代前のバージョンのソースプログラム１０に関数Ｘの定義記述が無いかまたは、関数定義の記述（具体的には、コメント記述などを除いたアルゴリズムに係る記述の部分）が最新バージョンと異なる場合は、関数定義記述の変化有りとし、当該関数とファイル名と関数定義記述のファイルの先頭からの位置とを図９に示す候補関数リスト５０に登録する（ステップＳ１６０）。
【００３４】
次に、関数記述の変化が有ったことを、図８の関数確認リスト３０ａにファイル名と関数定義記述のファイルの先頭からの位置と関数と関数定義の記述の変化「有り」を追加登録する（ステップＳ１７０）。
【００３５】
次に、実行ログ２０の読み込み行数ｎを１増加させる（ステップＳ１８０）。
【００３６】
次に、実行ログ２０の読み込み行数ｎが実行ログの最終行を超えたか否か調べ（ステップＳ１９０）、超えていなければステップＳ１１０に戻り、同じ処理を繰り返し実行する。そして、最終行を超えていれば、第１フェーズの候補関数の選択を終了する。
【００３７】
これにより、不具合が確認された実行ログ２０に記録された関数の中で、最新の編集作業で記述に変更が加えられた関数が、不具合原因の候補関数リスト５０として提供されることになる。
【００３８】
（第２フェーズ）：
次に、第２フェーズとしてデバッグ対象特定部６０で行われるデバッグ対象箇所の選択の処理手順を、図２乃至図７および図９乃至図１１および図１３を用いて説明する。図１３は、デバッグ対象特定部６０によるデバッグ対象箇所を特定する処理手順を示すフローチャートである。
【００３９】
ここで、図１０は、デバッグ対象特定ルール７０の一覧表である。デバッグ対象特定ルール７０は、デバッグ対象箇所を選択するための手順を示すものである。すなわち、「ルール名」で処理対象概要が示されるルール毎に定められた処理手順に従って関連候補関数の追加と、候補関数と追加された関連候補関数を含む全ての関数（デバッグ対象箇所）毎に優先度が与えられて、最終的にデバッグ対象箇所とその優先順位が示される。また、デバッグ対象特定ルール７０は、ルール毎に関連候補関数の追加の有無とその追加方法とデバッグ対象箇所に付与する優先度の値をコントロールできるように構成されていて、デバッグ状況に応じて柔軟にデバッグ対象の絞り込みを制御できる。
【００４０】
デバッグ対象特定部６０は最初に、デバッグ対象特定ルール７０を読み込み、また候補関数リスト５０へのアクセスポインタＰを初期化し（Ｐ＝１）、またデバッグ対象特定部６０内に設けられる仮候補リスト６０ａとデバッグ対象箇所候補リスト８０を初期化する（ステップＳ３００）。
【００４１】
次に、候補関数リスト５０のＰ番目の関数を読み込み、候補関数に設定する。Ｐ＝１の場合は、候補関数として「Ｓｅａｒｃｈ＿ＭＩＮ」が設定される。そして、図１０に示したデバッグ対象特定ルール７０のアクセスポインタQ＝１の１番目ルール「変更された関数」を適用する処理を行う。このルールの第２カラム「デバッグ対象候補として扱う」の記述は、規定値として「Ｙｅｓ」でありルールを適用するので、その候補関数の優先度合計に第４カラムに指定された「１０」を設定する（ステップＳ３１０）。
【００４２】
そして次に、デバッグ対象特定部６０は、その候補関数（Ｐ＝１の場合は、「Ｓｅａｒｃｈ＿ＭＩＮ」）と、その優先度合計「１０」をデバッグ対象箇所候補リスト８０に登録する（ステップＳ３２０）。なお、デバッグ対象箇所候補リスト８０への登録では、当該関数がデバッグ対象箇所候補リスト８０に登録されていなければ、ファイル名と、関数定義記述の先頭行位置と、関数名と、優先度合計とが追加登録される。一方、既にデバッグ対象箇所候補リスト８０に存在する場合は、既に登録されている関数の優先度合計に当該関数の優先度合計が加算され、優先度合計が更新されて登録される。
【００４３】
そして次に、デバッグ対象特定部６０は、デバッグ対象特定ルール７０のアクセスポインタQに「２」を設定する（ステップＳ３３０）。
【００４４】
次に、Q（＝２）番目のデバッグ対象特定ルール７０の第２「デバッグ対象候補として扱う」の記述から、このルールを適用するのか否を調べ（ステップＳ３４０）、ルールを適用しなければステップＳ３８０に進む。
【００４５】
ステップＳ３４０で同ルールを適用するとした場合（Ｙｅｓ）、Ｑ＝２（「変更された関数をコールする関数」）の時、最新バージョンのソースプログラム１０の中から「候補関数をコールする関数」の記述を探索し、候補関数をコールする関数が見つかる毎に、関連関数として仮候補リスト６０ａに登録する。なお、仮候補リスト６０ａへの登録では、既に同じ関数が登録されている時は関連関数として追加されないが、以下に示す関連関数の計算で求められる優先度が加算される。そして、同ルールの第３カラムの「オプション」で探索するコールの深さ（ネスト）が指定されている時は、その深さまで階層構造で記述されたソースプログラム１０を探索する。例えば、ネストの深さ指定が「２」の時は、「候補関数をコールした関連関数をコールした関数」までが関連関数として探索される。そして、ルールの第４カラムの「優先度」で指定されるルールに従って優先度が計算されて、当該関連関数に付与されて仮候補リスト６０ａに登録される（ステップＳ３５０）。例えば、ネストの深さ段数「２」で見出された関数（候補関数をコールした関連関数をコールした関数）の優先度は５／２＝２．５となる。
【００４６】
なお、このステップＳ３５０で、Ｑ＝３（「変更された関数からコールされる関数」）の時は、最新バージョンのソースプログラム１０の候補関数の定義記述でコールする関数記述を探索し、コールする関数が見つかる毎に関連関数として仮候補リスト６０ａに登録する。仮候補リスト６０ａに登録では上述のように、既に同じ関数が登録されている時は関連関数として追加されないが、以下に示す関連関数の計算で求められる優先度が加算される。そして、第３カラムの「オプション」で探索するコールの深さ（ネスト）が指定されている時は、その深さまで階層構造記述されたソースプログラム１０を探索する。そして、第４カラムの「優先度」で指定されるルールに従って関連関数に与えられる優先度が計算されて付与される。
【００４７】
また、このステップＳ３５０で、Ｑ＝４（「変更された関数と同じ共有変数を持つ関数」）の時は、最新バージョンのソースプログラム１０の候補関数の定義記述で使用される共有変数を関数定義において使用している関数を探索して、関連関数として仮候補リスト６０ａに登録する、仮候補リスト６０ａに登録では上述のように、既に同じ関数が登録されている時は関連関数として追加されないが、以下に示す関連関数の計算で求められる優先度が加算される。そして第４カラムの記述にあるようにその関連関数の定義記述で共有する共有変数の数の合計が求められ関連関数の優先度として付与される。
【００４８】
上述のルールの処理は、構文解釈や比較など一般的なソフトウェア処理で実現できるため、詳細のフローチャートの記載を省略している。
【００４９】
次に、仮候補リスト６０ａに登録された関連関数が優先度合計とともに、デバッグ対象候補リストに追加登録される（ステップＳ３６０）。
【００５０】
このデバッグ対象箇所候補リスト８０への関数の追加登録においても、ステップＳ３２０と同様に、既に同じ関数が登録されている時は、関連関数の優先度合計がデバッグ対象箇所候補リスト８０の既に登録された同じ関数の優先度合計に加算される。
【００５１】
次に、関連関数と優先度合計を登録する仮候補リスト６０ａは次のルールの処理で使用できるように、登録内容が消去されて初期化される（ステップＳ３７０）。
【００５２】
そして次に、デバッグ対象特定ルール７０のアクセスポインタＱを１増加させる（ステップＳ３８０）。
【００５３】
次に、Ｑ番目のデバッグ対象特定ルール７０が存在するか調べ（ステップＳ３９０）、存在すればステップＳ３４０に戻り、存在しなければ次のステップに進む。
【００５４】
次に、候補関数リスト５０のアクセスポインタＰを１増加させる（ステップＳ４００）。
【００５５】
次に、候補関数リスト５０のＰ（＝２）番目の候補関数が存在しないか調べ（ステップＳ４１０）、候補関数リスト５０のＰ番目に候補関数が存在する時は、ステップＳ３１０に戻り、候補関数リスト５０の終端で候補関数が存在しない時は、全ての候補関数についての処理が終了したので次のステップに進む。
【００５６】
次にデバッグ対象箇所候補リスト８０の優先度合計の大きなものから優先順位を付与し（ステップＳ４２０）、第２フェーズの処理を終了する。
【００５７】
ここで、図１１は、優先度および優先順位が付与されたデバッグ対象箇所候補リスト８０である。図１１の第１行目の関数「ｍａｉｎ」と第２行目の関数「Ｓｅｔ＿Ｎｕｍｂｅｒｓ」と第５行目の関数「Ｓｅａｒｃｈ＿Ｎｕｍ」を例に各項目の内容について説明する。
【００５８】
関数「ｍａｉｎ」は、Ｆｉｌｅ１．ｃのソースプログラムファイルの７行目（図２の２Ａ行）から関数定義記述が始まり、優先度合計は、デバッグ対象特定ルール２が適用されて「１２．５＝（５＋２．５ｘ３）」となり、優先順位は第「３」位であることを示している。優先度の「５」は、関数「ｍａｉｎ」が候補関数「Ｓｅａｒｃｈ＿ＭＩＮ」（図２の２Ｂ行）をコール「ネスト＝１」していることを示し、「２．５ｘ３」は、候補関数「Ｓｅａｒｃｈ＿Ｎｕｍ」（図３の３Ａ行）をコール「ネスト＝２」する時、関数「Ｓｅａｒｃｈ＿ＭＩＮ」（図２の２Ｂ行）、関数「Ｓｅａｒｃｈ＿ＭＡＸ」（図２の２Ｃ行）、関数「Ｐｒｉｎｔ＿Ｒｅｓｕｌｔ」（図２の２Ｄ行）の３つの関数を介してコールしていることを示している。
【００５９】
また、関数「Ｓｅｔ＿Ｎｕｍｂｅｒｓ」は、Ｆｉｌｅ２．ｃのソースプログラムファイルの９行目（図３の３Ｂ行）から関数定義記述が始まり、優先度合計は、候補関数と同じ共有変数が２つ含まれる（Ｇｌｏｂ＿Ｎｕｍ、Ｇｌｏｂ）のでデバッグ対象特定ルール４が適用されて「２＝（１＋１）」となり、優先順位は第「６」位であることを示している。
【００６０】
さらにまた、関数「Ｓｅａｒｃｈ＿Ｎｕｍ」は、Ｆｉｌｅ２．ｃのソースプログラムファイルの４７行目（図４の４Ａ行）から関数定義記述が始まり、優先度合計は、デバッグ対象特定ルール１（「Ｓｅａｒｃｈ＿Ｎｕｍ」が候補関数）とデバッグ対象特定ルール３（候補関数「Ｓｅａｒｃｈ＿ＭＩＮ」からコール「ネスト＝１」された関連関数）が適用されて「１５（１０＋５）」となり、優先度合計の値がデバッグ候補箇所候補リスト８０の中で一番大きいため第「１」位となったことを示している。
【００６１】
このようにしてデバッグ支援装置によって生成されたデバッグ対象箇所候補リスト８０は図１４に示す統合開発環境で、デバッグ作業を行うソフトウェア開発者に示される。ソフトウェア開発者がデバッグ対象箇所候補リスト８０の優先順位の高い関数「Ｓｅａｒｃｈ＿Ｎｕｍ」を指示（クリック）すると、関数「Ｓｅａｒｃｈ＿Ｎｕｍ」（図４の４Ａ行）の定義記述（ソースプログラム）が編集プログラムで表示されるようになって作業効率が図られる。
【００６２】
上述のようにあらかじめ定められたルールに従って、不具合の原因箇所の自動絞り込みが行われるので、デバッグ対象箇所候補リスト８０の優先順位に従って作業することで不具合原因に関連が深い箇所の関数記述から解析を進めて行くことができ、ソフトウェア開発におけるデバッグ作業時間の短縮が見込まれてデバッグ作業の効率を向上させることができる。
【００６３】
また、あらかじめ定められたルールに従って、不具合原因の箇所がリストアップされるので思い込みなどによるデバッグ対象箇所の見落としが減ってソフトウェア開発におけるデバッグ作業の信頼性や効率を向上させることができる。
【００６４】
本発明は、上記実施例に限定されるものではなく、発明の要旨を逸脱しない範囲で、種々、変形して実施できることは勿論である。
【００６５】
例えば、デバッグ対象箇所候補リストの優先度を合計だけでなく候補関数毎に分割した値も表示するようにすれば、候補関数の変更内容や変更量などの情報が得られる場合には、関数の解析順序をより適切とすることができ、ソフトウェア開発におけるデバッグ作業時間の短縮が見込まれてデバッグ作業の効率を向上させることができる。
【図面の簡単な説明】
【００６６】
【図１】本発明によるソフトウェアデバッグ支援装置およびデバッグ支援方法の実施例を含むソフトウェア開発システムのシステム構成図。
【図２】デバッグ対象のソースプログラム（Ｆｉｌｅ１．ｃ）のリスト。
【図３】デバッグ対象のソースプログラム（Ｆｉｌｅ２．ｃ）のリスト。
【図４】デバッグ対象のソースプログラム（Ｆｉｌｅ２．ｃの続き）のリスト。
【図５】デバッグ対象のソースプログラム（ｇｌｏｂａｌ．ｈ）のリスト。
【図６】実行ログリスト。
【図７】ソースプログラムの変更履歴一覧表。
【図８】関数確認リスト。
【図９】候補関数リスト。
【図１０】デバッグ対象特定ルールの一覧表。
【図１１】デバッグ対象箇所候補リスト。
【図１２】統合開発環境の表示画面を示す図。
【図１３】本実施例のデバッグ支援装置のバージョン解析部の処理手順を示すフローチャート。
【図１４】本実施例のデバッグ支援装置のデバッグ対象特定部の処理手順を示すフローチャート。
【符号の説明】
【００６７】
１  ソフトウェア開発システム
１０  ソースプログラム
１１  コンパイラ
１２  実行プログラム
１３  プログラム実行部
２０  実行ログ
３０  バージョン解析部
３０ａ  関数確認リスト
４０  ソースプログラム構成管理ツール
４１  変更履歴一覧表
５０  候補関数リスト
６０  デバッグ対象特定部
６０ａ  仮候補リスト
７０  デバッグ対象特定ルール
８０  デバッグ対象箇所候補リスト
【図１】
2009104252.tif 000003
【図２】
2009104252.tif 000004
【図３】
2009104252.tif 000005
【図４】
2009104252.tif 000006
【図５】
2009104252.tif 000007
【図６】
2009104252.tif 000008
【図７】
2009104252.tif 000009
【図８】
2009104252.tif 000010
【図９】
2009104252.tif 000011
【図１０】
2009104252.tif 000012
【図１１】
2009104252.tif 000013
【図１２】
2009104252.tif 000014
【図１３】
2009104252.tif 000015
【図１４】
2009104252.tif 000016