Diagrammunterstützung

Diagrammunterstützung bedeutet in diesem Zusammenhang das Erzeugen und Bearbeiten von UML-Diagrammen, das heißt Diagrammen, die konform zur graphischen Notation der UML sind.

Auf die Verwendung von UML-Diagrammen, um Diagramme von hauptsächlich objektorientierter Software zu zeichnen, hat man sich im Allgemeinen unter Software-Entwicklern geeinigt. Andererseits wird kontrovers diskutiert, ob und in welchen Phasen der Softwareentwicklung solche Diagramme überhaupt benötigt werden, und wie (wenn überhaupt) diese Diagramme aktualisiert werden sollten. Der Vorrang des Programm-Codes führt oft dazu, dass die Diagramme vernachlässigt werden.

Modelltransformation

Ein wesentlicher Bestandteil der modellgetriebenen Architektur ist die Fähigkeit, verschiedene Modelle ineinander zu transformieren. Es ist zum Beispiel möglich diese Fähigkeit auf die Codeerzeugung anzuwenden, um aus einer UML-Notation automatisch Java-Code zu erzeugen. Des Weiteren können verschiedene Arten von UML-Modellen ineinander umgewandelt werden. Dies wird zum Beispiel durch QVT (für Queries/Views/Transformations) ermöglicht. Ein Beispiel für eine QVT-Implementierung ist die ATL-Sprache von INRIA.

Quelltexterzeugung

Quelltexterzeugung bedeutet in diesem Zusammenhang, dass der Anwender UML-Diagramme mit spezifizierten Modelldaten erzeugt, und das UML-Werkzeug als Codegenerator fungiert und daraus einen Teil oder den gesamten Quelltext ableitet. Bei einigen Werkzeugen kann der Anwender ein Gerüst des Programm-Quelltextes in Form eines Code-Templates bereitstellten, in welchem dann vordefinierte Token während der automatischen Codeerzeugung durch Quelltext ersetzt werden.

Der Nutzen der automatischen Quelltexterzeugung aus UML-Diagrammen als solcher ist strittig und hängt zweifellos von dem spezifischen Feld und Grad der Anwendung ab. In bestimmten Bereichen ist die Codeerzeugung eine etablierte Methode und nicht auf UML beschränkt.

Die Idee, die Ebene des Programmcodes komplett zu verlassen und das „Programmieren“ auf der Ebene von UML zu beginnen (also auf Entwurfsniveau), ist unter Entwicklern umstritten. Es ist die Vision der modellgetriebenen Architektur. Die Idee ist nicht so verbreitet wie andere Werkzeuge der Softwareentwicklung, etwa Compiler und Systeme für das Konfigurationsmanagement.

Eine oft zitierte Kritik lautet, dass UML-Diagrammen eben jene Detailgenauigkeit fehlt, die notwendig ist, um die im Quellcode enthaltene Information abzudecken. Manche Entwickler sagen sogar: „Der Code ist der Entwurf“. Allerdings handelt es sich bei dem, was mit der nicht umsonst so genannten Unified Modeling Language erzeugt wird, immer bestenfalls um ein Modell von Software, nicht um die Software selbst.

Reverse Engineering

Reverse Engineering bedeutet in diesem Kontext, dass das UML-Werkzeug den Quelltext als Eingabe liest und daraus entsprechende UML-Diagramme und Modelldaten ableitet (im Gegensatz zu der etwas umfassenderen Bedeutung, die im Artikel Reverse Engineering beschrieben ist). Einige der Herausforderungen des Reverse Engineering sind:

• Der Quellcode hat oft sehr viel genauere Informationen, als man in Entwurfsdiagrammen sehen möchte. Dieses Problem wird innerhalb der Software-Architektur-Rekonstruktion behandelt.
• Diagramminformation findet sich gewöhnlich nicht im Quellcode, so dass das UML-Werkzeug wenigstens für einen Anfangsschritt ein zufälliges Layout der grafischen Symbole der UML-Notation erzeugen, oder einen Layoutalgorithmus verwenden muss, der die Symbole derart platziert, dass der Anwender das Diagramm verstehen kann. Zum Beispiel sollten die Symbole so angeordnet werden, dass sie sich nicht überlappen. Gewöhnlich muss der Anwender die automatisch generierten Diagramme manuell überarbeiten, so dass sie Bedeutung gewinnen. Zudem ergibt es meist keinen Sinn, Diagramme aus dem gesamten Quellcode abzuleiten, da diese mehr Detailinformation enthalten würden, als in UML-Diagrammen von Interesse ist.
• Einige Programmiersprachen besitzen Konstrukte, die in ihrer ganzen Komplexität automatisch besonders schwierig in UML-Diagramme umzuwandeln sind, wie etwa Klassen- oder Funktions-Templates in C++.

„Roundtrip“-Engineering

Manche UML-Werkzeuge bezeichnen die Fähigkeit, den Programmcode, die Modelldaten und die UML-Diagramme konsistent zu halten, als „roundtrip“ (die Verwendung von synchronisierten Fassungen wird auch Round-Trip-Engineering genannt).

Das bedeutet, dass der Anwender die Möglichkeit hat, entweder die Modelldaten (durch Veränderung der entsprechenden Diagramme) oder den Quellcode zu verändern, und das Werkzeug das Gegenstück automatisch aktualisiert.

XMI-Unterstützung

Die meisten UML-Werkzeuge ermöglichen das Speichern und Exportieren der UML-Modelle im XMI-Format. Theoretisch sollte die von einem UML-Werkzeug erzeugte XMI-Datei von einem anderen UML-Werkzeug gelesen werden können, jedoch erweisen sich in der Praxis die komplexeren UML-Entwürfe als inkompatibel bezüglich verschiedener Werkzeuge.

Unterstützung von UML 2.0

Die UML-2.0-Spezifikation umfasst 13 verschiedene Diagramme. Verglichen mit den 1.x-Versionen gibt es viele neue Symbole und auch neue Semantik. Viele UML-Werkzeuge unterstützen angeblich UML 2.0 – in Wirklichkeit wird der neue Standard von den meisten nur teilweise umgesetzt. Erweiterungen, die von kaum einem Werkzeug unterstützt werden, sind zum Beispiel strukturierte Classifier, named frames in Sequenzdiagrammen und das Zeitverlaufsdiagramm.

Freie Software

Proprietäre Software