JP2011215998A - プログラム検証装置 - Google Patents

Abstract

【課題】ユーザの判定作業を排除し、プログラムの検証を効率化することのできるプログラム検証装置を得る。
【解決手段】プログラムフロントエンド５によって、プログラム１を抽象構文木に変換し、プログラム抽象構文木８とする。仕様フロントエンド６によって、内部仕様２を抽象構文木に変換し、仕様抽象構文木９とする。抽象構文木検証部７は、プログラム抽象構文木８と仕様抽象構文木９とを比較し、検証対象プログラムが内部仕様２を満足するかを検証する。検証対象プログラムが内部仕様２を満足することができなかった場合は、検証結果をプログラムの誤り位置として示す検証結果報告書３を出力する。
【選択図】図１

Description

本発明は、ユーザがプログラムの入出力及び入出力間の関係を記述した内部仕様に基づいて作成したプログラムが、内部仕様に一致することを検証するプログラム検証装置に関するものである。

従来のプログラム検証装置では、プログラムの検証は実機あるいはシミュレータ上で検証対象のプログラムを動作させ、想定される入力を設定し、その際の出力を確認することでプログラムが仕様に一致しているかを検証していた。しかし、このような動的な試験では、一般に対象プログラムをブラックボックスとして試験するため、プログラムに間違いが存在している場合でも、間違いを検出するための適切な入力が設定されなければ、検出漏れが発生する。また、クロスコンパイル環境では、実機あるいはシミュレータがなければ試験が実施できないという問題がある。

一方、静的な解析を行う方法としては、例えば特許文献１に記載されたようなプログラム検証装置があった。このようなプログラム検証装置は、プログラムを入力としてロジックの解析を行い、設定したプログラムの入出力間の関係を示す入出力対応表を作成するものである。仕様との一致は、入出力対応表を基に人が目視で確認する。
このようなプログラム検証装置では、ロジック解析の際、対象とする出力データが２度以上更新されている場合は、最後のデータ更新処理のみを採用するため、結果が正しいにもかかわらずエラーとして認識してしまう可能性があった。例えば、ｒｅｓｕｌｔ＝（ｘ＋４）＊３という内部仕様について考える。この例では、対象とする出力データはｒｅｓｕｌｔである。この内部仕様に基づいて、ユーザがｒｅｓｕｌｔ＝ｘ＋４、ｒｅｓｕｌｔ＝ｒｅｓｕｌｔ＊３というプログラムを作成した場合、プログラムは正しく動作するが、入出力対応表には、最後のデータ更新処理であるｒｅｓｕｌｔ＝ｒｅｓｕｌｔ＊３のみが出力されるため、ユーザはプログラムを間違いと判断する。

特開平３−５７０３４号公報

上述した静的なロジック解析を行う検証装置は、入出力関連表に基づいて仕様との一致を人が目視によって確認しなければならなかった。プログラムの作成においては、論理的に等価な様々な記述方法が存在するが、従来の検証装置では、入出力関連表を出力する際には、複数の表現方法の中から、唯一の表現方法を選択することになる。従って、その記述が仕様の記述と異なる場合、その記述が一致するかの判断はユーザに委ねられることとなる。また、上述したように同じデータが２度以上更新されている場合には、最後のデータ更新処理のみを入出力表に出力するため、全ての更新処理を総合したプログラムが正しい場合でも、最後のデータ更新処理が仕様と異なる場合にはユーザは間違いと判断してしまうという問題があった。

本発明は、上記のような課題を解決するためになされたもので、ユーザの判定作業を排除し、プログラムの検証を効率化することのできるプログラム検証装置を得ることを目的とする。

この発明に係るプログラム検証装置は、検証対象プログラムが内部仕様を満足するかを検証するプログラム検証装置において、検証対象プログラムを抽象構文木に変換するプログラム変換手段と、内部仕様を抽象構文木に変換する内部仕様変換手段と、変換したそれぞれの抽象構文木を比較することで仕様に一致するか否かを検証する抽象構文木検証部とを備えたものである。

この発明のプログラム検証装置は、検証対象プログラムから生成した抽象構文木と内部仕様から生成した抽象構文木とを比較して仕様に一致するか否かを検証するようにしたので、ユーザの判定作業を不要とし、プログラムの検証を効率化することができる。

この発明のプログラム検証装置とその処理プロセスを示すブロック図である。 この発明のプログラム検証装置のプログラム抽象構文木と仕様抽象構文木との比較概要を示す説明図である この発明のプログラム検証装置の抽象構文木検証部とその処理プロセスを示すブロック図である。 この発明のプログラム検証装置の抽象構文木検証部の比較手順を示したフローチャートである。 この発明のプログラム検証装置の抽象構文木の一致判定手順全体を示したフローチャートである。 この発明のプログラム検証装置の抽象構文木の一致判定手順の詳細を示したフローチャートである。 この発明のプログラム検証装置の抽象構文木を用いた一致判定手順の概要を示した説明図である。 この発明のプログラム検証装置の同一アルゴリズムで入出力変数が異なるプログラム例を示す説明図である。 この発明のプログラム検証装置のプログラムが対象とする入出力変数を定義する入出力仕様を示す説明図である。 この発明のプログラム検証装置の入出力仕様で定義した変数間の関係を示す動作仕様の説明図である。 この発明のプログラム検証装置の仕様フロントエンドの動作例を示す説明図である。 この発明のプログラム検証装置の内部仕様を基にユーザが作成したプログラムを示す説明図である。 この発明のプログラム検証装置の動作仕様と入出力仕様要素１から生成される抽象構文木を示す説明図である。 この発明のプログラム検証装置のプログラムの回路０から生成される抽象構文木を示す説明図である。 この発明のプログラム検証装置の検証結果報告書の一例を示す説明図である。 この発明のプログラム検証装置の動作仕様と入出力仕様要素２から生成される抽象構文木を示す説明図である。 この発明のプログラム検証装置のプログラムの回路３から生成される抽象構文木を示す説明図である。 この発明のプログラム検証装置の動作仕様と入出力仕様要素３から生成される抽象構文木を示す説明図である。 この発明のプログラム検証装置のプログラムの回路６から生成される抽象構文木を示す構成図である。 この発明のプログラム検証装置の実施の形態２の入出力仕様を示す説明図である。 この発明のプログラム検証装置の実施の形態２の動作仕様を示す説明図である。 この発明のプログラム検証装置の実施の形態２のプログラムを示す説明図である。 この発明のプログラム検証装置のプログラム回路０の抽象構文木を示す説明図である。 この発明のプログラム検証装置のプログラム回路３の抽象構文木を示す説明図である。 この発明のプログラム検証装置の実施の形態２の内部仕様を変換した抽象構文木を示す説明図である。 この発明のプログラム検証装置の実施の形態３の内部仕様（動作仕様のみ）を示す説明図である。 この発明のプログラム検証装置の実施の形態３の内部仕様を基にユーザが作成したプログラムを示す説明図である。 この発明のプログラム検証装置の実施の形態３の内部仕様を変換した抽象構文木を示す説明図である。 この発明のプログラム検証装置の実施の形態３のプログラムを変換した抽象構文木を示す説明図である。 この発明のプログラム検証装置における複数の動作仕様を含んだ内部仕様を示す説明図である。

実施の形態１．
図１は、この発明の実施の形態１によるプログラム検証装置とその処理プロセスを示す説明図である。
図１に示すプログラム検証装置４は、プログラム１及び内部仕様２を入力とし、静的解析を行い、出力ファイルとしてプログラムの検証結果を検証結果報告書３として出力する。尚、本発明は静的なプログラム検証であるため、実機あるいはシミュレータは不要である。

プログラム検証装置４は、プログラム１の静的解析を実施するために、プログラムフロントエンド５、仕様フロントエンド６、抽象構文木検証部７の処理手段を備える。以下、各々の処理プロセスの機能について説明する。

プログラムフロントエンド５は、プログラム１を入力として抽象構文木への変換を行うプログラム変換手段を構成する。変換の際、エラー発生時に識別を容易にする情報として、高級言語では行番号、シーケンスプログラムでは回路のステップ番号などを持たせる。ステップは、シーケンスプログラムにおいてプログラムのサイズを表す値であり、プログラム全体で一意に付加されるため回路の識別に使用可能である。また、抽象構文木比較の効率化のために、抽象構文木毎に変換の際に抽象構文木内のノード数、及びノード名を記憶する。抽象構文木の詳細な解析を行う前に、これらの情報を比較し、一致しなければ不一致として解析を終了することで、解析時間を短縮することが可能である。プログラム抽象構文木８は、プログラムフロントエンド５の出力を示している。

仕様フロントエンド６は、入出力変数とその変数間の関連を記述した内部仕様２を入力として抽象構文木への変換を行う内部仕様変換手段を構成する。変換の際、入出力仕様の行番号などエラー発生時に識別可能な番号を持たせる。また、検証の効率化のために、抽象構文木毎に変換の際に抽象構文木内のノード数、及びノード名を記憶する。仕様抽象構文木９は仕様フロントエンド６の出力を示している。

抽象構文木検証部７は、図２に示すように、プログラム抽象構文木８が仕様抽象構文木９の何れかに一致するかを順に比較する。一致する仕様抽象構文木９が存在しない場合には、プログラム抽象構文木８に対して等価な抽象構文木への変換や最適化を実施し、再度比較を実施する。尚、この比較処理では、プログラムフロントエンド５及び仕様フロントエンド６による抽象構文木への変換の際に付加したノード数、ノード名の情報を用いた単純な比較処理を最初に実施し、詳細な解析は上記条件を満足した抽象構文木に対して実施することで、検証効率を向上することが可能である。

図３は、抽象構文木検証部７の内部を示す構成図である。
抽象構文木検証部７は、抽象構文木を最適化するための最適化機能を有する最適化部１０と、等価な抽象構文木に変換するための等価抽象構文木変換機能を有する等価回路変換部１１と、等価回路変換部１１における等価変換のパターンを記憶したテンプレート１６と、これら最適化部１０及び等価回路変換部１１を適宜用いて、プログラム抽象構文木８と仕様抽象構文木９との一致比較を行う抽象構文木比較部１２と、抽象構文木比較部１２における比較の結果、一致しなかったプログラム抽象構文木８を記憶するためのプログラム抽象構文木検証結果記憶部１３と、一致した仕様抽象構文木９を記憶するための内部仕様抽象構文木検証結果記憶部１４と、これらプログラム抽象構文木検証結果記憶部１３と内部仕様抽象構文木検証結果記憶部１４との結果に基づいて検証結果をユーザに報告するための検証結果報告部１５からなる。

最適化部１０における最適化機能とは、ユーザの冗長な記述を最適化する中間変数の削除、論理条件の最適化といった、プログラムとして等価な抽象構文木への変換機能を提供するものである。等価回路変換部１１における等価抽象構文木変換機能とは、左右のノードの入れ替え、及びドモルガンの定理の変換といった、抽象構文木として等価である異なる抽象構文木への変換機能を提供するものである。

抽象構文木比較手順を図４に示す。抽象構文木比較部１２は、ステップＳＴ１０で、解析対象の抽象構文木をプログラム抽象構文木８の先頭に設定した後、プログラム抽象構文木８の全てを検証するまで（ステップＳＴ１１〜ステップＳＴ２２）、繰り返し全ての仕様抽象構文木９との抽象構文木比較（ステップＳＴ１３〜ステップＳＴ１６）を行う。ステップＳＴ１４において二つの抽象構文木が一致すれば、一致した仕様抽象構文木９の識別子（変換の際に記憶した行番号など）を内部仕様抽象構文木検証結果記憶部１４に登録し（ステップＳＴ１５）、そのプログラム抽象構文木８の検証を終了する。

一方、ステップＳＴ１４において一致しない場合には、等価回路変換部１１により、プログラム抽象構文木８を等価な抽象構文木に変換し（ステップＳＴ１７、ＳＴ１８）、仕様抽象構文木９との比較を再度行う。等価回路変換部１１は、等価な抽象構文木のテンプレートをテンプレート１６として保持し、対象の抽象構文木の一部をテンプレート１６に基づいて置換する。例えば、対象の抽象構文木の左右のノードの入れ替えを行う。テンプレート１６に基づく等価な抽象構文木への変換を全て行っても一致する仕様抽象構文木９が見つからない場合には、プログラム抽象構文木８に対して最適化部１０により最適化を行い（ステップＳＴ１９、ＳＴ２１）、再度抽象構文木を比較する。等価な抽象構文木への変換、及び抽象構文木の最適化を行っても、一致する仕様抽象構文木９が見つからなければ、対象のプログラム抽象構文木８の識別番号（抽象構文木生成の際に記憶した行番号、あるいはステップ番号）をプログラム抽象構文木検証結果記憶部１３に記憶する（ステップＳＴ２０）。

次に、図４で示したステップＳＴ１４における抽象構文木の一致判定手順について説明する。二つの抽象構文木に対してノード数が一致し、抽象構文木内に含まれるノード名が一致し、抽象構文木を根から順に辿った左右のノード配置（以下、抽象構文木の構造と称す）が一致し、且つ各ノードの名前が一致していれば二つのノードは一致していると判断する。一方、ノード数が異なる、抽象構文木に含まれるノード名が異なる、抽象構文木を根から順に辿った左右のノード配置が異なる、あるいは何れかのノードの名前が異なる場合は非一致と判断する。

上記の抽象構文木の一致判定手順をフローチャートで示したものが図５及び図６であり、以下、これらフローチャートを用いてその手順を説明する。
一致判定では、初めに、処理時間が短く簡易な抽象構文木のノード数比較（ステップＳＴ３０）、ノード名比較（ステップＳＴ３１）により、詳細比較を行う対象を限定する。これらステップＳＴ３０，ＳＴ３１において、ノード数、ノード名が一致したものに対しては、ステップＳＴ３２以下に示す詳細な抽象構文木の一致判定を行う。この一致判定では、比較を行う二つの抽象構文木の根を解析対象のノードとしてそれぞれ記憶し（ステップＳＴ３２）、ノード比較処理（ステップＳＴ３３〜ＳＴ３５）を呼び出す。フローチャートでは、プログラム抽象構文木の解析対象ノードをｐ、仕様抽象構文木の解析対象ノードをｓで表す。

ノード比較処理では、図６に示すように、両ノードの名前が一致していれば（ステップＳＴ４０）、ステップＳＴ４１以降で子ノードの解析を行う。子ノードの解析は左子ノード→右子ノードの順に行う。両ノードの左子ノードが存在していれば（ステップＳＴ４１，ＳＴ４２）、解析対象ノードを左子ノードに設定して、ノード比較処理を呼び出す（ステップＳＴ４３）。ステップＳＴ４２がＮＯの場合には、一方のノードのみが左子ノードを持ち、抽象構文木は一致しないため、偽を返す。また、左子ノードのノード比較処理結果が偽の場合には、抽象構文木は一致しないため、偽を返す（ステップＳＴ４４）。ステップＳＴ４１において両ノードの左子ノードが存在せず、また、ステップＳＴ４４において、それまでの比較結果が真である場合は、右子ノードの解析（ステップＳＴ４５）に移る。両ノードの右子ノードが存在していれば（ステップＳＴ４５，ＳＴ４６）、解析対象ノードを右子ノードに設定して、ノード比較処理を呼び出す（ステップＳＴ４７）。ステップＳＴ４６がＮＯの場合には、一方のノードのみが右子ノードを持ち、抽象構文木は一致しないため、偽を返す。また、右子ノードのノード比較結果が偽の場合には、抽象構文木は一致しないため、比較結果として偽を返す（ステップＳＴ４８）。両ノードの右子ノードが存在せず、比較結果が真のままの場合は、真を返す。

この比較手順を実際の抽象構文木に対して適用した例を図７に示す。図７において（ａ）はプログラム抽象構文木、（ｂ）は仕様抽象構文木を示している。
図７では、抽象構文木から括弧内の番号順にノードの比較を行っている。例では、（１）、（２）までの抽象構文木の構成が一致しているが、（３）の比較においてノード名が異なっているため、その時点で解析を終了し、結果は偽となる。結果が偽として確定しているため、図の（４）の評価は行わない。

次に、プログラム検証装置４の動作の流れを説明する。ここでは、実例として論理式の場合を説明する。
図８はプログラム例であり、図９は入出力を定義した入出力仕様である。図９に示すような入出力仕様は、図８に示すようなプログラムにおいて共通のアルゴリズムで処理する入出力のみを定義する。入出力仕様には、入出力間の関連は含まない。入出力間の関連は、動作仕様に記述する。図１０に動作仕様の例を示す。図１０の動作仕様は、Ｙｏｕｔ１＝Ｘｉｎ１ ＯＲ Ｘｉｎ２であり、Ｘｉｎ１あるいはＸｉｎ２が真である場合に、Ｙｏｕｔ１が真となることを意味する。この動作仕様の各要素Ｙｏｕｔ１、Ｘｉｎ１、Ｘｉｎ２は、入出力仕様のラベルを示す。仕様フロントエンドは、図１１に示すように動作仕様の各要素と同名の入出力仕様のラベルを持つ表から、データを１行ずつ読み込んで、対象の要素と置き換えを行う。

結果として、仕様フロントエンド６は、入出力仕様から３行分の入力データを読み込んで、以下の３つの抽象構文木を生成する。
Ｙ１＝Ｘ１ ＯＲ Ｘ２・・・入出力仕様第１行より生成
Ｙ２＝Ｘ３ ＯＲ Ｘ４・・・入出力仕様第２行より生成
Ｙ３＝Ｘ５ ＯＲ Ｘ６・・・入出力仕様第３行より生成

図１２は、内部仕様２としての図９及び図１０に示す入出力仕様及び動作仕様に基づいてユーザが作成したプログラムである。入力仕様要素１に対応するのがステップ０の回路（以下、回路０）であり、要素２に対応するのがステップ３の回路（以下、回路３）であり、要素３に対応するのがステップ６の回路（以下、回路６）である。
図１３は、仕様フロントエンド６によって入出力仕様第１行に対応する内部仕様を抽象構文木に変換した結果を示すものである。図１４は、プログラムフロントエンド５によって回路０を抽象構文木に変換した結果である。図１３及び図１４に示す二つの抽象構文木は要素数、抽象構文木の構造、ノードの名前全てが完全に一致しているため、回路０は内部仕様を満足している。

抽象構文木比較部１２は、プログラムから生成されたそれぞれのプログラム抽象構文木８に対して、最適化部１０や等価回路変換部１１を用いて、最適化、等価な回路への変換を行い、仕様抽象構文木９との比較を行う。一致する内部仕様を検出した場合は、対応する仕様抽象構文木９の識別子（変換の際に付加した入出力仕様の行番号などの情報）を内部仕様抽象構文木検証結果記憶部１４に記憶する。一方、一致する内部仕様が検出されない場合、プログラム抽象構文木検証結果記憶部１３に対象のプログラム抽象構文木の識別子（変換の際に付加した行番号などの情報）を記憶する。

検証結果報告部１５は、プログラム抽象構文木検証結果記憶部１３におけるプログラム抽象構文木検証結果と、内部仕様抽象構文木検証結果記憶部１４における内部仕様抽象構文木検証結果を基に検証結果を報告する。内部仕様の全ての要素が内部仕様抽象構文木検証結果記憶部１４に登録されていれば、全ての内部仕様を満足しているため、ＯＫを出力する。一方、全ての内部仕様が登録されていなければ、対応するプログラムが存在しない要素番号を報告書に出力する。即ち、このような場合、検証結果報告部１５は、検証結果をプログラムの誤り位置として示す検証結果報告書３を出力する。

図１５における［ｅｒｒｏｒ１］は、内部仕様のエラー例である。また、プログラム抽象構文木検証結果記憶部１３には、一致する内部仕様が存在しないプログラムの行番号が登録されるため、その情報を検証結果報告書に出力する。図１５における［ｅｒｒｏｒ２］は、プログラムのエラー例である。

図１６は、仕様フロントエンド６によって入出力仕様要素第２行に対応する内部仕様を抽象構文木に変換した結果である。また、図１７は、プログラムフロントエンド５によって回路３を抽象構文木に変換した結果である。図１２の回路３は、ユーザは入力変数の順番を内部仕様と逆でプログラムを作成している。抽象構文木検証部７は、一致する抽象構文木が存在しない場合、等価回路変換部１１における等価抽象構文木変換機能によって抽象構文木の左右のノードを入れ替える機能を持つ。図１７の抽象構文木のＯＲノードの左右のノードを入れ替えると図１６と一致するため、回路３は内部仕様を満足する。このように、抽象構文木検証部７は、抽象構文木の左右位置が異なる場合も同様の解析木として判断することが可能である。

図１８は、仕様フロントエンド６によって入出力仕様要素第３行に対する内部仕様を抽象構文木に変換した結果である。図１９は、プログラムフロントエンド５によって回路６を抽象構文木に変換した結果である。回路６は、ユーザが入力変数Ｘ５を冗長に記述しているため、図１９の抽象構文木は図１８の内部仕様の抽象構文木と異なる。この例では、等価な抽象構文木に変換しても全て一致しない。等価変換で一致しない場合、抽象構文木比較部１２は、最適化部１０における抽象構文木最適化機能に基づいて、抽象構文木を最適化する。図１９の抽象構文木に対して論理条件の最適化を行うと、冗長なＸ５ノードが削除され、図１８の抽象構文木と全く同じ構成となる。従って、回路６は内部仕様を満足する。

以上説明したように、実施の形態１のプログラム検証装置によれば、検証対象プログラムが内部仕様を満足するかを検証するプログラム検証装置において、検証対象プログラムを抽象構文木に変換するプログラム変換手段と、内部仕様を抽象構文木に変換する内部仕様変換手段と、変換したそれぞれの抽象構文木を比較することで仕様に一致するか否かを検証する抽象構文木検証部とを備えたので、ユーザの判定作業を不要とし、プログラムの検証を効率化することができる。

また、実施の形態１のプログラム検証装置によれば、抽象構文木検証部は、抽象構文木を比較した結果、一致する抽象構文木が存在しない場合は、検証対象プログラムから生成した抽象構文木を所定のテンプレートに基づいて等価な抽象構文木に変換して比較するようにしたので、左右のノードの入れ替えといった変換が行え、確実な検証を行うことができる。

また、実施の形態１のプログラム検証装置によれば、抽象構文木検証部は、抽象構文木を比較した結果、一致する抽象構文木が存在しない場合は、検証対象プログラムから生成した抽象構文木を、そのプログラムとして等価な抽象構文木に最適化して比較するようにしたので、冗長な記述を最適化する中間変数の削除や論理条件の最適化を行うことができ、その結果、確実な検証を行うことができる。

また、実施の形態１のプログラム検証装置によれば、抽象構文木検証部は、一致しない抽象構文木を検証結果として記憶し、この検証結果を検証対象プログラムの誤り位置として出力するようにしたので、仕様に対するプログラムの誤りやプログラムの欠落を報告することができ、ユーザのプログラム修正を容易にすることができる。

実施の形態２．
実施の形態２は、仕様が数式の例であり、プログラム検証装置の構成については実施の形態１と同様であるため、ここでの説明は省略する。
図２０は、実施の形態２におけるプログラムの入出力仕様を定義した入出力仕様である。また、図２１は、入出力間の関係を示す動作仕様である。動作仕様は、Ｘｉｎ１＊Ｘｉｎ２＋Ｘｉｎ３の結果をＹｏｕｔに出力することを意味する。図２０の入出力仕様、及び図２１の動作仕様は、以下のように展開される。

Ｄ４＝Ｄ１＊Ｄ２＋Ｄ３
図２２は、内部仕様図２０及び図２１に基づいてユーザが作成したプログラムである。このプログラムでは、中間変数を用いて演算を行っている。これを抽象構文木で表したものが、図２３及び図２４である。図２３は、 ＊ Ｄ１ Ｄ２ Ｄ１０ （Ｄ１０＝Ｄ１＊Ｄ２）の抽象構文木であり、図２４は、 ＋ Ｄ１０ Ｄ３ Ｄ４ （Ｄ４＝Ｄ１０＋Ｄ３）の抽象構文木である。一方、図２５は内部仕様を抽象構文木に変換した結果である。

プログラムは二つの抽象構文木から構成され、内部仕様は一つの抽象構文木から構成される。これらの抽象構文木を比較しても結果は一致しない。そのため、最適化部１０による最適化を適用する。図２３と図２４の抽象構文木に中間変数の削除を適用すると、図２４のＤ１０ノードが、Ｄ１０と等価な図２３のＭＵＬノード以下で置換される。結果として、中間変数の削除を行ったプログラム抽象構文木は図２５と全く同じ構成となる。従って、プログラムと内部仕様の抽象構文木が一致するため、プログラムは内部仕様を満足する。

以上説明したように、実施の形態２のプログラム検証装置によれば、仕様が数式の場合でも実施の形態１と同様の効果を奏することができる。

実施の形態３．
実施の形態３では、高級言語で作成されたプログラムの検証の一例として、Ｃ言語を対象とした場合を説明する。
図２６は、実施の形態３における内部仕様である。動作仕様と入出力仕様が１対１に対応する場合には、動作仕様の提供のみでよい。実施の形態３では、入出力仕様は提供していないため、動作仕様各要素の展開は行わず、そのまま抽象構文木を生成する。つまり、ｚ＝ｘ＊ｙという抽象構文木を生成する。入出力仕様も提供した場合は、実施の形態１で説明したように各要素名を基に入出力仕様のラベルを検索し、検出された列から１行ずつデータを取り出し、動作仕様の各要素を置換する。

また、Ｃ言語の場合には、図２６に示すように関数単位で動作仕様を提供することを可能とする。関数単位で動作仕様を提供することにより、比較対象が関数内の抽象構文木に限定されるため、効率的に検証を行うことが可能となる。
図２７は、ユーザが内部仕様を基に作成したプログラムである。図２８は、プログラムのｍａｉｎ関数を抽象構文木に変換したものである。図２９は、ｍａｉｎ関数の内部仕様を抽象構文木に変換したものである。図２８と図２９の抽象構文木は一致しているため、このプログラムは内部仕様を満足する。
図３０に示すように、一つの関数あるいはプログラムに対して複数の動作仕様を記述することも可能である。また、本発明はＣ言語以外の高級言語にも対応可能である。複数の言語に対応するために言語毎にプログラムフロントエンドを準備すればよい。

以上説明したように、実施の形態３のプログラム検証装置によれば、高級言語で作成されたプログラムに対しても実施の形態１、２と同様の効果を奏することができる。

１ プログラム、２ 内部仕様、３ 検証結果報告書、４ プログラム検証装置、５ プログラムフロントエンド、６ 仕様フロントエンド、７ 抽象構文木検証部、８ プログラム抽象構文木、９ 仕様抽象構文木、１０ 最適化部、１１ 等価回路変換部、１２ 抽象構文木比較部、１３ プログラム抽象構文木検証結果記憶部、１４ 内部仕様抽象構文木検証結果記憶部、１５ 検証結果報告部。

Claims (4)

1. 検証対象プログラムが内部仕様を満足するかを検証するプログラム検証装置において、
   前記検証対象プログラムを抽象構文木に変換するプログラム変換手段と、
   前記内部仕様を抽象構文木に変換する内部仕様変換手段と、
   変換したそれぞれの抽象構文木を比較することで仕様に一致するか否かを検証する抽象構文木検証部とを備えたプログラム検証装置。
2. 抽象構文木検証部は、抽象構文木を比較した結果、一致する抽象構文木が存在しない場合は、検証対象プログラムから生成した抽象構文木を所定のテンプレートに基づいて等価な抽象構文木に変換して比較することを特徴とする請求項１記載のプログラム検証装置。
3. 抽象構文木検証部は、抽象構文木を比較した結果、一致する抽象構文木が存在しない場合は、検証対象プログラムから生成した抽象構文木を、当該プログラムとして等価な抽象構文木に最適化して比較することを特徴とする請求項１記載のプログラム検証装置。
4. 抽象構文木検証部は、一致しない抽象構文木を検証結果として記憶し、当該検証結果を検証対象プログラムの誤り位置として出力することを特徴とする請求項１から請求項３のうちのいずれか１項記載のプログラム検証装置。

Images