Wie wird aus Anforderungen eine Software-Architektur?

Autor: Peter Schedl, IBM Deutschland GmbH

Beitrag - Embedded Software Engineering Kongress 2015

 

Es wird die industrieerprobte Harmony Methode zur Erstellung von Architekturen für embedded Produkte vorgestellt. Im Vortrag wird das Zusammenspiel von Anforderungen, funktionalen Architekturen und dem Design beschrieben. Besonderes Augenmerk liegt auf der Bedeutung permanent begleitender Verfifikation der Entwicklungsschritte

Herausforderung Architekturerstellung

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 Produktentwicklungsyzyklus eine völlig neue Bedeutung. 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. Es besteht aus zwei Teilen, die sowohl einzeln als auch in Kombination in Projekten eingesetzt werden können. Der eine (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 z.B. Softwareentwicklung). Auch neue Methoden, wie z.B. SAFE (Scaled Agile Framework) [3], folgen einem vergleichbaren Ansatz. Es hat sich aber gezeigt, dass gerade in der Produktentwicklung, insb. 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 3 Phasen Anforderungsanalyse, Funktionale Analyse und Design-Synthese (siehe Bild 1, PDF-Datei).

Ausgangsbasis für das weitere Vorgehen ist ein Anforderungsdokument, z.B. in Form eines Kunden- bzw. Auftraggeberspezifikationsdokuments. Dies wird in ein Anforderungsmanagement-Werkzeug wie DOORS zur weiteren Analyse importiert und in eine Systemspezifikation überführt, und die System Use Cases werden 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 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ätren 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 inkl. 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 werden entsprechend auf diese gemappt. Aufgrund der geleisteten Vorarbeit und unter Einsatz von typischen Best Practices, wie z.B. 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 sicherzustellen, 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 der 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 Verfifikation 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 von 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://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=dbc39547-3619-4c31-9535-0b583a4e6190

[3]  SAFE: www.scaledagileframework.com