imported>Millbart: Revert auf Version von :Benutzer:Millbart (18:05 Uhr, 22. Februar 2024). Grund: siehe Diskussion und die Weblinks sind tot.

2024-04-21T14:21:24Z

Revert auf Version von Benutzer:Millbart (18:05 Uhr, 22. Februar 2024). Grund: siehe Diskussion und die Weblinks sind tot.

Neue Seite

Ein '''UML-Werkzeug''' ist ein Anwendungsprogramm, das einige oder auch alle Phasen im Entwicklungsprozess oder die Erzeugung von [[Artefakt (UML)|Artefakten]] unterstützt, die in der [[Unified Modeling Language]] (UML), einer Modellierungssprache für [[Software]] und andere Systeme, beschrieben sind.

Ein Teil der [[Modellierung]]swerkzeuge für den [[Software]]entwurf ist nicht auf UML fokussiert, unterstützt jedoch Aspekte der UML zu einem gewissen Grade, als Erweiterung oder Komponente der grundlegenden Funktionalität.

== Aspekte der Funktionalität ==
Aspekte der Funktionalität von UML-Werkzeugen sind unter anderem die Unterstützung von Diagrammen, Codeerzeugung und Reverse Engineering.

=== 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 [[modellgetriebene Architektur|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 (Programmiersprache)|Java]]-Code zu erzeugen. Des Weiteren können verschiedene Arten von UML-Modellen ineinander umgewandelt werden. Dies wird zum Beispiel durch [[MOF QVT|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-[[Template (Programmierung)|Templates]] bereitstellten, in welchem dann vordefinierte [[Token (Übersetzerbau)|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 [[XML Metadata Interchange|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 [[Symbol]]e 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 (UML)|Classifier]], named frames in [[Sequenzdiagramm]]en und das [[Zeitverlaufsdiagramm]].

== Siehe auch ==
* [[:Kategorie:UML-Werkzeug]]

== Weblinks ==
* [http://www.fit-for-bit.de/umltools.pdf Eine Übersicht über 100 UML-Werkzeuge] von [[Mario Jeckle]]† (Stand 2004)

[[Kategorie:UML-Werkzeug| ]]

UML-Werkzeug - Versionsgeschichte

imported>Millbart: Revert auf Version von :Benutzer:Millbart (18:05 Uhr, 22. Februar 2024). Grund: siehe Diskussion und die Weblinks sind tot.