Entwicklung von regelbasierten Systemen

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:

Regelbasierte Softwareentwicklung erlaubt Teile systeminhärenten Verhaltens
zu definieren und zu modifizieren und stellt einen der Grundpfeiler für die Entwicklung
selbstständiger, intelligenter und anpassungsfähiger Software dar.

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.

Lars Wunderlich ist Anwendungsentwickler und Wirtschaftsinformatiker. Er schreibt u.a. für das JavaMagazin und ist Ko-Autor von „Eclipse – die Plattform“. In seiner beruflichen Praxis hat er sich intensiv mit Rules Engines beschäftigt, darunter Ilog JRules und Drools.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.