Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
Elektronik automot ive 9 EmbEddEd-SyStEmE modifizierte Dateien beschränken Zum Problem kommt es wenn ein Satz modifizierter Dateien Header-Dateien beinhaltet die von keiner der Quelldateien in diesem Satz enthalten sind Statische Code-Analysewerkzeuge arbeiten mit Übersetzungseinheiten als Eingaben Header-Dateien allein werden nicht als gültige Eingabe für die Analyse betrachtet sondern immer im Zusammenhang mit der Quelldatei analysiert in der sie enthalten sind Oftmals enthält der automatisch eingeschränkte Analysebereich Header-Dateien die von keiner der Quelldateien im Analysebereich eingeschlossen sind Um zu verhindern dass der geänderte Header nicht analysiert wird wird eine Methode implementiert die den Analysebereich automatisch auf Quelldateien mit einer geänderten Header-Datei erweitert Getestet wurden zwei Ansätze zur automatischen Erweiterung des Analysebereichs Zunächst wurde der Analyseumfang um alle Quelldateien erweitert die eine modifizierte Header-Datei enthalten Dann wurde der Analyseumfang um eine zufällig ausgewählte Quelldatei mit einer modifizierten Header-Datei ergänzt Beim ersten Ansatz ist die Wahrscheinlichkeit geringer dass Tool-Anwender Verletzungen übersehen Dennoch kann diese Vorgehensweise die Dauer der Analysesitzungen erheblich verlängern Der zweite Ansatz birgt ein gewisses Risiko für das Übersehen eines Problems oder einer Problemgruppe Allerdings sind die Auswirkungen auf die Dauer der statischen Analysesitzung minimal und die vollständigen CI CD-Scans eliminieren das Risiko eine wichtige Verletzung zu überspringen Aus den mit der internen Code-Basis von Parasoft ausgeführten Experimenten folgt Die Strategie bei der für jede geänderte Header-Datei automatisch nur eine zufällig ausgewählte Quelldatei zum Analyseumfang hinzugefügt wird ist aus Geschwindigkeitsgründen vorzuziehen Die niedrige Anzahl von beim lokalen Scan übersehenen Verstößen wurde bei den vollständigen CI CD-Scans erfolgreich erkannt Konzentration auf neue Ergebnisse der statischen Code-Analyse Oft arbeiten Teams mit Code-Basen die die Einhaltung eines Programmierstandards wie MISRA oder AUTOSAR verlangen aber nicht von bereits bestehenden Verletzungen bereinigt wurden Das passiert gerne wenn eine neue Entwicklung auf bestehendem Code basiert wenn ein Projekt auf einem Prototyp aufsetzt der nicht im Hinblick auf Konformität entwickelt wurde oder durch die Übernahme von Drittanbieter-Code Als typisches Szenario in vielen Unternehmen wollen Entwicklerteams sicherstellen dass sie die Compliance-Schuld nicht erhöhen und der von ihnen neu programmierte Code mit dem Programmierstandard übereinstimmt Bereits bestehende Verstöße werden irgendwann korrigiert aber vorerst wollen sich die Teams auf den neuen Code konzentrieren Bereits bestehende Verstöße behindern die Produktivität der Entwickler Denn die Teammitglieder die an der neuen Funktion arbeiten oder bestehenden Code modifizieren müssen unterscheiden welche Ergebnisse der statischen Code-Analyse neu und für ihre Änderungen relevant sind und welche sie vorläufig ignorieren können Es gibt keine gute manuelle Strategie zur Unterscheidung neuer Probleme von den bereits vorhandenen Zur Fehlerbehebung modifizierte oder zur Implementierung neuer Funktionen erweiterte Dateien können zu einer Quelle neuer Verstöße werden Im Rahmen der Parasoft-Studie wurden die statischen Analyseverfahren um eine Ergebnis-Normal-Funktion erweitert Der Prototyp nutzt einen Referenzoder Normal-Bericht zur statischen Code-Analyse der den anerkannten Zustand des Projekts darstellt Ein Ergebnis-Normal lässt sich für jeden ausgewählten Zustand des Projekts erstellen beispielsweise identifiziert durch die Source Control Commit ID Der typische Anwendungsfall ist das Erstellen eines Ergebnis-Normals für die neue Funktionsverzweigung Wird die statische Code-Analyse auf der geänderten Code-Basis erneut ausgeführt erfolgt ein Vergleich der neuen Ergebnisse mit dem Normal-Bericht Alle bereits vorhandenen Probleme werden herausgefiltert sodass sich die Entwickler auf die Probleme konzentrieren können die für ihre Code-Änderungen relevant sind Der Prozess ist in Bild 2 dargestellt Das kritische Element der Funktion ist die Art des Vergleichs der Berichte Derselbe Verstoß gegen die statische Code-Analyse kann in beiden Berichten mit einer anderen Zeilennummer gemeldet werden da Code-Änderungen den Verstoß möglicherweise verlagert haben Um brauchbare Vergleiche zu erstellen wurde für die Studie mit verschiedenen Kombinationen von Verletzungsattributen experimentiert Gute Ergebnisse erzielten die IDs des Static Analysis Checkers und der Verletzungsmeldung Zur Vermeidung der unerwünschten Klassifizierung einer neuen Verletzung als eine bereits Vorhandene wurde der Vergleichsalgorithmus so eingestellt dass er Verstöße im Zweifelsfall als neu ausweist Die Rückmeldungen während der internen Tests des Prototyps sowie der externen Validierung mit Kunden waren Bild 2 Herausfiltern bereits vorhandener Ergebnisse mit Hilfe von Normal-Berichten Baseline-Reports Bild Parasoft