Die Model-Driven Architecture (MDA) ist ein Standard der Object Management
Group (OMG), der in den vergangenen Jahren stark vorangetrieben
wurde. Die OMG verspricht sich, und vor allem den Anwendern der MDA eine
Effizienzsteigerung im Softwareentwicklungsprozess. Erreicht werden soll
diese Positiventwicklung durch unterschiedliche Ansätze, die von der MDA
verfolgt werden. Zum einen wird die Anhebung des Abstraktionsniveaus als
Treiber für eine schnellere Entwicklung propagiert. Das Abstraktionsniveau
soll von der momentan etablierten Codeebene auf die Ebene eines formalen
Modells angehoben werden. Für die Modellierung schlägt die OMG eigene
Standards vor, die schon länger Einsatz in der Softwareentwicklung finden.
Hierzu zählen beispielsweise die Unified Markup Language (UML) und die
Object Constraint Language (OCL). Des Weiteren verspricht die OMG eine
weitgehende Automatisierung der Codegenerierung aus den Modellen, die
während des Entwicklungsprozesses erstellt werden. Dies soll den Prozess
auf der einen Seite beschleunigen und auf der anderen Seite standardisieren,
um leichter anpassbaren Code zu bekommen. Zu guter Letzt ist ein gestecktes
Ziel der MDA die parallele Entwicklung eines Systems für unterschiedliche
Plattformen, wie .NET, J2EE oder CORBA. Dies soll durch die
technologie-, und plattformunabhängige Modellierung ermöglicht werden.
Diesen Zielen und Versprechen der OMG stehen die Realitäten der Informatik
sowie der Wirtschaft gegenüber. Daraus ergeben sich Forschungsbereiche,
die bisher unzureichend bedient wurden. Da die OMG nur das theoretische
Framework für die MDA, sowie die zu verwendenden Standards vorgibt,
ist die praktische Implementierung den Softwareunternehmen überlassen.
Nun stellt sich auf der einen Seite die Frage, ob die Beschreibungssprachen
der Informatik schon mächtig genug sind, um die Modellierung von Systemen
auf derart abstraktem Niveau durchzuführen und auf der anderen Seite, ob
die Unternehmen dazu bereit und in der Lage sind, MDA-Werkzeuge effektiv und effizient in ihren Softwareentwicklungsprozess zu integrieren, um die
gewünschten Erfolge zu erzielen. Die Problematik der Informatik wird in der
folgenden Arbeit nur vereinzelt mit einbezogen. Das Hauptaugenmerk liegt
vor allem auf der wirtschaftlichen Fragestellung.
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1 Einleitung
1.1 Themenmotivation
1.2 Aufbau und Ziel der Arbeit
2 Grundlagen der Model-Driven Architecture
2.1 Definitionen
2.2 Technischer Reifegrad der Model-Driven Architecture
2.2.1 Konzepte
2.2.2 Umsetzung
2.2.3 Standards
2.3 Einordnung und Einsatz der Model-Driven Architecture
2.3.1 Einordnung der Model-Driven Architecture in die Historie der Softwareentwicklung
2.3.2 Einsatz der Model-Driven Architecture
2.4 Propagierte Ziele und Versprechen der Model-Driven Architecture
2.4.1 Lösungsansätze für Probleme im Softwareentwicklungsprozess
2.4.2 Potenzial der Model-Driven Architecture
3 Wirtschaftlichkeitsaussagen zur Model-Driven Architecture
3.1 Analyserahmen – Messung der Wirtschaftlichkeit in der Softwareentwicklung
3.2 Untersuchungsansatz
3.2.1 Problemeingrenzung: Gegenüberstellung der Model-Driven Architecture und des Computer-Aided Software Engineerings
3.2.2 Wirtschaftlichkeitsbetrachtungen des Computer-Aided Software Engineerings
3.2.3 Erste Wirtschaftlichkeitsbetrachtungen der Model-Driven Architecture
3.3 Thesenbildung zur Model-Driven Architecture
3.3.1 These – Verhältnis des Computer-Aided Software Engineerings zur Model-Driven Architecture
3.3.2 These – Kostenstruktur, Kostenarten und Personalstruktur
3.3.3 These – Prozessausgereiftheit , Qualitätsverbesserung und Kostenreduktion
3.3.4 These – Projektkommunikation und Entwicklungsgeschwindigkeit
3.3.5 These – Plattformportabilität und Wartungsintensität
3.3.6 These – Lernkurve und Projektnähe
3.3.7 These – Offshoringpotenzial
4 Untersuchung der Thesen zur Model-Driven Architecture
4.1 Untersuchungsdesign
4.2 Untersuchungsergebnisse
4.3 Fazit und kritische Würdigung
5 Zusammenfassung und Ausblick
5.1 Zusammenfassung
5.2 Ausblick
Literaturverzeichnis
Anhang
Anhang 1: Interviewleitfaden (Wirtschaft)
Anhang 2: Interviewleitfaden (Wissenschaft)
Abbildungsverzeichnis
Abb. 2.2.1/1 Logo der Model-Driven Architecture
Abb. 2.2.1/2 Modellabhängigkeiten in der modellgetriebenen Architektur
Abb. 2.2.1/3 Transformation unter Zuhilfenahme eines Plattformmodells
Abb. 2.2.2/1 Elaboratorischer Ansatz der modellgetriebenen Architektur
Abb. 2.2.2/2 Translatorischer Ansatz der modellgetriebenen Architektur
Abb. 2.2.2/3 Plattformunabhängiges Modell
Abb. 2.2.2/4 Plattformabhängiges Java-Modell
Abb. 2.2.2/5 Transformationsdefinition
Abb. 2.2.2/6 Visualisierung der beispielhaften Transformation
Abb. 2.2.3/1 Executable UML
Abb. 2.3.1/1 Abstraktionsgrad in der Softwareentwicklung
Abb. 2.3.2/1 Hebel und Auswirkungen des Model-Driven Offshoring
Abb. 2.3.2/2 Szenarien zum Einsatz des Model-Driven Offshoring
Abb. 2.4.1/1 Softwareentwicklungszyklus
Abb. 3.1/1 Wertschöpfungskette in der Softwareentwicklung
Abb. 3.1/2 Aufwandsstruktur im Lebenszyklus
Abb. 3.2.2/1 Trade-Off-Beziehung zwischen Qualität und Effizienz
Abb. 3.3.5/1 Erweiterter First Copy Cost Effect
Abb. 5.2/1 Untersuchungsframework der Fallstudien
Tabellenverzeichnis
Tab. 3.2.2/1 Übersicht der Studien zur Wirtschaftlichkeit des Computer-Aided Software Engineerings
Tab. 3.2.3/1 Übersicht der Studien zur Wirtschaftlichkeit der Model-Driven Architecture
Tab. 3.3.2/1 Aufwandsverschiebung im Lebenszyklus des Computer-Aided Software Engineerings
Tab. 4.2/1 Auswertung der Experteninterviews
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
In Kapitel 1.1 wird das Thema motiviert und in die Forschungslandschaft eingebettet, bevor Kapitel 1.2 den Aufbau der Arbeit, sowie die Ziele, die mit dieser Arbeit verfolgt werden aufzeigt.
1.1 Themenmotivation
Die Model-Driven Architecture (MDA) ist ein Standard der Object Management Group (OMG), der in den vergangenen Jahren stark vorangetrieben wurde. Die OMG verspricht sich, und vor allem den Anwendern der MDA eine Effizienzsteigerung im Softwareentwicklungsprozess. Erreicht werden soll diese Positiventwicklung durch unterschiedliche Ansätze, die von der MDA verfolgt werden. Zum einen wird die Anhebung des Abstraktionsniveaus als Treiber für eine schnellere Entwicklung propagiert. Das Abstraktionsniveau soll von der momentan etablierten Codeebene auf die Ebene eines formalen Modells angehoben werden. Für die Modellierung schlägt die OMG eigene Standards vor, die schon länger Einsatz in der Softwareentwicklung finden. Hierzu zählen beispielsweise die Unified Markup Language (UML) und die Object Constraint Language (OCL). Des Weiteren verspricht die OMG eine weitgehende Automatisierung der Codegenerierung aus den Modellen, die während des Entwicklungsprozesses erstellt werden. Dies soll den Prozess auf der einen Seite beschleunigen und auf der anderen Seite standardisieren, um leichter anpassbaren Code zu bekommen. Zu guter Letzt ist ein gestecktes Ziel der MDA die parallele Entwicklung eines Systems für unterschiedliche Plattformen, wie .NET, J2EE oder CORBA. Dies soll durch die technologie-, und plattformunabhängige Modellierung ermöglicht werden.
Diesen Zielen und Versprechen der OMG stehen die Realitäten der Informatik sowie der Wirtschaft gegenüber. Daraus ergeben sich Forschungsbereiche, die bisher unzureichend bedient wurden. Da die OMG nur das theoretische Framework für die MDA, sowie die zu verwendenden Standards vorgibt, ist die praktische Implementierung den Softwareunternehmen überlassen. Nun stellt sich auf der einen Seite die Frage, ob die Beschreibungssprachen der Informatik schon mächtig genug sind, um die Modellierung von Systemen auf derart abstraktem Niveau durchzuführen und auf der anderen Seite, ob die Unternehmen dazu bereit und in der Lage sind, MDA-Werkzeuge effektiv und effizient in ihren Softwareentwicklungsprozess zu integrieren, um die gewünschten Erfolge zu erzielen. Die Problematik der Informatik wird in der folgenden Arbeit nur vereinzelt mit einbezogen. Das Hauptaugenmerk liegt vor allem auf der wirtschaftlichen Fragestellung, das wird jedoch in Kapitel 1.2 detaillierter erläutert.
Interessant ist, dass einerseits durch die OMG bereits eine Reihe von Erfolgsgeschichten abgeschlossener MDA-Projekte veröffentlicht wurde, auf der anderen Seite im Rahmen dieser Arbeit aber kein Unternehmen gefunden werden konnte, das bereit war an einer Wirtschaftlichkeitsbetrachtung eines speziellen MDA-Projektes teilzunehmen. Für diese Herangehensweise scheint es also noch etwas zu früh zu sein. Aus diesem Grund erschien es für diese Arbeit sinnvoller auf theoretischer Basis Thesen zur MDA herzuleiten und deren Stoßrichtung in einer ersten Befragungsrunde mit Experten zu beurteilen. Der genaue Aufbau der Arbeit und die verfolgten Ziele werden im folgenden Kapitel dargestellt.
1.2 Aufbau und Ziel der Arbeit
Neben dem einleitenden Teil in Kapitel 1 und der Schlussbetrachtung in Kapitel 5 ist der Hauptteil der Arbeit in drei Bereiche gegliedert: Theoretische Grundlagen der MDA, Wirtschaftlichkeitsbetrachtung zur MDA im Vergleich zu CASE, sowie die Herleitung von Thesen zur MDA und Auswertung der Befragungsergebnisse.
Die Theoretischen Grundlagen werden in Kapitel 2 und den darin enthaltenen Unterkapiteln geschaffen. Ziel ist es zuerst eine Arbeitsdefinition der MDA herzuleiten, das geschieht in Kapitel 2.1. Danach wird der technische Reifegrad der Konzepte und Standards beschrieben, die der MDA zugrunde liegen. Besonderes Augenmerk wird dabei auf die verwendeten Modelle und Transformationen der MDA gelegt. Im Anschluss daran erfolgt in Kapitel 2.3 zuerst eine Einordnung der MDA in die Historie der Softwareentwicklung. Das verdeutlicht die Treiber, die zur Entwicklung der Model-Driven Architecture geführt haben. Im Anschluss zeigen erste Anwendungsbeispiele, dass die MDA in manchen Bereichen durchaus schon Anwendung gefunden hat. Kapitel 2.4 beschäftigt sich im Detail mit den propagierten Zielen und Versprechen der MDA im Sinne der OMG. Ziel hierbei ist es zu zeigen, wo im herkömmlichen Softwareentwicklungsprozess Probleme liegen und wie die MDA dazu beitragen soll diese zu beseitigen oder zumindest zu mindern.
Kapitel 3 und dessen Unterkapitel stehen ganz im Zeichen der Wirtschaftlichkeitsbetrachtungen in der Softwareentwicklung sowie der Entwicklung von Thesen die den Einfluss der MDA auf die Softwareentwicklung beschreiben. Neben Grundlagen der Wirtschaftlichkeitsmessung in der Softwareentwicklung, die vor allem in Kapitel 3.1 gelegt werden, steht die Gegenüberstellung von MDA und dem Computer-Aided Software Engineering (CASE) im Mittelpunkt dieses Kapitels. Der Vergleich dieser beiden Ansätze ist Grundlage für einige der Thesen, die in den Kapiteln 3.3.1 bis 3.3.7 hergeleitet werden. Diese sind entweder rein MDA-Literatur basiert erarbeitet, oder entstehen aus Analogien, die zwischen CASE und MDA gezogen werden.
Der dritte Bereich des Hauptteils, also Kapitel 4 und dessen Unterkapitel, stellt den praktischen Teil der Arbeit dar. Ziel dieses Segments ist es, die theoretisch abgeleiteten Thesen aus Kapitel 3.3 in einer ersten wissenschaftlichen Studie zu überprüfen. Dazu wird in Kapitel 4.1 ein Untersuchungsdesign erarbeitet, welches für die Durchführung verwendet wurde. In Kapitel 4.2 werden die Untersuchungsergebnisse schließlich ausgewertet um die Forschungsrichtung der Thesen beurteilen zu können. Abschließend stellt Kapitel 4.3 ein Fazit, sowie kritische Würdigung des MDA-Ansatzes dar.
2 Grundlagen der Model-Driven Architecture
In folgenden Kapiteln werden die Grundlagen der modellgetriebenen Architektur diskutiert. Die Begriffe MDA und modellgetriebene Architektur werden in dieser Arbeit synonym zueinander verwendet. Zuerst greift Kapitel 2.1 verschiedene Definitionsansätze der modellgetriebenen Architektur auf. Daraus wird eine Arbeitsdefinition abgeleitet. Kapitel 2.2 stellt darauf folgend den Stand der Forschung und der technischen Entwicklung der modellgetriebenen Architektur dar. Dazu werden die Sichtweise der OMG und die kritischere Betrachtung unabhängiger Experten gegenübergestellt. Nachdem Unterkapitel 2.2.1 die Kernkomponenten beschreibt, aus denen die modellgetriebene Architektur besteht, vergleicht Unterkapitel 2.2.2 zwei grundlegende Ansätze der MDA-Implementierung. Abschließend zeigt Unterkapitel 2.2.3 die Standards auf denen das MDA-Framework aufbaut.
2.1 Definitionen
Bevor die modellgetriebene Architektur an sich definiert werden kann, macht es Sinn an dieser Stelle eine Einordnung der MDA in die Begriffswelt der modernen Softwareentwicklung vorzunehmen. An erster Stelle ist hier die generative Softwareentwicklung zu nennen. Diese beschreibt das Streben nach automatisierter Generierung von Teilen eines Softwaresystems. Ein Ansatz der dem Gendanken der generativen Entwicklung Folge leistet ist das sogenannte Model-Driven Development (MDD) oder auch Model-Driven Software Development (MDSD). Dabei wird versucht, ein Softwaresystem möglichst vollständig durch Modelle abzubilden und am Ende den nötigen Programmcode so weit wie möglich aus diesen Modellen zu generieren [Czar05].
Bei der MDA handelt es sich um ein Framework, das die Ideen des Model-Driven Development aufgreift, dabei jedoch verstärkt auf Standards der Object Management Group aufsetzt. Es wird daher auch von einer OMG Implementierung des Model-Driven Development gesprochen. In der Fachliteratur wird die modellgetriebene Architektur aus verschiedenen Perspektiven definiert. Auf der einen Seite gibt es technisch basierte Definitionen wie die von Petrasch und Meimberg [PeMe06]: „MDA ermöglicht die Trennung von Artefakten der Software-Entwicklung in zwei Teile: Die wiederkehrenden Bereiche wie z. B. die Definition von Plattformen (Java Enterprise, CORBA etc.) können von den projektspezifischen (fachlichen) Teilen separiert werden, so dass die Essenz des Systems, z. B. die fachlichen Klassen, nicht mit technischen Details »verunreinigt « werden [PeMe06] .“ Auf der anderen Seite wird in Definitionen oft Bezug auf Prozessoptimierung und wirtschaftliche Effizienz genommen. So zum Beispiel in der Definition der Gesellschaft für Informatik e.V.: „Bei der Model-Driven Architecture (MDA) bilden Modelle die zentralen Elemente des Softwareentwicklungsprozesses. Ziel ist es, plattformspezifische Modelle möglichst automatisiert aus plattformunabhängigen Modellen abzuleiten. Dadurch soll der Aufwand der Softwareentwicklung verringert und die Adaptierung an neue Technologien erleichtert werden [KeMa05] .“ Die dieser Arbeit zugrunde liegende Forschung beschäftigt sich sowohl mit der technischen Ausprägung der modellgetrieben Architektur als auch mit der Wirtschaftlichkeit dieses Frameworks und dessen Auswirkungen auf den Softwareentwicklungsprozess. Um all diesen Aspekten gerecht zu werden, wird als Arbeitsdefinition die der OMG selbst verwendet, da diese sowohl die technische als auch die betriebswirtschaftliche Ausrichtung der modellgetriebenen Architektur beleuchtet: „OMG’s Model-Driven Architecture ® (MDA ®) provides an open, vendor-neutral approach to the challenge of business and technology change. Based on OMG’s established standards, the MDA separates business and application logic from underlying platform technology. Platform-independent models of an application or integrated system’s business functionality and behavior […] can be realized through the MDA on virtually any platform […].These platform-independent models document the business functionality […] separate from the technology-specific code […]. No longer tied to each other, the business and technical aspects of an application […] can each evolve at its own pace – business logic responding to business need, technology taking advantage of new developments – as the business requires [OMG07f] .”
2.2 Technischer Reifegrad der Model-Driven Architecture
Von der OMG [OMG07d] selber wird MDA als Allheilmittel für die Problematiken in der Softwareentwicklung angepriesen. Auf der Webseite der OMG und den in den dort zu findenden Dokumenten zum MDA-Standard [OMG07a; OMG07b; OMG07d; OMG07g] wird dargestellt, dass die modellgetriebene Architektur den kompletten Softwareentwicklungszyklus unterstützt. Auf Basis etablierter Standards werden Probleme auf allen Ebenen der Softwareentwicklung gelöst und damit ein signifikanter Schritt nach vorne gemacht. Die OMG verspricht deutliche Verbesserungen in den Punkten Übertragbarkeit, Interoperabilität, Plattformunabhängigkeit und Produktivität. Beim Einsatz der modellgetrieben Architektur soll es zu Einsparungen von Entwicklungskosten und –zeit bei gleichzeitiger Erhöhung der Qualität und des Return on Investment kommen. MDA wird mit Sätzen wie „The CIO Problem Solver [OMG07d]“ und „The Architecture of Choice for a Changing World [OMG07d]“ beworben.
Die Fachwelt betrachtet die modellgetriebene Architektur kritischer. Neben Werken die sich mit der MDA im Allgemeinen beschäftigen, hier sind Petrasch und Meimberg [PeMe06], Frankel [Fran03], sowie Kleppe, Warmer und Bast [KlWa03] zu nennen, wird MDA in vielen Artikeln und Büchern im Zusammenhang mit speziellen Standards erläutert. Dazu zählt zum Beispiel Raistrick, Francis und Wright [RaFr04], die MDA unter Verwendung von ausführbarem UML untersuchen.
Petrasch und Meimberg [PeMe06] formulieren kritisch, dass die Idee der MDA zwar sofort verständlich ist, die konzeptionelle Substanz sich aber nicht auf den ersten Blick erschließt. Das liegt an fehlender Standardisierung von MDA-Werkzeugen, der Vielzahl an relevanten Dokumenten und dem umfassenden Anspruch der MDA selbst.
Mehr Einigkeit herrscht darüber, dass die modellgetriebene Architektur zwar noch in den Kinderschuhen steckt, das Potential zur Weiterentwicklung jedoch vorhanden ist. Petrasch und Meimberg [PeMe06] schließen dies aus der schon jetzt großen Anzahl an umfangreichen MDA-Werkzeugen von kommerziellen Anbietern, sowie aus der Open Source Community. Auch Kleppe, Warmer und Bast [KlWa03] sehen, dass MDA-Werkzeuge schon jetzt signifikanten Einfluss auf den Entwicklungsprozess nehmen und bei einer weiteren Etablierung der zugrundeliegenden Standards die Möglichkeit für einen Paradigmenwechsel in der Softwareentwicklung besteht, wodurch „der Weg zur grafischen Programmierung wieder ein wenig kürzer geworden [PiRö06]“ wäre und Flexibilität, Wartbarkeit sowie Technologieunabhängigkeit verbessert würden [BoSt03].
Eine 100%ige Automatisierung sehen die Experten jedoch noch nicht, da hierfür die Standardisierung noch nicht weit genug fortgeschritten ist. Auch kann der Mensch, in einigen Bereichen des Softwareentwicklungszyklus nicht ersetzt werden. Viele Experten glauben aber, dass es ihm möglich sein wird sich mehr auf die korrekte Modellierung zu konzentrieren, als sich in technischen Details zu verlieren [KlWa03; PeMe06].
In weiteren Schritten ist es nun nötig die Wiederverwendbarkeit von Artefakten in der MDA nachzuweisen. Außerdem muss untersucht werden ob und vor allem wie sich die modellgetriebene Architektur auf die Softwareentwicklung auswirkt. Nachweisbarer und nachhaltiger Einfluss auf die Wirtschaftlichkeit der Softwareentwicklung ist für MDA essenziell um auf Dauer am Markt bestehen zu können [PeMe06].
2.2.1 Konzepte
Die modellgetriebene Architektur wurde von der OMG nicht gänzlich neu entwickelt. Es handelt sich vielmehr um bereits etablierte Standards die zu einem Framework kombiniert wurden [PeMe06]. Zum Grundverständnis der modellgetriebenen Architektur liegt den folgenden Kapiteln die Definition von Petrasch und Meimberg [PeMe06] zugrunde:
Ziel der MDA ist es, „Modelle so präzise und maschinenlesbar zu entwerfen, dass sich die Entstehung der Architektur auf jeder Abstraktionsebene automatisieren lässt. Keine künstliche Barriere, z. B. durch inkompatible Betriebssysteme, sollte der Entwicklung von Software-Systemen entgegenstehen.“
In den folgenden Unterkapiteln werden die grundlegenden Konzepte der MDA erläutert. Laut der angeführten Definition und der Spezifikation der OMG [OMG07e; OMG07g] bilden Modelle mit der durch ihre Abstraktion gewährleistete Plattformunabhängigkeit, sowie Transformationen das Kernstück der modellgetriebenen Architektur [PeMe06]. Es wird motiviert und erläutert, wie die MDA auf diesen Konzepten aufbaut.
Im Anschluss daran wird überblicksweise auf Basistechnologien und Standards verwiesen, die in den Modellen und Transformationen zur Anwendung kommen. Die grafische Repräsentation der MDA in Abb. 2.2.1/1 zeigt, dass die Unified Markup Language (UML), die Model Object Facility (MOF) und das Common Warehouse Metamodel (CWM) den Kern des Frameworks bilden. Dies sind die wichtigsten drei Modellierungsstandards. Des Weiteren zählen hierzu auch noch die Object Constraint Language (OCL) und die UML-Profile.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.2.1/1 Logo der Model-Driven Architecture
(Quelle: http://www.omg.org/mda/)
In der zweiten Schicht der Darstellung werden mögliche Zielplattformen angegeben, auf die in dieser Arbeit aber nicht näher eingegangen wird. Die Grafik verdeutlicht aber schon die Trennung von Modellen und plattformabhängiger Implementierung. Ebenfalls auf Schicht zwei ist der XML Interchange (XMI) Standarad angesiedelt. Dieser hilft beim Austausch von Metamodellen. Der äußerte Ring zeigt Services, die in Modellen der MDA Verwendung finden können und danach auf den Zielplattformen realisiert werden. Über die Pfeile werden Einsatzfelder der modellgetriebenen Architektur angedeutet.
Modelle und Plattformunabhängigkeit
Modelle dienen der modellgetriebenen Architektur als zentrales Hilfsmittel, indem sie während des Entwicklungsprozesses wichtige Informationen speichern [KlWa03]. Bevor weiter auf die Rolle der Modelle bei der MDA eingegangen wird hilft folgende Definition den Begriff besser einordnen zu können:
„Ein Modell ist eine abstrakte Repräsentation von Struktur, Funktion oder Verhalten eines Systems. [RoSt03] “ „Das Ziel von Modellen ist i.d.R. die Reduktion der Komplexität durch Weglassen von Eigenschaften und Berücksichtigung nur eines oder einiger weniger Aspekte. [PeMe06] “
Aber wo liegt nun genau der Vorteil bei der Verwendung von Modellen im MDA-Framework? Laut Definition abstrahieren Modelle von einer zugrunde liegenden Struktur. Dadurch wird es zum einen möglich die Spezifikation einer Architektur von deren Funktionalität, sowie die Benutzung von der Realisierung zu trennen. Zum anderen wird dadurch die gewünschte Plattformunabhängigkeit erreicht wodurch dem Grundsatz zufolge, „Konzepte sind stabiler als Technologien [RoSt03]“ die Langlebigkeit eines Systems erhöht wird [RoSt03].
Bei der Betrachtung der modellgetriebenen Architektur sind zwei grundlegende Anforderungen für die verwendeten Modelle zu beobachten, die nicht über die Modelldefinition impliziert werden.
Zum einen müssen MDA-Modelle sowohl von statischen als auch dynamischen Strukturen abstrahieren können [KlWa03]. Das ist wichtig, da es in Softwaresystemen immer statische Bestandteile wie Klassen und dynamische Bestandteile wie Prozesse gibt. Beide Formen des Systems müssen in Modellen darstellbar sein.
Ein weiterer Aspekt, der in der Literatur jedoch kontrovers diskutiert wird, ist die Formalität der MDA-Modelle. Die Formalität beschreibt die Eindeutigkeit der Form (Syntax) und Bedeutung (Semantik) der Modelle [PeMe06]. Der MDA-Guide selbst [OMG07e] macht hier widersprüchliche Angaben. Auf der einen Seite werden natürliche, also nicht formale Sprachen für Modelle zugelassen. In späteren Textpassagen wird wiederum eine formale Beschreibung für Modelle gefordert. Aktuellere Literatur setzt formale [RoSt03] oder zumindest semiformale [PeMe06] Modelle jedoch voraus, sodass eine maschinelle Verarbeitung ermöglicht wird [RoSt03].
Die OMG beschreibt in ihrem Standard zur MDA zwei Kernmodelle: das Platform Independent Model (PIM) und das Platform Specific Model (PSM). Diese Modelle sind auch durchgängig in der Fachliteratur zu finden. Auf einer noch höheren Ebene der Abstraktion wird das Computation Independent Model (CIM) eingeführt [OMG07c]. Das CIM wird in der Fachliteratur seltener erwähnt, da es nicht nur von Softwaresystemen abstrahiert, sondern auch von Geschäftsprozessen [KlWa03]. In folgenden Abschnitten, die beschreiben wie die einzelnen Modelle im MDA-Prozess integriert sind, wird das CIM aus Vollständigkeitsgründen mit erfasst. Jedem der aufgeführten Modelle wird außerdem ein sogenannter Viewpoint zugeordnet. Die unterschiedlichen Viewpoints des Systems beschreiben dieses aus einer bestimmten Sichtweise und unter Betrachtung verschiedener Aspekte. Abb. 2.2.1/2 stellt den Zusammenhang der Modelle und Viewpoints eines modellgetriebenen Ansatzes überblicksweise dar. In den folgenden Abschnitten wird unter Bezugnahme auf die Grafik das Zusammenspiel der Modelle näher erläutert.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.2.1/2 Modellabhängigkeiten in der modellgetriebenen Architektur
(Abb. angelehnt an [SiAl03])
Computation Independent Model
Am Anfang des modellgetriebenen Ansatzes steht ein Problem, welches eine oder mehrere Domänen[1] betrifft und durch ein System, welches auf eventuell unterschiedlichen Plattformen arbeitet gelöst werden soll.
Durch die Betrachtung des Problems aus dem Computation Independent Viewpoint (CIV) werden die Anforderungen und die Umgebung des zu entwickelnden Systems festgelegt und ein Computation Independent Model gebildet [SiAl03], welches die Problemdomäne repräsentiert. Aus diesem Grund wird das CIM auch Domain Model oder Business Model genannt [PeMe06]. Von der detaillierten Struktur und der Arbeitsweise des Systems wird in diesem Modell abstrahiert und dadurch eine Implementierungsunabhängigkeit in Bezug auf Soft- und Hardware [PeMe06] hergestellt. Die beiden wesentlichen Modellarten in diesem Schritt sind Geschäftsmodelle[2] auf der einen Seite, und Informationsmodelle[3] auf der anderen Seite [KlWa03; RoSt03]. Der Hauptnutzen eines CIM liegt laut der OMG darin, dass ein besseres Verständnis des Systems und eine gemeinsame Terminologie geschaffen werden. Außerdem ist es aufgrund der Unabhängigkeit von der Technologie möglich, dass Experten aus unterschiedlichen Domänen an der Entwicklung des CIM mitarbeiten und dadurch ein System entsteht, welches besser an die Bedürfnisse und Prozesse der einzelnen Domänen angepasst ist [OMG07e; PeMe06].
Platform Independent Model
Aufbauend auf dem Computation Independent Model wird das Problem über einen Platform Independent Viewpoint (PIV) analysiert und daraus ein Platform Independent Model erstellt. Nach Kleppe, Warmer und Bast [KlWa03] ist eine Automatisierung dieses Schrittes noch nicht möglich, da die Entscheidungen, welche Teile eines Geschäftsmodells softwaretechnisch unterstützt werden sollen, nicht von einer Maschine übernommen werden können. Im PIM werden vor allem die benötigten Daten und die Prozesse, sprich die Funktionalität des Systems modelliert [SiAl03]. Wichtig ist dabei, dass alle Teile unabhängig von der später verwendeten Software- und Hardwareplattform spezifiziert werden, das heißt, dass von Implementierungsdetails abstrahiert wird. Da die Automatisierung von CIM nach PIM noch nicht möglich ist, bildet das PIM das Kernstück der modellgetriebenen Architektur, da hier der Automatisierungsvorteil ansetzt. Der Detailierungsgrad eines PIM ist deutlich höher als der eines CIM. So sind Detaillierung und Formalisierung im CIM, die kaum über die der natürlichen Sprache hinausgehen, für ein PIM inakzeptabel und viel zu gering [PeMe06]. Durch die Erfassung der Geschäftslogik[4], Domänenwissens und Problemlösungen bildet das PIM einen zentralen Know-How Speicher [RoSt03]. Entsprechend der Fachliteratur und entgegen der Spezifikation der OMG ist es schwierig ein Modell eindeutig als plattformunabhängig zu bezeichnen. So vertreten Petrasch und Meimberg [PeMe06] aber auch Kleppe, Warmer und Bast [KlWa03] die Meinung, dass Modelle sowohl plattformabhängig als auch plattformunabhängig sein können, je nach Zielplattform. Zur Komplexitätsreduktion wird im Folgenden über eine klare Trennung der Modelltypen argumentiert.
Platform Model
Das plattformunabhängige Modell bildet die Grundlage für die Erstellung plattformabhängiger Modelle. Um automatisch ein plattformspezifisches Modell zu erhalten ist jedoch eine technische Spezifikation der Zielplattform nötig. Diese Spezifikation wird als Platform Modell (PM) oder Plattformdeskriptor [PeMe06] bezeichnet und beschreibt detailliert die angebotenen Dienste und Strukturen der Zielplattform [PeMe06] sowie die gegebenen Möglichkeiten zur Verbindung unterschiedlicher Komponenten [RoSt03]. Momentan liegen solche Spezifikationen in Form von Manuals, API-Beschreibungen oder gar nur im Kopf der Softwarearchitekten vor [PeMe06]. Hier setzt die MDA-Standardisierung an und fordert Spezifikationen in Form von Modellen, was erhebliche Vorteile im Bezug auf maschinelle Verarbeitung bringt. Laut dem MDA-Guide [OMG07e] liegt bezüglich der Syntax für solche Modelle zwar keine Verpflichtung vor, es macht jedoch Sinn hier zum Beispiel auf UML-Profile (vgl. Kapitel 2.2.3) zurückzugreifen [PeMe06].
Platform Specific Model
Durch Zuhilfenahme des entsprechenden Plattformmodells werden plattformunabhängige Modelle in sogenannte Platform Specific Models transformiert. Dazu werden die plattformunabhängigen Modelle durch den Einsatz der entsprechenden Plattformmodelle mit Details über die spezielle Plattform erweitert. Die entstehenden plattformabhängigen Modelle, welche das System aus einem Platform Specific Viewpoint (PSV) darstellen, sind immer technologieabhängig, das heißt sie ändern sich je nach gewähltem Design von Plattform zu Plattform [SiAl03]. Ziel bei der modellgetriebenen Architektur ist es, das plattformunabhängige Modell möglichst vollständig automatisiert unter Verwendung von Platform Models und Transformationsregeln in die entsprechenden plattformspezifischen Modelle zu überführen [BoEc04].
Aus den plattformspezifischen Modellen wird unter Berücksichtigung der Transformationsdefinition bzw. Annotationen in Form der UML-Profile oder Object Constraint Language [KlWa03] (vgl. Kapitel 2.2.3) in einem letzten Schritt der benötigte Quellcode generiert, der das System letztendlich repräsentiert [SiAl03]. In der modellgetriebenen Architektur, wie sie heute zum Einsatz kommt gibt es teilweise Abweichungen von dem beschrieben Prozess bezüglich der Nutzung aller zur Verfügung stehenden Modelle. Dies wird in folgendem Abschnitt und vor allem in Kapitel 2.2.2 näher beschrieben.
Transformation
Eine weitere tragende und damit in der Fachliteratur weit diskutierte Säule im MDA-Entwicklungsprozess sind die Transformationen [KlWa03]. Transformationen lassen sich in zwei Kategorien unterteilen.
Zum einen gibt es die einfache Transformation bei denen Modelle in Code transformiert werden (Model-to-Code). Diese Transformation kommt in der MDA zum Einsatz, wenn das plattformspezifische Modell in Code umgewandelt wird. Es kann aber auch bedeuten, dass das plattformunabhängige Modell direkt in eine plattformspezifische Implementierung (Programmcode) transformiert wird. Die Fachwelt ist sich einig, dass es sich bei dieser Art der Transformation nur um eine abgespeckte Version des MDA-Einsatzes handelt. Sie geht zum einen nicht viel weiter als die Code Generierung, die aus der CASE-Welle der 1980er und 1990er Jahre bekannt ist [KlWa03] und zum anderen gehen dadurch viele vorteilhafte Eigenschaften der MDA verloren. So führen Petrasch und Meimberg drei Kernprobleme dieses Ansatzes an [PeMe06]:
- Das plattformunabhängige Modell benötigt so viele plattformspezifische Zusatzinformationen, dass es kaum noch als PIM bezeichnet werden kann.
- Es müssen Entwurfsentscheidungen getroffen werden, die sehr plattformspezifisch sind.
- Dadurch, dass es nur noch ein PIM gibt wird die Implementierung der Model-to-Code Transformation sehr komplex, da in ihr alle Plattformeigenheiten enthalten sein müssen.
Zum anderen gibt es neben der Model-to-Code Transformation die Model-to-Model Transformation. Dieser Transformation von einem Modell in ein anderes wird in der Fachwelt größere Wichtigkeit für den MDA-Prozess, jedoch auch eine höhere Komplexität zugeteilt [BoEc04; KlWa03; PeMe06]. Nach Petrasch und Meimberg [PeMe06] ist eine Model-to-Model Transformation im Falle der modellgetriebenen Architektur von einem plattformunabhängigen Modell in plattformspezifische Modelle spätestens dann unausweichlich, wenn sich Entwurfsentscheidungen nicht mehr in Transformationsregeln abbilden lassen. Zur Transformation zwischen Modellen werden Transformationsdefinitionen verwendet, die beschreiben, nach welchen Regeln das Quellmodell in das Zielmodell überführt wird. So können aus einem plattformunabhängigen Modell mehrere plattformspezifische Modelle abgeleitet werden, aus denen wiederum der Programmcode generiert wird [KlWa03]. Unabhängig von der gewählten Modellierungssprache lassen sich PIM nach PSM Transformationen wie in Abb. 2.2.1/3 visualisieren.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.2.1/3 Transformation unter Zuhilfenahme eines Plattformmodells
(Abb. angelehnt an [BoEc04])
Zu beachten ist, dass Transformationen von einem Modell in ein anderes nicht zwingend reversibel sind. Das bedeutet, dass aus einem PSM meist nur unter Aufbringung eines Zusatzaufwandes wieder das zugehörige PIM erzeugt werden kann [PeMe06]. Daraus ergibt sich ein Problem im MDA-Prozess, welches als „Re-Generierungsproblem“ bekannt ist. Da die modellgetriebene Architektur momentan noch keine 100%ige Codegenerierung zulässt, kann es zu manuellen Änderungen der Zielartefakte kommen. Diese Änderungen können nicht automatisch in abstraktere Modelle übernommen werden, da sie semantisch nicht aussagekräftig genug sind. Wird danach eine Änderung im Quellartefakt gemacht und die Transformation erneut durchgeführt ist die manuelle Veränderung verloren. Um dieser Problematik entgegenzuwirken ist eine ausgereifte Werkzeugunterstützung nötig, bei der manuelle Änderungen in geschützten Bereichen, oder getrennt vom generierten Code eingearbeitet werden. Dadurch können sie nach der erneuten Transformation nachgezogen werden [PeMe06].
Ein weiteres Problem liegt in der zurzeit noch geringen Standardisierung der Transformationen. Standards spielen, wie in Kapitel 2.2.3 dargelegt wird, eine wichtige Rolle in der modellgetriebenen Architektur. Während die Standardisierung bei den Modellen schon weit fortgeschritten ist, ist der Bereich der Transformationen noch sehr heterogen [KeMa05]. Die OMG versucht diesem Missstand durch Spezifikation des Transformationsstandards Query/Views/Transformation (QVT, siehe Kapitel 2.2.3) zu begegnen. Es wird sich zeigen, ob sich die MDA-Werkzeuglandschaft dadurch homogenisieren lässt [BoEc04].
2.2.2 Umsetzung
Bei näherer Betrachtung der Werkzeuge, die die modellgetriebene Architektur unterstützen, sind zwei unterschiedliche Umsetzungsansätze des MDA-Prozesses zu finden, die einheitlich von der Fachwelt getrennt werden. So sind sich Weiszmann und Messenheimer [WeMe05], Cottenier, van den Berg und Elrad [CoBe06], Sarstedt et al [SaKo05] und McNeile [McNe03] einig, dass sich die beiden Ansätze hauptsächlich in dem Entwicklungsprozess zwischen dem plattformunabhängigen Modell und der Implementierung des plattformspezifischen Modells auf Programmcodeebene unterscheiden. Im Folgenden werden beide Ansätze getrennt voneinander betrachtet.
Elaboratorischer Ansatz (elaborationist approach)
Beim Einsatz des elaboratorischen Ansatzes entsteht die Applikation allmählich beim Durchlaufen der Modelle wie in Abb. 2.2.2/1 dargestellt. Zunächst wird das plattformunabhängige Modell entwickelt. Dieses ist jedoch nicht soweit spezifiziert, dass direkt Programmcode daraus generiert werden kann [CoBe06]. Deshalb wird das PIM, mit Hilfe eines Generators, in das plattformspezifische Modell überführt. Dieses kann manuell durch den Entwickler verfeinert werden. Danach wird durch einen weiteren Generator der plattformspezifische Programmcode erzeugt, welcher erneut manuell angepasst werden kann [CoBe06]. Um die Konsistenz zwischen den Modellen zu wahren muss das sogenannte Round Trip Engineering[5] unterstützt werden. Das bedeutet, dass manuelle Anpassungen eines spezifischen Modells (z. B. PSM) in das weniger spezifische Modell der darüber liegenden Ebene (z. B. PIM) übernommen werden müssen. Ansonsten gehen die manuellen Änderungen in späteren Iterationen verloren. In Abb. 2.2.2/1 wird dieser Vorgang durch die geraden Pfeile von rechts nach links symbolisiert [McNe03].
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.2.2/1 Elaboratorischer Ansatz der modellgetriebenen Architektur
(Abb. angelehnt an [McNe03])
Beim elaboratorischen Ansatz handelt es sich um den weiter verbreiteten Ansatz, da er näher am bekannten objektorientierten Entwicklungsprozess, von der Analyse über das Design hin zum Code liegt [CoBe06; McNe03].
Translatorischer Ansatz (translationist approach)
Im translatorischen Ansatz muss das gesamte System bereits im plattformunabhängigen Modell spezifiziert sein. Die Spezifikation des PIM und die Generierungsregeln müssen ausgiebig genug sein, um das System über einen hoch entwickelten Generator vollständig zu erzeugen. Bei diesem Ansatz, der auch in Abb. 2.2.2/2 dargestellt ist, wird am Code und im plattformspezifischen Modell keine manuelle Verfeinerung mehr vorgenommen. Das plattformspezifische Modell ist, für den Anwender transparent, im Transformationsschritt verschattet.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.2.2/2 Translatorischer Ansatz der modellgetriebenen Architektur
(Abb. angelehnt an [McNe03])
Auch ein Round Trip Engingeering ist in diesem Fall nicht von Nöten. Alle Änderungen werden nur im PIM vorgenommen. Diese überführt eine erneute Transformation dann in den Code. Dadurch bleiben Ausgangs- und Zielmodell, sowie der gesamten Prozess synchron [CoBe06; McNe03; SaKo05].
Einen Vorteil sehen Cottenier, van den Berg und Elrad [CoBe06] bei diesem Ansatz darin, dass das System sehr früh getestet werden kann, da der Prozess dem des Agile Software Development[6] sehr nahe kommt. Außerdem wird 100% des Codes generiert. Negativ bewerten die Experten, dass im plattformunabhängigen Modell schon das komplette System mit all seinen Funktionalitäten abgebildet werden muss. Dadurch entsteht zum einen eine hohe Komplexität und zum anderen sind einige Gegebenheiten zu diesem frühen Zeitpunkt in UML kaum modellierbar [CoBe06].
Executable UML (xUML) welches im folgenden Abschnitt erwähnt wird arbeitet nach diesem Prinzip.
Beispielhafte Modelltransformation
Um die in Kapitel 2.2.1 vorgestellten Konzepte der Modelle und Transformationen, sowie die in Kapitel 2.2.2 erläuterten Ansätze etwas greifbarer zu machen wird in Folgendem an einem einfachen Beispiel gezeigt wie drei Klassen eines plattformunabhängigen Modells, mittels des elaboratorischen Ansatzes, in ein plattformabhängiges Java-Modell transformiert werden. Das Beispiel ist an die Ausführung von Kleppe, Warmer und Bast [KlWa03] angelehnt.
Das zugrunde liegende Beispielsystem besteht aus den drei Klassen Bestellung, Artikel und Kunde. Wie in der plattformunabhängigen Modellierung in Abb. 2.2.2/3 dargestellt wird haben alle drei Klassen private Attribute[7]. Zwischen den Klassen bestehen Assoziationen[8]. So kann jeder Kunde mehrere Bestellungen aufgeben und jede Bestellung besteht aus einem oder mehreren Artikeln.
[...]
[1] Domänen stehen hier für unterschiedliche Fachgebiete
[2] Ein Geschäftsmodell beschreibt in diesem Fall Geschäftsprozesse, Stakeholder und deren Abhängigkeiten.
[3] Ein Informationsmodell ist die abstrakte Abbildung von Objekten und deren Beziehungen
[4] Die Geschäftslogik beschreibt unter Anderem Prozesse in einem Unternehmen
[5] Beim Round Trip Engineering wird der Code automatisch konsistent zu den Modellen und umgekehrt, bzw. Modelle untereinander konsistent gehalten.
[6] Agile Software Development zeichnet sich durch geringen bürokratischen Aufwand und wenige, flexible Regeln aus. Ein Beispiel ist Extreme Programming
[7] Private Attribute sind Variablen einer Klasse, die von anderen Klassen nicht direkt, sondern nur über spezielle Methoden geändert, bzw. gelesen werden können.
[8] Assoziationen beschreiben die Abhängigkeiten sowie die Kardinalitäten zwischen Klassen in einem System.
- Quote paper
- Johannes Vetter (Author), 2007, Model-Driven Architecture, Munich, GRIN Verlag, https://www.grin.com/document/81137
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.