(57)【要約】【課題】静的解析を利用してソフトウェアの排他制御に関する不具合を精度よく検出することができる排他制御不具合候補抽出装置を提供する。【解決手段】排他制御不具合候補抽出装置は、ソースプログラム入力部１０１で不具合を検出する対象のソフトウェアのソースプログラム１０６を入力し、設計情報入力部１０２でソースプログラム１０６の設計情報１０７を入力する。排他制御関数抽出部１０３は、設計情報１０７の排他制御関数・共有リソース名対応表およびタスクメイン関数リストを用い、ソースプログラム１０６から、複数のタスク上で利用される共有リソースにアクセスを行う排他制御関数を抽出する。排他制御判定実行部１０４は排他制御関数の中から排他制御不具合候補を検出し、排他制御不具合候補出力部１０５が排他制御不具合候補を検出結果として出力する。【選択図】図１
2010066889.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェア構成より共有リソースにアクセスする関数である排他制御関数を抽出する排他制御関数抽出手段と、
抽出された前記排他制御関数に対し、排他制御できているか否かを判定する処理を実行する排他制御判定実行手段とを備える、排他制御不具合候補抽出装置。
【請求項２】
前記排他制御関数抽出手段は、前記ソフトウェア構成の複数のタスク上で利用される共有リソースにアクセスを行なう排他制御関数を抽出する、請求項１に記載の排他制御不具合候補抽出装置。
【請求項３】
前記排他制御関数抽出手段は、抽出した前記関数に対して、さらに、予め規定されている、同時に実行可能なタスクの組み合わせを参照して、前記複数タスクが同時に実行されるか否かを判断し、前記複数のタスクが同時に実行されない場合には、前記抽出した関数を排他制御関数として抽出しないことを特徴とする、請求項２に記載の排他制御不具合候補抽出装置。
【請求項４】
入力手段と、演算手段と、出力手段とを備える排他制御不具合候補抽出装置における排他制御不具合候補抽出方法であって、
前記入力手段において、ソフトウェア構成を入力するステップと、
前記演算手段において、前記ソフトウェア構成より共有リソースにアクセスする関数である排他制御関数を抽出するステップと、
前記演算手段において、抽出された前記排他制御関数に対し、排他制御できているか否かを判定するステップと、
前記出力手段において、前記判断の結果を出力するステップとを備える、排他制御不具合候補抽出方法。
【請求項５】
前記排他制御関数を抽出するステップでは、前記ソフトウェア構成の複数のタスク上で利用される共有リソースにアクセスを行なう排他制御関数を抽出する、請求項４に記載の排他制御不具合候補抽出方法。
【請求項６】
前記排他制御関数を抽出するステップは、抽出した前記関数に対して、予め規定されている、同時に実行可能なタスクの組み合わせを参照して、前記複数タスクが同時に実行されるか否かを判断し、前記複数のタスクが同時に実行されない場合には、前記抽出した関数を排他制御関数として抽出しないように制御するステップを含む、請求項５に記載の排他制御不具合候補抽出方法。
【請求項７】
コンピュータに排他制御不具合候補抽出処理を実行させるプログラムであって、
前記コンピュータは、入力手段と、演算手段と、出力手段とを備え、
前記入力手段において、ソフトウェア構成を入力するステップと、
前記演算手段において、前記ソフトウェア構成より共有リソースにアクセスする関数である排他制御関数を抽出するステップと、
前記演算手段において、抽出された前記排他制御関数に対し、排他制御できているか否かを判定するステップと、
前記出力手段において、前記判断の結果を出力するステップとを実行させる、排他制御不具合候補抽出プログラム。
【請求項８】
前記排他制御関数を抽出するステップでは、前記ソフトウェア構成の複数のタスク上で利用される共有リソースにアクセスを行なう排他制御関数を抽出する、請求項７に記載の排他制御不具合候補抽出プログラム。
【請求項９】
前記排他制御関数を抽出するステップは、抽出した前記関数に対して、予め規定されている、同時に実行可能なタスクの組み合わせを参照して、前記複数タスクが同時に実行されるか否かを判断し、前記複数のタスクが同時に実行されない場合には、前記抽出した関数を排他制御関数として抽出しないように制御するステップを含む、請求項８に記載の排他制御不具合候補抽出プログラム。
【請求項１０】
請求項９に記載の排他制御不具合候補抽出プログラムを記録した、コンピュータ読取可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は排他制御不具合候補抽出装置、排他制御不具合候補抽出方法、および排他制御不具合候補抽出プログラムに関し、特に、ソフトウェアの排他制御に関する不具合を検出する排他制御不具合候補抽出装置、排他制御不具合候補抽出方法、および排他制御不具合候補抽出プログラムに関する。
【背景技術】
【０００２】
リアルタイムＯＳ（Operating System）上で動作するタスクは、必要に応じてグローバル変数や表示装置などのリソースをタスク間で共有する。各タスクがタスク間で共有しているリソース（以下、共有リソースという）に対してアクセスする際には、リアルタイムＯＳが提供する排他制御機構であるセマフォ等を用いて他タスクのアクセスを不可能な状態にした（ロックした）後にアクセスし、アクセス終了後にロックを解除することが必要である。したがって、タスクが共有リソースに対してアクセスするプログラムを作成する場合、プログラム作成者は、ロック、共有リソースへのアクセス、およびロック解除の順に実行されるプログラムを作成する必要がある。
【０００３】
しかし、プログラム作成者の不注意によりロックをかけることなく共有リソースにアクセスするモジュールが作成されてしまう場合がある。その場合、そのモジュールを利用した共有リソースへのアクセスが複数のタスクで同時に行なわれると、データ不整合などの不具合（以下、排他制御不具合）が発生してしまう可能性がある。
【０００４】
特開平３−２８８２３９号公報（以下、特許文献１）は、このような、共有リソースへのロック忘れによる不具合の発生を防ぐための、ロックをかけずに共有リソースにアクセスしている箇所を検出する技術を開示している。
【０００５】
詳しくは、特許文献１に開示されている技術では、ソースプログラムが入力として与えられると、ソースプログラムのコンパイル時に、データが共有リソースとして扱われるか否かのフラグがデータ割り当て認識領域Ａ１に設定され、実行時にロックをかける命令列を生成する際にロックをかけたことを示すフラグ（以下、ロックフラグ）をロック認識領域に設定する命令列がオブジェクトプログラム内に生成され、実行時にロックを解除する命令列を生成する際にロックフラグを解除する命令列がオブジェクトプログラム内に生成され、最終的にロードモジュールが生成される。さらに、前記ロードモジュールをデバッガで実行し、あるタスクによりリソースへのアクセスが行なわれた場合に、データ割り当て認識領域Ａ１が参照されて、そのリソースが共有リソースか否かが分かる。リソースが共有リソースの場合、さらにロックフラグが参照されることにより、その共有リソースに対してロックがかけられているか否かが分かる。ロックがかけられていない場合、未ロックの共有リソースへのアクセスが行なわれていることが分かる。特許文献１の技術では、上記手順により、未ロックの共有リソースへのアクセスを不具合として検出している。
【特許文献１】特開平３−２８８２３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に開示されている技術では、未ロック時における共有領域へのデータ定義参照という排他制御不具合の検出を、動的解析により行なっている。このため、処理内の条件分岐を網羅するために、条件を変更しながら膨大な回数の動的解析を行なう必要があるという問題があった。これを第１の問題として提起する。
【０００７】
また、特許文献１に開示されている技術を用いて排他制御不具合を検出するためには、動的解析の実行に必要な環境を別途用意する必要があるという問題があった。これを第２の問題として提起する。
【０００８】
上記第１の問題について詳細に説明する。
図３０は、共有リソースＡへアクセスする関数f1のソースプログラムを表わす図である。詳しくは、図３０を参照して、行２０１は共有リソースに対してロックをかける関数、行２０２は共有リソースの値を読込む関数、行２０３は呼ばれる関数f1_1、行２０５は共有リソースへ値を書込む関数、行２０４は共有リソースに対してアンロックを行なう関数を表わしている。
【０００９】
図３１は、共有リソースＢ，Ｃへアクセスする関数f2のソースプログラムを表わす図である。詳しくは、図３１を参照して、行３０１は関数の条件を表わす。関数f2は、行３０１の条件の判断を含む、共有リソースにアクセスする関数（以下、排他制御関数と呼ぶ）である。図３１の行群３０５は、行３０１の関数の条件に応じて、図３２，図３３のように２つのフローに分岐する。
【００１０】
図３２のフローの場合、行群４０２の共有リソースＢ，Ｃへのアクセス（読込み／書込み）の前後で、共有リソースＢ，Ｃへのロック、アンロックがそれぞれ行４０１，４０３で行なわれているため排他制御不具合の問題はない。一方、図３３のフローの場合、行５０２で共有リソースＣへのアクセス（書込み）が行なわれる前に行５０１で共有リソースＣに対してアンロックを行なっている。そのため、行５０２が排他制御不具合の原因となる。
【００１１】
特許文献１の技術を利用して図３１の排他制御関数の排他制御不具合を検出する場合、行３０１の条件判断において、図３２，３３のフローの排他制御不具合の有無の確認を行なう。そのために、行３０１の条件であるv2＞0と、v2≦0との２つの場合の条件を満たすように設定を行ない、それぞれの場合についてデバッグツールを用いた動的な検証を行なう必要があった。このため、デバッグの際の設定不備により、図３１の行３０１の条件のうちのv2≦0の条件の判断が漏れてしまった場合、図３３の行５０２の排他制御不具合の検出が行なえなかったという問題がある。
【００１２】
本発明はこのような問題に鑑みてなされたものであって、処理量および処理時間を抑えて、静的解析を利用してソフトウェアの排他制御に関する不具合を精度よく検出することができる排他制御不具合候補抽出装置、排他制御不具合候補抽出方法、および排他制御不具合候補抽出プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記目的を達成するために、本発明のある局面に従うと、排他制御不具合候補抽出装置は、ソフトウェア構成より共有リソースにアクセスする関数である排他制御関数を抽出する排他制御関数抽出手段と、抽出された排他制御関数に対し、排他制御できているか否かを判定する処理を実行する排他制御判定実行手段とを備える。
【００１４】
好ましくは、排他制御関数抽出手段は、ソフトウェア構成の複数のタスク上で利用される共有リソースにアクセスを行なう排他制御関数を抽出する。
【００１５】
より好ましくは、排他制御関数抽出手段は、抽出した関数に対して、さらに、予め規定されている、同時に実行可能なタスクの組み合わせを参照して、上記複数タスクが同時に実行されるか否かを判断し、上記複数のタスクが同時に実行されない場合には、抽出した関数を排他制御関数として抽出しないことを特徴とする。
【００１６】
本発明の他の局面に従うと、排他制御不具合候補抽出方法は、入力手段と、演算手段と、出力手段とを備える排他制御不具合候補抽出装置における排他制御不具合候補抽出方法であって、入力手段において、ソフトウェア構成を入力するステップと、演算手段において、ソフトウェア構成より共有リソースにアクセスする関数である排他制御関数を抽出するステップと、演算手段において、抽出された排他制御関数に対し、排他制御できているか否かを判定するステップと、出力手段において、その判断の結果を出力するステップとを備える。
【００１７】
好ましくは、排他制御関数を抽出するステップでは、ソフトウェア構成の複数のタスク上で利用される共有リソースにアクセスを行なう排他制御関数を抽出する。
【００１８】
より好ましくは、排他制御関数を抽出するステップは、抽出した関数に対して、予め規定されている、同時に実行可能なタスクの組み合わせを参照して、上記複数タスクが同時に実行されるか否かを判断し、上記複数のタスクが同時に実行されない場合には、抽出した関数を排他制御関数として抽出しないように制御するステップを含む。
【００１９】
本発明のさらに他の局面に従うと、排他制御不具合候補抽出プログラムは、コンピュータに排他制御不具合候補抽出処理を実行させるプログラムであって、上記コンピュータは、入力手段と、演算手段と、出力手段とを備え、入力手段において、ソフトウェア構成を入力するステップと、演算手段において、ソフトウェア構成より共有リソースにアクセスする関数である排他制御関数を抽出するステップと、演算手段において、抽出された排他制御関数に対し、排他制御できているか否かを判定するステップと、出力手段において、判断の結果を出力するステップとを実行させる。
【００２０】
好ましくは、排他制御関数を抽出するステップでは、ソフトウェア構成の複数のタスク上で利用される共有リソースにアクセスを行なう排他制御関数を抽出する。
【００２１】
より好ましくは、排他制御関数を抽出するステップは、抽出した関数に対して、予め規定されている、同時に実行可能なタスクの組み合わせを参照して、上記複数タスクが同時に実行されるか否かを判断し、上記複数のタスクが同時に実行されない場合には、抽出した関数を排他制御関数として抽出しないように制御するステップを含む。
【００２２】
本発明のさらに他の局面に従うと、記録媒体はコンピュータ読取可能な記録媒体であって、上述の排他制御不具合候補抽出プログラムを記録する。
【発明の効果】
【００２３】
本発明によると、多くの処理量や処理時間を必要とせず、ソフトウェアの排他制御に関する不具合を精度よく検出することができる。さらに、検出を行なう際の操作者の手間を減らすことができる。
【発明を実施するための最良の形態】
【００２４】
以下に、図面を参照しつつ、本発明の実施の形態について説明する。以下の説明では、同一の部品および構成要素には同一の符号を付してある。それらの名称および機能も同じである。
【００２５】
以下の実施の形態において、排他制御不具合候補抽出システムは排他制御不具合候補抽出装置としてのパーソナルコンピュータ等から構成される。そのハードウェア構成は一般的なパーソナルコンピュータのハードウェア構成と同様であって、全体を制御するＣＰＵ（Central Processing Unit）などで構成される演算部、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）やＨＤ（Hard Disk）などの記憶装置、ＣＤ−ＲＯＭ（Compact Disk-Read Only Memory）などの記録媒体から情報を読取る読取装置、キーボードやマウスや通信装置などの情報を入力する入力装置、および通信装置や表示装置などの演算結果を出力する出力装置を含む。これらはバスで接続される。または、排他制御不具合候補抽出システムは複数の装置から構成されて、専用回線や無線通信回線などで接続されてもよい。
【００２６】
さらに、上述の記憶装置には、所定の記憶領域として、入力装置から入力される、後述するソースプログラムや設計情報などを記憶する領域と、ＣＰＵで実行される排他制御不具合候補抽出プログラムを記憶する領域とが含まれる。
【００２７】
［第１の実施の形態］
図１は、本発明の第１の実施の形態の排他制御不具合候補抽出システムの構成の具体例を示す図である。図１に示される各構成は、排他制御不具合候補抽出システムのＣＰＵが記憶装置に記憶される排他制御不具合候補抽出プログラムを実行することで実現される機能である。図１に示される構成の少なくとも一部が、上述の排他制御不具合候補抽出システムのハードウェア構成で実現されてもよい。
【００２８】
図１を参照して、本実施の形態にかかる排他制御不具合候補抽出システムは、ソースプログラム入力部１０１、設計情報入力部１０２、排他制御関数抽出部１０３、排他制御判定実行部１０４、および排他制御不具合候補出力部１０５を含んで構成される。
【００２９】
ソースプログラム入力部１０１は、排他制御不具合を抽出する対象となるソフトウェア構成であるソースプログラム１０６を取得し、格納する。
【００３０】
設計情報入力部１０２は、ソースプログラム１０６の設計情報１０７を取得し、格納する。ここで、設計情報は、排他制御関数候補・共有リソース名対応表、共有リソース仕様書、およびタスクメイン関数リストを含む。
【００３１】
「排他制御関数候補・共有リソース名対応表」とは、図２に示されるような、共有リソースにアクセスする関数とその共有リソース名との対応関係を表わした表形式のデータである。ここで、「共有リソース」とは、グローバル変数、関数内静的変数などの、タスク間で共有するリソースを指す。
【００３２】
「共有リソース仕様書」とは、図３に示されるような、共有リソースごとに、共有リソースにアクセスするための関数であるAPI（Application Program Interface）の名前と、どのようなアクセスを行なうのかを表わす情報（タイプ）との対応関係を表わした情報である。「タイプ」には、共有リソースに対してロックをかけるlock、共有リソースに対してロックを解除するunlock、および共有リソースに対して読込みまたは書込みを行なうaccessの３種類が含まれる。
【００３３】
「タスクメイン関数リスト」とは、図４に示されるような、各タスクの起動時に最初に呼出される関数名のリストである。
【００３４】
排他制御関数抽出部１０３は、ソースプログラム入力部１０１が取得したソースプログラム１０６と、設計情報入力部１０２が取得した設計情報１０７の中の排他制御関数・共有リソース名対応表およびタスクメイン関数リストとから、複数のタスクから呼出される排他制御関数を抽出する。
【００３５】
図５は、排他制御関数抽出部１０３での処理の具体例を示すフローチャートである。図５のフローチャートは、具体的に、ソースプログラム入力部１０１がソースプログラム１０６として図３０，図３１のソースプログラムを含むソースプログラム、設計情報入力部１０２が設計情報１０７として図２の排他制御関数・共有リソース名対応表および図４のタスクメイン関数リストを取得した場合の、排他制御関数抽出部１０３の処理を表わしている。
【００３６】
図５を参照して、始めに、排他制御関数抽出部１０３は、ステップＳ８０１において、ソースプログラム入力部１０１から図３０，図３１のソースプログラムを含むソースプログラムと、設計情報入力部１０２から図２の排他制御関数・共有リソース名対応表Tableと、図４のタスクメイン関数リストTaskmainTableとをそれぞれ取得する。
【００３７】
次に、排他制御関数抽出部１０３は、対応表Table内の共有リソースすべてについて処理を行なっていない場合（ステップＳ８０２でＮＯ）、ステップＳ８０３において、対応表Tableから共有リソースを１つ取出し、同じく対応表Tableから、この共有リソースにアクセスする関数のリストF_servを生成する。図２の排他制御関数・共有リソース名対応表Tableの場合、共有リソースＡが対応表Tableから取出された場合、リストF_servは{f1}となり、共有リソースＢと共有リソースＣとがそれぞれ取出された場合、リストF_servは{f2}となる。
【００３８】
続いて、排他制御関数抽出部１０３は、ステップＳ８０４において、リストF_serv内の各関数f()について、関数f()を呼出す関数をソースプログラムから抽出して、これをリストF_serv内の関数を呼ぶ関数のリストF_use(F_serv)に追加する。たとえば、ソースプログラムの解析により、リストF_serv内の１関数である関数f1を呼出している関数が関数g1，関数g2の２つであることが分かった場合、関数g1と関数g2とがリストF_use(F_serv)に追加される。
【００３９】
続いて、排他制御関数抽出部１０３は、ステップＳ８０５において、リストF_use(F_serv)内の各関数g()について、関数g()を呼出す関数をソースプログラムから抽出し、再帰的にリストF_use(F_serv)に追加する。ここで、「再帰的」にとは、関数g()を呼出す関数として、たとえば、関数h()がリストF_use(F_serv)に追加された場合、この関数h()についても、これを呼出している関数をソースプログラムから抽出し、リストF_use(F_serv)に加えることを意味する。関数g()を呼出している関数が存在しない場合、リストF_use(F_serv)内の次の関数を関数g()として同様の処理を行なう。たとえば、リストF_use(F_serv)が{g1, g2}の場合、排他制御関数抽出部１０３は、関数g1を呼出している関数（たとえば関数h1，関数h2）をソースプログラムから抽出し、リストF_use(F_serv)に追加する（F_use(F_serv) = {g1, g2, h1, h2}）。続いて、排他制御関数抽出部１０３は、リストF_use(F_serv)の次の要素の関数g2についても同様にこれを呼出している関数をソースプログラムから抽出し、リストF_use(F_serv)に追加する。続いて、リストF_use(F_serv)の次の要素の関数h1について、これを呼出している関数が存在しない場合、リストF_use(F_serv)には何も追加せず、次の要素の関数h2について、これを呼出している関数の抽出を行なう。以上のような処理をリストF_use(F_serv)のすべてに対して行なう。
【００４０】
続いて、排他制御関数抽出部１０３は、ステップＳ８０６において、リストF_use(F_serv)内に、タスクメイン関数リストTaskmainTable内にあるタスクメイン関数がいくつあるかを数え、これが２以上の場合（ステップＳ８０６でＹＥＳ）、ステップＳ８０３で取出した共有リソースが２つ以上のタスクで利用されることがわかる。そのため、排他制御関数抽出部１０３は、ステップＳ８０７において、排他制御不具合候補検出の対象として、ステップＳ８０３で取出した共有リソースにアクセスを行なう排他制御関数のリストF_servを排他制御関数のリストF_exclusiveに加える。一方、リストF_use(F_serv)内に、タスクメイン関数リストTaskmainTable内にあるタスクメイン関数が１つだけしか存在しない場合（ステップＳ８０６でＮＯ）、ステップＳ８０３で取出した共有リソースは単一のタスクからのみ利用されることがわかる。そのため、排他制御関数抽出部１０３はこの共有リソースにアクセスを行なう排他制御関数F_servを排他制御不具合検出の対象としない。
【００４１】
排他制御関数抽出部１０３は、以上の処理を排他制御関数・共有リソース名対応表Table内のすべての共有リソースに対して行ない、ステップＳ８０８において、排他制御関数リストF_exclusiveを排他制御判定実行部１０４に出力する。
【００４２】
排他制御判定実行部１０４は、排他制御関数抽出部１０３が出力した排他制御関数リストF_exclusiveと、設計情報入力部１０２が取得した排他制御関数・共有リソース名対応表および共有リソース仕様書と、ソースプログラム取得部１０１が取得したソースプログラムとを取得し、排他制御不具合候補を検出する。
【００４３】
図６は、排他制御判定実行部１０４での処理の具体例を示すフローチャートである。図６のフローチャートは、具体的に、排他制御関数リストF_exclusiveとして{f1, f2}、図２の排他制御関数・共有リソース名対応表、図３の共有リソース仕様書、および図３０，図３１を含むソースプログラムが排他制御判定実行部１０４に与えられた場合の、排他制御判定実行部１０４の処理を表わしている。
【００４４】
図６を参照して、始めに、排他制御判定実行部１０４は、ステップＳ９０１において、ソースプログラム入力部１０１よりソースプログラムを、設計情報入力部１０２より排他制御関数・共有リソース名対応表と共有リソース仕様書とを、および排他制御関数抽出部１０３より排他制御関数リストF_exclusiveを取得する。
【００４５】
ステップＳ９０１で取得した排他制御関数リストF_exclusiveが空でない場合（ステップＳ９０２でＮＯ）、排他制御判定実行部１０４は、ステップＳ９０３において排他制御関数リストF_exclusiveから要素を１つ取出し、これを関数f()とする。
【００４６】
次に、排他制御判定実行部１０４は、ステップＳ９０４において、関数f()と関数f()から呼ばれている関数とが定義されている箇所をソースプログラムから見つけ、この箇所をSourceCodeSet(f())とする。ただし、共有リソース仕様書に記載されている共有リソースアクセス用APIは含まない。たとえば、関数f()が関数f1である場合、上記ステップＳ９０４において、図３０のソースプログラムにおける関数f1と関数f1から呼ばれている関数f1_1とのソースプログラムがSourceCodeSet(f())となる。
【００４７】
次に、排他制御判定実行部１０４は、ステップＳ９０５において、SourceCodeSet(f())のコントロールフローグラフを生成し、関数f()のコントロールフローグラフを、SourceCodeSet(f())の関数f()以外の関数のコントロールフローグラフで展開したフローグラフ(Graph)を作成する。「コントロールフローグラフ」とは、各関数内部における制御の流れを表わすグラフである。具体的には、SourceCodeSet(f())が、図３０のソースプログラムの場合、関数f1のコントロールフローグラフは図７、関数f1_1のコントロールフローグラフは図８で表わされる。上記ステップＳ９０５では、これらのグラフを用いて、関数f1について、図７のノード１００１を、図８の関数f1_1のコントロールフローグラフで展開することで、図９に示される関数f1のフローグラフGraphが作成される。図３１のソースプログラムに対しても同様にして、図１０に示される関数f2のフローグラフGraphが作成される。
【００４８】
次に、排他制御判定実行部１０４は、ステップＳ９０６において、関数f()がどの共有リソースに対してアクセスを行なうかを、ステップＳ９０１で取得した排他制御関数・共有リソース名対応表（図２）から取得する。そして、取得した共有リソース名について、その共有リソースにアクセスを行なうAPI名とそのAPIのタイプとの組の集合API_set(f())をステップＳ９０１で取得した共有リソース仕様書（図３）から抽出し、上記ステップＳ９０５で作成されたフローグラフGraphを分析する。具体的な分析方法としては、フローグラフGraphの各ノードが、共有リソースxへのロック(lock(x))、共有リソースxへのアンロック(unlock(x))、共有リソースxへのアクセス(access(x))、またはそれ以外（その他）のどれに割当てられるかを、共有リソース仕様書から抽出された上記API_set(f())内のAPI名とタイプとの対応関係より判別する。その判別結果に従って、フローグラフGraphを、イベントlock(x)、unlock(x)、access(x)、およびその他が割当てられたノードの並びに変換する。具体的に図９のフローグラフGraphを分析して上記割当てを行なう場合、上記ステップＳ９０６では図９の関数f1のフローグラフGraphより、図１１に示される、関数f1のイベント割当て後のノードの並びが得られ、また、図１０の関数f2のフローグラフGraphより、図１２に示される、関数f2のイベント割当て後のノードの並びが得られる。
【００４９】
次に、排他制御判定実行部１０４は、ステップＳ９０７において、上記ステップＳ９０６で得られたノードの並びをイベント列とみなして逐次読込み、共有リソースxの初期状態をunlockとして、図１３の共有リソースのロック状態遷移図に従って状態遷移を実行する。図１３の状態遷移図において、状態unlockは共有リソースxにロックがかかっていない状態、状態lockはロックがかかった状態を表わしている。図１３に示される状態遷移図は、共有リソースのロック状態の遷移を規定したものであって、予め排他制御判定実行部１０４に記憶されているものとする。ステップＳ９０７で排他制御判定実行部１０４は図１３に示される状態遷移図に従って、これらの状態間の遷移を静的に行なっていく。具体的に、ノードの並びが図１１の共有リソースＡに関するノードの並びである場合、ステップＳ９０７において、排他制御判定実行部１０４は、初期状態unlockでノード１４０１であるイベントlock(A)を読込み、図１３の状態遷移図に従い初期状態unlockから状態lockに遷移する。続いて、ノード１４０２，１４０３であるaccess(A)イベントを読込み、状態lockのままとする。最後に、ノード１４０４であるunlock(A)イベントを読込んで状態lockから状態unlockに遷移する。図１２のノードの並びの場合、共有リソースがＢ，Ｃと２つあるので、排他制御判定実行部１０４は、図１３の状態遷移図を共有リソースごとに用意し、同様に初期状態unlockから遷移を開始する。また、図１２のノード１５０４のように、条件判断のためにフローが分岐する場合、排他制御判定実行部１０４は、分岐したノード１５０５，１５１０であるイベントを通るフローそれぞれについて状態遷移を行ない、排他制御不具合候補の検出を行なう。
【００５０】
次に、排他制御判定実行部１０４は、ステップＳ９０８において、状態unlockでaccessイベントが発生したかどうかを調べる。状態unlockでaccessイベントが発生した場合は（ステップＳ９０８でＹＥＳ）、アンロック状態の共有リソースへのアクセスが発生することになるので、排他制御判定実行部１０４は、ステップＳ９１０において、排他制御不具合候補として、関数f()の関数名と“アンロック状態でのアクセス”といった不具合内容を含む情報とを排他制御不具合候補リストNG_Listに追加する。たとえば、図１２のノー
ドの並びのうちノード１５１０のイベントを通るフローに対して状態遷移を行なう場合、共有リソースＣに関するノードの並びは、順番にノード１５０２(lock)、ノード１５１０(access)、ノード１５１１(unlock)、ノード１５０７(access)、およびノード１５０８(unlock)となり、図１３の状態遷移図に従うと、ノード１５０７において、状態unlockでaccessイベントが発生することがわかる。このため、排他制御判定実行部１０４は、上記ステップＳ９０８において、排他制御不具合候補として“関数名：f2  内容：アンロック状態でのアクセス”を排他制御不具合候補リストNG_Listに追加する。
【００５１】
一方、状態unlockでaccessイベントが発生していない場合は（ステップＳ９０８でＮＯ）、排他制御判定実行部１０４は、ステップＳ９０９において、ノードの並びの終端に到達したかを判定する。ノードの終端に到達した場合（ステップＳ９０９でＹＥＳ）、さらにステップＳ９１１において、終端到達時点での共有リソースの状態を確認し、状態lockであった場合（ステップＳ９１１でＹＥＳ）、ステップＳ９１０において、アンロックせずに処理を終了したとして、関数f()の関数名と“ロック状態での処理終了”といった不具合内容を含む情報とを排他制御不具合候補として排他制御不具合候補NG_Listに追加する。
【００５２】
図１１に示されたノードの並びのように、ノード１４０２，１４０３の共有リソースへのアクセスがすべてロック状態で行なわれ、かつ、処理が終了する終端ノード１４０４においてアンロック状態である場合、上記ステップＳ９０８でＮＯ、ステップＳ９０９でＹＥＳ、かつステップＳ９１１でＮＯと判断され、排他制御不具合ではないと判断されるので、このノードの並びの排他制御不具合候補の抽出を終了し、再びステップＳ９０２からの処理を繰返す。
【００５３】
排他制御判定実行部１０４は、以上の手順を排他制御関数リストF_exclusiveが空になるまで繰返し（ステップＳ９０２でＹＥＳ）、ステップＳ９１２において、図１４に示されるような排他制御不具合候補リストNG_Listを排他制御不具合候補出力部１０５に出力する。
【００５４】
排他制御不具合候補出力部１０５は、たとえば図１４に示されるようなリスト形式などで、排他制御判定実行部１０４から取得した排他制御不具合候補を出力する。
【００５５】
第１の実施の形態にかかる排他制御不具合候補抽出システムが上述のように構成されて、上述のような処理が行なわれることで、排他制御不具合の検出の際の、条件分岐網羅のためのテストデータ作成や動的解析の実行に必要な環境構築を不要として、精度よく排他制御不具合を検出することができる。従って、当該システムの利用者の手間を減らすことができる。また、排他制御不具合を検出するためのシステム構成を容易にすることができる。また、排他制御不具合を検出するため処理量を減らし、処理速度を早めることができる。
【００５６】
［第２の実施の形態］
図１５は、本発明の第２の実施の形態の排他制御不具合候補抽出システムの構成の具体例を示す図である。図１５に示される各構成もまた、排他制御不具合候補抽出システムのＣＰＵが記憶装置に記憶される排他制御不具合候補抽出プログラムを実行することで実現される機能である。図１５に示される構成の少なくとも一部が、排他制御不具合候補抽出システムのハードウェア構成で実現されてもよい。
【００５７】
図１５を参照して、第２の実施の形態の排他制御不具合候補抽出システムは、図１に示された第１の実施の形態の排他制御不具合候補抽出システムの構成のうち、設計情報入力部１０２に替えて、排他制御関数・共有リソース名対応表生成部２２０１、共有リソース仕様書生成部２２０２、およびタスクメイン関数リスト生成部２２０３を含んで構成される。
【００５８】
設計情報２２０４は、図１６に示されるような、共有リソース名と、共有リソースに対してロック・アンロックを行なう関数の関数名と、ロック・アンロックのいずれかである関数のタイプとを含む共有リソース・ロックアンロック関数対応表、およびタスクを生成する関数名を含む。設計情報２２０４は、排他制御関数・共有リソース名対応表生成部２２０１、共有リソース仕様書生成部２２０２、およびタスクメイン関数リスト生成部２２０３で入力され、取得される。
【００５９】
共有リソース仕様書生成部２２０２は、取得した設計情報２２０４に含まれる共有リソース・ロックアンロック関数対応表に記載された共有リソースにアクセスしている関数を、ソースプログラム入力部１０１で取得したソースプログラム１０６から抽出し、取得した共有リソース・ロックアンロック関数対応表に追加することにより共有リソース仕様書を生成する。
【００６０】
排他制御関数・共有リソース名対応表生成部２２０１は、共有リソース仕様書生成部２２０２で生成された共有リソース仕様書に記載された共有リソースアクセス関数を呼出している関数を、ソースプログラム入力部１０１で取得したソースプログラム１０６から抽出し、排他制御関数・共有リソース名対応表を生成する。
【００６１】
タスクメイン関数リスト生成部２２０３は、取得した設計情報２２０４に含まれるタスクを生成する関数を呼出している箇所を、ソースプログラム入力部１０１で取得したソースプログラム１０６から検索し、上記関数の引数として記載されているタスクメイン関数を抽出してタスクメイン関数リストを生成する。
【００６２】
排他制御関数・共有リソース名対応表生成部２２０１で生成された排他制御関数・共有リソース名対応表は、排他制御関数抽出部１０３、排他制御判定実行部１０４での処理に用いられる。共有リソース仕様書生成部２２０２で生成された共有リソース仕様書は、排他制御判定実行部１０４での処理に用いられる。タスクメイン関数リスト生成部２２０３で生成されたタスクメイン関数リストは、排他制御関数抽出部１０３での処理に用いられる。
【００６３】
図１７は、共有リソース仕様書生成部２２０２および排他制御関数・共有リソース名対応表生成部２２０１での処理の具体例を示すフローチャートである。図１７のフローチャートは、具体的に、図１６に示された共有リソース・ロックアンロック関数対応表、および図３０，図１８の、共有リソースＡにアクセスする関数のソースプログラムを含むソースプログラムを使用して、共有リソース仕様書生成部２２０２が共有リソース仕様書を生成し、排他制御関数・共有リソース名対応表生成部２２０１が排他制御関数・共有リソース名対応表を生成する処理を表わしている。
【００６４】
図１７を参照して、始めに、共有リソース仕様書生成部２２０２は、ステップＳ１８０１において、図１６に示される共有リソース・ロックアンロック関数対応表Var_Comと、図３０，図１８のソースプログラムを含むソースプログラムとを取得する。対応表Var_Com内の共有リソースすべてについて調べていない場合（ステップＳ１８０２でＮＯ）、共有リソース仕様書生成部２２０２は、ステップＳ１８０３において、対応表Var_Comから共有リソースをv_cとして取得する。たとえば、図１６に示される共有リソース・ロックアンロック関数対応表Var_Comからは、共有リソースＡ，Ｂ，Ｃをそれぞれv_cとして取得する。
【００６５】
次に、共有リソース仕様書生成部２２０２は、ステップＳ１８０４において、上記ステップＳ１８０１で入力されたソースプログラムを検索し、共有リソースv_cに対して代入または参照が行なわれている箇所を見つけ、この箇所を含む関数群を関数群F_list(v_c)とする。上記ステップＳ１８０１で図１８のソースプログラムが与えられた場合、ステップＳ１８０３で取得した共有リソースv_cが共有リソースＡであれば行２１０１，２１０２の箇所が該当するため、ステップＳ１８０４において、図１９に示されるように、共有リソースＡにアクセスする関数のリストである関数群F_list(v_c)として関数ACCESS_READ_A，ACCESS_WRITE_Aが抽出される。共有リソース仕様書生成部２２０２は、これらを共有リソースv_cのアクセス関数として対応表Var_Comに追加し、共有リソース仕様書を生成する。
【００６６】
次に、排他制御関数・共有リソース名対応表生成部２２０１は、ステップＳ１８０５において、上記ステップＳ１８０１で入力されたソースプログラムを検索し、共有リソース仕様書Var_Com内の共有リソースv_cにアクセスを行なう関数群F_list(v_c)に含まれる関数を呼出している関数を見つけ、この関数群を関数群F_call(F_list(v_c))とする。上記ステップＳ１８０４において関数群F_list(v_c)として図１９の関数が抽出された場合、ステップＳ１８０５では、図３０のソースプログラムを含むソースプログラムの検索により、図３０のソースプログラムの行２０２の、関数群F_list(v_c)内の関数を呼出してい
る関数f1が関数群F_call(F_list(v_c))の１つとして抽出される。
【００６７】
次に、排他制御関数・共有リソース名対応表生成部２２０１は、ステップＳ１８０６において、関数群F_call(F_list(v_c))内の関数ごとに、共有リソース名として共有リソースv_cを対応付け、排他制御関数・共有リソース名対応表m_listに追加する。共有リソースv_cが共有リソースＡで、関数群F_call(F_list(v_c))内の関数が図３０の関数f1であった場合、ステップＳ１８０６では、関数f1と共有リソースＡとが対応付けられて排他制御関数・共有リソース名対応表m_listに追加され、図２０に示される共有リソースＡの共有リソース仕様書が生成される。以上の処理が全共有リソース対して繰返されると（ステップＳ１８０２でＹＥＳ）、排他制御関数・共有リソース名対応表生成部２２０１は、ステップＳ１８０７において、生成した共有リソース仕様書Var_Comを図３と同様の形式で排他制御判定実行部１０４に対して出力し、また、生成した排他制御関数・共有リソース名対応表m_listを図２と同様の形式で排他制御関数抽出部１０３と排他制御判定実行部１０４とに対して出力する。
【００６８】
第２の実施の形態にかかる排他制御不具合候補抽出システムが上述のように構成されて、上述のような処理が行なわれることで、第１の実施の形態にかかる排他制御不具合候補抽出システムに比べ、必要な設計情報を、排他制御関数・共有リソース名対応表、共有リソース仕様書、およびタスクメイン関数リストから、共有リソース・ロックアンロック関数対応表とタスク生成関数とに削減できる。そのため、当該システムの利用者の、入力として与える設計情報を作成するための手間を減らすことが可能となる。
【００６９】
［第３の実施の形態］
第１の実施の形態にかかる排他制御不具合候補抽出システムでは、図２１に示されるような共有リソースＤに対して直接アクセスする記述を含む関数f3のソースプログラムと、図２２に示されるような排他制御関数候補・共有リソース名対応表と、図２３に示されるような共有リソースＤの共有リソース仕様書とが与えられている。関数f3が複数のタスクから呼ばれる関数であった場合、排他制御判定実行部１０４は、図６のフローチャートに従い、ステップＳ９０５において図２４に示される関数f3のフローグラフGraphを生成する。さらに、ステップＳ９０６において、図２２の排他制御関数候補・共有リソース名対応表と図２３の共有リソース仕様書とを用いて、図２５に示される関数f3のイベント割当て後のノードの並びを生成する。ここで、共有リソースに対して直接アクセスを行なう記述とは、ソースプログラム上で共有リソースに代入を行なう文または、共有リソースを参照する文を指す。図２１のソースプログラムの行２６０１では共有リソースＤへのアクセスが行なわれているにもかかわらず、そのアクセス方法（直接アクセス）が図２３の共有リソース仕様書に記載されている以外の方法であるため、ステップＳ９０６では、図２５のノード２９０３に”その他”が割当てられてしまう。このため、第１の実施の形態にかかる排他制御不具合候補抽出システムでは、図２５のノードの並びより、ノード２９０３においてアンロック状態での共有リソースＤへのアクセスが行なわれると判定できず、図２１のソースプログラムの行２６０１の箇所を排他制御不具合として検出することができない。
【００７０】
第３の実施の形態にかかる排他制御不具合候補抽出システムは、共有リソースに対して直接的なアクセスが行なわれている場合でも、排他制御不具合が検出できるようにしたものである。
【００７１】
図２６は、本発明の第３の実施の形態の排他制御不具合候補抽出システムの構成の具体例を示す図である。図２６に示される各構成もまた、排他制御不具合候補抽出システムのＣＰＵが記憶装置に記憶される排他制御不具合候補抽出プログラムを実行することで実現される機能である。図２６に示される構成の少なくとも一部が、排他制御不具合候補抽出システムのハードウェア構成で実現されてもよい。
【００７２】
図２６を参照して、第３の実施の形態の排他制御不具合候補抽出システムは、図１に示された第１の実施の形態の排他制御不具合候補抽出システムの構成に加えて、共有リソース仕様書・ソースプログラム変更部２５０１を含んで構成される。
【００７３】
共有リソース仕様書・ソースプログラム変更部２５０１は、ソースプログラム入力部１０１からソースプログラムを取得し、設計情報入力部１０２から設計情報として共有リソース仕様書を取得する。共有リソース仕様書・ソースプログラム変更部２５０１は、共有リソース仕様書に記載された共有リソースにアクセスしている箇所をソースプログラムから検索し、ソースプログラムの共有リソースアクセス箇所を擬似関数に変更すると共に、共有リソース仕様書に擬似関数名をアクセス関数として追加する。
【００７４】
具体的には、ソースプログラム入力部１０１から図２１のソースプログラムを、設計情報入力部１０２から図２３の共有リソース仕様書を取得した場合、共有リソース仕様書・ソースプログラム変更部２５０１は、図２１のソースプログラムから行２６０１のように共有リソースＤに直接アクセスしている箇所を検索し、その箇所を共有リソース名Ｄを含む特定の文字列（たとえばTRANS_ACCESS_D）に置換する。図２１のソースプログラムの行２６０１は、共有リソース仕様書・ソースプログラム変更部２５０１によって図２７の行３００１のように変更される。さらに、共有リソース仕様書・ソースプログラム変更部２５０１は、置換した文字列（たとえばTRANS_ACCESS_D）を共有リソースＤのアクセス関数として共有リソース仕様書に追加する。図２３の共有リソースＤの共有リソース仕様書に、図２８の行３１０１に示されるように、置換した文字列およびタイプが追加される。
【００７５】
他の構成における処理は、第１の実施の形態にかかる排他制御不具合候補抽出システムの構成での同一である。第３の実施の形態にかかる排他制御不具合候補抽出システムでは、共有リソース仕様書・ソースプログラム変更部２５０１での処理によって、ソースプログラム入力部１０１から入力されたソースプログラム１０６である図２１のソースプログラムは図２７に示されるように変更され、設計情報入力部１０２から入力された設計情報１０７としての図２３の共有リソース仕様書は図２８のように変更される。そのため、第３の実施の形態にかかる排他制御不具合候補抽出システムでは、排他制御判定実行部１０４は、図２９に示されるように関数f3のイベント割当て後のノードの並びを生成することができ、ノード３２０３の箇所でアンロック状態での共有リソースアクセスが行なわれていることを検出できる。
【００７６】
第３の実施の形態にかかる排他制御不具合候補抽出システムが上述のように構成されて、上述のような処理が行なわれることで、ソースプログラムに共有リソースに対して直接アクセスしている記述が含まれている場合でも、排他制御不具合候補の抽出を行なうことができる。そのため、第１の実施の形態にかかる排他制御不具合候補抽出システムでの不具合検出精度を向上させることができる。
【００７７】
［第４の実施の形態］
第１、第２、第３の実施の形態にかかる排他制御不具合候補抽出システムでは、出力する排他制御不具合候補となる関数が、（２個以上の）呼び出し元のタスクから呼び出されている。ここで、呼び出し元のタスクがソフトウェアを実際に動作させる際において、互いに同時に実行されることがない場合には排他制御不具合は発生しないが、第１、第２、第３の実施の形態にかかる排他制御不具合候補抽出システムでは排他制御不具合候補として出力してしまう。よって、これら実施の形態にかかる排他制御不具合候補抽出システムでは、不必要な排他制御不具合候補が出力される場合がある。そこで、第４の実施の形態は、タスク同時起動の組み合わせの情報を参照し、関連する複数のタスクが同時に起動されない場合には不具合候補として出力しないようにする。
【００７８】
図３４は、本発明の第４の実施の形態の排他制御不具合候補抽出システムの構成の具体例を示す図である。図３４を参照して、第４の実施の形態にかかる排他制御不具合抽出システムは、図１に示された第１の実施の形態の排他制御不具合候補抽出システムの構成における設計情報１０７は、同時実行可能なタスクの組み合わせを示す、同時実行可能タスク組合せ表を含む。また、排他制御関数抽出部１０３は、第１処理部１０３１および第２処理部１０３２を含んで構成される。
【００７９】
第１処理部１０３１は、先に図５を用いて説明された処理である、複数のタスク上で利用される共有リソースにアクセスを行なう排他制御関数を抽出する処理を行なう。第２処理部１０３２は、第１処理部１０３１で抽出された排他制御不具合関数について、排他制御関数を呼び出す複数タスクが同時に実行されない場合に同排他制御関数を候補から除外するための処理を行なう。
【００８０】
図３５は、第２処理部１０３２で実行される処理の流れを具体例を用いて説明するためのフローチャートである。図３５を参照して、ｓｔｅｐ１で第２処理部１０３２は第１処理部１０３１から出力される排他制御関数リストを入力として受け取り、その中から排他制御関数を１個取り出す。たとえば、第２処理部１０３２は第１処理部１０３１から、図３６に示される、共有リソースアクセス関数（funcSetCommonResourceA）と、図３７に示される共有リソースアクセス関数（funcSetCommonResourceB）の２個の要素からなる排他制御関数リスト[funcSetCommonResourceA,funcSetCommonResourceB]を入力されたとする。このとき、ｓｔｅｐ１で第２処理部１０３２は、当該排他制御関数リストから１の排他制御関数funcSetCommonResourceAを取り出す。
【００８１】
次にstep２で第２処理部１０３２は、排他制御関数が呼び出されるタスク開始関数のリストを「タスクリスト」として取得する。排他制御関数リストから取り出した排他制御関数が関数funcSetCommonResourceAである場合は、図３６を参照して、関数funcSetCommonResourceAをタスク開始関数に突き当たるまで呼び出す関数を再帰的に求めることで、タスクリスト[funcTaskMain_BROWSER,funcTaskMain_ONESEG]を得る。
【００８２】
次にｓｔｅｐ３で第２処理部１０３２は、ｓｔｅｐ２で取得されたタスクリストのタスクが同時起動できるかどうかを、設計情報１０７に含まれる「同時実行可能タスク組み合わせ表」を利用して判定する。図３８は、同時実行可能タスク組み合わせ表の具体例を示す図である。図３８に示される組み合せ表を参照することで、タスク開始関数名funcTaskMain_BROWSERに対応するタスク（ブラウザ）と、タスク開始関数名funcTaskMain_ONESEGに対応するタスク（ワンセグ）とは、互いに同時に実行されることがないことがわかる。すなわち、ブラウザタスクが実行されている間、ワンセグタスクは実行できず、ワンセグタスクが実行されている間、ブラウザタスクは実行できない。よって、図３８に示される場合、ｓｔｅｐ３で第２処理部１０３２は、ｓｔｅｐ２で取得されたタスクリストのタスクが同時起動されることはないと判定し、ｓｔｅｐ４において、排他制御関数funcSetCommonResourceAを排他制御関数リストから削除する。
【００８３】
ｓｔｅｐ５で第２処理部１０３２は、排他制御関数リスト中の全排他制御関数について調べたかどうかを判断する。この例では、排他制御関数リスト中の排他制御関数funcSetCommonResourceBを調べていないため、ｓｔｅｐ１に戻り、排他制御関数funcSetCommonResourceBを排他制御関数リストから取り出す。そしてｓｔｅｐ２で、排他制御関数funcSetCommonResourceBが呼び出されるタスク開始関数のリストをタスクリストとして取得する。図３７を参照して、ｓｔｅｐ２で、排他制御関数funcSetCommonResourceBの呼び出しを行なうタスク開始関数として関数funcTaskMain_BROWSER、関数funcTaskMain_MAILが得られる。図３８に示される同時実行可能タスク組み合わせ表よりブラウザのタスクとメールのタスクとは同時起動が可能な場合があるため、ｓｔｅｐ３で第２処理部１０３２は、取得されたタスクリストのタスクが同時起動されない、とは判断されず、ｓｔｅｐ４において排他制御関数funcSetCommonResourceBを排他制御関数リストから削除しない。ｓｔｅｐ５で第２処理部１０３２は、排他制御関数リスト中の全排他制御関数について調べたと判断し、ｓｔｅｐ６で、排他制御関数リストとしてリスト[funcSetCommonResourceB]を出力する。
【００８４】
以上より、同時起動されないことが明らかであるタスクの組み合わせに対応する排他制御関数は除去できるようになり、不必要な排他制御不具合候補の出力が抑制され、ユーザの利便性を高める効果がある。
【００８５】
さらに、上述の排他制御不具合候補抽出システムにおける処理をコンピュータに実行させる排他制御不具合候補抽出プログラムを提供することもできる。このようなプログラムは、コンピュータに付属するフレキシブルディスク、ＣＤ−ＲＯＭ（Compact Disk-Read Only Memory）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）およびメモリカードなどのコンピュータ読取り可能な記録媒体にて記録させて、プログラム製品として提供することもできる。あるいは、コンピュータに内蔵するハードディスクなどの記録媒体にて記録させて、プログラムを提供することもできる。また、ネットワークを介したダウンロードによって、プログラムを提供することもできる。
【００８６】
なお、本発明にかかるプログラムは、コンピュータのオペレーションシステム（ＯＳ）の一部として提供されるプログラムモジュールのうち、必要なモジュールを所定の配列で所定のタイミングで呼出して処理を実行させるものであってもよい。その場合、プログラム自体には上記モジュールが含まれずＯＳと協働して処理が実行される。このようなモジュールを含まないプログラムも、本発明にかかるプログラムに含まれ得る。
【００８７】
また、本発明にかかるプログラムは他のプログラムの一部に組込まれて提供されるものであってもよい。その場合にも、プログラム自体には上記他のプログラムに含まれるモジュールが含まれず、他のプログラムと協働して処理が実行される。このような他のプログラムに組込まれたプログラムも、本発明にかかるプログラムに含まれ得る。
【００８８】
提供されるプログラム製品は、ハードディスクなどのプログラム格納部にインストールされて実行される。なお、プログラム製品は、プログラム自体と、プログラムが記録された記録媒体とを含む。
【００８９】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【図面の簡単な説明】
【００９０】
【図１】第１の実施の形態の排他制御不具合候補抽出システムの構成の具体例を示す図である。
【図２】排他制御関数候補・共有リソース名対応表の具体例を示す図である。
【図３】共有リソース仕様書の具体例を示す図である。
【図４】タスクメイン関数リストの具体例を示す図である。
【図５】排他制御関数抽出部１０３での処理の具体例を示すフローチャートである。
【図６】排他制御判定実行部１０４での処理の具体例を示すフローチャートである。
【図７】関数f1のコントロールフローグラフを示す図である。
【図８】関数f1_1のコントロールフローグラフを示す図である。
【図９】関数f1のフローグラフGraphを示す図である。
【図１０】関数f2のフローグラフGraphを示す図である。
【図１１】関数f1のイベント割当て後のノードの並びを示す図である。
【図１２】関数f2のイベント割当て後のノードの並びを示す図である。
【図１３】共有リソースのロック状態遷移の具体例を示す図である。
【図１４】排他制御不具合候補の出力の具体例を示す図である。
【図１５】第２の実施の形態の排他制御不具合候補抽出システムの構成の具体例を示す図である。
【図１６】共有リソース・ロックアンロック関数対応表の具体例を示す図である。
【図１７】共有リソース仕様書生成部２２０２および排他制御関数・共有リソース名対応表生成部２２０１での処理の具体例を示すフローチャートである。
【図１８】共有リソースＡにアクセスする関数のソースプログラムを示す図である。
【図１９】共有リソースＡにアクセスする関数のリストの具体例を示す図である。
【図２０】排他制御関数・共有リソース名対応表生成部２２０１が生成する排他制御関数候補・共有リソース名対応表の具体例を示す図である。
【図２１】関数f3のソースプログラムを示す図である。
【図２２】排他制御関数候補・共有リソース名対応表の具体例を示す図である。
【図２３】共有リソース仕様書の具体例を示す図である。
【図２４】関数f3のフローグラフGraphを示す図である。
【図２５】関数f3のイベント割当て後のノードの並びを示す図である。
【図２６】第３の実施の形態の排他制御不具合候補抽出システムの構成の具体例を示す図である。
【図２７】変更後の関数f3のソースプログラムを示す図である。
【図２８】共有リソースＤの変更後の共有リソース仕様書の具体例を示す図である。
【図２９】変更後の関数f3のイベント割当て後のノードの並びを示す図である。
【図３０】関数f1のソースプログラムを表わす図である。
【図３１】関数f2のソースプログラムを表わす図である。
【図３２】関数f2の第１の分岐のソースプログラムである。
【図３３】関数f2の第２の分岐のソースプログラムである。
【図３４】第４の実施の形態の排他制御不具合候補抽出システムの構成の具体例を示す図である。
【図３５】排他制御関数を呼び出す複数タスクが同時に実行されない場合に同排他制御関数を候補から除外する処理を示すフローチャートである。
【図３６】共有リソースアクセス関数（funcSetCommonResourceA）がブラウザタスクとワンセグタスクとから呼び出されている場合を表わす図である。
【図３７】共有リソースアクセス関数（funcSetCommonResourceB）がブラウザタスクとメールタスクとから呼び出されている場合を表わす図である。
【図３８】同時実行可能タスク組み合わせ表の具体例を示す図である。
【符号の説明】
【００９１】
１０１  ソースプログラム入力部、１０２  設計情報入力部、１０３  排他制御関数抽出部、１０４  排他制御判定実行部、１０５  排他制御不具合候補出力部、１０６  ソースプログラム、１０７  設計情報、１０３１  第１処理部、１０３２  第２処理部、２２０１  排他制御関数・共有リソース名対応表生成部、２２０２  共有リソース仕様書生成部、２２０３  タスクメイン関数リスト生成部、２５０１  共有リソース仕様書・ソースプログラム変更部。
【図１】
2010066889.tif 000003
【図２】
2010066889.tif 000004
【図３】
2010066889.tif 000005
【図４】
2010066889.tif 000006
【図５】
2010066889.tif 000007
【図６】
2010066889.tif 000008
【図７】
2010066889.tif 000009
【図８】
2010066889.tif 000010
【図９】
2010066889.tif 000011
【図１０】
2010066889.tif 000012
【図１１】
2010066889.tif 000013
【図１２】
2010066889.tif 000014
【図１３】
2010066889.tif 000015
【図１４】
2010066889.tif 000016
【図１５】
2010066889.tif 000017
【図１６】
2010066889.tif 000018
【図１７】
2010066889.tif 000019
【図１８】
2010066889.tif 000020
【図１９】
2010066889.tif 000021
【図２０】
2010066889.tif 000022
【図２１】
2010066889.tif 000023
【図２２】
2010066889.tif 000024
【図２３】
2010066889.tif 000025
【図２４】
2010066889.tif 000026
【図２５】
2010066889.tif 000027
【図２６】
2010066889.tif 000028
【図２７】
2010066889.tif 000029
【図２８】
2010066889.tif 000030
【図２９】
2010066889.tif 000031
【図３０】
2010066889.tif 000032
【図３１】
2010066889.tif 000033
【図３２】
2010066889.tif 000034
【図３３】
2010066889.tif 000035
【図３４】
2010066889.tif 000036
【図３５】
2010066889.tif 000037
【図３６】
2010066889.tif 000038
【図３７】
2010066889.tif 000039
【図３８】
2010066889.tif 000040