Erstellen von Engines für Geschäftsregeln mit Drools - Power to the SMEople

Eines der erstaunlichsten Dinge an der Arbeit in der Softwareentwicklung ist die Möglichkeit, in vielen verschiedenen Branchen zu arbeiten – insbesondere, wenn Sie Berater sind. Die meisten Softwareentwicklungsfähigkeiten, die Sie während der Arbeit in einer Branche erlernen, sind direkt auf eine beliebige Anzahl anderer Branchen, Unternehmen, Projekte und Nischen übertragbar.

Ich spreche von Themen wie Datenbankdesign, Design Patterns, GUI-Layouts, Event-Management etc. Dann gibt es natürlich noch branchen-, unternehmens- oder projektspezifische Themen.

KMU trifft IT, Wissenstransfer beginnt

Hier kommt der Fachexperte (SME) ins Spiel. Ein KMU ist in der Regel stark in die Entwurfsphase des Projekts involviert.

Das KMU arbeitet seit langem in der Branche, kennt die Fachsprache und versteht die Geschäftslogik hinter der Codierung. Das KMU hat möglicherweise ein gewisses Verständnis für Softwareentwicklung, dies ist jedoch nicht erforderlich, damit das Projekt erfolgreich ist.

Bei vielen Projekten wird es relativ schwierig sein, eine erfolgreiche Softwareanwendung fertigzustellen, es sei denn, der Softwareentwickler hat ein großes Verständnis der Geschäftslogik. Der Zeitaufwand für den Wissenstransfer variiert stark je nach Komplexität des Projekts.

Unter der Annahme, dass ein agiler Ansatz gewählt wird und ein oder mehrere KMU während der gesamten Entwicklungsphase des Projekts verfügbar sind, wird der Wissenstransfer in allen Phasen des Projekts fortgesetzt.

Was ist, wenn ein vollständiger Wissenstransfer nicht möglich ist?

Je nach Branche und Projekt kann es für ein KMU nicht möglich sein, einen vollständigen Wissenstransfer zu leisten.

Stellen Sie sich zum Beispiel vor, das KMU ist ein Arzt mit 25 Jahren Erfahrung und Sie haben 6 Monate Zeit, um ein Projekt abzuschließen. Oder stellen Sie sich das KMU als Biologe mit 40 Jahren Erfahrung vor – ein solcher Wissensstand lässt sich einfach nicht in einem realistischen Zeitrahmen für Softwareentwicklungsprojekte übertragen.

Was aber, wenn der Wissensbereich dynamisch ist?

In der Regel wird Software nach einem festgelegten Zeitplan veröffentlicht, der auf Zeit oder Funktionen basiert. Allerdings ändern sich die Geschäftsregeln innerhalb einiger Branchen viel häufiger.

In vielen Fällen ist es möglicherweise nicht möglich, Software so oft wie nötig zu veröffentlichen, um mit den Veränderungen in der Branche Schritt zu halten. Die Möglichkeit, Geschäftsregeln innerhalb einer Geschäftsregel-Engine zu externalisieren, kann in solchen Szenarien sinnvoll sein. Die Fähigkeit eines Softwareprojekts, Änderungen standzuhalten, trägt wesentlich dazu bei, seinen langfristigen Erfolg zu sichern.

Wann und wo sind Rules Engines sinnvoll?

Bei vielen Softwareprojekten ist es möglich, dass ein vollständiger Wissenstransfer stattfindet und die Geschäftslogik in einer Computersprache wie C# oder Java codiert wird.

Es gibt jedoch eine Teilmenge von Projekten, bei denen das Verständnis für ein bestimmtes Thema so groß ist oder die Geschäftsregeln so vielen Änderungen unterliegen, dass es für einen Nicht-Programmierer sinnvoller ist, direkten Zugriff auf die Geschäftslogik zu haben. Dies ist das Thema dieses Tutorials; Lassen Sie uns vor diesem Hintergrund ausführlich über Rules Engines sprechen.

Was ist eine Geschäftsregel-Engine?

Eine Rules Engine ist ein Werkzeug zum Ausführen von Geschäftsregeln. Geschäftsregeln bestehen aus Fakten und bedingten Anweisungen. Jede „Wenn-dann“-Aussage, die in der traditionellen Geschäftslogik vorkommt, gilt als Geschäftsregel.

Zum Beispiel: Wenn ein Mitarbeiter mehr als 5 Tage hintereinander krank ist und kein Arztzeugnis hat, dann muss es geschrieben werden. Wenn ein Geschäftspartner länger als 6 Monate nicht kontaktiert wurde und in dieser Zeit keine Einkäufe getätigt hat, ist es möglicherweise an der Zeit, ihm eine herzliche E-Mail zu senden. Wenn ein Patient eine hohe Körpertemperatur, Sehprobleme und ein Glaukom in der Familienanamnese hat, ist es möglicherweise an der Zeit, eine zusätzliche MRT oder andere Tests anzufordern.

Wie schreiben KMU Geschäftsregeln?

Anstatt von einem KMU zu erwarten, dass es Java, C# oder eine andere Programmiersprache lernt, erstellt die IT eine Mini-Sprache für ihn oder sie, um seine Geschäftsregeln auszudrücken. Die Bausteine ​​dieser Regeln werden aus Fakten bestehen, die abgefragt werden können. Einige Beispiele für Fakten nach Branche/Praxisbereichen sind:

• Human Resources: Gehalt, Position, Manager, Jahre im Unternehmen
• Medizinisch: Temperatur, Blutdruck, aktuelle Medikation
• Finanzen: aktueller Aktienkurs, 52-Wochen-Höchst-/Tiefstkurs, KGV, Datum der nächsten Gewinnveröffentlichung

Im Wesentlichen müssen die Informationen, die für geschäftliche Entscheidungen erforderlich sind, dem KMU auf optimierte Weise zur Verfügung stehen.

Wie sehen diese Regeln aus?

Für den Rest dieses Rules-Engine-Tutorials werde ich Drools verwenden, eine Open-Source-Java-basierte Rules-Engine, die unter www.drools.org zu finden ist und ein JBoss-Projekt ist. In Drools werden Regeln als Java-Code geschrieben und haben die folgende Struktur:

Importanweisungen gehen hier:

 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

Speichelfluss und Arbeitsgedächtnis

Drools verwendet ein Konzept namens Working Memory.

Anwendungscode wird dafür verantwortlich sein, geeignete Fakten in den Arbeitsspeicher zu laden, damit KMU Regeln schreiben können, die diese Fakten abfragen. Nur Fakten, die für die Geschäftslogik der Anwendung relevant sind, sollten in den Arbeitsspeicher geladen werden, um die Regelmaschine auf Höchstgeschwindigkeit laufen zu lassen.

Wenn zum Beispiel ein Antrag entscheidet, ob ein Kunde für einen Kredit zugelassen wird, wären relevante Fakten Gehalt, Kreditwürdigkeit und ausstehende Kredite. Nicht relevante Fakten wären der Wochentag oder das Geschlecht.

Regelauswertung

Nachdem Drools Working Memory mit Regeln und Fakten geladen wurde, werden die Regeln nach dem „Dann“-Teil ihrer Regel ausgewertet. Wenn der „dann“-Teil wahr ist, wird der „wann“-Teil der Regel ausgeführt.

In der Regel werden alle Regeln auf einmal ausgewertet, obwohl Regeln gruppiert und auf Gruppenbasis ausgewertet werden können. Der „dann“-Teil der Regel kann den Inhalt des Arbeitsspeichers verändern. Wenn dies eintritt, wertet Drools alle Regeln neu aus, um zu sehen, ob irgendwelche Regeln jetzt als wahr ausgewertet werden. Wenn dies der Fall ist, werden ihre „Wann“-Teile ausgeführt.

Diese rekursive Art der Regelauswertung kann Segen oder Fluch sein – daher müssen Regeln unter Berücksichtigung dieser Architektur erstellt werden.

Die „Wenn“-Seite einer Drools-Regel

In Drools werden Fakten durch Objekte dargestellt. Die Existenz oder Nichtexistenz eines Objekttyps kann abgefragt werden. Zusätzlich können auch die Attribute des Objekts abgefragt werden.

Hier sind ein paar Beispiele:

Stellen Sie fest, ob ein Mitarbeiter mehr als 100.000 verdient.

 Employee(salary > 100000)

Stellen Sie fest, ob ein Patient einen Cholesterinspiegel von mehr als 200 hat und Lipitor einnimmt.

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

Stellen Sie fest, ob der Kurs einer Aktie innerhalb von 1 % ihres Jahreshochs liegt.

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

Kombinieren von Abfragen

Beim Schreiben komplexer Geschäftslogik können Geschäftsregeln Abfragen kombinieren, indem sie boolesche Operatoren UND, ODER und NICHT verwenden und mithilfe von Klammern verschachteln.

Zum Beispiel:

Stellen Sie fest, ob es einen Manager gibt, der weniger als 75.000 US-Dollar verdient, oder einen Direktor, der weniger als 100.000 US-Dollar verdient.

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

Verwenden mehrerer Objekttypen

Alle bisherigen Beispiele basierten auf einem einzigen Objekttyp, z. B. Mitarbeiter oder Patient. Drools ermöglicht jedoch, dass Abfragen auf mehreren Objekttypen basieren.

Zum Beispiel:

Stellen Sie fest, ob der Kunde ein Gehalt von mehr als 50.000 US-Dollar hat und keinen Konkurs angemeldet hat.

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

Die „Dann“-Seite einer Regel

Die „Dann“-Seite einer Regel bestimmt, was passiert, wenn mindestens ein Ergebnis im „Wann“-Teil der Regel enthalten ist.

In Drools kann alles, was in Java geschrieben werden kann, in den „dann“-Teil der Regel geschrieben werden. Um Regeln jedoch besser wiederverwendbar zu machen, ist es im Allgemeinen eine gute Idee, keinen E/A-, Flusssteuerungscode oder allgemeinen Ausführungscode in einer Regel zu platzieren.

Alternativ kann der „Dann“-Teil einer Regel verwendet werden, um das Arbeitsgedächtnis zu ändern. Eine gängige Praxis besteht darin, eine Tatsache in das Arbeitsgedächtnis einzufügen, wenn eine Regel als wahr bewertet wird.

Zum Beispiel:

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

Woher wissen wir, wann eine Regel als wahr bewertet wurde?

Nachdem alle Regeln ausgelöst wurden, muss die Anwendung wissen, welche Regeln als wahr bewertet wurden. Wenn Regeln Objekte in den Arbeitsspeicher einfügen, wenn sie wahr sind, kann Code geschrieben werden, um den Arbeitsspeicher nach diesen Objekten abzufragen.

Im obigen Beispiel kann, nachdem alle Regeln ausgelöst wurden, eine Abfrage durchgeführt werden, um zu sehen, ob sich ein LoanApproval()-Objekt im Arbeitsspeicher befindet.

 query "GetLoanApproval " $result: LoanApproval() end

Wie interagiert eine Business Rules Engine mit einer Anwendung?

Typische Anwendungen umfassen Geschäftslogik, GUI, E/A und Steuerflusscode.

Beispielsweise kann eine Anwendung eine Benutzeranfrage wie folgt verarbeiten:

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

Das Einbetten einer Regel-Engine fügt diesem Prozess einige Schritte hinzu:

 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

Wie arbeiten KMU mit Regeln?

Regeln erstellen, bearbeiten und löschen

Damit KMU mit Regeln arbeiten können, benötigen sie eine benutzerfreundliche GUI. Einige Geschäftsregel-Engines werden mit einer solchen Schnittstelle ausgeliefert.

Zum Beispiel wird Drools mit zwei GUIs ausgeliefert, die ich benutzerfreundlich finde. Die erste ähnelt einer Tabellenkalkulation und ermöglicht es KMUs, Regeln zu erstellen, ohne jemals einen echten Code schreiben zu müssen. Die zweite GUI ermöglicht die Erstellung einer komplexeren Geschäftslogik.

Während diese beiden GUIs für die Eingabe einfacher Bedingungen hilfreich sein können, funktionieren sie nicht, wenn die Geschäftslogik komplexer wird. In diesem Fall müssen Sie Ihre eigene benutzerdefinierte GUI erstellen.

Elemente der benutzerdefinierten SME-GUI

Damit KMU effektiv arbeiten können, sollten Sie erwägen, eine benutzerdefinierte GUI mit den folgenden Funktionen zu erstellen:

• Syntaxprüfer – eine Schaltfläche „Syntax prüfen“ kann Drools-Code aufrufen, um nach möglichen Fehlern und deren Zeilennummern zu suchen.
• Drag/Drop – Anstatt von einem KMU zu verlangen, sich die ihm zur Verfügung stehenden Objekte und Attribute zu merken, sollten Sie ihm eine Auswahlliste anbieten, aus der er ziehen und ablegen kann.
• Web-Schnittstelle – eine Thin-Client-Schnittstelle wird KMU ohne Vertriebsprobleme zur Verfügung stehen. Dies ist praktisch, da die GUI zusätzliche Funktionen und allgemeine Wartung benötigt.
• Rule Tester – Die Fähigkeit, einzelne Regeln zu testen, ohne eine Schnittstelle zur gesamten Anwendung herzustellen, wird die Produktivität von KMU erheblich steigern. Lassen Sie die SME-GUI Fakten ermitteln und feuern Sie dann einzelne Regeln ab.

Wo sollten Regeln gespeichert werden?

In Drools gibt es normalerweise zwei Möglichkeiten, Regeln zu speichern. Drools funktioniert sofort mit dateibasierten Regeln, die normalerweise eine .drl-Erweiterung haben.

Dies funktioniert gut, wenn die Anzahl der Regeln klein ist. Wenn die Anzahl der Regeln zunimmt, werden Sie eine Datenbank verwenden wollen. Das Speichern und Abrufen von Regeln aus einer Datenbank erfordert mehr Arbeit, sollte Ihnen aber eine viel besser verwaltbare Architektur bieten.

Dieses Regelmodul-Tutorial hat nur einen sehr kleinen Teil der Drools-Regelsprache berührt. Eine vollständige Beschreibung finden Sie in der offiziellen Referenzdokumentation.

Die Entscheidung, eine Rules Engine zu verwenden, sollte nicht leichtfertig getroffen werden. Während eine Regel-Engine Ihre Anwendung für KMU erweiterbar macht, wird es auch komplizierter, sie zu entwickeln, zu testen und bereitzustellen. Weitere Überlegungen zu diesem Thema finden Sie in den folgenden Richtlinien.

Jetzt können wir Ihnen etwas Interessanteres zeigen – ein einfaches reales Beispiel von Drools in Aktion, in einem Anwendungsfall, der den meisten Toptal-Blog-Lesern bekannt vorkommen dürfte.

Verwendung von Drools in einem realen Szenario

Toptal, ein führender Anbieter hochrangiger Talente in der Softwareentwicklung, verwendet derzeit eine Applicant Tracking-Software, um Stellenbewerber durch verschiedene Phasen des Einstellungsprozesses zu führen. Hier ist ein vereinfachtes visuelles Flussdiagramm dieses Prozesses:

Derzeit ist die Geschäftslogik für die Entscheidung, ob ein Bewerber den Einstellungsprozess fortsetzt, fest in die Software einprogrammiert. Jedes Mal, wenn die Personalabteilung die Geschäftslogik ändern muss, muss sie die IT einbeziehen. Sie möchten die Möglichkeit haben, die Art und Weise, wie ihre Software ausgeführt wird, direkt zu ändern.

Die Applicant Tracking-Software wird so modifiziert, dass sie an jedem Entscheidungspunkt im Einstellungsprozess die von der Personalabteilung bereitgestellten Regeln ausführt. Die Personalabteilung verfügt über ein „Kandidaten“-Objekt, das einen Stellenbewerber darstellt, dessen Status gerade durch einen Ersteintrag, das Absolvieren einer Online-Prüfung oder eine Reihe verschiedener Faktoren geändert wurde. Das Candidate-Objekt verfügt über Felder zur Darstellung von Erfahrung, Testergebnissen, Interviewergebnissen usw.

Das folgende Beispiel stellt einen vereinfachten Satz von Regeln für Ihre Überlegungen dar. Es wurde nicht bereitgestellt, es ist nur ein einfaches Beispiel, das aus vier miteinander verbundenen Regeln besteht:

• Eingereicht -> Testen
• Prüfung -> Vorstellungsgespräch
• Vorstellungsgespräch -> Projekt
• Projekt -> Einstellung

Eingereicht -> Testen

Basierend auf den aktuellen Kundenanforderungen möchte die Personalabteilung eine Regel schreiben, die bestimmt, ob ein Kandidat für einen Online-Test eingeplant werden soll.

 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

Prüfung -> Vorstellungsgespräch

Nachdem der Kandidat die Online-Prüfung abgelegt hat, muss seine Punktzahl bewertet werden. HR möchte auch diese Regel kontrollieren. Die Online-Prüfung testet die Fähigkeit eines Kandidaten, Softwareentwicklungstheorie, Problemlösung und Syntax zu verstehen. Die Personalabteilung möchte entscheiden, mit welcher Punktzahl ein Kandidat für ein technisches Vorstellungsgespräch in Frage kommt.

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

Vorstellungsgespräch -> Projekt

Ein technisches Interview testet die Fähigkeit eines Kandidaten, über seine Erfahrungen zu sprechen, Fragen zur Problemlösung zu beantworten und seine Kommunikationsfähigkeit im Allgemeinen zu testen. Die Personalabteilung schreibt die Regel, die eine zum Bestehen des technischen Interviews erforderliche Punktzahl festlegt.

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

Projekt -> Einstellung

Wenn ein Kandidat das technische Interview bestanden hat, erhält er ein Offline-Programmierprojekt. Sie werden das Projekt einreichen und es wird auf Vollständigkeit, Architektur und GUI beurteilt.

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

Wie Sie sehen können, bietet selbst dieses einfache Beispiel eine Reihe von Möglichkeiten für die Personalabteilung und kann den Betrieb optimieren. Die Tatsache, dass die Personalabteilung Regeln ändern könnte, ohne die IT in den Prozess einbeziehen zu müssen, würde zwangsläufig Zeit sparen und den Überprüfungsprozess beschleunigen.

Da die Regeln spontan geändert werden können, hätte die Personalabteilung auch viel mehr Flexibilität. Beispielsweise könnte HR den Auswahlprozess erweitern oder einschränken, indem er verschiedene Parameter setzt.

Wenn es zu viele Kandidaten gibt, die alle richtigen Kästchen ankreuzen, könnte die Messlatte in Minuten höher gelegt werden, wodurch die Anzahl der Kandidaten verringert wird. Wenn der Prozess nur wenige oder keine Kandidaten hervorbringt, die alle Anforderungen erfüllen, kann die Personalabteilung alternativ einige der Standards reduzieren oder fallen lassen und ihren Fokus auf relevantere Fähigkeiten verlagern, bis eine angemessene Anzahl von Kandidaten die Anforderung erfüllt.