UML mit Style

UML-Diagramme können manchmal wirklich langweilig sein. Vor allem dann, wenn man gezwungen wird, UseCases oder Sequenzdiagramme für triviale Dinge anzufertigen, die man im Kopf sowieso schon zu Ende gedacht hat und eigentlich nur noch runterprogrammieren will.

Bei komplexeren Programmen kommt man allerdings nicht drum rum. Es stellt sich also die Frage: Wie und mit welchem Tool mache ich jetzt meine Diagramme? In den letzten Wochen sind mir einige interessante Ansätze untergekommen, die ich hier nun zusammentragen möchte.

Saffron AIR UML

Bisher verwende ich ArgoUML für Klassendiagramme und JUDE für Sequenzdiagramme (diese lassen sich mit ArgoUML nur sehr umständlich erstellen und der Editor ist immer noch sehr buggy) für den Alltagsgebrauch. Ich komme eigentlich recht gut damit zurecht, aber Spaß macht es nicht wirklich.

Saffron geht einen ganz anderen Weg. Es nutzt das neue AIR (von Adobe) um eine schicke, interaktive Oberfläche zu bieten. Das Programm ist leider noch nicht fertig, aber die Screenshots sehen schon sehr vielversprechend aus.

UMLGraph

Ich habe mich schon oft gefragt, welches Tool denn die ganzen Autoren der Fachbücher für die Diagramme verwenden, denn diese sehen meist sehr schick aus. Ich denke die Antwort gefunden zu haben: Mit UMLGraph lassen sich Klassen- und Sequenzdiagramme mit einer Metasprache definieren und mit der Unterstützung von Graphviz in Bilder wandeln. Das Ergebnis sieht sehr professionell aus. Allerdings ist diese Art der Modellierung nicht für den Entwurfsprozess geeignet, eher fürs Reinzeichnen.

Zum Entwerfen von Systemen habe ich auf YouTube ein interessantes Video entdeckt.

Allerdings ist mir jetzt schon bei mehreren Projekten aufgefallen, das der Rechner in der Entwurfs- und Planungsphase mehr im Wege steht als das es einen Vorteil gebracht hätte. Ein Klassendiagramm ist schneller mit Papier und Stift gezeichnet. Wenn man zusammen an einem Tisch sitzt, kann jeder schnell seine Ideen einbringen und dazumalen, und wenn das Chaos auf dem Papier zu groß wird, zeichnet man es noch einmal neu. Dies hat auch den Vorteil, das man sich viel mehr Gedanken über die Klassen macht. Wenn man eine Klasse in einem UML-Tool erstellt, und an den richtigen Platz gerückt hat, löscht man es in den seltensten Fällen wieder.

Noch was zu den UseCases: Ja ich mag sie nicht. Sie verbraten wertvolle Zeit und niemand weiß sie zu würdigen. Der Kunde erschrickt beim Anblick und die Programmierer lesen nicht gerne. Sie bevorzugen eher einfache (nicht unbedingt UML-Konforme) Skizzen, die direkt verstanden werden können und natürlich das bindende Kapitel Funktionale Anforderungen aus dem Projektauftrag. Auch der Artikel auf mittechnical.com konnte mich (noch) nicht überzeugen. Vielleicht schaffst Du es ja mit einem Kommentar :-)