この記事では、著者が開発したミニチュアJavaライブラリについて説明します。これにより、有限状態マシンを簡単かつ明確に定義できます。 ライブラリは、AkerFSMと呼びましょう。GoogleCodeで入手できます。

記事の最初の部分では、ライブラリの前提条件と要件が定式化されています。 2番目の部分では、ライブラリの使用の抽象的な例を示します。 3番目の部分では、ライブラリ自体の設計の重要な側面を検討します。 4番目の部分は、GWTアプリケーションのコントローラーの1つの動作がステートマシンを使用して設定される単純化された実際の例を検討することに専念します。

背景

有限状態マシンを実装するにはさまざまな方法があります。 提案されたライブラリを作成するまで、現在の状態番号で選択するswitchステートメントを使用する最も成功した方法を検討しました。 コードの例はここにあります。「SWITCH technology」および「Automatic programming」という名前で表示されるアプローチ自体は、言及されたサイトにあるShalytoとTukkelの記事で詳細に説明されています。

その単純さのために、switchステートメントの実装はオブジェクト指向のパラダイムにまったく適合せず、このため、現代の言語の機能を完全に使用することはできません。 したがって、私は次の要件を満たす実装を作成することにしました。

• マシンは、switchステートメントを使用するときと同じように明確かつ簡潔に設定されます。
• 実装はオブジェクト指向です
• 実装は自動プログラミングのすべての可能性をサポートします

今後、結果が問題の元のステートメントを超えたことに注意します（詳細は記事の最後にあります）。

抽象例

最初の例として、画面フォームのある抽象的なウィンドウを考えます。 ウィンドウは開いていても閉じていてもかまいません。 ウィンドウが開いている場合は、フォームデータを保存できます。 ウィンドウを最初に表示する前に、その初期化が必要です。

まず、オートマトンを宣言し、その状態のセットを定義します。







ここで、オートマトン自体とそれを作成するメソッドを定義します。







マシンを使用するには、オブジェクトを作成し、handleEvent（）メソッドを呼び出してイベントを処理し、イベントをパラメーターとして渡します。







したがって、提案された実装では、switchステートメントの場合と同じ視覚的かつ簡潔な方法でオートマトンを記述することができます。状態を判断するには数行のコードが必要で、オートマトン定義全体が単一のブロックに配置されます。 switchステートメントの場合のように、標準のソース形式を使用すると、画像が少し悪くなりますが、ここで選択する必要があります。 ご使用の環境で、特定のテキストの自動書式設定を無効にできる場合は、幸運です。

ボーナス	enumを使用すると、シリアル番号または定数で状態をコーディングするよりもオートマトンの定義がはるかに直感的になります。 ところで、enumの定数の名前にキリル文字を使用できます

ライブラリデバイスの機能

主なライブラリクラスはStateとFSMで、その目的は明らかです。 以下に示すように、両方のクラスは簡単に拡張できます。

クラスは次のように宣言されます。









Generic STATESは、マシンの多くの状態を保存するenumを定義します。 ジェネリックEVENTは、自動イベントのクラスを定義します。 実際のアプリケーションでは、EVENTはイベントエンジンで使用される基本イベントクラスを示します。 問題の例では、簡単にするためにStringを使用しています。

Stateクラスの3つのメソッド：enter（）、handleEvent（）、exit（）は、特定の状態を作成するときにオーバーライドされるように設計されています。 マシンが問題の状態になるとenterが呼び出され、イベントを処理するときにhandleEventが呼び出され、マシンが問題の状態を離れるとexitがそれぞれ呼び出されます。 これらのメソッドはTemplate Methodパターンを実装するため、それらを再定義する場合、superの呼び出しはオプションです。

オートマトンを定義するとき、Stateクラスと共に、その子孫であるSuperStateクラスを使用できます（StateとSuperStateは、Compositeパターンの類似物を共同で実装します）。 SuperStateの目的は、グループ遷移など、状態のグループに一般的な動作を実装することです。

State.toString（）メソッドは、状態の名前とシリアル番号を返します（長いライブ列挙！）FSM.toString（）およびSuperState.toString（）メソッドは、同じ方法で定義されます。

handleEvent（）メソッドを呼び出すときのFSMクラスの動作は次のとおりです。

• 現在の状態および現在の状態グループのhandleEvent（）を呼び出します
• 次の状態を決定します（グループ遷移は通常の遷移よりも優先されます）
• 現在の状態と、遷移時に破棄されるすべてのグループ状態のexit（）を呼び出します
• 新しい状態と遷移時に分類されるすべてのグループ状態のenter（）を呼び出します
• 次の状態の判定結果がnullになるまで遷移を実行します

さらに、FSMは14個のイベントを実装しています。これらのイベントに対してハンドラーを割り当て、特定のイベントハンドラーメソッドまたはいずれかのイベントが発生したときに呼び出されるメソッドをオーバーライドします。 イベントハンドラーの使用例は、MonitoredFSMおよびLoggedFSMクラスです。

ライブラリクラスの動作をより詳細に理解する最良の方法は、デバッガでライブラリに付属するJUnitテストを実行することです。 これらのテストは、ライブラリを使用してその動作のロジックを示す例となるように特別に作成されました。

ボーナス	ライブラリソースコードはGWTで正常にコンパイルされます

実生活の例

次に、実際の生活により近い例を考えてみましょう。 ボタンを押して特定のフォームを画面に表示するGWTアプリケーションを作成しましょう。 フォームを表示する場合、2段階でサーバーからデータをダウンロードする必要があります。まず、フォームの構成がロードされ、次にデータがダウンロードされてフォームに表示されます。 ボタンをクリックするだけでフォームを閉じることができます。 ダウンロードプロセスは、ユーザーによって中断される場合があります。 ダウンロードプロセス中に、実行する操作の名前を示す進行状況インジケータが表示されます。

マシンには5つの状態があります。







通常の状態に加えて、2つのグループ状態も定義します。 1つ目はLOADCONFIG状態とLOADDATA状態を含み、RPCFailureイベントを処理します。 2番目には、LOADCONFIG、LOADDATA、およびSHOW状態が含まれ、HideEventイベントを処理する役割を果たします。

進行状況バーを実装することは残っています。 これは非常にエレガントで普遍的な方法で行うことができ、抽象的なアプリケーションだけでなく、ほとんどの同様のタスクにも適しています。

まず、FSMの代わりに、Observerパターンを実装するMonitoredFSMクラスを使用します。 これにより、イベントマシンの状態変更イベントハンドラーを接続できます（別の方法は、FSMクラスのonAfterSwitchState（）メソッドを自分で再定義することです）。

次に、StateクラスからProgressStateクラスを生成します。 コンストラクターで指定された状態の説明の存在によって、祖先とは異なります。

3番目に、MonitoredFSMクラスインスタンスのコールバックを次のように定義します。







ProgressState型の状態への各遷移で、このコールバックは進行状況インジケーターを表示します。進行状況インジケーターは、現在の状態の説明、現在の状態の数、および状態の総数を示します。 通常の状態に移行すると、進行状況インジケータが消えます。

ご覧のとおり、現在の状態をわずかに停止し、表示された数の状態の総数（「2/5」と「3/5」が表示されますが、「1/2」と「 「2/2」）。 この問題の可能な解決策については説明しません。EnumSetクラスとその静的メソッドが有用であると言うだけです。

まとめると、オートマトンの次の定義が得られます（LOADCONFIG状態とLOADDATA状態では、外部の影響を処理するさまざまな方法が示されています）。







ボタンクリックイベントハンドラーは次のようになります。







RPCリクエストハンドラは次のようになります。







最後の2つのコードフラグメントから次のように、一気にGWTアプリケーションの非同期部分を正確に実装し、このための単純で普遍的なパターンを作成するタスクを見つけました。 さらに、このパターンは、RPC要求ハンドラーと通常のイベントハンドラーの両方で同一です。

ライブラリのソースコードは、 Google Codeで入手できます。 trunk / fsmフォルダーにはライブラリ自体とJUnitテストがあり、trunk / gwt_fsmフォルダーには例として考慮されたGWTアプリケーションがあります。

結論

AkerFSMライブラリは、すべての自動プログラミング機能をサポートしています。

• 明示的な状態の割り当てと状態マシンのコーディング
• switchステートメントと外観が似ている、有限状態マシンの明確で簡潔な定義
• さまざまな種類のマシン（Miles、Moore、mixed）のサポート
• イベントマシンとコンピューティングマシンのサポート（およびこれら2つのモデルを1台のマシンに混在させる機能）
• 組み込みマシンのサポート
• グループ移行サポート
• 有限状態マシンの観点からロギングする可能性

自動プログラミングのリストされた機能のサポートに加えて、AkerFSMライブラリには2つの基本的な利点があります。

1. ビジネスロジックは、テクノロジーコードとは別のものです。 実際、特定のマシンのロジック（ビジネスロジック）は、有限状態マシンのモデルを実装するコードとは別に設定されます。 モデルの実装は、特定のマシンとは独立して再定義および拡張でき、必要な技術操作でビジネスロジックを「装飾」します。
2. ライブラリはオブジェクト指向ですが、ライブラリの基本クラスは簡単に拡張可能です。

これらの利点のおかげで、多くの利点と拡張の機会があります。 それらのいくつかをリストします

1. 遷移の条件を確認するとき、状態に入るとき、および終了するときに実行されるアクションを決定する1つのコードブロックの機能。
2. 「グループ遷移」はグラフィック表記の要素としてのみ存在し、実装ではまったくサポートされない上記の自動プログラミングに関する出版物とは異なり、AkerFSMライブラリは「グループ状態」の概念を完全に実装します。 通常の状態と同様に、グループ状態の場合、遷移状態、およびグループ状態に出入りするときに実行されるアクションを決定することができます。
3. 有限状態マシンモデルからペトリネットモデルへの移行は、FSMクラスの単純な拡張です。
4. また、遷移の履歴を保存できるマシンのモデルを簡単に作成できます。
5. 戦略パターンとFSMクラスの実装により、制御するクラスからマシンを分離できます。 これにより、特に、マシンのJUnitテストを実行し、他のアプリケーションから完全に分離することができます。
6. Stateクラスは（FSMクラスと組み合わせて）Stateパターンを実装します。 このロールでの使用の最も単純なバージョンは、タスクに固有の操作でインターフェイスを定義し、Stateクラスの必要な数の子孫でこのインターフェイスを実装することだけが必要です。 Stateパターンの説明の「Gang of Four」には、特定の状態内の遷移ロジックの定義が「サブクラス間の実装依存関係」を導入すると書かれていますが、AkerFSMライブラリアーキテクチャにはこの欠点はありません。 この場合、状態間の遷移のロジックは有限状態マシンによって決定され、特定の状態のクラスで記述されますが、それらの間に依存関係はありません。
7. FSMクラスの拡張が可能です。これにより、実行時にオートマトンの定義を変更できます（状態の追加、削除、および置換）。

要約すると、AkerFSMライブラリは、 Polkarpovaの著書Shalytoの「Automated Programming」で説明されている実装よりも大幅に優れていると言えます。



PS。 GroovyまたはRubyでは、同様の実装をさらに美しくできると確信しています。