Basti

Hallo zusammen.

Ich suche nach einer Definitionssprache für einfache Prozesse, Programmabläufe bzw. konkrete Anwendungsfälle. Ein solcher Prozess besteht aus mehreren Operationen für die jeweils mehrere Rückgabewerte definiert werden. Jeder Rückgabewert wird nun wiederum mit einer anderen Operation verknüpft.

Ein erster Versuch sieht im Moment so aus:
Aber hier gibt es doch sicherlich bekannte Schemata, die darauf passen würden - ich hab jedoch noch keines gefunden. Könnt ihr mir da weiterhelfen?

Auch finde ich die Bezeichnungen "node" und "next" nicht so passend. Ideen?

Basti

PS:
Klar, ich weiß, sowas wäre auch denkbar:
...aber ich suche eben irgendwas standardisiertes oder bewährtes, sinniges. Muss ja auch kein XML sein.

Mister Ad

WSDL bzw BPEL?

Basti

Hab gerade WPML entdeckt:

http://wi.wu-wien.ac.at/~mendling/EPML/

Werd mir deine Vorschäge grad ml anschauen, danke.

Basti

..später dann:

Die sind für meine Zwecke ein wenig überfrachtet. WPML scheint mir ganz tauglich zu sein, allerdings ist da auch einiges an Overhead drinnen.

Hat jemand denn Erfahrungen damit, derartige Prozesse in eine PHP-Anwendung zu klöppeln? Auf der Grundlage der oben abgebildeten Prozess-Definition hab ich mir ein Skript gebastelt, mit dem man sich interaktiv durch den Prozess durchklicken kann.

Hier bräuchte es auch nur eine so simple Definition, wie meine oben. Hier wird auch nur ein Prozess abgebildet, der sich innerhalb einer Session für einen Benutzer abspielt. Ein wenig komplexer wird es dann, wenn da Prozesse mit mehreren Akteuren dazukommen, also die typischen Workflows von Content-Erzeugung, -Freigabe und -Archivierung etc.

Mein Ziel ist es, in einem Framework die einzelnen Methoden (Operationen/Funktionen/Methoden) gebündelt in Modulen unabhängig von diesen Abläufen programmierbar zu machen und dann eben über derartige Ablauf-Definitionen (die eben nicht hartcodiert sind) miteinander zu verknüpfen.

Die Frage ist dann auch noch, wie in einer solchen Prozess-Definition die Objekte abgebildet werden können, mit denen gearbeitet wird (in dem Beispiel deleteUser eben der zu löschende Benutzer oder der Artikel, den es zu erstellen gilt) und wie die Integrität sichergestellt wird.

In einem ersten Versuch, habe ich für jeden Knoten, der eine Benutzerschnisstelle bezeichnete (View) die vom Benutzer getroffene Entscheidung/das eingetretene Event gespeichert und bei jeder Fortsetzung den Prozess komplett von neuem durchlaufen lassen. Da war es dann nur nötig, die Existenz des zu löschenden Benutzers einmal zu Beginn des Prozesses zu prüfen, denn diese Prüfung wurde bei jeder Prozess-Fortführung wiederholt. Aber dafür müssten dann eben jedes mal von neuem die ganzen Methoden abgearbeitet werden und das ist ziemlich unwirtschaftlich (man könnte auch definieren, welche Methoden neu angesprochen werden müssen und für welche die Rückgabe-Signale gespeichert werden sollen).

Eine Altenative wäre, bei jeder Prozess-Fortsetzung einen Integritäts-Check zu veranstalten...

Hat jemand Erfahrungen damit oder Lust, seine Gedanken darber zu teilen?

Basti

Hallo Basti,

falls ich dich richtig verstanden habe, willst du ein Framework auf Basis eines definierbaren Gesamtprozesses (mit wiederverwendbaren, definierbaren Teilprozessen) basteln. Ich habe diese Idee seit einigen Wochen und werde mich in meinem Urlaub daran machen.

Das Ganze ähnelt dem Springframework von Java, soll aber um einiges reicher an Flexibilität sein. In einer Art Programmablaufplan (PAP) im z.B. XML-Format wird definiert, was bei welcher Aktion (sei es durch den Benutzer, denn er muss ja einen Prozess anstoßen, oder durch einen fertiggestellten Teilprozess) passiert. Verzweigungen zu Prozessen würde ich mit Rückgabewerten aus Prozessmethoden lenken.

Als Referenzprojekt würd ich eine stinknormale Webseite bauen, die u.a. ein paar übliche Formulare hat, um nicht nur einzelne Seiten, sondern auch aneinanderhängende Seiten (=Teilprozesse) abzubilden.

Ich hab sowas bisher weder gesehen noch intensiver drüber nachgedacht. Aber ich finde das eine super Idee, einen PAP in lesbarer Form einem Programm zu Grunde zu legen. Das würde dem Programmierer eine Menge Arbeit ersparen, und Teilprozesse lassen sich wunderbar unabhängig voneinander erstellen (Teamwork) und in anderen Projekten wiederverwenden.

Ich hab total Bock drauf

Basti

Hi.

Ja, das ist in etwa, was ich meine. Allerdings gibt es in meinen Entwürfen keinen "definierbaren Gesamtprozess". Die eingehenden Anfragen sind nicht zwingend Startpunkte für Prozesse oder Fortführungen laufender Prozesse, sondern auch Anfragen nach bestimmten Views oder Inhalten (wobei bei letzterem noch zu klären wäre, ob dahinter nicht auch ein Prozess liegt, der herausfindet, welches Modul den Inhalt darstellen soll und dieses dann mit der Anfrage füttert) - bzw. auch einfach nur Anfragen, die nur die View-Ebene betreffen (Thieme ändern etc.).

Ich denke auch, dass ich die oben angesprochenen Prozesse mit mehreren Akteuren erstmal draußen lasse und mich nur auf Prozesse beschränke, die innerhalb einer Sitzung stattfinden. Die anderen Prozesse (über mehrere Sessions bzw. mit mehreren Akteuren) lassen sich so ja auch noch halbwegs gut zusammenbauen.

Für mich stellt sich noch die Frage nach der Architektur des Ganzen. Ein erster Ansatz war, in einer konkreten Prozess-Klasse die Definition einzulesen, wobei dort nur Methodenaufrufe dieser Prozess-Klasse definiert werden.

Zum obigen Beispiel wäre es zum Testen z.B. diese Klasse:
Die Frage wäre, ob nicht auch direkt die einzelnen Modul-Methoden angesprochen werden können. Eine Idee wäre, ein Command-Objekt an die Methoden zu übergeben, dass dann a) das entsprechende Signal (success, noRights, invalidData etc.) und b) die relevanten Datenobjekte zurückgibt. Das sähe dann so aus, das der Conroller ein Request-Objekt von der View-Ebene erhält, guckt, ob es sich um einen Request im Kontext eines Prozesses handelt und in dem Falle den Request einer ProzessFactory (oder -Manager) übergibt, die dann entweder das bestehende Prozess-Objekt aus der Session ausgräbt oder ein neues baut und zurückgibt.

Diesem Prozess-Objekt übergibt der Controller dann ein Command-Objekt (quasi ein Event, dass sich aus dem Request ergibt). Das Prozess-Objekt aktualisiert anhand des Kommandos und der ggf. enthaltenen Daten (Formulareingaben, Objekte aus dem Model) seinen Status und schaut, welcher Schritt als nächster dran ist. Für diesen Schritt bereitet es ein neues Command-Objekt vor und gibt es dem Controller zurück. Der gibt es an die entsprechende Stelle weiter (entweder eine Methode im entsprechenden Modul oder an die View-Ebene oder als Startsignal für einen neuen Unterprozess) und die Antwort (das mit Daten bzw. zumindest einem Rückgabesignal beladenen Command-Objektes) kommt dann entweder gleich zurück oder eben nach dem nächtesn Client-Request und wird wieder an den Prozess verfüttert.

Bliebe eben die Frage, wie die Daten automatisiert vom Prozess-Objekt aufgenommen und weitergegeben werden können. So kommt also im Beispiel des deleteUser-Prozesses vom Benutzer eine ID des zu löschenden Benutzers. Dieser Wert muss ja dann zu einer Methode, die prüft, ob es den Benutzer gibt und das Benutzer-Objekt ggf. zurückgibt. Dieses Objekt muss dann später an die anderen Methoden weitergegeben werden - oder auch nicht. Es wäre natürlich fein, wenn das eben irgendwie automatisiert wäre, so dass es in der Prozess-Definition nicht unbeding auftauchen muss - oder nur einmalig in Form einer Aufzählung der Prozess-Daten.

Basti[/code]

Auch nach dreimaligem Lesen ist mir nicht jeder deiner Schritte klar geworden. Aber ich hab natürlich auch schon eine Idee, wobei ich statt des Begriffs "Teilprozess" einfach "Prozess" verwende.

Ich denke, zuerst sollte man mal die Programmstruktur vereinheitlichen. Die einzelnen Abarbeitungsseiten (impressum.php, home.php, angebote.php, etc.) werden in Klassen gekapselt, die ein bestimmtes Interface für Module erben und implementieren müssen. Eine Methode des Moduls ist der Einsprungpunkt für einen Seitenaufruf (Request). Dieser Methode werden bestimmte Objekte übergeben, die die Methode/der Prozess nutzt, z.B. ein Requestobjekt/Formularobjekt, ein Pfadobjekt, das bestimmt, welche weiteren Prozesse diese Methode nach der Abarbeitung anstoßen kann, ein Responseobjekt etc..

Eine weitere Methode könnte für die Validierung eines Requests zuständig sein. Sie kann Fehlercodes/-beschreibungen produzieren, die automatisch vom Framework aufgenommen und dargestellt werden. Die Methode könnte einen booleschen Wert zurückgeben, der aussagt, ob dieselbe Seite nochmal (mit den Fehlern) gezeigt werden soll, oder ob die Validierung erfolgreich war und zum nächsten Prozess/zur Ergebnisseite gegangen wird.

Man könnte den Modulen auch noch eine zu erbende Klasse zugrunde legen, die sämtliche wiederkehrende Methoden enthält, z.B. das Prüfen auf Vorhandensein eines Users aus deinem Beispiel. Das könnte man auch wieder vereinheitlichen, indem man sämtliche Datenbankabfragen eines bestimmten Typs (zB ist User vorhanden? <- gibt booleschen Wert zurück) in irgendeinem Array definiert und per Namen ansprechbar macht. Dann könnte man das mit in die Prozessdefinition einbauen.

Für Datenbankabfragen anderer Typen (zB Formular -> Speichern) würde ich eine unabhängige Abstraktion schreiben, die die Datenbankstruktur kennt und über die man Formulare über eine XML-Datei konfigurieren kann. Damit ließen sich Daten speichern und bearbeiten. Eine Abstraktion für das Darstellen von Daten für diverse Medien (HTML, PDF, ...) könnte man auch basteln.

Oder man definiert wirklich in einer Liste ALLE im Programm vorkommenden Abfragen als Templates, die also Variablen beinhalten, die vom Modul bzw. automatisch aus dem Modulkontext heraus ersetzt werden.

Interessantes Projekt, wirklich

Meine Ziele sind primär:

- Modularisierung und Vereinheitlichung eines Programms
- Programmablauf unabhängig vom Quelltext konfigurierbar über ein externes Medium (XML, ...)
- Datenein-/ausgabe automatisiert über Datenbankabstraktionen, evtl. im Detail konfigurierbar unabhängig vom Quelltext
- Darstellung abstrahieren, so dass Module für einzelne Ausgabemedien (HTML, PDF, CSV, SOAP...) geschrieben werden können

Basti

Ein Unterprozess wird ein Prozess ja erst in dem Kontext, dass er eben von einem "Mutter-Prozess" aufgerufen wird. Ist für den Prozess aber natürlich Schnuppe.

Erben oder implementieren?

In meinen Plänen gibt es keine "Abarbeitungsseiten". Es gibt Anfragen an Module und diese entscheiden anhand des Status und der Abfrage eben, welche Sicht engezeigt werden soll. Ist soweit ja auch nichts neues (diese Prozess-Geschichte natürlich auch nicht, aber im Kontext von PHP-Frameworks hab ich sie noch nicht gesehen - eine Ausnahme vielleicht Wizards z.B. in Prado). Das Ganze basiert natürlich auf dem MVC-Pattern - soweit sinnvoll zumindest.

Muss los.
Mehr vielleicht später

Basti

Natürlich ist implementieren gemeint.

Ich brauchte irgendwas anschauliches. Ich hoffe, wir meinen dasselbe. Ich würde mehrere Navigationspunkte auf der Oberfläche einer Webseite nur in Ausnahmefällen zu einem Modul zusammenfassen. Darüber, ob das nun in der Gesamtheit der MVC-Struktur ähnelt, mach ich mir erstmal keine Gedanken.

Hoffentlich

Basti

Hi "saraneus" (Ben?)

Ich will hier garnicht meine ganzen Konzepte für mein Framework aufblättern. Zum einen, weil es mir hier um diese Prozess-Geschichte geht, zum anderen, weil es selbst noch nicht klar habe. Wichtig ist mir nur diese Trennung zwischen Anfragen und "Seiten". Es ruft niemand eine Seite auf, sondern es werden Anfragen gestellt und das System entscheidet, welche Sicht als "Main-View" in die Seite eingesetzt wird. Allerdings sollten schon Aufrufe, wie "Zeig mir das Impressum" oder "Zeig mir das Kontakt-Formular" möglich sein, die dann, je nach Rechten und Vorhandensein der Daten in die gewünschte "Seite" (Ansicht der gewünschten Daten als Hauptbestandteil einer Seite) münden, oder eben in entsprechende Fehlermeldungen oder z.B. Identifizierungs-Aufforderungen.

Was die Prozesse angeht, so geht es mir in erster Linie, dieses Programmieren Seite-für-Seite zu durchbrechen (wofür es ja auch bereits Konzepte gibt, siehe auch hier z.B. Prado). Klassisch ist ja, eine Seite contact.php anzulegen, die dann via Affen-Formular so oft aufgerufen wird, bis sie am Schluß irgendwann mal eine Bestätigungsseite ausgibt - oder auch nicht, fals sich der Benutzer vorher wegklickt. Dabei gibt es in meinen Augen irgendwie ein ziemliches Durcheinander, was die Begriffe "Seite" und alles was darn hängt angeht. Der Benutzer möchte keine "Kontakt-Seite" oder "Bestätigungsseite", sondern er möchte eine Nachricht an die Betreiber verschicken und erhält im Zuge dieses Prozesses eben einmal eine Formular-Seite und einmal eine Bestätigungsseite. Aber das geht schon wieder vom Thema ab.

Das nächte Anliegen ist eben, diese Prozesse nicht in PHP zu gießen, sondern in eine Datenstuktur zu packen, die sich anpassen und erweitern lässt, ohne den Quellcode zu ändern. Das bedeutet z.B., dass es in meinen Augen keinen Sinn macht, jeden einzelnen Schritt eines solchen Prozesses in einer solchen Definition zu definieren, sondern größere Pakete, die nicht nur ein true oder false zurückgeben, sondern einen von mehreren möglichen (zuvor definierten) Werten/Ereignissen. Es würde wahrscheinlich auch keinen Sinn machen, wenn in so einer Definition zwei Blöcke unbedingt aufeinander folgen würden, sondern nur, wenn der Ausgang der einen Operation das Ausspucken einer bestimmten Sicht oder das Anspringen eines Unterprozesses zur Folge haben könnte.

Wären die einzelnen Schritte so klein gehalten, kann ich sie auch gleich in PHP programmieren.

De Frage ist auch, wo das die Authetisierung reinzupacken wäre. Es macht ja irgendwie auch keinen Snn, in jedem Prozess diese auf neue zu definieren, wo sie doch ohnehin in jedem Prozess stattfindet. Genauso die Validierung der Daten (hast du ja schon angesprochen).

Soweit mal mein Stand der Dinge.
Basti

Basti

In der Ausgabe 1/2006 von "OBJEKTspektrum" gibt es einen Artikel zur Verhaltensmodellierung mit der UML:

http://www.sigs.de/publications/os/2...s_OS_01_06.pdf

Basti