5 Teil 5: V-Modell-Referenz Produkte

5.3 Produkte

5.3.10 Systementwurf

5.3.10.5 SW-Architektur

Verantwortlich: SW-Architekt (bei Verwendung des Vorgehensbausteins SW-Entwicklung)

Mitwirkend: SW-Entwickler, Systemarchitekt, Systemintegrator

Sinn und Zweck

Für jede in der Systemarchitektur identifizierte »SW-Einheit wird eine »SW-Architektur erstellt. Ausgehend von den funktionalen und nicht-funktionalen Anforderungen an die SW-Einheit ist es Aufgabe des »SW-Architekten, eine geeignete SW-Architektur zu entwerfen. Das Produkt SW-Architektur dient dabei sowohl als Leitfaden zum Entwurf als auch zur Dokumentation der Entwurfsentscheidungen.

Wie in der Systemarchitektur werden richtungweisende Architekturprinzipien festgelegt und mögliche Entwurfsalternativen untersucht. Entsprechend der gewählten Entwurfsalternative wird die Zerlegung (Dekomposition) der SW-Einheit in »SW-Komponenten, »SW-Module und Produkte vom Typ »Externes SW-Modul beschrieben. Beziehungen und Schnittstellen zwischen den Elementen und zur Umgebung werden identifiziert und im Überblick dargestellt. Ein »Datenkatalog der an den Schnittstellen ausgetauschten Datenstrukturen wird erstellt.

Die gewählte Architektur wird hinsichtlich ihrer Eignung für das geforderte System bewertet. Offene Fragen können beispielsweise im Rahmen einer prototypischen Entwicklung geklärt werden.

Der Entwurf der SW-Architektur kann Änderungen der Systemarchitektur nach sich ziehen. Abhängig von den Vorgaben im Projekthandbuch wird die Änderung vom »Systemarchitekten geprüft und gegebenenfalls direkt eingearbeitet. Im Einzelfall kann ein expliziter Änderungsantrag notwendig sein.

Hauptverantwortlicher für den Entwurf der SW-Architektur ist der SW-Architekt. Unterstützt wird er dabei vom »SW-Entwickler sowie von verschiedenen Experten zu Einzelthemen wie Logistik, Sicherheit oder Ergonomie.

Die SW-Architektur stellt das zentrale Dokument für die Erstellung weiterer »Produkte dar. Sie legt alle SW-Komponenten und »SW-Module der SW-Einheit fest. Entsprechend ihren Vorgaben werden die jeweiligen Elemente mit ihren Spezifikationen erstellt.

Wird erzeugt von

Implementierungs-, Integrations- und Prüfkonzept System, Systemarchitektur (siehe Produktabhängigkeit 4.15)

Implementierungs-, Integrations- und Prüfkonzept System, Unterstützungs-Systemarchitektur (siehe Produktabhängigkeit 4.16)

Erzeugt

Prüfprotokoll Benutzbarkeit, Prüfspezifikation Benutzbarkeit, SW-Komponente, SW-Spezifikation, Prüfprotokoll Systemelement, Prüfprozedur Systemelement, Prüfspezifikation Systemelement, Datenschutzkonzept, Informationssicherheitskonzept, Sicherheitsanalyse (siehe Produktabhängigkeit 4.17)

Prüfprotokoll Benutzbarkeit, Prüfspezifikation Benutzbarkeit, Marktsichtung für Fertigprodukte, Externes SW-Modul, Externes-SW-Modul-Spezifikation, Make-or-Buy-Entscheidung, Prüfprotokoll Systemelement, Prüfprozedur Systemelement, Prüfspezifikation Systemelement, Datenschutzkonzept, Informationssicherheitskonzept, Sicherheitsanalyse (siehe Produktabhängigkeit 4.18)

Prüfprotokoll Benutzbarkeit, Prüfspezifikation Benutzbarkeit, SW-Modul, SW-Spezifikation, Prüfprotokoll Systemelement, Prüfprozedur Systemelement, Prüfspezifikation Systemelement, Datenschutzkonzept, Informationssicherheitskonzept, Sicherheitsanalyse (siehe Produktabhängigkeit 4.19)

Beispielprodukte

»FWD:SW-Architektur ECU-SW

5.3.10.5.1 Architekturprinzipien und Entwurfsalternativen

Die Beschreibung des Themas Architekturprinzipien und Entwurfsalternativen entspricht weitgehend dem Thema Architekturprinzipien und Entwurfsalternativen der Systemarchitektur.

Zu den Architekturprinzipien auf SW-Ebene zählen beispielsweise die Entscheidung für ein Programmierparadigma (objektorientiert, prozedural), die Entscheidung für eine Technologie (CORBA, EJB) oder auch die Vorgabe für eine spezielle Systemart (verteilte Internetanwendung, Desktopanwendung). Hilfestellung bei Entwurfsalternativen für die SW-Entwicklung geben beispielsweise Entwurfsmuster, Musterarchitekturen und Entwurfsheuristiken.

5.3.10.5.2 Dekomposition der SW-Einheit

Im Rahmen der Dekomposition wird die statische Struktur der »SW-Einheit festgelegt. Die statische Struktur beschreibt die Zerlegung der Einheit in »SW-Komponenten und »SW-Module. Das Entwurfsergebnis wird als Graph der zu realisierenden »SW-Elemente sowie ihrer Beziehungen untereinander dokumentiert. Zur Darstellung können beispielsweise Komponenten- und/oder Klassendiagramme verwendet werden.

Grundlage der Dekomposition sind die Anforderungen aus der »SW-Spezifikation der SW-Einheit oder eines übergeordneten Systemelements. Randbedingungen werden durch die in der »SW-Architektur identifizierten Architekturprinzipien sowie die getroffenen Entwurfsentscheidungen vorgegeben.

5.3.10.5.3 Schnittstellenübersicht

In der Schnittstellenübersicht der »SW-Architektur werden die Schnittstellen der »SW-Einheit sowie die Schnittstellen ihrer »SW-Elemente im Überblick dargestellt. Zur Beschreibung der Schnittstellenübersicht wird jeweils nur die Kommunikation auf einer Ebene betrachtet:

Auf Ebene der SW-Einheit werden die Schnittstellen zu anderen Einheiten sowie zur Umgebung beschrieben.
Auf Ebene der »SW-Komponenten werden die Schnittstellen zwischen den Komponenten innerhalb der Einheit beschrieben.
Auf Ebene der »SW-Module werden die Schnittstellen zwischen den Modulen innerhalb der Komponente beschrieben.

Umgebungsschnittstellen eines SW-Elements können beispielsweise zum Anwender, zur Logistik oder zu verschiedenen »Unterstützungssystemen existieren. Die detaillierte Beschreibung der Schnittstellen erfolgt in den jeweiligen Spezifikationen der SW-Elemente.

5.3.10.5.4 Datenkatalog

Im »Datenkatalog der »SW-Architektur werden die an den Schnittstellen der »SW-Einheit ausgetauschten Datenstrukturen mit Attributen, Datentypen und Wertebereichen beschrieben. Jede Programmiersprache und Plattform bietet hier eigene Lösungen, die bei der Definition zu berücksichtigen sind.

5.3.10.5.5 Designabsicherung

Wurde ein Architekturentwurf für die »SW-Einheit gewählt und bis auf Modulebene ausgearbeitet, so ist sicherzustellen, dass der gewählte Entwurf für die Anforderungen geeignet ist. Zur Designabsicherung von »SW-Architekturen stehen verschiedene Methoden zur Verfügung. Zwei häufig eingesetzten Methoden sind beispielsweise die Architekturevaluierung mit szenario-basierten Methoden und die prototypische Entwicklung von Systemteilen. Durchführung und Ergebnisse der Designabsicherung werden dokumentiert. Sie können gegebenenfalls eine Neubewertung der Entwurfsentscheidungen und eine Überarbeitung der Architektur nach sich ziehen.

5.3.10.5.6 Zu spezifizierende SW-Elemente

Die Erstellung einer Spezifikation für ein »SW-Element ist aufwändig und nicht in allen Fällen erforderlich. Zur individuellen Anpassung des Spezifikationsaufwands an die Projekterfordernisse hat der »SW-Architekt, abhängig von den Vorgaben im Projekthandbuch und den Anforderungen, die Möglichkeit festzulegen, für welche SW-Elemente eine »SW-Spezifikation zu erstellen ist.

Kriterien für die Notwendigkeit einer Spezifikation können beispielsweise sein: die Kritikalität des SW-Elements, die Komplexität der Anforderungen an das SW-Element oder die Vorgaben zur Prüfung im »Implementierungs-, Integrations- und Prüfkonzept SW. Für SW-Elemente, die einer Prüfung unterzogen werden, ist in jedem Fall eine SW-Spezifikation zu erstellen, da sie als Vorgabe der »Prüfspezifikation Systemelement dient. Für SW-Elemente, die als nicht zu spezifizieren eingestuft wurden, ist jeweils eine Begründung aufzuführen.