Mit Color Modelling farbige Domänenmodellen erstellen

Color Modelling im Einsatz

Um es vorwegzunehmen: es ist ein bisschen Übung notwendig. Einsteiger tun sich oft schwer, selbst scheinbar einfache Domänen so zu modellieren, dass ihre Bestandteile der Struktur des domäneneutralen Modellbausteins entsprechen. Doch was dann? Hat man dann etwas falsch gemacht? Nicht unbedingt. Grundsätzlich schreibt Color Modelling keine feste Modellstruktur vor, und natürlich sollte ein Domänenmodell immer so erstellt werden, dass es so nah wie möglich an der Realität ist und nicht so nahe wie möglich an einer generischen Modellabstraktion. Color Modelling soll dabei helfen, ein richtiges (oder das beste) Modell für eine Domäne zu finden.

Ein einfacher Einstieg ist daher vermutlich, als Übung bereits bestehenden Modellen die Archetypes und Farben zuzuweisen (siehe Kasten), zum Beispiel mit farbigen Post-It-Zetteln oder Textmarkern. Das Ergebnis kann dann mit dem domäneneutralen Modellbaustein verglichen werden, um zu überprüfen, ob die Farbmuster übereinstimmen. Es ist dabei wichtig zu verstehen, dass nicht jedes Modell auch jeden Archetype enthalten muss. An vielen Stellen werden bestimmte Archetypes gar nicht gebraucht (z.B. haben Orte und Dinge oftmals keine Rollen). In solchen Fällen können sie einfach weggelassen werden. In anderen Fällen machen Archetypes vielleicht logisch Sinn, sind aber so trivial, dass Sie mit einem benachbarten Archetype zusammengeführt werden können.

Bestimmung von Archetype und Farbe

Angenommen man hat eine bestimmte Klasse – wie bestimmt man dann ihren Archetype und damit auch die zugehörige Farbe? Die empfohlene Vorgehensweise hierzu ist die Bestimmung entlang der folgenden Checkliste:

  • Repräsentiert die Klasse einen Zeitpunkt oder ein Zeitintervall, oder einen Vorgang, der vom System aus geschäftlichen oder juristischen Gründen verfolgt oder protokolliert werden muss? Falls ja, dann gehört die Klasse zum „Moment-Interval“ Archetype und ist pink.
  • Falls nein, repräsentiert die Klasse eine Rolle? Falls ja, dann ist sie gelb.
  • Falls nein, repräsentiert die Klasse eine katalogartige Beschreibung, eine Gruppierung von Datenwerten die auf eine Vielzahl von Objekten zutreffen? Falls ja, dann gehört die Klasse zum „Description“ Archetype und ist die blau.
  • Falls nein, dann repräsentiert die Klasse ein „Party, Place or Thing“ und ist grün.

Auch die für die jeweiligen Archetypes typischen Attribute und Methoden (Abb. 5) helfen bei der Bestimmung.

Abb. 5: Anwendungsbeispiel: Anmeldung beim Video Store

Bei der Erstellung vollkommen neuer Modelle kann beispielsweise mit domäneneutralen Bausteinen begonnen werden, um dann die Artefakte der zu modellierenden Domäne den entsprechenden Archetypes zuzuweisen. In praktisch jeder Domäne lassen sich vor allem die Moment-Interval-Vertreter schnell identifizieren. In einem typischen Shop-System finden sich beispielsweise oft Preisanfrage, Bestellung, Auslieferung und Rechnungsstellung. Um die Moment-Interval-Artefakte herum lassen sich dann recht leicht auch die anderen Archteypes zuweisen. Nicht benötigte Archetypes werden schließlich aus dem Modell gestrichen.

Sollten vollkommen abweichende Farbmuster auftreten, und zum Beispiel ein als blau identifiziertes Artefakt mit einem pinken Artefakt in direkter Beziehung stehen, so kann dies jedoch zumindest zum Anlass genommen werden, den jeweiligen Modellaspekt mit einer gewissen Skepsis zu hinterfragen. Da die Abstraktion des domäneneutralen Modellbausteins aus umfassender Modellierungserfahrung in unterschiedlichsten Domänen abgeleitet wurde, existiert in solchen Fällen zumindest eine gewisse Wahrscheinlichkeit, dass an dem eigenen Modell irgendetwas noch nicht ganz stimmt. Erfahrene Color Modelling Experten berichten davon, durch einen kurzen Blick aus der Entfernung und allein aufgrund der wahrgenommenen Farbmuster erkennen zu können, wenn ein Modell nicht schlüssig oder mit hoher Wahrscheinlichkeit nicht korrekt ist.

Eine häufig gestellte Frage bezieht sich auf die Implementierung. Wenn die Archetypes also eine abstrakte Vorlage für alle Klassen der jeweiligen Kategorie vorgeben, könnte man dann nicht einfach die Archetypes als Superklassen implementieren und anschließend Domänenklassen davon ableiten? Die Antwort lautet nein. Es sei noch einmal betont, dass Domäneklassen ihren Archetypes nur mehr oder weniger folgen. Dies ist offensichtlich keine hinreichende Voraussetzung für Vererbung.

Fazit

Es gibt immer mehrere Möglichkeiten, ein Problem oder einen Sachverhalt zu modellieren. Woher weiß man jedoch, welches Modell das Beste ist? Color Modelling versucht, diese Frage zu beantworten. Die Archtetypes sollen den Modellierer anhand ihrer typischen Attribute, Methoden und Beziehungen hin zu guten Modellen führen. Sie dienen als kleine Bausteine, die man immer wieder verwenden kann. Somit ergibt sich ein einfacher, aber systematischer Ansatz um Modelle für beliebige Domänen zu entwickeln.

Die vier unterschiedlichen Farben vermitteln beim Color Modelling letztlich die gleiche Information wie die zugehörigen UML Stereotypes, jedoch auf einer andere Ebene. Während die (eigentlich sehr wichtige) textuelle Information im Rauschen der vielen Detailinformationen eines Modelldiagramms untergeht, vermitteln die entstehenden Farbmuster einen unmittelbaren Überblick über die Struktur des Modells. Basierend auf der Beobachtung, dass die allermeisten Domänen offenbar den gleichen abstrakten Strukturen folgen, helfen die Farben zudem die Beziehungen von Modellartefakten untereinander herauszuarbeiten.

Ein wesentlicher Grund dafür, dass Color Modelling keinen größeren Bekanntheitsgrad erreichen konnte, mag gewesen sein, dass sich Peter Coad aus der IT Branche zurückgezogen hat. Dieser mangelnde Bekanntheitsgrad führt leider auch dazu, dass es etwas schwierig ist, Literatur und Dokumentationen über die Methodik zu finden. Das Standardwerk von Peter Coad wird nicht mehr gedruckt. Mit etwas Entdeckergeist lassen sich per Internet aber durchaus noch Exemplare auftreiben und bestellen. Wie die Leserbewertungen auf einschlägigen Webseiten zeigen, gehen auch die Meinungen über das Buch recht weit auseinander. Einige der eher negativen Bewertungen kamen offensichtlich auch durch den etwas missverständlichen Buchtitel zustande. Auf Peter Coad’s Website kann das einführende erste Kapitel als PDF-Dokument herunter geladen werden.

Einer der Co-Autoren des Buches war Jeff DeLuca, der als Vater des Feature-Driven Development (FDD) gilt. FDD ist ein agiler Prozess, der sich durch kurze Iterationen auszeichnet und aus fünf grundlegenden Aktivitäten zusammensetzt. Die erste davon ist die Erstellung eines Domänenmodells. Während FDD keine spezielle Vorgehensweise hierfür vorschreibt, favorisiert DeLuca den Color Modelling-Ansatz. FDD wurde erstmals in Kapitel 6 des Color Modelling Buches vorgestellt, später aber [Stephen R. Palmer, John M. Felsing: A Practical Guide to Feature-Driven Development, Prentice Hall, 2002 ] noch einmal detaillierter und unabhängig von Color Modelling beschrieben. Jeff DeLucas Firma Nebulon bietet Workshops an, in denen das Color Modelling erlernt werden kann.

Letztlich muss jeder Software-Architekt und jedes Team für sich selbst entscheiden, ob sie Color Modelling hilfreich finden und einsetzen wollen oder ob sie die Methodik als unbrauchbar ansehen. Tatsache ist jedoch, dass die Mehrheit derjenigen Architekten, die Color Modelling eingesetzt haben und beherrschen, voller Begeisterung darauf schwören.

Thilo Frotscher ist freiberuflicher Software Architekt und Trainer mit den Schwerpunkten Enterprise Java und Web Services. Neben der Mitarbeit in Projekten seiner internationalen Kunden führt er regelmäßig auch Schulungen und Workshops durch. Seine Erfahrungen gibt Thilo gerne auf zahlreichen internationalen Fachkonferenzen an andere Entwickler weiter. Daneben verfasst er regelmäßig Artikel für unterschiedliche Fachmagazine und ist (Co-)Autor dreier Bücher im Themengebiet Java, Web Services und SOA.
Kommentare

Schreibe einen Kommentar

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