Von Sebastian Lasek
„An architecture is the set of significant decisions about the organisation of software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behaviour as specified in the collaborations among those elements, the composition of this structural and behavioural elements into progressively larger subsystems, and the architectural style that guides this organisation – these elements and their interfaces, their collaborations, and their composition." [1]
Die Definition ist recht umfangreich, beschreibt aber dafür alle Gesichtspunkte der Softwarearchitektur. Weitgehend vereinfacht, Softwarearchitektur betrachtet statische und dynamische Aspekte des Systems und deren Zusammenwirken.
Die Dokumentation einer Systemarchitektur muss wenigstens diese beiden Themenblöcke darstellen. Die Architekturbeschreibung entsteht bei der Betrachtung von denselben Artefakten aus verschiedenen Perspektiven (Views). Zum einen gilt es, die eingesetzten Technologien und Frameworks zu dokumentieren, anderseits muss auch die Struktur und Verhalten fachlicher Komponenten beschrieben werden. Die Systeme im Enterprise Umfeld sind heutzutage so komplex, dass die Vereinfachung durch die Erschaffung der Abstraktion schlicht notwendig ist. Dabei ist eine textuelle Beschreibung oder Dokumentation im Code nicht ausreichend. Es sei denn, Sie sind der Architekt, Projektleiter und Entwickler in einem, Es entsteht schon die Versuchung dabei gar keine Kommentare im Quellcode zu machen.
Eine der Aufgaben eines Architekten ist standarisierte Methoden zu benutzen um das System abstrakt zu beschreiben. Da helfen zwei Werkzeuge: standarisierte Templates zum Beschreibung der Architekturen und UML als Notationsmittel. Diese Tools bilden die Grundlage für Kommunikation mit Entwicklern, Testern, Projektleiter und Kunden (ja, auch ein gutes Architekturdokument sollte sich gut „power-pointen" lassen – z.B. „Big Picture"). Das erhöht auch Ihre Projektleistung, schafft Vollständigkeit und Korrektheit, zeigt viele Probleme, die Architektur-bedingt sind. Sie sparen sich auch lange Diskussionen der Art „wie soll ich das Problem beschreiben", weil Sie mit einem Standard arbeiten. Sie denken sich jetzt „das ist doch klar". Ich freue mich, dass ich mit einem erfahrenen IT-ler „virtuell spreche". Mein Ziel war nicht, die Weisheiten der einschlägigen Werke zu wiederholen (die gibt es wirklich genug), sondern die Leser zu sensibilisieren. Da die „Sensibilisierungsleistung" der 500-Seite-Werke scheint immer noch nicht ihre Wirkung erreicht zu haben (wenn man sich einige Projekte unter die Lupe nimmt), lohnt sich vielleicht weiter zu lesen.
Wenn Sie Architektur eines Systems dokumentieren, sollen Sie folgende Sichten beschreiben:
- Komponentensicht: ein Schnappschuss der statischen Struktur der Software-Bausteine
- beschreibt das Verhalten und das Zusammenspiel der Software-Bausteine untereinander
- Verteilungssicht: beschreibt das Deployment auf vorhandene physikalische Infrastrukturelemente
- Kontextsicht: dient zum Abgrenzung unseres Systems zum Nachbarsystemen
Alle diese Sichten sollen innerhalb der Architekturbeschreibung zu finden sein. Es wird somit sichergestellt, dass die wichtigsten dynamischen und statischen Aspekte des Systems betrachtet wurden.
Es gibt auch genug Hilfsmittel wie Checklisten und Templates, die solche Aufgaben etwas leichter machen. Erfinden Sie das Rad neu, sonder greifen Sie in Ihre Schatzkiste, oder greifen Sie in der Kiste der anderen (sehe Links am Ende des Artikels). Dokumentieren Sie auch nicht, weil es einfach nur Spaß macht UML Diagrame zu malen. Die Architekturdokumentation dient dem Zweck, alle wesentlichen Entscheidungen, die Sie als Architekt oder Sie mit dem Team getroffen haben, zu belegen.
Die Softwaresysteme entstehen meistens in einem höchst iterativen Entwicklungsprozess, diese Regel betrifft auch Architekturdokumentation. Machen Sie häufig Updates der Architekturdokumentation (neue Einflussfaktoren, Probleme, CRs). Das klingt erst nicht so spannend, hilft aber ungemein Qualität des Systems über den gesamten Lebenszyklus zu gewährleisten. Wenn Sie sich an dieser Regel halten, können Sie Ihre Entscheidungen immer hinterfragen. Das sollten Sie auch häufig tun! Dadurch können viele Fehler in Projekten vermieden werden. Der Architekt muss die Sichten so detailliert beschreiben, dass die Teammitglieder Ihre Aufgaben verstehen und die Verteilung der Aufgaben an die Entwickler erfolgen kann [2]. Softwarearchitektur entsteht, oder sollte zumindest, vor der eigentlichen Implementierung entstehen. Wenn Sie schon in der Architekturfindungsphase Fehler entdecken, können Sie ziemlich früh Gegenmaßnahmen einleiten. Das spart Zeit und Kosten.
Es gibt keine goldene Regel mit welcher Sicht die Lösungsfindung beginnen soll. Bei dem „green-field" Einsatz wird häufig nach dem fachlichen Datenmodel mit Komponentenfindung begonnen (Struktur - Komponentensicht), dabei wird die Grenze zu den Nachbarsystemen definiert (Schnittstellen – Kontextsicht). Die funktionalen Anforderungen werden auf Komponenten abgebildet. In der Komponentensicht werden die Bestandteile des Systems mittels UML (Komponentendiagram) weiter „zerlegt". Jede Komponente kann ein Komponentendiagram beinhalten, so kann man tiefer in Details „reinzoomen".
UML ist natürlich nicht alles was hier notwendig ist. Komponenten werden als White-Box und Black-Box beschrieben [3]. Die White-Box Beschreibung erläutert Innenleben der Komponente, wiederum die Black-Box Beschreibung, betrachtet die Merkmale des Bausteines aus der Sicht des Systems (Schnittstellen der Komponente, Zweck und in der Komponente erfüllte Anforderungen, …). Achten Sie bitte dabei darauf, dass die Schnittstellen „wasserdicht" spezifiziert sind. Wenn es nicht der Fall ist, kann sich das später im Projekt negativ auf Time&Budget auswirken. Behelfen Sie sich hier immer mit einem Schnittstellen Kontrakt!
Im weiteren Schritt werden die Anwendungsfälle betrachtet, also die Laufzeitsicht wird erstellt. Die Prozesse, die im System ablaufen, werden hier mittels Sequenz- und Aktivitäts- Diagrammen dargestellt. Die bereits modellierten Komponenten finden wir hier wider, nämlich in der Laufzeitperspektive.
Weiterhin bleiben noch Themen wie Architekturpräsentation (fängt schon bei dem Big Picture an), Umgang mit Anforderungen, Tests, Usability, Traceability, Konfigurationsmanagement, auf der Strecke. Dazu kommen noch Frameworks wie TOGAF, Zachmann, interne Firmenprozesse, die eher auf Großprojekte getrimmt sind und Enterprise Architektur im Focus haben. Leider ist das Thema sehr komplex und kann in einem online Artikel nicht ausführlich beschrieben werden.
Eine Architektur verständlich, korrekt und vollständig darzustellen ist eine komplexe und wirklich schwere Aufgabe. Häufig werden die Entscheidungen, die getroffen wurden, politisch getrieben, Kommunikation im Projekt lässt zum Wünschen übrig, Projektplan sieht keine ausführliche Designphase vor, usw. Jeder Architekt, der etwas länger dabei ist, konnte ein Lied davon singen. Da helfen leider nur Soft-Skills, Praxiserfahrung und diplomatisches Geschick.
Wenn Sie es wirklich bis zu diesem Satz gelesen haben, denken Sie sich sicherlich: „das machen wir doch schon längst so". Wenn das so ist, machen Sie bitte ein Test: versuchen Sie sich in Position eines neuen Mitarbeiters im Projekt zu versetzen oder finden Sie einen Testkandidaten. Wenn diejenige oder derjenige auf Anhieb alles verstanden hat, ist Ihre Architekturbeschreibung perfekt. Wenn nicht haben Sie einer der Pflichten des Architekten erfüllt, nämlich Sie haben ein Review durchgeführt. Noch eine Frage von mir: wie würde das laufen, wenn der Kollege ein Mitglied des Off/Nearshore Team wäre? Ja, stimmt schon, ein Thema für weiteren Artikel.
Quellen:
[1]: Booch, Rumbaugh, Jacobson, „The UML Modelling Language User Guide", Addison-Wesley, 1999
[2]: SE-Book ver. 3.3.1 (interner Softwareentwicklungsprozess bei T-Systems)
[3]: P. Hruschka, G. Starke: „Praktische Architekturdokumentation", OBJEKTspektrum 01/06
G. Starke: "Effektive Softwarearchitekturen. Ein praktischer Leitfaden", 2. Auflage. Hanser Fachbuchverlag, 2004
J. Siedersleben: "Moderne Softwarearchitektur", dpunkt Verlag, 2004
» www.arc42.de
» www.arc42.de/template/template.html
