機械翻訳について

デシジョン・ロジックのモデリングのベスト・プラクティス

この項では、Oracle Integrationでデシジョン・モデルを作成するためのいくつかのベスト・プラクティスと推奨事項を示します。 また、この推奨事項について簡単な例で説明します。

次に、デシジョン・モデルを開発、維持および解釈しやすくするためのベスト・プラクティスのリストを示します。

• 可能な場合は、デシジョン表を使用します。デシジョン表はロジックの優先形式です。
• デシジョン表では、第1 (F)ヒット・ポリシーの使用は避けてください。 このヒット・ポリシーによって、デシジョン・ロジックはルールの順序に過剰に依存します。
• 関数を使用して、リストの各要素にロジックを適用するなど、デシジョン・ロジックを複数回適用します。
• 関数を不必要に使用しないようにします。デシジョンのモデルのテストおよびデバッグは困難になります。
• 必ず複雑なネストされた式をより単純な式に分解します。
• 可読性を向上させるには、FEEL式ではなくboxed式を使用します(可能な場合)。
• 各デシジョンおよび入力データ(例:学生日数、合計日数、個人)に名前を付けるには、名詞または名詞フレーズを使用します。 名前に動詞を使用しないでください。
• 達成する内容を示すためのデシジョンごとに摘要を指定します(例: 「合計日数をその他の日数の合計として計算」)。 すべての説明を相互に一致させます。

有料タイム・オフ(PTO)計算機能の例

前述のベスト・プラクティスに従って、組織の従業員の有給休暇日数を計算するデシジョン・モデルを作成することをお薦めします。 (このPTO計算機の例では、デシジョン・モデリング・コミュニティ・ページ(dmcommunity.org)でチャレンジを提示しているProfessor Jan Vanthienenに紹介します。)

この例では、次の条件を使用して、従業員の合計有給休暇(日数)に達します:

1. すべての従業員は、それぞれのリージョンに従って一定の数の基本休暇日数を受け取ります。 米国のオフィスの従業員は、18基本休暇日数を受け取り、EUの従業員は21日を受け取り、APAC/LATIN-AMERICAの従業員は17日を受け取ります。
2. 18以上60年以上の期間またはサービス年数が少なくとも30年の従業員が5追加の休暇日数を受け取ります。
3. 少なくとも30年の勤続年数を持ち、さらに年齢60以上の従業員は、すでに付与されている追加の日数にわたって3の特別休暇日数を受け取ります。
4. 従業員が15以上30年未満の勤続年数を持っている場合、2追加日数が付与されます。 年齢45以上の従業員は、これらの2追加の日数も受け取ります。
5. 2番目のシフトで勤務する従業員(午後4時から - 午前12時)は2日間、3番目のシフト(午前12時-午前8時)で就業している従業員は4日間追加されます。
6. スケジュールが週末1日をカバーしている場合、従業員が週末に勤務すると、1余分な日程になります。 週末を含む従業員スケジュールでは、週末のどちらの日も例外です。2余分な曜日は例外です。 これらの休暇日数は、シフトに対してすでに付与されている日数に追加されます。
7. 単科大学の学生は1の追加休暇日に適格で、退役軍人は2追加日に適格です。

定義された条件に基づいて、次の順序でデシジョン・モデルを設計します:

• デシジョンの追加
• 入力を定義
• モデル・ロジック
• テスト・デシジョン
• デシジョン・サービスの作成

デシジョンの追加

最初のステップとして、デシジョン・モデルの目標をデシジョンします。 この場合の目標は、従業員の合計PTO日数を計算することです。 通常、目標はモデル内の上位または最終出力デシジョンに変換されます。 その他のすべての条件は、上位のデシジョンの出力に直接または間接的に貢献しています。

次の図は、この例で追加されたプレースホルダーのデシジョンを示しています。 デシジョン名には、名詞または名詞のフレーズ、およびすべてのデシジョンに一貫した説明があります。

「図bp-add-decisions.pngの説明」

入力を定義

ユーザーがデシジョン・モデルの情報を指定できるように、入力データ変数を定義します。 組込みデータ型(文字列、数値、ブール、日時など)を使用して入力変数を作成することも、要件に応じてカスタムの複合データ型を定義することもできます。 次の図は、この例に必要なすべての属性が含まれる複合データ型PersonInfoTypeを示しています。 このカスタム・データ型は、入力変数「個人」を作成するために使用されます。

属性は、可能なかぎり制約として定義することをお薦めします。 制約は、入力データの属性に適用される条件です。 正しく定義されている場合は、制約を使用して入力データの整合性をチェックできます。 制約は、有効値の範囲またはリストです。 この例では、属性Region、ShiftおよびWeekend Workdaysが、有効な文字列値および数値のリストとして定義されています。

「図bp-input-data.pngの説明」

モデル・ロジック

この例のデシジョン・ロジックをモデリングするために、主にデシジョン表を使用して、指定した条件の考えられるすべての組合せを効率的に取得できます。

• 条件1
• 条件2、3、および4
• 条件5および6
• 条件7
• 最終出力デシジョン

条件1

次のデシジョン表「リージョンの日数」は、以前にリストした条件1を実装しています。 属性Regionはすでに有効な値のリストを含む制約として定義されているため、列の許可された値セル(Person.Region)で「自動」を選択します。 この列に使用可能な値は、入力データ型のRegion属性の制約から自動的に導出され、このセルに移入されます。

「図bp-condition1.pngの説明」

条件2、3、および4

可能であれば、関連する条件をデシジョンにグループ化することをお薦めします。 ここでは、「年功日数」によって、この例の条件2、3および4が実装されており、これらすべての条件が従業員の年功を判断するために役立ちます。

一意(U)ヒット・ポリシーを選択して、従業員の1つのルールのみが一致するようにします。 このヒット・ポリシーは、ルールが競合、ギャップまたは冗長性なしで論理的に一貫した方法で作成されているかどうかの検証にも役立ちます。 また、注釈列を追加して、各ルールの実装をさらに明確にすることもできます。

「図bp-condition2.pngの説明」

条件5および6

デシジョン「奇数時間日数」では、従業員の勤務スケジュールに関連する条件5および6が実装されます。

「図bp-condition5.pngの説明」

条件7

2つのデシジョン(「学生日数」および「退役軍人日数」)により、単純な式に分割した後に条件7を実装します。 さらに、これらのデシジョンでは、次のようなFEEL式ではなくbox式(If-Then-Else)が使用されます:

「図bp-feel-exp.pngの説明」

学生日数:

「図bp-box-exp2.pngの説明」

退役軍人日数:

「図bp-box-exp1.pngの説明」

特別な条件日付の追加デシジョン合計:

「図bp-spl.pngの説明」

最終出力デシジョン

最上位のデシジョンでは、すべての下位デシジョンの出力が集計され、従業員の最終PTO日数が戻されます:

「図bp-final.pngの説明」

テスト・デシジョン

ロジックをモデリングした後で、入力データの様々な組合せを使用してデシジョン・モデルをテストし、モデルが期待どおりに動作することを確認します。

次の図は、サンプルのデータ・セットとその結果を示しています:

「図bp-sample-data.pngの説明」

「図bp-result.pngの説明」

デシジョン・サービスの作成

最後に、Oracle Integrationコンポーネントまたは外部アプリケーションでデシジョン・モデルを使用するためのデシジョン・サービスを作成します。 サービスに必要な出力デシジョンと入力データを選択します。 デシジョン・サービスは、出力デシジョンを公開REST APIとして公開します。

「図bp-service.pngの説明」

デシジョン・サービスを作成した後、サービスAPIのリクエストおよびレスポンス・ペイロードのJSONスキーマを調査できます。

次のイメージは、この例のリクエストおよびレスポンス・ペイロードを示しています。

リクエスト・ペイロード:

「図bp-request.pngの説明」

レスポンス・ペイロード:

「図bp-response.pngの説明」

プロセス・アプリケーションでこのデシジョン・モデルを使用するには、モデルのスナップショットを作成し、同じをアクティブ化して、最後にこのスナップショットをアプリケーションに追加します。 「デシジョン・スナップショットのアクティブ化」と「アプリケーションおよびプロセスへのデシジョンの追加」を参照してください。