© Excellent backgrounds/Shutterstock.com
Softwarearchitekturen besser dokumentieren

Keilschrift reloaded


Stellen Sie sich vor, Sie sollen Interessierten die Architektur Ihrer Software erklären – und es gibt keinerlei Dokumentation. Oder es stehen größere Änderungen an einem Altsystem an – und Sie können nirgendwo erkennen, welche Risiken dabei drohen oder ob man das System doch besser neu entwickelt. Ach, in diesem Dilemma stecken Sie wirklich? Dann sind Sie hier richtig.

„Der Quelltext ist die Dokumentation“. So lautet oft die Antwort von Projektteams auf die Frage, ob und wenn ja wie sie ihre Softwarearchitektur festhalten. Wir finden aussagekräftigen Code mit treffenden Bezeichnern, angemessener Dokumentation der öffentlichen Schnittstellen mit javadoc etc. wirklich gut. Aber dort finden Sie leider nur einen Teil der Architektur wieder. Der Quelltext erzählt, um es mit Simon Brown [1] zu sagen, nicht die ganze Geschichte.

Die ganze Geschichte

Bei der Softwarearchitektur eines Systems handelt es sich um fundamentale Strukturen, Konzepte, Entscheidungen und Lösungsansätze, die wesentlich sind, damit Systeme Ihren Anforderungen genügen. Manchmal entsteht eine Softwarearchitektur nebenher und implizit während der Entwicklung. Die Erfüllung der Anforderungen (insbesondere der Qualitätsanforderungen wie Sicherheit, Performance, Wartbarkeit oder Robustheit) bleibt dann aus unserer Sicht dem Zufall überlassen. Wer darauf nicht wetten mag, weil das Risiko des Scheiterns zu hoch wäre, steckt Aufwand in die Softwarearchitektur. Er trifft Entscheidungen explizit, entwirft Schnittstellen, Strukturen und querschnittliche Konzepte systematisch. Die Ergebnisse methodischer Architekturarbeit schlagen sich zwar auch im Quelltext nieder, doch nicht alles findet sich dort, mitunter ist es zumindest gut versteckt. Lassen Sie uns einige Informationen betrachten, die wir aus Quelltext nicht rekonstruieren können:

  • Begründungen für Entscheidungen: Warum haben wir diese Schnittstellen so gestaltet, warum haben wir die Anforderungen mit drei statt vier Komponenten erfüllt, warum haben wir diese statt jener Open ­Source Library eingesetzt?

  • Verworfene Alternativen: Wir haben zuerst die naheliegende Lösung mit Framework X versucht, sind aber an Performance, Stabilität oder sonstigen Problemen gescheitert. Nun verwenden wir Y. Aber unsere gescheiterten Experimente stehen ja nicht mehr im Quellcode.

  • Kriterien: Nach welchen Kriterien haben wir Entscheidungen oder Konzepte entworfen?

Darüber hinaus gibt es noch Architekturansätze, die sich zwar im Quelltext niederschlagen, aber schwer zu durchschauen sind:

  • Übergreifende Ideen und Konzepte: Gleiche Probleme werden immer wieder gleich gelöst (konzeptionelle Integrität) – dieser Umstand ist aber im Quelltext kaum nachzuvollziehen und geht daher mit der Zeit leicht verloren.

  • Strukturierung und (Kern-)Abstraktionen: Gerade bei einer großen Codebasis ist der Einstieg ohne „Landkarte“ schwer – auch wenn sich vieles mit Tools zur statischen Analyse ermitteln lässt, welchem neuen Entwickler wollen Sie das ernsthaft zumuten?

Vogelperspektive gibt Überblick

Wir, die Autoren, mögen darüber hinaus Übersicht, etwa in Form einer Vogelperspektive auf das System. Die zeigt uns externe Schnittstellen, Nachbarsysteme und Typen von Benutzern – auf einer sehr hohen Abstraktionsebene. Meist nennen wir dies die Kontextabgrenzung (oder Kontextsicht). Quelltext ist für diesen Top-Level-Überblick ein schlechtes Medium, weil wir darin fast nie alle Außenschnittstellen auf einen Blick erfassen können. Im Beispiel von Abbildung 1 finden Sie die Vogelperspektive auf ein kleines Open-Source-Projekt [2]. Auf einen Blick erkennen Sie darin, dass es zwei unterschiedliche Benutzergruppen gibt (den „user“ sowie das Build-System), und drei externe Schnittstellen.

starke_1.tif_fmt1.jpgAbb. 1: Vogelperspektive

Ein wichtiger Grund für die explizite Kontextabgrenzung liegt im inhärenten Risiko beim Zusammenwirken mit externen Systemen begründet: An Außenschnittstellen gibt es oft mehr technische oder organisatorische Reibungspunkte oder Probleme als im In...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang