Einleitung

Für medizinische Systeme mit sicherheitskritischen Anforderungen, wie z.B. Patientenüberwachungssysteme oder Beatmungsgeräte, ist die Dokumentation von System- und Software-Architekturen explizit erforderlich. Ergänzend muss ein Nachweis erfolgen, dass eine Architektur auch gemäss Ihrer Definition umgesetzt ist. Aber auch ausserhalb des regulierten Bereiches ist die sorgfältige Beschreibung einer Architektur für die meisten Anwendungen sinnvoll, denn die Beschreibung einer Architektur ist nicht nur ein Nachweis der Erfüllung von Anforderungen, sondern hilft auch, Fehler in der Spezifikation frühzeitig zu erkennen. Dieser Artikel zeigt, mit welchen (Hilfs-)Mitteln eine Architektur beschrieben werden kann und woran man sich dabei halten kann.

Beschreibung von Architekturen

Wie im Artikel über System- und Software-Architektur erläutert, ist die Architektur eines Systems «die Menge von Strukturen, welche benötigt werden, um auf das System schliessen zu können, respektive, um sicherzustellen, dass das System die geforderten Eigenschaften erfüllt. »

Zugegeben, diese Definition ist ziemlich abstrakt und zeigt keinen konkreten Bezug zu Hardware, Elektronik oder Software. Ein System besteht aber aus verschiedenen Strukturen wie Software, Elektronik oder Mechanik. Zusätzlich kann sich ein System auch durch logische Strukturen oder zeitlich aufeinanderfolgende Vorgänge charakterisieren. In diesem Sinne kann der Begriff «Die Architektur» irreführend sein, da die Singularität des Begriffes Architektur suggerieren könnte, dass eine Architektur aus einem einzigen Bild besteht. Die Praxis zeigt aber, dass ein System aus vielen unterschiedlichen Ansichten (Views) betrachtet und demnach auch beschrieben werden muss. Beispielsweise kann ein System in logische Einheiten und Funktionen unterteilt werden, die nicht unbedingt mit der physikalischen Aufteilung übereinstimmen. Dies kann anhand des folgenden, stark vereinfachten, Beispiels gezeigt werden:  

Abbildung 1: Logische und physikalische Sicht einer Client-Server-Anwendung sowie ein zugehöriges Szenario, um die Ansichten zu verbinden.

Aber welche ist die richtige oder beste, und vor allem von Regularien anerkannte Ansicht?

Eine Architekturbeschreibung besteht in der Regel genau darin, unterschiedlichen Ansichten aufzuzeigen, Verbindungen zwischen den Ansichten herzustellen und das Erfüllen von unterschiedlichen Anforderungen deutlich zu machen. Insofern besteht die Beschreibung einer Architektur aus mehreren Ansichten, welche unterschiedliche Aspekte beleuchten. Das heisst, es gibt nicht die einzig wahre Ansicht, sondern die Beschreibung einer Architektur berücksichtigt unterschiedliche Ansichten gleichwertig^[1].

Ansichten einer Architektur

Die Ansichten sind ein wesentlicher Bestandteil des internationalen ISO/IEC/IEEE 42010-Standards [link to https://www.iso.org/standard/50508.html], welcher eine Leitlinie bietet, wie die Architektur eines Systems zu beschreiben ist. Dieser Standard wurde 2011 veröffentlicht und ist das Resultat einer gemeinsamen ISO- und IEEE-Überarbeitung des früheren (stark Software-geprägten) IEEE 1471-Standards [link to https://standards.ieee.org/standard/1471-2000.html]. Der ursprüngliche IEEE 1471-Standard spezifizierte, wie die Architektur eines Systems zu beschreiben ist. Weitere Anforderungen wie der Aufbau einer Architektur sowie Anforderungen an die Beschreibungssprache wurden in 42010 ergänzt. Der Standard erfordert jedoch keine spezifische Architekturbeschreibung oder Beschreibungssprache. Stattdessen sollte die Praxis der Beschreibung einer Architektur standardisiert werden.

Ansichten (engl. Views) sollen ein System abbilden, indem sie auf Basis definierter Standpunkte die Anforderungen (Concerns) der Stakeholder berücksichtigen. Abbildung 2 zeigt, wie Ansichten, Standpunkte, Anforderungen und Stakeholder zusammenhängen.

Abbildung 2: Abhängigkeiten zwischen Ansichten, Standpunkten, Anforderungen und Stakeholdern in Anlehnung an den ISO 42010- Standard

Für die Erstellung einer Architekturbeschreibung hat sich folgender Prozess etabliert, welcher stark an den ISO 42010-Standard angelehnt ist:

1. Identifikation der Stakeholder
2. Identifikation der Belange / Anforderungen an die Beschreibung
3. Definition der passenden Standpunkte (Viewpoints)
4. Erstellung der Ansichten, basierend auf den Standpunkten
5. Verifikation der Architektur mittels Szenarien, wobei die Schritte 4 und 5 iterativ erfolgen.

Die einzelnen Schritte werden in den folgenden Kapiteln näher beschrieben.

Identifikation der Stakeholder

Damit die Standpunkte gezielt und vor allem systematisch definiert werden können, sollen in einem ersten Schritt die Stakeholder identifiziert werden, welche mit und für das System arbeiten oder Entscheidungen über das System treffen. Das können unter anderem Entwickler, Produkt-Manager, Risk-Manager, Endanwender, Produktionsmitarbeiter, Projekt-Manager usw. sein.

Identifikation der Belange und Anforderungen

Auf der Basis der identifizierten Stakeholder sollen deren Anforderungen an die Architekturbeschreibung erfasst und dokumentiert werden. Ergänzend zum Kontext-Interview mit den Stakeholdern können Hinweise zu Anforderungen an die Architekturdokumentation auch in den User- oder System-Requirements zu finden sein. Tabelle 1 zeigt, wie dies am Beispiel von Abbildung 1 aussehen könnte.

Tabelle 1: Identifikation von Stakeholdern und Erwartungen an die System-Architektur

Definition der passenden Standpunkte

Der Standpunkt charakterisiert sich durch eine Menge von Anforderungen der entsprechenden Stakeholder sowie durch unterschiedliche Konventionen hinsichtlich Modell-Typen, Notationen sowie Techniken für die darauf aufbauenden Ansichten. Die Standpunkte können wie im Beispiel von Tabelle 2 definiert werden. Ergänzend zu der tabellarischen Aufführung müssen die entsprechenden Notationen definiert werden. Dies kann entweder in jeder Ansicht separat, oder, im Sinne des 42010-Standards, in einem separaten Standpunkt-spezifischen Abschnitt erfolgen.

Tabelle 2: Definition der Standpunkte

Definition eines Standpunktes

Ein Standpunkt ist eine Art Vorlage, welche über mehrere Systeme (wieder-)verwendet werden kann und/oder unter Architekten austauschbar ist. Eine solche Vorlage wird dann verwendet um auf deren Basis systemspezifische Ansichten zu erstellen. Eine bekannte Sammlung von Standpunkten ist das «4+1 view model» von Kruchen oder das arc42 template, welche insbesondere in Software-Systemen Anwendung finden. Die Verwendung von Standpunkten ist aber nicht nur auf Software-Architekturen limitiert, sie können auf beliebige Systeme angewendet werden.

Die Definition und Wahl der Standpunkte werden primär durch die Belange der identifizierten Stakeholder festgelegt. In den nachfolgenden Kapiteln stellen wir drei mögliche Standpunkte vor, wobei diese Zusammenstellung nicht für jedes System anwendbar ist.

Generell empfiehlt es sich, die Anzahl der verwendeten auf ein sinnvolles Minimum zu beschränken, da Redundanzen mit jedem zusätzlichen steigen. Ausserdem muss jede Ansicht, welche aus den Standpunkten erstellt wird, über den Projektverlauf gepflegt, nachgeführt und vor allem konsistent gehalten werden. Der resultierende Aufwand nimmt mit der Anzahl der Standpunkte und den erstellten Ansichten zu. Unter der Voraussetzung, dass die Standpunkte und deren Ansichten den Nachweis der Anforderungen ermöglichen, ist also in diesem Fall weniger mehr.

Der logische Standpunkt

Der logische Standpunkt wird für Geräte, bestehend aus Hard- und Software, häufig als (primären) Standpunkt verwendet. Dabei wird das System in seine logischen Einzelteile zerlegt und angeordnet. In den daraus erstellten Ansichten können insbesondere funktionale Anforderungen den Komponenten zugeordnet und mögliche funktionale Redundanzen innerhalb des Systems identifiziert werden. Eine explizite Zuordnung der Systemanforderungen ist sinnvoll, da dadurch die Rückverfolgbarkeit (Traceability) gewährleistet wird. Insbesondere für sicherheitskritische Systeme ist ein Nachweis der Rückverfolgbarkeit erforderlich. Dies gilt nicht nur für System-Architekturen, sondern auch für Subsystem- und Software-Architekturen.

Kommunikationswege und zeitliche Abfolgen/Abhängigkeiten können, je nach Architektursprache, ebenfalls innerhalb der logischen Ansicht definiert werden. Da die logische Aufteilung und die dazugehörigen Prozesse eine sehr starke Abhängigkeit haben, bietet sich eine Kombination an. Alternativ können die Prozesse in einer dedizierten Sicht dargestellt werden, wobei für diesen Fall das Design von logischer Sicht und Prozess-Sicht üblicherweise iterativ erfolgt.

Der physikalische Standpunkt

Gleichwertig zum logischen Standpunkt können unterschiedliche physikalische Standpunkte die Beschreibung und das Verständnis des Systems erweitern. Physikalische Standpunkte können beispielsweise elektronische, pneumatische oder elektromechanische Ansichten sein, welche je nach Anforderungen an das System sinnvoll sind. Auch für verteilte Software-Systeme kann ein physikalischer Standpunkt Sinn machen, in der die Umsetzung von nicht-funktionalen Anforderungen wie Skalierbarkeit, Verfügbarkeit oder Performance aufgezeigt werden kann.

Der Entwicklungs-Standpunkt

Eine häufig nur implizit durchgeführte, aber für einen reibungslosen Projektablauf sehr wichtiger Standpunkt, ist die Entwicklungssicht. Dabei wird aufgezeigt, wie das zu entwickelnde System in kleine Arbeitspakete aufgeteilt werden kann, um diese den einzelnen Entwicklern oder Entwicklungs-Teams zuzuweisen. Damit können nicht nur interne Anforderungen wie beispielsweise Wiederverwendbarkeit oder die Auswahl der Entwicklungs-Tools berücksichtigt werden, sondern eine solche Ansicht ermöglicht auch die Überwachung der Entwicklungskosten und Termine im Verlauf des Projektes. Die Entwicklungssicht ist häufig nicht Bestandteil der formalen System-Architektur, sondern wird im Rahmen der Projektplanung erstellt.

Verifikation der Architektur

Ein beliebtes Instrument zwecks Verifikation einer Architektur ist das Durchspielen von Szenarien. Dabei werden in Abhängigkeit von den Anforderungen die wichtigsten Schlüssel-Szenarien definiert. Ein Szenario ist keine eigene Ansicht, sondern baut auf bestehenden Ansichten auf, indem es diese in Verbindung bringt. Demnach ist eine vollständige Architekturbeschreibung die Grundlage für die Verifikation, respektive, die Szenarien können nur durchgespielt werden, sofern die Architektur vollständig beschrieben ist. Analog zur Beschreibung der logischen oder physikalischen Ansichten, wird der Ablauf des Szenarios in der Form eines Diagramms dargestellt. Häufig werden dazu Objekt-Interaktions-Diagramme verwendet um die Interaktion zwischen den logischen und/oder physikalischen Elementen darzustellen (siehe dazu auch Abbildung 1). Solche Szenarien dienen nicht nur der Verifikation einer Architektur, sondern helfen auch, den Aufbau eines Systems zu verstehen.

Zusammenfassung

Häufig sind unterschiedliche Stakeholder involviert, welche unterschiedliche Anforderungen an ein System stellen. Damit diese Anliegen gezielt adressiert und deren Erfüllung nachgewiesen werden kann, bedarf es zur Beschreibung einer Architektur mehrerer Ansichten. Diese Ansichten können von generell definierten Standpunkten abgeleitet werden. Die Standpunkte bestehen aus allgemein anwendbaren Konventionen und sind somit über mehrere Systeme hinweg austausch- und wiederverwendbar. Abschliessend zur Architekturbeschreibung kann diese mit Hilfe von Szenarien verifiziert werden, um die Erfüllung der wichtigsten Anforderungen nachzuweisen.