JP5736588B2 - ソースコード変換方法及びソースコード変換プログラム - Google Patents

Description

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

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

モデル検査技術は、ソフトウェアの振舞いを、特定モデルチェッカの入力言語で記述し、特定モデルチェッカを実行することで、前記ソフトウェアの取り得る状態を網羅的に検査することによって前記ソフトウェアが持つべき性質を満たしているかどうかを判定する技術である（例えば非特許文献１参照）。非特許文献１に開示される方法によると、ソフトウェアの振る舞いを、Ｐｒｏｍｅｌａと呼ばれる入力言語で記述し、SPINと呼ばれるモデルチェッカに入力することで、検査を実施する。検査の結果、検査対象のソフトウェアの状態のうち、当該ソフトウェアが持つべき性質を満たしていない状態がある場合、管理者が当該状態に至る状態の遷移をトレースして、ソフトウェアの不具合箇所が特定される。

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

状態爆発に対応するために、抽象化と呼ばれる処理を、ソースコード又は検査コードに対して行い、状態数を検査可能な範囲まで削減することがある。検査対象のソースコードが検査コードに変換される場合に計算機の内部に保持される情報（モデル）の形式は、例えば、メタモデルによって定義される。メタモデルは、例えば、ＭＯＦ（例えば、非特許文献２参照）、ＱＶＴ（例えば、非特許文献３参照）、及びＯＣＬ（例えば、非特許文献４参照）を用いた記述によって定義されることが知られている。

抽象化は、例えば、選択的実行文の分岐条件の簡略化がある。抽象化によって、本来存在しない実行パスが生じる事態、又は存在する実行パスが消滅する事態が引き起こされる場合があるため、検査コードに対する検査結果によって示されるソフトウェアの性質と本来のソフトウェアの性質とに差異が生まれることがあり得る。そのため、ソフトウェアに対して検査すべき性質に鑑み、抽象化の水準を検討した上で、抽象化を適用することが望ましい。

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

また、検査コード書出しルールを用いて、検査モデルが検査コードに変換される方法が知られている（非特許文献５参照）。

特開２０００−１８１７５０号公報

G. J. Holzmann, "The Model Checker Spin," IEEE Transactions on Software Engineering, vol. 23, no. 5, pp. 279--295, May 1997http://doi.ieeecomputersociety.org/10.1109/32.588521 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文として表現される。ある実施形態においては、汎化モデル１２０６を、検査モデル１００８へ変換する際、汎化−検査変換ルール１００７のみを用いることもあり得る。また、ある実施形態において、汎化−検査変換ルール１００７が、複数の変換ルールを含む場合には、複数の変換ルールを統合して１つの変換ルールとし、汎化モデル１２０６から検査モデル１００８への変換に利用する方法があり得る。また、ある実施形態において、汎化−検査変換ルール１００７が、複数の変換ルールを含む場合には、変換処理を複数回繰り返すことで、汎化モデル１２０６から検査モデル１００８への変換を行う手順があり得る。

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

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

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

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

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

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

まず、本実施例におけるソースコード変換手順の一例を、図４及び図６を参照しながら説明する。本実施例におけるソースコード変換手順は、ソースコード入力ステップＳ１０１と、変換ルール入力ステップＳ１０２と、変換ルール適用ステップＳ１０３と、検査コード出力ステップＳ１０４と、を含む。このソースコード変換手順は、制御部１５００が主体となって実行される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、変換ルールの選択方法としては、次のようなものがある。

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

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

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

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

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

（第２の実施例）
次に、第２の実施例になるソース変換装置及びソースコード変換方法について図９〜図１１を用いて説明する。本実施例では、抽象化された汎化モデルをソースコードに逆変換することによって、検査対象のソースコードの抽象化された箇所を出力するステップを有する。

図９は、第２の実施例になるソースコード変換装置を含むソースコード変換システムの構成例を示す図である。図９のうち、第１の実施例の図３Ａに示すソースコード変換システムと同じ構成は同じ符号を付与し、説明を省略する。

本実施例のソースコード変換装置１０００は、入力部１１００、制御部１５００、出力部１３００、記憶部１４００、及び変換処理部４１００を備える。変換処理部４１００は、検査対象のソースコード０００１を検査コード０００５に変換する点では、第１の実施例の変換処理部１２００と同じであるが、ソースコード０００１を検査コード０００５に変換する一連の処理で抽象化された汎化モデルをソースコードに逆変換したソースコードである抽象化ソースコード４１０１を出力する点で、第１の実施例の変換処理部１２００と異なる。

図１０は、第２の実施例のソースコード変換装置の構成例を示す。図１０のうち、第１の実施例の図３Ｂに示すソースコード変換装置と同じ構成は、同じ符号を付与し、説明を省略する。

入力部１１００は、第１の実施例と同じく、ソースコード入力部１１０１及び変換ルール入力部１１０２を備える。変換処理部４１００は、モデル構築部４２０１、実装−汎化モデル変換部４２０２、抽象化モデル変換部４２０３、汎化−検査モデル変換部４２０４、汎化−実装モデル変換部４２０５、及びコード生成部４２０６を備える。出力部１３００は、検査コード書出し部１３０１、及び抽象化ソースコード出力部４２２０を備える。記憶部１４００は、変換ルールデータベース１４０１、メタモデルデータベース１４０２、及び書出しルールデータベース１４０３の他に、逆変換ルールデータベース４２１０を備える。

以下、変換処理部４１００について詳細に説明する。

モデル構築部４２０１は、ソースコード入力部１１０１からソースコード０００１を受け取り、受け取ったソースコード０００１を実装モデルへ変換する。また、モデル構築部４２０１は、変換箇所をソースコード−実装モデル変換対応表として逆変換ルールデータベース４２１０に登録する。

実装−汎化モデル変換部４２０２は、変換ルールデータベース１４０１から実装−汎化変換ルールを取り出し、メタモデルデータベース４２２１からメタ・実装モデル及びメタ・汎化モデルを取り出す。そして、実装−汎化モデル変換部４２０２は、取り出された実装−汎化ルール、メタ・実装モデル、及びメタ・汎化モデルを用いて、実装モデルを汎化モデルへ変換する。また、実装−汎化モデル変換部４２０２は、変換箇所を実装−汎化モデル変換対応表として逆変換ルールデータベース４２１０に登録する。

抽象化モデル変換部４２０３は、変換ルールデータベース１４０１から抽象化変換ルールを取り出し、メタモデルデータベース１４０２からメタ・汎化モデルを取り出す。そして、抽象化モデル変換部４２０３は、取り出された抽象化変換ルール及びメタ・汎化モデルを用いて、汎化モデルを抽象化する。また、抽象化モデル変換部４２０３は、抽象化された箇所を抽象化変換対応表として逆変換ルールデータベース４２１０に登録する。

汎化−検査モデル変換部４２０４は、変換ルールデータベース１４０１から汎化−検査変換ルールを取り出し、メタモデルデータベース１４０２からメタ・汎化モデル及びメタ・検査モデルを取り出す。そして、汎化−検査モデル変換部４２０４は、取り出された汎化−検査変換ルール、メタ・汎化モデル及びメタ・検査モデルを用いて、汎化モデルを検査モデルへ変換する。

汎化−実装モデル変換部４２０５は、抽象化モデル変換部４２０３が抽象化処理を終了すると、逆変換ルールデータベース４２１０から抽象化変換対応表を取り出す。そして、汎化−実装モデル変換部４２０５は、取り出された抽象化変換対応表を用いて、抽象化された汎化モデルを抽象化される前の汎化モデルに変換する。

次に、汎化−実装モデル変換部４２０５は、逆変換ルールデータベース４２１０から実装−汎化変換対応表を取り出す。そして、汎化−実装モデル変換部４２０５は、取り出された実装−汎化変換対応表示を用いて、抽象化される前の汎化モデルを実装モデルに変換する。

コード生成部４２０８は、汎化−実装モデル変換部４２０５によって抽象化される前の汎化モデルが実装モデルに変換されると、逆変換ルールデータベース４２１０からソースコード−実装変換対応表を取り出す。そして、コード生成部４２０８は、取り出されたソースコード−実装変換対応表を用いて、実装モデルを抽象化ソースコード４１０１に変換し、抽象化ソースコード４１０１を抽象化ソースコード出力部４２２０に出力する。

抽象化ソースコード出力部４２２０は、コード生成部４２０６から入力された抽象化ソースコード４１０１をシステム外部に出力する。例えば、ソースコード出力部４２１０は、抽象化ソースコード４１０１を外部記憶媒体へ保存したり、抽象化ソースコード４１０１を表示装置であるディスプレイに表示したりする。

これによって、利用者が、対象ソースコードと、検査水準（抽象化の度合い）に応じて、変換ルールを選択することで、検査可能な検査コードに変換し、前記検査コードと同じ抽象化の水準の抽象化ソースコードを出力することが可能となり、利用者によって選択された抽象化水準によるモデルの検査結果と抽象化前のソフトウェアとの対応付けの課題が解決される。

次に、本実施例の具体例について図１１を用いて説明する。まず、本具体例で検査対象となるソースコード０００１について説明する。検査対象となるソースコード０００１では、ａ、ｂ、及びｃの値が定義される。具体的には、ａには「０」が代入され、ｂには、ｉが５より大きい場合「０」が代入され、これ以外の場合「１」が代入され、ｃにはｃの値をインクリメントした値が代入される。

このソースコード０００１がモデル構築部４２０１によって図示しない実装モデルに変換され、この実装モデルが実装−汎化モデル変換部４２０２によって汎化モデルに変換される。実装−汎化モデル変換部４２０２は、実装モデルを汎化モデルに変換する場合にソースコード０００１中のｉｆ文を条件分岐に変換する。

そして、抽象化モデル変換部４２０３は、汎化モデルの条件分岐の分岐先を固定化することによって、汎化モデルを抽象化する。具体的には、ｂに代入される値が「０」に固定化されるため、図１１に示すように、汎化モデルの２行目、４行目、及び５行目が削除される。

次に、汎化−検査モデル変換部４２０４は、抽象化モデル変換部４２０３によって抽象化された汎化モデルを検査コード０００５に変換する。なお、図１１に示すように、検査コード０００５では、抽象化によってｂに代入される値は「０」で固定されている。

汎化−検査モデル変換部４２０４によって変換された検査コード０００５がモデル検査ツール２０００によって検査され、検査結果３０００が生成される。

また、抽象化モデル変換部４２０３が汎化モデルを抽象化すると、汎化−実装モデル変換部４２０５は、逆変換ルールデータベース４２１０を用いて、抽象化された汎化モデルを実装モデルに逆変換する。次に、コード生成部４２０６は、逆変換ルールデータベース４２１０を用いて、逆変換された実装モデルを抽象化ソースコード４１０１に変換する。

抽象化ソースコード４１０１は、抽象化モデル変換部４２０３によって抽象化された箇所が利用者に把握可能な形態で出力される。図１１に示す抽象化ソースコード４１０１は、抽象化モデル変換部４２０３によって抽象化された箇所が点線で囲まれた形態で出力される。

なお、抽象化された箇所が利用者に把握可能な形態で出力されるためには、抽象化された汎化モデルを抽象化される前の汎化モデルに変換した箇所を汎化−実装モデル変換部４２０５がコード生成部４２０６に抽象化された箇所として通知し、コード生成部４２０６が当該箇所を抽象化ソースコード４１０１に変換する場合に、当該箇所を利用者に把握可能な形態で出力する必要がある。

以上によって、抽象化された汎化モデルが、抽象化された箇所を抽象化される前の状態に戻した抽象化ソースコード４１０１に変換されるため、利用者は、検査結果と抽象化ソースコード４１０１とを対応付けやすくなる。

さらに、抽象化された箇所を利用者に把握可能にして抽象化ソースコード４１０１が出力されることによって、抽象化された箇所は検査結果に対応しないので、利用者は、検査結果と抽象化ソースコード４１０１とをさらに対応付けやすくなる。

（第３の実施例）
次に、第３の実施例になるソース変換装置及びソースコード変換方法について図１２及び図１３を用いて説明する。本実施例では、検査対象のソースコードの抽象化された箇所と当該抽象化に用いた抽象化変換ルールとを出力するステップを有する。

図１２は、第３の実施例のソースコード変換装置の構成例を示す。図１２のうち、第２の実施例の図１０に示すソースコード変換装置と同じ構成は、同じ符号を付与し、説明を省略する。

第３の実施例のソースコード変換装置に備わる変換処理部４１００は、ルール適用情報付加部４３０１を備える点で、第２の実施例のソースコード変換装置に備わる変換処理部４１００と異なる。また、第３の実施例の抽象化モデル変換部４２０３は、汎化モデルを抽象化した場合に、抽象化した箇所と抽象化に用いた抽象化変換ルールを特定可能な識別子とを抽象化変換対応表として逆変換ルールデータベース４２１０に登録する。

ルール適用情報付加部４３０１は、抽象化モデル変換部４２０３によって汎化モデルが抽象化された場合、逆変換ルールデータベース４２１０から抽象化変換対応表を取り出す。そして、ルール適用情報付加部４３０１は、取り出された抽象化変換対応表に登録された抽象化に用いた抽象化変換ルールの識別子を、汎化モデルの抽象化された箇所に付加して、当該汎化モデルを汎化−実装モデル変換部４２０５に渡す。

汎化−実装モデル変換部４２０５は、抽象化された汎化モデルを実装モデルに変換する場合に、実装モデルのうち、抽象化された箇所に対応する箇所に抽象化に用いた抽象化変換ルールの識別子を付加する。

コード生成部４２０６は、実装モデルの抽象化変換ルールの識別子が付加された箇所を抽象化ソースコード４１０１に変換する場合、当該抽象化変換ルールの識別子を当該箇所のソースコードのコメントとして記述する。

本実施例の具体例について図１３を用いて説明する。

図１３に示す具体例は、図１１に示す第２の実施例の具体例と、抽象化ソースコード４１０１が異なる。

本実施例の抽象化ソースコード４１０１では、抽象化された箇所と同じ行に、コメントとして当該箇所の抽象化に用いた抽象化変換ルールが記述される。図１３に示す抽象化ソースコード４１０１では、抽象化された箇所と当該箇所の抽象化に用いた抽象化変換ルールが記述された部分は点線によって囲まれ、どこが抽象化された箇所なのか利用者に把握可能にしている。すなわち、本実施例の抽象化ソースコード４１０１は、抽象化モデル変換部４２０３によって抽象化された箇所と当該箇所の抽象化に用いた抽象化変換ルールとの関係を利用者に把握可能な形態で出力される。

なお、図１３では、一つの抽象化変換ルールを用いてすべての箇所が抽象化されているが、抽象化された箇所が異なる抽象化変換ルールを用いて抽象化されていてもよいことは言うまでもない。

以上によって、抽象化ソースコード４１０１は、抽象化された箇所と当該箇所の抽象化に用いた抽象化変換ルールとの関係が利用者に把握可能な形態で出力される。このため、利用者が検査結果を検討した結果、抽象化変換ルールを変更する必要がある場合、どの抽象化変換ルールを変更すればよいかが把握しやすくなる。

さらに、第３の実施例の抽象化ソースコード４１０１を含む表示画面において、コメントで記述された抽象化に用いた抽象化変換ルールを抽象化モデル変換部４２０３で適用するか否かの利用者からの選択操作を受け付け可能な領域を設けてもよい。

ソースコード変換装置１０００は、抽象化ソースコード４１０１の表示画面を介して抽象化変換ルールを適用する旨の選択を受け付けた場合、選択を受け付けた抽象化変換ルールを抽象化モデル変換部４２０３で抽象化に用いるように設定する。一方、ソースコード変換装置１０００は、抽象化ソースコード４１０１の表示画面を介して抽象化変換ルールを適用しない旨の選択を受け付けた場合、選択を受け付けた抽象化変換ルールを抽象化モデル変換部４２０３で抽象化に用いないように設定する。

これによって、利用者は、抽象化された箇所と当該箇所の抽象化に用いられた抽象化変換ルールとの関係及び検査結果を把握しながら、抽象化変換ルールを抽象化に用いるか否かの決定を容易にすることができる。

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

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

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

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

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

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

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

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

以上、本発明者によりなされた発明を実施形態に基づき具体的に説明したが、本発明は上述した実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

本願発明は、ソフトウェアのソースコードを検証ツールの入力言語で記述された検査コードに変換するソースコード変換方法に適用可能である。

１１００ 入力部
１１０１ ソースコード入力部
１１０２ 変換ルール入力部
１３００ 出力部
１３０１ 検査コード書出し部
１４００ 記憶部
１４０１ 変換ルールデータベース
１４０２ メタモデルデータベース
１４０３ 書出しルールデータベース
４１００ 変換処理部
４２０１ モデル構築部
４２０２ 実装−汎化モデル変換部
４２０３ 抽象化モデル変換部
４２０４ 汎化−検査モデル変換部
４２０５ 汎化−実装モデル変換部
４２０６ コード生成部
４２１０ 逆変換ルールデータベース
４２２０ 抽象化ソースコード出力部

Claims (6)

1. ソフトウェアのソースコードを、異なる複数の変換ルールを用いて、検証ツールの入力言語で記述された検査コードに変換するソースコード変換装置で実行されるソースコード変換方法であって、
   前記変換ルールは、
   前記ソースコードを特定のプログラミング言語に依存しない形式である中間形式で表現されたソフトウェアへ変換する第１変換ルールと、
   前記変換された中間形式で表現されたソフトウェアを抽象化する第２変換ルールと、
   前記抽象化された中間形式で表現されたソフトウェアを前記検査コードに変換する第３変換ルールと、を含み、
   前記方法は、
   前記ソースコードを入力するステップと、
   少なくとも一つの前記第１変換ルールの入力を受け付けるステップと、
   少なくとも一つの前記第２変換ルールの入力を受け付けるステップと、
   少なくとも一つの前記第３変換ルールの入力を受け付けるステップと、
   前記入力された第１変換ルールを用いて、前記ソースコードを前記中間形式で表現されたソフトウェアへ変換し、前記変換された箇所を第１逆変換ルールに記憶するステップと、
   前記入力された第２変換ルールを用いて、前記変換された中間形式で表現されたソフトウェアを抽象化し、前記抽象化された箇所を第２逆変換ルールに記憶するステップと、
   前記入力された第３変換ルールを用いて、前記抽象化された中間形式で表現されたソフトウェアを前記検査コードへ変換するステップと、
   前記第２逆変換ルールを用いて、前記抽象化された中間形式で表現されたソフトウェアを前記抽象化される前の中間形式で表現されたソフトウェアに変換するステップと、
   前記第１逆変換ルールを用いて、前記抽象化される前の中間形式で表現されたソフトウェアを、前記中間形式で表現されたソフトウェアに変換される前のソースコードに変換するステップと、を含むことを特徴とするソースコード変換方法。
2. 請求項１に記載のソースコード変換方法であって、
   前記変換された中間形式で表現されたソフトウェアを抽象化した場合、前記抽象化された箇所と、当該抽象化に用いられた第２変換ルールと、を前記第２逆変換ルールに記憶し、
   前記方法は、前記第１逆変換ルールを用いて変換されたソースコードを出力するステップを含み、
   前記第１逆変換ルールを用いて変換されたソースコードを出力するステップでは、前記第２逆変換ルールを用いて、前記抽象化された箇所と当該箇所の抽象化に用いられた第２変換ルールとの関係を出力することを特徴とするソースコード変換方法。
3. 請求項２に記載のソースコード変換方法であって、
   前記第１逆変換ルールを用いて変換されたソースコードを出力するステップでは、前記第１逆変換ルールを用いて変換されたソースコードを含み、前記抽象化に用いられた第２変換ルールを適用するか否かの選択操作を受け付け可能な画面を出力し、
   前記方法は、
   前記抽象化に用いられた第２変換ルールを適用するか否かの選択を受け付けるステップと、
   前記抽象化に用いられた第２変換ルールを適用する旨の選択を受け付けた場合、当該第２変換ルールを、前記中間形式で表現されたソフトウェアの抽象化に用いるように設定するステップと、
   前記抽象化に用いられた第２変換ルールを適用しない旨の選択を受け付けた場合、当該第２変換ルールを、前記中間形式で表現されたソフトウェアの抽象化に用いないように設定するステップと、を含むことを特徴とするソースコード変換方法。
4. プロセッサ及び記憶領域を備えるソースコード変換装置に、ソフトウェアのソースコードを、異なる複数の変換ルールを用いて、検証ツールの入力言語で記述された検査コードに変換する処理を実行させるソースコード変換プログラムであって、
   前記変換ルールは、
   前記ソースコードを特定のプログラミング言語に依存しない形式である中間形式で表現されたソフトウェアへ変換する第１変換ルールと、
   前記変換された中間形式で表現されたソフトウェアを抽象化する第２変換ルールと、
   前記抽象化された中間形式で表現されたソフトウェアを前記検査コードに変換する第３変換ルールと、を含み、
   前記処理は、
   前記ソースコードを入力するステップと、
   少なくとも一つの前記第１変換ルールの入力を受け付けるステップと、
   少なくとも一つの前記第２変換ルールの入力を受け付けるステップと、
   少なくとも一つの前記第３変換ルールの入力を受け付けるステップと、
   前記入力された第１変換ルールを用いて、前記ソースコードを前記中間形式で表現されたソフトウェアへ変換し、前記変換された箇所を第１逆変換ルールに記憶するステップと、
   前記入力された第２変換ルールを用いて、前記変換された中間形式で表現されたソフトウェアを抽象化し、前記抽象化された箇所を第２逆変換ルールに記憶するステップと、
   前記入力された第３変換ルールを用いて、前記抽象化された中間形式で表現されたソフトウェアを前記検査コードへ変換するステップと、
   前記第２逆変換ルールを用いて、前記抽象化された中間形式で表現されたソフトウェアを前記抽象化される前の中間形式で表現されたソフトウェアに変換するステップと、
   前記第１逆変換ルールを用いて、前記抽象化される前の中間形式で表現されたソフトウェアを、前記中間形式で表現されたソフトウェアに変換される前のソースコードに変換するステップと、を含むことを特徴とするソースコード変換プログラム。
5. 請求項４に記載のソースコード変換プログラムであって、
   前記変換された中間形式で表現されたソフトウェアを抽象化した場合、前記抽象化された箇所と、当該抽象化に用いられた第２変換ルールと、を前記第２逆変換ルールに記憶し、
   前記処理は、前記第１逆変換ルールを用いて変換されたソースコードを出力するステップを含み、
   前記第１逆変換ルールを用いて変換されたソースコードを出力するステップでは、前記第２逆変換ルールを用いて、前記抽象化された箇所と当該箇所の抽象化に用いられた第２変換ルールとの関係を出力することを特徴とするソースコード変換プログラム。
6. 請求項５に記載のソースコード変換プログラムであって、
   前記第１逆変換ルールを用いて変換されたソースコードを出力するステップでは、前記第１逆変換ルールを用いて変換されたソースコードを含み、前記抽象化に用いられた第２変換ルールを適用するか否かの選択操作を受け付け可能な画面を出力し、
   前記処理は、
   前記抽象化に用いられた第２変換ルールを適用するか否かの選択を受け付けるステップと、
   前記抽象化に用いられた第２変換ルールを適用する旨の選択を受け付けた場合、当該第２変換ルールを、前記中間形式で表現されたソフトウェアの抽象化に用いるように設定するステップと、
   前記抽象化に用いられた第２変換ルールを適用しない旨の選択を受け付けた場合、当該第２変換ルールを、前記中間形式で表現されたソフトウェアの抽象化に用いないように設定するステップと、を含むことを特徴とするソースコード変換プログラム。

Images