• Recent Articles
• By Topic
• By Year
• About me

Raus aus dem Wolkenkuckucksheim

25.05.2010 Permalink

Softwarearchitekten besitzen viel Erfahrung mit dem Bau komplexer Softwaresysteme. Das ist der Grund, warum sie in einem Projekt die Verantwortung für das technische große Ganze tragen sollen. Damit haben sie primär zwei Aufgaben: erstens erarbeiten sie im Team mit Analysten und Entwicklern die Architektur, darunter die fachliche und technische Zerlegung des Gesamtsystems sowie kritische technische Lösungen. Und zweitens stellen sie sicher, dass die Ideen und Festlegungen tatsächlich im Code ankommen. Ist Letzteres nicht gewährleistet, kann man sich Ersteres im Grunde sparen.

Aber wie schafft der Architekt dies? Welche Mittel hat er dazu?

Er kann ein Softwarearchitekturdokument schreiben, z.B. ein 100-seitiges Papier, das die Aufgabenstellung (also Architekturziele, Rahmenbedingungen, architekturrelevante Anforderungen), und die Lösung (z.B. fachliche Zerlegung, technische Schichten, Produkt- und Werkzeuginfrastruktur, Lösungen zu Einzelaspekten) enthält. Das ist aufwändig, doch gerade im Hinblick auf die Aufgabe, die ja die Triebkraft hinter der Wahl bestimmter Lösungen ist, ist es wertvoll.

Nun muss nur noch jeder Entwickler das Dokument vollständig lesen, verstehen und während seiner Arbeit stets in allen Aspekten berücksichtigen. Hier hakt es in der Praxis bereits gewaltig. Denn das Dokument kann nur "flach" beschreiben, wie das System aussehen soll. Die Architektur wird nicht plastisch. Es fehlt etwas, das man "anfassen" kann oder sogar beim Ablauf beobachten könnte. Kurz: ein Dokument ist zur Anleitung, wie ein System konkret gebaut werden soll, eine Ergänzung, reicht aber nicht aus.

Das nächste, etwas mächtigere Mittel, um das System im Sinne der Architektur zu formen, ist ein lauffähiger Prototyp, der an exemplarischen Anwendungsfällen zeigt, wie das System zu bauen ist. So ein Prototyp ist auch im Rahmen von frühen Lasttests zwecks Prüfung technischer Lösungen nützlich. Und beim Bau des Prototyps entstehen nebenbei Entscheidungen für oder gegen bestimmte Werkzeuge, die wiederum wichtig sind, damit es leicht ist, im Sinne der Architektur zu programmieren. Der Quellcode des Prototypen kann prima für gemeinsame Walkthroughs von Entwicklern und Architekten genutzt werden. Es entsteht eine befruchtende Diskussion, aus der das ganze Team etwas über das System, seine Architektur und wie sie zu verwirklichen ist, lernt.

Teams lernen während eines Projekts, wie sie ihre Projektarbeit besser gestalten. Das gilt in gleichem Maße für Architekturentscheidungen, die sich als "gut" oder "verbesserungswürdig" erweisen können. Geänderte Architekturentscheidungen sollten sich möglichst bald auf bereits bestehende Systemteile auswirken, d.h. dass Entwickler von diesen Änderungen "entwicklerfreundlich" informiert werden. Der Architekt benötigt also einen Update-Mechanismus. Mails oder ein persönlicher Hinweis sind zur Erzeugung der Aufmerksamkeit geeignet, der Inhalt, also was warum geändert wurde, ist in einer zentralen Wikiseite mit Einträgen in der Reihenfolge Neu-Alt-NochÄlter schon besser aufgehoben. Entstehen größere Baustellen, so ist statt einer Mail ein Eintrag in ein Ticketingsystem ratsam, der die Anpassung an eine geänderte Entscheidung zum Inhalt hat. So ein Eintrag kann im Rahmen der Iterationsplanung dann als Aufgabenpaket berücksichtigt werden.

Wir sind mit den o.g. Mitteln schon soweit, dass Entwickler die Architektur effizient verstehen lernen und Änderungen an dieser mitbekommen. Aber wie können Architekten feststellen, ob die tatsächliche Realisierung mit der Architektur zusammenpasst?

Ein wirksames, lange bekanntes Mittel sind Code Reviews. Architekten überprüfen durch das Lesen von Quellcode, ob die Implementierung die Lösungen der Softwarearchitektur berücksichtigt. Ist das an einer Stelle nicht der Fall, so kann das ein guter Anlass für den Architekten sein, mehr über das System und die bisherige Lösungsidee zu lernen. Das verbessert die Architektur und den Architekten. Es kann natürlich auch sein, dass der Entwickler jetzt mehr über die Architektur lernen kann. Das verbessert den Entwickler. Es entsteht zudem ein wertvoller Eindruck von der allgemeinen Codequalität, wie ihn Tools bis heute nicht vermitteln können.

Code Reviews haben aber den Nachteil, dass sie in großen Teams nur noch stichprobenartig erfolgen können. Ihre Durchführung skaliert nicht besonders gut. Durch die zusätzliche Verwendung von statischer Codeanalyse lassen sich einige wenige Aspekte vollautomatisch prüfen. Dazu zählt die Begrenzung auf zulässige Abhängigkeiten für Komponenten oder die Verwendung bestimmter Muster. Die statische Codeanalyse wird die Architekten aber auch darauf hinweisen, wo viel oder komplexer Code entsteht. Das erleichtert die Auswahl, was von einem Menschen via Code Review geprüft werden sollte.

Reviews und automatische Prüfungen schlagen erst an, wenn ein Missstand besteht, und somit eine Behebung erforderlich ist. Damit wirken sie eigentlich zu spät, um Fehler gar nicht erst entstehen zu lassen. Um Fehler und Inkonsistenzen auszuschließen, setzen Architekten Model-driven software development (MDSD) ein. Gemäß dieses Ansatzes werden bestimmte Aspekte des Systems wie z.B. seine Gesamtstruktur, Formulare und deren Abfolgen, persistente Datenstrukturen und Schnittstellen zu Fremdsystemen in Modellen beschrieben. In diesen Modellen spielen technische Entscheidungen keine Rolle. Erst bei der Erzeugung von Code aus den Modellen werden die fachlichen Modellinhalte mit Technik versehen. Dieser generierte Code kann z.B. mittels Vererbung manuell ergänzt werden. Auf diese Weise sind Fehler ausgeschlossen und späte Änderungen technischer Lösungen erfordern lediglich die Anpassung des Generators sowie die Neugenerierung des Codes. Bei MDSD handelt es sich damit um ein äußerst mächtiges Mittel, um einer Architektur zur konsistenten Implementierung zu verhelfen.

Ein Softwareteam besitzt also eine ganze Reihe von Werkzeugen, um einer Architektur Leben einzuhauchen und vor allem die ungewollte Abweichungen von richtigen Lösungsideen zu vermeiden. Es ist neben der Gestaltung des Softwaresystems eine sehr wichtige Aufgabe von Softwarearchitekten, diese Werkzeuge einzuführen und ihre Verwendung zur Gewohnheit des Teams werden zu lassen. Denn nur dann bleibt die Architektur kein Wolkenkuckucksheim.