oAW Workshop Teil 1 – MDSD

Am Donnerstag und Freitag habe ich einen 2-tägigen Workshop zu openArchitectureWare besucht. In zwei Blogeinträgen berichte ich über das Gelernte. (zu Teil 2)

Teil1: Einführung in die MDSD

Modellgetriebene Softwareentwicklung

Mit den steigenden non-funktionalen Anforderungen und zuliebe “schönen” Designs, OOP, moderner Sprachen und komplizierten Patterns wird die Fachlogik von schematischem Architekturcode ertränkt und ist kaum noch auffindbar.

Durch MDSD soll diese oft nötige Komplexität verborgen werden. Der Fokus geht zurück auf die Fachlogik; um die technischen Details kümmert sich der Generator. So lassen sich Redundanzen im Code vermeiden und es lässt sich sicherstellen, dass Architekturrichtlinien eingehalten werden. Als geliebter Nebeneffekt sinkt die Fehlerrate während die Produktivität besonders in großen Projekten schnell steigt.

Wenn ein Technologiewechsel stattfinden soll, liegen die anzupassenden Details im Generator. Die Wiederverwendung eines Models für eine vollständig andere Zielplattform ist kaum realistisch. Man kann jedoch mit relativ überschaubarem Aufwand Teilaspekte der Architektur anpassen oder austauschen.

Begriffe

Domäne: Alle Aspekte einer Applikation werden in Domänen eingeteilt uns seperat modelliert. Die richtige Aufteilung ist grundlegend für den Erfolg von MDSD.

Modell: Ein abstrahiertes Abbild eines Teilaspektes der Realität. Bei Modellen ist wichtig nur einen sehr deutlich abgegrenzten Aspekt zu betrachten. Aus mehreren eindeutigen Modellen entsteht das Gesamtbild.

Metamodell: Beschreibt die Struktur für ein Modell. Im Vergleich zu Objektorientierung ist das Metamodell die Klasse, wärend das Modell die Instanz ist. Ein Metamodell ist in vielen Fällen die Implementierung einer DSL, d.h. die Verwendung fachlicher Begrifflichkeiten der Domäne sind erwünscht.

Metametamodell: Ein selbstbeschreibendes meist recht einfaches Modell zur Beschreibung der Grammatik von Metamodellen. Hier wird keine Rücksicht auf fachliche Domänen genommen, sondern der Bezug ist rein technisch. Beispielsweise MOF oder EMF. Diese nimmt man normalerweise als gegeben, und fängt nicht an sie selbst zu bauen.

Die funktionsweise von MDSD

Aus dem formalen Modell wird gewöhnlicherweise ein auf die technische Problemstellung abgestimmtes Zwischenmodell generiert. Daraus erstellt der Generator Code um diesen mit manuell geschriebener Fachlogik zusammenzuführen. Das Ergebnis ist lauffähiger Code.

MDSD vs. MDA

Die MDA ist ein OMG-Standard, der sehr teoretisch ist. In MDA wird optimalerweise vollkommen platformabhängig definiert, während in MDSD gerne etwas mehr Bezug auf die Platttform, den Prozess und die Quellcodegenerierung genommen wird.

Domänenspezifische Sprachen (DSL)

DSLs werden auf eine bestimmte Problem-Domäne zugeschnitten und sind somit ein Metamodell. Eine DSL muss eindeutig sein, sprich eine formale Syntax und eine formale Semantik besitzen.

Gute DSLs sind einfach und nicht redundant. Sie reflektieren die Sprache des Domänenexperten und sind von solchen zumindest lesbar. Dies macht Teile der Dokumentation überflüssig.

Tools wie Xtext, EMF/Ecore oder Language Workbench helfen bei der Erstellung von DSLs. Bei der Konzeption muss darauf geachtet werden, dass sie für Änderungen offen bleibt.

DSLs und UML

Oft werden DSLs mit UML2 beschrieben. Dies hat den wesentlichen Vorteil, dass UML ein Standard ist und viele grafische Tools beim erstellen der Modelle unterstützen. Leider ist UML praktisch nicht einschränkbar, sondern nur durch Profile und Beschränkungen erweiterbar. Da diese von Tools nicht durchgehend unterstützt werden, ist es jedoch so gut wie unmöglich eindeutige DSLs zu definieren.

Das einzige Format, das zum Austausch von UML-Modellen taugt ist EMF UML2. Der Export in dieses Format wird jedoch noch nicht von allen Toolherstellern unterstützt.

DSLs mit EMF/Ecore

Ein DSL kann it EMF modelliert werden. Eine grafische Unterstützung kann man über GMF erstellen.

DSLs mit xtext

Xtext ist eine DSL zur Beschreibung der Grammatik von textuellen DSLs. Xtext ist Teil des oAW-Projektes und bietet dem Entwickler Möglichkeiten zur formalen Validierung seiner Modelle sowie in Eclipse integrierte Editoren mit Intellisense, etc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s