新人PGとの書簡 フラグの考え方ー状態遷移表、デシジョンテーブル

フラグの考え方、いまとなってはフラグ管理からの脱却方法と言った内容になっていますが、次に大事なのは以下です。

2.状態の管理をすること

方法はこうです。

  1. 状態遷移図(UMLでよい)を作り、起こりうる状態を洗い出す。
  2. そして洗い出した状態を組み合わせ網羅したディシジョンテーブル(DT表)を作成してください。
  3. DT表では、状態の組み合わせの優先度を業務的に考えて明確にしてください(左から右に優先度の高い順に並べる)。
  4. そして、組み合わせごとにその状態になった時に、何をすべきかを明確に定義します。

いま作っているような同期処理だけのツールであればどうとでもなりますが、Parkerのようなウィンドウズアプリは、外部からのイベントを受けて非同期にロジックが走ります(ユーザーや他のシステムからのイベント受付、OSからの割り込みなど)。

その時、上記の状態遷移表を見て何をすべきか決めます。全ての状態の組み合わせを網羅しますので、どんな状態になってもなにをすべきかが明確になります。

そして、そのとおり実装すれば、その機能にバグが存在し無い事を証明できるようになりますし、テストで100%カバレージできます。

逆にこういった分析、管理をやってないプログラムは、解決できないバグがずっと残る可能性が出てきます。また、機能追加も難しくなります。

 

上記で実装するロジックは、すべて同じ場所に記述してください。

イベントハンドラーごとに記述しない事。

私の場合はCheckState()という関数を判で押したように各GUIクラスで作成します。

状態の判定コードは全てそこに記述し、イベントが起きたらそのコードを呼びます。

判定のコードがいくら長くなっても、経路は限られるので、通常一瞬の処理できます。

状態を判定して実施する処理の中でもっとも大切なのはGUIの有効/無効制御です。

これもやり方があるのですが、全てのGUIコンポーネントの有効/無効の制御を完璧に実施します。

そうすると、DT表の中に、起こりえない状態の組み合わせが増えてくるでしょう。

これもバグが起こりえなくするための非常に有効で、しかもより重要なのはユーザビリティが非常にアップします。

二昔前のウエブアプリじゃないので、ボタンをクリックしないと入力値が受付可能かどうかわからないなんて仕様はいただけません。

全てのGUIコンポーネントの有効/無効の制御を完璧に実施すれば、ユーザは最小限の労力でアプリを使用できるのです。

他と例えば、GUIコンポーネントが50個、100個あろうと、完璧に制御する方法があります。それはどこかの機会で説明します。

Posted in