Droolsを使用したビジネスルールエンジンの構築-SMEopleへのパワー

公開: 2022-03-11

ソフトウェア開発で働くことの最も驚くべきことの1つは、多くの異なる業界で働く能力です。特にコンサルタントの場合はそうです。 ある業界で働いている間に学んだほとんどのソフトウェア開発スキルは、他の多くの業界、企業、プロジェクト、およびニッチに直接転用できます。

データベース設計、デザインパターン、GUIレイアウト、イベント管理などのトピックについて話しています。もちろん、特定の業界、企業、またはプロジェクトに固有のトピックもあります。

SMEがITと出会い、知識の伝達が始まります

ここで、対象分野の専門家（SME）が登場します。SMEは通常、プロジェクトの設計段階に深く関わっています。

SMEは業界内で長い間働いており、用語を知っており、コーディングの背後にあるビジネスロジックを理解しています。 SMEはソフトウェア開発についてある程度理解しているかもしれませんが、プロジェクトが成功するためにこれは必要ではありません。

多くのプロジェクトでは、ソフトウェア開発者がビジネスロジックを十分に理解していない限り、ソフトウェアアプリケーションを成功させることは比較的困難です。 知識の伝達に費やす必要のある時間は、プロジェクトの複雑さによって大きく異なります。

アジャイルアプローチが採用され、プロジェクトの開発フェーズ全体で1つ以上の中小企業が利用可能であると仮定すると、知識の伝達はプロジェクトのすべての段階で継続されます。

完全な知識の伝達が不可能な場合はどうなりますか？

業界やプロジェクトによっては、SMEが完全な知識の伝達を提供できない場合があります。

たとえば、SMEが25年の経験を持つ医師であり、プロジェクトを完了するのに6か月あるとします。 または、SMEを40年の経験を持つ生物学者として想像してみてください。このようなレベルの知識は、ソフトウェア開発プロジェクトの現実的な時間枠では転送できません。

しかし、知識領域が動的である場合はどうなるでしょうか。

通常、ソフトウェアは時間または機能に基づいて設定されたスケジュールでリリースされます。 ただし、一部の業界内のビジネスルールははるかに頻繁に変更されます。

多くの場合、業界の変化に対応するために必要な頻度でソフトウェアをリリースすることは現実的ではないかもしれません。 このようなシナリオでは、ビジネスルールエンジン内でビジネスルールを外部化する機能を持つことが理にかなっている場合があります。 ソフトウェアプロジェクトが変化に耐えることができる能力は、その究極の長期的な成功を保証するのに大いに役立ちます。

ルールエンジンはいつどこで意味をなしますか？

多くのソフトウェアプロジェクトでは、完全な知識の伝達を行い、ビジネスロジックをC＃やJavaなどのコンピューター言語でコーディングすることが可能です。

ただし、特定の主題の理解量が非常に多いプロジェクトのサブセットや、ビジネスルールが大幅に変更されるため、プログラマー以外の人がビジネスロジックに直接アクセスする方が理にかなっているプロジェクトのサブセットがあります。 これがこのチュートリアルの主題です。 そのことを念頭に置いて、ルールエンジンについて詳しく説明しましょう。

ビジネスルールエンジンとは何ですか？

ルールエンジンは、ビジネスルールを実行するためのツールです。 ビジネスルールは、事実と条件付きステートメントで構成されています。 従来のビジネスロジックに表示される「if-then」ステートメントはすべて、ビジネスルールとして適格です。

ビジネスルールエンジン

例：従業員が5日以上連続して病気になり、医師のメモがない場合は、それらを書き留める必要があります。 ビジネスアソシエイトに6か月以上連絡がなく、その間に購入を行わなかった場合は、心のこもったメールを送信する時期かもしれません。 患者の体温が高く、視力に問題があり、緑内障の家族歴がある場合は、追加のMRIまたはその他の検査を依頼する時期かもしれません。

SMEはどのようにビジネスルールを作成しますか？

SMEがJava、C＃、または別のプログラミング言語を学ぶことを期待する代わりに、ITは彼または彼女がビジネスルールを表現するためのミニ言語を作成します。 これらのルールの構成要素は、照会できるファクトで構成されます。 業界/実務分野別の事実の例は次のとおりです。

  • 人材：給与、役職、マネージャー、会社での年数
  • 医療：体温、血圧、現在の投薬
  • 財務：現在の株価、52週間の最高/最低価格、株価収益率、次の決算発表日

基本的に、ビジネス上の意思決定を行うために必要な情報は、合理化された方法でSMEが利用できる必要があります。

これらのルールはどのように見えますか？

このルールエンジンチュートリアルの残りの部分では、オープンソースのJavaベースのルールエンジンであるDroolsを使用します。これはwww.drools.orgにあり、JBossプロジェクトです。 Droolsでは、ルールはJavaコードとして記述され、次の構造を持っています。

インポートステートメントはここにあります：

 rule “Name of rule” when “The if” part of the business logic goes here. then The “then” part of the business logic goes here. end

よだれとワーキングメモリ

Droolsは、ワーキングメモリーと呼ばれる概念を採用しています。

アプリケーションコードは、SMEがこれらのファクトをクエリするルールを記述できるように、適切なファクトをワーキングメモリにロードする責任があります。 ルールエンジンを最高速度で実行し続けるために、アプリケーションビジネスロジックに関連するファクトのみをワーキングメモリにロードする必要があります。

たとえば、アプリケーションが顧客のローンを承認するかどうかを決定している場合、関連するファクトには、給与、クレジットスコア、およびローンの残高が含まれます。 関連性のない事実には、曜日または性別が含まれます。

ルールの評価

Drools Working Memoryにルールとファクトがロードされた後、ルールはルールの「then」部分に従って評価されます。 「then」の部分がtrueと評価された場合、ルールの「when」の部分が実行されます。

通常、すべてのルールは一度に評価されますが、ルールをグループ化してグループごとに評価することもできます。 ルールの「then」部分は、作業メモリーの内容を変更できます。 これが発生すると、Droolsはすべてのルールを再評価して、ルールがtrueと評価されるかどうかを確認します。 もしそうなら、それらの「いつ」の部分が実行されます。

ルール評価のこの再帰的な性質は、祝福または呪いになる可能性があるため、このアーキテクチャを念頭に置いてルールを作成する必要があります。

Droolsルールの「If」側

Droolsでは、ファクトはオブジェクトによって表されます。 オブジェクトタイプの存在または非存在を照会できます。 さらに、オブジェクトの属性も照会できます。

次にいくつかの例を示します。

従業員の収入が100,000を超えているかどうかを判断します。

 Employee(salary > 100000)

患者のコレステロール値が200を超えており、リピトールを服用しているかどうかを確認します。

 Patient(cholesterol > 200, medications.contains(“lipitor”))

株式の価格が年間高値の1％以内であるかどうかを判断します。

 Stock(price >= (yearHigh * .99))

クエリの組み合わせ

複雑なビジネスロジックを作成する場合、ビジネスルールでは、ブール演算子AND、OR、およびNOTを使用し、括弧を使用してネストすることにより、クエリを組み合わせることができます。

例えば：

75,000ドル未満のマネージャーがいるのか、100,000ドル未満のディレクターがいるのかを判断します。

 Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)

複数のオブジェクトタイプの使用

これまでのすべての例は、EmployeeやPatientなどの単一のオブジェクトタイプに基づいています。 ただし、Droolsでは、クエリを複数のオブジェクトタイプに基づくことができます。

例えば：

顧客の給与が50,000ドルを超えており、破産を申請していないかどうかを判断します。

 Customer(salary>50000) AND not exists Bankruptcy()

ルールの「Then」側

ルールの「then」側は、ルールの「when」部分に少なくとも1つの結果がある場合に何が起こるかを決定します。

Droolsでは、Javaで記述できるものはすべて、ルールの「then」部分に記述できます。 ただし、ルールをより再利用可能にするために、I / O、フロー制御コード、または一般的な実行コードをルール内に配置しないことをお勧めします。

別の方法として、ルールの「then」部分を使用して、作業メモリーを変更できます。 一般的な方法は、ルールがtrueと評価されたときに、ファクトをワーキングメモリーに挿入することです。

例えば：

 rule “LoanApproved” when Customer(credit>700) && not exist LoanOutstanding() then insert(new LoanApproval()) end

ルールが真であると評価されたことをどのようにして知ることができますか？

すべてのルールが実行された後、アプリケーションはどのルールがtrueと評価されたかを知る必要があります。 ルールがtrueと評価されたときにオブジェクトをワーキングメモリに挿入する場合、それらのオブジェクトについてワーキングメモリにクエリを実行するコードを記述できます。

上記の例では、すべてのルールが実行された後、LoanApproval（）オブジェクトが作業メモリーにあるかどうかを確認するためのクエリを実行できます。

 query "GetLoanApproval " $result: LoanApproval() end

ビジネスルールエンジンはアプリケーションとどのように相互作用しますか？

一般的なアプリケーションには、ビジネスロジック、GUI、I / O、および制御コードのフローが含まれます。

たとえば、アプリケーションは次のようなユーザーリクエストを処理できます。

 GUI ? Flow Control ? I/O ? Business Logic ? I/O ? Flow Control ? GUI

ルールエンジンを埋め込むと、このプロセスにいくつかの手順が追加されます。

 GUI ? Flow Control ? I/O ? Create Rules Engine Session ? Add Facts to Working Memory ? Fire Rules ? Determine which rules have evaluated true ? I/O ? Flow Control ? GUI

SMEはルールとどのように連携しますか？

ルールの作成、編集、削除

SMEがルールを操作するには、ユーザーフレンドリーなGUIが必要です。 一部のビジネスルールエンジンには、このようなインターフェイスが付属しています。

たとえば、Droolsには2つのGUIが付属しており、ユーザーフレンドリーだと思います。 1つ目はスプレッドシートに似ており、SMEは実際のコードを記述せずにルールを作成できます。 2番目のGUIを使用すると、より複雑なビジネスロジックを作成できます。

これらのGUIはどちらも単純な条件を入力するのに役立ちますが、ビジネスロジックがより複雑になると機能しなくなります。 その場合、独自のカスタムGUIを作成する必要があります。

SMEカスタムGUIの要素

SMEが効果的に機能するために、次の機能を備えたカスタムGUIを作成することを検討してください。

  • 構文チェッカー–「構文のチェック」ボタンはDroolsコードを呼び出して、考えられるエラーとその行番号をチェックできます。
  • ドラッグアンドドロップ– SMEに使用可能なオブジェクトと属性を記憶させる代わりに、ドラッグアンドドロップできる選択リストを提供することを検討してください。
  • Webインターフェイス–シンクライアントインターフェイスは、配布の懸念なしにSMEが利用できるようになります。 GUIには追加機能と一般的なメンテナンスが必要なため、これは便利です。
  • ルールテスター–アプリケーション全体とやり取りすることなく個々のルールをテストできるため、SMEの生産性が大幅に向上します。 SME GUIが事実を判別し、個々のルールを実行できるようにします。

ルールはどこに保存する必要がありますか？

Droolsでは、通常、ルールを保存する方法が2つあります。 Droolsは、通常.drl拡張子を持つファイルベースのルールですぐに機能します。

これは、ルールの数が少ない場合にうまく機能します。 ルールの数が増えるにつれて、データベースを使用する必要があります。 データベースからルールを保存および取得するには、より多くの作業が必要ですが、はるかに管理しやすいアーキテクチャが提供されるはずです。

このルールエンジンのチュートリアルでは、Droolsルール言語のごく一部にしか触れていません。 完全な説明については、公式のリファレンスドキュメントを参照してください。

ルールエンジンを使用するという決定は、軽々しく行われるべきではありません。 ルールエンジンを使用すると、SMEによるアプリケーションの拡張性が向上しますが、開発、テスト、および展開がより複雑になります。 このトピックに関する追加の考慮事項については、次のガイドラインを確認することをお勧めします。

これで、もう少し興味深いものを紹介できます。ほとんどのToptalブログの読者がおなじみのユースケースで、Droolsの実際の動作の簡単な例です。

実際のシナリオでのDroolの使用

高レベルのソフトウェア開発人材の大手プロバイダーであるToptalは、現在、応募者追跡ソフトウェアを使用して、採用プロセスのさまざまな段階で求職者を導きます。 このプロセスの簡略化された視覚的なフローチャートを次に示します。

よだれ

現在、応募者が採用プロセスを続行するかどうかを決定するビジネスロジックは、ソフトウェアにハードコードされています。 人材育成がビジネスロジックを変更する必要があるときはいつでも、ITが関与している必要があります。 彼らは、ソフトウェアの実行方法を直接変更できるようにしたいと考えています。

応募者追跡ソフトウェアは、採用プロセスの各決定ポイントでHRが提供するルールを実行するように変更されます。 HRには、最初のエントリ、オンライン試験の完了、またはさまざまな要因によってステータスが変更されたばかりの求職者を表す「候補者」オブジェクトがあります。 Candidateオブジェクトには、経験、テストスコア、面接スコアなどを表すフィールドがあります。

次の例は、検討のための簡略化された一連のルールを示しています。 デプロイされていません。相互接続された4つのルールで構成される単純な例です。

  • 提出済み->テスト
  • テスト->インタビュー
  • インタビュー->プロジェクト
  • プロジェクト->採用

提出済み->テスト

現在のクライアントのニーズに基づいて、HRは、候補者がオンラインテストをスケジュールする必要があるかどうかを決定するルールを作成したいと考えています。

 Rule “Schedule For Testing” when $candidate: Candidate(status=='Submitted',yrsExperience >= 10, skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5)) then $candidate.setStatus('Testing'); end

テスト->インタビュー

候補者がオンライン試験を受けた後、彼らのスコアを評価する必要があります。 HRは、このルールも管理したいと考えています。 オンライン試験では、ソフトウェア開発理論、問題解決、構文を理解する候補者の能力をテストします。 HRは、候補者が技術面接の対象となることを可能にするスコアの組み合わせを決定したいと考えています。

 Rule “Schedule For Interview” when $candidate: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8); then $candidate.setStatus('Interview'); end

インタビュー->プロジェクト

技術面接では、候補者の経験について話し、問題解決の質問に答える能力をテストし、一般的なコミュニケーション能力をテストします。 HRは、技術面接の合格点を決定するルールを作成します。

 Rule “Schedule For Project” when $candidate: Candidate(status=='Interview', interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 ); then $candidate.setStatus('Project'); end

プロジェクト->採用

候補者が技術面接に合格した場合、オフラインプログラミングプロジェクトが提供されます。 彼らはプロジェクトを提出し、完全性、アーキテクチャ、およびGUIについて判断されます。

 Rule “Schedule For Hiring” when $candidate: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 ); then $candidate.setStatus('Hiring'); end

ご覧のとおり、この基本的な例でさえ、HRに多くの可能性を提供し、運用を合理化することができます。 HRがプロセスにITを関与させることなくルールを変更できるという事実は、必然的に時間を節約し、スクリーニングプロセスをスピードアップします。

ルールはその場で変更できるため、人事部門の柔軟性も大幅に向上します。 たとえば、HRは、さまざまなパラメータを設定することにより、選択プロセスを拡張または制限できます。

すべての正しいボックスにチェックマークを付ける候補が多すぎる場合、バーが数分で上がる可能性があり、それによって候補の数が減ります。 あるいは、プロセスですべての要件を満たす候補者がほとんどまたはまったくいない場合、HRは基準の一部を減らすか削除するかを選択し、適切な数の候補者が要件を満たすまで、より関連性の高いスキルに焦点を移すことができます。