Archiv für den Monat: Februar 2011

Polymorphismus in UML-Sequenzdiagrammen

Polymorphismus (oder Polymorphie) ist ein wichtiges Konzept in objektorientierten Sprachen. Der verlinkte Wikipedia-Artikel beschreibt eine Sicht auf Polymorphismus, meine Sicht (und Definition) ist folgende: „Polymorphismus tritt auf, wenn verwandte Objekte auf dieselbe Nachricht unterschiedlich reagieren“. Hingegen die Beschreibung von Wikipedia (Stand 19.02.2011): „Eine Methode ist polymorph, wenn sie in verschiedenen Klassen die gleiche Signatur hat, jedoch erneut implementiert ist.“. Wikipedia definiert Polymorphismus auf der statischen Klassenebene, meine Definition findet auf der dynamischen Instanzenebene statt. Trotz dieser Unterschiede drücken die Definitionen dasselbe aus, sind also isomorph.

Am Beispiel „mehrere Aufträge eines Kunden sollen mit einem OrderChecker validiert werden“ wird im Folgenden die Darstellung von Polymorphismus in UML gezeigt.

Order-Typen

Will man Polymorphismus in UML (z.B. in Sequenzdiagrammen) darstellen, so muss man sich zunächst über die Absichten klarwerden. Meist ist eine exakte Darstellung gar nicht nötig, es genügt, eine Validierungsnachricht an die abstrakten Aufträge zu senden.

Nachricht an Auftrag

Sind die Reaktionen der unterschiedlichen Auftraginstanzen doch von Interesse, so stellt UML dafür „Found Messages“ zur Verfügung.

Konkrete Verarbeitung der Nachricht

Mit diesen Mitteln von UML ist eine Darstellung von Polymorphismus problemlos möglich.

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.

UML in Farbe: UML colors

Bei der Programmierung von Anwendungen wird (in den meisten Sprachen) mit Klassen gearbeitet. Eine Person wird durch eine Klasse (oder zumindest durch eine Instanz dieser Klasse) repräsentiert. Eine Action, die eine Buchung durchführt, ist bei der Programmierung ebenfalls eine Klasse. Hinter Person und Buchung stehen aber völlig verschiedene Konzepte, eine Person ist mit Information verknüpft und etwas dauerhaftes (im Sinne von: „sollte in einer DB gespeichert werden“). Eine Buchung (damit ist jetzt kein Objekt gemeint, welches Buchungsinformationen darstellt, sondern etwas im Sinne einer Gui-Action oder einer Stateless SessionBean) ist etwas hochdynamisches, sie besitzt keine Identität und ist die in eine Klasse gepackte Business-Logik.
Es werden üblicherweise völlig unterschiedliche Konzepte in Klassen gepackt.

Nun stellt sich die Frage: Ist eine „Klasse“ genug, um diese verschiedenen Konzepte abzubilden?

Peter Coad hat in seinem Ansatz „UML colors“ diese Konzepttypen in vier Archetypen unterteilt:

  • PPTs (Party, Place or Thing): Objekte, die eine echte Identität besitzen
  • Description: Eine Beschreibung, die für eine Klasse von Objekten (also die Gesamtmenge der Instanzen) gilt
  • Role: Eine Rolle, mit der ein Objekt (ein PPT) an einer Interaktion teilnimmt
  • Moment-Interval: Etwas temporäres, kurzlebiges, zum Beispiel temporäre Objekte oder Interaktionsobjekte

Die vier Archetypen ordnen sich in typischer Weise an.  Da eine vollständige Beschreibung von Peter Coads Ansatz nicht Ziel dieses Eintrags ist, verweise ich an dieser Stelle auf diesen Bericht.
Meiner Meinung nach zeigt Peter Coads Konzept sehr gut, dass UML als universelle Modellierungssprache nicht auf spezielle Konstrukte Rücksicht nehmen kann. Peter Coad setzt mit der Markierung der Archetypen durch Stereotypen auf ein von UML bereitgestelltes Mittel, um die Sprache zu erweitern.

Eine andere Möglichkeit zur Unterstützung dieser Konstrukte ist eine Erweiterung des UML-Metamodells. Über einen Package-Merge können die vier Archetypen als Subklassen von „Class“ definiert werden, und dann als Instanzen in Modellen genutzt werden.

uml colors

Die Frage am Anfang war: Ist eine “Klasse” genug, um diese verschiedenen Konzepte abzubilden? Dieser Blog-Eintrag hat die Frage nicht beantwortet. Eine Anwendung kann aus „Klassen-Bausteinen“gebaut werden,  sie kann aber auch aus den vier „Archetyp-Bausteinen“ zusammengesetzt werden.

Der Einsatz von UML colors führt zu neuen Erkenntnissen, ich habe ihn in einem kleinen Projekt eingesetzt, nachdem zu dritt ein herkömmliches UML-Modell erstellt wurde. Unheimlich war, dass das Modell nach UML colors sich anders „anfühlte“, es war aber lückenlos und wurde dann später auch so als Modell der Anwendung  verwendet. Bei Gelegenheit werde ich einen Erfahrungsbericht zu „UML colors“ veröffentlichen.