JP4759546B2 - 仕様欠陥検証システム、その方法及びプログラム - Google Patents

Description

本発明は、設計段階における製品の仕様を記述した状態遷移モデルを用いて、イベントにより発生する状態遷移により、設計段階におけるシステムの仕様の欠陥の有無を検証する仕様欠陥検証システムに関する。

システムの開発を行う際、設計者はシステムが作成される前の段階において、製品仕様における欠陥、例えばセキュリティ上において、権限の無い人間がアクセス可能となる状態などの「起こるべきではない状態」をできる限り除去するための作業を行っている。
設計者は、仕様書を関係者間において設計書レビューを行ってチェックを行ったり、シミュレーションツールを独自に開発して、可能な限りの仕様上の動作を確認して、上記欠陥を除去する努力を行っている。
また、システムの試験工程においては、製品の内部仕様に基づいた単体試験や総合試験を実施したり、外部仕様に基づいて、単体試験や総合試験を実施することにより、仕様欠陥を検証する処理を行っている（例えば、特許文献１参照）。
特開平０６−１６１７５９号公報

しかしながら、開発対象の製品仕様のパラメータ（状態ノード、状態ノードを変更するイベントなど）の数が非常に多い場合、その全ての動作や動作に基づく状態が爆発的に増加するするため、設計書レビューや特許文献１に記載したシミュレーションツールだけで、網羅的に確認することは不可能である。
上記特許文献１は、システムのあらゆる状態遷移を発生させて表示するシステムであり、設計書レビューを支援するために利用可能であるが、手作業を伴い、組合せが膨大となると作業時間が増加し、システムの利用時間も膨大となってしまう。

また、上述した欠陥の検証については、試験工程においても同様であり、膨大な試験項目に時間を費やすことによるシステム開発コストの増大を、システム開発から除くため、境界値試験や実験計画法などのテスト手法に頼ることも考えられるが、仕様欠陥を完全に除去することはできない。
本発明は、製品設計の段階において、製品仕様を記述した状態遷移モデルを、この製品仕様における全パラメータを用いて動作させ、セキュリティ上の「起こるべきではない」欠陥の状態を、簡易に検証することができる仕様欠陥検証システム及びプログラムを提供することを目的とする。

本発明の仕様欠陥検証システムは、設計対象のシステムの仕様をイベントの発生に伴う状態ノードの変更による状態遷移の複数の組み合わせとして記述した状態遷移モデルとし、前記イベントに基づく状態遷移のシミュレーションにより、該設計対象のシステムの仕様を検証する仕様欠陥検証システムであって、前記状態遷移モデルが記憶されているモデル記憶部と、前記状態遷移モデルの状態ノードの状態において、発生してはいけない状態ノードの組合せを示すリスクファイルが記憶されたリスクファイル部と、該モデル記憶部から前記状態遷移モデルを読み出し、該状態遷移モデルから、イベント、及び該イベントによる状態ノードの遷移前後の状態を示す状態情報を読み出す初期設定部と、前記イベントを順次実行し、所定の条件を満たす場合に前記状態情報に応じて状態ノードの状態を変更し、状態遷移モデルにおける状態遷移を行う展開部と、前記展開部の前記イベントの実行により状態ノードの状態が変更された場合、遷移後の状態ノードの状態及びイベントとを状態遷移モデルから抽出し、遷移後の状態ノードの状態がリスクファイル部に記憶されている発生してはいけない状態ノードの組合せに一致するか否かを検出し、一致した場合に仕様欠陥として出力する検証部とを有することを特徴とする。

本発明の仕様欠陥検証システムは、前記仕様欠陥検証システムがさらにスタック領域記憶部を有し、前記展開部が、前記状態遷移モデルの初期状態の状態ノードの組み合わせと、イベントの実行により状態ノードの状態が変更された場合の遷移後の状態ノードの組み合わせ及びイベントとを前記スタック領域記憶部にプッシュすることを特徴とする。

本発明の仕様欠陥検証システムは、前記状態遷移モデルが前記イベントを実行したときに前記状態ノードの値を変更する条件として、前記状態ノードの値を事前条件として有しており、前記展開部がイベントの実行時における状態ノードの値が前記事前条件に一致する場合、イベントに対応して状態ノードの値を変更して状態遷移を行うことを特徴とする。

本発明の仕様欠陥検証システムは、前記展開部が、前記イベントの実行による状態遷移モデルにおける状態遷移が行われた場合、遷移した状態を示す状態情報を、時系列に記憶する履歴管理記憶部をさらに有することを特徴とする。

本発明の仕様欠陥検証システムは、前記展開部は、遷移後の状態の組み合わせと前記履歴管理記憶部に記憶されている状態ノードの組み合わせとが一致した場合、対応するイベントの状態遷移を行わないことを特徴とする。

本発明の仕様欠陥検証システムは、前記状態遷移モデルが、状態ノードの変化に対応して実行される事後イベントを有していることを特徴とする。

本発明の仕様欠陥検証システムは、前記検証部が状態遷移後の状態ノードの組み合わせと、前記リスクファイル部に記憶されている発生してはいけない状態ノードの組合せとが一致した場合、前記スタック領域記憶部に記憶されている各状態における状態ノードの組み合わせとイベントとを出力することを特徴とする。

本発明の仕様欠陥検証システムは、前記展開部が、ある状態遷移における状態ノードの組み合わせにおいて、全てのイベントが実行され、状態遷移が行われなかった場合、前記スタック領域記憶部の最上部のイベントの組み合わせをポップし、その前の状態で未実行のイベントを実行することを特徴とする。

本発明の仕様欠陥検証方法は、設計対象のシステムの仕様をイベントの発生に伴う状態ノードの変更による状態遷移の複数の組み合わせとして記述した状態遷移モデルとし、前記イベントに基づく状態遷移のシミュレーションにより、該設計対象のシステムの仕様を検証する仕様欠陥検証方法であって、初期設定部が状態遷移モデルが記憶されているモデル記憶部から前記状態遷移モデルを読み出し、該状態遷移モデルから、イベント、及び該イベントによる状態ノードの遷移前後の状態を示す状態情報を読み出す過程と、展開部が前記イベントを順次実行し、所定の条件を満たす場合に前記状態情報に応じて状態ノードの状態を変更し、状態遷移モデルにおける状態遷移を行う過程と、検証部が前記展開部の前記イベントの実行により状態ノードの状態が変更された場合、遷移後の状態ノードの状態及びイベントとを状態遷移モデルから抽出し、前記状態遷移モデルの状態ノードの状態において発生してはいけない状態ノードの組合せを示すリスクファイルが記憶されたリスクファイル部に記憶されている発生してはいけない状態ノードの組合せと、前記遷移後の状態ノードの状態が一致するか否かを検出し、一致した場合に仕様欠陥として出力する過程とを有することを特徴とする。

本発明のプログラムは、上記いずれかに記載の仕様欠陥検証システムとして、コンピュータを機能させるためのプログラムである。

以上説明したように、本発明によれば、設計段階における仕様を表す状態遷移モデルを用い、状態遷移モデルが有するイベントを順次実行していき、実行結果として遷移後の状態の各状態ノード（あるいは内部変数）と、リスクファイル部に予め記憶されている「起こるべきでない」組合せの状態と一致するか否かを検出し、一致している場合に仕様の欠陥として通知する構成であり、状態遷移モデルに含まれる全てのイベントに対して起こる状態遷移の結果を検証することが可能となるため、設計段階において製品仕様の欠陥を早期に検出し、また製品仕様に欠陥がないことが検証できる。

また、本発明によれば、外部から入力されるイベント（あるいは外部イベント）による状態遷移の結果として起動する事後イベント（あるいは内部イベント：状態ノードの変化に対応して実行されるイベント）による状態遷移の結果をも含んで欠陥を検証することができるため、事後イベントによる状態遷移を含めて、設計段階において製品仕様の欠陥を早期に検出し、また製品仕様に欠陥がないことが検証できる。
また、本発明によれば、リスクが起こる組み合わせが抽出された場合、その起こってはいけない組み合わせがどのようなイベントの実行順序にて発生したのかを、スタック領域記憶部に記憶されている処理の状態遷移の変化によりトレースが行え、再現性が可能となる。

本発明は、ソフトウェアを開発する際に製品仕様をモデル化して記述するモデリング言語、例えばＵＭＬ（Unified Modeling Language）等で記述された状態遷移モデルを用い、イベントによる各状態ノードの変更による状態遷移をシミュレーションし、状態遷移後の状態ノードの値が、予め設定した仕様上において「起こってはならない」状態ノードの組合せ、すなわち欠陥である状態ノードの組合せに、実行した各イベントにより遷移したか否かを検出することで、欠陥の有無を検証するものである。

上記状態遷移モデルは、複数の状態遷移ラベルから構成されている。この状態遷移ラベルは、外部からのイベント(外部装置やユーザから入力される)と、イベントにより変更される状態ノードの遷移前後の値との対応関係を示すものである。
また、上記イベントには、外部から直接に起動されずに、上記状態ノードの状態遷移に対応してプログラムにより実行される事後イベントも含まれている。
本実施形態において、状態遷移とは、上記イベント（さらに事後イベントも含む）の実行による状態ノードが変更され、状態ノードの組合せが変化することを意味している。

以下、本発明の一実施形態による欠陥検証システムを図面を参照して説明する。図１は同実施形態による欠陥検証システムの構成例を示すブロック図である。
この図において、欠陥検証システムは、初期設定部１、展開部２、検証部３、出力部４、モデル記憶部５、履歴記憶部６、リスクファイル記憶部７、状態管理記憶部８及びスタック領域記憶部９から構成されている。
モデル記憶部５には、欠陥の検証を行う製品仕様の状態遷移モデルが記憶されている。ここで、状態遷移モデルは図２に示すように、複数の状態遷移ラベルから構成されている。図２には例として、LABEL_AUTH1、LABEL_AUTH2、LABEL_LIFECYCLE、LABEL_ADMINFILE、LABEL_USERFILEが記載されている。この状態遷移モデルは、ＩＣカードの動作状態の例を表すものとしている。

各状態遷移ラベルには、図３の各テーブルに示されるように、状態ノードの値と、イベントと、このイベント実行後にイベントにより変更される状態ノードの値ととともに、イベントを実行する前提となる事前条件及び状態遷移直後に実行される事後イベントが付加されている。各テーブルにおいて「＊」が付加されている状態ノードの値はその状態遷移ラベルのデフォルト値であり、製品が起動された状態において初期設定される値である。

例えば、図３（ｃ）のラベルLABEL_LIFECYCLEにおいて、状態ノードの値として「ISSUE」と「USAGE」とが設定され、イベントとして「CHANGE_LIFECYCLE1」と「CHANGE_LIFECYCLE2」とが設定され、それぞれのイベントに対応してイベント実行後の状態遷移ラベルの状態ノードの値として「USAGE」と「ISSUE」とが設定され、同様にそれぞれのイベントを実行するための条件である事前条件として「LABEL_AUTH1=ON」と「LABEL_AUTH1=ON」とが設定され、状態遷移後、すなわち状態ノードの値が変更されたことにより実行される事後イベントとして、それぞれのイベントに対応して「RESET_KEY1」と「RESET_KEY2」とが設定されている。

ここで、簡単に図３におけるイベントの実行による状態遷移について説明する。各イベントは外部からイベントに対応するイベント名や制御信号などが入力されると起動する。
イベント「CHANGE_LIFECYCLE1」の実行による状態遷移が実行されるためには、事前条件として図３（ａ）の状態遷移ラベル「LABEL_AUTH1」の状態ノードの値が「ON」である場合、イベント「CHANGE_LIFECYCLE1」による状態遷移が実行される。
このイベント「CHANGE_LIFECYCLE1」による状態遷移が実行されると、状態ノードの値が「ISSUE」から「USAGE」に変更され、この状態ノードの値の変更に伴い事後イベント「RESET_KEY1」が実行される。
また、事後イベント「RESET_KEY1」による状態遷移が実行されると、図３（ａ）のラベル「LABEL_AUTH1」の状態ノードが「ON」である場合に「OFF」に変更され、図２（ｅ）のラベル「LABEL_ADMINFILE」の状態ノードが「READ」である場合に「NOT_READ」に変更される。

一方、図３（ｃ）のイベント「CHANGE_LIFECYCLE2」が実行されるためには、事前条件として図３（ａ）の状態遷移ラベル「LABEL_AUTH1」の状態ノードの値が「ON」である必要があり、「LABEL_AUTH1＝ON」である場合、イベント「CHANGE_LIFECYCLE2」が実行される。
このイベント「CHANGE_LIFECYCLE2」が実行されると、状態ノードの値が「USAGE」から「ISSUE」に変更され、この状態ノードの値の変更に伴い事後イベント「RESET_KEY2」が実行される。
また、事後イベント「RESET_KEY2」が実行されると、図３（ｄ）の状態遷移ラベル「LABEL_USERFILE」の状態ノードの値が「READ」である場合に「NOT_READ」に変更される。
上述したように、事前条件が設定されている際には、他の状態遷移ラベルにおける状態ノードの値が設定された事前条件と一致している場合にのみ、イベントに対応する状態ノードの値を変更して状態遷移を実行する。
また、事後イベントが設定されている際には、状態ノードの値が変更され状態遷移が発生した場合、この事後イベントが起動し他の状態遷移ラベルの状態ノードの値を変更し、状態遷移が発生する。

一方、図３（ａ）のイベント「AUTH_SUCCES1」においては、事前条件が設定されていないため、図３の状態遷移ラベル「LABEL_AUTH1」の状態ノードが「OFF」である場合には、「ON」に状態ノードが変更される。
また、事後イベントが設定されていない場合、他の状態遷移ラベルの状態ノードに対しては影響を与えずに、自身の状態ノードの値の変更のみを行うこととなる。

初期設定部１は、ユーザが入力した名称の状態遷移モデルを上記モデル記憶部５から読み出し、各状態遷移ラベルにおける状態ノードのディフォルト値（初期状態）及びイベントＩＤ（後述する初期イベントを示すイベントを特定するための番号）を、それぞれの状態遷移ラベルに対応して、状態管理記憶部（状態管理メモリ）８へ記憶させるとともに、上記初期状態と初期イベントのイベントＩＤをスタック領域記憶部９のスタックにプッシュ（PUSH）して記憶させる。
ここで、上記イベントＩＤとイベント名とは、図４に示すイベントテーブルにより対応付けられている。上記イベントＩＤに対応したイベント名をキーとし、状態遷移モデルを検索することにより、状態ノードの遷移情報、事前条件や事後イベントを参照することができる。
また、後述する処理において、展開部２が実行するイベントの順番は、上記イベントテーブルのイベントＩＤ順となる。このイベントテーブルにおける最初のイベントＩＤ（＝１）が初期イベントを示している。

展開部２は、入力されるイベントが事前条件の有無、また事前条件が有ればこのイベントを実行する状態に対応する状態ノードの値がこの事前条件と一致しているか（満足されているか）否かを検出し、イベントに対応した状態遷移である状態ノードの変更を行い、成功した場合、状態管理記憶部８のイベントに対応する状態ノードの値及びイベント番号を変更し、イベントの実行が成功したことを示すture信号を検証部３に対して通知する。
また、展開部２は、全てのイベントの実行に失敗した場合、イベントの実行が失敗したことを示すfalse信号を検証部３に対して通知する。
ここで、全てのイベントの実行に失敗する場合とは、全てのイベントが以下のいずれかのためイベントが行えない場合をいう。
Ａ．状態遷移の事前条件が満足されていないので、状態ノードの変更が行えない
Ｂ．状態遷移前の状態ノードがイベントが定義している状態遷移前の状態ノードでないため、状態遷移が行えない
Ｃ．状態遷移の変更を行った際、すでに履歴記憶部６に記憶されている状態ノードの組み合わせであったので状態変更が行えない

検証部３は、上記展開部２からture信号が入力されると、変更後の状態ノードの値の組合せ及び及び実行したイベント番号を上記スタックの先頭にプッシュして記憶させ、false信号が入力されると、上記スタック領域記憶部９のスタックの先頭をポップ（POP）し、最後に記憶された変更後の状態ノードの組合せ及び及び実行したイベントのイベント番号を削除する。
また、検証部３は、状態管理記憶部８に記憶されている現在の状態ノードの値の組合せを、時系列に履歴記憶部６に記憶させる。
また、検証部３は、状態管理記憶部８から読み出した現在の状態ノードの値の組合せが、リスクファイル記憶部７に記憶されている状態ノードの値の組合せ（起きるべきではない組合せ）であるか否かの検出を行い、検出された場合、スタック内の全ての情報を、内部のrisklogファイルに記録し、全ての検証処理が終了したことを検出すると、上記risklogファイルを出力部４を介して、結果リストとして出力する。

次に、図５は、図３の状態遷移モデルに対応するリスク状態と判定される状態ノードの組み合わせを、各リスク状態の組み合わせを示すリスクＩＤとの対応を示すリスクテーブルを記憶したリスクファイル記憶部７の一例である。
リスクＩＤ「Ｒ１」及び「Ｒ２」は、認証成功前にファイルが読み込まれてしまう状態ノードの組み合わせである。
すなわち、リスクＩＤ「Ｒ１」は、状態遷移ラベル「LABEL_AUTH1」がOFFであり、認証が成功していないにもかかわらず、状態遷移ラベル「LABEL_ADMINFILE」がREADとなっており、ファイルの読み出しが可能な状態となっている。
また、リスクＩＤ「Ｒ２」は、状態遷移ラベル「LABEL_AUTH2」がOFFであり、認証が成功していないにもかかわらず、状態遷移ラベル「LABEL_USERFILE」がREADとなっており、ファイルの読み出しが可能な状態となっている。
また、リスクＩＤ「Ｒ３」は、利用フェーズにおいて管理者ファイルを読み出す状態ノードの組み合わせである。
すなわち、ＩＣカードが利用フェーズであるから、状態遷移ラベル「LABEL_ADMINFILE」は読み出されてはいけないにもかかわらず、状態遷移ラベル「LABEL_ADMINFILE」はREADとなっておりファイルの読み出しが可能な状態となっている。
また、リスクＩＤ「Ｒ４」は、発行フェーズにおいて利用ファイルを読み出す状態ノードの組み合わせである。
すなわち、ＩＣカードが発行フェーズであるから、状態遷移ラベル「LABEL_USERFILE」が読み出されてはいけないにもかかわらず、状態遷移ラベル「LABEL_USERFILE」はREADとなっておりファイルの読み出しが可能となっている。

次に、図１，図３，図６，図７，図８，及び図９を参照して本実施形態による仕様欠陥検証システムの動作を説明する。図６〜図９は、図１の仕様欠陥検証システムの動作例を示すフローチャートである。また、本発明にて用いられているアルゴリズムは、Pythonの探索アルゴリズムに対応した処理である。各状態遷移ラベルに対応するイベントは、状態遷移モデルが読み込まれた段階にて、図３に示すテーブルのイベントの項目から初期設定部１により抽出される。また、イベントが実行される順番を示すイベント番号は任意にユーザが予め設定しておく。
まず、初期設定部１及び検証部が行う処理として図６のフローチャートを説明する。
初期設定部１は、ユーザが検証対象として入力した名称の状態遷移モデルをモデル記憶部５から読み込み（処理１）、各状態遷移ラベルにおける初期状態における状態ノードの値の組合せ及び初期イベント番号（node＝１）とをスタックＳＴ（状態ノードの値の組合せのスタック領域）及びＮＤ（イベント番号のスタック領域）にプッシュするとともに、状態管理記憶部８へ記憶させる（処理２）。
そして、検証部３は、スタックＳＴが空か否かの検出を行い、空（スタックＳＴになにも記憶されていない状態）でないことを検出した場合、処理を処理４へ進め、空であることを検出した場合、処理を処理１０へ進め、内部に記憶されているrisklogファイルを結果リストとして出力部４を介して出力して検証処理を終了する。

次に、検証部３は、スタックにおけるスタックＳＴ及びスタックＮＤの先頭の値を読み出し、状態管理記憶部８に現在の状態ノードの値の組合せ（以下、現在の状態states）及びノードとして設定し（処理４）、処理を処理５へ進める。
この処理４は、処理４−１及び処理４−２とを有しており、後述する処理８−ａ及び処理８−ｂのいずれを通過してきたか、あるいは処理２を通過してきたかにより、行われる処理が異なる。
処理２及び処理８−ｂを通過してきた場合、検証部３は、状態管理記憶部８に現在の状態statusとイベント番号（node＝１）とを記憶させて設定する（処理４−１）。
一方、処理８−ａを通過してきた場合、検証部３は、ポップしたスタックＳＴ及びＮＤの先頭の状態ノードの値の組合せ及びイベント番号｛node｝に１を加算した数値それぞれを、現在の状態statesとイベント番号｛node｝として状態管理記憶部８に設定する（処理４−２）。

そして、検証部３は、状態管理記憶部８に記憶されている現在の状態ノードの値の組合せの状態を、時系列に履歴記憶部６へ記憶させ（処理５）、処理を処理６へ進める。
次に、検証部３は、状態管理記憶部８に記憶されている現在の状態ノードの値の組合せの状態と、リスクファイル記憶部７に記憶されている状態ノードの複数の組合せ（リスク集合）のいずれかと一致するか否かの検出を行い（処理６）、一致する状態ノードの組合せがリスクファイル記憶部７に記憶されたリスク集合から検出された場合、処理を処理９へ進め、一方、検出されない場合に処理を処理７へ進める。
一致したことが検出されると処理９において、検証部３は、「起こるべきでない状態」に到達したため、スタック内の情報を全て内部のriskファイルに追加書き込みする。

そして、展開部２は、関数Ａを呼び出し、状態管理記憶部８に記憶されている状態ノードの組合せの状態にて、上記イベントテーブルにおけるイベントＩＤの順番にイベントを実行し、状態遷移の実行（状態ノードの変更）が行われた場合、その時点においてtrue信号（成功）を検証部３に通知し（処理７、この処理７の詳細は後述）、イベントテーブルにおけるすべてのイベントを実行しても状態遷移の実行が行われなかった場合、false信号（失敗）にて、検証部３に対して通知し（同様に処理７）、処理を処理８へ進める。

次に、検証部３は、false信号が入力されると、スタックの先頭に記憶されている状態ノードの状態とイベント番号とをポップし（処理８−ａ）、処理を処理３へ進める。
一方、検証部は、true信号が入力されると、後述する次の状態newstatesに記載されている状態ノードの値の状態と、後述する関数Ａにおける作業量メモリのtmpnodeに記憶されているイベント番号をスタックにプッシュして記憶させる（処理８−ｂ）。

次に、展開部２における関数Ａの処理について、図７（ａ）のフローチャートにより説明する。
展開部２は、状態管理記憶部８に記憶されている現在の状態statesとイベント番号｛node｝とを読み出し、作業用メモリに格納（tmpnode＝node、tmpstates＝states）し（処理Ａ１）、処理を処理Ａ２へ進める。
そして、展開部２は、tmpnodeに対応するイベントtmpeventを、状態遷移モデルから取得し（処理Ａ２）、作業用メモリにおけるnewstatesを初期化し、処理を処理Ａ３へ進める。
これにより、展開部２は、関数Ｂの処理においてイベントtmpeventを実行し（処理Ａ４、この処理Ａ４の詳細は後述）、イベントtmpeventの実行が成功であればtrue信号を出力し、処理を図６の処理８−ｂへ進め、イベントtmpeventの実行が失敗であればfalse信号を出力し、処理を処理Ａ５へ進める。

イベントtmpeventの実行が失敗すると、展開部２はtmpnodeをインクリメント（１を加算）して、次のイベントの処理を行う準備を行い（処理Ａ５）、処理を処理Ａ６へ進める。
次に、展開部２は、インクリメントされたtmpnodeが状態遷移モデルにおけるイベント数以下であるか否かの検出を行い（処理Ａ６）、イベント数よりtmpnodeが少ないことを検出した場合、処理を処理Ａ３へ進め、一方イベント数をtmpnodeが超えたことを検出した場合、処理を処理Ａ８へ進める。
そして、展開部２は、false信号を検証部３へ出力し（処理Ａ８）、処理を処理８−ａへ進める。
この図７（ａ）のフローチャートの処理において、図７（ｂ）に示すように、ある状態ノードの組合せの状態において、予め実行される順番（イベント番号）がイベントテーブル設定されているイベントを、関数Ｂにより順次実行していく処理を、展開部２が関数Ａの処理により制御している。

次に、展開部２における関数Ｂの処理について、図８（ａ）のフローチャートにより説明する。
展開部２は、イベントtmpeventが実行されることによって状態ノードが変更される状態遷移ラベルの全てとその状態遷移に含まれる遷移前の状態ノードと遷移後の状態ノードの値を状態遷移モデルから検出し、状態遷移tmpmoveとして一時的に記憶しておく（処理Ｂ１）。例えば、イベントAUTH_SUCCESS1のtmpmoveには、状態遷移ラベル「LABEL_AUTH1」をOFFからONに遷移させることが記憶されている。
そして、展開部２は、関数Ｃにより、イベントtmpeventを実行することにより、上記一覧テーブルを参照して、状態遷移tmpmoveに対応した状態ノードの値の変更を行い、変更された値をnewstatesへ上書きする（処理Ｂ２、この処理Ｂ２の詳細は後述）。

次に、展開部２は処理Ｂ２の関数Ｃの処理において、イベントtmpeventの処理が成功した場合、true信号を出力し、処理を処理Ｂ３へ進める。
これにより、展開部２は、一覧テーブルを参照して、状態遷移tmpmoveが全て実行されたか否かを検出し（処理Ｂ３）、全て実行されたことを検出すると処理を処理Ｂ４へ進め、一方全て実行されていないことを検出すると、処理を処理Ｂ２へ進め、実行されていない状態遷移tmpmoveの実行を行う。
そして、展開部２は、処理Ｂ３にて状態遷移tmpmoveが全て実行されたことを検出すると、true信号を出力し（処理Ｂ４）、処理を図７（ａ）の処理Ａ７へ進める。

一方、展開部２は処理Ｂ２の関数Ｃの処理において、イベントtmpeventの処理が失敗した場合、false信号を出力し処理を処理Ｂ５へ進める。
そして、展開部２は関数Ｃの処理においてfalse信号が出力されると、このfalse信号を出力し（処理Ｂ５）、処理を図７（ａ）における処理Ａ５へ進める。
ここで、展開部２は、図８（ｂ）に示すように、上記関数Ｂの処理において、状態遷移tmpmoveを１つずつ処理し、イベントtmpeventにおいて実行される各状態ノードの状態遷移tmpmoveが全て終了、すなわち変更される状態ノードが全て変更されて、状態遷移が全て成功した場合、関数Ｂの処理結果の出力としてtrue信号を出力する。

次に、展開部２における関数Ｃの処理について、図９（ａ）のフローチャートにより説明する。
展開部２は、状態遷移モデルから実行するイベントtmpeventにおいて、実行するイベントに対応して、このイベントによる状態ノードの変換を実行する条件として設定されている事前条件tmpconstraintを抽出し、抽出された事前条件tmpconstraintが記載された事前条件テーブルを一覧として生成し（処理Ｃ１）、１つでも事前条件tmpconstraintが存在する場合、処理を処理Ｃ２へ進め、１つも事前条件tmpconstraintが検出されない場合、処理を処理Ｃ３へ進める。

次に、展開部２は、事前条件が検出された状態ノードにおいて、現在の状態ノードの値の状態tmpstatesが事前条件に設定されている状態ノードの値の組合せと同一であるか否かの検出を行い（処理Ｃ２）、１つでも満足しない事前条件tmpconstraintが検出された場合、処理を処理Ｃ１１へ進め、一方、事前条件tmpconstraintを全て満足することが検出された場合、処理を処理Ｃ３へ進める。
展開部２は、１つでも満足しない事前条件tmpconstraintの状態ノードが検出された場合、false信号を出力し（処理Ｃ１１）、処理を図８（ａ）の処理Ｂ５へ進める。

一方、展開部２は、事前条件tmpconstraintを全て満足することが検出された場合、あるいは処理Ｃ１にて１つも事前条件tmpconstraintが検出されなかった場合、状態遷移tmpmoveの状態遷移前の状態を状態遷移モデルから抽出し、遷移前状態prestatesに設定し、状態遷移後の状態を同様に状態遷移モデルから抽出し、遷移後状態poststatesに設定し（処理Ｃ３）、処理を処理Ｃ４へ進める。
次に、展開部２は、現在のtmpstatesが遷移前状態prestatesを有しているか否かの検出を行い（処理Ｃ４）、現在のtmpstatesが遷移前状態prestatesを有していることが検出された場合、処理を処理Ｃ５へ進め、一方、現在のtmpstatesが遷移前状態prestatesを有していないことが検出された場合、処理を処理Ｃ１１へ進める。

そして、展開部２は、現在のtmpstatesが遷移前状態prestatesを有していることが検出された場合、poststatesに記載された状態ノードの値がtmpstatesに上書きされた状態を、次の状態newstatesとして記録して設定し（処理Ｃ５）、処理を処理Ｃ６へ進める。
次に、展開部２は、次の状態newstatesにおける状態ノードの値の組合せが、履歴記憶部６に記憶されている状態ノードの値の組合せの中に存在するか否かを検出し（処理Ｃ６）、一致する値の組合せが検出された場合、すでに検出された状態のため処理を処理Ｃ１１へ進め、一方、一致する値の組合せが検出されない場合、未検証の状態として処理を処理Ｃ７へ進める。

そして、展開部２は、状態遷移tmpmoveの後の状態ノードの値の変更により起動される事後イベントを、この状態遷移される状態ノードにより状態遷移モデルから抽出し、各状態ノードに対応して、事後イベントposteventの一覧である事後イベントテーブルを生成し（処理Ｃ７）、１つでも事後イベントposteventが存在する場合、処理を処理Ｃ８へ進め、１つも事後イベントが存在しない場合、処理をＣ１０へ進める。
次に、展開部２は、関数Ｂの処理により、すでに説明した図８のフローチャートの処理により、イベントの実行と同様に、事後イベントの実行を行い（処理Ｃ８）、実行結果として事後イベントposteventの実行に失敗した場合、false信号を出力して処理を処理Ｃ１１へ進め、事後イベントposteventの実行に成功した場合、true信号を出力して処理を処理Ｃ９へ進める。

展開部２は、処理Ｃ８において事後イベントposteventの実行に成功した場合、事後イベントテーブルにある全ての事後イベントposteventの処理が終了したか否かを検出し（処理Ｃ９）、全ての事後イベントが終了していることを検出した場合、処理を処理Ｃ１０へ進め、一方、全ての事後イベントが終了していないことを検出した場合、処理を処理Ｃ８へ進める。
そして、展開部２は、全ての事後イベントが終了していないことを検出した場合、あるいは処理Ｃ７において１つも事後イベントposteventが存在していない場合、true信号を出力し（処理Ｃ１０）、処理を図８（ａ）の処理Ｂ３へ進める。
これにより、図９（ｂ）に示すように、展開部２は、関数Ｃにおいてイベントを実行する際、各状態ノードの状態遷移を行う際に事前条件の有無を検出し、事前条件があれば事前条件が満足されるか否かを検出し、条件が満足されてイベントが実行され、状態遷移がなされた後、この状態ノードの変更により事後イベントの実行をイベントと同様の処理により行うこととなる。

次に、図１の仕様欠陥検証システムが図６〜図９のフローチャートにより、実際に仕様の欠陥の検証を行う処理を、図１０〜図１８を用い動作の一例を説明する。図１０は存在する状態及び選択されるノードを説明する概念図であり、図１１、図１２、図１３、図１４、図１５、図１６、図１７、図１８は動作フローを時系列（上部から順に）に記載したフロー図を示すものである。
上記図１１〜図１８においては、奇数番号の図にて、各欄が左からメインルーチン（図６の各処理に対応）、関数Ａ（図７の各処理に対応）、関数Ｂ（図８の各処理に対応）、関数Ｃ（図９の各処理に対応）、事後イベントの関数Ｂ（図８の各処理に対応）、事後イベントの関数Ｃ（図９の各処理に対応）、処理、処理内容及び処理結果、スタック領域記憶部９のスタック（上部が先頭となる）内の状態ノード及びイベント番号となっている。
例として用いる状態遷移モデルは、図３に示す各状態遷移ラベルから構成されるものとする。また、リスクファイル記憶部７には、図５に示すように、「起こるべきではない状態」を示すリスク状態がリスクＩＤに対応して、リスク集合として記憶されている。また、実行されるイベントは、図４に示すように、イベントＩＤに対応して記憶されている。また、図１９及び図２０には、各処理の深さにおいて成功するイベントに対応し、状態遷移後の状態ノードの組み合わせと実行されたイベント番号とが、スタック記憶領域記憶部９にプッシュされていく過程が記載されている。

＜図１０における深さ１の処理（図１１参照）＞
深さ＝１における処理において、初期設定部１は、初期設定１として、状態遷移モデルの各状態遷移モデルを、モデル記憶部５から読み出す（処理１）。
そして、初期設定部１は、初期設定２として、スタックに対して各状態遷移ラベルの状態ノードの組み合わせ｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝の初期状態｛OFF，OFF，ISSUE，NOT，NOT｝をスタック領域ＳＴへ、またイベント番号｛node｝の最初のイベント番号｛１｝をスタック領域ＮＤへプッシュする（処理２）。
次に、検証部３は、スタックの各領域が空であるか否かを検出し（処理３）、最初にこの処理が行われるため、スタックの先頭に初期状態の状態ノードの組み合わせが記録されていることを検出すると、この状態ノードとイベント番号とを現在の状態として、状態管理記憶部８へ記憶する（処理４−１）。
そして、検証部３は、処理４にて状態管理記憶部８へ記憶した現在の状態｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝を、履歴記憶部６historyに記憶する（処理５）。

ここで、検証部３は、現在の状態における状態ノードの値の組み合わせが、リスクファイル記憶部７のリスク集合に含まれている状態ノードの値の組み合わせのいずれかと一致するか否かの検出を行う（処理６）が、いずれにも対応しないため、関数Ａを読み出して処理７へ処理を進める。
処理が処理７に移行すると、展開部２は、上記関数Ａの処理により、現在の状態ノードの値の組み合わせstatesと、イベント番号｛node｝とを、内部の作業用メモリtmpstates及びtmpnodeに対してそれぞれ記憶させる（処理Ａ１）。
そして、展開部２は、tmpnode（＝１）のイベント番号｛node｝に対応するイベントであるtmpevent（AUTH_SUCCESS1）を取得し（処理Ａ２）、newstatesを初期化し（処理Ａ３）、関数Ｂを読み出して処理を処理Ａ４へ進める。

次に、展開部２は、イベントtmpevent（AUTH_SUCCESS1）に関連する状態ノード全ての状態遷移tmpmoveの一覧を遷移状態モデルから抽出して取得し（処理Ｂ１）、関数Ｃを読み出し処理を処理Ｂ２へ進める。この処理Ｂ１において、イベントtmpevent（AUTH_SUCCESS1）に対応する状態遷移tmpmoveは、LABEL_AUTH1の状態ノードをOFFからONへ移行することが示されている。また、イベントtmpevent（AUTH_SUCCESS1）には事前条件及び事後イベントが設定されていない。

処理が処理Ｂ２に遷移すると、展開部２は、状態遷移tmpmoveに記載された状態ノードの値の遷移が行われるための事前条件tmpconstrainの事前条件テーブルを取得し（処理Ｃ１）、事前条件が設定されている状態ノードの有無を検出する（処理Ｃ２）が、事前条件が検出されないため、処理を処理Ｃ３へ進める。
そして、展開部２は、状態遷移tmpmoveにおける状態遷移前の状態ノードの値を取得してprestate（＝OFF）に設定し、状態遷移後の状態ノードの値を取得してpoststate（＝ON）に設定する（処理Ｃ３）。
展開部２は、現在の状態ノードの値（OFF）が、prestate（＝OFF）と一致しているか否かを検出し（処理Ｃ４）、一致しているため処理を処理Ｃ５へ進める。

次に、展開部２は、poststateの示す状態遷移ラベルの状態ノードを、tmpstatesに上書きした状態ノードの値をnewstates｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝＝｛ON，OFF，ISSUE，NOT，NOT｝として設定する（処理Ｃ５）。
そして、展開部２は、次の状態newstatesが履歴記憶部６のhistoryに記憶されている状態ノードの組み合わせでないかどうかの検出を行い（処理Ｃ６）、この状態ノードの組み合わせが履歴記憶部６のhistoryに記憶されていないため、処理を処理７へ進める。
展開部２は、状態遷移tmpmove後に起動する事後イベントを状態遷移モデルから抽出し、事後イベントテーブルを生成する（処理Ｃ７）、事後イベントが存在しないため、処理を処理Ｃ１０へ進める。
そして、展開部２は、関数Ｃの処理結果として、true信号を出力し（処理Ｃ１０）、処理を処理Ｂ３へ進める。

展開部２は、イベントtmpevent（AUTH_SUCCESS1）に対応する全ての状態遷移tmpmoveを実行したか否かを検出し（処理Ｂ３）、全てが終了したことを検出したため、関数Ｂの処理によりtrue信号を出力し処理を処理Ａ７へ進めるにおける（処理Ｂ４）。
そして、検証部３は、関数Ｂのtrue信号が入力されると、関数Ａの処理としてtrue信号を出力し（処理Ａ７）、該関数Ａからtrue信号が出力されたため、newstatesの状態ノードの値とtmpnodeのイベント番号（＝１）とをスタックＳＴ及びＮＤへそれぞれプッシュして記憶させる（処理８−ｂ）。このとき、スタック領域記憶部９には、図１９（ａ）に示す深さ１のように、初期状態のノード状態の組み合わせと、イベント「AUTH_SUCCESS1」の実行により状態遷移が実行された結果の状態ノードの組み合わせとが記憶されている。

＜図１０における深さ２の処理（図１２及び図１３参照）＞
次に、検証部３は、スタックが空か否かを検出し（処理３）、空でないことを検出し、処理８−ｂを通過しているため、深さ＝１から深さ＝２へ処理の対象が移行することとなるので、スタックＳＴから読み出した状態ノードの値の組み合わせと、スタックＮＤから読み出したイベント番号（＝１）とを、状態管理記憶部８へ記憶させる（処理４−１）。
そして、検証部３は、処理４−１にて状態管理記憶部８へ記憶した現在の状態｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝を、履歴記憶部６historyに記憶する（処理５）。

ここで、検証部３は、深さ＝１の場合と同様に、現在の状態における状態ノードの値の組み合わせが、リスクファイル記憶部７のリスク集合に含まれている状態ノードの値の組み合わせのいずれかと一致するか否かの検出を行う（処理６）が、いずれにも対応しないため、関数Ａを読み出して処理７へ処理を進める。
処理が処理７に移行すると、展開部２は、上記関数Ａの処理により、現在の状態ノードの値の組み合わせstatesと、イベント番号｛node｝とを、内部の作業用メモリtmpstates及びtmpnodeに対してそれぞれ記憶させる（処理Ａ１）。
そして、展開部２は、tmpnode（＝１）のイベント番号｛node｝に対応するイベントであるtmpevent（AUTH_SUCCESS1）を取得し（処理Ａ２）、newstatesを初期化し（処理Ａ３）、関数Ｂを読み出して処理を処理Ａ４へ進める。

次に、展開部２は、イベントtmpevent（AUTH_SUCCESS1）に関連する状態ノード全ての状態遷移tmpmoveの一覧を遷移状態モデルから抽出して取得し（処理Ｂ１）、関数Ｃを読み出し処理を処理Ｂ２へ進める。この処理Ｂ１において、イベントtmpevent（AUTH_SUCCESS1）に対応する状態遷移tmpmoveは、状態遷移ラベル「LABEL_AUTH1」の状態ノードをOFFからONへ移行することが示されている。また、イベントtmpevent（AUTH_SUCCESS1）には事前条件及び事後イベントが設定されていない。

処理が処理Ｂ２に移行すると、展開部２は、状態遷移tmpmoveに記載された状態ノードの値の遷移が行われるための事前条件tmpconstrainの事前条件テーブルを取得し（処理Ｃ１）、事前条件が設定されている状態ノードの有無を検出する（処理Ｃ２）が、事前条件が検出されないため、処理を処理Ｃ３へ進める。
そして、展開部２は、状態遷移tmpmoveにおける状態遷移前の状態ノードの値を取得してprestate（＝OFF）に設定し、状態遷移後の状態ノードの値を取得してpoststate（＝ON）に設定する（処理Ｃ３）。
展開部２は、現在の状態ノードの値（OFF）が、prestate（＝OFF）と一致しているか否かを検出し（処理Ｃ４）、一致していないためfalse信号を出力し（処理Ｃ１１）、処理を処理Ｂ５へ進める。

そして、展開部２は、false信号を出力し（処理Ｂ５）、処理を処理Ａ５へ進める。
次に、展開部２は、tmpnodeのイベント番号をインクリメントし（処理Ａ５）、処理を処理Ａ６へ進める。
そして、展開部２は、このインクリメントしたtmpnodeのイベント番号｛node｝が予め設定しているノード数を超えたか否かの検出を行い（処理Ａ６）、イベント番号が「２」でありノード数「６」を超えていないことを検出したため、処理を処理Ａ２へ進める。
これにより、展開部２は、展開部２は、tmpnode（＝２）のイベント番号に対応するイベントであるtmpevent（AUTH_SUCCESS2）を取得し（処理Ａ２）、newstatesを初期化し（処理Ａ３）、関数Ｂを読み出して処理を処理Ａ４へ進める。

次に、展開部２は、イベントtmpevent（AUTH_SUCCESS2）に関連する状態ノード全ての状態遷移tmpmoveの一覧を遷移状態モデルから抽出して取得し（処理Ｂ１）、関数Ｃを読み出し処理を処理Ｂ２へ進める。この処理Ｂ１において、イベントtmpevent（AUTH_SUCCESS2）に対応する状態遷移tmpmoveは、状態遷移ラベル「LABEL_AUTH2」の状態ノードをOFFからONへ移行することが示されている。また、イベントtmpevent（AUTH_SUCCESS2）には事後イベントが設定されていないが、事前条件としてLABEL_LIFECYCLE＝USAGEであることが設定されている。

処理が処理Ｂ２に遷移すると、展開部２は、状態遷移tmpmoveに記載された状態ノードの値の遷移が行われるための事前条件tmpconstrainの事前条件テーブルを取得し（処理Ｃ１）、事前条件が設定されている状態ノードの有無を検出し、かつ事前条件が満足されているか否かを検出する（処理Ｃ２）が、事前条件LABEL_LIFECYCLE＝USAGEが検出され、現在、LABEL_LIFECYCLE＝ISSUEであるため、事前条件を満足していないことを検出したため、false信号を出力して処理を処理Ｃ１１へ進める。
これにより、展開部２は、false信号を出力し（処理Ｃ１１）、処理を処理Ｂ５へ進める。

そして、展開部２は、false信号を出力し（処理Ｂ５）、処理を処理Ａ５へ進める。
次に、展開部２は、tmpnodeのイベント番号｛node｝をインクリメントし（処理Ａ５）、処理を処理Ａ６へ進める。
そして、展開部２は、このインクリメントしたtmpnodeのイベント番号｛node｝が予め設定しているノード数を超えたか否かの検出を行い（処理Ａ６）、イベント番号が「３」でありノード数「６」を超えていないことを検出したため、処理を処理Ａ２へ進める。
これにより、展開部２は、展開部２は、tmpnode（＝３）のイベント番号｛node｝に対応するイベントであるtmpevent（READ_ADMINFILE）を取得し（処理Ａ２）、newstatesを初期化し（処理Ａ３）、関数Ｂを読み出して処理を処理Ａ４へ進める。

次に、展開部２は、イベントtmpevent（READ_ADMINFILE）に関連する状態ノード全ての状態遷移tmpmoveの一覧を遷移状態モデルから抽出して取得し（処理Ｂ１）、関数Ｃを読み出し処理を処理Ｂ２へ進める。この処理Ｂ１において、イベントtmpevent（READ_ADMINFILE）に対応する状態遷移tmpmoveは、状態遷移ラベル「LABEL_ADMINFILE」の状態ノードをNOTからREADへ移行することが示されている。また、イベントtmpevent（READ_ADMINFILE）には事後イベントが設定されていないが、事前条件としてLABEL_AUTH1＝ON、LABEL_LIFECYCLE＝ISSUEであることが設定されている。

処理が処理Ｂ２に遷移すると、展開部２は、状態遷移tmpmoveに記載された状態ノードの値の遷移が行われるための事前条件tmpconstrainの事前条件テーブルを取得し（処理Ｃ１）、事前条件が設定されている状態ノードの有無を検出し、かつ事前条件が満足されているか否かを検出する（処理Ｃ２）が、事前条件LABEL_AUTH1＝ON、LABEL_LIFECYCLE＝ISSUEが検出され、現在、LABEL_AUTH1＝ONかつLABEL_LIFECYCLE＝ISSUEであるため、事前条件を満足していることを検出したため、処理を処理Ｃ３へ進める。
そして、展開部２は、状態遷移tmpmoveにおける状態遷移前の状態ノードの値を取得してprestate（＝NOT）に設定し、状態遷移後の状態ノードの値を取得してpoststate（＝READ）に設定する（処理Ｃ３）。
展開部２は、現在の状態ノードの値（NOT）が、prestate（＝NOT）と一致しているか否かを検出し（処理Ｃ４）、一致しているため処理を処理Ｃ５へ進める。

次に、展開部２は、poststateの示す状態遷移ラベルの状態ノードを、tmpstatesに上書きした状態ノードの値をnewstates｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝＝｛ON，OFF，ISSUE，READ，NOT｝として設定する（処理Ｃ５）。
そして、展開部２は、次の状態newstatesが履歴記憶部６のhistoryに記憶されている状態ノードの組み合わせに存在するか否かの検出を行い（処理Ｃ６）、この状態ノードの組み合わせが履歴記憶部６のhistoryに記憶されていないため、処理を処理Ｃ７へ進める。
展開部２は、状態遷移tmpmove後に起動する事後イベントを状態遷移モデルから抽出し、事後イベントテーブルを生成する（処理Ｃ７）、事後イベントが存在しないため、処理を処理Ｃ１０へ進める。
そして、展開部２は、関数Ｃの処理結果として、true信号を出力し（処理Ｃ１０）、処理を処理Ｂ３へ進める。

展開部２は、イベントtmpevent（AUTH_SUCCESS1）に対応する全ての状態遷移tmpmoveを実行したか否かを検出し（処理Ｂ３）、全てが終了したことを検出したため、関数Ｂの処理によりtrue信号を出力し処理を処理Ａ７へ進めるにおける（処理Ｂ４）。
そして、検証部３は、関数Ｂのtrue信号が入力されると、関数Ａの処理としてtrue信号を出力し（処理Ａ７）、該関数Ａからtrue信号が出力されたため、newstatesの状態ノードの値とtmpnodeのイベント番号（＝１）とをスタックＳＴ及びＮＤへそれぞれプッシュして記憶させる（処理８−ｂ）。
このときのスタック領域記憶部９には、図１９（ｂ）に示す深さ２のように、初期状態の状態ノードの組み合わせと、深さ１にてイベントAUTH_SUCCESS1の実行により遷移が実行された結果である状態ノードの組み合わせと、今回の深さ２でイベントREAD_LIFECYCLEの実行により遷移が実行された結果である状態ノードの組み合わせが記憶されている。
以降、上述したように、深さ＝３〜深さ＝１１の検証処理が行われる。

＜図１０の深さ３における事後イベントの処理（図１４及び図１５を参照）＞
上述したように、深さ３においても同様の検証処理が行われる。深さ３においては、tmpnodeのイベント番号｛node｝が「５」の場合、イベント「tmpivent（＝CHANGE_LIFECYCLE１）」により状態遷移が実行され、状態遷移ラベル「LABEL_LIFECYCLE」の状態ノードがISSUEからUSAGEに遷移した際に、事後イベントRESET_KEY1が起動される。
以下、処理Ａ２にて、イベントtmpivent（＝CHANGE_LIFECYCLE1）が選択された時点から説明する。
そして、展開部２は、tmpnode（＝５）のイベント番号｛node｝に対応するイベントであるtmpevent（CHANGE_LIFECYCLE1）を取得し（処理Ａ２）、newstatesを初期化し（処理Ａ３）、関数Ｂを読み出して処理を処理Ａ４へ進める。

次に、展開部２は、イベントtmpevent（CHANGE_LIFECYCLE1）に関連する状態ノード全ての状態遷移tmpmoveの一覧を遷移状態モデルから抽出して取得し（処理Ｂ１）、関数Ｃを読み出し処理を処理Ｂ２へ進める。この処理Ｂ１において、イベントtmpevent（CHANGE_LIFECYCLE1）に対応する状態遷移tmpmoveは、状態遷移ラベルLABEL_LIFECYCLE」の状態ノードをISSUEからUSAGEへ移行することが示されている。また、イベントtmpevent（CHANGE_LIFECYCLE1）には事後イベントRESET_KEY1が設定され、事前条件としてLABEL_AUTH1＝ONであることが設定されている。

処理が処理Ｂ２に遷移すると、展開部２は、状態遷移tmpmoveに記載された状態ノードの値の遷移が行われるための事前条件tmpconstrainの事前条件テーブルを取得し（処理Ｃ１）、事前条件が設定されている状態ノードの有無を検出し、かつ事前条件が満足されているか否かを検出する（処理Ｃ２）が、事前条件LABEL_AUTH1＝ONが検出され、現在、LABEL_AUTH1＝ONであるため、事前条件を満足していることを検出したため、処理を処理Ｃ３へ進める。
そして、展開部２は、状態遷移tmpmoveにおける状態遷移前の状態ノードの値を取得してprestate（＝ISSUE）に設定し、状態遷移後の状態ノードの値を取得してpoststate（＝USAGE）に設定する（処理Ｃ３）。
展開部２は、現在の状態ノードの値（ISSUE）が、prestate（＝ISSUE）と一致しているか否かを検出し（処理Ｃ４）、一致しているため処理を処理Ｃ５へ進める。

次に、展開部２は、poststateの示す状態遷移ラベルの状態ノードを、tmpstatesに上書きした状態ノードの値をnewstates｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝＝｛ON，OFF，USAGE，READ，NOT｝として設定する（処理Ｃ５）。
そして、展開部２は、次の状態newstatesが履歴記憶部６のhistoryに記憶されている状態ノードの組み合わせと一致するか否かの検出を行い（処理Ｃ６）、一致するものが検出されず、この状態ノードの組み合わせが履歴記憶部６のhistoryに記憶されていないため、処理を処理７へ進める。
展開部２は、状態遷移tmpmove後に起動する事後イベントを状態遷移モデルから抽出し、事後イベントテーブルを生成する（処理Ｃ７）、事後イベントRESET_KEY1が存在するため、処理を処理Ｃ８へ進める。

これにより、展開部２は、関数Ｂを読み出し、イベントtmpevent（RESET_KEY1）に関連する状態ノード全ての状態遷移tmpmoveの一覧を遷移状態モデルから抽出して取得し（処理Ｂ１）、関数Ｃを読み出し処理を処理Ｂ２へ進める。この処理Ｂ１において、イベントtmpevent（RESET_KEY1）に対応する状態遷移tmpmoveは、状態遷移ラベル「LABEL_AUTH1」の状態ノードをONからOFFに移行する状態遷移と、状態遷移ラベル「LABEL＿ADMINFILE」の状態ノードをREADからNOT_READに移行する状態遷移とが示されている。

処理が処理Ｂ２に移行し、展開部２は、状態遷移tmpmoveの一覧から状態遷移ラベル「LABEL_AUTH1」の状態ノードをONからOFFに移行する状態遷移を実行する。状態ノードの値の状態遷移が行われるための事前条件tmpconstrainの事前条件テーブルを取得し（処理Ｃ１）、事前条件が設定されている状態ノードの有無を検出し、かつ事前条件が満足されているか否かを検出する（処理Ｃ２）が、事前条件が設定されてないことが検出されたため、処理を処理Ｃ３へ進める。
そして、展開部２は、状態遷移tmpmoveにおける状態遷移前の状態ノードの値を取得してprestate（＝ON）に設定し、状態遷移後の状態ノードの値を取得してpoststate（＝OFF）に設定する（処理Ｃ３）。
展開部２は、現在の状態ノードの値（ON）が、prestate（＝ON）と一致しているか否かを検出し（処理Ｃ４）、一致しているため処理を処理Ｃ５へ進める。

次に、展開部２は、poststateの示す状態遷移ラベルの状態ノードを、tmpstatesに上書きした状態ノードの値をnewstates｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝＝｛OFF，OFF，USAGE，READ，NOT｝として設定する（処理Ｃ５）。
そして、展開部２は、次の状態newstatesが履歴記憶部６のhistoryに記憶されている状態ノードの組み合わせと一致するか否かの検出を行い（処理Ｃ６）、一致するものが検出されず、この状態ノードの組み合わせが履歴記憶部６のhistoryに記憶されていないため、処理を処理Ｃ７へ進める。

展開部２は、状態遷移tmpmove後に起動する事後イベントを状態遷移モデルから抽出し、事後イベントテーブルを生成する（処理Ｃ７）、事後イベントが存在しないため、処理を処理Ｃ１０へ進める。
そして、展開部２は、関数Ｃの処理結果として、true信号を出力し（処理Ｃ１０）、処理を処理Ｂ３へ進める。
次に、展開部２は、イベントtmpevent（reset_key1）に対応するtmpmoveが全て実行されたか否かを検出し（処理Ｂ３）、まだ状態遷移ラベル「LABEL_ADMINFILE」の状態ノードをREADからNOT_READに移行する状態遷移が実行されていないため、処理Ｂ２に移る。

そして、展開部２は、状態遷移ラベル「LABEL_ADMINFILE」の状態ノードをREADからNOT_READに移行させる状態遷移を関数Ｃにより実行する。処理内容は、すでに説明したものと同様であるため、詳細な説明を省略する。展開部２は、この処理の関数Ｃが出力する処理結果としてのnewstatesの状態ノード値を、newstates｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝＝｛OFF，OFF，ISSUE，READ，NOT｝として設定し、true信号を出力し、処理をＢ３へ進める。

ここで、展開部２は、全てのtmpmoveが実行されたため、関数Ｂの処理によりtrue信号を出力し、処理を処理Ａ７へ進める。
そして、検証部３は、関数Ｂからtrue信号が入力されると、関数Ａの処理としてtrue信号を出力し、newstatesの状態ノードの組み合わせとイベントＩＤ（＝５）とをスタック領域記憶部９にプッシュして記憶させる（処理８−ｂ）。
すなわち、上述した検証部３によるプッシュ処理により、スタック領域記憶部９は、今回の深さ３におけるイベント「CHANGE_LIFECYCLE1」と、その事後イベント「RESET_KEY1」の実行により遷移が実行された結果である状態ノードの組み合わせ｛OFF，OFF，USAGE，NOT，NOT，5｝がプッシュされ、図１９（ｃ）に示す状態となる。

上述したように、本実施形態によれば、状態ノードの変更により起動される事後イベントを含めた、状態遷移の検証を行うことができる。
以降、上述した処理と同様に、各深さにて処理が継続されるため、詳細な説明は省略し、深さ４から深さ９までの検証部３による関数Ａの実行状況を簡単に説明する。
図１０（ｄ）に示す深さ４においては、tmpnodeのイベントＩＤが「１」の場合、イベントtmpevent（＝AUTH_SUCCESS1）により、状態遷移が実行され、状態遷移ラベル「LABEL_AUTH1」の状態ノードがOFFからONに遷移する。このとき、スタック領域記憶部９には、図１９（ｄ）に示す深さ４のように、｛ON，OFF，USAGE，NOT，NOT，１｝がプッシュされて記憶される。

図１０（ｅ）に示す深さ５においては、tmpnodeのイベントＩＤが「２」の場合、イベントtmpevent（＝AUTH_SUCCESS2）により、状態遷移が実行され、状態遷移ラベル「LABEL_AUTH2」の状態ノードがOFFからONに遷移する。このとき、スタック領域記憶部９には、図１９（ｅ）に示す深さ５のように、｛ON，ON，ISSUE，NOT，NOT，2｝がプッシュされて記憶される。
図１０（ｆ）に示す深さ６においては、tmpnodeのイベントＩＤが「４」の場合、イベントtmpevent（＝READ_USERFILE）により、状態遷移が実行され、状態遷移ラベル「LABEL_USERFILE」の状態ノードがNOT＿READからREADに遷移する。このとき、スタック領域記憶部９には、図１９（ｆ）に示す深さ６のように、｛ON，ON，USAGE，NOT，READ，4｝がプッシュされて記憶される。

図１０（ｇ）に示す深さ７においては、tmpnodeのイベントＩＤが「６」の場合、イベントtmpevent（＝CHANGE_LIFECYCLE2）による状態遷移と、その事後イベントRESET_KEY2による状遷移とが実行され、状態遷移ラベル「LABEL_LIFECYCLE」の状態ノードがUSAGEからISSUEに遷移し、また状態遷移ラベル「LABEL_USERFILE」の状態ノードがREADからNOT_READに遷移する。このとき、スタック領域記憶部９には、図１９（ｇ）に示す深さ７のように、｛ON，ON，ISSUE，NOT，NOT，6｝がプッシュされて記憶される。
図１０（ｈ）に示す深さ８においては、tmpnodeのイベントＩＤが「３」の場合、イベントtmpevent（＝READ_ADMINFILE）により、状態遷移が実行され、状態遷移ラベル「LABEL_ADMINFILE」の状態ノードがNOT＿READからREADに遷移する。このとき、スタック領域記憶部９には、図１９（ｈ）に示す深さ８のように、｛ON，ON，ISSUE，READ，NOT，4｝がプッシュされて記憶される。
図１０（ｉ）に示す深さ９においては、tmpnodeのイベントＩＤが「４」の場合、イベントtmpevent（＝READ_USERFILE）により、状態遷移が実行され、状態遷移ラベル「LABEL_USERFILE」の状態ノードがNOT＿READからREADに遷移する。このとき、スタック領域記憶部９には、図１９（ｉ）に示す深さ９のように、｛ON，ON，ISSUE，READ，READ，4｝がプッシュされて記憶される。

＜図１０の深さ１０において、状態ノードの組合せがリスクで検出される処理（図１６参照）＞
また、状態管理記憶部８の状態ノードの値の組み合わせが、リスクファイル記憶部７に記憶されている集合リスクのいずれかの組み合わせと一致した場合の処理について、深さ＝１０において説明する。
深さ９における処理８−ｂにおいて、すでに述べたように、スタック領域記憶部９には｛ON，ON，ISSUE，READ，READ，4｝がプッシュされて記憶されている。
そして、検証部３は、スタックが空か否かを検出し（処理３）、空でないことを検出し、処理８−ｂを通過しているため、深さ＝９から深さ＝１０へ処理の対象が移行することとなるので、スタックＳＴから読み出した状態ノードの値の組み合わせと、スタックＮＤから読み出したイベント番号（＝１）とを、状態管理記憶部８へ記憶させる（処理４−１）。

そして、検証部３は、処理４−１にて状態管理記憶部８へ記憶した現在の状態｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝を、履歴記憶部６のhistoryに記憶する（処理５）。
ここで、検証部３は、現在の状態における状態ノードの値の組み合わせが、リスクファイル記憶部７のリスク集合に含まれている状態ノードの値の組み合わせのいずれかと一致するか否かの検出を行い（処理６）、リスクＲ４の｛LABEL_LIFECYCLE，LABEL_USERFILE｝＝{ISSUE，READ}に対応していることが検出されたため、処理を処理９へ進める。
そして、検証部３は、現在のスタックＳＴ及びスタックＮＤの全てを内部のriskファイルにリスク到達履歴として追加書き込みして記憶する（処理９）。
最終的に、全ての検証が終了した際、検証部３は、出力部４を介して結果リストとして、上記riskファイルを出力する。

このスタック領域記憶部９のRISKLOGにより、イベントをどの順序にて実行した場合に、リスクに到達するのかを知ることができる。
続いて、関数Ａが実行されるが、深さ１０（図１０（ｊ））においては、tmpnodeのイベント番号｛node｝が「５」の場合、イベントtmpevent（＝CHANGE_LIFECYCLE1）による状態遷移と、その事後イベントRESET_KEY1による状態遷移が実行され、状態遷移ラベル「LABEL_LIFECYCLE」の状態ノードがISSUEからUSAGEの遷移と、状態遷移ラベル「LABEL_ADMINFILE」の状態ノードがREADからNOT＿READの遷移と、状態遷移ラベル「LABEL_AUTH1」の状態ノードがONからOFFへの遷移とが行われる。これにより、スタック領域記憶部には、図２０の（ｊ）に示すように、｛OFF，ON，USAGR，NOT，READ，5｝がプッシュされて記憶される。

＜図１０の深さ１１におけるスタックからのポップ処理（図１７及び図１８参照）＞
次に、スタックに対してプッシュされた状態ノードの組み合わせ及びイベント番号｛node｝がポップされる動作について深さ＝１１において説明する。添付したフローチャートにおいては、深さ＝１１において、イベント番号｛node｝が「６」までのイベント全てが実行できないとして説明している。
上記処理をイベント番号｛node｝が「５」のイベント（CHANGE_LIFECYCLE1）により得られるnewstatesがすでにスタックＳＴに記憶されている状態ノードの組み合わせに存在するため、処理Ａ５に処理が戻った時点から説明する。
展開部２は、tmpnodeのイベント番号｛node｝をインクリメントし、（処理Ａ５）、処理を処理Ａ６へ進める。

そして、展開部２は、このインクリメントしたtmpnodeのイベント番号｛node｝が予め設定しているノード数を超えたか否かの検出を行い（処理Ａ６）、イベント番号｛node｝が「６」でありノード数「６」を超えていないことを検出したため、処理を処理Ａ２へ進める。
これにより、展開部２は、tmpnode（＝２）のイベント番号｛node｝に対応するイベントであるtmpevent（CHANGE_LIFECYCLE2）を取得し（処理Ａ２）、newstatesを初期化し（処理Ａ３）、関数Ｂを読み出して処理を処理Ａ４へ進める。

次に、展開部２は、イベントtmpevent（CHANGE_LIFECYCLE2）に関連する状態ノード全ての状態遷移tmpmoveの一覧を遷移状態モデルから抽出して取得し（処理Ｂ１）、関数Ｃを読み出し処理を処理Ｂ２へ進める。この処理Ｂ１において、イベントtmpevent（CHANGE_LIFECYCLE2）に対応する状態遷移tmpmoveは、CHANGE_LIFECYCLE2の状態ノードをUSAGEからISSUEへ移行することが示されている。また、イベントtmpevent（CHANGE_LIFECYCLE2）には事後イベントRESET_KEY1が設定され、事前条件としてLABEL_AUTH1＝ONであることが設定されている。

処理が処理Ｂ２に遷移すると、展開部２は、状態遷移tmpmoveに記載された状態ノードの値の遷移が行われるための事前条件tmpconstrainの事前条件テーブルを取得し（処理Ｃ１）、事前条件が設定されている状態ノードの有無を検出し、かつ事前条件が満足されているか否かを検出する（処理Ｃ２）が、事前条件LABEL_AUTH1＝ONが検出され、現在、LABEL_AUTH1＝ONであるため、事前条件を満足していることを検出したため、処理を処理Ｃ３へ進める。
そして、展開部２は、状態遷移tmpmoveにおける状態遷移前の状態ノードの値を取得してprestate（＝USAGE）に設定し、状態遷移後の状態ノードの値を取得してpoststate（＝ISSUE）に設定する（処理Ｃ３）。

展開部２は、現在の状態ノードの値（ISSUE）が、prestate（＝USAGE）と一致しているか否かを検出し（処理Ｃ４）、一致していないことを検出したため処理を処理Ｃ１１へ進める。
これにより、展開部２は、false信号を出力し（処理Ｃ１１）、処理を処理Ｂ５へ進める。
そして、展開部２は、false信号を出力し（処理Ｂ５）、処理を処理Ａ５へ進める。
次に、展開部２は、tmpnodeのイベント番号｛node｝をインクリメントし（処理Ａ５）、処理を処理Ａ６へ進める。

そして、展開部２は、このインクリメントしたtmpnodeのイベント番号｛node｝が予め設定しているノード数を超えたか否かの検出を行い（処理Ａ６）、イベント番号｛node｝が「７」でありノード数「６」を超えたことを検出したため、処理を処理Ａ８へ進める。
これにより、展開部２は、false信号を出力し（処理Ａ８）、処理を８−ａへ進める。
次に、検証部３は、スタックＳＴ及びスタックＮＤの先頭に記憶されている状態ノードの組み合わせ｛OFF，ON，ISSUE，NOT，READ｝とイベント番号｛node｝の「５」とをポップして削除する（処理８−ａ）。

ここで、深さ＝１１の処理から深さ＝１０の処理に戻り、検証部３は、スタックの各領域が空であるか否かを検出し（処理３）、処理８−ａを通過してきているため、ポップして削除したスタックＳＴの先頭にあった状態の組み合わせ｛OFF,ON,USAGE,NOT,READ｝と、スタックＮＤの先頭にあったイベント番号｛５｝をインクリメント（１を加算）した値とを、状態管理記憶部８に現在の状態として記憶する（処理４−２、図１０（ｌ））。
そして、検証部３は、処理４にて状態管理記憶部８へ記憶した現在の状態｛AUTH1，AUTH2，LIFECYCLE，ADMINFILE，USERFILE｝を、履歴記憶部６historyに記憶する（処理５）。
後述する処理についてはすでに説明しているため省略する。

上述したように、本実施形態によれば、製品の仕様を状態遷移モデルとして記述し、「起こるべきではない状態」をリスク集合としてリスクファイル記憶部７に記憶され、外部からイベントを与え、このイベントにより状態遷移後の、状態ノードの組み合わせがリスク集合に含まれているか否かを検証することにより、仕様欠陥を設計段階レベルにて無くすことが可能な仕様欠陥検証システムを提供することができる。また、状態遷移には、外部から与えられるイベントのみでなく、状態遷移による状態ノードの変更に伴い起動される事後イベントによる状態遷移を含むため、全ての状態遷移を網羅して製品仕様を検証することができる。

なお、図１における仕様欠陥検証システムの機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、設計段階における仕様欠陥検証の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、ホームページ提供環境（あるいは表示環境）を備えたＷＷＷシステムも含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

本発明の一実施形態による仕様欠陥検証システムの構成例を示すブロック図である。 図１のモデル記憶部５に記憶されている状態遷移モデルを構成する状態遷移ラベルの一例を示す概念図である。 図２における各状態遷移ラベルの構成を示すテーブルである。 イベントＩＤとイベント名との対応関係を示すイベントテーブルの構成例を示す図である。 図３の状態遷移モデルに対応するリスク状態と判定される状態ノードの組み合わせと、各リスク状態の組み合わせを示すリスクＩＤとの対応を示すリスクテーブルの構成例を示す図である。 図１の仕様欠陥検証システムの動作例を示すフローチャートである。 図１の仕様欠陥検証システムの動作例を示すフローチャートである。 図１の仕様欠陥検証システムの動作例を示すフローチャートである。 図１の仕様欠陥検証システムの動作例を示すフローチャートである。 図１の仕様欠陥検証システムの実施形態の図９〜図１０５の検証例における検証の深さと各深さにおけるイベントのイベント番号との関係を示す概念図である。 図１の仕様欠陥検証システムの実施形態による検証例のフローを示すテーブルである。 図１の仕様欠陥検証システムの実施形態による検証例のフローを示すテーブルである。 図１の仕様欠陥検証システムの実施形態による検証例のフローを示すテーブルである。 図１の仕様欠陥検証システムの実施形態による検証例のフローを示すテーブルである。 図１の仕様欠陥検証システムの実施形態による検証例のフローを示すテーブルである。 図１の仕様欠陥検証システムの実施形態による検証例のフローを示すテーブルである。 図１の仕様欠陥検証システムの実施形態による検証例のフローを示すテーブルである。 図１の仕様欠陥検証システムの実施形態による検証例のフローを示すテーブルである。 各処理の深さにおいて成功するイベントに対応し、状態遷移後の状態ノードの組み合わせと実行されたイベント番号とが、スタック記憶領域記憶部９にプッシュされていく過程を示す概念図である。 各処理の深さにおいて成功するイベントに対応し、状態遷移後の状態ノードの組み合わせと実行されたイベント番号とが、スタック記憶領域記憶部９にプッシュされていく過程を示す概念図である。

符号の説明

１…初期設定部
２…展開部
３…検証部
４…出力部
５…モデル記憶部
６…履歴記憶部
７…リスクファイル記憶部
８…状態管理記憶部
９…スタック領域記憶部

Claims (10)

1. 設計対象のシステムの仕様をイベントの発生に伴う状態ノードの変更による状態遷移の複数の組み合わせとして記述した状態遷移モデルとし、前記イベントに基づく状態遷移のシミュレーションにより、該設計対象のシステムの仕様を検証する仕様欠陥検証システムであって、
   前記状態遷移モデルが記憶されているモデル記憶部と、
   前記状態遷移モデルの状態ノードの状態において、発生してはいけない状態ノードの組合せを示すリスクファイルが記憶されたリスクファイル部と、
   該モデル記憶部から前記状態遷移モデルを読み出し、該状態遷移モデルから、イベント、及び該イベントによる状態ノードの遷移前後の状態を示す状態情報を読み出す初期設定部と、
   前記イベントを順次実行し、所定の条件を満たす場合に前記状態情報に応じて状態ノードの状態を変更し、状態遷移モデルにおける状態遷移を行う展開部と、
   前記展開部の前記イベントの実行により状態ノードの状態が変更された場合、遷移後の状態ノードの状態及びイベントとを状態遷移モデルから抽出し、遷移後の状態ノードの状態がリスクファイル部に記憶されている発生してはいけない状態ノードの組合せに一致するか否かを検出し、一致した場合に仕様欠陥として出力する検証部と
   を有することを特徴とする仕様欠陥検証システム。
2. 前記仕様欠陥検証システムがさらにスタック領域記憶部を有し、
   前記展開部が、前記状態遷移モデルの初期状態の状態ノードの組み合わせと、イベントの実行により状態ノードの状態が変更された場合の遷移後の状態ノードの組み合わせ及びイベントとを前記スタック領域記憶部にプッシュする
   ことを特徴とする請求項１に記載の仕様欠陥検証システム。
3. 前記状態遷移モデルが前記イベントを実行したときに前記状態ノードの値を変更する条件として、前記状態ノードの値を事前条件として有しており、
   前記展開部がイベントの実行時における状態ノードの値が前記事前条件に一致する場合、イベントに対応して状態ノードの値を変更して状態遷移を行うことを特徴とする請求項１または請求項２に記載の仕様欠陥検証システム。
4. 前記展開部が、前記イベントの実行による状態遷移モデルにおける状態遷移が行われた場合、遷移した状態を示す状態情報を、時系列に記憶する履歴管理記憶部をさらに有することを特徴とする請求項１から請求項３のいずれかに記載の仕様欠陥検証システム。
5. 前記展開部は、遷移後の状態の組み合わせと前記履歴管理記憶部に記憶されている状態ノードの組み合わせとが一致した場合、対応するイベントの状態遷移を行わないことを特徴とする請求項４記載の仕様欠陥検証システム。
6. 前記状態遷移モデルが、状態ノードの変化に対応して実行される事後イベントを有していることを特徴とする請求項１から請求項５のいずれかに記載の仕様欠陥検証システム。
7. 前記検証部が状態遷移後の状態ノードの組み合わせと、前記リスクファイル部に記憶されている発生してはいけない状態ノードの組合せとが一致した場合、前記スタック領域記憶部に記憶されている各状態における状態ノードの組み合わせとイベントとを出力することを特徴とする請求項２から請求項６のいずれかに記載の仕様欠陥検証システム。
8. 前記展開部が、ある状態遷移における状態ノードの組み合わせにおいて、全てのイベントが実行され、状態遷移が行われなかった場合、前記スタック領域記憶部の最上部のイベントの組み合わせをポップし、その前の状態で未実行のイベントを実行することを特徴とする請求項２から請求項７のいずれかに記載の仕様欠陥検証システム。
9. 設計対象のシステムの仕様をイベントの発生に伴う状態ノードの変更による状態遷移の複数の組み合わせとして記述した状態遷移モデルとし、前記イベントに基づく状態遷移のシミュレーションにより、該設計対象のシステムの仕様を検証する仕様欠陥検証方法であって、
   初期設定部が状態遷移モデルが記憶されているモデル記憶部から前記状態遷移モデルを読み出し、該状態遷移モデルから、イベント、及び該イベントによる状態ノードの遷移前後の状態を示す状態情報を読み出す過程と、
   展開部が前記イベントを順次実行し、所定の条件を満たす場合に前記状態情報に応じて状態ノードの状態を変更し、状態遷移モデルにおける状態遷移を行う過程と、
   検証部が前記展開部の前記イベントの実行により状態ノードの状態が変更された場合、遷移後の状態ノードの状態及びイベントとを状態遷移モデルから抽出し、前記状態遷移モデルの状態ノードの状態において発生してはいけない状態ノードの組合せを示すリスクファイルが記憶されたリスクファイル部に記憶されている発生してはいけない状態ノードの組合せと、前記遷移後の状態ノードの状態が一致するか否かを検出し、一致した場合に仕様欠陥として出力する過程と
   を有することを特徴とする仕様欠陥検証方法。
10. 請求項１から請求項８のいずれかに記載の仕様欠陥検証システムとして、コンピュータを機能させるためのプログラム。

Images