Grau ist (fast) alle Theorie

Mit Color Modelling farbige Domänenmodelle erstellen

Thilo Fotscher

Nicht alles, was schon ein paar Jahre älter ist, muss deswegen gleich schlecht sein. Gerade in einer Branche, in der nichts so konstant ist wie der stetige Wandel, sollte man sich dies immer mal wieder ins Gedächtnis rufen. Während sich Technologien rasant verändern und verbessern, haben grundlegende Erkenntnisse, Methodiken oder Ansätze in der Regel deutlich länger Bestand. Die Analysetechnik des „Color Modelling“ wurde bereits vor zehn Jahren erstmals vorgestellt, begeistert ihre Anhänger jedoch noch heute.

Obwohl seitdem eine geraume Zeit vergangen ist, ist Color Modelling bis heute nicht sehr weit bekannt. Und unter jenen Architekten, welche die Methodik kennen, findet man teils recht unterschiedliche Meinungen. Die einen finden, das Ganze sei altmodisch, überholt oder einfach nicht zu gebrauchen. Wieder andere schwören auf das farbunterstützte Modellieren und vermuten, die anderen hätten bloß nicht genügend Erfahrung damit gesammelt. Grund genug, diese Methodik genauer unter die Lupe zu nehmen und sich selbst ein Bild zu machen.

Der Ansatz des Color Modelling geht zurück auf Peter Coad, der die Methodik erstmals auf der OOPSLA’97 Konferenz vorstellte. Coad erreichte hohen Bekanntheitsgrad als Gründer von TogetherSoft, das 2003 an Borland verkauft wurde, und wo er fortan als Senior Vice President und Chief Strategist tätig war. Darüber hinaus wurde er bekannt als Autor von sechs Büchern im Bereich OOA und OOD, sowie als anerkannter und ausgesprochen erfahrener Modellierer. In seinem Buch „Java Modelling in Color with UML“ [Peter Coad, Eric Lefebvre, Jeff De Luca: Java Modeling in Color with UML, Prentice Hall, 1999] vergleicht Coad den Übergang von der Modellierung in schwarz-weiß zur farbunterstützten Modellierung mit dem Übergang von der Schwarzweiß- zur Farbfotographie.

„Black-and-white conveys basic information. Color reaches out and grabs you.“

Archetypes

Wichtigstes Grundkonzept des Color Modelling sind die so genannten Archetypes. Über die Jahre hinweg und basierend auf umfassender Modellierungserfahrung, die sie durch die Entwicklung hunderter Modelle für verschiedenste Domänen sammeln konnten, machten Coad und seine Kollegen eine interessante Beobachtung: die einzelnen Artefakte von Modellen ließen sich praktisch immer in die gleichen vier Kategorien gruppieren. Dabei zeichneten sich die Artefakte einer Kategorie dadurch aus, dass sie im Wesentlichen dieselben Attribute und Methoden hatten. Es lag daher nahe, Schablonen (oder Vorlagen) für diese Kategorien zu abstrahieren. Die Schablonen spezifizieren also Attribute, Beziehungen, Plug-in Points (Erweiterungspunkte auf Basis von Interfaces) und Interaktionen, die typisch sind für die Artefakte der jeweiligen Kategorie.

Bei der Suche nach einer passenden Bezeichnung für diese Schablonen befand man schließlich den englischen Ausdruck „Archetype“ als am passendsten. Dieser wird definiert als „eine Vorlage, der alle Dinge der gleichen Gattung mehr oder weniger folgen“. Der zentrale Punkt an dieser Definition ist das „mehr oder weniger“. Ein wichtiger Gedanke in Coad’s Methodik ist nämlich, dass die Archetypes zwar Schablonen vorgeben, diese aber an die jeweilige Domäne angepasst werden dürfen. Dies steht im Gegensatz zur Definition des Begriffs „Stereotype“, der laut Definition etwas eher Unveränderliches bezeichnet und daher als unpassend verworfen wurde. Nichtsdestotrotz werden in UML Diagrammen aber UML Stereotypes verwendet, um den Archetype einer Klasse anzuzeigen.

Welches sind nun aber die verschiedenen Archetypes? Coad identifizierte die folgenden vier Typen:

  1. Moment-Interval: ein Zeitpunkt oder Zeitintervall
  2. Role: eine Rolle
  3. Party-Place-Thing: eine Person(engruppe), ein Ort oder ein Ding
  4. Description: eine katalogartige Beschreibung.

Moment-Interval, die erste wichtige Kategorie, umfasst Zeitpunkte („moment in time“) oder Zeitintervalle. Sie repräsentiert Dinge, mit denen oder an denen man arbeiten muss, die aus geschäftlichen oder juristischen Gründen verfolgt werden müssen, oder Dinge, die zu einem bestimmten Zeitpunkt oder über ein bestimmtes Zeitintervall passiert.

Ein Verkauf ist beispielsweise ein Zeitpunkt, denn er geschieht an einem bestimmten Datum und zu einer bestimmten Zeit. Die Vermietung eines Fahrzeugs ist dagegen ein Zeitintervall, und zwar von Zeitpunkt der Abholung bis zum Zeitpunkt der Rückgabe. Auch Bestellungen sind Zeitintervalle, sie beginnen mit dem Bestellungseingang und enden in der Regel mit der Auslieferung der Ware oder mit dem Zahlungseingang. Ein weiteres gutes Beispiel sind Reservierungen. Gegebenenfalls kann auch ein Verkauf ein Zeitintervall sein, nämlich dann, wenn der Verkauf in der zu modellierenden Domäne eher ein längerer Prozess ist, dessen Zustand verfolgt werden muss.

Moment-Interval-Artefakte sind die zentralen Bestandteile von Domänemodellen. Sie binden die anderen Artefakte zusammen und repräsentieren den Kernaspekt des Modells bzw. die Prozesse, die mit dem Modell abgebildet werden sollen. Daher kapseln diese Artefakte in der Regel die interessantesten Methoden. Oftmals besteht ein Moment-Interval aus mehreren Teilen. So kann beispielsweise eine Bestellung aus mehreren Einzelposten bestehen. Diese werden dann Moment-Interval Details genannt.

Der zweite wichtige Archetype ist die Role und beschreibt die Art und Weise, wie eine Person(engruppe), ein Ort oder ein Ding an einem Moment-Interval partizipieren. Im Falle einer Bestellung können Personen beispielsweise die Rolle des Kunden oder des Mitarbeiters einnehmen. Falls es in der Problemdomäne möglich ist, dass Mitarbeiter eine Bestellung beim eigenen Unternehmen aufgeben (zum Beispiel um ein Produkt für den Privatbedarf zu erwerben), so können Personen sogar beide Rollen gleichzeitig einnehmen.

Die Rollenspieler haben ihren eigenen Archetype namens Party, Place or Thing, wobei Party für eine Person, eine Personengruppe oder auch eine Organisation stehen kann. Rollenspieler und Rolle werden also als getrennte Artefakte modelliert. Der Rollenspieler beinhaltet Kernattribute und Verhalten, die immer benötigt werden, unabhängig davon, welche Rolle er einnimmt. Im Falle von Personen sind dies natürlich in der Regel solche Attribute wie Name oder Geburtsdatum sowie Geschäftsmethoden wie etwa isAuthorizedFor(…). Die Rolle kapselt dagegen Attribute und Geschäftslogik, die nur bei ihrer Ausübung benötigt werden. Diese Trennung hat den offensichtlichen Vorteil, dass das Domänenmodell leichter erweiterbar ist. Auch wenn ein Rollenspieler anfänglich nur eine einzige Rolle annehmen kann, so kommt es häufig vor, dass im Laufe der Zeit zusätzliche Rollen hinzukommen. Dies geschieht insbesondere dann, wenn neue Prozesse (oder Moment-Intervals) hinzugefügt werden.

In den meisten Domänen nehmen nur Personen oder Personengruppen unterschiedliche Rollen ein. Es kann jedoch auch vorkommen, dass ein Ort oder ein Ding unterschiedliche Rollen einnimmt. So kann ein etwa Gebäude sowohl ein Lagerhaus als auch ein Verkaufsgeschäft sein.

Der vierte und letzte Archetype heißt Description und repräsentiert eine katalogartige Beschreibung oder eine Menge von Werten, die auf eine Vielzahl von Party, Place or Thing Artefakten zutrifft. Ein anschauliches Beispiel hierfür ist das Domänemodell für einen Fahrzeugverleih. Jedes einzelne Fahrzeug hat seine eigenes Kennzeichen, eine Farbe, ein Kaufdatum und einen Kilometerstand. Ein Fahrzeug ist also eindeutig ein Ding. Jedes dieser Fahrzeuge hat jedoch auch ein bestimmtes Fahrzeugmodell. Die Details zum Modell, wie Hersteller, Modellbezeichnung, PS, Ausstattung treffen auf eine Vielzahl von Fahrzeugen des Fuhrparks zu. Sie repräsentieren damit eine katalogartige Beschreibung von Fahrzeugen und werden als separater Archetype modelliert.

Geschrieben von
Thilo Fotscher
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.