(57)【要約】【課題】プロセッサと、メモリと、ハード・ドライブとを有するビジネス用コンピュータ・システムの動作を制御するシステムを提供する。【解決手段】ビジネス用コンピュータ・システムは、コンピュータ・システムの状態マシンの実施を定義する仕様言語ステートメントを含むハード・ドライブ上に格納された仕様言語ファイルと、仕様言語ファイルから仕様言語ステートメントを抽出するため、および抽出された仕様言語ステートメントを解釈するためのパーサと、実行可能なコンパイル済みプログラム・ステートメントを含むビジネス・ロジック・モジュールより構成されるビジネス・ロジック・アプリケーション・プログラムとを備え、パーサは、仕様言語ファイルからパーサによって抽出されたメッセージを処理するために、ビジネス・ロジック・モジュールのうちの少なくとも１つを呼び出す。【選択図】図１
2008140390.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサと、メモリと、ハード・ドライブとを有するビジネス用コンピュータ・システムの動作を制御するためのシステムであって、前記システムが、
ハード・ドライブ上に格納された仕様言語ファイルであって、前記ファイルがコンピュータ・システムの状態マシンの実施を定義する仕様言語ステートメントを含む仕様言語ファイルと、
前記仕様言語ファイルから仕様言語ステートメントを抽出するため、および前記抽出された仕様言語ステートメントを解釈するためのパーサと、
ビジネス・ロジック・モジュールより構成されるビジネス・ロジック・アプリケーション・プログラムであって、前記ビジネス・ロジック・モジュールが、実行可能なコンパイル済みプログラム・ステートメントを含むビジネス・ロジック・アプリケーション・プログラムとを備え、
前記パーサが、前記仕様言語ファイルから前記パーサによって抽出されたメッセージを処理するために、前記ビジネス・ロジック・モジュールのうちの少なくとも１つを呼び出すコンピュータ・システム。
【請求項２】
前記パーサが、
前記仕様言語ステートメント内の式タグを特定するため、および前記特定された式タグに従って、対応するタグ間の前記仕様言語ステートメントを解釈するための式インタプリタと、
ビジネス・ロジック・モジュールを呼び出すためのメソッド・インボーカであって、前記仕様言語ファイルから前記パーサによって抽出されたメッセージを使用して前記ビジネス・ロジック・モジュール呼び出しをサポートするインボーカとを備える、請求項１に記載のコンピュータ・システム。
【請求項３】
前記ビジネス・ロジック・モジュールがプログラミング言語オブジェクトである、請求項１に記載のコンピュータ・システム。
【請求項４】
複数の仕様ファイルであって、各ファイルがビジネス・システムの状態マシン実施を定義する仕様言語ステートメントを含む複数の仕様ファイルをさらに備え、
前記パーサが、現在解析されている前記仕様ファイルを識別するフォーカス変数を維持する、請求項１に記載のコンピュータ・システム。
【請求項５】
前記仕様言語ステートメントが、拡張可能マークアップ言語（ＸＭＬ）ステートメントで記述される、請求項１に記載のコンピュータ・システム。
【請求項６】
前記パーサが、前記コンピュータ・システムのプロセッサによって実行されるアプリケーション・プログラムである、請求項１に記載のコンピュータ・システム。
【請求項７】
前記ビジネス・ロジック・モジュールがプログラミング言語オブジェクトである、請求項１に記載のコンピュータ・システム。
【請求項８】
前記プログラミング言語オブジェクトが、Ｃ＋＋オブジェクトおよびＪａｖａオブジェクトのうちの１つである、請求項７に記載のコンピュータ・システム。
【請求項９】
状態マシンを生成するため、ならびに、ＪａｖａクラスおよびＣ＋＋オブジェクトのうちの１つで実施されるアクションを呼び出すためのＪａｖａアプリケーションにおけるＪａｖａサポート・インタフェースをさらに備える、請求項２に記載のコンピュータ・システム。
【請求項１０】
前記パーサが、メッセージを処理するためのメソッドを有さずに解析される前記仕様言語ファイル内の前記仕様言語ステートメントによって定義される前記状態マシン実施に応答してフォーカス状態を変更する、請求項４に記載のコンピュータ・システム。
【請求項１１】
プロセッサと、メモリと、ハード・ドライブとを有するビジネス用コンピュータ・システムの動作を制御するための方法であって、
仕様言語ステートメントを使用して、コンピュータ・システムの状態マシン実施を定義するステップと、
前記コンピュータ・システムを実施するために前記仕様言語ステートメントを解釈するステップと、
解釈された仕様言語ステートメントからパーサによって抽出されたメッセージを処理するために、実行可能なコンパイル済みプログラム・ステートメントを含むビジネス・ロジック・モジュールを呼び出すステップとを含むコンピュータ・システムの動作制御方法。
【請求項１２】
仕様言語ステートメントを解釈する前記ステップが、
前記仕様言語ステートメント内の式タグを特定するステップと、
前記特定された式タグに従って、対応するタグ間の前記仕様言語ステートメントを解釈するステップと、
前記仕様言語ステートメントから抽出されたメッセージを使用して、ビジネス・ロジック・モジュールを呼び出すステップとをさらに含む、請求項１１に記載のコンピュータ・システムの動作制御方法。
【請求項１３】
ビジネス・ロジック・モジュールを呼び出す前記ステップが、
プログラミング言語オブジェクト内のメソッドを呼び出すステップをさらに含む、請求項１１に記載のコンピュータ・システムの動作制御方法。
【請求項１４】
複数の仕様言語ファイルをクラスタ化するステップであって、各仕様言語ファイルが、ビジネス・システムの状態マシン実施を定義する仕様言語ステートメントを含むステップと、
現在解析されている前記複数の仕様言語ファイル内の前記仕様ファイルを識別するために、フォーカス変数を維持するステップとをさらに含む、請求項１１に記載のコンピュータ・システムの動作制御方法。
【請求項１５】
仕様言語ステートメントを解釈する前記ステップが、
拡張可能マークアップ言語（ＸＭＬ）ステートメントを解釈するステップをさらに含む、請求項１１に記載のコンピュータ・システムの動作制御方法。
【請求項１６】
前記仕様言語ステートメント解釈ステップが、
前記ビジネス・システムのプロセッサを使用してアプリケーション・プログラムを実行するステップを含む、請求項１１に記載のコンピュータ・システムの動作制御方法。
【請求項１７】
ビジネス・ロジック・モジュールを呼び出す前記ステップが、
プログラミング言語オブジェクトを呼び出すステップを含む、請求項１１に記載の方法。
【請求項１８】
プログラミング言語オブジェクトを呼び出す前記ステップが、Ｃ＋＋オブジェクトおよびＪａｖａオブジェクトのうちの１つを呼び出すステップを含む、請求項１７に記載のコンピュータ・システムの動作制御方法。
【請求項１９】
状態マシン実施の定義に含まれるＪａｖａサポート・インタフェースを通してＪａｖａアクション・クラスを呼び出すステップをさらに含む、請求項１２に記載のコンピュータ・システムの動作制御方法。
【請求項２０】
メッセージを処理するためのメソッドを有さずに解析されている前記仕様言語ファイル内の前記仕様言語ステートメントによって定義される前記状態マシン実施に応答して、前記フォーカス変数の状態を変更するステップをさらに含む、請求項１４に記載のコンピュータ・システムの動作制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンピュータで実施されるビジネス用コンピュータ・システムに関し、特に、販売時点でビジネス・トランザクションを処理するためにコンピュータで実施されるコンピュータ・システムに関する。
【背景技術】
【０００２】
ビジネス用コンピュータ・システム（以下、適宜「ビジネス・システム」という）は、ビジネス・トランザクションまたは機能を容易にするようにプログラミングされたコンピュータ・システムとして記述することができる。例えば、コンピュータは、ユーザからの入力を受け入れるように、およびトランザクションの明細を明らかにし、トランザクション・イベントのログを報告するために、特定の環境でイベントが発生した場合にそれらを検出するように、プログラミングすることができる。管理者がこれらの報告を使用して、業務に関する情報を引き出すか、または効率を向上させるためにビジネスの様々な面を修正することができる。例えば、在庫管理システムは、トランザクションの検証、製品が在庫に入庫された場合のこれの記録、および在庫から製品が出庫された時点での製品累積の更新のためにプログラミングされたコンピュータで構成することができる。これらのトランザクションに使用されるデータは、キーボードを通して、またはバーコード・リーダなどを通して、入力することができる。その後このシステムは、現在の在庫レベルおよび発生したトランザクションのボリューム・レベルを管理者に報告するために、１つまたは複数の報告を生成することができる。
【０００３】
一般的に遭遇する他のビジネス・システムは、通常、小売店の販売時点場所で使用されるチェックアウト・ステーションである。これらの販売時点（ＰＯＳ）ステーションは、単純な電子キャッシュ・レジスタとするか、または複雑なセルフ・チェックアウト・ステーションとすることができる。より複雑なＰＯＳシステムには、オペレータからのコマンド入力のためのキーパッド、バーコードの読み取りおよびアイテムの計量のためのセンサ、ならびに、それぞれデータの読み取りおよび格納ならびにリモート・サイトへのデータの通信のためのデータベースおよび通信機器が含まれる。これらのＰＯＳシステムは周知のものである。これらのＰＯＳステーションでは、購入物品は識別可能なようにスキャンされる。端末は、中央リポジトリから価格を取り出し、より柔軟な物品の価格付けをサポートすることができる。すべての購入アイテムがＰＯＳ端末に提示されると、小計が累積され、税金または値引きがあれば計算され、合計支払い金額が消費者に表示される。ＰＯＳ端末またはステーションは、トランザクションに関する支払いを処理するための、キャッシュ・レジスタ機能、クレジットまたはデビット・カード・リーダ、あるいはスマート・カード・インタフェースも含むことができる。提示された支払いが確認されると、物品は消費者に引き渡される。販売が完了すると、ステーションは在庫管理システムと通信し、販売されたアイテムについて在庫を更新することができる。
【０００４】
ＰＯＳチェックアウト・ステーションは、通常、端末と、単価コード（ＵＰＣ：Ｕｎｉｔ  Ｐｒｉｃｅ  Ｃｏｄｅ）を読み取るためおよび物品の重量を決定するためのスキャナ／秤と、レジ係のキーパッドおよびディスプレイと、支払い入力のためのＰＯＳ端末と、レシート・プリンタと、つり銭ユニットと、いったんスキャンされた物品を保持するためのチェックアウト領域とを含む。ＰＯＳ端末は、また、ディスプレイと、プロセッサと、メモリと、プログラム済み命令と、ステーションの動作を制御するためのデータ周辺装置とを含む。プログラム済み命令は、物品の価格に関してデータベースを照会し、合計を算出し、チェックアウト・ステーションを通じて物品の購入に関する他の機能を実行するモジュールを含むことができる。一部のチェックアウト・ステーションは、また、チェックアウト時に不正な物品の差し替えが発生する確率を減らすために、秤および／またはカメラなどのセンサからのデータを使用するセキュリティ・アプリケーション・プログラムを含むこともできる。
【０００５】
チェックアウト・ステーションは、多くの異なる企業によって製造される。ＰＯＳシステムの動作は一般に似ているが、各製造業者は、異なる方法でトランザクションを実行するプログラム・コードを実施する。例えば、キーパッドのキーによって生成されるコードまたはセンサ・システムとのインタフェースは、製造業者によってわずかに異なる方法で実施することができる。したがって、ＰＯＳシステムの１つまたは複数のプロセッサによって実行されるプログラミングは、製造業者によって異なる。
【０００６】
ほとんどの製造業者は、チェックアウト・ステーションに必要なすべての機能を実施する１つの単一プログラムを有するのではなく、何らかのタイプのモジュラ・プログラミングを備えるＰＯＳシステム・コントローラを実施する。モジュラ・プログラミングでは、ＰＯＳシステムによって実施されるビジネス・ロジックがサブ機能にセグメント化される。これらのサブ機能は、離散プログラミング・オブジェクトまたはモジュールとして実施される。これらのモジュールまたはオブジェクトには、オブジェクトまたはモジュールが出力を生成するために処理する入力データが提供される。このプログラミングのためのモジュラ方式を使用して、コンピュータ・プログラムの保守を容易にし、システムの機能を区分化して、新しい機能をより簡単に組み込めるように修正する。
【０００７】
上記モジュールおよびオブジェクトは、プログラムの保守および適合性を容易にする一方で、通常は、トランザクションまたは他のビジネス・プロセスを実施するために階層構造に結合される。モジュールを互いに結合するために使用される階層および制御論理は、プログラミング言語でも実施される。制御論理および階層を実施するプログラミング・ステートメントは、ＰＯＳシステム用のフレームワークを形成する。これらのプログラム・ステートメントは、ＰＯＳシステムの種々のサブ機能を実施するために使用されるプログラム・オブジェクトおよびモジュールの実行を制御するために、コンパイルされ、コンピュータ上にインストールされる。このようにＰＯＳシステムのすべての制御論理を実施することは、モジュラ・プログラミングの原理に反する。トランザクションを処理するために制御論理を変更しなければならない場合、ＰＯＳシステムを実施するコンピュータ上で、ビジネス・ロジックに関するプログラミング・ステートメントを改訂、再コンパイル、および再インストールしなければならない。さらに、プログラミング論理が実行される製造業者のプラットフォームと互換性のある方法で、この変更を再プログラミングしなければならない。すなわち、ビジネス・ロジックは、製造業者のサブ機能の実施と互換性のある方法で修正しなければならない。したがって、ＰＯＳシステムに関するビジネス・ロジックを実行する制御論理の修正には、システム向けのハードウェア環境およびシステムの実施に使用されるプログラミング言語に十分注意を払う必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
システムは、実行可能なコンピュータ論理を再コンパイルする必要なしに柔軟性を提供するような形で、プロセッサと、メモリと、ハード・ドライブとを有するビジネス・システムの動作を制御する。このシステムは、ビジネス・システムの状態マシンの実施を定義する仕様言語ステートメントを含むハード・ドライブ上に格納された仕様言語ファイルと、仕様言語ファイルから仕様言語ステートメントを抽出するため、および抽出された仕様言語ステートメントを解釈するためのパーサと、実行可能なコンパイル済みプログラム・ステートメントを含むビジネス・ロジック・モジュールより構成されるビジネス・ロジック・アプリケーション・プログラムとを備え、パーサは、仕様言語ファイルからパーサによって抽出されたメッセージを処理するために、ビジネス・ロジック・モジュールのうちの少なくとも１つを呼び出す。
【課題を解決するための手段】
【０００９】
上記システムによって実施可能な方法は、実行可能なコンピュータ論理を再コンパイルする必要なしに柔軟性を提供する形で、ビジネス・システムの動作を制御する。この方法は、仕様言語ステートメントを使用してビジネス・システムの状態マシンの実施を定義するステップと、ビジネス・システムを実施するために仕様言語ステートメントを解釈するステップと、解釈された仕様言語ステートメントからパーサによって抽出されたメッセージを処理するために、実行可能なコンパイル済みプログラム・ステートメントを含むビジネス・ロジック・モジュールを呼び出すステップとを含む。
【００１０】
本明細書で説明するシステムおよび方法の利点および特徴は、添付の図面および以下の詳細な説明を再検討することから明確に理解することができる。
【００１１】
本開示に記載されたシステムおよび方法は、種々の構成要素および構成要素の配置構成ならびに種々の方法の形を取ることができる。図面は、例示的実施形態および代替実施形態を示すことのみを目的とし、本発明を制限するものとして解釈されるべきではない。
【発明を実施するための最良の形態】
【００１２】
図１に、本発明の原理に従って修正することが可能なチェックアウト・ステーションを示す。チェックアウト・ステーション１０は、フィーダ・ユニット１４と、チェックスタンド１８とを含むことができる。フィーダ・ユニット１４は、フィーダ・ベルト２０と、フィーダ・ベルト２０を動作させるモータおよび制御回路用のハウジング２２とを含む。フィーダ・ユニット１４は、フィーダ・ベルトがスキャナ／秤ユニット２６と位置合わせ可能なように、チェックスタンド１８と可動的に結合される。チェックスタンド１８は、スキャナ／秤ユニット２６と、消費者端末３４と、支払いデータ入力用の支払い端末３８と、レシート・プリンタ４４とを含む。スキャナ／秤ユニット２６は、ガラスまたは他の透明なプラテン上で光るレーザを使用して、製品またはパッケージに貼付されたバーコードからのデータを入力する。ユニット２６は、また、重量ベースの価格／単位で販売される物品の重量を測定するための秤を含むことができる。消費者端末３４は、スキャナ／秤ユニット２６を通して入力された物品のデータを表示する。支払い端末３８は、クレジット・カード、デビット・カード、および他の支払い方法をサポートするためのカード・リーダ３２を組み込む任意の周知のＰＯＳ端末とすることができる。レシート・プリンタ４４は、購入した物品および支払いの方法を箇条書きにしたレシートを消費者に提供する。
【００１３】
レシート・プリンタ４４およびスキャナ／秤ユニット２６は、その床面としてセキュリティ秤４８を有するバッグ受け台４６によって分離することができる。消費者がスキャンおよび計量した物品を格納するためのバッグは、バッグ受け台４６内の吊りレール５０から吊り下げられる。セキュリティ秤４８は、スキャナ／秤２６から導出された物品の重量データ、またはスキャン済みの単位製品コード（ＵＰＣ：Ｕｎｉｔ  Ｐｒｏｄｕｃｔ  Ｃｏｄｅ）を使用するデータベースを使用して、スキャン済みの物品のみがセキュリティ秤上に置かれていることを検証する。端末３４内で動作するセキュリティ・アプリケーション・プログラムは、スキャンされていない物品がセキュリティ秤領域に追加されていないかどうかを判別するために、セキュリティ秤４８を監視する。チェックスタンド１８のインジケータ・ポール５２の終端に取り付けられた３色インジケータ内で、警告または警報色光を光らせることによって、検査を必要とする特異な条件を信号によって示すことができる。チェックスタンド領域に対応するビデオ・データを生成するために、インジケータ・ポール５２上にセキュリティ・カメラ５６を取り付けることができる。データベース、ディスク・ドライブ、またはステーションの動作に必要な他のコンピュータ周辺機器を、チェックスタンド１８内に配置された周辺トレイ６０内に収容することができる。チェックスタンド１８は、また、トランザクションに関する支払いとして、消費者から貨幣または硬貨を受け取るための上部貨幣モジュール４０を含む。モジュール４０は、また、消費者のつり銭のうちの硬貨部分を返却する硬貨支払機３６を含む一方で、下部貨幣モジュール４２は、消費者のつり銭のうちの紙幣部分を返却する。モジュール４０は、また、消費者に支払われるつり銭の中に、消費者から受け取った現金を提供するための現金リサイクル・ユニット（図示せず）も含むことができる。
【００１４】
図１に示すように、消費者は、フィーダ・ベルト２０上に物品を置くことが可能であり、ベルト２０が駆動して物品をベルト２０の端部まで運び、ここでシャットオフ機構がベルト２０を停止させる。次に消費者は、ベルト２０から物品を１つずつ取り除き、製品データの検索および／または計量のためにスキャナ／秤２６上を移動させる。別の方法として、消費者は、購入用の物品が入ったカートをフィーダ・ユニット２２に隣接するように引き寄せ、カートからスキャナ／秤２６上へ物品を置くこともできる。次に、スキャン済みの物品をセキュリティ秤４８上のバッグに入れることができる。すべての物品がスキャンされると、消費者は支払い端末３８または貨幣モジュール４０を通して支払いを行い、モジュール４４からのつり銭とプリンタ４４からのレシートを受け取ることができる。次に消費者は、セキュリティ秤４８からバッグを取り外し、ステーション１０を離れることができる。このチェックアウト・ステーション１０の動作は、通常は、端末３４に組み込まれたプロセッサによって制御される。
【００１５】
ビジネス・ロジック・システムの状態マシン実施を動作させるために使用可能なシステムを示すブロック図が図２に示されている。システム１００は、ハード・ドライブ上に格納可能な状態マシン定義１０４と、状態マシン定義１０４から仕様言語ステートメントを抽出するため、および抽出された仕様言語ステートメントを解釈するためのパーサ１０８と、ビジネス・ロジック・モジュールより構成されるビジネス・ロジック・アプリケーション・プログラム１１０とを含む。ビジネス・ロジック・モジュールは、より詳細に以下で説明するアクションとして示すことが可能な、実行可能なコンパイル済みプログラム・ステートメントを含む。パーサは、状態マシン定義の仕様言語ステートメントからパーサによって抽出されたメッセージを処理するために、ビジネス・アプリケーション・プログラム１１０のビジネス・ロジック・モジュールを呼び出す。仕様言語ステートメントは、好ましくは仕様言語ファイル内に含まれる。これらのステートメントは、ビジネス・システムの状態マシン実施を定義する。
【００１６】
より詳細には、以下でより詳細に説明するチェックアウト・ステーションなどのビジネス・システムに関する仕様言語定義は、チェックアウト・ステーション用の販売時点（ＰＯＳ）システムの製造業者によって提供されるデータ・リンク・ライブラリ（ＤＬＬ）を使用する。仕様言語ステートメントによって定義される状態マシン実施は、ＤＬＬに含まれるビジネス・ロジック・モジュールを使用して、チェックアウト・ステーションを動作させる。これらのモジュールは、チェックアウト・ステーションの製造業者によって開発されたコンパイル済みの実行可能コンピュータ・コードである。これらのモジュールは、バーコードの読み取り、販売トランザクションの累積および合計、商品の計量、支払いの処理、およびレシートの発行などのシステムの動作を実施する。これらの機能をチェックアウト・システムに編成するビジネス・ロジックは、仕様言語ステートメントによって定義される状態マシン実施に従って実行される。状態マシン実施は、また、他の仕様言語文書および／またはカスタマイズされたＤＬＬによって補足することもできる。
【００１７】
システム初期設定が実行されると、以下でより詳細に説明するように、パーサは、仕様言語ファイルからの仕様言語ステートメントの抽出を開始する。抽出された仕様言語ステートメントは、パーサによって解釈される。この解釈は、以下でより詳細に説明するように、それらのタグによる仕様言語ステートメントの識別、および解釈された仕様言語ステートメントで識別されたビジネス・ロジック・モジュールへの呼び出しの起動を含む。以下でより詳細に説明するように、これらのビジネス・ロジック・モジュールは、プログラミング言語オブジェクトによって実施することができる。オブジェクトはメソッドを含むことが可能であり、これらのメソッドは、仕様言語ステートメントから抽出されたメッセージなどのデータを処理するために、パーサによって呼び出される。これらのオブジェクトは、システムを動作させるためのビジネス・ロジックの最小単位である、アクションを実施するために使用される。したがって、仕様言語ファイルは、チェックアウト・ステーションの動作に必要なビジネス・ロジックを定義するためのフレームワークを提供し、ＤＬＬのモジュールまたはオブジェクトは、ビジネス・ロジックを実施するために必要な実行可能コンピュータ・コードを提供する。この構造によって、チェックアウト・ステーションの動作ならびに保守の修正が容易になる。より詳細には、チェックアウト・ステーションの動作は、コンピュータ内の実行可能コードを再コンパイルおよびインストールする必要なしに、仕様言語ステートメントを変更するだけで修正することができる。
【００１８】
次に、チェックアウト・ステーションの実施についてより詳細に説明する。この実施では、チェックアウト・ステーションの動作を制御するための状態マシンの生成および状態マシンの初期設定について説明する。次に、仕様言語ステートメントを式に編成することを含む仕様言語ステートメントの構造に関する詳細が提供される。これらの式は、仕様言語ステートメント内の式タグ（ｅｘｐｒｅｓｓｉｏｎ  ｔａｇ）を特定するため、および特定された式タグに従って、対応するタグ間の仕様言語ステートメントを解釈するために、パーサ内に組み込まれた式インタプリタ（ｅｘｐｒｅｓｓｉｏｎ  ｉｎｔｅｒｐｒｅｔｅｒ）によって解釈することができる。ビジネス・ロジック・モジュールを呼び出して仕様言語ファイルから抽出されたメッセージを処理するために、メソッド・インボーカをパーサに組み込むこともできる。チェックアウト・ステーションに対して実施されるアクションに関する詳細について説明する。状態マシン実施のデバッグ、アクションを実施するクラスに対するＪＡＶＡサポートの提供、およびビジネス・システムの動作を増大するための状態マシン実施のクラスタ化に関する追加の特徴についても説明する。
【００１９】
ビジネス・システムを動作させるために、状態マシンのインスタンスが生成される。状態マシンのインスタンスを生成するために、ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙオブジェクトの静的ファクトリ・メソッドＢｕｉｌｄＳｔａｔｅＭａｃｈｉｎｅを、パラメータのリストと共に呼び出すことができる。ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙオブジェクトは、チェックアウト・ステーションなどのビジネス・システム・プラットフォームの製造業者によって提供されるプログラミング言語オブジェクトである。メソッド呼び出し用のパラメータには、状態マシンの固有名、状態マシン定義を含むｕｎｉｖｅｒｓａｌ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｅｒ（ＵＲＬ）、ライブラリ名、およびディレクトリ・パスが含まれる。状態マシン定義は、状態マシンに関するデータ値および規則セットを生成するために使用される。ライブラリ名は、好ましくは、状態マシンのインスタンスを戻す実際のファクトリ・メソッドを含む。ディレクトリ・パスは、状態マシンの生成時にファクトリによってロードされるすべてのファイルを含む。ＢｕｉｌｄＳｔａｔｅＭａｃｈｉｎｅメソッドをＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙオブジェクトから戻すことによって、初期設定を必要とする完全に機能する状態マシンが提供される。
【００２０】
状態マシンの生成時に、ファクトリ・オブジェクトは、ＣＳＭＬｏａｄｅｒなどのローダ・クラスのインスタンスまたはその派生物のうちの１つを使用して、状態マシンのインスタンスをロードする。このクラスは、ＳＡＸパーサ実施を使用して、仕様言語を式などの適切なデータ構造に解析する。以下でより詳細に説明するように、好ましい仕様言語ファイルはＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ：拡張可能マークアップ言語）で記述される。ＳＡＸパーサを使用して、状態マシンを動作させるために状態マシン定義ファイルのＸＭＬを解析する。ＣＣｏｎｔｅｎｔＨａｎｄｌｅｒなどのコンテンツ・ハンドラ・クラスの実施によって、個々のタグが処理される。構築時に、各タグとその対応するハンドラ・クラスとを関連付けるマップが生成される。このマッピングは、ＸＰａｔｈ式をキーとして使用することによって達成される。ＸＰａｔｈ式は、停止タグが検出されるまで、フォワードスラッシュ記号「／」文字をタグ名と連結させることによって構築される。その後、タグ名およびその関連するフォワードスラッシュ文字は、最後の停止タグに達するまで除去される。
【００２１】
ＳＡＸパーサは、仕様言語ファイルを解析する場合、ステートメントの構造の妥当性を検査する。例示的なＸＭＬ仕様ファイルで遭遇する可能性のあるステートメント構造については、以下でより詳細に説明する。構造の妥当性検査中に検出されるいかなるエラーも、エラー・ログで報告される。エラー・ログに含まれるエラー・メッセージを生成するハンドラは、（１）状態、メッセージ、アクション、定数、タイマ、または変数の重複定義、（２）定義されていない状態、メッセージ、アクション、定数、タイマ、または変数、（３）状態、メッセージ、アクション、定数、タイマ、または変数の無効な名前、および（４）矛盾するタグ・オプションを検出する。
【００２２】
仕様言語ファイルによって定義される状態マシン実施は、カスタマイズ済みＤＬＬを含むことができる。状態マシンのファクトリ実施は、それぞれがオプションで提供可能ないくつかのエントリ・ポイントについて、これらのＤＬＬを検索する。ファクトリ・オブジェクトは、ＤＬＬによって定義されていないエントリ・ポイントがあれば、これに対してデフォルトの実施を使用する。これらのエントリ・ポイントは、以下で説明するように、「Ｃ」スタイルのエントリ・ポイントとすることができる。これらのエントリ・ポイントは、（１）サポートされるアクション名の登録／登録解除、（２）状態マシン・インスタンスの生成／破棄、および（３）任意の必要なプラグイン・オブジェクトの生成／破棄に対するサポートを提供する。アクションの生成／破棄をサポートするために、テンプレート・メソッドを使用することもできる。以下のエントリ・ポイントが提供可能である。
【００２３】
【表１】
2008140390.tif 000003
【００２４】
アクション登録／登録解除における第１のエントリ・ポイントは、このライブラリによってサポートされるすべてのアクションの名前リストを戻す。これは、ライブラリが生成される場合、初期設定時に１回呼び出される。エントリ・ポイントの署名は次のとおりである。
HRESULT__declspec(dllexport)RegisterAll(const_TCHAR***,HTRACE).
この呼び出しの第１のパラメータは、名前アレイへのポインタのアドレスである。このアレイは、呼び出しによって戻され、解放されてはならない。第２のパラメータは、Ｔｒａｃｅオブジェクトへのハンドルである。状態マシンが破棄プロセス中である場合、名前は解放される。これを容易にするために、状態マシンは以下のエントリ・ポイントを呼び出す。
void__declspec(dllexport)UnregisterAll().
これでわかるように、このエントリ・ポイントはいかなるパラメータも取らず、何の値も戻さない。
【００２５】
状態マシン・ファクトリ作成／破壊カテゴリ内の第１のエントリ・ポイントは、ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙのインスタンスへのポインタを戻す。これは、ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙによって初期設定時に１回呼び出される。エントリ・ポイントの署名は次のとおりである。
HRESULT__declspec(dllexport)BuildStateMachineFactory(HTRACE
hTrace,STATE_MACHINE_NAMESPACE::CStateMachineFactory**).
このメソッドは、２つのパラメータ、すなわちＴｒａｃｅオブジェクトへのハンドルと、新しく構築されたファクトリ状態マシンへの戻されたポインタのアドレスを取る。生成中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。このカテゴリ内の第２のエントリ・ポイントは、終了時に状態マシン・ファクトリを解放するために使用される。その署名は次のとおりである。
HRESULT__declspec(dllexport)ReleaseStateMachineFactory(HTRACE
hTrace,STATE_MACHINE_NAMESPACE::CStateMachineFactory*).
このメソッドは、２つのパラメータ、すなわちＴｒａｃｅオブジェクトへのハンドルと、破壊される状態マシン・ファクトリへのポインタを取る。破壊中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。これらのオプション・メソッドが宣言されない場合、ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙのデフォルト・インスタンスが生成される。
【００２６】
状態マシン・ローダ作成／破壊カテゴリ内の第１のエントリ・ポイントは、ＣＳＭＬｏａｄｅｒのインスタンスへのポインタを戻す。これは、ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙによって、要求された状態マシン・インスタンスの構築および初期設定に使用される。エントリ・ポイントの署名は次のとおりである。
HRESULT__declspec(dllexport)BuildStateMachineLoader(HTRACE
hTrace,STATE_MACHINE_NAMESPACE::CSMLoader**).
このメソッドは、２つのパラメータ、すなわちＴｒａｃｅオブジェクトへのハンドルと、新しく構築されたＣＳＭＬｏａｄｅｒへの戻されたポインタのアドレスを取る。生成中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。このカテゴリ内の第２のエントリ・ポイントは、終了時に状態マシン・ローダを解放するために使用される。その署名は次のとおりである。
HRESULT__declspec(dllexport)ReleaseStateMachineLoader(HTRACE
hTrace,STATE_MACHINE_NAMESPACE::CSMLoader*).
このメソッドは、２つのパラメータ、すなわちＴｒａｃｅオブジェクトへのハンドルと、破壊される状態マシン・ローダへのポインタを取る。破壊中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。これらのオプション・メソッドが宣言されない場合、ＣＳＭＬｏａｄｅｒのデフォルト・インスタンスが生成される。
【００２７】
状態マシン作成／破壊カテゴリ内の第１のエントリ・ポイントは、状態マシンのインスタンスへのポインタを戻す。これは、ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙによって初期設定時に１回呼び出される。エントリ・ポイントの署名は次のとおりである。
HRESULT__declspec(dllexport)BuildStateMachine(const_TCHAR*HTRACE
hTrace STATE_MACHINE_NAMESPACE::IStateMachine**)
【００２８】
このメソッドは、ＸＭＬファイルのＵＲＬと、Ｔｒａｃｅオブジェクトへのハンドルと、新しく構築された状態マシンへの戻されたポインタのアドレスの３つのパラメータを取る。生成中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。このカテゴリ内の第２のエントリ・ポイントは、終了時に状態マシンを解放するために使用される。その署名は次のとおりである。
HRESULT__declspec(dllexport)ReleaseStateMachine(HTRACE
hTrace,STATE_MACHINE_NAMESPACE::IStateMachine*).
このメソッドは、Ｔｒａｃｅオブジェクトへのハンドルと、破壊される状態マシンへのポインタの２つのパラメータを取る。破壊中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。
【００２９】
クラスタ生成／破壊カテゴリ内の第１のエントリ・ポイントは、２つ以上の協働する状態マシンからなる状態マシンのインスタンスへのポインタを戻す。これは、ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙによって初期設定時に１回呼び出される。エントリ・ポイントの署名は、HRESULT__declspec(dllexport)BuildCluster(const_TCHAR*HTRACE
hTrace,STATE_MACHINE_NAMESPACE::CCluster**)である。
【００３０】
このメソッドは、ＸＭＬファイルのＵＲＬと、Ｔｒａｃｅオブジェクトへのハンドルと、新しく構築された状態マシン・クラスタへの戻されたポインタのアドレスの３つのパラメータを取る。構築中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。このカテゴリ内の第２のエントリ・ポイントは、終了時に状態マシンを解放するために使用される。その署名は、HRESULT __declspec(dllexport)ReleaseCluster(HTRACE
hTrace,STATE_MACHINE_NAMESPACE::CCluster*)である。このメソッドは、Ｔｒａｃｅオブジェクトへのハンドルと、破壊される状態マシン・クラスタへのポインタの２つのパラメータを取る。破壊中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。
【００３１】
プラグイン作成／破壊カテゴリ内の第１のエントリ・ポイントは、新しいタグを使用して状態マシン定義言語を拡張するための機構を提供する、ファクトリ・オブジェクトのインスタンスへのポインタを戻す。これは、ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙによって初期設定時に１回呼び出される。エントリ・ポイントの署名は、HRESULT__declspec(dllexport)GetPlugin(const_TCHAR*,IPlugin**,HTRACE)である。このメソッドは、プラグインの記号名と、新しく構築されたＩＰｌｕｇｉｎオブジェクトへの戻されたポインタのアドレスと、Ｔｒａｃｅオブジェクトへのハンドルの３つのパラメータを取る。構築中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。このカテゴリ内の第２のエントリ・ポイントは、終了時にｐｌｕｇｉｎオブジェクトを解放するために使用される。その署名は、HRESULT__declspec(dllexport)ReleasePlugin(IPlugin*,HTRACE)である。このメソッドは、破壊されるＩＰｌｕｇｉｎへのポインタと、Ｔｒａｃｅオブジェクトへのハンドルの２つのパラメータを取る。破壊中にエラーが発生しなかった場合、エントリ・ポイントは、Ｓ＿ＯＫを戻す。他のいかなる値もエラーである。
【００３２】
ＤＬＬで公開された各アクションに対して、２つのアクション・ファクトリ・メソッド・エントリ・ポイントがある。このカテゴリ内のどちらのエントリ・ポイントも、アクションそれ自体と同じファイルに含まれる登録マクロによって生成されるべきである。例えば、状態マシン内にはＣＳｅｎｄＭｓｇと呼ばれるアクションがある。ｓｅｎｄｍｓｇ．ｃｐｐファイルの底部には、コードREGISTER_SM_ACTION(SendMsg)が常駐する。マクロＲＥＧＩＳＴＥＲ＿ＳＭ＿ＡＣＴＩＯＮそれ自体が、ファイルＡｃｔｉｏｎＢａｓｅ．ｈ内に以下のように定義されている。
#define SM_REGISTRATION_PREFIXSM.
#define REGISTER_SM_ACTION(NAME)＼
DECLARE_CLASS_CREATION_DESTRUCTION(NAME)＼
DECLARE_REGISTRATION_CLASS(SM_REGISTRATION_PREFIX,NAME)＼
DEFINE_REGISTRATION(NAME)
これらのマクロは、アクションに必要なエントリ・ポイントを自動的に生成し、それらをＣＲｅｇｉｓｔｒａｔｉｏｎＭａｎａｇｅｒに公開する。状態マシンの各構成要素ユーザは、一意の登録マクロおよび登録プレフィックスを作成し、そのマクロをＤＬＬ内に定義されたすべてのアクションに使用する。
【００３３】
このカテゴリ内の第１のエントリ・ポイントは、新しく作成されたタイプＴのアクションのインスタンスへのポインタを戻す。このエントリ・ポイントは、静的テンプレート・メンバ関数である。これは、アクションを生成するためにＣＸＭＬＳｔａｔｅＭａｃｈｉｎｅファクトリによって呼び出される。エントリ・ポイントの署名は次のとおりである。
IAction*CCreateable<T,IAction>::NewInstance()
このカテゴリ内の第２のエントリ・ポイントは、上記エントリ・ポイントによって生成されたアクションを解放するために使用される。この署名は次のとおりである。
void CCreateable<T,IAction>::ReleaseInstance(IAction*)
このメソッドは、パラメータとして、解放するためのアクションのアドレスを取る。
【００３４】
ＢｕｉｌｄＳｔａｔｅＭａｃｈｉｎｅメソッドを戻すと、戻された状態マシンのインスタンスの開始メソッドを呼び出すことによって、初期設定が完了する。このメソッドは、状態マシンを実行するために使用される新しいワーカー・スレッド・パラメータで呼び出される。すべての状態マシン・アクションは、このワーカー・スレッドを使用して実行される。
【００３５】
状態マシンはメッセージを処理し、規則を実行する。メッセージの処理は、非同期または同期のいずれかとすることができる。メッセージ処理および規則セットの実行は、状態マシン要素によって実行される。次に、メッセージ処理、規則セット実行、およびこれらのタスクを実行するための状態マシン要素について、より詳細に説明する。
【００３６】
状態マシンは、メッセージの受け入れ、およびそれに応答する規則セットの実行によって動作する。ＳｔａｔｅＭａｃｈｉｎｅの実行は、非同期動作の場合はＰｏｓｔＭｓｇメソッド、または同期動作の場合はＳｅｎｄＭｓｇメソッドのいずれかを使用して、メッセージをＣＳｙｎｃｈｒｏｎｉｚｅｄＱｕｅｕｅに配置することによって調整される。非同期動作の場合、ＰｏｓｔＭｓｇは戻りコードを待たない。同期動作の場合、ＳｅｎｄＭｓｇメソッドは、そのメッセージに関する最後のアクションが処理されるまで待機し、規則セットによって設定された何らかの戻りコードを戻す。ワーカー・スレッドは、ＣＳｙｎｃｈｒｏｎｉｚｅｄＱｕｅｕｅからメッセージを除去し、グローバル状態にそのメッセージに関する規則セットが存在するか否かを判別する。メッセージに関する規則セットが存在する場合、その規則セットが最初に実行される。この規則セットは、現在の状態から遷移しない場合がある。
【００３７】
次にワーカー・スレッドは、現在の状態にそのメッセージに関する規則セットが存在するか否かを判別する。存在する場合、その規則セットを実行する。存在しない場合、ワーカー・スレッドは、ＸＭＬ定義では状態名「＊」で示される、「ａｎｙ」状態と呼ばれる特別な状態にそのメッセージに関する規則セットが存在するか否かを判別する。ａｎｙ状態で規則セットが発見された場合は、これが実行される。規則セットが発見されなかった場合、メッセージは、メッセージを処理するかまたは処理しない可能性のあるデフォルト・ハンドラ・メソッドに渡される。基本状態マシン用のデフォルト・ハンドラは、メッセージが無視されたことを示すエントリをログに記録するだけである。状態マシン・クラスタ用のデフォルト・ハンドラは、メッセージの処理が可能なクラスタ内の任意の他の状態マシンにメッセージを渡す。
【００３８】
規則セットは、ゼロ以上のＩＡｃｔｉｏｎ、およびゼロ以上の他の状態への遷移からなる。ＩＡｃｔｉｏｎは、以下でより詳細に説明する状態マシン要素である。ＩＡｃｔｉｏｎが存在する場合、それらは、ＩＡｃｔｉｏｎが「偽」を戻す、ＩＡｃｔｉｏｎが例外を投げる（障害）、またはこれ以上シーケンス内にＩＡｃｔｉｏｎがない、のうちの１つが発生するまで順番に実行される。ＩＡｃｔｉｏｎが「偽」を戻した場合、規則セットは、実行される偽アクションを指定することができる。他の状態への遷移も指定することができる。例外が投げられた場合、状態マシンはこの例外を受け取り、これをログ記録し、規則セットによって指定された任意のオプション障害アクション、およびオプションで、規則セットによって指定された障害状態への遷移を実行する。シーケンス内にこれ以上ＩＡｃｔｉｏｎがない場合、規則セットはオプションで新しい状態への遷移を指定することができる。
【００３９】
非同期メッセージ処理は、状態マシンの通常モードの動作である。メッセージは、ＰｏｓｔＭｓｇメソッドを呼び出すことによって非同期にされる。ＰｏｓｔＭｓｇからの戻りは即時である。この通知されただけのメッセージは、将来何らかの時点で処理される。
【００４０】
同期メッセージ処理も提供されるが、これはデッドロックの可能性があるため、制限的に使用される。メッセージを生成するいずれのアクションも、デッドロックを発生させる可能性がある。メッセージは、ＳｅｎｄＭｓｇメソッドを呼び出すことによって同期にされる。同期メッセージがキューに追加されると、呼び出し側スレッドは待機状態に入る。状態マシンは、所与のメッセージに関するすべてのアクションが実行されると、待機スレッドを発信する。
【００４１】
状態マシンによって使用されるすべての要素は、それぞれが状態マシンの異なる面を表す抽象ベース・クラスとして実施される一連のインタフェースによって外部的に（およびＣＡｂｓｔｒａｃｔＳｔａｔｅＭａｃｈｉｎｅによって内部的に）表される。一般に、すべての外部表現は読み取り専用であり、修正用のいかなる機構も提供しない。次に、これらの要素について説明する。
【００４２】
ＩＳｔａｔｅＭａｃｈｉｎｅインタフェースは、状態マシンそれ自体を表す。これは、読み取り専用で状態マシンの様々な要素にアクセスするためのメソッド・セットを提供する。すべての実施の詳細は、このクラスのユーザに対して隠される。別段の指定がない限り、アクションは、このインタフェースを通してのみ、状態マシンにアクセスすることができる。
【００４３】
ＩＭｅｓｓａｇｅインタフェースは、実行する規則セットを決定する際に使用される状態マシンへの入力の読み取り専用表現を提供する。各ＩＭｅｓｓａｇｅは、その名前によって一意に識別される。名前は、状態マシン内の２Ｄマップに第１のキーを提供する。ＩＭａｓｓａｇｅ名は、区切り文字用にＸＭＬパーサによって使用されるものを除く、任意の文字を含むことができる。無効の文字には、「＜」、「＞」、および「＆」が含まれる。
【００４４】
ＩＳｔａｔｅインタフェースは、状態マシンが常駐可能な状態の読み取り専用表現を提供する。各ＩＳｔａｔｅは、その名前によって一意に識別される。名前は、状態マシン内の２Ｄマップに第２のキーを提供する。ＩＳｔａｔｅ名は、区切り文字用にＸＭＬパーサによって使用されるものを除く、任意の文字を含むことができる。無効の文字には、「＜」、「＞」、および「＆」が含まれる。
【００４５】
ＩＡｃｔｉｏｎインタフェースは、状態マシンへの入力に応答して実行可能な作業の最小単位、すなわちビジネス・ロジックを表す。この表現は読み取り専用である。一般に、ＩＡｃｔｉｏｎの実施は小さく、２つ以上の関数は含まない。この制約によって、他の規則セット内のＩＡｃｔｉｏｎを再使用することができる。さらに、ＩＡｃｔｉｏｎが小さくなるほど、そのデバッグおよび保守が容易になる。各ＩＡｃｔｉｏｎは、名前によって表される。この名前は、１つのＩＬｉｂｒａｒｙ内で一意である。ＩＡｃｔｉｏｎ名は、英数文字のみを含むことができる。
【００４６】
さらにアクションを区別し、名前の衝突を避けるために、アクションはネームスペース内に常駐することができる。この場合、名前は、「．」文字で分けられたネームスペース名とアクション名の２つの部分からなる。例えば、ネームスペース「ｔｂ」内で「ＳｔａｒｔＴｒａｎｓａｃｔｉｏｎ」と名付けられたアクションは、「ｔｂ．ＳｔａｒｔＴｒａｎｓａｃｔｉｏｎ」と呼ばれる。次に、ネームスペースに関する詳細を示す。
【００４７】
ＩＬｉｂｒａｒｙは、ＤＬＬの表現である。これは、状態マシンで使用されるＩＡｃｔｉｏｎセットを管理するための機能を提供する。各ＩＡｃｔｉｏｎは、動的にロードされ、必要に応じてＤＬＬから生成される。またオプションで、前述のように、状態マシンの挙動をカスタマイズするために使用される一連のエントリ・ポイントも提供することができる。
【００４８】
ＩＣｏｎｓｔａｎｔインタフェースは、ＳｔａｔｅＭａｃｈｉｎｅで使用可能な定数値の読み取り専用表現である。これは、ＩＶａｒｉａｂｌｅへの式または割り当てで使用可能である。各ＩＣｏｎｓｔａｎｔは、その名前によって一意に識別される。ＩＣｏｎｓｔａｎｔ名は、英数文字および「＿」文字の両方を含むことができる。定数に関する定義について、以下でより詳細に説明する。
【００４９】
ＳｔａｔｅＭａｃｈｉｎｅ実施により、必要に応じて使用される変数の生成が可能である。ＩＶａｒｉａｂｌｅインタフェースは、これらの変数を表す。ほとんどの他の要素とは異なり、ＩＶａｒｉａｂｌｅは読み取り専用ではなく、その値を変更することができる。各ＩＶａｒｉａｂｌｅはその名前によって一意に識別される。ＩＶａｒｉａｂｌｅ名は、英数文字および「＿」文字の両方を含むことができる。変数に関する定義について、以下でより詳細に説明する。
【００５０】
ＳｔａｔｅＭａｃｈｉｎｅ実施は、定期的に反復するかまたは１回のみで満了するタイマの生成をサポートする。任意のタイマは、満了するごとに、状態マシンによって処理されるタイムアウト・メッセージを生成する。ＩＴｉｍｅｒインタフェースは、これらのタイマを表す。各ＩＴｉｍｅｒはその名前によって一意に識別される。ＩＴｉｍｅｒ名は、英数文字および「＿」文字の両方を含むことができる。タイマの定義は、対応するタイムアウト・メッセージの生成も示唆することに留意されたい。このメッセージには、タイマ名に付加された文字列「＿ｔｉｍｅｏｕｔ」を含む名前が割り当てられる。タイマの定義について、以下でより詳細に説明する。
【００５１】
ＳｔａｔｅＭａｃｈｉｎｅ実施は、キー付きテーブルの指定を可能にする。テーブル内の各エントリは関連するキーを有する。各キーは１つの値を言い表す。キーおよび値は、文字列データまたは整数データのいずれかとすることができる。各ＩＬｏｏｋｕｐＴａｂｌｅは、その名前によって一意に識別される。ＩＬｏｏｋｕｐＴａｂｌｅ名は、英数文字および「＿」文字の両方を含むことができる。ルックアップ・テーブルの定義について、以下でより詳細に説明する。
【００５２】
ＳｔａｔｅＭａｃｈｉｎｅ実施は、いくつかの方法で式を使用する。各式は、ＩＳｔａｔｅＭａｃｈｉｎｅインタフェースのＧｅｔＥｘｐｒｅｓｓｉｏｎファクトリ・メソッドから取得されるＩＥｘｐｒｅｓｓｉｏｎインタフェースのインスタンスによって表される。ＸＭＬ解析の制限により、式は、以下の文字によってＸＭＬエンティティとして表されることに留意されたい。
【００５３】
【表２】
2008140390.tif 000004
【００５４】
ＳｔａｔｅＭａｃｈｉｎｅ実施は、ＸＭＬにおける拡張タグの使用を可能にする。これらのタグは、ＩＰｌｕｇｉｎのインスタンスを介して処理される。ＩＰｌｕｇｉｎインタフェースは、状態マシンそれ自体によって使用されていないタグを処理するために必要なサービスを提供する。各ＩＰｌｕｇｉｎは、その名前によって一意に識別される。ＩＰｌｕｇｉｎ名は、英数文字および「＿」文字の両方を含むことができる。プラグインを状態マシンへと展開することに関するさらなる情報について、以下で説明する。
【００５５】
ＩＰｒｏｃｅｄｕｒｅインタフェースは、実行可能なアクションのセットを表す。各ＩＰｒｏｃｅｄｕｒｅはその名前によって一意に識別される。ＩＰｒｏｃｅｄｕｒｅ名は英字で始まり、英数文字および「＿」文字の両方を含むことができる。プロシージャに関するさらなる情報について、以下で説明する。
【００５６】
ＩＳｙｎｃｈＴａｂｌｅインタフェースは、状態遷移前に複数のイベントを調整するための機構である。各ＩＳｙｎｃｈＴａｂｌｅは、その名前によって一意に識別される。ＩＳｙｎｃｈＴａｂｌｅ名は英字で始まり、英数文字および「＿」文字の両方を含むことができる。同期化イベントに関するさらなる情報について、以下で説明する。
【００５７】
状態マシンの動作は、その実行の終了のために２つのフェーズを必要とする。第１のフェーズでは、状態マシンの実行スレッドは、状態マシンのＳｔｏｐメソッドを呼び出すことによって停止される。このメソッドは、スレッドが完了し、首尾よく終了されるまで戻されない。状態マシン終了の第２のフェーズは、ＣＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙオブジェクトのＲｅｌｅａｓｅＳｔａｔｅＭａｃｈｉｎｅ静的メソッドを呼び出すことによって起動される。この静的メソッドは、Ｔｒａｃｅオブジェクトに対するハンドル、および解放される状態マシン・インスタンスへのポインタを含むパラメータを受け入れる。
【００５８】
有効な状態マシンＸＭＬに関する好ましいＸＭＬ仕様言語ファイルの構造は、以下のように、＜ｓｔａｔｅ−ｍａｃｈｉｎｅ＞タグで始まる。
<state-machine modal=false>
…
</state-machine>
＜ｓｔａｔｅ−ｍａｃｈｉｎｅ＞タグは、オプションのモード属性を有する。この属性は、未知のメッセージを処理するために使用される挙動を変更するために使用することが可能であり、以下でより詳細に説明する。モード属性を使用不可にするために、「偽」の値に設定される。この属性は、通常の環境下では使用されない。
【００５９】
残りのＸＭＬファイルは、セクションに構造化され、その第１が、従う規則で使用される要素を定義する。すべての要素は規則内での使用に先立って定義される。これらの要素には、ライブラリ、タイマ、定数、変数、状態、メッセージ、アクション、およびルックアップ・テーブルが含まれる。各要素タイプは、図３に示された関連するリスト・タグに含まれる。
【００６０】
ライブラリ定義は、＜ｌｉｂｒａｒｙ＞タグと、それに続くＤＬＬの名前を識別する名前属性からなる。名前は、完全に修飾される場合がある。修飾されない場合、ＤＬＬの探索で使用される実行可能モジュールの通常の検索順序が使用される。オプションの＜ｃｏｍｍｅｎｔ＞タグを含むことができる。図４に、例示的ライブラリ・リストを示す。
【００６１】
図５に示すように、タイマ定義は、＜ｔｉｍｅｒ＞タグと、それに続くタイマの名前を識別する名前属性からなる。この名前は、タイムアウト時に使用されるメッセージを生成するためにも使用される。オプションの＜ｃｏｍｍｅｎｔ＞タグを含むことができる。
【００６２】
図６に示すように、定数定義は、＜ｃｏｎｓｔａｎｔ＞タグと、それに続く定数の名前を識別する名前属性、および定数のタイプを識別するオプションのタイプ属性からなる。タイプ属性が指定されない場合、定数のタイプはデフォルトで整数となる。タイプ属性は、以下のテーブルに指定された値のうちの１つを有することができる。
【００６３】
【表３】
2008140390.tif 000005
【００６４】
所与の定数の値に、必須の＜ｖａｌｕｅ＞タグが続く。オプションの＜ｃｏｍｍｅｎｔ＞タグを含むことができる。
【００６５】
変数定義は、＜ｖａｒｉａｂｌｅ＞タグと、それに続く変数の名前を識別する名前属性、および変数のタイプを識別するオプションのタイプ属性からなる。タイプ属性が指定されない場合、変数のタイプはデフォルトで整数となる。タイプ属性は、以下のテーブルに指定された値のうちの１つを有することができる。
【００６６】
【表４】
2008140390.tif 000006
【００６７】
さらに、以下のテーブルに示すように、変数について、初期値、最大値、および最小値を定義することができる。
【００６８】
【表５】
2008140390.tif 000007
【００６９】
図７の例は、整数の暗黙タイプ、０の初期値、０の最小値、および１００の最大値を有する、ｍｙ＿ｖａｒｉａｂｌｅと命名された変数の定義を示す。
【００７０】
図８に示すように、状態定義は、＜ｓｔａｔｅ−ｄｅｆｉｎｉｔｉｏｎ＞タグと、それに続く状態の名前を識別する名前属性からなる。オプションの＜ｃｏｍｍｅｎｔ＞タグを含めることができる。さらに、＜ｉｎｉｔｉａｌ／＞タグを使用して、唯一の状態を初期状態として識別しなければならない。また、状態特定規則に先立って規則について検査されるグローバル状態として状態を識別するオプションの＜ｇｌｏｂａｌ＞タグも指定することができる。状態がグローバルとしてマーク付けされている場合、初期状態としてマーク付けすることはできない。
【００７１】
図９に示すように、メッセージ定義は、＜ｍｓｇ＞タグと、それに続くメッセージの名前を識別する名前属性からなる。オプションで、この定義は、以下のタグのいずれかまたはすべてを含むことができる。
【００７２】
【表６】
2008140390.tif 000008
【００７３】
図１０に示すように、アクション定義は、＜ａｃｔｉｏｎ＞タグと、それに続くアクションの名前を識別する名前属性からなる。オプションの＜ｃｏｍｍｅｎｔ＞タグを含めることができる。パラメータは、オプションの＜ｐａｒａｍｅｔｅｒ＞タグを介して指定することもできる。複数の＜ｐａｒａｍｅｔｅｒ＞タグを指定することができる。１つのパラメータ文字列のみが必要な場合、パラメータはａｃｔｉｏｎタグのパラメータ属性を使用して指定することができる。
【００７４】
図１１に示すように、ルックアップ・テーブル定義は、＜ｌｏｏｋｕｐ−ｔａｂｌｅ＞タグと、それに続く以下の属性からなる。
【００７５】
【表７】
2008140390.tif 000009
【００７６】
＜ｌｏｏｋｕｐ−ｔａｂｌｅ＞タグには、ゼロ以上の＜ｌｏｏｋｕｐ−ｅｎｔｒｙ＞タグが続くことができる。これらタグのそれぞれが、キー属性および値属性を指定する。このテーブルを使用するルックアップは、マッチング・キーに関するテーブルを通して検索すること、および対応する値を戻すことを含む。
【００７７】
プロパティは、１つの文字列を、タグの値および属性内の他の文字列と置換する機能を提供する。プロパティ定義は、＜ｐｒｏｐｅｒｔｙ＞タグと、それに続くプロパティの名前を識別する名前属性、および置換される値を識別する値属性からなる。プロパティを使用するためには、「％」文字で囲むものとする。プロパティ定義の例は、<property name="SOMENAME"value="c:＼file＼path">である。
【００７８】
ネームスペースは、異なるオブジェクト内に定義されたアクションと名前との衝突を防ぐのに役立つ機能を提供する。複数のアクションは、異なるネームスペース内に常駐する限り、同じ名前を有することができる。例えば、ＳｔａｒｔＴｒａｎｓａｃｔｉｏｎと命名された２つの異なるアクションは、ＴＢオブジェクトとＲＡＰオブジェクトに常駐することができる。区別するために、これらはそれぞれ別々のネームスペース、ｔｂおよびｒａｐ内に常駐し、ｔｂ．ＳｔａｒｔＴｒａｎｓａｃｔｉｏｎおよびｒａｐ．ＳｔａｒｔＴｒａｎｓａｃｔｉｏｎと呼ばれる。以下の例のネームスペースは、以下のように使用されるのに先立って定義される。
<state-machine>
…
<namespace name="tb"/>
<namespace name="rap"/>
…
</state-machine>
【００７９】
ＳｔａｒａｔＴｒａｎｓａｃｔｉｏｎアクションを参照する規則は、以下の構文を使用する。
<rules>
<state name="State-1">
<message name="Message-1">
<message-rule-list>
<rule action-name="tb.StartTransaction"/>
<rule action-name="rap.StartTransaction"/>
</message-rule-list>
</message>
…
</state>
…
</rules>
【００８０】
規則の定義は、このマシンの有効な状態を定義することによって、以下の例のように開始される。
<rules>
<state name="State-1"/>
…
<state name="State-n"/>
</rules>
【００８１】
各状態タグは、状態タグ内で受け取り可能な有効メッセージのセットを有する。
<rules>
<state name="State-1">
<message name="Message-1"/>
…
<message name="Message-n"/>
</state>
…
</rules>
【００８２】
「＊」状態内にそのメッセージに関するハンドラがない場合、デフォルトでは、状態内に含まれないいかなるメッセージも無視される。＜ｓｔａｔｅ＞タグは、その状態に入った場合に、匿名タイマが開始されることを指定する、オプションのタイムアウト属性も含むことができる。その状態から離れる前にタイマがタイムアウトした場合、その状態内に定義された＜ｔｉｍｅｏｕｔ−ｒｕｌｅ−ｌｉｓｔ＞ハンドラによって処理される。
【００８３】
規則のセット（規則セット）は、オプションで各メッセージ・タグに定義される。何の規則も定義されない場合、何のアクションも実行されない。規則セットは以下のフォーマットを有する。
<rules>
<state name="State-1">
<message name="Message-1">
<message-rule-list>
<rule action-name=…/>
<rule action-name=…/>
…
<rule action-name=…/>
<success-transition>…</success-transition>
</message-rule-list>
</message>
…
</state>
…
</rules>
【００８４】
＜ｓｕｃｃｅｓｓ−ｔｒａｎｓｉｔｉｏｎ＞タグは、規則セット内のすべてのアクションが実行された際に「真」を戻す場合、状態マシンの遷移先である状態の名前を指定する。＜ｓｕｃｃｅｓｓ−ｔｒａｎｓｉｔｉｏｎ＞タグが指定されない場合、何の遷移も発生しない。
【００８５】
規則タグ定義は、＜ｒｕｌｅ＞要素からなる。規則の他の部分は、すべてオプションである。規則のオプション部分は、下記を含む。
・実行するアクション
・上記第１のアクションが「偽」を戻した場合に実行するアクション
・上記第１のアクションが例外を投げた場合に実行するアクション
上記いずれのオプション・アクションも指定されない場合、規則は、Ｅｘｅｃｕｔｅ（）メソッドが呼び出された場合は何も実行しないＣＮｕｌｌＡｃｔｉｏｎを実行する。
【００８６】
規則定義は以下のようになる。
<rules>
<state>
<state-name>State-1</state-name>
<message>
<message-name>Message-1</message-name>
<message-rule-list>
<rule action-name="…">
<on-failure-action>…</on-failure-action>
<on-exception-action></on-exception-action>
</rule>
<success-transition>…</success-transition>
</message-rule-list>
</message>
…
</state>
…
</rules>
【００８７】
アクション・タグ定義は、使用するアクションの名前を指定し、アクションによって使用されるゼロ以上の＜ｐａｒａｍｅｔｅｒ＞タグを指定することができる。アクションが１つのパラメータしか必要としない場合、＜ａｃｔｉｏｎ＞または＜ｒｕｌｅ＞タグ上のパラメータ属性を使用して指定することができる。アクション・タグのフォーマットは、以下の形を有することができる。
<rules>
<state>
<state-name>State-1</state-name>
<message>
<message-name>Message-1</message-name>
<message-rule-list>
<rule action-name="SomeAction">
<parameter value="SomeAction"/>
…
<parameter value="SomeAction"/>
…
</rule>
<success-transition>…</success-transition>
</message-rule-list>
</message>
…
</state>
…
</rules>
【００８８】
状態は、また、状態への入口または状態からの出口で実行される入口および／または出口タグ・セット規則を有することができる。この規則セットに対する唯一の制約は、入る／出る状態以外には遷移できないということである。エントリ・リスト・タグは以下の形を有することができる。
<rules>
<state>
<state-name>State-1</state-name>
…
<entry-rule-list>
<rule action-name="SomeAction">
<parameter value="SomeAction"/>
…
<parameter value="SomeAction"/>
</rule>
</entry-rule-list>
<exit-rule-list>
…
</exit-rule-list>
</state>
…
</rules>
【００８９】
いかなる状態マシン仕様文書も、他の状態マシン仕様文書を埋め込むことができる。例えば、状態マシンＸＭＬ文書は、まとめて処理するために他のＸＭＬ文書を埋め込むことができる。ＳｔａｔｅＭａｃｈｉｎｅは、埋め込まれた文書を含めるための＜ｉｎｃｌｕｄｅ＞タグを提供し、そのＵＲＬは名前属性によって指定される。文書を状態マシン仕様ファイル内に埋め込み、アクション、状態、メッセージの共通セット、ならびに、基本ファイル内の要素を指定変更するための顧客特定設定要素のセットを提供することができる。例えば、以下のオリジナル・ファイルは、処理される４つの埋め込み文書を含む。
<state-machine>
<include name="other-document-url.xml">
<include name="other-document2-url.xml">
<include name="other-document3-url.xml">
<include name="other-document4-url.xml">
…
</state-machine>
【００９０】
埋め込まれたファイルは、最上位に＜ｓｔａｔｅ−ｍａｃｈｉｎｅ＞タグを有していなければならない。例えば、前の例に含まれたｏｔｈｅｒ−ｄｏｃｕｍｅｎｔ−ｕｒｌ．ｘｍｌは、正当な状態マシンＸＭＬ文書でなければならず、ｓｔａｔｅ−ｍａｃｈｉｎｅタグで始まるものとしなければならない。
【００９１】
状態マシンは、メッセージ・ハンドラが共通規則のグループを実行できるようにする新しいプロシージャ機能を提供する。プロシージャとは、任意のメッセージ・ハンドラから呼び出すことが可能な規則の集合のことである。この規則セットの実行が完了すると、実行は、オリジナルのメッセージ・ハンドラに戻る。
【００９２】
プロシージャ・タグは、以下の例に示すように、＜ｐｒｏｃｅｄｕｒｅ＞タグを使用して定義される。
<procedure name="Null">
<procedure-rule-list>
<rule action-name=…>
…
<procedure-rule-list>
</procedure>
【００９３】
プロシージャは、必須の名前属性を有する＜ａｒｇｕｍｅｎｔ＞タグを使用して定義されたゼロ以上の引数タグを有することができる。引数は、名前属性上の名前を使用して、プロシージャ内のいずれでも変数として参照することができる。プロシージャから戻ると、引数の値は未定義である。引数は以下のように定義することができる。
<procedure name="Null">
<argument name="arg1"type="string"default-value="">
<procedure-rule-list>
<rule action-name=…>
…
<procedure-rule-list>
</procedure>
【００９４】
【表８】
2008140390.tif 000010
【００９５】
＜ｒｅｔｕｒｎ＞タグを使用して、呼び出し側に実行を戻す。戻りタグの例は以下のとおりである。
<procedure name="Null">
<rule action-name=…>
…
<return>
</procedure>
プロシージャが戻ると、実行は、＜ｃａｌｌ＞規則に従って次の規則を再開する。
【００９６】
プロシージャは、以下の例のように＜ｃａｌｌ＞タグを使用して実行される。
<call name="Null"/>
名前属性は必須であり、以前に定義されたプロシージャの名前を指定する。＜ｃａｌｌ＞規則は、＜ｒｕｌｅ＞タグを配置できる場所であればどこにでも配置することができる。
【００９７】
プロシージャ用の＜ｃａｌｌ＞タグは、パラメータ・タグの値も指定することができる。これらの値は、＜ｐａｒａｍｅｔｅｒ＞タグによって以下の例のように表される。
<call name="Null">
<parameter type="string"value="Hello World!">
<call name="Null">
パラメータが省略された場合、対応する＜ａｒｇｕｍｅｎｔ＞タグによって指定された任意のデフォルト値を採用する。パラメータは定位置にあり、すなわち第１のパラメータは指定された第１の引数と合致し、第２のパラメータは第２の引数と合致する。
【００９８】
時には、状態間を遷移するまでに、複数のイベントが発生するのを待つ必要がある。すべてのイベントを追跡するには、各イベントを待つ複数の状態、または、特定のイベントが受け取られた場合に設定される一連のフラグのいずれかが必要である。このような特徴は一般的であるため、状態マシンは複数のイベントを追跡するための特別な構造を提供する。ＩＳｙｎｃｈＴａｂｌｅオブジェクトは、予想されるイベントのテーブルを提供する。イベントが受け取られる場合、ＩＳｙｎｃｈＴａｂｌｅは、どれが受け取られるかを追跡する。一連の内部アクションは、ＩＳｙｎｃｈＴａｂｌｅの状態を管理および監視する機能を提供する。これらは以下のとおりである。
【００９９】
【表９】
2008140390.tif 000011
【０１００】
ＳｙｎｃｈＴａｂｌｅは、以下の例のように＜ｓｙｎｃｈ−ｔａｂｌｅ＞タグを使用して定義される。
<synch-table name="STable1">
<entry>Message 1</entry>
<entry>Message 2</entry>
…
<entry>Message n</entry>
</synch-table>
【０１０１】
ある種のタグは、実行される一連のアクションを決定する際に式を使用する。これらのタグは条件付き論理を提供し、＜ｉｆ＞、＜ｅｌｓｅ−ｉｆ＞、＜ｓｅｌｅｃｔ＞、および＜ｗｈｉｌｅ＞を含む。式は、左側、オプションの演算子、およびオプションの右側からなる。左側および右側は、変数、定数、または値とすることができる。サポートされる演算子は以下のとおりである。
【０１０２】
【表１０】
2008140390.tif 000012
【０１０３】
式が左側のみからなる場合、その式は、式の値が「ゼロ」または「空」でなければ「真」と評価する。そうでなければ、式は「偽」と評価する。さらに、インタフェースＩＥｖａｌｕａｔｅａｂｌｅを実施するいかなるアクションも、式として使用することができる。アクションのＥｘｅｃｕｔｅメソッドが呼び出され、式の結果として使用されるブール値が戻される。「！」演算子を任意の式に適用することができる。この演算子は、それに続く、式を評価した結果を否定する。式は、式タグと、タグ間に提供された仕様言語ステートメントを使用して定義される。例示的な式のグループは、次に提示する論理構造を含むことができる。
【０１０４】
＜ｉｆ＞タグが所与の式を評価し、「真」の場合、その中に含まれる規則セットを実行する。図１２に、ｉｆ式の例を示す。オプションで、＜ｉｆ＞タグの後に＜ｅｌｓｅ＞タグを続けることができる。式が「偽」と評価した場合、＜ｅｌｓｅ＞タグ内の規則セットが実行される。図１３に、ｅｌｓｅ定義を示す。またオプションで、＜ｉｆ＞タグの後に＜ｅｌｓｅ−ｉｆ＞タグを続けることができる。このタグは式属性を含む。式が「真」と評価した場合、＜ｅｌｓｅ−ｉｆ＞タグ内の規則セットが実行される。図１４に、ｅｌｓｅ−ｉｆ定義を示す。
【０１０５】
＜ｓｅｌｅｃｔ＞タグは、一連の式の評価に基づいて、一連の規則セットのうちの１つを実行することができる。図１５に、ｓｅｌｅｃｔ定義を示す。＜ｓｅｌｅｃｔ＞タグは、囲まれた＜ｗｈｅｎ＞タグ内に与えられた一連の式の評価に基づいて、一連の規則セットのうちの１つを実行することができる。図１６に、ｗｈｅｎ定義を示す。デフォルトの選択は、＜ｏｔｈｅｒｗｉｓｅ＞タグを使用して指定することができる。前のすべての式が失敗した場合、＜ｏｔｈｅｒｗｉｓｅ＞タグ内に指定された規則セットが実行される。図１７に、ｏｔｈｅｒｗｉｓｅ定義を示す。
【０１０６】
＜ｆｏｒ＞タグは、アクション・セットの反復実行を可能にする。図１８に、ｆｏｒ定義を示す。「ｆｏｒ」式内のｖａｒｉａｂｌｅ属性は、制御ループに使用するための制御変数を指定する。そのためには整数変数のみが使用可能である。ｉｎｉｔｉａｌ−ｖａｌｕｅ属性は、制御変数を開始する初期値を指定する。ｌｉｍｉｔ属性は、制御変数の最大値を指定する。制御変数値がこの値を超えた場合、ルーピングは終了する。ｉｎｃｒｅｍｅｎｔ属性は、ループの各反復について制御変数の増加を指定する。＜ｗｈｉｌｅ＞タグは、アクション・セットの反復実行を可能にする。図１９に、ｗｈｉｌｅ定義を示す。ｅｘｐｒｅｓｓｉｏｎ属性が「真」のままである限り、アクションは再度実行される。
【０１０７】
＜ｔｉｍｅｏｕｔ−ｒｕｌｅ−ｌｉｓｔ＞タグは、タイマからのタイムアウト・メッセージ用のハンドラを定義するための便利なショートカット機構を提供する。オプションのｔｉｍｅｒ−ｎａｍｅ属性は、名前によってタイマを識別することができる。この属性が指定されない場合、処理されるタイマは状態によって設定された属性に対応しなければならない。タイムアウト規則リストは、＜ｍｅｓｓａｇｅ＞定義と同じレベルに常駐する。図２０に、タイムアウト規則リストの例を示す。
【０１０８】
＜ｂｒｅａｋ＞タグは、メッセージ・ハンドラに現在のメッセージに対する規則の実行を停止させる機構を提供する。これは、＜ｒｕｌｅ＞タグが常駐できる場所ではいずれでも有効である。図２１に、ｂｒｅａｋタグの使用例を示す。
【０１０９】
＜ｙｉｅｌｄ＞タグは、メッセージ・ハンドラに現在のメッセージに対する規則の実行を停止させる他の機構を提供する。さらに、現在の状態マシンが、以下でより詳細に説明する協働する状態マシンのクラスタのメンバである場合、グループ内の何らかの他の状態マシンにフォーカスを渡す。協働するグループのメンバでない場合、＜ｂｒｅａｋ＞タグと同様に動作する。これは、＜ｒｕｌｅ＞タグが常駐できる場所ではいずれでも有効である。図２２に、ｙｉｅｌｄタグの使用例を示す。
【０１１０】
＜ａｓｓｅｒｔ＞規則タグによって識別されるアサーション・サポートは、ＸＭＬ規則内の何らかの特定のポイントで「真」を保持するように予測される条件を指定する。その条件が「真」を保持しない場合、アサーションは失敗する。アサーション障害時に実行されるアクションは、状態マシンがどのようにコンパイルされたかに依存する。状態マシンがＲｅｌｅａｓｅモードでコンパイルされた場合、アサーションは、規則セットの障害として扱われる例外を投げ、障害ハンドラが実行される。状態マシンがＤｅｂｕｇモードでコンパイルされた場合、状態マシンの実行は中断され、図２３に示されたアサーション・ダイアログ・ボックスが表示される。アサーション・ダイアログ・ボックス上のボタンを押すことによって実行されるアクションは、以下のとおりである。
【０１１１】
【表１１】
2008140390.tif 000013
【０１１２】
状態マシンによって維持されるデータ・オブジェクトを表示するための機構を提供するために、データ・モデル・エクスプローラに状態マシン実施を提供することができる。状態マシン内に格納された各オブジェクトは、関連するメタデータ・セットを有する。このメタデータは、以下のものを含む。
【０１１３】
【表１２】
2008140390.tif 000014
【０１１４】
現在、データ・モデル・エクスプローラはＪａｖａサポートと連携する場合のみ使用可能である。Ｊａｖａサポートについては、以下でより詳細に説明する。図２４に、データ・モデル・エクスプローラ・ウィンドウの例を示す。
【０１１５】
環境変数テキストは、ＸＭＬステートメント内の値および属性に置き換えることができる。一例として、以下の環境変数が生成されたものと仮定する。
SCOT_BASE=c:＼scot
この変数は、以下の例のように、変数名を「％」記号で囲むことによって置き換えることができる。
<tag attribute="%SCOT_BASE%＼filename.txt">.
結果として生じるテキストは、以下と等価である。
<tag attribute="c:＼scot＼filename.txt">.
【０１１６】
プロパティ値は、仕様言語ステートメント内の値および属性に置き換えることができる。これらは環境変数として扱われる。プロパティおよび環境変数が同じ名前を共有する場合、プロパティ値は、環境変数によってセットアップされた値を指定変更する。一例として、以下のプロパティがＸＭＬ言語ステートメント内に定義され、＜ｐｒｏｐｅｒｔｙ−ｌｉｓｔ＞ステートメントがそれに続くものと仮定する。
<property name="SCOT_BASE"value="c:＼scot">.
この値は、以下の例のように、プロパティ名を「％」記号で囲むことによって置き換えることができる。
<tag attribute="%SCOT_BASE%＼filename.txt">.
結果として生じるテキストは、以下と等価である。
<tag attribute="c:＼scot＼filename.txt">.
【０１１７】
基本的な状態マシン実施によって、いくつかのアクションが提供される。組込みアクションのリスト例を以下に示す。
【０１１８】
【表１３】
2008140390.tif 000015
【０１１９】
名前付き変数に値を割り当てるために、ａｓｓｉｇｎ−ｖａｒｉａｂｌｅ組込みアクションが使用される。以下のパラメータを受け入れる。
【０１２０】
【表１４】
2008140390.tif 000016
【０１２１】
状態マシン・スタックからすべての状態を除去するために、ｃｌｅａｎ−ｓｔａｔｅ組込みアクションが使用される。パラメータはない。
【０１２２】
名前付き変数の値を減分するために、ｄｅｃｒｅｍｅｎｔ−ｖａｒｉａｂｌｅ組込みアクションが使用される。以下のパラメータを有する。
【０１２３】
【表１５】
2008140390.tif 000017
【０１２４】
状態マシンを所与の状態に強制的に遷移するために、ｇｏｔｏ−ｓｔａｔｅ組込みアクションが使用される。以下のパラメータを有する。
【０１２５】
【表１６】
2008140390.tif 000018
【０１２６】
名前付き変数の値を増分するために、ｉｎｃｒｅｍｅｎｔ−ｖａｒｉａｂｌｅ組込みアクションが使用される。以下のパラメータを有する。
【０１２７】
【表１７】
2008140390.tif 000019
【０１２８】
ＩＳｙｎｃｈＴａｂｌｅインスタンス内のすべてのイベントが受け取られた場合、ｉｓ＿ａｌｌ＿ｃｏｍｐｌｅｔｅ組込みアクションは「真」を戻す。以下のパラメータを有する。
【０１２９】
【表１８】
2008140390.tif 000020
【０１３０】
ＩＳｙｎｃｈＴａｂｌｅインスタンス内のいずれかのイベントが受け取られた場合、ｉｓ＿ａｎｙ＿ｃｏｍｐｌｅｔｅ組込みアクションは「真」を戻す。以下のパラメータを有する。
【０１３１】
【表１９】
2008140390.tif 000021
【０１３２】
パラメータ・リスト内に指定されたすべてのイベントがＩＳｙｎｃｈＴａｂｌｅインスタンスによって受け取られた場合、ｉｓ＿ｃｏｍｐｌｅｔｅ組込みアクションは「真」を戻す。以下のパラメータを有する。
【０１３３】
【表２０】
2008140390.tif 000022
【０１３４】
特定のタイマが現在計時中であるか否かを判別するために、式でｉｓ＿ｔｉｍｅｒ＿ｔｉｍｉｎｇ組込みアクションが使用される。以下のパラメータを有する。
【０１３５】
【表２１】
2008140390.tif 000023
【０１３６】
デバッグ・ログに出力ラインを追加するために、ｌｏｇ組込みアクションが使用される。以下のパラメータを有する。
【０１３７】
【表２２】
2008140390.tif 000024
【０１３８】
アプリケーション・イベント・ログに出力ラインを追加するために、ｌｏｇ−ｅｖｅｎｔ組込みアクションが使用される。以下のパラメータを有する。
【０１３９】
【表２３】
2008140390.tif 000025
【０１４０】
所与の正規表現に照らして文字列をテストするために、ｍａｔｃｈ組込みアクションが使用される。以下のパラメータを有する。
【０１４１】
【表２４】
2008140390.tif 000026
【０１４２】
以前にスタックに保存された状態に状態マシンを遷移するために、ｐｏｐ−ｓｔａｔｅ組込みアクションが使用される。スタックが空の場合、このアクションはエラーをログに記録し、実行チェーンを終了する。このアクションにはパラメータがない。
【０１４３】
現在の状態または何らかの所与の状態をスタックに保存するために、ｐｕｓｈ−ｓｔａｔｅ組込みアクションが使用される。以下のパラメータを有する。
【０１４４】
【表２５】
2008140390.tif 000027
【０１４５】
現在のメッセージをそれ自体に再送するために、状態マシンによってｒｅｓｅｎｄ−ｍｓｇ組込みアクションが使用される。このアクションにはパラメータがない。
【０１４６】
ＩＳｙｎｃｈＴａｂｌｅインスタンスを既知の状態にリセットするために、ｒｅｓｅｔ組込みアクションが使用される。以下のパラメータを有する。
【０１４７】
【表２６】
2008140390.tif 000028
【０１４８】
メッセージをそれ自体に送信するために、状態マシンによってｓｅｎｄ−ｍｓｇ組込みアクションが使用される。以下のパラメータを有する。
【０１４９】
【表２７】
2008140390.tif 000029
【０１５０】
タイマを開始するために、ｓｔａｒｔ−ｔｉｍｅｒ組込みアクションが使用される。以下のパラメータを有する。
【０１５１】
【表２８】
2008140390.tif 000030
【０１５２】
タイマを停止するために、ｓｔｏｐ−ｔｉｍｅｒ組込みアクションが使用される。所与のタイマが現在アクティブでない場合、アクションは失敗する。以下のパラメータを有する。
【０１５３】
【表２９】
2008140390.tif 000031
【０１５４】
ＩＳｙｎｃｈＴａｂｌｅインスタンス内のエントリを更新するために、ｕｐｄａｔｅ組込みアクションが使用される。デフォルトでは、現在のメッセージをイベントとして使用する。イベントは、オプションで指定することができる。以下のパラメータを有する。
【０１５５】
【表３０】
2008140390.tif 000032
【０１５６】
タイマがタイムアウトするのを待つために、ｗａｉｔ−ｔｉｍｅｒ組込みアクションが使用される。所与のタイマが現在アクティブでない場合、アクションは失敗する。以下のパラメータを有する。
【０１５７】
【表３１】
2008140390.tif 000033
【０１５８】
注：このアクションは、メインの状態マシン・スレッドでハード待ちを実行する。このアクションは、待機が完了するまでいかなる他のメッセージも処理できないため、慎重に使用される。
【０１５９】
クラスタ内の何らかの他の状態マシンへの制御を解放するために、ｙｉｅｌｄ組込みアクションが使用される。このクラスタに対して他の状態マシンが定義されていない場合、このアクションは、実行の現在のチェーンを停止するためにのみ働く。このアクションにはパラメータがない。
【０１６０】
状態マシン内には２つの異なる種類のクラスが定義されている。第１は、プロパティを備えていない抽象基本クラスであり、すべてのメソッドは純粋に仮想として定義される。これらのタイプ・クラスに関するクラス名の最初の文字は、ＩＣｌａｓｓＮａｍｅのように「Ｉ」である。第２の種類のクラスは、定義されたプロパティおよび／またはメソッドを有する具象実施態様または抽象基本クラスのいずれかである。この種のクラスに関するクラス名は、ＣＣｌａｓｓＮａｍｅのように文字「Ｃ」で始まる。例示的クラス名および各クラスの簡単な説明のリストを、以下のテーブルに示す。
【０１６１】
【表３２−１】
2008140390.tif 000034
【表３２−２】
2008140390.tif 000035
【表３２−３】
2008140390.tif 000036
【０１６２】
図２５に、非一時状態マシン・クラスに関するクラス図を示す。各クラスは、クラスに関連付けられたメソッドを含む。図中で、三角形を通して他のクラスに結合されたクラスは、高位クラスの継承を表す。図中で、ダイヤ形を通して他のクラスに結合されたクラスは、関連クラスを表す。
【０１６３】
以下のテーブルは、タグ・マッピングへのＸＰａｔｈ式のリストを含む。これらは、どのＣＣｏｎｔｅｎｔＨａｎｄｌｅｒクラスが現在のＸＭＬタグを処理するか否かを決定するために、ＳＭＬｏａｄｅｒによって使用される。
【０１６４】
【表３３−１】
2008140390.tif 000037
【表３３−２】
2008140390.tif 000038
【０１６５】
図２６のクラス図中のほとんどのクラスは、ＸＭＬファイルの解析のためにのみ使用され、解析が完了すると解放される。一時的でないものは、状態マシンによって使用されるクラスである。
【０１６６】
最新バージョンの状態マシンは、Ｊａｖａアプリケーション向けのサポートを提供する。状態マシンは、クラスｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅのインスタンスによって表される。このＪａｖａクラスは、ＪａｖａアクションをＣ＋＋アクションと共に実行させることができる、基礎となるＣ＋＋  ＣＪａｖａＳｔａｔｅＭａｃｈｉｎｅオブジェクトと対話する。状態マシン向けのＪａｖａサポートは、ｓｔａｔｅｍｊ．ｄｌｌと呼ばれる別の実行可能ＤＬＬとして提供される。このＤＬＬは、Ｊａｖａ向けのすべてのサポート・クラス、ならびにＪａｖａアクションをサポートするＪａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ（ＪＮＩ）コードを提供する。Ｊａｖａサポートは、状態マシンへのプラグインとして実施されている。したがって、Ｊａｖａプラグインは、以下のステートメントと共にＸＭＬ定義に追加される。
<plugin-list>
<plugin
name="Java.Factory"/>
</plugin-list>.
【０１６７】
クラスｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅのすべてのインスタンスは、ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅＦａｃｔｏｒｙクラスを介して生成される。ｃｒｅａｔｅメソッドは、完全にロードされたＳｔａｔｅＭａｃｈｉｎｅインスタンスを戻す。以下の署名を有する。
public static StateMachine create(String_name
,String_url
,String_dllName
,String_configDir);
この呼び出しステートメントでは、＿ｎａｍｅパラメータが状態マシンの固有名を指定する。＿ｕｒｌパラメータは、この状態マシンに関するＸＭＬ定義を含むＵＲＬを指定する。＿ｄｌｌＮａｍｅパラメータは、Ｊａｖａサポートを含む共有ｄｌｌの名前を指定する。＿ｃｏｎｆｉｇＤｉｒパラメータは、ＵＲＬ関連検索に使用するためのディレクトリを指定する。
【０１６８】
アクションはＪａｖａで定義することが可能であり、Ｃ＋＋で定義されたアクションと共存することができる。実際のところ、すべての内部アクションはＣ＋＋アクションである。Ｃ＋＋アクションとは異なり、Ｊａｖａアクションは使用に先立って登録されない。その代わりに、Ｊａｖａ反映機能を使用して生成される。名前付きクラスのインスタンスは、最初に遭遇した際にオンデマンドで生成され、状態マシンの存続期間全体を通じて維持される。状態マシンの終了時に、Ｊａｖａアクションは廃棄される。以下に、Ｊａｖａアクション定義の例を示す。＜ｃｌａｓｓ＞タグの追加により、このアクションがＪａｖａアクションとして識別される。＜ｃｌａｓｓ＞タグ上のｎａｍｅ属性が、アクションの完全に修飾されたクラス名を指定する。
<action-list>
<action name="SomeAction">
<class name="com.ncr.ActionName">
</action>
</action-list>
【０１６９】
以下で説明する、共有データ・モデルに格納されたＪａｖａオブジェクトのいかなるフィールドにも、状態マシンによって使用される式でアクセスすることができる。これらのフィールドは、フィールドに関するアクセサ・メソッドを呼び出すことによってアクセスされる。ｇｅｔＸＸＸ（）の形のアクセサ・メソッドのみを呼び出すことが可能であり、ここでＸＸＸはアクセスするフィールドの名前である。オブジェクトそれ自体は、そのＸＰａｔｈ名を介して共有データ・モデルから参照される。式で使用するための構文は、以下のとおりである。
$(xpath-expression)[.method-name()][[index]]
上式で、ｘｐａｔｈ−ｅｘｐｒｅｓｓｉｏｎは、所望のＪａｖａオブジェクトのＸＰａｔｈ式である。「／」文字で始まる単純な絶対ＸＰａｔｈ式のみがサポートされる。
ｍｅｔｈｏｄ−ｎａｍｅはアクセサ・メソッド名である。メソッド名はオプションである。これが指定されない場合、オブジェクトそれ自体が値に使用される。ｉｎｄｅｘはアレイ・インデックスを指定する。このパラメータは、データ・モデルから戻されるオブジェクトが、ＡｒｒａｙＬｉｓｔなどのインデックスを介してそのメンバにアクセスする機能を指定するアレイまたはＪａｖａコレクションのいずれかである必要がある。Ｊａｖａによってサポートされるネイティブ・タイプのみが直接操作可能である。これらは、ｉｎｔ、ｌｏｎｇ、およびＢｏｏｌｅａｎを含む。ｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇクラスは特別であり、直接アクセスすることもできる。他のすべてのユーザ定義Ｊａｖａオブジェクトは、オブジェクトのｔｏＳｔｒｉｎｇ（）メソッドを呼び出すことによって間接的に操作される。
【０１７０】
以下の例で、式"$(/transaction/current-instance).getTotalDue()&gt;0"は、最初に、ｘｐａｔｈ式「／ｔｒａｎｓａｃｔｉｏｎ／ｃｕｒｒｅｎｔ−ｉｎｓｔａｎｃｅ」を使用して、共有データ・モデルからのオブジェクト・ルックアップを実行する。次にこの式は、そのオブジェクトのｇｅｔＴｏｔａｌＤｕｅメソッドの位置を特定し、これを呼び出す。最後にこの式は、そのメソッドから戻されたｌｏｎｇ値とゼロとを比較する。値がゼロよりも大きい場合、「真」の値が戻される。値がゼロより小さいかまたは等しい場合、「偽」の値が戻される。
【０１７１】
図２６に、Ｊａｖａをサポートするために使用されるクラスに関するクラス図を示す。ここでも、各クラスで使用可能なメソッドを図中に示す。Ｊａｖａサポート・クラスが以下のテーブルで識別され、テーブルに続いて各クラスについて簡単に説明する。
【０１７２】
【表３４】
2008140390.tif 000039
【０１７３】
ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅクラスは、メインＳｔａｔｅ  Ｍａｃｈｉｎｅクラスである。このクラスは、状態マシンの機能にアクセスするための機構を提供する。以下のものを提供する。
・ＬｏｏｋｕｐＴａｂｌｅおよびＡｃｔｉｏｎなどの基礎となるデータ構造へのアクセス
・状態マシンにメッセージを送信／通知する機能
・アクションが使用するためのオブジェクト用のキー付きストレージを提供するために使用されるＤａｔａＭｏｄｅｌオブジェクトへのアクセス
ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅの各インスタンスについて、基礎となるＣ＋＋のＣＪａｖａＳｔａｔｅＭａｃｈｉｎｅオブジェクトが存在する。
【０１７４】
ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅＣｌｕｓｔｅｒクラスは、協働するｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅインスタンスのコレクションを表す。これは、それ自体がｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅのインスタンスであり、ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅを使用するために有効な場所であれば、どこでも使用することができる。これは、ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅについて上述した機能と同じ機能と、現在アクティブな状態マシン・インスタンスへのメッセージのルーティングを提供する。ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＳｔａｔｅＭａｃｈｉｎｅＣｌｕｓｔｅｒの各インスタンスについて、基礎となるＣ＋＋のＣＪａｖａＣｌｕｓｔｅｒオブジェクトが存在する。
【０１７５】
ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．Ａｃｔｉｏｎクラスは、すべてのＪａｖａアクションが実施しなければならないインタフェースである。ｅｘｅｃｕｔｅおよびｇｅｔＲｅｓｕｌｔの２つのメソッドが提供される。前者は、Ｃ＋＋  ＩＡｃｔｉｏｎインタフェースのＥｘｅｃｕｔｅメソッドに対応する。後者は、「真」または「偽」の戻り値を取得するための機能を提供する。Ｃ＋＋の世界では、この機能は、ｐＲｅｓｕｌｔパラメータの設定によって達成される。パラメータはＪａｖａでの値によって渡されるため、この手法は使用されない。生成される各ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．Ａｃｔｉｏｎクラスについて、基礎となるＣＪａｖａＡｃｔｉｏｎのＣ＋＋オブジェクトが存在する。
【０１７６】
ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．Ｍｅｓｓａｇｅクラスは、状態マシンへの入力として使用される。このクラスは、Ｃ＋＋実施におけるＩＭｅｓｓａｇｅの等価物を提供する。このクラスの各インスタンスについて、Ｃ＋＋側に基礎となるＣＪａｖａＭｅｓｓａｇｅが存在する。
【０１７７】
ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＬｏｏｋｕｐＴａｂｌｅクラスは、Ｃ＋＋実施におけるＩＬｏｏｋｕｐＴａｂｌｅの等価物を提供する。ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＬｏｏｋｕｐＴａｂｌｅとＩＬｏｏｋｕｐＴａｂｌｅインスタンスとの間には、１対１の対応が存在する。ｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．ＬｏｏｋｕｐＴａｂｌｅの各インスタンスについて、基礎となるＩＬｏｏｋｕｐＴａｂｌｅオブジェクトが存在する。
【０１７８】
Ｃ＋＋のＪａｖａネイティブ・クラスが次のテーブルで識別され、以下で簡単に説明される。
【０１７９】
【表３５】
2008140390.tif 000040
【０１８０】
ＣＪａｖａＳｔａｔｅＭａｃｈｉｎｅクラスはＣＸＭＬＳｔａｔｅＭａｃｈｉｎｅから導出され、Ｊａｖａアクションが状態マシンから実行できるようにするために必要な機能を提供する。
【０１８１】
ＣＪａｖａＡｃｔｉｏｎクラスは、Ｃｌａｓｓパス、および対応するｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．Ａｃｔｉｏｎのｅｘｅｃｕｔｅメソッドの呼び出しに関連する他の情報を保存するためのバッキング・ストアを提供する。
【０１８２】
ＣＪａｖａＭｅｓｓａｇｅクラスは、状態マシンでの対応するｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．Ｍｅｓｓａｇｅの使用に関連するＪＮＩ情報を保存するための、バッキング・ストアを提供する。
【０１８３】
ＣＪａｖａＡｃｔｉｏｎＰｒｏｘｙクラスは、ローディング・プロセス中のクラス情報を保存する。この情報は、ＣＪａｖａＡｃｔｉｏｎおよびその対応するｃｏｍ．ｎｃｒ．ｓｔａｔｅｍ．Ａｃｔｉｏｎを生成するために、後で使用される。
【０１８４】
ＣＪａｖａＰｌｕｇｉｎＦａｃｔｏｒｙクラスは、Ｊａｖａサポートを状態マシンに接続する為に必要なＩＰｌｕｇｉｎインタフェースを提供する。
【０１８５】
前述のコードは、Ｊａｖａネイティブ・メソッドの実施に使用される。しかし、Ｊａｖａネイティブ・インタフェースが「Ｃ」プログラミング言語で実施されるため、実際のクラスはない。クラスおよびそれらの機能を以下のテーブルに列挙する。
【０１８６】
【表３６】
2008140390.tif 000041
【０１８７】
状態マシンは、複数の状態マシンが協働的に動作する構成もサポートする。この構成では、１つの状態マシンが基本状態マシンに指定され、「フォーカス」と認められる。すべてのメッセージは、最初にフォーカスを備える状態マシンに向けて送られる。その状態マシンがメッセージを処理しない場合、そのメッセージを処理できる状態マシンがもしもあれば、それがどれであるかを調べるために、すべての他の状態マシンが問い合わせられる。他の状態マシンがメッセージを処理できる場合、それがフォーカスを獲得し、現在実行中の状態マシンとなる。
【０１８８】
各状態マシンは、ＸＭＬ定義ファイルに定義された休止状態を有する。この状態に入ると、状態マシンは、基本状態マシンでない限りフォーカスを失う。状態マシンは、それらをスタック上に配置することによって追跡される。スタックのトップは現在実行中の状態マシンであり、フォーカスを有する。新しい状態マシンはフォーカスを獲得すると、スタックに追加される。状態マシンは、フォーカスを失うとスタックのトップから除去され、使用可能なプールに戻される。スタックの新しいトップがフォーカスを取り戻し、中止した時点から実行を再開する。
【０１８９】
現在実行中の状態マシンは、２つの方法でフォーカスを失う可能性がある。状態マシンは、ｙｉｅｌｄアクションを実行することによって、自発的にフォーカスを他の状態マシンに引き渡す。フォーカスを失うもう１つの方法は、状態マシンが処理しない旨のメッセージを受け取ることである。この無効性により、「フォーカス」を備える状態マシンは、そのメッセージを処理できる他の状態マシンにそのフォーカスを譲ることになる。協働する状態マシンのセットは、ＣＣｌｕｓｔｅｒクラスのインスタンスによって管理される。このクラスは、スタックの保守および構成要素状態マシンへの役割の委任の責務を負う。
【０１９０】
クラスタを定義するＸＭＬステートメントは、トップ・レベルの＜ｓｔａｔｅ−ｍａｃｈｉｎｅ−ｃｌｕｓｔｅｒ＞タグと、それに続く、構成要素状態マシンを識別する１つまたは複数の＜ｓｔａｔｅ−ｍａｃｈｉｎｅ＞タグとを有する。これらのタグでは、以下の属性が可能である。
・両方のタグのｎａｍｅ属性は、構成要素を参照する際に使用可能な固有名である。
・ｕｒｌ属性は、状態マシンに使用されるＸＭＬ定義を含むファイルのＵＲＬを識別する。
・ｌｉｂｒａｒｙ属性は、関連する状態マシン要素を含むライブラリの名前を識別する。このライブラリは、状態マシンがロードされる前にロードしなければならない。
【０１９１】
クラスタ定義は、ＸＭＬステートメントでは以下のようになる可能性がある。
<?xml version="1.0"?>
<state-machine-cluster name="Fastlane">
<state-machine name="CustomerMode"
url="FastLaneCustomerMode.xml"
library="statemj" default="true"/>
<state-machine name="StoreMode"
url="FastLaneStoreMode.xml"
library="statemj"/>
<state-machine name="AssistMode"
url="FastLaneAssistMode.xml"
library="statemj"/>
<state-machine name="MaintenanceMode"
url="FastLaneMaintenanceMode.xml"
library="statemj"/>
<state-machine name="ErrorMode"
url="FastLaneErrorMode.xml"
library="statemj"/>
</state-machine-cluster>
【０１９２】
モーダル状態マシンとは、未知のメッセージを処理するためのデフォルトの挙動が変更されている状態マシンのことである。モーダル状態マシンは、制御およびメッセージをクラスタの他のメンバに渡すのではなく、明示的＜ｙｉｅｌｄ＞タグに遭遇するまで、メッセージをキューに入れる。この時点で、モーダル状態マシンは制御を他の状態マシンに譲り、キューに入れられていたすべてのメッセージを再送する。モーダル状態マシンは、＜ｓｔａｔｅ−ｍａｃｈｉｎｅ＞タグにｍｏｄａｌ＝属性を追加することによって、以下のように定義される。
<state-machine modal="true">
…
</state-machine>
【０１９３】
動作の準備をするために、状態マシン実施は、ＸＭＬなどの仕様言語で設計および記述される。定義内の仕様言語ステートメントは、チェックアウト・ステーションなどのビジネス・プラットフォーム上でシステム機能を実施する、実行可能コンピュータ・コードを呼び出すアクションを含む。仕様言語ステートメントを含む仕様ファイルは、ビジネス・プラットフォームのハード・ドライブまたはその他に格納される。パーサ・アプリケーション・プログラムも、ビジネス・システムを制御するプロセッサによる実行のために、ビジネス・プラットフォームのハード・ドライブまたはメモリに格納される。
【０１９４】
動作を開始するために、状態マシン実施が初期設定され、ワーカー・スレッドが提供される。パーサは、状態マシン定義の仕様言語ステートメントの解釈を開始する。この解釈には、ビジネス・プラットフォームのビジネス・ロジック・モジュールの呼び出しと、仕様言語ステートメントの解析を続行するための戻された値の評価とが含まれる。状態マシン実施定義の解析は、状態マシンが終了ポイントに到達するまで続行される。その後、状態マシン実施は、実施の解析が再度開始される前の再初期設定を必要とする。
【０１９５】
ビジネス・システムの動作を修正するために必要な変更は、ビジネス・プラットフォームが修正されていない限り、ビジネス・ロジックに必要な変更のみである。ビジネス・ロジックは仕様言語で記述されるため、仕様ファイル内の構造は、再コンパイルおよびシステム内の他のコンピュータ・コードのインストールの必要なしに、変更することができる。代わりに、新しいバージョンの仕様言語ファイルがハード・ドライブに書き込まれる。次に、この新しいバージョンは初期設定時に検証され、ビジネス・システムを制御するために新しい仕様ファイルの解析が開始される。
【０１９６】
以上、本発明について、例示的プロセスおよびシステム構成要素の説明によって示し、様々なプロセスおよび構成要素についてかなり詳細に説明してきたが、出願人は、添付の特許請求の範囲を制約すること、またはこうした細部に限定することを意図しない。当業者であれば、追加の利点および修正も容易に明らかとなろう。したがって本発明は、その最も広義の態様において、図示および説明された特定の細部、実施、または例に限定されるものではない。したがって、出願人の全体的な発明の概念の趣旨または範囲から逸脱することなく、こうした細部から逸脱することが可能である。
【図面の簡単な説明】
【０１９７】
【図１】ビジネス・ロジックおよびチェックアウト・ステーションを実施するための仕様言語ファイル・インタプリタを有するチェックアウト・ステーションを示す斜視図である。
【図２】システムに関するビジネス・ロジックを実施するために仕様言語インタプリタを使用するシステムを示すブロック図である。
【図３】状態マシンを定義するために使用可能なＸＭＬファイル構造の一例を示す図である。
【図４】図３のファイル構造で使用可能なライブラリ定義の一例を示す図である。
【図５】図３のファイル構造で使用可能なタイマ定義の一例を示す図である。
【図６】図３のファイル構造で使用可能な定数定義の一例を示す図である。
【図７】図３のファイル構造で使用可能な変数定義の一例を示す図である。
【図８】図３のファイル構造で使用可能な状態定義の一例を示す図である。
【図９】図３のファイル構造で使用可能なメッセージ定義の一例を示す図である。
【図１０】図３のファイル構造で使用可能なアクション定義の一例を示す図である。
【図１１】図３のファイル構造で使用可能なルックアップ・テーブル定義の一例を示す図である。
【図１２】図３のファイル構造で使用可能なｉｆ式の一例を示す図である。
【図１３】図１２のｉｆ式で使用可能なｅｌｓｅ式の一例を示す図である。
【図１４】図３のファイル構造で使用可能なｅｌｓｅ−ｉｆ式の一例を示す図である。
【図１５】図３のファイル構造で使用可能なｓｅｌｅｃｔ式の一例を示す図である。
【図１６】図３のファイル構造で使用可能なｗｈｅｎ式の一例を示す図である。
【図１７】図３のファイル構造で使用可能なｏｔｈｅｒｗｉｓｅ式の一例を示す図である。
【図１８】図３のファイル構造で使用可能なｆｏｒ式の一例を示す図である。
【図１９】図３のファイル構造で使用可能なｗｈｉｌｅ式の一例を示す図である。
【図２０】図３のファイル構造で使用可能なｔｉｍｅｏｕｔ−ｒｕｌｅ−ｌｉｓｔ式の一例を示す図である。
【図２１】図３のファイル構造で使用可能なｂｒｅａｋ式の一例を示す図である。
【図２２】図３のファイル構造で使用可能なｙｉｅｌｄ式の一例を示す図である。
【図２３】状態マシン実施で使用可能なアサーション・ダイアログ・ボックスの一例を示す図である。
【図２４】図３のファイル構造で使用可能なデータ・モデル・エクスプローラの一例を示す図である。
【図２５Ａ】状態マシン実施で使用可能な非一時クラスの例示的セットを示すクラス図の一部である。
【図２５Ｂ】状態マシン実施で使用可能な非一時クラスの例示的セットを示すクラス図の一部である。
【図２５Ｃ】状態マシン実施で使用可能な非一時クラスの例示的セットを示すクラス図の一部である。
【図２５Ｄ】状態マシン実施で使用可能な非一時クラスの例示的セットを示すクラス図の一部である。
【図２５Ｅ】状態マシン実施で使用可能な非一時クラスの例示的セットを示すクラス図の一部である。
【図２５Ｆ】状態マシン実施で使用可能な非一時クラスの例示的セットを示すクラス図の一部である。
【図２５Ｇ】状態マシン実施で使用可能な非一時クラスの例示的セットを示すクラス図の一部である。
【図２５Ｈ】状態マシン実施で使用可能な非一時クラスの例示的セットを示すクラス図の一部である。
【図２５】状態マシン実施で使用可能な非一時クラスの例示的セットを示すクラス図（図２５Ａ〜図２５Ｈ）の全体構成図である。
【図２６Ａ】図３のファイル構造を解析するために使用可能な一時クラスを示すクラス図の一部である。
【図２６Ｂ】図３のファイル構造を解析するために使用可能な一時クラスを示すクラス図の一部である。
【図２６Ｃ】図３のファイル構造を解析するために使用可能な一時クラスを示すクラス図の一部である。
【図２６Ｄ】図３のファイル構造を解析するために使用可能な一時クラスを示すクラス図の一部である。
【図２６Ｅ】図３のファイル構造を解析するために使用可能な一時クラスを示すクラス図の一部である。
【図２６Ｆ】図３のファイル構造を解析するために使用可能な一時クラスを示すクラス図の一部である。
【図２６】図３のファイル構造を解析するために使用可能な一時クラスを示すクラス図（図２６Ａ〜図２６Ｆ）の全体構成図である。
【図２７】状態マシン実施のＪａｖａサポートに使用可能なクラスを示すクラス図である。
【図１】
2008140390.tif 000042
【図２】
2008140390.tif 000043
【図３】
2008140390.tif 000044
【図４】
2008140390.tif 000045
【図５】
2008140390.tif 000046
【図６】
2008140390.tif 000047
【図７】
2008140390.tif 000048
【図８】
2008140390.tif 000049
【図９】
2008140390.tif 000050
【図１０】
2008140390.tif 000051
【図１１】
2008140390.tif 000052
【図１２】
2008140390.tif 000053
【図１３】
2008140390.tif 000054
【図１４】
2008140390.tif 000055
【図１５】
2008140390.tif 000056
【図１６】
2008140390.tif 000057
【図１７】
2008140390.tif 000058
【図１８】
2008140390.tif 000059
【図１９】
2008140390.tif 000060
【図２０】
2008140390.tif 000061
【図２１】
2008140390.tif 000062
【図２２】
2008140390.tif 000063
【図２３】
2008140390.tif 000064
【図２４】
2008140390.tif 000065
【図２５Ａ】
2008140390.tif 000066
【図２５Ｂ】
2008140390.tif 000067
【図２５Ｃ】
2008140390.tif 000068
【図２５Ｄ】
2008140390.tif 000069
【図２５Ｅ】
2008140390.tif 000070
【図２５Ｆ】
2008140390.tif 000071
【図２５Ｇ】
2008140390.tif 000072
【図２５Ｈ】
2008140390.tif 000073
【図２５】
2008140390.tif 000074
【図２６Ａ】
2008140390.tif 000075
【図２６Ｂ】
2008140390.tif 000076
【図２６Ｃ】
2008140390.tif 000077
【図２６Ｄ】
2008140390.tif 000078
【図２６Ｅ】
2008140390.tif 000079
【図２６Ｆ】
2008140390.tif 000080
【図２６】
2008140390.tif 000081
【図２７】
2008140390.tif 000082