Was der eigentliche Kern einer Regel ist, wurde bisher noch nicht ausreichend betrachtet. Zuletzt wurde eine Regel als ein Objekt mit einem Namen, einem Regelinhalt (content) und Abhängigkeiten dargestellt. Bei weiteren Gedanken zur Umsetzung ist aufgefallen, dass eine Regel nicht nur als ein Regel-Dokumentteil mit einem Inhalt betrachtet werden darf. Der Inhalt besteht aus einem Bedingungsteil (LHS) und einem Konsequenzteil (RHS). Dabei ist es der LHS-Teil lediglich Drools-XML-Code. Der RHS-Teil ist indes ein Abschnitt mit Java-Code in dem diverse Aktivitäten gekapselt werden, die als Konsequenzhandlung ausgeführt werden sollen. Das zukünftige Ziel ist die Konfiguration von Regeln bzw. von Konsequenzen der Regeln in einem Editor oder Wizard. Denkbar ist es, dass per Drag-And-Drop einzelne Aktionen in den Konsequenzteil hineingezogen werden, sortiert, und mit den entsprechenden Aktionsparametern eingefügt, eine komplette Regel-Konsequenz erstellt wird. Dies ist nur möglich durch eine starke Kapselung von Funktionalitäten. Dem widerspräche die bisherige Modellierung des Regel-Inhalts. Im Modell sollte diese feingranulare Struktur abgebildet werden. Demnach besteht der Konsequenzteil also aus atomaren Aktionen, die entweder in Modulen bereits zur Verfügung stehen, oder speziellen Java-Anweisungen, die für eine Regel spezifisch sein können. Die Klassenstruktur der nochmals angepassten Regel müsste demnach wie folgt aussehen:
Nun besitzt Rule eine Liste vom Typ Consequence, um den RHS-Teil abzubilden. Für den LHS-Teil dagegen, genügt es aktuell als String gespeichert zu werden.
Keine Kommentare:
Kommentar veröffentlichen