Diplomarbeit. Coverage Analyse für Software-Tests. Stefan Kopf 25. August Betreuung: Prof. Dr. Andreas Künkler

Größe: px
Ab Seite anzeigen:

Download "Diplomarbeit. Coverage Analyse für Software-Tests. Stefan Kopf 25. August 2004. Betreuung: Prof. Dr. Andreas Künkler"

Transkript

1 Diplomarbeit Coverage Analyse für Software-Tests Stefan Kopf 25. August 2004 Betreuung: Prof. Dr. Andreas Künkler

2 FACHHOCHSCHULE TRIER UNIVERSITY OF APPLIED SCIENCES FACHBEREICH DESIGN UND INFORMATIK Autor: Stefan Kopf Titel: Coverage Analyse für Software-Tests Studiengang: Angewandte Informatik Betreuung: Prof. Dr. Andreas Künkler Fachbetreuung: Dipl. Ing. Matthias Thullner 25. August 2004 Es wird hiermit der Fachhochschule Trier (University of Applied Sciences) die Erlaubnis erteilt, die Arbeit, nach Einhaltung einer Frist von 2 Jahren, zu nicht-kommerziellen Zwecken zu verteilen und zu kopieren. Stefan Kopf c Copyright Stefan Kopf, 2004 ii

3 Besonderer Dank gebührt meinen Kollegen bei der Firma Robert Bosch GmbH insbesondere: Dipl.-Ing. Matthias Thullner Dipl.-Phys. Andre Scholand Dr.-Ing. Uta Fischer meinem Betreuer an der FH Prof. Dr. Andreas Künkler und Jutta iii

4 - iv - Kurzfassung Die vorliegende Diplomarbeit befasst sich mit der Entwicklung eines Code Coverage Tools für Software-Tests und dessen Anbindung an die Entwicklungsumgebung ASCET-SD der Firma ETAS. Die Code Coverage Analyse ist ein Verfahren zum Messen der Abdeckung von Software-Tests. Dabei wird ermittelt, welche Teile der Software durch den Test ausgeführt werden und welche nicht. Aufbauend auf diesen Ergebnissen kann eine Optimierung der Testumgebung und der Software durchgeführt werden. Das entwickelte Code Coverage Analyse Tool wird in die Entwicklungsumgebung ASCET-SD integriert und liefert bereits zur Laufzeit des Tests erste Ergebnisse. Nach Ablauf des Tests werden die Ergebnisse der Code Coverage Analyse aufbereitet und für den Softwareentwickler in einer geeigneten Form dargestellt. Abstract This diploma thesis is concerned with the development of a Code Coverage Tool for Software-Tests and its binding to the development environment ASCET-SD of ETAS. The Code Coverage Analysis is a procedure for measuring the Coverage of Software-Tests. It is to be determined thereby, which parts of the software the Test goes through and which not. From this results an optimization of the test environment and the software can be accomplished. The developed Code Coverage Analysis Tool is integrated into the development environment ASCET-SD and is already supplied runtime results. At expiration of the Test the results of the Code Coverage Analysis are prepared and represented for the software developer in a suitable form.

5 Inhaltsverzeichnis - v - Inhaltsverzeichnis 1 Einleitung Aufgabenstellung und Zielsetzung Grundlagen Verwendete Software Telelogic DOORS Rational ClearCase ETAS ASCET-SD Bugzilla Technologien Rapid Prototyping Code-Generierung mit ASCET-SD Hardware Entwicklungsumgebung LabCar NG Projektplanung Requirements Management Project Planning Project Monitoring and Control Process and Product Quality Assurance Configuration Management Change Request Management Analyse vorhandener Code Coverage Tools Untersuchung Resümee Realisierung - Vorbereitung Definition von Schnittstellen Erfassung der Informationen von CGenCorr Übergabe der Zählervariablen an ASCET-SD Speicherung der Coverage-Ergebnisse Definition von Dateiformaten Die Initialisierungsdatei Log-Dateien

6 Inhaltsverzeichnis - vi - 6 Realisierung - Implementierung Instrumentierung des Quellcodes Voraussetzungen Implementierung Analyse der Coverage-Werte Voraussetzungen Implementierung Präsentation der Ergebnisse Voraussetzungen Implementierung Beschreibung der Testumgebung Das ASCET-SD Testprojekt Das Testverfahren CompareComputing Integration in den ASD CodeGen Test Zusammenfassung und Ausblick 72 9 Glossar 74 Literaturverzeichnis Inhalt der beiliegenden CD Anhang A Anhang B 87

7 1 Einleitung Einleitung Obwohl sich die Verkehrsdichte in den letzten 20 Jahren mehr als verdoppelte, sank die Zahl der Straßenverkehrsunfälle mit Personenschäden. Dies ist vor allem auf die ständigen technischen Verbesserungen im Kraftfahrzeug zurückzuführen. Eine dieser Verbesserungen ist das ABS [Bau01], das Anti Blockier System. Bei kritischen Fahrverhältnissen, wie nasser oder glatter Fahrbahn, schreckhafter Reaktion des Fahrers oder Fehlverhalten anderer Verkehrsteilnehmer, kann es während des Bremsvorganges ohne ABS zu einem Blockieren der Räder kommen. Ist dies der Fall, so ist das Fahrzeug nicht mehr lenkbar, kann somit ins Schleudern geraten und gegebenenfalls von der Fahrbahn abkommen. In einer solchen Situation verhindert das ABS ein Blockieren der Räder und ermöglicht dem Fahrer somit eine dauerhafte Lenkbarkeit des Fahrzeuges. Dadurch ist auch bei einer Vollbremsung ein Ausweichmanöver möglich und Zusammenstöße können somit verhindert werden. Um diese Funktionalität zu ermöglichen werden hohe Anforderungen an die Software des ABS-Steuergerätes gestellt. Sie verarbeitet die Informationen der Sensoren nach festgelegten Steuer- und Regelalgorithmen und ermittelt daraus die Ansteuersignale für die Steuerventile im ABS-Hydraulikaggregat. Bei der Bremsanlage eines Kraftfahrzeugs handelt es sich um ein System mit hohen Sicherheits- und Qualitätsansprüchen. Diese Ansprüche gelten insbesondere auch für die Software des ABS-Steuergerätes. Um diesen Ansprüchen gerecht zu werden, muss die Software vor der Fertigstellung möglichst vollständig getestet werden. Zum Testen der ABS-Software werden Testabläufe entwickelt und durchgeführt. Um diese Software-Tests zu optimieren ist es sinnvoll, eine Code Coverage Analyse der Testabläufe durchzuführen, d.h. die Abdeckung des Quellcodes durch die Tests zu messen. Mit Hilfe der Code Coverage Analyse soll die Abdeckung der Software durch einen Testablauf auf folgende Kriterien hin ermittelt werden: Wird jede Methode in der Software mindestens einmal ausgeführt? Wird jeder Zweig innerhalb Software mindestens einmal ausgeführt? Wie oft wird jeder Pfad vom Test durchlaufen? Wie oft wird eine Schleife in der Software durchlaufen? Aufgrund der Ergebnisse lassen sich Rückschlüsse auf die Qualität der Testumgebung schließen. Dadurch kann eine Optimierung der Tests und eine höhere Testabdeckung der Software erreicht werden.

8 1.1 Aufgabenstellung und Zielsetzung Aufgabenstellung und Zielsetzung Die Regler-Software für das ABS-Steuergerät wird mit Hilfe der Entwicklungsumgebung ASCET-SD [ETAS00] der Firma ETAS erstellt, siehe Kapitel Dabei modelliert der Entwickler die Funktionalitäten der Software und ASCET-SD generiert mit Hilfe eines Code-Generators ANSI-C-Code, der im Anschluss noch von einem Code-Optimierer CGenCorr [Th04] hinsichtlich Speicherbedarf und Effizienz verbessert wird. Anschließend liefert der C-Compiler den Objekt-Code und der Linker schließlich den ausführbaren Code für die Zielumgebung. Dieser Code ist Teil der ABS-Reglersoftware, die mit einem Echtzeit- Betriebssystem auf einem 32-Bit Mikrocontroller lauffähig ist. Um die von ASCET-SD generierte Software und den Code-Optimierer zu testen, wurde das CompareComputing [Th04], siehe auch Kapitel 7.2, entwickelt. Dabei wird ein definierter Testablauf gleichzeitig auf zwei verschiedenen Zielumgebungen gestartet. Zum einen mit dem ursprünglichen Code von ASCET-SD auf einem PowerPC und zum anderen mit dem von CGenCorr optimierten Code auf der EMU [Bo04], Electronic Model Unit. Während des Testablaufes werden die Ein- und Ausgabewerte der einzelnen Methoden und Teilergebnisse zur Laufzeit bitweise miteinander verglichen. Das zu entwickelnde Code Coverage Analyse Tool soll in den ursprünglichen Steuergerätecode in ASCET-SD integriert werden und über den gesamten Testverlauf die Abdeckung des zu testenden Codes messen. Außerdem sollen die Optimierungen von CGenCorr berücksichtigt werden. Der von ASCET-SD generierte C-Code muss für die Code Coverage Analyse durch eingesetzte Zähler vorbereitet werden, und die Ergebnisse der Analyse sollen bereits zur Laufzeit des Tests und nach Beendigung der Testreihe verfügbar sein. Folgende Ergebnisse stehen nach Beendigung der Testreihe zu Verfügung: Die Gesamtabdeckung der Software. Die Abdeckung von Methoden. Die Abdeckung von Zweigen, If/Else oder Switch/Case. Die Abdeckung von Begrenzern (Limiter), begrenzen den Wertebereich einer Variablen. Die Abdeckung von Schleifen, While oder For.

9 1.1 Aufgabenstellung und Zielsetzung Parallel zum Code Coverage Analyse Tool wird auch ein automatisierter Testablauf für das CompareComputing entwickelt, der so genannte ASD Code-Gen Test [Scho97], siehe auch Kapitel 7.3. Dabei werden vom Anwender Voreinstellungen bezüglich der ASCET-SD-Datenbank und dem Umfang des Testes vorgenommen. Danach wird der automatisierte Testablauf gestartet und anschließ- end die Ergebnisse ausgewertet. Das Code Coverage Analyse Tool soll ebenfalls in diesen Ablauf integriert werden.

10 1.1 Aufgabenstellung und Zielsetzung Auf der folgenden Seite werden die einzelnen Kapitel dieser Diplomarbeit näher beschrieben: Kapitel 2: Grundlagen Im zweiten Kapitel der vorliegenden Arbeit werden verwendete Programme vorgestellt, verschiedene Technologien erläutert und die Entwicklungsumgebung beschrieben. Kapitel 3: Projektplanung In diesem Kapitel wird erläutert, wie die Anforderungen an das Code Coverage Tool erstellt und festgehalten wurden. Es wird dargestellt, wie der zeitliche Projektablaufplan entwickelt und umgesetzt wurde. Außerdem wird in diesem Kapitel die Art der Versionisierung von Entwicklungsstufen definiert. Kapitel 4: Analyse vorhandener Code Coverage Tools Bei der Entwicklung einer Softwarekomponente ist zur Vorbereitung eine Marktanalyse ähnlicher Produkte hilfreich. In diesem Kapitel wird dargestellt, wie bei dieser Untersuchung verschiedene Code Coverage Tools aufgrund bestimmter Kriterien analysiert und auf eine mögliche Anwendung hin überprüft werden. Kapitel 5: Realisierung - Vorbereitung Vor der eigentlichen Implementierung der Softwareanwendung werden in diesem Kapitel die Schnittstellen zu anderen Programmen und die Datenformate der benötigten und erzeugten Dateien festgelegt. Kapitel 6: Realisierung - Implementierung Dieses Kapitel erläutert die Realisierung des zu entwickelnden Code Coverage Tools. Unterteilt ist es in drei Bereiche: Instrumentierung, Analyse und Auswertung. Diese Unterteilung entspricht auch den entwickelten Programmteilen. Kapitel 7: Beschreibung der Testumgebung Bei dem Prozess der Softwareentwicklung spielt die Qualität eine immer größere Rolle. Es wird aufgezeigt, wie mit Hilfe verschiedener Testumgebungen und Testabläufen die Qualität der entwickelten Software geprüft und erhöht wird. Kapitel 8: Zusammenfassung und Ausblick Im letzten Teil dieser Diplomarbeit wird abschließend zusammenfassend auf die Diplomarbeit zurückgeblickt. Neben den erzielten Ergebnissen werden weitere Möglichkeiten und Verbesserungen aufgezählt.

11 2 Grundlagen Verwendete Software 2 Grundlagen Bei der Entwicklung des Code Coverage Tools werden verschiedene Programme verwendet. So wird für die Erfassung und Dokumentation der Anforderungen das Requirements Management Werkzeug DOORS der Firma Telelogic benutzt. Außerdem wird für die Versionisierung der einzelnen Entwicklungsschritte das Konfigurations-Management Werkzeug Rational ClearCase eingesetzt. Das Code Coverage Tool wird für den Einsatz bei der Softwareentwicklung im Bereich Embedded Software im Kraftfahrzeug entwickelt. Für die Entwicklung der eigentlichen Reglersoftware für das ABS [Bau01] wird die Entwicklungsumgebung ASCET-SD verwendet, in der auch das Code Coverage Tool integriert werden soll Telelogic DOORS Das Programm DOORS der Firma Telelogic [QSS00], siehe auch Abbildung 1, ermöglicht es dem Benutzer, Requirements Management komfortabel umzusetzen. Es unterstützt den Benutzer bei der systematischen Erfassung, Analyse, Bearbeitung und Verfolgung der Anforderungen. Die Anforderungen werden in zwei Bereiche unterteilt, die Customer- und die System Requirements. Bei den Customer Requirements werden die Anforderungen des Kunden an das zu entwickelnde Produkt festgehalten, wohingegen die System Requirements die Anforderungen des Produktes an das vorhandene System beschreiben. Somit entstehen zwei voneinander getrennte Dokumente, die in einer Datenbank abgelegt werden. Auf diese Datenbank können alle involvierten Personen zugreifen und somit standort- und abteilungsübergreifend die Anforderungen bearbeiten.

12 2.1 Verwendete Software Abbildung 1: Erfassung der Anforderungen durch DOORS, siehe auch CD Im Gegensatz zu herkömmlichen Methoden werden bei DOORS alle Gruppen im Unternehmen, die einen konstruktiven Beitrag leisten können, mit einbezogen. Auch die nicht-technischen Spezialisten haben die Möglichkeit, zur Vervollständigung der Anforderungen beizutragen. Hier zeigt sich eine der besonderen Stärken des DOORS-Ansatzes zum Requirements Management. Die präzise Formulierung und die Strukturierung der Anforderungen sowie deren Verwaltung in einer Datenbasis, die standort- und abteilungsübergreifend allen involvierten Personen offen steht, trägt wesentlich zur Erfüllung der wichtigsten Voraussetzung für die Gewinnung eines vollständigen Anforderungsprofils bei: Der interdisziplinären Kommunikation zwischen Menschen, die unterschiedliche Perspektiven vertreten.

13 2.1 Verwendete Software Rational ClearCase Rational ClearCase [Rat02] ist ein Konfigurations-Management-System, dass bei der Firma Robert Bosch als Projektdatenbank und Versionsverwaltung eingesetzt wird. Es ermöglicht dem Software-Entwicklungsteam sämtliche Daten eines Projektes zu sichern und wieder zu finden. Der Projektentwicklungsprozess wird somit für jeden Entwickler transparent und reproduzierbar gehalten. Grundbedingung für die Reproduzierbarkeit von Anwendungen ist eine Versionskontrolle, mit der verschiedene Entwicklungsstände von Quelldateien, wie beispielsweise Quellcode oder Dokumentation, verwaltet werden können. Als eine Version wird eine Datei bezeichnet, nachdem sie nach einer Änderung wieder in die Projektdatenbank eingeschrieben wurde. ClearCase wurde speziell für die Anwendung von paralleler Softwareentwicklung erstellt. Somit können sowohl die Arbeit eines Entwicklers von anderen in der Gruppe isoliert werden, als auch multiple Versionen in parallel arbeitenden Teams entwickelt werden. Des weiteren können Teams unterschiedlicher Standorte auf der gleichen Quelle arbeiten (ClearCase MultiSite). ClearCase erlaubt den Benutzern außerdem, die Quelldateien zu reproduzieren, darin Fehler zu beheben und diese zu erneuern, ohne damit den laufenden Entwicklungsprozess zu beeinträchtigen. Die Dateien und Ordner, in ClearCase Elemente genannt, werden in einer so genannten Versioned Object Base (VOB) gespeichert. Ein VOB beinhaltet alle Versionen einer bestimmten Anzahl von Elementen. Ein Entwickler arbeitet auf einer View, einer definierten Sicht auf spezielle Versionen der Elemente. Diese werden dem Entwickler als ein normales Dateisystem aufbereitet und zur Bearbeitung freigegeben. Wie auch andere Konfigurations-Management Werkzeuge benutzt ClearCase für das Verwalten von Dateiänderungen ein checkoutedit-checkin-modell. Die zu bearbeitende Datei wird aus der Projektdatenbank ausgecheckt, bearbeitet, mit einem Kommentar versehen und durch das einchecken der Datei wird die Änderung für alle sichtbar. Bei diesem Vorgang wird für die Datei automatisch eine neue Version angelegt. Die hier vorliegende Diplomarbeit wird als eigenständiges Projekt in Clear- Case angelegt und verwaltet. Dabei wird folgende Verzeichnisstruktur verwendet: /da kopfstefan /deliver /documentation /source

14 2.1 Verwendete Software ETAS ASCET-SD Bei dem Entwicklungs- und Applikationswerkzeug ASCET-SD [ETAS00] der Firma ETAS handelt es sich um ein Werkzeug zur Entwicklung von Steuerungssoftware in Embedded Systems. Dieses Werkzeug findet bei der Robert Bosch GmbH beispielsweise Anwendung bei der Generierung von Software für Kfz- Steuergeräte in den Bereichen Motormanagement, Bremssysteme, Getriebement, Fahrdynamikregelung, Adaptive Cruise Control und Body Electronics. Es beinhaltet eine grafisch orientierte Entwicklungsumgebung, einen Code-Generator und ein Testmodul (Simulator). Dadurch soll, bei schnellen Entwicklungsmöglichkeiten, eine hohe Softwarequalität und Wiederverwertbarkeit der Software bieten. ASCET-SD erfüllt die Anforderungen moderner Embedded Control Entwicklungssysteme wie beispielsweise Abstraktion, Einfachheit und Sicherheit. Somit kann der Entwickler seine Vorstellungen, beispielsweise in UML, direkt auf ASCET-SD übertragen. Die Steuergerätesoftware kann in einer grafischen Entwicklungsumgebung aus Block-Diagrammen generiert werden. Außerdem ist es möglich, Code in der JAVA-ähnlichem Modelliersprache ESDL sowie direkt in C-Code zu schreiben. Aus dieser physikalischen Modellierung wird anschließend zielplatt-formabhängiger C-Code generiert. Der vom Code-Generator ausgegebene Programmcode wird mit zielplattformspezifischen Werkzeugen in ausführbaren Binärcode übersetzt. Damit können abschließend umfangreiche Tests und Messungen durchgeführt werden. Hierbei ist es möglich, ein Offline-Experiment innerhalb der Entwicklungsumgebung, oder ein Online-Experiment in Echtzeit direkt auf dem LabCar NG [Bo04], siehe auch Kapitel 2.3.2, oder im Fahrzeug durchzuführen. Das LabCar NG ist ein Messgeräteaufbau, das die Simulation eines Fahrzeugs im Labor ermöglicht. Ein wichtiger Aspekt beim Online-Experiment ist das Prototyping. Hierbei wird die entwickelte Software auf das Steuergerät übertragen, wobei allerdings auch Echtzeit-Links gesetzt werden. Während dem Testablauf werden die neu zu entwickelnden Methoden umgeleitet, d.h. ein Teil der Steuergeräte-Funktionalität wird auf einer experimentellen Plattform, der ES1000 [ETAS00], und nicht auf dem Steuergerät ausgeführt. Dadurch ist es möglich, die neu entwickelte Software schnell und zeitsparend anzupassen und zu testen. Da ASCET-SD hauptsächlich für die Anwendung im Automobilbereich entwickelt wurde, liegt der Schwerpunkt bei der Code-Generierung für automobile Embedded Control Systeme auf der Begrenztheit von Speicher und Rechenzeit. Die entwickelte Software muss möglichst klein und schnell sein, da eine Vergrößerung der Speicherkapazitäten oder der Rechenleistung bei einem Produkt in Serienproduktion eine erhebliche Kostenfrage darstellt.

15 2.1 Verwendete Software Für die Entwicklung der Software in ASCET-SD werden Komponenten wie beispielsweise Klassen, Module und deren Instanzen verwendet. Diese sind die Hauptkomponenten der Anwendung und werden innerhalb eines Projektes zusammengestellt. Ein Projekt ist daher auch für die Verwaltung der Tasks zuständig, welche Prozesse starten, die in den Modulen definiert wurden Bugzilla Das Open-Source-Projekt Bugzilla ist ein, in PERL [Sie99] geschriebenes, datenbankbasiertes Werkzeug, mit dem bei der Firma Robert Bosch GmbH im Bereich Chassis Systems folgende Prozesse bewältigt werden: 1. Define Workpackages, Erstellung von Arbeitspaketen für die Entwicklung von Software. 2. Change Request Management, Erfassung von Änderungsanfragen an bestehende Entwicklungen. 3. Bug Tracking, Verfolgung von Fehlern in entwickelter Software. Mit Hilfe von Bugzilla werden die Arbeitspakete dieser Diplomarbeit festgehalten und sind somit vom Entwicklungsteam einsehbar. Es werden Fehlermeldungen eingetragen und deren Lösungen beschrieben, um einen auftretenden Fehler mit früheren Fehlern zu vergleichen und dadurch Lösungen effektiver zu erarbeiten. Neue Anforderungen und Änderungswünsche an das Produkt werden ebenfalls durch Bugzilla erfasst und an den Entwickler weitergeleitet.

16 2.2 Technologien Technologien Um einen besseren Überblick über das gesamte Entwicklungssystem zu bekommen, wird in diesem Kapitel auf die Technologien bei der Softwareentwicklung im Bereich Embedded Systems eingegangen Rapid Prototyping Bei der Robert Bosch GmbH im Bereich Chassis Systems wurde vor Jahren die Entscheidung getroffen, das damals neu zu entwickelnde ABS, Version 8, nicht mehr auf die herkömmliche Art, durch Programmierung in Assembler, zu entwickeln, sondern sich auf einen neuen Weg der Softwareentwicklung mit Hilfe von ASCET-SD zu begeben. Dieser Schritt wurde vor allem durch einen Compilerwechsel notwendig, wodurch die Entwicklung in Assembler nicht mehr möglich war. Die Entscheidung wurde getroffen, die Entwicklungsumgebung ASCET-SD, siehe Kapitel der Firma ETAS, ein Tochterunternehmen der Bosch Gruppe, zu verwenden. Somit wurde die Regler-Software für das ABS mit Hilfe von ASCET-SD entwickelt und anschließend der Code automatisch erzeugt. Dieses Werkzeug ermöglicht es dem Entwickler ohne große Programmieroder Hardwarekenntnisse die Software nach seinen Vorgaben zu entwickeln. Es entsteht ein Modell, dass aus entwickelten Klassen und Modulen besteht. Zum Testen der Software bietet ASCET-SD die Möglichkeit, die entwickelte Software auf verschiedenen Zielumgebungen umzusetzen, beispielsweise auf einem PC, Pentium mit Windows NT, einem PowerPC, der ES1000, oder auf einer EMU, Electronic Emulate Unit [Bo04]. Mit Hilfe von verschiedenen Compilern generiert ASCET-SD den C-Code für den PowerPC und den Maschinencode für die EMU, die mit einem TMS 470 Prozessor von Texas Instruments arbeitet. Dem Entwickler wird dadurch ermöglicht, schon während der Entwicklungsphase bestimmte Teile der Software zu testen. Die Software wird für ein Embedded System entwickelt, d.h. die Software muss auf einem bestimmten Prozessor lauffähig sein. Bei der Robert Bosch GmbH wird der Prozessor ARM7 verwendet. Dieser Prozessor erlaubt nur die Berechnung von Integer-Werten, d.h. alle Variablen haben keine Kommastellen. Die Entwicklung einer Software mit Integer-Werten wäre viel aufwendiger als in Float- Werten, also mit Nachkommastellen. Durch das Rapid Prototyping-Verfahren, ist es allerdings möglich, das Modell in Float zu entwickeln, d.h. die Berechnungen mit Kommastellen durchzuführen.

17 2.2 Technologien Dabei wird während der Testphase ein Teil der Software über einen Bypass auf der ES1000 gestartet, siehe Abbildung 2. Die ES1000 kann im Gegensatz zum ARM7 mit Float-Werten rechnen. Um die Software später auf der Zielhardware, dem ARM7, zu starten, ist eine Umstellung auf Integer-Werte nötig. Dies kann allerdings ohne Veränderung des Modells durchgeführt werden. Abbildung 2: Entwicklung der ABS-Reglersoftware mit dem Rapid Prototyping Verfahren

18 2.2 Technologien Code-Generierung mit ASCET-SD Der von ASCET-SD generierte Quellcode liegt in Form von C-Dateien vor. Um diese Quelldateien in ein ausführbares Programm umzuwandeln, sind eine ganze Reihe von Arbeitschritten notwendig. Bevor der Präprozessor den C-Code bearbeiten kann, wird der Quellcode vom Code Coverage Tool instrumentiert, d.h. die Zähler für Methoden, Zweige, Begrenzer und Schleifen werden in den Quellcode eingesetzt. Die Vorarbeit der Kompilierung liefert der Präprozessor, der die einzelnen Quelldateien zusammensetzt und die benutzten Makros aufschlüsselt. Danach erzeugt der Compiler einen Assemblercode, der anschließend vom Assembler übernommen wird. Dieser übersetzt den Code in Maschinencode, bevor der Linker noch benötigte Bibliotheken einbindet. In der Abbildung 3 wird dieser Ablauf mit den typischen Zwischenschritten aufgezeigt. ASCET-SD Generierung Dateiname.c mit Code Coverage Code Coverage Analyse Tool ohne Code Coverage Instrumentierung Präprozessor Instrumentierter C-Code Compiler Assembler Linker Ausführbarer Code Abbildung 3: Code-Generierung mit ASCET-SD

19 2.3 Hardware Hardware Zur Entwicklung der Softwarekomponenten wird ein PC mit Windows-Betriebssystem und einem speziellen Softwarepaket zur Werkzeug-Entwicklung verwendet. Zum Testen der Code Coverage Analyse auf der Zielumgebung wird das LabCar NG benötigt. Das LabCar NG ist ein Laboraufbau, der entwickelt wurde, um fahrzeugspezifische Software im Labor prüfen zu können, ohne dabei aufwendige Umbauten und Testfahrten mit Fahrzeugen durchführen zu müssen Entwicklungsumgebung Für die Entwicklung des Code Coverage Tools wird ein PC mit dem Betriebssystem Microsoft Windows 2000, Servicepack 3, verwendet. Wie in der gesamten Tool-Entwicklungsgruppe im Bereich Chassis Systems der Robert Bosch GmbH wird die Softwarekomponente dieser Arbeit mit dem XEmacs-Editor [Aich04] entwickelt. Es handelt sich hierbei um eine Open-Source Editor, bei dem es möglich ist, für die Programmiersprache PERL vorgegebene Abstände einzuhalten und Sprachelemente hervorzuheben. Dieser Editor hat aus diesen Gründen die besten Voraussetzungen für die Einhaltung der PERL-Codierungsrichtlinien der Robert Bosch GmbH. Diese beziehen sich bei der Softwareentwicklung in PERL auf die Einheitlichkeit von: Dateinamen Abständen Kommentaren Variablennamen Funktionsaufbau Dokumentation etc. Für die Ausführung der PERL-Skripte wird die Version Active PERL verwendet. Um die entwickelte Software vom ausführenden System so unabhängig wie möglich zu halten, werden aus den PERL-Skripten ausführbare Dateien generiert. Somit ist das Endprodukt nicht von einer bestimmten PERL-Version oder benutzten Bibliotheken abhängig.

20 2.3 Hardware Für die Entwicklung des Code Coverage Tools wird außerdem die im Kapitel 2.1 beschriebene Software verwendet. Das Werkzeug DOORS wird dabei für die Aufnahme und Einhaltung der Anforderungen an das Produkt, ClearCase für die Versionsverwaltung der Software und ASCET-SD als Entwicklungs- und Testumgebung verwendet LabCar NG Beim LabCar NG handelt es sich um einen Versuchaufbau, mit dem die Simulierung einer Kraftfahrzeugumgebung im Labor möglich ist. Dadurch soll dem Entwickler von Embedded Software ermöglicht werden, die entwickelten Komponenten direkt im Labor, ohne aufwendige Testfahrten im Fahrzeug, zu testen. Deswegen ist die Entwicklung von Software in diesem Bereich schneller und kostengünstiger möglich. Das LabCar NG beinhaltet folgende Komponenten, die auch in Abbildung 4 zu sehen sind: E-Target, ES1000 PowerPC mit Monitor EMU, Electronic Emulate Unit Fahrzeugsimulations-Hardware mit ABS-Sensorkarten Flash-Tool Stromversorgung CAN, Fahrzeug-Bussystem zur Datenübertragung Um im Labor das Bremssystem eines Kraftfahrzeugs simulieren zu können, wird in aller erster Linie das Steuergerät für das ABS benötigt. Für die Entwicklung wird nicht ein Seriensteuergerät benutzt, sondern eine modifizierte Version davon: die EMU. Bei der Entwicklung der EMU wurde kein Wert auf Kompaktheit oder Schutz vor Umwelteinflüssen gelegt, sondern auf den einfachen Zugriff auf möglichst viele Messwerte. Das Flash-Tool wird benötigt, um die entwickelte Software vor dem Test auf die EMU zu übertragen. Dieser wird über eine Schnittstelle vom PowerPC angesteuert. Der PowerPC dient außerdem zur Messung der Werte beim Testablauf, wohingegen die ES1000 als zweite Zielumgebung, neben der EMU, für die ABS-Reglersoftware im LabCar NG installiert ist. Um die Fahrzeugumgebung zu komplettieren, wird noch ein Informationsbussystem, der CAN, und verschiedene Sensorkarten für die Radsensorik benötigt.

21 2.3 Hardware Abbildung 4: LabCar NG, Laboraufbau zur Steuergeräte-Softwareentwicklung

22 3 Projektplanung Projektplanung Die vorliegende Diplomarbeit wird als eigenständiges Projekt betrachtet und somit auch eine Projektplanung dafür erstellt. Grundlage für diese Projektplanung ist das V-Modell [Ba98], siehe Abbildung 5, ein Vorgehensmodell, dass die Aktivitäten und Produkte eines Entwicklungsprozesses festlegt. Bei einer Softwareentwicklung nach dem V-Modell wird ein strukturierter Ablauf der Entwicklung gewährleistet. Außerdem wird dabei mit definierten Abläufen und Ergebnissen gearbeitet, was eine frühzeitige Fehlerbeseitigung ermöglicht. Abbildung 5: Softwareentwicklung nach dem V-Modell Um die Planung für diese Diplomarbeit übersichtlich und strukturiert zu halten, werden Prozesse für das Projektmanagement durchgeführt. So wird beispielsweise ein Projektplan mit Hilfe von Microsoft Excel erstellt, der die zeitliche Abfolge der einzelnen Entwicklungsschritte des Code Coverage Tools beinhaltet. Dieser Projektplan soll in den wöchentlichen Statusbesprechungen kontrolliert und gegebenenfalls aktualisiert werden. Ebenfalls wird eine Anforderungsanalyse durchgeführt, durch die die Anforderungen an das Code Coverage Tool festhalten werden können. Diese werden dabei in Bereiche wie Kunden- und Systemanforderungen unterteilt. Um für projektspezifische Prozesse Vorgehensweisen festlegen zu können und sich die Fähigkeit zu erhalten, eine Entwicklungsprojekt zu verwalten und zu pflegen, ist es sinnvoll, ein allgemeines Modell für die Prozessabwicklung zu verwenden. Ein solches Modell ist CMMI, Capability Maturity Model Integration.

23 3 Projektplanung Es wurde am Software Engineering Institute der Carnegie Mellon University in Pittsburgh ursprünglich im Auftrag des amerikanischen Verteidigungsministeriums entwickelt, um die Definition eines beliebigen Auftrages und die damit verbundenen Qualitätsanforderungen festzulegen. Mit der Zeit entwickelte sich daraus ein Modell zur Erfassung und Verbesserung der Prozesse in der Softwareentwicklung. CMMI beruht nicht auf einem theoretischen Modell, sondern auf Vorgehensweisen, die sich in der Praxis bewährt haben. Der Organisation wird nicht eine konkrete Umsetzung der Anforderungen, bzw. ein bestimmtes Werkzeug, vorgeschrieben, sondern nur die Festlegung zur Durchführung des Prozesses. Die Umsetzung liegt alleine bei der Organisation, die CMMI benutzt und damit ihre Vorgehensweisen verbessern will. CMMI wird in so genannte Maturity Levels, Reifegrade, eingeteilt, wobei jeder dieser Grade unterschiedliche Schwerpunkte auf die System- bzw. Softwareentwicklung legt. Ein Maturity Level wird durch seine Prozessbereiche definiert, die wiederum aus einer Gruppe zusammengehörender Prozesse und Aktivitäten besteht. Die Prozessbereiche für das Maturity Level 2, das momentan bei Bosch umgesetzt werden soll, sind: Requirements Management, Analyse der Anforderungen an das Produkt. Project Planning, Erstellen und Pflege von Projektaktivitätsplänen. Project Monitoring and Control, regelmäßige Analyse und Kontrolle des Projektstandes. Supplier Agreement Management, Regelung von Erwerb externen Produkten oder Dienstleistungen. Measurement and Analysis, Messung und Vergleich der Werte verschiedener Projekte. Process and Product Quality Assurance, Informationsfluss und Qualitäts-überprüfung gegenüber der Projektleitung. Configuration Management, Integrität von Arbeitsprodukten. Change Request Management, Erfassung von Änderungsanfragen. Für die hier vorliegende Arbeit wird nur ein Teil dieser Prozessbereiche umgesetzt. So wird eine Requirements Analyse durchgeführt, ein Projektplan erstellt, eine wöchentliche Statusbesprechung durchgeführt und für die Versionsverwaltung das Konfigurationsmanagementprogramm ClearCase verwendet.

24 3.1 Requirements Management Requirements Management Unter Requirements Management versteht man das Aufnehmen und Verwalten von Anforderungen an das Produkt. Das Produkt wird mit den Anforderungen konsistent gehalten und Verantwortliche für die Realisierung der Anforderungen und deren Zeitpunkt bestimmt. Es sollen die gesammelten Anforderungen dokumentiert und eventuelle Änderungen kontrolliert werden. Außerdem soll es möglich sein, Verbindungen und Zusammenhänge zwischen einzelnen Anforderungen aufzuzeigen. Das Requirements Management liefert somit eine solide Basis für eine erfolgreiche Planung und Durchführung eines Projektes. Hauptziel dieses Prozessbereiches ist es, ein einheitliches Verständnis der Anforderungen zu erreichen. Um einen besseren Überblick über die Anforderungen zu erhalten und diese einfach verwalten zu können, wird für diese Diplomarbeit die Software DOORS der Firma Telelogic verwendet, siehe Kapitel Die Anforderungen an ein Produkt werden von DOORS in folgende Bereiche unterteilt: 1. Customer Requirements, die vom Kunden gewünschten Anforderungen an das Produkt. 2. System Requirements, die Anforderungen des Produkts an das System und die Umgebung. Für diese beiden Anforderungsmodule werden geeignete Testfälle definiert, d.h. für jede Anforderung in den Modulen Customer Requirements und System Requirements wird ein geeignetes Testszenario entwickelt. 3.2 Project Planning Beim Project Planning handelt es sich um die Einführung und Pflege von Plänen in denen die Projektaktivitäten definiert sind. Die Anforderungen des Requirement Managements werden in eine zeitliche Abfolge eingegliedert, um das Projekt hinsichtlich Lebensdauer, Kosten und Ressourcen abschätzen zu können. Durch einen Projektplan sind die Projektaktivitäten bzw. Arbeitspakete identifizierbar und die Zuständigkeiten mit den Ressourcen sind abgestimmt. Der Projektplan dieser Diplomarbeit, siehe auch Kapitel 11, wurde mit Microsoft Excel erstellt und ist im Laufe der Diplomarbeit immer wieder aktualisiert und erweitert worden.

25 3.3 Project Monitoring and Control Project Monitoring and Control Durch das Project Monitoring and Control soll für die beteiligten Personen ein Verständnis für den Projektablauf hergestellt werden. Der Projektfortschritt wird gegenüber dem Projektplan überwacht und bei deutlichen Abweichungen vom Projektplan werden geeignete Maßnahmen ergriffen werden. Dem Projektleiter und den Mitarbeitern soll ein Überblick über den aktuellen Stand des Projekts gegeben werden Außerdem soll es dem Projektleiter möglich sein, ein Projekt zu jedem beliebigen Zeitpunkt zu überprüfen. Dabei stellen sich folgende Fragen: Werden bestimmte Aufgaben in der vorgeschriebenen Zeit bearbeitet? Sind die Aufgaben richtig auf die Ressourcen verteilt? Wird der erstellte Zeitplan eingehalten? Treten unvorhergesehene Probleme und Zeitverschiebungen auf? Um bei der vorliegenden Diplomarbeit einen Überblick über den aktuellen Stand der Entwicklung zu haben und gegebenenfalls Gegenmaßnahmen ergreifen zu können, wurde während der gesamten Dauer der Diplomarbeit eine wöchentliche Statusbesprechung mit dem Projektleiter Hr. Thullner abgehalten. Dabei werden die Anforderungspläne und Lastenhefte überarbeitet und eventuell der Projektplan aktualisiert. In der Statusbesprechung werden auftretende Probleme diskutiert und deren Lösungsmöglichkeiten besprochen. 3.4 Process and Product Quality Assurance Die Process and Product Quality Assurance soll die Projektleitung und das Management mit sachlichen Informationen über den Prozessstatus und die beteiligten Arbeitspakete versorgen. Dadurch soll eine Beurteilung der Prozesse und eine Bewertung der Arbeitsprodukte und Dienstleistungen ermöglicht werden. Der Projektleitung und dem Management soll damit eine Möglichkeit eröffnet werden, nicht erfüllbare Aufgaben zu lösen und eine Qualitätssicherung zu etablieren. Dieser Prozess wird ebenfalls in der wöchentlichen Statusbesprechung mit dem Projektleiter abgearbeitet.

26 3.5 Configuration Management Configuration Management Beim Configuration Management soll eine Etablierung und Unterstützung der Integrität von Arbeitsprodukten unter folgenden Gesichtspunkten sichergestellt werden: Identifikation Änderungskontrolle Einheitliche Verfahrensweisen bei der Definition von Baselines Alle zum Projekt dazugehörenden Komponenten müssen eindeutig identifiziert, versioniert und mit Baselines versehen werden. Dies ermöglicht dem Entwickler, bzw. dem Projektleiter, Änderungsanfragen zu verfolgen und zu kontrollieren. Jede Änderung einer Komponente kann durch das Configuration Management verfolgt und transparent gehalten werden. Bei der Bearbeitung dieser Diplomarbeit wird mit dem Konfigurationsmanagement Werkzeug ClearCase, siehe Kapitel 2.1.2, gearbeitet. Dabei wird dem Benutzer ermöglicht, Entwicklungsstände zu identifizieren und Änderungen nachzuvollziehen. So können beispielsweise aktuelle Versionen mit früheren verglichen werden, um Änderungen aufzuzeigen. 3.6 Change Request Management Unter dem Begriff Change Request Management versteht man die Erfassung und Verwaltung von Änderungswünschen an ein Produkt. Bei der Firma Robert Bosch GmbH im Bereich Chassis Systems wird für diese Aufgabe das Werkzeug Bugzilla, siehe Kapitel 2.1.4, verwendet. Es ermöglicht die Eingabe der Änderungsanfrage und durch die datenbankbasierte Speicherung auch eine Verfolgung dieser Anfrage. Für die vorliegende Diplomarbeit werden Änderungsanfragen ebenfalls mit Hilfe von Bugzilla erfasst.

27 4 Analyse vorhandener Code Coverage Tools Analyse vorhandener Code Coverage Tools Um einen Einblick in die Möglichkeiten von Code Coverage Tools und um eine eventuelle Grundlage für eine Entwicklung zu erhalten, werden mehrere bereits vorhandene Code Coverage Tools auf festgelegte Kriterien hin untersucht. Dabei soll einerseits geprüft werden, ob es möglich ist, ein bereits entwickeltes Code Coverage Tool komplett oder teilweise zu verwenden oder ob es notwendig ist, ein neues Tool zu entwickeln. Andererseits soll diese Analyse Einblicke in die Möglichkeiten eines Code Coverage Tools geben. Durch die Requirements Analyse sind die Anforderungen an das Tool festgelegt, woraus sich auch die Kriterien für dieser Untersuchung ergeben haben. Um die Gewichtung der einzelnen Kriterien zu berücksichtigen wurden diese in verschiedene Prioritätsstufen unterteilt. Kriterien Prio 1: Welche Funktionen können mit dem Programm durchgeführt werden? Können die Informationen von CGenCorr verarbeitet werden? Ist eine Integration in ASCET-SD möglich? Prio 2: Ist der instrumentierte Quellcode des Projekts einsehbar? Ist die Präsentation der Ergebnisse übersichtlich und für den Entwickler brauchbar? Wie komfortabel ist die Installation? Ist ein Support vorhanden? Prio 3: Ist der Quellcode des Code Coverage Tools einsehbar und erweiterbar? Wie hoch sind die Kosten einer Lizenz? Ist eine komplette Installation erforderlich? Können die einzelnen Komponenten separat voneinander ausgeführt werden? Instrumentierung des Quellcodes. Anzeige der Teilergebnisse während des laufenden Experiments. Graphische oder tabellarische Präsentation der Endergebnisse.

28 4.1 Untersuchung Untersuchung Bei der praktischen Untersuchung der folgenden Code Coverage Tools wurden alle auf dem Entwicklungssystem installiert und auf die bereits aufgezählten Kriterien hin untersucht. Panorama Die Anwendungssoftware Panorama [ISA04] der Firma International Software Automation aus den USA ist ein sehr einfach gehaltenes GUI für die Code Coverage Analyse von C oder C++ Quellcode. Die Installation ist einfach und komplett notwendig. Aus einer grafischen Oberfläche heraus können Quelldateien zur Analyse angegeben werden. Leider ist es nicht möglich, die Instrumentierung des Quellcodes einzusehen. Eine Integration in ASCET-SD ist ebenfalls nicht möglich, da der Zugriff auf die verwendeten Zählervariablen dafür notwendig wäre. Bei Panorama ist es allerdings möglich, die grafische Präsentation der Ergebnisse separat zu starten, wozu die Daten aber in einem bestimmten Datenbankformat zur Verfügung stehen müssen. CC-Analyser Der CC-ANALYZER [CCA04] der Firma CaseConsult aus Wiesbaden ist ein weiteres Produkt zur Coverage Analyse. Mit diesem Programm ist der Anwender in der Lage, den instrumentierten Code einzusehen und somit ist es auch möglich, dieses Programm in die Entwicklungsumgebung ASCET-SD einzubinden. Die einzelnen Teile, wie Instrumentierer und die Präsentation der Ergebnisse, sind separat durch ausführbare Skripte aufrufbar, wodurch einzelne Teilbereiche des CC-Analyser verwendet werden könnten. Die Präsentation der Ergebnisse ist in Form von HTML-Seiten und ist sehr übersichtlich gestaltet. CTC++ Wie auch beim CC-Analyser kann mit der Software CTC++ [VS04], aus dem Hause Verifysoft, Quellcode in C instrumentiert, getestet und die Ergebnisse visualisiert werden. Die Komponenten sind einzeln ausführbar und der instrumentierte Quellcode ist einsehbar, wodurch eine Anbindung an ASCET-SD möglich wäre. Die Ausgabe der Ergebnisse erfolgt ebenfalls in HTML- Seiten, wobei hier allerdings eine erweiterte Form verwendet wird. So ist es beispielsweise möglich, den Quellcode und die unabgedeckten Teile des Codes mit Hilfe von Links einzusehen.

29 4.1 Untersuchung Prepare BranchCounter Das vom Bereich Chassis Systems der Robert Bosch GmbH für diesen Zweck entwickelte Code Coverage Tool Prepare BranchCounter [Th01] ermöglicht es dem Benutzer, ohne vorherige Installation, den von ASCET-SD generierten Quellcode für die Code Coverage Analyse zu instrumentieren. Durch ein Coverage-Modul, welches in beliebige Projekte eingebunden werden kann, ist eine Anbindung an ASCET-SD möglich. Mit dem Prepare BranchCounter ist eine visuelle Ausgabe der Coverage- Ergebnisse nicht möglich. Ebenso ist eine Speicherfunktion der Ergebnisse durch ASCET-SD nicht vorhanden. Die Instrumentierung des Codes ist fehlerhaft und nicht vollständig. Prepare BranchCounter ist ein PERL-Skript, aus dem vor der Verwendung durch ASCET-SD, eine ausführbare Datei generiert wird.

30 4.2 Resümee Resümee Durch die Analyse von herkömmlicher Standardsoftware und dem bereits vorhandenen internen Tool für die Code Coverage Analyse werden verschiedene Möglichkeiten der Instrumentierung, Online Monitoring und der späteren Ergebnisvisualisierung aufgezeigt. Die externen Code Coverage Tools werden für eine weiter Verwendung nicht in Betracht gezogen, da entweder eine Integration in ASCET-SD nicht möglich ist, oder die Funktionalitäten des Werkzeuges für eine Anwendung in diesem Bereich nicht ausreichen, siehe auch Abbildung 6. Das bereits vorhandene interne Werkzeug Prepare BranchCounter kann für die Implementierung und das Online Monitoring verwendet werden. Für diese Anwendungen wird das Werkzeug erweitert, korrigiert und optimiert. Um die Visualisierung der Coverage-Ergebnisse dem Entwickler nützlich darzustellen, wird eine neue Komponente entwickelt. Abbildung 6: Ergebnisse der Untersuchung vorhandener Code Coverage Tools, siehe auch CD

31 5 Realisierung - Vorbereitung Realisierung - Vorbereitung Vor der eigentlichen Implementierung des Code Coverage Tools müssen einige Vorarbeiten geleistet werden. So werden beispielsweise die Schnittstellen zu den anderen Programmen definiert und implementiert werden. Außerdem sind der Inhalt und das Format der Log-Dateien und der Initialisierungsdatei festzulegen. 5.1 Definition von Schnittstellen In der Definition der Anforderungen an das Code Coverage Tool werden verschiedene Schnittstellen zu anderen Programmen notwendig. So müssen vor dem Beginn der Instrumentierung des Quellcodes die Information vom Code- Optimierer CGenCorr eingelesen und verarbeitet werden. Ebenso sollten die vom Instrumentierer benutzten Variablen und Arrays an ASCET-SD übergeben werden, damit eine Messung überhaupt durchführbar ist. Nach erfolgreichem Abschluss des Experiments müssen die gemessenen Werte wieder an das Code Coverage Tool zurückgegeben werden, um anschließend eine Aufbereitung der Ergebnisse durchführen zu können Erfassung der Informationen von CGenCorr Die von ASCET-SD generierten Quelldateien werden von dem Code-Optimierer CGenCorr aus Gründen der Performance überprüft. CGenCorr durchsucht dabei das gesamte Projekt nach überflüssigem Programmcode, wie zum Beispiel nicht aufgerufene Methoden. Da diese im gesamten Projekt nicht benützt werden, sind sie somit für die Funktionalität der Software nicht erforderlich und können entfernt werden. Diese Methoden können in einem Projekt enthalten sein, da es in ASCET-SD möglich ist, Software durch Modulbildung zusammenzusetzen. CGenCorr entfernt diese unbenützten Methoden aus dem Quellcode, um dadurch Speicherbedarf auf der Zielhardware zu sparen. Die Informationen, welche Methoden in welcher Quelldatei entfernt wurden, sind für das Code Coverage Tool sehr wichtig. Beim Testablauf Compare- Computing, siehe Kapitel 7.2, wird die Software parallel auf zwei verschiedenen Zielumgebungen gestartet. Auf der einen Seite die optimierte Software von CGen- Corr und auf der anderen Seite die Originalsoftware mit dem instrumentierten Code vom Code Coverage Tool.

32 5.1 Definition von Schnittstellen Die im optimierten Code entfernten Methoden sind in der Originalsoftware noch enthalten. Aus diesem Grunde, müssen die im optimierten Code entfernten Methoden, die im Originalcode noch enthalten sind, speziell instrumentiert werden. Würden diese Methoden als ganz normale Methoden initialisiert werden, so bleiben diese Zähler immer auf Null stehen, da sie im Code auf der Zielumgebung ja nicht mehr vorkommen und deshalb vom Test nicht aufgerufen werden. Für die Übergabe der Informationen von CGenCorr muss eine geeignete Schnittstelle definiert werden. Dabei sind folgende Informationen über die optimierten Code-Stellen jeder Quelldatei notwendig: In welcher Quelldatei wurden die Optimierungen durchgeführt? Welche Methoden wurden von CGenCorr entfernt (UnusedMethods)? Welche Zweige befinden sich innerhalb von gelöschten Methoden (UnusedBranches)? Welche Limiter, Begrenzer, befinden sich innerhalb von gelöschten Methoden (UnusedLimiters)? Welche Limiter wurden ausgelagert, bzw. für welche Limiter wurden eigene Methoden generiert (OutlinedLimiters)? Welche Bitfelder wurden erstellt, bzw. welche einzelnen Bits wurden zusammengefasst (CreatedBitfields)? Welche Methoden wurden entfernt und die Befehle in die aufrufende Zeile direkt eingesetzt (InlinedMethods)? Um diese Informationen durch das Code Coverage Tool verarbeiten zu können, wurde eine Austauschdatei definiert, in der die benötigten Informationen gespeichert werden. Sie enthält die Informationen von den durch CGenCorr durchgeführten Optimierungsschritten in XML-Format und kann optional vom Code Coverage Tool eingelesen werden. Durch diese optionale Einstellung in der Initialisierungsdatei, ist das Code Coverage Tool auch mit früheren Versionen von CGenCorr kompatibel und funktioniert auch unabhängig von CGenCorr.

33 5.1 Definition von Schnittstellen Es folgt ein Ausschnitt aus der Übergabedatei cov xchange.xml: <DELETED METHOD> <ARGLIST>void</ARGLIST> <ARGS>0</ARGS> <BODY> return (f1562 WHLSIS 5MS SZD2SI tgaestimact FL()); </BODY> <CLASSNAME>RADSIGNALAUFBEREITUNG WO</CLASSNAME> <CNAME>f1028 RADSIGNALAUFBEREITUNG WO tgaestimact FL</CNAME> <FILENAME>../ecco/asw RADSIGNALAUFBEREITUNG.c</FILENAME> <FUNCTYPE>method</FUNCTYPE> <ID>tGaEstimAct FL</ID> <IS CALLING> <5MS SZD2SI tgaestimact FL>1</5MS SZD2SI tgaestimact FL> </IS CALLING> <NO OF CALLS>0</NO OF CALLS> <STATEMACHINE>0</STATEMACHINE> <TYPE>uint8</TYPE> </DELETED METHOD> In diesem Beispiel wird eine Methode von CGenCorr beschrieben, die in der späteren Software nicht mehr enthalten ist, da sie aus Optimierungsgründen entfernt wurde. Für den Instrumentierer sind vor allem der Klassenname und der Dateiname wichtig, um diese später bei der Instrumentierung der Quelldateien wieder zu erkennen. Ist das der Fall, so wird diese Methode und alle Zähler die sich darin befinden mit einer speziellen Zählerart versehen. Dadurch verringern diese Zähler die Gesamtabdeckung nicht und eine Überprüfung des Code-Optimierers ist außerdem möglich. Diese Methoden dürfen während des Experimentes nicht aufgerufen werden, bzw. diese Zähler dürfen nicht inkrementiert werden, da sonst eine Methode benützt wurde, die es in der optimierten ABS-Reglersoftware nicht mehr gibt, siehe auch Kapitel Übergabe der Zählervariablen an ASCET-SD Bei der Instrumentierung werden Variablen und Arrays als externe Werte in einer Header-Datei angelegt. Bei der Code-Generierung kann der Compiler und Linker auf diese Datei zugreifen und somit im späteren Experiment auch ASCET-SD: print HEADER " extern uint32 FileNumber;/n"; print HEADER " extern uint32 BranchCounter[];/n"; print HEADER " extern uint32 LimitCounter[];/n"; print HEADER " extern uint32 MethodCounter[];/n"; print HEADER " extern uint32 LoopCounter[];/n"; print HEADER " extern uint32 LoopLimiterCounter[];/n"; print HEADER " extern uint32 UnusedMethodCounter[];/n"; print HEADER " extern uint32 UnusedBranchCounter[];/n"; print HEADER " extern uint32 UnusedLimitCounter[];/n"; print HEADER " extern uint32 OutlinedLimiterCounter[];/n"; print HEADER " extern uint32 CreatedBitfieldCounter[];/n"; print HEADER " extern uint32 InlinedMethodCounter[];/n";

34 5.1 Definition von Schnittstellen Dadurch ist eine Übergabe der Zählerarrays möglich und die in den Quelldateien instrumentierten Zähler können von ASCET-SD ausgewertet werden. Dabei wird ebenso ein struct definiert, in dem verschiedene Informationen über die Datei, wie beispielsweise Name, OID (Objekt-ID) und die Anzahl der Coverage-Zähler, abgelegt werden können: print HEADER " struct FileInfo { real64 CoverageMC; real64 CoverageBC; real64 CoverageLC; real64 CoverageLoC; real64 CoverageLoLiC; real64 CoverageUMC; real64 CoverageUBC; real64 CoverageULC; real64 CoverageOLC; real64 CoverageCBC; real64 CoverageIMC; char Name[64]; char Object[96]; char OID[64]; };"; Dieses Struct wird einmalig in der Header-Datei deklariert, ebenso wie die Arrays der verschiedene Zähler und deren Indizes. Für jede Klasse wird die Anzahl der einzelnen Zähler ebenfalls als Variable deklariert. Die bei der Instrumentierung angelegte Header-Datei wird bei der Kompilierung durch den Linker in die einzelnen Dateien eingebunden. Somit ist es für das Coverage-Modul in ASCET-SD möglich, auf die extern deklarierten Variablen zuzugreifen und diese zu verwenden Speicherung der Coverage-Ergebnisse Nach der Durchführung des Experiments sollen die Ergebnisse der Code Coverage Analyse für die Überarbeitung und Aufbereitung abgespeichert werden. Zu diesem Zwecke gibt es in ASCET-SD die Möglichkeit, Variablenwerte in einer binären Messwertedatei abzulegen. In der Vorbereitungsphase des Experimentes werden die gewünschten Variablen in den so genannten Data- Logger aufgenommen. Der DataLogger ist eine Anwendung unter ASCET-SD, die es dem Benutzer ermöglicht, Werte von Variablen zu speichern. Ist dieser aktiviert, so werden die Werte der enthaltenen Variablen zyklisch in eine Messwertedatei geschrieben.

35 5.1 Definition von Schnittstellen Für die Messung der Code Coverage Ergebnisse müssen die folgenden Variablen mit den DataLogger, siehe Abbildung 7, gespeichert werden: Coverage-Variablen, alle Abdeckungswerte der einzelnen Zählervarianten. Temporäre Messvariablen, in denen die Indizes der nicht abgedeckten Zähler geschrieben werden. Die Coverage-Variablen übergeben den prozentualen Wert der Testabdeckung an den DataLogger. Die temporären Dateivariablen hingegen, geben die Zähler- und Dateiindizes für die Auswertung der Ergebnisse an. Diese Variablen werden nach Beendigung des Experimentes in eine Messwertdatei geschrieben und in einem speziellen Verzeichnis von ASCET-SD abgelegt. Zum Auswerten der Ergebnisse greift Show BranchCounterResults auf diese Datei zurück und analysiert die darin enthaltenen Messergebnisse. Abbildung 7: DataLogger in ASCET-SD zum Abspeichern der Coverage-Ergebnisse

36 5.2 Definition von Dateiformaten Definition von Dateiformaten Um für die Code Coverage Analyse Voreinstellungen durchführen zu können, ist es notwendig, eine externe Initialisierungsdatei zu definieren, durch die der Benutzer den Quellcode des Code Coverage Tools nicht verändern muss, um alle benötigen Einstellungen vorzunehmen. Außerdem ist es vor der Implementierung des Werkzeuges notwendig, die Ausgabedateiformate festzulegen. Dabei wird festgelegt, in welcher Dateiform die Log- und Ergebnisdateien erstellt werden Die Initialisierungsdatei In der externen Initialisierungsdatei coverage.ini können vor Beginn der Code Coverage Analyse mehrere Einstellungen vorgenommen werden. So können unter anderem die Verzeichnisse und Namen der Log-Dateien festgelegt werden. Es kann eingestellt werden, ob die Informationen vom Code-Optimierer CGenCorr berücksichtigt werden sollen und ob dabei jede Zählerart benutzt wird. Dadurch ist es möglich, eine benutzerdefinierte Durchführung der Code Coverage Analyse einzustellen. Außerdem ist es möglich, Informationen zur Fehlersuche während der Analyse auszugeben und diese in einer Datei zu sichern. Um einzelne Dateien von der Instrumentierung auszuschließen, kann eine Liste von Dateinamen angegeben werden. Das ist vor allem sinnvoll, um Systemdateien, die eine Messung der Code Coverage verfälschen würde, nicht zu instrumentieren. Diese Informationen werden sowohl vom Instrumentierer Prepare Branch-Counter als auch von Show BranchCounterResults eingelesen und ausgewertet Log-Dateien Die bei der Instrumentierung und der Ergebnisvisualisierung werden Zwischenergebnisse, Informationen zur Fehlersuche und die Abfolge der Arbeitschritte in Dateien gespeichert. Diese Log-Dateien sollen in einem einheitlichen Format gespeichert werden. Sie müssen übersichtlich, kompatibel und einfach zu realisieren sein. Aus diesen Gründen wurde das Format XML [Bi01] gewählt, da es eine strukturierte Ausgabe ermöglicht und auch die Weiterverarbeitung der Dateien vereinfacht. Dies ist notwendig, da bei der Auswertung der Ergebnisse in Kapitel 6.3 die Log-Dateien nochmals eingelesen und verarbeitet werden müssen.

37 6 Realisierung - Implementierung Realisierung - Implementierung Im Kapitel 4 wird beschrieben, welche Möglichkeiten bestehen, bereits vorhandene Code Coverage Tools für dieses Projekt zu verwenden. Als Ergebnis dieser Untersuchung ging hervor, dass das von Bosch intern entwickelte Tool Prepare BranchCounter für den weiteren Einsatz die besten Voraussetzungen hat. Dabei soll es in dieser Diplomarbeit erweitert, korrigiert und optimiert werden. Nach eingehender Untersuchung wurden die folgenden Mängel am Code Coverage Tool festgestellt: I. Folgende benötigte Funktionalitäten arbeiten mangelhaft und werden im Laufe dieser Diplomarbeit korrigiert: 1. Die Quelldateien werden zeilenweise eingelesen. 2. If/Else-Zweige werden für die Instrumentierung nicht alle erkannt. 3. Variablenbegrenzer, in ASCET-SD Limiter genannt, wurden nur teilweise erkannt und instrumentiert. 4. For- und While-Schleifen werden nicht instrumentiert. 5. Begrenzer der Schleifenvariablen, so genannte LoopLimiter, werden nicht instrumentiert. 6. Switch/Case-Elemente, so genannte Statemachines, werden nicht vollständig instrumentiert. II. Die folgenden Funktionalitäten sind nicht vorhanden und werden neu entwickelt: 1. Erfassung und Auswertung der Informationen von CGenCorr. 2. Visualisierung der Ergebnisse nach Ablauf des Experiments in HTML-Reports. 3. Instrumentierung von C-Modulen aus ASCET-SD. 4. Coverage-Modul in ACSET-SD soll nicht instrumentiert werden. 5. Erstellung von Log-Dateien.

38 6 Realisierung - Implementierung Das Code Coverage Tool Prepare BranchCounter bestand aus zwei Programmteilen. Zum einen aus dem Instrumentierer, der Zähler in die Quelldateien einsetzt und zum anderen aus dem Modul für ASCET-SD, das während des Experiments die Ergebnisse der Code Coverage Analyse darstellt. Für die neue Version des Code Coverage Tools wurden diese beiden Teile übernommen und ein neues Programmteil für die Präsentation der Ergebnisse entwickelt. Somit kann die Einteilung der Code Coverage Analyse in folgende Phasen vorgenommen werden, siehe Abbildung 8. Abbildung 8: Phasen der Code Coverage Analyse Diese Phasen entsprechen in der neuen Version des Code Coverage Tools den Programmteilen. In der ersten Phase werden die von ASCET-SD generierten Quelldateien instrumentiert. Dabei wird von ASCET-SD, vor dem Compileraufruf, das Werkzeug Prepare BranchCounter mit jeder Klasse/Datei des Projektes als Argument aufgerufen. In diesem Schritt werden in den Quellcode die Zähler für Methoden und Zweige eingesetzt. Jeder dieser eingesetzten Zähler wird unter einem bestimmten Index in einem globalen Array abgelegt. Diese globalen Arrays werden in einer Header-Datei deklariert und an ASCET-SD übergeben. Außerdem wird für jede Zählerart ein Startindex für die jeweilige Datei deklariert und in die Initialisierungsdatei der Klasse geschrieben.

39 6 Realisierung - Implementierung Bei der Messung der Coverage-Werte werden diese Arrays vom Coverage- Modul in ASCET-SD vor dem Experiment initialisiert und während des laufenden Experiments inkrementiert. Am Ende des Experiments werden die Ergebnisse in temporäre Variablen geschrieben und dann mittels einer Speicherfunktion für Messwerte, dem DataLogger, in eine Datei geschrieben, siehe Abbildung 9. Diese Messwertedatei wird im Anschluss an das Experiment von Show BranchCounterResults ausgewertet und die Ergebnisse im HTML-Format präsentiert. Show_BranchCounterResults.pl Prepare_BranchCounter.pl C2HTML.pm Import MakeExe Import Finish_BranchCounterLog.pm Show_BranchCounterResults.exe ASCET-SD MakeExe Generier ung Start C-CODE Start Prepare_BranchCounter.exe Instrumentierung Auswertung der Ergebnisse und Überbearbeitung der Log- Dateien Compiler Linker Instrumentierter C-Code ASCET-SD Experiment Auswertung Ohne Coverage Coverage-Modul in ASCET-SD Messung der Coverage-Werte Coverage- Ergebnisse Messwerte speichern DataLogger HTML Präsentation der Coverage-Ergebnisse Abbildung 9: Ablauf der Code Coverage Analyse

40 6.1 Instrumentierung des Quellcodes Aus den zwei PERL-Skripten Show BranchCounterResults.pl und Prepare -BranchCounter.pl wird mit Hilfe des Programms MakeExe eine ausführbare Datei generiert. Ist unter ASCET-SD die Code Coverage Analyse aktiviert, so wird beim Aufbau des Experiments vor dem Compiler der Instrumentierer Prepare BranchCounter.exe mit jeder Quelldatei als Parameter aufgerufen. Erst danach wird der nun instrumentierte Code an den Compiler übergeben und das Experiment wird gestartet. Innerhalb des Experiments werden die Coverage-Werte gemessen und im Anschluss daran in eine Messwertedatei geschrieben. Diese wird nach dem Experiment von Show BranchCounterResults ausgewertet und die Ergebnisse als HTML-Report präsentiert. 6.1 Instrumentierung des Quellcodes Bei der Code-Generierung in ASCET-SD wird vor dem Compiler der Instrumentierer Prepare BranchCounter aufgerufen. Er wird mit jeder von ASCET-SD generierten Klasse als Argument aufgerufen und instrumentiert diese mit den Zählern für die Code Coverage Analyse. Dabei wird die zu analysierende Datei geöffnet, deren Inhalt in einen String eingelesen, die Datei geschlossen und anschließend der String mit dem Dateiinhalt analysiert. Mit dem in PERL einsetzbarem Pattern Matching kann ein gegebener String nach einer bestimmten Zeichenfolge durchsucht werden, um anschließend geeignete Aktionen durchführen zu können. Wird so beispielsweise eine Methode im String gefunden, wird an diese Stelle ein Methodenzähler mit einem eindeutigen Index eingesetzt. Das gleiche Verfahren wird auch für folgende Programmzweige verwendet: If/Else-Abfragen Switch/Case-Elemente Die verschiedenen Zähler, für Methoden, Zweige, Begrenzer und Schleifen werden in getrennten Arrays angelegt und in einer Header-Datei deklariert. Nach der Instrumentierung der Quelldatei wird diese wieder gesichert. Nach Abschluss der Instrumentierung aller Quelldateien werden diese dem Compiler zur weiteren Code-Generierung übergeben.

41 6.1 Instrumentierung des Quellcodes Voraussetzungen Bevor es möglich ist, einen Quellcode mit Zählern zu instrumentieren, ist es notwendig zu wissen, wie dieser Quellcode aussieht. Da es sich im vorliegenden Falle um generierten Code handelt, sind die Variationen eingeschränkt, was bei einer Instrumentierung durchaus hilfreich sein kann. Der Aufbau einer Methode oder einer If/Else-Abfrage ist immer gleich, nur der Namensraum ändert sich. In ASCET-SD ist es allerdings auch möglich, von Hand geschriebenen Code zu integrieren, wodurch dem Programmierer beinahe unendlich viele Möglichkeiten zum Aufbau einer Klasse bleiben. So kann er beispielsweise die öffnende Klammer eines Methodenrumpfes direkt nach den Argumenten oder erst in der nächsten Zeile anbringen. Er kann Leerzeichen dazwischen setzen oder nicht. Im Gegensatz dazu sind bei einem Code-Generator alle Methoden nach dem gleichen Muster aufgebaut. Aus diesen Gründen wurde vor dem Beginn der Implementierung eine Analyse des Quellcodes durchgeführt, wobei die möglichen Formen folgender Code-Bausteine analysiert wurden: Methoden If/Else-Abfragen Begrenzer Schleifen Aufgrund der Ergebnisse dieser Analyse ist eine effektivere Instrumentierung des Quellcodes möglich, d.h. die Abdeckung des Quellcodes mit Zählern wurde erhöht.

42 6.1 Instrumentierung des Quellcodes Implementierung Bei der Instrumentierung der Quelldateien müssen folgende Möglichkeiten von Code-Variationen abgedeckt werden: 1. Unterschiede zwischen handgeschriebenem und generiertem Programmcode. 2. Die unterschiedliche Code-Generierung für die verschiedenen Zielumgebungen. 3. Die ASCET-SD Versionen generieren unterschiedlichen Programmcode: Version 4.0 Version 4.1 Version 4.2 Um diese verschiedenen Code-Varianten zu erkennen, wird die Quelldatei zeilenweise eingelesen und in drei Teile gegliedert: In den Header, den eigentlichen Programmcode (content) und die so genannten L1-Messages, die beispielsweise Informationen zur Initialisierung der Entwicklungsumgebung (Rapid Prototyping System) beinhalten. Es folgt ein Beispiel einer nicht instrumentierten Quelldatei mit Header (rot), Content (schwarz) und L1-Messages (grün): /* BEGIN handwritten header */ /* END handwritten header */ /********** module code for OneBit::Kl **********/ extern uint32 globalresourcecounter; struct A01G2 Obj * A01G2instance = NULL; /*public*/ uint8 A01G2 Read (uint8 Variable, uint8 Position) { /* Read 0 */ return ((Variable >>Position ) & 1); } /*L1 messages for instance methods*/ uint8 * L1 A01G2 Read (ASDObject *self, uint8 *data) { uint8 Variable; uint8 Position; uint8 return; asdsimprecall (data); removescalar (data, (uint8 *) &Position, 1); /*create global instance and initialize it*/ /*create global instance and initialize it*/ A01G2 Class A01G2 ClassObj = {{1,& A01G2 ClassHeader}}; void initclass A01G2 ( A01G2 Class *class) {} }

43 6.1 Instrumentierung des Quellcodes Der Header, im Beispiel rot dargestellt, und die L1-Messages, im Beispiel grün dargestellt, werden bei normalen Klassendateien nicht instrumentiert. Sie liefern aber Informationen über die Art der Quelldatei, bzw. um was für eine Quelldatei es sich handelt. Es gibt drei verschieden Typen von Quelldateien: Klassen, Initialisierungsund System-/Coverage-Dateien, siehe Abbildung 10. Handelt es sich bei der zu instrumentierenden Datei um eine Klassendatei, so wird der Header und die L1-Messages unverändert übernommen und der Programmcode instrumentiert. Bei einer Klasseninitialisierungsdatei gibt es keinen Programmcode und auch keine L1-Messages. Der Code wird nicht wie üblicherweise mit Zählern instrumentiert, sondern die Initialisierung der Zähler für diese Klasse werden eingefügt. Eine Datei des Coverage-Moduls oder eine Datei des Prototyping Systems, die nicht zur eigentlichen Applikation gehört, wird nicht initialisiert, da es sonst zu einer Verfälschung der Coverage-Werte kommen würde. Einlesen der Quelldatei Bestimmung der Dateiart Klassen-Datei Initialisierungs-Datei System-/Coverage-Datei Unterteilung des Quellcodes Initialisierung der Zählervariablen Keine Instrumentierung notwendig Analyse des Quellcodes Einfügen der Coverage-Zähler Abbildung 10: Ablauf der Instrumentierung

44 6.1 Instrumentierung des Quellcodes In der alten Version des Code Coverage Tools wurde die jeweilige Quelldatei zeilenweise eingelesen und auch der Code zeilenweise analysiert. Bei Programmcode, der nur einzeilige Befehle hat, funktionierte diese Variante einwandfrei, aber in der ABS-Reglersoftware gibt es Methoden oder Programmbefehle, die über die Länge einer Zeile, bzw. eines Zeilenumbruchs hinausreichen. War dies der Fall, so erhielt der Instrumentierer als Eingabe nicht den ganzen Befehl auf einmal. Dadurch wurden Methoden und Zweige als solche nicht erkannt und deshalb nicht instrumentiert. Ebenfalls kam es vor, dass Codezeilen unterbrochen wurden und Zähler an die falsche Position im Code gesetzt wurden. Dabei entstand eine Verletzung der Modellierungsrichtlinien für ANSI-C und der Compiler konnte den Quellcode danach nicht mehr fehlerfrei übersetzen. Um dieses Problem zu lösen, wird der eigentliche Programmcode einer Klasse auf eine andere Art analysiert, wobei der gesamte Quellcode wird dabei aber immer noch zeilenweise eingelesen. Der Header jeder Quelldatei mit Einfügungen und Kommentaren wird zeilenweise eingelesen und unverändert in einen String ($head) geschrieben, da eine Instrumentierung hier nicht notwendig ist. Wird allerdings die erste Methode erkannt, so wird der nachfolgenden Code bis zu den L1-Messages ohne Modifikation ebenfalls zeilenweise in einen String ($content) geschrieben. Abschließend werden die L1-Messages ebenfalls in einem String ($l1messages) gespeichert. Damit ist das zeilenweise Einlesen beendet und die Quelldatei kann vorerst wieder geschlossen werden. Bei einer System- oder einer Quelldatei des Coverage-Moduls werden die drei Teile einfach wieder zusammengesetzt, mit einem Kommentar und einem Zeitstempel versehen und die alte Quelldatei mit den neuen Daten überschrieben. Handelt es sich bei der Quelldatei um eine Initialisierungsdatei sind die letzten beiden Teile leer. Im ersten Teil, dem Header, werden der Kommentar und der Zeitstempel, sowie Initialisierungen für die Klasse eingesetzt. Dabei erhält jede Klasse eine eindeutige Dateinummer. Außerdem werden verschiedene Daten in ein Array geschrieben, welches später von ASCET-SD ausgewertet werden kann, so beispielsweise der Dateiname, die Objekt-ID und die Anzahl der jeweiligen Zähler in der dazugehörigen Klassendatei. Die dazugehörigen Deklarationen der Zählervariablen werden in einer Header-Datei vorgenommen.

45 6.1 Instrumentierung des Quellcodes Ein Beispiel für die Initialisierung des Arrays in den Klasseninitialisierungsdateien zeigt der folgende PERL-Code: $$head.= $1. " /*begin counter for coverage*//n "; $$head.= $1. " FileNumber = $fileindex;/n "; $$head.= $1. " FileCounter = FileNumber + 1;/n "; $$head.= $1. " FileStartIdx = I MC WOInst Index;/n "; $$head.= $1. " I MC WOInst Index += $OID Obj/ MC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].Instances++;/n "; $$head.= $1. " Files[FileNumber].FileStartIdx = FileStartIdx;/n "; $$head.= $1. " strcpy(files[filenumber].name, $$currentfile);/n "; $$head.= $1. " strcpy(files[filenumber].oid, $OID Obj);/n "; $$head.= $1. " Files[FileNumber].MCs = $OID Obj/ MC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].BCs = $OID Obj/ BC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].LCs = $OID Obj/ LC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].LoCs = $OID Obj/ LoC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].UMCs = $OID Obj/ UMC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].UBCs = $OID Obj/ UBC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].ULCs = $OID Obj/ ULC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].OLCs = $OID Obj/ OLC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].CBCs = $OID Obj/ CBC BRANCHES;/n "; $$head.= $1. " Files[FileNumber].IMCs = $OID Obj/ IMC BRANCHES;/n "; $$head.= $1. " I MultipleInstance++; /* Statistics *//n "; $$head.= $1. " if ( Files[FileNumber].Instances == 1 )/n "; $$head.= $1. " {/n "; $$head.= $1. " self->mc startindex = I MCcurIndex; /* MC *//n "; $$head.= $1. " { uint32 i; "; $$head.= " for ( i=i MCcurIndex;i<I MCcurIndex+$OID Obj/ MC BRANCHES;i++ ) "; $$head.= $1. " { LTB MethodnameIdx[i] = FileNumber; }; };/n "; $$head.= $1. " I MCcurIndex += $OID Obj/ MC BRANCHES; /* MC *//n "; $$head.= $1. " asdwriteuserdebug( Class $RealName ($OID Obj) "; $$head.= " with startindex %d and %d branches ". $1. " (MC)/n "; $$head.= ", self->mc startindex, $OID Obj/ MC BRANCHES );}/n "; Der obere Teil der Initialisierung, rot markiert, wird für jede Klasse nur einmal vorgenommen, wobei der untere Teil, grün markiert, für jede Zählerart vorgenommen wird. Dadurch werden für jede Klasse die Anfangszähler gesetzt. Im Array LTB MethodnameIdx werden die eingefügten Zähler dem Klassenindex zugewiesen. Dadurch ist es bei der Analyse der Zähler, wie in Kapitel 6.2 beschrieben, möglich, für jede Klasse nicht alle Methoden überprüfen zu müssen, sondern nur die Methoden, die auch zu dieser Klasse gehören. Das Problem bei der Initialisierung besteht darin, dass auch Instanzen der eigentlichen Klasse gebildet werden können. Dabei wird die Initialisierungsdatei von allen Instanzen benutzt und somit für jede Instanz die Anzahl der Zähler erhöht, obwohl diese im Projekt nur einmal vorkommen. Mit Hilfe der If-Abfrage wird die Initialisierung der eingesetzten Zähler nur einmalig vorgenommen.

46 6.1 Instrumentierung des Quellcodes Wenn es sich bei der zu instrumentierenden Quelldatei um eine Klasse handelt, werden der erste und der letzte Teil, also der Header und die L1-Messages, nahezu unverändert übernommen. Dabei werden lediglich ein Kommentar und ein Zeitstempel in den Header eingefügt. Der eigentliche Programmcode befindet sich in einem String ($content). Um auch mehrzeilige Befehle oder Argumentenlisten erkennen zu können, wird dieser Teil nicht mehr zeilenweise, sondern blockweise analysiert. So wird im String nach drei verschiedenen Formen in der folgenden Reihenfolge gesucht: 1. Expressions, alle Ausdrücke zwischen runden Klammern. 2. Structs, Ausdrücke zwischen geschweiften Klammern, die aber innerhalb einer Methode stehen. Nicht zu verwechseln mit Structs in C-Code! 3. Bodies, alle anderen Ausdrücke in geschweiften Klammern, also die Methodenrümpfe. Es folgt ein Beispiel für die Suche nach Expressions im String content (Dereferenzierung des Strings content durch $$): # scan for EXPRESSIONS, search content like (...) # and substitute them by key while ( defined $$content && $$content = //(/ ) { my $expr; $expr key = MyExpr. align cnt ($expr cnt, $align ). ; # get key $expr cnt++; if ( $$content = s/(/([^()]*/))/$expr key/s ) { } $expr = $1; } else { die hard (" expression not packed completely... "); } $$structs{$expr key} = $expr; # store expr in hash Wird durch diesen Algorithmus ein Ausdruck in runden Klammern im String content gefunden, so wird dieser Ausdruck (expr) durch einen eindeutigen Schlüssel ersetzt und unter diesem Schlüssel in einer dafür vorgesehenen Hashtabelle abgelegt. Dadurch werden alle Ausdrücke, die in runden Klammern stehen, durch ihre eindeutigen Schlüssel im String ersetzt, um eine doppelte Analyse der Ausdrücke zu vermeiden.

47 6.1 Instrumentierung des Quellcodes Danach werden, durch eine ähnliche While-Schleife wie oben, die Ausdrücke in geschweiften Klammern (structs), die aber nicht ein Methodenrumpf sind, durch ihre Schlüssel ersetzt und ebenfalls in einer Hashtabelle abgelegt. Als Structs werden bei der Instrumentierung alle Blöcke innerhalb geschweifter Klammern erkannt, die keine Methodenrümpfe sind. Sie sind mit so genannten Structs in C-Code nicht zu verwechseln. Am Schluss dieser Analyse sollten nur noch Ausdrücke in geschweiften Klammern übrig sein, die einen Methodenrumpf darstellen. Wird ein Ausdruck als solcher erkannt, so wird dieser mit einem Methodenzähler versehen. Anschließend wird dieser Ausdruck ebenso wie alle anderen in einer dafür vorgesehenen Hashtabelle abgelegt. Im Anschluss an die Analyse des Programmcodes muss der Content-String leer sein. Dadurch kann eine Überprüfung vorgenommen werden, ob alle Ausdrücke richtig gefunden wurden. Ist dieser Vorgang erfolgreich beendet worden, so werden nun im nachfolgendem Schritt die einzelnen Ausdrücke auf ihren Inhalt hin untersucht. Diese geschieht rekursiv beim Zusammensetzen der neuen Dateistruktur. So wird zuerst der bereits mit einem Methodenzähler instrumentierte Methodenrumpf aus der Hashtabelle wieder aufgelöst. Die darin enthaltenen Ausdrücke werden dabei ebenfalls analysiert. Diese werden bei ihrem Aufruf auf Zweige, Begrenzer und Schleifen hin untersucht und dabei gegebenenfalls Zähler eingesetzt. Befindet sich beispielsweise in einem Struct nochmals ein Struct, so wird dieser Vorgang wiederholt und anschließend das Ganze wieder rekursiv zusammengesetzt. Der gleiche Vorgang wird ebenfalls mit den Expressions durchgeführt. So wird erreicht, dass sowohl mehrzeilige Befehle als auch ineinander verschachtelte Befehle erkannt und korrekt instrumentiert werden.

48 6.1 Instrumentierung des Quellcodes Anbei ein Beispiel für eine instrumentierte Quelldatei, wobei der Header rot, der eigentliche Programmcode schwarz und die L1-Messages grün dargestellt ist: /* instrumented by $Id:BranchAndPathAnalysis/source/Prepare BranchCounter */ /* (Build:172; Production) Tue Aug 03 09:15: ko82abt$ */ /* at Wed Aug 4 09:06: */ #include " temp.h " /* BEGIN handwritten header */ /* END handwritten header */ /********** module code for OneBit::Kl **********/ extern uint32 globalresourcecounter; struct A01G2 Obj * A01G2instance = NULL; /*public*/ uint8 A01G2 Read (uint8 Variable, uint8 Position) { /* instrumentation start, method, index: 0 */ { MethodCounter [ A01G2instance->MC startindex+0]++; } /* instrumentation end, method, index: 0 */ } /* Read 0 */ /* Read 1 */ /* Read 2 */ /* Read 3 */ // Extrahiert 1 bit an Position aus Variable /* Read 4 */ return ((Variable >>Position ) & 1); /*L1 messages for instance methods*/ uint8 * L1 A01G2 Read (ASDObject *self, uint8 *data) { uint8 Variable; uint8 Position; uint8 return; asdsimprecall (data); removescalar (data, (uint8 *) &Position, 1); /*create global instance and initialize it*/ /*create global instance and initialize it*/ A01G2 Class A01G2 ClassObj = {{1,& A01G2 ClassHeader}}; void initclass A01G2 ( A01G2 Class *class) {} } Um die Erkennung von Zweigen, Begrenzern und Schleifen gegenüber der alten Version von Prepare BranchCounter zu erhöhen, werden in der neuen Version die Suchkriterien für diese Fälle erweitert. So wurden beispielsweise in der alten Version If/Else-Fälle nur dann erkannt, wenn sie einem bestimmten Muster entsprachen. Handelt es sich aber bei der zu instrumentierenden Klasse um ein von Hand codiertes C-Modul, so gibt es beispielsweise viele verschiedene Möglichkeiten ein If-Fall zu programmieren: if(signal < -50){ if(signal < -50) { if( signal < -50 ) {

49 6.1 Instrumentierung des Quellcodes Um nun so viele Fälle wie möglich zu erkennen, wurde die Suchfunktion nach If-Fällen erweitert. Es wurden alle Möglichkeiten der verschiedenen Fälle in Betracht gezogen, um eine möglichst vollständige Erkennung aller Fälle zu bekommen. Wie in den obigen Fallbeispielen können nur durch unterschiedliches Setzen eines Leerzeichens viele verschiedene Arten eine If-Abfrage erstellt werden. Somit müssen bei der Suche nach diesen Fällen möglichst viele Möglichkeiten in Betracht gezogen werden. Anbei ein Beispiel für die in PERL implementierte Suchmaske nach If-Fällen: $item = //n(.*)if/s*( MyExpr /d+ )/s*.* *( MyStruct /d+ )/s+/ Hierbei wird nach If-Fällen gesucht, die in ihrer Ausführung sehr unterschiedlich ausfallen können. Es werden If-Fälle gefunden, bei denen sich optional vor oder nach dem if ein oder mehrere Leerzeichen oder Steuerzeichen befinden ( * steht für beliebig viele Vorkommen,. steht für beliebige Zeichen und s für beliebige Steuerzeichen wie Leerzeichen, Tabulator oder Zeilenumbruch). Danach folgt auf jeden Fall ein Ausdruck (Expression) in runden Klammern, gefolgt von beliebig vielen Steuerzeichen, beliebig vielen anderen Zeichen und beliebig vielen Leerzeichen. Anschließend folgt eine Struktur (Struct), also ein Ausdruck in geschweiften Klammern. Mit dieser Art der Abfrage ist es möglich, eine sehr hohe Abdeckung von If/Else-Fällen zu erreichen, einschließlich in sich geschachtelter Fälle. Bei der Instrumentierung eines Methodenrumpfes muss dieser daraufhin untersucht werden, ob er in der optimierten Softwareversion von CGenCorr noch enthalten ist. Um die gewünschten Informationen zu erhalten, wird die Überagabedatei von CGenCorr durch den Instrumentierer eingelesen und die Informationen in Arrays abgelegt. Dabei werden der Klassenname und der Methodenname gespeichert, um später bei der Instrumentierung einer Methode überprüfen zu können, ob diese durch den Code-Optimierer entfernt wurde oder nicht. Wurde die Methode nicht von CGenCorr entfernt, so werden ganz normale Zähler für Methoden, Zweige, Begrenzer und Schleifen eingefügt. Ist die vorliegende Methode durch CGenCorr entfernt worden, so handelt es sich dabei um eine unusedmethod, also um eine Methode, die nicht mehr benutzt werden sollte. Deswegen muss diese Methode und alles was in dieser Methode an Zweigen, Begrenzern und Schleifen enthalten ist, speziell instrumentiert werden. Für diesen Fall werden spezielle Zählerarten definiert: UnusedMethods UnusedBranches UnusedLimiters

50 6.1 Instrumentierung des Quellcodes Diese Zähler müssen ebenfalls bei der Auswertung der Ergebnisse gesondert behandelt werden, da diese Zähler Null bleiben sollen. Würde einer dieser Zähler während des Experiments inkrementiert, so würde das bedeuten, dass beispielsweise eine Methode aufgerufen wurde, die es in der optimierten Steuergerätesoftware nicht mehr gibt. Das könnte zu erheblichen Problemen und Qualitätsverlusten innerhalb der ABS-Reglersoftware führen. Es folgt nun ein Beispiel für die Unterscheidung bei der Instrumentierung in benutzte und unbenutzte Else-Zweige: if ( $insideunusedmethod ) { $tmp = ; print " " x $xmlindent2. " <CGENCORR unusedelse>/n "; print " " x $xmlindent3. " <UBC index>$ubcindex". " - "; print " $currentfile</ubc index>/n "; print " " x $xmlindent3. " <matchedifcond>$xmlmatchedifcond "; print " </matchedifcond>/n "; print " " x $xmlindent2. " </CGENCORR unusedelse>/n "; $tmp.= " /n "; $tmp.= $elsindentp. " /* instrumentation start, unused branch "; $tmp.= ", index: $UBCindex *//n "; $tmp.= $elsindentp. " {/n "; $tmp.= $elsindentp. " UnusedBranchCounter "; $tmp.= " [$objname->ubc startindex+$ubcindex]++;/n "; $tmp.= $elsindentp. " }/n "; $tmp.= $elsindentp. " /* instrumentation end, unused branch "; $tmp.= ", index: $UBCindex *//n "; $$structs{$structkey} = s//{//{/n$tmp/; $item = s/else//; # del counted else from input $UBCindex++; $FoundUnusedBranches++; } else { print " " x $xmlindent2. " <else>/n "; print " " x $xmlindent3. " <BC index>$bcindex". " - "; print " $currentfile". " </BC index>/n "; print " " x $xmlindent3. " <matchedifcond>$xmlmatchedifcond "; print " </matchedifcond>/n "; print " " x $xmlindent2. " </else>/n "; $tmp.= $elsindentp. " /* instrumentation start, branch "; $tmp.= ", index: $BCindex *//n "; $tmp.= $elsindentp. " {/n "; $tmp.= $elsindentp. " BranchCounter "; $tmp.= " [$objname->bc startindex+$bcindex]++;/n "; $tmp.= $elsindentp. " }/n "; $tmp.= $elsindentp. " /* instrumentation end, branch "; $tmp.= ", index: $BCindex */ "; } $$structs{$structkey} = s//{//{/n$tmp/; $item = s/else//; # del counted else from input $BCindex++; $FoundBranches++;

51 6.1 Instrumentierung des Quellcodes In dem obigen Beispiel ist die Standardausgabe in eine Log-Datei umgeleitet worden. Somit wird jeder eingesetzte Zähler durch den print-befehl in einer Log- Datei erfasst. Der String tmp wird abschließend in die Hashtabelle structs an einer bestimmten Stelle structkey eingefügt und der String else aus dem zu untersuchendem Teilstring entfernt, um ein nochmaliges Einfügen eines Zählers für diesen Else-Fall zu verhindern. Durch die If-/Else-Abfrage wird geprüft, ob die Methode, in der sich dieser Else-Fall befindet entfernt wurde, rot dargestellter If-Zweig, oder nicht, grün dargestellter Else-Zweig. Der Wert insideunusedmethods wird vorher eventuell in einer For-Schleife gesetzt, in der die aktuelle Methode mit den entfernten Methoden von CGenCorr verglichen wird.

52 6.2 Analyse der Coverage-Werte Analyse der Coverage-Werte Für ein Experiment in ASCET-SD, siehe Abbildung 11, sollen die eingefügten Zähler initialisiert, während des Experiments gemessen und nach Abschluss der Testabläufe die Ergebnisse gesichert werden. Zu diesem Zwecke wird das bereits intern entwickelte ESDL-Modul mit dem Namen Coverage, welches die eingesetzten Zähler zur Laufzeit anzeigen und die Ergebnisse für eine spätere Auswertung speichern kann, erweitert und angepasst. Abbildung 11: Das Experiment in ASCET-SD Voraussetzungen Um die Zähler initialisieren zu können, müssen diese durch den Instrumentierer gesetzt werden. ASCET-SD ruft vor dem Compiler den Instrumentierer Prepare BranchCounter mit jeder Klasse als Argument auf, um diese instrumentieren zu lassen. Außer dem Einsetzen der Zähler in den Quellcode werden die eingesetzten Variablen und Arrays in einer Header-Datei deklariert. Das Coverage- Modul ist dadurch in der Lage, diese Variablen und Arrays während des laufenden Experiments zu benutzen.

53 6.2 Analyse der Coverage-Werte Implementierung Um die beiden Aufgaben des Coverage-Moduls für ASCET-SD erfüllen zu können, müssen in einem Teil die aktuellen Zähler in den Quelldateien ausgewertet und in einem anderen Teil diese Zähler für die spätere Analyse aufbereitet werden. Diese Gliederung spiegelt sich auch in der Anzahl der Prozesse des Coverage-Moduls wieder: 1. init() 2. checkcoverage() 3. showresults() Diese Prozesse werden in die hardwarespezifischen Tasks der jeweiligen Zielhardware eingegliedert, bzw. aus denen heraus gestartet. So wird der Prozess init() in den gleichnamigen Task des Betriebssystems der Zielhardware eingebunden und somit vor dem Beginn des Experiments ausgeführt. Dabei werden die für die Auswertung benötigten temporären Variablen initialisiert. Außerdem wird in diesem Prozess den Variablen file loop index, loop index, start idx und coverage progress der Wert Null zugewiesen. Diese Variablen werden benötigt, um bei der später stattfindenden Aufbereitung der Coverage- Werte eine Messung durch den DataLogger vornehmen zu können. Der Data- Logger ist ein Werkzeug innerhalb von ASCET-SD, mit dem es möglich ist, Variablen in eine Messwertedatei abzuspeichern. Im Prozess init() wird außerdem für jede Zählerart eine boolsche Variable mit true initialisiert. Diese sind notwendig, um die Analyse der Werte pro Zählerart nur einmal durchzuführen und um den nächsten Analyseschritt zu starten. Ein Kommentar in der obersten Zeile jedes Prozesses dient dem Instrumentierer zur Erkennung des Coverage-Moduls und somit zur Nichtinstrumentierung dieser Klassen, siehe Beispielcode auf der nächsten Seite. Im zweiten Prozess des Coverage-Moduls, checkcoverage(), wird die eigentliche Messung der Code Coverage durchgeführt. Zum besseren Verständnis beziehen sich die nachfolgenden Erklärungen auf das Beispiel der Methodenzähler. So werden Zu Beginn eines Experiments alle Methodenzähler mit Null initialisiert. Die Anzahl aller Methodenzähler wird zu Beginn des Experiments in der Variable ZeroMC festgehalten.

54 6.2 Analyse der Coverage-Werte Im Gegensatz dazu gibt es eine Variable notzeromc, siehe Abbildung 12, in der die Anzahl aller Methodenzähler enthalten ist, die später im laufenden Experiment inkrementiert werden. Wird eine Methode benutzt, so wird die Variable ZeroMC um Eins erniedrigt und die Variable notzeromc um Eins erhöht. Somit ist die Summe beider Variablen gleich der Gesamtsumme aller Methoden, die bereits in I MCcurIndex festgehalten ist. Abbildung 12: Method-Counter im ASCET-SD Experiment Um nun während eines laufenden Experiments die gewünschten Messungen durchzuführen, gibt es für jede Zählerart eine For-Schleife, die über die Gesamtanzahl der Methoden läuft und die jeweiligen Zählerstände überprüft. Dadurch verändert sich das Verhältnis von ZeroMC zu notzeromc und somit die Abdeckung der Methoden im laufendem Experiment. Am nachfolgenden Beispiel wird die Messung der Coverage-Werte für Methodenzähler im Prozess checkcoverage() dargestellt: //*************** method counter array *************** notzeromc = 0; ZeroMC = 0; for( i=0; i < I MCcurIndex; i++ ) { if( MethodCounter[i] > 0 ) notzeromc++; } if ( I MCcurIndex > 0 ) { ZeroMC = I MCcurIndex - notzeromc; CoverageMC = notzeromc / I MCcurIndex; } Dieser Programmcode ist in diesem Prozess für jede Zählerart, also auch für Zweige, Begrenzer, usw. enthalten. Ebenfalls in diesem Prozess enthalten ist die Berechnung der Gesamtabdeckung. Dabei wird ein Mittel über alle Coverage- Werte berechnet. Die einzelnen Coverage-Werte (CoverageMC, CoverageBC, usw.) und das Mittel dieser Werte (Coverage) bilden die Grundlage für die Messung der Abdeckung zur Laufzeit eines Experiments. Der Prozess checkcoverage() wird in einen Task des Betriebssystems der Zielhardware eingebunden.

55 6.2 Analyse der Coverage-Werte In der Zielhardware gibt es verschiedene Tasks des Betriebssystems, in die funktionale Prozesse der Software eingebunden werden können. Durch dieses Einbinden werden die gewünschten Softwareprozesse somit im 5-, 10- oder 20- Millisekundentakt gestartet. Dadurch wird eine sich ständig aktualisierende Messung erzeugt und dem Benutzer zur Laufzeit immer die neusten Werte angezeigt. Im dritten Prozess des Coverage-Moduls, showresults(), werden die Ergebnisse der Code Coverage Analyse für die Präsentation zusammengestellt und ausgewertet. Dabei entstanden einige Probleme, da es in ASCET-SD nicht ohne Interaktion möglich ist, mehrere Variablenwerte abzuspeichern. Es gibt verschiedene gepufferte Ausgabefenster, auf deren Daten entweder nicht zugreifbar ist, oder durch die begrenzte Anzahl der Ausgabewerte eine komplette Übergabe der Coverage-Werte nicht möglich ist. Die einzige Möglichkeit besteht darin, die benötigten Werte einzeln in temporäre Variablen zu schreiben und diese dann in einer Messwertedatei abzuspeichern. Durch den DataLogger, ein Messinstrument von ASCET-SD, ist es dem Benutzer möglich, einzelne Variablen in einer Messwertedatei zu sichern. Dabei ist die Anzahl der Variablen allerdings auf 1000 begrenzt.

56 6.2 Analyse der Coverage-Werte In diesem Falle der Datensicherung kann aber nicht auf eine Variablenänderung innerhalb einer Schleife zugegriffen werden, d.h. die Abfrage und Ausgabe der Werte innerhalb einer For-Schleife werden vom DataLogger nicht erfasst. Deshalb wird in diesem Prozess für jede Zählerart eine Abfolge von If/Else-Abfragen benutzt. Da dieser Prozess wie auch der checkcoverage-prozess in einem sich ständig wiederholendem Betriebssystemtask eingebunden ist, entsteht dadurch eine zyklische Abfolge, siehe Abbildung 13, ähnlich der Wirkung einer For-Schleife. Dabei durchläuft ein Zähler, loop index, die Anzahl der zu messenden Zählerart und dabei wird geprüft, ob der aktuelle Array-Eintrag, also der aktuelle Zählerindex, an dieser Stelle Null ist. Initialisierung: actmethods = 0 file_loop_index = 0 loop_index = 0 Abfrage (akt. Zähler = Null && Zähler in dieser Klasse): MethodCounter[loop_index]== 0 && LTB_Methodname_idx[loop_index] == file_loop_index NEIN JA Abfrage (noch mehr Methoden in dieser Klasse): loop_index < I_MCcurIndex-1 && loop_index < (start_idx + actmethods) Ausgabe an DataLogger: tempafileindex = file_loop_index tempdfilemindex = loop_index NEIN JA Abfrage (noch Klassen zu prüfen): file_loop_index < FileCounter Nächste Methode: loop_index++ Neuer Zyklus NEIN JA Reinitialisierung: tempafileindex = -1 tempdfilemindex = -1 countmc = false file_loop_index = 0 loop_index = 0 start_idx = 0 coverage_progress +=... Nächste Klasse: file_loop_index++ loop_index = 0 actmethods = 0 Neuen Startindex und Anzahl der Methoden dieser Klasse bestimmen: for (i=0; i < I_MCcurIndex; i++) {... } Neuer Zyklus Ende Methodenzähler Abbildung 13: Darstellung der Coverage-Messung im Prozess showresults()

57 6.2 Analyse der Coverage-Werte Außerdem muss der aktuelle Array-Eintrag, also die Methode mit dem Index loop index, mit dem Eintrag des Arrays LTB MethodnameIdx an der gleichen Stelle verglichen werden. An dieser Stelle im Array steht der Index, ob die Methode zu der aktuellen Klasse gehört. Dadurch wird ein Bezug der Methode zur Datei hergestellt und nur wenn die aktuelle Methode zur aktuellen Datei passt wird eine Ausgabe erzeugt. Die Messung der Messwerte durch den DataLogger erfolgt über die gesamte Laufzeit des Experiments. Somit kann der Benutzer auch andere Werte des Experiments messen. In Abhängigkeit der boolschen Variable, showresults(), siehe Abbildung 14, die zu jedem beliebigen Zeitpunkt des Experiments gesetzt werden kann, ist es dem Benutzer allerdings möglich, die Messung der Coverage- Ergebnisse von Hand zu starten. Der Fortlauf der Messung wird in einem Fortschrittsbalken, der dem Wert coverage progress entspricht, angezeigt. Um die vom DataLogger schon vorher gemessenen, unwichtigen Coverage-Werte von den jetzt gemessenen Werte zu filtern, werden die temporären Variablen, hier tempafileindex und tempdfilemindex, anfangs mit dem Wert -1 initialisiert und nach Abschluss der Messung wieder zurückgesetzt. Dadurch wird eine einfachere Auswertung der Daten nach Abschluss des Experiments erreicht. Abbildung 14: Variable showresults, zum Starten der Speicherung Außerdem wird die boolsche Variable countmc nach Abschluss der Messung der Methodenzähler auf false gesetzt, um eine doppelte Messung der Methoden und eine sich überschneidende Messung mit einer anderen Zählerart zu verhindern. Diese Überschneidung darf nicht sein, da in allen Zählerarten zum Teil die gleichen temporären Variablen eingesetzt werden.

58 6.2 Analyse der Coverage-Werte Es folgt ein Beispiel für den Prozess showresults() anhand der Zählerart Methodenzähler: //*************** method counter *************** if ( countmc &&!countlc ) { if ( ZeroMC!= 0 ) { if ( MethodCounter[loop index] == 0 && LTB MethodnameIdx[loop index] == file loop index ) { tmp = loop index - start idx; tempafileindex = file loop index; tempdfilemindex = tmp; } if ( (loop index < (I MCcurIndex - 1)) && (loop index < (start idx + actmethods - 1)) ) { loop index++; } else { if (file loop index < FileCounter - 1) { file loop index++; loop index = 0; actmethods = 0; coverage progress += 1/coverage progress max; for ( i=0; i < I MCcurIndex;i++ ) { if ( LTB MethodnameIdx[i] == file loop index ) { if ( actmethods == 0 ) { start idx = i; loop index = start idx; } actmethods++; } if ( (actmethods!= 0) && (LTB MethodnameIdx[i]!= file loop index) ) { i = I MCcurIndex; } } // end for if ( actmethods == 0 ) { loop index = I MCcurIndex - 1; } } else { tempafileindex = -1; tempdfilemindex = -1; countmc = false; file loop index = 0; loop index = 0; start idx = 0; } } } // end of if( ZeroMC!= 0) else { tempafileindex = -1; tempdfilemindex = -1; countmc = false; file loop index = 0; loop index = 0; start idx = 0; coverage progress += FileCounter/coverage progress max; } } // end of if (countmc)

59 6.2 Analyse der Coverage-Werte Auf diese Weise ist es durch den DataLogger möglich, die einzelnen temporären Messwerte zu speichern. Ist die Methodenzählart aktiv, d. h. der boolsche Wert countmc ist true, so werden nacheinander alle Klassen durchlaufen, wobei diese in der Variable file loop index gezählt werden. Im Array LTB MethodnameIdx[] wird der Bezug zwischen einer Methode und der dazugehörigen Klasse hergestellt. Um die Dauer der Messung so kurz wie möglich zu halten, sollen bei einer Klasse nicht alle Methodenzähler des Projektes geprüft werden, sondern nur die Methoden, die sich auch in dieser Klasse befinden. Um die Suche nur auf die Methoden zu begrenzen, die zu dieser Klasse gehören, wurde eine For-Schleife entwickelt. Diese läuft für jede Klasse einmalig über alle Methoden des Projektes. Somit wird bei jeder Klasse die erste Methode in dem Array gesucht, die zu dieser Klasse gehört. Ist dieser Index gefunden, so ist dies gleichzeitig der Methoden-Startindex dieser Klasse. Danach wird der Zähler actmethods so lange inkrementiert, bis im Array eine Methode nicht zu dieser Klasse passt und die Schleife dadurch abgebrochen wird: if( (actmethods!=0) && (LTB MethodnameIdx[i]!= file loop index) ) In der Variable actmethods befindet sich nun die Anzahl der Methoden, die sich in dieser Klasse befinden. Werden für diese Klasse jedoch keine Methoden gefunden, so wird der globale Schleifenindex loop index auf den höchsten Wert gesetzt, um die Suche in dieser Klasse beim nächsten Aufruf dieses Prozesses abzubrechen. Wurde die Anzahl der Methoden festgestellt und auch der Schleifenindex auf den Startindex gesetzt, so wird in den nächsten Prozessaufrufen jeder Methodenzähler dieser Klasse auf seinen Wert hin überprüft. Ist dieser Wert Null, wurde also die Methode nicht benutzt, so wird diese als nicht abgedeckt bezeichnet und der Dateiindex und der Methodenindex den temporären Variablen zugeordnet und dadurch vom DataLogger zur Speicherung erfasst: tempafileindex = file loop index; tempdfilemindex = tmp; Somit werden durch diesen Algorithmus nacheinander die Methodenzähler aller Klassen auf ihren Wert hin untersucht und eventuell, durch die Zuweisung zu den temporären Variablen, gespeichert. Sind alle Klassen überprüft, so werden die temporären Variablen, der Schleifen-, Klassen- und Startindex zurückgesetzt. Außerdem wird der Zähler coverage progress um den anteiligen Wert der Gesamtabdeckung erhöht. Dadurch ist es dem Benutzer möglich, während dem Ablauf der Messung den Fortschritt zu beobachten und bei Beendigung der Messungen das Experiment zu schließen. Ist die Erfassung der Methoden beendet, so wird auch die boolsche Variable countmc auf false gesetzt, um eine doppelte Erfassung der Methoden zu verhindern. Auf diese Weise werden nacheinander alle Zählerarten durchlaufen und die Ergebnisse der Code Coverage Analyse dadurch abgespeichert.

60 6.3 Präsentation der Ergebnisse Präsentation der Ergebnisse Um eine spätere Analyse der Coverage-Ergebnisse durchführen zu können, müssen diese nach Ablauf des Experiments aufbereitet werden. Die Ergebnisse der Code Coverage Analyse sollen dem Benutzer übersichtlich dargestellt werden und es soll möglich sein, die betreffenden Code-Stellen durch Interaktionen möglichst einfach zu finden Voraussetzungen Während der Instrumentierung der Quelldateien durch Prepare BranchCounter wurden die folgenden Log-Dateien erzeugt: coverage filecounter.xml coverage log.xml coverage xchange.xml Diese Dateien werden zur Analyse der Ergebnisse benötigt. Außerdem kommt für die Auswertung noch die gespeicherte Messwertedatei von ASCET-SD hinzu. Aus den darin enthaltenen Daten werden durch das Werkzeug Show BranchCounter-Results die Ergebnisse zusammengefügt und in einem HTML-Report übersichtlich dargestellt Implementierung Bei der Verarbeitung der Coverage-Ergebnisse ist darauf zu achten, die Ausgabe der Messwerte von ASCET-SD den richtigen Zählern in den richtigen Dateien zuzuordnen. Da es mit ASCET-SD nicht möglich war, die benötigten Werte in einem String abzuspeichern, wird der Bezug vom Zähler zum Dateinamen über einen Index hergestellt. In Kapitel 6.2 wird beschrieben, wie bei einer nicht abgedeckten Methode der Dateiindex und der Methodenindex durch den DataLogger abgespeichert wird. Die dabei gesicherten Messwerte liegen nach dem Experiment in einem Messwerte-Format vor und müssen zur weiteren Verarbeitung in ein ASCII-Format umgewandelt werden, siehe auch Abbildung 15. Damit der Benutzer abschließend mit den Ergebnissen arbeiten kann, muss von den gemessenen Methodenzählern ein Bezug zum Dateinamen und Methodennamen hergestellt werden. Dies wird über die bei der Instrumentierung gespeicherten Log-Dateien realisiert. Sind danach alle Werte erfasst, so werden diese übersichtshalber in ein Gesamtergebnis mit einbezogen.

61 6.3 Präsentation der Ergebnisse So wird dem Benutzer in der späteren Ergebnisdatei auf einen Blick beispielsweise die Anzahl aller Methoden angezeigt, die beim Experiment nicht benutzt wurden. Die Ergebnisse werden außerdem in einer Log-Datei coverage result.xml gesichert. In einem weiteren Schritt werden die Ergebnisse aufbereitet und in einem HTML-Report ausgegeben. Auf diese Weise ist es für den Benutzer möglich, eine Übersicht der Ergebnisse zu erhalten und auch über interaktive Verweise auf die einzelnen Quelldateien zuzugreifen. Abbildung 15: Ablauf der Ergebnisaufbereitung Analysieren der Messwertedatei von ASCET-SD Um die von ASCET-SD gespeicherten Coverage-Werte nach dem Test in das ASCII-Format umzuwandeln, wird die Funktion getascii() entwickelt. Die Ergebnisse der Code Coverage Analyse werden von ASCET-SD in ein spezielles Binärdatenformat zur Signalaufzeichnung gespeichert. Um diese Werte wieder verarbeiten zu können, müssen diese zuerst aus dem Datenformat ausgelesen und anschließend in einem Array gesichert werden. Aus diesem Array lassen sich schließlich die Coverage-Werte herausfiltern. Zuerst wird eine Auflistung der gemessenen Signale, also der Mittelwerte der Analyse und auch die einzelnen Zählerarten, in einer separaten Datei, coverage resultlog.xml, gespeichert. Die eigentlichen Ergebnisse der Code Coverage Analyse, nämlich die Zählerwerte, die Null sind, werden als Datensätze zusammengefasst und ebenfalls in der Datei gesichert.

62 6.3 Präsentation der Ergebnisse Um die wichtigen Daten von den unwichtigen zu trennen, wurden die Variablen im ASCET-SD Coverage-Modul mit -1 initialisiert. Bei der Auswertung sucht ein Algorithmus schließlich nach Datensätzen, bei denen nicht alle Werte negativ sind. Diese Datensätze enthalten somit wichtige Informationen und werden schließlich in der Datei coverage resultlog.xml gespeichert. Diese Datei dient dem Werkzeug Show BranchCounterResults als Grundlage zur weiteren Verarbeitung der Ergebnisse.

63 6.3 Präsentation der Ergebnisse Der folgende Algorithmus ermöglicht die Ausgabe der Coverage-Werte in die Log-Datei coverage resultlog.xml: my $var; my $noimpdata = 1; # read every timestamp and sort the data foreach $timestamp (sort { $a <=> $b } keys (%{$values{ 1 }})) { $timestamp count++; $starttime = $timestamp if not defined $starttime; $dtime = $timestamp; $dtime = sprintf ("%.5f",$dtime); $dtime = s/([0-9.]+?)([.0]*)$/$1/; $dtime = ( x (12 - length ($dtime))).$dtime; for ($i=0; defined $values{$i}; $i++) { $temp = $values{$i}->{$timestamp}; $temp = sprintf ("%.3f",$temp); $temp = s/(/d+?)/.([0-9]*?)([0]*)$/$1/.$2/; $temp = s/(/d+?)/.$/$1/; $var.= "$temp". " SK "; # if some important data is found, noimpdata = 0 if ( $temp!= -1 ) { $noimpdata = 0; } } $endtime = $timestamp; # results seperated by an SK # if var = -2 the important data ends, so cut loop if ( $var = /-2/ ) { last; } # seperate the inportant information from the not important infos, unless ( $var = /-2/ $noimpdata ) { print STDERR " var: $var/n " if $debug; my $tmp = 0; my $set = $var; $set = s/(-?/d+) SK /$1 /g; print RESLOGOUT " " x $xmlindent1. " <dataset>/n "; print RESLOGOUT " " x $xmlindent2. " <set>$set</set>/n "; while ( $var = / SK /) { $var = s/(-?(0 _ )?/d+) SK / FI /; my $value = $1; print RESLOGOUT " "x$xmlindent2." <dataset signal>/n "; print RESLOGOUT " "x$xmlindent3." <signalidx>$tmp</signalidx>/n "; print RESLOGOUT " "x$xmlindent3." <signalval>$value</signalval>/n "; print RESLOGOUT " "x$xmlindent2." </dataset signal>/n "; $tmp++; print RESLOGOUT " "x$xmlindent1." </dataset>/n "; } $var = " "; $noimpdata = 1; }

64 6.3 Präsentation der Ergebnisse In dem bereits dargestellten Programmcode werden für jeden Zeitstempel in der Messwertedatei, timestamp, die Werte der Variablen angepasst (zwei Nachkommastellen) und in die temporäre Variable temp geschrieben. In der folgenden Abfrage: if ( $temp!= -1 ) wird geprüft, ob es sich um wichtige Informationen handelt oder nicht. Bei unwichtigen Informationen bekommt die Variable in ASCET-SD den Wert -1 zugewiesen. Ist ein Dataset komplett, so folgt eine Überprüfung: if ( $var = /-2/ ) bei der die Foreach-Schleife abgebrochen wird, falls in den Werten ein -2 vorkommt. Dies ist nur dann der Fall, wenn die Messung der Coverage-Werte abgeschlossen ist. Dabei wurde durch das Coverage-Modul von ASCET-SD der letzte Coverage-Wert auf -2 gesetzt. Ist das nicht der Fall und im Dataset sind wichtige Werte, so werden diese in die Datei coverage resultlog.xml geschrieben, woraus sie später wieder gelesen und präsentiert werden. Berechnung der Gesamtergebnisse Aus den von ASCET-SD ausgelesenen Ergebnissen lassen sich die Gesamtergebnisse berechnen. So wird beispielsweise die Anzahl der Klassen bestimmt, unterteilt in komplett abgedeckte und nicht abgedeckte Klassen. Es werden für jede Zählerart die Anzahl der Zähler berechnet, die Null geblieben sind und die, die während des Experiments inkrementiert wurden. Ebenfalls wird für jede Zählerart eine Übersicht über die abgedeckten Klassen zusammengestellt. Um den erhöhten Zeitaufwand durch die Code Coverage Analyse zu erfassen, wird die Dauer für die Instrumentierung und für die Überarbeitung der Ergebnisse gemessen. Diese Ergebnisse werden ebenfalls in der HTML-Ergebnisdatei in tabellarischer Form dargestellt.

65 6.3 Präsentation der Ergebnisse Erstellung von HTML-Reports Um dem Benutzer eine einfache und übersichtliche Präsentation der Ergebnisse präsentieren zu können, wurde als Ausgabeformat HTML gewählt. In HTML ist es möglich, die Messergebnisse tabellarisch darzustellen und durch interaktive Verweise und Anker eine Struktur zwischen den Ergebnissen und den Klassen herzustellen. Wie in Abbildung 16 zu sehen ist, werden zu Beginn der tabellarischen Darstellung allgemeine Informationen wie Datum, Namen der Messwertedatei und Dauer der Verarbeitung angezeigt. Abbildung 16: Ergebnispräsentation in HTML-Format, siehe auch CD Danach folgen Informationen über gemessene Coverage-Signale, Anzahl der Klassen und die Anzahl aller Zähler, die während dem Experiment nicht instrumentiert wurden. Anschließend werden die Zählerarten einzeln aufgeführt, zuerst die Prozentangabe der Abdeckung, danach die Anzahl der inkrementierten- und nicht inkrementierten Zähler und schließlich die Anzahl der abgedeckten- und nicht abgedeckten Klassen.

66 6.3 Präsentation der Ergebnisse In der letzten Spalte werden Schaltflächen eingefügt, die einen Verweis zu einer Tabelle darstellen, in der eine Übersicht über die Klassennamen der jeweiligen Zähler gargestellt wird, siehe auch Abbildung 17. In dieser Tabelle ist es möglich, durch anwählen des gewünschten Klassenamens den Quellcode einzusehen. Um den Quellcode einzusehen ist es auch möglich, auf die rot markierten Namen der Zählerarten in der Gesamtübersicht zu klicken. In dem HTML-Report wird nach unten gesprungen und eine Liste der einzelnen nicht inkrementierten Zähler wird angezeigt. Durch anwählen der Klassennamen durch den Benutzer kann der Quellcode genau an der Stelle des gewünschten Zählers in einem neuen Fenster geöffnet und analysiert werden. Dies ist für alle Zählerarten möglich, gesetzt den Fall, dass es für diese Zählerart überhaupt nicht inkrementierte Zähler gibt. Eine Ausnahme spielen hierbei die nicht benützten Zähler, also die Zähler, die durch den Code-Optimierer CGenCorr entfernt worden sind. Bei diesen Zählerarten sollen die Zählerwerte Null bleiben. Sind diese trotzdem während des Experiments inkrementiert worden, so werden diese ebenfalls in der Tabellenstruktur angezeigt. Abbildung 17: Präsentation der abgedeckten und nicht abgedeckten Klassen

67 6.3 Präsentation der Ergebnisse Überarbeiten der Log-Dateien Die bei der Instrumentierung und Auswertung angelegten Log-Dateien und Ergebnisdateien müssen nach Ablauf der Code Coverage Analyse und der Auswertung der Ergebnisse noch überarbeitet werden. Die Log-Dateien sollen XML-konform sein, d.h. den Anforderungen an ein XML-Dokument nach XML-Version 1.0 [W3C04] des XML-Konsortiums genügen. Durch dieses Konsortium wurden Regeln für den Aufbau einer XML-Datei festgelegt. So muss in der XML-Datei ein Header mit der Document Type Definition und ein Start- und End-Tag enthalten sein. Um diesen Vorgang durchzuführen wurde das Modul Finish BranchCounterLog.pm entwickelt, das nach Abschluss der Code Coverage Analyse die Dateien mit einem XML-Header, Root-Start-Tag und einem Root- End-Tag versieht. Im XML-Header wird die XML-Version, der verwendete Zeichensatz und eine Document Type Definition [Bi01] eingefügt. Durch die XML-DTD werden die zulässigen Attribute und Elemente, die möglichen Inhalte sowie die Regeln zum Aufbau der Verschachtelung festgelegt. Die Elemente innerhalb eines XML- Dokuments müssen in einem gemeinsamen, so genannten Root-Tag, stehen. Somit wird vor und nach dem eigentlichen Inhalt ein vorher definiertes Wurzel- Element eingefügt.

68 6.3 Präsentation der Ergebnisse Im folgenden Beispiel der Log-Datei coverage log.xml sind der eingesetzte XML-Header und die XML-DTD rot markiert: <?xml version=" 1.0 " encoding=" UTF-8 " standalone=" no "?> <!DOCTYPE coverage log [ <!ELEMENT coverage log (coverage)+> <!ELEMENT coverage (fileindex?,filename, localtime, revision, inserted counters, entire counters?)> <!ELEMENT fileindex (#PCDATA)> <!ELEMENT filename (#PCDATA)> <!ELEMENT localtime (#PCDATA)> <!ELEMENT revision (#PCDATA)> <!ELEMENT inserted counters (method statemachine limiter if else loop looplimiter CGENCORR unusedmethod tip)*> <!ELEMENT method (MC index, method name)> <!ELEMENT MC index (#PCDATA)> <!ELEMENT method name (#PCDATA)> usw. ]> <coverage log> <coverage> <filename>limitm.c</filename> <localtime>wed Aug 4 09:06: </localtime> <revision> $Id: ASD/BranchAndPathAnalysis/source/Prepare BranchCounter.pl (Build:172; main/finish BRANCHCOUNTERLOG BUILD13 KO82ABT/40; Production) Tue Aug 03 09:15: ko82abt$ new build started, log created </revision> <inserted counters> <method> <MC index>0-limitm.c</mc index> <method name> 040G060KG0001K07085G calc</method name> </method> </inserted counters> <entire counters> <methodcounter>1</methodcounter> <branchcounter>0</branchcounter> <limitercounter>0</limitercounter> <loopcounter>0</loopcounter> <looplimitercounter>0</looplimitercounter> <unusedmethodcounter>0</unusedmethodcounter> </entire counters> </coverage> <coverage> <fileindex>0</fileindex> <filename>limiti.c</filename> <localtime>wed Aug 4 09:06: </localtime> <revision> $Id: ASD/BranchAndPathAnalysis/source/Prepare BranchCounter.pl (Build:172; main/finish BRANCHCOUNTERLOG BUILD13 KO82ABT/40; Production) Tue Aug 03 09:15: ko82abt$ new build started, log created </revision> <inserted counters> <tip>no counters had to be insert</tip> </inserted counters> </coverage> </coverage log>

69 6.3 Präsentation der Ergebnisse Zum Schluss ändert Finish BranchCounterLog noch die Namen der Log- Dateien. Dabei wird, vor den eigentlichen Dateinamen, ein Datums- und Zeitstempel eingefügt, um eine Überschreibung alter Ergebnisse zu verhindern. Vorhandene XML-Dateien im Verzeichnis C:/bin/log, vor der Umbenennung: coverage build.log, beinhaltet die Ausgabe aus der Shell. coverage error.xml, speichert eventuelle Fehlermeldungen. coverage filecounter.xml, enthält die Anzahl der instrumentierten Quelldateien und deren Indizes. coverage log.xml, nimmt die Vorgänge der Instrumentierung aller Quelldateien auf: 1. Optional: Dateiindex. 2. Name der Datei. 3. Datum und Uhrzeit der Instrumentierung. 4. Revision, Pfad, Version. 5. Eingefügte Zähler: Methoden, If/Else, Begrenzer, Schleifen, Switch/Case. Jeweils mit Index, eventuell Typ, Name oder Bedingung. 6. Gesamtanzahl der einzelnen Zählerarten. coverage presentation.html, zeigt die Ergebnisse der Code Coverage Analyse. coverage result.xml, speichert die Resultate der Code Coverage Analyse nach Ablauf des Experiments. 1. Resultate der einzelnen Coverage-Werte: Coverage, Abdeckung gesamt. CoverageBC, Abdeckung der Branch Counters. CoverageCBC, Abdeckung der Created Bitfield Counters. CoverageIMC, Abdeckung der Inlined Method Counters. CoverageLC, Abdeckung der Limiter Counters. CoverageLoC, Abdeckung der Loop Limiter Counters. CoverageMC, Abdeckung der Method Counters. CoverageOLC, Abdeckung der Outlined Limiter Counters. CoverageUMC, Abdeckung der Unused Method Counters.

70 6.3 Präsentation der Ergebnisse Ergebnisse der einzelnen Zähler mit Angabe der Zählerart, des Dateiindex, des Dateinamens, des internen Index und schließlich des Zählernamens. coverage resultlog.xml, enthält die eingelesenen Zwischenergebnisse von der Messwertedatei: 1. Übersicht über alle gemessenen Signale 2. Aufzählung der gemessenen Datensätze und dabei die Werte der einzelnen Signale im aktuellen Datensatz. coverage xchange.xml, sichert die nutzbare Informationen aus der Übergabedatei von CGenCorr. Außer diesen Dateien wird ein Ordner html-files erstellt, in dem sich, die von C2HTML aus den Quelldateien erstellten HTML-Dateien und die Dateitabellen, befinden. Dieser Ordner und die oben aufgeführten Dateien werden zusammen in einen gemeinsamen Ordner verschoben. Dieser Ordner wird ebenfalls in C:/bin/log erstellt und mit einem eindeutigen Zeitstempel versehen, beispielsweise coverage results. Somit befinden sich alle von dem Code Coverage Tool erstellten Dateien in einem gemeinsamen Ordner und sind durch den eindeutigen Zeitstempel gegen unbeabsichtigtes Überschreiben geschützt.

71 7 Beschreibung der Testumgebung Beschreibung der Testumgebung Um die Qualität einer Software zu erhöhen ist es notwendig, schon in frühen Entwicklungsstadien einzelne, sich in der Entwicklung befindliche, Teilmodule zu Testen. Dabei bietet sich vor allem ein iterativer Prozess an, bei dem die jeweils neu entwickelte Komponente getestet und anschließend weiterentwickelt und wieder getestet wird. Dies entspricht dem Spiralmodell zum Entwickeln von Softwarekomponenten. Dabei soll vor allem die Qualität der Softwarekomponente erhöht und gleichzeitig der Aufwand des Testens der Gesamtsoftware verringert werden, da schon Teile der Gesamtsoftware während der Entwicklungsphase getestet wurden. 7.1 Das ASCET-SD Testprojekt Die in dieser Arbeit entwickelte Softwarekomponente ist für die Messung der Abdeckung eines ABS-Projekts angedacht. Bei einem ABS-Projekt handelt es sich um eine vorbereitete Testumgebung für eine ABS-Reglersoftware. Für die Vorbereitung eines Experiments mit einer ABS-Reglersoftware ist es notwendig, alle Quellen neu zu kompilieren. Dieser Vorgang benötigt etwa eine halbe Stunde. Um für das Testen einzelner Komponenten des Code Coverage Tools nicht zuviel Zeit zu verlieren, ist zu Beginn dieser Diplomarbeit ein Testprojekt in ACSET-SD erstellt worden, siehe auch Abbildung 18. Die Testumgebung beinhaltet sämtliche programmierspezifischen Merkmale, die in einem ABS-Projekt vorkommen können: Ein Signalgenerator (Stimuli-Modul). Ein If/Else-Modul (If/Else). Eine begrenzte Variable (Limiter Variable). Ein Modul mit einer While- und einer For-Schleife (Loop). Ein Switch/Case-Modul (Statemachine (Switch/Case)). Ein Modul mit zwei Methoden (odd/even). Ein Modul zur internen Messung der Code Coverage. Und schließlich das entwickelte ASCET-SD Coverage-Modul.

72 7.1 Das ASCET-SD Testprojekt Abbildung 18: Übersicht über das Coverage-Testprojekt Mit diesem Testprojekt sind somit alle Möglichkeiten eines ABS-Projektes abgedeckt. Dadurch kann schnell und sicher eine neue Funktionalität getestet werden. Das Testprojekt ist sowohl online, auf der Zielumgebung ES1130, als auch offline am PC nutzbar. Mit dem zusätzlichen Modul zur Messung der internen Coverage ist es dem Entwickler möglich, die externe Messung von Prepare BranchCounter und Show BranchCounterResults mit einer internen Messung zu überprüfen. Außerdem ist es möglich, verschiedene Zählerarten, beispielsweise Methoden, nicht mitzuzählen und so dem Code Coverage Tool eine unbenutzte Methode zu simulieren. Wie in Abbildung 19 zu sehen, sind im If/Else-Modul zwei Prozesse enthalten, die nicht benutzt werden. Diese werden vom Code Coverage Tool als vom Test nicht abgedeckte Methoden erkannt und als solche ausgegeben.

73 7.2 Das Testverfahren CompareComputing Abbildung 19: Das If/Else-Modul des Coverage-Testprojekts 7.2 Das Testverfahren CompareComputing Zum Testen der ABS-Reglersoftware bei der Rober Bosch GmbH ist das so genannte CompareComputing entwickelt worden. Dabei beinhaltet der von ASCET-SD generierte Code die Funktionalitäten der eigentlichen Regler-Software. Dieser Teil der Software wird ASW genannt, Application Software. Der zweite Teil der Regler-Software, der die plattformabhängigen Abläufe regelt, nennt man PSW, Platform Software. Durch eine ganze Reihe von verschiedenen Tools, zusammengefügt in der Make Tool Chain, die beispielsweise auch noch die Modellierungsrichtlinien prüft, werden diese beiden Softwareteile miteinander verbunden. Mit Hilfe von bestimmten Parameterfeldern, die bestimmte Applikationen der ABS-Software darstellen, entsteht somit die CSW, Complete Software. Die Trennung der Funktionalitäten und die einheitlichen Schnittstelle zwischen ASW und PSW ermöglichen es, die gleiche ASW auf verschiedenen Hardwareumgebungen zu testen.

74 7.2 Das Testverfahren CompareComputing Diese Möglichkeit wird beim CompareComputing ausgenutzt, siehe auch Abbildung 20. Dabei wird die CSW parallel auf zwei verschiedene Zielumgebungen geladen. Auf der einen Seite der von ASCET-SD generierte Code auf der ES1000, einem PowerPC, und auf der anderen Seite der von CGenCorr optimierte Code auf der EMU. ASCET-SD DB ECU Project Parallel Pass Project Start Generierung *.db *.c.pl *.h.pl Online Experiment CSW CGenCorr ES 1000 PowerPC Coverage Make Tool Chain PSW + ASW Parallel Pa ss ASD_CodeGen_Test Testfall CSW EMU LabCar NG Abbildung 20: Übersicht über das Testverfahren CompareComputing

75 7.2 Das Testverfahren CompareComputing Das Entwicklungssteuergerät und auch der PowerPC befindet sich im so genannten LabCar NG, siehe Kapitel 2.3. Dieses Laborauto ist ein Geräteaufbau, das dem Steuergerät mit Hilfe von Hardware-Sensoren und Software eine komplette Fahrzeugumgebung simuliert. Ebenfalls im Laborauto befindet sich auch ein PC, der für die Initialisierung der EMU und des PowerPC s und für die Messung zuständig ist. Der optimierte Code wird je nach Einstellung von CGenCorr hinsichtlich Laufzeit, RAM- und ROM-Bedarf optimiert und unterscheidet sich vom Originalcode in den folgenden Punkten: Unbenutzte Methoden werden entfernt. Unbenutzte Variablen und Parameter werden entfernt. Methoden werden je nach ihrer Aufrufhäufigkeit aufgelöst und in die entsprechenden Zeilen eingefügt, oder bei mehrmaligem Vorkommen von gleichen Algorithmen neue Methoden gebildet. Optimierung von Typumwandlungen. Optimierung von Strukturen und Zustandsautomaten. Um anschließend die Funktionalität des optimierten Codes zu prüfen, werden beide Codes, der Optimierte auf der EMU und der nicht Optimierte auf dem PowerPC, parallel gestartet und durch den ASD CodeGen Test, siehe auch Kapitel 7.3 verschiedene Testfälle durchlaufen. Jedes Zwischenergebnis einer Berechnung wird bitweise miteinander verglichen und dokumentiert. Somit kann eine vollständige Funktionskontrolle des optimierten Codes durchgeführt werden. Im Hintergrund der CSW auf dem PowerPC wird dabei auch die Coverage Analyse eingesetzt, um die Abdeckung des Testverfahrens zu ermitteln.

76 7.3 Integration in den ASD CodeGen Test Integration in den ASD CodeGen Test Das in dieser Arbeit entwickelte Code Coverage Analyse Tool soll innerhalb eines automatisierten Testablaufes eingesetzt werden. Dieser Testablauf ist für die Anwendung des Testverfahrens CompareComputing ausgelegt. Dabei werden verschiedene Testfälle automatisiert, durchgeführt und die Ergebnisse in einer Microsoft Excel Tabelle, dem ASD CodeGen Test Report gespeichert, siehe Ablauf in Abbildung 21. ASD_CodeGen_Test ASCET-SD Projekt Start CompareComputing Code Coverage Tool Prepare_BranchCounter Übergabe-Datei CGenCorr Instrumentierung C-Code PowerPC ES 1130 LabCar NG EMU Optimierung C-Code Start CompareComputing Testabläufe Start Parallel-Test Start CompareComputing Fehlermessung Coverage-Modul ASCET-SD Online Messung Parallel-Test Ende ASD_CodeGen_Test Report Code Coverage Tool Präsentation der Ergebnisse Abbildung 21: Aufbau des ASD CodeGen Test

77 7.3 Integration in den ASD CodeGen Test Für den automatisierten Test werden folgende Hardwarekomponenten benötigt: PC mit ASCET-SD LabCar NG, siehe Kapitel Die Voreinstellungen für den ASD CodeGen Test werden in einer MS Excel Tabelle vorgenommen. Dabei kann beispielsweise eingestellt werden, welches Projekt verwendet, ob die Quelldateien neu kompiliert und ob eine Code Coverage Analyse durchgeführt werden soll. Außerdem werden die Testfälle in dieser Tabelle definiert, die später den Testablauf darstellen. Ist der automatisierte Test gestartet, so werden die voreingestellten Anweisungen ausgeführt und nach der Abarbeitung der Testfälle die Ergebnisse in einem HTML-Report präsentiert. Bei diesem Testablauf wird vor allem auf die Gleichheit der beiden Softwarevarianten, siehe Kapitel 7.2, geachtet. Die Coverage-Ergebnisse sollen anschließend ausgewertet werden, um eine Verbesserung der Testfälle zu ermöglichen.

78 8 Zusammenfassung und Ausblick Zusammenfassung und Ausblick Die Aufgabe dieser Diplomarbeit bestand darin, ein Code Coverage Analyse Tool für Software-Tests zu entwickeln und dieses in die Entwicklungsumgebung ASCET-SD zu integrieren. Zu Beginn wurden in einer Studie verschiedene Code Coverage Tools auf einen möglichen Einsatz im Bereich Chassis Systems bei der Robert Bosch GmbH getestet. Aus dieser Studie ging hervor, dass das bereits von der Robert Bosch GmbH entwickelte Werkzeug Prepare BranchCounter optimiert und erweitert werden soll. Außerdem soll ein neues Werkzeug zur Präsentation der Ergebnisse entwickelt werden. Die wichtigsten Entwicklungsschritte dieser Diplomarbeit werden in der folgenden Auflistung nochmals dargestellt: Zu Beginn dieser Diplomarbeit wurde ein Projektplan erstellt, um die zeitliche Abfolge der Tätigkeiten zu ermitteln. In einer wöchentlichen Statusbesprechung wurde dieser Projektplan aktualisiert. Die Anforderungen an das Produkt wurden in einer Requirements Analyse festgehalten. Es wurde eine Analyse bereits vorhandener Code Coverage Tools durchgeführt, um eine mögliche Verwendung der analysierten Werkzeuge zu untersuchen. Das von der Robert Bosch GmbH entwickelte Code Coverage Tool Prepare BranchCounter, dass für die Instrumentierung der Quelldateien entwickelt worden ist, wurde korrigiert, optimiert und durch verschiedene Funktionalitäten erweitert. So wurden beispielsweise die Informationen vom Code-Optimierer CGenCorr verarbeitet. Ebenfalls optimiert und erweitert wurde das Coverage-Modul in ASCET-SD. Durch dieses Modul ist es möglich, die Werte der Code Coverage Analyse zu messen und zu speichern. Zum Testen des Code Coverage Tools wurde in ASCET-SD ein Testprojekt entwickelt, dass die gleichen Komponenten wie ein ABS-Projekt in minimaler Form enthält. Um die Ergebnisse der Code Coverage Analyse auszuwerten und sie dem Benutzer zu präsentieren, wurde das Werkzeug Show BranchCounterResults entwickelt. Es verarbeitet die gespeicherten Ergebnisse des Coverage-Moduls von ASCET-SD und präsentiert die Resultate in HTML-Reports.

79 8 Zusammenfassung und Ausblick Zur Erweiterung von Show BranchCounterResults wurde das PERL-Modul C2HTML implementiert. Es übersetzt die Quelldateien von C- in HTML- Format, damit diese bei der Präsentation der Ergebnisse im Internet-Browser durch Links im HTML-Report übersichtlich dargestellt werden können. Die bei der Code Coverage Analyse erstellten Log-Dateien müssen vor der Ergebnispräsentation überarbeitet werden. Zu diesem Zwecke wurde das PERL-Modul Finish BranchCounterLog entwickelt. Ausblick Das Code Coverage Analyse Tool Prepare BranchCounter wird in Zukunft die Entwickler von ABS-Reglersoftware im Bereich Chassis Systems der Robert Bosch GmbH unterstützen. Es wird in den automatisierten Testablauf ASD CodeGen-Test integriert werden und kann somit dem Benutzer Informationen über die Abdeckung der getesteten Software liefern. Dadurch ist es dem Entwickler möglich, Verbesserungen am Testablauf, am Code-Optimierer CGenCorr und an der Software selbst vorzunehmen. Aufbauend auf dieser Arbeit ist eine Optimierung und Erweiterung des Code Coverage Tools möglich. Eine wichtige Verbesserung wäre die Vereinfachung der Integration des Werkzeuges in den Ablauf eines Experiments, beispielsweise durch einen Eintrag im Pull-Down Menu von ASCET-SD, wodurch der Anwender die Code Coverage Analyse ein- bzw. ausschalten kann. Dadurch wäre eine Änderung einer Systemdatei von ASCET-SD nicht mehr notwendig. Um die Präsentation der Ergebnisse für die Fehlersuche noch zu optimieren, wäre es möglich, eine Verbindung aller Methoden innerhalb des gesamten Projektes zu erreichen. So könnte der Entwickler beispielsweise von einer nicht abgedeckten Methode zum Aufruf dieser Methode in einer anderen Klasse springen, um dort die Fehlersuche fortsetzen. Außerdem wäre es bei der Präsentation der Ergebnisse möglich, Grafiken und Schaubilder zur Übersicht über die Code Coverage Analyse darzustellen. Wie bereits in der Einleitung dieser Diplomarbeit erwähnt, wäre eine Erweiterung der Code Coverage Analyse im Hinblick auf eine Pfadanalyse wünschenswert. Durch die Implementierung einer Pfadanalyse sind genauere Angaben über die nicht abgedeckten Programmteile möglich. Somit wird eine Suche nach den Ursachen der nicht abgedeckten Code-Teile vereinfacht.

80 9 Glossar Glossar Nachfolgend sind Begriffe definiert, die für das Verständnis dieser Arbeit nützlich sind. ABS: Anti Blockier System, regelt die Bremskraft bei einer Vollbremsung des Kraftfahrzeugs und ermöglicht dadurch die Lenkbarkeit während des Bremsvorgangs. Adaptive Cruise Control: Unter Adaptive Cruise Control versteht man die automatische Regelung der Geschwindigkeit im Fahrbetrieb. Sie wird von einigen Fahrzeugherstellern auch als Tempomat bezeichnet. ASCET-SD: Entwicklungswerkzeug der Firma ETAS zur Modellierung und Entwicklung von Steuergerätecode im Bereich Embedded Systems. ASD CodeGen Test: Automatisierter Testablauf für die ABS-Reglersoftware in Verbindung mit CompareComputing. Body Electronics: Body Electronics ist ein Sammelbegriff für die mechatronischen Antriebe im Kraftfahrzeug, wie beispielsweise Fensterheber, Schiebedach, etc. CGenCorr: Code-Optimierer, der den generierten Code von ASCET-SD hinsichtlich Laufzeit, RAM- und ROM-Bedarf optimiert. CMMI: Capability Maturity Model Integration, Prozessabwicklungsmodell zur Definition und Beschreibung von Geschäftsprozessen. Code Coverage Analyse: Analyse der Abdeckung einer Softwarekomponente durch einen definierten Testablauf. Code-Generierung: Programmcode wird automatisch von einem Werkzeug generiert. Code-Optimierung: Optimierung von bestehendem Quellcode, siehe CGenCorr. CompareComputing: Testverfahren, bei dem die ABS-Reglersoftware auf zwei verschiedenen Zielumgebungen parallel gestartet und ein bitweiser Vergleich der Zwischenergebnisse durchgeführt wird. Compiler: Der Compiler übersetzt den C-Code in Objektcode, der aber noch offene Aufrufe enthält. Die Zuweisung der Aufrufe erfolgt durch den Linker.

81 9 Glossar EMU: Die Electronic Emulate Unit ist eine, für die Entwicklung angepasste, Hardwareversion des Steuergerätes im Kraftfahrzeug. DataLogger: Integriertes Werkzeug in ASCET-SD, durch das eine Abspeicherung von Messwerten während des laufenden Experiments ermöglicht wird. HTML: Hypertext Markup Language ist ein Format für Dokumente, das besonders im World Wide Web eingesetzt wird. Dem gewünschten Text wird durch Tags und Elementen eine Struktur verliehen, ähnlich zu XML. Instrumentierung: Die Quelldateien werden durch das Code Coverage Tool mit zusätzlichem Code versehen, um beispielsweise Zähler für Funktionen und Schleifen in den Quellcode einzufügen. LabCar NG: Laborauto zur Simulierung der Fahrzeugumgebung im Labor. Es ermöglicht das Testen der ABS-Reglersoftware schnell und ohne größeren Aufwand. Limiter: Bei der Code-Generierung von ASCET-SD wird der Wertebereich von Variablen begrenzt. Dieser Algorithmus wird in ASCET-SD Limiter genannt. Beispiel: limited var = (( t1uint8 > 50)? 50 : t1uint8); /*min=0, max=50*/ Linker: Bei der Erstellung von ausführbaren Dateien aus C-Code werden durch den Linker die noch offenen Funktionsaufrufe mit den zugehörigen Funktionen verbunden und verwendete Bibliotheken eingebunden. Log-Dateien: Beim Ablauf der Code Coverage Analyse werden Zwischenergebnisse, Informationen zur Fehlersuche und die Abfolge der Arbeitschritte in Dateien gespeichert. Diese Dateien, die zur Fehlerbehebung eingesetzt werden können, werden als Log-Dateien bezeichnet. MakeExe: Mit Hilfe des Programms MakeExe werden aus den PERL-Skripten des Code Coverage Tools ausführbare Dateien erstellt. Dadurch ist es für den Anwender der Coverage Analyse nicht notwendig, PERL zu installieren. Pattern Matching: Methode in PERL, bei dem ein String nach einem vorgegebenen Ausdruck durchsucht werden kann. PERL: PERL ist eine Skriptsprache zum Entwickeln von Computerprogrammen. Der Schwerpunkt dieser Programmiersprache liegt besonders auf der Verarbeitung von Dateien und Texten.

82 9 Glossar Requirements Management: Erstellung und Fixierung der Anforderungen an ein Produkt. XEmacs: Entwicklungsumgebung für Software bei der Robert Bosch GmbH im Bereich Chassis Systems. XML: Extensible Markup Language ist ein einfaches und flexibles Format für Textdateien. Es eignet sich besonders für hierarchische Dokumentationen und zum Austausch von Daten zwischen verschiedenen Programmen.

83 Literaturverzeichnis Literaturverzeichnis [Ba98] Balzert, H.: Lehrbuch der Software-Technik, Spektrum, Akademischer Verlag (1998) 16 [Bau01] [Bi01] [Bo04] [Bo04] [CCA04] Bauer, H.: Konventionelle und elektronische Bremssysteme, Firma Robert Bosch GmbH (2001) 1, 5 Birbeck, M.: Professional XML, 2nd Edition, Wrox Press, Birbeck und Diamond (2001) 30, 61 Robert Bosch GmbH: EMU Handbuch, Firma Robert Bosch GmbH, Intranet (2004) Robert Bosch GmbH: LabCar Team, Firma Robert Bosch GmbH, Intranet (2004) 2, 10 8 CaseConsult: Flyer ANALYZER de, Firma CaseConsult in Wiesbaden, (2004) 22 [CMU, 02] Carnegie Mellon University: Introduction to Capability Maturity Model, Carnegie Mellon University (2002) [ETAS00] [ETAS00] ETAS GmbH & Co. KG: ASCET 4.0 Handbuch, ETAS GmbH & Co. KG (2000) 2, 8 ETAS GmbH & Co. KG: Netzwerkinstallation für ES und ES1120.1, ETAS GmbH & Co. KG (2000) 8 [ISA04] 22 ISA: User s Manual of Panorama-2 (C/C++) for Windows NT/2000/XP/98, Firma International Software Automation, e.htm (2004) [QSS00] [Rat02] QSS, Inc.: Using DOORS, Firma QSS, Inc. and its affiliated companies (2002) 5 Rational: ClearCase Benutzerhandbuch, Firma Rational Software Corporation (2002) 7 [Scho97] Scholand, A.: ASD4 Schulung 4.2, ETAS GmbH & Co. KG (1997) 3 [Sie99] Siever, E.: Perl in a Nutshell, Deutsche Ausgabe (1999) 9

84 Literaturverzeichnis [Sta94] [Th01] [Th04] [Th04] [VS04] Stallman, R.: XEmacs User s Manual,Stallman, Lucid Inc. und Wing (1994) Thullner, M.: Branch and path analysis, Firma Robert Bosch GmbH, Intranet (2001) Thullner, M.: CGenCorr news, Firma Robert Bosch GmbH, Intranet (2004) Thullner, M.: CompareComputing index, Firma Robert Bosch GmbH, Intranet (2004) Verifysoft: CTC++ - Test Coverage Analyzer for C/C++, Firma Verifysoft in Offenburg, (2004) 22 [W3C04] W3C: Extensible Markup Language (XML), (2004) 61 [Aich04] Aichner, A.: XEmacs Website, Aichner Adrian, (2004) 13

85 10 Inhalt der beiliegenden CD Inhalt der beiliegenden CD Auf der CD befinden sich mehrere Ordner, deren Inhalt nachfolgend erläutert ist: Ordner deliver: Aktuelle Version des Code Coverage Analyse Tools. Ordner documentation: Die Dokumentation der Diplomarbeit in den Dateiformaten *.pdf, *.dvi, *.ps und *.tex. Ordner source: Der Quellcode des Code Coverage Tools, inkl. Dokumentation über den Quellcode und verwendete Bibliotheken. Ordner misc: Sonstige Dateien, die für das Verständniss dieser Diplomarbeit hilfreich sind: Projektplan How to Code Coverage ASCET-SD Testprojekt DOORS-Dateien, Requirements Analyse Log-Dateien Beispiele

86 11 Anhang A Anhang A ID Cov_CUR_31 Cov_CUR_32 Cov_CUR_1 Cov_CUR_42 Cov_CUR_36 Cov_CUR_43 Cov_CUR_44 Cov_CUR_37 Cov_CUR_2 Cov_CUR_3 Customer Requirements of Coverage 1 Analyze external tools Do internet research on external tools 1.1 evaluate selection of external tools use case is to run coverage analysis for an ASCET-SD online experiment on an ES1000. The simulation HW is an ES1130 with PPC750 and the operating system ERCOSek. 2 Measure coverage of ASCET-SD experiment measure coverage of ASCET-SD experiment 2.1 starting coverage tool the coverage tool, including measurement and result presentation, must be startable either from an ASCET_SD menu item or from the automatically testing process 2.2 instrument code the coverage tool must instrument the c-code generated by ASCET-SD instrumentation automatically the coverage tool must instrument the generated c-code automatically verify internal tool internal coverage tool 'Prepare_BranchCounter' must be checked, optimized or if the tool is not usefull, substituted by a new tool instrument code regarding code optimizations instrument code with different counters for optimized/not optimized code to simplify the online analysis. 2.3 branch coverage analysis measure each branch of software method counter an ASCET-SD class could contains several methods, each method must be measured. for each methods several functions are generated by ASCET-SD. measure function-execution for functions programed by user: measure initialisation functions measure module code do not measure functions generated only for experiment (e.g. L1-messages). Abbildung 22: Customer Requirements, Teil 1, siehe auch CD

87 11 Anhang A Cov_CUR_5 Cov_CUR_6 Cov_CUR_7 Cov_CUR_8 Cov_CUR_9 Cov_CUR_16 Cov_CUR_17 Cov_CUR_18 Cov_CUR_ limiter counter ASCET-SD is generating limiter code for each variable to protect overflow of physical range. the physical range is propably more narrow than the type range. limiter code uses conditional expressions. example: model code: a = b + c; generated code: tmp = b + c; a = ( tmp > a_max? a_max : ( tmp < a_min? a_min : tmp ) ); count execution of each possible position of the limiter, i.e. in the example abouve, there will be three counters: limit-low limit-max not-limiting loop counter count execution of each loop cycle if- else branches count execution of each branch, so every if and else must be measured switch- case branches ASCET-SD generates switch-case statements for statemachines. measure execution of all cases, including default case 2.4 analyse coverage regarding code optimizations the modules of the ASCET-SD experiment are used to generate code for electonic control unit (ECU). this generated code will be modified by code generation tool chain, i.e. the serial code differs to the experiment code. coverage analysis is done with the experiment code of ASCET-SD, so it must be considered Method coverage measure coverage of used methods Methods that are not removed by the optimizer are clarified as 'used Methods'. Count execution of these methods measure executions of unused methods The optimizer detects unused methods and removes them from the ECU code. If an removed method is executed in the experiment this has to be measured seperatly from the used methods 2.5 measure ressources of coverage analysis Cov_CUR_ measure time to instrument code measure delta between code generation without code instrumentation and with code instrumentation Cov_CUR_ measure ressources used in online experiment Cov_CUR_13 measure runtime delta caused by code instrumentation (counters) Cov_CUR_14 measure additional RAM required for counters Cov_CUR_15 measure additional ROM required by instumented code Abbildung 23: Customer Requirements, Teil 2, siehe auch CD

88 11 Anhang A Cov_CUR_33 Cov_CUR_34 Cov_CUR_35 Cov_CUR_19 Cov_CUR_24 3 Supported targets ASCET-SD experiments run on several targets. The following targets are used for ABS development: 3.1 offline experiment The offline experiment is executed on the PC. The offline experiment does not run in real time, i.e. it is much faster. 3.2 online experiment The online experiment is executed on the ES1130 simulation hardware. 4 Analyze measurement 4.1 online calculated coverage Cov_CUR_27 calculate coverage of branches/methods/limiters/loops in percent while the experiment is running Cov_CUR_28 calculate overall coverage. Cov_CUR_25 Cov_CUR_23 Cov_CUR_20 Cov_CUR_22 Cov_CUR_ offline analyze write a logfile while the experiment is running and analyze this logfile offline results lists of executed methods/branches/limiters/loops lists of non executed methods/branches/limiters/loops List results of the complete project List results of each method graphical presentation of results Abbildung 24: Customer Requirements, Teil 3, siehe auch CD

89 11 Anhang A ID Cov_SYR_1 Cov_SYR_10 Cov_SYR_11 System Requirements of Coverage 1 CGenCorr CGenCorr must hand over a file with informations about the optimized code to the instrumenter. 1.1 file in xml format the hand over file from CGenCorr has to be in an valid xml format 1.2 basic informations the properties of following CGenCorr activities must be included in the hand over file: Cov_SYR_2 removing uncalled functions CGenCorr is removing all functions which are never called Cov_SYR_3 outlining limiters for equal limiters a function and the function calls are created Cov_SYR_4 creating bifields several bitvariables are packed into bitfields Cov_SYR_5 inline methods methods called once a time or are very small are inlined Cov_SYR_6 2 ASCET-SD ASCET-SD is generating the code for the experiement Cov_SYR_7 2.1 starting instrumenter after code generation ASCET-SD must start the coverage tool to instrument the c-code automatically after the c- code generation is finished, but before the c-code is compiled. Cov_SYR_8 2.2 coverage modul including in ASCET-SD project coverage modul must be included in the ASCET-SD project. the coverage module contains the processes to measure and analyze the coverage and write the results. the tasks of ES 1130 must start the processes of the coverage modul in the online experiement. The processes must be added to the 'OS' tasks in ASCET-SD. Cov_SYR_ online measurement included in generated code the process for the online measurement of coverage must be included. Cov_SYR_ result writer included in generated code the process for the result outputs must be included. Cov_SYR_ logfile after experiement ASCET-SD has to write all user debug outputs, the results of the coverage analysis, in an log file Cov_SYR_ logfile must use a defined format ASCET-SD has to use a predefined format for the log file. Cov_SYR_18 3 Code intrumenter The code intrumenter gets the required information from a XML file generated by CGenCorr. Abbildung 25: System Requirements, Teil 1, siehe auch CD

90 11 Anhang A Cov_SYR_19 Cov_SYR_20 Cov_SYR_21 Cov_SYR_22 Cov_SYR_23 Cov_SYR_ standalone executable The tool to instrument code must be a standalone executable that runs without an installed environment (except ASCET-SD), i.e. for example without perl installed on the PC. 3.2 configure instrumenter The instumentation tool must be configurable: switch on/off the code instrumentation instrument only parts of the code 4 Offline analysis tool 4.1 automated execution start the tool to offline analyze the coverage date when the experiment is started. 4.2 Input Input for analysis tool is the logfile of the ASCET-SD coverage module exported with the write process. 4.3 Output Output Abbildung 26: System Requirements, Teil 2, siehe auch CD

91 11 Anhang A Abbildung 27: Projektplan, siehe auch CD

92 11 Anhang A Abbildung 28: Vergleich zwischen instrumentierter und nicht instrumentierter Quelldatei, siehe auch CD

Programmieren. Wie entsteht ein Programm

Programmieren. Wie entsteht ein Programm Wie entsteht ein Programm 1/9 1. Schritt: Programmentwurf Der wichtigste Teil beim Erstellen eines Programms ist der Programmentwurf. Dabei wird das vorgegebene Problem analysiert, es wird ermittelt, welche

Mehr

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems.

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems. Das zeitliche Verhalten von Echtzeitsoftware zu analysieren und sicher zu stellen, dass die Anforderungen an das Echtzeitverhalten erfüllt werden kann sehr aufwendig und teuer sein. In diesem Artikel sollen

Mehr

CMMI for Embedded Systems Development

CMMI for Embedded Systems Development CMMI for Embedded Systems Development O.Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree Software Engineering Gruppe Leiter des Fachbereichs Informatik cs.uni-salzburg.at Inhalt Projekt-Kontext CMMI FIT-IT-Projekt

Mehr

Absicherung von Automotive Software Funktionen

Absicherung von Automotive Software Funktionen GI Themenabend "Automotive" Absicherung von Automotive Software Funktionen 27.02.2013 Jürgen Schüling Überblick Berner & Mattner Gründung: 1979 Mitarbeiter: 400 Umsatz 2011: Standorte: Angebot: Branchen:

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Konfiguration Management System. Konfiguration Management System. Versionierung Parallele Entwicklung Workspace

Konfiguration Management System. Konfiguration Management System. Versionierung Parallele Entwicklung Workspace Konfiguration System ClearCase ClearQuest Unified Change Konfiguration System ClearCase Merkmale eines Konfiguration Systems (KM) Buildoptimierung UCM-Unified Change Der Software-sprozess Projekt definiert

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

SPS-Sensors für Paessler's PRTG White Paper

SPS-Sensors für Paessler's PRTG White Paper SPS-Sensors für Paessler's PRTG White Paper 1 Inhaltsverzeichnis Copyright... 2 1. Übersicht... 3 Voraussetzungen... 3 Die Arbeitsweise... 4 Das StarterPack... 5 Die Zugriffsmethode S7... 5 Die XML-Übergabe

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

FlexSpooler ProgramSuite 2.0

FlexSpooler ProgramSuite 2.0 FlexSpooler ProgramSuite 2.0 FlexSpooler ProgramSuite 2.0 Installationsanleitung für die kundenspezifische Integration in Insight Server für WSS 2.0 Kunde: Beispiel Datum: 15.04.2010 Aufgabenstellung Bei

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Software Engineering in

Software Engineering in Software Engineering in der Werkzeuge für optimierte LabVIEW-Entwicklung Folie 1 Best Practices Requirements Engineering Softwaretest Versionsmanagement Build- Automatisierung Folie 2 Arbeiten Sie im Team?

Mehr

[DIA] Webinterface 2.4

[DIA] Webinterface 2.4 [DIA] Webinterface 2.4 2 Inhalt Inhalt... 2 1. Einleitung... 3 2. Konzept... 4 2.1 Vorteile und Anwendungen des... 4 2.2 Integration in bestehende Systeme und Strukturen... 4 2.3 Verfügbarkeit... 5 3.

Mehr

PADS 3.0 Viewer - Konfigurationen

PADS 3.0 Viewer - Konfigurationen PADS 3.0 Viewer - Konfigurationen Net Display Systems (Deutschland) GmbH - Am Neuenhof 4-40629 Düsseldorf Telefon: +49 211 9293915 - Telefax: +49 211 9293916 www.fids.de - email: info@fids.de Übersicht

Mehr

Win7Deploy Seite 2 von 17. Was ist Win7Deploy?

Win7Deploy Seite 2 von 17. Was ist Win7Deploy? Win7Deploy Seite 1 von 17 Win7Deploy Eine einfache, passgenaue und kostengünstige Lösung um Windows 7 in Ihrem Unternehmen einzuführen [ www.win7deploy.de ] Ablauf einer Win7Deploy Installation am Beispiel

Mehr

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise A-Plan 12.0 Zeiterfassung 2.0 Ausgabe 1.1 Copyright Copyright 1996-2014 braintool software gmbh Kein Teil dieses Handbuches darf ohne ausdrückliche Genehmigung von braintool software gmbh auf mechanischem

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Handbuch zu AS Connect für Outlook

Handbuch zu AS Connect für Outlook Handbuch zu AS Connect für Outlook AS Connect für Outlook ist die schnelle, einfache Kommunikation zwischen Microsoft Outlook und der AS Datenbank LEISTUNG am BAU. AS Connect für Outlook Stand: 02.04.2013

Mehr

Java-IDE-Vergleich Seite 1 / 5

Java-IDE-Vergleich Seite 1 / 5 Java-IDE-Vergleich Seite 1 / 5 Java-IDEs im Vergleich 1. Getestete IDEs: Borland JBuilder 3 Professional Edition IBM Visual Age 3 Entry Edition Sun Forte 1.01 Community Edition Microsoft Visual J++ 6.0

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

DSLinux Skriptbasierte Inventarisierung für Linux

DSLinux Skriptbasierte Inventarisierung für Linux DSLinux Skriptbasierte Inventarisierung für Linux www.docusnap.com TITEL DSLinux AUTOR Docusnap Consulting DATUM 21.04.2015 Die Weitergabe, sowie Vervielfältigung dieser Unterlage, auch von Teilen, Verwertung

Mehr

MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20.

MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20. MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20. Februar 2008 Presenter: Neno Loje, MVP für Team System www.teamsystempro.de

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

Erste Schritte mit Eclipse

Erste Schritte mit Eclipse Erste Schritte mit Eclipse März 2008, KLK 1) Java Development Kit (JDK) und Eclipse installieren In den PC-Pools der HAW sind der JDK und Eclipse schon installiert und können mit dem Application Launcher

Mehr

Sybase Central Dokumentation Aktivierung der Monitoringfunktion

Sybase Central Dokumentation Aktivierung der Monitoringfunktion Sybase Central Dokumentation Aktivierung der Monitoringfunktion Version 1.0 14. Dezember 2012 Inhaltsverzeichnis 1 EINLEITUNG... 3 2 ZIELSETZUNG... 3 3 VORGEHENSWEISE... 3 4 ANHANG... 7 4.1 DOKUMENTHISTORIE...

Mehr

CVS-Einführung. Sebastian Mancke, mancke@mancke-software.de

CVS-Einführung. Sebastian Mancke, mancke@mancke-software.de CVS-Einführung Sebastian Mancke, mancke@mancke-software.de Grundlagen Motivation und Anforderung Sobald ein Softwaresystem anwächst, ergeben sich Probleme im Umgang mit dem Quell Code. CVS (Concurrent

Mehr

Pflichtenheft Programmanwendung "Syntax Tool"

Pflichtenheft Programmanwendung Syntax Tool Projekt: Syntax Tool Autor: Michael Rattun Home: www.mrattun.de Letzte Änderung: 27.10.2011 1 SEITE Syntax Tool Inhaltsverzeichnis Inhaltsverzeichnis 1. Zielbestimmung... 3 1.1 Muss-Kriterien (Freeware)...

Mehr

Grundlagen des Software Engineering

Grundlagen des Software Engineering Grundlagen des Software Engineering Teil 1: SW-Management Fachrichtung Wirtschaftsinformatik FB Berufsakademie der FHW Berlin Prof. Dr. Gert Faustmann Einleitung Historie des Konfigurationsmanagements:

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

Produktinformation DaVinci Developer

Produktinformation DaVinci Developer Produktinformation DaVinci Developer Inhaltsverzeichnis 1 DaVinci Developer - Entwurf von AUTOSAR Softwarekomponenten... 3 1.1 Die Vorteile von DaVinci Developer im Überblick... 3 1.2 Anwendungsgebiete...

Mehr

Einführung in PHP. (mit Aufgaben)

Einführung in PHP. (mit Aufgaben) Einführung in PHP (mit Aufgaben) Dynamische Inhalte mit PHP? 2 Aus der Wikipedia (verkürzt): PHP wird auf etwa 244 Millionen Websites eingesetzt (Stand: Januar 2013) und wird auf etwa 80 % aller Websites

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Neue Produkte 2010. Ploetz + Zeller GmbH Truderinger Straße 13 81677 München Tel: +49 (89) 890 635-0 www.p-und-z.de

Neue Produkte 2010. Ploetz + Zeller GmbH Truderinger Straße 13 81677 München Tel: +49 (89) 890 635-0 www.p-und-z.de Neue Produkte 2010 Ploetz + Zeller GmbH Truderinger Straße 13 81677 München Tel: +49 (89) 890 635-0 Ploetz + Zeller GmbH. Symbio ist eine eingetragene Marke der Ploetz + Zeller GmbH. Alle anderen Marken

Mehr

Kurzbeschreibung PC-Software für das Gerät URO-2050

Kurzbeschreibung PC-Software für das Gerät URO-2050 Kurzbeschreibung PC-Software für das Gerät URO-2050 1 Einleitung 1.1 Allgemeines Das Programm kann zum Verwalten der durchgeführten Untersuchungen mit dem Gerät URO-2050 benutzt werden. Es funktioniert

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL INGTES AG Bahnhofstr. 94 CH 5000 Aarau Tel. +4162 836 30 70 www.ingtes.com PRODUKTENTWICKLUNG NACH DEM INGTES-PROZESSMODELL 2 1 PRODUKT- ENTWICKLUNG Bei

Mehr

Methoden und Werkzeuge des Konfigurationsmanagements

Methoden und Werkzeuge des Konfigurationsmanagements Methoden und Werkzeuge des Konfigurationsmanagements Zunächst ein paar Fragen:! Was ist euer Bild des Konfigurationsmanagements?! Welche Aufgaben hat eurer Meinung nach das Konfigurationsmanagement?! Wer

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt Massive Automatisierung von Software-Tests In einem agilen Automotive Projekt Inhalt Die Projektziele Die Projektstruktur und die Rahmenbedingungen Automotive SPICE und Scrum Die Automatisierung der SW-Testfälle

Mehr

Python Programmierung. Dipl.-Ing.(FH) Volker Schepper

Python Programmierung. Dipl.-Ing.(FH) Volker Schepper Python Programmierung Kontaktdaten Homepage: http://wwwlehre.dhbw-stuttgart.de/~schepper/ Email: Volker. Schepper [A@T] yahoo.de Vorlesung Skriptsprachen Vorlesung: 06.03.2013 13.03.2013 20.03.2013 27.03.2013

Mehr

Technische Probleme lösen mit C/C++

Technische Probleme lösen mit C/C++ Technische Probleme lösen mit C/C++ Von der Analyse bis zur Dokumentation von Norbert Heiderich, Wolfgang Meyer 1. Auflage Hanser München 2010 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 446 42382

Mehr

CDT bei Bosch Rexroth (Ein Erfahrungsbericht)

CDT bei Bosch Rexroth (Ein Erfahrungsbericht) CDT bei Bosch Rexroth (Ein Erfahrungsbericht) DCC/EDF Harald Kästel-Baumgartner Agenda Firmenpräsentation Ausgangslage Zielsetzung Know How Toolchain Projektstruktur Positive und negative Erfahrung 2 Das

Mehr

CMMI und SPICE im Automotive Umfeld

CMMI und SPICE im Automotive Umfeld Vorträge 2006 CMMI und SPICE im Automotive Umfeld Inhalt Motivation Übersicht zu CMMI Anwendung in Entwicklungsprojekten Prozess Management als Lösungsansatz SPICE Motivation Jährliche Kosten für Prozessverbesserung

Mehr

Arbeitsbereich (workspace) auf Laufwerk D anlegen Dateiendung.dsw (=developer studio workbench)

Arbeitsbereich (workspace) auf Laufwerk D anlegen Dateiendung.dsw (=developer studio workbench) I Vorbereitung Rechner hochfahren C++ aufrufen II Dateien anlegen Schritt 1: Arbeitsbereich (workspace) auf Laufwerk D anlegen Dateiendung.dsw (=developer studio workbench) Inhalt: Informationen zu Benutzereinstellungen

Mehr

Vorstellung eines SAS-Makros zur Dokumentation von Programmen in Multi-User Umgebungen

Vorstellung eines SAS-Makros zur Dokumentation von Programmen in Multi-User Umgebungen Vorstellung eines SAS-Makros zur Dokumentation von Programmen in Multi-User Umgebungen Programmierung Martin Kappler BGFA Bochum Bürkle-de-la-Camp-Platz 1 44789 Bochum kappler@bgfa.de Zusammenfassung Bei

Mehr

Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 4. Juni 2007 45

Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 4. Juni 2007 45 Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 4. Juni 2007 45 7 Programmverstehen + Fehlersuche Nach einer Vorlesung von Prof. Andreas Zeller, Lehrstuhl Softwaretechnik Universität

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

Vector Software W H I T E P A P E R. Mit VectorCAST die FDA-Anforderungen an Softwaretests erfüllen

Vector Software W H I T E P A P E R. Mit VectorCAST die FDA-Anforderungen an Softwaretests erfüllen Vector Software W H I T E P A P E R Mit VectorCAST die FDA-Anforderungen an Softwaretests erfüllen Einführung Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den gesamten Software Entwicklungszyklus.

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Rhapsody in J Modellierung von Echtzeitsystemen

Rhapsody in J Modellierung von Echtzeitsystemen Rhapsody in J Modellierung von Echtzeitsystemen Tobias Schumacher tobe@uni-paderborn.de Rhapsody in J - Modellierung von Echtzeitsystemen p.1/17 Anspruch des Tools Einsatzbereiche/Features Modellierung

Mehr

Modularis Spector Datenerfassung

Modularis Spector Datenerfassung Modularis Spector Datenerfassung Version 1.1 1. Überblick Die aufgezeichneten Logdaten lassen sich über den USB-Anschluss des Modularis-Moduls abrufen. Dazu kann die hierfür entwickelte PC-Applikation

Mehr

Die Laborjournalführungs-Software professionell - zuverlässig

Die Laborjournalführungs-Software professionell - zuverlässig Produktinformation Die Laborjournalführungs-Software professionell - zuverlässig Integration von InfoChem ICEdit, ensochemeditor, MDL ISIS / Draw und CS ChemDraw Optional mit Schnittstelle zu anderen Datenbanksystemen

Mehr

Graphing - SNMP DATA - MRTG II

Graphing - SNMP DATA - MRTG II Graphing - SNMP DATA - MRTG II Netzwerkmanagement Software hat sich in den letzten Jahren vom hilfreichen Produkt zur integralen Grundlage für den professionellen IT Betrieb gewandelt. Grosse und leistungsfähige

Mehr

1. Einführung. 2. Vorbereitung zur Installation. 1.1 Eclipse

1. Einführung. 2. Vorbereitung zur Installation. 1.1 Eclipse 1. Einführung 1.1 Eclipse Die Eclipse ist eine kostenlose integrierte Entwicklungsumgebung oder auch IDE genannt, (Abkürzung IDE, engl. Integrated development enviroment). Sie ist eine grafische Benutzeroberfläche

Mehr

Java Einführung Programmcode

Java Einführung Programmcode Java Einführung Programmcode Inhalt dieser Einheit Programmelemente Der erste Programmcode Die Entwicklungsumgebung: Sun's Java Software Development Kit (SDK) Vom Code zum Ausführen des Programms 2 Wiederholung:

Mehr

Programmieren was ist das genau?

Programmieren was ist das genau? Programmieren was ist das genau? Programmieren heisst Computerprogramme herstellen (von griechisch programma für Vorschrift). Ein Computerprogramm ist Teil der Software eines Computers. Als Software bezeichnet

Mehr

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Eine große Anzahl von CRM- Projekten scheitert oder erreicht die gesetzten Ziele nicht. Die Ursachen hierfür liegen oftmals in der

Mehr

Requirement Engineering. in der Steuergeräteentwicklung

Requirement Engineering. in der Steuergeräteentwicklung Requirement Engineering in der Steuergeräteentwicklung A.User A.User IAV IAV GmbH GmbH Geschäftsfeld Geschäftsfeld Automobilelektronik Automobilelektronik Abteilung Abteilung Softwareentwicklung Softwareentwicklung

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

SDM WinLohn 2015. Inhalt. Installationsanleitung Ausgabe November 2014. Einleitung 2. Installation und Deinstallation 4. Starten des Programms 10

SDM WinLohn 2015. Inhalt. Installationsanleitung Ausgabe November 2014. Einleitung 2. Installation und Deinstallation 4. Starten des Programms 10 Installationsanleitung 1 SDM WinLohn 2015 Installationsanleitung Ausgabe November 2014 Inhalt Einleitung 2 Allgemeine Informationen... 2 Lieferumfang... 2 Systemvoraussetzungen... 3 Installation und Deinstallation

Mehr

Ein kleines Tutorial zu 1 st News, dem New sletter- Skript von Stephan Altmann

Ein kleines Tutorial zu 1 st News, dem New sletter- Skript von Stephan Altmann Ein kleines Tutorial zu 1 st News, dem New sletter- Skript von Stephan Altmann 1 Einführung 2 Voraussetzungen 3 I nstallation allgemein 4 I nstallation als Plugin für AT Contenator 5 Funktionalitäten 6

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Buzzword Bingo Game Documentation (Java based Game)

Buzzword Bingo Game Documentation (Java based Game) Buzzword Bingo Game Documentation (Java based Game) Meppe Patrick Djeufack Stella Beltran Daniel April 15, 2011 1 Inhaltsverzeichnis 1 Einleitung 3 2 Aufgabenstellung 3 3 Allgemeines zu Buzzword Bingo

Mehr

Permanente Integration Einstellung und Prozess versus Werkzeuge

Permanente Integration Einstellung und Prozess versus Werkzeuge Consulting Guild AG Methodenberatung für Projekte im 21. Jahrhundert Permanente Integration Einstellung und Prozess versus Werkzeuge Inhalt: Einleitung 1 Worum geht's hier überhaupt? 2 Überblick 2 Permanente

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

Test modellbasiert entwickelter Steuergeräte

Test modellbasiert entwickelter Steuergeräte Seite 1 von 31 26. Treffen der GI-Arbeitsgruppe Test, Analyse und Verifikation von Software Stuttgart, den 06.12.2007 Systematischer Test modellbasiert entwickelter Steuergeräte Dipl.-Ing. Matthias Wiese

Mehr

Benutzerhandbuch / Installationsanweisung

Benutzerhandbuch / Installationsanweisung Das innovative Notfall-Alarm-System für medizinische Einrichtungen Benutzerhandbuch / Installationsanweisung 1. Einleitung... 1.1 Allgemeine Hinweise zur Installation... 3 1.2 Technische Voraussetzungen...

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

Ihr Vorteil durch effizientes Testen

Ihr Vorteil durch effizientes Testen EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM XAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM M EXAM EXAM EXAM EXAM EXAM EXAM EXAM

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Willkommen zu TwinCAT 3. Die TwinCAT-3-Philosophie

Willkommen zu TwinCAT 3. Die TwinCAT-3-Philosophie Erste Schritte Willkommen zu TwinCAT 3 Mit TwinCAT 3 beginnt ein neues Zeitalter der PC-basierten Steuerungssoftware und eine neue Etappe in der Firmengeschichte der Beckhoff Automation GmbH. Besonders

Mehr

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht.

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht DRESDEN Ermitteln von Sprunghöhen mit einem Windows Phone Felix Guttbier Schule: Gymnasium Brandis Jugend forscht 2014 ERMITTELN VON SPRUNGHÖHEN

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

Software Engineering. 2. V-Modell XT

Software Engineering. 2. V-Modell XT Software Engineering 2. V-Modell XT Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement

Mehr

ISA Server 2004 - Best Practice Analyzer

ISA Server 2004 - Best Practice Analyzer ISA Server 2004 - Best Practice Analyzer Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Seit dem 08.12.2005 steht der Microsoft ISA Server 2004 Best Practice Analyzer

Mehr

Arbeiten am Client. Achtung: Während der gesamten Vorbereitungsarbeiten darf das Programm MS Outlook auf keinen Fall geöffnet werden!

Arbeiten am Client. Achtung: Während der gesamten Vorbereitungsarbeiten darf das Programm MS Outlook auf keinen Fall geöffnet werden! Microsoft Office automatisieren Um beim ersten Start eines MS Office Programms (Word, Excel,...) eines neuen Benutzers auch schon brauchbare Einstellungen von Symbolleisten, Icons,... zur Verfügung stellen

Mehr

Installation und Dokumentation. juris Autologon 3.1

Installation und Dokumentation. juris Autologon 3.1 Installation und Dokumentation juris Autologon 3.1 Inhaltsverzeichnis: 1. Allgemeines 3 2. Installation Einzelplatz 3 3. Installation Netzwerk 3 3.1 Konfiguration Netzwerk 3 3.1.1 Die Autologon.ini 3 3.1.2

Mehr

Computerpflege. Windows XP Update (Arbeitssicherheit) Dieses Programm öffnet die Internetseite von Windows. Starten Sie die [Schnellsuche].

Computerpflege. Windows XP Update (Arbeitssicherheit) Dieses Programm öffnet die Internetseite von Windows. Starten Sie die [Schnellsuche]. Computerpflege Neben dem Virus Schutz ist es sehr wichtig den PC regelmässig zu Pflegen. Es sammeln sich täglich verschiedene Dateien an die nicht wirklich gebraucht werden und bedenkenlos gelöscht werden

Mehr

Grundlagen. Kapitel 1

Grundlagen. Kapitel 1 Grundlagen Dieses Kapitel umfasst grundlegende Fragen und Aufgaben zur Erstellung von C++-Programmen. Hierzu zählen auch das Inkludieren von Header-Dateien Eine Header-Datei beinhaltet Informationen, die

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

Benutzerhandbuch. Gästebuch Software - YellaBook v1.0 http://www.yellabook.de. Stand: 01.08.2012. by YellaBook.de - Alle Rechte vorbehalten.

Benutzerhandbuch. Gästebuch Software - YellaBook v1.0 http://www.yellabook.de. Stand: 01.08.2012. by YellaBook.de - Alle Rechte vorbehalten. Benutzerhandbuch Gästebuch Software - YellaBook v1.0 http://www.yellabook.de Stand: 01.08.2012 Inhalt 1 Funktionen... 3 2 Systemanforderungen... 4 3 Installation... 4 4 Einbinden des Gästebuchs... 5 5

Mehr

ABES/Objects: Dokumentation Datensicherung

ABES/Objects: Dokumentation Datensicherung 1 Einführung 1.1 Das Problem Datenbanken lassen sich nicht mit den üblichen Verfahren sichern, da eine zentrale Vorbedingung für das direkte Sichern von Datenbanken ist, dass diese für die Dauer des Vorgangs

Mehr

Quip Trade Business Manager auf Windows Terminal Server

Quip Trade Business Manager auf Windows Terminal Server Quip Trade Business Manager auf Windows Terminal Server 2009 by Fraas Software Engineering GmbH (FSE). Arne Schmidt. Alle Rechte vorbehalten. Fraas Software Engineering GmbH Sauerlacher Straße 26 82515

Mehr

Komponenten- und ereignisorientierte Softwareentwicklung am Beispiel von Borland-Delphi

Komponenten- und ereignisorientierte Softwareentwicklung am Beispiel von Borland-Delphi Komponenten- und ereignisorientierte Softwareentwicklung am Beispiel von Borland-Delphi Dr. Henry Herper Otto-von-Guericke-Universität Magdeburg Institut für Simulation und Graphik Lisa-Weiterbildung -

Mehr

Forms2Net Die neue Migrations-Software

Forms2Net Die neue Migrations-Software Forms2Net Die neue Migrations-Software Forms2Net transportiert Ihre Oracle Forms Anwendungen perfekt nach Microsoft.NET Darauf haben viele gewartet. Vielleicht auch Sie! Forms2Net ist ein Produktpaket,

Mehr

ecotec wirtschaftliche technologien gmbh Unternehmens- und Technologieberatung

ecotec wirtschaftliche technologien gmbh Unternehmens- und Technologieberatung SW Development Management (SDM) Nicht nur im Bereich der Entwicklung von Software steigen mit Umfang und Komplexität auch die Anforderungen an Leistungsfähigkeit, Zuverlässigkeit und Sicherheit. Die Benutzung

Mehr

DIskus. E-Mail mit DISKUS. 1. Erzeugen einer E-Mail 2. Versenden der E-Mail 3. Gezippte E-Mail mit HTML-Dateien 4.

DIskus. E-Mail mit DISKUS. 1. Erzeugen einer E-Mail 2. Versenden der E-Mail 3. Gezippte E-Mail mit HTML-Dateien 4. Carl H.Hilgers Technisches Büro DIskus Mikroskopische Diskussion E-Mail mit DISKUS 1. Erzeugen einer E-Mail 2. Versenden der E-Mail 3. Gezippte E-Mail mit HTML-Dateien 4. E-Mail einrichten DISKUS kann

Mehr

Projektmanagement-Plan

Projektmanagement-Plan Applikationsentwicklung FS14 Gruppe 20 Horw, 29.05.2014 Bontekoe Christian Estermann Michael Rohrer Felix Autoren Bontekoe Christian Studiengang Informatik - Software Systems (Berufsbegleitend) Adresse

Mehr