ユーザーに一連の質問を提示する既存の「ウィザード」を更新するように依頼されました。クライアントから提供されたフローチャートを参照して、このウィザードを更新するタスクが与えられました。フローチャートは現在の流れから大きく逸脱しています。現在、すべてが質問番号と有効な回答でハードコーディングされているため、必要な変更を整理するのは非常に困難です。
これにより、質問と回答のフローチャート/ウィザードをモデル化するために人々がどのような手法を使用するのか疑問に思いました. 有限状態マシンの使用についての言及を見たことがありますが、これは適切ではないようです。ハードコーディングされた参照のコレクションを並べ替えることなく、既存の質問を簡単に移動、挿入、および削除できる手法を探しています。CSV 経由で読み込まれる配列を使用することを検討しましたが、質問のリストが増えるにつれて、これが簡単に維持できるかどうかはわかりません。
保留中の要求は、会話の流れに応じて、任意の時点でウィザードにジャンプしたり、ウィザードからジャンプしたりすることもできることに注意してください。「質問が広すぎる」という回答を避けるために、可能性のリストではなく、この用途のために特別に作成された特定のパターンまたは手法を探しています。ありがとう！
1 に答える
2
有限ステート マシンが適していないのはなぜですか? 有限状態機械に関するこの wikiの改札口の例を参照してください。
IQuestion彼らが持っている「状態遷移表」を見ると、列ヘッダーをインターフェイスのプロパティと簡単に考えることができます。
- 現在の状態: 現在
IQuestion - 入力:
IQuestion.Answer. - 次の状態:
IQuestion.NextIQuestion - 出力: システムに何をするか。
得られるのは、IQuestionルーティング ロジックが組み込まれた s (さまざまなタイプ: MultipleChoiceQuestion、DateQuestion など) のグラフです。
質問の再利用/並べ替えについて心配しているようですが、ある程度の抽象化で処理できます。たぶんIQuestion、ルーティングの問題を気にせずQuestionText、PossibleAnswers、 などのプロパティを持ってからIQuestionNode、実際のグラフ/ルーティングの問題を格納できる を持っています。の評価を処理IQuestionし、固定された順序に基づいて、または現在の質問に対する選択された回答を検査することによって、次の質問へのポインターを提供できます。
次に、システムによってこのグラフに変換できる State/Event テーブルを定義するだけです (詳細については、Wiki の説明を参照してください)。
また、さまざまなニーズに基づいてアンケートのさまざまなグラフをロードするための戦略パターンを確認することもできます。
于 2013-03-13T22:13:25.723 に答える