25.1.2006

Software-Engineering IIEingebettete Systeme, Softwarequalität, Projektmanagement

Prof. Dr. Holger SchlingloffInstitut für Informatik der Humboldt Universität

und

Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

Folie 2H. Schlingloff, Software-Engineering II 25.1.2006

Überblick

1. Eingebettete Systeme1.1. Definitionen1.2. Anforderungsanalyse1.3. Modellierung1.4. Architektur1.5. Automotive Software Engineering

2. Software-Qualität2.1 Definitionen und Standards2.2 Funktionstest, Überdeckungsmaße2.3 Integrations-, HiL- und Abnahmetests2.4 Verifikation und Validierung

3. Projektmanagement

Folie 3H. Schlingloff, Software-Engineering II 25.1.2006

Integrationstest

• Ziel: Systematische Erprobung des korrekten Zusammenspiels von Modulen

• „Modultest auf höherer Abstraktionsebene“• White-Box auf Modulebene

Komponenten und Verbindungensind sichtbar

• Vorbedingung: die elementarenModule sind gut getestet;man kann annehmen, dass sieweitgehend fehlerfrei sind(neu auftretende Fehler sind auf Inkompatibilitäten zwischen den Modulschnittstellen zurückzuführen)

• Methode: Platzhalter und Treiber

Modul A

Modul F

Modul C Modul DModul B

Modul E

Folie 4H. Schlingloff, Software-Engineering II 25.1.2006

Platzhalter (stubs, Stümpfe)

• Ein Platzhalter (stub) ist ein Pseudo-Modul, der die Funktionalität einer noch nicht geschriebenen oder integrierten Komponente (partiell) emuliert

• Implementierungsmöglichkeiten z.B. Rückgabe eines konstanten Wertes statt eines

berechneten Funktionswertes z.B. Anzeigen der Eingabewerte und Zurückgeben

von vom Benutzer eingegebener Werte z.B. Erzeugung von schnellen Prototypen oder

schlecht synthetisierten Funktionen, die mit wenig Aufwand erstellt werden kann („Wegwerfsoftware“)

Folie 5H. Schlingloff, Software-Engineering II 25.1.2006

Beispiel

•Taschenrechner Funktionalität: wissenschaftlich-technischer

Rechner, Speicher, Anzeige-Scrolling, programmierbare Funktionen, grafisches Display (für Funktionsplot)

•Systemarchitektur?

•Stubs?

Folie 6H. Schlingloff, Software-Engineering II 25.1.2006

Treiber und Orakel

• Ein Treiber ist ein Modul welches ein zu testendes Modul (IUT, Implementation under Test) aufruft und mit Eingabedaten versorgt

• Orakelproblem: Entscheidung ob die von der IUT zurück gelieferten Werte korrekt sind lösbar: automatische Testauswertung im Treiber unlösbar: manuelle Bewertung der Tests

• Beispiele für lösbare bzw. unlösbare Orakelprobleme Treiber zum Test einer Additionsfunktion sende „i“, prüfe ob Turingmaschine „i“ terminiert wird ein Programmtext korrekt übersetzt? Erfolgt die Berechnung innerhalb einer

Millisekunde?

Folie 7H. Schlingloff, Software-Engineering II 25.1.2006

Ergebnisse Integrationstest

•Was kann bei der Integration schiefgehen? undokumentierte Seiteneffekte Eigenschaften des Betriebssystems,

Speicherlecks Parallelität, Verklemmungen Kommunikationsverzögerungen

•Oft wird für die Integration zusätzliche „glueware“ benötigt, die nicht im Modultest getestet wurde

Folie 8H. Schlingloff, Software-Engineering II 25.1.2006

Beispiel: Taschenrechner

•Welche Testtreiber werden benötigt?

•Welche Tests sollen in welcher Reihenfolge durchgeführt werden?

•Entwerfen Sie ein Konzept für die Integrationstests

• jetzt!

Folie 9H. Schlingloff, Software-Engineering II 25.1.2006

Systemtest (1)

• Möglichkeiten: Big-Bang, Top-down, Bottom-Up, Sandwich• Big-Bang

Alle individuellen Komponenten werden an einem Tag zusammengesetzt und getestet

Klingt verwegen, ist aber manchmal nicht anders machbar(z.B. wegen Verfügbarkeit spezieller Ressourcen, organisatorische Trennung zwischen Testphasen nicht möglich o.ä.)

• Top-Down Platzhalter für alle Komponenten vorbereitet Übergeordnetes Modul wird mit Platzhaltern getestet diese werden einer nach dem anderen durch untergeordnete

Module ersetzt- breadth-first oder depth-first

während die Module integriert werden, müssen einige Tests erneut durchgeführt werden (Regressionstest)

Folie 10H. Schlingloff, Software-Engineering II 25.1.2006

Systemtest (2)

• Bottom-Up Treiber für alle Komponenten vorbereitet Basismodule werden in sogenannte „Builds“ gruppiert und

integriert idealerweise wertet der Treiber die Ergebnisse der Testläufe

aus Treiber werden nach und nach ersetzt, Funktionsumfang

wächst ständig• Sandwichmethode

Zusammenwachsen des Systems von oben und unten Stümpfe für übergeordnete Module, Treiber für Basismodule Platzhalter bzw. Treiber werden bedarfsgerecht (in

Abhängigkeit der Testphase) ersetztModul A

Modul F

Modul C Modul DModul B

Modul E

Folie 11H. Schlingloff, Software-Engineering II 25.1.2006

Vor- und Nachteile (1)

• Big-bangkeinerlei Zusatzaufwand für Treiber/Platzhalterunsystematische Methode, Test problematischFehlerlokalisation evtl. schwierig

• inkrementell Integration bei Fertigstellung der Komponente

möglich Testfälle können vergleichsweise einfach

konstruiert werden, Testüberdeckung kann gewährleistet werden

Gegebenenfalls viele Testtreiber/Platzhalter nötig

Folie 12H. Schlingloff, Software-Engineering II 25.1.2006

Vor- und Nachteile (2)

• Top-down frühe Verfügbarkeit des Systems aus Benutzersicht

(„Prototyp“) Verzahnung von Entwurf und Implementierung schwierige Implementierung der Platzhalter mit zunehmender Integrationstiefe Schwierigkeiten bei der

Konstruktion von Testfällen für tiefer liegende Komponenten Zusammenspiel der Systemsoftware, Hardware und

Anwendungsebene wird erst sehr spät getestet• Bottom-up

keine Platzhalter nötig Testbedingungen leicht herstellbar Testergebnisse einfach zu interpretieren Fehleingaben zur Prüfung der Ausnahmebehandlung lauffähiges Gesamtsystem erst sehr spät verfügbar Fehler in der Produktdefinition werden spät erkannt, können

zu umfangreichen Änderungen führen

Folie 13H. Schlingloff, Software-Engineering II 25.1.2006

Pause!

Folie 14H. Schlingloff, Software-Engineering II 25.1.2006

Test eingebetteter Software

http://swt.cs.tu-berlin.de/asim-sts-05/folien/baero.pdf

Folie 15H. Schlingloff, Software-Engineering II 25.1.2006

Folie 16H. Schlingloff, Software-Engineering II 25.1.2006

HiL-Tests

• Test realer Steuergeräte (-verbünde) Zielsoftware läuft auf Zielhardware

• Simulation der Strecke in Echtzeit Sensorik, Aktuatorik, Loop Umgebungsmodell teilweise sehr komplex

(Handelsobjekt!) Schnittstellenanpassung, I/O-Karten ggf. auch Simulation anderer Steuergeräte

• Testsystem arbeitet Testsuite ab Vorspielen von Dateien mit Verläufen der Stimuli Aufzeichnen von Dateien mit Verläufen der

Reaktionen

Folie 17H. Schlingloff, Software-Engineering II 25.1.2006

HiL-Aufbau

• Implementierungssoftware Modelle auf dem Simulator

• Experiment-Kontrolle Skripte oder graphisch Animation der Ergebnisse

• Streckenmodelle kommerziell oder proprietär

• HiL-Hardware Prozessorkarte(n), I/O,

flexibele Stromversorgung(versch. Spannungsebenen)

Anschlüsse für Steuergerät FehlerinjektionsmöglichkeitBilder. dSPACE GmbH

Folie 18H. Schlingloff, Software-Engineering II 25.1.2006

HiL-Tests

• Vorteile von HiL-Tests Testabdeckung auch wenn reale Umgebung fehlt /

nicht verfügbar (z.B. Glatteis, Schwerelosigkeit) gezielte Herbeiführung von Grenzsituationen automatisches Durchschreiten von Parametersätzen Nachbildung von im Feldversuch aufgetretenen

Auffälligkeiten

• Probleme Aufwändige Hardware und Streckenmodellierung Schnittstellen müssen jedesmal neu angepasst

werden Spezifikation von Sollverhalten, Testauswertung