Konzept: MDD (Model Driven Development) und MDA (Model Driven Architecture)
Diese Anleitung erläutert MDD (Model Driven Development) und MDA (Model Driven Architecture), deren Schwerpunkt auf der Rolle der Modelle im Software-Engineering liegt.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

In Rational Unified Process (RUP) sind Modelle wichtige Arbeitsergebnisse, die in der Sprache UML (Unified Modeling Language) tool- und umgebungsneutral ausgedrückt werden, so dass RUP in verschiedenen Umgebungen mit vielen Tools implementiert und verwendet werden kann. Im Abschnitt Visuelle Modellierung werden die Vorteile der Modellierung erläutert. Hierzu gehören unter anderem:

  • Besseres Verständnis komplexer Systeme
  • Designalternativen ohne großen Aufwand als Grundlage für die Implementierung suchen und vergleichen
  • Anforderungen präzise erfassen
  • Entscheidungen unmissverständlich vermitteln

Modelle werden als Möglichkeit betrachtet, sich Gedanken über Systemverhalten (gewünscht und realisiert) und Strukturen zu machen, und die Ergebnisse dieser Überlegungen dann interessierten Stakeholdern mitzuteilen. In MDD (Model Driven Development, modellorientierte Entwicklung) und MDA (Model Driven Architecture, modellorientierte Architektur) werden Modelle als grundlegende Elemente für die Implementierung betrachtet. Es wird davon ausgegangen, dass sie mehr als nur Entwürfe sind, auf deren Grundlage Entwickler Code schreiben werden. Sie sind vielmehr je nach Funktionalität der unterstützenden Tools selbst einsetz- bzw. ausführbar. Diese Art der Betrachtung folgt dem Trend, der bereits vor langer Zeit eingesetzt hat, die Abstraktionsebene, auf der Entwickler arbeiten, zu erhöhen. Die Aufmerksamkeit richtet sich nun auf Modelle und nicht auf Code, ausgedrückt in einer höheren, eher grafisch orientierten Sprache. RUP unterstützt diese Möglichkeit indirekt, indem bestimmte Artefakte als Modelle und nicht als Dokumente mit Bildern von Modellen (z. B. Erfassen von Anforderungen und Design) identifiziert werden.

Blickwinkel und Sichten Seitenanfang

Ein Blickwinkel ist ein theoretischer Ansatz, in dem verschiedene Aspekte oder Probleme des Systems (oder die Gruppe von Modellen, die das System darstellen) unter Anwendung von Konzepten und Regeln als konzeptionelle Filter sichtbar gemacht werden. Der Begriff "Perspektive" wird ähnlich verwendet, um eine Art der Betrachtung und des Verständnisses von Modellen zu beschreiben, die am besten den unterschiedlichen Schwerpunkten und Problemen der verschiedenen Stakeholder gerecht wird.

Sichten sind die Projektionen von Modellen, die die Entitäten zeigen, die von einem bestimmten Blickwinkel aus relevant sind.

In MDD werden Blickwinkel und Sichten verwendet, um Abgrenzungen vorzunehmen, z. B. um die logische Struktur unabhängig von der physischen Struktur und unabhängig von der Prozessstruktur zu behandeln. Je näher die Modelle der Problemdomäne sind, um so stärker lassen sich die Blickwinkel bzw. Perspektiven auf die Geschäftsinteressen der Stakeholder abbilden. Je weiter sich die Entwicklung der Modelle einer ausführbaren Form annähert, umso mehr spielen verarbeitungsrelevante Probleme eine Rolle. Es geht in keinem Fall darum, passive Abbildungen zu erzeugen, sondern Modelle, die wenigstens potenziell aus Implementierungen stammen können, die diese verschiedenen Aspekte vereinen.

Ausarbeitung und Übersetzung (Umsetzung) Seitenanfang

Diese Begriffe werden oft informell verwendet, um zwischen manuellen Änderungen am Modell (Ausarbeitung) und Änderungen am Modell, die mit einem Tool (Übersetzung) vorgenommen werden, zu unterscheiden. In RUP hat der Begriff "Ausarbeitung" eine andere formale Bedeutung. Es ist die Bezeichnung einer Lebenszyklusphase. In diesem Abschnitt wird jedoch der Begriff informell verwendet, um scheinbar unterschiedliche Ansätze in der Weiterentwicklung von Modellen zu veranschaulichen.

Übersetzung und Ausarbeitung unterscheiden sich auch in der Anzahl der Schritte insofern, als ein Modell in vielen kleinen Schritten so genau ausgearbeitet wird (einschließlich Sprache, Infrastruktur und Betriebssystem), dass Code daraus generiert werden kann, entweder mit einem Tool oder manuell. Bei der manuellen Generierung wird das Modell von einem Menschen begutachtet, der dann Code in Java, C++ oder in anderen Sprachen schreibt und die Ausarbeitung im Prozess weiter voranbringt. Demgegenüber wird in der Übersetzung das Modell, das sich noch auf einer von Sprache, Infrastruktur oder Betriebssystemfragen unbeeinflussten Abstraktionsebene befindet, in etwas konvertiert, das das gewünschte Ergebnis mit geringem oder gar keinem weiteren Ausarbeitungsaufwand liefert. Beachten Sie, dass das gewünschte Ergebnis auch Leistungsverhalten und andere nicht funktionale Merkmale beinhaltet. Daher ist in diesem Ansatz auch enthalten, dass solche architekturübergreifenden Probleme anhand der Modellstruktur und der Art und Weise, wie die Ressourcenanforderungen beschrieben werden, in Angriff genommen werden.

Der Begriff Umsetzung wird verwendet, um den Generierungsprozess eines Zielmodells aus einem Quellenmodell zu beschreiben, der gewissen Regeln folgt und durch Parameter gesteuert werden kann. Beachten Sie, dass der Begriff "Modell" mit derselben Bedeutung wie in RUP verwendet wird, d. h. Zielmodelle können Implementierungselemente wie beispielsweise Code oder Text sein. Umsetzungen können selbstverständlich auch manuell durchgeführt werden. So werden aufeinander folgende Umsetzungen (Hinzufügen von Details) genauso behandelt wie Ausarbeitungen. Die Regeln können sehr komplex sein und eine tiefgreifende Kenntnis der verfügbaren Technologie und der Domäne erfordern. Die übliche Bedeutung dieses Begriffs ist jedoch, dass Umsetzungen automatisch durchgeführt werden. Diese Bedeutung wird im nächsten Abschnitt zu MDA® erneut aufgegriffen.

Bei der Umsetzung geht es im Wesentlichen um ein Quellen- und ein Zielmodell. Der Normalfall sieht so aus, dass das Zielmodell weniger abstrakt ist als das Quellenmodell, d. h. das Zielmodell ist genauer als das Quellenmodell. Dieser Aspekt ist jedoch nicht implizit in der Umsetzung inbegriffen. Mit der Umsetzung können einem Modell auch Details hinzugefügt werden, die ein genaueres Zielmodell erzeugen, während es weitestgehend insofern auf derselben Abstraktionsebene bleibt, als keine für eine andere Domäne relevante Informationen hinzugefügt werden. Wenn Sie dies mit einer Umsetzung vergleichen, die Code aus einem UML-Modell erzeugt, wird diesem Zielmodell mehr hinzugefügt, das für den Stakeholder des Geschäfts nicht von Bedeutung ist, vorausgesetzt das erforderliche Verhalten und nicht funktionale Merkmale werden beibehalten.

Inwieweit eine Realisierung des Umsetzungsideals möglich ist, hängt vom Leistungsspektrum des Tools und den Möglichkeiten ab, wieviel von dem Wissen erfahrener Menschen in Code umgesetzt, erfasst und wiederverwendet werden kann. Das Maß an Wissen, das erfasst und codiert werden muss, hängt von der Abstraktionsebene ab, von der aus der Umsetzungsschritt durchgeführt wird. Je höher die Abstraktionsebene, umso größer ist üblicherweise die Abhängigkeit von Wissen und Domäne.

In MDD geht es darum, die Abstraktionsebene so zu erhöhen, dass daraus ein betriebsbereites System automatisch generiert werden kann. Ein Modell wird bis zu dem Punkt ausgearbeitet, an dem aus ihm etwas generiert werden kann. Hierbei ist wichtig, dass das Ergebnis nicht weiter ausgearbeitet werden muss, um ausgeführt werden zu können. Außerdem sollten die vorherigen Ausarbeitungen weitestgehend durch schrittweise automatisierte Umsetzungen erzielt werden. Diese beiden Konzepte treffen hier aufeinander: die Übersetzung wird durch fortlaufende Umsetzungsschritte realisiert und so weit wie möglich automatisiert. Die letzte Umsetzung zum ausführenden System tritt zu einem Zeitpunkt auf, an dem sich die Modellbeschreibung noch auf einer hohen Abstraktionsebene befindet und an dem Technologie, Infrastruktur und die in der Steuerkomponente für Umsetzungen codierte Zielsprachenauswahl sowie die Regeln und Daten verfügbar sind.

Ein weiterer Vorteil von MDD liegt darin, Umsetzungen insbesondere dann wiederverwenden zu können, wenn sie das Plattform- und Fachwissen sowie die Best Practices von Experten in den entsprechenden Domänen enthalten. Auf diese Weise wird die Wiederverwendung durch weniger erfahrene Entwickler erleichtert und eine von Grund auf neue Erstellung mit jeder neuen Anwendung vermieden.

Was ist eine hohe Abstraktionsebene? Seitenanfang

Es gibt verschiedene Betrachtungsweisen hierfür. Eine Form der Betrachtung ist die anhand der Sprache, die beispielsweise ausführbare UML-Modelle hervorbringt. Eine andere ist die aus der Perspektive des Domänen-Engineering, in der die Sprach- und Modellkonzepte für die Domäne angepasst werden müssen. UML ist eine vielseitig einsetzbare Sprache, d. h. mit Hilfe von UML-Profilen können Sie UML effizient einsetzen. Andererseits sollten hersteller- und infrastrukturspezifische Modelle vermieden werden, um weiterhin offen für neue Technologie zu sein.

Was die Ausdrucksmöglichkeiten detaillierten dynamischen Verhaltens betrifft, so ist es mit der Ausarbeitung der UML Action Semantics (Aktionssemantik der UML) möglich, ausführbare Formen von UML zu erstellen. Die konkrete Syntax und Notation ist jedoch nicht standardisiert, und die Ebene der Aktionssemantik anderen objektorientierten Sprachen ähnlich. Die Verwendung von UML zusammen mit der Aktionssemantik ist wahrscheinlich nicht der Weisheit letzter Schluss, gibt jedoch die Richtung an, in die der Weg führt.

Ein in UML ausgedrücktes Modell oder ein Modell, das ein UML-Profil verwendet, das keine herstellerabhängigen Elemente enthält, nicht von einer bestimmten Infrastrukturplattform, wie z. B. J2EE oder Microsoft ® .NET, abhängig und in Struktur und Verhalten semantisch vollständig ist, ohne auf eine bestimmte prozedurale Sprache (Java, C#, ...) zurückgreifen zu müssen, befindet sich nach dieser Definition auf einen hohen Abstraktionsebene, wenngleich das Thema der Ebene der Aktionssemantik bestehen bleibt.

Aus der Sicht einer Problemdomäne, d.h. aus der Perspektive des Benutzers oder Geschäftskunden betrachtet, ist eine mögliche und attraktive Lösung die Formulierung von domänenspezifischen Modellierungssprachen. Es handelt sich hierbei um abstrakte Sprachen, die auf UML basieren, jedoch den Mitarbeitern in der betreffenden Domäne bekannte Begriffe und Konzepte verwenden, mit denen Modelldynamik vollständig ausgedrückt werden kann.

Wie passt das zu RUP? Seitenanfang

Die Beziehung der Analyse-, Design- und Implementierungsmodelle in RUP veranschaulicht die folgenden Konzepte: das Analysemodell stellt eine frühe Sicht der Realisierung des in den Anwendungsfällen ausgedrückten Verhaltens dar. Es nähert sich der Domäne des behandelten Problems anschaulich an und die darin enthaltenen Analyseklassen werden als konzeptionelle Gruppierungen der erforderlichen Zuständigkeiten und des Verhaltens betrachtet. Das Analysemodell kann in der Regel nicht ausgeführt werden, es sei denn, es handelt sich um das gedankliche Experiment eines Menschen, der das Modell liest und die Lücken füllt, da zu viel unerwähnt bleibt. Das Analysemodell muss daher noch einem Optimierungsprozess unterzogen werden, bei dem eine Präzisierung (Detail und Genauigkeit) stattfindet, deren Ergebnis das Designmodell ist.

In RUP ist es möglich, in einem Projekt ein separates Analysemodell zu verwalten oder das Analysemodell als ein Modell zu betrachten, das in ein Designmodell weiterentwickelt wird. Der Optimierungsprozess wird in den Aufgaben von RUP ausführlich beschrieben. Hierbei wird standardmäßig davon ausgegangen, dass Menschen in den Rollen des Softwarearchitekten und Designers diese Ausarbeitung mit wahrscheinlich nicht unerheblicher Toolunterstützung durchführen. Beachten Sie, dass diese Verbesserung als Folgeprozess der Modellumsetzungen betrachtet werden kann, von denen einige automatisiert werden können. Dies gilt beispielsweise für die Anwendung von Analysemustern und Designmustern in den RUP-Aufgaben Architekturanalyse und Designmechanismen identifizieren.

Wann ist das Designmodell fertig? Seitenanfang

Das Designmodell wird im ganzen Lebenszyklus des Projekts in verschiedenen Iterationen weiterentwickelt. Daher stellt sich die Frage, wann das Designmodell (oder ein Teil davon) in Code generiert werden kann, d. h. wann kann damit begonnen werden, Implementierungselemente zu erzeugen und diese in mögliche Builds für das System zu integrieren? In RUP werden Anleitungen zum Thema Zuordnung von Design zu Code bereitgestellt, es gibt jedoch im Wesentlichen keine verbindlichen Antworten. Sie können dann eine Implementierung durchführen, wenn Sie beispielsweise nach einer Überprüfung der Meinung sind, dass dies möglich ist. Dieser Zeitpunkt kann je nach Organisation und Projekt ganz unterschiedlich sein. RUP stellt eine Reihe von Möglichkeiten für den Übergang von Design zu Code bereit. Zwei davon werden nachfolgend erläutert, um zu veranschaulichen, wie Entscheidungen zu der Frage, wann das Design fertig ist, getroffen werden:

1. Skizzieren und codieren
In RUP heißt es: "Ein gebräuchlicher Ansatz für das Design ist, das Design relativ abstrakt zu skizzieren und anschließend direkt zur Codierung überzugehen. Die Pflege des Designmodells wird manuell durchgeführt."

Damit dieser Ansatz erfolgreich ist, muss der Entwickler in der Lage sein, die Abstraktionslücke zwischen Design- und Implementierungsebenen zu überbrücken. Oft ist die Pflege des Designmodells von zweitrangiger Bedeutung und nur der Code steht im Vordergrund!

2. Round-Trip-Engineering (RTE) mit einzelnem Designmodell
In RUP heißt es: "Bei diesem Ansatz wird nur ein Designmodell verwendet. Erste Skizzen von Designelementen werden so weit ausgearbeitet, dass sie mit dem Code synchronisiert werden können."

Hier schließen die Entwickler die Abstraktionslücke über eine Abfolge von Modellierungsschritten. Der Unterschied zwischen diesem Ansatz und dem Ansatz "Skizzieren und codieren" liegt darin, dass die Zwischenschritte manifestiert sind, und die abstrakte Version des Designmodells am Ende nicht mehr vorhanden ist.

In beiden Fällen geht der potenzielle Wert eines abstrakten Designmodells verloren: im Ansatz "Skizzieren und codieren" wird das Designmodell üblicherweise nicht gepflegt und verliert so mit der Zeit den Bezug zum Code und im Ansatz "Einzelnes Designmodell" ist am Ende die abstrakte Vision nicht mehr vorhanden. Selbst wenn eine Erstversion aufbewahrt wird, ereilt sie doch am Ende dasselbe Schicksal wie das Designmodell beim Ansatz "Skizzieren und codieren". Beachten Sie, dass der Endpunkt für das Designmodell mit RTE tatsächlich die Codevisualisierung ist. Eine ähnliche Visualisierung könnte mit geeigneten Tools aus Code rückentwickelt werden, der mit dem Ansatz "Skizzieren und codieren" erstellt wurde. In RUP wird der Verlust des abstrakten Designmodells bis zu einem gewissen Grad dadurch gemildert, dass wichtige Architektursichten und Begründungen für das Design an kritischen Punkten im Softwarearchitekturdokument festgehalten werden.

Mit MDD besteht die Hoffnung, dass das abstrakte Designmodell sich in der Codegenerierung etablieren und langfristig durchsetzen wird. MDD wird zur Hauptgrundlage für die Pflege, ist möglicherweise sogar die einzige Grundlage hierfür. MDD bietet auch eine eindeutige Definition für den Endpunkt des Designs, d. h. den Punkt, an dem im Hinblick auf die Steuerkomponente für die Umsetzung das Modell fertig, konsistent und eindeutig ist, und in ein ausführbares System konvertiert werden kann. Der Abstraktionsgrad des Modells hängt von der verfügbaren Technologie und der Toolsets (ein Beispiel hierfür finden Sie unter Symbol für Onlinehilfe Tour: Rational Software Architect Übersicht) oder auch von der Domäne ab. Für MDD ist es einfach eine weitere Umsetzung (Design zu Code), wenngleich eine wichtige Umsetzung, die Abstraktionsebenen überspringt.

Im nächsten Abschnitt wird der für MDD entstehende Framework-Standard MDA® (Modell Driven Architecture®, modellorientierte Architektur), eine Initiative der OMG (Object Management Group), beschrieben.

MDA (Model Driven Architecture)Seitenanfang

ZielsetzungSeitenanfang

MDA ist eine Initiative der OMG, ein Branchenkonsortium mit ca. 800 Mitgliedern, deren Ziel die Etablierung von Standardrichtlinien und -spezifikationen ist, um ein allgemeines, herstellerunabhängiges Framework für die Anwendungsentwicklung bereitzustellen und so eine Interoperabilität über große Hardware- und Softwareinfrastrukturplattformen hinweg zu fördern. Die Sprache UML (Unified Modeling Language) wurde von OMG entwickelt. OMG fördert nun MDA als neueste Spezifikation. Betrachtet man die Stellung, die OMG bei der Einführung praktischer Standards einnimmt, die von der branchenspezifischen Intelligence Community (IC), Praxis, Produkten und Tools unterstützt werden sollen und berücksichtigt den Erfolg vom UML, lohnt es sich, MDA Aufmerksamkeit zu schenken. Es gibt sehr viele Informationen zu MDA, einschließlich das aktuelle Handbuch zu MDA [OMG03], das Sie auf der Website von OMG finden. Es gibt außerdem verschiedene Bücher, wie z. B. [FRA03], [KLE03] und [MEL04] sowie viele Artikel, wie beispielsweise der Artikel "An MDA Manifesto" von Grady Booch, Alan Brown, Sridhar Iyengar, James Rumbaugh und Bran Selic, der in "The MDA Journal" im Mai 2004 veröffentlicht wurde.

Die Kernpunkte von MDA Seitenanfang

In den nachfolgenden Abschnitten werden die mit MDA eingeführten besonderen Konzepte und die zugehörige Terminologie vorgestellt, die sich von den eher allgemeinen Ansätzen in MDD unterscheiden.

Auf vorhandenen Standards aufbauen Seitenanfang

MDA stützt sich auf die folgenden vorhandenen OMG-Standards:

  • MOF (Meta-Object Facility) - Neben der Definition einer Sprache für die Erstellung von Metamodellen wie beispielsweise UML und CWM definiert MOF ein Framework für die Implementierung von Repositorys für Modelle und Metamodelle und ermöglicht so einen einheitlichen Ansatz für die Manipulation dieser Modelle mit MDA. Daher ist MOF eine für MDA wichtige Technologie.
  • UML (Unified Modeling Language) - PIMs (Platform Independent Models, plattformunabhängige Modelle), PMs (Platform Models, Plattformmodelle) und PSMs (Platform Specific Models, plattformspezifische Modelle) sind in UML definiert. UML ist die Basisnotation für MDA.
  • XMI (XML Metadata Interchange) - XMI definiert ein Austauschformat für UML-Modelle, das auf XML basiert.
  • CWM (Common Warehouse Metamodel) - Was UML für die Anwendungsmodellierung bedeutet, ist CWM für die Datenmodellierung.

Plattformunabhängigkeit Seitenanfang

Eine Plattform unterstützt eine höhere Architekturschicht über die Bereitstellung von Services mit einem klar strukturierten Satz an Schnittstellen, die die Implementierungsdetails verdecken. OMG definiert in seinem Handbuch zu MDA den Begriff wie folgt:

"Eine Gruppe von Subsystemen/Technologien, die eine kohärente Funktionalität über Schnittstellen und definierte Nutzungsmuster bereitstellt, die jedes Subsystem, das auf dieser Plattform basiert, verwenden kann, ohne die Details der Funktionalitätsimplementierung kennen zu müssen."

Diese Definition ähnelt der Termdefinition zum Konzept der Schicht, wie sie in RUP verwendet wird.

Der Begriff Plattformunabhängigkeit ist nicht ganz präzise: es handelt sich hierbei mehr um eine Qualität bzw. ein Merkmal eines Modells. So könnte man beispielsweise von einem von einer bestimmten Plattform unabhängigen Modell sprechen, wenn es keine Referenzen auf von dieser Plattform bereitgestellte Services oder Funktionalität gibt. Diese Aussage ist jedoch relativ, da es schwierig ist, sich eine absolute Form von Plattformunabhängigkeit vorzustellen. Im Handbuch zu MDA wird dieser Punkt bestätigt und außerdem die Möglichkeit eingeräumt, dass es im Hinblick auf eine bestimmte Plattform Abstufungen von Plattformunabhängigkeit geben kann, wenn beispielsweise ein Modell eine verallgemeinerte Form eines Features in einer bestimmten Plattform verwendet.

Plattformunabhängigkeit wurde auch durch die Weiterentwicklung von Plattformen wie J2EE, .NET und WebSphere unterstützt, so dass höhere Abstraktionsebenen im Hinblick auf das, was für die Anwendungen bereitgestellt werden konnte, erreicht wurde. Auf diese Weise lassen sich plattformunabhängige Strukturen einfacher identifizieren und die plattformspezifischen Umsetzungen, die sie konvertieren, sind einfacher zu schreiben.

PIM (Platform Independent Model) Seitenanfang

Ein Modell ist im Hinblick auf eine bestimmte Plattform ein PIM (Platform independent Model, plattformunabhängiges Modell), wenn es nicht an die Verwendung dieser Plattform gebunden ist und mit jeder Plattform dieses Typs verwendet werden kann. In einem früheren Abschnitt wurde das Prinzip einer höheren Abstraktionsebene diskutiert und festgehalten, dass ein in UML ausgedrücktes Modell (oder ein Modell, das ein UML-Profil verwendet), das keine herstellerabhängigen Elemente enthält, nicht von einer bestimmten Infrastrukturplattform abhängig und in Struktur und Verhalten semantisch vollständig ist, ohne auf eine prozedurale Sprache zurückgreifen zu müssen, zumindest theoretisch ausführbar ist und sich auf einer hohen Abstraktionsebene befindet. Ist ein solches Modell plattformunabhängig? Ja und nein. Im Hinblick auf eine vielleicht imaginäre virtuelle UML-Maschine lautet die Antwort Nein. Betrachtet man jedoch eine ganze Klasse an Plattformen, von denen eine solche virtuelle Maschine abhängt, dann lautet die Antwort Ja.

Plattformmodell Seitenanfang

Das Plattformmodell umfasst die Konzepte (die Teile und Services darstellen), Spezifikationen, Schnittstellendefinitionen, Vorgabendefinitionen und andere Anforderungen, die eine Anwendung für eine bestimmte Plattform benötigt. In MDA werden die Plattformmodelle detailliert beschrieben und formalisiert, z. B. in UML, und sind in einem MOF-konformen Repository verfügbar. Beispielsweise können Plattformmodelle unter anderem für J2EE oder .NET erstellt werden.

PSM (Platform Specific Model)Seitenanfang

Ein PIM wird in ein oder mehrere PSMs umgesetzt, indem die Informationen hinzugefügt werden, durch die es an eine bestimmte Plattform oder mehrere Plattformen gebunden wird. Das PIM und das PSM spezifizieren immer noch dasselbe System. Das PSM ist jedoch an eine bestimmte Technologie gebunden und kann plattformspezifische Elemente enthalten. Beachten Sie, dass daraus nicht gefolgert werden kann, ob es sich um einen großen oder kleinen Umsetzungsschritt (von PIM zu PSM oder die zugehörige Plattform) handelt. Eine Umsetzung, bei der durch die Anwendung einer kleinen Gruppe von Mustern das Modell optimiert und in einigen Fällen sogar spezifiziert wird. Auch hier wird die Relativität der Begriffe PIM und PSM zum Ausdruck gebracht.

Blickwinkel und Sichten Seitenanfang

Diese Begriffe werden in MDA und in MDD auf dieselbe Weise verwendet:

  • Ein Blickwinkel ist eine theoretische "Position", aus der verschiedene Aspekte oder Probleme des Systems unter Anwendung von Konzepten und Regeln als konzeptionelle Filter sichtbar gemacht werden. Wenn man berücksichtigt, dass einige Informationen zum System unterdrückt werden, ist es eine Art der Abstraktion. Der Begriff Perspektive wird ähnlich verwendet.
  • Aus einem Blickwinkel sehen Sie Sichten, die Projektionen von Modellen sind und Entitäten anzeigen, die von diesem Blickwinkel aus relevant sind.

In MDA kann ein System aus drei Blickwinkeln betrachtet werden: aus einem verarbeitungsunabhängigen, einem plattformunabhängigen und einem plattformspezifischen Blickwinkel.

Verarbeitungsunabhängiger Blickwinkel Seitenanfang

Ein verarbeitungsunabhängiger Blickwinkel lässt Sie den Systemkontext, die Anforderungen und Vorbedingungen, nach denen das System betrieben werden und die Komponenten in der Umgebung, mit denen es interagieren muss, betrachten. Aus diesem Blickwinkel heraus, sehen Sie keine Details der Systemstruktur oder des Systemverhaltens.

Das CIM (Computation Independent Model, verarbeitungsunabhängiges Modell) ist die Sicht eines Systems oder eines zukünftigen Systems aus einem verarbeitunsunabhängigen Blickwinkel. Das CIM ähnelt konzeptionell einer Kombination aus dem Domänenmodell in RUP, das aus einer Reihe von Artefakten, einschließlich Geschäftsglossar und Geschäftsanalysemodell, besteht, die das Ergebnis der Aufgabe "Domänenmodell entwickeln (in der Geschäftsmodellierung)" sind, und dem Anwendungsfallmodell, das die verarbeitungsunabhängige Beschreibung des Systemverhaltens darstellt. Das von Fachleuten formulierte CIM stellt eine wichtige Verbindung (während der Analyse und des Designs) bei der Identifizierung von Schlüsselabstraktionen im zukünftigen System dar.

Plattformunabhängiger BlickwinkelSeitenanfang

Der plattformunabhängige Blickwinkel ist relativ zu einer bestimmten Plattform. Aus diesem Blickwinkel sehen Sie die Struktur und das Verhalten eines Systems ohne die Details dieser Plattform. Das PIM ist eine Sicht des Systems aus dem plattformunabhängigen Blickwinkel.

Plattformspezifischer Blickwinkel Seitenanfang

Aus dem plattformspezifischen Blickwinkel, ebenfalls relativ zu einer bestimmten Plattform, sehen Sie das, was bisher aus dem plattformunabhängigen Blickwinkel zu sehen war, jedoch sehen Sie jetzt auch die Details zur Plattformverwendung. Das PSM ist eine Sicht des Systems aus dem plattformspezifischen Blickwinkel.

Automatisierung der Umsetzung Seitenanfang

Ein elementares Prinzip in MDA ist die Umsetzung, und die Modellumsetzung wird definiert als "den Prozess der Konvertierung eines Modells in ein anderes Modell desselben Systems". In MDA wird auch ein kleines Muster zur Visualisierung der Konvertierung und zur Veranschaulichung der Verwendung einiger bereits genannter Begriffe definiert:

MDA-Muster mit PIM und anderen Informationen als Eingabe für eine Umsetzung und PSM und Umsetzungsbericht als Ausgabe.

Das MDA-Muster

Mit einem Diagramm wird die Bedeutung der Umsetzung veranschaulicht: Die Umsetzung verwendet das PIM und andere Informationen, und kombiniert sie, um daraus ein PSM zu erstellen.

Modellumsetzungen können natürlich auch manuell durchgeführt werden. Darin unterscheiden sie sich nicht von der üblichen Vorgehensweise beim Softwaredesign. MDA ist auch hier hilfreich, wenn es darum geht, die Umsetzungsidee, den Prozess und die zusätzlich benötigten Informationen zu skizzieren und zu formalisieren. In MDA wird empfohlen, einen Bericht der Umsetzung zu erstellen. Dies ermöglicht Rückverfolgbarkeit vom PIM zum PSM, da der Bericht auch eine Zuordnung der Elemente des PIM zu den Elementen des PSM enthalten sollte. Der größte Nutzen liegt in der Möglichkeit, Umsetzungen zu automatisieren, selbst wenn es sich nur um partielle Automatisierungen handelt. Dies bietet dieselben Vorteile, die auch aus der Ablösung der Programmierung mit Assemblern durch höhere Programmiersprachen entstanden sind.

Wie wird die Umsetzung durchgeführt? Seitenanfang

In der MDA wird keine Umsetzung vorgeschrieben. Es wird eine an der ausgewählten Plattform orientierte Zuordnung vorbereitet, um eine Spezifikation darüber zu erstellen, wie ein PIM in ein PSM für diese Plattform umgesetzt wird. Aus dieser Zuordnung wird eine Umsetzungsdefinition (evtl. als Reihe von Umsetzungsregeln ausgedrückt), die Umsetzungsparameter enthalten kann, die in einer Definitionssprache für Umsetzungen geschrieben ist. Mit dem von OMG erstellten RFP (MOF 2.0 Query/Views/Transformations RFP) sollen die Sprachen (für MOF) für die Erstellung von Modellsichten, Modellabfragen und die Erstellung von Umsetzungsdefinitionen standardisiert werden. Im Handbuch zur MDA werden verschiedene Umsetzungsansätze beschrieben. Hierzu gehören unter anderem:

  • Metamodellumsetzung - Dieser Ansatz geht davon aus, dass ein MOF-Metamodell auf PIM-Ebene in der Sprache vorliegt, in der das PIM erstellt wurde. Außerdem gibt es für die ausgewählte Plattform ein Metamodell auf PSM-Ebene in der Sprache, in der ein PSM erstellt werden kann. Eine Zuordnung zwischen den beiden Metamodellen kann dazu verwendet werden, eine Umsetzungsdefinition zu erstellen, aus der dann das PIM in ein PSM konvertiert wird.
  • Markierung - Es wird eine Zuordnung für die ausgewählte Plattform vorbereitet. Diese Zuordnung wird für die Erstellung einer Umsetzungsdefinition verwendet. Die Definition enthält eine Reihe von Markierungen, die für die Kennzeichnung von Elementen des PIM verwendet werden, aus denen dann ein 'markiertes PIM' zusammen mit einer Definition erstellt wird, die die Informationen zur Verwendung der markierten Elementen enthält. Aus dem markierten PIM wird nach weiteren Umsetzungen das PSM erstellt. Die Kennzeichnung ist üblichweise ein manueller Vorgang, die weiteren Umsetzungen können jedoch automatisiert werden.
  • Modellumsetzung - Das PIM wird aus in einem Modell angegebenen plattformunabhängigen Typen erstellt, in dem die Elemente im PIM Untertypen der plattformunabhängigen Typen sind. Es wird eine bestimmte Plattform ausgewählt, die einer Reihe plattformspezifischer Typen zugeordnet ist. Es wird eine Zuordnung zwischen den beiden Typgruppen erstellt, aus der eine Umsetzungsdefinition entsteht, die auf das PIM angewendet wird. Das daraus resultierende PSM wird in Untertypen der plattformspezifischen Typen ausgedrückt. Dieser Ansatz ähnelt der Metamodellumsetzung. Die Umsetzung ist jedoch hier auf die Typen in einem Modell beschränkt und nicht auf die Konzepte aus einem MOF-Metamodell.
  • Musteranwendung - Das PIM wird aus einer Reihe von Typen und abstrakten Mustern erstellt, die plattformunabhängig sind. Für die ausgewählte Plattform sind eine Reihe plattformspezifischer Typen und Muster vorhanden. Es wird eine Zuordnung zwischen den beiden Typen und der Mustergruppe erstellt, aus der eine Umsetzungsdefinition entsteht, die auf das PIM angewendet werden kann. Daraus entsteht ein PSM, bei dem die abstrakten Muster in plattformspezifische Muster umgesetzt wurden.

Nähere Informationen finden Sie im Handbuch zu MDA [OMG03].

Wie wird die Umsetzung angewendet? Seitenanfang

Das einfachste Szenario für die Anwendung von MDA sieht folgendermaßen aus:

  1. Bereiten Sie ein PIM vor.
  2. Wählen Sie eine Plattform aus.
  3. Bereiten Sie eine Zuordnung vor, wenn nicht bereits eine vorhanden ist.
  4. Erzeugen Sie mit einer Umsetzung ein PSM.
  5. Konvertieren Sie das PSM in Code. Wenn das PSM nicht weiter optimiert werden muss und direkt implementiert werden kann, handelt es sich um eine Implementierung, wie sie im nächsten Abschnitt definiert ist.

PSMs für andere Plattformen können auf dieselbe Weise generiert werden.

Wiederholte Anwendung des MDA-Musters Seitenanfang

Das MDA-Muster kann wiederholt angewendet werden. Ein generiertes PSM auf der einen Ebene wird zum PIM für die nächste, d. h. für die nächste, stärker spezialisierte Plattform. Beachten Sie, dass es bei der in RUP beschriebenen und von dem Toolset IBM Rational unterstützten modellorientierten Entwicklung darum geht, die Anzahl der Schritte, die für die Präzisierung verwendet werden, zu verringern, d. h. so schnell wie möglich, von einer Darstellung, die der Problemstellung des Kunden am nächsten kommt, zu einer ausführbaren Form zu gelangen.

Drei Anwendungsmöglichkeiten von MDA-Mustern für drei verschiedene Plattformen

Wiederholte Anwendung des MDA-Musters

Das oben abgebildete Diagramm zeigt drei Anwendungsmöglichkeiten von MDA-Mustern. Das erste PIM wird zu einem von Plattform 1 abhängigen PSM und dann so umgesetzt, dass es auch von Plattform 2 abhängig ist. Anschließend wird es so umgesetzt, dass es von den Plattformen 1, 2 und 3 abhängig ist.

Allgemeine Modell-zu-Modell-Umsetzung Seitenanfang

Dasselbe Konzept kann auch auf eine allgemeine Umsetzung angewendet werden, d. h. ein beliebiges Modell in ein beliebiges Modell. Sind beispielsweise zwei Metamodelle vorhanden, in deren Sprachen Modelle ausgedrückt werden, kann grundsätzlich eine Zuordnung erstellt werden, aus der eine Umsetzungsdefinition entsteht. Dies wird auf dieselbe Weise angewendet wie bei der Umsetzung von PIM zu PSM.

Implementierung Seitenanfang

Im Handbuch zu MDA wird der Begriff "Implementation" (Implementierung) ähnlich im Implementierungsmodell in RUP verwendet. Es ist die Spezifikation aller Implementierungselemente, die für die Konstruktion, das Deployment, die Installation und den Betrieb des Systems notwendig sind.

Ein PSM selbst kann eine Implementierung sein oder weitere Präzisierungsschritte erfordern, bevor es in Code konvertiert werden kann. Bei einem Implementierungs-PSM kann der Manifestierungsschritt des PSM übersprungen werden. Es kann direkt in Code konvertiert werden. In diesem Fall kann das abstraktere PIM von der Umsetzungssteuerkomponente direkt in Code konvertiert werden. Eine Visualisierung des Code kann dennoch dem Entwickler zur Veranschaulichung bereitgestellt werden (Reverse-Engineering aus dem Code).

Putative VorteileSeitenanfang

Portierbarkeit und InteroperabilitätSeitenanfang

Mit MDA besteht die Hoffnung, dass die Kosten und die Unsicherheiten in einer sich ständig wandelnden Technologiewelt durch die erneute Ausrichtung eines relativ stabilen Satzes von PIMs an beliebige, neue Technologien gelenkt werden können. Es wird damit gerechnet, dass mit der zunehmenden Akzeptanz der MDA die Entwickler der neuen Technologie auch Zuordnungen bereitstellen werden, so dass Umsetzungen schnell durchgeführt werden können.

Durch die Erweiterung der PIM-PSM-Zuordnungen auf zwei Plattformen kann mit MDA eine Brücke zwischen den beiden PSMs geschlagen werden und letztlich auch zwischen zwei Implementierungen, so dass ein PIM über Plattformen hinweg verteilt werden kann. Viele Unternehmen entwickeln in heterogenen Umgebungen, die sich aus alten und neuen Technologien zusammensetzen, so dass die Realisierung von Interoperabilität potenziell von großem Nutzen ist.

Geringe Kosten der Lebenszyklen Seitenanfang

ProduktivitätSeitenanfang

Bei der Entwicklung mit MDA richtet sich die Aufmerksamkeit auf das abstraktere PIM. Mit einem leistungsfähigen Toolset zur Generierung eines PSM (oder Code) sollte eine solche Umgebung ähnlich produktiv sein wie die Arbeit mit einer höheren Programmiersprache produktiver ist als die Arbeit mit einem Assembler, insbesonders da ein PIM, oder etwas in der Art, oftmals ohnehin entwickelt wird, wie beispielsweise das Designmodell in RUP. Der Produktivitätsgewinn hängt im Wesentlichen davon ab, wie viele manuelle Eingriffe im Umsetzungsprozess erforderlich sind.

Qualität Seitenanfang

Im Idealfall liegt in MDA der Fokus auf der Pflege des PIM. Unter der Voraussetzung, dass das PIM sorgfältig ausgearbeitet ist, sollten daher auch weniger Mängel im Produktlebenszyklus auftreten, da es weniger Möglichkeiten für einen Menschen gibt, einen Mangel einzuführen, und die festgestellten Mängel in der Behebung aufgrund der automatisierten Umsetzung nicht so kostenintensiv sein sollten. Da eine Konzentration auf das PIM auch sehr eng mit den Problemstellungen der Domäne verbunden ist, ist eine Befriedigung der Bedürfnisse der Benutzer umso wahrscheinlicher.