Endliche Automaten / Rule Engines

[Landei]

Mir gefällt nicht, wie in unserem Code mit Statusfeldern (etwa der Finanzstatus einer Order) umgegangen wird, nämlich in dem die Übergangsregeln irgendwie hartkodiert wurden. Auf der anderen Seite will ich möglichst keine super-komplizierte Rule-Engine, sondern eine einfache, leichtgewichtige Lösung, um die Status-Übergänge sauber abzubilden.

Der DSL-Ansatz von bbvfsm gefällt mir schon ganz gut, aber hier fehlt mir die Möglichkeit, eine State-Engine zu laden (aus XML oder besser aus einer DB), so dass verschiedene Instanzen unserer Anwendung unterschiedliche Regeln verwenden können. Der Code ist unter unserer Kontrolle, also muss die Lösung auch nicht super-flexibel sein (es wäre z.B. kein Problem, wenn das Status-Feld immer ein Enum sein muss oder so).

Wie habt ihr solche Probleme gelöst, und welche Erfahrungen habt ihr dabei mit Rule Engines oder endlichen Automaten gemacht?

 

[Landei]

Kein irgendwie strukturierter Ansatz von Niemandem?

 

[Nardian]

Hi,

ich vermute, dass hier niemand gepostet hat, weil das ein doch sehr großes Thema mit relativ gesehen sehr wenig Informationen angesprochen wurde...

Was ich dir vorschlagen könnte (wie bereits angedeutet, keine Ahnung ob das dein "echtes" Problem löst) - wenn dein eigentliches Problem "nur" das hardcoden von magic-Strings oder ähnliches ist, dann wäre eine Art Constants.java überlegenswert. Dort sind die Magic-Strings zwar auch hardgecoded, jedoch im restlichen System durch Konstanten abgebildet, was der java-Compiler und auch die verwendete IDE sofort überprüfen kann ob das im System bekannt ist.

Ich denke für tiefergehende Hilfestellungen wäre mehr Informationen / vielleicht ein (paar) Beispiel(e) hilfreich.

Lg

 

[SlaterB]

wenn schon solche Konstanten, dann Enums, aber das scheint nicht ganz das Thema zu sein,
bzw. entgegengesetzt soll eher nichts 'hardkodiert' im Quelltext stehen

 

[Nardian]

wenn schon solche Konstanten, dann Enums, aber das scheint nicht ganz das Thema zu sein,
bzw. entgegengesetzt soll eher nichts 'hardkodiert' im Quelltext stehen

Im Prinzip hast du vollkommen recht, nur kanns auch sein dass längere Strings verwendet werden sollen (beispielsweise ein Titel der an mehreren Stellen verwendet wird - der Schlicht und einfach zu lang für ein enum ist / Blanks enthalten soll)...
Aber ja, wenns geht dann enums, sonst eben globale Konstanten..

(konnte ich wie gesagt aus der eigentlich Frage nicht erkennen was für Art / lange Strings das sind )

Lg

 

[Landei]

Mit Enums als Statuswerten habe ich kein Problem, nur die "Übergangsregeln" sollen nicht irgendwo im Code verstreut sein, sondern flexibel einstellbar sein. Also wenn z.B. eine Bestellung generiert werden soll, und es dafür schon eine Regel gibt, möchte ich diese Regel einfach ergänzen können, dass sie nur ab einem bestimmten Mindestbestellwert zutrifft. Dafür möchte ich den Code möglichst nicht anfassen müssen, sondern nur eine Datei oder Datenbank ändern. Wenn ich die Anwendung auf zwei verschiedenen App-Servern deploye, soll sie auch unterschiedliche Regelsätze verwenden können.

 

[Nardian]

Hi,

hört sich für mich nach etwas wie das übliche Listener-Konzept von Java an. Versuch eine Hashtable, mit einem Wert als Key der berechnet wird anhand einer Regel (kann alles mögliche sein), und als Listener / Liste von Listeners als value, die dann alle abgearbeitet werden, wenn diese Regel auftaucht.

Gut den key-Teil müsste man sich vermutlich nochmal überdenken wie man den bekommt, aber wie gesagt - ist ein ziemlich großes Thema dass du hier ansprichst..

Bzw generell könntest du einfach durch refactoring versuchen zumindest alle Aufrufe in einer oder einigen wenigen Klassen zu sammeln, und die in ein eigenes package rausziehn, und nach außen hin nur mehr durch eine Klasse repräsentieren.

Lg

 

[SlaterB]

bedenke bitte dass du mit jemanden mit 4600 Postings sprichst, der Sätze wie "DSL-Ansatz von bbvfsm" von sich gibt,
das ist kein Anfängerthema zum Sortieren von 20 Daten in einer Map

 

[Nardian]

Nabend,

Nun ja.. ich sehe ehrlich gesagt keinen Grund sowas zu bedenken.. ich versuche anhand von dem zu helfen was ich an Inhalt aus der Frage rauslesen kann.

Mir ist schon klar, dass jemand der sich schon recht gut mit Java / OOP auskennt meinen Post für nicht gerade hilfreich betrachten wird.. Mir passiert es hin und wieder auch mal dass ich den Wald vor lauter Bäumen nich mehr sehe, und da hilft ein Post der mich zurück zu den Basics führt doch manchmal auch weiter.

Ich würde ja gerne helfen, nur wenn ich das Problem (meiner Meinung nach) nicht besonders ausführlich erklärt bekomme, muss ich nun mal anfangen zu raten. Auf Antworten von anderen zu warten (die vielleicht besser helfen könnten) ist in diesem Thread wohl sinnfrei, da der TO es heute neu hochgepusht hat, da seit Tagen niemand geantwortet hat.

Lg

 

[Landei]

bedenke bitte dass du mit jemanden mit 4600 Postings sprichst, der Sätze wie "DSL-Ansatz von bbvfsm" von sich gibt,

Was nicht davor schützt, auch Blödsinn zu verzapfen

Die Rule-Engines, die ich mir bisher angeschaut habe, schienen mir zu komplex zu sein. Je länger ich darüber nachdenke, umso klarer wird, dass das Thema tatsächlich ziemlich kompliziert ist.

Ich denke, ich werde erst mal selbst ein wenig herumspielen, vielleicht kommt ja etwas dabei raus.

 

[Landei]

Um das mal wieder aufzuwärmen: Ich schaue mir gerade Werecat an, auf das ich eher zufällig gestoßen bin.

Ich denke, es würde recht gut in unser System passen, da wir bereits JSON für Konfigurationsaufgaben nutzen, und Werecat ziemlich leichtgewichtig und offen zu sein scheint. Hat schon jemand Erfahrungen damit?

 

[FArt]

Ich kenne Werecat nicht, habe aber die Erfahrung gemacht, dass die Ansprüche an einen Regelengine gerne vom ersten Gedanken über den Prototypen bis zum fertigen Konzept gerne steigen.
Ich habe mit Drools (in einer älteren Version, ohne Business Logic Integration Platform) sehr gute Erfahrungen machen können, sowohl was Wartbarkeit angeht, als auch Performance und Footprint.

 

[Gast2]

Wir standen mal vor einem ähnlichen Problem und haben es mit self evaluating transitions in der state machine gelöst. Die Transitions hatten ein fest vorgegebenes Interface.

Die Vorgabe welche Transitions bei welchen Einganskombinationen (Datentypen waren auch fest) wurde aus einer Transitions.xml eingelesen. So konnten zu Beginn des Programmablaufs alle Transitions in der FSM dynamisch angelegt werden.

Das ganze kann man natürlich beliebig weitre treiben (Daten und auch States selber auf diese Art und Weise definieren, jedoch kann man dann auch gleich ein existierendes Framework verwenden..)

Mir ist bewusst, dass das ganze so für dich wohl nicht Anwendbar ist, jedoch kommt dir so vielleicht noch eine neue Idee.

 

[HoaX]

Fertige Ansätze waren mir idR zu unflexibel. Ich nehme dafür einfach ein 2D-Array. Erste Dimension ist der aktuelle Zustand, zweite Dimension der Zielzustand, der Wert in entsprechenden Feld ist ein Interface welches eine Methode hat um zu entscheiden ob die Bedingungen erfüllt sind (wie auch kappesf vorschlägt). So hat man die Übergange und deren Bedingungen schön getrennt in Klassen verteilt und die Übergangstabelle ist auch relativ gut lesbar. Zum Laden/Speichern muss man sich halt selbst was einfallen lassen.