Die systematische Erstellung einer System- und Softwarearchitektur

Dieser Artikel behandelt das Vorgehen beim Entwurf und der Dokumentation einer Systemarchitektur anhand eines systematischen und strukturierten Architekturprozesses.

Der Artikel ist wie folgt strukturiert:

1. Definitionen – Definiert die in diesem Artikel verwendeten Begriffe
2. Entwicklungsprozess – Eine kurze Beschreibung des Systementwicklungsprozesses, in den der Architekturprozess eingebettet ist.
3. Architekturprozess – Beschreibung des Vorgehens beim Entwurf einer Systemarchitektur.
4. Architekturdokumentation – Zeigt wie der Architekturprozess und die erstellte Architektur zu dokumentieren ist.
5. Integration – Beschreibt was beim Integrieren von durch die Architektur definierten Komponenten zu einem Gesamtsystem zu beachten ist.
6. Zusammenfassung – Eine Zusammenfassung der wichtigsten Inhalte dieses Artikels.

1. Definitionen

Systemarchitektur ist nach Wikipedia wie folgt definiert:

Systemarchitektur bezeichnet, abgeleitet aus der Definition von Architektur im Allgemeinen (= Baukunst …), die Disziplin (Tätigkeitsfeld, Aufgabenstellung, Management), die auf Systeme und die in ihnen zusammenwirkenden Komponenten ausgerichtet ist.

Die Komponenten einer Systemarchitektur umfassen sowohl Hardware als auch Software. Bei der Software spricht man auch von Softwarearchitektur. Im Kontext eines Embedded Systems ist es jedoch sehr wichtig, dass die Softwarearchitektur als Teil der Systemarchitektur verstanden wird.

In diesem Artikel werden die folgenden in Abbildung 1 gezeigten Begriffe in Anlehnung an ISO 42010 verwendet:

System / Embedded System
Das System für das eine Architektur entwickelt werden soll. Ein Embedded-System ist ein elektronischer Rechner oder Computer, der eine definierte Funktion ausführt und in eine physikalische Umgebung eingebunden ist, optional von anderen Umsystemen umgeben ist sowie optional eine Benutzerschnittstelle aufweist.

Umgebung
Das Umfeld in dem das System eingesetzt wird.

Architektur
Die tatsächliche Architektur des Systems. Diese ergibt sich durch die umgesetzten Komponenten und ihr Zusammenspiel.

Stakeholder
Eine Person oder Gruppe mit einem Interesse am System.

Anforderung
Beschreibt ein einzelnes Interesse eines Stakeholders am System. Es gibt funktionale Anforderungen und nicht funktionale (Qualitätsanforderungen).

Architekturbeschreibung
Die Beschreibung der Architektur die das Ergebnis des Architekturprozesses dokumentiert. Diese sollte die tatsächliche Architektur so gut wie möglich abbilden.

2. Entwicklungsprozess

Bei der Entwicklung von Embedded Systemen empfiehlt es sich ein systematisches und strukturiertes Vorgehen. Dabei hat sich das Vorgehen nach dem V-Model (Siehe https://de.wikipedia.org/wiki/V-Modell) in der Praxis bewährt.

Das Vorgehen kann dabei grob in die in Abbildung 2 gezeigten Phasen unterteilt werden:

• Definition
• Analyse und Spezifikation
• Entwicklung
• Integration und Verifikation
• Validierung
• Wartung

Die Architektur spielt in allen Phasen des Entwicklungsprozesses eine wichtige Rolle.

Definition
Die System Definition stellt einen wichtigen Input für die Architektur dar.

Analyse und Spezifikation
In dieser Phase sollten alle Anforderungen an das zu entwickelnde System erfasst werden. Diese dienen als Inputs in die zu erstellende Architektur. Anschliessend wird der Architekturprozess gestartet und das System in Subsysteme zerlegt. Die erstellten Subsysteme werden spezifiziert. Das Vorgehen wird weiter unten im Kapitel Architekturprozess beschrieben.

Entwicklung
Stehen die Anforderungen und die Architektur fest, kann das System realisiert werden. Herbei werden die einzelnen Komponenten zuerst separat entwickelt und anschliessend zu Subsystem und zuletzt zum kompletten System integriert. Wenn während der Umsetzungen Änderungen an der Architektur gemacht werden, muss der Architekturprozess erneut durchlaufen werden, um Inkonsistenzen in der Architektur zu vermeiden.

Integration und Verifikation
Es muss sichergestellt werden, dass die Umsetzung der Komponenten der vorher definierten Architektur entspricht. Daher werden die einzelnen Komponenten anhand der Anforderungen verifiziert. Bei der Integration sollten auch die integrierten Komponenten und Subsysteme sowie das fertig integrierte System verifiziert werden.

Validierung
Anschliessend muss das System gegen die Definition validiert werden, um sicherzustellen, dass es diese auch erfüllen kann.

Wartung
Auch nachdem das System entwickelt wurde und bereits eingesetzt wird, kommt es oft zu Änderungen wie Fehlerbehebung oder Ergänzungen durch neue Funktionen. Oft wird dazu das V-Model nochmals durchlaufen. Dabei ist es ebenfalls wichtig, dass auch für solche Änderungen der Architekturprozess durchlaufen wird. Sonst besteht die Gefahr, dass die Architektur während der Lebensdauer des Systems degeneriert, was zu Fehlern im System und erhöhten Kosten in der Entwicklung führen kann.

3. Architekturprozess

Wie kommt man von den Systemanforderungen zu einer guten Architektur? Am besten man geht strukturiert und systematisch vor und dokumentiert jeden Schritt. Dieses Vorgehen sollte in einem Architekturprozess definiert werden. Im Folgenden wird ein solcher Prozess basierend auf dem Attribute-Driven Design (ADD) (Siehe https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8147) beschrieben.

Gibt es eine systematische Herangehensweise um ein (zu) schwierig erscheinendes Problem anzugehen?

Natürlich! Schon in der Redensart ‘etwas herunterbrechen’ ist ein deutlicher Hinweis auf ein sehr erfolgreiches Konzept zu finden. Die Aufteilung eines Problems in kleinere Teilprobleme und das anschliessende Zusammenführen der Teillösungen zu einer Gesamtlösung. Dieses Konzept wird vor allem bei der Erstellung von Algorithmen schon sehr lange verwendet. Heute ist das Paradigma bekannt als ‘Teile und herrsche’ (Siehe https://de.wikipedia.org/wiki/Teile-und-herrsche-Verfahren) (Divide and conquer) und ist wohl vielen Softwareentwicklern geläufig.

Aber auch im System-Design Prozess wird das Paradigma oft angewendet, dabei werden die Architekturelemente soweit zerlegt (Dekomposition) bis überschaubare, klar definierte Komponenten bestimmt sind. Hier erfolgt dann der Übergang zur Umsetzung.

Daher ist eine der wichtigsten Aufgaben einer Architektur die Aufteilung eines Systems in klar definierte Komponenten. Diese werden wiederum in Sub-Komponenten zerlegt. Jede Komponente hat eine klar definierte Aufgabe im System und kommuniziert mit anderen Komponenten über genau definierte Schnittstellen. Dadurch entstehen Architekturebenen. Die Schnittstellen einer Ebene werden auf die nächste tiefere Ebene propagiert, das heisst sie müssen von einer der Komponenten auf dieser Ebene realisiert werden.

Wichtig:

Ein Architekturprozess ist ein iterativer Vorgang, bei dem die Architektur ausgehend von den Inputs erstellt und immer weiter verfeinert wird. Die Architektur ist vollständig, wenn alle Inputs berücksichtig sind.

Dabei werden die in Abbildung 3 gezeigten Schritte für jede Iteration durchgeführt:

• Inputs überprüfen

  Eine Architektur wird durch verschiedene Faktoren beeinflusst. Es ist wichtig, dass diese identifiziert und verstanden werden, um eine zielorientierte Architektur zu entwickeln. Inputs können sich im Verlauf des Entwicklungs- und Produkt-Lebenszyklus auch verändern, daher sollten auch bei späteren Iteration immer geprüft werden, ob sie noch korrekt und vollständig sind.

  Architektur Inputs kommen aus diesen Quellen:

  • Funktionelle Anforderungen
  • Qualitätsanforderungen
  • Einschränkungen
  • Umgebung
  • Risiko Management

   

  Für das Erstellen der Architektur ist es nicht notwendig, dass alle Inputs bereits vollständig spezifiziert wurden. Wichtig sind vor allem solche Inputs, welche die Architektur beeinflussen können.

  Stehen noch nicht alle Inputs die benötigt werden zur Verfügung, sollte man mit dem verfeinern der Architektur oder zumindest der betroffenen Komponenten abwarten bis diese bereitstehen. Andernfalls besteht die Gefahr, das wichtige Faktoren unberücksichtigt bleiben und die Architektur nochmals angepasst werden muss.

   

  Funktionelle Anforderungen

  Die Architektur muss alle an das System gestellten funktionellen Anforderungen (functional requirements) erfüllen können. Daher sollten alle architekturrelevanten Anforderungen bekannt sein.

   

  Qualitätsanforderungen

  Neben den funktionellen Anforderungen (siehe oben) gibt es auch die nicht funktionelle Anforderungen (non-functional requirements). Diese werden in diesem Artikel unter dem Begriff Qualitätsanforderungen zusammengefasst.

  Beispiele für Qualitätsanforderungen:

  • Temperaturbereich in dem das System eingesetzt werden können muss
  • Reaktionszeit der Benutzerschnittstelle
  • Verfügbarkeit des Systems (Service Level Agreement)

   

  Einschränkungen

  Jede Architektur wird neben den Anforderungen (siehe oben) auch durch weitere Einschränkungen (Constraints) beeinflusst. Diese können technischer oder organisatorischer Natur sein. Diese Einschränkungen sollten klar dokumentiert werden und können als Begründung für Architekturentscheide herangezogen werden.

   

  Beispiele für technische Einschränkungen sind:

  • Begrenzte Hardware Ressourcen wie z.B. RAM oder Flashspeicher.
  • Zu verwendende Programmiersprache(n).
  • Zu verwendende Komponenten oder Subsystem (Wiederverwendung, Lagerbestände, …).

   

  Beispiele für organisatorische Einschränkungen sind:

  • Verwenden eines bestimmten Architektur Frameworks das z.B. die zu dokumentierenden Standpunkte und zu verwendende Diagramme (UML etc.) vorgibt.
  • Geltende Prozesse für Entwicklung und Design.
  • Geltende Normen und Gesetzte.

   

  Umgebung

  Das System existiert nicht in Isolation, sondern ist in einen Systemkontext eingebettet. Dieser wird durch seine Umgebung definiert.

  Zum System Kontext gehören:

  • Umwelteinflüsse (Druck, Temperatur, …)
  • Umsysteme
  • Benutzer
  • Externe Schnittstellen

   

  Ziel der Iteration definieren

  Es ist wichtig, dass man bei jeder Iteration zielgerichtet vorgeht. Dies erlaubt ein effizienteres Vorgehen. Es ermöglicht auch, kritische Komponenten und Subsysteme zuerst anzugehen, oder solche mit fehlenden Inputs später weiter zu detaillieren.

  Im Standardfall einer Architekturerstellung wird das System ausgehend vom Gesamtsystem iterativ zerlegt (Dekomposition). D.h. das Ziel dieser Iterationen ist die Zerlegung des entsprechend ausgewählten (Teil)-Systems oder einer Komponente. Eine Iteration könnte aber auch eine Verfeinerung der Architektur zu einem Thema sein. Z.B. Umsetzung der Sicherheits-Anforderungen.

   

  Architekturtreiber Identifizieren.

  Wurde das Ziel der Iteration definiert, ist es wichtig, aus der Liste aller Inputs dieser Iteration, nur die relevanten auszuwählen. Diese werden als Architekturtreiber bezeichnet, da sie die zu erstellende Architektur beeinflussen.

   

  Design Konzept erarbeiten und auswählen

  Oft gibt es nicht nur eine Variante wie ein Problem gelöst werden kann, sondern mehrere. Daher ist es wichtig, dass die verschiedenen Varianten identifiziert und bewertet werden. In der Architekturbeschreibung sollten auch nicht gewählte Varianten beschrieben werden und die gewählte Variante begründet werden. Das hilft dabei, auch später im Lebenszyklus des Systems, Architekturentscheidungen nachvollziehen zu können.

   

  Architekturelemente erstellen/Ergänzen

  Die Zerlegung oder Verfeinerung der Architektur wird nun nach dem vorher evaluierten Konzept durchgeführt. Dafür werden die notwendigen neuen Architekturelemente (Subkomponenten) eingeführt und die Verantwortlichkeiten zugewiesen, oder die bestehenden Architekturelemente entsprechend ergänzt.

  Bei der Benennung von neu eingeführten Subkomponenten ist darauf zu achten, dass diese einen klaren Hinweis auf die Verantwortlichkeiten der Komponente geben.

   

  Beispiel

  Die folgende Komponente soll zerlegt werden (1. Architekturebene):

Die Komponente hat 3 externe Schnittstellen

• Dc12V: Speisung
• SystemBus: Serielle Schnittstelle zu einem Umsystem
• ErrorLED: LED zur Fehleranzeige während der Entwicklung

Auf der 2. Architekturebene wird die Komponente in 2 Subkomponenten aufgeteilt:

Die externen Schnittstellen von Level 1 werden den Subkomponenten zugeordnet. Zwischen den 2 Subkomponenten wird eine neue Schnittstelle definiert. Diese ist aus Sicht der Level 1 Komponente eine interne Schnittstelle, aber für die Level 2 Komponenten ebenfalls eine externe Schnittstelle.

Im DATAFLOW Designer können Komponenten mit einem einzigen Klick zerlegt werden. Alle externen Schnittstellen der Komponente werden dabei automatisch auf die nächste Architekturebene propagiert.

Schnittstellen definieren

Wurde eine Iteration durchgeführt, ist es wichtig, dass alle neu eingeführten Schnittstellen zwischen den Komponenten definiert werden.

Damit es nicht zu Verwechslungen kommt ist es sehr wichtig, dass die Benennung der Schnittstellen eindeutig ist und über alle Architekturebenen und Architektursichten (Sowohl Hardware als auch Software) beibehalten wird.

Im DATAFLOW Designer werden die Namen von definierten Schnittstellen von oben nach unten propagiert. Dadurch kann es innerhalb der DATAFLOW Software nicht zu Inkonsistenzen in der Benennung kommen.

Verifizieren und verfeinern

Die erstellte Architektur sollte nun anhand der Inputs verifiziert werden. Dies stellt sicher das die gewählte Variante die Anforderungen, Einschränkungen etc. auch erfüllen kann. Dies kann zum Beispiel durch ein Review mit einem anderen Architekten erfolgen. Dabei geht man die Liste der Inputs durch und zeigt auf, wie diese im vorliegenden Design adressiert wurden. Anschliessend kann mit der nächsten Iteration begonnen werden, um die Architektur weiter zu verfeinern.

Architekturbeschreibung

Die während dem Architekturprozess definierte Architektur sollte so dokumentiert werden das für die Umsetzung in der Phase ‘Entwicklung’ des Entwicklungsprozesses alle Informationen vorhanden sind und das gewählte Design nachvollziehbar ist.

Auf den genauen Inhalt und die Struktur einer Architekturbeschreibung wird in einem anderen Artikel genauer eingegangen. Wichtig ist, dass auch die einzelnen Iterationen des Architekturprozesses als Teil dieser Beschreibung dokumentiert werden, und nicht nur die fertige Architektur. Dies erlaubt es in allen Phasen des Lebenszyklus des Systems Architekturentscheidungen zu verstehen.

Aufteilung der Architekturbeschreibung anhand der Dekomposition

Die Dekomposition im Design-Prozess dient dazu die Definition des Systems so weit zu verfeinern bis mit der Umsetzung begonnen werden kann. Dabei werden nicht nur die Komponenten zur Lösung der Teilprobleme definiert, sondern auch das Zusammenspiel dieser, um die gewünschte Gesamtlösung zu erhalten. Damit ergibt sich eine hierarchische Struktur für die System Architektur, welche üblicherweise in einem oder mehreren Dokumenten mittels Abbildungen und Text beschrieben wird.

In Abbildung 4 ist ein Beispiel für die Struktur einer Architekturbeschreibung dargestellt. Die Pfeile stellen zum einen die hierarchische Abhängigkeit dar und zum anderen den Informationsfluss (Bezeichnungen etc.) im Zuge des Design-Prozesses.

Integration

Wie bereits weiter oben ausgeführt hat die Dekomposition eines Systems in Komponenten viele Vorteile. Allerdings müssen diese Komponenten schlussendlich in der Integrationsphase des Entwicklungsprozesses als Gesamtsystem zusammenspielen. Wenn jede Komponente einzeln und möglicherweise von verschiedenen Teams entwickelt wird, kann dies im Verlaufe der Entwicklung aus dem Fokus geraten.

Dies kann zu verschiedenen Problemen führen:

• Integrationsprobleme durch inkompatible Schnittstellen
• Fehler durch Seiteneffekte von Komponenten
• Konflikte durch Verwendung derselben Schnittstelle in verschiedene Komponenten

Im Folgenden wird darauf eingegangen, wie diese Probleme vermieden werden können.

Inkompatible Schnittstellen

Die Schnittstellen zwischen Komponenten müssen klar definiert werden. Weiter muss bei der Verifikation der Komponenten sichergestellt werden, dass die Spezifikation der Schnittstelle eingehalten wurde. Weiter muss auch beim Spezifizieren der Schnittstelle auf Vollständigkeit geachtet werden. Oft werden zeitliche Aspekte vergessen oder ungenau spezifiziert, was zu Problemen beim Integrieren führen kann.

Im DATAFLOW Designer werden Schnittstellen automatisch propagiert und können mit der Schnittstellenspezifikation verknüpft werden. Dadurch wird sichergestellt, dass keine Schnittstelle vergessen wird und die relevante Dokumentation für alle Komponenten verfügbar ist.

Seiteneffekte

Wenn eine Komponente das System durch eine nicht dokumentiere Schnittstelle beeinflusst, spricht man auch von einem Seiteneffekt. Dies kann zu verschiedenen Fehlern führen, die teilweise erst nach der Integration der Komponenten entdeckt werden können. Um diese zu vermeiden, muss bei der Definition der Schnittstellen einer Komponente auf Vollständigkeit geachtet werden. Dadurch werden die Seiteneffekte in der Architekturbeschreibung sichtbar und können berücksichtigt werden. Es ist auch möglich, dass durch eine andere Aufteilung von Komponenten der Seiteneffekt vermeiden werden kann, ohne dass eine neue Schnittstelle eingeführt werden muss.

Die graphische Darstellung im DATAFLOW Designer zeigt die Schnittstellen und deren Zusammenhänge auf. So können alle Schnittstellen einer Komponente übersichtlich erfasst werden.

Konflikte

Wird eine Schnittstelle durch mehr als eine Komponente verwendet, kann es zu Konflikten kommen. Wenn z.B. 2 Komponenten dieselbe LED verwenden, würde die 2. Komponente den Zustand (an/aus) der ersten Komponente wieder übersteuern.

Daher sollte jede Schnittstelle auf einer Architekturebene exklusiv einer Komponente zugeordnet werden.

Im DATAFLOW Designer wird dies automatisch sichergestellt, da eine Schnittstelle immer nur in genau einer Komponente verwendet werden kann.

Das Erarbeiten einer guten Systemarchitektur erfordert ein gut strukturiertes und systematisches Vorgehen. Die Architektur muss dabei laufend aktualisiert und überprüft werden, um Änderungen im Entwicklungs- und Produktlebenszyklus Rechnung zu tragen.

Für die Architektur werden zuerst alle Inputs wie Stakeholder, Anforderungen, Einschränkungen und die Systemumgebung erfasst. Anschliessend wird die Architektur in einem Iterativen Prozess immer weiter verfeinert.

Ein wichtiger Aspekt einer Systemarchitektur ist dabei die Dekomposition des Systems in Komponenten und Subkomponenten (Teile und Herrsche). Dabei ist es wichtig, dass alle Schnittstellen auf die nächste Architekturebene propagiert und jeweils einer Komponente zugeordnet werden.

Dazu wird eine Komponente ausgewählt und diese zerlegt. Dabei sind die dabei gemachten Überlegungen und Entscheidungen zu dokumentieren.

Die so entstandene Architektur ist in einer Architekturbeschreibung zu dokumentieren.

Ebenfalls nicht zu vergessen ist die Integrationsstrategie, mit der die einzelnen Komponenten wieder zu einem Gesamtsystem integriert werden. Diese sollte bereits im Architekturprozess berücksichtigt werden.

Erfahren Sie hier mehr über die IMT DATAFLOW – Plattformen, Tools und Know-how für die Entwicklung von Embedded Systemen unter folgendem Link.