WO2015040735A1

WO2015040735A1 - ソフトウェア仕様の形式検証支援装置及びその方法

Info

Publication number: WO2015040735A1
Application number: PCT/JP2013/075461
Authority: WO
Inventors: 佐藤　直人; 伊藤　信治; 宮崎　邦彦
Original assignee: 株式会社日立製作所
Priority date: 2013-09-20
Filing date: 2013-09-20
Publication date: 2015-03-26

Abstract

　ソフトウェア仕様の検証において、リファイメントを適用した自動証明率の高い形式モデルを、自然言語の入力から生成する。　自然言語を含む形式で記述されるソフトウェア仕様を、形式言語記述へ変換することでソフトウェア仕様の検証を支援する装置は、ソフトウェア仕様が満たすべき性質で構成される仕様の証明戦略を編集する戦略編集手段と、仕様の構成要素および性質を、形式言語記述の構成要素となる形式言語部品に変換する言語変換手段と、証明戦略と形式言語部品から形式言語記述の一部の構成要素を含む形式言語記述スケルトンを生成するスケルトン生成手段と、形式言語記述スケルトンに対して形式言語部品を導入することで、形式言語記述を生成する形式言語部品配置手段を有する。

Description

ソフトウェア仕様の形式検証支援装置及びその方法

　本発明は、ソフトウェア開発を支援する技術に関し、特に、ソフトウェア仕様の検証を支援する技術に関する。

　ソフトウェア仕様の正しさに関する形式検証は、ソフトウェアの仕様を、数学的意味を持つ形式言語によって記述し、この形式言語で記述されたソフトウェア仕様（以下、形式モデルと呼ぶ）の正しさを、数学的手法に基づいて証明することで行われる。よって、上記形式検証のためには、ソフトウェア仕様の設計者が形式言語を習得していることが要件となる。このため、形式検証の導入には形式言語習得に要する導入コストがかかるという課題がある。

　この課題に対処するため、特許文献１には、自然言語または図などによって記述したソフトウェア仕様（以下、自然言語モデルと呼ぶ）を、形式モデルに変換して生成する方法が開示されている。この生成方法によれば、ソフトウェアの設計者は、自然言語や図などによって記述した自然言語モデルから、検証のための形式モデルを得ることができるため、形式言語を習得せずとも形式検証を活用できる。よって形式言語習得にかかる導入コストを削減できるという効果がある。

　上記形式検証の手法のうち、Event-BやBメソッドなどの手法では、リファイメントと呼ばれる形式モデルの設計手法が採用されている。リファイメントとは、対象のソフトウェア仕様の一部を抽象的に記述した後、段階的に仕様を追加および詳細化していく設計手法である。このリファイメントを適用することで、自動証明器による形式モデルの証明率（以下、自動証明率と呼ぶ）を向上することができる。自動証明率が高いほど、手作業による証明作業を削減できるため、形式検証にかかる作業工数を削減できるという利点がある。逆に、生成した形式モデルの自動証明率が低い場合、多くの証明を手作業で行う必要がある。手作業での証明には、形式言語に関する専門的知識を要する場合もあるため、証明可能なソフトウェア仕様であるにも拘わらず、その証明を達成できない可能性もある。

特開２０１１－１８０８５０号公報

　上記リファイメントの手続きは、形式言語が持つ数学的意味において、どの程度仕様を抽象化するかという仕様抽象度に関する要素と、抽象した仕様をどのような手順で詳細化していくかという詳細化手順に関する要素を含む。よって、対象のソフトウェア仕様に対して数学的意味が与えられた後、すなわち、対象のソフトウェア仕様に対応する形式モデルを得た後でなければ、リファイメントの手続きは決定できない。つまり、自然言語モデル上でリファイメント手続きを決定することは困難である。このため、自然言語モデルを形式モデルに変換する従来技術では、リファイメントを適用した自動証明率の高い形式モデルを生成できないという問題がある。つまり、形式言語を習得し、形式言語上で形式モデルを設計しなければ、リファイメントを適用した自動証明率の高い形式モデルを得ることが困難である。

　上記のように、形式言語を習得しなくても、リファイメントを適用した自動証明率の高い形式モデルを得られるようにすることで、形式言語習得にかかる導入コストの削減と、形式モデルの証明にかかる作業コストの削減を両立することが課題となる。

　本発明の目的は、リファイメントを適用した自動証明率の高い形式モデルを自然言語の入力から生成可能にすることで、ソフトウェア仕様の検証工数を削減することにある。

　本発明は、好ましくは、自然言語を含む形式で記述されるソフトウェア仕様を、形式言語記述へ変換することで、該ソフトウェア仕様の検証を支援する装置であって、ソフトウェア仕様が満たすべき性質で構成される、ソフトウェア仕様の証明戦略を編集する戦略編集手段と、ソフトウェア仕様の構成要素および該性質を、形式言語記述の構成要素となる形式言語部品に変換する言語変換手段と、該証明戦略と該形式言語部品から形式言語記述の一部の構成要素を含む形式言語記述スケルトンを生成するスケルトン生成手段と、該形式言語記述スケルトンに対して該形式言語部品を導入することで、該形式言語記述を生成する形式言語部品配置手段を有する、ことを特徴とするソフトウェア仕様の形式検証支援装置として構成される。
また本発明は、上記形式検証支援装置におけるソフトウェア仕様の形式検証支援方法としても構成される。

　本発明の好ましい実施形態によれば、ソフトウェア仕様の正しさを形式的に検証するための形式モデルを作成する際において、自然言語にて記述可能な図であるリファイメント戦略図に基づいて、リファイメントを適用した形式モデルを生成する。これにより、形式モデルの自動証明率を左右するリファイメントの戦略を、自然言語上で設計できるようになるため、形式言語を習得しなくても、リファイメントを適用した自動証明率の高い形式モデルを得ることができる。これにより、ソフトウェア仕様の正しさを証明できる可能性が向上し、ソフトウェア仕様の形式検証のための導入コストの削減と、ソフトウェア仕様の形式検証工数を削減することが可能となる。

ソフトウェア仕様の形式検証支援装置の構成を示すブロック図。ソフトウェア仕様の形式検証支援装置のハードウェア構成を示すブロック図。自然言語モデルの例を示すオブジェクト図。自然言語モデルの例を示すフローチャート。自然言語モデルの例を示すフローチャート。自然言語モデルの例を示すフローチャート。システム要件の例を示す図。リファイメント戦略図の例を示す図。形式モデルスケルトンの例を示す図。形式モデルスケルトンの例を示す図。形式モデルスケルトンの例を示す図。形式モデル部品の例を示す図。形式モデル部品の例を示す図。形式モデル部品の例を示す図。ラベル情報の例を示す図。インバリアント生成情報の例を示す図。スケルトン生成部の処理手順を示すフローチャート。形式モデル部品配置部の処理手順を示すフローチャート。形式モデル部品配置部の処理手順を示すフローチャート。形式モデルの例（１）を示す図。形式モデルの例（２）を示す図。形式モデルの例（２）を示す図。形式モデルの例（３）を示す図。形式モデルの例（３）を示す図。

　以下、本発明の好ましい実施形態を、図面を参照しながら詳細に説明する。本実施形態は、自然言語にて記述可能な自然言語モデルおよびリファイメント戦略図から、リファイメントを適用した形式モデルを生成する、ソフトウェア仕様の形式検証支援装置として適用される。

　本実施形態によれば、形式言語の未習熟なソフトウェア仕様設計者でも、適切なリファイメント戦略図を与えることで、リファイメントを適用した自動証明率の高い形式モデルを得ることができるようになる。これにより、形式言語の習得にかかる形式検証の導入コストを削減することができる。また、自動証明率の高い形式モデルを得ることで、形式モデルを手作業で証明した場合にかかる作業コストを削減できるとともに、ソフトウェア仕様の正しさを証明できる可能性が向上する。

　また本実施形態によれば、自動証明に失敗した場合に、その原因箇所を上記リファイメント戦略図上に表示するため、自動証明率の向上のためのリファイメント戦略図の修正効率を向上できる。これにより、リファイメントを適用した自動証明率の高い形式モデルを得るためのリファイメント戦略図の設計工数を削減できる。

　図１は、形式手法Event-Bを対象とした形式検証支援装置の機能構成の例を示すブロック図である。
形式検証支援装置は、自然言語モデル編集部１０１、自然言語モデル保持部１０２、戦略図編集部１０３、戦略図保持部１０４、言語変換部１０５、形式モデル部品保持部１０６、スケルトン生成部１０７、スケルトン保持部１０８、ラベル情報保持部１０９、インバリアント生成情報保持部１１０、形式モデル部品配置部１１１、形式モデル保持部１１２、形式モデル証明部１１３、及び修正箇所表示部１１４を有して構成される。

　自然言語モデル編集部１０１は、自然言語または図などで記述したソフトウェア仕様である自然言語モデルの作成・編集を受け付け、自然言語モデルを自然言語モデル保持部１０２に登録する。自然言語モデルに含まれる要素のうち、ソフトウェアの処理を表す要素には、それらを一意に識別するためのラベルを付与する。

　戦略図編集部１０３は、ソフトウェアが満たすべき複数の要件を木構造で接続したリファイメント戦略図の作成・編集を受け付け、リファイメント戦略図を戦略図保持部１０４に登録する。

　言語変換部１０５は、自然言語モデル保持部１０２から自然言語モデルを、戦略図保持部１０４からリファイメント戦略図をそれぞれ取得して、自然言語のモデル記述を形式言語に変換する。変換によって得られた形式言語の記述は形式モデルの構成要素となるため、形式モデル部品として形式モデル部品保持部１０６に登録する。

　スケルトン生成部１０７は、戦略図保持部１０４からリファイメント戦略図を、形式モデル部品保持部１０６から形式モデル部品をそれぞれ取得して、マシン名（MACHINE）、詳細化元マシン名（REFINES）、参照コンテクスト名（SEES）、変数（VARIABLES）、インバリアント（INVARIANTS）、初期化イベント（INITIALISATION）のアクション、コンテクスト名（CONTEXT）、定数（CONSTANTS）、及び公理（AXIOMS）など、形式モデルの一部の構成要素からなる形式モデルスケルトン（以下単にスケルトンと呼ぶことがある）を生成し、スケルトン保持部１０８に登録する。また、形式モデルスケルトン生成の際に、形式モデルの構成要素であるマシン名と、そのマシンに導入されるべき処理を特定するラベルとの対応関係を作成し、対応関係をラベル情報としてラベル情報保持部１０９に登録する。また同じく、形式モデルスケルトン生成の際に、リファイメント戦略図を構成する要件の識別子と、当該要件から生成したインバリアントの識別子との対応関係を作成し、インバリアント生成情報としてインバリアント生成情報保持部１１０に登録する。

　形式モデル部品配置部１１１は、形式モデル部品保持部１０６から形式モデル部品を、スケルトン生成部１０７から形式モデルスケルトンをそれぞれ取得して、形式モデルスケルトンに形式モデル部品を配置していくことで形式モデルを作成する。その際、ラベル情報保持部１０９から当該形式モデルスケルトンを生成する際に作成したラベル情報を取得し、そのラベル情報に基づいて形式モデル部品の配置を行う。その結果得られた形式モデルは、形式モデル保持部１１２に登録する。
形式モデル証明部１１３は、形式モデル保持部１１２から形式モデルを取得して、自動定理証明器を用いて形式モデルの証明を行う。

　修正箇所表示部１１４は、形式モデル証明部１１３から証明に失敗したインバリアントの識別子を取得した後、インバリアント生成情報保持部１１０を参照して、上記識別子に対応する要件識別子を取得する。そして、取得した要件識別子の示す要件を、戦略図編集部１０３が表示するリファイメント戦略図上に強調表示する。

　図２は、形式検証支援装置のハードウェア構成例を示す。
形式検証支援装置は、ＣＰＵ２０２、メモリ２０３、外部記憶装置２０４、表示装置２０５、入力装置２０６、及び外部媒体入出力装置２０７を有する。

　ＣＰＵ２０２は、メモリ２０３に記憶されたプログラムを実行することによって、各種処理を実行する。メモリ２０３は、ＣＰＵ２０２のワークエリアとして機能し、プログラム及びプログラムの実行に必要なデータを記憶する。具体的には、プログラムとして、上記自然言語モデル編集部１０１、戦略図編集部１０３、言語変換部１０５、スケルトン生成部１０７、形式モデル部品配置部１１１、形式モデル証明部１１３、及び修正箇所表示部１１４の各機能を実現するプログラムがメモリ２０３に用意される。併せて、自然言語モデル保持部１０２、戦略図保持部１０４、形式モデル部品保持部１０６、スケルトン保持部１０８、ラベル情報保持部１０９、インバリアント生成情報保持部１１０、及び形式モデル保持部１１２に保持されるデータがメモリ２０３に記憶される。

　外部記憶装置２０４は例えばハードディスク装置であり、種々のデータを格納する。具体的には、自然言語モデル保持部１０２、戦略図保持部１０４、形式モデル部品保持部１０６、スケルトン保持部１０８、ラベル情報保持部１０９、インバリアント生成情報保持部１１０、及び形式モデル保持部１１２に保持されるデータが格納される。

　なお、自然言語モデル編集部１０１、戦略図編集部１０３、言語変換部１０５、スケルトン生成部１０７、形式モデル部品配置部１１１、形式モデル証明部１１３、及び修正箇所表示部１１４を実現する各プログラム又は少なくともその一部は外部記憶装置２０４又は外部媒体入出力装置２０７に着脱可能な外部媒体に格納されてもよい。その場合、上記各機能を実現するに際して、ＣＰＵ２０２は、外部記憶装置２０４又は外部媒体からプログラムをメモリ２０３に読み出して、そのプログラムを実行する。

　表示装置２０５は例えば液晶ディスプレイであり、プログラムの処理結果などを表示する。入力装置２０６は例えばキーボード及びマウスであり、処理の実行指示及び処理に必要な情報の入力などを利用者から受け付ける。

　外部媒体入出力装置２０７は、外部媒体と、外部記憶装置２０４に格納されているデータの入出力を行う。外部媒体は、外部媒体入出力装置２０７に着脱可能で可搬性のある記憶媒体であり、外部媒体出力装置２０７は、外部媒体に読み書き可能なドライブ装置などである。

　本実施形態では、島と陸の間の車の往来を制御する信号システムを検証対象として使用する。島と陸の間には、一方通行の橋が架かっており、車は陸から島へ又は島から陸へ橋上を往来する。車は全て陸からやってくるものとし、島上で急に車が出現することはない。また、橋の幅は一車線分しかないため、橋上の通行は一方通行である。そのため、島から橋、あるいは陸から橋への進入地点にそれぞれ信号機が設置されており、橋上で車が正面衝突することのないように、車の往来を制御している。本実施形態では、信号機の現示を制御する信号システムを検証対象とする。この信号システムは、島上の車数および橋上の車数とその向きを認識できるため、車数に従って信号機を制御する。また、島上の車の数と、橋上に合わせて存在できる車数には上限値が設定されており、信号システムは上限値を超えないように、信号機を制御する。

　図３は、自然言語モデルの例を示すオブジェクト図である。
自然言語モデルの一部であるオブジェクト図は、オブジェクト３０２、３０３、３０４を定義する。
オブジェクト３０２は「自動車」という名称のオブジェクトを定義する。オブジェクト３０２は、識別子「v1」で表される「陸から島への車数」という名称の変数３０５を持つ。この変数は、自然数の型を持つ変数であることが、それぞれ自然数を意味する「NAT」、および変数を意味する「VAR」から読み取れる。「島から陸への車数」v2、「島上の車数」v3も同様に定義できる。一方、「車数上限値」は、定数を表す「CON」より、自然数型の定数であることが読み取れる。
また、オブジェクト３０３の「信号機」及びオブジェクト３０４の「制御装置」についても同様に識別子「v4」「v5」が定義される。BOOLはブール型を表す。

　図４Ａ，図４Ｂは、自然言語モデルの例を示すフローチャートである。（図４Ａ，図４Ｂは総じて図４ということがある。）
自然言語モデルの一部であるフローチャートは、対象のオブジェクト名称４０２と、判断４０３～４０８、周期開始４０９、周期終了４１０の各ステップを含む。

　オブジェクト名称４０２は、このフローチャートで処理を定義する対象のオブジェクト名称を表す。
判断４０３～４０８は、処理の流れを決定する判断条件を表す。例えば、判断４０３は「島から陸への信号現示」という変数がTRUEかどうかという条件を表しており、この変数がTRUEであれば判断４０４に進み、変数がFALSEであれば周期終了４１０に進む。

　周期開始４０９および周期終了４１０は、このフローチャートの開始点および終了点を表す。ただし、周期終了４１０に到達した場合は、処理を終了せずに、周期開始４０９に戻って同様の処理を周期実行する。

　図４Ｂに示すように、自然言語モデルの一部であるフローチャートは、対象のオブジェクト名称４０２と周期終了４１０に加え、処理ステップ５０２～５０５、ラベル５０６～５０９を含む。処理５０２～５０５は、対象のオブジェクトが実行する処理の内容を表す。複数の処理が記載されている場合は、それらの処理は並行的実行されるものとする。例えば、処理５０２には、「島から陸への車数を１増加」と「島上の車数を１減少」の２つの処理が記載されているが、これらの処理は並行的に実行される。ラベル５０６～５０９（即ちイベントＥＶ１～ＥＶ４）は、それぞれ処理５０２～５０５の識別子である。

　図４Ａでは、オブジェクトの名称や、変数の名称および変数の値を下線付きで示している。オブジェクトの名称、変数の名称、および変数の値は、オブジェクト図（図３）の定義と一致する必要がある。そこで、自然言語モデル編集部１０１は、オブジェクト図の定義に基づいてオブジェクト名称の候補、変数名称の候補、および値の候補などを画面表示し、ユーザからの選択を受け付けることで、図４Ａのフローチャートを作成することもできる。以下に示す、図４Ｂ、図５、図６、図７においても同様である。

　図５は、自然言語モデルの例を示すフローチャートである。これも図４と同様に解釈できる。
フローチャートに含まれる処理６０２は、判断結果がYESの場合に、処理６０３あるいは判断６０４のどちらか一方に進むことができる。処理６０３あるいは判断６０４のどちらに進むかは、実行の度に非決定的に選択される。
この自然言語モデルは、上記したオブジェクト（図３）、図４～図５に示すフローチャートによって構成される。

　図６は、システム要件の例を示す。
システム要件７０１は、自然言語モデルによって定義されるシステムが満たすべき要件を表す。つまり、自然言語モデルがシステム要件７０１を満たすかを判定することが、形式検証の目的である。システム要件７０１はユーザが決めて入力装置２０６より入力され、自然語モデル保持部１０２に保持される。

　図７は、リファイメント戦略図の例を示す。
リファイメント戦略図８０１は、システム要件７０１、サブ要件８０２～８０６を含んで構成される。以下、システム要件７０１とサブ要件８０２～８０６を合わせて、要件と総称する。要件の先頭行に表れる「REQ1」～「REQ6」は、要件の識別子である。

　サブ要件８０２～８０６は、システム要件７０１を木構造に従って分割した結果である。例えば、サブ要件８０２が成立するならば、システム要件７０１は成立する。そして、サブ要件８０３およびサブ要件８０４が成立するならば、サブ要件８０２は成立する。さらに、サブ要件８０５およびサブ要件８０６が成立するならば、サブ要件８０３は成立する。このように、上位の要件を満たすために必要な要件を下位に記述する。

　サブ要件には、サブ要件が成立するための前提となる処理のラベルを付与する。図７では、サブ要件８０４、８０５及び８０６に、上記処理のラベル５０６、５０７、６０６、及び６０７（即ちＥＶＴ１、２、５、６）が付与されている。例えば、サブ要件８０４には、ラベル５０６および６０６（即ちＥＶＴ２、５）が付与されており、上記ラベルに対応する処理５０２および６０３に基づいて、サブ要件８０４が成立することを表している。
リファイメント戦略図８０１はユーザが決めて入力装置２０６より入力され、戦略図保持部１０４に保持される。

　図８Ａ～８Ｃは、形式モデルスケルトンの例を示す。（総じて図８ということがある。）
形式モデルスケルトンは、スケルトンの構成要素９０１、９０６、１００１、および１１０１から構成される。
スケルトンの構成要素９０１は、マシン名９０２、変数９０３および９０４、インバリアント９０５、９１２、９１３、初期化イベントのアクション９１４および９１３を含む。

　スケルトンの構成要素９０１は、マシンと呼ばれる構成要素のスケルトンであり、マシン名９０２は、当該マシンの名称を表している。そこで以降、マシンのスケルトンであるスケルトンの構成要素９０１、９０６、１００１、および１１０１を、マシンスケルトンと呼ぶことにする。変数９０３および９０４は、当該マシンが使用する変数の宣言を表す。インバリアント９０５は、当該マシンにて成立する不変条件であり、「陸から島への車数が０あるいは島から陸への車数は０、という条件が常に成立する」という意味を持つ。またインバリアント９１２および９１３は、変数９０３および９０４の型を定義するインバリアントである。さらに、初期化イベントのアクション９１４および９１５は、変数９０３および９０４に初期値を代入する初期化アクションを表す。

　同様に、マシンスケルトン９０６は、マシン名９０７、詳細化元マシン名９０８、変数９０９および９１０、インバリアント９１１を含む。詳細化元マシン名９０８は、マシン名９０２を指しているため、マシンスケルトン９０６に基づいて作成されるマシンは、マシンスケルトン９０１に基づいて作成されるマシンをリファイメント（詳細化）したマシンである。
図８Ｂ，８Ｃに示す、マシンケルトン１００１、１１０１の構成も同様にして理解できるであろう。

　図９は、形式モデル部品の例を示す。
形式モデル部品１２０１は、自然言語モデルの種別１２０２、自然言語モデルの識別子１２０３、形式モデルの種別１２０４、形式モデルの記述内容１２０５の項目から構成される。
自然言語モデルの種別１２０２および自然言語モデルの識別子１２０３は、形式モデルのもとになった自然言語モデルの要素を表す。例えば、Ｎｏ１の「変数」および「v1」は、識別子v1を持つ変数３０５を指している。

　形式モデルの種別１２０４、および形式モデルの記述内容１２０５は、自然言語モデルの変換によって得た形式モデルの種別と記述内容を表す。例えば、Ｎｏ１の「VARIABLES」、「陸から島への車数」は、「陸から島への車数」という名称の変数の宣言を表す．同様に、「INVARIANTS」、「陸から島への車数 ∈ NAT」は、「変数“陸から島への車数”は自然数型である」という型定義のインバリアントを表す。さらに「INITIALISATION」、「陸から島への車数：＝ 0」は、「変数“陸から島への車数”は、0に初期化する」という、初期化イベントにおける変数の初期化アクションを表す。

　結局、上記例では、識別子v1を持つ変数３０５から、「陸から島への車数」という変数の宣言、「陸から島への車数 ∈ NAT」という型定義のインバリアント、及び「陸から島への車数：＝ 0」という初期化アクションが得られたことになる。

　図１０は、形式モデル部品の例を示す。
形式モデル部品１３０１は、形式モデル部品１２０１(図９)と同様に、自然言語モデルの種別１２０２、自然言語モデルの識別子１２０３、形式モデルの種別１２０４、形式モデルの記述内容１２０５の項目から構成される。

　例えば、Ｎｏ７の自然言語モデルに関する項目値である「要件」および「REQ1」は、識別子REQ1を持つ要件７０１を指している。そして、Ｎｏ７の形式モデルに関する項目値である「INVARIANTS」および「陸から島への車数＝ 0 ∨ 島から陸への車数＝ 0」は、「陸から島への車数＝ 0 ∨ 島から陸への車数＝ 0」という内容のインバリアントを表す。

　図１１は、形式モデル部品の例を示す。
形式モデル部品１４０１は、形式モデル部品１２０１および１３０１と同様に、自然言語モデルの種別１２０２、自然言語モデルの識別子１２０３、形式モデルの種別１２０４、形式モデルの記述内容１２０５の項目から構成される。

　例えば、Ｎｏ１３の自然言語モデルに関する項目値である「イベント」および「EVT1」は、識別子EVT1を持つ処理５０２を指している。そして、Ｎｏ１３の形式モデルに関する項目値である「EVENTS」および「WHERE grd1:島から陸への信号現示＝ TRUE grd2:島上の車数 ≧ 1 THEN act1:島から陸への車数：＝島から陸への車数＋ 1 act2:島上の車数：＝島上の車数－ 1 END」は、形式モデルにおける上記内容のイベント（EVENTS）を表す。

　図１２は、ラベル情報の例を示す。
ラベル情報１５０１は、マシン名１５０２と、ラベル１５０３の項目から構成される。
マシン名１５０２は、スケルトン生成部１０７が生成するマシンスケルトンを特定する。

　ラベル１５０３は、マシン名１５０２が示すマシンスケルトンに導入されるべき処理を特定する。例えば、Ｎｏ１のマシン名「m2」は、マシンスケルトン１００１を指す。さらにＮｏ1のラベル「EVT1、EVT5」は、処理５０２および６０３の内容を、マシンスケルトン１００１に導入する必要があることを意味する。処理５０２および６０３は、言語変換部１０５によって形式モデル部品に変換され、形式モデル部品１４０１の形式モデルの記述内容１２０５の項目に登録される。つまりラベル情報１５０１のＮｏ１は、形式モデル部品１４０１から取得可能な処理５０２および６０３に対応する形式モデルの記述内容を、マシンスケルトン１００１に導入する必要があるという意味である。

　図１３は、インバリアント生成情報の例を示す。
インバリアント生成情報１６０１は、インバリアント識別子１６０２と、要件識別子１６０３の項目から構成される。

　インバリアント識別子１６０２は、マシンに含まれるインバリアントを一意に特定するための識別子で、当該インバリアントが含まれるマシン名と、当該マシン内でインバリアントを特定可能なインバリアント名から構成される。例えば、Ｎｏ１のインバリアント識別子「inv1@m0」は、マシン名「m0」が示すマシンスケルトン９０１に含まれる「inv1」の識別子を持つインバリアント９０５を示す。

　要件識別子１６０３は、インバリアント識別子１６０２が示すインバリアントの生成もとになった要件の識別子を表す。例えば、Ｎｏ１の要件識別子「REQ1」は、要件７０１を指している。

　以上より、インバリアント生成情報１６０１のＮｏ１は、インバリアント識別子「inv1@m0」によって示されるインバリアント９０５が、要件識別子「REQ1」によって示される要件７０１から生成されたことを表している。

　図１４は、スケルトン生成部１０７の処理手順を示すフローチャートである。
この処理は、形式検証支援装置２０１内のＣＰＵ２０２が、メモリ２０３に保持されたプログラムを実行することで実現される。そしてこのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

　ＣＰＵ２０２は、スケルトン生成部１０７を実行することによって、戦略図保持部１０４からリファイメント戦略図を取得し、取得したリファイメント戦略図の最上位の要件であるシステム要件を選択する。その後ステップ１７０５を実行する（ステップ１７０１）。

　スケルトン生成部１０７は、リファイメント戦略図に含まれる要件のうち、未選択の要件があるかを確認する。未選択の要件がある場合はステップ１７０３を実行する。未選択の要件がない場合、つまり全ての要件を選択し、処理した場合は、実行を終了する（ステップ１７０２）。

　スケルトン生成部１０７は、未選択の要件のうち、最上位の要件を選択する（ステップ１７０３）。

　スケルトン生成部１０７は、ステップ１７０３で選択した要件の上位の要件を取得する。上記上位要件の下位要件のうち、未選択の全ての要件を選択する（ステップ１７０４）。例えば、リファイメント戦略図８０１において、要件８０３がステップ１７０３で選択されたとすると、要件８０３の上位要件は要件８０２である。さらに、要件８０２の下位要件は要件８０３および要件８０４である。要件８０３は未選択であり、要件８０４も未選択であるとすると、要件８０３および要件８０４が選択される。

　スケルトン生成部１０７は、マシンを新規作成する。既に１つ以上のマシンを作成済みの場合、最下位のマシンをリファイメント（詳細化）してマシンを新規作成する（ステップ１７０５）。マシン間における上下関係は、次のように定義する。あるマシンとそのマシンをリファイメントすることで得られる詳細化マシンが与えられた場合、当該マシンを上位のマシン、詳細化マシンを下位のマシンと定義する。コンテクストについても同様で、あるコンテクストとそのコンテクストを拡張（EXTENDS）した拡張コンテクストが与えられた場合、当該コンテクストを上位のコンテクスト、拡張コンテクストを下位のコンテクストと定義する。

　スケルトン生成部１０７は、形式モデル部品保持部１０６を参照し、選択した要件に対応する形式モデル部品を取得する。複数の要件を選択している場合、それぞれの形式モデル部品を取得する。形式モデル部品１３０１に示した通り、要件に対応する形式モデル部品はインバリアントである。そこで、形式モデル部品を、ステップ１７０５で新規作成したマシンに導入する。その際、上記要件に付与されているラベルとマシンとの対応関係であるラベル情報を作成し、ラベル情報保持部１０９に登録する。同時に、上記要件とインバリアントとの対応関係であるインバリアント生成情報を作成し、インバリアント生成情報保持部１１０に登録する（ステップ１７０６）。

　例えば、ステップ１７０４で要件８０３と要件８０４が選択され、ステップ１７０５でマシンm2が新規作成された場合を考える。この場合、形式モデル部品１３０１より、インバリアント「陸から島への車数 ≧ 1 ⇒ 島から陸への信号現示＝ FALSE」および「島から陸への信号現示＝ FALSE ⇒ 島から陸への車数＝ 0」を取得する。そして、これらのインバリアントをマシンm2のインバリアント１００５および１００６として導入する。

　スケルトン生成部１０７は、ステップ１７０６で導入したインバリアントに、未宣言の変数が含まれるかを確認する。未宣言の変数が含まれる場合はステップ１７０８を実行する。未宣言の変数が含まれない場合は、ステップ１７０９を実行する（ステップ１７０７）。

　スケルトン生成部１０７は、形式モデル部品保持部１０６を参照し、未宣言の変数に対応する形式モデル部品を取得する。形式モデル部品１２０１に示す通り、変数に対応する形式モデル部品は、変数の宣言、変数の型を定義するインバリアント、及び変数の初期化アクションである。そこで、形式モデル部品をマシンに導入する（ステップ１７０８）。例えば、マシンm2に導入したインバリアント１００６は、「島から陸への信号現示」という未宣言の変数を含む（変数「陸から島への車数」と変数「島から陸への車数」はm0にて宣言しているため、未宣言ではない）。そこで、上記変数に対応する形式モデル部品として、変数の宣言１００４、型定義のインバリアント１００７、及び初期化アクション１００８をマシンm2に導入する。その結果、マシンスケルトン１００１が得られる。

　スケルトン生成部１０７は、ステップ１７０６で導入したインバリアントに、未宣言の定数が含まれるかを確認する。未宣言の定数が含まれる場合はステップ１７１０を実行する。未宣言の変数が含まれない場合は、ステップ１７０２に戻る（ステップ１７０９）。スケルトン生成部１０７はまず、コンテクストを新規作成する。既に１つ以上のコンテクストを作成済みの場合、最下位のコンテクストを拡張（EXTENDS）してコンテクストを新規作成する。次に形式モデル部品保持部１０６を参照し、未宣言の定数に対応する形式モデル部品を取得する。形式モデル部品１２０１に示す通り、定数に対応する形式モデル部品は、定数の宣言、および変数の型を定義する公理である。そこで、形式モデル部品を新規作成したコンテクストに導入する。さらに、上記マシンの参照コンテクスト名（SEES）に、新規作成したコンテクストの名称を指定する。参照コンテクスト名とは、マシンが参照可能なコンテクストの名称である。その後ステップ１７０２に戻る（ステップ１７１０）。
上記の手順にて、図８に示す形式モデルスケルトンが得られる。

　図１５Ａ，１５Ｂは、それぞれ形式モデル部品配置部１１１の処理手順を示すフローチャートである。
この処理は、形式検証支援装置２０１内のＣＰＵ２０２が、メモリ２０３に保持されたプログラムを実行することで実現される。そしてこのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

　ＣＰＵ２０２は、形式モデル部品配置部１１１を実行することによって、スケルトン生成部１０７から形式モデルスケルトンを取得する。そして、取得した形式モデルスケルトンに含まれるマシンスケルトンのうち、未選択のマシンスケルトンがあるかを確認する（ステップ１８０１）。確認の結果、未選択のマシンスケルトンが有ればステップ１８０２を実行し、未選択のマシンスケルトンが無ければステップ１８１０を実行する。

　形式モデル部品配置部１１１は、未選択のマシンスケルトンのうち、最上位のマシンスケルトンを選択する（ステップ１８０２）。例えば、形式モデルスケルトンとして、マシンスケルトン９０１、９０６、１００１、および１１０１を取得したとする。この時、全てのマシンスケルトンが未選択であれば、最上位のマシンスケルトンは、マシン名「m0」を持つマシンスケルトン９０１となる。

　形式モデル部品配置部１１１は、ラベル情報保持部１０９を参照し、ステップ１８０２で選択したマシンスケルトンに関連づけられたラベル情報があるかを確認する（ステップ１８０３）。確認の結果、ラベル情報があればステップ１８０４を実行し、ラベル情報が無ければステップ１８０７を実行する。

　形式モデル部品配置部１１１は、形式モデル部品保持部１０６を参照し、ラベル情報が示す処理に対応する形式モデルのイベントを取得する。そして、取得したイベントをマシンスケルトンに導入する（ステップ１８０４）。当該マシンスケルトンよりも上位のマシンにおいて、当該イベントを抽象化した抽象イベントを導入済みの場合は、抽象イベントの名称を、当該イベントにおける詳細化元イベント名（REFINES）に指定する。また当該イベントでは使用しないパラメータを抽象イベントにおいて使用していた場合は、ウィットネス（WITNESS）にて、パラメータに置き換えられた値を指定する。抽象イベントについては、ステップ１８０７で説明する。

　例えば、ラベル情報１５０１のＮｏ１では、m2の名称を持つマシンスケルトン１００１に対してEVT1およびEVT5が対応付けられている。よって、マシンスケルトン１００１を選択した場合は、EVT1およびEVT5の処理に対応する形式モデル部品を導入する。例として、EVT1の処理に対応する形式モデル部品の導入について述べる。EVT1の処理５０２に対応する形式モデル部品は、形式モデル部品１４０１のＮｏ１３に示したイベント「WHERE grd1:島から陸への信号現示＝ TRUE grd2:島上の車数 ≧ 1 THEN act1:島から陸への車数：＝島から陸への車数＋ 1 act2:島上の車数：＝島上の車数－ 1 END」である。よって、上記イベントを、マシンスケルトン１００１に導入する。ここで、m2の名称を持つマシンスケルトンを選択するまでに、m0およびm1の名称を持つマシンが完成していることに注意する。つまり、m0およびm1のマシンは図１６～図１８に示す通り完成しており、イベントの抽象イベント２１０１が導入されている。よって、イベントは、抽象イベントのリファイメント（詳細化）によって作成する。その結果が、イベント２３０１である。イベント２３０１では、イベント２１０１のパラメータprm1を使用しないため、ウィットネスにて、「prm1 ＝島から陸への車数＋ 1 」を指定している。

　形式モデル部品配置部１１１は、形式モデル部品保持部１０６を参照し、ステップ１８０４で導入したイベントが使用する変数のうち、未宣言の変数に対応する形式モデル部品を取得する。形式モデル部品１２０１に示す通り、変数に対応する形式モデル部品は、変数の宣言、変数の型を定義するインバリアント、及び変数の初期化アクションである。上記形式モデル部品をマシンスケルトンに導入する（ステップ１８０５）。

　形式モデル部品配置部１１１は、形式モデル部品保持部１０６を参照し、ステップ１８０４で導入したイベントが使用する定数のうち、未宣言の定数に対応する形式モデル部品を取得する。形式モデル部品１２０１に示す通り、定数に対応する形式モデル部品は、定数の宣言、および変数の型を定義する公理である。形式モデル部品をマシンスケルトンが参照するコンテクストに導入する。マシンスケルトンが参照するコンテクストが存在しない場合は、最下位のコンテクストを拡張（EXTENDS）してコンテクストを新規作成し、新規作成したコンテクストに形式モデル部品を導入する。そして、マシンスケルトンの参照コンテクスト名（SEES）に、新規作成したコンテクストの名称を指定する（ステップ１８０６）。

　形式モデル部品配置部１１１は、形式モデル部品保持部１０６を参照し、形式モデル部品１４０１から得られる全てのイベントに含まれるアクションのうち、マシンスケルトンに未導入で、かつステップ１８０５で新たに追加した変数に代入を行うアクションを取得する。そして、上記アクションを、「上記変数に対して、上記変数が取り得る値を非決定的に代入するアクション」に抽象化して、上記マシンスケルトンに導入する（ステップ１８０７）。上記抽象化したアクションを含むイベントを抽象イベントと呼ぶ。例えば、マシンスケルトン１００１の場合、ステップ１８０５によって、変数２３０２「島上の車数」が導入される。この変数に代入を行う未導入のアクションとして、アクション１２０６「act2:島上の車数：＝島上の車数＋ 1」がある。そこで、アクション１２０６を、上記の通り抽象化し、抽象化アクション２４０１「島上の車数：＝prm2（ガード２４０２より、prm2は任意の自然数）」を得る。

　形式モデル部品配置部１１１は、マシンスケルトンにおいて、非決定的代入を行う抽象化アクションを持つイベントのガードに、ステップ１７０６にて導入したインバリアントが成立するための最弱条件を追加する（ステップ１８０８）。ここで、最弱条件とはアクションの実行後にインバリアントが成立するために、アクションの実行前に成立すべき条件である。例えば、マシンスケルトン１００１の場合、ステップ１７０６にてインバリアント１００５および１００６が導入される。そして、イベント「陸から島に到着」は、非決定的代入を行う抽象化アクション２４０１および２４０５を持つ。これらのアクション２４０１および２４０５の実行後にインバリアント１００５および１００６が成立するための最弱条件は、ガード２４０３および２４０４である。よって、これらの論理式をガードとして導入する。

　形式モデル部品配置部１１１は、マシンスケルトンにおいて、非決定的代入を行う抽象化アクションを持つイベントのガードから、ステップ１７０６にて導入したインバリアントの上位インバリアントを成立させるために（上位のマシンにて）追加してあった最弱条件を、当該イベントのガードから削除する。本ステップにて、ステップ１８０２で選択したマシンスケルトンへの形式モデル部品の導入は完了し、形式モデルの構成要素となるマシンを得る（ステップ１８０９）。インバリアントの上下関係は、その元になった要件の上下関係と等しい。例えば、マシンスケルトン１００１のイベント「陸から島に到着」の場合、マシンスケルトン１００１の上位マシンであるm1のマシンにおいて、インバリアント９１１を成立させるための最弱条件であるガード２２０１を追加する。インバリアント９１１は、インバリアント１００５および１００６の上位インバリアントである。よって、インバリアント１００５および１００６を導入したマシンスケルトン１００１において、ガード２２０１を削除する。

　形式モデル部品配置部１１１は、形式モデル部品保持部１０６を参照し、全てのイベントが何れかのマシンに導入済みかどうかを確認する（ステップ１８１０）。ここでは、ステップ１８０７において抽象イベントとして導入されたイベントは未導入と判定し、ステップ１８０４によって導入されたイベントのみを導入済みと判定する。全てのイベントが導入済みの場合、実行を終了する。未導入のイベントがある場合、ステップ１８１１を実行する。
形式モデル部品配置部１１１は、最下位のマシンをリファイメント（詳細化）してマシンを新規作成する（ステップ１８１１）。

　形式モデル部品配置部１１１は、未導入のイベントを、新規作成したマシンに導入する。上位のマシンにて抽象イベントを導入済みの場合は、抽象イベントの名称を、当該イベントにおける詳細化元イベント名（REFINES）に指定する。また当該イベントでは使用しないパラメータを抽象イベントにおいて使用していた場合は、ウィットネス（WITNESS）にて、パラメータに置き換えられた値を指定する（ステップ１８１２）。

　形式モデル部品配置部１１１は、ステップ１８０５と同様に、形式モデル部品保持部１０６を参照し、ステップ１８１２で導入したイベントが使用する変数のうち、未宣言の変数に対応する形式モデル部品を取得する。そして上記形式モデル部品を、新規作成した上記マシンに導入する（ステップ１８１３）。

　形式モデル部品配置部１１１は、ステップ１８０６と同様に、形式モデル部品保持部１０６を参照し、ステップ１８０４で導入したイベントが使用する定数のうち、未宣言の定数に対応する形式モデル部品を取得する。そして形式モデル部品を、新規作成したマシンが参照するコンテクストに導入する。マシンが参照するコンテクストが存在しない場合は、最下位のコンテクストを拡張（EXTENDS）してコンテクストを新規作成し、新規作成したコンテクストに形式モデル部品を導入する。そして、マシンの参照コンテクスト名（SEES）に、新規作成したコンテクストの名称を指定する（ステップ１８１４）。

　上記の処理手順にて、図８Ａ～８Ｃに示す形式モデルスケルトンから、図１６～図１８に示す形式モデルが得られる。

　１０１：自然言語モデル編集部
　１０２：自然言語モデル保持部
　１０３：戦略図編集部
　１０４：戦略図保持部
　１０５：言語変換部
　１０６：形式モデル部品保持部
　１０７：スケルトン生成部
　１０８：スケルトン保持部
　１０９：ラベル情報保持部
　１１０：インバリアント生成情報保持部
　１１１：形式モデル部品配置部
　１１２：形式モデル保持部
　１１３：形式モデル証明部
　１１４：修正箇所表示部

Claims

　自然言語を含む形式で記述されるソフトウェア仕様を、形式言語記述へ変換することで、該ソフトウェア仕様の検証を支援する装置であって、
　ソフトウェア仕様が満たすべき性質で構成される、ソフトウェア仕様の証明戦略を編集する戦略編集手段と、
　ソフトウェア仕様の構成要素および該性質を、形式言語記述の構成要素となる形式言語部品に変換する言語変換手段と、
　該証明戦略と該形式言語部品から形式言語記述の一部の構成要素を含む形式言語記述スケルトンを生成するスケルトン生成手段と、
　該形式言語記述スケルトンに対して該形式言語部品を導入することで、該形式言語記述を生成する形式言語部品配置手段を有する、
ことを特徴とするソフトウェア仕様の形式検証支援装置。
　該形式言語記述は、複数の構成要素をまとめた複数のコンポーネントから構成され、
　該コンポーネントは、常に成立すべき条件を表す不変条件を含み、
　該戦略編集手段にて編集可能な証明戦略は、該性質を木構造で接続した形式であり、
　該証明戦略は、木構造の葉の部分に記述した性質が成立する場合、木構造の根の部分に記述した性質が成立するという関係を持ち、
　該言語変換手段は、少なくとも該性質を該不変条件に変換する手段を備え、
　該形式言語記述スケルトンは、少なくとも該不変条件とコンポーネント間の構造定義を含み、
　該スケルトン生成手段は、該証明戦略の木構造に基づいてコンポーネント間の構造を定義し、該不変条件をコンポーネントに導入する
請求項１に記載のソフトウェア仕様の形式検証支援装置。
　前記証明戦略に含まれる性質にはソフトウェア仕様の構成要素を特定する仕様識別子が付与され、
　前記スケルトン生成手段は、不変条件をコンポーネントに導入する際に、該不変条件の変換もとになった性質に付与された仕様識別子と、コンポーネントとの対応関係を記録しておき、
　前記形式言語部品配置手段は、該対応関係を参照して、該仕様識別子が示すソフトウェア仕様の構成要素を特定し、該構成要素を該言語変換手段によって変換することで得られた形式言語部品を、該不変条件が導入されたコンポーネントに導入する
請求項１又は２に記載のソフトウェア仕様の形式検証支援装置。
　前記形式言語部品配置手段は、形式言語部品をコンポーネントに導入したことでコンポーネントに追加された変数に対し、
　該変数に対する代入処理を含む形式言語部品を抽出し、
　該形式言語部品が含む該代入処理を、該変数に対して該変数の取り得る値を非決定的に代入する処理に抽象化し、
　該抽象化した形式言語部品をコンポーネントに代入する、
請求項１乃至３のいずれかの項に記載のソフトウェア仕様の形式検証支援装置。
　前記形式言語部品配置手段は、抽象化した形式言語部品をコンポーネントに代入した後に、コンポーネントに導入した不変条件が、形式言語部品が含む代入処理後にも成立するための最弱の条件を、代入処理のガード条件として導入する請求項４に記載のソフトウェア仕様の形式検証支援装置。
入力装置から入力される、自然言語または図などで記述したソフトウェア仕様である自然言語モデルの編集を行う自然言語モデル編集手段を有し、
更に前記戦略編集手段は、入力装置から入力されるリファイメント戦略図について編集を行い、
前記言語変換手段は、該自然語モデル編集手段で編集された自然言語モデルを形式言語に変換する
請求項１乃至５のいずれかの項に記載のソフトウェア仕様の形式検証支援装置。
　前記形式言語記述の証明における前提と結論から構成される証明責務を受け付けて推論による証明を行う証明手段と、
　前記証明手段による証明に失敗した場合に、前記証明戦略上において、修正が必要な性質を特定できるように表示する修正箇所表示手段をさらに備え、
　前記スケルトン生成手段は、不変条件を前記コンポーネントに導入する際に、不変条件の変換もとになった性質を特定する性質識別子と、不変条件を特定する不変条件識別子との対応関係を記録しておき、
　前記修正箇所表示手段は、前記証明手段による証明に失敗した不変条件の不変条件識別子を取得し、該対応関係を参照して不変条件の変換元になった性質を特定する性質識別子を取得し、該証明戦略上において該性質識別子が示す性質を特定できるように表示する
請求項１乃至６の何れかの項記載のソフトウェア仕様の形式検証支援装置。
　自然言語を含む形式で記述されるソフトウェア仕様を、形式言語記述へ変換することで、該ソフトウェア仕様の検証を支援するソフトウェア仕様の形式検証支援方法であって、
　ソフトウェア仕様が満たすべき性質で構成される、ソフトウェア仕様の証明戦略を編集する戦略編集ステップと、
　ソフトウェア仕様の構成要素および該性質を、形式言語記述の構成要素となる形式言語部品に変換する言語変換ステップと、
　該証明戦略と該形式言語部品から形式言語記述の一部の構成要素を含む形式言語記述スケルトンを生成するスケルトン生成ステップと、
　該形式言語記述スケルトンに対して該形式言語部品を導入することで、該形式言語記述を生成する形式言語部品配置ステップを有する、
ことを特徴とするソフトウェア仕様の形式検証支援方法。