(57)【要約】      （修正有）【課題】データを受け渡しながら動作するソフトウェアの不具合の検出を効率よく行う不具合検出装置を提供する。【解決手段】不具合検出装置１００は、ルール仕様生成部２１０と、不具合検出部２２０と、情報記憶部２３０を備える。情報記憶部は、ソフトウェアの仕様を、入力変数についての条件を示す情報と出力変数の値を示す情報とを含む一つ以上のルールにより記述した、ルール仕様２５０と、検出しようとする不具合の特徴を、ルール仕様の構文上及び意味上のパターンにより表した、不具合パターンリスト２６０とを記憶する。不具合検出部は、ルール仕様のルールと不具合パターンリストとを照合し、ルール仕様からパターンを満たすルールを抽出した、不具合の発生条件リストを生成し、出力変数についての不具合の有無を示す、不具合サマリを生成する。【選択図】図２
2019086953.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの仕様を、入力変数についての条件を示す情報と出力変数の値を示す情報とを含む一つ以上のルールにより記述した情報である、ルール仕様と、
検出しようとする不具合の特徴を、ルール仕様の構文上及び意味上のパターンにより表した情報を含む、不具合パターンリストと、
を記憶する情報記憶部と、
前記ルール仕様と前記不具合パターンリストとを照合し、前記ルール仕様から前記パターンを満たす前記ルールを抽出した情報である不具合の発生条件リストを生成する不具合検出部と、
を備える、不具合検出装置。
【請求項２】
請求項１に記載の不具合検出装置であって、
前記不具合検出部は、前記出力変数についての不具合の有無を示す情報である不具合サマリを生成する、
不具合検出装置。
【請求項３】
請求項１に記載の不具合検出装置であって、
前記不具合検出部は、
前記ルール仕様に基づき、データの出力側となる機能を構成する前記ルールと前記データの入力側となる機能を構成する前記ルールとの組み合わせである複数のルールペアを生成し、
前記ルールペアと前記不具合パターンリストとを照合し、前記パターンを満たす前記ルールペアを抽出した情報を前記不具合の発生条件リストとして生成する、
不具合検出装置。
【請求項４】
請求項３に記載の不具合検出装置であって、
前記不具合検出部は、前記ルールペアが前記意味上のパターンを満たしているか否かをＳＭＴソルバ（Satisfiability Modulo Theories solver）により判定する、
不具合検出装置。
【請求項５】
請求項１乃至４のいずれか一項に記載の不具合検出装置であって、
前記ルール仕様はＩＦ−ＴＨＥＮ形式で記述される、
不具合検出装置。
【請求項６】
請求項１乃至４のいずれか一項に記載の不具合検出装置であって、
前記ルール仕様は、決定表形式で記述される、
不具合検出装置。
【請求項７】
請求項１乃至４のいずれか一項に記載の不具合検出装置であって、
前記不具合の発生条件リストは、ＩＦ−ＴＨＥＮ形式で記述される、
不具合検出装置。
【請求項８】
請求項１乃至４のいずれか一項に記載の不具合検出装置であって、
前記不具合の発生条件リストは、決定表形式で記述される、
不具合検出装置。
【請求項９】
情報処理装置が、
ソフトウェアの仕様を、入力変数についての条件を示す情報と出力変数の値を示す情報とを含む一つ以上のルールにより記述した情報である、ルール仕様と、
検出しようとする不具合の特徴を、ルール仕様の構文上及び意味上のパターンにより表した情報を含む不具合パターンリストと、
を記憶するステップ、及び、
前記ルール仕様と前記不具合パターンリストとを照合し前記ルール仕様から前記パターンを満たす前記ルールを抽出した情報である不具合の発生条件リストを生成するステップ、
を実行する、不具合検出方法。
【請求項１０】
請求項９に記載の不具合検出方法であって、
前記情報処理装置が、前記出力変数についての不具合の有無を示す情報である不具合サマリを生成するステップをさらに実行する、
不具合検出方法。
【請求項１１】
請求項９に記載の不具合検出方法であって、
前記情報処理装置が、
前記ルール仕様に基づき、データの出力側となる機能を構成する前記ルールと前記データの入力側となる機能を構成する前記ルールとの組み合わせである複数のルールペアを生成するステップ、及び
前記ルールペアと前記不具合パターンリストとを照合し、前記パターンを満たす前記ルールペアを抽出した情報を前記不具合の発生条件リストとして生成するステップ、
を実行する、不具合検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、不具合検出装置、及び不具合検出方法に関する。
【背景技術】
【０００２】
特許文献１には「データを共有する複数のプログラムに潜在する類似のバグを検出するために、第一に、プログラムと潜在するバグの関係を明確にすること、第二に、プログラムと潜在するバグとデータ項目の関係を明確にする。」、「データを共有する複数のプログラムに潜在するバグを検出するバグ検出システムにおいて、各プログラムとそれらの参照するデータの関係を記憶する記憶手段と、バグの種類とそのバグの発生したデータとの関係を入力する入力手段と、当該入力内容と記憶手段の内容に基づき、プログラムとバグの関係を出力する出力手段とから構成する。」と記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１１−８５５６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ソフトウェアは一般に複数の機能を実現するプログラムや関数によって構成されており、これらの機能がデータベースやファイル等への入出力を介してデータを受け渡しながら動作する。各機能を実現するソースコードの作成に際しては、ソースコードに含まれている不具合（バグ）を検出して修正するデバッグ（Debug）を行うことにより不具合を取り
除く。
【０００５】
ここで上記の特許文献１では、あるデータ（変数）を参照もしくは更新する機能に不具合が検出されたとき、同じデータを参照もしくは更新する機能を特定することで、同じ不具合を含む可能性の高い機能を特定している。
【０００６】
しかし特許文献１では、データの具体的な値までは考慮していないため、例えば、同じ値を取る別のデータ（変数）を参照もしくは更新する機能については特定することができない。また不具合に関係する機能とデータ（変数）が特定されるだけでは、どのような条件の下で不具合が発生するかがわからないため修正箇所の特定に時間を要する。
【０００７】
本発明は、こうした背景に鑑みてなされたものであり、ソフトウェアの不具合の検出を効率よく行うことを可能とする、不具合検出装置及び不具合検出方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するための本発明のうちの一つは、不具合検出装置であって、ソフトウェアの仕様を、入力変数についての条件を示す情報と出力変数の値を示す情報とを含む一つ以上のルールにより記述した情報である、ルール仕様と、検出しようとする不具合の特徴を、ルール仕様の構文上及び意味上のパターンにより表した情報を含む、不具合パターンリストと、を記憶する情報記憶部と、前記ルール仕様と前記不具合パターンリストとを照合し、前記ルール仕様から前記パターンを満たす前記ルールを抽出した情報である不具合の発生条件リストを生成する不具合検出部と、を備える。
【０００９】
その他、本願が開示する課題、及びその解決方法は、発明を実施するための形態の欄、
及び図面により明らかにされる。
【発明の効果】
【００１０】
本発明によれば、ソフトウェアの不具合の検出を効率よく行うことができる。
【図面の簡単な説明】
【００１１】
【図１】不具合検出装置のハードウェア構成例を示す図である。
【図２】不具合検出装置が備える機能及び不具合検出装置が記憶する情報を示す図である。
【図３】ＩＦ−ＴＨＥＮ形式で記述されたルール仕様の例を示す図である。
【図４】不具合パターンリストの例を示す図である。
【図５】ＩＦ−ＴＨＥＮ形式で記述された不具合検出結果の例を示す図である。
【図６】不具合検出の処理を説明するフローチャートである。
【図７】決定表形式で記述されたルール仕様の例を示す図である。
【図８】決定表形式で記述された不具合検出結果の例を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照しつつ実施形態について説明する。以下の説明において、同一の又は類似する構成について同一の符号を付して重複した説明を省略することがある。
【００１３】
［第１実施形態］
図１に第１実施形態として示す不具合検出装置１００のハードウェア構成を、図２に不具合検出装置１００が備える機能及び不具合検出装置１００が記憶するデータを、夫々示している。
【００１４】
不具合検出装置１００は、ソフトウェア（例えば、金融、保険、製造、流通、通信、教育、医療等の業務に関するもの）の開発や保守に際して利用される情報処理装置（コンピュータ）である。不具合検出装置１０は、例えば、クラウドシステムにより提供されるクラウドサーバのように仮想的な情報処理資源を用いて実現されるものであってもよい。
【００１５】
ソフトウェアは、商品やサービス等に関する法的な規制、業務上の規則、基準等。ビジネスルール、システムルール、チェックルール等（以下、これらをルールと総称する。）に従ってその仕様が決定され設計がなされる。上記ルールは、例えば「もし〜ならば〜である」といった自然文による記述や「ＩＦ  Ａ＝１  ＡＮＤ  Ｂ＝２  ＴＨＥＮ  Ｒ＝１」というようにコンピュータにより解釈可能な所定の規則に従った記述、条件と結果の対応関係を表形式で定義した決定表による記述などの様々な形で表現される。以下、ソフトウェアの仕様をルールの集まりとして記述したものをルール仕様と称する。ルール仕様は、例えば、記号実行などのソースコード解析技術により、ソースコードから自動的に生成することができる。
【００１６】
不具合検出装置１００は、ルール仕様に含まれている不具合を検出する。不具合検出装置１００は、ルール仕様と、検出しようとする不具合の特徴をルール仕様の構文（syntax）上及び意味（semantics）上のパターンにより表した情報を含む不具合パターンリスト
（後述する不具合パターンリスト２６０）とを記憶し、ルール仕様のルールと不具合パターンリストとを照合し、ルール仕様から不具合パターンリストのパターン（条件）を満たすルールを抽出した情報（発生条件リスト）を含む不具合検出結果（後述する不具合検出結果２７０）を生成する。
【００１７】
不具合検出装置１００が生成する不具合検出結果には、不具合の有無を表す不具合サマリ（後述する不具合サマリ５１０）と、検出された不具合の一覧（後述する、検出された
不具合の発生条件リスト５２０）とが含まれる。
【００１８】
図１に示すように、不具合検出装置１００は、プロセッサ１１０、主記憶装置１２０、補助記憶装置１３０、入力装置１４０、出力装置１５０、及び通信装置１６０を備える。これらは図示しないバス等の通信手段を介して互いに通信可能に接続されている。
【００１９】
プロセッサ１１０は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）を用いて構成されている。プロセッサ１１０が、主記憶装置１２０に格納されているプログラムを読み出して実行することにより、不具合検出装置１００の様々な機能が実現される。
【００２０】
主記憶装置１２０は、プログラムやデータを記憶する装置であり、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、不揮発性半導体メモリ（ＮＶＲＡＭ（Non Volatile RAM））等である。
【００２１】
補助記憶装置１３０は、例えば、ハードディスクドライブ、ＳＳＤ（Solid State Drive）、光学式記憶装置（ＣＤ（Compact Disc）、ＤＶＤ(Digital Versatile Disc)等）、
ストレージシステム、ＩＣカード、ＳＤメモリカードや光学式記録媒体等の記録媒体の読取／書込装置、クラウドサーバの記憶領域等である。補助記憶装置１３０に格納されているプログラムやデータは主記憶装置１２０に随時読み込まれる。
【００２２】
入力装置１４０は、例えば、キーボード、マウス、タッチパネル、カードリーダ、音声入力装置等である。出力装置１５０は、ユーザに処理経過や処理結果等の各種情報を提供するユーザインタフェースであり、例えば、画面表示装置（液晶モニタ、ＬＣＤ（Liquid
Crystal Display）、グラフィックカード等）、音声出力装置（スピーカ等）、印字装置等である。尚、例えば、不具合検出装置１００が通信装置１６０を介して他の装置との間で情報の入力や出力を行う構成としてもよい。
【００２３】
通信装置１６０は、ＬＡＮやインターネット等の通信手段を介した他の装置との間の通信を実現する有線方式又は無線方式の通信インタフェースであり、例えば、ＮＩＣ（Network Interface Card）、無線通信モジュール、ＵＳＢ（Universal Serial Interface）モジュール、シリアル通信モジュール等である。
【００２４】
図２に示すように、不具合検出装置１００は、ルール仕様生成部２１０、不具合検出部２２０、情報記憶部２３０の各機能を備える。また不具合検出装置１００は、ソースコード２４０、ルール仕様２５０、不具合パターンリスト２６０、不具合検出結果２７０を、補助記憶装置１３０に記憶する。
【００２５】
ルール仕様生成部２１０は、記号実行等のソースコード解析技術により、ソースコード２４０からルール仕様２５０を生成する。
【００２６】
不具合検出部２２０は、事前に定義された不具合パターンリスト２６０に基づきルール仕様２５０の不具合を検出する。
【００２７】
情報記憶部２３０は、不具合検出部２２０がルール仕様２５０の不具合を検出した結果を不具合検出結果２７０として補助記憶装置１３０に記憶する。不具合検出部２２０が行う処理の詳細については後述する。
【００２８】
図３は、ルール仕様生成部２１０により生成され情報記憶部２３０が記憶するルール仕様２５０の一例である。ルール仕様２５０は、識別子（以下、機能ＩＤと称する）で識別
される機能ごとにまとめられた１つ以上のルール群から構成される。尚、以下の説明において、各機能を、機能１、機能２、・・・のように表記する。各ルール群は、１つ以上のＩＦ−ＴＨＥＮ形式で記述されたルールを含む。各ルールは識別子（以下、ルールＩＤと称する。）で識別される。以下、上記ルール群のことをルールセットとも称する。
【００２９】
同図に示すルール仕様２５０は、機能１のルールセット３１０、機能２のルールセット３２０、及び機能３のルールセット３３０の３つのルールセットを含む。このうちルールセット３１０は、ルールＩＤが１〜４の４つのルールを含む。またルールセット３２０は、ルールＩＤ１〜３の３つのルールを含む。またルールセット３３０は、ルールＩＤが１〜２の２つのルールを含む。尚、以下の説明において、各ルールを、ルール１、ルール２、・・・のように表記する。
【００３０】
各ルールは、条件部と結果部とを含む。ＩＦ−ＴＨＥＮ形式の記述においては、条件部と結果部は夫々、ＩＦ節とＴＨＥＮ節に相当する。例えば、図３に例示するルールセット３１０のルール１の場合、条件部は「ｐ＝１  ａｎｄ  ｑ＞ｒ」であり、結果部は「ｘ＝１」である。
【００３１】
以下の説明において、各ルールセットに対し、そのルールセットに含まれるルールの条件部に記述されている変数を入力変数と称し、結果部に記述されている変数を出力変数と称する。例えば、図３に例示するルールセット３１０において、入力変数はｐ、ｑ、ｒであり、出力変数はｘである。
【００３２】
各ルールセットにおいて、入力変数の具体的な値を定めると、各ルールの条件部が充足するか（条件部の論理式が真となるか）一意に定まる。ルールの条件部が充足すると、当該ルールの結果部が真となるように出力変数の値が定まる。例えば、図３に例示するルールセット３１０において、入力変数ｐ、ｑ、ｒの具体的な値が夫々、１、２、３であるときルール２の条件部が充足し、出力変数ｘの具体的な値が２に定まる。
【００３３】
例えば、ルール仕様２５０において、２つの機能がデータベースやファイル等への入出力を介してデータを受け渡す場合には、一方のルールセットの出力変数が他方のルールセットの入力変数に含まれる。例えば、図３に例示するルール仕様２５０において、機能１のルールセット３１０の出力変数ｘは、機能２のルールセット３２０の入力変数に含まれる。これは、機能１が変数ｘの値をデータベースやファイルに書き出し、機能２が変数ｘの値を同じデータベースやファイルから読み込んで参照等することを意味する。以下では、同じ変数を読み書きする複数の機能において、当該変数をルールセットの出力変数にもつ機能を「出力側機能」、当該変数をルールセットの入力変数にもつ機能を「入力側機能」と称する。
【００３４】
尚、２つの機能について、一方のルールセットの出力変数と他方のルールセットの入力変数が異なる場合に、入力変数と出力変数の対応関係の情報を別に用意し、データベースやファイル等への入出力を介してデータが受け渡されていることを表してもよい。例えば、図３に例示するルール仕様２５０において、機能３のルールセット３３０の出力変数ｎと、機能２のルールセット３２０の入力変数ｚとが対応している（データベースやファイル上では同じ値を指している）という別の情報により、これら機能間にデータの受け渡しがあることを表現してもよい。
【００３５】
図４は、情報記憶部２３０が記憶する不具合パターンリスト２６０の一例である。不具合パターンリスト２６０には、不具合検出装置１００が検出する不具合ごとの、その不具合の特長を記述した不具合パターンを示す情報を含む。尚、不具合パターンリスト２６０は、例えば、ユーザが作成する
【００３６】
同図に示す不具合パターンリスト２６０は、不具合Ａ（ゼロ除算）の不具合パターン４１０と、不具合Ｂ（関数ｆの引数不正）の不具合パターン４２０とを含む。各不具合パターンは、種別と条件式の各項目を有する１つ以上の判定条件から構成される。種別には、「構文」又は「意味」のいずれかが設定される。条件式には、不具合検出装置１００がルール仕様２５０に不具合を含むと判断するパターンが設定される。種別に「構文」が設定されている場合、条件式にはルール仕様２５０の構文（syntax）上の（変数に設定される具体的な値は考慮しない）パターンが設定される。種別に「意味」が設定されている場合、条件式にはルール仕様２５０の意味（semantics）上の（変数に設定される具体的な値
を考慮する）パターンが設定される。
【００３７】
例えば、図４に例示する不具合Ａの不具合パターン４１０は２つの判定条件を含む。１つ目の判定条件は構文上のパターンであり、条件式は「引数に出現（出力変数、／、２）」である。２つ目の判定条件は意味上のパターンであり、条件式は「出力変数＝０」である。
【００３８】
条件式に記載されている「出力変数」は、不具合判定中の出力変数が格納されるプレースホルダである。また条件式に記載されている「引数に出現（式、関数、Ｎ）」は、式が関数に渡される第Ｎ引数に構文上含まれることを表す関数で、Ｎには正整数が設定される。つまり、条件式「引数に出現（出力変数、／、２）」は、出力変数が、関数「／」（除算）の第２引数（除数）に構文上含まれることを表す。尚、本例ではプレースホルダ「出力変数」と関数「引数に出現」とを使用するが、これらを使用しないことも、またこれら以外のプレースホルダや関数を定義して使用することも可能である。
【００３９】
図５は、図３に例示したルール仕様２５０及び図４に例示した不具合パターンリスト２６０に基づき、不具合検出装置１００が生成した不具合検出結果２７０の例である。不具合検出結果２７０は、不具合サマリ５１０、検出された不具合の発生条件リスト５２０を含む。図５に示す不具合サマリ５１０の各行は、夫々、ルール仕様２５０中のルールセットの出力変数ごとに、その変数に関する不具合が含まれるか否かを示している。ユーザは不具合サマリ５１０を参照することで、出力変数ごとの不具合の有無を容易に把握することができる。
【００４０】
不具合サマリ５１０は、出力変数と、不具合パターンリスト２６０中の各不具合の有無とを含む。出力変数には、ルール仕様２５０中のルールセットの出力変数から一つが設定される。不具合の有無は、不具合パターンリスト２６０に設定されている不具合ごとに設定される。図５に例示する不具合サマリ５１０は、出力変数ｘに関して、不具合パターンリスト２６０中の不具合Ａと不具合Ｂが含まれることを示している。また出力変数ｍやｎに関して、不具合パターンリスト２６０中の不具合Ａや不具合Ｂが含まれていないことを示している。尚、本例では不具合があることを「●」、不具合がないことを「‐」で表しているが、これら以外の文字や記号により表現してもよい。
【００４１】
検出された不具合の発生条件リスト５２０は、不具合サマリ５１０で不具合を含むと示された出力変数と不具合ごとに、その不具合の発生条件を有する。図５に例示する、検出された不具合の発生条件リスト５２０は、出力変数ｘに関する不具合Ａの発生条件５３０、及び出力変数ｘに関する不具合Ｂの発生条件５４０を含む。
【００４２】
各不具合の発生条件は、ルール仕様２５０に含まれるルールのうち、不具合パターンリスト２６０で定義された不具合パターンを満たすルールを含む。例えば、図３に例示する機能１のルールセット３１０のルール４の条件部が充足する時、出力変数ｘの具体的な値が０となり、かつ、機能２のルールセット３２０のルール１又はルール２では条件部の除
数に出力変数ｘが出現する。つまり、出力変数ｘに関して、図４に例示する不具合Ａの不具合パターン４１０が満たされ、図５に示すように、出力変数ｘに関する不具合Ａの発生条件５３０は、ルールセット３１０のルール４と、ルールセット３２０のルール１及びルール２とを含む。
【００４３】
図５に示す、出力変数ｘに関する不具合Ａの発生条件５３０と、出力変数ｘに関する不具合Ｂの発生条件５４０は、いずれも複数の機能のルールを含むが、単一の機能のみに依存する不具合である場合、不具合の発生条件を当該機能のルールのみとすることも可能である。例えば、図５に例示する出力変数ｘに関する不具合Ｂの発生条件５４０には、図３に例示するルール仕様２５０における、機能３のルールセット３３０のルールが全て含まれる。これは、不具合Ｂの発生条件は機能３に依存せず、機能１のみに依存することを意味しており、不具合Ｂの発生条件５４０は、機能１のルールセット３１０のルール４のみとしてもよい。
【００４４】
検出された不具合の発生条件リスト５２０には、不具合の発生条件のほかに、その不具合の発生条件を満たす入力変数・出力変数の具体的な値の例を出力してもよい。例えば、図５に示す出力変数ｘに関する不具合Ｂの発生条件５４０について、この不具合の発生条件を満たす入力変数と出力変数の具体的な値の例として「ｐ＝２、ｑ＝０、ｒ＝０、ｘ＝０、ｎ＝１」を出力してもよい。
【００４５】
図６は、不具合の検出に際して不具合検出装置１００が行う処理（以下、不具合検出処理Ｓ６００と称する。）を説明するフローチャートである。以下、同図とともに不具合検出処理Ｓ６００について説明する。尚、不具合検出部２２０は、例えば、ユーザからの指示を契機として不具合検出処理Ｓ６００を開始する。また不具合検出部２２０は、例えば、スケジュールされたタイミングでバッチ処理等により自動的に不具合検出処理Ｓ６００を実行する。尚、以下において、符号の前に付している文字「Ｓ」は処理ステップを意味する。
【００４６】
まず不具合検出装置１００は、情報記憶部２３０が記憶しているルール仕様２５０を読み込むとともに（Ｓ６０１）、情報記憶部２３０が記憶している不具合パターンリスト２６０を読み込む（Ｓ６０２）。
【００４７】
続いて、不具合検出装置１００は、Ｓ６０１で読み込んだルール仕様２５０に基づきルールペアを生成する。ここでルールペアとは、データベースやファイル等への入出力を介してデータの受け渡しを行う２つの機能について、出力側機能のルールセットと入力側機能のルールセットの夫々からルールを１つずつ選択して組み合わせたものである。以下では、出力側機能のルールセットから選ばれたルールを「出力側ルール」と、また入力側機能のルールセットから選ばれたルールを「入力側ルール」と、夫々称する。例えば、図３に示すルール仕様２５０では、機能１と機能２、及び機能１と機能３が、夫々変数ｘの値を受け渡す出力側機能と入力側機能の組となっている。従って、この例の場合、不具合検出装置１００は、機能１と機能２の組から４×３＝１２個、機能１と機能３の組から４×２＝８個、合計２０個のルールペアを生成する。
【００４８】
尚、Ｓ６０３において、不具合検出装置１００が、ルール仕様２５０から直接ルールペアを生成する代わりに、ルール仕様２５０に基づき出力側機能と入力側機能のペアを全て生成した後、各機能ペアからルールペアを生成するようにしてもよい。
【００４９】
図６に戻り、Ｓ６０４では、不具合検出装置１００は、Ｓ６０３で生成した全てのルールペアについてＳ６０５〜Ｓ６０９の処理を実行する。
【００５０】
Ｓ６０５では、不具合検出装置１００は、Ｓ６０２で読み込んだ不具合パターンリスト２６０の全ての不具合についてＳ６０６〜Ｓ６０９の処理を実行する。
【００５１】
Ｓ６０６では、不具合検出装置１００は、現在処理中の不具合の不具合パターンにおいて「構文」を種別にもつ判定条件を、現在処理中のルールペアが満たしているか否かを判定する。不具合検出装置１００は、判定条件の条件式中にプレースホルダ「出力変数」がある場合、現在処理中のルールペアにおける出力側ルールの出力変数をプレースホルダに格納して判定を行う。ルールペアが構文上のパターンを満たしているか否かは、例えば、パターンマッチングにより判定することができる。「構文」を種別にもつ全ての判定条件をルールペアが満たしている場合（Ｓ６０６：ＹＥＳ）、処理はＳ６０７に進み、満たしていない場合（Ｓ６０６：ＮＯ）、処理はＳ６０５のループに戻る。
【００５２】
続いて、不具合検出装置１００は、現在処理中の不具合の不具合パターンにおいて「意味」を種別にもつ判定条件を、現在処理中のルールペアが満たしているか否かを判定する（Ｓ６０７）。ＩＦ−ＴＨＥＮ形式で記述されたルール仕様の場合、ルールペアが意味上のパターンを満たしているか否かは、例えば、ＳＭＴソルバ（Satisfiability Modulo Theories solver）を用いて判定することができる。「意味」を種別にもつ全ての判定条件
をルールペアが満たしている場合（Ｓ６０７：ＹＥＳ）、処理はＳ６０８に進み、そうでない場合（Ｓ６０７：ＮＯ）、処理はＳ６０５のループに戻る。
【００５３】
尚、本例では、Ｓ６０６で構文上のパターンを判定した後にＳ６０７で意味上のパターンを判定しているが、これらの処理の順序は逆にしてもよい。構文上のパターンの判定処理に時間がかかる場合、先に意味上のパターンの判定処理を行って構文上のパターンを判定するルールペアの数を減らすことで、不具合検出の処理時間を短縮することができる。
【００５４】
Ｓ６０８では、不具合検出装置１００は、現在処理中のルールペアにおける出力側ルールの出力変数に現在処理中の不具合が含まれていることを、不具合検出結果２７０中の不具合サマリ５１０に記録する。例えば、不具合検出装置１００は、図５に例示する不具合サマリ５１０において、当該出力変数の行の当該不具合の欄に「●」を記録する。
【００５５】
Ｓ６０９では、不具合検出装置１００は、Ｓ６０８で不具合が含まれていると記録した出力変数と不具合に関する発生条件として、検出された不具合の発生条件リスト５２０に現在処理中のルールペアを構成している２つのルールを追加する。尚、既に検出された不具合の発生条件リスト５２０に同じルールが含まれている場合、そのルールは検出された不具合の発生条件リスト５２０に追加しなくてもよい。
【００５６】
以上に説明したように、不具合検出装置１００は、データベースやファイル等への入出力を介してデータを共有する機能を有するソフトウェアについて、ルール仕様と不具合パターンリストとに基づき、データの具体的な値（意味上のパターン）を考慮して不具合を検出するので、ソフトウェアの不具合を効率よく確実に検出することができる。また不具合検出装置１００は、不具合の発生条件を発生条件リスト５２０として明確な形で出力するので、ユーザがデバッグ時の修正箇所の特定に要する時間を短縮することができる。このように不具合検出装置１００によれば、データを受け渡しながら動作するソフトウェアの不具合を効率よく検出することができる。そのため、ユーザはソフトウェアの修正箇所の特定や不具合の除去等の作業を効率よく行うことができる。
【００５７】
［第２実施形態］
第１実施形態では、ルール仕様２５０及び不具合検出結果２７０において、夫々が含むルールをＩＦ−ＴＨＥＮ形式で記述しているが、第２実施形態の不具合検出装置１００は、ルール仕様２５０及び不具合検出結果２７０の夫々が含むルールを決定表形式で記述す
る。尚、第２実施形態の不具合検出装置１００のハードウェア構成及び基本的なソフトウェア構成については、第１実施形態の不具合検出装置１００と同様である。以下では、主として第１実施形態と異なる構成について説明する。
【００５８】
図７は、第２実施形態の不具合検出装置１００のルール仕様生成部２１０により生成され情報記憶部２３０が記憶する、決定表形式で記述されたルール仕様２５０の例である。同図に示すように、このルール仕様２５０は、機能１のルールセット７１０、機能２のルールセット７２０、及び機能３のルールセット７３０を含む。
【００５９】
同図に示すように、各ルールセットは、ルールＩＤ、条件部、及び結果部の各列を含む一つ以上のルールの行で構成される。各列には列ラベルが付され、条件部の列ラベルには条件式が、結果部の列ラベルには結果変数が設定される。例えば、同図におけるルールセット７１０の場合、２列の条件部と１列の結果部とを含み、条件部の各列ラベルには夫々、ｐ、ｑ＞ｒが、結果部の各列ラベルにはｘが設定されている。
【００６０】
各ルールの条件部と結果部には、列ラベルに設定された条件式や結果変数の値、又は値の範囲が設定される。ルールの条件部の全ての列において、条件式の具体的な値がルールに設定された値、又は値の範囲である時、そのルールの条件部が充足する。例えば、図７に例示するルールセット７１０のルール１は、条件式ｐの値が１、かつ、条件式ｑ＞ｒの値がＴｒｕｅ（真）の時に条件部が充足し、結果変数ｘの値が１となることを意味する。またルールセット７２０のルール２は、条件式ｚの値がｚ＞１０の範囲、かつ、条件式ｙ／ｘの値が２以外の時に条件部が充足し、結果変数ｍの値が２となることを意味する。
【００６１】
図８は、図７に例示したルール仕様２５０、及び図４に例示した不具合パターンリスト２６０に基づき、第２実施形態の不具合検出装置１００の不具合検出部２２０が生成した不具合検出結果２７０の例である。同図に示す不具合検出結果２７０は、図５に示した不具合検出結果２７０における発生条件リスト５２０において、不具合の発生条件の各ルールを決定表形式で記述したものに相当する。
【００６２】
第２実施形態の不具合検出装置１００は、第１実施形態の不具合検出装置１００と同様に不具合検出処理Ｓ６００を実行する。尚、第２実施形態の不具合検出装置１００が実行する不具合検出処理Ｓ６００は、以下の点で第１実施形態の不具合検出装置１００と同様に不具合検出処理Ｓ６００と相違する。
【００６３】
まずＳ６０６では、不具合検出装置１００は、現在処理中の不具合（不具合パターン）において「構文」を種別にもつ判定条件を現在処理中のルールペアが満たしているか否かを判定する。ルールペアが構文上のパターンを満たしているか否かは、ルールペアに含まれるルールを決定表形式からＩＦ−ＴＨＥＮ形式に変換した上で、第１実施形態と同様にパターンマッチングを行うことにより判定することができる。またルールの決定表形式からＩＦ−ＴＨＥＮ形式への変換は、例えば、以下のようにして行うことができる。即ち、まず列ラベルに設定された条件式や結果変数を、ルールの対応する行に設定された値と等号（＝）で連結するか、又は値の範囲と連結する。続いて、条件部の列をすべて論理積（ａｎｄ）で連結し、「ＩＦ  条件部  ＴＨＥＮ  結果部」の形に並べる。必要ならば適宜括弧を追加してもよい。例えば、図７に例示するルールセット７１０のルール１をＩＦ−ＴＨＥＮ形式に変換すると「ＩＦ  ｐ＝１  ａｎｄ  （ｑ＞ｒ）＝Ｔｒｕｅ  ＴＨＥＮ  ｘ＝１」となる。
【００６４】
またＳ６０７では、不具合検出装置１００は、現在処理中の不具合の不具合パターンにおいて「意味」を種別にもつ判定条件を、現在処理中のルールペアが満たしているか否かを判定する。ルールペアが意味上のパターンを満たしているか否かは、Ｓ６０６と同様の
方法でルールを決定表形式からＩＦ−ＴＨＥＮ形式に変換した上で判定することができる。
【００６５】
尚、Ｓ６０６とＳ６０７において、ルールを決定表形式からＩＦ−ＴＨＥＮ形式に変換する代わりに、Ｓ６０１等で事前にルール形式をＩＦ−ＴＨＥＮ形式に変換してもよい。またＳ６０６でＩＦ−ＴＨＥＮ形式に変換せず、決定表形式のまま構文上のパターンを判定するようにしてもよい。
【００６６】
以上のように変更することで、不具合検出装置１００は、不具合の発生条件を決定表形式で出力するため、ＩＦ−ＴＨＥＮ形式よりも不具合の発生条件の可読性が上がり、デバッグ時の修正箇所の特定に要する時間を更に短縮することができる。
【００６７】
以上、本発明について実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また上記実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【００６８】
また上記の各構成、機能部、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、また
はＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【００６９】
また上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。例えば、実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
【００７０】
また以上に説明した不具合検出装置１００の各種機能部、各種処理部、各種データベースの配置形態は一例に過ぎない。各種機能部、各種処理部、各種データベースの配置形態は、不具合検出装置１００が備えるハードウェアやソフトウェアの性能、処理効率、通信効率等の観点から最適な配置形態に変更し得る。
【００７１】
また前述した各種データベースの構成（スキーマ（Schema）等）は、リソースの効率的な利用、処理効率向上、アクセス効率向上、検索効率向上等の観点から柔軟に変更し得る。
【符号の説明】
【００７２】
１００  不具合検出装置、２１０  ルール仕様生成部、２２０  不具合検出部、２３０  情報記憶部、２４０  ソースコード、２５０  ルール仕様、２６０  不具合パターンリスト、２７０  不具合検出結果、５２０  検出された不具合の発生条件リスト、Ｓ６００  不具合検出処理
【図１】
2019086953.tif 000003
【図２】
2019086953.tif 000004
【図３】
2019086953.tif 000005
【図４】
2019086953.tif 000006
【図５】
2019086953.tif 000007
【図６】
2019086953.tif 000008
【図７】
2019086953.tif 000009
【図８】
2019086953.tif 000010