Architekturzentrierte Modellgetriebene Softwareentwicklung

2 MDSD, AC-MDSD und Begriffsdefinitionen 7
Einen anderen Weg beschreitet die modellgetriebene Vorgangsweise, bei der die
entworfenen Modelle den selben Stellenwert wie der Quellcode einnehmen, da
sie gleichbedeutend mit ihm sind. Der Übergang vom Modell zum Code wird
automatisiert mit Hilfe eines Generators und einer Reihe definierter Transfor-
mationsvorschriften vorgenommen. Diesen Ansatz nennt man Modellgetriebene
Softwareentwicklung oder Model Driven Software Development kurz MDSD.
Bei MDSD werden Modelle als abstrakt und formal zugleich angesehen. Sie
sind abstrakt, da implementierungsspezifische Details weggelassen werden.
Die Modelle zeigen ausschließlich Eigenschaften, die das Verständnis für die
Problemstellung fördern. Formal sind diese Modelle, da sie sich an einer Domain
Specific Language (DSL) orientieren.
Bei MDSD stehen die benutzten Modelle immer im Kontext eines abgegrenzten
Problemraums, der Domäne. Die Konzepte dieser Domäne werden mit einer
für sie spezifischen Sprache beschrieben, der DSL. Eine DSL kann zum Beispiel
durch ein UML-Profil abgebildet werden.
Ein Hauptbestandteil der DSL ist das Metamodell der Domäne (siehe Abschnitt
2.3.1). Es ist auch dem Generator bekannt. Auf diese Weise kann aus dem Modell
bedeutend mehr ” herausgeholt“ werden, als es mit einem allgemeinen domänenu-
nabhängigen Generator der Fall ist. Der MDSD-Ansatz unterscheidet sich somit
auch auf Seite der Generatoren von aktuellen CASE-Tools, bei denen zumeist
ein ” One Size fits all!“-Ansatz verfolgt wird. Hier wird nicht auf den spezifischen
Einsatzzweck einer Software geachtet, sondern das Generat folgt stets den selben
Designparadigmen. Dadurch ist einerseits der erzielbare Generierungsfaktor
niedriger als bei einem domänenspezifischen Ansatz und andererseits wird mit
hoher Wahrscheinlichkeit den geforderten Qualitätskriterien nicht Genüge getan.
Um die Generierung zu vereinfachen und den erzeugten Quellcode nicht auf der
” nackten“ Programmiersprache aufbauen zu müssen, werden domänenspezifische
Plattformen eingesetzt. Sie bilden den zweiten Eckpfeiler von MDSD. Eine Platt-
form setzt sich aus Komponenten und Frameworks zusammen. Diese Bestandteile
sind für alle Anwendungen einer Domäne gleich. Der Einsatz höherwertiger APIs
erleichtert den Entwurf der nötigen Transformationsvorschriften ungemein, da
dem Generat ein Stück des Weges entgegengekommen wird.
Abbildung 2.1 stellt die Zusammenhänge bei der Entwicklung mit MDSD dar.
Betrachtet man den Quellcode eines beliebigen Mitglieds einer Softwaresys-