Architekturzentrierte, modellgetriebene Softwareentwicklung für das Zikula Application Framework

PHP braucht keinen Code
Kommentare

Die Hyperlinks in der oberen Leiste rufen alle den view-Anwendungsfall auf, entsprechen aber verschiedenen Objekttypen. Hier zeigt sich, dass durch die Benutzung des Komponentenmodells eine Trennung zwischen

Die Hyperlinks in der oberen Leiste rufen alle den view-Anwendungsfall auf, entsprechen aber verschiedenen Objekttypen. Hier zeigt sich, dass durch die Benutzung des Komponentenmodells eine Trennung zwischen Anwendungsfällen und den betroffenen Objekten erreicht wird. Mithilfe der Überschriften in den Tabellenspalten kann der Benutzer die Liste der Datensätze sortieren. Auf der rechten Seite befinden sich Links zu weiteren Anwendungsfällen. Der erste heißt display und führt zu einer Detailansicht des betroffenen Objektes. Der zweite heißt edit und veranlasst ebenso wie der über der Tabelle stehende Link zum Anlegen eines neuen Anbieters die Bearbeitung einer Objektinstanz. Abbildung 10 zeigt das dem Objekttyp Anbieter entsprechende Formular.

Abb. 10: Änderungsformular

Je nach Datentyp eines Feldes wird ein anderes Plug-in verwendet, so existieren beispielsweise spezielle Felder für Zahlen oder Datumswerte. Falls die Eingaben des Benutzers nicht gültig sind, erscheinen entsprechende Hinweise (vgl. Abbildung 11).

Abb. 11: Validierung

Die generierten Module verfügen über einige weitere Funktionen, zum Beispiel setzen sie eine objektbasierte Klasse zum Filtern von Listenansichten ein. In Zikula gängige Funktionalitäten wie Hook-Aufrufe werden ebenso unterstützt wie das PageLock-Modul zur Verhinderung nebenläufiger Manipulationen gleicher Objekte. Die Anpassung des generierten Moduls erfolgt auf mehreren Ebenen (vgl. Kasten „Zikula Facts“). Zum einen lassen sich kosmetische Anpassungen mithilfe des Overriding-Mechanismus in die Smarty-Templates einpflanzen, um sie vor dem Überschreiben durch neue Versionen zu schützen. Zum anderen wird die Geschäftslogik separat in Spezialisierungen der generierten Komponentenklassen implementiert. Doch auch ohne individuelles Customizing macht es enormen Spaß, mit wenigen Mausklicks Welten zu bewegen. Hat man einmal ein Modell mit zehn Tabellen zu durchschnittlich ebenso vielen Feldern in einer halben Stunde gebastelt und sieht dann allein die generierten Tabellendefinitionen und Formulare, kann man erahnen, wie produktiv auf einmal gearbeitet werden kann.

Software unkaputtbar!

Woraus bestehen nun Unterschiede und Vorteile gegenüber anderen Methoden, um schnell und einfach Prototypen für eigene Erweiterungen zu erstellen? Abbildung 12 zeigt das Procedere von ModuleStudio noch einmal im Überblick: der Entwickler beschreibt mithilfe des Editors mehrere Modelle, die jeweils verschiedene Ausprägungen der durch das Metamodell spezifizierten, domänenspezifischen Sprache repräsentieren. Der Generator wendet verschiedene Transformationen an, um aus dem Modell den Quelltext für das korrespondierende Modul zu erzeugen.

Abb. 12: Arbeitsweise mit ModuleStudio

Mit den Domänenmodellen werden Anwendungen komplett unabhängig von ihrer technischen Implementierung und damit in einer langlebigen Form beschrieben. Aus neuen Generatorversionen kann jederzeit eine aktualisierte Anwendungsversion generiert werden, die den neuesten Anforderungen der Framework-Architektur genügt. Dabei werden nicht nur Fehler zentral behoben, sondern auch neue Funktionen stehen allen Anwendungen zur Verfügung. Während der Generator sukzessive verbessert wird, steigt damit implizit auch die Codequalität aller darauf basierenden Anwendungen, die alle von bewährten Mustern profitieren können. Insbesondere in Kombination mit den gezeigten Validierungsmöglichkeiten stellt dies einen entscheidenden Schritt zu der qualitativen Verbesserung von Drittmodulen aus Sicht des Grundsystems dar, die langfristig sogar zeitaufwändige Zertifizierungen bei vielen Open-Source-Projekten überflüssig machen könnten.

Ein phantastischer Aspekt dieser Vorgehensweise besteht darin, dass sich die Vorteile mit jedem neuen Modell, beziehungsweise jeder neuen Applikation, multiplizieren. Jede einzelne Tätigkeit auf abstrakter Ebene bedeutet gesparte Zeit, weniger Kosten und mehr Produktivität. Wenn eine Agentur beispielsweise rund fünfzig verschiedene Erweiterungen für projektspezifische Zwecke modelliert hat, spart sie natürlich bei jeder einzelnen Anwendung dieser Softwaresystemfamilie die Implementierungs- und Testaufwände, sowohl bei der initialen Generierung als auch bei späteren Aktualisierungen. Diese schafft eine ideale Voraussetzung zur Konstruktion wartbarer Produktpaletten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -