Prozesse als Input: Generierung von Web-Portalen

Am Hasso-Plattner-Institut für Softwaresystemtechnik (HPI) in Potsdam fand am 12. April das "Bachelorpodium 2006" statt. Ein Highlight unter den präsentierten Projektergebnissen ist der Software-Generator "Magrathea". Er erzeugt aus Prozessmodelldaten die lauffähige Implementierung eines Internet-Portals. Das Projekt ist ein Teil des Forschungsprojekts PESOA (Process Family Engineering in Service-Oriented Applications), wobei Delta Software Technology (Delta) mit HyperSenses die Basistechnologie liefert. Der Magrathea-Generator setzt ein Systemfamilien-Konzept in die Praxis um, wie es im Generative Programming postuliert wird. Wir stellen es Ihnen im Folgenden genauer vor.

Im Magrathea-Projekt haben sieben Studenten des HPI gearbeitet, unterstützt durch Mitarbeiter des PESOA-Projektpartners ehotel AG, des HPI und von Delta. Drei von ihnen haben in unserer Zentrale in Schmallenberg an einer HyperSenses-Schulung teilgenommen und wesentliche Teile des Generators dort implementiert.

Die Anwendungsdomäne des Magrathea-Generators sind Web-Portale, die Geschäftsprozesse implementieren. Den praktische Anwendungsfall dafür liefert ehotel: ehotel bietet auf seiner Website Dienstleistungen, z.B. eine Hotelsuche, als Webservices an. Dass Webservices Geschäftsprozessen entsprechen, und umgekehrt, ist üblich. Beide werden häufig angepasst, was ihre Wartung teuer macht – ein ideales Anwendungsfeld für Generatoren.

"Computerprogramme für komplexe Geschäftsanwendungen müssen oft aufwändig an individuelle Kundenwünsche angepasst werden. Dadurch entstehen viele ähnliche Produkte, die sich nur in kleinen Teilen unterscheiden. Diese Produktpalette ist entsprechend schwierig zu pflegen, zum Beispiel bei Erweiterungen."
HPI-Student Olaf Märker

Dass Software-Generatoren eingesetzt werden, um die Wartungskosten einer Anwendung niedrig zu halten, ist zunächst auch noch nichts Neues. Spannend wird es, wenn bei der Generierung ein hoher Abstraktionsunterschied überwunden werden muss. Bei Geschäftsprozessen, die als Portale implementiert werden, ist dies eindeutig der Fall: Die Prozesse werden mit der BPMN (Business Process Modeling Notation) modelliert. Diese Notation ist sehr stark auf die inhaltliche Beschreibung eben von Geschäftsprozessen selbst ausgerichtet. Dagegen ist sie nicht für die Beschreibung von Implementierungen geeignet. Eine "codenahe" Modellierung mit BPMN ist, im Gegensatz beispielsweise zu bestimmten UML-Diagrammen, schlichtweg nicht möglich.

Auf der anderen Seite ist ein Web-Portal eine technisch hochkomplexe Implementierung, in der verschiedene Architekturschichten und verschiedene Programmiersprachen und -technologien eine Rolle spielen. Wie hat das Magrathea-Team es geschafft, dafür einen Generator zu entwickeln, der nicht nur auf einen Anwendungsfall (z.B. die Hotelsuche) zugeschnitten ist, sondern jedwede Web-Portale aus entsprechenden BPMN-Modellen erzeugen kann?

Zuerst hat sich das Projektteam für Ruby on Rails als technische Plattform entschieden. Ruby on Rails bietet ein Framework, welches die Entwicklung von Webservices enorm erleichtert. Dieses Framework ermöglichte, das Abstraktionsniveau der Zielplattform des Generators anzuheben: Der Ruby-Code für die komplette Controller-Schicht sowie für Teile der Model- und View-Komponenten (Ruby on Rails propagiert eine Architektur entsprechend Model-View-Controller) wurde vollständig generiert.

Dies allein war jedoch nicht ausreichend, denn auf der anderen Seite stellten die Elemente der BPMN-Prozesse keine Ruby-Konstrukte dar. Die Lösung: Die Implementierung in Bausteine zerlegen, die, wenn man jeden für sich betrachtet, nur geringfügigen, technischen Änderungen unterworfen sind. Das Magrathea-Generator-Team hat die Bausteine, die Abhängigkeiten gegenüber einem (variierenden) Prozessmodell besitzen, als HyperSenses-Patterns realisiert. Bausteine ohne solche Abhängigkeiten wurden manuell programmiert und als generische Komponenten zur Verfügung gestellt.

Auf der einen Seite waren die BPMN-Prozessmodelle definiert worden, auf der anderen die Bausteine der Implementierung, die Abhängigkeiten zu den Prozessmodellen besitzen. Zwischen beiden musste eine Abbildung definiert werden, die die Prozessmodellelemente mit diesen Bausteinen in Beziehung setzt. Dazu war es notwendig, die zu verarbeitenden Geschäftsprozesse als eine Prozessfamilie zu betrachten, d.h. ihre potentiellen Gemeinsamkeiten und Variationspunkte zu definieren. Auf dieser Basis ließen sich Konventionen definieren, durch welche einzelne BPMN-Elemente für die Domäne "Generierung von Web-Portalen" mit bestimmten Implementierungsbausteinen verknüpft werden konnten. Dreh- und Angelpunkt dieser Verknüpfungen war das Metamodell der eingesetzten Technologie HyperSenses.

Das Ergebnis: Ein äußerst leistungsfähiger Generator, der die Prozessmodelldaten im OMG XMI-Format erhält und den passenden Ruby-Code erzeugt. Dies kann sogar zur Laufzeit des Webservice passieren, da Ruby eine interpretative Sprache ist.

Der Einsatz von HyperSenses in diesem Projekt lieferte Delta wichtige Erkenntnisse für die Weiterentwicklung der Technologie. Bei Magrathea handelt es sich nicht um einen Generator nur für einen konkreten Anwendungsbereich (Domäne = Hotelsuche), sondern es geht um einen vergrößerten Anwendungsbereich, eine erweiterte Domäne (= Web-Portale für Geschäftsprozesse). Da der Generator jegliche BPMN-Daten verarbeiten können sollte, war ein entsprechend umfangreiches Metamodell in HyperSenses zu definieren. Dies ist jedoch nur ein einmaliger Aufwand. Da die Prozessmodelle bereits als Konfiguration für die Codegenerierung dienen, entfiel die Erstellung von Konfigurations-Patterns, wie sie sonst bei HyperSenses üblich ist. Die Hauptarbeit der Implementierung bestand in der Definition von Produktions-Patterns. Für ihre Erstellung war ein Prototyp unabdingbar, der manuell erstellt werden musste. Auch dies war ein hoher, aber eben auch nur ein einmaliger Aufwand. Die Anwendung des Generators war hingegen mit nur sehr geringem Aufwand verbunden: Die Projektumgebung, bestehend aus dem Prozessmodellierungstool, übrigens eine Eigenentwicklung des HPI, HyperSenses sowie Ruby on Rails, wurde als Produktionsstraße realisiert, innerhalb der sich die Anwendung des Generators automatisieren ließ.

In PESOA wird zwischen den Entwicklungsarbeiten für die Prozessfamilie insgesamt und den Arbeiten für die Erstellung einer Instanz, also einer Applikation, unterschieden: Wir sprechen von "Domänen-Engineering" und "Application-Engineering". Was die jeweiligen Aufwände angeht, entspricht das Magrathea-Projekt den Bewertungskriterien von PESOA: Die domänenbezogenen Aufwände dürfen durchaus hoch sein – sie müssen sich erst in Bezug auf alle erzeugten Anwendungen rentieren. Die Entwicklung einer einzelnen Anwendung muss sich hingegen für sich rechnen, also entsprechend gering sein. Letzteres ist bei Magrathea eindeutig der Fall. Auch wenn auf der anderen Seite das Domänen-Engineering zum Teil aufwändig war – es hat sich gelohnt!

Die Entwicklung eines leistungsfähigen Tools mit mehreren Projektpartnern an mehreren Standorten unterstreicht den Anspruch sowohl des HPI wie auch von Delta, Forschung und Praxis so eng wie möglich miteinander zu verzahnen.

Über den Magrathea-Generator sowie das Bachelorpodium am HPI wurde an verschiedenen Stellen berichtet – hier können Sie weiterlesen:

Magrathea-Seite des HPI
Innovations-Report
Wissenschaftsjahr 2006
Land der Ideen