Germany’s next Top(UML)model

Ein Bild sagt mehr als tausend Worte.

Eine Weisheit, die sehr alt ist, aber trotzdem im Bereich der IT, im Besonderen der Anwendungsentwicklung bzw. in der Anforderungsaufnahme einer Entwicklung häufig ignoriert wird. Zumindest in den Bereichen, in welchen ich unterwegs bin/bisher war.

Dabei wird mit der UML-Beschreibungssprache, nicht unbedingt mit der ersten Version, aber sicherlich seit der Version Zwei und entsprechender Werkzeuge eine m.E. ganz adäquate Unterstützung angeboten, um dem Bild auch in der Anwendungsentwicklung seine notwendige Bedeutung zu geben.

Ich selber hatte meine ersten Berühungspunkte mit der UML erstmals im Jahre 1999, aber seitdem immer wieder nur sporadisch damit zu tun. In der Regel werden lieber Hunderte von Word-Dokumenten erstellt, aus welchen dann jeder Beteiligte (Kunde, Auftragnehmer, Projektleiter, Entwickler…) in der Regel etwas anderes heraus liest.

Unstimmigkeiten und Change Requests sind dann eher noch harmlose Ergebnisse dieser Vorgehensweise.

Dabei bieten neuere UML-Werkzeuge wirklich für fast alle Anwendungsfälle gute Unterstützungen an. Selbst Screens- und Screenflows (etwas, was dann auch der Fachexperte gut verstehen kann) lassen sich inzwischen, wenn auch öfters etwas properitär, gut mit diesen Werkzeugen beschreiben.

Und viel Geld muss man inzwischen auch nicht mehr für eine solche Unterstützung ausgeben. Sicherlich werden viele Experten sagen, dass es unbedingt der Rational Software Architect von IBM sein muss, aber ich habe in meinen Untersuchungen festgestellt, dass man wirklich nicht eine Kleinwagensumme, auch wenn man eine „UML-Abwrackprämie“ 🙂 angeboten bekäme, ausgeben muss, um „UML zu sprechen“.

Der Enterprise Architect, für einen Bruchteil der Summe des RSA von IBM, hat mich, z.B. , sehr überzeugt. Ein Architekt kann hier m.E. auch deutlich weitergehender modellieren, als mit einem RSA. Der EA bietet z.B. auch eine direkte Unterstützung für das Screendesign und auch für die Prozessmodellierung an und ist in der Handhabung deutlich einfacher und flexibler. So zumindest habe ich den direkten Vergleich eines EA mit einem RSA erlebt, natürlich nicht hoch wissenschaftlich, sondern tief subjektiv und emotional :-).

Aber man muss heute auch kein Geld für ein UML-Design ausgeben und kann trotzdem Einiges erreichen. So bietet das OpenSource Projekt UML2Tools für Eclipse eine (fast) ausreichende UML-Unterstützung für Eclipse an (3.4.x). Sicherlich nicht in dem Umfang, wie es der EA oder RSA anbieten, aber um zu prüfen, ob ich mit UML weiter komme, als mit Word und Powerpoint, reicht dieses Projekt allemal. Und es ist erst der Beginn freier UML2-Tools. Wer weiß, was wir in Zukunft noch alles erleben dürfen.

Aber bei aller „UMLlerei“. Eines sollte man nicht, zumindest nicht am Anfang, probieren: Roundtrip-Engeneering.

Lieber UML für die Anlayse- und Designphase verwenden und danach den Code als Dokumentationsbasis verwenden. Leider habe ich bei einigen Projekten immer wieder erlebt, wie eine 360-Grad-Wende versucht wurde. Von der Phase „Der Code ist alles“ zu der Phase „UML ist alles“ und das meistens in einer Iteration. Am Ende des Tages sind solche Projekte meistens gescheitert, und man ist schlussendlich zu dem Modell „Der Code ist alles“ zurück gegehrt, auch kein wirklicher Erfolg.

Deswegen empfehle ich am Anfang: Erst UML, dann Code und dann nochmal nachdenken und erneut entscheiden.

Welche UML-Werkzeuge ich benutze ist dann sicherlich auch Geschmacksache (es gibt natürlich deutlich mehr gute UML-Werkzeuge, als hier aufgezählt).

Eines ist allerdings heute möglich: UML auch große Investitionen in Tools!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.