Architekturzentrierte, modellgetriebene Softwareentwicklung für das Zikula Application Framework

PHP braucht keinen Code
Kommentare

Die Entwicklung wird somit auf eine abstraktere Ebene gehoben: man braucht nicht mehr umständlich in Bytes, Strings und for-Schleifen zu denken, sondern ein Problem kann auf einfache Weise modelliert

Die Entwicklung wird somit auf eine abstraktere Ebene gehoben: man braucht nicht mehr umständlich in Bytes, Strings und for-Schleifen zu denken, sondern ein Problem kann auf einfache Weise modelliert werden. Anschließend kann das Modell dann weiterverarbeitet werden. Durch Transformationen wird das Modell mit zusätzlichen technischen Informationen angereichert, bis abschließend ausführbarer Quelltext erzeugt wird. Dies erhöht die Entwicklungsgeschwindigkeit signifikant. Wofür Sie zuvor Stunden brauchten, dafür genügen auf einmal ein paar Minuten. Es wird buchstäblich möglich, Erweiterungen am Fließband zu produzieren. Auch die Wartbarkeit und damit die Softwarequalität werden entscheidend verbessert, da sich Änderungen zentral in den Transformationen pflegen lassen.

Vereinfacht ausgedrückt, basiert die automatische Verarbeitung von Modellen auf Metaklassen. Für jedes Element im Metamodell, also jeden Bestandteil der domänenspezifischen Sprache, existiert solch eine Metaklasse. Durch Instantiierung aller Modellelemente anhand ihrer korrespondierenden Metaklassen wird ein Modell als Objektgraf im Speicher abgebildet. Bei fachlichen Änderungen, zum Beispiel einer Neuerung in einer bestimmten Kundenbeziehung, muss nur das entsprechende Modell geändert und der Code neu erzeugt werden, um eine aktuelle Version der gleichen Anwendung zu erhalten. Von Änderungen in Bezug auf technische Aspekte, wie der Implementierung eines Kontos, profitieren nach Anpassung der Transformation alle Modelle.

Modelle für Module

Für den PHP-Bereich gab es bisher keine Werkzeuge, die eine modellgetriebene Entwicklung möglich machen. Das Zikula Application Framework steht unter der GPL und bietet dem Entwickler ein umfangreiches Arsenal an Werkzeugen (siehe Kasten „Zikula Facts“). Auf Basis offener Standards wie der Datenbankabstraktion ADOdb und der Templating Engine Smarty besticht es vor allem durch seine Modularität und Flexibilität. Zum Einsatz kommt es hauptsächlich zur Realisierung von interaktiven Portalapplikationen und webbasierten Geschäftsanwendungen.

Das im Folgenden vorgestellte Projekt ModuleStudio realisiert eine generative Architektur zur Entwicklung von Modulen, beziehungsweise Erweiterungen für Zikula. Es basiert auf Eclipse und ist daher auf verschiedenen Systemen lauffähig, darunter Windows, Linux und MacOS. Benötigt wird lediglich Java in der Version 6, anschließend läßt sich das zuvor entpackte ModuleStudio einfach starten. Um die Komplexität der Modelle nicht ausufern zu lassen, nimmt ModuleStudio eine Teilung der Domäne „Zikula-Erweiterungen“ in mehrere technische Subdomänen vor. Jede dieser Subdomänen entspricht einer typischen Schicht gängiger Applikationen, die das MVC-Muster (Model View Controller) implementieren:

  • Die „Persistenzschicht“ bildet Datenobjekte (Entities) und deren Relationen (Relationships) ab. Man spricht daher typischerweise von einem ER-Modell.
  • Darauf basieren die Elemente der „Verhaltensschicht“ und fügen objektspezifische Geschäftslogik hinzu. Persistenz und Verhalten bilden gemeinsam das Model in der Architektur.
  • Die „Prozesskontrollschicht“ definiert generische Anwendungsfälle für die verschiedenen Objekttypen. Sie bildet damit die Controller ab.
  • Zur Darstellung (View) benutzen diese Anwendungsfälle Templates, deren Modellierung in der „Präsentationsschicht“ vorgenommen wird.

Abbildung 2 fasst diese Aufteilung zusammen. Für jede Subdomäne existiert eine eigene DSL, für die Präsentation ist also ein anderer Editor möglich als für die Persistenz.

Abb. 2: Aufteilung in technische Subdomänen

ModuleStudio kapselt die einzelnen Subdomänen in verschiedenen Containerelementen, die über Relationen verbunden sind. Damit das Gesamtmodell insgesamt auch sinnvolle Informationen enthält, existiert in den Metamodellen eine Sammlung verschiedener Validierungsregeln, die dafür sorgen, dass architektonische Erfordernisse eingehalten werden. Beispielsweise setzt ein Geschäftsobjekt immer ein gleichnamiges Persistenzobjekt in dem Datencontainer voraus, den der Verhaltenscontainer als Datenquelle verlinkt hat. Die Architekturkonformität von modellierten Erweiterungen wird also nicht nur gefördert, sondern sogar erzwungen – bestimmte Fehlerarten werden komplett ausgeschlossen. Dazu zählen beispielsweise syntaktische Probleme oder Flüchtigkeitsfehler.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -