Als Entwickler und Architekt modelliert man ja hin und wieder. Irgendeinen komplexeren Sachverhalt, den man sich selbst klar machen will, oder anderen erklären möchte. Wenn man sich den Sachverhalt (Fachliches Problem, technisches Design) selber durch ein Modell veranschaulichen möchte, dann gibt es eigentlich wenig zu sagen, wie man das machen sollte. Man will es ja nur selbst anschauen. Wenn man jedoch anderen Kollegen etwas darstellen möchte, dann wird es schon etwas anspruchsvoller. Dann stellt man sich auch mal die Frage: ist das jetzt ein gutes Modell?
Für mich ist Modellierung oft wichtig, um (während man implementiert) das zu lösende Problem erstmal analytisch zu durchdringen: was ist "es" womit ich mich beschäftige und wie sieht es aus? Was sind die einzelnen Begriffe, mit denen ich in meiner Domäne zu tun habe und wie stehen sie in Beziehung? Das stelle ich dann i.d.R. als Klassendiagramm dar (vgl. Abbildung 1). Darin zeichne ich die im Problembereich
entdeckten Klassen wie Person, Kunde, Rechnung aber auch
Erfindungen aus dem Design: Controller, Command, Adapter, Factory. Ein Kunde ist eine Person, er bekommt mehrere Rechnungen usw. usw. Wenn ich die Struktur meiner Problemdomäne ersfasst habe, frage ich mich: wie verhält es sich, z.B. bei Aufrufen durch den Client? Dann mache ich noch ein Sequenzdiagramm (vgl. Abbildung 2). Nun ergeben sich neue Erkenntnisse und ich ändere das Klassendiagramm wieder. Nach einiger Zeit stabilisiert sich der Entwurf. Dann habe ich das Problem verstanden. Dieses Vorgehen bietet sich an, (1) wenn man etwas komplexes implementieren will, und auch, (2) wenn man den komplexen Code von anderen Entwicklern verstehen möchte.
 |
| Abbildung 1: Beispiel für ein Klassendiagram |
 |
| Abbildung 2: Beispiel für ein Sequenz-Diagramm |
Kommen wir zurück zu dem Thema Kommunikation. In meinem ersten UML Buch stand der Satz: "Modelling is all about communication". Anhand eines Modells möchte man selber genauer verstehen worum es geht bzw. eine Lösung entwerfen (Analyse und Design eines Problems). Es geht bei Modellierung aber vor allem auch um die Weitergabe von Wissen, denn: man ist nicht der einzige Entwickler im Team und jetzt muss ich anderen meine Idee erklären, oder ihnen erklären worum es eigentlich geht in diesem Projekt. Und: ein Bild sagt mehr als 1000 Worte! Jetzt spätestens muss man höhere Anforderungen an die Qualität seines Modells haben. Es wird komplizierter, andere Menschen "sind mit im Spiel". Modelle werden dann häufig größer, dann hat man plötzlich ein High-Level-Modell und weitere Modelle, die die Details erklären. Schnell stößt man auf die Frage: Wann ist ein Modell wirklich gut? Mir ist zur Beantwortung der Frage vor allem folgende Passage von Booch im Gedächtnis geblieben:
"In order to be useful as a visual communication device, any diagram must be aesthetically pleasing as well as correct. As such, analysts should judge their schemas by the following rules:
If it looks messy, it’s probably wrong.
If it’s too complex, it’s probably wrong.
If it’s too big, it’s probably wrong.
If people don’t like it, it’s probably wrong.
If it doesn’t work, it is wrong."
Das ist aus dem Buch „Object Oriented Analysis and Design“ (Addison-Wesley Professional, 1994). Ich finde das hilft wirklich weiter. Und vor allem betont es, dass Modelle nicht nur einem selbst gefallen sollen, sondern vor allem einem Zweck dienen:
nämlich Wissen an andere zu übertragen.
