Architekturdokumentation mit Viewpoints: Best Practice und normative Aspekte

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 (Viewpoints oder 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:

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 (Grundsätzliches Prinzip (II) der ISO 42010).

Ansichten (Viewpoints) einer Architektur

Die Ansichten sind ein wesentlicher Bestandteil des internationalen ISO/IEC/IEEE 42010-Standards, 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. 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 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.

Aufgrund der langjährigen Erfahrung der Firma IMT im Bereich von System- und Software-Design hat sich für die Erstellung einer Architekturbeschreibung folgender Prozess etabliert, welcher stark an den ISO 42010-Standard angelehnt ist:

• Identifikation der Stakeholder
• Identifikation der Belange / Anforderungen an die Beschreibung
• Definition der passenden Standpunkte (Viewpoints)
• Erstellung der Ansichten, basierend auf den Viewpoints
• 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 Viewpoints 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.

 

Stakeholder	Erwartungen an die Architektur (Concerns)
Software-Entwickler	Definition der Zielsystem(e) Definition der Schnittstellen
Produkt-Manager	Erwartet Skalierbarkeit Nachweis zur Ausfall-Sicherheit
Datenschutz Verantwortlicher	Nachweis für den Datenschutz

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

 

Definition der passenden Standpunkte

Der Viewpoint 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 Viewpoints 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 View separat oder, im Sinne des 42010-Standards, in einem separaten Viewpoint-spezifischen Abschnitt erfolgen.

Viewpoint	Adressierte Concerns	Modell-Typen	Analyse Techniken
Logischer Viewpoint	Schnittstellen	Hierarchisches Dekompositions-Diagramm mit der Beschreibung aller Schnittstellen.	Reviews
Physikalischer Viewpoint	Skalierbarkeit Ausfall-Sicherheit Zielsysteme	Hierarchisches Dekompositions-Diagramm mit der Beschreibung aller Schnittstellen.	Reviews Fehlerbaum Analyse Szenarien
Datenverarbeitungsprozesse	Datenschutz	Tabellarische Auflistung der Datenverarbeitungsprozesse mit Sensitivitäts-Klassifikation und Verwendungszweck.	Check-Liste
…

Tabelle 2: Definition der Viewpoints

Viewpoints

Ein Viewpoint 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 Viewpoints ist das «4+1 view model» von Kruchen oder das arc42 template, welche insbesondere in Software-Systemen Anwendung finden. Die Verwendung von Viewpoints ist aber nicht nur auf Software-Architekturen limitiert, sie können auf beliebige Systeme angewendet werden.

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

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

 

Die Logische Sicht

Die logische Ansicht wird für Geräte, bestehend aus Hard- und Software, häufig als (primärer) Viewpoint verwendet. Dabei wird das System in seine logischen Einzelteile zerlegt und angeordnet. In dieser Ansicht 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.

 

Die Physikalische Sicht

Gleichwertig zu der logischen Ansicht können unterschiedliche physikalische Standpunkte die Beschreibung und das Verständnis des Systems erweitern. Physikalische Ansichten 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 eine physikalische Sicht Sinn machen, in der die Umsetzung von nicht-funktionalen Anforderungen wie Skalierbarkeit, Verfügbarkeit oder Performance aufgezeigt werden kann.

 

Die Entwicklungssicht

Eine häufig nur implizit durchgeführte, aber für einen reibungslosen Projektablauf sehr wichtige Ansicht, 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 Sicht 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.

 

Ein Beispiel aus der Praxis

Citrex ist ein präzises Druck- und Fluss-Messgerät, welches für den mobilen Einsatz konzipiert ist. Im inneren verbergen sich zwei Mikrocontroller. Der Measurement-Controller verarbeitet sämtliche Sensor Signale und führt anspruchsvolle Normierungen und Kompensierungen aus. Die aufbereiteten Mess-Signale werden dann dem UI-Controller übermittelt, welcher die Messwerte auf dem grafischen User-Interface darstellt und den externen Schnittstellen (USB, Seriell) zur Verfügung stellt.

Für die Architekturbeschreibung der UI-Software wurde folgende Stakeholder-Analyse durchgeführt:

Stakeholder	Concerns
System Designer	·         Fault tolerance concerns ·         Interfaces to hardware modules ·         Risk classification according to 62304 ·         Persistent data ·         System States (Boot/Shut Down/Standby) ·         Update Procedure
SW Development Team	·         Fault tolerance concerns ·         Task, Interrupts and their connection ·         Risk classification according to 62304 ·         Interfaces to hardware modules ·         Persistent data ·         Deployment ·         Decomposition according to 62304 ·         System States (Boot/Shut Down/Standby) ·         SOUPs ·         Update Procedure ·         Project Planning/Monitoring
Signal Processing Development Team	·         Task, Interrupts and their sampling rate ·         Risk classification according to 62304 ·         Decomposition according to 62304 ·         Persistent data ·         System States (Boot/Shut Down/Standby) ·         Project Planning/Monitoring
Electronic Development Team	·         Interfaces to hardware modules ·         System States (Boot/Shut Down/Standby) ·         Update Procedure
Project Manager	·         Fault tolerance concerns ·         Interfaces to hardware modules ·         Risk classification according to 62304 ·         SOUPs ·         Decomposition according to 62304 ·         System States (Boot/Shut Down/Standby) ·         Update Procedure ·         Project Planning/Monitoring
QARA	·         Fault tolerance concerns ·         Risk classification according to 62304 ·         Decomposition according to 62304 ·         SOUPs ·         Decomposition
Auditors	·         Risk classification according to 62304 ·         Decomposition according to 62304 ·         SOUPs
Imt Analytics	·         SOUPs ·         System States (Boot/Shut Down/Standby) ·         Risk classification according to 62304 ·         Project Planning/Monitoring

Tabelle 3: Identifikation der Stakeholder und deren Concerns für das Fluss-Messgerät Citrex

 

Als nächster Schritt erfolgte die Definition der unterschiedlichen Viewpoints, um die Concerns entsprechend zu adressieren. Bei diesem Beispiel reichten 7 Viewpoints, um sämtliche Erwartungen abzudecken.

Viewpoint	Concerns addressed	Modell-Type	Analyse techniques
Deployment & SOUP View	SOUPs Deployment	Euler diagram	Review
Risk classification View	Risk classification according to EN62304	Euler diagram	Review
Dynamic/State View	System States (Boot/Shut Down/Standby) Update Procedure Fault tolerance concerns	State/Flowchart diagram	Sequence Diagrams Review
Decomposition View	Decomposition according to 62304	Tree diagram	Review
Process View	Persistent data Task, Interrupts and their connection Sampling rates	Data flow diagram	Sequence Diagrams Review
Interface View	Interfaces to hardware modules	Data flow diagram	Review Sequence Diagrams
Development View	Project Planning/Monitoring	Tree diagram / Lists / Burndown charts	Review

Tabelle 4: Definition der Viewpoints für die UI-Software

 

Das Design der Software-Architektur sowie die Dokumentation mit Hilfe von Views ist ein iterativer Prozess. Somit ist es unrealistisch, dass die Erstellung der unterschiedlichen Views linear durchlaufen wird. Dennoch braucht es einen Startpunkt damit die Iteration überhaupt starten kann. In der Praxis hat es sich der Top-Down Ansatz bewährt um, ein System (oder in diesem Fall Software-System) systematisch von «Oben» nach «Unten» zu zerlegen und zu definieren. Sind die Strukturen auf Top-Level definiert, werden systematisch einzelne Items ausgewählt und mit weiteren Views dokumentiert. Ein guter Startpunkt ist die Deployment-View, bei der die wesentlichen Software-Items und SOUPs (Software of Unknown Provenance) definiert werden. Abbildung 3 zeigt, wie dies am Beispiel der UI-Software des Citrex Messgerätes aussieht.

Da aus dieser Ansicht noch nicht hervorgeht, wie die Programme UIBootloader und UIFirmware zusammenhängen und interagieren, wurde auf Top-Level unter anderem auch eine Dynamic/State-View ausgearbeitet. Tabelle 5 zeigt eine Übersicht sämtlicher Views, welche für den UI-Controller erstellt wurden.

 

System/Subsystem	Erstellte Views
UI Controller	Deployment & SOUP view (Abbildung 3) Dynamic/State view Risk classification view Development View
UI.BootloaderUpdater	Decomposition view Dynamic/State view Interface view
UI.Main	Decomposition view Process view (Abbildung 4) Dynamic/State view Interface view

Tabelle 5: Ansichten, welche für den UI-Controller zwecks Architekturdokumentation erstellt wurden.

 

Insgesamt wurden also 11 Views auf der Basis von 7 Viewpoints erstellt. Vier davon zeigen das Software-System aus Top-Level Sicht. Die restlichen 7 Views verteilen sich auf die in der Deployment-View definierten Software-Items UI.BootloaderUpdater und UI.Main. Abbildung 4 zeigt ein Beispiel der Prozess-Sicht des Software-Items UI.Main.

Mit dem Design der Views ist die Arbeit jedoch noch nicht getan. Grundsätzlich enthält jede View eine Auflistung und Beschreibung sämtlicher Komponenten und deren Treiber (z.B: Systemanforderungen). Des Weiteren umfasst das Erstellen einer Architektur dokumentation weitere Schritte wie die Verifikation mittels Szenarien, das Auflisten von Constraints (Limitierungen, welche die Architektur beeinflussen), Begründungen von Architekturentscheidungen sowie Ausführungen zur Integration und Test-Strategie. Wie man dabei am besten vorgeht ist in diesem Artikel beschrieben. Für den UI-Controller wurden insgesamt 9 Szenarien definiert und durchgespielt. Abbildung 5 zeigt das Szenario wie der Messwert vom Measurement-Controller zur GUI gelangt.

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 Viewpoints abgeleitet werden. Die Viewpoints 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.