Modellgetriebene Entwicklung

Wie sieht ein typischer Prozess bei der Modell Driven Development (MDD) aus?

Mit AGen überführen Sie Ihre Entwicklungsprozesse in die moderne und effiziente modellgetriebene Entwicklung (MDD – Modell Driven Development). Was zeichnet diese Entwicklungsmethode aus? Wie sieht ein typischer MDD-Prozess aus?

Der Beginn der modellgetriebenen Entwicklung (MDD – Modell Driven Development) ist mit jedem traditionellen Projektstart in der Softwareprogrammierung vergleichbar – der Lösungsarchitekt legt die ersten Aufgaben an und definiert die High-Level-Struktur der Anwendung in enger Abstimmung mit der Fachseite und ihren inhaltlichen Anforderungen:

  1. Die fachlichen Anforderungen werden oder sind in unterschiedlichen Formaten erfasst: formale Use-Case-Diagrammen bis hin zu Excel-Sheets mit Entitäten und Funktionen sowie GUI-Mock-Ups.
  2. Der Architekt legt die konzeptionelle Struktur der Anwendung fest. Hierbei werden architektonische Stile definiert, die die Entwickler später adoptieren werden, wenn sie die Anwendung erstellen.
  3. Der Architekt definiert die Laufzeitumgebungen, in der die Anwendung ausgeführt werden soll. Dies umfasst alle Testumgebungen, einschließlich Komponententests und die finale Produktivumgebung.

 

Wenn diese beiden Aufgaben abgeschlossen sind, hat der Architekt einen guten Überblick, welche Module für die Anwendung entwickelt werden müssen, und die eigentliche MDD kann beginnen:

  1. Gemeinsame Muster und Normen werden identifiziert: Der Architekt identifiziert wiederkehrende Muster in der Anwendung, die entweder aus dem architektonischen Stil oder aus den Anforderungen der Laufzeitplattformen resultieren.
  2. Bereits bestehende MDD-Assets-Entitäten, die wieder verwendet werden können, werden identifziert: Hierbei vergleicht der Architekt die wiederkehrenden Muster mit vorhandenen MDD-Assets und nimmt kleinere Anpassungen an ihnen vor, um sie auch im vorhandenen Projekt nutzen zu können. Diese MDD-Assets können aus vorherigen MDD-Projekten stammen oder von Standard-Tools. Die Entitäten werden in der Regel von der Fachseite in nichtformaler Notation, erfasst, bei einem Produktmanagement mit hohem IT-Kenntnisstand auch in formalen Notationen.
  3. Das Designmodell wird definiert: Hierbei wählt der Architekt das UML-Modell aus, das sich am besten eignet, um die Details einer Komponente für die Anwendungsentwickler zu definieren. Gleichzeitig verfasst er auch eine erste Liste mit Stereotypen für das UML-Profil des Projektes. Um diese Aufgabe zu lösen, muss der Architekt die verschiedenen Arten von UML-Diagrammen (wie Klassendiagramme, Kollaborationsdiagramme, Aktivitätsdiagramme) verstehen und wissen, wann man diese anwendet.
  4. Ein laufzeitunabhängiges Modell für die Komponenten wird definiert: Bei dieser Aufgabe wird das UML-Modell definiert, das die Komponenten der Anwendung in einer laufzeitunabhängigen Umgebung spezifiziert. Dies wird entweder durch den Architekten oder einen erfahrenen Entwickler durchgeführt.
  5. Beispiel-Artefakte werden entwickelt: Bei dieser Aufgabe wird Code für ein typisches Anwendungsszenario bzw. Use-Case geschrieben. Diese Beispiel-Artefakte dienen als eine Art Bauplan für die MDD-Templates und Transformationen.
  6. MDD-Tools werden definiert: Bei dieser Aufgabe werden die MDD-Tools festgelegt, die für das Projekt entwickelt werden müssen. Hierfür wird ein Entwickler mit entsprechender Erfahrung in der Programmierung von MDD-Tools benötigt, der auch den Aufwand für diese Entwicklung abschätzen und kalkulieren kann.

 

Nach diesen Vorarbeiten werden nun die MDD-Tools entwickelt:

  1. Templates werden aus Beispiel-Artefakten und den vorhandenen Modellen extrahiert: Bei dieser Aufgabe bewertet der MDD-Tool-Entwickler die Beispiel-Artefakte und verwendet sie als Grundlage für die Entwicklung der Templates. Diese Templates enthalten den Softwaregenerierungscode, der für jede Instanz des generierten Artefakts identisch ist. Darüber hinaus beinhalten sie Marker, die von der Transformation verwendet werden, um die spezifischen Teile des Artefakts auf Basis des jeweiligen Modells einzufügen.
  2. Design, Code, Test-Transformationen und Muster: Diese Aufgabe erfordert Java- oder C#-Programmierkenntnisse. Für jede Transformation oder Muster muss der MDD Tool-Entwickler C#-Code schreiben, der ein UML-2-Modell oder ein AGen-Modell lesen und entweder das Modell aktualisieren oder die passenden Lücken eines Templates füllen kann, um ein neues Artefakt zu generieren.
  3. MDD-Tooling: Die MDD-Tools müssen in einer Form verpackt werden, die in der Arbeitsumgebung der im Projekt eingebundenen Entwickler installiert werden kann. Hierfür gibt es mehrere Optionen: ein Zip-File mit Anweisungen zum Entpacken der Dateien, Standard Eclipse-Plug-in-Management, RAS-Repository etc.
  4. Dokumentation und Einweisung der Anwendungsentwickler: Der Architekt beschreibt, wie ein Anwendungsentwickler ein Modell programmiert und dann die richtige Transformation wählt, um die richtigen Artefakte zu generieren.
  5. Validierung der MDD-Tool-Chain durch Schlüsselszenarien: Die MDD-Tools modellieren und generieren alle Artefakte, die für jede Laufzeitplattform benötigt werden, um einige Schlüsselszenarien zu validieren.

 

Nun sind die MDD-Tools dazu bereit, vom Anwendungsentwickler bzw. Softwaregenerierungsarchitekten eingesetzt zu werden:

  1. Schulung der Anwendungsentwickler in der Verwendung der MDD-Tools: Die Anwendungsentwickler müssen lernen, wie der neue Entwicklungsprozess funktioniert, wann und wie sie die MDD Tools einsetzen sollten und wie diese in Bezug auf ihre traditionellen Tools in den Prozess hineinpassen.
  2. Entwicklung der Anwendung: Nun beginnen die Anwendungsentwickler mit Unterstützung der MDD-Tools die Anwendung zu programmieren.