Architektursichten (Teil IV)

stockvault-eyeglasses111323 homero chapa
Die Dokumentation von Softwarearchitekturen macht einen großen Teil der Tätigkeiten eines Softwarearchitekten aus. Art und Umfang der Dokumentation sind dabei ebenso wichtig, wie die Wahl der richtigen Werkzeuge. Obwohl längst nicht völlig unumstritten, ist und bleibt die Unified Modeling Language (UML) eines der wichtigsten Standardmittel des Architekten. In diesem Artikel betrachten wir, wie UML zur angemessenen Dokumentation von Softwarearchitekturen verwendet werden kann.
Dokumentation

Die Dokumentation von Softwarearchitekturen dient vornehmlich der Kommunikation zwischen den unterschiedlichen Stakeholdern und dem Architekten. Er muss also darauf achten, dass er gegenüber allen Beteilig­ten eine geeignete Form und eine verständliche Darstellung findet, da die Interessen von sehr unterschiedlichen Aspekten und Sichtweisen geprägt sind.

So sind beispielsweise betriebliche Belange, wie Installations­prozeduren oder Wartungsvorgänge eines Systems für das Management von geringer Bedeutung, während dies für die Administratoren zum Tagesgeschäft gehört.

Sichten

Die Vielschichtigkeit und Komplexität eines Software­systems ist in der Regel nicht durch eine einzelne Darstellung zu dokumentieren. Aus diesem Grund bedient man sich spezieller Formen, die sich auf bestimmte Aspekte des Gesamtsystems konzentrieren und so die Komplexität der Darstellung reduzieren. Die Idee dieser Sichten ist noch relativ neu. Sie geht unter anderem auf Philipp Kruchten zurück, der sie 1995 bei der Entwicklung des Rational Unified Process (RUP) vorstellte. Er prägte den Begriff des „4+1-Sichtenmodells der Softwarearchitektur“ (siehe Abbildung 1).

afl abb1
Abb. 1: „4+1-Sichtenmodell der Softwarearchitektur“ (Quelle: Wikipedia).

Die vier Sichten repräsentieren dabei die Blickwinkel unter­schiedlicher Stakeholder, wie Endanwender, Entwickler, Administratoren oder Manager. Sie beziehen sich auf die Szenarien (Use Cases), die die eigentliche Funktionalität des Systems beschreiben. Bis heute haben sich die vier Sichten etabliert. Im deutschsprachigen Raum haben sich dafür die Begriffe Systemkontext oder Kontextabgrenzung (Logical view), Bausteinsicht (Development view), Laufzeitsicht (Process view) und Verteilungssicht (Physical view) etabliert.

Unified Modeling Language (UML)

Wie in vielen anderen Ingenieursdisziplinen gibt es auch in der Informatik Standards zur Kommunikation von speziellen Sachverhalten. Seit 1997 ist die Unified Modeling Language (UML) von der Object Management Group (OMG) standardisiert und weltweit als Mittel zur Dokumentation von Analyse- und Architekturmodellen anerkannt. Obwohl sie wegen ihrer Komplexität nicht unumstritten ist, steht sie als Standard zurzeit konkurrenzlos dar.

Es ist also naheliegend, die UML auch als Dokumentationsmittel für die oben genannten Sichten zu verwenden. Für jede Sicht stellt die UML eine oder mehrere geeignete Diagrammarten zur Verfügung. Dabei ist natürlich zu berücksichtigen, dass für die einzelnen Sichten je nach Umfang, Teilaspekte der Architektur über mehrere Diagramme verteilt dargestellt werden können.

Systemkontext (Logical view)

Der Systemkontext hat eine etwas übergeordnete Stellung. Er zeigt, wie das System in seiner Umgebung eingebettet ist. Als Blackbox wird es aus der Vogelperspektive betrachtet und ermöglicht so die Abgrenzung zu umgebenden Systemen zu finden. Dadurch können Schnittstellen und Infrastrukturkomponenten erkannt und Nutzer des Systems identifiziert werden.

Da der Systemkontext häufig zur Kommunikation mit den nicht technischen Stakeholdern verwendet wird, stellt er das System auf einer relativ hohen Abstraktionsstufe dar (siehe Abbildung 1 aus dem Teil III dieser Reihe [3]).

Zu diesem Zweck hat sich das Komponentendiagramm aus der UML bewährt. Denkbar sind aber auch durchaus andere Darstellungen wie zum Beispiel das Kommunikationsdiagramm oder das Klassendiagramm.

Bausteinsicht (Development view)

Im Gegensatz zum Systemkontext ist die Bausteinsicht eine wesentlich speziellere Darstellung des Systems. Sie dient vornehmlich den Entwicklern und beschreibt, aus welchen Architekturbausteinen, also Subsystemen, Komponenten und Schnittstellen das System besteht. Die Bausteinsicht befasst sich dabei nur mit dem statischen Aufbau des Systems, sie berücksichtigt keinerlei Informationen bezüglich der internen Verarbeitungsprozesse.

In der Regel verwendet man zur Darstellung einen Top-Down-Ansatz ausgehend von der Blackbox des Gesamtsystems aus dem Systemkontext. Diese wird über mehrere Verfeinerungsstufen in kleinere Bausteine zerlegt, bis alle architekturrelevanten Details herausgearbeitet sind (siehe Abbildung 3 aus dem Teil III dieser Reihe [3]).

Bausteine bilden einzelne Funktionalitäten ab. Die Bausteinsicht macht Strukturen und Abhängigkeiten zwischen den einzelnen Bausteinen durch die Schnittstellen sichtbar. Zur Darstellung verwendet die Bausteinsicht Klassensymbole, Komponenten und Pakete aus der UML. Dabei handelt es sich um Abstraktionen, die im detaillierten Architekturentwurf weiter verfeinert werden können.

So bietet sich folgerichtig für die Darstellung der Bausteinsicht die Verwendung derjenigen UML-Diagramme an, die sich vornehmlich mit der Abbildung der Strukturierung des Gesamtsystems befassen. Dies sind neben dem Komponentendiagramm auch das Klassen- und Paketdiagramm.

Laufzeitsicht (Process view)

Die Laufzeitsicht dokumentiert das System so, wie es sich zur Laufzeit darstellt. Sie beantwortet Fragen zur Existenz und zum Verhalten von Instanzen bestimmter Bausteine zur Laufzeit, deren Zusammenspiel und Konfiguration.

Anders als bei der Bausteinsicht werden hier also vorwiegend die dynamischen Aspekte eines Systems beschrieben. Es interessieren dementsprechend diejenigen Bausteine, von denen zur Laufzeit auch tatsächlich Exemplare erzeugt werden. Sie werden als Einheit ausgeführt und aufgerufen, ihr Verhalten implementiert spezielle Funktionalitäten.

Das Zusammenspiel dieser Bausteine manifestiert sich in deren Beziehungen untereinander. Dabei kann es sich sowohl um Kontroll- als auch um Datenflüsse handeln.

Zur Notation der Laufzeitsicht bietet die UML mit dem Aktivitäts- und dem Sequenzdiagramm zwei sehr gut geeignete Darstellungsformen an. Zur Erstellung der Laufzeitsicht muss die Dynamik der statischen Bausteine aus der Bausteinsicht beschrieben werden. Die Use Cases sind dabei eine sehr nützliche Hilfe, denn sie beschreiben im Wesentlichen das Verhalten des Gesamtsystems.

Das (stark vereinfachte) Sequenzdiagramm aus Abbildung 2 verdeutlicht sehr gut die Abhängigkeiten der einzelnen Komponenten durch die Darstellung der gegenseitigen Aufrufe.

afl abb2
Abb. 2: Sequenzdiagramm eines Teilaspekts der Laufzeitsicht.

Die Erstellung solcher Sequenzdiagramme kann durch die Betrachtung der dazugehörigen Use Cases und Aktivitäten erleichtert werden, wie dies die Diagramme in den Abbildungen 3 und 4 verdeutlichen.

afl abb3
Abb. 3: Aktivitätendiagramm.

afl abb4
Abb. 4: Use Case.

Verteilungssicht (Physical view)

Mit der vierten noch fehlenden Sicht, der Verteilungssicht, wird die Ablaufumgebung des Systems beschrieben. Hierbei handelt es sich um eine Art Landkarte, in der alle Hardwarekomponenten und die dazugehörigen Protokolle eingezeichnet werden.

Oft auch als Infrastruktursicht bezeichnet, stellt die Verteilungssicht also physikalische Geräte wie Server,Prozessoren, Netzwerke, Router, Firewalls, Speicher oder Datenbanken dar. Diese werden oft um Leistungsdaten, Kapazitäten, Mengengerüste, Geschwindigkeiten oder Angaben zu Betriebssystemen und Laufzeitumgebungen ergänzt.

Die UML stellt für die Darstellung der Verteilungssicht das Deployment-Diagramm zur Verfügung (siehe Abbildung 5). Der Knoten wird für beliebige technische Elemente verwendet. Für die Laufzeitelemente können auch Komponenten- oder Paketsymbole verwendet werden.

Weitere Sichten?

Die vorgestellten Sichten sind ein wichtiger Bestandteil der Softwarearchitekturdokumentation. Dennoch stellen sie nur einen Teil der Gesamtdokumentation dar. In einem späteren Artikel werden wir eine weitere Methode vorstellen, mit der Architekturen systematisch in einem sinnvollen Umfang dokumentiert werden können. Zudem zeigen wir auf, welche weiteren Aspekte es noch zu berücksichtigen gilt.

Grundsätzlich sollte jedoch auch die Dokumentation von Softwarearchitekturen einem pragmatischen Ansatz folgen. Das bedeutet, dass wenn bestimmte Informa­tionen zum Verständnis der Architektur benötigt werden oder überflüssig sind, diese entsprechend hinzugefügt oder weggelassen werden können.

Werden möglicherweise Informationen zu Daten­haltung oder Datenstrukturen benötigt, so sollte unbedingt auch eine entsprechende Sicht, beispielsweise in Form von Entity-Relationship-Diagrammen, zur Doku­mentation hinzugefügt werden.

Andere Formen

UML stellt ein mächtiges und sinnvolles Instrumentarium zur Dokumentation von Softwarearchitekturen bereit. Im Sinne eines pragmatischen Ansatzes sollte der Architekt aber auch andere Formen in Betracht ziehen. So reichen in manchen Fällen auch einfache Zeichnungen, Tabellen, Checklisten, Aufzählungen oder andere textuelle Darstellungen aus, deren Verwendung durchaus legitim ist.

Fazit

Das erläuterte Sichtenmodell stellt einen geeigneten Ansatz dar, um die zentralen Aspekte einer Softwarearchitektur zu dokumentieren. UML hält, alle wichtigen Mittel dafür bereit. Allerdings fällt auch auf, dass dafür nur ein Bruchteil des mächtigen Instrumentariums tatsächlich benötigt wird.

Ein Softwarearchitekt muss also kein spezialisierter UML-Experte sein. Er ist im Gegenteil gut beraten, die Dokumenta­tion immer den Anforderungen seiner Zielgruppe anzupassen und allzu technische oder spezialisierte Darstellungsformen zu vermeiden. Eine einfache Zeichnung, Tabelle oder simpler Text ist zur Dokumenta­tion manchmal mindestens genauso gut geeignet, wie ein detailliertes UML-Diagramm.

afl

Andreas Flügge

Projektmanager
Java-Entwickler
Softwarearchitekt
und Autor von Fachartikeln
in den ORDIX news und Java Aktuell

Diesen Artikel als PDF

pdf-symbol 

Sie wollen den Artikel nochmal in Ruhe nachlesen?
Laden Sie sich einfach die PDF aus der ORDIX news 1/2012 herunter.

Lesen Sie auch Teil V

Die Architekturbewertungen

afl Fotolia 14186901 L

„Was man nicht messen kann, kann man nicht kontrollieren!“ lautet eine alte Weisheit, die mittlerweile auch in der Softwareentwicklung Berücksichtigung findet.

Erfahren Sie mehr ...


 

Bildquelle

Das Titelbild dieses Artikels entstand aus dem folgenden Bild:

© Stockvault.net | homero chapa | Eyeglasses