Architekturzentrierte, modellgetriebene Softwareentwicklung für das Zikula Application Framework

PHP braucht keinen Code
Kommentare

Seit einigen Jahren gibt es einen regelrechten Hype um Frameworks, die Entwicklern viel Arbeit abnehmen und ihnen dabei helfen, bestimmte Regeln einzuhalten. Schnelle erste Erfolge beim Aufbau kompletter Webanwendungen sind der Hauptgrund für diese Begeisterung. Unbeachtet bleibt dabei aber meist die Frage nach der langfristigen Wartbarkeit: wie lassen sich eigene Entwicklungen einfach und dauerhaft an Änderungen des dahinterstehenden Frameworks anpassen? Dieser Artikel zeigt einen Ansatz, der auf den Prinzipien der modellgetriebenen Softwareentwicklung basiert.

Ob CakePHP, Drupal oder Symfony – heutzutage sind Frameworks in der PHP-Welt in aller Munde. Auch wenn die internen Funktionsweisen und Paradigmen unterschiedlich sind, verfolgen doch alle Frameworks das gemeinsame Ziel, die Entwicklung von individuellen Anwendungen zu vereinfachen. Typische Schlagworte sind hier unter anderem APIs, MVC-Muster oder Komponentenmodelle. Bei einigen Systemen kommt auch ein so genanntes Scaffolding zum Einsatz, um mit minimalem Aufwand Prototypen für Erweiterungen zu erstellen.

Während sich die verschiedenen Lösungen darin überbieten, die Entwicklung am schnellsten, einfachsten oder flexibelsten zu ermöglichen, wird oft verschwiegen, wie die Anwendungen auf lange Sicht aktuell und konform gehalten werden können, ohne dass Aufwand und Kosten in die Höhe schießen. Mit der Zeit entstehen größere Mengen an Erweiterungsmodulen, die regelmäßig an neue Versionen und damit verbundene architektonische Änderungen angepasst werden müssen. Dies betrifft Entwickler von freien Modulen ebenso wie Agenturen, die Anwendungen für ihre Kunden warten. Wie kann gewährleistet werden, dass alle verfügbaren Erweiterungen den qualitativen Ansprüchen des Frameworks genügen – und das am besten noch dauerhaft und ohne unnötige Fleißarbeit zur mehrmaligen Lösung wiederkehrender Probleme?

Weg mit der Technik!

Egal ob Sie einen Shop, ein Forum oder ein Auftragssystem programmieren – Sie müssen immer den gleichen Regeln Ihres Frameworks folgen. Wenn Sie bereits für ein System mehrere Erweiterungen geschrieben haben, haben Sie sicher auch schon einmal gedacht: muss ich das wirklich jedes Mal wieder tun? Unterschiede existieren vor allem in den fachlichen Daten: Produkte sind keine Foreneinträge und beides sind keine Aufträge. In den meisten Anwendungen kann man Daten anlegen, editieren und löschen (CRUD = create, update, delete). Je nachdem, ob es sich dabei zum Beispiel um ein Forum oder einen Shop handelt, sind die Workflows unterschiedlich, die zum Anlegen, Editieren und Löschen der Daten nötig sind. Es liegt nahe, dass sich die eigentliche Entwicklung auf die fachlichen Bestandteile konzentrieren könnte, die eine Erweiterung von anderen unterscheidet. Die Aufgabe ist es nun, die gemeinsamen Anteile zu kapseln und eine Notation zu finden, welche die verbleibenden Anteile kompakt und präzise ausdrücken kann.

Häufig kommen modellbasierte Ansätze zum Einsatz, um Softwaresysteme zu beschreiben. Mit der UML (Unified Modeling Language) lassen sich verschiedene Sichten auf ein Programm in Diagrammform angeben. Typischerweise können daraus jedoch entweder nur simple Klassenskelette erzeugt werden, oder es werden zusätzliche Informationen in den Modellen nötig. Um die Diagramme mit Fachwissen aufzuwerten, existieren verschiedene Ansätze wie die OCL (Object Constraint Language). Aufgrund ihres generischen Charakters hat sich die UML bei der Modellierung kompletter Anwendungen jedoch als komplex und wenig intuitiv erwiesen, insbesondere für beteiligte Fachanwender.

Bei der modellgetriebenen Softwareentwicklung (MDSD – Model-Driven Software Development) ist der Ansatz anders: ein Softwaresystem wird durch ein Modell verkörpert, das mit einer domänenspezifischen Sprache (DSL – Domain Specific Language) erstellt wird. Jedes Modell bezieht sich damit auf einen bestimmten eingegrenzten Einsatzbereich, eine Domäne. Das bedeutet, dass jedes im Modell vorkommende Element eine bestimmte Bedeutung im Kontext der Domäne hat. Eine Bank könnte zum Beispiel mit einer DSL für ihre Prozesse verschiedene Kundenszenarien modellieren. Dabei ist jeweils schon vorher festgelegt, was einen Kunden beschreibt und in welcher Beziehung er zu einem Berater oder einem Konto steht.

Eine DSL ist also speziell auf ihren Anwendungsbereich zugeschnitten. Im Groben besteht sie aus einem Metamodell und einem Editor (vgl. Abbildung 1). Das Metamodell legt den Bauplan für ein Modell fest und bestimmt, welche Elemente darin enthalten sein und auf welche Weise sie miteinander interagieren dürfen. Der Editor dient als Schnittstelle zum Entwickler und erlaubt das Benutzen der Sprache, um Modelle zu definieren. Das kann entweder in Textform, beispielsweise in Form einer XML-basierten Syntax, oder auch in grafischen Editoren geschehen. Somit kann eine domänenspezifische Notation auf die Bedürfnisse und die die Umgebung der Zielgruppe hin optimiert werden, um die Bedienung zu erleichtern.

Abb. 1: Domänenspezifische Sprachen
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -