DE112020003888T5

DE112020003888T5 - De-identifizierungscode für organisationsübergreifendes fehlerbehebungswissen

Info

Publication number: DE112020003888T5
Application number: DE112020003888.2T
Authority: DE
Inventors: Asankhaya Sharma; Hao Xiao; Hendy Heng Lee Chua; Darius Tsien Wei Foo
Original assignee: Veracode Inc
Current assignee: Veracode Inc
Priority date: 2020-11-10
Filing date: 2020-11-10
Publication date: 2022-07-21
Also published as: US20230153459A1; GB2608668A; GB202203617D0; WO2022103382A1

Abstract

Zur Wahrung des Datenschutzes beim wirksamen Einsetzen von organisationsspezifischem Fehlerbehebungswissen zur Fehlerbehebung in verschiedenen Organisationen wird der Programmcode de-identifiziert, um Code zu entfernen, der potenziell seine Quelle/Herkunft identifiziert. Die De-identifizierung erfolgt auf der Grundlage der Struktur von Fehlern und Korrekturen auf der Ebene der Quellcodekonstrukte auf der Grundlage eines abstrakten Syntaxbaums (AST) oder einer anderen strukturellen Kontextdarstellung einer Korrektur und des entsprechenden Fehlers. Potenziell identifizierende Teile einer Korrektur, die in ihrer AST angegeben sind, werden ermittelt und modifiziert (z. B. entfernt oder verschleiert), ohne die AST-Struktur zu beeinflussen. De-identifiziertes Wissen über Fehlerbehebungen, das von verschiedenen Organisationen stammt, wird dazu verwendet, ein Modell (oder Modelle) für Korrekturvorschläge zu trainieren, das (die) den strukturellen Kontext von Korrekturen und entsprechende Fehler erlernt (erlernen) und, sobald es (sie) trainiert ist (sind), Vorhersagen generiert (generieren), die vorgeschlagene Fehlerkorrekturen auf der Grundlage des strukturellen Kontexts der Fehler angeben. Die De-identifizierung kann vor dem Trainieren des Korrekturvorschlagsmodells (der Korrekturvorschlagsmodelle) oder während der Vorhersage erfolgen, so dass potenziell identifizierender Programmcode entfernt wird, bevor die vorgeschlagenen Korrekturen von den verschiedenen Organisationen genutzt werden.

Description

TECHNISCHES GEBIET
Die Offenbarung bezieht sich im Allgemeinen auf das Gebiet der Softwareentwicklung, -installation und -verwaltung sowie auf das Testen oder Debuggen.
STAND DER TECHNIK
Automatische Programmreparaturtechniken zielen darauf ab, den manuellen Debugging-Aufwand durch die Automatisierung der Patch-Generierung zu reduzieren, um Fehler zu korrigieren, die im Programmcode identifiziert wurden, z. B. solche, die mit Bugs oder Sicherheitslücken zusammenhängen. Die automatische Patch-Generierung setzt häufig die Analyse potenzieller Korrekturmuster oder hochgradiger Modifikationen am Programmcode als Ergebnis der Anwendung eines Patches wirksam ein, um diejenigen zu ermitteln, die einen identifizierten Fehler beheben können. Beim Generierungs- und Überprüfungsansatz für die automatische Patch-Generierung werden beispielsweise in Frage kommende Patches, die einer Reihe von Korrekturmustern entsprechen, auf Programmcode angewendet, der einen Fehler enthält, und das Programm wird anhand einer Reihe von Tests bewertet, um festzustellen, welcher der auf das Programm angewendeten in Frage kommenden Patches den identifizierten Fehler erfolgreich korrigiert.
Figurenliste
Durch Verweis auf die beigefügten Zeichnungen werden Ausführungsformen der Offenbarung besser verstanden.

1 ist ein Systemdiagramm, das einen Fehlerbehebungsdienst veranschaulicht, der de-identifizierte Korrekturvorschläge für in einem Softwareprojekt identifizierte Fehler liefert.
2 zeigt ein beispielhaftes konzeptionelles Diagramm für das Trainieren einer Korrekturvorschlagspipeline mit de-identifizierten Fehler-/Korrektur-Trainingsdaten.
3 zeigt ein beispielhaftes konzeptionelles Diagramm zur Bestimmung von Korrekturvorschlägen für Fehler auf der Grundlage der Ausgabe einer trainierten Korrekturvorschlagspipeline und zur De-identifizierung der Korrekturvorschläge.
4 ist ein Flussdiagramm von Beispieloperationen zur De-identifizierung von Code für organisationsübergreifendes Fehlerbehebungswissen.
5 ist ein Flussdiagramm von Beispieloperationen für das Trainieren einer Korrekturvorschlagspipeline, die de-identifizierte Korrekturvorschläge für Codefehler erzeugt.
6 ist ein Flussdiagramm mit Beispieloperationen zur Gewinnung und De-identifizierung von Korrekturvorschlägen aus einer trainierten Korrekturvorschlagspipeline.
Die 7 und 8 sind Flussdiagramme mit Beispieloperationen zur De-identifizierung einer Korrektur auf der Grundlage ihrer strukturellen Darstellung.
9 zeigt ein Beispiel für ein Computersystem mit einem Fehlerbehebungsdienst, der einen Code-De-Identifikator enthält.

BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
Die nachfolgende Beschreibung enthält beispielhafte Systeme, Verfahren, Techniken und Programmabläufe, die Aspekte der Offenbarung verkörpern. Es versteht sich jedoch, dass diese Offenbarung auch ohne diese spezifischen Details ausgeführt werden kann. So bezieht sich die vorliegende Offenbarung z. B. auf abstrakte Syntaxbäume als Veranschaulichungsbeispiele für eine Datenstruktur, die den strukturellen Kontext von Programmcode erfasst. Bei Aspekten der vorliegenden Offenbarung können andere Zwischendarstellungen wie etwa ein Steuerungsablaufgraph verwendet werden, um den strukturellen Kontext von Programmcode auszudrücken oder zu beschreiben. In anderen Fällen sind bekannte Befehlsinstanzen, Protokolle, Strukturen und Techniken nicht im Detail dargestellt worden, damit die Beschreibung nicht unübersichtlich wird.
Übersicht
Das von einer bestimmten Organisation gesammelte Wissen über die Behebung von Fehlern kann nützlich sein, um in anderen Organisationen über Korrekturvorschläge für in Programmcode identifizierte Fehler zu informieren. Der Programmcode, der den Korrekturen (d.h. Patches) zugeordnet ist, kann jedoch Informationen enthalten, die proprietär, sensibel oder anderweitig privat für die Organisation sind. So können beispielsweise die im Programmcode der Organisation verwendeten Namenskonventionen proprietäre Informationen wiedergeben. Daher können Korrekturen, die bei einer Überprüfung und Analyse des Programmcodes einer Organisation identifiziert werden, nicht an Mitglieder externer Organisationen weitergegeben werden, ohne dass die Gefahr besteht, dass die privaten Informationen der Ursprungsorganisation weitergegeben werden.
Es wurde eine Technik zur De-identifizierung von Programmcode unter Beibehaltung der zugrundeliegenden Struktur entwickelt, die das Problem der Wahrung des Datenschutzes bei der Nutzung von organisationsspezifischem Fehlerbehebungswissen zur Behebung von Fehlern in verschiedenen Organisationen löst. Die De-identifizierung von Programmcode kann als Entfernen von Merkmalen betrachtet werden, die die Organisation identifizieren können, von der der Programmcode stammt. Gesammeltes und de-identifiziertes Wissen über eine Fehlerbehebung, das aus verschiedenen Organisationen stammt, oder organisationsübergreifendes Wissen über eine Fehlerbehebung kann dazu verwendet werden, ein Modell (Modelle) für Korrekturvorschläge zu trainieren, das aus dem strukturellen Kontext von Korrekturen und entsprechender Fehler lernt. Die von dem trainierten Korrekturvorschlagsmodell generierten Vorhersagen geben vorgeschlagene Korrekturen für Fehler an, die im Programmcode auf der Grundlage des strukturellen Kontexts der Fehler identifiziert wurden, wobei die vorgeschlagenen Korrekturen de-identifizierte Korrekturen enthalten können, die von einer beliebigen Ursprungsorganisation erlernt wurden. Vorgeschlagene Korrekturen können somit unabhängig von der Quelle/Herkunft der Korrekturen organisationsübergreifend zur Fehlerbehebung eingesetzt werden, ohne dass private Informationen, die sich möglicherweise im Programmcode widerspiegeln, weitergegeben werden.
Die hier offenbarte De-identifizierung von Programmcode erfolgt basierend auf der Struktur von Fehlern und Korrekturen, wobei die Struktur des Programmcodes in Form eines abstrakten Syntaxbaums (AST) oder einer anderen strukturellen Darstellung definiert werden kann, die den strukturellen Kontext eines Fehlers oder eines Fehlers und seiner entsprechenden Korrektur angibt. Die De-identifizierung kann daher auf der Ebene einzelner Konstrukte im Quellcode erfolgen, die in einer strukturellen Kontextdarstellung des Quellcodes, z. B. eines AST, dargestellt sind. Diese niedrigere Granularität, auf der Programmcode de-identifiziert wird, bietet die Beibehaltung der Struktur des Programmcodes, die andernfalls verloren gehen könnte, wenn etwa der Code stattdessen auf der Ebene der Zeilennummern de-identifiziert würde. Die Code-De-identifizierung wird dadurch erreicht, dass potenziell identifizierende Teile einer Korrektur ermittelt werden, die aus dem Programmcode einer Organisation erfasst werden, der in der zugehörigen strukturellen Kontextdarstellung angegeben ist, und der potenziell identifizierende Code in einer von mehreren Stufen entfernt, verschleiert oder anderweitig modifiziert wird, bevor die Korrektur als Vorschlag präsentiert wird. Potenziell identifizierender Code kann Programmcode sein, der nicht mit bekannten oder öffentlich zugänglichen Codeeinheiten/-elementen übereinstimmt, z. B. Standardbibliotheken oder Open-Source-Bibliotheken, oder von einer Organisation verwendete Namenskonventionen. Nachdem der potenziell identifizierende Code auf der Grundlage der strukturellen Kontextdarstellung, die einer Korrektur zugeordnet ist, ermittelt wurde, kann der ermittelte Code in einer Weise geändert werden, die sich nicht auf die Gesamtstruktur des Programmcodes der Korrektur auswirkt, d. h. die Struktur, die der strukturellen Kontextdarstellung zugrunde liegt, bleibt als Ergebnis der De-identifizierung der Korrektur unverändert. Die De-identifizierung kann entweder vor dem Trainieren des Korrekturvorschlagsmodells/der Korrekturvorschlagsmodelle oder während der Vorhersage erfolgen. Wenn die De-identifizierung vor dem Trainieren durchgeführt wird, können Fehler und entsprechende Korrekturen vorverarbeitet werden, um sensiblen Code zu de-identifizieren, während die Fehler und Korrekturen für die Verwendung als Trainingsdaten vorbereitet werden. Das/die Korrekturvorschlagsmodell(e) wird/werden somit auf de-identifizierten Fehlern und Korrekturen trainiert. Bei der De-identifizierung während der Vorhersage werden die von dem trainierten Korrekturvorschlagsmodell ausgegebenen Korrekturvorhersagen de-identifiziert, bevor die Korrekturvorhersagen als Vorschläge präsentiert werden. In beiden Fällen wird der potenziell identifizierende Code modifiziert, so dass quellenidentifizierende Informationen wie Informationen, die eine Organisation identifizieren, entfernen werden, bevor die Korrekturen von Nutzern in verschiedenen Organisationen genutzt werden, so dass das organisationsübergreifend gewonnene Wissen über Fehlerbehebungen dazu verwendet werden kann, sowohl organisationsinterne als auch organisationsübergreifende Korrekturvorschläge zu machen, ohne den organisatorischen Datenschutz zu gefährden.
Beispielhafte Veranschaulichungen
1 ist ein Systemdiagramm, das einen Fehlerbehebungsdienst veranschaulicht, der de-identifizierte Korrekturvorschläge für in einem Softwareprojekt identifizierte Fehler liefert. In 1 ist ein Fehlerbehebungsdienst 119 dargestellt, der mit einem in der Pipeline integrierten Agenten kommuniziert. Auch wenn die Ausführungsformen mit verschiedenen Arten von Softwareentwicklungspipelines verwendet werden können, wird in 1 eine Pipeline 107 für kontinuierliche Integration (engl. Continuous Integration - Cl) als beispielhafte Pipeline für die Veranschaulichung verwendet. Die Cl-Pipeline 107 ist mit einem Software-Entwicklungswerkzeug 105 implementiert. Ein Agent 117 kann ein in das Software-Entwicklungswerkzeug 105 integrierter Programmcode sein oder von dem Software-Entwicklungswerkzeug 105 aus aufgerufen werden, z. B. über eine Anwendungsprogrammierschnittstelle (API). Der Fehlerbehebungsdienst 119 kommuniziert mit dem Agenten 117 als Teil der Bereitstellung von de-identifizierten Korrekturvorschlägen.
Während eines Softwareprojekts übermitteln die Entwickler/Ingenieure Codeänderungen über ein Software-Entwicklungswerkzeug, das eine definierte Entwicklungspipeline implementiert. 1 zeigt einen einzelnen Fall eines Entwicklers 101, der eine Codeänderung 102 für ein Softwareprojekt mit dem Software-Entwicklungswerkzeug 105 vorlegt, das die Cl-Pipeline 107 implementiert. Das Vorlegen einer Codeänderung kann in Abhängigkeit von dem verwendeten Software-Entwicklungswerkzeug ein Commit, Merge, Push usw. sein. Bei der Codeänderung 102 kann es sich um Programmcode handeln, der dem Softwareprojekt hinzugefügt wird, oder um eine Überarbeitung/Bearbeitung des im Softwareprojekt vorhandenen Programmcodes. Das Vorlegen der Codeänderung 102 löst die Ausführung der Cl-Pipeline 107 aus, wie in einer Pipeline-Konfigurationsdatei definiert. Die Cl-Pipeline 107 wurde so definiert, dass sie zumindest eine Scanstufe umfasst, die nach der Build- und der Testphase stattfindet. Die Scanstufe ruft einen Schwachstellen-Scanner 113 auf.
Der Agent 117 arbeitet mit den Scan-Ergebnissen des Schwachstellen-Scanners 113, um Korrekturvorschläge für erkannte Fehler zu erhalten. Eine anfängliche Eingabe in den Schwachstellen-Scanner 113 wird in 1 als Programmcode 103A bezeichnet. Bei dem Programmcode 103A kann es sich um die Codeänderung 102, eine Zwischendarstellung der Codeänderung 102 oder eine Zwischendarstellung zumindest eines Teils des Softwareprojekts mit integrierter Codeänderung 102 handeln. Die Eingabe des Programmcodes 103A in den Schwachstellen-Scanner 113 erzeugt Scan-Ergebnisse 115A. Die Scan-Ergebnisse 115A zeigen einen oder mehrere Fehler (z. B. Schwachstellen) an. Der Agent 117 erhält Korrekturvorschläge für die in den Scan-Ergebnissen 115A identifizierten Fehler durch Zusammenwirkung mit dem Fehlerbehebungsdienst 119. Der Agent 117 kommuniziert mit dem Fehlerbehebungsdienst 119 oder gibt die Fehler darin ein, um mögliche Korrekturen zu erhalten, die von einem oder mehreren trainierten Modellen 127 ausgegeben werden. Der Fehlerbehebungsdienst 119 umfasst die trainierten Modelle 127, ein Repository 123 mit Trainingsdaten zu Fehlern/Korrekturen mehrerer Organisationen und einen Modelltrainer 125. Die trainierten Modelle 127 wurden mit Fehler-/Korrektur-Trainingsdaten aus dem Repository 123 trainiert. Die organisationsübergreifenden Fehler-/Korrektur-Trainingsdaten basieren auf Daten aus verschiedenen Quellen, wie etwa Open-Source-Software-Repositories, Peer-Organisationen usw. Um das Trainieren mit den organisationsübergreifenden Trainingsdaten zu ermöglichen, ohne proprietäre Informationen preiszugeben, verwendet der Modelltrainer 125 einen Code-De-Identifikator 126. Der Code-De-Identifikator 126 ermittelt und modifiziert Programmcode, der potenziell seine Ursprungsorganisation oder die Eigentümer-/Kontrollorganisation des Softwareprojekts, die die Quelle des Programmcodes ist, identifiziert. Die Änderung des Programmcodes bezieht sich auf die Änderung des Programmcodes, um die Informationen zur Identifizierung der Quelle/Organisation zu entfernen. Beispielsweise kann ein Element des Programmcodes, das Informationen zur Identifizierung seiner Quelle (z. B. seiner Ursprungsorganisation) enthält, durch Entfernen und optionales Ersetzen des Codeelements durch eine andere Darstellung (z. B. einen generischen Identifikator oder eine andere abstrakte Darstellung) oder durch Verschleiern des Codeelements geändert werden.
Nachdem der Agent 117 die potenziellen Korrekturen für die verbleibenden Fehler erhalten hat, präsentiert er die potenziellen Korrekturen als vorgeschlagene Korrekturen 135. Bei den vorgeschlagenen Korrekturen 135 wurde potenziell sensibler, privater oder anderweitig proprietärer Programmcode modifiziert, um eine de-identifizierte Darstellung des Programmcodes als Ergebnis davon zu erzeugen, dass der Modelltrainer 125 den Code-De-Identifkator 126 zur De-Identifizierung von Trainingsdaten verwendet hat, die zur Erzeugung der trainierten Modelle 127 verwendet wurden. Die vorgeschlagenen Korrekturen 135 können daher organisationsübergreifende Korrekturen, organisationsinterne Korrekturen oder eine Kombination davon umfassen. Die Präsentation der vorgeschlagenen Korrekturen 135 kann auf unterschiedliche Weise erfolgen. Der Agent 117 kann die Scan-Ergebnisse 115A aktualisieren, so dass sie die vorgeschlagenen Korrekturen 135 aufzunehmen. Der Agent 117 kann die vorgeschlagenen Korrekturen 135 in Verbindung mit den entsprechenden verbleibenden Fehlern an die Instanz des Software-Entwicklungswerkzeugs 105 weitergeben, die von dem Entwickler 101 verwendet wird. Der Agent 117 kann seine eigene Benutzerschnittstelle haben und die vorgeschlagenen Korrekturen 135 selbst präsentieren. In einigen Implementierungen kann der Agent 117 die Informationen speichern oder eine Benachrichtigung über die vorgeschlagenen Korrekturen 135 erzeugen.
Der Fehlerbehebungsdienst 119 kann auch mit dem Agenten 117 kommunizieren, um den Aufbau des Repository 123 zu erleichtern. Der Agent 117 kann dem Fehlerbehebungsdienst 119 Trainingsdaten zur Verfügung stellen, die auf der Verwendung von vorgeschlagenen Korrekturen basieren, die er von dem Fehlerbehebungsdienst 119 erhalten hat, wie etwa die vorgeschlagenen Korrekturen 135 oder andere in Frage kommende Korrekturen, die angewandt und für erfolgreich befunden wurden. Nachdem die vorgeschlagenen Korrekturen 135 von dem Fehlerbehebungsdienst 119 erhalten wurden, kann der Agent 117 beispielsweise die in den Scan-Ergebnissen 115A angezeigten Fehler in Verbindung mit den vorgeschlagenen Korrekturen präsentieren. Der Agent 117 erkennt dann, welche vorgeschlagenen Korrekturen zur Verwendung ausgewählt wurden, und kennzeichnet diese für das überwachte Trainieren. Alternativ oder zusätzlich kann der Agent 117 andere von dem Entwickler 101 identifizierte Fehler/Korrekturdaten für das überwachte Trainieren kennzeichnen, auf der Grundlage, dass der Entwickler 101 auf ein Commit-Log oder andere historische Informationen zugreift, die von dem Software-Entwicklungswerkzeug 105 verwaltet werden, und Korrekturen und entsprechende Fehler identifiziert (z. B. wenn der Entwickler 101 feststellt, dass ein zuvor identifizierter Fehler behoben wurde). Der Agent 117 kann die gekennzeichneten Trainingsdaten an den Fehlerbehebungsdienst 119 übermitteln, damit sie in einer konfigurierten Kadenz (z. B. alle n Commits, jede Auswahl usw.) in das Repository 123 eingefügt werden. Gekennzeichnete Trainingsdaten, die an den Fehlerbehebungsdienst 119 übermittelt werden, können einer zusätzlichen Kennzeichnung, einem Tag, einem Identifikator usw. zugeordnet werden, die/der die Ursprungsorganisation der Trainingsdaten angibt. Jeder Eintrag im Repository 123 für Fehler-/Korrekturdaten gibt somit seine Ursprungsorganisation auf der Grundlage der zugehörigen Kennzeichnung, des zugehörigen Tags, des zugehörigen Identifikators usw. an.
Während 1 den Modelltrainer 125 zeigt, der den Code-De-Identifikator 126 aufruft, um die aus dem Repository 123 abgerufenen Fehler/Korrektur-Trainingsdaten zu de-identifizieren, ruft der Fehlerbehebungsdienst 119 in anderen Implementierungen den Code De-Identifikator 126 auf, um die von den trainierten Modellen 127 ausgegebenen potenziellen Korrekturen zu de-identifizieren, bevor die Korrekturen als Vorschläge präsentiert werden. Der Code-De-Identifikator 126 kann somit während der Vorverarbeitung der Trainingsdaten für korrigierte Fehler, die zur Erstellung der trainierten Modelle 127 verwendet werden (wie in 1 dargestellt), oder nach der Ausgabe potenzieller Korrekturen durch die trainierten Modelle 127 nach einer Anfrage nach prognosebasierten Korrekturvorschlägen genutzt werden. Diese Implementierungen werden mit Bezug auf 2 bzw. 3 ausführlicher beschrieben.
2 zeigt ein beispielhaftes konzeptionelles Diagramm für das Trainieren einer Korrekturvorschlagspipeline mit de-identifizierten Fehler-/Korrektur-Trainingsdaten. Ein Fehlerbehebungsdienst 219 verwaltet das Repository 123 mit organisationsübergreifenden Fehler-/Korrektur-Trainingsdaten. Der Fehlerbehebungsdienst 219 umfasst auch einen Modelltrainer 225, der eine Modellpipeline 231 für maschinelles Lernen, die aus einem oder mehreren Modellen für maschinelles Lernen besteht, oder die „Korrekturvorschlagspipeline 231“ mit Trainingsdaten aus dem Repository 123 trainiert, um eine trainierte Korrekturvorschlagspipeline 215 zu erzeugen. Der Modelltrainer 225 verwendet den Code-De-Identifikator 126, um die aus dem Repository 123 erhaltenen Trainingsdaten zu de-identifizieren. Der Agent 117 kommuniziert mit dem Fehlerbehebungsdienst 219, so dass dem Fehlerbehebungsdienst 219 gekennzeichnete Trainingsdaten 241 zum Einfügen in das Repository 123 bereitgestellt werden, wie in ähnlicher Weise oben beschrieben.
2 ist mit einer Reihe von Buchstaben A-E versehen. Diese Buchstaben stehen für Arbeitsstufen. Obwohl diese Stufen für dieses Beispiel geordnet sind, veranschaulichen die Stufen ein Beispiel zum besseren Verständnis der vorliegenden Offenbarung und sollten nicht zur Einschränkung der Ansprüche verwendet werden. Der Gegenstand, der in den Umfang der Ansprüche fällt, kann hinsichtlich der Reihenfolge und einiger Operationen variieren.
In Stufe A ruft der Modelltrainer 225 gekennzeichnete Trainingsdaten aus dem Repository 123 ab. Der Modelltrainer 225 ruft Fehler-/Korrekturdaten 227 ab, die eine oder mehrere Quellcodedatei(en) eines Fehlers und eine oder mehrere Quellcodedatei(en) seiner entsprechenden Korrektur umfassen können. Zu den aus dem Repository 123 abgerufenen Trainingsdaten können Fehler-/Korrekturdaten gehören, die aus einem Softwareprojekt im Besitz einer bestimmten Organisation oder einem Open-Source-Software-Repository stammen. Den im Repository 123 gespeicherten Trainingsdaten, die aus dem Programmcode eines Softwareprojekts stammen, das einer Organisation gehört, kann eine Kennung (ID) zugewiesen werden, die die jeweilige Ursprungsorganisation bei der Erfassung durch den Agenten 117 oder beim Einfügen in das Repository 123 eindeutig identifiziert. In diesem Beispiel sind die Fehler-/Korrekturdaten 227 einer Ursprungsorganisation mit einer Organisations-ID von 217 zugeordnet.
In Stufe B ruft der Modelltrainer 225 einen Trainingsdaten-Präprozessor 203 dazu auf, die Fehler-/Korrekturdaten 227 vorzuverarbeiten. Der Trainingsdaten-Präprozessor 203 verarbeitet die Fehler-/Korrektur-Trainingsdaten vor, so dass die Daten in ein Format umgewandelt werden, das als Eingabe für die Korrekturvorschlagspipeline 231 zum Trainieren verwendet werden kann. Die Vorverarbeitung von Fehler-/Korrekturdaten umfasst die Bestimmung des strukturellen Kontexts des Fehlers und der entsprechenden Korrektur, wobei der strukturelle Kontext auf der Grundlage der Erzeugung eines AST für den Fehler und die Korrektur bestimmt werden kann. Der Trainingsdaten-Präprozessor 203 verwendet einen AST-Generator 229, um den AST auf der Grundlage der Bestimmung eines Unterschieds zwischen dem Quellcode des Fehlers und dem Quellcode der Korrektur zu erzeugen und einen AST diff 207 auf der Grundlage des resultierenden Unterschieds zwischen dem jeweiligen Quellcode des Fehlers und der Korrektur zu erzeugen. Der von dem AST-Generator 229 erzeugte AST wird hier als „AST diff“ bezeichnet, da er im Allgemeinen mit der Code-Diff übereinstimmt, die sich aus der Bestimmung des Unterschieds zwischen dem Fehlerquellcode und dem Korrekturquellcode ergibt. Der AST diff 207 umfasst mehrere Knoten, die Quellcodekonstrukten entsprechen und Ergänzungen oder Löschungen anzeigen können, die als Ergebnis der Anwendung der Korrektur auf den Fehler am Quellcode vorgenommen wurden. In diesem Beispiel enthält der AST diff 207 einen Knoten 205 und einen Knoten 209, die Konstrukte angeben, die hinzugefügt wurden, und einen Knoten 211, der ein Konstrukt angibt, das gelöscht wurde. Die Werte der Quellcodekonstrukte für jeden Knoten (z. B. die entsprechende Syntax) können in den Knoten des AST diff 207 als Knoteneigenschaft, Attribut usw. angegeben werden. Der Trainingsdaten-Präprozessor 203 kann dem AST diff 207 eine ID zuweisen, die die durch die Fehler-/Korrekturdaten 227 dargestellte Korrektur identifiziert, und den AST diff 207 in ein Repository 235 einfügen, das zum Speichern von während des Trainierens erzeugten AST diffs unterhalten wird.
In Stufe C erhält der Code-De-Identifikator 126 den AST diff 207 und de-identifiziert potenziell identifizierende Merkmale der Fehler/Korrekturdaten 227, die von den Knoten des AST diff 207 angegeben werden. Der Code-De-Identifikator 126 nutzt die Regeln 221 zur Bestimmung von Code, der sensibel, proprietär oder anderweitig potenziell die Ursprungsorganisation der ausgewerteten Fehler-/ Korrekturdaten 227 identifiziert. Die Regeln 221 geben Kriterien zur Bestimmung an, ob ein von einem Knoten des AST diff 207 angegebenes Quellcodekonstrukt einem potenziell identifizierenden Code entspricht. Die Kriterien können den Typ, den Ursprung und/oder andere Merkmale von Quellcodekonstrukten umfassen, die das Konstrukt potenziell identifizierend für seine Ursprungsorganisation machen. Die Regeln 221 können z. B. vorschreiben, dass Quellcodekonstrukte, die nicht öffentlich zugänglichen Codeelementen/-einheiten (z. B. Open-Source-Codeeinheiten, Standard-Codeeinheiten usw.) entsprechen, als potenziell identifizierend betrachtet werden sollten. Alternativ oder zusätzlich können die Regeln 221 darauf hinweisen, dass Namenskonventionen, z. B. Namen, die Variablen, Klassen, Routinen/Subroutinen oder anderen Konstrukten zugewiesen sind, potenziell identifizierende Merkmale sind. Um die Quellcodekonstrukte der Fehler-/Korrekturdaten 227 zu bestimmen, die potenziell identifizierenden Code enthalten, wertet der Code-De-Identifikator 126 die Knoten des AST diff 207 anhand der Regeln 221 aus und bestimmt, welche davon potenziell identifizierendem Code entsprechen, basierend darauf, dass er mindestens eine erste der Regeln 221 erfüllt. Der Code-De-Identifikator 126 kann z. B. über jeden der Knoten der AST diff 207 iterieren und ein Attribut oder einen Eigenschaftswert (Eigenschaftswerte) des Knotens anhand der Regeln 221 auswerten, um festzustellen, ob das durch den Knoten dargestellte Quellcodekonstrukt eine erste Regel der Regeln 221 erfüllt. Knoten, bei denen der Code-De-Identifikator 126 feststellt, dass sie eine der Regeln 221 erfüllen, werden für die De-Identifizierung des entsprechenden Quellcodes ausgewählt. In diesem Beispiel stellt der Code-De-Identifikator 126 fest, dass der Knoten 205 und ein Knoten 213 die Regeln 221 erfüllen und somit einem potenziell identifizierenden Code entsprechen.
Um den den Knoten 205, 213 entsprechenden Quellcode zu de-identifizieren, modifiziert der Code-De-Identifikator 126 den dem Knoten entsprechenden Quellcode. Die Änderung des Quellcodes führt zu einer de-identifizierten Darstellung des Quellcodes oder zu einer Darstellung, bei der die potenziell identifizierenden Elemente/Konstrukte des Codes entfernt wurden. Die Art und Weise, in der der Quellcode geändert wird, kann durch eine Reihe von De-Identifizierungsrichtlinien spezifiziert werden, die in den Regeln 221 angegeben sind, die dem Code-De-Identifikator 126 beigefügt sind (z. B. darauf installiert sind oder andere Weise für ihn zugänglich sind), usw. So kann der Code beispielsweise geändert werden, indem ein allgemeiner Identifikator bestimmt wird, der den Typ des jeweiligen Konstrukts angibt, und das Konstrukt durch den allgemeinen Identifikator ersetzt wird. Als weiteres Beispiel kann der Code durch Verschleierung geändert werden, z. B. durch Ersetzen des Codes durch eine zufällig generierte Zeichenkette. Die De-identifizierung des durch die Knoten 205, 213 dargestellten Codes erzeugt einen de-identifizierten AST diff 233, in dem die potenziell identifizierenden Merkmale, die in dem AST diff 207 angegeben waren, entfernt wurden. Die De-Identifizierung von potenziell identifizierendem Code auf der Ebene einzelner Quellcode-Konstrukte, die in dem AST diff 207 dargestellt sind, erhält die Struktur der Fehler/Korrekturdaten 227, da der Code-De-Identifikator 126 die Struktur des AST diff 207 bei der De-Identifizierung des Quellcodes nicht verändert, d. h. der AST diff 207 und der de-identifizierte AST diff 233 haben die gleiche Struktur.
In Stufe D fügt der Code-De-Identifikator 126 Zuordnungen 201, die eine Angabe des de-identifizierten Quellcodes, der den Knoten 205, 213 entspricht, mit einer Angabe ihrer jeweiligen ursprünglichen Darstellungen assoziiert, in ein Repository 239 von de-identifizierten Code-Zuordnungen ein. Das Repository 239 speichert Zuordnungen zwischen geänderten und ursprünglichen Versionen von Programmcode, der als potenziell identifizierend für seine Ursprungsorganisation bestimmt wurde. Das Repository 239 kann nach Organisations-ID indiziert werden, oder die Einträge im Repository 239 können auf der Grundlage der Organisations-ID gekennzeichnet werden. Die Zuordnungen 201 können z. B. jeweils eine Organisations-ID und eine Konstrukt-ID sowie eine Angabe des ursprünglichen und des de-identifizierten Codes enthalten. Durch das Speichern von Zuordnungen zwischen ursprünglichen und de-identifizierten Fehler-/ Korrekturinformationen können, wenn eine de-identifizierte Korrektur für einen Fehler vorgeschlagen wird, der in einem Code auftritt, der zu seiner Ursprungsorganisation gehört (d. h., die Korrektur ist eine organisationsinterne Korrektur), die ursprüngliche(n) Darstellung(en) des de-identifizierten Teils bzw. der de-identifizierten Teile der Korrektur anstelle der de-identifizierten Darstellung angezeigt werden, um das Verständnis der vorgeschlagenen Korrekturen durch die Benutzer, die die Vorschläge nutzen, und die Einbindung der vorgeschlagenen Korrekturen in das Softwareprojekt zu erleichtern, wenn ein organisationsinterner Korrekturvorschlag ausgewählt wird. Der Fehlerbehebungsdienst 219 könnte z. B. so konfiguriert sein, dass er Originaldarstellungen von Korrekturvorschlägen präsentiert, die aufgrund des Zugriffs auf das Repository 239 als organisationsinterne Korrekturen ermittelt wurden, bevor die Korrekturvorschläge an den Agenten 117 zurückgegeben werden.
In Stufe E stellt der Modelltrainer 225 den de-identifizierten AST diff 233 als Eingabe für die Korrekturvorschlagspipeline 231 zum Trainieren bereit. Da die Struktur der AST diff 207 von den Operationen des Code-De-Identifikators 126, der den de-identifizierten AST diff 233 erzeugt hat, nicht verändert wurde, kann der Modelltrainer 225 die Korrekturvorschlagspipeline 231 so trainieren, dass sie den strukturellen Kontext von Fehlern und ihren Korrekturen lernt, etwa die Fehler-/ Korrekturdaten 227, im Gegensatz zur spezifischen Syntax von Fehlern und Korrekturen. Der Modelltrainer 225 kann damit fortfahren, Fehler-/Korrekturdaten aus dem Repository 123 abzurufen, einen AST diff auf der Grundlage der Trainingsdaten zu erzeugen, die Fehler-/Korrekturdaten auf der Grundlage des AST diff zu de-identifizieren, wenn die Regeln 221 erfüllt sind, und den de-identifizierten AST diff als Eingabe in die Korrekturvorschlagspipeline 231 bereitzustellen, bis ein oder mehrere Trainingskriterien erfüllt sind, um die trainierte Korrekturvorschlagspipeline 215 zu erhalten. Da der Modelltrainer 225 die Korrekturvorschlagspipeline 231 auf der Grundlage von AST trainiert, die de-identifiziert wurden, erzeugt die trainierte Korrekturvorschlagspipeline 215 Vorhersagen, die de-identifizierten Korrekturen entsprechen. Vorgeschlagene Korrekturen, die auf der Grundlage der Ausgabe der trainierten Korrekturvorschlagspipeline 215 ausgewählt wurden, können somit Benutzern in jeder Organisation präsentiert werden, unabhängig von der/den Ursprungsorganisation(en) der vorgeschlagenen Korrekturen.
3 zeigt ein Beispiel für ein konzeptionelles Diagramm zur Bestimmung von Korrekturvorschlägen für Fehler auf der Grundlage einer Ausgabe einer trainierten Korrekturvorschlagspipeline und zur De-Identifizierung der Korrekturvorschläge. Ein Fehlerbehebungsdienst 319 verwaltet das Repository 123 mit organisationsübergreifenden Fehler-/Korrektur-Trainingsdaten. Der Fehlerbehebungsdienst 319 umfasst auch einen Modelltrainer 325, der eine Korrekturvorschlagspipeline 331 mit Trainingsdaten aus dem Repository 123 trainiert, um eine trainierte Korrekturvorschlagspipeline 315 zu erzeugen. Der Agent 117 kommuniziert mit dem Fehlerbehebungsdienst 319, um vorgeschlagene Korrekturen für einen oder mehrere Fehler zu erhalten, indem er den Programmcode der Fehler als Eingabe für die trainierte Korrekturvorschlagspipeline 315 bereitstellt. Der Fehlerbehebungsdienst 319 verwendet den Code-De-Identifikator 126 zur De-Identifizierung von von der trainierten Korrekturvorschlagspipeline 315 ausgegebenen vorgeschlagenen Korrekturen.
3 ist mit einer Reihe von Buchstaben A-E versehen. Diese Buchstaben stehen für Arbeitsstufen. Obwohl diese Stufen für dieses Beispiel geordnet sind, veranschaulichen die Stufen ein Beispiel zum besseren Verständnis der vorliegenden Offenbarung und sollten nicht zur Einschränkung der Ansprüche verwendet werden. Der Gegenstand, der in den Umfang der Ansprüche fällt, kann hinsichtlich der Reihenfolge und einiger Operationen variieren.
In Stufe A trainiert der Modelltrainer 325 die Korrekturvorschlagspipeline mit gekennzeichneten Trainingsdaten, die aus dem Repository 123 abgerufen werden, so dass die trainierte Korrekturvorschlagspipeline 315 erzeugt wird. Der Modelltrainer 325 ruft Fehler-/Korrekturdaten aus dem Repository 123 ab, einschließlich gekennzeichneter Trainingsdaten 327, die Fehler-/Korrekturdaten (z. B. Fehler- und Korrektur-Quellcodedateien) umfassen. Der Abruf und die Vorverarbeitung von gekennzeichneten Trainingsdaten, die von dem Modelltrainer 325 aus dem Repository 123 abgerufen werden, erfolgt wie in ähnlicher Weise in Bezug auf die Stufen A und B von 2 beschrieben. Insbesondere ruft der Modelltrainer 325 den Trainingsdaten-Präprozessor 203 dazu auf, die gekennzeichneten Trainingsdaten 327 auf der Grundlage der Bestimmung des strukturellen Kontexts für den Fehler und die entsprechende Korrektur, die durch die gekennzeichneten Trainingsdaten 327 dargestellt werden, vorzuverarbeiten, wobei der strukturelle Kontext durch einen AST für die gekennzeichneten Trainingsdaten 327 angegeben werden kann. Der Trainingsdaten-Präprozessor 203 nutzt den AST-Generator 229, um auf der Grundlage der Bestimmung eines Unterschieds zwischen dem Quellcode des Fehlers und dem Quellcode der Korrektur einen AST diff 307 zu erzeugen. In diesem Beispiel gibt der AST diff 307 die Hinzufügung eines Quellcodekonstrukts an, das einem Knoten 305 entspricht, und die Löschung von Quellcodekonstrukten, die einem Knoten 309 und einem Knoten 311 entsprechen. Der Modelltrainer 325 stellt den AST diff 307 als Eingabe für das Trainieren der Korrekturvorschlagspipeline 331 bereit. Wie in ähnlicher Weise in 2 beschrieben, lernt die Korrekturvorschlagspipeline 331 aus dem strukturellen Kontext der Fehler-/Korrekturdaten, die durch die als Eingabe bereitgestellten AST diffs angegeben werden. Der Modelltrainer 325 fährt mit dem Trainieren der Korrekturvorschlagspipeline 331 auf diese Weise fort, bis ein oder mehrere Trainingskriterien erfüllt sind, um die trainierte Korrekturvorschlagspipeline 315 zu erhalten. In diesem Beispiel wird der Modelltrainer 325 unter Verwendung von Originaldarstellungen von Fehler-/Korrekturdaten trainiert und nicht mit de-identifizierten Fehler-/Korrekturdaten, wie in 2 beschrieben.
In Stufe B erhält der Fehlerbehebungsdienst 319 den Programmcode mindestens eines ersten Fehlers 333 von dem Agenten 117. Bei dem Fehler 333 kann es sich um einen Fehler handeln, der von dem Agenten 117 als Ergebnis der Überprüfung eines Softwareprojekts, wie in 1 beschrieben, erkannt wurde. Der Agent 117 kann Fehler wie den Fehler 333 an den Fehlerbehebungsdienst 319 übermitteln, um potenzielle Korrekturen oder Korrekturvorschläge anzufordern, die von der trainierten Korrekturvorschlagspipeline 315 als Ergebnis der Ausführung der Pipeline 315 mit den Fehlern als Eingabe ausgegeben werden. Der Fehlerbehebungsdienst 319 kann eine ähnliche anfängliche Verarbeitung des Fehlers 333 durchführen, so dass ein AST des Fehlers 333 erzeugt wird, der den strukturellen Kontext des Fehlers angibt, bevor der Fehler 333 als Eingabe an die trainierte Korrekturvorschlagspipeline 315 weitergegeben wird. Die Ausführung der trainierten Korrekturvorschlagspipeline 315 mit dem Fehler 333 als Eingabe führt dazu, dass die Korrekturvorschlagspipeline 315 einen oder mehrere Korrekturvorschläge 323 als Vorhersageergebnisse ausgibt. Die Korrekturvorschläge 323 umfassen Korrekturvorschläge für den Fehler 333 auf der Grundlage des strukturellen Kontexts des Fehlers 333. Die Korrekturvorschläge 323 enthalten auch den ursprünglichen Korrekturprogrammcode, auf dessen Grundlage die trainierte Korrekturvorschlagspipeline 315 trainiert wurde, d. h. im Gegensatz zu dem in 2 dargestellten Beispiel handelt es sich bei den von der trainierten Korrekturvorschlagspipeline 315 ausgegebenen Korrekturvorschlägen nicht um de-identifizierte Korrekturen.
In Stufe C de-identifiziert der Code-De-Identifikator 126 potenziell identifizierenden Code, der in den Korrekturvorschlägen 323 enthalten ist. Der Code-De-Identifikator 126 kann zunächst feststellen, ob es sich bei einem oder mehreren der Korrekturvorschläge 323 um organisationsinterne Korrekturen handelt, z. B. auf der Grundlage, ob eine mit dem Fehler 333 verknüpfte Organisations-ID mit der Organisations-ID übereinstimmt, die mit einem der Korrekturvorschläge 323 verknüpft ist. Bei organisationsinternen Korrekturen kann die De-Identifizierung umgangen werden, so dass die nutzende Organisation mit der ursprünglichen Darstellung der Korrektur dargestellt wird, wie sie aus dem Programmcode dieser Organisation gewonnen wurde (d. h. die Korrektur ohne De-Identifizierung). Für jeden verbleibenden Korrekturvorschlag 323 kann der Code-De-Identifikator 126 den Korrekturvorschlag auf der Grundlage des strukturellen Kontexts des Korrekturvorschlags de-identifizieren. Der Code-De-Identifikator 126 kann den strukturellen Kontext jedes Korrekturvorschlags 323 auf der Grundlage der Bestimmung eines AST, der mit der Korrektur verknüpft ist, und der Auswertung der Knoten der bestimmten AST anhand der Regeln 321 bestimmen, um den in der Korrektur enthaltenen Code zu ermitteln, der potenziell seine jeweilige Ursprungsorganisation identifiziert. Wie bei den Regeln 221 können die Regeln 321 ein oder mehrere Kriterien zur Bestimmung angeben, dass ein Quellcodekonstrukt potenziell identifizierend für seine Ursprungsorganisation ist, wie z. B. Typ, Herkunft und/oder andere Merkmale des Konstrukts. In diesem Beispiel kann der Code-De-Identifikator 126 basierend auf einer mit der Korrektur verknüpften ID einen AST erhalten, der zuvor für jeden Korrekturvorschlag 323 während des Trainierens erstellt wurde, das zu der trainierten Korrekturvorschlagspipeline 315 führte. Ein Repository, das der Fehlerbehebungsdienst 319 nach der Korrektur-ID abfragen kann, kann z. B. AST speichern, die während des Trainierens aus Fehler-/Korrekturdaten erzeugt wurden (z. B. wie mit Bezug auf 2 in Stufe B in Bezug auf das Repository 235 beschrieben). Die Bestimmung des AST, der den Korrekturvorschlägen 323 zugeordnet ist, kann dann darin bestehen, dass der Fehlerbehebungsdienst 319 die AST, die jedem der Korrekturvorschläge 323 entsprechen, aus dem AST-Repository abruft, das während des Trainierens der Korrekturvorschlagspipeline 331 erstellt/aktualisiert wurde.
Für jeden AST, der für die Korrekturvorschläge 323 bestimmt wurde, wertet der Code-De-Identifikator 126 die Knoten des AST anhand der Regeln 321 aus und bestimmt auf der Grundlage der Erfüllung mindestens einer ersten der Regeln 321, ob einer der Knoten einem potenziell identifizierenden Code entspricht. Der Code-De-Identifikator 126 kann beispielsweise über jeden der Knoten des AST iterieren und ein oder mehrere Attribut- oder Eigenschaftswerte des Knotens anhand der Regeln 321 auswerten, um festzustellen, ob das durch den Knoten repräsentierte Quellcodekonstrukt eine erste Regel der Regeln 321 erfüllt. Knoten, bei denen der Code-De-Identifikator 126 feststellt, dass sie eine der Regeln 321 erfüllen, werden für die De-Identifizierung des entsprechenden Quellcodes ausgewählt. In diesem Beispiel stellt der Code-De-Identifikator 126 fest, dass der Knoten 305 und ein Knoten 329 eines ersten bestimmten AST die Regeln 321 erfüllen und somit potenziell identifizierendem Code entsprechen. Der Code-De-Identifikator 126 kann dann den Quellcode, der den Knoten 305, 329 entspricht, modifizieren, z. B. durch Verschleiern des Quellcodes oder Ersetzen des Quellcodes durch einen generischen Identifikator (z. B. einen Identifikator, der den Typ des Quellcodekonstrukts darstellt), um eine de-identifizierte Darstellung des Quellcodes zu erzeugen. Die Art und Weise, in der der Quellcode geändert wird, kann durch eine Reihe von De-Identifizierungsrichtlinien festgelegt werden, die in den Regeln 321 angegeben sind, die auf dem Code-De-Identifikator 126 installiert sind oder für diesen anderweitig zugänglich sind, usw. Die De-Identifizierung des bzw. der AST, die den Korrekturvorschlägen 323 zugeordnet sind, erzeugt eine entsprechende Anzahl von de-identifizierten AST, einschließlich eines de-identifizierten AST 337. Der Code-De-Identifikator 126 kann dann Zuordnungen 335, die eine Angabe des de-identifizierten Quellcodes, der den Knoten 305, 329 entspricht, mit einer Angabe ihrer jeweiligen ursprünglichen Darstellungen verknüpft, in ein Repository 317 von de-identifizierten Code-Zuordnungen einfügen, wie in ähnlicher Weise mit Bezug auf 2 beschrieben. Die in der Vorhersagestufe der De-Identifizierung ermittelten und gespeicherten Zuordnungen können später für ein erneutes Trainieren der Korrekturvorschlagspipeline 331 und/oder für Programmfehlerbeseitigungsoperationen verwendet werden.
In Stufe D bestimmt der Fehlerbehebungsdienst 319 de-identifizierte Korrekturvorschläge 313 auf der Grundlage des/der de-identifizierten AST, die von dem Code-De-Identifikator 126 erstellt wurden. Zum Beispiel kann der Fehlerbehebungsdienst 319 für den de-identifizierten AST 337 den Korrekturvorschlag auf der Grundlage des de-identifizierten AST 337 „rekonstruieren“, um den entsprechenden de-identifizierten Korrekturvorschlag 313 zu erhalten. Die Rekonstruktion von Korrekturvorschlägen kann als Umwandlung eines de-identifizierten AST in den Quellcode betrachtet werden, den er repräsentiert, um den entsprechenden de-identifizierten Korrekturvorschlag zu generieren, wobei de-identifizierte Quellcodekonstrukte, die in dem de-identifizierten AST angegeben sind, in den de-identifizierten Korrekturvorschlag übernommen werden. Die de-identifizierten Korrekturvorschläge 313 sind somit de-identifizierte Versionen der Korrekturvorschläge 323, die von der trainierten Korrekturvorschlagspipeline 315 ausgegeben werden.
In Stufe E gibt der Fehlerbehebungsdienst 319 die de-identifizierten Korrekturvorschläge 313 an den Agenten 117 zurück. Der Fehlerbehebungsdienst 319 kann zunächst die de-identifizierten Korrekturvorschläge 313 ermitteln, deren Ursprungsorganisation die gleiche ist wie die besitzende/kontrollierende Organisation des Softwareprojekts, in dem der Fehler 333 entdeckt wurde, und die somit organisationsinterne Korrekturen sind. Diejenigen der de-identifizierten Korrekturvorschläge 313, die als organisationsinterne Korrekturen ermittelt wurden, können mit einer Kennzeichnung oder einer Gewichtung versehen werden, bevor der Fehlerbehebungsdienst 319 die de-identifizierten Korrekturvorschläge 313 an den Agenten 117 zurückgibt, um anzugeben, welche vorgeschlagenen Korrekturen Vorrang vor den anderen haben können.
Die 4-8 sind Flussdiagramme, die Beispieloperationen eines Fehlerbehebungsdienstes zur De-Identifizierung von Code für organisationsübergreifendes Fehlerbehebungswissen zeigen. Bei der Beschreibung dieser Beispieloperationen wird auf einen Fehlerbehebungsdienst verwiesen, der die Beispieloperationen durchführt, wobei ein Code-De-Identifikator auf dem Fehlerbehebungsdienst ausgeführt werden kann, wie mit Bezug auf die vorherigen Figuren beschrieben, doch die Benennung des Akteurs dient der Vereinfachung. Die Benennung und Organisation des Programmcodes kann willkürlich sein und je nach Plattform, Entwickler usw. variieren. Ferner sind einige der Blöcke in den 4-8 mit gestrichelten Linien dargestellt. Diese Blöcke stellen Beispiele für Operationen dar, die optional ausgeführt werden können, wie etwa konfigurierbare Einstellungen des Fehlerbehebungsdienstes. Diese Darstellung der Blöcke ist jedoch nicht so zu verstehen, dass die Operationen in den mit durchgezogenen Linien dargestellten Blöcken obligatorische Operationen sind.
4 ist ein Flussdiagramm von Beispieloperationen zur De-Identifizierung von Code für organisationsübergreifendes Fehlerbehebungswissen. In 4 wird auf den Fehlerbehebungsdienst verwiesen, der die Beispieloperationen durchführt.
In Block 401 erhält der Fehlerbehebungsdienst eine Programmcodekorrektur für einen in einem Softwareprojekt identifizierten Fehler, wobei die Programmcodekorrektur einer ersten Organisation zugeordnet ist. Der Fehlerbehebungsdienst kann die Programmcodekorrektur und den identifizierten Fehler aus Trainingsdaten erhalten, die zum Trainieren einer Korrekturvorschlagsmodellpipeline für maschinelles Lernen verwendet werden. In anderen Beispielen kann der Fehlerbehebungsdienst die Programmcodekorrektur auf der Grundlage der Ausgabe einer laufenden trainierten Korrekturvorschlagsmodellpipeline für maschinelles Lernen mit dem identifizierten Fehler als Eingabe erhalten.
In Block 403 bestimmt der Fehlerbehebungsdienst den strukturellen Kontext der Programmcodekorrektur. Der Fehlerbehebungsdienst kann einen AST der Programmcodekorrektur und/oder einen Steuerungsablaufgraphen der Programmcodekorrektur bestimmen. Um den strukturellen Kontext zu bestimmen, der durch einen AST dargestellt wird, kann der Fehlerbehebungsdienst den AST z. B. auf der Grundlage von Unterschieden zwischen dem Quellcode des Programmcodefehlers und dem Quellcode der Programmcodekorrektur bestimmen. In anderen Beispielen kann der Fehlerbehebungsdienst einen strukturellen Kontext erhalten, der zuvor für die Programmcodekorrektur bestimmt wurde (z. B. während des Trainierens einer Korrekturvorschlagsmodellpipeline für maschinelles Lernen).
In Block 405 bestimmt der Fehlerbehebungsdienst zumindest teilweise auf der Grundlage des strukturellen Kontexts der Programmcodekorrektur, ob die Programmcodekorrektur Programmcode enthält, der potenziell für die erste Organisation identifizierend ist. Der Fehlerbehebungsdienst wertet den strukturellen Kontext aus, um festzustellen, ob eines der angegebenen Codeelemente (z. B. AST-Knoten, die Quellcodekonstrukte darstellen) potenziell identifizierend für die erste Organisation ist. Potenziell identifizierender Programmcode kann beispielsweise auf der Grundlage von Codeelementen bestimmt werden, die im strukturellen Kontext angegeben sind und eine oder mehrere Regeln, Kriterien usw. zur Bestimmung von Programmcode erfüllen, der potenziell seine Quelle identifizieren könnte. Die Regeln oder Kriterien können z. B. darauf hinweisen, dass Programmcode, der nicht einer oder mehreren Open-Source-Codeeinheiten oder Standard-Codeeinheiten und/oder Namenskonventionen entspricht, als Programmcode zu betrachten ist, der potenziell für seine Quelle identifizierend ist.
Basierend auf der Feststellung, dass die Programmcodekorrektur Programmcode enthält, der potenziell für die erste Organisation identifizierend ist, de-identifiziert in Block 407 der Fehlerbehebungsdienst die Programmcodekorrektur zumindest teilweise auf der Grundlage der Modifizierung des potenziell identifizierenden Programmcodes. Der Fehlerbehebungsdienst modifiziert den Programmcode so, dass die darin enthaltenen potenziell identifizierenden Informationen entfernt werden. Der potenziell identifizierende Programmcode kann beispielsweise durch Verschleierung, Löschung, Löschung und Ersetzung durch einen Platzhalter oder einen Identifikator usw. geändert werden.
Wie oben erwähnt, verwendet der Fehlerbehebungsdienst die Modellpipeline für maschinelles Lernen oder die Korrekturvorschlagspipeline zur Bereitstellung von vorhergesagten Korrekturvorschlägen. Die Korrekturvorschlagspipeline ist so trainiert, dass sie den strukturellen Kontext verschiedener Korrekturen für unterschiedliche Fehlertypen lernt. Der strukturelle Kontext kann in Form von Vererbung, Variablendeklarationen, Aufrufen usw. beschrieben werden. Struktureller Kontext für Programmcode kann mit einem AST oder einem Steuerungsablaufgraphen ausgedrückt werden. Nach dem Erlernen von Merkmalen für verschiedene strukturelle Kontexte wird die Korrekturvorschlagspipeline darauf trainiert, Korrekturen nach Fehlertyp und strukturellem Kontext zu gruppieren. Die 5 bis 6 sind Flussdiagramme mit Beispieloperationen für das Trainieren der Korrekturvorschlagspipeline zur Erzeugung von Korrekturvorschlägen und die Verwendung der trainierten Korrekturvorschlagspipeline.
5 ist ein Flussdiagramm von Beispieloperationen für das Trainieren einer Korrekturvorschlagspipeline, die de-identifizierte Korrekturvorschläge für Codefehler generiert. Die Korrekturvorschlagspipeline ist in dieser Figur mit zwei Modellen für maschinelles Lernen ausgebildet, zu denen ein Modell für ein faltendes neuronales Netz (engl. Convolutional Neural Network - CNN) und ein Clustermodell gehören. Die Ausführungsformen sind nicht auf ein CNN und ein Clustermodell beschränkt. So können beispielsweise auch ein rekurrentes neuronales Netz und ein herkömmlicher Merkmalslernalgorithmus trainiert werden. Die resultierende trainierte Korrekturvorschlagspipeline umfasst den Programmcode für die einzelnen Modelle und den Programmcode, der die Modelle miteinander verbindet. Die Beschreibung von 5 bezieht sich auf den Fehlerbehebungsdienst, der die Beispieloperationen durchführt.
In Block 501 ruft der Fehlerbehebungsdienst gekennzeichnete Trainingsdaten ab, die aus Korrekturen und entsprechenden Fehlern zusammengestellt wurden. Die Korrekturen und Fehler werden durch einen oder mehrere Quelldateinamen und Zeitstempel und/oder Commit-Identifikatoren identifiziert. In den Korrekturen und Fehlern kann auch die jeweilige Ursprungsorganisation angegeben sein.
In Block 502 beginnt der Fehlerbehebungsdienst mit der Iteration über jedes der Fehler/Korrektur-Paare. Ein Repository kann z. B. Einträge nach Fehlertyp mit Verweisen auf entsprechende Instanzen des Fehlertyps und entsprechende Korrekturen indizieren.
In Block 503 erzeugt der Fehlerbehebungsdienst eine strukturelle Kontextdarstellung, die den Kontext für die Korrektur und den entsprechenden Fehler angibt. Der Fehlerbehebungsdienst kann beispielsweise einen AST oder einen Steuerungsablaufgraphen für die Korrektur und den entsprechenden Fehler als strukturelle Kontextdarstellung erzeugen. Bei der Erzeugung eines AST für die strukturelle Kontextdarstellung stellt der Fehlerbehebungsdienst einen Unterschied zwischen der/den Quellcodedatei(en), die den Fehler enthält/enthalten, und der/den Quellcodedatei(en), die die Korrektur enthält/enthalten, fest. Der Fehlerbehebungsdienst erzeugt dann einen AST aus der Differenz zwischen der/den Fehlerquellcodedatei(en) und der/den Korrekturquellcodedatei(en). Der Fehlerbehebungsdienst kann ein Werkzeug nutzen, das Quellcodedateien parst, einen Unterschied zwischen den geparsten Dateien feststellt und daraus einen AST erzeugt.
In Block 505 de-identifiziert der Fehlerbehebungsdienst die Korrektur. Der Fehlerbehebungsdienst kann die Korrektur auf der Grundlage der Iteration über jede Angabe eines Codeelements in der strukturellen Kontextdarstellung (z. B. jeden AST-Knoten) und der Bewertung des entsprechenden Codeelements anhand eines oder mehrerer Kriterien, Regeln usw. zur Bestimmung eines potenziell identifizierenden Programmcodes de-identifizieren. Solche Kriterien oder Regeln können beispielsweise angeben, dass Codeelemente, die nicht einer oder mehreren Open-Source-Codeeinheiten oder einer oder mehreren Standard-Codeeinheiten entsprechen, und/oder Namen, die Codeelementen (z. B. Variablennamen) zugewiesen sind, potenziell identifizierenden Programmcode darstellen. In der strukturellen Kontextdarstellung angegebene Codeelemente, die als potenziell identifizierendem Programmcode entsprechend bestimmt wurden, werden auf der Grundlage einer Modifizierung des potenziell identifizierenden Programmcodes de-identifiziert, wobei die Modifizierung die darin enthaltenen potenziell identifizierenden Informationen entfernt (z. B. durch Verschleierung, Löschung und optionales Ersetzen durch einen generischen Identifikator oder Platzhalter usw.). Die De-Identifizierung wird mit Bezug auf die 7-8 näher beschrieben.
In Block 507 erzeugt der Fehlerbehebungsdienst eine Vektordarstellung der strukturellen Kontextdarstellung. Durch die Erzeugung der Vektordarstellung kann der strukturelle Kontext in ein maschinelles Lernmodell, in diesem Fall ein CNN, eingespeist oder eingegeben werden. Die Vektordarstellung zerlegt auch die in der strukturellen Kontextdarstellung ausgedrückten strukturellen Kontextinformationen in Merkmale des strukturellen Kontexts.
In Block 509 gibt der Fehlerbehebungsdienst die Vektordarstellung in das CNN ein, um das CNN so zu trainieren, dass es Merkmale des strukturellen Kontexts für die Korrektur und den Fehlertyp lernt. Die letzte vollständig verbundene Schicht ist ein Merkmalsvektor, der durch den Klassifizierungsalgorithmus des CNN klassifiziert wird, z. B. Klassifizierungen des Merkmals mit einem Konfidenz- oder Vorhersagewert pro Fehlertyp.
In Block 510 stellt der Fehlerbehebungsdienst fest, ob zusätzliche gekennzeichnete Trainingsdaten vorhanden sind, die in das CNN eingespeist werden. Wenn zusätzliche Trainingsdaten vorhanden sind, kehrt der Vorgang zu Block 502 zurück, um mit der Vorverarbeitung des nächsten Trainingsdatensatzes zu beginnen. Ist dies nicht der Fall, geht der Vorgang zu Block 512 über. Das Trainieren des CNN-Modells kann mit der Iteration über alle Trainingsdaten oder der Erfüllung des Trainingsabbruchkriteriums beendet werden. Nach dem Trainieren wird das trainierte CNN als Teil der Vorstufe der Korrekturvorschlagspipeline gespeichert.
In Block 512 beginnt der Fehlerbehebungsdienst mit der Iteration über jede der aus dem CNN-Training generierten Vektordarstellungen. Diese können vor dem Beginn des Trainierens der Modelle erzeugt werden. Jede der Vektordarstellungen ist mit dem Fehlertyp gekennzeichnet, der durch den von der Vektordarstellung repräsentierten Programmcode korrigiert wird.
In Block 513 gibt der Fehlerbehebungsdienst die Vektordarstellung in das trainierte CNN ein. Der von dem trainierten CNN-Modell erzeugte Merkmalsvektor der letzten Schicht wird abgerufen, während die Klassifizierung verworfen werden kann.
In Block 515 gibt der Fehlerbehebungsdienst den Merkmalsvektor aus dem trainierten CNN-Modell in ein Clustermodell ein. Dadurch wird das Clustermodell darauf trainiert, Korrekturen mit ähnlichem strukturellem Kontext nach Fehlertyp zu gruppieren.
In Block 516 bestimmt der Fehlerbehebungsdienst, ob eine zusätzliche Vektordarstellung für das Trainieren des Clustermodells vorliegt. Wenn ja, kehrt der Vorgang zu Block 512 zurück, um die nächste Vektordarstellung zu verarbeiten. Andernfalls wird der Vorgang mit Block 517 fortgesetzt, da das Trainieren des Clustermodells beendet ist. Wie beim CNN-Training wird auch das Clustermodell-Training beendet, wenn ein Trainingsabbruchkriterium erfüllt ist. In einigen Fällen kann die Iteration über alle Trainingsdaten das Trainingsabbruchkriterium sein.
In Block 517 erzeugt der Fehlerbehebungsdienst eine Korrekturvorschlagspipeline mit dem trainierten CNN-Modell und dem trainierten Clustermodell. Ein Eingangsvektor für die Pipeline wird als erster in das trainierte CNN-Modell eingegeben. Ein von dem trainierten CNN-Modell erzeugter Merkmalsvektor der letzten Schicht wird dann als Eingabe in das trainierte Clustermodell weitergeleitet.
Bei den in 5 beschriebenen Beispieloperationen wird davon ausgegangen, dass die Trainingsdaten, die für das Trainieren des Korrekturvorschlagsmodells abgerufen wurden, aus Programmcode stammen, der einer Organisation gehört oder von ihr kontrolliert wird. Zu den Trainingsdaten kann jedoch auch Programmcode gehören, der aus öffentlichen Repositories (z. B. Open-Source-Repositories) abgerufen wurde. In den Fällen, in denen Fehler-/ Korrekturdaten, die aus einem öffentlichen Repository stammen, während einer oder mehrerer Iterationen des Trainings als Eingabe verwendet werden und die Fehler-/Korrekturdaten somit nicht mit einer besitzenden/kontrollierenden Organisation verbunden sind, können die in Block 505 beschriebenen De-Identifizierungsoperationen ausgelassen werden.
6 ist ein Flussdiagramm von Beispieloperationen zur Gewinnung und De-Identifizierung von Korrekturvorschlägen aus einer trainierten Korrekturvorschlagspipeline. Aus Gründen der Konsistenz wird 6 mit Bezug auf den Fehlerbehebungsdienst beschrieben.
In Block 601 erzeugt der Fehlerbehebungsdienst eine strukturelle Kontextdarstellung, die den Kontext für einen erkannten Fehler angibt. Der Fehlerbehebungsdienst kann z. B. einen AST oder einen Steuerungsablaufgraphen für den erkannten Fehler als strukturelle Kontextdarstellung erzeugen. Im Falle der Erzeugung eines AST für die strukturelle Kontextdarstellung kann der Fehlerbehebungsdienst die Quelldatei(en) für den erkannten Fehler von einem Agenten erhalten, der den Fehler (z. B. als Ergebnis einer Schwachstellenüberprüfung) erkannt hat. Der Fehlerbehebungsdienst kann die Quelldatei(en) auf der Basis einer von dem Agenten übermittelten Beschreibung des erkannten Fehlers abrufen. In einigen Ausführungsformen kann der Agent so programmiert sein, dass er ein Werkzeug zur Erzeugung des AST verwendet oder eine Zwischendarstellung von einem Compiler-Front-End erhält.
In Block 603 erzeugt der Fehlerbehebungsdienst eine Vektordarstellung der strukturellen Kontextdarstellung. Der Fehlerbehebungsdienst kann dasselbe Worteinbettungsmodell verwenden, das für das Pipeline-Training verwendet wurde.
In Block 605 gibt der Fehlerbehebungsdienst die Vektordarstellung in das trainierte CNN-Modell ein. Von dem trainierten CNN-Modell erhält der Fehlerbehebungsdienst einen Merkmalsvektor, der einer letzten Schicht des trainierten CNN-Modells entspricht.
In Block 607 gibt der Fehlerbehebungsdienst den erhaltenen Merkmalsvektor in das trainierte Clustering-Modell ein. Das Clustermodell bestimmt einen Cluster für den Merkmalsvektor. Die Zugehörigkeit des Merkmalsvektors zu einem der strukturellen Kontextcluster für die Korrektur zeigt die Ähnlichkeit des strukturellen Kontexts an. Obwohl das Clustermodell mit Merkmalsvektoren von Korrekturen trainiert wurde, haben die Merkmalsvektoren strukturelle Kontextinformationen einer Korrektur für einen Fehlertyp kodiert. Der Merkmalsvektor des Fehlers wird höchstwahrscheinlich einen strukturellen Kontext kodieren, der dem eines oder mehrerer Korrekturen für Fehler desselben Typs ähnelt. Dieses Clustering ermöglicht auch die Unterscheidung zwischen Korrekturen desselben Fehlertyps in unterschiedlichen strukturellen Kontexten.
In Block 609 wählt der Fehlerbehebungsdienst bis zu M der nächsten Nachbarn in dem ermittelten Cluster aus. Die Auswahlgrenze kann ein Konfigurationswert sein, der von dem Fehlerbehebungsagenten oder einem Parameter der Pipeline übermittelt wird.
In Block 610 iteriert der Fehlerbehebungsdienst über jedes der ausgewählten Clusterelemente. Insbesondere iteriert der Fehlerbehebungsdienst über jeden der in Block 609 ausgewählten M nächsten Nachbarn.
In Block 611 bestimmt der Fehlerbehebungsdienst die dem ausgewählten Clusterelement zugeordnete Korrektur. Der Fehlerbehebungsdienst unterhält Referenzen oder Assoziationen zwischen den Merkmalsvektoren, die die Cluster des trainierten Clustermodells bilden, und den entsprechenden Programmcodekorrekturen. Die Programmcodekorrekturen können mit unterschiedlicher Granularität identifiziert werden. Beispielsweise kann eine Programmcodekorrektur anhand des Quelldateinamens, der Zeilennummern und des Commit-Identifikators (z. B. Zweig und Zeitstempel) identifiziert werden. Die Programmcodekorrekturen können auch einer ID, einer Kennzeichnung usw. zugeordnet sein, die die jeweilige Ursprungsorganisation angibt.
In Block 613 de-identifiziert der Fehlerbehebungsdienst die ermittelte Korrektur. Der Fehlerbehebungsdienst bestimmt den strukturellen Kontext der ermittelten Korrektur, z. B. indem er den strukturellen Kontext erhält, der zuvor für die Korrektur während des Trainings der Korrekturvorschlagspipeline bestimmt und gespeichert wurde. Der Fehlerbehebungsdienst kann die ermittelte Korrektur auf der Grundlage einer Iteration über jede Angabe eines Codeelements in der strukturellen Kontextdarstellung (z. B. jeden AST-Knoten) und einer Bewertung des entsprechenden Codeelements anhand eines oder mehrerer Kriterien, Regeln usw. zur Ermittlung von potenziell identifizierendem Programmcode de-identifizieren. Solche Kriterien oder Regeln können beispielsweise angeben, dass Codeelemente, die nicht einer oder mehreren Open-Source-Codeeinheiten oder einer oder mehreren Standard-Codeeinheiten entsprechen, und/oder Namen, die Codeelementen zugewiesen sind (z. B. Variablennamen), potenziell identifizierenden Programmcode darstellen. In der strukturellen Kontextdarstellung angegebene Codeelemente, die als potenziell identifizierendem Programmcode entsprechend bestimmt wurden, werden auf der Grundlage einer Modifizierung des potenziell identifizierenden Programmcodes de-identifiziert, wobei die Modifizierung die darin enthaltenen potenziell identifizierenden Informationen entfernt (z. B. durch Verschleierung, Löschung und optionales Ersetzen durch einen generischen Identifikator oder Platzhalter usw.). Die De-Identifizierung wird mit Bezug auf die 7-8 näher beschrieben.
In Block 614 stellt der Fehlerbehebungsdienst fest, ob die de-identifizierte Korrektur mindestens ein erstes Kriterium der Organisationsspezifität erfüllt. Einige Korrekturvorschläge, die aus dem Programmcode einer Organisation stammen, z. B. solche, die proprietäre oder interne Bibliotheken verwenden, können für externe Organisationen von begrenztem Nutzen sein. Der Fehlerbehebungsdienst kann dies berücksichtigen, indem er organisationsübergreifende Korrekturen auf der Grundlage mindestens eines ersten Kriteriums für die Organisationsspezifität einschränkt. Die Organisationsspezifität bezieht sich auf die Spezifität einer Korrektur für seine Ursprungsorganisation. Beispielsweise würde eine Korrektur, die eine oder mehrere proprietäre oder interne Codeeinheiten enthält, eine höhere Spezifität für ihre Ursprungsorganisation haben, während eine Korrektur, bei der sich die De-Identifizierung auf die Verschleierung/Löschung von Namen für Variablen, Standarddatentypen usw. beschränkt, eine geringere Spezifität für ihre Ursprungsorganisation haben würde. Der Fehlerbehebungsdienst kann die de-identifizierte Korrektur auf der Grundlage einer oder mehrerer Heuristiken bewerten, um ihre Organisationsspezifität zu bestimmen, oder eine Organisationsspezifität erkennen, die für die de-identifizierte Korrektur während der De-Identifizierung bestimmt wurde. Die Organisationsspezifität, die de-identifizierten Korrekturen zugeordnet ist, kann mit einem Prozentsatz, einem Wert, einem Rang usw. angegeben und beispielsweise mit einem im Kriterium angegebenen Schwellenwert verglichen werden. Der Fehlerbehebungsdienst kann zusätzlich so konfiguriert sein, dass er Korrekturvorschläge auf organisationsinterne Korrekturen beschränkt. In diesem Fall kann der Fehlerbehebungsdienst feststellen, dass die de-identifizierte Korrektur das Kriterium nicht erfüllt, wenn die de-identifizierte Korrektur einer anderen Ursprungsorganisation als der des erkannten Fehlers zugeordnet ist. Wenn die de-identifizierte Korrektur das Kriterium der Organisationsspezifität nicht erfüllt, wird der Vorgang in Block 615 fortgesetzt. Wenn die de-identifizierte Korrektur das Kriterium der Organisationsspezifität erfüllt, werden die Vorgänge in Block 616 fortgesetzt.
In Block 615 entfernt der Fehlerbehebungsdienst die Korrektur und wählt das nächstgelegene Element des Clusters aus. Der Fehlerbehebungsdienst kann versuchen, Korrekturen zu ersetzen, die das Kriterium der Organisationsspezifität nicht erfüllen, um den Nutzen der als Vorschläge präsentierten Korrekturen zu erhöhen und gleichzeitig eine Gesamtzahl von M Korrekturen zu präsentieren. Der Fehlerbehebungsdienst kann dann mit der Bestimmung und De-Identifizierung der zugehörigen Korrekturen für das nächstgelegene Element fortfahren. Der Fehlerbehebungsdienst kann die kumulative Anzahl der Korrekturlöschungen verfolgen und die Auswahl des nächstgelegenen Elements bzw. der nächstgelegenen Elemente beenden, sobald ein Schwellenwert erreicht ist, der einer konfigurierbaren Anzahl von Löschungen und Ersatzvorgängen entspricht. Beispielsweise kann der Fehlerbehebungsdienst die Ersetzung gelöschter Korrekturen einstellen, nachdem die beiden nächstgelegenen Elemente des Clusters ausgewählt wurden. Alle nachfolgenden Korrekturen, die das Kriterium nicht erfüllen, werden dann ohne Ersatz entfernt.
In Block 616 stellt der Fehlerbehebungsdienst fest, ob noch ein weiteres ausgewähltes Clusterelement übrig ist. Wenn ein weiteres ausgewähltes Clusterelement verbleibt, werden die Operationen in Block 610 fortgesetzt. Sind keine ausgewählten Clusterelemente mehr vorhanden, wurde jede der relevanten Korrekturen de-identifiziert, und die Operationen werden in Block 619 fortgesetzt.
In Block 619 übermittelt der Fehlerbehebungsdienst die de-identifizierten Korrekturen als vorgeschlagene Korrekturen. Die vorgeschlagenen Korrekturen können dem Agenten mitgeteilt werden, der dem Fehlerbehebungsdienst ursprünglich den erkannten Fehler mitgeteilt hat. Der Fehlerbehebungsdienst kann zunächst jeder der de-identifizierten Korrekturen einen Rang, eine Priorität usw. auf der Grundlage der Organisationsspezifität der Korrekturen zuweisen, bevor die Korrekturen als Vorschläge übermittelt werden. Der Fehlerbehebungsdienst kann bei der Zuweisung des Rangs oder der Priorität auch die jeweilige Ursprungsorganisation der de-identifizierten Korrekturen berücksichtigen. Beispielsweise kann der Fehlerbehebungsdienst de-identifizierten Korrekturen, deren jeweilige Ursprungsorganisation mit der Organisation übereinstimmt, die mit dem erkannten Fehler verknüpft ist, die höchste Priorität oder den höchsten Rang zuweisen, während de-identifizierte Korrekturen, die mit gleichrangigen Organisationen verknüpft sind, einen niedrigeren Rang oder eine niedrigere Priorität erhalten können.
In 6 beschreiben die Beispieloperationen die De-Identifizierung von Korrekturen in der Vorhersagestufe, die auftreten kann, wenn die Korrekturvorschlagspipeline nicht mit de-identifizierten Fehler/korrektur-Trainingsdaten trainiert wird. In Implementierungen, in denen die Korrekturvorschlagspipeline mit de-identifizierten Fehler-/Korrektur-Trainingsdaten trainiert wurde und die trainierte Korrekturvorschlagspipeline somit de-identifizierte Korrekturen ausgibt, können die in 6 beschriebenen De-Identifizierungsoperationen während des Abrufs von vorgeschlagenen Korrekturen für einen Fehler aus der trainierten Korrekturvorschlagspipeline ausgelassen werden. Der Fehlerbehebungsdienst kann z. B. die in Block 613 beschriebenen De-Identifizierungsoperationen auslassen.
Die Beispieloperationen in 6 beschreiben auch die De-Identifizierung der einzelnen Korrekturen, die den ausgewählten Clusterelementen zugeordnet sind. In einigen Implementierungen kann der Fehlerbehebungsdienst feststellen, ob die in Block 611 ermittelten Korrekturen organisationsinterne Korrekturen sind. Der Fehlerbehebungsdienst kann so konfiguriert sein, dass organisationsinterne Korrekturen die De-Identifizierung umgehen können, so dass die in den vorgeschlagenen Korrekturen enthaltenen organisationsinternen Korrekturen ihre ursprünglichen Darstellungen beibehalten (d. h. nicht de-identifiziert werden). In solchen Fällen können bei der Feststellung, dass es sich bei einer in Block 611 ermittelten Korrektur um eine organisationsinterne Korrektur handelt, die in den Blöcken 613 und 614 beschriebenen De-Identifizierungsoperationen für die ermittelte organisationsinterne Korrektur ausgelassen werden.
Die 7-8 zeigen ein Flussdiagramm mit Beispieloperationen zur De-Identifizierung einer Korrektur auf der Grundlage ihrer strukturellen Darstellung. Aus Gründen der Konsistenz mit den früheren Figuren beziehen sich die Beispieloperationen auf einen Fehlerbehebungsdienst, der die dargestellten Operationen durchführt. Die in den 7-8 beschriebene Funktionalität des Fehlerbehebungsdienstes kann während des Trainierens einer Korrekturvorschlagspipeline aufgerufen werden, so dass die in die Korrekturvorschlagspipeline eingegebenen Trainingsdaten de-identifiziert werden, oder nachdem eine trainierte Korrekturvorschlagspipeline Korrekturvorhersagen ausgibt, um die Korrekturen zu de-identifizieren (z. B. wie in Bezug auf 5 bzw. 6 beschrieben). In den 7-8 wird auch die Bestimmung eines AST beschrieben, der den strukturellen Kontext für eine Korrektur angibt. Die Ausführungsformen sind nicht darauf beschränkt, den strukturellen Kontext für eine Korrektur auf der Grundlage der Bestimmung eines AST zu bestimmen. So kann beispielsweise ein Steuerungsablaufgraph ermittelt werden, der den strukturellen Kontext für die Korrektur angibt.
In Block 701 bestimmt der Fehlerbehebungsdienst einen AST, der den strukturellen Kontext für eine zu de-identifizierende Korrektur angibt. Der Prozess, mit dem der AST bestimmt wird, kann variieren, je nachdem, ob der Fehlerbehebungsdienst eine Korrektur, die als Trainingsdaten während des Trainierens einer Korrekturvorschlagspipeline verwendet werden soll, oder eine Korrekturvorhersage, die von der trainierten Korrekturvorschlagspipeline ausgegeben wird, de-identifiziert, bevor die Korrektur als Korrekturvorschlag übermittelt wird. Während der De-Identifizierung in der Trainingsstufe bestimmt der Fehlerbehebungsdienst den AST, indem ein AST für die Korrektur erzeugt wird, z. B. auf der Grundlage der Bestimmung von Unterschieden zwischen einer oder mehreren Quellcodedateien der Korrektur und einer oder mehreren Quellcodedateien eines entsprechenden Fehlers. Während der De-Identifizierung in der Vorhersagestufe kann der Fehlerbehebungsdienst einen AST bestimmen, der auf dem Erhalt eines AST basiert, der zuvor für die Korrektur während des Trainierens der Korrekturvorschlagspipeline bestimmt und gespeichert wurde.
In Block 703 wählt der Fehlerbehebungsdienst eine Richtlinie für die De-Identifizierung von Programmcode aus. Die Richtlinie gibt den Prozess oder die Technik zur Entfernung potenziell identifizierender Informationen aus dem Programmcode an. Die Richtlinie kann beispielsweise angeben, dass potenziell identifizierender Programmcode der Korrektur durch Verschleiern des Programmcodes, Löschen des Programmcodes oder Löschen und Ersetzen des Programmcodes durch einen Platzhalter oder Identifikation zu de-identifizieren ist. Die zu verwendende De-Identifizierungsrichtlinie kann eine Konfigurationseinstellung des Fehlerbehebungsdienstes sein.
In Block 704 beginnt der Fehlerbehebungsdienst mit der Iteration über jeden Knoten im AST. Jeder der Knoten im AST entspricht einem Quellcodekonstrukt, das im Programmcode der Korrektur auftritt. Die Werte der einzelnen Quellcodekonstrukte können in einer Eigenschaft, einem Attribut, einem Wert usw. des entsprechenden Knotens angegeben werden. Die Operationen werden bis zum Übergangspunkt A fortgesetzt, der in Block 805 von 8 weitergeführt wird.
In Block 805 wertet der Fehlerbehebungsdienst das dem Knoten entsprechende Quellcodekonstrukt anhand einer oder mehrerer Regeln zur Bestimmung von Codeelementen aus, die potenziell für eine Ursprungsorganisation der Korrektur identifizierend sind. Der Fehlerbehebungsdienst kann z. B. einen oder mehrere Werte mindestens einer ersten Knoteneigenschaft, eines Attributs usw. anhand der Regeln auswerten. Die Regeln können angeben, dass Codeelemente (z. B. Quellcodekonstrukte, die in AST-Knoten angegeben sind), die nicht einer oder mehreren Open-Source-Codeeinheiten oder Standard-Codeeinheiten entsprechen, als potenziell identifizierend für ihre jeweilige Quelle betrachtet werden sollten. Die Regeln können z. B. eine Auflistung „bekannter“ Codeeinheiten, einschließlich Open-Source-Codeeinheiten und Standard-Codeeinheiten, angeben, die keine bestimmte Organisation oder andere Quelle identifizieren. Die Regeln können dann vorschreiben, dass Codeelemente, die einer oder mehreren Code-Einheiten entsprechen, die in der Liste der bekannten Codeeinheiten nicht identifiziert werden können, so zu bestimmen sind, dass sie potenziell identifizierende Informationen enthalten. Alternativ oder zusätzlich können die Regeln angeben, dass die für Codeelemente verwendeten Namenskonventionen als potenziell identifizierend für die jeweilige Quelle anzusehen sind (z. B. Variablennamen, Klassennamen, Routinen-/Subroutinen-Namen usw.).
In Block 807 bestimmt der Fehlerbehebungsdienst, ob mindestens eine erste Regel erfüllt ist. Mindestens eine erste der Regeln kann erfüllt sein, wenn festgestellt wird, dass das dem Knoten entsprechende Quellcodekonstrukt nicht einer oder mehreren Open-Source-Codeeinheiten oder Standard-Codeeinheiten entspricht und/oder wenn das Quellcodekonstrukt einen Namen enthält, der beispielsweise von einem Element der Ursprungsorganisation zugewiesen wurde. Wenn eine Regel erfüllt ist, wird die Operation in Block 809 fortgesetzt. Wenn keine Regel erfüllt ist, werden die Operationen zum Übergangspunkt B fortgesetzt, der in Block 718 von 7 weiterläuft.
In Block 809 modifiziert der Fehlerbehebungsdienst das Quellcodekonstrukt, so dass eine de-identifizierte Darstellung erzeugt wird. Der Fehlerbehebungsdienst modifiziert das Quellcodekonstrukt entsprechend der ausgewählten De-Identifizierungsrichtlinie. Wenn die Richtlinie beispielsweise angibt, dass der Code durch Verschleierung modifiziert werden soll, kann der Fehlerbehebungsdienst die potenziell identifizierenden Informationen, die durch das Quellcodekonstrukt angegeben werden, verschleiern (z. B. durch Erzeugung einer zufällig generierten Zeichenfolge, die die potenziell identifizierenden Informationen ersetzt). Wenn die Richtlinie angibt, dass der Code durch Löschung und Ersetzen zu ändern ist, kann der Fehlerbehebungsdienst einen Platzhalter oder Identifikator bestimmen, durch den der potenziell identifizierende Code ersetzt wird. Der Fehlerbehebungsdienst kann z. B. einen Typ des Quellcodekonstrukts bestimmen und das Quellcodekonstrukt durch einen generischen Identifikator ersetzen, der den Typ angibt. Der Fehlerbehebungsdienst kann den Typ des Quellcodekonstrukts auf der Grundlage eines Satzes von Zuordnungen zwischen Quellcodekonstrukten der Ursprungsorganisation und entsprechenden, zuvor ermittelten und generierten Typen bestimmen, der für den Fehlerbehebungsdienst zugänglich ist.
In Block 811 bestimmt der Fehlerbehebungsdienst eine Ursprungsorganisationsspezifität des Quellcodekonstrukts. Die Ursprungsorganisationsspezifität gibt an, inwieweit das Quellcodekonstrukt spezifisch für seine Ursprungsorganisation ist. Der Fehlerbehebungsdienst kann einen Wert, eine Punktzahl oder eine andere Metrik für das Quellcodekonstrukt bestimmen, der/die die Spezifität für seine Ursprungsorganisation z. B. auf der Grundlage einer Reihe von Heuristiken anzeigt. Die Heuristiken können darauf hinweisen, dass Quellcodekonstrukte mit einem höheren Grad an Ursprungsorganisationsspezifität solche umfassen können, die mit proprietären oder internen Codeeinheiten verknüpft sind, während Quellcodekonstrukte mit einem niedrigen Grad an Ursprungsorganisationsspezifität Namen umfassen können, die für Variablen, Klassen, Routinen/Subroutinen usw. verwendet werden. Der Fehlerbehebungsdienst kann das Quellcodekonstrukt auf der Grundlage der Heuristiken bewerten und einen entsprechenden Wert, eine Punktzahl usw. bestimmen, der/die den Grad der Spezifizität der Ursprungsorganisation angibt und der de-identifizierten Darstellung zuzuweisen ist. Beispielsweise können Heuristiken so implementiert werden, dass Codeelemente und deren Merkmale mit einem entsprechenden Spezifitätswert verknüpft werden. Der Fehlerbehebungsdienst kann dann dem Quellcodekonstrukt einen Standard-Spezifitätswert von Null zuweisen und das Quellcodekonstrukt auf der Grundlage der Heuristiken bewerten und den Wert bei Bedarf erhöhen. Der Fehlerbehebungsdienst kann auch eine kumulative Ursprungsorganisationsspezifität für die Korrektur aufrechterhalten, die bei jeder Spezifitätsbestimmungsinstanz auf der Grundlage der ermittelten Ursprungsorganisationsspezifität jedes de-identifizierten Quellcodekonstrukts aktualisiert wird.
In Block 813 ordnet der Fehlerbehebungsdienst eine Angabe der Ursprungsorganisationsspezifität der de-identifizierten Darstellung des Quellcodekonstrukts zu. Der Fehlerbehebungsdienst kann eine Kennzeichnung, einen Tag usw., die/der die Spezifität der Ursprungsorganisation angibt, mit der de-identifizierten Darstellung verknüpfen.
In Block 815 speichert der Fehlerbehebungsdienst eine Assoziation zwischen einer Angabe des Quellcodekonstrukts und einer Angabe seiner de-identifizierten Darstellung. Der Fehlerbehebungsdienst kann die Assoziation zusammen mit der Organisations-ID in ein Repository einfügen, das Assoziationen zwischen Quellcodekonstrukten und ihren de-identifizierten Darstellungen speichert (z. B. eine relationale Datenbank). Der Fehlerbehebungsdienst kann der de-identifizierten Darstellung für die Organisations-ID vor dem Einfügen in das Repository eine eindeutige Kennzeichnung, Tag, ID usw. zuweisen. Der Fehlerbehebungsdienst kann daher bei der anschließenden Präsentation von de-identifizierten Korrekturvorschlägen aus dem Repository auf der Grundlage von Organisations-IDs und/oder de-identifizierten Darstellungen von Quellcodekonstrukten auf die Zuordnung zugreifen, so dass den Benutzern innerhalb der Organisation, aus der der de-identifizierte Korrekturvorschlag stammt, die Originaldarstellungen präsentiert werden können. Das Repository kann auch während nachfolgender De-Identifizierungsoperationen abgefragt werden (z. B. in Block 809), um festzustellen, ob eine de-identifizierte Darstellung eines QuellcodeKonstrukts, das einem AST-Knoten entspricht, bereits generiert worden ist. Die Operationen werden bis zum Übergangspunkt B fortgesetzt, der in Block 718 von 7 weiterläuft.
In Block 718 bestimmt der Fehlerbehebungsdienst, ob ein weiterer Knoten des AST übrig ist. Wenn ein weiterer Knoten verbleibt, werden die Operationen in Block 704 fortgesetzt. Sind keine Knoten des AST mehr vorhanden, werden die Vorgänge in Block 719 fortgesetzt.
In Block 719 zeigt der Fehlerbehebungsdienst die de-identifizierte Korrektur an. Wenn während der De-Identifizierung der Korrektur eine oder mehrere Ursprungsorganisationsspezifitäten festgestellt wurden, kann der Fehlerbehebungsdienst eine Gesamtheit aus den Ursprungsorganisationsspezifitäten mit der de-identifizierten Korrektur angeben. Der Fehlerbehebungsdienst kann z. B. die kumulative Ursprungsorganisationsspezifität, die sich aus der De-Identifizierung ergibt, zusammen mit der de-identifizierten Korrektur anzeigen. Die kumulierte Ursprungsorganisationsspezifität kann dazu genutzt werden, auf der Grundlage eines oder mehrerer Kriterien für die Organisationsspezifität eine Entscheidung anzuzeigen, ob die Korrektur später als Korrekturvorschlag präsentiert werden soll (z. B. wie in 6 in Block 614 beschrieben).
Varianten
Die Flussdiagramme dienen dem besseren Verständnis der Veranschaulichungen und sollen nicht dazu dienen, den Umfang der Ansprüche einzuschränken. Die Flussdiagramme zeigen Beispieloperationen, die innerhalb des Umfangs der Ansprüche variieren können. Es können zusätzliche Operationen ausgeführt werden, es können weniger Operationen ausgeführt werden, die Operationen können parallel ausgeführt werden, und die Operationen können in einer anderen Reihenfolge ausgeführt werden. Beispielsweise können die in den Blöcken 704 bis 718 dargestellten Operationen parallel oder gleichzeitig für jeden der Knoten durchgeführt werden. Es versteht sich, dass jeder Block der Flussdiagrammabbildungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagrammabbildungen und/oder Blockdiagrammen durch Programmcode implementiert werden können. Der Programmcode kann für einen Prozessor eines Allzweckcomputers, eines Spezialcomputers oder einer anderen programmierbaren Maschine oder Vorrichtung bereitgestellt werden.
Wie zu erkennen ist, können Aspekte der Offenbarung als System, Verfahren oder Programmcode/-anweisungen, die in einem oder mehreren maschinenlesbaren Medien gespeichert sind, verkörpert werden. Dementsprechend können Aspekte die Form von Hardware, Software (einschließlich Firmware, residenter Software, Mikrocode usw.) oder einer Kombination von Software- und Hardwareaspekten annehmen, die hier allgemein als „Schaltung“, „Modul“ oder „System“ bezeichnet werden können. Die in den Beispielabbildungen als einzelne Module/Einheiten dargestellten Funktionen können je nach Plattform (Betriebssystem und/oder Hardware), Anwendungsökosystem, Schnittstellen, Präferenzen des Programmierers, Programmiersprache, Administratorpräferenzen usw. unterschiedlich organisiert sein.
Es kann eine beliebige Kombination aus einem oder mehreren maschinenlesbaren Medien verwendet werden. Das maschinenlesbare Medium kann ein maschinenlesbares Signalmedium oder ein maschinenlesbares Speichermedium sein. Ein maschinenlesbares Speichermedium kann beispielsweise, aber nicht ausschließlich, ein System, ein Gerät oder eine Vorrichtung sein, das bzw. die eine elektronische, magnetische, optische, elektromagnetische, Infrarot- oder Halbleitertechnologie oder eine Kombination daraus zum Speichern von Programmcode verwendet. Zu den spezifischeren Beispielen (eine nicht erschöpfende Liste) für ein maschinenlesbares Speichermedium gehören: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Festwertspeicher (ROM), ein löschbarer programmierbarer Festwertspeicher (EPROM oder Flash-Speicher), ein tragbarer Compact-Disc-Festwertspeicher (CD-ROM), eine optische Speichervorrichtung, eine magnetische Speichervorrichtung oder jede geeignete Kombination daraus. Im Zusammenhang mit diesem Dokument kann ein maschinenlesbares Speichermedium jedes greifbare Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einem Gerät oder einer Vorrichtung zur Befehlsausführung enthalten oder speichern kann. Ein maschinenlesbares Speichermedium ist kein maschinenlesbares Signalmedium.
Ein maschinenlesbares Signalmedium kann ein übertragenes Datensignal mit darin enthaltenem maschinenlesbarem Programmcode enthalten, beispielsweise im Basisband oder als Teil einer Trägerwelle. Ein solches übertragenes Signal kann verschiedenen Formen annehmen, einschließlich, ohne darauf beschränkt zu sein, elektromagnetische Signale oder optische Signale oder eine geeignete Kombination davon. Ein maschinenlesbares Signalmedium kann jedes maschinenlesbare Medium sein, bei dem es sich nicht um ein maschinenlesbares Speichermedium handelt und das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einem Gerät oder eine Vorrichtung zur Befehlsausführungssystem verbreiten oder transportieren kann.
Programmcode, der auf einem maschinenlesbaren Medium verkörpert ist, kann über jedes geeignete Medium übertragen werden, einschließlich, ohne darauf beschränkt zu sein, drahtlose, drahtgebundene, optische Faserkabel, RF usw., oder jede geeignete Kombination der vorgenannten Möglichkeiten.
Computerprogrammcode zum Ausführen von Operationen für Aspekte der Offenbarung kann in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, einschließlich einer objektorientierten Programmiersprache wie der Programmiersprache Java®, C++ oder einer ähnlichen Sprache, einer dynamischen Programmiersprache wie Python, einer Skriptsprache wie der Programmiersprache Perl oder der Skriptsprache PowerShell, und herkömmlichen prozeduralen Programmiersprachen wie die Programmiersprache „C“ oder ähnlichen Programmiersprachen. Der Programmcode kann vollständig auf einem eigenständigen Rechner ausgeführt werden, er kann verteilt auf mehreren Rechnern ausgeführt werden, und er kann auf einem Rechner ausgeführt werden, während er auf einem anderen Rechner Ergebnisse liefert oder Eingaben entgegennimmt.
Der Programmcode/die Anweisungen können auch in einem maschinenlesbaren Medium gespeichert werden, das eine Maschine anweisen kann, in einer bestimmten Weise zu funktionieren, so dass die in dem maschinenlesbaren Medium gespeicherten Anweisungen einen Herstellungsartikel erzeugen, der Anweisungen enthält, die die in dem Flussdiagramm und/oder dem Blockdiagrammblock oder den Blockdiagrammböcken angegebene Funktion/Aktion ausführen.
9 zeigt ein Beispiel für ein Computersystem mit einem Fehlerbehebungsdienst, der einen Code-De-Identifikator enthält. Das Computersystem umfasst einen Prozessor 901 (der möglicherweise mehrere Prozessoren, mehrere Kerne, mehreren Knoten umfasst und/oder mit Multithreading implementiert ist usw.). Das Computersystem umfasst einen Speicher 907. Bei dem Speicher 907 kann es sich um einen Systemspeicher (z. B. um einen Cache-Speicher und/oder SRAM und/oder DRAM und/oder kondensatorfreien RAM und/oder Zwillingstransistor-RAM und/oder eDRAM und/oder EDO-RAM und/oder DDR-RAM und/oder EEPROM und/oder NRAM und/oder RRAM und/oder SONOS und/oder PRAM usw.) oder eine oder mehrere der oben bereits beschriebenen möglichen Realisierungen von maschinenlesbaren Medien handeln. Das Computersystem umfasst auch einen Bus 903 (z. B. PCI, ISA, PCI-Express, HyperTransport0-Bus, InfiniBand®-Bus, NuBus usw.) und eine Netzschnittstelle 905 (z. B. eine Fibre-Channel-Schnittstelle, Ethernet-Schnittstelle, Internet-Kleincomputer-System-Schnittstelle, SONET-Schnittstelle, drahtlose Schnittstelle usw.). Das System umfasst auch einen Fehlerbehebungsdienst 911 mit einem Code-De-Identifikator 913. Der Fehlerbehebungsdienst 911 trainiert eine Korrekturvorschlagsmodellpipeline für maschinelles Lernen mit Fehler-/Korrektur-Trainingsdaten von mehreren Organisationen und liefert vorgeschlagene Korrekturen für Fehler, die in einem Softwareprojekt erkannt wurden, basierend auf der Ausführung der trainierten Korrekturvorschlagsmodellpipeline für maschinelles Lernen mit erkannten Fehlern als Eingabe. Auf der Grundlage einer Modifikation des Programmcodes, bei dem festgestellt wurde, dass er Informationen enthält, die potenziell die besitzende/kontrollierende Organisation des jeweiligen Programmcodes identifiziert, ruft der Fehlerbehebungsdienst 911 den Code-De-Identifikator 913 dazu auf, Fehler/Korrektur-Trainingsdaten und/oder Programmcodekorrekturen zu de-identifizieren, die von der trainierten Korrekturvorschlagsmodellpipeline für maschinelles Lernen ausgegeben werden. Jede der zuvor beschriebenen Funktionalitäten kann teilweise (oder vollständig) in Hardware und/oder auf dem Prozessor 901 implementiert sein. Beispielsweise kann die Funktionalität mit einer anwendungsspezifischen integrierten Schaltung, in einer im Prozessor 901 implementierten Logik, in einem Koprozessor auf einem Peripheriegerät oder einer Karte usw. implementiert sein. Darüber hinaus können Realisierungen weniger oder zusätzliche Komponenten enthalten, die in 9 nicht dargestellt sind (z. B. Videokarten, Audiokarten, zusätzliche Netzschnittstellen, Peripheriegeräte usw.). Der Prozessor 901 und die Netzschnittstelle 905 sind an den Bus 903 gekoppelt. Auch wenn der Speicher 907 an den Bus 903 gekoppelt veranschaulicht ist, kann er auch an den Prozessor 901 gekoppelt sein.
Während die Aspekte der Offenbarung mit Bezug auf verschiedene Implementierungen und Anwendungen beschrieben werden, versteht es sich, dass diese Aspekte veranschaulichend sind und der Umfang der Ansprüche nicht darauf beschränkt ist. Im Allgemeinen können die hierin beschriebenen Techniken zur De-Identifizierung von Programmcode für organisationsübergreifendes Fehlerbehebungswissen mit Einrichtungen implementiert werden, die mit einem beliebigen Hardwaresystem oder beliebigen Hardwaresystemen kompatibel sind. Viele Änderungen, Modifikationen, Ergänzungen und Verbesserungen sind möglich.
Für Komponenten, Operationen oder Strukturen, die hier als eine einzelne Instanz beschrieben sind, können mehrere Instanzen vorgesehen sein. Schließlich sind die Grenzen zwischen den verschiedenen Komponenten, Operationen und Datenspeichern etwas willkürlich, und bestimmte Operationen werden im Zusammenhang mit bestimmten veranschaulichenden Ausgestaltungen dargestellt. Andere Zuordnungen von Funktionen sind denkbar und können in den Umfang der Offenbarung fallen. Im Allgemeinen können Strukturen und Funktionen, die in den Ausgestaltungsbeispielen als separate Komponenten dargestellt sind, als kombinierte Struktur oder Komponente implementiert sein. Ebenso können Strukturen und Funktionen, die als einzelne Komponente dargestellt sind, als separate Komponenten implementiert sein. Diese und andere Änderungen, Modifikationen, Ergänzungen und Verbesserungen können in den Umfang der Offenbarung fallen.
Die Verwendung der Formulierung „mindestens eines von“, die einer Aufzählung mit der Konjunktion „und“ vorangestellt wird, sollte nicht als ausschließliche Aufzählung behandelt und nicht als eine Aufzählung von Kategorien mit einem Gegenstand aus jeder Kategorie ausgelegt werden, sofern nicht ausdrücklich etwas Anderes angegeben wird. Ein Absatz, in dem es heißt „A und/oder B und/oder C“, kann mit nur einem der aufgelisteten Gegenstände, mehreren der aufgelisteten Gegenstände und einem oder mehreren der Gegenstände in der Liste und einem anderen nicht aufgelisteten Gegenstand verletzt werden.
Ausführungsbeispiele
Ausführungsbeispiele umfassen Folgendes:

Ausführungsform 1: Ein Verfahren umfasst das Erhalten einer Programmcodekorrektur für einen in einem Softwareprojekt identifizierten Fehler, wobei die Programmcodekorrektur einer ersten Organisation zugeordnet ist. Der strukturelle Kontext der Programmcodekorrektur wird bestimmt. Es wird zumindest teilweise auf der Grundlage des strukturellen Kontextes der Programmcodekorrektur bestimmt, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die erste Organisation identifizierend ist. Basierend auf der Bestimmung, dass die Programmcodekorrektur Programmcode umfasst, der potentiell für die erste Organisation identifizierend ist, wird die Programmcodekorrektur zumindest teilweise auf der Grundlage der Modifikation des potentiell identifizierenden Programmcodes de-identifiziert.
Ausführungsform 2: Verfahren gemäß Ausführungsform 1, wobei das Bestimmen des strukturellen Kontextes der Programmcodekorrektur das Bestimmen eines abstrakten Syntaxbaums der Programmcodekorrektur oder eines Steuerungsablaufgraphen der Programmcodekorrektur umfasst.
Ausführungsform 3: Verfahren gemäß Ausführungsform 2, wobei das Bestimmen des abstrakten Syntaxbaums der Programmcodekorrektur das Bestimmen des abstrakten Syntaxbaums zumindest teilweise auf der Grundlage von Unterschieden zwischen dem Quellcode des Fehlers und dem Quellcode der Programmcodekorrektur umfasst.
Ausführungsform 4: Ausführungsform gemäß Anspruch 2 oder 3, wobei das Bestimmen, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die erste Organisation identifizierend ist, das Auswerten von Knoten des strukturellen Kontextes der Programmcodekorrektur anhand einer oder mehrerer Regeln zur Bestimmung von potentiell identifizierendem Programmcode und das Bestimmen, ob zumindest ein erster der Knoten eine erste der einen oder mehreren Regeln erfüllt, umfasst.
Ausführungsform 5: Verfahren gemäß Ausführungsform 4, wobei die eine oder die mehreren Regeln Regeln zur Bestimmung umfassen, dass der Programmcode potentiell identifizierend ist, wenn der Programmcode nicht den Standard-Codeeinheiten oder den Open-Source-Codeeinheiten entspricht.
Ausführungsform 6: Verfahren gemäß einer der Ausführungsformen 1-5, wobei das Modifizieren des potenziell identifizierenden Programmcodes das Verschleiern oder Entfernen zumindest eines ersten Quellcodekonstrukts umfasst, das dem potenziell identifizierenden Programmcode entspricht, wobei das Verschleiern oder Entfernen eine de-identifizierte Darstellung des ersten Quellcodekonstrukts erzeugt.
Ausführungsform 7: Verfahren gemäß Ausführungsform 6, wobei das Entfernen des ersten Quellcodekonstrukts das Bestimmen einer Angabe des Typs des ersten Quellcodekonstrukts und das Ersetzen des ersten Quellcodekonstrukts durch die Angabe des Typs umfasst.
Ausführungsform 8: Verfahren gemäß den Ausführungsformen 6 oder 7, das ferner das Erzeugen und Speichern einer Zuordnung zwischen dem ersten Quellcodekonstrukt und der de-identifizierten Darstellung umfasst, wobei die Zuordnung auch die erste Organisation identifiziert.
Ausführungsform 9: Verfahren gemäß einer der Ausführungsformen 1-8, wobei das Erhalten der Programmcodekorrektur für den Fehler das Erhalten der Programmcodekorrektur für den Fehler aus einem Repository von gekennzeichneten Programmcodekorrekturen und entsprechenden Fehlern umfasst.
Ausführungsform 10: Verfahren gemäß einer der Ausführungsformen 1-9, das ferner das Bestimmen einer oder mehrerer vorgeschlagener Programmcodekorrekturen für den Fehler umfasst, wobei das Erhalten der Programmcodekorrektur für den Fehler das Erhalten der Programmcodekorrektur aus der einen oder den mehreren vorgeschlagenen Programmcodekorrekturen umfasst.
Ausführungsform 11: Nichtflüchtiges maschinenlesbares Medium oder mehrere nichtflüchtige maschinenlesbare Medien mit Programmcode zum De-identifizieren einer Programmcodekorrektur, die einer ersten Organisation zugeordnet ist, wobei der Programmcode dazu dient: eine strukturelle Darstellung der Korrektur zu erzeugen, wobei die strukturelle Darstellung mehrere Quellcodekonstrukte angibt; zumindest teilweise auf der Grundlage der strukturellen Darstellung der Korrektur zu bestimmen, ob zumindest ein erstes Quellcodekonstrukt der mehreren Quellcodekonstrukte Informationen enthält, die potenziell die erste Organisation identifizieren; und basierend auf einer Bestimmung, dass das erste Quellcodekonstrukt Informationen enthält, die potentiell die erste Organisation identifizieren, das erste Quellcodekonstrukt zu modifizieren, wobei die Modifikation des ersten Quellcodekonstrukts die potentiell identifizierenden Informationen entfernt oder verschleiert.
Ausführungsform 12: Nichtflüchtige maschinenlesbare Medien gemäß Ausführungsform 11, wobei der Programmcode zum Bestimmen, ob das erste Quellcodekonstrukt potentiell für die erste Organisation identifizierend ist, Programmcode zum Bestimmen umfasst, ob das erste Quellcodekonstrukt nicht einer oder mehreren Standard-Codeeinheiten oder einer oder mehreren Open-Source-Codeeinheiten entspricht.
Ausführungsform 13: Nichtflüchtige maschinenlesbare Medien gemäß den Ausführungsformen 11 oder 12, wobei der Programmcode zum Entfernen der potenziell identifizierenden Informationen Programmcode zum Ersetzen des ersten Quellcodekonstrukts durch einen Identifikator umfasst, der einen Typ des ersten Quellcodekonstrukts angibt.
Ausführungsform 14: Nichtflüchtige maschinenlesbare Medien gemäß einer der Ausführungsformen 11-13, wobei der Programmcode zum Erzeugen der strukturellen Darstellung der Korrektur Programmcode zum Erzeugen eines abstrakten Syntaxbaums der Korrektur umfasst, wobei der abstrakte Syntaxbaum mehrere Knoten umfasst, wobei jeder der mehreren Knoten einem entsprechenden Quellcodekonstrukt aus den mehreren Quellcodekonstrukte entspricht.
Ausführungsform 15: Eine Vorrichtung weist einen Prozessor und ein maschinenlesbares Medium auf. Das maschinenlesbare Medium hat Programmcode, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, eine oder mehrere Programmcodekorrekturen für einen in einem Softwareprojekt identifizierten Fehler zu erhalten, wobei jede der Programmcodekorrekturen einer entsprechenden Ursprungsorganisation aus den mehreren Ursprungsorganisationen zugeordnet ist, und wobei das Softwareprojekt einer ersten Organisation zugeordnet ist. Der Programmcode kann auch von dem Prozessor ausgeführt werden, so dass die Vorrichtung dazu veranlasst wird, für jede Programmcodekorrektur der einen oder mehreren Programmcodekorrekturen und der entsprechenden Ursprungsorganisation aus den mehreren Ursprungsorganisationen einen strukturellen Kontext der Programmcodekorrektur zu bestimmen; zumindest teilweise auf der Grundlage des strukturellen Kontextes der Programmcodekorrektur zu bestimmen, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die entsprechende Ursprungsorganisation aus den mehreren Ursprungsorganisationen identifizierend ist; und basierend auf einer Bestimmung, dass die Programmcodekorrektur Programmcode umfasst, der potentiell für die entsprechende Ursprungsorganisation aus den mehreren Ursprungsorganisationen identifizierend ist, die Programmcodekorrektur zumindest teilweise auf der Grundlage einer Modifikation des potentiell identifizierenden Programmcodes zu de-identifizieren.
Ausführungsform 16: Vorrichtung gemäß Ausführungsform 15, wobei der Programmcode, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, den strukturellen Kontext der Programmcodekorrektur zu bestimmen, Programmcode umfasst, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, einen abstrakten Syntaxbaum oder einen Steuerungsablaufgraphen der Programmcodekorrektur zu bestimmen.
Ausführungsform 17: Vorrichtung gemäß Ausführungsform 16, wobei der Programmcode, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird zu bestimmen, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die entsprechende Ursprungsorganisation identifizierend ist, Programmcode umfasst, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, Knoten des abstrakten Syntaxbaums oder des Steuerungsablaufgraphen anhand einer oder mehrerer Regeln zur Bestimmung von potenziell identifizierendem Programmcode auszuwerten.
Ausführungsform 18: Vorrichtung gemäß Ausführungsform 17, die ferner Programmcode umfasst, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, zumindest teilweise auf der Grundlage mindestens eines ersten der Knoten, der eine erste der einen oder mehreren Regeln erfüllt, zu bestimmen, dass die Programmcodekorrektur Programmcode umfasst, der potenziell für die entsprechende Ursprungsorganisation identifizierend ist, wobei die eine oder mehreren Regeln Regeln zur Bestimmung umfassen, dass Programmcode potenziell identifizierend ist, wenn der Programmcode nicht einer oder mehreren Standard-Codeeinheiten oder einer oder mehreren Open-Source-Codeeinheiten entspricht.
Ausführungsform 19: Vorrichtung gemäß einer der Ausführungsformen 15-18, wobei die Bestimmung des strukturellen Kontextes, die Bestimmung, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die entsprechende Ursprungsorganisation der mehreren Ursprungsorganisationen identifizierend ist, und die De-identifizierung des potenziell identifizierenden Programmcodes für jede Programmcodekorrektur mehrere de-identifizierte Programmcodekorrekturen erzeugt.
Ausführungsform 20: Vorrichtung gemäß Ausführungsform 19, die ferner einen Programmcode umfasst, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, für jede der mehreren de-identifizierten Programmcodekorrekturen festzustellen, ob die entsprechende Ursprungsorganisation aus den mehreren Ursprungsorganisationen dieselbe ist wie die erste Organisation; und basierend auf einer Bestimmung, dass die entsprechende Ursprungsorganisation aus den mehreren Ursprungsorganisationen dieselbe wie die erste Organisation ist, der de-identifizierten Programmcodekorrektur einen Rang oder eine Angabe zuzuordnen, dass die de-identifizierte Programmcodekorrektur eine Korrektur mit hoher Priorität ist.

Claims

Verfahren, das Folgendes umfasst: Erhalten einer Programmcodekorrektur für einen in einem Softwareprojekt identifizierten Fehler, wobei die Programmcodekorrektur einer ersten Organisation zugeordnet ist; Bestimmen des strukturellen Kontextes der Programmcodekorrektur; Bestimmen, zumindest teilweise auf der Grundlage des strukturellen Kontextes der Programmcodekorrektur, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die erste Organisation identifizierend ist; und basierend auf der Bestimmung, dass die Programmcodekorrektur Programmcode umfasst, der potentiell für die erste Organisation identifizierend ist, De-identifizieren der Programmcodekorrektur zumindest teilweise auf der Grundlage der Modifikation des potentiell identifizierenden Programmcodes.
Verfahren nach Anspruch 1, wobei das Bestimmen des strukturellen Kontextes der Programmcodekorrektur das Bestimmen eines abstrakten Syntaxbaums der Programmcodekorrektur oder eines Steuerungsablaufgraphen der Programmcodekorrektur umfasst.
Verfahren nach Anspruch 2, wobei das Bestimmen des abstrakten Syntaxbaums der Programmcodekorrektur das Bestimmen des abstrakten Syntaxbaums zumindest teilweise auf der Grundlage von Unterschieden zwischen dem Quellcode des Fehlers und dem Quellcode der Programmcodekorrektur umfasst.
Verfahren nach Anspruch 2, wobei das Bestimmen, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die erste Organisation identifizierend ist, Folgendes umfasst Auswerten von Knoten des strukturellen Kontextes der Programmcodekorrektur anhand einer oder mehrerer Regeln zur Bestimmung von potentiell identifizierendem Programmcode; und Bestimmen, ob zumindest ein erster der Knoten eine erste der einen oder mehreren Regeln erfüllt.
Verfahren nach Anspruch 4, wobei die eine oder die mehreren Regeln Regeln zur Bestimmung umfassen, dass der Programmcode potentiell identifizierend ist, wenn der Programmcode nicht den Standard-Codeeinheiten oder den Open-Source-Codeeinheiten entspricht.
Verfahren nach Anspruch 1, wobei das Modifizieren des potenziell identifizierenden Programmcodes das Verschleiern oder Entfernen zumindest eines ersten Quellcodekonstrukts umfasst, das dem potenziell identifizierenden Programmcode entspricht, wobei das Verschleiern oder Entfernen eine de-identifizierte Darstellung des ersten Quellcodekonstrukts erzeugt.
Verfahren nach Anspruch 6, wobei das Entfernen des ersten Quellcodekonstrukts das Bestimmen einer Angabe des Typs des ersten Quellcodekonstrukts und das Ersetzen des ersten Quellcodekonstrukts durch die Angabe des Typs umfasst.
Verfahren nach Anspruch 6, das ferner das Erzeugen und Speichern einer Zuordnung zwischen dem ersten Quellcodekonstrukt und der de-identifizierten Darstellung umfasst, wobei die Zuordnung auch die erste Organisation identifiziert.
Verfahren nach Anspruch 1, wobei das Erhalten der Programmcodekorrektur für den Fehler das Erhalten der Programmcodekorrektur für den Fehler aus einem Repository von gekennzeichneten Programmcodekorrekturen und entsprechenden Fehlern umfasst.
Verfahren nach Anspruch 1, das ferner das Bestimmen einer oder mehrerer vorgeschlagener Programmcodekorrekturen für den Fehler umfasst, wobei das Erhalten der Programmcodekorrektur für den Fehler das Erhalten der Programmcodekorrektur aus der einen oder den mehreren vorgeschlagenen Programmcodekorrekturen umfasst.
Nichtflüchtiges maschinenlesbares Medium oder mehrere nichtflüchtige maschinenlesbare Medien mit Programmcode zum De-identifizieren einer Programmcodekorrektur, die einer ersten Organisation zugeordnet ist, wobei der Programmcode dazu dient: eine strukturelle Darstellung der Korrektur zu erzeugen, wobei die strukturelle Darstellung mehrere Quellcodekonstrukte angibt; zumindest teilweise auf der Grundlage der strukturellen Darstellung der Korrektur zu bestimmen, ob zumindest ein erstes Quellcodekonstrukt der mehreren Quellcodekonstrukte Informationen enthält, die potenziell die erste Organisation identifizieren; und basierend auf einer Bestimmung, dass das erste Quellcodekonstrukt Informationen enthält, die potentiell die erste Organisation identifizieren, das erste Quellcodekonstrukt zu modifizieren, wobei die Modifikation des ersten Quellcodekonstrukts die potentiell identifizierenden Informationen entfernt oder verschleiert.
Nichtflüchtige maschinenlesbare Medien nach Anspruch 11, wobei der Programmcode zum Bestimmen, ob das erste Quellcodekonstrukt potentiell für die erste Organisation identifizierend ist, Programmcode zum Bestimmen umfasst, ob das erste Quellcodekonstrukt nicht einer oder mehreren Standard-Codeeinheiten oder einer oder mehreren Open-Source-Codeeinheiten entspricht.
Nichtflüchtige maschinenlesbare Medien nach Anspruch 11, wobei der Programmcode zum Entfernen der potenziell identifizierenden Informationen Programmcode zum Ersetzen des ersten Quellcodekonstrukts durch einen Identifikator umfasst, der einen Typ des ersten Quellcodekonstrukts angibt.
Nichtflüchtige maschinenlesbare Medien nach Anspruch 11, wobei der Programmcode zum Erzeugen der strukturellen Darstellung der Korrektur Programmcode zum Erzeugen eines abstrakten Syntaxbaums der Korrektur umfasst, wobei der abstrakte Syntaxbaum mehrere Knoten umfasst, wobei jeder der mehreren Knoten einem entsprechenden Quellcodekonstrukt aus den mehreren Quellcodekonstrukte entspricht.
Vorrichtung, die Folgendes aufweist: einen Prozessor; und ein maschinenlesbares Medium mit Programmcode, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, eine oder mehrere Programmcodekorrekturen für einen in einem Softwareprojekt identifizierten Fehler zu erhalten, wobei jede der Programmcodekorrekturen einer entsprechenden Ursprungsorganisation aus den mehreren Ursprungsorganisationen zugeordnet ist, wobei das Softwareprojekt einer ersten Organisation zugeordnet ist; für jede Programmcodekorrektur der einen oder mehreren Programmcodekorrekturen und der entsprechenden Ursprungsorganisation aus den mehreren Ursprungsorganisationen einen strukturellen Kontext der Programmcodekorrektur zu bestimmen; zumindest teilweise auf der Grundlage des strukturellen Kontextes der Programmcodekorrektur zu bestimmen, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die entsprechende Ursprungsorganisation aus den mehreren Ursprungsorganisationen identifizierend ist; und basierend auf einer Bestimmung, dass die Programmcodekorrektur Programmcode umfasst, der potentiell für die entsprechende Ursprungsorganisation aus den mehreren Ursprungsorganisationen identifizierend ist, die Programmcodekorrektur zumindest teilweise auf der Grundlage einer Modifikation des potentiell identifizierenden Programmcodes zu de-identifizieren.
Vorrichtung nach Anspruch 15, wobei der Programmcode, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, den strukturellen Kontext der Programmcodekorrektur zu bestimmen, Programmcode umfasst, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, einen abstrakten Syntaxbaum oder einen Steuerungsablaufgraphen der Programmcodekorrektur zu bestimmen.
Vorrichtung nach Anspruch 16, wobei der Programmcode, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird zu bestimmen, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die entsprechende Ursprungsorganisation identifizierend ist, Programmcode umfasst, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, Knoten des abstrakten Syntaxbaums oder des Steuerungsablaufgraphen anhand einer oder mehrerer Regeln zur Bestimmung von potenziell identifizierendem Programmcode auszuwerten.
Vorrichtung nach Anspruch 17, die ferner Programmcode umfasst, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird zumindest teilweise auf der Grundlage mindestens eines ersten der Knoten, der eine erste der einen oder mehreren Regeln erfüllt, zu bestimmen, dass die Programmcodekorrektur Programmcode umfasst, der potenziell für die entsprechende Ursprungsorganisation identifizierend ist, wobei die eine oder mehreren Regeln Regeln zur Bestimmung umfassen, dass Programmcode potenziell identifizierend ist, wenn der Programmcode nicht einer oder mehreren Standard-Codeeinheiten oder einer oder mehreren Open-Source-Codeeinheiten entspricht.
Vorrichtung nach Anspruch 15, wobei die Bestimmung des strukturellen Kontextes, die Bestimmung, ob die Programmcodekorrektur Programmcode umfasst, der potenziell für die entsprechende Ursprungsorganisation der mehreren Ursprungsorganisationen identifizierend ist, und die De-identifizierung des potenziell identifizierenden Programmcodes für jede Programmcodekorrektur mehrere de-identifizierte Programmcodekorrekturen erzeugt.
Vorrichtung nach Anspruch 19, die ferner einen Programmcode umfasst, der von dem Prozessor ausgeführt werden kann, so dass die Vorrichtung dazu veranlasst wird, für jede der mehreren de-identifizierten Programmcodekorrekturen festzustellen, ob die entsprechende Ursprungsorganisation aus den mehreren Ursprungsorganisationen dieselbe ist wie die erste Organisation; und basierend auf einer Bestimmung, dass die entsprechende Ursprungsorganisation aus den mehreren Ursprungsorganisationen dieselbe wie die erste Organisation ist, der de-identifizierten Programmcodekorrektur einen Rang oder eine Angabe zuzuordnen, dass die de-identifizierte Programmcodekorrektur eine Korrektur mit hoher Priorität ist.