Unified Modeling Language (UML) und Model Driven Architecture (MDA) spielen eine wichtige Rolle in der Entwicklung und Implementierung von heterogenen Software Systemen.

 

UML ist ein Standard und eine ziemlich genau definierte Sprache, aber sie lässt jede Menge Raum für Interpretationen zu. Genau dieser Umstand macht es auf der einen Seite schwierig, sie zu handhaben, lässt aber auf der anderen Seite genau jenen Spielraum zu, den kreative Architekten und Designer brauchen. Gerade auch deshalb wurde und wird UML als Standard bei der Modellierung von Software von so vielen Personen verwendet. Hätte die OMG den Standard wesentlich strikter definiert, hätte UML vielleicht nie diese Verbreitung und Akzeptanz erfahren.

 

Sogar die Entwickler und Architekten von UML (Booch, Jacobson und Rumbaugh) sind sich nicht immer einig in der Auslegung „ihres“ Standards. Es gibt zwar eine genau definierte Anzahl von Diagrammtypen (in UML 2.0 sind es 13 Stück), die ihrerseits wiederum genau spezifizierte Elemente enthalten dürfen, aber es spricht nichts dagegen, Elemente aus verschiednen Diagrammtypen zu kombinieren.

 

Das Hauptaugenmerk bei der Designphase sollte nicht darauf gelegt werden, ein 100%ig dem UML-Standard-entsprechendes Diagramm zu erstellen. Es ist viel wichtiger ein gutes Design, eine gute Architektur zu machen, als die Diagramme auf Standardkonformität zu trimmen. In diesem Sinne ist UML viel mehr als Hilfsmittel und als Unterstützung für alle Projektbeteiligten zu sehen, welches zur Verbesserung der Kommunikation zwischen den Beteiligten und so auch zum besseren Verständnis des Problems bzw. der Aufgabenstellung dienen soll.

 

Auch wenn UML viele nützliche Diagrammtypen enthält, wird man damit in vielen Fällen nicht das Auslangen finden. In solchen Situationen sollte man nicht zögern, Diagramme zu erstellen, die nicht UML-konform sind. Keiner, nicht einmal die Erfinder von UML, verwenden das komplette Set an Diagrammen. Die meisten verwenden nur einen kleinen Teil des Standards; auch das ist kein Problem.

 

Neben den bereits aus UML 1 bekannten Diagrammen, wie Activity-, Class-, Component-, Deployment-, Sequence-, State- und Use Case-Diagram, gibt es in UML 2.0 einige zusätzliche Diagrammtypen: Composite Structure, Interaction Overview, Object-, Package- und Timing-Diagramm. Das Collaboration-Diagramm aus Version 1 wurde in Communication-Diagramm umbenannt.

 

In Zusammenhang mit UML wird auch oft der Ausdruck MDA (Model driven Architecture) gebraucht.

MDA ist eine Methode, ein Ansatz zur Entwicklung von Software, wobei UML als zugrunde liegende Modellierungsprache dient.

 

MDA unterteilt den Entwicklungsprozess in zwei Teile. Als erstes wird eine Anwendung vollständig unabhängig von ihrer Zielplattform modelliert. Das Ergebnis dieser Phase ist als Platform Independent Model (PIM). Für die Erstellung dieses Modells wird zumeist UML verwendet. Der zweite Schritt ist besteht darin, aus diesem Modell ein spezifisches der Zielplattform angepasstes Modell zu erzeugen. Dieser Vorgang kann auch automatisiert von einem Tool erbracht werden. Das Ergebnis dieses Vorganges ist das Platform Specific Model (PSM).

 

Wenn der Übergang von dem plattformunabhängigen zu dem plattformspezifischen Modell automatisiert abläuft, dann kann man UML als Programmiersprache bezeichnen. Als letzter Schritt wird dann aus dem PSM der Code erzeugt.

Wie realistisch ist es heute, diesen theoretischen Ansatz auch in die Praxis umzusetzen? Nun, zum einen wird es davon abhängen, wie gut die Tools bei der Übersetzung arbeiten. Diese Tools sind derzeit noch nicht sehr weit verbreitet, werden aber in Zukunft mit Sicherheit besser werden und daher auch mehr Verbreitung finden.

 

Das größere Problem dürfte aber sein, ob UML als Programmiersprache bei den Entwicklern angenommen wird. Denn nur wenn dieser Ansatz von einer kritischen Masse an Personen Verwendung findet, hat diese Idee eine Chance.