University, Diss., 2003--Kiel.

University, Diss., 1998--Saarbrücken.

University, Diss., 2003--Saarbrücken.

Corfu is a framework for satellite software, not only for the onboard part but also for the ground. Developing software with Corfu follows an iterative model-driven approach. The basis of the process is an engineering model. Engineers formally describe the basic structure of the onboard software in configuration files, which build the engineering model. In the first step, Corfu verifies the model at different levels. Not only syntactically and semantically but also on a higher level such as the scheduling. Based on the model, Corfu generates a software scaffold, which follows an application-centric approach. Software images onboard consist of a list of applications connected through communication channels called topics. Corfu’s generic and generated code covers this fundamental communication, telecommand, and telemetry handling. All users have to do is inheriting from a generated class and implement the behavior in overridden methods. For each application, the generator creates an abstract class with pure virtual methods. Those methods are callback functions, e.g., for handling telecommands or executing code in threads. However, from the model, one can not foresee the software implementation by users. Therefore, as an innovation compared to other frameworks, Corfu introduces feedback from the user code back to the model. In this way, we extend the engineering model with information about functions/methods, their invocations, their stack usage, and information about events and telemetry emission. Indeed, it would be possible to add further information extraction for additional use cases. We extract the information in two ways: assembly and source code analysis. The assembly analysis collects information about the stack usage of functions and methods. On the one side, Corfu uses the gathered information to accomplished additional verification steps, e.g., checking if stack usages exceed stack sizes of threads. On the other side, we use the gathered information to improve the performance of onboard software. In a use case, we show how the compiled binary and bandwidth towards the ground is reducible by exploiting source code information at run-time. / Corfu ist ein Framework für Satelliten-Software für beide Seiten: Space und Boden. Mit Corfu folgt die Softwareentwicklung einem iterativen modellgetriebenen Ansatz. Grundlage der Software-Entwicklung ist ein technisches Modell, das formell die grundlegende Struktur der Onboard-Software beschreibt. EntwicklerInnen beschreiben dieses Modell in Konfigurationsdateien, die von Corfu in verschiedenen Aspekten automatisch verifiziert werden, z.B. im Bereich des Scheduling. Anhand des definierten Modells erstellt Corfu ein Quellcode-Gerüst. Die Onboard-Software ist in einzelne Applikationen aufgeteilt, die durch Kommunikationskanäle miteinander kommunizieren (Topics genannt). Generischer Code und der generierte Code implementieren bereits die Behandlung und Verwaltung der Topic-Kommunikation, Telekommandos, Telemetrie und Threads. Der generierte Code definiert pur-virtuelle Callback-Methoden, die BenutzerInnen in erbenden Klassen implementieren. Das vordefinierte Modell kann allerdings nicht alle Implementierungsdetails der BenutzerInnen enthalten. Daher führt Corfu als Neuerung ein Code-Feedback ein. Hierbei werden anhand von statischer Analyse Informationen aus dem BenutzerInnen-Quellcode extrahiert und in einem zusätzlichen Modell gespeichert. Dieses extrahierte Modell enthält u.a. Informationen zu Funktionsaufrufen, Anomalien, Events und Stackspeicherverbrauch von Funktionen. Corfu extrahiert diese Informationen durch Quellcode- und Assembler-Analyse. Das extrahierte Modell erweitert das vordefinierte Modell, da es Elemente aus dem vordefinierten Modell referenziert. Auf der einen Seite nutzt Corfu die gesammelten Informationen, um weitere Verifikationsschritte durchführen zu können, z.B. Überprüfen der Stack-Größen von Threads. Auf der anderen Seite kann die Nutzung von Quellcode-Informationen auch die Leistung verbessern. In einem Anwendungsfall zeigen wir, wie die Größe des kompilierten Programms sowie die genutzte Bandbreite für die Übertragung von Log-Event-Nachrichten durch das erweiterte Modell verringert werden kann.

Durch die Einführung der Systemarchitektur AUTOSAR im automobilen Umfeld, können Applikationen unabhängig von der verwendeten Hardware oder der genutzten Kommunikationssysteme entwickelt werden. Dadurch können Funktionen wieder verwendet werden, was Zeit und Ressourcen einsparen kann. So können Funktionen, die sich etabliert haben, in späteren Entwicklungen durch Anpassung in der Konfiguration genutzt werden ohne dabei den Quellcode zu ändern. Jedoch stellt die große Zahl an Parametern in der AUTOSAR Architektur große Herausforderungen an die Absicherung eines Steuergerätes. Dieser Aspekt wird durch eine meist heterogene Toollandschaft verstärkt. Umso wichtiger ist es, dass während der Entwicklung von AUTOSAR Steuergeräten statische Analysen die Software und die Konfiguration überprüfen, um so die Softwarequalität sicherstellen zu können. In der Masterarbeit werden eine Menge von AUTOSAR spezifischen statischen Analysen für die einzelnen Schichten eines AUTOSAR Steuergerätes entwickelt. Für die Analyse werden Einstellungsdateien (nach Standard und Firmenspezifische) und der Quellcode an sich genutzt. Die Analysen geben optional Korrekturvorschläge an den Entwickler. Die Umsetzung erfolgt in einem C# Prototyp und wird an der Lichtsteuerung des Automotive Demonstrator YellowCar angewendet werden.

Durch die Einführung der Systemarchitektur AUTOSAR im automobilen Umfeld, können Applikationen unabhängig von der verwendeten Hardware oder der genutzten Kommunikationssysteme entwickelt werden. Dadurch können Funktionen wieder verwendet werden, was Zeit und Ressourcen einsparen kann. So können Funktionen, die sich etabliert haben, in späteren Entwicklungen durch Anpassung in der Konfiguration genutzt werden ohne dabei den Quellcode zu ändern. Jedoch stellt die große Zahl an Parametern in der AUTOSAR Architektur große Herausforderungen an die Absicherung eines Steuergerätes. Dieser Aspekt wird durch eine meist heterogene Toollandschaft verstärkt. Umso wichtiger ist es, dass während der Entwicklung von AUTOSAR Steuergeräten statische Analysen die Software und die Konfiguration überprüfen, um so die Softwarequalität sicherstellen zu können. In der Masterarbeit werden eine Menge von AUTOSAR spezifischen statischen Analysen für die einzelnen Schichten eines AUTOSAR Steuergerätes entwickelt. Für die Analyse werden Einstellungsdateien (nach Standard und Firmenspezifische) und der Quellcode an sich genutzt. Die Analysen geben optional Korrekturvorschläge an den Entwickler. Die Umsetzung erfolgt in einem C# Prototyp und wird an der Lichtsteuerung des Automotive Demonstrator YellowCar angewendet werden.

Refactoring wird angewandt, wenn eine Software-Inspektion Defekte im Programmcode feststellt. Code-Smells sind Beispiele solcher Defekte im Programmcode. Clean-Code ist ein neuerer Ansatz, der genauso wie das Code-Smell-Konzept festlegt, wann Defekte im Programmcode vorliegen. Für Code-Smells gibt es bereits zahlreiche Code-Analyse-Tools, die die automatische Erkennung solcher Defekte ermöglicht. Die vorliegende Arbeit implementiert ein Clean-Code-Analyse-Tool für Programmcode mithilfe von statischer Code-Analyse, das Refactoring-Hinweise ausgibt. Für diesen Zweck werden ein Lexer und ein Parser zur syntaktischen Analyse eines Subsets der Programmiersprache C++ implementiert. Die Evaluation durch quantitative Datenanalyse zeigt, wie nützlich die automatische Erkennung von Clean-Code mithilfe eines statischen Code-Analyse-Tools bei der Erstellung von Programmcode mit höherer Lesbarkeit für Entwicklerinnen und Entwickler ist.:Inhaltsverzeichnis 6 Abbildungsverzeichnis 9 Tabellenverzeichnis 10 Akronyme 13 1. Einleitung 14 2. Theoretische Grundlagen 17 2.1. Wichtige Begriffe und Definitionen 17 2.1.1. Software-Inspektion 17 2.1.2. Fagan-Inspektion 18 2.1.3. Checklistenbasiertes Code-Review 19 2.1.4. Statische vs. dynamische Code-Analyse-Tools 21 2.1.5. Refactoring 24 2.1.6. Code-Smells 24 2.1.7. Clean-Code 25 2.2. Code-Smell-Heuristiken im Detail 27 2.3. Einführung in den Compilerbau 32 2.3.1. Kurze Einführung in die Sprachtheorie 32 2.3.2. Die lexikalische Analyse 34 2.3.3. Die syntaktische Analyse 35 3. Forschungsstand 38 3.1. Code-Smell-Analyse-Tools auf Grundlage von Strukturinformationen 42 3.2. Code-Smell-Analyse durch maschinelles Lernen 50 3.3. Code-Smell-Suche mithilfe von Änderungsdaten 52 3.4. Code-Smell-Erkennung durch Textanalyse 54 4. Forschungsfragen und Konzeptentwicklung 56 4.1. Clean-Code: Welche Teile sind messbar? - Die Konzeptionalisierung hin zu einem maschinenlesbaren Ansatz 56 4.1.1. Größe von Entitäten im Clean-Code 57 4.1.2. Clean-Code und Zugriffsmodifikatoren 59 4.1.3. Bezeichner von Entitäten im Clean-Code 60 4.1.4. Formatierungskonventionen des Clean-Codes 62 4.1.5. Funktionsparameterübergabe im Clean-Code-Konzept 63 4.1.6. Clean-Code-Kommentare 65 4.1.7. Clean-Code — Was nicht geht 66 4.1.8. Platzierung von Entitäten im Clean-Code 67 4.2. Forschungsfragen und Hypothesen 69 5. Methodik 71 5.1. Implementierung des statischen Clean-Code-Analyse-Tools 71 5.1.1. Abhängigkeiten 72 5.1.2. Umsetzung des statischen Clean-Code-Analyse-Tools 72 5.1.3. Abhängige Variablen 78 5.2. Checklistenbasiertes Code-Review 80 5.2.1. Begründung der Methodenauswahl 80 5.2.2. Fragebogen 81 5.2.3. Unabhängige Variablen 85 5.2.4. Ablauf der Studie 86 6. Ergebnisse 87 6.1. Populationsbeschreibung 88 6.2. Deskriptive Werte der Evaluationsitems aus der Lesbarkeitsstudie 88 6.3. Deskriptive Werte der Evaluation des statischen Clean-Code-Analyse-Tools 90 6.4. Inferenzstatistik 91 7. Diskussion 96 7.1. Beantwortung der Forschungsfrage 96 7.2. Bedrohungen der Validität 97 7.3. Ausblick und Vergleich mit ähnlichen Code-Analyse-Tools 98 8. Fazit 100 Literaturverzeichnis 102 A. Anhang 112 A.1. Tabellen 112 A.2. Clean-Code Analyse-Tool Ein- und Ausgabe 124 A.3. Lesbarkeitsstudie 135 A.4. Regressionsergebnisse 144 B. CD 148 C. Selbstständigkeitserklärung 148

Die vorliegende Dissertation beinhaltet eine umfassende Untersuchung der Entscheidbarkeit und Komplexität der Probleme, die sich durch eine statische Analyse von monadischem Datalog auf endlichen gefärbten Bäumen stellen. Statische Analyse bedeutet hierbei Anfrageoptimierung ohne Blick auf konkrete Instanzen, aber mit Rücksicht auf deren zugrunde liegende Struktur. Im Kern beinhaltet dies die Lösung der drei folgenden Probleme: das Leerheitsproblem (die Frage, ob eine Anfrage auf jeder Instanz ein leeres Ergebnis liefert), das Äquivalenzproblem (die Frage, ob zwei Anfragen auf jeder Instanz das gleiche Ergebnis liefern) und das Query-Containment-Problem (die Frage, ob das Ergebnis der einen Anfrage auf jeder Datenbank im Ergebnis der anderen Anfrage enthalten ist). Von Interesse ist dabei, ob die Fragen für eine gegebene Anfragesprache entscheidbar sind und wenn ja, welche Komplexität ihnen innewohnt. Wir betrachten diese Probleme für monadisches Datalog auf unterschiedlichen Repräsentationen für endliche gefärbte Bäume. Hierbei unterscheiden wir zwischen ungeordneten und geordneten Bäumen, welche die Achsen child bzw. firstchild und nextsibling und deren Erweiterung um die descendant-Achse nutzen. Außerdem unterscheiden wir Alphabete mit und ohne Rang. Monadisches Datalog ist eine Anfragesprache, die in Abhängigkeit vom gewählten Schema die Ausdrucksstärke der monadischen Logik zweiter Stufe (MSO) erreicht und dennoch effizient ausgewertet werden kann. Wir zeigen, dass unter in der Datenbanktheorie üblichen Mengensemantik die drei genannten Probleme für alle Schemata ohne descendant-Achse EXPTIME-vollständig sind und lösbar in 2EXPTIME, falls die descendant-Achse involviert ist. Eine passende untere Schranke wird für fast alle Schemata gezeigt. Unter Multimengensemantik lassen sich die obigen Ergebnisse für das Leerheitsproblem übertragen, während das Query-Containment-Problem für alle betrachteten Schemata unentscheidbar ist. / This thesis provides a comprehensive investigation into the decidability and complexity of the fundamental problems entailed by static analysis of monadic datalog on finite labeled trees. Static analysis is used for optimizing queries without considering concrete database instances but exploiting information about the represented structure. Static analysis relies on three basic decision problems. First, the emptiness problem, whose task is to decide whether a query returns the empty result on every database. Second, the equivalence problem asking if the result of two given queries always coincides on every database. And finally, the query containment problem where it is to decide whether on every database a given query produces a subset of the results of a second given query. We are interested in finding out whether these problems are decidable and, if so, what their complexity is. We consider the aforementioned problems for monadic datalog on different representations of finite labeled trees. We distinguish unordered and ordered trees which use the axis child, as well as the axes firstchild and nextsibling, respectively. An extension of the schemas by the descendant-axis is also considered. Furthermore, we distinguish ranked and unranked labeling alphabets. Depending on the schema, the query language monadic datalog can reach the expressive power of monadic second order logic but remains efficiently evaluable. Under set semantics, we show EXPTIME-completness for all used schemas where the descendant-axis is omitted. If the descendant-axis is involved, we present an algorithm that solves the problem within 2-fold exponential time. A matching lower bound is proven for virtually all schemas. Finally, we prove that the complexity of the emptiness problem of monadic datalog on finite trees under bag semantics is the same as under set semantics. Furthermore, we show that the query containment problem of monadic datalog under bag semantics is undecidable in general.