JP5825231B2 - ソフトウェア設計支援装置及びソフトウェア設計支援方法 - Google Patents

Description

形式的手法を利用してソースコードから形式言語で記述されたモデルを構築するソフトウェア設計支援装置に関する。

ソフトウェア開発において、設計段階で混入する不具合の発覚が下流工程まで持ち越されると、修正のための時間的・金銭的コストが肥大化する問題がある。上流工程の設計段階で動作試験や仕様の性質の検証が可能な形式的手法は、この問題へのひとつの対処法として期待されている。

形式的手法とは、数学的に厳密に定義されたソフトウェア開発手法を総称して指す言葉で、形式言語を用いて仕様を記述し、その仕様の性質を検証、または、証明する手法である。ＩＳＯ／ＩＥＣ１３８１７−１で標準化されている言語ＶＤＭ−ＳＬ（Ｖｉｅｎｎａ Ｄｅｖｅｌｏｐｍｅｎｔ Ｍｅｔｈｏｄ−Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｌａｎｇｕａｇｅ）を用いた手法ＶＤＭや、Ｂメソッドと呼ばれる手法などがある。一般的なソフトウェア開発では、自然言語や準形式言語（例えば、図や記号など）で仕様を記述するため、曖昧な表現や解釈の取り違え、記述の抜け落ちが生じやすいが、形式的手法を用いることで仕様を一意に記述できる。また、ツールを用いて仕様の動作を確認することも可能である。

形式的手法を用いて仕様の性質を検証する方法は主に２つあり、モデル検査と定理証明である。モデル検査は、形式言語で記述された仕様（モデル）の実行可能パスをすべて動的に実行し、証明の対象となる性質に反例がないことを確認する手法の総称である。ＳＰＩＮは、モデル検査の代表的な例である。もうひとつの手法である定理証明は、モデルの実行可能パスをすべて網羅的に試すのではなく、数学的推論を使って、証明の対象となる性質が、モデルの上で数学的に成り立っていることを示す手法の総称である。前述のＢメソッドや、Ｃｏｑ、Ｉｓａｂｅｌｌｅなどは定理証明の代表的な例である。

定理証明では、モデルと証明の対象となる性質、また必要であれば証明の道程を特定する定理集合やその適用順序などを入力とするのが一般的である。証明の対象となる性質は、「変数Ａはいかなる関数を実行したとしても必ず０以下の値は取らない」、「変数Ｂの条件を満たす値に対し、変数Ｃの条件を満たす値が必ず１つ以上存在する」などの論理式で表される。定理証明ツールの持つ定理集合及び推論方式を利用して、その論理式が真であるかどうか証明する。定理証明は、実行可能パス空間の大きさに左右されず、モデル検査よりも包括的かつ数学的厳密に検証することができる。

従来、形式言語によるモデルの記述は、自然言語で記述された仕様を基に人手で行われている。人手によるモデルの記述には、仕様の規模にもよるが数週間〜数ヶ月の時間を必要とし、仕様が頻繁に変更される昨今のソフトウェア開発にはそぐわない。また、ソフトウェア開発では、一から仕様を起こして製品を作ることはほとんどなく、多くは前バージョンの製品の仕様を一部改修したり、何世代かの製品に渡って使用してきたソフトウェアモジュールなどを利用したりするのが一般的である。このような場合も、従来では一から人手でモデルを記述する必要があった。また、人手が介在することによりモデルにヒューマンエラーが混入する可能性があった。

そこで、形式的手法を用いてソースコードの検証を行う研究が進められている。ソースコードの検証を行う際に、検証の前提条件が影響するソースコード範囲を検証前に決定し、その範囲だけを検証することによって検証時間を短縮する技術が提示されている。（下記特許文献１参照）

また、ソースコードをブーリアン表現に翻訳し、ＳＡＴベースのモデル検査を適用することで、ソースコードの状態遷移を検証する技術が提示されている。ソースコード中の各基本ブロックを最小構成要素として翻訳し、ブロック間の遷移をモデル検査で検証する手法である。（下記特許文献２参照）

特開２００８−１９１９６３ 特表２００７−５２８０５９

しかしながら、特許文献１ではソースコードの検証を具体的にどのように行うかについては提示されていない。また、特許文献２はブロック間の遷移を検証するものであって、ブロック内の処理を検証することはできない。

本発明は、上記に鑑みてなされたものであって、ソースコードからステートメント単位でモデルを構築して検証するソフトウェア設計支援装置を得ることを目的としている。ステートメントとは、制御や宣言などを行うためにプログラミング言語の言語仕様にあらかじめ組み込まれている命令語を用いて記述された一つの命令文のことである。

本発明のソフトウェア設計支援装置は、抽象化フィルタ作成部により作成された抽象化フィルタによって、関数や変数、定数から成る要素情報を含むソースコードから機能要件に関連する要素情報を含むステートメントを抽出し、ソースコードが記述されたソースコード記述言語から形式言語への書換規則に基づいて、モデル構築部が１以上のステートメントの集合である部分ソースコードから形式言語で記述されたモデルを構築するようにしたものである。

本発明によれば、ソースコードからステートメント単位でモデルを構築し、検証することが可能である。

実施の形態１に係るソフトウェア設計支援装置を示すブロック図。 実施の形態１に係るユーザ関数リスト、大域変数リスト、大域定数リストの例を示す図。 実施の形態１に係る抽象化フィルタ作成部の動作を示すフローチャート。 実施の形態１に係る選択可能機能要件リスト、選択可能ユーザ関数リスト、選択可能大域変数リスト、選択可能大域定数リストの例を示す図。 実施の形態１に係る抽象化フィルタ作成部により作成された抽象化フィルタの例を示す図。 実施の形態１に係る機能要件に対応した抽象化フィルタによりモデルが抽出される過程を示す図。 実施の形態１に係る書換規則テーブルの例を示す図。 実施の形態２に係るソフトウェア設計支援装置を示すブロック図。 実施の形態２に係る機能要件と関連する要素情報とを対応付ける要素情報リストの例を示す図。 実施の形態２に係るコード修正支援部の動作を示すフローチャート。 実施の形態２に係る修正対象候補リストの例を示す図。 実施の形態４に係るソフトウェア設計支援装置を示すブロック図。

実施の形態１．
図１は、実施の形態１に係るソフトウェア設計支援装置１００を示すブロック図である。ソフトウェア設計支援装置１００は、ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）１０１からソースコード１０２が入力されるとソースコード解析部１０３に出力し、ソースコード解析部１０３においてソースコード１０２を解析し、解析した情報を解析情報蓄積部１０４へ蓄積する。抽象化フィルタ作成部１０５は、ＵＩ１０１を介してユーザに問い合わせながら、仕様１０６に記載された機能要件と、解析情報蓄積部１０４に蓄積されたソースコード１０２の解析情報とを関連付けて抽象化フィルタ１０７を作成する。

抽象化フィルタ１０７は、ＵＩ１０１を介して入力されたソースコード１０２をフィルタリングし、モデル構築部１０８へ出力する。モデル構築部１０８は、フィルタリングされたソースコード１０２からモデル１１１を構築する。このとき、モデル構築部１０８は書換規則テーブル１０９に格納されたソースコード記述言語から形式言語への書換規則書換規則を適用する。モデル構築部１０８は、構築されたモデル１１１の内部に矛盾がないか外部の定理証明器１１０で証明した後、モデル１１１を出力する。

ソースコード１０２は、Ｃ言語などのプログラミング言語でプログラムが記述されているものを想定する。ソースコード１０２は、コンパイル済みのオブジェクトファイルなど、プログラムの制御構造が抽出できないものでない限り、記述言語、方式は問わない。
ソースコード１０２をソースコード解析部にて解析した結果を図２に示す。図２は、実施の形態１に係るユーザ関数リスト２００、大域変数リスト２０１、大域定数リスト２０２の例を示す図である。

ソースコード解析部１０３は、ソースコード１０２の制御構造を解析する。制御構造とは、ソースコード１０２内で規定されている関数、その入力変数及び戻値、関数内部で定義される局所変数、局所定数、大域変数、大域定数など、ソースコード１０２の機能を実現するための要素情報及びそれらの間の依存関係を指す。ソースコード解析部１０３は、これらの解析情報を抽出し、解析情報蓄積部１０４に蓄積する。蓄積の形態は特に限定しないが、例えば、図２に示すリストとなる。

ユーザ関数リスト２００は、ソースコード１０２中で定義されるユーザ関数を、その入力変数、戻値、内部で使用する局所変数や局所定数の名称とともに、関数１、関数２、といった一意の識別子で管理する。大域変数リスト２０１は、ソースコード１０２内で定義されている大域変数を、使用されるユーザ関数とともに、大域変数１、大域変数２、といった一意の識別子で管理する。大域定数リスト２０２は、ソースコード１０２内で定義されている大域定数を、使用されるユーザ関数とともに、大域定数１、大域定数２、といった一意の識別子で管理する。

仕様１０６は、ソースコード１０２が満たすべき性質（機能要件）が自然言語や準形式言語で記述されたものである。ユーザは、仕様１０６から機能要件を抽出する。抽出される機能要件は、例えば、「暗号化のための暗号鍵の格納は、アクセス権限のある管理者のみが可能である」といったものである。仕様１０６や機能要件は、以後説明する処理を行うことができるものであれば、記法や記述の仕方は問わない。本実施の形態では、４個の機能要件が抽出されたと仮定して説明する。

次に抽象化フィルタ作成部１０５の動作を説明する。
図３は、実施の形態１に係る抽象化フィルタ作成部１０５の動作を示すフローチャートである。抽象化フィルタ作成部１０５は、解析情報蓄積部１０４に蓄積された解析情報から機能要件に関連する要素情報を抽出し、抽象化フィルタ１０７を作成する。

図４は、実施の形態１に係る選択可能機能要件リスト４００、選択可能ユーザ関数リスト４０１、選択可能大域変数リスト４０２、選択可能大域定数リスト４０３の例を示す図である。選択可能機能要件リスト４００、選択可能ユーザ関数リスト４０１、選択可能大域変数リスト４０２、選択可能大域定数リスト４０３は、図３のフローチャートにおいて各項目が選択可能または選択済を示すリストで、初期値はすべて選択可能に設定しておき、フローチャートの処理に従って選択済に変更する。図３のフローチャートにおいて、選択可能ユーザ関数リスト４０１は、図２に示すユーザ関数リスト２００とあわせて１つのリストとしてもよい。選択可能大域変数リスト４０２、選択可能大域定数リスト４０３についても同様に、大域変数リスト２０１、大域定数リスト２０２と合わせて各々一つのリストとしてもよい。
図５は、実施の形態１に係る抽象化フィルタ作成部１０５により作成された抽象化フィルタ１０７ａ〜ｄの例を示す図である。

抽象化フィルタ作成部１０５は、図３のステップＳ３００より処理を開始する。ステップＳ３０１へ進み、抽象化フィルタ作成部１０５は、ＵＩ１０１を通して選択可能機能要件リスト４００において選択可能な機能要件をユーザに提示する。抽象化フィルタ作成部１０５はユーザに機能要件を１つ選択させると（機能要件ｉとする）、ステップＳ３０２へ進む。ステップＳ３０２において、抽象化フィルタ作成部１０５は、選択可能ユーザ関数リスト４０１を参照し、選択可能なユーザ関数が残されているか調べる。残されていればステップＳ３０３へ進み、残されていなければステップＳ３０６へ進む。ステップＳ３０３において、抽象化フィルタ作成部１０５は、選択可能ユーザ関数リスト４０１からユーザ関数を１つ選択し（ユーザ関数ｊとする）、ステップＳ３０４へ進む。

ステップＳ３０４において、抽象化フィルタ作成部１０５は、ユーザ関数ｊが機能要件ｉと関連するかを、ＵＩ１０１を通してユーザに問い合わせる。ユーザが関連すると回答した場合は、選択可能ユーザ関数リスト４０１のユーザ関数ｊを選択済とし、ステップＳ３０５へ進む。関連しないと回答した場合は、選択可能ユーザ関数リスト４０１のユーザ関数ｊを選択済とし、ステップＳ３０２へ進む。ステップＳ３０５において、抽象化フィルタ作成部１０５は、抽象化フィルタｉにユーザ関数ｊを追加し、ステップＳ３０２に戻る。

ステップＳ３０６において、抽象化フィルタ作成部１０５は、選択可能大域変数リスト４０２に選択可能な大域変数が残されているか調べる。残されていればステップＳ３０７へ進む。残されていなければステップＳ３１０へ進む。ステップＳ３０７において、抽象化フィルタ作成部１０５は、選択可能大域変数リスト４０２から大域変数を１つ選択し（大域変数ｋとする）、ステップＳ３０８へ進む。ステップＳ３０８において、抽象化フィルタ作成部１０５は、大域変数ｋが機能要件ｉと関連するかを、ＵＩ１０１を通してユーザに問い合わせる。

ユーザが関連すると回答した場合は、抽象化フィルタ作成部１０５は、選択可能大域変数リスト４０２の大域変数ｋを選択済とし、ステップＳ３０９へ進む。関連しないと回答した場合は、選択可能大域変数リスト４０２の大域変数ｋを選択済とし、ステップＳ３０６へ進む。ステップＳ３０９において、抽象化フィルタ作成部１０５は、抽象化フィルタｉに大域変数ｋと大域変数ｋを内部で使用するユーザ関数を追加し、ステップＳ３０６へ進む。ただし、そのユーザ関数がすでに抽象化フィルタｉに追加されている場合は再追加しない。

ステップＳ３１０において、抽象化フィルタ作成部１０５は、選択可能大域定数リスト４０３に選択可能な大域定数が残されているか調べる。残されていればステップＳ３１１へ進む。残されていなければ、ステップＳ３１４へ進む。ステップＳ３１１において、抽象化フィルタ作成部１０５は、選択可能大域定数リスト４０３から大域定数を１つ選択し（大域定数ｌとする）、ステップＳ３１２へ進む。ステップＳ３１２において、抽象化フィルタ作成部１０５は、大域定数ｌが機能要件ｉと関連するかを、ＵＩ１０１を通してユーザに問い合わせる。

ユーザが関連すると回答した場合、抽象化フィルタ作成部１０５は、選択可能大域定数リスト４０３の大域定数ｌを選択済とし、ステップＳ３１３へ進む。関連しないと回答した場合、抽象化フィルタ作成部１０５は、選択可能大域定数リスト４０３の大域定数ｌを選択済とし、ステップＳ３１０へ進む。ステップＳ３１３において、抽象化フィルタ作成部１０５は、抽象化フィルタｉに大域定数ｌと大域定数ｌを内部で使用するユーザ関数を追加し、ステップＳ３１０へ進む。ただし、そのユーザ関数がすでに抽象化フィルタｉに追加されている場合は再追加しない。

ステップＳ３１４において、抽象化フィルタ作成部１０５は、選択可能機能要件リスト４００に選択可能な機能要件が残されているか調べる。選択可能な機能要件が残されている場合、抽象化フィルタ作成部１０５は、選択可能ユーザ関数リスト４０１、選択可能大域変数リスト４０２、選択可能大域定数リスト４０３をすべて選択可能に設定し、ステップＳ３０１に戻る。選択可能な機能要件が残されていなければステップＳ３１５へ進み、処理を終了する。このようにして作成された抽象化フィルタ１０７は、例えば図５に示すものとなり、機能要件に関連する関数や大域変数、大域定数から成る。

次に、ソフトウェア設計支援装置１００が抽象化フィルタ１０７を利用してモデル１１１を構築する動作を説明する。
図６は、実施の形態１に係る機能要件に対応した抽象化フィルタ１０７ａ〜ｄによりモデル１１１ａ〜ｄが抽出される過程を示す図である。抽象化フィルタ１０７ａ〜ｄは、抽象化フィルタ作成部１０５によって作成されたものである。
図７は、実施の形態１に係る書換規則テーブル１０９の例を示す図である。図７は、ソースコード記述言語をＣ言語、形式言語をＢ言語としたときの書換規則テーブル１０９に格納された書換規則の例である。変数名や定数名は、形式言語における構文規則などに特に支障がない限りそのまま使用する。

抽象化フィルタ１０７ａ〜ｄは、ソースコード１０２を入力として、各機能要件に関連する関数や大域変数、大域定数が含まれるステートメントを抽出する。１つのフィルタからステートメントが１以上抽出され、１つのフィルタから抽出されたステートメントの集合を部分ソースコード６００ａ〜ｄと呼ぶこととする。

モデル構築部１０８は、書換規則テーブル１０９に格納された書換規則を適用することにより、ソースコード記述言語で記述された部分ソースコード６００ａ〜ｄを形式言語へステートメント単位で書き換え、モデル１１１ａ〜ｄを構築する。構築されたモデル１１１ａ〜ｄは、内部で矛盾を起こしていないことを証明するため、定理証明器１１１にかけられる。定理証明器１１１は、ソフトウェア設計支援装置１００が想定する形式言語に対応した証明ツールで、特定の方式に用途を限定するものではない。ソフトウェア設計支援装置１００は、定理証明器１１１により内部に矛盾がないことが証明されたモデル１１１ａ〜ｄを出力する。

したがって、本実施の形態では、関数や変数、定数から成る要素情報を含むソースコード１０２から機能要件に関連する要素情報を含むステートメントを抽出する抽象化フィルタ１０７ａ〜ｄを作成する抽象化フィルタ作成部１０５と、ソースコード１０２が記述されたソースコード記述言語から形式言語への書換規則に基づいて、１以上のステートメントの集合である部分ソースコード６００ａ〜ｄから形式言語で記述されたモデル１１１ａ〜ｄを構築するモデル構築部１０８と、を備えているので、ソフトウェア設計支援装置１００はソースコード１０２から形式言語で記述されたモデル１１１をステートメント単位で構築し、検証することが可能である。

また、ステートメント単位でモデル１１１を構築することにより、元のソースコード１０２に近い形でモデル１１１を構築できるため、検証できる性質も細かく指定することができる。現状の仕様を元にしたソフトウェア開発においては、構築されたモデル１１１に修正を加えることで、効率的に修正することができる。

さらに、自然言語で記述された仕様から人手でモデル１１１を記述する場合と比較して開発者の負荷を軽減し、短期間でのソフトウェア開発を実現する。また、人手による不具合混入を低減し、モデル構築者の技量によって出ていたモデル１１１の質の差をなくすことができる。

実施の形態２．
以上の実施の形態１では、抽象化フィルタ作成部１０５により作成された抽象化フィルタ１０７によってソースコード１０２から機能要件と関連する部分ソースコード６００ａ〜ｄを抽出し、ソースコード１０２が記述されたソースコード記述言語から形式言語への書換規則を定義した書換規則に基づいて、モデル構築部１０８が部分ソースコード６００ａ〜ｄから形式言語で記述されたモデル１１１を構築するようにしたものであるが、本実施の形態においては、機能要件が変更された場合にソフトウェア設計支援装置８００がソースコード１０２の修正を支援する実施の形態を示す。
なお、実施の形態２におけるコード修正支援部８０１と抽象化フィルタ作成部１０５以外の部分は実施の形態１と同じであるため、説明を割愛する。

図８は、実施の形態２に係るソフトウェア設計支援装置８００を示すブロック図である。コード修正支援部８０１は、ＵＩ１０１を通して機能要件の変更がユーザより通知されると、抽象化フィルタ作成部１０５に当該機能要件に関連する要素情報を問い合わせ、ＵＩ１０１を通してユーザへ提示する。

図９は、実施の形態２に係る機能要件と関連する要素情報とを対応付ける要素情報リスト９００の例を示す図である。抽象化フィルタ作成部１０５は、抽象化フィルタ１０７を作成する際、機能要件と関連する要素情報とを対応付けてあらかじめ要素情報リスト９００を作成しておく。抽象化フィルタ作成部１０５は、要素情報リスト９００を作成する際に、機能要件をより細分化して関連する要素情報と関連付けて記憶させてもよい。機能要件を細分化することにより、変更に関連する要素情報が絞り込まれ、修正対象候補リスト１１００に格納される要素情報も絞り込まれる。よって、ユーザはより効率的にソースコード１０２を修正することができる。

図１０は、実施の形態２に係るコード修正支援部８０１の動作を示すフローチャートである。
図１１は、実施の形態２に係る修正対象候補リスト１１００の例を示す図である。コード修正支援部８０１が修正対象候補リスト１１００を作成する。

次に、コード修正支援部８０１の動作を図１０を用いて説明する。
コード修正支援部８０１は、ユーザよりＵＩ１０１を通して変更のある機能要件（機能要件ｘとする）が入力されると、ステップＳ１０００より処理が始まる。処理はステップＳ１００１へ進み、コード修正支援部８０１は、ユーザから提示された機能要件ｘに関連する要素情報を抽象化フィルタ作成部１０５に問い合わせる。抽象化フィルタ作成部１０５は要素情報リスト９００を参照し、機能要件ｘに関連する要素情報をコード修正支援部８０１へ通知する。処理はステップＳ１００２へ進む。

ステップＳ１００２において、コード修正支援部８０１は、機能要件ｘに関連する要素情報を修正対象候補リスト１１００に追加し、ステップＳ１００３へ進む。コード修正支援部８０１は、修正対象候補リスト１１００に機能要件と当該機能要件に関連する要素情報とを格納する。修正対象候補リスト１１００は、例えば図１１に示すようなリストとなる。処理はステップＳ１００３へ進む。

ステップＳ１００３において、コード修正支援部８０１は、機能要件ｘに関連する要素情報について機能要件ｘ以外の機能要件に関連するか抽象化フィルタ作成部１０５に問い合わせる。機能要件ｘに関連する要素情報が複数存在する場合、コード修正支援部８０１は各要素情報について機能要件ｘ以外の機能要件に関連するか抽象化フィルタ作成部１０５に問い合わせる。抽象化フィルタ作成部１０５は、各要素情報について機能要件ｘ以外に関連する機能要件があればコード修正支援部８０１へ通知する。関連する機能要件（機能要件ｙとする）があれば処理はステップＳ１００４へ進み、関連する機能要件が１つもなければステップＳ１００６へ進む。

ステップＳ１００４において、コード修正支援部８０１は抽象化フィルタ作成部１０５から通知された機能要件ｙについて、変更があるかどうかユーザに問い合わせる。機能要件ｙに変更があればステップＳ１００５へ進み、機能要件ｙに変更がなければステップＳ１００６へ進む。なお、抽象化フィルタ作成部１０５から通知された機能要件が複数ある場合は、各機能要件について変更があるかどうかユーザに問い合わせる。変更のある機能要件があればステップＳ１００５へ進み、変更のある機能要件が１つもなければステップＳ１００６へ進む。

ステップＳ１００５において、コード修正支援部８０１は、変更のある機能要件ｙに関連する要素情報を抽象化フィルタ作成部１０５に問い合わせ、修正対象候補リスト１１００に追加し、ステップＳ１００６へ進む。ステップＳ１００６において、コード修正支援部８０１は、修正対象候補リスト１１００に記載されているすべての要素情報をユーザへ提示する。処理はステップＳ１００７へ進み、終了する。

したがって、本実施の形態では、抽象化フィルタ作成部１０５は抽象化フィルタ１０７を作成する際に機能要件と関連する要素情報とを対応付けた要素情報リスト９００を作成し、機能要件が変更された場合に、要素情報リスト９００に基づいて抽象化フィルタ作成部１０５から通知される変更された機能要件に関連する要素情報を提示するコード修正支援部８０１を備えているので、機能要件に変更があってソースコード１０２を修正する場合に、ユーザは当該機能要件と関連する要素情報を把握して的確にソースコードを修正することができる。

また、コード修正支援部８０１は、機能要件が変更され、関連する要素情報が他の機能要件にも関連し、他の機能要件に変更がある場合、要素情報リスト９００に基づいて抽象化フィルタ作成部１０５から通知される他の機能要件に関連する要素情報を提示するので、ユーザは一部の機能要件の修正が影響を及ぼす他の機能要件を把握することができ、的確にソースコード１０２を修正することができる。

実施の形態３．
以上の実施の形態２では、機能要件が変更された場合にソースコード１０２の修正を支援するものであるが、本実施の形態においては、機能要件の変更に伴うモデル１１１の修正を支援する実施の形態を示す。
なお、実施の形態２におけるコード修正支援部８０１とモデル構築部１０８以外の部分は実施の形態２と同じであるため、説明を割愛する。

モデル構築部１０８は、モデル１１１を作成する際、あらかじめ機能要件と関連するモデル１１１とを対応付けて記憶しておく。コード修正支援部８０１は、ＵＩ１０１を通して機能要件の変更がユーザより通知されると、当該機能要件に関連するモデル１１１をモデル構築部１０８に問い合わせ、ＵＩ１０１を通してユーザへ提示する。

したがって、本実施の形態では、モデル構築部１０８はモデル１１１を構築する際に機能要件とモデルとの対応付けを保持し、機能要件が変更された場合に、対応付けに基づいてモデル構築部１０８から通知される変更された機能要件に関連するモデル１１１を提示するコード修正支援部８０１を備えているので、機能要件に変更があってモデル１１１を修正する場合に、ユーザは当該機能要件と関連するモデル１１１を的確に修正することができる。

実施の形態４．
以上の実施の形態３では、機能要件の変更に伴うモデル１１１の修正を支援するものであるが、本実施の形態においては、複数の書換規則から選択してモデル１１１を構築する実施の形態を示す。
なお、実施の形態４における書換規則テーブル１２０１、書換規則選択部１２０２以外の部分は実施の形態１と同じであるため、説明を割愛する。
さらに、以下は、実施の形態１に対する変更について説明するが、実施の形態２または実施の形態３に対する変更としても構成可能である。

書換規則選択部１１０１の動作を説明する。
図１２は、実施の形態４に係るソフトウェア設計支援装置１２００を示すブロック図である。書換規則テーブル１２０１は複数の書換規則を保持し、書換規則選択部１２０２は書換規則テーブル１２０１からモデル構築に適用する書換規則を選択する。
書換規則テーブル１２０１は、１つのソースコード記述言語に対して複数の形式言語への書換規則を保持する。通常、書換規則選択部１２０２はモデル構築の際に適用する書換規則を１つ決めておく。書換規則をユーザに選択させる場合、書換規則選択部１２０２はＵＩ１０１を通してユーザに選択肢となる書換規則を提示して、選択させる。

また、モデル１１１を定理証明器１１０にかけた際に、タイムアウトやメモリが不足して証明がうまくいかなかった場合、モデル構築部１０８は書換規則選択部１２０２へ通知する。書換規則選択部１２０２は書換規則テーブル１２０１から他の書換規則を選択してモデル構築部１０８に通知し、モデル構築部１０８は通知された書換規則を適用してモデル１１１を構築する。このとき、書換規則選択部１２０１が他の書換規則をユーザに提示して選択させてもよい。形式言語の違いは、ユーザにとってモデル１１１が読みやすく保守しやすいかどうかや定理証明の容易さに影響する。

なお、ソフトウェア設計支援装置１２００は、機能要件の変更に伴うソースコード１０２の修正を支援するコード修正支援部８０１をあわせて保持してもよい。

したがって、１つのソースコード記述言語から複数の形式言語への書換規則を保持する書換規則テーブル１２０１と、書換規則テーブル１２０１から書換規則を選択する書換規則選択部１２０２を備えているので、モデル構築の際に適用する書換規則を変更することにより、ユーザにとって読みやすく保守のしやすさを優先するか、形式言語が複雑になっても定理証明を容易にするかといったユーザの要望に合わせたモデル１１１の構築が可能になる。

また、書換規則選択部１２０２は書換規則テーブル１２０１の書換規則を提示して選択させるようにしているので、ユーザがモデルを記述する形式言語を選択することができる。

１００、８００、１２００ ソフトウェア設計支援装置
１０１ ＵＩ
１０２ ソースコード
１０３ ソースコード解析部
１０４ 解析情報蓄積部
１０５ 抽象化フィルタ作成部
１０６ 仕様
１０７、１０７ａ〜ｄ 抽象化フィルタ
１０８ モデル構築部
１０９、１２０１ 書換規則テーブル
１１０ 定理証明器
１１１、１１１ａ〜ｄ モデル
２００ ユーザ関数リスト
２０１ 大域変数リスト
２０２ 大域定数リスト
４００ 選択可能機能要件リスト
４０１ 選択可能ユーザ関数リスト
４０２ 選択可能大域変数リスト
４０３ 選択可能大域定数リスト
６００ａ〜ｄ 部分ソースコード
８０１ コード修正支援部
９００ 要素情報リスト
１１００ 修正対象候補リスト
１２０２ 書換規則選択部

Claims (7)

1. 関数や変数、定数から成る要素情報を含むソースコードから機能要件に関連する前記要素情報を含むステートメントを抽出する抽象化フィルタを作成する抽象化フィルタ作成部と、
   前記ソースコードが記述されたソースコード記述言語から形式言語への書換規則に基づいて、１以上の前記ステートメントの集合である部分ソースコードから前記形式言語で記述されたモデルを構築するモデル構築部と、
   を備えることを特徴とするソフトウェア設計支援装置。
2. 前記抽象化フィルタ作成部は、前記抽象化フィルタを作成する際に機能要件と関連する前記要素情報とを対応付けた要素情報リストを作成し、
   コード修正支援部は、機能要件が変更された場合に、前記要素情報リストに基づいて前記抽象化フィルタ作成部から通知される変更された機能要件に関連する前記要素情報を提示することを特徴とする請求項１に記載のソフトウェア設計支援装置。
3. 前記コード修正支援部は、機能要件が変更され、関連する前記要素情報が他の機能要件にも関連し、前記他の機能要件に変更がある場合、前記要素情報リストに基づいて前記抽象化フィルタ作成部から通知される前記他の機能要件に関連する前記要素情報を提示する
   ことを特徴とする請求項２に記載のソフトウェア設計支援装置。
4. 前記モデル構築部は、モデルを構築する際に機能要件とモデルとの対応付けを保持し、
   前記コード修正支援部は、機能要件が変更された場合に、前記対応付けに基づいて前記モデル構築部から通知される変更された機能要件に関連するモデルを提示することを特徴とする請求項２または３に記載のソフトウェア設計支援装置。
5. １つのソースコード記述言語から複数の形式言語への書換規則を保持する書換規則テーブルと、
   前記書換規則テーブルから前記書換規則を選択する書換規則選択部
   を備えることを特徴とする請求項１乃至４のいずれか一項に記載のソフトウェア設計支援装置。
6. 前記書換規則選択部は、前記書換規則テーブルの前記書換規則を提示して選択させることを特徴とする請求項５に記載のソフトウェア設計支援装置。
7. 関数や変数、定数から成る要素情報を含むソースコードから機能要件に関連する前記要素情報を含むステートメントを抽出する抽象化フィルタを作成する抽象化フィルタ作成ステップと、
   前記ソースコードが記述されたソースコード記述言語から形式言語への書換規則に基づいて、１以上の前記ステートメントの集合である部分ソースコードから前記形式言語で記述されたモデルを構築するモデル構築ステップと、
   を有するソフトウェア設計支援方法。

Images