Schlussbericht zum Verbundprojekt EMPRESS

Ziel des Projektes EMPRESS (Evolution Management and Process for Real-Time Embedded Software Systems) war die Entwicklung von Methoden und Prozessen zum flexiblen und dynamischen Management der Evolution eingebetteter Realzeitsysteme. Für die Bearbeitung der Aufgabe wurden die folgenden Schwerpunkte definiert: - Schwerpunkt "Design Time Modeling" Qualitätsaspekte sind ein wichtiger Treiber für die Entwicklung von Produkten, insbesondere innerhalb einer Produktfamilie. Darüber hinaus haben Qualitätsanforderungen Einfluss auf die Architektur eines zu entwickelnden Systems. Um sicherzustellen, dass Produkte die geforderten Qualitätseigenschaften aufweisen, sind bereits beim Entwurf einer Softwarearchitektur diese Qualitäten zu beachten und durch eine verzahnte Durchführung von Design- und Analyseaktivitäten geeignete und qualitativ hochwertige Architekturen sicherzustellen. Das Ziel dieses Schwerpunktthemas war es, eine Methode zur integrierten Analyse und Design von Softwarearchitekturen im allgemeinen und Produktfamilienarchitekturen im Besonderen unter Verwendung von Architekturstilen, Architektursichten und Qualitätsmodellen auch für die Domäne der eingebetteten Systeme nutzbar zu machen. Schwerpunkt "Dynamic Reconfiguration and Versioning" Die statische und dynamische Rekonfiguration eines Systems beinhaltet funktionale Veränderungen eines Systems zur Entwicklungszeit (statisch) und zur Laufzeit (dynamisch). Dabei werden üblicherweise gesamte Komponenten ausgetauscht um z.B. einen neuen Dienst im System anzusiedeln, wobei allerdings ältere Dienste, die noch von Nutzern des Systems gebraucht und benutzt werden, weiter geführt werden müssen. Dies wird als Versionierung bezeichnet. Statische Rekonfiguration eines Systems bedeutet, dass das System angehalten wird, Komponenten ausgetauscht werden und das System wieder neu gestartet wird. Dabei werden keine laufenden Zustände weitergeführt. Bei der dynamischen Konfiguration wird das System während des Austauschvorgangs von Komponenten nicht angehalten oder neu gestartet. Die dynamische Rekonfiguration in Komponenten-basierten Systemen ist sehr schwierig durchführbar, weil interne Komponenten-Zustände übertragen werden müssen. Die Überprüfung der neuen Komponenten, nachdem die eigentliche Konfiguration erfolgte, erweist sich als relativ einfach. Ziel dieses Schwerpunkt war es, eine Testmethode basierend auf eingebauten Testverfahren (built-in test) zum Überprüfen solcher Updates zu entwickeln. Damit kann das Verhalten der neuen Komponenten nach der statischen oder dynamischen Rekonfiguration mittels fest im System verankerter Testbausteine und Test-Schnittstellen überprüft werden, bevor eine Re-Konfiguration als korrekt angenommen wird. Die Überprüfung des Zeitverhaltens eines Systems in einer neuen Konfiguration gestaltet sich ähnlich, wobei die Testfälle der Verhaltenstests durch dynamische Suchverfahren ergänzt werden. Solche Zeittests sind jedoch nur bei statischer Rekonfiguration möglich. - Schwerpunkt "Quality of Service Specification" Ein eingebettetes Realzeit-System muss nicht nur als nicht korrekt angesehen werden, wenn ein falsches Ergebnis berechnet wird, sondern auch, wenn ein richtiges Ergebnis mit der falschen Qualität geliefert wird, z.B. mit der falschen Genauigkeit, oder zur falschen Zeit. Letzteres wird als Qualität eines Dienstes (QoS) bezeichnet und ist ein fundamentaler Teil einer Systemspezifikation. Im EMPRESS-Projekt lag der Schwerpunkt dieser QoS-Anforderungen bei der Definition und Überprüfung von Antwortzeiten eines Realzeit-Systems. Ziel des Schwerpunkts war es, eine Methode zu entwickeln, um dynamisch durchgeführte Anwortzeit-Analysen, die auf modernen Such-Heuristiken basieren, auch bei objekt-orientierten und komponenten-basierten Systemen verwendbar zu machen. Diese Systeme sind im Gegensatz zu den traditionellen, prozeduralen Systemen sehr stark Zustands-basiert, so dass spezielle Testsequenzen verfolgt werden müssen, um die Antwortzeiten von Objekten analysieren zu können. - Schwerpunkt "Requirements Engineering for Non-Functional Requirements and Requirements Management" Ziel war die Entwicklung einer Methode zum Setzen, Analysieren und Reduzieren von Beziehungen von nicht-funktionalen Anforderungen zur Unterstützung von Änderungen. Nicht-funktionale Anforderungen hängen von funktionalen und anderen nichtfunktionalen Anforderungen ab. Oft stehen verschiedene nicht-funktionale Anforderungen in Konflikt zueinander, wie zum Beispiel Anforderungen an die Performanz und die Wartbarkeit eines Systems. Weiterhin tritt eine nichtfunktionale Anforderung häufig mehrfach in einem Anforderungsdokument auf, beispielsweise wenn nicht-funktionale Anforderungen für das Gesamtsystem und für einzelne Teilsysteme, für System und Software oder für verschiedene Perspektiven beschrieben werden. Darüber hinaus beeinflussen nicht funktionale Anforderungen die Architektur eines zu entwickelnden Systems und die Auswahl von Algorithmen. Typischerweise werden die Beziehungen von nicht-funktionalen Anforderungen nur unzureichend dokumentiert. Außerdem werden getroffene Entwurfsentscheidungen häufig nicht beschrieben. Entwurfsentscheidungen begründen beispielsweise, warum zur Erfüllung einer nicht-funktionalen Anforderung eine bestimme Architektur/bestimmte Algorithmen gewählt wurden. Eine unzureichende Dokumentation von Beziehungen und Entwurfsentscheidungen ist problematisch, denn die Änderung einer nicht-funktionalen Anforderung hat häufig auch Auswirkungen auf in Beziehung stehende Anforderungen, oder macht die Wahl einer anderen Architektur oder anderer Algorithmen erforderlich. Nicht explizit dokumentierte Beziehungen und Entwurfsentscheidungen erschweren ein Verständnis des Systems, eine Analyse der Auswirkungen von Änderungen und Umsetzung ohne negative Seiteneffekte für das System. - Schwerpunkt "Requirements Engineering for Functional Requirements" Bei der Erstellung einer Produktlinie, d.h. in der Produktlinienphase des Domain Engineering, ist es im Normalfall sinnvoll, auf Informationen zu existierenden Systemen zurückzugreifen. Zur Erstellung eines Domänenmodells existieren jedoch bisher keine Ansätze zur systematischen Integration von Legacy Information. Auch bei eingebetteten Systemen existieren Dokumentationen von Software und System (z.B. Benutzerdokumentation, Anforderungsspezifikation) die nützliche Informationen für die aufzusetzende oder weiterzuentwickelnde Produktlinie enthalten. Diese Informationen sollten systematisch in die Produktlinie integriert und eine Verfolgbarkeit dieser Information in die Altsysteme zurück sichergestellt werden. Schwerpunkt "Incremental (Re-)Verification/(Re-)Validation" Im Rahmen dieses Schwerpunkts wurde an zwei Teilthemen gearbeitet: ,,Assessment of fulfillment of non-functional requirements" und "Dynamic execution time analysis and verification". Im ersten Thema wurde die Frage adressiert, wie das Erreichen von nichtfunktionalen Anforderungen frühzeitig im Entwicklungsprozess beurteilt werden kann. Es sollte Im zweiten Thema ging es um die dynamische Antwortzeitanalyse (Dynamic execution time analysis and verification), die zusätzlich zur Überprüfung der funktionalen Eigenschaften eines Echtzeit-Systems durchgeführt werden muss. Hier wurden Genetische Algorithmen zur dynamischen Überprüfung der Antwortzeiten von Objekten und Komponenten eingeführt und eingesetzt, die im Vergleich zu traditionelleren dynamischen Verfahren (z.B. Zufallsgenerator) wesentlich effizienter arbeiten und qualitativ bessere Ergebnisse liefern.