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
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)
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?
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?
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?
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 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)
Zielsetzung
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
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
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
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)
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
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)
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
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
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
Blickwinkel
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
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
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:
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?
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?
Das einfachste Szenario für die Anwendung von MDA sieht folgendermaßen aus:
-
Bereiten Sie ein PIM vor.
-
Wählen Sie eine Plattform aus.
-
Bereiten Sie eine Zuordnung vor, wenn nicht bereits eine vorhanden ist.
-
Erzeugen Sie mit einer Umsetzung ein PSM.
-
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
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.
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
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
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 Vorteile
Portierbarkeit und
Interoperabilität
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
Produktivität
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
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.
|