JP2013057985A

JP2013057985A - システムの設計支援装置および方法

Info

Publication number: JP2013057985A
Application number: JP2009279041A
Authority: JP
Inventors: Makoto Ichii; 誠市井; Masumi Kawakami; 真澄川上; Hideto Noguchi; 秀人野口
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2009-12-09
Filing date: 2009-12-09
Publication date: 2013-03-28
Also published as: WO2011071016A1

Abstract

【課題】ソフトウェア開発において状態設計をする作成される状態表は、内部状態によって分岐する場合には記述が煩雑かつ複雑になる
【解決手段】あらかじめ記憶部２３０に登録した画面状態定義２３１及び内部状態定義２３２を用いて、状態表及び決定表からなく決定テーブル２３３を作成する。
【選択図】図１

Description

本発明は、特に組込みシステム向けのソフトウェア開発支援及び検証に関する。

組込みシステムの開発では、状態表を用いてシステムを設計することが多い。状態表を用いた設計では、ユーザが画面等で認識できるシステムの状態（「画面状態」という）と、システムがユーザから受ける操作やセンサなどで検知される現象（「イベント」という）との組に対して、システムの画面状態遷移やシステムが行うべき処理（「アクション」という）を決定する。図１０に状態表の例を示す。状態表は、ある画面状態（横軸）においてあるイベント（縦軸）が発生した時に、遷移すべき画面状態（上段）とアクション（下段）との組を単一もしくは複数の表に定義するものである。状態表１０１では、例えば、画面状態が「OFF」のときに「電源ボタン」のイベントが生じれば、画面状態が「放送画面」へと遷移すること、画面状態が「放送画面」のときに「録画ボタン」のイベントが生じれば「録画開始」のアクションが実行されること、画面状態が「OFF」のときに「録画ボタン」のイベントが生じても画面状態の遷移やアクションの実行はないこと、などが表現されている。

状態表１０１は単純な例であるが、実際には、ある画面状態とイベントとの組に対して生じる画面状態遷移／アクションが、そのイベントが生じた時点でのシステムの「内部状態」に応じて異なる場合がある。非特許文献１はこのような場合の状態表の定義方法を例示している。第１の方法では、状態表１０２のようにイベント行を分割し、分割したそれぞれの行（１０３、１０４）に内部状態を条件として定義する。また、第２の方法では、アクション１０５のように、プログラムコードなどの分岐を表現できる記法を用いてアクションと遷移後の画面状態とを定義する。さらに、非特許文献１には、内部状態の遷移を定義するために、アクション１０６のようにプログラミング言語を用いて内部状態の遷移を表現するアクションを定義することが開示されている。

渡辺政彦, 拡張階層化状態遷移表設計手法 Ver.2.0 P.8-9, キャッツ株式会社, 1998

近年の組込みシステムは大規模化および複雑化が進展している。そのため、非特許文献１の第１の方法では、内部状態を考慮しなければならないイベントや内部状態そのものが多いと、条件分岐のための行の分割により状態表が非常に大きくなり、全体を一覧することができなくなり、設計の漏れや誤りの発見や、定義および修正すべき箇所の発見が困難になり、設計の効率が落ちるおそれがある。

一方、非特許文献１の第２の方法を用いれば状態表はコンパクトになるが、記述自由度の高いプログラミング言語を用いて内部条件を記述することに起因して、条件分岐に含まれる内部条件や、遷移の記述に不整合が生じるおそれがある。

また、開発されるシステムの状態設計を手作業で検証することが困難になったことに伴い、状態設計の性質を検証する自動化ツールも開発されてきている。例えば、状態設計をPromelaとよばれる言語で記述し、SPINとよばれる検査ツールへ入力することで、状態到達性などの状態設計の性質を検証するような自動化ツールも存在する。しかしながら、状態表の記載方法に対する自由度が高いと、状態設計の性質についての検証に必要な画面状態遷移の条件に関する情報を状態設計情報から機械的に抽出することができないため、人手によらない自動的な検証ができない。

本発明では、複数のコンポーネントを有するシステムの状態設計にあたり、各コンポーネント（この中には被制御対象のコンポーネントが含まれる）の状態の定義及び状態間の遷移情報と被制御対象のコンポーネントの状態変化をもたらすイベントがあらかじめ登録される。これに基づき、被制御対象のコンポーネントの状態およびイベントを行および列とする状態表を作成する。前記状態表の各セル（すなわち、被制御対象となるコンポーネントの状態とイベントとの組み合わせ）に対応して、条件分岐となる他のコンポーネントの状態（ここでは「内部状態」という）と遷移後の被制御対象のコンポーネントの状態と遷移後の内部状態との３つ組の情報をもつ決定表を作成する。ここで、決定表に入力する内部状態は、はじめに登録された内部状態に限定され、また、決定表により表現される内部状態の状態遷移は、はじめに登録された内部状態間の遷移情報に限定される。

このように、本発明では、画面状態とイベントの組み合わせに対して決定表を作成し、内部条件による分岐は決定表にのみ含めることで、状態表が大きくなることを防ぐことができる。

また、本発明では、決定表に入力される内部状態は、最初に登録された内部状態に限定され、また、決定表に入力される内部状態の遷移は、最初に登録された遷移関係に限定されるため、内部状態を統一的に入力することができ、さらに、内部状態入力すべき内部状態の選択肢を利用者に提示し、選択させることによる、入力効率の向上が可能となる。

また、状態表から、画面状態の遷移に関係する情報を抽出し、抽出した情報を画面状態の性質を検証するアルゴリズムへと入力することで、状態表の性質の検証を実現する。状態表からの情報の抽出は、すべての画面状態とイベントの組に対して決定表が網羅的に作成されていることと、それぞれの決定表の条件分岐は、定義された内部状態のみで構成されていることと、それぞれの決定表の内部条件の遷移は、定義された内部状態遷移のみであること、それぞれの決定表が漏れなく記入されていることによって、機械的に行うことができる。

状態表の規模増大に起因する設計効率の低下無しに、かつ、内部状態の記入誤りなく、画面状態遷移および内部状態遷移の記述を行うことができる。

また、記述した状態設計に対する検証を機械的に行うことができる。

設計支援装置のシステム構成図である。画面状態テーブルの例である。画面状態遷移テーブルの例である。イベントテーブルの例である。内部状態テーブルの例である。内部状態遷移テーブルの例である。決定テーブルの例である。決定テーブルを作成する処理フローを示す図である。検証アルゴリズムのフローを示す図である。状態表の例である。

以下、図面を参照して本発明の実施形態について詳しく説明する。

設計支援装置２００は、システムの状態設計における、内部状態とイベントの組に対する決定表の記述を支援し、状態設計の検証用の情報を出力する装置である。ここで、状態設計支援装置２００の機能構成の一例を、図１のブロック図に示す。状態設計支援装置２００は、図示するように、入力部２１０と、制御部２２０と、記憶部２３０と、出力部２４０とを有する。

入力部２１０は、ユーザによって入力されるデータを受付け、入力されたデータを制御部２２０または記憶部２３０に供給する。入力部２１０に受け付けられた状態表に関する情報、内部状態定義に関する情報は、それぞれ記憶部２３０の画面状態定義データベース２３１及び内部状態定義データベース２３２に格納する。また、入力部２１０に受け付けられた決定表に関する情報により決定表処理部２２１を駆動し、入力部２１０に受け付けられた検証に関する情報により検証部２２２を駆動する。

制御部２２０は、決定表処理部２２１と、検証部２２２とを有する。決定表処理部２２１は、画面状態定義データベース２３１に格納された情報と内部状態定義データベース２３２に格納された情報と入力部２１０を通じて入力された情報とから作成される決定表を記憶部２３０の決定表データベース２３３に格納する。

このような設計支援装置は、例えば、入力部２１０、出力部２４０は端末装置、制御部２２０はコンピュータ、記憶部２３０は外部記憶装置で実現でき、決定表処理部２２１及び検証部２２２はそれぞれコンピュータで実行されるプログラムで実現することができる。また、スタンドアロンの計算機のみならず、ネットワーク環境で動作する計算機で実現されてもよい。

ここで、設計支援装置により設計支援しようとする開発対象のシステムは、複数のコンポーネントからなるシステムである。本実施例はＴＶのようなシステムのユーザインタフェース設計を例にとって説明する。ユーザによるリモコンへの入力に応じた出力を、システムはディスプレイに表示するインタフェースがこの例での設計対象である。このとき、録画装置のような、システムの他のコンポーネントの状態に応じて同じリモコン入力であっても、ディスプレイに表示される内容は異なる場合がある。

画面状態定義データベース２３１には、開発対象のシステムのすべての画面状態を表す画面状態テーブル３１０（図２）と、画面状態がとりうる遷移を表す画面状態遷移テーブル３２０（図３）と、画面状態を変化させるイベントを表すイベントテーブル３３０（図４）とが予め記憶されている。

図２に示すように、画面状態テーブル３１０は、画面状態名欄３０１を備え、画面状態を識別する情報（画面状態名）が格納されている。例えば、それぞれディスプレイに特定内容が表示されることを示す「画面状態１」、「画面状態２」等の名前が格納される。また、図３に示すように、画面状態遷移テーブル３２０は、遷移前画面状態欄３２１と遷移後画面状態欄３２２とを備え、それぞれ画面状態テーブル３１０に格納された画面状態を識別する情報が格納される。遷移後画面状態欄３２２の画面状態は、遷移前画面状態欄３２１に格納されている画面状態ごとに対応付けて格納されている。図３の例では、「画面状態１」から「画面状態２」または「画面状態３」という２通りの画面状態遷移が存在することを示している。図４に示すように、イベントテーブル３３０は、イベント名欄３３１を備え、イベントを識別する情報（イベント名）が格納されている。例えば、リモコンの第１ボタンがユーザによって押下されたことを示す「イベント１」、リモコンの第２ボタンがユーザによって押下されたことを示す「イベント２」等の名前が格納される。

また、内部状態定義データベース２３２には、開発対象のソフトウェアのすべての内部状態を示す内部状態テーブル４１０（図５）と、内部状態がとりうる遷移を表す内部状態遷移テーブル４２０（図６）とが格納されている。

図５に示すように、内部状態テーブル４１０は、内部状態区分欄４１１と内部状態名欄４１２とを備える。内部状態区分欄４１１には内部状態区分情報が格納される。内部状態区分とは、互いに独立な内部状態を区分するための情報である。区分は任意に決めてよいが、例えば、開発システムのコンポーネント単位に区分を設定することができる。録画装置における「テープ状態」、内蔵タイマーの「タイマー状態」といったものである。一方、内部状態名欄４１２には、内部状態区分４１１ごとにとりうる内部状態を識別する情報が格納されている。例えば、区分「テープ状態」に対して、「テープ正常」、「テープ異常」といった内部状態がとりうる。図５の例では、「内部状態区分１」は「内部状態１」、「内部状態２」、「内部状態３」を取りうることになる。

また、図６に示すように、内部状態遷移テーブル４２０は、遷移前内部状態欄４２１と、遷移後内部状態欄４２２とを備える。遷移前内部状態欄４２１及び遷移後内部状態欄４２２には、内部状態テーブル４１０に格納された内部状態を識別する情報が格納される。遷移後内部状態欄４２２の内部状態は、遷移前内部状態欄４２１に格納されている内部状態ごとに、対応付けて格納されている。図６の例では、「内部状態１」から「内部状態２」または「内部状態３」への２通りの内部状態の遷移が生じ得ることを示す。

決定表データベース２３３には、画面状態定義データベース２３１に格納される画面状態テーブル３１０、画面状態遷移テーブル３２０、イベントテーブル３３０と、内部状態定義データベース２３２に格納される内部状態テーブル４１０、内部状態遷移テーブル４２０とを用いて作成される決定テーブル４３０が格納される。図７に示すように、決定テーブル４３０は、画面状態欄４３１と、イベント欄４３２と、内部状態区分欄４３３と、内部状態欄４３４と、画面状態遷移欄４３５と、内部状態遷移欄４３６とを備える。

画面状態欄４３１には、画面状態テーブル３１０に格納された画面状態を識別する情報が格納される。図７の例では「画面状態１」等の画面状態名が格納される。イベント欄４３２には、イベントテーブル３３０に格納されたイベントを識別する情報が格納される。図７の例では「イベント１」などのイベント名が格納される。内部状態区分欄４３３には、内部状態テーブル４１０に格納された内部状態区分を識別する情報が格納される。図７の例では、「内部状態区分１」などの内部状態区分名が格納される。内部状態欄４３４には、内部状態テーブル４１０に格納された内部状態であって、内部状態区分欄４３３に格納された内部状態区分に対応するものが格納される。図７の例では、「内部状態区分１」に対応付けられた「内部状態１」、「内部状態２」等が格納される。

画面状態遷移欄４３５には、画面状態遷移テーブル３２０の遷移後画面状態欄３２２に格納された画面状態であって、遷移前画面状態欄３２１に対応づいている画面状態が画面状態欄４３１に格納された画面状態であるものが格納される。したがって、画面状態遷移欄４３５の画面状態は、画面状態欄４３１、イベント欄４３２、内部状態区分欄４３３、内部状態欄４３４の組ごとに対応付けて格納されている。例えば、図７の例では、画面状態が「画面状態１」にあるときに「イベント１」が発生した場合、「内部状態区分１」が「内部状態１」であれば、画面状態が「画面状態２」に遷移することを示す。

内部状態遷移欄４３６には、内部状態遷移テーブル４２０の遷移後内部状態欄４２２に格納された内部状態であって、遷移前内部状態欄４２１に対応づいている内部状態が、内部状態欄４３４に格納された内部状態であるものが格納される。したがって、内部状態遷移欄４３５の内部状態は、画面状態欄４３１、イベント欄４３２、内部状態区分欄４３３、内部状態欄４３４の組ごとに対応付けて格納されている。例えば、図７の例では画面状態が「画面状態１」にあるときに「イベント１」が発生した場合、「内部状態区分１」が「内部状態１」であれば、「内部状態区分１」が「内部状態２」に遷移することを示す。

次に、図８を用いて、決定表処理部２２１による決定テーブル４３０作成の処理の流れを説明する。Ｆ０１は、決定テーブル４３０を作成する対象となる画面状態とイベントの組を選択する流れを示している。これにより、例えば、図１０に示す状態表のうち、画面状態遷移または内部状態遷移の生じる画面状態とイベントとの組を選択する。Ｆ０２は、Ｆ０１で選択された画面状態とイベントの組それぞれに対する決定表を作成する流れを示している。決定表は、画面状態とイベントの組に対して、開発対象システムが所定の内部状態である場合に生じる画面状態遷移と内部状態遷移とを表す表である。

決定表処理部２２１は、入力部２１０に備えられた画面および入力装置を通じて、利用者への情報の提示、および、利用者からの入力の受付をおこなう。まず、システムは決定表が未入力である画面状態とイベントの組の集合を画面上に表示し（ステップＳ１０１）、画面状態とイベントの組の入力を受け付ける（ステップＳ１０２）。画面上に表示される画面状態とイベントの組の集合は、画面状態テーブル３１０とイベントテーブル３３０とからそれぞれ読込んだ画面状態の集合とイベントの集合の全組み合わせのうち、決定テーブル４３０に格納されていない組み合わせとして得られる。続いて、入力された画面状態とイベントの組の有効性の入力を受け付け（ステップＳ１０３）、入力された値が「無効」ならば、ステップＳ１０２で選択された画面状態とイベントの組が無効であることを示す特殊な値（例えば、NULL値）を決定テーブル４３０に格納し（ステップＳ１０６）、入力された値が「有効」ならば決定表作成に移る（ステップＳ１０５）。

決定表作成のフローチャートＦ０２では、内部状態テーブル４１０に格納された内部状態区分の集合を画面上に表示し（ステップＳ２０１）、内部状態区分の入力を受け付ける（ステップＳ２０２）。ステップＳ２０２で入力された内部状態区分に属する内部状態の一覧を内部状態テーブル４１０から読込み、画面上に表示する（ステップＳ２０３）。内部状態の入力を受け付けると（ステップＳ２０４）、ステップＳ１０１で入力された画面状態とイベントとステップＳ２０４で受け付けた内部状態の３つ組に対して有効性の入力を受け付ける（ステップＳ２０５）。入力された値が「無効」であれば、前記３つ組が無効であることを示す特殊な値を決定テーブル４３０に格納する（ステップＳ２１１）。入力された値が「有効」ならば、ステップＳ１０１で入力された画面状態を遷移前画面状態として持つ遷移後画面状態の集合を画面状態遷移テーブル３２０から読込み、画面上に表示し（ステップＳ２０７）、遷移後画面状態の入力を受け付ける（ステップＳ２０８）。続いて、ステップＳ２０４で入力された内部状態を遷移前内部状態としてもつ遷移後内部状態の集合を内部状態遷移テーブル４２０から読込み、画面上に表示し（ステップＳ２１０）、遷移後内部状態の入力を受け付ける（ステップＳ２１０）。続いて、ステップＳ１０１で入力された画面状態と、イベントと、ステップＳ２０２で入力された内部状態区分と、ステップＳ２０４で入力された内部状態と、ステップＳ２０８で入力された遷移後画面状態と、ステップＳ２１０で入力された遷移後内部状態とからなる組（この組を決定表という）を、決定テーブル４３０へ格納する（ステップＳ２１１）。ステップＳ２０２で入力された内部状態区分に対応づくすべての内部状態について、ステップＳ１０１で入力された画面状態とイベントとの３つ組が決定テーブル４３０に格納されているかどうかを確認し（ステップＳ２１２）、格納されていない内部状態が存在すれば、ステップＳ２０３に戻り、存在しなければ、Ｆ０２を完了する。

フローチャートＦ０１に戻り、Ｆ０２（ステップＳ１０５）の完了後、または、ステップＳ１０６での格納後、決定表が未作成である画面状態とイベントの組が存在しないかどうかを確認し（ステップＳ１０７）、未作成の組が存在すれば、ステップＳ１０１に戻り、すべて作成済であれば、手続きを終了する。

なお、決定表において条件となる内部状態区分は、図８の例では１個のみであるが、複数の内部状態区分の組み合わせで条件が形成されてもよい。この場合、決定表において遷移できる内部状態は、それら複数の内部状態の組み合わせに対して1つの遷移が生じればよい。また、すべての画面状態とイベントと内部状態の組合せに対してすべての入力が完了する前に処理を中断し、後に、続きから入力することも可能である。

検証部２２２は、図１に示すように、検証アルゴリズム５１０と、検証用情報抽出部５２０とを備える。検証アルゴリズム５２０は、入力部より与えられた情報と、検証用情報抽出部５１０を通じて記憶部２３０から読込んだ状態設計情報に対して、検証を行い、その結果を出力部２４０を通じて出力する。

図９は検証アルゴリズム５２０のフローチャートＦ０３およびＦ０４であって、入力として与えられた画面状態が、任意の画面状態から到達可能であるかどうかを検証する。ここで、ある画面状態Ｄ１から他の画面状態Ｄ２へ到達可能であるとは、フローチャートＦ０１に示した前記手続きに基づいて作成された決定表に基づき、画面状態Ｄ１からの画面状態の遷移を１度以上繰り返し、画面状態Ｄ２まで遷移可能な画面状態遷移の列が少なくとも１つ存在することを意味する。

フローチャートＦ０３は、任意の画面状態から特定の画面状態（画面状態１１）へ到達能かどうかを検証する手続きを示す。フローチャートＦ０３は、「到達可能」もしくは「到達不可能」のいずれかの結果を返す。画面状態テーブル３１０に登録されている画面状態それぞれ（画面状態１２とする）について（ステップＳ３０１、ステップＳ３０４）、画面状態１２から画面状態１１へ到達可能かどうかを判定する（ステップＳ３０２）。

フローチャートＦ０４は、特定の画面状態（画面状態２１）から、特定の画面状態（画面状態２２）へ、到達可能かどうかを検証する再帰的な手続きを示す。フローチャートＦ０４は、「到達可能」もしくは「到達不可能」のいずれかの結果を返す。イベントテーブル３３０に登録されているイベントそれぞれについて（ステップＳ４０１，ステップＳ４１１）、画面状態２１に対する決定表が存在すれば（ステップＳ４０２）、該決定表を決定表２１として参照する（ステップＳ４０３）し、決定表２１上の遷移先画面状態それぞれについて（ステップＳ４０４，ステップＳ４１０）、前記遷移先画面状態を画面状態２３としたとき、画面状態２３から画面状態２２へ到達移可能かどうかを判定する。ただし、画面状態２３が検査済集合２１の要素であれば該判定は行わない（ステップＳ４０５）。これは、ある画面状態から同一画面状態に到達可能である場合に、フローチャートＦ０４における再帰的手続きにおいて、該画面状態から画面状態２２へ到達可能かどうかの判定を繰り返すことで本手続きが停止しないような事態を防ぐ。画面状態２３が検査済集合２１の要素でなければ、画面状態２３を検査済集合２１の要素に加える（ステップＳ４０６）。画面状態２３を検査済画面状態２３が画面状態２２と一致すれば到達可能であり（ステップＳ４０７）、それ以外の場合は、画面状態２３から画面状態２２へ到達可能かどうかを、フローチャートＦ０４に示す手続きを用いて再帰的に判定する（ステップ４０８）。前記判定結果が「到達可能」であれば（ステップＳ４０７もしくはステップＳ４０９）、フローチャートＦ０４は結果として「到達可能」を返す（ステップＳ４１３）。すべてのイベント（ステップＳ４０１、ステップＳ４１１），すべての遷移先画面状態（ステップＳ４０４、ステップＳ４１０）について繰り返した結果、すべて「到達不可能」であれば、フローチャートＦ０４は結果として「到達不可能」を返す（ステップＳ４１２）。

フローチャートＦ０３に戻り、繰り返し３１（ステップＳ３０２，ステップＳ３０５）における画面状態のすべてが画面状態１１に対して「到達可能」と判定されれば、フローチャートＦ０３は結果として「到達可能」を返し（ステップＳ３０６）、さもなくば、結果として「到達不可能」を返す（ステップＳ３０７）。

以上、ＴＶシステムのユーザインタフェースを例に実施例を説明してきたが、本発明の適用範囲はこれに限られるものではない。複数のコンポーネントからなるシステムに対し、被制御対象となるコンポーネントの状態（上記実施例では「画面状態」）が、制御対象となるコンポーネントに生じる状態変化、すなわちイベント（上記実施例では「イベント」）と他の一つ以上のコンポーネントの状態（上記実施例では「内部状態」）に応じて遷移するシステムに広く適用できる。例えば、制御対象となるコンポーネントも人が操作するシステムに限られず、センサによって検出される変化入力であってもよい。また、設計目的に応じて被制御対象となるコンポーネントは変化しうることはいうまでもない。

また、システムに対して、イベントテーブルを作成するコンポーネント、内部状態テーブルを作成するコンポーネントは設計目的に依存して選択してよい。ただし、選択したコンポーネントについてはそのとりうる状態を網羅してテーブルを作成する必要がある。

１０１：状態表、２００：状態設計支援装置、２１０：入力部、２２０：制御部、２２１：決定表処理部、２２２：検証部、２３０：記憶部、２３１：画面状態定義データベース、２３２：内部状態定義データベース、２３３：決定表データベース、２４０：出力部、３１０：画面状態テーブル、３２０：画面状態遷移テーブル、３３０：イベントテーブル、４１０：内部状態テーブル、４２０：内部状態遷移テーブル、４３０：決定テーブル、５１０：検証用情報抽出部、５２０：検証アルゴリズム。

Claims

複数のコンポーネントを有するシステムの設計支援装置であって、
被制御対象となる第１コンポーネントのとりうる状態を登録する第１状態テーブル、上記第１状態テーブルに登録された状態間で生じうる遷移を登録する第１状態遷移テーブル、第２コンポーネントのとりうる状態を登録する第２状態テーブル、上記第２状態テーブルに登録された状態間で生じうる遷移を登録する第２状態遷移テーブル、制御のためのイベントを登録するイベントテーブルをあらかじめ記録し、
上記第１状態テーブルに登録された状態と上記イベントテーブルに登録されたイベントとの組み合わせの有効性を受け付ける第１手段と、
上記有効とされた上記第１コンポーネントの状態とイベントとの組み合わせに対して、上記第２状態テーブルに登録された状態との組み合わせの有効性を受け付ける第２手段と、
上記有効とされた上記第１コンポーネントの状態とイベントと上記第２コンポーネントの状態との組み合わせについて、上記第１状態遷移テーブルを参照し、該第１コンポーネントの状態から遷移される他の上記第１コンポーネントの状態を特定する第３手段と、
上記有効とされた上記第１コンポーネントの状態とイベントと上記第２コンポーネントの状態との組み合わせについて、上記第２状態遷移テーブルを参照し、該第２コンポーネントの状態から遷移される他の上記第２コンポーネントの状態を特定する第４手段と、
上記有効とされた上記第１コンポーネントの状態とイベントと上記第２コンポーネントの状態との組み合わせについて、上記第３手段で特定された上記第１コンポーネントの状態及び上記第４手段で特定された上記第２コンポーネントの状態を決定表に登録する第５手段とを有する設計支援装置。
請求項１において、
上記第２状態テーブル及び上記第２状態遷移テーブルは複数の第２コンポーネントに対して作成され、
上記第２状態テーブルに登録される状態は、上記複数の第２コンポーネントごとに区分されて登録される設計支援装置。
複数のコンポーネントを有するシステムの設計支援装置であって、
被制御対象となる第１コンポーネントのとりうる状態を登録する第１状態テーブル、制御のためのイベントを登録するイベントテーブルと、第１コンポーネントの状態とイベントと他のコンポーネントの状態の組み合わせに対して、所定の条件下で遷移する第１コンポーネントの状態を少なくとも登録する決定表とをあらかじめ記録し、
上記第１状態テーブルから、任意の第１状態と第２状態とを選択する第１手段と、
上記第１コンポーネントの上記第１状態と上記イベントテーブルに登録されたイベントとの組み合わせに対して、上記決定表に登録された上記遷移する第１コンポーネントの状態を抽出する第２手段と、
上記第２手段で抽出された第１コンポーネントの状態が上記第２状態と一致しない場合には、上記第２手段での組み合わせのうち、上記第１状態を上記第２手段で抽出された第１コンポーネントの状態に代えて、上記決定表に登録された上記遷移する第１コンポーネントの状態を抽出する第３手段と、
上記第３手段で抽出された上記遷移する第１コンポーネントの状態が上記第２状態と一致するまで、上記第２手段での組み合わせのうち、上記第１状態を上記第３手段で抽出された第１コンポーネントの状態に代えて、上記決定表に登録された上記遷移する第１コンポーネントの状態を抽出する第４手段とを有する設計支援装置。
請求項３において、
第１手段で選択する任意の第１状態と第２状態が上記第１状態テーブルからとりうるすべての状態の組み合わせを満たすまで、上記第２乃至第４手段を繰り返す設計支援装置。
請求項３において、
上記第２状態に遷移可能であることが検証された第１コンポーネントの状態の集合を記憶し、
上記第３手段において、上記第２手段で抽出された第１コンポーネントの状態が上記集合に含まれる場合には上記第１状態から上記第２状態に遷移可能であると判定する設計支援装置。
請求項５において、
上記第４手段において、上記第３手段で抽出された第１コンポーネントの状態が上記集合に含まれる場合には上記第１状態から上記第２状態に遷移可能であると判定する設計支援装置。
複数のコンポーネントを有するシステムの設計支援方法であって、
被制御対象となる第１コンポーネントのとりうる状態を登録する第１状態テーブル、上記第１状態テーブルに登録された状態間で生じうる遷移を登録する第１状態遷移テーブル、第２コンポーネントのとりうる状態を登録する第２状態テーブル、上記第２状態テーブルに登録された状態間で生じうる遷移を登録する第２状態遷移テーブル、制御のためのイベントを登録するイベントテーブルをあらかじめ記録し、
上記第１状態テーブルに登録された状態と上記イベントテーブルに登録されたイベントとの組み合わせの有効性を受け付ける第１ステップと、
上記有効とされた上記第１コンポーネントの状態とイベントとの組み合わせに対して、上記第２状態テーブルに登録された状態との組み合わせの有効性を受け付ける第２ステップと、
上記有効とされた上記第１コンポーネントの状態とイベントと上記第２コンポーネントの状態との組み合わせについて、上記第１状態遷移テーブルを参照し、該第１コンポーネントの状態から遷移される他の上記第１コンポーネントの状態を特定する第３ステップと、
上記有効とされた上記第１コンポーネントの状態とイベントと上記第２コンポーネントの状態との組み合わせについて、上記第２状態遷移テーブルを参照し、該第２コンポーネントの状態から遷移される他の上記第２コンポーネントの状態を特定する第４ステップと、
上記有効とされた上記第１コンポーネントの状態とイベントと上記第２コンポーネントの状態との組み合わせについて、上記第３ステップで特定された上記第１コンポーネントの状態及び上記第４ステップで特定された上記第２コンポーネントの状態を決定表に登録する第５ステップとを有する設計支援方法。
請求項７において、
上記第２状態テーブル及び上記第２状態遷移テーブルは複数の第２コンポーネントに対して作成され、
上記第２状態テーブルに登録される状態は、上記複数の第２コンポーネントごとに区分されて登録される設計支援方法。
複数のコンポーネントを有するシステムの設計支援方法であって、
被制御対象となる第１コンポーネントのとりうる状態を登録する第１状態テーブル、制御のためのイベントを登録するイベントテーブルと、第１コンポーネントの状態とイベントと他のコンポーネントの状態の組み合わせに対して、所定の条件下で遷移する第１コンポーネントの状態を少なくとも登録する決定表とをあらかじめ記録し、
上記第１状態テーブルから、任意の第１状態と第２状態とを選択する第１ステップと、
上記第１コンポーネントの上記第１状態と上記イベントテーブルに登録されたイベントとの組み合わせに対して、上記決定表に登録された上記遷移する第１コンポーネントの状態を抽出する第２ステップと、
上記第２ステップで抽出された第１コンポーネントの状態が上記第２状態と一致しない場合には、上記第２ステップでの組み合わせのうち、上記第１状態を上記第２ステップで抽出された第１コンポーネントの状態に代えて、上記決定表に登録された上記遷移する第１コンポーネントの状態を抽出する第３ステップと、
上記第３ステップで抽出された上記遷移する第１コンポーネントの状態が上記第２状態と一致するまで、上記第２ステップでの組み合わせのうち、上記第１状態を上記第３ステップで抽出された第１コンポーネントの状態に代えて、上記決定表に登録された上記遷移する第１コンポーネントの状態を抽出する第４ステップとを有する設計支援方法。
請求項９において、
第１ステップで選択する任意の第１状態と第２状態が上記第１状態テーブルからとりうるすべての状態の組み合わせを満たすまで、上記第２乃至第４ステップを繰り返す設計支援方法。
請求項９において、
上記第２状態に遷移可能であることが検証された第１コンポーネントの状態の集合を記憶し、
上記第３ステップにおいて、上記第２ステップで抽出された第１コンポーネントの状態が上記集合に含まれる場合には上記第１状態から上記第２状態に遷移可能であると判定する設計支援方法。
請求項１１において、
上記第４ステップにおいて、上記第３ステップで抽出された第１コンポーネントの状態が上記集合に含まれる場合には上記第１状態から上記第２状態に遷移可能であると判定する設計支援方法。