Anwendungsszenarien für regelbasierte Softwareentwicklung

Im Jahre 2005 schrieb ich ein Buch zum Thema Softwarearchitekturen in Java [Lars Wunderlich: Software-Architekturen in Java. Modelle, Techniken, Praxis. MITP-Verlag, 2005]. Darin versuchte ich die unterschiedlichsten Facetten von Java zu präsentieren, die Implementierungsalternativen von der einfachen Java-Anwendung bis hin zum Multi-Tier-System, von der Webservice-Anbindung bis zum agentenbasierten Parallelmodell. Die Recherchearbeiten machten mir persönlich vor allen Dingen deutlich, dass es über die reine Java-Sprache und das JRE hinaus einfach eine faszinierende Bandbreite von Lösungsideen und Möglichkeiten gibt. Mal sind sie universell einsetzbar, dann wieder einem spezifischen Zweck dienlich. Jede einzelne will verstanden und durchdrungen werden, um einsetzbar und dienlich zu sein.

Auch eine Regelmaschine ist eine funktional eingeschränkte Lösung für einen ganz konkreten Bereich der Programmierung. Sie müssen also ein bestimmtes technisches Problem haben und vergleichen dann, ob eine Rules Engine hier genau die Antworten liefern kann, nach denen Sie konkret gesucht haben. Es ist keine Lösung für jede Aufgabe und weder ein Nischen- noch ein typisches Massenprodukt.

Bevor ich mich erstmals im Projekt mit derlei Tools auseinandersetzen, Schnittstellen schreiben und Produkte bewerten musste, schien der Begriff regelbasierter Softwareentwicklung für mich sehr verschwommen und unklar. Wozu braucht man so was, was soll das sein? Bisher ließen und lassen sich Regeln doch bestens mit den typischen if/switch-Elementen von Java erschlagen, wozu braucht es da überhaupt so etwas wie eine Regelengine?

Einige Monate später und nach Durchforstung diverser Dokumentationen kam ich zu der zunächst finalen Erkenntnis, es handele sich um ein Tool, das besonders von Kunden und Fachbereichen genutzt werden könne. In Unternehmensanwendungen mit oftmals komplexer und leider auch durch Marktbedingungen sehr dynamischer Geschäftslogik ist die Anwendung eines starren Regelkonzeptes nur bedingt überlebensfähig. Wer also schnell und intensiv auf Marktänderungen reagieren und Einfluss von Geschäftspartnern in das interne Verhaltensmuster der Anwendung zulassen möchte (Fachexperten wie man so gerne sagt), erhält über Rules Engines dafür eine einheitliche und relativ omnipotente Schnittstelle. Sie kann sowohl von IT-Experten als auch von relativen Programmierlaien bedient und entsprechend angepasst werden.

Meine zweite Definition einer Rules Engine war also ein Produkt, das primär in Anwendungen mit hoher Logikdynamik (was wiederum zumeist Unternehmensanwendungen betrifft) zum Einsatz kommt und ein Steuerungs- und Modellierungsinstrument für Fachexperten anbietet. Dererlei Programme finden Sie auch in Verbindung mit dem Begriff „Experten-Systeme“ (expert systems oder auch expert shells) in der Literatur.

Expert Systems

„An expert system is a computer program that represents and reasons with knowledge of some specialist subject with a view to solving problems or giving advice.“ [Peter Jackson: Introduction to Expert Systems. Addison-Wesley, 1998.]

Peter Jackson beschreibt in seinem Buch “Expert Systems” einen sehr großen Facettenbereich von Systemen, die scheinbar intelligente, ja gar vernunftbegabtes Handeln simulieren. Solcherlei Expertensysteme schöpfen ihr Wissen aus bestimmten vorgefilterten Eingabedaten (knowledge base) und ihre Handlungsfähigkeit
aus den ihnen zur Arbeit zugedachten Regeln. Sie werden daher auch oft in Einklang mit dem Synonym wissensbasierter Systeme (knowledge-based systems) verwendet. Ein Expertensystem definiert sich dabei über:

• die Simulation vernunftorientierten Handelns innerhalb eines nach außen hin abgeschlossenen Problembereiches
• die Zusammensetzung aus Wissensbasis (knowledge base) und Regelmaschine (inference engine)
• die Anwendung heuristischer Suche oder Näherungsverfahren zur Lösung einer Aufgabe

Es gibt zahlreiche Softwaresysteme, die ihr inhärentes Wissen erst zum Zeitpunkt ihrer Arbeit erwerben, ansammeln oder Schlussfolgerungen ziehen. So erworbene Regeln lassen sich nur mit Mühe extrahieren oder wiederverwenden. Geben sie also einem Expertensystem bestimmte Eingabedaten und die immer gleichen Regeln, wird das entstehende Ergebnis der Regeln immer wiederholbar sein. Jackson bezeichnet das als „capable of explaining and justifying solutions“, also die Fähigkeit, das Ergebnis des eigenen Transformationsprozesses (der Anwendung der Regeln) erklärund sicherstellbar zu machen.

Umfasst der Begriff der regelbasierten Systeme aber nicht nur diese wissensbasierten, quasi „vorkonfektionierten“ Regelmaschinen, so bewegen wir uns auf der Skala des dynamischen Programmverhaltens in Richtung selbstlernender Software.

Dynamisiertes Programmverhalten und lernende Systeme

Während der Recherchearbeiten an diesem Artikel habe ich meinen persönlichen Begriff von Regelverarbeitung etwas weiter reifen lassen und kam zu der Erkenntnis, dass Expertensysteme zwar ein guter Ausgangspunkt für die Abhandlung des Themas waren, aber eben nur ein kleiner Bruchteil des Gesamtkunstwerkes. Inzwischen bin ich zu der Überzeugung gelangt, dass meine Verbindung zwischen Regeln und Expertensystemen zu eng gefasst und vielleicht sogar ein wenig antiquiert ist.

Faktisch geht es bei regelbasierten Systemen um die Frage, wie ich das Verhalten einer Applikation, eines Moduls oder Anwendungsteils dynamisieren kann. Dies kann im Zweifelsfalle durch Properties- oder XML-Konfigurationsdateien geschehen, durch Datenbanktabellen, aber auch durch simple Benutzerinteraktion, wenn ein Anwender auf einen Button auf der GUI klickt. Das ist eine Form der Dynamisierung von Verhalten, hat aber wenig architektonischen Charme.

Dynamisiert man bestimmte Teile von Applikationen ist es nicht nur möglich, Geschäftslogik zu modifizieren, die Applikation kann vorübergehend oder dauerhaft ihre Arbeitsweise, ihre Aufgabenstellung aber auch ihre damit verbundene Zuständigkeit ändern.

Regelbasierte Softwareentwicklung rankt sich um drei konkrete Fragen:

1. Wo kommen die Regeln her, die das Verhalten der Applikation bestimmen?
2. Wann, wie und wo beeinflussen sie das Verhalten der Anwendung?
3. Welche Auswirkungen hat der geänderte Zustand für das Programm nach oder bei Ausführung der Regeln?

Versuchen wir es hier noch mal mit einem einfachen Beispiel: Meine Frau und ich haben einen zweijährigen Sohn und seit er laufen kann, müssen natürlich vor dem Nach-draußen-Gehen z.B. Schuhe und Jacke angezogen sein. Früher haben wir gesagt: „Warte bitte, bis Mama und Papa dir die Schuhe und die Jacke angezogen haben“. Die Regel ist also, wenn Mama oder Papa dir die Schuhe angezogen haben, kannst du mit ihnen nach draußen gehen. Mittlerweile kann er das auch ganz gut selber, also sagen wir jetzt: „Zieh bitte erst deine Schuhe und deine Jacke an, sonst können wir nicht nach draußen gehen“. Das auslösende Ereignis, der Event quasi, hat sich also leicht geändert. Die Logikkette ist heute mehr: „Ich will nach draußen gehen, dann muss ich mir die Schuhe anziehen. Wenn ich die Schuhe anhabe, darf ich mit Mama und Papa nach draußen gehen.“ Mittlerweile ist es so – weil er das Prinzip natürlich inzwischen gelernt hat – dass wir sagen, wir möchten nach draußen gehen und er von sich aus darauf hinweist, dass er keine Schuhe anhat. „Wenn ich nach draußen gehen will, muss ich mir die Schuhe anziehen, sonst kriege ich vielleicht Ärger.“

Was hat dieses Beispiel nun mit Software zu tun? Nun, wenn es uns gelingt, Regeln und Assoziationen sinnvoll abzubilden, wenn Programme in der Lage sind, durch Lernen nach Vorlage, Lernen aus Fehlern, Vergleich zwischen Ist- und Soll-Zustand bestimmte Fähigkeiten zu erwerben oder zu erweitern, so ist dies ein Schritt einer künstlichen Intelligenz.

Ich habe mich lange davor gescheut, den Begriff KI (künstliche Intelligenz) oder AI (artificial intelligence) bei so etwas profanen wie einem Tool zur Erfassung von Regeln in den Mund zu nehmen. Denn es ist ein himmelweiter Unterschied zwischen einem Programm, das „Eingabebefehle“ über eine Regeltabelle erhält und einem Roboter, der in meiner Küche steht, abwäscht und den Staubsauger bedienen kann. Ich möchte versuchen Sie mitzunehmen, auf die spannende Reise vom IFThen-Statement in einer Richclient-Anwendung über die typische RETEbasierte Regelmaschine für Großapplikationen bis hin in Richtung künstlicher Intelligenz gepaart mit dynamischen Verhaltensänderungen von Software z.B. mittels aspektorientierter Softwareentwicklung. Letzteres würde sicherlich Bücherschränke füllen, weshalb es sich hier auch nur in Bruchteilen anreißen lässt.

Wir befinden uns mit regelbasierter Softwareentwicklung an einer der Nahtstellen intelligenter Programmierung und intelligenter Programme. Das ist es, was Rules Engines weit interessanter erscheinen lässt als das magere If-Then-Else aus der Syntaxjackentasche der Java-Sprache. Die Definition müsste also in etwa lauten:

Die Bandbreite der Anwendungsgebiete für Rules Engines und entsprechende Derivate enthält beispielsweise:

• Festlegung des Verhaltens von Prozessschritten in Geschäftsabläufen (z.B. Routing von Nachrichten an bestimmte Ansprechpartner, Filterung und Sortierung von Datenmengen, Errechnung von Gebühren, Zinsen, Aufschlägen oder Preisen anhand entsprechender Basiseckdaten)
• Modellierung von Geschäftsabläufen durch Beschreibung von abhängigen Prozessschritten und deren Beziehungen
• Entwurf von Schlussfolgerungssystemen (z.B. zur Analyse von Daten in medizinischen Bereichen oder Prognose von erwarteten Entwicklungsverläufen im Aktien- oder Wettervorhersagesektor)
• Entwicklung von Lösungsmodellen und -methodiken in großen Datenmengen (z.B. im Bereich der Forschung durch brute-force Suche nach bestimmten genetischen oder chemikalischen Substanzen und Ermittlung der Abweichung zum gewünschten Zielzustand)
• Einsatz im Bereich der künstlichen Intelligenz und autonomer Handlungspartner (z.B. in Agentensystemen, die Hybridkombinationen aus festen Regeln, potentiell austauschbaren Variablen abstrakten Regeln und selbst erlerntem und erprobtem Verhalten ausweisen)

Fazit

Wesentliche Grundlage für den Umgang mit Daten ist die Anhäufung von Wissen. Aus ihr heraus ergibt sich die Notwendigkeit zur Anwendung und Schlussfolgerung auf Basis von Fakten. Derartige Schlussfolgerungssysteme arbeiten primär auf der Basis von Regeln und setzen diese aus Bedingungs- und Konsequenzelementen zusammen.

Regeln bauen bei regelbasierter Programmierung auf dem Fundament der darunter befindlichen Zielsprache auf. Durch Transformation geschieht eineÜbersetzung der semantischen Bedeutung einer Regel auf die Syntax der jeweiligen Sprache in den Grenzen des zur Verfügung stehenden Anwendungsmodells.

Als Expertensysteme bezeichnen wir jene Software, die auf Basis solcher Schlussfolgerungsregeln scheinbar intelligente und wiederholbare Entscheidungen durchführen bzw. Konsequenzen ziehen kann. Künstliche Intelligenz zeichnet sich als Erweiterung dieser Fähigkeiten durch die eigenverantwortliche Anhäufung von Informationen und/oder die Ableitung daraus resultierender Regeln oder Ergebnisse aus.

Links & Literatur

1. entwickler-press.de