Erfahrungsbericht UML colors

UML colors war bereits früher ein Thema dieses Blogs. An dieser Stelle kommt deshalb ein Erfahrungsbericht über einen Praxiseinsatz vom UML colors. Der Einsatz liegt zwei Jahre zurück, und die verschiedenen Modelle können leider auf Kundenwunsch nicht hier veröffentlicht werden.

Ein JEE-Projekt für eine kleine Anwendung (Modell als EJBs, View über JSF), die das Testen und Mocking von WebServices unterstützt, sollte von drei Personen durchgeführt werden. Da wir noch nie zusammengearbeitet haben, prallten auch drei verschiedene Ansätze zu objektorientierten Analyse / Design aufeinander.
Normalerweise hätten wir jetzt über Diskussionen (und auch über die Verwendung von GRASP) zu einem gemeinsamen Modell finden können. Da ich aber schon vorher in Kontakt mit UML colors kam (unter anderem durch die IDE „Together„, die das sehr gut unterstützt), schlug ich vor, unser erarbeitetes (und noch nicht ganz vollständiges) Domänenmodell nochmals mit UML colors zu erstellen.

Da wir durch vorherige Diskussionen schon die meisten unklaren Punkte beseitigt hatten, ging die Erstellung des Modells relativ schnell. Eine große Verbesserung gegenüber unserem vorherigen Modell war die strikte Trennung von PPT und Description. Hatten wir vorher noch bei einigen Klassen unbewußt auf diese Trennung verzichtet, konnten diesmal die Descriptions direkt gesucht und identifiziert werden.

Als ein ungewohntes Konzept haben sich die „Rollen“ entpuppt. Dazu muss man Peter Coad verstehen, der immer eine Hinterfragung der Rolle (ist eine Rolle mehr als ein Marker, enthält sie evtl. mehr Informationen) fordert. Wenn eine Rolle zusätzliche Informationen (z.B. Berechtigungen) enthält, kommt man mit dem Rollen-Verständnis von UML colors gut zurecht.

Moment-Intervals und Rollen hängen voneinander ab, d.h. eine Rolle kann man am Besten dann identifizieren, wenn man schon eine Vorstellung des Moment-Intervals, an dem diese Rolle teilnimmt, besitzt. Darüberhinaus war ich erstaunt, dass die Moment-Intervals sich relativ einfach und ohne viele Diskussionen identifizieren ließen.

Das fertige Modell hat mich überrascht. UML colors hat uns wenig Freiraum für Meinungsverschiedenheiten gelassen, und am Ende stand ein Modell, das meiner Meinung nach verständlicher als unser klassisches Modell war.

Die Entwicklungsgeschwindigkeit läßt sich nicht direkt ablesen, denn während des Entwurfs des „klassischen“ Modells wurden auch Dinge geklärt, die dann bei dem UML colors Modell bekannt waren. Subjektiv kam mir die Modellierung nach UML colors aber bedingt durch weniger Diskussionen (über Modellierungsentscheidungen, damit sind jetzt nicht die Diskussionen über Anforderungen / Fachlichkeiten gemeint, die bereits während des Entwurfs des „klassischen“ Modells geführt wurden) aber schneller vor.

Die am Projekt mitwirkenden Personen waren neben mir ein Kollege mit ~20 Jahren Berufserfahrung und ein Kollege mit ~7 Jahren Berufserfahrung. Also reichlich Praxiserfahrung und Design-Fertigkeiten. Dass trotzdem ein deutlich anderes Modell nach dem Ansatz von Peter Coad herauskam, hat mich daher erschreckt; eigentlich dachte jeder von uns, dass er gute, funktionierende Modelle entwerfen kann. An den Gedanken, dass ein schematisches Vorgehen (dass aber weiterhin kreativ bleibt) zu einer besseren Lösung (wie oben beschrieben erscheint sie mir verständlicher) führen kann, musste ich mich erst gewöhnen.

Fazit: UML colors hat in unserem Projekt sehr gut funktioniert, und es hat uns Diskussionszeit gespart. Ich suche immer noch nach der nächsten Gelegenheit, diesen Ansatz wieder einzusetzen.

Schreibe einen Kommentar

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