JP5471971B2 - Data generation method, data generation apparatus, and data generation program in model checking - Google Patents
Data generation method, data generation apparatus, and data generation program in model checking Download PDFInfo
- Publication number
- JP5471971B2 JP5471971B2 JP2010186666A JP2010186666A JP5471971B2 JP 5471971 B2 JP5471971 B2 JP 5471971B2 JP 2010186666 A JP2010186666 A JP 2010186666A JP 2010186666 A JP2010186666 A JP 2010186666A JP 5471971 B2 JP5471971 B2 JP 5471971B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- item
- inspection
- generation
- input
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Description
本発明は、モデル検査に用いるテストデータを生成する技術に関する。 The present invention relates to a technique for generating test data used for model checking.
従来のモデル検査は、まず擬似システムに予め作成したテストデータを、ドライバを用いて入力する処理を行う。ここで、擬似システムとは、検査対象のシステムの振る舞いを、該システムの設計書や仕様書などに基づいて専用言語などを用いて作成されるプログラムである。また、擬似システムである検査対象プログラムは、検査対象プログラムを動かすドライバとデータベースやネットワークなどの外部環境を抽象化するためのスタブなどと接続されている。ドライバは、検査対象プログラムを様々な実行順序で複数回、連続的に呼び出して、ユーザの操作を模倣したテストデータを引数として検査対象プログラムに渡す。 In conventional model checking, first, test data created in advance in a pseudo system is input using a driver. Here, the pseudo system is a program in which the behavior of the system to be inspected is created using a dedicated language or the like based on the design document or specification document of the system. The inspection target program that is a pseudo system is connected to a driver that runs the inspection target program and a stub for abstracting an external environment such as a database or a network. The driver continuously calls the inspection target program a plurality of times in various execution orders, and passes the test data imitating the user's operation as an argument to the inspection target program.
次にモデル検査では、該テストデータを用いて検査対象プログラムを実行する処理をして、該テストデータを用いた検査対象プログラムの実行結果が、プロパティに記録されている該テストデータに対応する検査条件を満たしているか否かを、判定する処理を行う。 Next, in model checking, the test target program is executed using the test data, and the execution result of the test target program using the test data corresponds to the test data recorded in the property. Processing for determining whether or not the condition is satisfied is performed.
そして、上記説明した処理を終了すると、現在の検査対象プログラムの状態に対するテストデータを、ドライバを用いて検査対象プログラムに入力する処理を再度行い、検査対象プログラムを実行して実行結果が、検査条件を満たしているか否かを判定する。 When the above-described processing is completed, the test data for the current inspection target program state is input again to the inspection target program using the driver, the inspection target program is executed, and the execution result is the inspection condition. It is determined whether or not
このように、モデル検査では設計書や仕様書などに基づき、検査対象プログラムの取りうる状態遷移の各状態が取りうる全ての組み合わせに対してテストデータを入力して、繰り返し実行する。 In this way, in model checking, test data is input to all combinations that can be taken by each state transition that can be taken by the program to be checked, based on a design document, specifications, etc., and is repeatedly executed.
ところが、全ての組み合わせに対して網羅的にモデル検査を実施すには、検査対象プログラムのあらゆる動作を想定したテストデータを予め作成し、作成したテストデータを入力できるドライバが必要である。すなわち、検査対象プログラムのユーザ操作イベントおよびユーザ操作イベントの引数となるテストデータについて、仕様上可能な組み合わせを再現できるようにしなければならない。 However, in order to exhaustively perform model checking for all combinations, a driver that can create test data assuming all operations of the program to be checked and input the created test data is required. In other words, it is necessary to be able to reproduce the possible combinations in terms of specifications for the user operation event of the program to be inspected and the test data serving as an argument of the user operation event.
例えば、Java PathFinderに代表されるモデル検査では、検査対象プログラムに入力するテストデータは検査対象プログラムの動作結果に依存して決定されるため、検査対象プログラムを動作させる前に具体的な値が決定できない。例えば、商品の注文を複数回連続して行える商品注文システムにおいて、注文できる数量が在庫数を超える場合は購入できないという仕様がある場合について考える。従来のドライバによるテストデータの生成では、在庫数量に対して具体的な値を設定して、ケースごとに在庫数量<購入数量を満たす購入数量を求めている。在庫数量が100個であれば、購入数量を101個とすることが考えられる。 For example, in model checking typified by Java PathFinder, the test data to be input to the inspection target program is determined depending on the operation result of the inspection target program, so a specific value is determined before operating the inspection target program. Can not. For example, let us consider a case in which there is a specification that a product cannot be purchased when the quantity that can be ordered exceeds the quantity in stock in a product ordering system that can place an order for a product multiple times. In the generation of test data by a conventional driver, a specific value is set for the inventory quantity, and a purchase quantity satisfying the inventory quantity <purchase quantity is obtained for each case. If the stock quantity is 100, the purchase quantity may be 101.
しかし、購入によって在庫数量が変わると、1回目に購入できる数量と2回目に購入できる数量が異なる。そのため、2回目に購入できる数量を求めるには、1回目に購入した結果の在庫数量を算出する必要があり、在庫数量も算出に関するすべての仕様を判断できる形で記述する必要がある。例えば、1回目に購入数量=90個で購入したら、在庫数量は在庫数量(100個)−購入数量(90個)=10個になるので、次の購入時の境界値は10個になる。しかし、在庫数量10個を求めるには「在庫数量−数量が次の在庫数量になる」という仕様が記述されなければならないが、通常そのような仕様までドライバは対応していない。 However, when the inventory quantity changes by purchase, the quantity that can be purchased for the first time and the quantity that can be purchased for the second time are different. Therefore, in order to obtain the quantity that can be purchased for the second time, it is necessary to calculate the inventory quantity as a result of the first purchase, and it is also necessary to describe the inventory quantity in such a way that all specifications relating to the calculation can be judged. For example, if the purchase quantity is 90 at the first time, the inventory quantity is inventory quantity (100 pieces) −purchase quantity (90 pieces) = 10 pieces, so the boundary value at the next purchase is 10 pieces. However, in order to obtain the inventory quantity of 10 pieces, the specification “inventory quantity—the quantity becomes the next inventory quantity” must be described, but usually the driver does not support such a specification.
また、前述の境界値により作成したデータを、2回目以降の購入でも使うと次のような問題が発生する。1回目に在庫数100個のときに購入数量100個で商品を購入した場合、在庫数量の境界値は0個になる。しかし、1回目と同じデータを用いると、在庫が無いにもかかわらず、在庫数量<購入数量、在庫数量=購入数量、在庫数量>購入数量の場合について検査を実行しなくてはならない。例えば、購入数量が101個、100個、90個の3パターンについても検査を実行する。また、在庫数100個のときに購入数量90個で商品を購入した場合、在庫数量の境界値は10個になるが、1回目と同じデータを用いていると在庫数量が10個で同じように3パターンについて実行しなくてはならない。また、在庫数量が10個以下の場合については検査をしないことになる。しかし、通常そのような仕様をすべて網羅するドライバは現実的でないため、2回目以降も1回目の境界値を使って検査をしている。 Further, if the data created based on the boundary value is used in the second and subsequent purchases, the following problem occurs. When a product is purchased with a purchase quantity of 100 when the stock quantity is 100 for the first time, the boundary value of the inventory quantity becomes 0. However, if the same data as the first time is used, the inspection must be executed in the case of inventory quantity <purchase quantity, inventory quantity = purchase quantity, inventory quantity> purchase quantity even though there is no inventory. For example, the inspection is also performed on three patterns of 101, 100, and 90 purchased quantities. In addition, when a product is purchased with a purchase quantity of 90 pieces when the stock quantity is 100 pieces, the boundary value of the stock quantity is 10 pieces, but if the same data as the first time is used, the stock quantity is the same with 10 pieces. The three patterns must be executed. Further, when the stock quantity is 10 or less, the inspection is not performed. However, since a driver that covers all such specifications is not practical, the second and subsequent tests are performed using the first boundary value.
なお、テストデータを生成する技術として、テスト実行中に通過しなかったルートを検出し、ソースプログラムを解析し、当該ルートを通るような入力パラメータ値を生成する技術が知られている。この技術では、プログラムのテスト実行中にコードカバレッジを測定し、テスト実行後、カバレッジ結果を解析して未実行ルートを特定し、その直前の分岐条件から未実行ルートを実行させるための条件を抽出する。その条件と関連するテスト実行中に計測した変数の変移情報から、未実行ルートを通す入力データを特定する。 As a technique for generating test data, a technique is known in which a route that has not passed during test execution is detected, a source program is analyzed, and an input parameter value that passes through the route is generated. In this technology, code coverage is measured during the test execution of the program, and after the test execution, the coverage result is analyzed to identify the unexecuted route, and the condition for executing the unexecuted route is extracted from the immediately preceding branch condition. To do. The input data passing through the unexecuted route is identified from the variable transition information measured during the test execution related to the condition.
本発明は上記のような実情に鑑みてなされたものであり、モデル検査で用いるテストデータを動的に生成するデータ生成方法、モデル検査装置およびデータ生成プログラムを提供することを目的とする。 The present invention has been made in view of the above circumstances, and an object thereof is to provide a data generation method, a model checking apparatus, and a data generation program for dynamically generating test data used in model checking.
実施の態様のひとつであるモデル検査においてテストデータを動的に生成するデータ生成方法(ドライバ)は、モデル検査を実行するコンピュータが、上記モデル検査の検査対象プログラムで用いるデータ項目各々について入力データ項目であるか出力データ項目であるかが定義されている定義テーブルを参照する。そして、上記検査対象プログラムを実行する際に用いる検査条件の記述から入力データ項目と出力データ項目を抽出して、抽出した入力データ項目を生成対象項目として特定する。 A data generation method (driver) that dynamically generates test data in model checking, which is one of the embodiments, is an input data item for each data item used by the computer that executes model checking in the program to be tested for model checking. Refers to the definition table that defines whether it is an output data item. Then, the input data item and the output data item are extracted from the description of the inspection condition used when the inspection target program is executed, and the extracted input data item is specified as the generation target item.
次に、上記検査条件の記述から抽出した上記出力データ項目に対応する上記検査対象プログラムの実行環境に記録されているデータを取得して、取得したデータに対応する上記出力データ項目のデータとして用いる形式に変換して出力データを生成する。 Next, data recorded in the execution environment of the inspection target program corresponding to the output data item extracted from the description of the inspection condition is acquired and used as data of the output data item corresponding to the acquired data. Convert to format and generate output data.
次に、上記検査条件と前記出力データを、SMTソルバプログラムに入力するデータの形式に変換して生成条件を生成する。
次に、上記生成条件を入力してSMTソルバプログラムを実行し、上記記生成条件を満たすデータを求め、該データから上記生成対象項目に対応するデータを抽出し、抽出したデータを前記生成対象項目の入力として検査対象プログラムの実行環境に入力させる。
Next, the inspection condition and the output data are converted into a data format to be input to the SMT solver program to generate a generation condition.
Next, the generation condition is input to execute the SMT solver program, data that satisfies the generation condition is obtained, data corresponding to the generation target item is extracted from the data, and the extracted data is extracted from the generation target item. Input to the execution environment of the program to be inspected.
実施の態様によれば、モデル検査で用いるテストデータを動的に生成することにより、検査精度と実行効率を向上させることができるという効果を奏する。 According to the embodiment, it is possible to improve inspection accuracy and execution efficiency by dynamically generating test data used in model checking.
以下図面に基づいて、実施形態1について詳細を説明する。
図1は、モデル検査システムの一実施例を示すブロック図である。図1のモデル検査システムは、モデル検査部1、ドライバ2、検査対象プログラム実行環境3、プロパティ4などを有している。モデル検査部1、ドライバ2、検査対象プログラム実行環境3の機能を実現する方法として、Central Processing Unit(CPU)を用いることが考えられる。また、プログラマブルなデバイス(Field Programmable Gate Array(FPGA)、Programmable Logic Device(PLD)など)を用いることが考えられる。なお、モデル検査部1の機能と、ドライバ2および検査対象プログラム実行環境3の機能を、分けて実現してもよい。また、モデル検査部1、ドライバ2、検査対象プログラム実行環境3、プロパティ4のプログラムやデータなどは、例えばRead Only Memory(ROM)、Random Access Memory(RAM)などのメモリやハードディスクなどの記録部に記録することが考えられる。また、記録部にはパラメータ値、変数値などのデータを記録してもよいし、実行時のワークエリアとして用いてもよい。なお、モデル検査部1、ドライバ2、検査対象プログラム実行環境3、プロパティ4のプログラムやデータなどは、同一のメモリやハードディスクなどに記録しなくてもよい。
Details of the first embodiment will be described below with reference to the drawings.
FIG. 1 is a block diagram showing an embodiment of a model checking system. The model checking system in FIG. 1 includes a
モデル検査部1は、検査対象プログラム実行環境3とドライバ2とプロパティ4を用いてモデル検査を実行し、実行結果がプロパティ4に記録されている後述する機能仕様に記載されている条件が満たされているかを判定する。
The
ドライバ2は、モデル検査に用いる動的なテストデータを生成する。
検査対象プログラム実行環境3は、該検査対象のシステムの設計書や仕様書などに基づいて検査対象のシステムの振る舞いを専用言語などにより作成した後述する検査対象プログラム5、データベーススタブ6、ネットスタブ7を有している。検査対象プログラム5は、検査対象のシステムの振る舞いを設計書や仕様書などに基づいて作成したプログラムであり、検査対象プログラムを動かすドライバ2とデータベース6やネットワーク7などの外部環境を抽象化するためのスタブなどと接続されている。データベーススタブ6はデータベースの記録内容と動作などを模倣したスタブであり、ネットスタブ7はネットワークと接続された装置と装置とのやり取りなどを模倣したスタブである。
The
The inspection target
プロパティ4には、仕様書や設計書などに記載された機能仕様が、「A(条件部)ならばB(帰結部)」(A−>B)の形式で示され、記録されている。仕様書や設計書などに記載されている機能仕様は、例えば、「購入時に入力した購入数量が在庫数量以内ならば購入可能」である。また、「在庫数量−購入数量が10未満ならば警告を出力」「購入数量に0未満が入力されたならばエラー」「購入数量×単価が10000円を超えたならば金額オーバー」などである。「購入時に入力した購入数量が在庫数量以内ならば購入可能」に対応する内容であれば、条件部に「在庫数量−購入数量and購入数量>0」が記録され、帰結部に「メッセージ=「null」and在庫数量(after)=在庫数−購入数量」が記録されている。ここで、andは複数の条件を同時に満たす場合を示す記号である。また、帰結部の「メッセージ=・・・」は、後述する出力部の画面にメッセージや計算結果などを表示する関数である。例えば、メッセージ=「表示内容1」and「表示内容2」と記載すると、「表示内容1」と「表示内容2」が出力部に表示される。また、「在庫数量−購入数量が10未満ならば警告を出力」に対応する内容であれば、条件部に「0≦在庫数量−購入数量<10and購入数量>0」が記録される。また、帰結部に「メッセージ=「警告」and在庫数量(after)=在庫数量−購入数量」が記録されている。また、「購入数量に0未満ならばエラー」に対応する内容であれば、条件部に「購入数量≦0」が記録され、帰結部に「メッセージ=「購入数量エラー」」が記録されている。また、「購入数量×単価が10000円を超えたならば金額オーバー」に対応する内容であれば、条件部に「単価×購入数量≧10000」が記録され、帰結部に「メッセージ=「金額オーバー」」が記録されている。
なお、上記プロパティ4の記載形式は上記形式に限定されるものではない。
In the
The description format of the
モデル検査システムの動作について説明する。
図2は、モデル検査システムの動作の一実施例を示すフロー図である。ステップS1では、モデル検査部1が現在の状態において検査可能な検査条件の選択肢を列挙する。例えば、設計書や仕様書などに基づき作成した検査対象プログラム5の取りうる状態遷移の各状態が、図3に示すような組み合わせである場合について説明する。また、図3の状態1(丸形1)〜状態10(丸形10)・・・は状態遷移の各状態を示している。図3の状態1は初期状態を示し、状態1からは状態2、3などに状態遷移する。状態2からは状態4、6、7に状態遷移する。状態3からは状態10に状態遷移する。状態4からは状態5に状態遷移する。状態7からは状態8、9に状態遷移する。ここで、現在の状態が状態1であれば、状態2、3などの検査条件を列挙する。同じように、現在の状態が状態2であれば状態4、6、7の検査条件を列挙する。検査条件は、プロパティ4に記録されている状態各々に対応する機能仕様の条件部である。また、図3に示した状態各々の遷移については、予め作成して記録部に記録されている。
The operation of the model checking system will be described.
FIG. 2 is a flowchart showing an embodiment of the operation of the model checking system. In step S1, the
ステップS2では、モデル検査部1が検査条件から1つを特定する。例えば、現在の状態が図3の状態2であれば状態4、6、7の検査条件を列挙されているので、状態4、6、7の検査条件を選択する。選択の方法は、プロパティ4に記録されている検査条件を順に選択する方法が考えられる。しかし、選択の方法は上記に限定されるものではない。
In step S2, the
ステップS3では、モデル検査部1が特定した検査条件をドライバ2に入力する。そして、ドライバ2は後述する動的なテストデータを生成して、検査対象プログラム実行環境3に該テストデータを入力する。次に、検査対象プログラム実行環境3により実行され、モデル検査部1に実行結果が出力される。
In step S <b> 3, the inspection condition specified by the
ステップS4ではモデル検査部1が実行結果を検査する。例えば、実行結果とプロパティ4の状態各々に対応する機能仕様の帰結部の記載を比較して、実行結果が帰結部の記載内容を満たしていればステップS5で合格と判定してステップS7(Yes)に移行する。実行結果が帰結部の記載内容を満たしていないときは、ステップS5で不合格と判定してステップS6(No)に移行する。ステップS6で不合格である場合には、モデル検査を停止してもよいし、他の状態に遷移してモデル検査を継続してもよい。
In step S4, the
ステップS7では、モデル検査部1が合格した後に遷移した現在の状態を検査対象プログラム実行環境3の実行結果を参照して抽出する。例えば、図3の状態4の状態において検査に合格したのであれば、状態5の状態がモデル検査部1により抽出される。
In step S7, the current state after the
ステップS8では、モデル検査部1が既に検査実行済みの状態であるか否かを判定し、検査実行済みの状態であればステップS10(Yes)に移行し、まだ検査が実行されていない状態であればステップS9(No)に移行する。例えば、ステップS7において図3の状態7の状態において検査に合格し状態8の状態が抽出され場合に、状態8の状態が既に検査実行済みであれば、1つ前の状態である状態7に状態を戻すためにステップS10に移行する。状態8の状態がまだ検査が実行されていないのであれば、状態8より先に検査をする状態があるかを判定するためにステップS9に移行する。
In step S8, it is determined whether or not the
ステップS9では、モデル検査部1が現在の状態より先に検査をする状態があるか否かを判定し、現在の状態より先に検査をする状態がない場合は終了状態と判定してステップS10(Yes)に移行する。現在の状態より先に検査をする状態がある場合は終了状態でないと判定してステップS1(No)に移行する。例えば、図3の状態8の状態が既に検査実行済みであれば、1つ前の状態である状態7に状態を戻し、状態8の状態がまだ検査が実行されていないのであれば、状態8の状態のモデル検査を実行するためにステップS1に移行する。
In step S9, it is determined whether or not there is a state in which the
ステップS10では、モデル検査部1が現在の状態を1つ前の状態に戻す。例えば、図3の状態8の状態が既に検査実行済みであれば、1つ前の状態である状態7に状態を戻す。
In step S10, the
ステップS11では、モデル検査部1がステップS1で列挙した全ての状態の検査条件各々を実行したか否かを判定して、列挙した全ての検査条件を実行した場合にはステップS12(Yes)に移行する。まだ実行していない検査条件がある場合にはステップS2(No)に移行する。
In step S11, it is determined whether the
ステップS12でモデル検査部1は、現在の条件が初期状態であるか否かを判定して、初期状態であればモデル検査を終了し、初期状態でない場合にはステップS10(No)に移行する。例えば、図3の状態1の初期状態で、かつ全ての状態についてモデル検査が終了していればモデル検査を終了する。また、状態2の場合であればステップS10に移行して1つ前の状態である状態1(初期状態)に状態を戻す。
In step S12, the
ドライバ2について説明する。
図4は、ドライバ2の一実施例を示すブロック図である。図4のドライバ2は、検査条件特定部201、出力データ取得部202、検査条件変換部203、Satisability Modulo Theories(SMT)ソルバ実行部204、生成データ通知部205を有している。ドライバ2は、後述する検査条件テーブル206、画面項目定義テーブル207、DB項目定義テーブル208、変換ルールテーブル211を有している。また、第1の生成条件テーブル209、DB/画面出力データテーブル210、第2の生成条件テーブル212、生成データテーブル214を有している。ただし、上記各テーブルはドライバ2以外に記録しておいてもよい。また、ドライバ2は、SMTソルバ実行部204が実行するSMTソルバのプログラムを有している。
The
FIG. 4 is a block diagram showing an embodiment of the
検査条件特定部201は、定義テーブルを参照して検査対象プログラムを実行する際に用いる検査条件の記述から入力データ項目と出力データ項目を抽出して、該入力データ項目を生成対象項目と特定する。定義テーブルは、モデル検査の検査対象プログラムで用いるデータ項目各々について入力データ項目であるか出力データ項目であるかが定義されているテーブルである。また定義テーブルは、例えば、画面項目定義テーブル207、DB項目定義テーブル208などである。図5と図6を用いて、検査条件特定部201の説明をする。
The inspection
図5は、入出力装置の画面から商品IDと発注数を入力して在庫数が足りていれば注文を受け付けるプログラムの表示画面、画面項目定義テーブル、DB項目定義テーブル、商品テーブルを示す図である。上記プログラムが実行されると、図5に示すような画面51が表示され、担当者を識別する担当者ID、画面51に商品を識別するIDを入力する入力範囲52と、該商品の発注数を入力する入力範囲53が表示される。また、図5に示す画面51には、利用者が注文を決定したことを通知する注文ボタン54が表示される。図5の例では担当者IDとして1000が記録されている。
FIG. 5 is a diagram showing a display screen, a screen item definition table, a DB item definition table, and a product table for a program that accepts an order if the product ID and the order quantity are input from the screen of the input / output device and the stock quantity is sufficient. is there. When the above program is executed, a
上記画面51から入出力されるデータの定義は、画面項目定義テーブル55に記録されている。画面項目定義テーブル55は「画面項目名」「入出力区分」「型」を有している。「画面項目名」には入出力されるデータを識別する識別子が記録され、図5の例では「担当者ID」「商品ID」「発注数」が記録されている。「入出力区分」には画面から入力される入力データであるか、画面に表示される出力データであるかを区分けする「入力」「出力」が、「画面項目名」各々に関連付けられて記録されている。「型」には、「画面項目名」各々に関連付けられて入出力されるデータの型が記録されている。型は、例えば、C言語などで用いられているようなデータの型を定義する型であってもよい。なお、図5の例では、全ての型が整数であることを示す「int」が記録されている。
Definitions of data input / output from the
図5のDB項目定義テーブル56は、データベーススタブ6で用いるデータが記録されており、「テーブル名」「DB項目名」「型」を有している。「テーブル名」にはデータベーススタブ6で用いるテーブルを識別する「テーブル名」が記録されている。図5の例では「商品テーブル」が記録されている。「DB項目名」にはテーブル各々で用いるデータを識別する識別子が記録され、図5の例では「担当者ID」「商品ID」「在庫数」が記録されている。「型」には、「DB項目名」各々に関連付けられて入出力されるデータの型が記録されている。型は、例えば、C言語などで用いられているような型であってもよい。なお、図5の例では、全ての型が整数であることを示す「int」が記録されている。商品テーブル57は、検査対象プログラム実行環境3のデータベーススタブ6に記録され、「担当者ID」「商品ID」「在庫数」を有し、「担当者ID」には担当者を識別する識別子「1000」「1000」「1010」「1020」が記録されている。「商品ID」には商品を識別するための識別子「1」「2」「3」「4」が記録されている。「在庫数」には現在の商品の在庫数量を示す「10」「200」「1000」「50」が記録されている。
The DB item definition table 56 in FIG. 5 records data used in the
検査条件特定部201について説明する。
図6は、検査条件特定部201の動作の一実施例を示すフロー図である。
ステップS61では、検査条件特定部201が検査条件テーブル206の検査条件からデータ項目を一つ特定する。例えば、モデル検査部1が図7に示す検査条件テーブル206の項番各々に関連付けられている検査条件を用いてモデル検査を実行する。ここで、検査条件テーブル206は「項番」「検査条件」を有している。「項番」は、検査条件を識別するための識別子である。本例では、「P1」「P2」「P3」・・・が記録されている。「検査条件」は、既に説明したプロパティ4に記録されている機能仕様の条件部に対応する記述が「項番」に関連付けられて記録されている。本例では、「P1」に関連付けて「画面.発注数<=0」が記録されている。画面51の入力範囲53に利用者により入力された発注数が0以下の場合を示している。また、「P2」に関連付けて「画面.発注数>0 and (numOf(filter(rec in 商品テーブル,rec.担当者ID==画面.担当者ID and rec.商品ID==画面.商品ID and rec.在庫数>=画面.発注数))==1)」が記録されている。ここで、recはテーブル内のあるレコードを表している。上記検査条件は、画面51の入力範囲53に利用者により入力された発注数が0より大きく。且つ、商品テーブル内の担当者IDと画面51上の担当者IDが同じで、商品テーブル内の商品IDと画面51の入力範囲52に利用者により入力された商品IDが同じである。さらに、商品テーブル内の在庫数が画面51の入力範囲53に利用者により入力された発注数以上の場合を示している。つまり、注文が成功する場合を示している。また、「P3」に関連付けて「画面.発注数>0 and (numOf(filter(rec in 商品テーブル,rec.担当者ID==画面.担当者ID and rec.商品ID==画面.商品ID and rec.在庫数<画面.発注数))==1)」が記録されている。ここで、recはテーブル内のあるレコードを表している。上記検査条件は、画面51の入力範囲53に利用者により入力された発注数が0より大きい。且つ、商品テーブル内の担当者IDと画面51上の担当者IDが同じで、商品テーブル内の商品IDと画面51の入力範囲52に利用者により入力された商品IDが同じである。さらに、商品テーブル内の在庫数が画面51の入力範囲53に利用者により入力された発注数より少ない場合を示している。つまり、在庫数が足りなり場合を示している。
The inspection
FIG. 6 is a flowchart showing an example of the operation of the inspection
In step S61, the inspection
モデル検査部1が、図7に示す検査条件テーブル206の「項番」の「P2」に関連付けられている検査条件を取得した場合であれば、まずP2に対応する検査条件からデータ項目を抽出する。次に、P2に対応する検査条件は、第1の生成条件テーブル209に検査条件として記録される。
If the
次にデータ項目の抽出は、例えば、P2に対応する検査条件の記載内容から、画面項目定義テーブル55の「画面項目名」、DB項目定義テーブル56の「テーブル名」「DB項目名」に記載されているデータと一致するデータ項目を抽出する。本例では、図8の81に示すようにデータ項目「画面.発注数」「商品テーブル.担当者ID」「画面.担当者ID」「商品テーブル.商品ID」「画面.商品ID」「商品テーブル.在庫数」を抽出する。そして、抽出したデータ項目の中から一つのデータ項目を特定する。 Next, the extraction of data items is described in, for example, “screen item name” in the screen item definition table 55 and “table name” and “DB item name” in the DB item definition table 56 from the description content of the inspection condition corresponding to P2. Extract data items that match the recorded data. In this example, as shown by 81 in FIG. 8, the data items “screen.number of orders” “product table.person ID” “screen.person ID” “product table.product ID” “screen.product ID” “product”. "Table. Inventory quantity" is extracted. Then, one data item is specified from the extracted data items.
第1の生成条件テーブル209は、検査条件の記述から抽出された入力データ項目と出力データ項目を分けて記録する。例えば、図9に第1の生成条件テーブル91に示すように「検査条件」「画面出力項目」「DB項目」「生成対象項目」を有している。図9の例では、第1の生成条件テーブル91の「検査条件」にP2に関連付けられた検査条件の内容が記録されている。「画面出力項目」「DB項目」には出力データ項目が記録され、「生成対象項目」には入力データ項目が記録される。 The first generation condition table 209 separately records input data items and output data items extracted from the description of the inspection conditions. For example, as shown in the first generation condition table 91 in FIG. 9, it has “inspection conditions”, “screen output items”, “DB items”, and “generation target items”. In the example of FIG. 9, the contents of the inspection condition associated with P <b> 2 are recorded in the “inspection condition” of the first generation condition table 91. Output data items are recorded in “screen output items” and “DB items”, and input data items are recorded in “generation target items”.
ステップS62では、検査条件特定部201が特定したデータ項目がDB項目か否かを、DB項目定義テーブル208を参照して判定をして、ステップS63においてデータ項目がDB項目である場合にステップS64(Yes)に移行する。DB項目でない場合にはステップS65(No)に移行する。例えば、商品テーブル57のデータ項目であればDB項目であるので「商品テーブル.担当者ID」「商品テーブル.商品ID」「商品テーブル.在庫数」をDB項目に振り分ける。「画面.」などの記述があるデータ項目であれば、画面項目であると判定する。例えば、「画面.発注数」「画面.担当者ID」「画面.発注数」を画面項目である。
In step S62, it is determined with reference to the DB item definition table 208 whether or not the data item specified by the inspection
ステップS64では、検査条件特定部201が第1の生成条件テーブル209の出力データ項目にDB項目であるデータ項目を記録してステップS69に移行する。例えば、第1の生成条件テーブル91ではDB項目であるデータ項目を記録する「DB項目」に、データ項目を記録する。本例では、第1の生成条件テーブル91の「DB項目」に「商品テーブル.担当者ID」「商品テーブル.商品ID」「商品テーブル.在庫数」が記録されている。
In step S64, the inspection
ステップS65では、検査条件特定部201が画面項目定義テーブル207を参照して振り分けられたデータ項目が画面出力項目か判定する。ステップS66では、検査条件特定部201が画面出力項目である場合にステップS67(Yes)に移行し、画面出力項目でない場合にはステップS68(No)に移行する。例えば、図5の画面項目定義テーブル55の「入出力区分」を参照して、データ項目が「出力」である場合にはステップS67(Yes)に移行する。データ項目が「入力」である場合にはステップS68(No)に移行する。
In step S65, the inspection
ステップS67では、検査条件特定部201が第1の生成条件テーブル209の画面出力項目(出力データ項目)にデータ項目を記録してステップS69に移行する。本例では、図9の第1の生成条件テーブル91の「画面出力項目」に「画面.担当者ID」が記録される。
In step S67, the inspection
ステップS68では、検査条件特定部201が第1の生成条件テーブル209の生成対象項目(入力データ項目)にデータ項目を記録する。本例では、図9の第1の生成条件テーブル91の「生成対象項目」に「画面.発注数」「画面.発注数」が記録される。
In step S68, the inspection
ステップS69では、検査条件特定部201が全てのデータ項目を処理したか否かを判定し、全てのデータ項目を振り分けていれば出力データ取得部202の処理に移行し、まだ振り分けられていないデータ項目がある場合にはステップS61に移行する。
In step S69, it is determined whether the inspection
出力データ取得部202について説明する。
出力データ取得部202は、検査対象プログラムの実行環境に記録されている検査条件の記述から抽出した出力データ項目に対応するデータを取得して、取得したデータを前記出力データ項目で用いることを示す形式に変換することにより出力データを生成する。例えば、第1の生成条件テーブル209の画面出力項目、DB項目などの出力データ項目に記録されているデータ項目に対応するデータを検査対象プログラム実行環境3にアクセスして取得して、DB/画面出力データテーブル210に記録する。
The output
The output
図10は、出力データ取得部202の動作の一実施例を示すフロー図である。
例えば、検査対象プログラム実行環境3に前述した入出力装置の画面から商品IDと発注数を入力して在庫数が足りていれば注文を受け付けるプログラムがある場合について説明する。現在の状態が図9に示す第1の生成条件テーブル91の状態であるとする。また、図11に示すように現在の検査対象プログラム実行環境3の画面の状態が画面51に示す状態で、データベーススタブ6に記録されているテーブルの状態が商品テーブル57に示す状態であるとする。
FIG. 10 is a flowchart showing an embodiment of the operation of the output
For example, a case will be described in which there is a program that accepts an order if the inventory number is sufficient by inputting the product ID and the number of orders from the screen of the input / output device described above into the inspection target
ステップS101では、出力データ取得部202が第1の生成条件テーブル91の「DB項目」を参照して、データ項目を特定する。次に、ステップS102で出力データ取得部202は、「DB項目」のデータ項目に関連するデータを、検査対象プログラム実行環境3から取得する。本例では、出力データ取得部202は第1の生成条件テーブル91の「DB項目」に記録されているデータ項目各々がすべて商品テーブル57に関連付けられているので、商品テーブル57に関連するデータを取得する。
In step S <b> 101, the output
ステップS103では、出力データ取得部202が取得したデータを出力データ項目が用いることを示す形式に変換しDB/画面出力データテーブル210に記録する。例えば、出力データ取得部202が取得したデータが商品テーブル57の場合であれば、図11の「DBデータ」に示したデータが記録される。本例では「DBデータ」に、商品テーブル57の1行目に対応する「商品テーブル[0].担当者ID=1000,商品テーブル[0].商品ID=1,商品テーブル[0].在庫数=10」が記録されている。また、「DBデータ」に、商品テーブル57の2行目に対応する「商品テーブル[1].担当者ID=1000,商品テーブル[1].商品ID=2,商品テーブル[1].在庫数=200」が記録されている。また、「DBデータ」に、商品テーブル57の3行目に対応する「商品テーブル[2].担当者ID=1010,商品テーブル[2].商品ID=3,商品テーブル[2].在庫数=1000」が記録されている。また、「DBデータ」に、商品テーブル57の4行目に対応する「商品テーブル[3].担当者ID=1020,商品テーブル[3].商品ID=4,商品テーブル[3].在庫数=50」が記録されている。
In step S103, the data acquired by the output
ステップS104では、出力データ取得部202がDB/画面出力データテーブル111の行数を表すレコード数に行数を記録する。本例では、商品テーブル57の行数が4なので、DB/画面出力データテーブル111の「DBレコード数」に「4」が記録される。ただし、「DBレコード数」はなくてもよい。
In step S104, the output
ステップS105では、出力データ取得部202が第1の生成条件テーブル91の「画面出力項目」を参照して、データ項目を特定する。次に、ステップS106で出力データ取得部202は、画面出力項目のデータ項目に関連するデータを、検査対象プログラム実行環境3から取得する。例えば、出力データ取得部202は第1の生成条件テーブル91の「画面出力項目」に記録されているデータ項目が画面.担当者IDに関連付けられているので、検査対象プログラム実行環境3の画面.担当者IDに関連するデータを取得する。
In step S <b> 105, the output
ステップS107では、出力データ取得部202が取得したデータを出力データ項目が用いることを示す形式に変換しDB/画面出力データテーブル210に記録する。本例では、画面.担当者IDに関連するデータ「画面.担当者ID=1000」が図11の「画面出力データ」に記録される。
In step S107, the data acquired by the output
検査条件変換部203について説明する。
検査条件変換部203は、検査条件と出力データをSMTソルバプログラムへ入力するデータの形式に変換して生成条件を生成する。検査条件変換部203は、例えば、検査条件を変換ルールテーブル211とDB/画面出力データテーブル210を用いて変換する。
The inspection
The inspection
図12は、検査条件変換部203の動作の一実施例を示すフロー図である。
ステップS121では、検査条件変換部203がDB/画面出力データテーブル210から各テーブルのレコード数を取得する。例えば、図11のDB/画面出力データテーブル111の場合であれば、「DBレコード数」から「4」を取得する。また、「DBレコード数」がない場合には「DBデータ」を用いて行数を求めてもよい。本例では、商品テーブル57しかないが、データベーススタブ6などで用いるテーブルが複数ある場合にはテーブル各々のレコード数を取得する。
FIG. 12 is a flowchart showing an example of the operation of the inspection
In step S121, the inspection
ステップS122では、検査条件変換部203が第1の生成条件テーブル209に記録されている検査条件と、変換ルールテーブル211の変換前パターン各々を比較して、形式が一致する変換前パターンを特定する。そして、特定した変換前パターンを用いて検査条件に含まれる変数を抽出する。例えば、図9の「検査条件」の記載内容の形式と図13の変換ルールテーブル131に記録されている変換前パターン各々の形式を比較する。図13の例では、変換ルールテーブル131の「変換前パターン」の「numOf(filter(rec in %DBテーブル%,%条件式%))==1」の形式と一致しているので、特定した変換前パターンを用いて検査条件に含まれる変数を抽出する。「変換前パターン」の%で囲われた文字列「%DBテーブル%」「%条件式%」に対応する検査条件の変数「商品テーブル」「rec.担当者ID==画面.担当者ID and rec.商品ID==画面.商品ID and rec.在庫数>=画面.発注数」を抽出する。
In step S122, the inspection
ステップS123では、検査条件変換部203が変換ルールテーブル211の変換後パターンに、抽出した変数とレコード数を代入して検査条件を変換して、第2の生成条件テーブル212に記録する。例えば、図13の変換ルールテーブル131のステップS122で特定した変換前パターンに関連付けられている変換後パターン「For i = 0 to %DBテーブル%.DBレコード数{%条件式%} or 接続」を用いて、生成条件を生成する。変換後パターンは、検査条件をSMTソルバの入力データに変換するための関数であり、生成条件はSMTソルバの入力データに用いられるデータである。本例では、図13の生成条件132に示す形式のデータに変換する。「For i = 0 to %DBテーブル%.DBレコード数」は、「%DBテーブル%」が示す「商品テーブル」の各レコードを示す[0]〜[3]を示している。また、「%条件式%」は商品テーブルのレコードが[0]のとき「商品テーブル[0].担当者ID == 画面.担当者ID and 商品テーブル[0].商品ID == 画面.商品ID and 商品テーブル[0].在庫数>=画面.発注数」になる。また、商品テーブルのレコードが[1]のとき「商品テーブル[1].担当者ID == 画面.担当者ID and 商品テーブル[1].商品ID == 画面.商品ID and 商品テーブル[1].在庫数>=画面.発注数」になる。また、商品テーブルのレコードが[2]のとき「商品テーブル[2].担当者ID == 画面.担当者ID and 商品テーブル[2].商品ID == 画面.商品ID and 商品テーブル[2].在庫数>=画面.発注数」になる。また、商品テーブルのレコードが[3]のとき「商品テーブル[3].担当者ID == 画面.担当者ID and 商品テーブル[3].商品ID == 画面.商品ID and 商品テーブル[3].在庫数>=画面.発注数」になる。そして、「or 接続」は上記4つの「%条件式%」に対応する記述を論理和「or」で結合することを示している。ただし、本例の変換後パターンの関数は実際に用いるSMTソルバの入力データの形式に変換できる関数であればよく、上記変換後パターンに限定されるものではない。
In step S123, the inspection
ステップS124では、検査条件変換部203が検査条件に対して全て変換処理をしたかを判定して、全ての変換処理をした場合にはステップS125(Yes)に移行し、すべての変換処理をしていない場合にはステップS122(No)に移行する。例えば、検査条件が複数の変換前パターンの形式を有している場合に、全ての変換前パターンに対して変換処理をしたか否かを判定する。
In step S124, the inspection
ステップS125では、検査条件変換部203がDB/画面出力データテーブル210の画面出力データを取得して条件式に変換して、第2の生成条件テーブル212に記録する。例えば、図11のDB/画面出力データテーブル111から「画面出力データ」に記録されている「画面.担当者=1000」を取得して、図14に示すように「and 画面.担当者=1000」に変換して、変換後生成条件に追加して記録する。ただし、本例の変換は実際に用いるSMTソルバの入力データの形式に変換できる関数であればよく、上記変換に限定されるものではない。
In step S <b> 125, the inspection
ステップS126では、検査条件変換部203がDB/画面出力データテーブル210のDBデータを取得して条件式に変換、第2の生成条件テーブル212に記録する。例えば、図11のDB/画面出力データテーブル111から「DBデータ」に記録されているデータを取得して、図14に示すように「and 商品テーブル[0].担当者ID=1000 and 商品テーブル[0].商品ID=1 and 商品テーブル[0].在庫数=10 and ・・・・」に変換して、変換後生成条件に追加して記録する。ただし、本例の変換は実際に用いるSMTソルバの入力データの形式に変換できる関数であればよく、上記変換に限定されるものではない。
In step S126, the inspection
SMTソルバ実行部204について説明する。
SMTソルバ実行部204は、検査条件変換部203で生成した第2の生成条件テーブル212に記録した生成条件を入力としてSMTソルバプログラム213を実行して、生成条件を満たすデータを得る。次に、SMTソルバ実行部204は、第1の生成条件テーブル209の生成対象項目から画面入力データを抽出し、生成データテーブル214に記録する。SMTソルバとは、DPLL(T)アルゴリズム(「Decision Procedures: An Algorithmic Point of View」、Daniel Kroening他、ISBN:978-3540741046の11章参照)等を用いて入力された制約の充足可能性を判定するものである。ここで、DPLL(T)とは、命題論理用の充足可能性判定アルゴリズムであるDPLLアルゴリズムを述語論理に拡張したものである。DPLLは、Davis-Putnam-Logemann-Lovelandを示し、Tは理論(Theory)の略で、理論とは述語論理のサブセットを指す。例えば、「x=yかつy=1かつx!=2」といった自然数の等価関係(=)のみから構成される論理式のクラスは理論の一つである。また、SMTソルバでは、まず入力された制約の論理的な最小単位である原子論理式に対応する命題論理式を新たに与える。続いて、当該制約の各原子論理式を対応する命題論理式で変換した論理式が充足可能であるように、SMTソルバは各命題論理式に対して真偽値を与えていく。そして、原子論理式の真偽値が対応する各命題論理式の真偽値と一致するように、当該原子論理式に出現するインスタンス(変数)の具体的な充足値を得ようと試みる。実際に各インスタンスの具体的な充足値を得ることができた場合、SMTソルバは入力された制約を充足可能と判定し、得た充足値を充足解として出力する。充足値を得ることができなかった場合、SMTソルバは入力された制約を充足不能と判定する。この処理により、SMTソルバは変換後制約を入力として受け取り、変換後制約充足解を出力する。
The SMT
The SMT
図15は、SMTソルバ実行部204の動作の一実施例を示すフロー図である。
ステップS151では、SMTソルバ実行部204が第2の生成条件テーブル212の生成条件を取得して実行する。そして、SMTソルバ実行部204は実行結果を取得する。例えば、SMTソルバ実行部204は、生成条件141を入力してSMTソルバプログラム213を実行して、実行結果を取得する。図16の実行結果161にSMTソルバプログラムの実行結果の一実施例を示す。
FIG. 15 is a flowchart illustrating an example of the operation of the SMT
In step S151, the SMT
ステップS152では、SMTソルバ実行部204が第1の生成条件テーブル209に記録されている生成対象項目のデータ項目を取得する。例えば、第1の生成条件テーブル91のデータ項目「画面.発注数」「画面.商品ID」を取得する。図16に生成対象項目162を示す。
In step S152, the SMT
ステップS153では、SMTソルバ実行部204が実行結果から生成対象項目で用いる生成データを抽出して、生成データテーブル214に記録する。例えば、図16に実行結果161の「画面.発注数=10」「画面.商品ID=1」を抽出して生成データテーブル163に記録する。
In step S153, the SMT
生成データ通知部205について説明する。
生成データ通知部205は、生成データテーブル214の生成データを用いて検査対象プログラムを実行するために、生成データテーブル214の生成データを検査対象プログラム実行環境3に入力する。
The generated
The generated
図17は、生成データ通知部205の動作の一実施例を示すフロー図である。
ステップS171では、生成データ通知部205が生成データテーブル214から生成データを取得する。次に、ステップS172で生成データ通知部205は、生成データをテストデータとして検査対象プログラムに入力する。図18の場合であれば、生成データテーブル163の生成データである画面.発注数=10、画面.商品ID=1を、テストデータとして検査対象プログラムへ入力する。その後、モデル検査部1は、現在の検査対象プログラムの実行をし、実行が終了するとモデル検査完了か否かの判定を行い、モデル検査を続行する場合、次の検査条件の特定を行う。
FIG. 17 is a flowchart illustrating an example of the operation of the generated
In step S <b> 171, the generation
実施形態1のドライバによれば、生成対象項目に含まれる複数のデータ項目で用いる値によりテストデータを決定する必要がある場合に、変換後生成条件を満たす生成データを作成してテストデータとして検査対象プログラム実行環境に入力する。すなわち、動的にテストデータを検査対象プログラム実行環境に入力することができるため、従来のように無駄なテストデータを検査対象プログラム実行環境に入力して実行することを抑制できるので、モデル検査の実行効率を向上させることができる。また、動的にテストデータを生成するため、従来検査できなかった検査条件についても検査をすることができるため、モデル検査の精度を向上させることができる。また、検査対象プログラムに入力するテストデータが、検査対象プログラムの動作結果に依存して決定されるため、検査対象プログラムを動作させる前に具体的な値が決定できる。また、検査できなかった検査条件が検知された場合には、従来のようにその検査条件に対するドライバを生成してコンパイルし直す必要がないため、モデル検査を実施する準備作業を削減できる。 According to the driver of the first embodiment, when it is necessary to determine test data based on values used in a plurality of data items included in a generation target item, generation data that satisfies a post-conversion generation condition is generated and inspected as test data Enter the target program execution environment. In other words, since test data can be dynamically input to the program execution environment to be inspected, it is possible to suppress inputting unnecessary test data to the program execution environment to be inspected and executing it as in the past. Execution efficiency can be improved. In addition, since test data is dynamically generated, inspection conditions that could not be inspected conventionally can be inspected, so that the accuracy of model inspection can be improved. Further, since the test data input to the inspection target program is determined depending on the operation result of the inspection target program, a specific value can be determined before the inspection target program is operated. Further, when an inspection condition that could not be inspected is detected, it is not necessary to generate a driver for the inspection condition and recompile as in the prior art, so that the preparation work for performing model inspection can be reduced.
実施形態2について説明する。
実施形態2は、実施形態1を、コンピュータを用いて実現する場合について説明する。
図19は、実施形態2のコンピュータのハードウェア構成の一実施例を示す図である。コンピュータのハードウェア1900は、CPU1901、記録部1902、記録媒体読取装置1903、入出力インタフェース1904(入出力I/F)、通信インタフェース1905(通信I/F)などを備えている。また、上記各構成部はバス1906によってそれぞれ接続されている。
FIG. 19 is a diagram illustrating an example of the hardware configuration of the computer according to the second embodiment. A
CPU1901は、記録部1902に記録されている上記説明した各処理を実行する。
記録部1902には、CPU1901が実行するプログラムやデータが記録されている。また、ワークエリアなどとして使用される。例えば、ROM、RAM、ハードディスクドライブなどである。
The
The
記録媒体読取装置1903は、CPU1901の制御に従って記録媒体1907に対するデータのリード/ライトを制御する。そして、記録媒体1907に記録媒体読取装置1903の制御で書き込まれたデータを記録させたり、記録媒体1907に記憶されたデータを読み取らせたりする。また、着脱可能な記録媒体1907は、コンピュータで読み取り可能なnon−transitory(非一時的)な記録媒体として、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置(HDD)などがある。光ディスクには、Digital Versatile Disc(DVD)、DVD−RAM、Compact Disc Read Only Memory(CD−ROM)、CD−R(Recordable)/RW(ReWritable)などがある。光磁気記録媒体には、Magneto-Optical disk(MO)などがある。なお、記録部1902もnon-transitory(非一時的)な記録媒体に含まれる。
The recording
入出力インタフェース1904には、入出力装置1908が接続され、利用者が入力した情報を受信し、バス1906を介してCPU1901に送信する。また、CPU1901からの命令に従ってディスプレイの画面上に操作情報などを表示する。入出力装置1908は、例えば、タッチパネルなどが考えられる。
An input / output device 1908 is connected to the input /
通信インタフェース1905は、必要に応じ、他のコンピュータとの間のLocal Area Network(LAN)接続やインターネット接続や無線接続を行うためのインタフェースである。また、他の装置に接続され、外部装置からのデータの入出力を制御する。
The
このようなハードウェア構成を有するコンピュータを用いることによって、上記説明した各種処理機能が実現される。その場合システムが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体1907に記録しておくことができる。なお、上記各種処理機能は、実施形態1で説明したフロー図などである。
By using a computer having such a hardware configuration, the various processing functions described above are realized. In that case, a program describing the processing contents of the functions that the system should have is provided. By executing the program on a computer, the above processing functions are realized on the computer. The program describing the processing contents can be recorded in a computer-
プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVD、CD−ROMなどの記録媒体1907が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
When distributing the program, for example, a
プログラムを実行するコンピュータは、例えば、記録媒体1907に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記録部1902に格納する。そして、コンピュータは、自己の記録部1902からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、記録媒体1907から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
The computer that executes the program stores, for example, the program recorded in the
また、本発明は、上記実施の形態に限定されるものでなく、本発明の要旨を逸脱しない範囲内で種々の改良、変更が可能である。なお、各実施例は処理に矛盾の無い限りにおいて、互いに組み合わせても構わない。 The present invention is not limited to the above-described embodiment, and various improvements and modifications can be made without departing from the gist of the present invention. Each embodiment may be combined with each other as long as there is no contradiction in processing.
1 モデル検査部
2 ドライバ
3 検査対象プログラム実行環境
4 プロパティ
5 検査対象プログラム
6 データベーススタブ
7 ネットスタブ
201 検査条件特定部
202 出力データ取得部
203 検査条件変換部
204 SMTソルバ実行部
205 生成データ通知部
206 検査条件テーブル
207、55 画面項目定義テーブル
208、56 DB項目定義テーブル
209、91 第1の生成条件テーブル
210、111 DB/画面出力データテーブル
211、131 変換ルールテーブル
212、132、141 第2の生成条件テーブル
213 SMTソルバプログラム
214、163 生成データテーブル
51 画面
52、53 入力範囲
54 注文ボタン
57 商品テーブル
161 実行結果
162 生成対象項目
1900 ハードウェア
1901 CPU
1902 記録部
1903 記録媒体読取装置
1904 入出力インタフェース(入出力I/F)
1905 通信インタフェース(通信I/F)
1906 バス
1907 記録媒体
1908 入出力装置
DESCRIPTION OF
1902
1905 Communication interface (communication I / F)
1906
Claims (3)
前記モデル検査の検査対象プログラムで用いるデータ項目各々について入力データ項目であるか出力データ項目であるかが定義されている定義テーブルを参照して、前記検査対象プログラムを実行する際に用いる検査条件の記述から入力データ項目と出力データ項目を抽出して、抽出した入力データ項目を生成対象項目として特定し、
前記検査条件の記述から抽出した前記出力データ項目に対応する前記検査対象プログラムの実行環境に記録されているデータを取得して、取得したデータに対応する前記出力データ項目のデータとして用いる形式に変換して出力データを生成し、
前記検査条件と前記出力データを、SMTソルバプログラムに入力するデータの形式に変換して生成条件を生成し、
前記生成条件を入力してSMTソルバプログラムを実行し、前記生成条件を満たすデータを求め、該データから前記生成対象項目に対応するデータを抽出し、
抽出したデータを前記生成対象項目の入力として検査対象プログラムの実行環境に入力する、
ことを実行するデータ生成方法。 A computer that performs model checking
For each data item used in the inspection target program of the model inspection, with reference to a definition table that defines whether the data item is an input data item or an output data item, an inspection condition used when executing the inspection target program Extract the input data item and output data item from the description, identify the extracted input data item as the generation target item,
Acquires data recorded in the execution environment of the inspection target program corresponding to the output data item extracted from the description of the inspection condition, and converts it to a format used as data of the output data item corresponding to the acquired data To generate output data,
The inspection conditions and the output data are converted into a data format to be input to the SMT solver program to generate generation conditions,
Input the generation condition, execute an SMT solver program, obtain data satisfying the generation condition, extract data corresponding to the generation target item from the data,
The extracted data is input to the execution environment of the inspection target program as the input of the generation target item.
A data generation method that performs that.
前記検査条件の記述から抽出した前記出力データ項目に対応する前記検査対象プログラムの実行環境に記録されているデータを取得して、取得したデータに対応する前記出力データ項目のデータとして用いる形式に変換して出力データを生成する出力データ取得部と、
前記検査条件と前記出力データを、SMTソルバプログラムに入力するデータの形式に変換して生成条件を生成する検査条件変換部と、
前記生成条件を入力してSMTソルバプログラムを実行し、前記生成条件を満たすデータを求め、該データから前記生成対象項目に対応するデータを抽出するSMTソルバ実行部と、
抽出したデータを前記生成対象項目の入力として検査対象プログラムの実行環境に入力させる生成データ通知部と、
を備えることを特徴とするデータ生成装置。 Description of inspection conditions used when executing the inspection target program with reference to a definition table that defines whether each data item used in the inspection target program of model checking is an input data item or an output data item An input data item and an output data item extracted from the test condition specifying unit for specifying the extracted input data item as a generation target item;
Acquires data recorded in the execution environment of the inspection target program corresponding to the output data item extracted from the description of the inspection condition, and converts it to a format used as data of the output data item corresponding to the acquired data An output data acquisition unit for generating output data,
An inspection condition conversion unit that generates the generation condition by converting the inspection condition and the output data into a format of data input to the SMT solver program;
An SMT solver execution unit that inputs the generation condition, executes an SMT solver program, obtains data that satisfies the generation condition, and extracts data corresponding to the generation target item from the data;
A generation data notification unit for inputting the extracted data to the execution environment of the inspection target program as input of the generation target item;
A data generation device comprising:
前記モデル検査の検査対象プログラムで用いるデータ項目各々について入力データ項目であるか出力データ項目であるかが定義されている定義テーブルを参照して、前記検査対象プログラムを実行する際に用いる検査条件の記述から入力データ項目と出力データ項目を抽出して、抽出した入力データ項目を生成対象項目として特定する処理と、
前記検査条件の記述から抽出した前記出力データ項目に対応する前記検査対象プログラムの実行環境に記録されているデータを取得して、取得したデータに対応する前記出力データ項目のデータとして用いる形式に変換して出力データを生成する処理と、
前記検査条件と前記出力データを、SMTソルバプログラムに入力するデータの形式に変換して生成条件を生成する処理と、
前記生成条件を入力してSMTソルバプログラムを実行し、前記生成条件を満たすデータを求め、該データから前記生成対象項目に対応するデータを抽出する処理と、
抽出したデータを前記生成対象項目の入力として検査対象プログラムの実行環境に入力させる処理と、
を実行させることを特徴とするデータ生成プログラム。 A computer that performs model checking,
For each data item used in the inspection target program of the model inspection, with reference to a definition table that defines whether the data item is an input data item or an output data item, an inspection condition used when executing the inspection target program Extracting input data items and output data items from the description and identifying the extracted input data items as generation target items;
Acquires data recorded in the execution environment of the inspection target program corresponding to the output data item extracted from the description of the inspection condition, and converts it to a format used as data of the output data item corresponding to the acquired data Process to generate output data,
A process for generating the generation condition by converting the inspection condition and the output data into a data format to be input to the SMT solver program;
A process of inputting the generation condition, executing an SMT solver program, obtaining data satisfying the generation condition, and extracting data corresponding to the generation target item from the data;
A process of inputting the extracted data into the execution environment of the inspection target program as the input of the generation target item;
A data generation program characterized in that
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010186666A JP5471971B2 (en) | 2010-08-23 | 2010-08-23 | Data generation method, data generation apparatus, and data generation program in model checking |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010186666A JP5471971B2 (en) | 2010-08-23 | 2010-08-23 | Data generation method, data generation apparatus, and data generation program in model checking |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2012043384A JP2012043384A (en) | 2012-03-01 |
JP5471971B2 true JP5471971B2 (en) | 2014-04-16 |
Family
ID=45899567
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010186666A Expired - Fee Related JP5471971B2 (en) | 2010-08-23 | 2010-08-23 | Data generation method, data generation apparatus, and data generation program in model checking |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5471971B2 (en) |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08212106A (en) * | 1995-02-01 | 1996-08-20 | Toshiba Corp | Device and method for supporting system test |
-
2010
- 2010-08-23 JP JP2010186666A patent/JP5471971B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2012043384A (en) | 2012-03-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Măruşter et al. | Redesigning business processes: a methodology based on simulation and process mining techniques | |
JP3815218B2 (en) | Data analysis method and apparatus | |
CN111125560A (en) | Data visualization processing method and device and computer system | |
JP2019148897A (en) | Behavior pattern search system and behavior pattern search method | |
JP7059220B2 (en) | Machine learning program verification device and machine learning program verification method | |
JP2018147280A (en) | Data analysis device and data analysis method | |
US7630951B2 (en) | Method, program product, and apparatus for generating analysis model | |
CN109710306A (en) | Source code resolver, source code analysis method, computer readable recording medium | |
JP6692281B2 (en) | Test case generation device and test case generation method | |
CN116627418A (en) | Multi-level form interface visual generation method and device based on recursion algorithm | |
JP7145118B2 (en) | DESIGN SUPPORT SYSTEM, DESIGN VERIFICATION METHOD AND DESIGN VERIFICATION PROGRAM | |
Coscia | Using arborescences to estimate hierarchicalness in directed complex networks | |
JP5799823B2 (en) | Test data generation device, test data generation program, and test data generation method | |
JP2005122560A (en) | Program for detecting deadlock beforehand | |
JP5672165B2 (en) | Test data generation program, test data generation method, test data generation device | |
JP5106447B2 (en) | Test case generation apparatus, generation method thereof, and computer program | |
KR101836333B1 (en) | System of automatic design verification of nuclear reactor core design | |
JP6360625B2 (en) | Verification support system and method | |
JP5471971B2 (en) | Data generation method, data generation apparatus, and data generation program in model checking | |
JP2012014308A (en) | Method and device for predicting influence of change | |
JP2009245177A (en) | Feature model creation support device and program | |
JP2006277282A (en) | Model evaluation analysis system and model evaluation analysis program | |
JP5321286B2 (en) | Program model checking method, program model checking program | |
WO2013058252A1 (en) | Model examination support method, model examination support program, and model examination support device | |
JP5304470B2 (en) | Model checking program, model checking method, model checking device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130604 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140107 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140120 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |