デシジョンツリー

デシジョンツリーを使用すると、一連のテスト条件から1つの結果を返すロジックを処理できます。 デシジョンツリーでは、さまざまなテスト条件やプロパティを使って評価できます。 比較結果がtrueなら、さらに比較が実行されます。

たとえば、ある人事アプリケーションには、候補者を評価するプロセスが含まれています。 候補者には、面接時に一連の評点が付与されます。 これらの評点を評価して、その候補者に対して採用を進めるかどうかを決定します。 デシジョンツリーは、これらの評点をテスト条件として自動的に使用し、候補者の適性を判断するように構成されています。 意思決定は、ツリーの最上位から開始して下方へと進み、 結果が「yes」になるごとに評価を進めます。 結果は「Not qualified」か「Eligible for job offer」となります。

デシジョンツリーは、フロールール、デクレアエクスプレッション、アクティビティ、ルーターで参照できます。

以下の動画では、デシジョンツリーの構成を説明しています。

動画のスクリプト

デシジョンツリーは、デシジョンテーブルと同様に、評価する条件と返す結果のセットで構成されています。 しかし、デシジョンテーブルとは異なり、デシジョンツリーは、より具体的な条件を含む一連の分岐で構成され、最終的には返す値を導きます。

デシジョンツリーには、条件分岐として比較値、比較演算子、アクションが含まれます。 アクションには、結果を返す、評価を続ける、評価を止めることが含まれます。 分岐は、階層ツリー構造で構成されます。 通常は、ツリーの幹に一般的な条件と結果を指定します。 その後、より具体的な条件とアクションに向けて、ツリーを外側に拡張していきます。 デシジョンツリーを呼び出すと、システムは最上位の行を評価し、trueと評価される結果に到達するまで続行します。 結果はシステムに返されます。 すべての分岐を処理したものの、返される結果に到達しなかった場合は、最終的なotherwise値が返されます。

ネストされた分岐

デシジョンツリーの分岐は、ネスト構造で構成できます。 たとえば、購入リクエストをサブミットした際に、考えられる結果が3つ存在するとします。 最初の条件は、100ドルを超えるリクエストの場合はリクエストを承認に回す必要があるとしています。 ここで考えられる承認結果は2つ存在します。 コンサルタント部門がサブミットしたリクエストは、コンプライアンス部門による承認に進みます。 それ以外の部門からのリクエストは、ワークマネージャーによる承認に進みます。 100ドル以下のリクエストの場合、承認は不要です。

以下の図は、リクエストを正しく進めるためにデシジョンツリーを構成する方法を示しています。 部門承認の条件は、購入リクエストの条件の下にネストされていることに留意してください。 部門承認の条件が評価される前に、購入リクエストの条件がtrueである必要があります。 100ドル以下のリクエストの場合、ツリーはリクエストをそれ以上評価する必要がなく、「Not needed」という結果を返します。