© 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...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang