JP2009211503A - ソースコード検証装置、及びソースコード検証方法 - Google Patents

Abstract

【課題】ソースコードの検証に対してモデル検査を行う際に問題となる状態爆発を抑制する。
【解決手段】ソースコード検証システム２００は、検証対象ソースコード１００をKripke構造モデル３００に変換し、Kripke構造モデル３００に対してモデル検査を行うことにより、検証対象ソースコード１００を検証する。Kripke構造モデル３００は、検証対象ソースコード１００について定義された契約情報に記述された条件を満足しない状態を排除するようにKripke構造モデル３００を生成する。
【選択図】図１

Description

本発明は、ソースコード検証装置、及びソースコード検証方法に関し、特に、モデル検査技術（model checking）を用いてソースコードを検証するための技術に関する。

近年、ソフトウェアの品質を向上させるための一つの手法としてモデル検査技術が注目され、組込みソフトウェアなどの分野の検証として利用されるケースが増えてきている。モデル検査技術とは、ソフトウェアやハードウェアなどの何らかのシステムの状態遷移モデルをコンピュータに入力することで、その振る舞いにおかしな点がないかどうかをしらみつぶしにチェックする技術である。このモデル検査技術は、モデルとプロパティを与えてしまえば後はコンピュータが機械的にバグを検索し、不具合を発見してくれるということで非常に便利な技術である。

例えば、特開平１０−６３５３７号公報は、Kripke構造の論理装置モデルを用いて論理装置が仕様を満足するか否かを検査するための記号モデル検査手法を開示している。特開２００６−３２３６９４号公報は、ユースケース図を用いて記述されたソフトウェアの仕様書の正当性を自動的に検証するための仕様書確認装置を開示している。特開２００５−３１６７１０号公報は、ソースコードを解析して状態遷移情報を抽出し、抽出した状態遷移情報を設計情報に基づく状態遷移情報と比較してソースコードの試験をするソフトウェア試験支援装置を開示している。また、特開２００６−９１９４４号公報は、実行仮想環境アプリケーションサーバを用いてソフトウェアコンポーネントのそれぞれを他のソフトウェアコンポーネントのバグに影響されることなく正確にテストするための技術を開示している。

モデル検査技術をソースコードの検証に適用する場合の一つの問題は、入力されるモデルが大きすぎると「状態爆発」と呼ばれる現象がおき、現在のコンピュータで現実的な時間内に検索を終えられなくなってしまうことである。ソースコードのモデル検査ではモデル化の際に、変数の値の組を“状態”として表現し、その遷移をモデル化する状態遷移グラフを作成する。そのため、ソースコードが大規模になると変数が多くなり、その値の組合せ（即ち、状態）が莫大になる。例えば、変数ｉ（ｉ＝１〜ｍ：ｍは変数の数）の取り得る値の数がＮ_ｉであるとすると、可能な状態の数Ｎ_ａｌｌは、下記式：
Ｎ_ａｌｌ＝Ｎ_１×Ｎ_２×・・・×Ｎ_ｍ，
で表される。その結果、状態遷移を辿る処理は指数関数的に時間が掛かるようになり、「状態爆発」という現象が起きてしまう。

このような問題は、ソフトウェアの検証技術でのモデル検査の適用を妨げる１つの要因となっている。そのため、実際のソフトウェアの検証にモデル検査を適用する際には、検索をある深さで打ち切ったり、本来チェックしたいモデルを抽象化したりして現実的に検査できるモデルに落とし込むことが行われている。しかしながら、このような手法は、検証の信頼性の観点からは好ましくない。
特開平１０−６３５３７号公報 特開２００６−３２３６９４号公報 特開２００５−３１６７１０号公報 特開２００６−９１９４４号公報

したがって、本発明の目的は、ソースコードの検証に対してモデル検査を行う際に問題となる状態爆発を抑制することにある。

本発明の一つの特徴は、ソースコードのモデル化の際に契約駆動開発（Contract First Development, Design by Contract）で使用される契約情報（契約の表明（notion of contract）とも呼ばれる）を参照することにある。より具体的には、本発明のソースコード検証装置は、ソースコードを状態遷移モデルに変換する状態遷移モデル変換手段と、前記状態遷移モデルに対してモデル検査を行うことにより、前記ソースコードを検証する検証手段とを具備する。前記状態遷移モデル変換手段は、前記ソースコードについて定義された契約情報に記述された条件を満足しない状態を排除するように前記状態遷移モデルを生成する。

契約駆動開発によるソフトウェアの開発では、契約情報を用いて操作についての責任の所在を明確にし、関数の不必要な入力チェックなどを省略する開発スタイルが浸透してきている。しかしながら、従来は、契約情報がソースコードのモデル検査において有効に活用されることはなかった。本発明は、ソースコードの状態遷移モデルから、契約情報に記述されている条件を排除することで状態爆発を抑制する。

本発明によれば、ソースコードの検証に対してモデル検査を行う際に問題となる状態爆発を抑制することができる。

次に、本発明の一実施形態のソースコード検証装置について図面を参照して詳細に説明する。図１を参照して、本実施形態のソースコード検証システム２００は、検証対象ソースコード１００を検証するソフトウェアプログラムである。ソースコード検証システム２００は、検証対象ソースコード１００を、Kripke構造モデル３００にモデル化し、そのKripke構造モデル３００に対してモデル検査（model checking）を行う。ここで、Kripke構造モデルとは、システムの状態及びその遷移を記述する非決定性有限オートマトンの一種であり、モデル検査において広く使用される状態遷移モデルの一つである。ソースコード検証システム２００は、Kripke構造モデル３００に対して行ったモデル検査の結果を検証結果４００として出力する。検証者は、この検証結果４００から検証対象ソースコード１００の正当性を判断することができる。

図２は、ソースコード検証システム２００を実行するためのハードウェア資源の一例を示している。一実施形態では、ソースコード検証システム２００は、ソースコード検証装置１０にインストールされて実行される。ソースコード検証装置１０は、ＣＰＵ１１と、ＲＡＭ１２と、入力装置１３と、出力装置１４と、外部記憶装置１５とを備えたコンピュータとして構成されており、ソースコード検証システム２００は、外部記憶装置１５にインストールされる。入力装置１３は、検証対象ソースコード１００をソースコード検証装置１０に入力するために使用され、外部記憶装置１５は、検証対象ソースコード１００、Kripke構造モデル３００、及び検証結果４００を保存するために使用される。出力装置１４は、検証結果４００を出力するために使用される。

図１を再度に参照して、本実施形態のソースコード検証システム２００は、契約駆動開発に従って作成されたソースコードをその検証対象としている。契約駆動開発とは、システムのコンポーネント同士が、互いに厳密な契約を介して協調するように設計するソフトウェア構築手法であり、呼び出す側が守る条件として「事前条件」を設定し、呼ばれる側が守るべき条件を「事後条件」、システムとしていつでも満たさせる条件を「不変条件」として契約を定義し、コンポーネントがこの契約を守るように協調させる手法である。契約の内容の記述は、「表明」と呼ばれる。「表明」は、論理式で記述される。本明細書にいう「契約情報」とは、「契約の表明」と同義である。

本実施形態のソースコード検証システム２００の一つの特徴は、検証対象ソースコード１００をKripke構造モデル３００にモデル化する際に、コンポーネントのインターフェースに付与された契約の内容を示す契約情報を利用することある。これにより、本実施形態のソースコード検証システム２００は、Kripke構造モデル３００の大きさを小さくし、モデル検査を行う際に問題となる状態爆発を抑えることができる。

具体的には、本実施形態では、各コンポーネントに対して定義された事前条件、事後条件、不変条件といった契約情報が記載されている検証対象ソースコード１００が、ソースコード検証システム２００への入力として与えられる。詳細には、検証対象ソースコード１００は、検証対象コンポーネント１１０と、検証対象外コンポーネント１２０と、不変条件１３０から構成される。検証対象コンポーネント１１０は、事前条件１１１と事後条件１１２とソースコード１１３から構成されている。検証対象外コンポーネント１２０は、事前条件１２１と事後条件１２２とソースコード１２３から構成されている。検証対象コンポーネント１１０、検証対象外コンポーネント１２０の事前条件１１１、１２１、事後条件１１２、１２２、及び不変条件１３０は、検証対象ソースコード１００に埋め込まれていても、検証対象ソースコード１００の外部に定義されていてもかまわない。

ソースコード検証システム２００は、検証対象ソースコード１００に記述された契約情報を元に、検証対象ソースコード１００をKripke構造モデル３００に変換する。Kripke構造モデル３００は、状態遷移グラフ３１０と「検証したい性質」（properties to be verified）３２０から構成される。状態遷移グラフ３１０は、検証対象ソースコード１００の構造を、変数の値の組からなる状態、及び状態から状態への遷移として記述するグラフである。ソースコード検証システム２００は、検証対象コンポーネント１１０をKripke構造モデル３００へモデル化する際に、契約情報を利用することで、実際に取りえない状態をKripke構造モデル３００から排除する。即ち、ソースコード検証システム２００は、検証対象ソースコード１００に記述されている事前条件、事後条件、及び不変条件を満足するような状態のみを選択的に記述したKripke構造モデル３００を生成し、これにより、状態爆発を抑制する。

図３は、本実施形態におけるソースコード検証の手順を示すフローチャートである。まず、検証者により検証対象ソースコード１００が作成され、ソースコード検証装置１０の外部記憶装置１５に格納される（ステップＡ１）。この検証対象ソースコード１００の作成は、契約駆動開発によって行われる。検証対象ソースコード１００の作成の際には、検証対象コンポーネント１１０の事前条件１１１、事後条件１１２、検証対象外コンポーネント１２０の事前条件１２１、事後条件１２２、及び不変条件１３０が作成され、検証対象ソースコード１００に記述される。検証対象ソースコード１００の作成が完了したら、検証者は、ソースコード検証装置１０の入力装置１３を操作して、ソースコード検証システム２００へ検証指示を出す（ステップＡ２）。

ソースコード検証システム２００は、検証指示に応答して、検証対象ソースコード１００をKripke構造モデル３００へ変換する（ステップＢ１）。この際、ソースコード検証システム２００は、検証対象ソースコード１００に埋め込まれている契約情報（契約の表明）を、Kripke構造モデル３００の状態遷移グラフ３１０を作成するときの前提条件として利用することで、状態遷移グラフ３１０の大きさを小さくすることができる。

具体的には、状態遷移グラフ３１０へのモデル化の際に、検証対象コンポーネント１１０の入力（即ち、検証対象コンポーネント１１０の事前条件１１１と検証対象外コンポーネント１２０の事後条件１２２）、および不変条件１３０が成立することが前提にされる。即ち、ソースコード検証システム２００は、状態遷移グラフ３１０の生成の際、実際に取りえない状態（即ち、事前条件１１１、事後条件１２２、不変条件１３０を成立させないような状態）を排除する。これにより、検証対象ソースコード１００の状態遷移グラフ３１０の大きさを最低限にすることができ、状態爆発を抑えることができる。

例えば、一般的な検証方法では、ソースコードにおいて値域が明示されていない場合、３２ビット整数変数は、−２^３１以上、２^３１−１以下の２^３２乗通り（約４２億通り）の値を取り得るものとして状態遷移モデルを作成する必要があり、状態遷移モデルに記述される状態数が莫大になる。一方、本実施形態のソースコード検証システム２００では、例えば、ある変数の値が設計上−４以上３以下の８通りと判っている場合、これを事前条件や不変条件として検証対象ソースコード１００に与えることにより、状態数を大幅に削減することができる。したがって、状態爆発を抑えることができる。

また、実際に取りえない状態を状態遷移グラフ３１０から排除することは、ソースコード検証システム２００の誤検出を削減するという利点もある。例えば、ある変数の値が−１００００である場合に起きる不具合が検出されたとしても、設計上、当該変数の値が−４以上３以下に制約されていれば、この不具合は起こりえない。したがって、このような不具合が検出されることは、本来、誤りである。本実施形態のソースコード検証システム２００では、事前条件や不変条件によって、変数の値域（−４以上３以下）を与えることで、変数の値が−１００００で起きる不具合は検出されなくなるので、ソースコード検証システム２００の誤検出を減らすことができる。

ステップＢ１では、同時に、契約情報（契約の表明）がKripke構造モデル３００の検証したい性質３２０に変換される。具体的には、検証したい性質３２０を抽出する際に、検証対象コンポーネント１１０の出力が遵守すべき条件、即ち、検証対象コンポーネント１１０の事後条件１１２と、検証対象外コンポーネント１２０の事前条件１２１、および検証対象ソースコード１００の不変条件１３０が検証したい性質３２０として抽出される。後述のKripke構造モデル３００の検証では、ステップＢ２で抽出された検証したい性質３２０が、常に守られることを検証すればよいことになる。作成されたKripke構造モデル３００は、ソースコード検証装置１０の外部記憶装置１５に格納される。

Kripke構造モデル３００の作成が完了したら、Kripke構造モデル３００の検証が行われる（ステップＢ２）。詳細には、Kripke構造モデル３００に対してモデル検査が行われ、状態遷移グラフ３１０が検証したい性質３２０を満たすかどうかが確認される。モデル検査の結果は、検証結果４００として外部記憶装置１５に格納されると共に、出力装置１４によって外部に出力される。

ステップＢ２におけるモデル検査では、契約情報の矛盾を検出するようにしてもよい。モデル検査では網羅的な検索が行われるので、契約駆動開発で定義した契約情報（即ち、コンポーネント間の事前条件、事後条件、不変条件）に矛盾があれば、Kripke構造モデルのモデル検査の際にその矛盾を指摘し、契約情報の誤りを検出することができる。これにより、コンポーネント間のインターフェースの整合性が検証され、バグの誤検出を削減することができる。

最後にソースコード検証システム２００は、検証完了報告を行い（ステップＢ３）、検証者は検証結果４００を確認する（ステップＡ３）。

以上に説明されているように、本実施形態のソースコード検証システム２００は、検証対象ソースコード１００のKripke構造モデル３００へのモデル化の際の状態爆発を抑えることができる。本実施形態のソースコード検証システム２００は、モデル化の際の入力データとして、ソースコードだけではなく、契約駆動開発において作成される契約情報（契約の表明）を利用する。本実施形態では、検証対象コンポーネントの入力（検証対象コンポーネント１１０の事前条件１１１及び検証対象外コンポーネント１２０の事後条件）および不変条件１３０が必ず成立するような状態のみをKripke構造モデル３００に記述することで、検証対象ソースコード１００に起こりえない状態がKripke構造モデル３００から排除される。したがって、本実施形態のソースコード検証システム２００は、状態爆発を抑えることができる。

本実施形態では、ソースコードの内容を変更することなく状態爆発を抑えることができることに留意されたい。本実施形態のソースコード検証システム２００では、ソースコードの内容を変更して、本来チェックしたいモデルを抽象化したり、現実的に検査できるモデルに落とし込んだりする必要はない。

加えて、本実施形態のソースコード検証システム２００は、バグの誤検出を減らすことができる。上述のように、本実施形態のソースコード検証システム２００は、検証対象ソースコード１００に起こりえない状態をKripke構造モデル３００から排除し、起こりえない状態に対しては検証を省略する。したがって、起こりえない状態に対して発生するバグが誤って検出されることはない。

図１は、本発明の一実施形態のソースコード検証システムの機能を示す概念図である。 図２は、ソースコード検証システムを実行するためのハードウェア資源の一例を示している。 図３は、一実施形態における、検証対象ソースコードを検証する手順を示すフローチャートである。

符号の説明

１００：検証対象ソースコード
１１０：検証対象コンポーネント
１１１：事前条件
１１２：事後条件
１１３：ソースコード
１２０：検証対象外コンポーネント
１２１：事前条件
１２２：事後条件
１２３：ソースコード
１３０：不変条件
２００：ソースコード検証システム
３００：Kripke構造モデル
４００：検証結果
１０：ソースコード検証装置
１１：ＣＰＵ
１２：ＲＡＭ
１３：入力装置
１４：出力装置
１５：外部記憶装置

Claims (6)

1. ソースコードを状態遷移モデルに変換する状態遷移モデル変換手段と、
   前記状態遷移モデルに対してモデル検査を行うことにより、前記ソースコードを検証する検証手段
   とを具備し、
   前記状態遷移モデル変換手段は、前記ソースコードについて定義された契約情報に記述された条件を満足しない状態を排除するように前記状態遷移モデルを生成する
   ソースコード検証装置。
2. 請求項１に記載のソースコード検証装置であって、
   前記状態遷移モデルは、前記ソースコードの検査対象コンポーネントの事前条件、前記ソースコードの検査対象外コンポーネントの事後条件、及び前記ソースコードについて定義された不変条件を満足しない状態を排除するように生成された
   ソースコード検証装置。
3. 請求項２に記載のソースコード検証装置であって、
   前記状態遷移モデル変換手段は、前記検証対象コンポーネントの事後条件と、前記検証対象外コンポーネントの事前条件、および前記ソースコードについて定義された前記不変条件を、検証したい性質として抽出し、
   前記検証手段は、前記状態遷移モデルが前記検証したい性質を満足するかを検証する
   ソースコード検証装置。
4. 請求項１乃至３のいずれかに記載のソースコード検証装置であって、
   前記状態遷移モデルが、Kripke構造を有している
   ソースコード検証装置。
5. 状態遷移モデル変換手段と検証手段とを備えるソースコード検証装置を用いたソースコード検証方法であって、
   前記状態遷移モデル変換手段が、ソースコードを状態遷移モデルに変換するステップと、
   前記検証手段が、
   前記状態遷移モデルに対してモデル検査を行うことにより、前記ソースコードを検証するステップ
   とを具備し、
   前記状態遷移モデルは、前記ソースコードについて定義された契約情報に記述された条件を満足しない状態を排除するように生成される
   ソースコード検証方法。
6. コンピュータを、
   ソースコードを状態遷移モデルに変換する状態遷移モデル変換手段と、
   前記状態遷移モデルに対してモデル検査を行うことにより、前記ソースコードを検証する検証手段
   として動作させるプログラムであって、
   前記状態遷移モデルが、前記ソースコードについて定義された契約情報に記述された条件を満足しない状態を排除するように生成される
   プログラム。

Images