Innere Werte, Teil 5: Ausdrucksstärke
"Ich weiß nicht, was soll das bedeuten." – Das hat sich wohl jeder schon einmal beim Lesen einer Architekturspezifikation gefragt. Ausdrucksstärke ist für das Verständnis eines Entwurfs allerdings essenziell.
- Dr. Michael Stal
"Ich weiß nicht, was soll das bedeuten." – Das hat sich wohl jeder schon einmal beim Lesen einer Architekturspezifikation gefragt. Ausdrucksstärke ist für das Verständnis eines Entwurfs allerdings essenziell.
In einem Projekt zur Entwicklung eines Enterprise-Telefonie-Systems präsentierte ein Subsystem-Team den Entwurf für eine Telefonkonferenz-Funktionalität. In diesem Entwurf gab es zwei Konzepte, die verwirrten. Neben einem Conference Organizer tauchte ein Conference Manager auf. Preisfrage: Was mag sich hinter diesen Konzepten verbergen?
Es stellte sich heraus, dass der Conference Manager diejenige Komponente repräsentiert, die den Lebenszyklus einer Konferenz und deren Ressourcen verwaltet. Der Conference Organizer war hingegen der menschliche Aktor, der die Konferenz kreiert hat.
Weitere Mittel mit Verwirrungsfaktor
Irreführende Begriffe können also Verwirrung stiften. Ein anderes Beispiel für schlechte Ausdrucksstärke sind implizite Datentypen. Angenommen, jemand stellt ein Datum als drei ganze Zahlen dar. Dann taucht im Design eventuell eine Methode der Art method(..., int, int, int, ...) auf, die implizit Ganzzahlen zum Darstellen eines Datums nutzt. Ganz abgesehen davon, dass der Übersetzer implizite Typverletzungen nicht erkennt, realisiert auch der menschliche Betrachter unter Umständen nicht, was es mit den Parametern auf sich hat. Sinnvoller ist es explizit, dafür einen Datumstyp einzuführen.
Gerade beim Zusammenspiel zwischen Komponenten müssen derartige Gegebenheiten explizit sichtbar sein. Was sonst passieren kann, beweist ein gescheitertes Marsprojekt der NASA. Eine der Komponenten rechnete implizit in Meter, eine andere in Yards. Auch hier können Entwickler durch Implementierung derartige Probleme verhindern. Etwa durch explizite Annotation von Fließkommazahlen mit physikalischen Einheiten.
Apropos Schnittstellen. Zu der architektonischen Beschreibung einer Schnittstelle gehört auch der Kontrakt mit allen Vorbedingungen, Nachbedingungen, und Invarianten. Ebenso ein Protokoll, falls sich hinter der Schnittstelle eine Zustandsmaschine verbergen sollte, also zum Beispiel FileRead() erst nach vorherigem FileOpen().
Ein weiteres Minenfeld sind Bezeichner. Die sollten immer eindeutige und verständliche Namen haben. Das meiste lässt sich mithilfe von Programmierkonventionen und Architekturvorgaben verhindern. Vorausgesetzt natürlich, dass entsprechende Prüfwerkzeuge vorhanden sind. Architekturmodelle erschließen sich durch gut gewählte Namen wesentlich schneller.
Bei Nutzern der Architektur auf Verständlichkeit prüfen
Verständlichkeit lässt sich dadurch bewerten, indem Architekten verschiedenen Beteiligten die Architektur vermitteln und anschließend feststellen, ob die Architektur auch auf die Betroffenen einen verständlichen Eindruck macht oder an einigen Stellen eher zur Konfusion führt.
Als Leser einer Architekturspezifikation bemerke ich Ausdrucksstärke dann, wenn mir der Entwurf gut erklärt, was das System leistet und wie es das tut. Eine Architekturbeschreibung sollte mit Antworten glänzen, statt neue Fragen aufzuwerfen.
Das ist der Fall, wenn sich Komponenten, Abhängigkeiten und Schnittstellen mir auf den ersten Blick erschließen, wenn Datentypen immer explizit sichtbar vorliegen, wenn Architekturentscheidungen nachvollziehbar sind, wenn alle Abhängigkeiten explizit gemacht werden und wenn die richtigen Perspektiven auf den richtigen Abstraktionsstufen Architektur und Umgebung visualisieren.
Wie üblich, bleibt anzumerken, dass Ausdrucksstärke ein Indiz und kein Beweis für gute innere Qualität ist. Selbst eine ausdrucksstarke Architektur kann schließlich inadäquat sein. ()
