Architekturdokumentation mit Viewpoints: Best Practice und normative Aspekte

Matthias van der Staay, Senior Signal Processing Engineer
Lesedauer: 6 min.

Insight in Brief

Dieser Artikel zeigt, mit welchen (Hilfs-) Mitteln eine Architektur beschrieben werden kann und wie IMT diese Leitlinie in der Praxis umsetzt.

  • Entgegen der weit verbreiteten Meinung besteht eine System- oder Softwarearchitektur in der Regel nicht nur aus «einem Bild». In der Praxis sind immer mehrere Ansichten («Viewpoints») nötig, um eine Architektur zu beschreiben.
  • Viewpoints oder Views sind ein elementarer Bestandteil des internationalen Standards ISO/IEC/IEEE 42010.

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

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

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

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.

Abbildung 3: Deployment- & SOUP-View des UI-Controllers

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.

Abbildung 4: 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.

Abbildung 5: Durchspielen des Szenarios «Neuer Messwert»

[1] Grundsätzliches Prinzip (II) der ISO 42010

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

Sind Sie an weiteren Beiträgen interessiert?

Hinterlassen Sie hier Ihre E-Mail-Adresse und wir informieren Sie, sobald wir neue Beiträge veröffentlichen.

Das könnte Sie auch interessieren

IMT Insight TDPM Valve
Lesedauer: 12 Min

Modellierung thermodynamischer Prozesse in Gassystemen

Modelle thermodynamischer Prozesse sind ein wichtiges Instrument in der Entwicklung von Regelkreisen...
IMT Teststände
Lesedauer: 6 Min

Entwicklung von (teil-)automatischen Testständen

Dieser Artikel befasst sich mit der Planung und Entwicklung von Produktionsprüfständen mit Fokus auf drei Aspekte...
IMT Embedded Bild
Lesedauer: 9 Min

Embedded Systeme – «von A bis Z»

Dieser Artikel erfasst die Grundlagen zum Thema Embedded Systeme, mit denen sich IMT seit 30 Jahren...
IMT CFD Simulation
Lesedauer: 5 Min

CFD-Simulation zur Verbesserung des Wärmemanagements

Das Wärmemanagement spielt im Hinblick auf die Robustheit, Sicherheit, Langlebigkeit und Leistungsfähigkeit von Geräten...
Mitarbeiter bei der Arbeit
Lesedauer: 5 Min

System- und Softwarearchitektur in Embedded Systems

Die Begriffe «System», «Design», «Architektur» sind bei der Entwicklung von eingebetteten Systemen oft nicht klar definiert...
Besprechung eines Projektes
Lesedauer: 4 Min

Modellbasierte Methoden in der Systementwicklung

Modellbasierte Methoden bieten reichlich Potential, um die Systementwicklung effektiv zu gestalten.