Hat Mozart modelliert?

In der Musik werden Melodien als Noten in einem speziellen Liniensystem visualisiert. Es erlaubt die Angabe von Tonhöhen, -längen und vielem mehr und ist eine seit Jahrhunderten etablierte, grafische, domänenspezifischen Sprache. Komplexe musikalische Werke wie eine Sinfonie werden allerdings nicht einfach mit einer Folge von Noten beschrieben.

Die in der Softwareentwicklung bewährten Mittel, um mit Komplexität umzugehen, finden auch hier Verwendung: Abstraktion, Zerlegung, Hierarchie. Beispiele hierfür sind kompakte Beschreibungen, die sich zur schnellen Einordnung des Werkes eignen (Abstraktion, z.B. „1. Klavierkonzert op. 23 in b-Moll“), Zerlegung einer Partitur durch unterschiedliche Einzelstimmen je Musikinstrument, oder auch durch Akte, Sätzen, Takte (Hierarchiebildung). Bei Bühnenwerken kommen ggf. noch Bühnenbild und Handlung dazu. Viele Sichten auf das große Ganze werden erstellt, jede verfolgt einen besonderen Zweck und hat eine bestimmte Zielgruppe.

Mit Entwürfen von Softwaresystemen verhält es sich genau so. Auch hier werden Ideen und Konzepte gerne visualisiert, um sie zielgruppengerecht kommunizieren zu können. Allerdings reicht ein einzelnes Bild in der Regel nicht aus, um allen Adressaten gerecht zu werden, bzw. alle relevanten Aspekte zu beschreiben. Auch in Architekturbeschreibungen haben sich mehrere Sichten bewährt.

Mit der Darstellung des Systemkontextes im letzten Heft haben Sie bereits eine spezielle Sicht auf Software kennen gelernt. Ich werde in späteren Folgen weitere beleuchten. Die Literatur schlägt unterschiedliche Sichtensätze vor, am prominentesten sind vielleicht die 4 + 1 Sichten, wie sie auch im Rational Unified Process [1] Verwendung finden. Alternativ beschreibt Gernot Starke Kontext-, Baustein-, Laufzeit- und Verteilungssicht [2]. Es ist müßig, den universellen, minimalen Satz von Sichten zur optimalen Überdeckung aller Architekturaspekte finden zu wollen. Je nach Situation sind bestimmte Sichten notwendig oder auch nicht. In der Musikwelt kommt für ein Ballet die Choreographie hinzu, für einem Auftritt von Pink Floyd wird ein Beleuchtungskonzept erarbeitet.

In jedem Fall wird aber mehr als ein einzelnes großes Bild zum Entwurf eines Softwaresystems von Nöten sein. Damit stellt sich aber die Frage, wie Sie Sorge tragen können, dass unterschiedlichen Sichten untereinander konsistent entworfen werden, und es im Verlauf einer iterativen Entwicklung auch bleiben. Sichten haben unterschiedliche Zielgruppen (Auftraggeber, Entwickler, Betrieb, QS, …), und widersprüchliche Sichten führen im Verlauf eines IT-Projektes schnell zu Missklängen, Mehraufwenden, im Extremfall zum Scheitern des Vorhabens.

Mir ist ein völliges Rätsel, wie Mozart es ohne Toolunterstützung (mal abgesehen von Tinte und Feder) hinbekommen hat, die Noten der unterschiedlichen Instrumente für ein sinfonisches Werk konsistent zu halten. IT-Architekten sind in der Regel weitaus weniger genial; und daher an geeigneten Werkzeugen und Techniken zur Erstellung ihrer Arbeitsergebnisse interessiert.

Ein viel versprechender Ansatz, um die Konsistenz zwischen den unterschiedlichen Sichten einer Architektur sicherzustellen, ist es ein einheitlichen Modell darunter zu legen. Immerhin setzen erfolgreiche Ingenieursdisziplinen seit langem auf Modelle, der Automotive-Bereich etwa im Computer Aided Design. Was hat die Softwareentwicklung zu bieten?

Ein nahe liegender Kandidat ist die UML. Als grafische Notation bietet sie für unterschiedliche Sichten passende Diagramme an. Aber man kann mehr als nur ein paar Bildchen malen. Der zentrale Punkt ist, dass die unterschiedlichen Diagramme tatsächlich Sichten auf ein einheitliches Modell sind. Man muss Sichten nicht zwingend mit UML beschreiben. Bezüglich der Erhaltung der Konsistenz schneiden Powerpoint und Co. aber vergleichsweise schlecht ab, weil der Modellgedanke fehlt. Echte Alternativen sollten ihn berücksichtigen.

Aber man kann es auch übertreiben. UML-Modelle mit dem Detaillierungsgrad der Implementierung sind kaum konsistent zum Quelltext zu halten. Projekte verzichten zu Recht darauf, dieses Ziel zu erreichen. Architektursichten sind jedoch abstrakter; hier besteht berechtigter Grund zur Hoffnung, zumindest auf dieser Ebene widerspruchsfreie, zielgruppengerechte Sichten auf das Ganze zu schaffen.

Also Vorsicht. Ein Taktstock allein macht noch keinen Dirigenten. Und ebenso ein UML-Tool noch keinen erfolgreichen IT-Architekten. Entwickler spielen ohnehin, um im Bild zu bleiben, nicht gern vom Blatt ab. Sie bevorzugen es, im vorgegebenen Rahmen kreativ zu sein, treffen selbst Entscheidungen, und zu einem gewissen Grad improvisieren sie auch. Agile Projekte erinnern daher eher an Jazz mit seiner stilistischen Individualität einzelner Musiker. Trotz Freiräumen gibt es auch in diesem Musikstil klare Strukturen. Zum Beispiel einen gemeinsamen Takt.

Links & Literatur

[1] P. Kruchten, “The Rational Unified Process: An Introduction”, Addison-Wesley, 3. Aufl. 2004
[2] Gernot Starke, “Effektive Software-Architekturen”, Hanser Fachbuch, 5. Auflage 2011

Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
“Hat Mozart modelliert?”, Java Magazin, 12/2008, 1 Seite, S. 44
(mit freundlicher Genehmigung)