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

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

C ++のしくみ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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％以内であるかどうかを判断します。

sasscssの使い方

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」側は、ルールの「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はアプリケーションをより拡張しやすくなりますが、開発、テスト、および展開もより複雑になります。このトピックに関する追加の考慮事項については、 次のガイドラインを確認してください 。

モノのインターネットスマートホーム

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

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

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

現在、応募者が採用プロセスを続行するかどうかを決定するビジネスロジックは、ソフトウェアにハードコードされています。人事部がビジネスロジックを変更する必要があるときはいつでも、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

テスト->インタビュー

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

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

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

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

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は基準の一部を削減または削除することを選択し、適切な数の候補者が要件を満たすまで、より関連性の高いスキルに焦点を移すことができます。