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.

Schreibe einen Kommentar

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