Eclipse UML: Ein guter Kompromiss

29.03.2005
Von   
Bernhard Steppan arbeitet als IT-Chefarchitekt bei DB Systel GmbH (Deutsche Bahn) in Frankfurt am Main. Er hat 100+ Artikel und zahlreiche Bücher über C++ und Java verfasst. Er betreibt mehrere Blogs, unter anderem http://steppan.net, http://artouro.org und http://tourbine.com

 

Drei Kategorien für UML-Werkzeuge

UML-Werkzeuge existieren in verschiedenen Ausprägungen für unterschiedliche Ansprüche der Entwickler.

Es gibt Malwerkzeuge, bei denen der Entwurf im Vordergrund steht, nicht jedoch die spätere Implementierung. Sie dienen dazu, spielerisch zu modellieren, ohne von den Grenzen einer konkreten Programmiersprache oder späteren Implementierung eingeengt zu werden. Entwicklern, die diese Werkzeuge verwenden, kommt es nicht darauf an, dass das Modell und die spätere Implementierung deckungsgleich sind.

Werkzeuge, bei denen die Modellierung im Vordergrund steht, die es aber auch zulassen, dass Quelltext erzeugt wird, gehören zur zweiten Kategorie. Bei ihnen ist jedoch ein Abgleich zwischen Modell und Quelltext entweder nur schwer realisierbar, sehr umständlich oder überhaupt nicht gewünscht. Die Werkzeuge dienen hauptsächlich dazu, mit allen Freiheiten zu modellieren und danach initial Quelltext zu erzeugen, der in einer Workbench implementiert wird. Eine Abweichung der Implementierung vom Modell wird bei diesem Verfahren ebenfalls in Kauf genommen.

Die dritte Kategorie von UML-Werkzeugen, zu der auch Eclipse UML zählt, hat sich im Laufe der Jahre durchgesetzt. Für diese Tools ist Code und Modell nur eine unterschiedliche Sicht auf die Software. Hier entsteht zwischen dem Ausgangsmodell (Analyse) und dem späteren Design sowie der Implementierung kein Bruch. Implementierung und Modell sind also - zumindest bei den codezentrierten Klassendiagrammen - prinzipiell deckungsgleich. Ändert sich die Implementierung, aktualisiert das Tool in der Regel automatisch auch das Modell. Ein Austausch zwischen Modell und Quelltext (Roundtrip) ist daher problemlos möglich.