JP2012185539A - ソフトウェア検証支援装置、ソフトウェア検証支援方法及びソフトウェア検証支援プログラム - Google Patents

Abstract

【課題】検証モレを抑制したソフトウェアの検証を可能とするソフトウェア検証支援装置、ソフトウェア検証支援方法及びソフトウェア検証支援プログラムを提供することを課題とする。
【解決手段】検証要件に基づくソフトウェアの検証を支援するために、ソフトウェアから機能モデルを生成し、その生成した機能モデルに基づいて検証要件を生成することを特徴とし、検証要件を生成する際に、機能モデルから検証対象のパターンとマッチングする機能要素を抽出して、その抽出した機能要素に基づいて検証要件を生成したり、あるいは、機能モデルをスナップショットに分解して、その分解したスナップショットに基づいて検証要件を生成する。
【選択図】図１

Description

本発明は、検証要件に基づくソフトウェアの検証を支援するソフトウェア検証支援装置、ソフトウェア検証支援方法及びソフトウェア検証支援プログラムに関する。

ソフトウェアを開発した場合、そのソフトウェアが正常に動作するかを検証する必要がある。ソフトウェアを検証するためには、検証すべき要件を決定し、その検証要件に基づいて検証を行う。検証要件は、主として人によって決定され、装置によってソフトウェアの構造に基づいて自動生成される場合もある。特許文献１には、ハードウェア設計された検証対象回路に含まれるレジスタに対する検証処理を支援する検証支援について開示されており、検証対象回路の構成から検証対象となる検証対象レジスタを特定し、その特定された検証対象レジスタについてカバレッジ基準となる検証を要するパターンを抽出し、この抽出する際に検証対象回路に含まれるレジスタにおいてＤｅｃｌａｒｅ、Ｉｎｉｔｉａｌｉｚｅ、Ｒｅａｄ及びＷｒｉｔｅの４つの状態の中から生じる可能性のある状態遷移をあらわしたＤＩＲＷマトリックスを用意し、そのＤＩＲＷマトリックスを利用してマトリックスカバレッジ基準と実装カバレッジ基準との２種類のカバレッジ基準を決定する。

特開２０１０−３２８１号公報

ソフトウェアは、計算負荷低減や関連の無い機能をひとつのプログラムにまとめるなど、実装上の理由で必ずしも各機能を人が理解し易い形で記述されていない。また、ある一つのシステムのソフトウェアが、異なる複数の言語で記述されている場合もある。このような理由などからソフトウェアから各機能を読み解くのは難しく、スキルを要する作業である。そのため、人が検証要件を決定する場合、人によって検証要件の品質がばらつく。また、ソフトウェアの構造のみに基づいて検証要件を決定する場合、検証で網羅すべき基準がソフトウェアの構造に基づいたものになるため、検証すべき機能を網羅した検証要件を抽出できない。その結果、検証モレが生じる。また、上記の特許文献１の検証支援は検証対象がハードウェアの回路であり、レジスタの状態変化に着目して検証要件を抽出しているので、ソフトウェアの検証要件の抽出には適用できない。

そこで、本発明は、検証モレを抑制したソフトウェアの検証を可能とするソフトウェア検証支援装置、ソフトウェア検証支援方法及びソフトウェア検証支援プログラムを提供することを課題とする。

本発明に係るソフトウェア検証支援装置は、検証要件に基づくソフトウェアの検証を支援するソフトウェア検証支援装置であって、ソフトウェアから機能モデルを生成する機能モデル生成手段と、機能モデル生成手段で生成した機能モデルに基づいて検証要件を生成する検証要件生成手段とを備えることを特徴とする。

このソフトウェア検証支援装置では、機能モデル生成手段によって検証対象のソフトウェアから機能モデルを生成する。機能モデルは、ソフトウェアの機能を網羅したモデルであり、ソフトウェアの検証すべきある一面（ポイント）を抽出してモデル化したものである。また、機能モデルは、人に目に見える形で示すことができ、人がソフトウェアの機能を容易に読み解けるようにモデル化したものである。このような機能モデルを生成すると、ソフトウェア検証支援装置では、検証要件生成手段によってその機能モデルに基づいて検証要件を生成する。このように、ソフトウェア検証支援装置は、ソフトウェアから機能モデルを生成して、機能モデルから検証要件を生成することにより、機能モデルから検証すべき機能を網羅した検証要件を簡単かつ自動で生成でき、その検証要件に基づいてソフトウェアを検証することによって検証モレを抑制することができる。また、ソフトウェアが異なる複数の言語で記述されている場合でも、そのソフトウェアを機能モデルで統一的に扱うことができ、機能モデルから検証要件を簡単に生成できる。

なお、検証対象のソフトウェアの記述言語としては、様々な言語が適用可能であり、例えば、Ｃ言語等の手続き型言語、Ｓｉｍｕｌｉｎｋなどのモデリング言語がある。機能モデルとしては、例えば、制御フローであればデータフローグラフ[Data flow graph]モデル、制御モードの切り替えであれば状態遷移モデル、タイミングの問題であればＴｉｍｅｄ Ａｕｔｏｍａｔａがある。

本発明の上記ソフトウェア検証支援装置では、検証要件生成手段は、機能モデルから検証対象のパターンとマッチングする機能要素を抽出し、当該抽出した機能要素に基づいて検証要件を生成する構成としてもよい。このソフトウェア検証支援装置では、機能モデルから検証対象のパターン（すなわち、検証したい機能のパターン）にマッチングする機能要素を抽出して検証要件を生成することにより、機能モデルから検証すべき機能を網羅した検証要件を簡単かつ高精度に抽出できる。

本発明の上記ソフトウェア検証支援装置では、検証要件生成手段は、機能モデルをスナップショットに分解し、当該分解したスナップショットに基づいて検証要件を生成する構成としてもよい。このソフトウェア検証支援装置では、機能モデルをスナップショットに分解して検証要件を生成することにより、機能モデルから検証すべき機能を網羅した検証要件を簡単かつ高精度に抽出できる。

本発明の上記ソフトウェア検証支援装置では、検証要件生成手段で生成した検証要件からソフトウェアに入力するテストを生成するテスト生成手段を備える構成としてもよい。このソフトウェア検証支援装置では、検証要件からテストを自動生成し、このテストを入力してソフトウェアを検証することにより、検証すべき機能を効率的に検証することができる。

本発明の上記ソフトウェア検証支援装置では、各生成手段で生成されるものを表示する表示手段を備える構成としてもよい。表示手段で表示するものとしては、例えば、機能モデル、検証要件、検証対象パターン、分解されたスナップショット、検証要件に応じたテストがある。このソフトウェア検証支援装置では、各生成手段で生成したものを表示することにより、検証を行う人に機能モデルや検証要件などを明示することができ、人がソフトウェアの機能構成や検証すべき要件などを容易に認識できる。

本発明に係るソフトウェア検証支援方法は、検証要件に基づくソフトウェアの検証を支援するソフトウェア検証支援方法であって、ソフトウェアから機能モデルを生成する機能モデル生成ステップと、機能モデル生成ステップで生成した機能モデルに基づいて検証要件を生成する検証要件生成ステップとを含むことを特徴とする。このソフトウェア検証支援方法によれば、各ステップの処理を行うことにより、上記ソフトウェア検証支援装置の作用及び効果を奏する。

本発明に係るソフトウェア検証支援プログラムは、検証要件に基づくソフトウェアの検証を支援するためのソフトウェア検証支援プログラムであって、コンピュータに、ソフトウェアから機能モデルを生成する機能モデル生成機能と、機能モデル生成機能で生成した機能モデルに基づいて検証要件を生成する検証要件生成機能とを実現させることを特徴とする。このソフトウェア検証支援プログラムによれば、このプログラムをコンピュータに実行させることによって、上記ソフトウェア検証支援装置の作用及び効果を奏する。

本発明によれば、ソフトウェアから機能モデルを生成して、機能モデルから検証要件を生成することにより、機能モデルから検証すべき機能を網羅した検証要件を簡単かつ自動で生成でき、その検証要件に基づいてソフトウェアを検証することによって検証モレを抑制することができる。

本実施の形態に係る制御ソフトウェア検証装置の概念図である。 第１の実施の形態に係る制御ソフトウェア検証装置の構成図である。 制御ソフトウェアがＣ言語で記述されたプログラムの例である。 図３のプログラムのデータフローグラフである。 制御ソフトウェアが異なる言語で記述された場合の例であり、（ａ）が異なる言語で記述された制御ソフトウェアのデータフローグラフ（図４と同じデータフローグラフ）であり、（ｂ）が制御ソフトウェアの一部を記述したＳｉｍｕｌｉｎｋモデルであり、（ｃ）が制御ソフトウェアの一部を記述したＣ言語のプログラムである。 パターンマッチング手法で用いる検証パターンの例（（ａ）、（ｂ））である。 パターンマッチング手法によって図４のデータフローグラフから抽出された図６の各検証パターンにマッチングする機能要素の例である。 パターンマッチング手法によって抽出された図７の機能要素に対応する検証要件の例である。 スナップショット分解の概念図である。 スナップショット分解手法によって図４のデータフローグラフから分解されたスナップショットデータフローグラフの例（（ａ）、（ｂ）、（ｃ）、（ｄ））である。 スナップショット分解手法によって抽出された図１０（ｄ）のスナップショットデータフローグラフに対応する検証要件の例である。 検証手段の構成の例であり、（ａ）が実機検証試験の構成であり、（ｂ）がＨＩＬＳ試験の構成である。 検証対象プログラムへの監視情報の埋め込み手順である。 監視情報が埋め込まれたプログラムの例である。 第２の実施の形態に係る制御ソフトウェア検証装置の構成図である。 テスト入力生成のための命令が埋め込まれたプログラムの例である。

以下、図面を参照して、本発明に係るソフトウェア検証支援装置、ソフトウェア検証支援方法及びソフトウェア検証支援プログラムの実施の形態を説明する。なお、各図において同一又は相当する要素については同一の符号を付し、重複する説明を省略する。

本実施の形態では、本発明を、任意のシステムを制御する制御ソフトウェアを検証する制御ソフトウェア検証装置に適用する。本実施の形態に係る制御ソフトウェア検証装置は、検証対象の制御ソフトウェアが入力されると、制御ソフトウェアの検証要件を自動で生成し、その検証要件に応じて制御ソフトウェアを検証する。本実施の形態には、２つの形態があり、第１の実施の形態が基本の形態であり、第２の実施の形態が基本の形態に加えて制御ソフトウェアに入力するテストを自動生成する機能も有する形態である。本実施の形態に係る制御ソフトウェア検証装置は、制御ソフトウェアの検証だけを行う専用装置でもよいし、あるいは、汎用コンピュータで制御ソフトウェア検証用のアプリケーションを実行することによって構成されてもよい。

なお、検証対象のソフトウェアは、単一の言語で記述されてものでもよいし、あるいは、異なる複数の言語で記述されたものでもよい。記述言語としては、様々な言語が適用可能であり、例えば、Ｃ言語などの手続き型言語、Ｓｉｍｕｌｉｎｋなどのデータフロー型のモデリング言語がある。

まず、図１を参照して、本実施の形態に係る制御ソフトウェア検証装置の概要について説明する。図１は、本実施の形態に係る制御ソフトウェア検証装置の概念図である。図１では、実線で接続する構成が制御ソフトウェア検証装置の最大の構成であり、破線で接続する各構成（各組み合わせ）が制御ソフトウェア検証装置の最小の構成である。

まず、制御ソフトウェア検証装置では、検証対象の制御ソフトウェアから機能モデルを生成する。機能モデルは、制御ソフトウェアの機能を網羅したモデルであり、制御ソフトウェアの検証すべきある一面（ポイント）を抽出してモデル化したものである。また、機能モデルは、人の目に見える形で示すことができ、人が制御ソフトウェアの機能を容易に読み解けるようにモデル化したものである。このように機能モデルという形で人に明示することができるので、人が機能モデルを見て検証すべき機能が網羅されているかが容易に判る。

制御ソフトウェアを実現している制御機能は様々な側面を持つので、機能モデルとしては、その制御機能の各側面に応じたものでモデル化され、例えば、制御フローであればデータフローグラフモデル（ＤＦＧモデル）、制御モードの切り替えであれば状態遷移モデル、タイミングの問題であればＴｉｍｅｄ Ａｕｔｏｍａｔａがある。なお、本実施の形態では、データフローグラフモデルの場合を例にして説明する。

次に、制御ソフトウェア検証装置では、機能モデルから検証要件を生成する。検証要件は、制御ソフトウェアにおいて検証すべき機能の要件である。この検証要件の生成手法には、パターンマッチングとスナップショット分解の２つの手法がある。パターンマッチング手法では、機能モデルから検証パターンとマッチングする機能要素を抽出し、その抽出した機能要素に基づいて検証要件を生成する。検証パターンは、機能モデルの中で検証したい機能のパターンであり、人によって決められる。スナップショット分解手法では、機能モデルをスナップショットに分解し、その分解したスナップショットに基づいて検証要件を生成する。機能モデルのスナップショットは、機能モデルの中で特定の瞬間（タイミング）で成立しているパターンであり、機能モデルの中で可能な全てのパターンでもよいしあるいは一部のパターンでもよい。一部のスナップショットだけを用いる場合、制御機能の重要性などから、人によって決められる。

次に、制御ソフトウェア検証装置では、生成した検証要件に応じて制御ソフトウェアを検証する。ここでは、検査パスを決定するために、カバレッジモニタやテスト自動生成を利用する。カバレッジモニタでは、カバレッジ基準として制御ソフトウェアの検証すべき機能をどの程度網羅しているかを明示するために生成された検証要件をモニタに表示する。テスト自動生成では、生成された検証要件から制御ソフトウェアのテスト入力をモデル検査器を用いて自動生成する。そして、この生成されたテスト入力を制御ソフトウェアに入力して検証を行う。なお、検証については、通常は専用の装置や汎用コンピュータによって行うが、検証要件に基づいて人が行ってもよい。

図２を参照して、第１の実施の形態に係る制御ソフトウェア検証装置１について説明する。図２は、第１の実施の形態に係る制御ソフトウェア検証装置の構成図である。

制御ソフトウェア検証装置１は、検証対象の制御ソフトウェアＳが入力されると、制御ソフトウェアＳからデータフローグラフ（機能モデルＭ）を生成し、データフローグラフから検証要件を生成し、制御ソフトウェアＳに対して検証要件に応じた検証を行い、検証結果Ｒを出力する。そのために、制御ソフトウェア検証装置１は、機能モデル生成手段１０、検証要件生成手段１１、検証手段１２を備えている。

入力される制御ソフトウェアＳは、任意の言語によって記述され、ソフトウェアモデルＳＭやプログラムＳＰとして構成される。また、制御ソフトウェアＳは、単一の言語で記述されたものでもよいし、あるいは、複数の異なる言語で記述されたものでもよい。例えば、図３には、ある制御について、単一のＣ言語で記述されたＣコードプログラムＳＰ１の一例を示している。このＣコードプログラムＳＰ１では、変数ｔ以外は全てグローバル変数である。また、図５には、図３と同じ制御について２つの言語で記述された場合の一例を示しており、図（ｂ）に前半部がＳｉｍｕｌｉｎｋで記述されたＳｉｍｕｌｉｎｋモデルＳＭ２と図（ｃ）に後半部がＣ言語で記述されたＣコードプログラムＳＰ２を示している。

機能モデル生成手段１０では、制御ソフトウェアＳが入力されると、制御ソフトウェアＳから機能モデルＭとしてデータフローグラフを生成する。制御ソフトウェアＳは上記したように部分的に異なる言語で記述されることもあるが、データフローグラフという機能モデルを定義することにより、記述言語にかかわらず、「入力から出力へのデータフローとその切り替え」という制御機能の一面を抽出することができる。データフローグラフは、プログラムの演算や分岐をノード、変数をエッジで表現されたグラフとしてモデリングされたものである。この生成されたデータフローグラフ（機能モデルＭ）は、モニタ（表示手段）に表示され、検証対象の人が視覚的に確認できる。

データフローグラフの生成は、従来の手法を適用する。例えば、手続き型のプログラムの場合、プログラムの構文を解析し、そのプログラムの構文解析結果に基づいてプログラムのコントロールフローグラフ[Control flow graph]を生成し、コントロールフローグラフを用いてグローバル変数についての到達定義を算出し、各ノードの到達定義集合を用いて出力変数から到達定義を逆順に追跡し、その追跡結果に基づいて出力変数を出力とするデータフローグラフを生成する。

図４には、図３に示すＣコードプログラムＳＰ１のデータフローグラフＤＦＧ１を示している。データフローグラフは、演算が四角形で表され、セレクタが菱形で表され、入出力ポートが楕円で表され、参照する変数が矢印（エッジ）に付加され、参照する定数値が矢印の末端に付加される。このデータフローグラフＤＦＧ１は、「ｇｏｕｔ」を出力変数とするものである。したがって、データフローグラフＤＦＧ１では、「ｇｏｕｔ」に関連する演算フローだけが理解し易い形で抽出されている。

また、図５に示すＳｉｍｕｌｉｎｋモデルＳＭ２とＣコードプログラムＳＰ２で構成される制御ソフトウェアについても、図４と同様のデータフローグラフＤＦＧ１となる。図５（ａ）に示すように、このデータフローグラフＤＦＧ１のうち、破線で区切られる左上部分がＳｉｍｕｌｉｎｋモデルＳＭ２に対応する部分ＤＦＧ１_Ｍであり、右下部分がＣコードプログラムＳＰ２に対応する部分ＤＦＧ１_Ｐである。

検証要件生成手段１１では、機能モデルＭとしてデータフローグラフが生成されると、そのデータフローグラフから検証要件Ｃを生成する。検証要件の生成手法としては、上記したようにパターンマッチングによる手法とスナップショット分解による手法があり、いずれか一方の手法を用いるか、あるいは、２つの手法を組み合わせて用いる。

まず、パターンマッチングについて説明する。まず、データフローグラフの中から検証パターンにマッチングする部分（機能要素）を抽出する。検証パターンは、検証が必要とされるパターン（分岐、演算等）であり、局所的なパターンを持つ機能要素に相当する。検証パターンは、検証する人が予め決めて、制御ソフトウェア検証装置１に予め登録されているものでもよいし、あるいは、検証する人がモニタ表示されるデータフローグラフを見て選択されるものでもよい。検証パターンを容易に決めるために、制御ソフトウェア検証装置１内にデータベースを構築し、そのデータベースに定型的な検証パターンを登録しておき、データベースから検証パターンを選択できるようにするとよい。図６には、検証パターンの例として、図（ａ）に検証パターンＩＰ１と図（ｂ）に検証パターンＩＰ２を示している。このような検証パターンを、モニタに表示してもよい。図７には、図４に示すデータフローグラフＤＦＧ１において図６（ａ）に示す検証パターンＩＰ１にマッチングする部分ＩＰ１’と図６（ｂ）に示す検証パターンＩＰ２にマッチングする部分ＩＰ２’を示している。このようなデータフローグラフにおいて検証パターンにマッチングする部分を強調してモニタに表示してもよい。

次に、制御ソフトウェアＳから、データフローグラフにおいて検証パターンにマッチングする部分（機能要素）に相当する部分を抽出し、その制御ソフトウェアＳにおいて検証パターンに相当する部分から検証要件Ｃを生成する。このように人の目に見える形で判り易くモデル化されているデータフローグラフ（機能モデルＭ）から抽出される検証パターンにマッチングする部分を利用することにより、検証要件Ｃを容易に生成でき、検証モレを抑制できる。図８には、ＣコードプログラムＳＰ１において、図７で示される検証パターンＩＰ１にマッチングする部分（機能要素）ＩＰ１’と検証パターンＩＰ２にマッチングする部分（機能要素）ＩＰ２’に相当する各行を示しており、機能要素ＩＰ１’に相当する行が５−７行であり、機能要素ＩＰ２’に相当する部分が１７−１８行である。この例の場合、「ＣコードプログラムＳＰ１の５−７行と１７−１８行をカバーする検証を実行すること」が検証要件Ｃとなり、５−７行のパスの成立条件は（Ｐ＝＝ＴＲＵＥ ａｎｄ Ｒ＝＝ＴＲＵＥ）であり、１７−１８行のパスの成立条件は（Ｑ＝＝ＴＲＵＥ）である。生成された検証要件Ｃは、モニタに表示され、検証対象の人が視覚的に確認できる。

次に、スナップショット分解について説明する。図９の例で、スナップショット分解の概要を説明する。データフローＤＦは、処理Ａの出力変数ｅ１と処理Ｂの出力変数ｅ２がセレクタＳＬ１で切り替えられ、セレクタＳＬ１の出力変数が処理Ｃに入力され、処理Ｃの出力変数ｅ３と処理Ｄの出力変数ｅ４がセレクタＳＬ２で切り替えられて出力される。ここで、各セレクタＳＬ１，ＳＬ２で切り替えられるデータフローに対し、セレクタＳＬ１，ＳＬ２毎にエッジを一つずつ選択すると（すなわち、スナップショット分解）、入力から出力まで切り替えの無いデータフロー（スナップショット）が得られる。スナップショットＳＳ１は、セレクタＳＬ１で処理Ａの出力変数ｅ１が選択されかつセレクタＳＬ２で処理Ｃの出力変数ｅ３が選択されたデータフローである。スナップショットＳＳ２は、セレクタＳＬ１で処理Ｂの出力変数ｅ２が選択されかつセレクタＳＬ２で処理Ｃの出力変数ｅ３が選択されたデータフローである。スナップショットＳＳ３は、セレクタＳＬ２で処理Ｄの出力変数ｅ４が選択されたデータフローである。制御機能の観点からこれらスナップショットはある瞬間に成立している機能（制御モード）と考えることができ、制御機能全体はこれらの制御モードを適宜切り替えることで実現されていると考えることができる。したがって、このようなスナップショットはデータフローにおける各機能を構成要素に分解したものとして考えることができ、機能要素に応じて検証を行うことによりモレの無い検証ができる。

そこで、まず、データフローグラフに含まれるセレクタ毎にエッジを一つずつ選択し、入力から出力まで切り替えの無いスナップショットデータフローグラフを生成する。ここでは、全てのセレクタについての全ての切り替えの組み合わせを構成した場合の全てのパターンについてのスナップショットデータフローグラフを生成してもよいし、あるいは、一部のパターンについてのスナップショットデータフローグラフを生成してもよい。一部のパターンの場合には、検証する人が、生成するパターンを制御モードの重要性に応じて決めるようにするとよい。例えば、検証する人がインタラクティブに、モニタに表示されるデータフローグラフを見ながらデータフローグラフの中で切り替えられるエッジ等を選択できるようにするとよい。生成されたスナップショットデータフローグラフは、モニタに表示され、検証対象の人が視覚的に確認できる。

図１０には、図４に示すデータフローグラフＤＦＧ１をスナップショット分解した例を示しており、３つのセレクタＧＳＬ１、ＧＳＬ２，ＧＳＬ３について各エッジの切り替えの全ての組み合わせを考えることで、４つのスナップショットデータフローグラフＳＳＤＦＧ１，ＳＳＤＦＧ２，ＳＳＤＦＧ３，ＳＳＤＦＧ４が得られる。図（ａ）に示すスナップショットデータフローグラフＳＳＤＦＧ１は、セレクタＧＳＬ３で定数値０のエッジが選択された場合である。図（ｂ）に示すスナップショットデータフローグラフＳＳＤＦＧ２は、セレクタＧＳＬ１で変数ｘ＝０のエッジが選択された場合である。図（ｃ）に示すスナップショットデータフローグラフＳＳＤＦＧ３は、セレクタＧＳＬ１で変数ｘ＝ｇｉｎのエッジが選択された場合である。図（ｄ）に示すスナップショットデータフローグラフＳＳＤＦＧ４は、セレクタＧＳＬ２で変数ｘ＝ｇｉｎのエッジが選択された場合である。

次に、スナップショットデータフローグラフに相当する部分を制御ソフトウェアＳから抽出し、その制御ソフトウェアＳにおいてスナップショットデータフローグラフに相当する部分から検証要件Ｃを生成する。このように人の目に見える形で判り易く各機能要素に分解されたスナップショットデータフローグラフを利用することにより、検証要件を容易に抽出でき、検証モレも抑制できる。図１１には、ＣコードプログラムＳＰ１において、図１０（ｄ）に示されるスナップショットデータフローグラフＳＳＤＦＧ４に相当する行を示しており、四角形で囲んだ２、４、１１−１２、１６、２０行である。この例の場合、このパスの成立条件は（Ｐ＝＝ＦＡＬＳＥ ａｎｄ Ｑ＝＝ＦＡＬＳＥ）であり、これが検証要件Ｃとなる。生成されたこの検証要件Ｃは、モニタに表示され、検証対象の人が視覚的に確認できる。

検証手段１２では、検証要件Ｃが生成されると、検証要件Ｃに応じて制御ソフトウェアＳを検証し、検証結果Ｒを出力する。ここでは、生成された検証要件Ｃをガバレッジ基準として適用し、検証を行う。検証方法としては、従来の様々な方法を適用でき、例えば、検証要件Ｃ（すなわち、機能要素）に応じて、実機試験、ＨＩＬＳ[Hardware In the Loop Simulator]やＳＩＬＳ[Software In the LoopSimulator]などの閉ループシミュレーション、ユニットテストなどの制御ソフトウェアＳの一部分を切り出したテスト、モデル検査がある。出力される検証結果Ｒは、モニタに表示され、検証対象の人が視覚的に確認できる。

図１２（ａ）には検証手段１２の構成の一例として、実機検証試験における内部状態の監視システムを示している。この検証手段１２Ａは、制御対象１２ａを制御装置１２ｂで制御する実機システムに対して、試験条件入力装置１２ｃと内部状態監視装置１２ｄを備える。例えば、検証対象の制御ソフトウェアＳが自動車のエンジンを制御するためのソフトウェアの場合、制御対象１２ａはエンジンであり、制御装置１２ｂはエンジンを制御するためのＥＣＵ[Electronic Control Unit]である。制御装置１２ｂには、検証対象の制御ソフトウェアＳの実行ファイルが組み込まれる。試験条件入力装置１２ｃは、検証要件Ｃ毎に、検証要件Ｃを満たすための試験条件（テスト入力）を入力するための装置である。内部状態監視装置１２ｄは、試験条件を入力後、制御装置１２ｂによって制御対象１２ａを制御しているときに、制御装置１２ｂのＲＡＭ値などを監視することによって内部状態を監視する装置である。このように内部状態を監視することによって、検証要件Ｃが網羅された試験となっているか、検証要件Ｃ毎に制御ソフトウェアＳが検証要件Ｃを満たすように正常に動作しているかなどを検証する。この内部状態は、モニタに表示され、検証対象の人が視覚的に確認できる。

図１２（ｂ）には検証手段１２の構成の他の例として、ＨＩＬＳ試験における内部状態の監視システムを示している。この検証手段１２Ｂは、制御対象モデル演算装置１２ｅを制御装置１２ｂで制御するシミュレーションシステムに対して、試験条件入力装置１２ｃと内部状態監視装置１２ｄを備える。制御対象モデル演算装置１２ｅは、制御対象の動作をシミュレートするシミュレータである。このように、検証手段１２Ｂでは、検証手段１２Ａと比較すると実機の代わりにシミュレータ（制御対象モデル演算装置１２ｅ）を用いて検証を行う。

内部状態を監視する方法としては、様々な方法がある。その一例として、図１３を参照して、検証対象のプログラムＳＰに監視すべき情報を組み込む方法について説明する。まず、検証対象プログラムＳＰに監視コードを埋め込み、監視コード付プログラムＣＳＰを作成する。図１４には、図４に示すＣコードプログラムＳＰ１に、図１０（ｄ）に示されるスナップショットデータフローグラフＳＳＤＦＧ４から生成された検証要件Ｃであるパス成立条件（Ｐ＝＝ＦＡＬＳＥ ａｎｄ Ｑ＝＝ＦＡＬＳＥ）が成立したことを検証するために必要な監視コードＷＣ１，ＷＣ２，ＷＣ３，ＷＣ４，ＷＣ５，ＷＣ６，ＷＣ７を埋め込んだ監視コード付プログラムＣＳＰ１を示している。そして、その監視コード付プログラムＣＳＰをクロスコンパイルして実行ファイルＥＦを作成し、その実行ファイルＥＦを制御装置１２ｂに転送して、制御装置１２ｂに組み込む。これによって、図１２に示すような試験環境において、制御装置１２ｂに組み込まれた検証対象プログラムＳＰが検証要件Ｃを満たすように動作しているか否かを監視することが可能となる。

なお、上記のような実機やシミュレータを用いた検証について説明したが、制御ソフトウェアＳのユニットテストなどでも、同様に、検証要件Ｃをガバレッジ基準として適用した検証を行うことができる。

この制御ソフトウェア検証装置１によれば、制御ソフトウェアＳの機能構成を網羅しかつ視覚的に把握し易い機能モデルＭを生成し、機能モデルＭから検証要件Ｃを生成することにより、機能モデルＭから検証すべき機能を網羅した検証要件Ｃを簡単かつ自動で生成でき、その検証要件Ｃに基づいて制御ソフトウェアＳを検証することによって検証モレを抑制することができる。また、制御ソフトウェアＳが異なる複数の言語で記述されている場合でも、その制御ソフトウェアＳを機能モデルＭで統一的に扱うことができるので、機能モデルＭから検証要件Ｃを簡単に生成できる。また、機能モデルＭを用いて検証要件Ｃを生成することにより、人のスキルに依存しないで検証要件Ｃを生成して検証を行うことができる。

また、制御ソフトウェア検証装置１によれば、機能モデルＭから検証要件Ｃを生成するためにパターンマッチングやスナップショット分解を用いることにより、機能モデルＭから検証すべき機能を網羅した検証要件Ｃを簡単かつ高精度に抽出できる。また、制御ソフトウェア検証装置１によれば、各生成手段１０，１１，１２で生成したものをモニタ表示することにより、検証を行う人に機能モデルＭや検証要件Ｃなどを明示することができ、人が制御ソフトウェアＳの機能構成や検証すべき要件などを容易に理解できる。

図１５を参照して、第２の実施の形態に係る制御ソフトウェア検証装置２について説明する。図１５は、第２の実施の形態に係る制御ソフトウェア検証装置の構成図である。

制御ソフトウェア検証装置２は、第１の実施の形態に係る制御ソフトウェア検証装置１と比較すると、検証要件Ｃからテスト入力（テストベクタ）Ｔを自動で生成して検証を行う点が異なる。そのために、制御ソフトウェア検証装置２は、機能モデル生成手段２０、検証要件生成手段２１、検証手段２２及びテスト入力生成手段２３を備えている。なお、機能モデル生成手段２０、検証要件生成手段２１、検証手段２２は、第１の実施の形態に係る機能モデル生成手段１０、検証要件生成手段１１、検証手段１２と同様のものなので、説明を省略する。

テスト入力生成手段２３では、検証要件Ｃが生成されると、検証要件Ｃを満たすテスト入力Ｔを自動的に生成する。この生成手法としては、従来の手法を適用でき、例えば、ランダムテスト生成、モデル検査器を利用した手法がある。生成されたテスト入力Ｔは、モニタに表示され、検証対象の人が視覚的に確認できる。

一例として、図１６を参照して、モデル検査器を利用したテスト入力の生成について説明する。ここでは、図４に示すＣコードプログラムＳＰ１について、図１０（ｄ）に示されるスナップショットデータフローグラフＳＳＤＦＧ４から生成された検証要件Ｃのパス成立条件（Ｐ＝＝ＦＡＬＳＥ ａｎｄ Ｑ＝＝ＦＡＬＳＥ）を成立させるためのテスト入力Ｔを生成する場合について説明する。まず、図１６に示すように、ＣコードプログラムＳＰ１に、パス成立条件（Ｐ＝＝ＦＡＬＳＥ ａｎｄ Ｑ＝＝ＦＡＬＳＥ）を否定するような論理式を満たすべきプロパティＰ１及びその論理式に関連して必要な各コードＴＣ１，ＴＣ２，ＴＣ３，ＴＣ４，ＴＣ５，ＴＣ６を埋め込み、プロパティ付プログラムＰＳＰ１を作成する。そして、このプロパティ付プログラムＰＳＰ１をモデル検査器にかけ、論理式の条件が成立しない入力の判例として検証要件Ｃのパス成立条件（Ｐ＝＝ＦＡＬＳＥ ａｎｄ Ｑ＝＝ＦＡＬＳＥ）を満たすテスト入力Ｔを生成する。なお、Ｃ言語で記述されたプログラムの場合、ＣＢＭＣというモデル検査ツールを適用できる。

なお、このように生成されたテスト入力Ｔを用いて検証手段２２で検証を行う場合、主に、制御ソフトウェアＳのユニットテストなどが対象となり、制御ソフトウェアＳ単体の検証を行う。

制御ソフトウェア検証装置２は、第１の実施の形態に係る制御ソフトウェア検証装置１と同様の効果を有する上に、以下の効果も有している。制御ソフトウェア検証装置２によれば、検証要件Ｃからテスト入力Ｔを自動生成し、このテスト入力Ｔを入力して制御ソフトウェアＳを検証することにより、検証すべき機能を効率的に検証することができる。

以上、本発明に係る実施の形態について説明したが、本発明は上記実施の形態に限定されることなく様々な形態で実施される。

例えば、本実施の形態では制御ソフトウェアの検証要件を生成し、その検証要件に基づいて制御ソフトウェアの検証まで行う制御ソフトウェア検証装置に適用したが、ソフトウェアの検証要件やその検証要件に応じたテストを生成するためのソフトウェア検証支援装置に適用してもよい。また、ＣＤ−ＲＯＭなどの記憶媒体に格納されたプログラムやインタネットなどのネットワークを介して利用可能なプログラムなどに適用し、このようなプログラムをコンピュータ上で実行することによってソフトウェアの検証要件やその検証要件に応じたテストを生成する構成としてもよい。

また、本実施の形態では自動車などの制御に用いられる制御ソフトウェアに適用したが、制御以外にも様々なソフトウェアに適用可能である。

１，２…制御ソフトウェア検証装置、１０，２０…機能モデル生成手段、１１，２１…検証要件生成手段、１２，１２Ａ，１２Ｂ，２２…検証手段、１２ａ…制御対象、１２ｂ…制御装置、１２ｃ…試験条件入力装置、１２ｄ…内部状態監視装置、１２ｅ…制御対象モデル演算装置、２３…テスト入力生成手段。

Claims (7)

1. 検証要件に基づくソフトウェアの検証を支援するソフトウェア検証支援装置であって、
   ソフトウェアから機能モデルを生成する機能モデル生成手段と、
   前記機能モデル生成手段で生成した機能モデルに基づいて検証要件を生成する検証要件生成手段と、
   を備えることを特徴とするソフトウェア検証支援装置。
2. 前記検証要件生成手段は、機能モデルから検証対象のパターンとマッチングする機能要素を抽出し、当該抽出した機能要素に基づいて検証要件を生成することを特徴とする請求項１に記載のソフトウェア検証支援装置。
3. 前記検証要件生成手段は、機能モデルをスナップショットに分解し、当該分解したスナップショットに基づいて検証要件を生成することを特徴とする請求項１に記載のソフトウェア検証支援装置。
4. 前記検証要件生成手段で生成した検証要件からソフトウェアに入力するテストを生成するテスト生成手段を備えることを特徴とする請求項１〜請求項３のいずれか１項に記載するソフトウェア検証支援装置。
5. 前記各生成手段で生成されるものを表示する表示手段を備えることを特徴とする請求項１〜請求項４のいずれか１項に記載するソフトウェア検証支援装置。
6. 検証要件に基づくソフトウェアの検証を支援するソフトウェア検証支援方法であって、
   ソフトウェアから機能モデルを生成する機能モデル生成ステップと、
   前記機能モデル生成ステップで生成した機能モデルに基づいて検証要件を生成する検証要件生成ステップと、
   を含むことを特徴とするソフトウェア検証支援方法。
7. 検証要件に基づくソフトウェアの検証を支援するためのソフトウェア検証支援プログラムであって、
   コンピュータに、
   ソフトウェアから機能モデルを生成する機能モデル生成機能と、
   前記機能モデル生成機能で生成した機能モデルに基づいて検証要件を生成する検証要件生成機能と、
   を実現させることを特徴とするソフトウェア検証支援プログラム。

Images