Wie wird aus Anforderungen eine Software-Architektur?

Autor / Redakteur: Peter Schedl* / Martina Hafner

Mit der Harmony-Methode hat IBM ein Designverfahren entwickelt, das auf modellbasierte Entwicklung und frühzeitige Absicherung durch ausführbare Modelle setzt. Stetige Verifikation begleitet die einzelnen Entwicklungsschritte.

Anbieter zum Thema

Der Harmony-Prozess bildet eine Brücke zwischen Anforderungsanalyse, funktionaler Analyse und Systemdesign.
Der Harmony-Prozess bildet eine Brücke zwischen Anforderungsanalyse, funktionaler Analyse und Systemdesign.
(Bild: ClipDealer)

Jahrelang wurde die Entwicklung von Produkten über die Mechanik- und Elektronikkomponenten bestimmt. Die eingebettete Software hatte nur einen kleinen Anteil, der üblicherweise von einem einzigen Entwickler programmiert wurde. Entsprechend gering war auch die Bedeutung der Software, besonders im Hinblick auf die Qualität.

Mittlerweile hat sich dies dramatisch gewandelt - die Software übernimmt immer größere Anteile der gesamten Produktfunktionalität und somit auch immer öfter sicherheitskritische Funktionen. Vor diesem Hintergrund bekommen auch die Techniken der Softwareentwicklung sowie die Integration in den Produktentwicklungszyklus eine völlig neue Bedeutung.

Architekturerstellung als Herausforderung

Typische Fragestellungen sind dann: „Wie komme ich zu einer Produkt- oder Systemarchitektur und wie stelle ich die Nachverfolgbarkeit über die verschiedenen Ebenen sicher?“ Letzteres wird gerade bei der Entwicklung sicherheitskritischer Systeme wichtig, da die entsprechenden Standards genau dies aus gutem Grund einfordern.

Zum Thema der Nachverfolgbarkeit oder Traceability sei hier nur gesagt, dass es primär eine Frage der Werkzeugunterstützung darstellt und es mit OSLC (Open Services for Lifecycle Collaboration) [1] einen herstellerunabhängigen, werkzeugübergreifenden Standard gibt, der unter anderem auch genau dies leistet.

Vorstellung der Harmony-Methode

Bleibt die Frage: „Wie komme ich zu einer Architektur?“ IBM hat mit der Harmony-Methodik [2] eine erprobte Vorgehensweise, die genau diese beantwortet. Harmony wird seit über 10 Jahren in der Industrie eingesetzt und laufend angepasst. Somit kann von einer ausgereiften Vorgehensweise gesprochen werden.

Harmony setzt auf modellbasierte Entwicklung und auf frühzeitige Absicherung durch Ausführung der Modelle. Sie besteht aus zwei Teilen, die sowohl einzeln als auch in Kombination in Projekten eingesetzt werden können. Der eine Teil (Harmony ESW) verfolgt einen agilen Ansatz mit sehr kleinen Iterationen, welcher für die Softwareentwicklung gerade auch im eingebetteten Umfeld entwickelt wurde. Der andere (Harmony SE) verfolgt einen parallelisierten Ansatz mit größeren Iterationen, der ursprünglich für System Engineering gedacht war.

In Kombination ergibt sich somit eine erste Phase zur Definition einer ersten Systemarchitektur, gefolgt von kleinen Iterationen innerhalb der einzelnen Domänen (wie etwa Softwareentwicklung). Auch neue Methoden wie SAFE (Scaled Agile Framework) [3] folgen einem vergleichbaren Ansatz. Es hat sich aber gezeigt, dass gerade in der Produktentwicklung, speziell vor dem Hintergrund der Entwicklung nach dem V-Modell, Harmony SE auch zur Erstellung der Softwarearchitektur verwendet wird, um anschließend in eine abgesicherte Implementierung zu gehen.

Inside Harmony: 1. Anforderungsanalyse

Harmony besteht aus den Phasen Anforderungsanalyse, Funktionale Analyse und Design Synthese (Bild 1).

Ausgangsbasis für das weitere Vorgehen ist ein Anforderungsdokument, etwa in Form eines Spezifikationsdokuments des Kunden oder Auftraggebers. Dies wird in ein Anforderungsmanagementwerkzeug wie DOORS zur weiteren Analyse importiert, in eine Systemspezifikation überführt und die System Use Cases identifiziert.

Harmony verwendet als Notation neben textuellen Requirements eine sehr vereinfachte SysML Notation mit reduziertem Umfang an Diagrammen und auch Elementen, wie beispielsweise den Use Cases. Durch den Einsatz in zahlreichen Projekten hat sich dieses Subset bewährt und kann als Profil im Tool eingestellt, durch die reduzierte Auswahl, den Einstieg erleichtern.

Inside Harmony: 2. Funktionale Analyse

Die Anwendungsfälle (Use Cases) sind die Ausgangsbasis für die Erstellung der funktionalen Architektur. Jeder Use Case wird in ein simulierbares funktionales Modell überführt und die Anforderungen werden über Modellausführung verifiziert.

Eine zentrale Rolle spielt hierbei das Identifizieren sowie das Zusammenspiel der Systemfunktionen in Form eines Aktivitätsdiagramms. Dieses bildet die Basis für alle weiteren Schritte, sei es das Ableiten von Testsequenzen für den späteren Integrationstest, die Generierung der Systemschnittstellen oder die Verifikation mittels Modellausführung.

Es hat sich gezeigt, dass Modellierungswerkzeuge dem Anwender hier viel Arbeit abnehmen können, da etliche Schritte (teil-)automatisiert werden können. Beispielsweise bietet das Werkzeug Rhapsody eine große Anzahl solcher Automatismen, wie das Generieren der Testsequenzen aus den Aktivitätsdiagrammen.

Das Ergebnis dieser Phase stellt eine überprüfte Black-Box-Sicht des Systems mit seinen Schnittstellen inklusive Nachverfolgbarkeit zu den Systemanforderungen für die einzelnen Use Cases dar.

Inside Harmony: 3. Design-Synthese

In dieser Phase wird nun basierend auf den gefundenen Funktionen und Schnittstellen eine Architektur des Systems erstellt und die Elemente entsprechend auf diese gemappt. Aufgrund der geleisteten Vorarbeit und unter Einsatz von typischen Best Practices wie eine möglichst geringe Zahl von Schnittstellen zwischen den Komponenten bildet sich hier schnell eine erste Architektur, die über die weiteren Iterationen konkretisiert wird.

Je Iteration werden die Use-Case-Modelle in die Architektur integriert. Das Mapping erfolgt wieder automatisiert.

Um die Korrektheit des integrierten Modells sicher zu stellen wird es wieder ausgeführt und die Konsistenz, vergleichbar einem Regressionstest, zur vorherigen Phase sichergestellt. Das Ergebnis dieser Phase ist eine stabile Architektur des Systems in Form eines überprüfbaren Modells und den verlinkten Anforderungen von der Komponenten über die Systemspezifikation bis zurück zu den Kundenanforderungen.

Bedeutung der Verifikation

Verifikation der einzelnen Schritte hat eine nicht zu unterschätzende Bedeutung gerade in den frühen Phasen eines Projekts wo typischerweise die Unsicherheit noch am größten ist und gleichzeitig die Auswirkungen von Fehlern am dramatischsten.

Natürlich bedeutet Verifikation Aufwand, sei es das Verlinken der Anforderungen untereinander sowie mit dem Modell, sei es über Metriken und Reviews bis hin zur Simulation. Nicht umsonst fordern dies viele Standards insbesondere solche zur Entwicklung sicherheitskritischer Produkte.

Gerade die frühe Modellausführung bringt immer wieder Fehler zutage, die in späteren Phasen nur schwer aufzudecken und somit mit hoher Wahrscheinlichkeit wenn überhaupt erst ganz am Ende der Entwicklung entdeckt würden.

Aber bereits der Einsatz innerhalb Harmony zur automatisierten Überprüfung der Architekturerstellung ist effizienter und in Summe mit weniger Aufwand verbunden als eine manuelle Überprüfung.

Literatur- und Quellenverzeichnis

[1] Open Services for Lifecycle Collaboration (OSLC): open-services.net

[2] Harmony Community: https://tinyurl.com/y8z2sktm

[3] SAFE: www.scaledagileframework.com

* Peter Schedl befasst sich seit mehr als 20 Jahren mit Themen im Bereich der modellbasierten Entwicklung. Aktuell liegt der Schwerpunkt im Bereich Model Based Systems Engineering (MBSE), bei dem er Kunden bei der Einführung von MBSE unterstützt.

(ID:44129707)