JP2012059026A - ソースコード変換方法およびソースコード変換プログラム - Google Patents

Abstract

【課題】ソフトウェアのモデル検査において、モデルチェッカの入力言語で検査コードを記述するコストを低減させるため、ソフトウェアのソースコードを検査コードに変換するアプローチがある。利用者は単一の変換方式しか選べないため、抽象化の水準の変更が困難、ソースコードの設計変更へ追従するためのルール修正コストが高い、異なる検査ツールで検査するためのルール修正コストが高い、等の課題が存在する。
【解決手段】ソースコードを検査コードに変換する際、複数の変換ルールを選択する手段を提供し、利用者が容易に抽象化の水準を変更可能とする。また、複数の変換ルールは、ソースコードを中間形式に変換する変換ルールと、中間形式において抽象化を行う変換ルールと、中間形式から検査コードに変換する変換ルールとを含む。
【選択図】図３Ａ

Description

本発明は、ソースコード変換方法およびソースコード変換プログラムに係り、特に、ソフトウェアのモデル検査において、モデルチェッカの入力言語で検査コードを記述するコストを低減させるために、計算機を活用してソフトウェアのソースコードを検査コードに変換する手法に関する。

近年、ソフトウェアシステムが一般社会に浸透し、ソフトウェアに求められる信頼性が非常に高くなってきている一方で、ソフトウェアは複雑化および大規模化の一途をたどっており、手作業でのレビューや、テストによる品質確保が非常に困難になってきている。

モデル検査技術は、たとえば非特許文献１に開示される方法であって、ソフトウェアの振舞いを、特定モデルチェッカの入力言語で記述し、特定モデルチェッカを実行することで、前記ソフトウェアが持つべき性質を満たしているかどうかを、前記ソフトウェアの取り得る状態を網羅的に検査する技術である。非特許文献１に開示される方法によると、ソフトウェアの振る舞いを、Promelaと呼ばれる入力言語で記述し、SPINと呼ばれるモデルチェッカに入力することで、検査を実施する。

モデル検査技術は複雑化及び大規模化の一途をたどるソフトウェアの品質確保に有望な技術であるが、ソフトウェアの取り得る状態を網羅的に検査するため、規模の大きなソフトウェアでは、検査すべき状態数が膨大な分量となる状態爆発と呼ばれる現象が起き、処理に必要な時間計算量が現実的に許容不可能な大きさとなる現象と、もしくは、処理に必要な空間計算量が処理に用いる計算機に搭載された記憶領域を超える現象の、両方もしくは一方が起き、検査を完了することができないことがあり得る。

状態爆発に対応するために、抽象化と呼ばれる処理を、ソースコードもしくは検査コードに対して行い、状態数を検査可能な範囲まで削減することがある。抽象化は、例えば、選択的実行文の分岐条件の簡略化がある。抽象化によって、本来存在しない実行パスが生じる、もしくは、存在する実行パスが消滅することがあり得るため、検査コードに対する検査結果が示すソフトウェアの性質と、本来のソフトウェアの性質に差異が生まれることがあり得る。そのため、ソフトウェアに対して検査すべき性質に鑑み、抽象化の水準を検討した上で、抽象化を適用することが望ましい。

さらに、モデル検査技術は、検査対象のソフトウェアを、特定モデルチェッカの入力言語で記述する労力が大きいことが実用上の問題となることがあり得る。図１１に、特許文献１に開示されたソースコード変換装置の一例を示す。特許文献１に開示される方法によると、ソースコードは、特定モデルチェッカの入力言語で書かれた検査コードへ、翻訳マップを用いて変換される（ステップ９１０〜９４０）。特許文献１に開示される方法によると、検査コードを、前記変換とは別に利用者により定義された環境モデルを用いて、前記特定モデルチェッカにより検査する（ステップ９７５、ステップ９５０〜９７０）。

また、ソフトウェアの開発技術のひとつとして、モデル駆動型開発がある。モデル駆動型開発は、ソフトウェアの設計情報をモデルとして記述し、そのモデルを変換操作により詳細化することで、ソフトウェア開発を進める技術である。例えば、モデル駆動型開発において、モデルのフォーマットや意味は非特許文献2に開示される方法であるMOFにより記述されたメタモデルにより規定され、非特許文献3に開示される方法であるQVTによりモデルを詳細化する変換ルールが記述され、非特許文献4に開示される方法であるOCLによりモデルの整合性や健全性に関する制約の記述および検証が行われ、非特許文献5に開示される方法であるMOFM2Tによりモデルからソースコードが生成される。

なお、モデル検査技術における「モデル」と、モデル駆動型開発における「モデル」は、互いに独立した概念であり、一般にデータ構造や意味などに関する共通性はない。

特開2000-181750号広報

Gerard J. Holzmann, "The SPIN Model Checker: Primer and Reference Manual", Addison-Wesley Professional, 2003, ISBN: 978-0321228628 The Object Management Group, "Meta Object Facility (MOF) Core Specification", formal/06-01-01, January 2006, http://www.omg.org/spec/MOF/2.0/PDF The Object Management Group , "Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification", formal/2008-04-03, April 2008, http://www.omg.org/spec/QVT/1.0/PDF The Object Management Group、"Object Constraint Language", formal/2006-05-01, May 2006, http://www.omg.org/spec/OCL/2.0/PDF The Object Management Group, "MOF Model to Text Transformation Language, v1.0", formal/2008-01-16, January 2008, http://www.omg.org/spec/MOFM2T/1.0/PDF

モデル検査によるソフトウェアの信頼性確保を有効に実施するためには、ソースコードからモデルチェッカの入力言語で記述された検査用コードを自動生成するなどの方法により、検査用コードを得るための労力を低減させること、および、ソフトウェアの仕様および設計を、モデルチェッカによる網羅的検査が現実的な時間計算量および空間計算量で終了するように抽象化することが必要となる。

しかし、特許文献１に開示される方法によると、（１）抽象化の水準の変更が困難である、（２）ソフトウェア設計変更への追従コストが高い、（３）異なるモデルチェッカにて検査する際のコストが高い、という課題が存在する。

上記（１）の課題に関して、特許文献１に開示される方法によると、翻訳マップの変更は、ソースプログラムの改訂など、新しいタイプの命令がソースコード内に導入された場合のみに限定される。そのため、利用者が抽象化の水準を変更する方法は、変換前の検査対象のソースコードに修正を加える方法と、変換後の特定モデルチェッカの入力言語で書かれた検査コードに修正を加える方法と、環境モデルに修正を加える方法とに限定され、いずれの方法においても、利用者が大きな手間を費やすことになる。

上記（２）の課題に関して、特許文献１に開示される方法によると、使用するライブラリの変更などの変更が生じた際には、翻訳マップの修正と、環境モデルの修正とを行う必要がある。しかし、翻訳マップは、前記ソースコードから、前記検査コードへと直接変換するマップ要素で構成されていることと、環境モデルが特定モデルチェッカの入力言語で書かれていることとに起因して、設計変更に追従するように整合性を保ちながら修正することは困難である。

上記（３）の課題に関して、特許文献１に開示される方法によると、異なるモデルチェッカにて検査するためには、翻訳マップの修正と、環境モデルの修正とを行う必要がある。しかし、翻訳マップは、前記ソースコードから前記検査コードへと直接変換するマップ要素で構成されていることや、環境モデルが特定モデルチェッカの入力言語で書かれていることとに起因して、翻訳マップと環境モデルのすべてを修正する必要があり、大きなコストを要する。

また、検査水準と状態数のトレードオフを、利用者側で管理したいというニーズがある。すなわち、複雑なシステムの検査では、状態爆発が容易に発生し、検査を完了することができない。このようなとき、何も検査できないよりも、水準を若干落としてでも、検査を完了できることが望ましい場合がある。例えば、繰り返し実行時のみに発生する特定の不具合がある場合、その繰返しを除去することで、特定の不具合の検出はできなくなるものの、大幅に状態数を削減できる、という場合もある。

本発明は、従来の技術の課題を踏まえ、抽象化の水準等に柔軟に対応できる、ソースコード変換方法およびソースコード変換プログラムを提供することを目的とする。

本発明の代表的なものを示せば、次の通りである。ソースコード変換装置によるソースコード変換方法は、ソフトウェアのソースコードを入力するステップと、異なる複数の変換ルールを入力するステップと、前記ソースコードを、前記異なる複数の変換ルールにより、検証ツールの入力言語で記述された検査コードに変換するステップとを有することを特徴とする。

本発明によれば、細粒度に分割された複数の変換ルールを入力するインタフェースを所有する。そのため、利用者による抽象化の水準の変更は、検査対象のソースコードに対応した、異なる複数の変換ルールを選択して入力する操作により、容易に実現される。

本発明の基本概念を説明するための図。 本発明のソースコード変換処理における、変換ルールの入力インタフェースについて説明する図。 本発明の第一の実施例になるソースコード変換システムの構成例を示す図。 図３Ａの変換システムにおけるソースコード変換装置の構成例を示す図。 第一の実施例の処理フローの例を示す図。 ソースコード変換装置に対する入力操作の一例を示す図。 ソースコード変換装置に対する入力操作の他の例を示す図。 ソースコード変換装置の動作を説明する図。 ソースコード変換の手順をより詳細に説明する図。 モデルの抽象化の一例を示す図。 モデルの抽象化の一例を示す図。 本発明の第二の実施例になるソースコード変換装置の処理フローの例を示す図。 本発明の第三の実施例における、変換の妥当性の検証の手順を詳細に説明する図。 従来例のソースコード変換装置の一例を示す図。

本発明では、異なる複数の変換ルールを用いて検査対象のソースコードをモデルチェッカの入力言語で記述された検査コードへと変換する。前記異なる複数の変換ルールは、検査対象のソースコードをモデルチェッカの入力言語で記述された検査コードへと変換し、抽象化する一連の処理を細粒度に分割したものであり、複数の変換ルールを組み合わせて用いることにより、前記ソースコードから前記検査コードへの変換が実現される。

本発明において、検査対象のソースコードを検査コードへと変換する一連の処理を、抽象化の処理も含めて、細粒度に分割し、分割されたそれぞれを、「変換ルール」と呼ぶ。本発明により実現されるソースコード変換装置は、ソースコードを検査コードへ変換する時、異なる複数の変換ルールが、利用者によって、選択され、入力されるためのインタフェースを所有する。前記変換ルールは、事前にソースコード変換装置内部に蓄積された複数の変換ルールの中からの選択と、利用者の記述と、のいずれかの手段により入力される。

また、本発明において、変換ルールは、ソースコードを、前記ソースコードの記述言語に依存しない、汎化されたプログラム情報をもつ形式（汎化モデル）へと変換する実装−汎化変換ルールと、汎化モデルを抽象化する抽象化変換ルールと、汎化モデルをモデルチェッカの記述言語へと変換する汎化−検査変換ルールに分類される。換言すると、異なる複数の変換ルールは、ソースコードを特定のプログラミング言語に依存しない形式である中間形式へと変換する第１変換ルールと、前記中間形式に対して抽象化処理を行う第２変換ルールと、前記中間形式から前記検査コードに変換する第３変換ルールとに分類される。ソースコードから検査コードへの変換は、ソースコードを、実装−汎化変換ルールにより、汎化モデルへと変換するステップと、前記汎化モデルを、抽象化変換ルールにより抽象化するステップと、前記汎化モデルを、汎化−検査変換ルールにより、検査コードへと変換するステップと、の３つのステップを続けて行うことで実現される。換言すると、ソースコードから検査コードへの変換は、前記第１、第２、第３の変換ルールを各々１つ以上入力するステップと、前記第１変換ルールを用いて、ソフトウェアのソースコードを、前記中間形式へと変換するステップと、前記第２変換ルールを用いて、前記中間形式で表現されたソフトウェアを抽象化するステップと、前記第３変換ルールを用いて、前記中間形式を検証ツールの入力言語で記述された検証用コードに変換するステップの３つのステップを続けて行うことで実現される。

また、本発明において、検査対象のソースコードを、検査コードへと変換する一連の処理にて、内部的に保持される情報（モデル）は、その形式をメタモデルにより定義される。前記モデルは、検査対象のソースコードに対応する情報をもつ実装モデルと、前述の汎化モデルと、モデルチェッカの記述言語に対応する情報をもつ検査モデルと、に分類される。実装モデルは、そのメタモデルであるメタ・実装モデルにより定義され、汎化モデルは、そのメタモデルであるメタ・汎化モデルにより定義され、検査モデルは、そのメタモデルであるメタ・検査モデルにより定義される。前述のそれぞれのメタモデルは、データ構造の定義と、データに含まれる要素間の制約に関する情報とを保有する。

以下、図面を参照して本発明の実施形態について詳しく説明する。
まず、図１、図２を参照しながら本発明の基本概念を説明する。本発明では、図１に示したように、ソースコードを、複数の変換ルールの組み合わせた変換処理を行うことにより、既存モデル検査装置に適合した検査コードへ変換する。すなわち、（ａ）“変換”を細粒度に分割し、複数の「変換ルール」の組み合わせとしてパッケージ化することで、柔軟な変換を実現する。（ｂ）利用者（検査者）は、検査対象のソースコードを入力し、対象のソースコードと検査水準に応じた「変換ルール」を選択して、所望の検査コードを得る。

本発明における、「変換ルール」の例を挙げると次の通りである。
（ａ）単純な構文変換
「C言語の条件分岐 (If文・Switch文)」を、「検査コードの条件分岐(If 文)」に変換
「C言語の繰り返し文（for文・while文・…）」を、「検査コードの繰り返し(Do文)」に変換
（ｂ）外部環境のモデル化
「データ読込み」を、「ランダム入力」へ置き換え
（ｃ）抽象化
「繰り返しの除去」
「条件の簡略化」
図２により、本発明のソースコード変換処理における変換ルールの入力インタフェースについて、説明する。

本発明によれば、細粒度に分割された複数の変換ルールを入力するインタフェースを所有することによって、利用者による抽象化の水準の変更は、複数の異なる変換ルールを選択・入力する操作により容易に実現される。すなわち、利用者による抽象化の水準の変更は、ドメイン情報や、検査したい性質、検査水準の情報（抽象化による性質への影響）に応じて、利用者が複数の異なる変換ルールを選択して呼び出し、ソースコード変換処理装置へ入力する操作により容易に実現される。これにより、抽象化の水準の変更が困難である課題が解決される。

本発明によれば、異なる複数の変換ルールを用いて検査対象のソースコードをモデルチェッカの入力言語で記述された検査コードへと変換する手順を含んでいる。前記異なる複数の変換ルールは、実装−汎化変換ルールと、抽象化変換ルールと、汎化−検査変換ルールとに分類され、変換が段階的に行われる手順とを含んでいる。検査対象のソースコードの設計変更に追従する際には、変更に関連する変換ルールのみを変更すればよく、変更が最小限にとどめられる。加えて、実装モデルと、汎化モデルと、検査モデルとをそれぞれメタモデルで定義し、制約を加えることにより、変換ルールによる変換結果が不正でないことを検証可能となる。これにより、検査対象のソースコードを検査コードへと抽象化しながら変換する一連の処理を、細粒度の変換ルールを組み合わせることで実現することによって生じる、変換ルールの検証コストの増大を防ぐことが出来る。

また、異なる検査ツールにて検査するために、前記検査ツールの形式で出力する際には、メタ・検査モデルと、汎化−検査変換ルールのみを作成すればよく、作成部分が最小限にとどめられる。これにより、異なるモデルチェッカにて検査する際のコストが高いという課題が解決される。

次に、本発明の第一の実施例になるソースコード変換装置および変換処理方法を、図３Ａないし図８を参照しながら説明する。

図３Ａは、第一の実施例になるソースコード変換装置を含むソースコード変換システムの構成例を示す図である。本発明の実施形態に適用されるソースコード変換装置１０００は、検査対象のソースコードを検査コードに変換する装置であり、入力部１１００と、変換処理部１２００と、出力部１３００と、記憶部１４００と、制御部１５００とを有する。２０００はモデル検査ツール、３０００は検査結果を示す。図３Ｂに、ソースコード変換装置の構成例を示す。入力部１１００は、ソースコード入力部１１０１と、変換ルール入力部１１０２とを有する。変換処理部１２００は、モデル構築部１２０１、実装−汎化モデル変換部１２０２、抽象化モデル変換部１２０３、及び、汎化−検査モデル変換部１２０４を備えている。出力部１３００は、検査コード書出し部１３０１を有する。記憶部１４００は、変換ルールデータベース１４０１、メタモデルデータベース１４０２、およひ、書出しルールデータベース１４０３を有する。

ソースコード変換装置１０００は、例えば、１台のコンピュータ、あるいはネットワークを介して接続された複数のコンピュータ上で動作するプログラムとして実施される。ソースコード０００１と変換ルール集合０００２とは、例えば、コンピュータ上の記憶装置から読込む方法と、コンピュータに接続された入力デバイスにより直接入力される方法等の方法により入力される。また、検査コード０００５は、例えば、コンピュータ上の記憶装置に書出す方法と、コンピュータのディスプレイ装置に表示する方法により出力される。

入力部１１００は、ユーザによって入力されるデータを受付け、入力されたデータを変換処理部１２００へと供給する処理を行う。入力部１１００は、ソースコード０００１に関する情報と、細粒度に分割された複数の変換ルール、すなわち「変換ルール集合」０００２に関する情報とを受付け、変換処理部１２００へ供給する。ある実施形態においては、入力部１１００は、ユーザによる、変換処理部の駆動や制御、出力部の駆動や制御、に関する指示を受け付けてもよい。

変換処理部１２００は、入力部より、ソースコード０００１の情報と、ソースコード０００１に適用すべき変換ルール集合０００２の情報とを供給され、ソースコード０００１を、変換ルール集合０００２により変換する処理を行い、変換結果の情報を、出力部１３００に供給する。ある実施形態においては、入力部より供給される変換ルール集合０００２に関する情報は、記憶部に格納された変換ルールを指し示す識別情報のみが含まれていて、変換ルール集合０００２の実体を、前記識別情報を用いて記憶部１４００より取り出し、変換に用いてもよい。

変換処理部１２００は、モデル構築部１２０１と、実装−汎化モデル変換部１２０２と、抽象化モデル変換部１２０３と、汎化−検査モデル変換部１２０４とを有する。本実施形態において、変換処理部１２００は、メタモデルと、変換ルールを用いたモデル変換により、ソースコード情報１００１を、検査モデル１００８へと変換する。メタ・実装モデル１００２と、メタ・汎化モデル１００３と、メタ・検査モデル１００４と、は、例えば、非特許文献２に記載のMOFにて記述する。また、例えば、非特許文献３に記載されているQVTにて、実装−汎化変換ルール１００５と、抽象化変換ルール１００６と、汎化−検査変換ルール１００７とを記述し、モデルの変換を行う。前記変換は、既に例示した方法の他のモデル変換方法でも良く、また、複数の方法を混在させてもよい。

また、ある実施例においては、実装−汎化モデル変換部１２０２と、抽象化モデル変換部１２０３と、汎化−検査モデル変換部１２０４とをそれぞれ独立させず、同一の部位により行われても良く、さらに、実装モデル１２０５と、汎化モデル１２０６と、検査モデル１００８と、のそれぞれのメタモデルとして、メタ・実装モデル１００２と、メタ・汎化モデル１００３と、メタ・検査モデル１００４とを個別に用意せず、単一のメタモデルにより、実装モデル１２０５と、汎化モデル１２０６と、検査モデル１００８とを定義してもよい。また、ある実施例においては、メタ・実装モデル１００２と、メタ・汎化モデル１００３と、メタ・検査モデル１００４と、は、複数の方式により、それぞれ実装モデル１２０５、汎化モデル１２０６、検査モデル１００８、の形式や制約を定義してもよい。例えば、それぞれのメタモデルは、前記MOFによる定義のほかに、非特許文献４に記載されているOCLにて記載された制約条件を含み、モデルの変換を行った際に、制約条件を満たしているかどうかの検証を行う方法があり得る。

モデル構築部１２０１は、ソースコード入力部１１０１からソースコード情報１００１を受け取り、実装モデル１２０５へと変換する。実装モデル１２０５の形式は、そのメタモデルであるメタ・実装モデル１００２により、定義される。実装モデル１２０５は、本発明の効果を最大限に得るためには、ソースコード情報１００１と相互に変換するのに必要十分な情報を持つことが望ましいが、ある実施形態によっては、検査コードを出力するという目的を逸しない程度にて、情報の省略や、追加があってもかまわない。

ある実施形態においては、モデル構築部１２０１は、ソースコード入力部１１０１と不可分な様態で実装され、ソースコード情報１００１が生じない形態で処理が進んでもよい。

実装−汎化モデル変換部１２０２は、実装−汎化変換ルール１００５と、メタ・実装モデル１００２と、メタ・汎化モデル１００３とを用いて、実装モデル１２０５を、汎化モデル１２０６へと、変換する。汎化モデルは、複数のプログラミング言語における構造や処理を表現可能なデータ構造をもつ。例えば、汎化モデル中では、ソースコード０００１におけるIf文とSwitch文とを区別せず、選択的実行文として表現する。ある実施形態においては、実装モデル１２０５を、汎化モデル１２０６へと変換する際、実装−汎化変換ルール１００５のみを用いることもあり得る。また、ある実施形態において、実装−汎化変換ルール１００５が、複数の変換ルールを含む場合には、複数の変換ルールを統合して１つの変換ルールとし、実装モデル１２０５から汎化モデル１２０６への変換に利用する方法があり得る。また、ある実施形態において、実装−汎化変換ルール１００５が、複数の変換ルールを含む場合には、変換処理を複数回繰り返すことで、実装モデル１２０５から汎化モデル１２０６への変換を行う手順があり得る。

抽象化モデル変換部１２０３は、抽象化変換ルール１００６と、メタ・汎化モデル１００３とを用いて、汎化モデル１２０６の抽象化を行う。抽象化の例としては、選択文における条件式を、恒真、もしくは恒偽、もしくは非決定的な選択で置き換える方法があり得る。ある実施形態においては、汎化モデル１２０６を抽象化する際、抽象化変換ルール１００６のみを用いることもあり得る。また、ある実施形態において、抽象化変換ルール１００６が、複数の変換ルールを含む場合には、複数の変換ルールを統合して１つの変換ルールとし、汎化モデル１２０６の抽象化に用いる方法があり得る。また、ある実施形態において、抽象化変換ルール１００６が、複数の変換ルールを含む場合には、変換処理を複数回繰り返すことで、汎化モデル１２０６の変換を行う手順があり得る。

汎化−検査モデル変換部１２０４は、汎化−検査変換ルール１００７と、メタ・汎化モデル１００３と、メタ・検査モデル１００４とを用いて、汎化モデル１２０６を、検査モデル１００８へと、変換する。例えば、検査コード０００５がPromela形式である場合、汎化モデルにおいて選択的実行文として表現された要素は、検査モデルにおいてはIf文として表現される。ある実施形態においては、汎化モデル１２０６を、検査モデル１００８へと変換する際、汎化−検査変換ルール１００７のみを用いることもあり得る。また、ある実施形態において、汎化−検査変換ルール１００７が、複数の変換ルールを含む場合には、複数の変換ルールを統合して１つの変換ルールとし、汎化モデル１２０６から検査モデル１００８への変換に利用する方法があり得る。また、ある実施形態において、汎化−検査変換ルール１００７が、複数の変換ルールを含む場合には、変換処理を複数回繰り返すことで、汎化モデル１２０６から検査モデル１００８への変換を行う手順があり得る。

出力部１３００は、変換処理部１２００より供給された、変換結果の情報を用いて、検査コード０００５を出力する。ある実施形態においては、検査コード０００５の出力に際して、例えばモデルチェッカの記述言語の文法情報などの情報を記憶部から供給されてもよい。

検査コード書出し部１３０１は、メタ・検査モデル１００４と、記憶部１４００の書出しルールデータベース１４０３から取得した検査コード書出しルール１００９とを用いて、検査モデル１００８を検査コード０００５へと変換する。たとえば、非特許文献５に記載される方法にて、検査コード書出しルール１００９を記述し、検査モデル１００８から、検査コード０００５への変換を行う。ある実施例においては、これに限らず、検査モデル１００８を、検査に利用するモデルチェッカの記述形式へと変換する任意の方法でもよい。検査コード０００５は、例えば、モデルチェッカとしてＳＰＩＮを用いる場合には、ＳＰＩＮの入力言語である、Ｐｒｏｍｅｌａにより記述される。

記憶部１４００において、変換ルールデータベース１４０１と、メタモデルデータベース１４０２と、書出しルールデータベース１４０３のそれぞれは、例えば、関係データベース、もしくは、階層型データベースなどの、コンピュータ上にて実現される任意のデータ格納方式で実現される。変換ルールデータベース１４０１と、メタモデルデータベース１４０２と、書出しルールデータベース１４０３と、は互いに同一の方式で実現されている必要性は無く、互いに異なる方式で実現されていてもよい。また、検査ルールデータベース１４０１と、メタモデルデータベース１４０２と、書出しルールデータベース１４０３と、のそれぞれは、単一の方式で実現されている必要性は無く、例えば、保有すべき情報の一部を関係データベースに格納し、保有すべき情報の一部を、発明を実現するコンピュータプログラム中に組込むなど、それぞれ異なる方式の組み合わせで実現されていてもよい。

記憶部１４００は、入力部１１００と、変換処理部１２００と、出力部１３００とが、それぞれの処理を行うのに必要な情報を供給する。例えば、記憶部１４００は、変換ルールに関する情報と、メタモデルに関する情報と、モデルチェッカの記述言語の文法に関する情報とを格納する。

変換ルールデータベース１４０１は、既に述べたとおり、変換ルールを、メタデータとともに保有する。前記メタデータは、変換ルールを選択するためのものであり、実装−汎化変換ルール１００５と、抽象化変換ルール１００６と、汎化−検査変換ルール１００７の、それぞれ異なる情報を持つ方法があり得る。実装−汎化変換ルール１００５のメタデータは、例えば、変換元ソースコードの記述言語の種類があり得る。抽象化変換ルール１００６のメタデータは、例えば、抽象化を分かりやすく端的に表現した名前、簡単な説明、「データの抽象化」、「処理の抽象化」などの抽象化の種別、自然語もしくはアルファベットや数値で表現された抽象化による状態数削減効果、自然語もしくはアルファベットや数値で表現された抽象化による性質への影響、抽象化の適用できるソフトウェアのドメイン、があり得る。汎化−検査変換ルール１００７のメタデータは、例えば、検査に使用するモデルチェッカを指し示す名前があり得る。

以降、図４ないし図６を参照しながら入力部１１００と、変換処理部１２００と、出力部１３００と、記憶部１４００と、制御部１５００の詳細に関し、説明する。

まず、本実施例におけるソースコード変換手順の一例を、図４を参照しながら説明する。本実施例におけるソースコード変換手順は、ソースコード入力ステップＳ１０１と、変換ルール入力ステップＳ１０２と、変換ルール適用ステップＳ１０３と、検査コード出力ステップＳ１０４とからなる。

まず、ソースコード入力ステップＳ１０１において、ソースコード入力部１１０１により、ソースコード０００１がソースコード変換装置１０００に読み込まれ、ソースコード情報１００１へと変換される。

ソースコード入力部１１０１は、利用者から入力された検査対象のソースコード０００１を受付け、ソースコード情報１００１へと変換する。ソースコード０００１は、例えば、JIS X3010-1993に公開されるプログラミング言語Ｃにより記述される。ソースコード情報１００１は、具体的には、例えば抽象構文木の形式で保持される。ソースコード情報１００１の形式は、抽象構文木に限らず、構造や論理などソースコード０００１の検査に要する情報を保持する、任意の形式でもよい。

ソースコード入力ステップＳ１０１に続き、変換ルール入力ステップＳ１０２において、変換ルール入力部１１０２により、細粒度に分割された複数の変換ルールである変換ルール集合０００２がソースコード変換装置１０００に読み込まれる。この変換ルール入力ステップＳ１０２では、変換前のモデルの要素と、変換後のモデル要素との対応関係と、変換によって変換前のモデルの要素に加えられる操作との一方もしくは両方が定義される。変換ルール集合０００２をソースコード変換装置１０００に読み込む処理は、利用者による一度の操作で行われる必要性は無く、繰り返し操作により行われてもよい。また、ソースコード入力ステップＳ１０１と、変換ルール入力ステップＳ１０２は、必ずしもこの順番で完了する必要性は無く、ソースコード入力部１１０１によりソースコード情報１００１が生成される前にソースコード０００１が入力され、かつ、変換ルール入力部１１０２が変換ルール入力処理のためにソースコード情報１００１を要求するまえにソースコード０００１が入力されていれば良く、したがって、ソースコード入力ステップＳ１０１の処理と、変換ルール入力ステップＳ１０２の処理とが混在する順番で処理がすすんでもよい。例えば、ソースコード入力部１１０２がソースコード０００１を受付け、続いて、変換ルール入力部が、変換ルール集合０００２を受付け、続いて、ソースコード入力部１１０２が、ソースコード０００１をソースコード情報１００１へ変換する、手順があり得る。

変換ルール入力部１１０２は、利用者から入力された変換ルール集合０００２を受け付ける。利用者から変換ルール集合０００２を受け付ける方法は、例えば、次に示す方法があり得る。

１つめの変換ルール入力方法の例として、変換ルール入力部１１０２は、変換ルール集合０００２の一部として、利用者が手作業で直接入力した変換ルールを受け取る。

２つめの変換ルール入力方法の例として、図５Ａに示したように、変換ルール集合０００２の少なくとも一部は、利用者が記述した変換ルール（記述）００１０により入力しても良い。あるいはまた、入力部１１００が、記憶部１４００から変換ルールの一覧００１５を取得し、それを利用者に一覧などの形式で提示し、前記一覧から利用者が選択すること、変換ルール集合０００２の入力を受け付けてもよい。すなわち、利用者が、変換ルールの入力に前置して、変換ルールの検索条件００１１を入力部１１００の変換ルール入力部１１０２に入力（記述）し、続いて、変換ルール入力部１１０２が、前記検索条件に合致する変換ルールを、記憶部１４００が有する変換ルールデータベース１４０１から取得し変換ルール一覧００１５として前記利用者に提示する。続いて、前記利用者が、提示された前記変換ルール一覧に含まれる１つ以上の変換ルールを選択する。この利用者によって選択された１つ以上の変換ルールを、変換ルール入力部１１０２が、変換ルール集合０００２の一部として受け付ける。

３つめの変換ルール入力方法の例として、まず、利用者が、変換ルールの入力に前置して、変換ルールの検索条件００１１を変換ルール入力部１１０２に入力し、続いて、変換ルール入力部１１０２が、前記検索条件に合致する変換ルールを、変換ルールデータベース１４０１から取得して、変換ルール集合０００２の一部として受け付けても良い。

４つめの変換ルール入力方法の例として、図５Ｂに示したように、入力されたソースコード０００１から、変換ルール入力部１１０２が、変換ルールの検索条件００１２を抽出、生成し、さらに、前記検索条件に合致する変換ルールを、変換ルールデータベース１４０１から取得し、変換ルール集合０００２の一部として受け付ける。

２つめの変換ルール入力方法の例と、３つめの変換ルール入力方法の例と、４つめの変換ルール入力方法の例における、変換ルール検索条件の因子としては、例えば、後述する、変換ルールデータベース１４０１において、変換ルールのメタデータとして格納される情報があり得る。

また、５つめの変換ルール入力方法の例として、変換ルール入力部１１０２は、何からの方法で入力された変換ルールを加工することにより、変換ルールを受け付ける。前記加工方法の例としては、変換ルールデータベース１４０１には、ソースコード０００１中の変数名などをパラメタ化した状態で変換ルールを保持しておき、例えば利用者の明示的な入力による方法などにより、ソースコード０００１の情報にてパラメタを埋めたものを、変換ルール集合０００２に含める方法があり得る。５つ目の変換ルール入力方法の例において、加工元の変換ルールの入力方法としては、既に述べた１つめの変換ルール入力方法の例など、入力された変換ルールを加工せずに用いる場合と同様の方法があり得る。

変換ルール入力部１１０２が、変換ルール集合０００２を受け付ける方法は、これらの変換ルール入力方法に限らず、変換処理部１２００で用いる変換ルールの集合を受け付ける任意の方法でよく、また、これらの変換ルール入力方法の１つ以上の組合せにより変換ルール集合０００２を受け付けてもよい。

変換ルール入力ステップＳ１０２に続き、変換ルール適用ステップＳ１０３において、モデル構築部１２０１がソースコード情報１００１を実装モデル１２０５へと変換し、続いて、実装−汎化モデル変換部１２０２が実装モデル１２０５を汎化モデル１２０６へと変換し（Ｓ１０３１）、続いて、抽象化モデル変換部１２０３が汎化モデル１２０６を抽象化し（Ｓ１０３２）、続いて、汎化−検査モデル変換部１２０４が汎化モデル１２０６を検査モデル１００８へと変換する（Ｓ１０３３）。変換ルール入力ステップＳ１０２と、変換ルール適用ステップＳ１０３とは、必ずしもこの順番で処理が完了する必要性は無く、実装−汎化モデル変換部１２０２の処理までに実装−汎化変換ルール１００５が入力され、かつ、抽象化モデル変換部１２０３の処理までに抽象化変換ルール１００６が入力され、かつ、汎化−検査モデル変換部の処理までに汎化−検査変換ルール１００７が入力されていればよい。

変換ルール適用ステップＳ１０３に続き、検査コード出力ステップＳ１０４において、検査コード書出し部１３０１により、検査モデル１００８が、検査コード０００５として書き出される。検査コード０００５の書出し先の指定は、必ずしも変換ルール適用ステップＳ１０３の後である必要性は無く、検査コード０００５の書出しよりも先であればよい。例えば検査コード０００５の書出し先の指定がソースコード入力ステップＳ１０１と平行して行われる手順があり得る。

次に、図７、図８Ａ、図８Ｂを用いて、変換の手順をより詳細に説明する。図７に示したように、本発明では、モデル変換技術を利用し、段階的に変換するために、次のような処理を行う。

（１）ソースコード０００１をこれと（ほぼ）等価な「実装モデル」１２０５へと変換
（２）「実装モデル」を特定のプログラミング言語に依存しない形式にて構造や論理などのプログラム情報を表現する「汎化モデル」へと変換
すなわち、異なる複数の第１変換ルール１００５−１〜１００５−ｎの少なくとも１つを用いて、「実装モデル」１２０５を特定のプログラミング言語に依存しない形式である中間形式の「汎化モデル」１２０６へと変換する。図７の例では、第１変換ルールとして、「“ｉｆ文”→条件分岐」、「“ｓｗｉｔｃｈ文”→条件分岐」、「“ｗｈｉｌｅ文”→“繰り返し”」、「“ｆｏｒ文”→“繰り返し”」の少なくとも４つの異なる変換ルールが選択されている。

（３）汎化モデル１２０６に対して、抽象化のための変換を実施
すなわち、異なる複数の第２変換ルール１００６−１〜１００６−ｎの少なくとも１つを用いて、前記中間形式の汎化モデルに対して抽象化処理を行う。図７の例では、第２変換ルールとして、「データ読み込み→ランダム入力」、「データの抽象化」の少なくとも２つの異なる変換ルールが選択されている。

（４）汎化モデルを、「検査モデル」に変換し、コード生成（出力）
すなわち、異なる複数の第３変換ルール１００７−１〜１００７−ｎの少なくとも１つを用いて、前記中間形式の汎化モデル１２０６から検査コードの生成に要する情報を有する検査モデル１００８に変換する。図７の例では、第３変換ルールとして、第１変換ルールに対応した「“条件分岐”→“ｉｆ”文」、「“繰り返し”→“ｄｏ”文」の少なくとも２つの異なる変換ルールが選択されている。

また、実装モデル、汎化モデル、検査モデルは、それぞれ構文を定義する「メタモデル」によりデータ構造と意味論が定義される。

このように、実装モデルから汎化モデルへの変換に際しては、例えば、変換対象ソースコードの記述言語の文法が、繰り返し処理の記法として“ｆｏｒ文”や“ｗｈｉｌｅ文”を含むとき、使用者が“ｆｏｒ文”を「繰り返し」へ変換するルールと、“Ｗｈｉｌｅ文”を「繰り返し」へ変換するルールとを、既に述べた変換ルール入力方法を用いて、第１変換ルールとして選択する。汎化モデルの抽象化の変換に際しては、使用者が検査水準（抽象化の度合い）を決定し、決定した検査水準を達成する変換ルールとして、例えば、外部データ読込みに関する命令および一連の処理をランダムな入力へと変換するルールと、特定のデータ型をより抽象度の高い型へと変換するルールとを、既に述べた変換ルール入力方法を用いて、第２変換ルールとして選択する。さらに、汎化モデルから検査モデルへの変換に当たっては、例えば、モデルチェッカの入力言語の文法が、繰り返し処理の記法として“ｄｏ文”をもつとき、使用者が「繰り返し」を“ｄｏ文”へ変換するルールを、既に述べた変換ルール入力方法を用いて、第３変換ルールとして選択する。変換ルールは、複数のソフトウェアにまたがって適用可能な汎用的なルールなど、繰り返し利用可能なものがデータベース化される。データベースに格納された変換ルールは、使用者による検索やルール選択の判断材料として用いられるメタ情報として、ドメイン情報や検査水準（抽象化による検査への影響）の情報を有する。

また、変換ルールの選択方法としては、次のようなものがある。
（１）汎用的なルール： 常に選択
（２）特定のライブラリに依存したルール： 使用ライブラリや、検査対象のドメイン(カテゴリ)を入力することで、まとめて選択
（３）抽象化に対応したルール：（検査したい性質・検査水準を入力して得た）変換ルール一覧から、利用者が選択、もしくは利用者自身が記述して入力、もしくは検査したい性質などから、自動生成。

図８Ａ、図８Ｂに夫々、モデルの抽象化の一例を示す。モデルの抽象化により、状態数を削減することができる。しかし、抽象化によりモデルの性質に影響を与えることがある。たとえば、検出された欠陥（反例）が、もとのシステムに存在しない、もとのシステムに存在する欠陥を発見できない、等である。一方で、性質に影響を与えない健全な抽象化は、状態数削減効果が小さい傾向がある。

本実施例によれば、細粒度に分割された複数の変換ルールを入力するインタフェースを所有することによって、利用者による抽象化の水準の変更は、変換ルールを入力する操作により容易に実現される。すなわち、複数の細粒度の変換ルールを利用者が入力インタフェースにより選択できるため、図８Ａ、図８Ｂに示したような抽象化の水準を、状況に応じて利用者が容易に選定、変更することが可能となる。

ソースコード変換法は、複数の変換ルールを用いて検査対象のソースコードをモデルチェッカの入力言語で記述された検査コードへと変換する手順を有し、前記変換ルールは、実装−汎化変換ルールと、抽象化変換ルールと、汎化−検査変換ルールと、に分類され、変換が段階的に行われる。これにより、検査対象のソースコードの設計変更に追従する際には、複数の変換ルールの中の変更に関連する変換ルールのみを変更すればよく、変更が最小限にとどめられる。加えて、実装モデルと、汎化モデルと、検査モデルとをそれぞれメタモデルで定義し、制約を加えることにより、変換ルールによる変換結果が不正でないことを検証可能となる。これにより、検査対象のソースコードを検査コードへと抽象化しながら変換する一連の処理を、細粒度の変換ルールを組み合わせることで実現することによって生じる、変換ルールの検証コストの増大を防ぐことが出来る。

また、細粒度に分割された複数の変換ルールを入力するインタフェースを所有することによって、利用者による抽象化の水準の変更は、検査したい性質、検査水準に応じて、利用者が変換ルールを選択・入力する操作で容易に実現される。これにより、抽象化の水準の変更が困難であるという課題が解決される。例えば、繰り返し実行時のみに発生する特定の不具合がある場合、その繰返しを除去することで、特定の不具合の検出はできなくなるものの、その繰返しを発生原因に含まない不具合の検出は可能であるままに、大幅に状態数を削減できる。

さらに、モデルの変換ルールをデータベースに蓄積・再利用することで、検査対象ソースコードの設計変更や、別ソフトウェアへの応用に、低コストで対応可能になる。

なお、異なる検査ツールにて検査するために、検査ツールの形式で出力する際には、メタ・検査モデルと、汎化−検査変換ルールのみを作成すればよく、作成部分が最小限にとどめられる。これにより、異なるモデルチェッカにて検査する際のコストが高いという課題が解決される。

図９により、本発明の第二の実施例になるソースコード変換装置および変換処理方法を説明する。この実施例においては、図９に示すように、検査コード出力ステップＳ１０４に続き、変換ルール入力ステップＳ１０２へと進むことで、既に入力されたソースコード０００１を、繰り返し、異なる変換ルール集合０００２を用いて、変換する手順をとってもよい。また、ある実施例においては、検査コード出力ステップＳ１０４に続き、変換ルール入力ステップＳ１０２へと進み、既に入力された変換ルール集合０００２の全てまたは一部と、新たに変換ルール入力ステップＳ１０２で入力された変換ルール集合０００２をあわせて、変換ルール集合０００２として用いてもよい。

本実施例によれば、細粒度に分割された複数の変換ルールを入力するインタフェースを所有し、入力されたソースコードと、変換に用いた変換ルール集合を保存し、前記ソースコードを前記変換ルール集合の一部を入れ替えて変換できることにより、異なる抽象度の複数の検査コードを生成する場合などの、同一のソースコードに対して繰り返し変換をおこなう手間を削減することができる。

図１０により、本発明の第三の実施例になるソースコード変換装置および変換処理方法を説明する。本実施例では、ソースコードから検査コードを得る過程において生成される実装モデルと、汎化モデルと、検査モデルとを制約条件により検証するステップを有する。

図１０を用いて、変換の妥当性の検証手順を詳細に説明する。

特定の変換ルールが、その変換に際して対象モデルについての前提条件をもつ場合、変換対象のモデルにおいて、前記特定の変換ルールの前提条件が、他の変換ルールの適用によって満たされなくなることがあり得る。このように前提条件が満たされないときに前記特定の変換ルールによってモデル変換を実施すると、変換結果のモデルが不正な状態になり得る。また、単に変換ルールに誤りが含まれるときも、変換結果のモデルが不正な状態になり得る。

本実施例では、ソフトウェアのソースコード０００１を入力するステップと、ソースコードの情報をもつ実装モデル１２０５を特定のプログラミング言語に依存しない形式である中間形式（汎化モデル１２０６）へと変換する第１変換ルールを入力するステップと、中間形式に対して抽象化処理を行う第２変換ルールを入力するステップと、中間形式から検査コードの情報をもつ検査モデル１００８に変換する第３変換ルールを入力するステップと、ソフトウェアのソースコード０００１を解析して実装モデル１２０５へと変換するステップと、前記第１変換ルールを用いてソフトウェアのソースコード０００１を前記中間形式の汎化モデル１２０６へと変換するステップと、第２変換ルールを用いて、前記中間形式で表現されたソフトウェアを抽象化するステップと、第３変換ルールを用いて、前記中間形式を検査モデル１００８に変換するステップと、検査モデル１００８を用いて検証ツールの入力言語で記述された検査コードを生成するステップと、前記各段階のモデルを各々第１の制約条件００３０、第２の制約条件００３１、第３の制約条件００３０２で検証するステップとを有する。

前記各段階のモデルの、各々第１の制約条件００３０、第２の制約条件００３１、第３の制約条件００３２による検証は、例えば、非特許文献２に開示されるＭＯＦでメタモデルを記述することによって、もしくは、非特許文献４に開示されるＯＣＬによりメタモデルにより定義されるモデルに対する制約条件を記述することによって、実現される。

本実施例によれば、メタモデルおよび制約条件を用いることで、変換ルール同士の衝突や変換ルールの不具合による変換の妥当性を保証できる。このモデル変換では、メタモデルによって定義された形式のモデルが生成される。また、制約条件を追加し、生成されたモデルの妥当性を制約条件００３０〜００３２で検証することができる。

０００１ ソースコード
０００２ 変換ルール集合
０００３ メタモデル
０００４ 書出しルール
０００５ 検査コード
１０００ ソースコード検査装置
１１００ 入力部
１２００ 変換処理部
１３００ 出力部
１４００ 記憶部
１００１ ソースコード情報
１００２ メタ・実装モデル
１００３ メタ・汎化モデル
１００４ メタ・検査モデル
１００５ 実装−汎化変換ルール
１００６ 抽象化変換ルール
１００７ 汎化−検査変換ルール
１００８ 検査モデル
１００９ 検査コード書出ルール
１１０１ ソースコード入力部
１１０２ 変換ルール入力部
１２０１ モデル構築部
１２０２ 実装−汎化モデル変換部
１２０３ 抽象化モデル変換部
１２０４ 汎化−検査モデル変換部
１２０５ 実装モデル
１２０６ 汎化モデル
１３０１ 検査コード書出し部
１４０１ 変換ルールデータベース
１４０２ メタモデルデータベース
１４０３ 書出しルールデータベース
１５００ 制御部
Ｓ１０１ ソースコード入力 ステップ
Ｓ１０２ 変換ルール入力 ステップ
Ｓ１０３ 変換ルール適用 ステップ
Ｓ１０４ 検査コード出力 ステップ。

Claims (18)

1. ソースコード変換装置によるソースコード変換方法であって、
   ソフトウェアのソースコードを入力するステップと、
   異なる複数の変換ルールを入力するステップと、
   前記ソースコードを、前記異なる複数の変換ルールにより、検証ツールの入力言語で記述された検査コードに変換するステップとを有する
   ことを特徴とするソースコード変換方法。
2. 請求項１において、
   前記異なる複数の変換ルールは、検査対象の前記ソースコードを前記検査コードへと変換し抽象化する一連の処理を、細粒度に分割したものである
   ことを特徴とするソースコード変換方法。
3. 請求項１において、
   前記変換ルールは、
   ソースコードを特定のプログラミング言語に依存しない形式である中間形式へと変換する第１変換ルールと、
   前記中間形式に対して抽象化処理を行う第２変換ルールと、
   前記中間形式から前記検査コードに変換する第３変換ルールとを含み、
   ソフトウェアのソースコードを入力するステップと、
   少なくとも１つの前記第１変換ルールを入力するステップと、
   少なくとも１つの前記第２変換ルールを入力するステップと、
   少なくとも１つの前記第３変換ルールを入力するステップと、
   前記第１変換ルールを用いて、前記ソフトウェアのソースコードを、前記中間形式へと変換するステップと、
   前記第２変換ルールを用いて、前記中間形式で表現された前記ソフトウェアを抽象化するステップと、
   前記第３変換ルールを用いて、前記中間形式を検証ツールの入力言語で記述された検証用コードに変換するステップを有する
   ことを特徴とする、ソースコード変換方法。
4. 請求項３において、
   前記中間形式を制約条件により検証するステップを有する
   ことを特徴とする、ソースコード変換方法。
5. 請求項１において、
   前記変換ルールは、C言語の条件分岐を前記検査コードの条件分岐に変換する構文変換を含む
   ことを特徴とする、ソースコード変換方法。
6. 請求項１において、
   前記変換ルールは、C言語の繰り返し文を、前記検査コードの繰り返しに変換する構文変換を含む
   ことを特徴とする、ソースコード変換方法。
7. 請求項１において、
   前記異なる複数の変換ルールの少なくとも一部は、前記ソースコード変換装置の内部に蓄積された複数の変換ルールの中から選択して入力される
   ことを特徴とするソースコード変換方法。
8. 請求項１において、
   前記異なる複数の変換ルールの少なくとも一部は、利用者の記述により入力される
   ことを特徴とするソースコード変換方法。
9. ソースコード変換装置によるソースコード変換方法であって、
   ソフトウェアのソースコードを入力するステップと、
   異なる複数の変換ルールを入力するステップと、
   前記ソースコードを、前記異なる複数の変換ルールにより、検証ツールの入力言語で記述された検査コードに変換するステップとを含み、
   前記複数の変換ルールの少なくとも一部は、前記ソースコード変換装置の内部に蓄積された複数の変換ルールの中から選択して入力される
   ことを特徴とするソースコード変換方法。
10. 請求項９において、
    前記異なる複数の変換ルールは、前記ソースコードを、該ソースコードの記述言語に依存しない汎化されたプログラム情報をもつ汎化モデルへ変換する実装−汎化変換ルールと、前記汎化モデルを抽象化する抽象化変換ルールと、前記汎化モデルを前記検証ツールの記述言語へと変換する汎化−検査変換ルールとを含む
    ことを特徴とするソースコード変換方法。
11. 請求項１０において、
    前記検査対象のソースコードを前記検査コードへと変換する一連の処理において、内部的に保持される情報であるモデルがその形式をメタモデルにより定義され、
    前記モデルは、検査対象のソースコードに対応する情報をもつ実装モデルと、前記汎化モデルと、前記検証ツールの記述言語に対応する情報をもつ検査モデルとを含み、
    前記実装モデルは、そのメタモデルであるメタ・実装モデルにより定義され、
    前記汎化モデルは、そのメタモデルであるメタ・汎化モデルにより定義され、
    前記検査モデルは、そのメタモデルであるメタ・検査モデルにより定義され、
    前記各メタモデルは、データ構造の定義と、データに含まれる要素間の制約に関する情報とを保有する
    ことを特徴とするソースコード変換方法。
12. 請求項１０において、
    前記変換ルールに関する情報は、ソースコード変換装置の記憶部に格納された変換ルールを指し示す識別情報のみが含まれており、
    前記変換ルールの実体を、前記識別情報を用いて前記記憶部取り出し、変換に用いる
    ことを特徴とするソースコード変換方法。
13. 請求項１０において、
    前記入力されたソースコードから、前記変換ルールの検索条件を抽出、生成し、
    前記検索条件に合致する変換ルールを、ソースコード変換装置の記憶部から取得し、前記変換ルールとして受け付ける
    ことを特徴とするソースコード変換方法。
14. 請求項１０において、
    前記実装モデル、前記抽象プログラムモデル、及び前記検査モデルの各中間のモデルは、それぞれ構文を定義するメタモデルによりデータ構造と意味論が定義される
    ことを特徴とするソースコード変換方法。
15. 少なくとも１台のコンピュータ上で動作し、ソースコード変換装置を構成するプログラムであって、
    前記コンピュータを、
    ソフトウェアのソースコードを入力する手段、
    異なる複数の変換ルールを入力する手段、及び
    前記ソースコードを、前記異なる複数の変換ルールにより、検証ツールの入力言語で記述された検査コードに変換する手段
    として機能させるためのソースコード変換プログラム。
16. 請求項１５において、
    前記変換ルールは、
    ソースコードを特定のプログラミング言語に依存しない形式である中間形式へと変換する第１変換ルールと、
    前記中間形式に対して抽象化処理を行う第２変換ルールと、
    前記中間形式から前記検査コードに変換する第３変換ルールとを含み、
    前記コンピュータを、
    前記ソースコードを入力する手段と、
    少なくとも１つの前記第１変換ルールを入力する手段、
    少なくとも１つの前記第２変換ルールを入力する手段、
    少なくとも１つの前記第３変換ルールを入力する手段、
    前記第１変換ルールを用いて、ソフトウェアのソースコードを、前記中間形式へと変換する手段、
    前記第２変換ルールを用いて、前記中間形式で表現された前記ソフトウェアを抽象化する手段、及び
    前記第３変換ルールを用いて、前記中間形式を前記検証ツールの入力言語で記述された検証用コードに変換する手段
    として機能させるためのソースコード変換プログラム。
17. 請求項１６において、
    前記コンピュータを、
    前記中間形式を制約条件により検証する手段
    として機能させるためのソースコード変換プログラム。
18. 請求項１５において、
    前記コンピュータを、
    前記複数の変換ルールの少なくとも一部は、前記ソースコード変換装置の内部に蓄積された複数の変換ルールの中から選択して入力する手段
    として機能させるためのソースコード変換プログラム。

Images