DE102019008598A1

DE102019008598A1 - Identifikation und Visualisierung von Assoziationen zwischen Code, der von einem Modell generiert ist, und Quellen, welche die Codegeneration beeinflussen

Info

Publication number: DE102019008598A1
Application number: DE102019008598.1A
Authority: DE
Inventors: Xiaocang Lin; Sherman BRAGANZA; Wuwei LIANG; Wei Wang; Yong Huang; Michael IANNICELLI
Original assignee: MathWorks Inc
Current assignee: MathWorks Inc
Priority date: 2018-12-11
Filing date: 2019-12-11
Publication date: 2020-06-18

Abstract

Ein System bestimmt, welche Aspekte von Eingangsquellen zur Codegeneration beitragen und stellt Assoziationen zwischen den Eingangsquellen und Komponenten von Merkmalen des generierten Codes bereit. Diese Assoziationen können visualisiert werden, indem visuelle Hinweise der Assoziationen angezeigt werden. Die Eingangsquellen können von unterschiedlichem Typ sein, einschließlich, ohne hierauf begrenzt zu sein, ein Modell, ein Codegenerator und Werte für atomare Konfigurationseinstellungen zur Codegeneration. Der angezeigte visuelle Hinweis kann die Form einer sichtbaren Verbindung zwischen den Eingangsquellen und dem relative Teil oder den relative Teilen des generierten Programmcodes annehmen. Es können Empfehlungen generierte werden in Antwort auf Editierungen in dem generierte Programmcode hinsichtlich wie die Quellen modifiziert werden können, um gewünschte Änderungen in dem generierten Programmcode zu bewirken. Es kann eine Analyse ausgeführt werden, um Artefakte in dem generierten Programmcode zu identifizieren, und es können Assoziationen zu den Quellen identifiziert werden, um zu spezifizieren, welche Quelle zu Teilen des generierten Programmcodes beigetragen hat.

Description

Verwandte Anmeldungen
Diese Anmeldung beansprucht die Priorität der US Patentanmeldung Nr. 62/778,101 , eingereicht am 11. Dezember 2018, mit dem Titel „Identification And Visualization Of Associations Among Code Generated From A Model And Sources That Affect Code Generation“. Die Inhalte der vorgenannten Anmeldungen sind hiermit durch Bezugnahme mit aufgenommen.
Zusammenfassung
Gemäß einer beispielhaften Ausführungsform wird ein Verfahren von einem Prozessor einer Rechenvorrichtung ausgeführt. Für das Verfahren wird Programmcode für ein Modell und/oder einem oder mehreren Konfigurationswerten, die für das Modell eingestellt sind, generiert. Das Modell wird ausgeführt, oder der Programmcode, welcher das Verhalten eines Systems der echten Welt simuliert, wie etwa zum Beispiel ein physikalisches System, ein Rechnersystem, ein von Ingenieuren entworfenes System, ein eingebettetes System, ein biologisches System, ein chemisches System, etc., wird ausgeführt. Information bezüglich Verhaltenseffekten des Modells auf den Programmcode wird aufgezeichnet. Ein oder mehrere Konfigurationseffekte von einem oder von mehreren Konfigurationswerten, welche den Programmcode beeinflussen, werden ebenfalls aufgezeichnet. Zumindest einige der Verhaltenseffekte und der eine oder die mehreren Konfigurationseffekte sind voneinander abhängig. Für einen Teil des Programmcodes wird einer des einen oder der mehreren Konfigurationseffekte und/oder Verhaltenseffekte bestimmt, zu einem Merkmal des Teils des Programmcodes beizutragen. Diese Bestimmung beinhaltet Analysieren der aufgezeichneten Information und Ableiten, von den Verhaltenseffekten und dem einen oder den mehreren Konfigurationseffekten, einer Identität des einen oder der mehreren Konfigurationseffekte und/oder Verhaltenseffekten, die zu dem Merkmal des Teils des Programmcodes beigetragen haben. Eine Assoziation zwischen dem identifizierten von dem einen oder den mehreren Konfigurationseffekten und/oder Verhaltenseffekten, die zu dem Merkmal des Teils des Programmcodes beigetragen haben, wird gespeichert. Dementsprechend erlaubt das Verfahren eine verbesserte Mensch-Maschine-Interaktion, da spezifisch die Konfigurationseffekte computerunterstützt erhalten werden können, spezifischer automatisch erhalten werden können. Weiter vorteilshaft wird bzw. werden zumindest für einen Teil des Programmcodes ein oder mehrere Konfigurationseffekte und/oder Verhaltenseffekte auf computerunterstützte Weise bestimmt, was es ermöglicht, eine Assoziation zwischen dem identifizierten von dem einen oder den mehreren Konfigurationseffekten und/oder Verhaltenseffekten, die zu dem Merkmal des Teils des Programmcodes beigetragen haben, bereitzustellen, so dass Effekte und/oder der Einfluss individueller Merkmale auf das Verhalten des Codes und/oder das Modell identifiziert werden könne. Dementsprechend ermöglicht das Verfahren eine verbesserte computerunterstützte Generation von Code. Weiter vorteilshaft kann das Verfahren das Ausrollen von Code und/oder Anpassung und/oder Optimierungen und/oder kundenspezifische Anpassungen für unterschiedliche Systeme, auf die der generierte Code ausgerollt werden soll, ermöglichen.
Die Analyse, welche von dem Verfahren ausgeführt wird, kann in einigen Fällen den einen oder die mehreren Konfigurationseffekte als zu dem Merkmal beitragen identifizieren. In anderen Fällen kann die Analyse den einen oder die mehreren Verhaltenseffekte als zu dem Merkmal beitragend identifizieren. Die Konfigurationseffekte können von einem oder von mehreren der folgende Konfigurationswerte herrühren: Wahl von Namensgebungsregeln für Identifikatoren, Wahl einer Speicherklasse, Wahl eines Lösertyps, Wahl eines Lösers, Wahl von zu importierenden Daten, Wahl von zu exportierenden Daten, Zielhardwaredetails, Codierstilparameter oder Wahl der Programmiersprache des generierten Programmcodes. Vorteilhafter Weise, gemäß einer oder beider der vorgenannten Ausführungsformen, können Assoziationen zwischen mehreren Typen von Quellen identifiziert werden und/oder Programmcode durch einen Codegenerator von den Quellen generiert werden.
Der identifiziert von dem einen oder den mehreren Verhaltenseffekten kann das Ergebnis von zumindest einem der folgenden sein: eine Wahl einer Optimierung bei der Codegeneration, ein hinzugefügtes Merkmal des Codegenerators, ein Patch, der auf den Codegenerator angewandt wurde, ein Algorithmus des Modells, eine Änderung an dem Modell, um einen Fehler zu beheben, oder eine Änderung an dem Modell, um den generierten Programmcode kompatibel mit einem Codierstandard zu machen.
In einigen Ausführungsformen wird die gespeicherte Assoziation verwendet, um zu identifizieren, welcher von dem einen oder den mehreren Konfigurationswerten, Aspekten des Modells und/oder Aspekten des Codegenerators zu dem Merkmal des Teils des Programmcodes beigetragen hat. Ein visueller Hinweis kann auf einer Anzeige angezeigt werden. Der visuelle Hinweis macht die identifizierten Konfigurationswerte, Aspekte des Modells und/oder Aspekte des Codegenerators, welche zu dem Merkmal des Teils des Programmcodes beigetragen haben, visuell unterscheidbar. Die Anzeige kann durch einen programmtechnischen Mechanismus automatisch getriggert werden. Alternativ kann die Anzeige in Antwort auf ein Benutzerschnittstellenereignis erfolgen.
Das Modell kann zum Beispiel ein graphisches Modell oder ein textliches Modell sein. Die Konfigurationswerte können atomare Konfigurationswerte (wie nachfolgend beschrieben) sein. Vorteilhafter Weise kann auszurollender Code und/oder eine Anpassung und/oder Optimierungen und/oder kundenspezifische Anpassungen für unterschiedliche Systeme ermöglicht werden, auf welchen der generierte Code ausgerollt werden soll. Das atomare Nachverfolgen bzw. Tracing, spezifischer die Identifikation von Aspekten von Quellen auf einer atomaren Ebene, kann es Benutzern ermöglichen, geeignete Änderungen an dem Modell oder an Modellkonfigurationen vorzunehmen, um gewünschten Code zu erhalten.
Es kann unterschiedliche Beziehungen zwischen Konfigurationswerten geben. Zum Beispiel mag zumindest einer der Konfigurationswerte zumindest eine der folgenden Beziehungen relativ zum Verursachen des einen oder der mehreren Konfigurationseffekte aufweisen: eine logische und Beziehung, eine logische oder Beziehung, eine überschreibende bzw. überstimmende Beziehung, wobei einer der zwei Konfigurationswerte den anderen überschreibt bzw. überstimmt, oder eine Kombinationsbeziehung, wobei die zumindest zwei Konfigurationswerte jeweils zu dem einen oder den mehreren Konfigurationseffekten beitragen.
Das oben beschriebene Verfahren kann ausgeführt werden, indem von einem Computer ausführbare Anweisungen ausgeführt werden, die auf einem nichttransitorischen computerlesbaren Speichermedium gespeichert sind.
In beispielhaften Ausführungsformen kann ein Verfahren von einer Rechenvorrichtung ausgeführt werden. Das Verfahren kann beinhalten Identifizieren, dass generierter Code modifiziert wurde, so dass er eine Modifikation aufweist, wobei der generierte Code erzeugt wurde von einem Codegenerator für mehrere Quellen, die ein Modell beinhalten, wie etwa ein graphisches Modell oder ein Textmodell, und zumindest einem anderen Quellentyp, welche die Codeerzeugung durch den Codegenerator beeinflusst. Es wird eine Bestimmung gemacht, wie die Quellen modifiziert werden können, um die Modifikation mittels Codegeneration durch den Codegenerator zu bewirken. Auf der Anzeigevorrichtung wird Information angezeigt, die sich darauf bezieht, wie die Quellen modifiziert werden können, um die Modifikation mittels Codegeneration durch den Codegenerator zu bewirken. Es kann Information erfasst werden, die sich auf Beziehungen zwischen Quellen bezieht, und verwendet werden beim Bestimmen, wie die Quellen modifiziert werden können. Wie die Quellen modifiziert werden können kann in einer priorisierten Reihenfolge basierend auf einem vorbestimmten Priorisierungssystem angezeigt werden. Das vorbestimmte Priorisierungssystem kann auf zumindest einem basieren von vergangenem Verhalten, einer empfangenen Präferenz oder einer Regel. Dieses Verfahren kann ausgeführt werden, indem von einem Computer ausführbare Anweisungen ausgeführt werden, die auf einem nichttransitorischen computerlesbaren Speichermedium gespeichert sind.
Gemäß einer anderen beispielhaften Ausführungsform wird ein Verfahren von einem Prozessor einer Rechenvorrichtung ausgeführt. Das Verfahren beinhaltet das Ausführen einer Analyse eines Teils von generiertem Code, welcher von einem Codegenerator führ mehrere Eingabequellen erzeugt wird. Die mehreren Eingabequellen können ein graphisches Modell und eine andere Eingabequelle von einem Typ, der kein graphisches Modell ist, und der die Erzeugung des generierten Codes durch den Codegenerator beeinflusst, beinhalten. Die Analyse liefert Ergebnisse. Es wird eine Bestimmung gemacht, welche der Eingabequellen zu den Ergebnissen der Analyse beigetragen hat. Eine Nachverfolgung bzw. Trace der Ergebnisse der Analyse zu den bestimmten Eingangsquellen, welche zu den Ergebnissen beigetragen haben, wird auf einer Anzeigevorrichtung angezeigt. Die Analyse kann eines der folgenden identifizieren: Verstöße gegen einen Codierstandard, Kompilationsfehler, Fehler im Programmcode, dass ein Teil des generierten Codes nicht von einem Code Prover bzw. einem Codebeweiser bewiesen werden kann, oder Änderungen in dem generierten Code relativ zu zuvor generiertem Code, der durch den Codegenerator von dem graphischen Modell generiert wurde. Die Analyse kann eine statische Analyse oder eine dynamische Analyse sein.
Figurenliste

1A zeigt Komponenten in einer beispielhaften Ausführungsform.
1B zeigt eine beispielhafte Liste von Quelltypen.
1C zeigt eine beispielhafte Liste von Aspekte eines Codegenerators, die sich ändern können und die Codegeneration beeinflussen können.
1D zeigt eine beispielhafte Liste von Typen von Konfigurationseinstellungen.
1E zeigt ein Beispiel von Quellenaspekten, die als verhaltensbetreffend oder nicht-verhaltensbetreffend kategorisiert sind.
2A ist ein Flussdiagramm, welches eine grobe Übersicht von Schritten angibt, die in einer beispielhaften Ausführungsform ausgeführt werden.
2B zeigt Quellen, einen Codegenerator und erzeugten Programmcode.
2C zeigt ein Beispiel eines Baums von Information, die während der Codeerzeugung für Quellen gespeichert werden können.
2D ist ein Flussdiagramm von Schritten, die in einer beispielhaften Ausführungsform ausgeführt werden, um eine umgekehrte Assoziation zwischen Quellaspekt(en) und Komponente(n) von erzeugtem Programmcode zu erstellen.
2E ist ein Flussdiagramm von Schritten, die in einer beispielhaften Ausführungsform ausgeführt werden, um eine Vorwärts-Assoziation zwischen Komponente(n) generierten Programmcodes und Quellenaspekt(en).
3A illustriert ein Beispiel einer Anzeige einer Assoziation unter eine Komponente in generiertem Programmcode und Quellenaspekten.
3B illustriert ein Beispiel einer Anzeige einer Assoziation zu Quellenaspekten und Komponenten von generiertem Programmcode.
4A ist ein Flussdiagramm, das die Schritte illustriert, die bei der Analyse ausgeführt werden, in einer beispielhaften Ausführungsform.
4B illustriert beispielhafte Analysetypen.
5A und 5B illustrieren eine beispielhafte Benutzerschnittstelle, welche eine Assoziationen zwischen Quellenkomponenten und einem Artefakten der Analyse zeigt.
6A ist ein Flussdiagramm, das Schritte illustriert, die ausgeführt werden, um Unterschiede in generiertem Programmcode mit Quellenaspekten zu assoziieren.
6B zeigt ein Beispiel einer Benutzerschnittstelle welche Assoziationen unter einem Quellenaspekt, einer Codeänderung und einem Kompilierfehler zeigt.
7 illustriert beispielhafte unterschiedliche Typen von Codedifferenzen.
8A illustriert eine beispielhafte Benutzerschnittstelle, in welcher Parameter für einen Löser ausgewählt werden können.
8B illustriert eine beispielhafte Benutzerschnittstelle, in welcher Import/Export Einstellungen ausgewählt werden können.
8C ist eine beispielhafte Benutzerschnittstelle, die ein Beispiel illustriert, in welchem Hardwareimplementierungsparameter ausgewählt werden können.
8D illustriert eine beispielhafte Benutzerschnittstelle, in welcher Namensgebungsregeln ausgewählt werden können und eine Erläuterung der Namensgebungsregelsyntax bereitgestellt werden kann.
8E illustriert eine beispielhafte Benutzerschnittstelle, in welcher Codierstilparameter ausgewählt werden können.
9A illustriert ein Beispiel einer beispielhaften Benutzerschnittstelle, in welcher Codegenerierungsparameter ausgewählt werden können.
9B illustriert eine beispielhafte Benutzerschnittstelle, in welcher Optimierungsgrade und -prioritäten ausgewählt werden können.
9C illustriert eine beispielhafte Benutzerschnittstelle, in welcher die Priorität maximaler Ausführungsgeschwindigkeit ausgewählt wurde.
9D illustriert eine beispielhafte Benutzerschnittstelle, in welcher die Priorität minimaler Nutzung von Speicher mit wahlfreiem Zugriff (RAM) ausgewählt wurde.
10A zeigt ein Beispiel einer logischen und Beziehung unter Quellenaspekten.
10B zeigt ein illustratives Merkmal in generiertem Programmcode, wenn Pufferwiederverwendung nicht ausgewählt ist, im Kontrast zum Merkmal, das in 10A gezeigt ist.
10C zeigt ein Beispiel für eine überschreibende bzw. überstimmende Beziehung, wobei eine Speicherklasse ausgewählt wird, welche eine Default Speicherklasse überschreibt.
10D zeigt ein Beispiel von generiertem Programmcode, wobei eine Default Speicherklasse ausgewählt ist für Inports in einem Modell.
10E zeigt ein Beispiel von generiertem Programmcode, wenn eine Speicherklasse ausgewählt ist für einen Inport, um die Default Speicherklasse zu überschreiben.
11A ist ein Flussdiagramm von Schritten, die ausgeführt werden, um Empfehlungen zu generieren und zu akzeptieren, in einer beispielhaften Ausführungsform.
11B zeigt ein Beispiel von Empfehlungen, die Ergebnisse des Akzeptierens der Empfehlungen und mögliche Nebenwirkungen.
11C zeigt ein Beispiel, in welchem die Empfehlungen in Tooltips angezeigt werden.
12A illustriert eine Rechenvorrichtung, die geeignet ist, eine beispielhafte Ausführungsform zu verwirklichen.
12B illustriert eine verteilte Umgebung, die geeignet ist, eine beispielhafte Ausführungsform zu verwirklichen.

Detaillierte Beschreibung
Herkömmliche Systeme bieten nicht die Möglichkeit, Assoziationen zwischen mehreren Arten von Quellen und generiertem Programmcode, der von einem Codegenerator aus den Quellen generiert wird, zu identifizieren. In diesem Kontext bezieht sich eine Quelle auf etwas, das modifiziert werden kann und das Einfluss hat auf den Programmcode, der von dem Codegenerator von einem Modell generiert wird. Darüber hinaus ist es mit herkömmlichen Systemen schwierig zu wissen, wie eine Quelle oder wie Quellen zu modifizieren sind, um eine gewünschte Änderung in dem generierten Programmcode zu bewirken. Die hierin beschriebenen beispielhaften Ausführungsformen können diese Unzulänglichkeiten herkömmlicher Systeme überwinden.
Die hierin beschriebenen beispielhaften Ausführungsformen können auch in der Lage sein, Aspekte der Quellen zu analysieren, welche zu einem Merkmal des generierten Programmcodes beitragen. Die beispielhaften Ausführungsformen sind daher nicht auf ein einfaches Abbilden bzw. Mappen zwischen einem Modell und generiertem Programmcode beschränkt. Die beispielhaften Ausführungsformen können vielmehr in der Lage sein, Assoziationen nicht nur zu dem Modell, sondern auch zu anderen Arten von Quellen zu identifizieren, welche zu den resultierenden Merkmalen des generierten Programmcodes beitragen, wie etwa Konfigurationseinstellungen für die Codegeneration und Versionen oder Modifikationen an dem graphischen Modell und/oder Codegenerator. Die beispielhaften Ausführungsformen können daher Assoziationen zwischen mehreren Quellen unterschiedlichen Typs und den resultierenden Merkmal(en) identifizieren. Die beispielhaften Ausführungsformen stellen daher insbesondere eine verbesserte Mensch-Maschine Interaktion und eine verbesserte und effiziente Simulation des Verhaltens eines Systeme der realen Welt bereit, indem Assoziationen zwischen mehreren Quellen unterschiedlichen Typs und der resultierenden Merkmal(e) bereitgestellt werden.
Quellen können nach den Effekten kategorisiert werden, die sie auf den generierten Programmcode haben. Dies repräsentiert eine Art, die Quellen nach Typ zu kategorisieren. Eine Quelle kann der Typ sein, der das beobachtbare Verhalten/Ergebnisse des generierten Programmcodes beeinflusst. Dieser Typ von Quelle wird hierin als „verhaltensbetreffend“ bezeichnet, da dieser Typ von Quelle einen „verhaltensbetreffenden“ Effekt hat. Umgekehrt kann eine Quelle von dem Typ sein, der das beobachtbare Verhalten/Ergebnisse des generierten Programmcodes nicht beeinflusst, aber nicht-verhaltensbetreffende Effekte auf den generierten Programmcode hat (beispielsweise Speicherverbrauch des generierten Programmcodes). Dieser Typ von Quelle wird hierin al seine „nicht-verhaltensbetreffende“ Quelle bezeichnet. Es sei verstanden, dass einige Quellen sowohl verhaltensbetreffende Effekte als auch nicht-verhaltensbetreffende Effekte haben. In solchen Fällen können Aspekte der Quellen wie angebracht als verhaltensbetreffend oder nicht-verhaltensbetreffend kategorisiert werden.
Der Typ einer Quelle kann die Varietät der Quelle identifizieren. Zum Beispiel können unterschiedliche Typen von Quellen ein Modell und einen Codegenerator beinhalten. Darüber hinaus bilden Konfigurationseinstellungen und/oder Konfigurationswerte, wie etwa Wahl von Namensgebungsregeln, Wahl einer Speicherklasse einen weiteren Typ von Quelle, welcher den generierten Programmcode beeinflusst. Weiter bildet die Wahl von Optimierungen, die von einem Codegenerator angewandt werden, einen Typ von Quelle dahingehend, dass sie Konfigurationseinstellungen für den Codegenerator sind.
Systeme und/oder Verfahren wie hierin beschrieben können eine Rechenumgebung verwenden, wie etwa eine Umgebung zum technischen Rechnen („technical computing environment“, TCE), um Rechenoperationen auszuführen. Eine TCE kann eine hardwarebasierte Logik oder eine Kombination von hardware- und Softwarebasierter Logik beinhalten, welche eine Rechenumgebung bereitstellt, die es ermöglicht, dass Aufgaben bzw. Tasks ausgeführt werden (beispielsweise von Benutzern), die sich auf Disziplinen wie etwa, ohne hierauf beschränkt zu sein, Mathematik Wissenschaft, Ingenieurswesen, Medizin und Wirtschaft. Die TCE kann textbasierte Umgebungen (beispielsweise MATLAB® Software), eine graphisch basierte Umgebung (beispielsweise Simulink® Software, Stateflow® Software, SimEvents® Software, Simscape™ Software, etc., von The MathWorks, Incorporated; VisSim von Visual Solutions; LabView® von National Instruments, etc.), oder eine andere Art von Umgebung, wie etwa eine hybride Umgebung, die beispielsweise eine oder mehrere von den vorgenannten textbasierten Umgebungen und eine oder mehrere der vorgenannten graphisch basierten Umgebungen beinhalten kann, beinhalten.
Die TCE kann integriert sein in, oder kann zusammenarbeiten mit einer graphischen Modellierungsumgebung, die graphische Werkzeuge zum Erstellen von Modellen von Systemen und/oder Prozessen bereitstellen kann. Die TCE kann weitere Werkzeuge beinhalten, wie etwa Werkzeuge, die dazu entworfen sind, ein Modell in eine alternative Repräsentation umzuwandeln, wie etwa Computerquellcode, kompilierten Computercode oder eine Hardwarebeschreibung (beispielsweise eine Beschreibung eines Schaltungslayouts). Diese alternative Repräsentation kann auch einen Link auf einen Bezeichner bzw. Bezeichner beinhalten, der mit einem Modellelement eines graphischen Modells assoziiert ist. Der Bezeichner kann es daher der TCE ermöglichen, zu dem Modellelement und/oder zu einer oder mehreren hierarchische Ebenen eines Modells, in welchen das Modellelement existiert, zu navigieren. Zusätzlich oder alternativ kann der Bezeichner es der TCE ermöglichen, zu einem Element in der alternativen Repräsentation zu navigieren, welches den Link zu dem Bezeichner enthält. Zusätzlich oder alternativ kann der Bezeichner es der TCE ermöglichen, zu einer oder zu mehreren hierarchische Ebenen der alternativen Repräsentation zu navigieren, in welchen das Element existiert. In einigen Implementierungen kann die TCE diese Fähigkeit unter Verwendung graphischer Werkzeugkisten bzw. Toolboxen (beispielsweise Werkzeugkisten für Signalverarbeitung, Bildverarbeitung, Farbmanipulation, Datenplotting, Parallelverarbeitung, etc.) bereitstellen. In einigen Implementierungen kann die TCE diese Funktionen als Blocksätze bereitstellen. In einigen Implementierungen kann die TCE diese Funktionen auf andere Weise bereitstellen.
Modelle, welche mit der TCE generiert werden, können beispielsweise Modelle eines physikalischen Systems, eines Rechnersystems, eines von Ingenieuren entworfenen Systems, eines eingebetteten Systems, eines biologischen Systems, eines chemischen Systems, etc. sein. Die Modelle können basieren auf Differentialgleichungen, partiellen Differentialgleichungen, Differenzengleichungen, Differential- und algebraischen Gleichungen, diskrete Ereignissysteme, Zustandsübergangssysteme, Zustandsdiagramme, Datenflusssysteme, etc. In einigen Implementierungen können Modelle hierarchisch sein und eine Anzahl von hierarchischen Ebenen beinhalten. Eine Hierarchieebene eines hierarchischen Modells kann durch eine Entität, wie etwa ein Untersystem oder ein Unterdiagramm, repräsentiert sein. Das Untersystem oder das Unterdiagramm kann mit einem lokalen Namensraum assoziiert sein, wobei Daten innerhalb des Namensraums global verfügbar sein können, aber nicht außerhalb des Namensraums.
Ein Modell, das mit der TCE generiert wird, kann beispielsweise Gleichungen, Aktionssprache, Zuweisungen, Bedingungen, Berechnungen, Algorithmen, Funktionen, Verfahren und/oder Prozessabläufe beinhalten. Das Modell kann beispielsweise implementiert sein als zeitbasierte Blockdiagramme (beispielsweise mittels dem Simulink® Produkt, erhältlich von The MathWorks, Incorporated), diskrete Ereignis-basierte Diagramme (beispielsweise mittels dem SimEvents® Produkt, erhältlich von The MathWorks, Incorporated), Datenflussdiagramme, Zustandsübergamsdiagramme (beispielsweise mittels dem Stateflow® Produkt, erhältlich von The MathWorks, Incorporated), Softwarediagramme, eine textfeldbasierte und/oder dynamisch typisierte Sprache (beispielsweise mittels dem MATLAB® Produkt, erhältlich von The MathWorks, Incorporated), akausale Blockdiagramme (beispielsweise mittels dem Simscape™ Produkt, erhältlich von The MathWorks, Incorporated) und/oder als ein anderer Typ von Modell.
Die TCE kann ein oder mehrere textbasierte Produkte verwenden, wie etwa textuelle Modellierungsumgebungen. Eine textbasierte Umgebung kann beispielsweise implementiert sein unter Verwendung von Produkten wie beispielsweise, ohne hierauf beschränkt zu sein, MATLAB von The MathWorks, Incorporated; Octave von der Free Software Foundation; MATRIXx von National Instruments; Python von der Python Software Foundation; Comsol Script von Comsol Inc.; Mathematica von Wolfram Research, Inc.; Mathcad von Mathsoft Engineering & Education Inc.; Maple von Maplesoft; Extend von Imagine That Inc.; Scilab von dem französischen Nationalen Forschungsinstitut für Informatik und Automatisierung (INRIA), Virtuoso von Cadence Design Systeme, Inc.; oder Modelica von der Modelica Assoziation oder Dymola von Dassault Systemes. In einigen Ausführungsformen kann die textbasierte Modellierungsumgebung Hardware und/oder Software beinhalten, die auf Logik basiert, welche eine Rechenumgebung bereitstellt, welche es Benutzern erlaubt, Aufgaben, die sich auf Disziplinen bezieht, wie beispielsweise, ohne hierauf beschränkt zu sein, Mathematik, Wissenschaft, Ingenieurswesen, Medizin, Wirtschaft, etc., effizienter auszuführen als wenn die Aufgaben in einer anderen Rechenumgebung würden, wie etwa einer Umgebung, welche es erfordern würde, dass der Benutzer Code in einer herkömmlichen Programmiersprache wie etwa C++, C, Fortran, Pascal, etc. entwickelt.
In einigen Implementierungen kann die textbasierte Modellierungsumgebung eine dynamisch typisierte Sprache beinhalten, die verwendet werden kann, um Probleme und/oder Lösungen in mathematischen Notationen auszudrücken, die den Fachleuten in den relevanten Gebieten bekannt sind. Die Modellierungsumgebung kann beispielsweise ein Feld bzw. Array al sein Basiselement verwenden, wobei das Feld keine Dimensionierung erfordert. Diese Felder können verwendet werden, um Feldprogrammierung zu ermöglichen, indem Operationen anwendbar sind auf einen ganzen Satz von Werten, wie etwa Werten in einem Feld. Feldprogrammierung kann es erlauben, dass feldbasierte Operationen als Hochsprachenprogrammierungstechniken oder -modell behandelt werden, welche es einem Programmierer erlauben, in gesamten Aggregationen von Daten zu denken und auf diesen zu arbeiten, ohne auf explizite Schleifen von einzelnen, nicht feldbasierten, das heißt, skalaren Operationen zurückgreifen zu müssen.
Die Modellierungsumgebung kann weiter angepasst sein, Matrix- und/oder Vektorformulierungen auszuführen, die verwendet werden können zur Datenanalyse, Datenvisualisierung, Anwendungsentwicklung, Simulation, Modellierung, Algorithmusentwicklung, etc. Diese Matrix- und/oder Vektorformulierungen können in vielen Gebieten verwendet werden, wie etwa Statistik, Finanzwesen, Bildverarbeitung, Signalverarbeitung, Steuerungs- und/oder Regelungsentwurf, computerunterstütztes Design (CAD), Produktlebenszyklusmanagement (PLM), Biowissenschaften, Bildung, diskrete Ereignisanalyse und/oder Design, zustandsbasierte Analyse und/oder Design, etc.
In einer anderen beispielhaften Ausführungsform kann die TCE in einer graphisch basierten Modellierungsumgebung implementiert sein unter Verwendung von Produkten wie beispielsweise, ohne hierauf beschränkt zu sein, Simulink®, Stateflow®, SimEvents®, Simscape™, etc. von The MathWorks, Incorporated; VisSim von Visual Solutions; LabView® von National Instruments; Dymola von Dassault Systemes; SoftWIRE von Measurement Computing; WiT von DALSA Coreco; VEE Pro oder SystemVue von Agilent; Vision Program Manager von PPT Vision; Khoros von Khoral Research; Gedae von Gedae, Inc.; Scicos von INRIA; Virtuoso von Cadence; Rational Rose von IBM; Rhapsody oder Tau von IBM; Ptolemy von der University of California at Berkeley; oder Aspekten einer Unified Modeling Language (UML) oder SysML Umgebung.
Die beispielhaften Ausführungsformen ermöglichen die Identifikation von Aspekten von Quellen auf einer atomaren Ebene sowie auch auf nicht atomaren Ebenen. Ein atomarer Quellenaspekt bezieht sich auf einen Aspekt der Quellen, der einen beobachtbaren und nachverfolgbaren bzw. tracebaren Effekt in dem generierten Code hervorruft. Die Identifikation von Aspekten von Quellen auf einer atomaren Ebene, was auch als atomares Nachverfolgen bzw. Tracing bezeichnet werden kann, erlaubt es Benutzern, geeignete Änderungen an einem Modell oder an Modellkonfigurationen vorzunehmen, um erwünschten Code zu erzielen.
Der Begriff „atomar“ kann hierin verwendet werden, um sich auf Quellenaspekte zu beziehen, wie zum Beispiel etwa Konfigurationseinstellungen, Modellelemente, Optimierungsauswahlen, etc. „Atomar“ kann hierin auch verwendet werden, um sich auf Effekte zu beziehen, die von den atomaren Quellenaspekten während der Codegenerierung bewirkt werden. Einstellungen auf höherer Ebene, wie etwa die Auswahl eines Optimierungsgrads, sind beispielsweise nichtatomare Quellenaspekte. Konfigurationseinstellungen auf niedrigerer Ebene, die eingestellt werden in Antwort auf die Einstellungen auf höherer Ebene können atomare Quellenaspekte sein.
Die beispielhaften Ausführungsformen können es einem erlauben, Assoziationen zwischen atomaren Quellenaspekten und Merkmalen in dem generierten Programmcode zu sehen. Es ist daher insbesondere möglich, Assoziationen zwischen einem Aspekt einer Quelle, wie etwa einem oder mehreren Konfigurationseffekten und/oder einem oder mehreren verhaltensbetreffenden Effekten von zum Beispiel dem Modell und/oder dem Codegenerator, und Merkmalen des generierten Codes zu sehen. Genauer ist es daher möglich, Aspekte einer Quelle zu identifizieren, die dann modifiziert werden können, um eine gewünschte Änderung in dem generierten Code zu bewirken, und umgekehrt. Jedes Merkmal kann eine oder mehrere Komponenten haben. Atomare Quellenaspekte können mit atomaren Komponenten in dem generierten Programmcode assoziiert sein. Die Visualisierung jeder derartigen Assoziation kann alle derartige Komponenten und assoziierten Quellenaspekte zeigen. Die atomare Natur von Quellenaspekten und resultierenden atomaren Konfigurationseffekt(en), die in den Komponenten wahrgenommen werden, ermöglichen es einem, auf einer fundamentalen Ebene zu identifizieren, was in den Quellen sich mittels der Codegeneration in den relevanten Merkmalen in dem generierten Programmcode manifestiert und umgekehrt. Atomare Ebene in einem Code wie in dieser Anmeldung verwendet kann sich beispielsweise auf granulare Komponenten von Programmcode beziehen.
Die beispielhaften Ausführungsformen können eine Visualisierung von Assoziationen zwischen Ergebnissen der Analyse des generierten Programmcodes und der Quellenaspekte identifizieren und erzeugen. Zum Beispiel kann eine statische Analyse ausgeführt werden, wie etwa Identifizieren von Artefakten, wie Kompilationsfehlern, Logikfehlern, Codestandardverletzungen und Codebeweisfehlern. Die statische Analyse kann eine Analyse der Codesyntax beinhalten, wie etwa eine strukturelle Analyse, oder eine Analyse des Verhaltens des Codes, ohne den Code auszuführen. In den beispielhaften Ausführungsformen können die Quellenaspekte, welche in den Artefakten resultieren, identifiziert werden und die Assoziation der Quellenaspekte und der Artefakte kann visualisiert werden. Ähnlich kann eine dynamische Analyse (das heißt eine Analyse, die auf dem generierten Programmcode ausgeführt wird, wenn der generierte Programmcode ausgeführt wird), wie etwa Code Profiling und Codeabdeckungsanalyse, ausgeführt werden, um Artefakte zu erzeugen. Die Ergebnisse der statischen Analyse und/oder der dynamischen Analyse können ein oder mehrere identifizierte Artefakte sein. Beispielhafte Ausführungsformen können Assoziationen zwischen den Artefakte und Quellenaspekten der Quellen identifizieren und eine Visualisierung der Assoziationen bereitstellen. Dies ermöglicht insbesondere eine verbesserte Mensch-Maschine-Interaktion, zum Beispiel wenn spezifische Änderungen an dem Code gewünscht sind.
Die beispielhaften Ausführungsformen können auch nützliche Information bezüglich generiertem Programmcode bereitstellen, welcher generiert ist von einem ersten Satz Quellen, mit generiertem Programmcode, der aus einem zweiten Satz von Quellen generiert ist. In beispielhaften Ausführungsformen kann ein Codedifferenzierwerk die Unterschiede zwischen den Sätzen von generiertem Programmcode identifizieren, und kann identifizieren, welche atomaren Quellenaspekt(en) in den jeweiligen Sätzen von Quellen für die Unterschiede in den Sätzen von generiertem Programmcode verantwortlich ist/sing. Zum Beispiel sei angenommen, dass eine erste Version eines Codegenerators subsequent genutzt wurde, um Programmcode für ein graphisches Modell zu generieren. Es sei weiter angenommen, dass eine zweite Version des Codegenerators verwendet wurde, um Code für das graphische Quellenmodell zu generieren, um einen zweiten Satz von generiertem Programmcode zu generieren. Ein Codedifferenzierwerk kann auf die erste Version des Programmcodes und die zweite Version des Programmcodes angewandt werden, um Unterschiede zwischen dem generierten Programmcode zu identifizieren. Ein bestimmter der Unterschiede kann identifiziert werden, als von einem bestimmten Unterschied in den Versionen des Codegenerators herzurühren. Die Assoziation zwischen den Unterschieden in den Codegeneratoren und der Unterschied in dem generierten Programmcode kann in beispielhaften Ausführungsformen identifiziert und visualisiert werden. Es ist daher insbesondere möglich, schnell und effizient Unterschiede in Code zu identifizieren, welche durch die Verwendung unterschiedlicher Codegeneratoren und/oder unterschiedlicher Versionen eines Codegenerators verursacht werden. Dies stellt zum Beispiel ein signifikant verbessertes Simulationsergebnis bereit, da unerwünschte Verhaltens- und/oder Konfigurationseffekte, die durch die Verwendung der Codegeneratoren hervorgerufen werden, rasch und effizient identifiziert werden können, und unterschieden werden können von tatsächlichen Ergebnissen der Simulation. Weiter ist es auch möglich, eine verbesserte Mensch-Maschine-Interaktion bereitzustellen, zum Beispiel während dem Debuggen des generierten Codes und/oder während dem Debuggen und/oder dem Entwurf von Codegeneratoren.
Andere Unterschiede im Code, wie etwa Verbesserungen im generierten Programmcode und Codeänderungen, die gemacht wurden, um Bugs oder Regressionen (beispielsweise Verschlechterungen in der Performanz des Programmcodes, die von Änderungen resultieren) zu beheben, können identifiziert und zurück mit den Änderungen in atomaren Quellenaspekt(en) assoziiert werden, die die Verbesserungen, Bugs oder Regressionen verursacht haben. Weiterhin ist es, indem die Assoziationen zum Beispiel zwischen Verbesserungen im generierten Programmcode und Änderungen in atomaren Quellenaspekten des Codegenerators identifiziert und bereitgestellt werden, möglich, die Effizienz und Performanz des Codegenerators signifikant zu verbessern.
Das Identifizieren der Assoziationen zwischen Quellenaspekten und den resultierenden Merkmalen in dem generierten Programmcode oder Artefakten kann auf dem Speichern von Informationen in Konstrukten, wie etwa Datenstrukturen, während des Codegenerationsprozesses basieren. In einigen beispielhaften Ausführungsformen kann ein Codegenerator Effekte von Quellenaspekten in Datenstrukturen kennzeichnen, wenn der generierte Programmcode generiert wird. In beispielhaften Ausführungsformen, in welchen die Quellen ein Modell beinhalten, von welchem der generierte Programmcode generiert wird, können einige beispielhafte Ausführungsformen intermediäre Repräsentationen verwenden, die bei der Codegeneration verwendet werden. Die gespeicherte Information (wie oben erwähnt) kann zusammen mit derartigen intermediäre Repräsentationen gespeichert werden, um die atomaren Quellenaspekte zu identifizieren und die Assoziationen der Quellenaspekte zu den resultierenden Effekten in dem generierten Code zu ermöglichen. In alternativen beispielhaften Ausführungsformen kann andere Information gespeichert werden, wie eine Identifikation der Assoziation oder Änderungsinformation, welche anzeigt, wenn ein Aspekt einer Quelle sich geändert hat. Insbesondere verbessert das Speichern der Information die Mensch-Maschine-Interaktion weiter, indem es ein effizientes späteres Abrufen der Information wenn benötigt ermöglicht.
Beispielhafte Ausführungsformen können auch Empfehlungen bereitstellen, wie die Quellen zu modifizieren sind, wie etwa die Quellenaspekte, um einen assoziierten Effekt in dem generierten Programmcode zu bewirken. Die Empfehlungen können über eine Benutzerschnittstelle oder einen anderen Mechanismus angezeigt werden. Jede Empfehlung kann einen Mechanismus beinhalten, der aktiviert werden kann, um die Empfehlung zu implementieren. Beispielhafte Ausführungsformen können weiter für jede angezeigte Empfehlung eine verursachte Änderung in dem generierten Programmcode anzeigen, die in Verbindung mit dem assoziierten Effekt steht, durch Implementieren der jeweiligen angezeigten Empfehlung. Mit anderen Worten können beispielhafte Ausführungsformen weiter für jede angezeigte Empfehlung anzeigen, wie der generierte Programmcode geändert würde, um den assoziierten Effekt in dem generierten Programmcode zu bewirken. Beispielhafte Ausführungsformen können weiter für jede angezeigte Empfehlung eine verursachte Änderung in dem generierten Programmcode anzeigen, die nicht mit dem assoziierten Effekt in Verbindung steht, durch Implementieren der jeweiligen angezeigten Empfehlung. Mit anderen Worten können beispielhafte Ausführungsformen weiter für jede angezeigte Empfehlung potentielle Änderungen als Seiteneffekt an dem generierten Code anzeigen, die verursacht werden durch Implementieren der jeweiligen Empfehlung. Die Empfehlung kann beispielsweise getriggert werden, indem der Benutzer den generierten Programmcode modifiziert. Insbesondere wird, indem die Empfehlungen auf eine derartige Weise präsentiert werden, die Mensch-Maschine-Interaktion während beispielsweise dem Modifizieren von generiertem Code und/oder Modifizieren von Quellen signifikant vereinfacht und verbessert.
1A zeigt eine Darstellung 100 einer Anzahl von Komponenten, die in einer beispielhaften Ausführungsform bereitgestellt sein können. Wie in 1A gezeigt, kann eine Anzahl von unterschiedliche Typen von Quellen 102 als Eingaben in einen Codegenerator 104 fungieren, um generierten Programmcode 106 zu erzeugen. Wie in 1B gezeigt, können die Quellen 102 ein Modell 122 beinhalten, wie zum Beispiel etwa ein textuelles Modell oder ein graphisches Modell. Die Quellen können auch den Codegenerator 104 beinhalten. Algorithmen in dem Codegenerator 104 und Änderungen, die an dem Codegenerator 104 vorgenommen werden, können Auswirkungen auf den generierten Programmcode haben. Die Quellen können auch Konfigurationseinstellungen 126 beinhalten. Wie in größerem Detail nachstehend beschreiben, können Werte einer Anzahl von atomaren Konfigurationseinstellungen, welche sich auf das Modell 122 und die Codegeneration beziehen, Auswirkungen auf den generierten Programmcode 106 haben. Die Quellen 102 können auch Optimierungen 128 beinhalten, welche von dem Codegenerator 104 ausgeführt werden. Der Codegenerator 104 kann die Option bereitstellen, den generierten Programmcode 106 auf verschiedene Weisen zu optimieren. Der generierte Code kann zum Beispiel optimiert werden, um den Speicherbedarf zu minimieren oder um auf einem Prozessor mit begrenzter Rechenleistung schneller ausgeführt zu werden. Diese Liste von Quellen 102 ist nicht als abschließend gedacht, sondern ist allein als illustrativ gedacht.
Wie oben erwähnt kann der Codegenerator 104 als eine Quelle 102 fungieren, die einen Effekt auf den generierten Programmcode 106 hat. 1C zeigt ein Beispiel einiger illustrativer Aspekte des Codegenerators 104, welche Auswirkungen auf den generierten Programmcode 106 haben können. Auf den Codegenerator 104 können Bugfixes 132 angewandt werden, um Fehler zu beheben, die zuvor in dem Codegenerator 104 existiert haben. Diese Bugfixes 132 können einen resultierenden Effekt auf den generierten Programmcode 106 haben. Neue Merkmale 134, die dem Codegenerator 104 hinzugefügt werden, können ebenfalls den generierten Programmcode 106 beeinflussen. Oftmals beinhalten neue Release eines Codegenerators 104 solche neuen Merkmale 134. Andere Aspekte 136 des Codegenerators 104 können den generierten Programmcode 106 beeinflussen, wie etwa die Auswahl von Codegenerierungsalgorithmen und dergleichen.

Wie oben erwähnt, können Werte der Konfigurationseinstellungen 126 den generierten Programmcode 106 beeinflussen. Diese Konfigurationseinstellungen können atomar oder nichtatomar sein. 1D zeigt eine illustrative Liste beispielhafter Kategorien von Konfigurationseinstellungen 126, welche den generierten Programmcode 106 beeinflussen können. Unter diesen Kategorien von Konfigurationseinstellungen 126 kann eine Speicherklassenspezifikation 142 sein. Jede Speicherklasse kann Merkmale einer Variablen und/oder Funktion spezifizieren. Die Merkmale können zum Beispiel den Scope bzw. Gültigkeitsbereich, Sichtbarkeit, Lebensdauer, Datentyp und Speicherabschnitt beinhalten. Beispielsweise spezifiziert eine „ConstVolatile“ Speicherklasse einen Speicherabschnitt für Datenelemente, indem die Typqualifikatoren „const“ und „volatile“ hinzugefügt werden vor Datendeklarationen:

Deklaration: exportiert über Datei:
INSTANZEN_SPEZIFISCHEN_HEADER
	/* ConstVolatile Speicherabschnitt */
	/* CSC Deklarationskommentar standardmäßig erzeugt */ extern const volatile DATENTYP DATENNAME[DIMENSION],
Definition:
	/* ConstVolatile Speicherabschnitt */
	/* CSC Deklarationskommentar standardmäßig erzeugt */ const volatile DATENTYP DATENNAME[DIMENSION] [= {...}];

Als ein weiteres Beispiel teilt eine „BitField“ Speicherklasse dem Codegenerator mit, einen Typ struct mit Bitfeldinformation zu generieren, so dass der Compiler speichereffizienten Code generieren kann.

typedef struct

INSTANZEN SPEZIFISCHER STRUKTURNAME bezeichner {

unsigned int x : 2;

unsigned int y : 2;

unsigned int z : 2;

} INSTANZEN_SPEZIFISCHER_STRUKTURNAME_typ;

Die folgende Tabelle zeigt weitere beispielhafte Speicherklassen.

Speicherklassenname	Beschreibung
ExportedGlobal	Generiere eine globale Variablendefinition und -deklaration. Der Name der Variable ist der Name des Datenelements.
ImportedExtern	Generiere Code, der eine globale Variable, die von Deinem externen Code definiert ist, ausliest und in diese schreibt.
ImportedExternPointer	Generiere Code, der eine globale Zeigervariable, die von Deinem externen Code definiert ist, ausliest und in diese schreibt. Verwende diese Speicherklasse, wenn externer Code ein Datenelement definiert und einen Zeiger bereitstellt, um auf diese Daten zuzugreifen.
CompilerFlag	Unterstützt Präprozessorkonditionale, die über Compilerflag oder -option definiert sind.
Const	Generiere eine globale Variablendefinition und -deklaration mit dem Typqualifikator const.
ConstVolatile	Generiere eine globale Variablendefinition und -deklaration mit den Typqualifikatoren const und volatile .
Define	Generiere ein Makro (#define Direktive) wie etwa #define myParam 5.
ExportToFile	Generiere eine globale Variablendefinition und -deklaration. Es können die Namen der Dateien, welche die Variable definieren und deklarieren, spezifiziert werden.
FileScope	Generiere eine globale Variablendefinition und -deklaration mit dem Typqualifikator static. In dem generierten Code ist der Scope bzw. Gültigkeitsbereich der Variablen auf die aktuelle Datei beschränkt.
GetSet	Generiere Code, welcher mit Daten interagiert, indem er deine benutzerdefinierten Zugriffsfunktionen aufruft. Externer Code definiert die Daten und stellt die Funktionsdefinitionen bereit.
ImportedDefine	Generiere Code, welcher ein Makro (#define Direktive) verwendet, welches in einer Headerdatei in externem Code definiert ist.
ImportFromFile	Generiere Code, welcher eine globale Variable ausliest und in diese schreibt, die von Deinem externen Code definiert ist. Ähnlich wie ExportToFile, aber der generierte Code definiert die Variable nicht.
Reusable	Generiere effizienteren Code, welcher Zwischenberechnungen eines Datenpfads in einer einzelnen, wiederverwendeten globalen Variablen speichert.
Struct	Generiere eine globale Struktur, deren Name Du spezifizieren kannst.
Volatile	Generiere eine globale Variablendefinition und -deklaration mit dem volatile Typqualifikator.
Localizable	Für Signale, generiere wenn möglich Variablen, die lokal zu Funktionen sind, anstatt im globalen Speicher. Das Generieren lokaler Variablen hindert den Codegenerator daran, Optimierungen zu implementieren, welche die Variablen aus dem generierten Code entfernen.

Die Konfigurationseinstellungen 126 können auch die Spezifikation von Namensgebungsregeln 144 für Identifikatoren in dem generierten Programmcode 106 beinhalten. Die Namensgebungsregeln 144 spezifizieren die Konventionen, die auf Namen von Identifikatoren, die in dem generierten Programmcode 106 auftreten, angewandt werden. Die Konfigurationseinstellungen 126 können Einstellungen beinhalten, die sich auf Löser und Parameter der Löser 146 beziehen, welche den generierten Programmcode 106 beeinflussen können. Die Konfigurationseinstellungen 124 können Datenimport-/-export Einstellungen 148 beinhalten, welche den generierten Programmcode 106 beeinflussen. Derartige Einstellungen zum Datenimport-/-export können spezifizieren, ob Daten importiert werden, von wo Daten importiert werden, ob Daten exportiert werden und wohin Daten exportiert werden. Die Konfigurationseinstellungen 126 können Einstellungen beinhalten, die sich auf Hardwaredetails 150 beziehen. Derartige Hardwaredetails können Einzelheiten der Zielvorrichtung definieren, in welcher der generierte Programmcode 106 ausgeführt werden soll. Die Konfigurationseinstellungen 126 können Einstellungen beinhalten, die sich auf Codierstil 152 beziehen. Die Codierstileinstellungen 152 können die Syntax und/oder Struktur des generierten Programmcodes beeinflussen. Beispielsweise können cast Konfigurationseinstellungen ausgewählt werden, um zu bestimmen, ob in dem generierten Programmcode 106 alle Typen für Identifikatoren explizit gemacht werden, implizit gemacht werden, oder ob nur einige der Typen explizit gemacht werden. Die atomaren Konfigurationseinstellungen 126 können Einstellungen 154 beinhalten, die sich auf die Codegenerierung beziehen. Die Codegenerierungseinstellungen 154 können beispielsweise die Programmiersprache spezifizieren, in welcher der generierte Programmcode generiert wird.
1E zeigt, dass die Quellenaspekte 102 in eine Kategorie von verhaltensbetreffenden Quellen 103 und nicht-verhaltensbetreffenden Quellen 105 kategorisiert werden können, wie oben beschrieben. In der Darstellung in 1E können einige Quellenaspekten des Modells 160 und des Codegenerators 162 als verhaltensbetreffende Quellen 103 gruppiert werden. Auch können sich in den verhaltensbetreffenden Quellen 103 Optimierungen 164 befinden. Die Quellen können auch Quellenaspekte beinhalten, die als nicht-verhaltensbetreffend 105 kategorisiert werden können. In dem in 1E gezeigten Beispiel kann ein bzw. können nicht-verhaltensbetreffende(r) Quellenaspekt(en) verschiedene Konfigurationseinstellungen 166, Aspekte des Codegenerators 168 und Aspekte des Modells 170 beinhalten.
Es sei verstanden, dass die in 1E gezeigte Kategorisierung nicht als beschränkend gedacht ist, sondern vielmehr als lediglich veranschaulichend gedacht ist. Es kann zum Beispiel andere Aspekte von Optimierungen geben, die nicht-verhaltensbetreffende Effekte haben, und es kann Aspekte der Konfigurationseinstellungen 150 geben, die verhaltensbetreffende Effekte haben.
Mit Bezug zurück auf 1A können die beispielhaften Ausführungsformen Programmierfunktionalität aufweisen, um die Analyse 108 auszuführen. Wie oben erwähnt, kann die Analyse eine statische Analyse 110 oder eine dynamische Analyse 112 sein. Beispiele einer statischen Analyse 110 beinhalten die Identifikation von Kompilationsfehlern, die Identifikation von Logikfehlern, die Identifikation von Bugs und die Identifikation von Codierstandardverletzungen. Es kann daher eine statische Analyse der Codestruktur und eine statische Analyse des Laufzeitverhaltens geben. Beispiele der dynamischen Analyse 112 beinhalten Codeprofiling und Codeabdeckungsanalyse.
Die Ergebnisse der Anwendung der Analyse 108 sind Artefakte 114. Beispielsweise kann das Anwenden der Codierstandardverletzungsanalyse eine Liste von Codierstandardverletzungen erzeugen. Jede dieser Verletzungen kann ein Artefakt konstituieren. Eine Codierverletzung kann sich beispielsweise auf einen verbotenen Operator beziehen, der in generiertem Programmcode verwendet wird. Die beispielhaften Ausführungsformen stellen die Fähigkeit bereit, derartige Artefakte zu identifizieren und mit Quellenaspekten zu assoziieren. Dies ermöglicht es, die Ursache der Artefakte genau zu lokalisieren. Daher kann die Ursache der Artefakte modifiziert werden, so dass das Artefakt nicht länger existiert, wodurch beispielsweise eine Mensch-Maschine-Interaktion verbessert wird.
Wie in 1A gezeigt, können beispielhafte Ausführungsformen ein Codedifferenzierwerk 116 beinhalten. Das Codedifferenzierwerk 116 kann Unterschiede 118 in Sätzen von generiertem Programmcode 106 identifizieren. In beispielhaften Ausführungsformen können diese Codedifferenzen 118 identifiziert werden, und die Ursachen (das heißt die Quellenaspekte) in den Quellen 102 der Codedifferenzen 118 können identifiziert werden, um die Quellenaspekte mit jeweiligen Codedifferenzen 118 zu assoziieren. Die Assoziation kann auf einer Anzeige visualisiert werden, indem visuelle Hinweise der Assoziationen gegeben werden. Beispiele von Codedifferenzen 118, die nützlich zu kennen und nützlich mit den Aspekten der Quellen 102 zu assoziierten sein mögen können beispielsweise Codedifferenzen beinhalten, die resultieren aus unterschiedlichen Versionen von Modulen oder unterschiedlichen Versionen des Codegenerators 104 in den Quellen 102, Codeverbesserungen, Codefehlern, Code Bugs oder Coderegressionen.
Indem die Codedifferenzen identifiziert und die Assoziationen zwischen Aspekten der Quellen und korrespondierenden Komponenten in dem generierten Programmcode, die von den geänderten Quellen generiert wurden, identifiziert werden, können die beispielhaften Ausführungsformen das Identifizieren von Ursachen der Codedifferenzen in dem generierten Programmcode für die ursprünglichen Quellen und die modifizierten Quellen ermöglichen. Die Identifikation der Ursachen kann wiederum die Behebung etwaiger Fehler oder verschlechterter Performanz ermöglichen.
Es sei verstanden, dass es nicht allein eine Ursache für Codedifferenzen oder die Artefakte der Analyse geben mag. Stattdessen mögen mehrere Ursachen vorliegen, und diese Ursachen können voneinander abhängig sein, so dass die mehreren Ursachen zusammen in der Codedifferenz oder dem Artefakt der Analyse resultieren. Wie in größerem Detail nachstehend beschrieben, verfügen die beispielhaften Ausführungsformen über die Fähigkeit, die Ursachen (beispielsweise atomare Quellenaspekt(en)) aufzuzeichnen und die Interdependenz der Ursachen zu bestimmen. Weiter verfügen die beispielhaften Ausführungsformen über die Fähigkeit, diese Ursachen zu visualisieren.
2A stellt ein Flussdiagramm 200 von Schritten bereit, die in einer beispielhaften Ausführungsform ausgeführt werden. Dieses Flussdiagramm 200 wird in Verbindung mit dem Diagramm 220 von Komponenten, das in 2B gezeigt ist, beschrieben. Zunächst kann in Schritt 202 das Generieren von Code aus Quellen 222 beginnen. Wie oben erwähnt, können die Quellen 222 zum Beispiel ein Modell, einen Codegenerator, Konfigurationseinstellungen für die Codegeneration und Auswahlen von Optimierungen beinhalten. In Schritt 204 wird Quellenaspektinformation in intermediären Repräsentationen 228 und/oder Datenstrukturen 230, wie etwa Einträge, Tabellen oder andere Typen von Datenstrukturen gespeichert.
In Schritt 206 der 2A wird der Codegenerationsprozess abgeschlossen, was in dem generierten Programmcode 226 resultiert. Nachdem der Codegenerationsprozess abgeschlossen ist (Schritt 206), wird die gespeicherte Information verarbeitet, um Assoziationen zu identifizieren (Schritt 208). Die Assoziationen sind zwischen Quellenaspekten und den Komponenten von Merkmalen in dem generierten Programmcode 226, welche von den Quellenaspekten der Quellen 222 beeinflusst werden. Die Verarbeitung kann On Demand ausgeführt werden, wenn eine Anforderung gemacht wird, derartige Assoziationen zu identifizieren. In alternativen Ausführungsformen können einige oder alle der Assoziationen verarbeitet werden, bevor eine Anforderung gestellt wird, und die Assoziationsinformation gespeichert werden, zur Verwendung wenn benötigt.
Ein visueller Hinweis der Assoziationen kann auf einer Anzeigevorrichtung angezeigt werden in Schritt 210 von 2A. Die Form der visuellen Hinweise kann variieren. Einige Beispiele sind unten beschrieben. Die Anzeige der visuellen Hinweise kann durch Aktionen getriggert werden, wie etwa der Auswahl eines Teils des generierten Programmcodes, Schweben über generiertem Programmcode oder ähnliches.
2C zeigt ein Beispiel der Information, die in einer beispielhaften Ausführungsform für ein Modellelement und eine Variable, die mit dem Modellelement assoziiert ist, die in dem generierten Programmcode enthalten ist, gespeichert werden kann. In diesem Fall ist die Information in einem Baumdiagramm 240 enthalten. Das in Rede stehende Modellelement ist ein Inport (beispielsweise ein Eingangsport), der als „Inport1“ bezeichnet ist.
Das Baumdiagramm 240 in 2C zeichnet Information auf, die mit Entscheidungen in Beziehung steht, die während dem Codegenerationsprozess gemacht wurden. Das Baumdiagramm zeichnet insbesondere für die in 2C gezeigten Beispiele Information auf, die an unterschiedlichen Entscheidungspunkten während des Codegenerationsprozesses getroffen werden, um den Namen einer Blockausgangssignalvariablen in dem generierten Programmcode von dem Inport zu bestimmen. Der in 2 gezeigte Teilbaum 240 beginnt an dem Entscheidungspunkt, um den Namen der Ausgangssignalvariablen für den Modellblock Inport1 zu bestimmen. Für das Modellelement wird ein Knoten 242 gespeichert und erzeugt. Am nächsten Entscheidungspunkt überprüft der Codegenerator, ob ein Signalname spezifiziert ist für das Ausgangssignal wie beim Knoten 244 angegeben. In einem ersten Fall ist der Signalname als „In1“ spezifiziert, wie beim Zweig 245 in 2C angegeben. Der spezifizierte Signalname „In1“ wird als die Basis für den Variablennamen verwendet. In einem anderen Fall ist der Signalname nicht spezifiziert, wie beim Zweig 243 zu sehen.
Der Codegenerator prüft dann beim nächsten Entscheidungspunkt (reflektiert im Knoten 246), ob für das In1 Signal eine Speicherklasse spezifiziert ist. Wenn die Speicherklasse als „Exportiert Global“ spezifiziert ist, wie in dem linken Zweig 247 gezeigt, bestimmt der Codegenerator dann, dass die Variable eine alleinstehende globale Variable sein soll. Als solches verwendet das System die Namensgebungsregeln, die im Knoten 248 spezifiziert sind, was in dem finale Variablennamen resultiert, der im Knoten 250 reflektiert ist.
Wenn beim Entscheidungspunkt, der mit dem Schritt 246 assoziiert ist, bestimmt wird, dass die Speicherklasse „Default“ ist, wie durch den Zweig 249 angezeigt, bestimmt der Codegenerator, dass die Variable ein Feld einer globalen Variable eines Strukturtyps sein sollte, und für die Namensgebungsregel für derartige Felder globaler Variablen gilt, wie durch den Knoten 252 angezeigt. Dies resultiert in dem Variablen-Finalstrukturfeldnamen „In1“ innerhalb einer globalen Variablen vom Strukturtyp.
Diese aufgezeichnete Information kann während und nach den Codegenerationen verarbeitet werden. Der Codegenerator kann bestimmen, welche Quellenaspekte für welche Komponente(n) des generierten Programmcodes verantwortlich sind. Für das Beispiel, das mit der 2C assoziiert ist, kann der gespeicherte Baum an Information verwendet werden, um folgendes zu bestimmen:

1. Die Speicherklasse ist „Exportiert Global“ für das Eingangssignal und daher wird es als alleinstehend global generiert.
2. Der Variablenname wird durch die Namensgebungsregel für alleinstehende globale Variablen bestimmt:
1. a. Der „rt“ Teil kommt von den Zeichenliteralen in der Namensgebungsregel „rt$R_$N$M.“
2. b. Der „Modell“ Teil in dem Variablenname ist wegen dem „$R“, der in der Namensgebungsregel spezifiziert ist.
3. c. Es existiert ein Signalname „In1“ und bildet den letzten Teil des Variablennamens, weil „$N“ in der Namensgebungsregel spezifiziert ist.

Mit derartiger Information kann der Codegenerator bestimmen, welche Quellenaspekte mit den Komponenten eines Merkmals des generierten Programmcodes assoziiert ist, und auch Empfehlungen darüber geben, welche Änderungen gemacht werden können, um die gewünschten Effekte zu erzielen, wenn ein Benutzer den Variablennamen in dem generierten Code modifiziert.
Es sei verstanden, dass die Darstellung in 2C nur für einen sehr kleinen Teil des zugrundeliegenden Modells ist. Information kann für das gesamte Modell gespeichert werden während der Codegeneration. Weiter kann Information, wie etwa die Konfigurationseinstellungen und dergleichen, gespeichert werden, um die Konfigurationseffekte zu identifizieren, welche Auswahlen in den Quellen auf den generierten Programmcode haben. Information bezüglich Optimierungen und Aspekt des Codegenerators können ebenfalls in einer derartigen Weise gespeichert werden.
Die beispielhaften Ausführungsformen identifizieren und visualisieren Assoziationen von der bzw. den Komponente(n) des generierten Programmcodes zu den Quellenaspekten. 2D zeigt ein Flussdiagramm 260, welches ein Beispiel von Schritten zeigt, die ausgeführt werden können, um die „reversen“ bzw. „umgekehrten“ Operationen des Identifizierens von Komponente(n) eines Merkmals in dem generierten Programmcode und den Quellenaspekten zu verwirklichen. In Schritt 262 wird eine bzw. werden Komponente(n) eines Merkmals in dem generierten Programmcode, die von Interesse ist bzw. sind, identifiziert. Dies kann von einem Benutzer oder einer anderen Partei verwirklicht werden, der bzw. die den Cursor so positioniert, dass er über der bzw. den Komponente(n) schwebt, durch Auswahl der Komponente(n) mittels einer Eingabevorrichtung oder mittels anderer Mechanismen. Auf die gespeicherte Information, wie etwa die in 2C gezeigt, wird dann in Schritt 264 zugegriffen. Auf die Information wird zugegriffen, um den bzw. die Quellenaspekt(en) zu identifizieren, der bzw. die mit der bzw. den identifiziert Komponente(n) des Merkmals assoziiert ist bzw. sind (Schritt 266). Wenn man beispielsweise daran interessiert ist, zu wissen, wo der Code 250, der in 2C gezeigt ist, ursprünglich herkommt aus den Quellen, kann der Prozess den Baum, der in 2C gezeigt ist, durchlaufen, beginnend an den Blattebenen, um zu bemerken, dass der Code von der Auswahl der Speicherklasse, den Namensgebungsregeln und daher, dass das Modell den Signalnamen sowie das Modellelement des Inports spezifiziert, herrührt.
Basierend darauf, dass in Schritt 266 der bzw. die Quellenaspekt(en) identifiziert wird bzw. werden, können in Schritt 268 Assoziationen identifiziert werden. Diese Assoziationen können sich in den visuellen Hinweisen wiederspiegeln, die angezeigt werden können, wie in Schritt 210 von 2A erwähnt.
2E zeigt ein Flussdiagramm 270 des Vorwärtsprozesses, der ausgeführt werden kann, um Quellenaspekt(e) zu identifizieren und mit Komponente(n) in dem generierten Programmcode zu assoziieren, in beispielhaften Ausführungsformen. Dieser Prozess ist weitgehend eine Umkehrung des Rückwärtsprozesses von 2D. Insbesondere beginnt der Prozess mit Schritt 272 in welchem ein oder mehrere Quellenaspekte identifiziert werden, wie das Modellelement 242, der Signalname In1 245, die Speicherklasse exportiert global 246 und die Namensgebungsregel 248 (2C). Dies kann beinhalten, dass sein Benutzer verschiedene Quellenaspekte auswählt oder über diesen schwebt, die auf einer Benutzerschnittstelle angezeigt werden. In Schritt 274 wird auf die gespeicherte Information zugegriffen, wie diejenige, die in 2C gezeigt ist. Basierend auf der gespeicherten Information wird eine bzw. werden Komponente(n) in dem generierten Programmcode in Schritt 276 identifiziert, wie der Variablenname bei der Deklaration 302 (3A). Assoziationen zwischen dem bzw. den Quellenaspekt(en) und der bzw. den identifizierten Komponente(n) werden in Schritt 278 identifiziert. Beim Identifizieren einer bzw. von Komponente(n) kann das System die Information in 2C nutzen, um den Baum entlang von dem bzw. den identifizierten Quellenaspekt(en) nach unten zu schreiten, bis das angemessene Blatt erreicht wird, das den betreffenden Code widerspiegelt. Diese Assoziationen können visualisiert werden, indem visuelle Hinweise der Assoziationen angezeigt werden, wie oben diskutiert.
Die Benutzerschnittstellenkomponenten zum Anzeigen der Assoziationen können unterschiedliche Formen annehmen. 3A zeigt ein Beispiel, das der Information entspricht, die in 2C gespeichert ist. Wie zu sehen ist, beinhaltet der generierte Programmcode eine Codezeile 79, welche den Typ von In1 302 definiert. Ein Benutzerschnittstellenelement 304, wie etwa eine Popup Tooltip, kann in Antwort auf ein Ereignis angezeigt werden, wie etwa wenn der Benutzer zum Beispiel die Zeile 79 anwählt oder über der Zeile 79 schwebt. Das Popup 304 kann einen Definitionsabschnitt 306 beinhalten, welcher identifiziert, wo die Variable definiert wird in dem zugrundeliegenden Code für das Modell (das heißt, einer der Quellenaspekte). Der Popup 304 kann auch einen Modellelementabschnitt 308 beinhalten, welcher die Modellelemente 310 (für den Inport1) und 312 (für das Signal, das vom Inport1 ausgegeben wird) identifiziert. Diese Elemente 310 und 312 sind weitere Quellenaspekte, die mit der Zeile 79 in dem generierten Programmcode assoziiert sind. Das Popup 304 beinhaltet einen Anpassungsabschnitt 314. Der Anpassungsabschnitt 314 identifiziert im Feld 318, wie das Signal In1 angepasst wurde durch Deklarieren von In1 als von der Speicherklasse Exportiert Global zu sein, anstatt von einer Default Speicherklasse. Dieser Abschnitt 318 identifiziert diesen zusätzlichen assoziierten Quellenaspekt.
3B zeigt ein anderes Beispiel einer Menge von Benutzerschnittstellenkomponenten, um Assoziationen zu veranschaulichen, wie die oben diskutierten. In dem in 3B gezeigten Beispiel zeigt ein Fenster 332 ein Modell in einer Simulationsumgebung an. Das Modell beinhaltet den Inport 340. Der Inport 340 gibt das Signal In1 341 aus. Ein Modelldateneditierfenster 336 zeigt eine Spezifikation an, dass der Signalname von der Speicherklasse Exportiert Global ist (siehe 344). Dieses Modelldateneditierfenster 336 kann verwendet werden, um diese Speicherklasse des Signals In1 festzulegen oder zu editieren. Es ist ein drittes Fenster 334 gezeigt, das den generierten Programmcode anzeigt. Der generierte Programmcode beinhaltet hervorgehobene Codezeilen 342. Die hervorgehobenen Codezeilen 342 sind die Komponenten, die mit den hervorgehobenen Quellenaspekten in den Fenstern 332 und 336 assoziiert sind. Wie im Fenster 332 gesehen werden kann, sind der Inport 340 sowie der Signalname 341 In1 hervorgehoben. Weiterhin ist die Zeile 344 in Fenster 336 hervorgehoben, um einen visuellen Hinweis des atomaren Quellenaspekts zu geben, dass In1 der Speicherklasse Exportiert Global zugeordnet ist. Insbesondere ist es durch Hervorheben von einer oder von mehreren Komponenten oder Merkmalen eines Teils von generiertem Programmcode, die mit einem spezifischen Quellenaspekt assoziiert sind, wie etwa einem Aspekt eines Modells oder Codegenerators, in Antwort auf das Hervorheben oder Auswählen (zum Beispiel durch einen Benutzer) des spezifischen Quellenaspekts, und/oder durch Hervorheben von einem oder von mehreren Quellenaspekten, die mit einer spezifischen Komponente oder Merkmal eines Teils von generiertem Programmcode assoziiert sind, in Antwort auf Hervorheben oder Auswählen (zum Beispiel durch einen Benutzer) der spezifischen Komponente oder des spezifischen Merkmals eines Teils von generiertem Programmcode, möglich, sowohl die Präsentation des einen oder der mehreren Quellenaspekte und dem generierten Programmcode beizubehalten, und weiter einen visuellen Hinweis der Assoziation zwischen jeweiligen Komponenten oder Merkmalen eines Teils von generiertem Programmcode und jeweiligen Quellenaspekten zu präsentieren. Daher werden diese zwei in Widerspruch stehenden Anforderungen gelöst.
Wie oben erwähnt kann eine Analyse auf dem generierten Programmcode ausgeführt werden, um verschiedene Artefakte der Analyse, die von Interesse sind, zu identifizieren. Wie oben ebenfalls erwähnt können die beispielhaften Ausführungsformen die Artefakte identifizieren und diese mit den Quellenaspekten assoziieren, welche die Artefakte verursacht haben.
4A zeigt ein Flussdiagramm 400 der Schritte, die mit Bezug auf eine solche Analyse ausgeführt werden können. Zunächst wird in Schritt 402 eine Analyse des generierten Programmcodes ausgeführt. Diese Analyse kann viele unterschiedliche Formen annehmen, wie etwa die Identifikation von Kompilationsfehlern, Codierstandardverstößen, Logikfehlern oder Bugs. Die Analyse kann von Programmen, Bibliotheken oder anderen Werkzeugen ausgeführt werden, welche die gewünschten analytischen Funktionalitäten aufweisen. Basierend auf der Analyse werden Artefakte identifiziert (Schritt 404). Insbesondere kann diese Analyse Ergebnisse liefern, welche die identifizierten Artefakte sein können. Es wird eine Bestimmung gemacht, welche Quellenaspekte zu den Artefakten beigetragen haben (Schritte 406). Basierend auf der gespeicherten Information, die oben mit Bezug auf 2C diskutiert ist, kennt das System die Assoziation zwischen Komponenten des generierten Programmcodes und Quellenaspekten. Das System kennt die Assoziation zwischen den Artefakten und den Komponenten des generierten Programmcodes. Daher kann das System die Assoziationen zwischen Quellenaspekten und den Artefakten bestimmen. Die resultierenden Assoziationen, die auf der Bestimmung basieren, werden zwischen den Quellenaspekten und den Artefakten hergestellt (Schritt 408). Wenn dazu aufgefordert oder basierend auf ausgewählten Befehlen, kann der visuelle Hinweis deren Assoziationen auf der Benutzerschnittstelle (Schritt 410) angezeigt werden. Insbesondere ist es daher möglich, die Mensch-Maschine-Interaktion signifikant zu verbessern, wenn es zum Beispiel gewünscht wird, gewünschte Änderungen in einem generierten Programmcode zu bewirken.
Die Arten der Analyse können variieren. 4B zeigt ein Beispiel von einigen der Arten von Analyse, die auf den generierten Programmcode angewandt werden können, und die in Artefakten resultieren können. In der Darstellung in 4B hat das Analysediagramm 420 die Analyse 422 an der Wurzel. Unter der Wurzel 422 befinden sich zwei Varianten von Analyse: statische Analyse 424 und dynamische Analyse 426. Beispiele statischer Analyse 424 beinhalten strukturelle Analyse 430 zum Analysieren der Struktur des generierten Programmcodes und Analysieren des Laufzeitverhaltens 432 des generierten Programmcodes. Ein Beispiel der Strukturanalyse 430 ist eine Codierstandardanalyse 440 zum Bestimmen, ob der generierte Programmcode mit Codierstandards konform ist, wie etwa Misra C. Eine andere Art von struktureller Analyse 430 ist eine Analyse 442, welche Logikfehler in dem generierten Programmcodes identifizier, oder welche Bugs identifiziert, die in dem generierten Programmcode vorhanden sind. Ein Beispiel einer solchen Analyse ist die Analyse, welche von Programmen wie etwa Debuggern und Logikanalysewerkzeugen ausgeführt werden. Eine weitere Art von Analyse des Laufzeitverhaltens 432, die angewandt werden kann, ist diejenige, die von einem Code Prover bzw. Codebeweiser 444 ausgeführt wird. Der Codebeweiser 444 kann Logikfehler und Bugs identifizieren, mag aber auch identifizieren, ob ein Teil des generierten Programmcodes beweisbar korrekt ist.
Die Analyse 422 kann auch eine dynamische Analyse 426 sein. Beispiele einer dynamischen Analyse 426 beinhalten die Analyse, die von einem Codeprofiler 436 ausgeführt wird. Der Codeprofiler profiliert die Performanz des generierten Programmcodes, wenn dieser ausgeführt wird. Der Codeprofiler 436 kann Information wie etwa Speichernutzung, CPU Nutzung und dergleichen bereitstellen. Eine andere Art dynamischer Analyse 426 ist eine Codeabdeckungsanalyse 438. Es können verschiedene Programme und Werkzeuge angewandt werden, um zu bestimmen, ob e seine vollständige Codeabdeckung gibt oder nicht. Dabei kann die dynamische Analyse 426 unterschiedliche Typen der Abdeckung analysieren. Die dynamische Analyse 426 kann zum Beispiel die Entscheidungsabdeckung, Bedingungsabdeckung, Bedingungs-/Entscheidungsabdeckung, modifizierte Bedingungs-/Entscheidungsabdeckung, Ausdrucksabdeckung, etc. analysieren.
Diese Analysewerkzeuge können, wie oben erwähnt, Artefakte generieren. Die Typen von Artefakten hängen von der Natur des Werkzeugs ab. Ein Codierstandardanalysewerkzeug 440 zum Beispiel kann eine Identifikation dahingehend erzeugen, welche Komponenten in dem generierten Programmcode nicht mit dem Codierstandard übereinstimmen, der angewandt wird. Im Gegensatz dazu kann ein Logikfehler und Bugs Analysewerkzeug 442 Artefakte in der Form einer Identifikation erzeugen, wo es Logikfehler in dem generierten Programmcode gibt und wo es Bugs in diesem generierten Programmcode gibt. Zum Beispiel kann ein Codebeweiser Werkzeug 444 eine Division-durch-null Operation identifizieren, wohingegen andere Arten von Werkzeugen eine solche Operation nicht identifizieren mögen. Ein Codeprofiler 436 erzeugt Artefakte wie etwa wie viel Speicher eine Funktion in dem generierten Programmcode verwendet und wieviel CPU Zeit eine Funktion in dem generierten Programmcode verwendet, wenn sie ausgeführt wird.
5A zeigt ein Beispiel einer Benutzerschnittstelle, wo ein visueller Hinweis bereitgestellt wird, um die Assoziation von Quellenaspekten mit einem Artefakt zu identifizieren. In dem in 5A gezeigten Fall wird ein Codebeweiser auf den generierten Programmcode, der im Fenster 536 gezeigt ist, angezeigt. Wie durch den Tooltip 542 gesehen werden kann, erkennt der Codebeweiser, dass die Multiplikationsoperation des Codes in der Zeile 364 potentiell zu einem Überlauf führen kann, und generiert den Tooltip 542. Diese Multiplikationsoperation ist aus dem Produktblock 538 (siehe Modell 532) generiert, der zwei Eingangssignale aufweist, wovon eines die Ausgabe von einer Look-Up Tabelle ist, und eines von einem Inport ausgegeben wird. The Tooltip 542 zeigt an, dass es Optionen gibt, um das Artefakt zu beheben. Man kann das Artefakt beheben, indem die Signalattribute von „Sättigung bei Integer Überlauf“ des Produktblocks gewählt werden, oder man kann Begrenzungen der Eingangssignale spezifizieren. Dieses Spezifizieren von Begrenzungen kann erzielt werden, indem „Tabellendaten“ Attribute des Look-Up Tabellenblocks geändert werden und das Signalattribut so spezifiziert wird, einen „Maximum“ Wert auf dem Inport Block zu haben.
5A zeigt auch eine Darstellung des Modells 532, wobei der Multiplikationsblock 538 hervorgehoben ist, um einen atomaren Quellenaspekt anzuzeigen, der das Artefakt produziert. In 5A ist auch ein Fenster 534 für den Codebeweiser gezeigt, das den Fehler in der Zeile 540 als einen Überlauffehler identifiziert.
5B zeigt ein Beispiel 550, in welchem der Codebeweiser angewandt wird, um einen Codierstandardverstoß in dem generierten Programmcode zu identifizieren. Wie in 5B gezeigt, enthält das Codebeweiser Fenster 552 einen hervorgehoben Eintrag 554, der identifiziert, dass es dort einen Codierstandardfehler gibt. Es wird ein Fenster 555 angezeigt, das Details 556 des Codierstandardverstoßes zeigt. Das Fenster 557 wird angezeigt und enthält ein Listing des generierten Programmcodes mit dem Tooltip 558. The Tooltip 558 bemerkt, dass es mehrere Quellenaspekte gibt, die mit diesem Codierstandardverstoß assoziiert sind. The Tooltip 558 identifiziert das Subsystem des Modells, von welchem der Fehler herrührt („Werk“) und spezifiziert die angebrachten Konfigurationsparameter, die in dem Codierstandardverstoß resultieren. Siehe ‚Löser‘: ode5 (Dormand-Prince) und Klammerebene: Minimum (sich auf C/C++ Operatorpräzedenz verlassen). Indem die Konfigurationsparameter spezifiziert werden, kann man die Parameter ändern, um den Codierstandardverstoß zu beheben. Der Hyperlink 559 kann ausgewählt werden, um ein Benutzerschnittstellenelement zum Vornehmen der Änderung bezüglich der Klammerebene aufrufen. In diesem Fall zum Beispiel wird ein Ändern der Klammerebene von minimal zu maximal den Codierstandardverstoß beheben.
Wie oben erwähnt können die beispielhaften Ausführungsformen Codedifferenzierung ausführen und eine Visualisierung von Assoziationen zwischen Codedifferenzen und den Ursachen (Quellenaspekte) der Codedifferenzen bereitstellen. Dies kann auf unterschiedliche Versions von generiertem Programmcode angewandt werden. 6A stellt ein Flussdiagramm 600 der Schritte bereit, die mit Bezug auf Codedifferenzen ausgeführt werden. Zunächst werden in Schritt 602 Codedifferenzen identifiziert. Dies kann durch das Codedifferenzierwerk ausgeführt werden, welches den fraglichen generierten Programmcode vergleicht und etwaige Unterschiede identifiziert. In Schritt 604 wird die Ursache der Codedifferenzen identifiziert. Die Codedifferenzen werden angezeigt und deren Ursachen können angezeigt werden in Schritt 606. Das System kann daher die Codedifferenzen identifizieren, und was in den Quellen die Codedifferenzen verursacht hat.
6B zeigt ein Beispiel einer Benutzerschnittstelle, das hilft, die Identifikationsvisualisierung von Assoziationen, die in Beziehung zur Codedifferenzierung stehen, und Artefakte zu illustrieren. In dem Diagramm 620 von 6B zeigt ein erstes Fenster 622 ein Modell. Es ist auch ein Fenster 624 gezeigt, das Speicherklasseninformation identifiziert. Ein drittes Fenster 630 zeigt generierten Programmcode. In dem in 6B dargestellten Beispiel ist der Inport 631, der in Fenster 622 gezeigt ist, welches das Modell darstellt, mit dem illustrativen Teil des generierten Programmcodes assoziiert, der in Fenster 630 gezeigt ist, wie durch den gerichteten Pfeil 623 angezeigt. Insbesondere enthält der hervorgehobene Abschnitt 634 die Zeile 78, die mit dem Inport 631 assoziiert sein kann. Das Popup Fenster 637 identifiziert, dass diese Zeile 78 in dem generierten Programmcode mit dem Inport 631 assoziiert ist, wie durch den Eintrag 640 belegt. Das Popup Fenster 637 bemerkt auch, dass der Signalwert, der von dem Inport 631 ausgegeben wird, sich von einer Default Speicherklasse zu einer importiert extern Speicherklasse geändert hat, wie durch den Eintrag 638 angegeben. Das Fenster 624 zeigt, dass die Inports als importiert extern Speicherklasse spezifiziert wurden, wie durch den hervorgehobenen Eintrag 626 angegeben. Die Assoziation zwischen dem Element 626 und dem Eintrag 638 in dem Popup Fenster 637 wird durch den gerichteten Pfeil 636 erfasst. Diese Assoziation erfasst die Ursache für die Änderung in dem generierten Programmcode. Diese Änderungen können durch ein Codedifferenzierwerk produziert und hervorgehoben werden, wie in dem Codelisting des generierten Programmcodes angezeigt.
6B zeigt auch ein Beispiel eines Artefakts, das mit der Codeänderung assoziiert ist. In diesem Beispiel hat die Änderung der Speicherklasse in einem Kompilationsfehler resultiert, wie durch den Eintrag 652 in Fenster 650 angezeigt. Der Kompilationsfehler ist eine undefinierte Referenz zu rtln1. Diese Assoziation wird durch den gerichteten Pfeil 654 in 6B erfasst. Die Assoziation zwischen dem, was den Kompilationsfehler verursacht hat, und dem, was die Codeänderung verursacht hat, kann daher in einer derartigen Benutzerschnittstelle für eine beispielhafte Ausführungsform repräsentiert werden.
7 zeigt ein Beispiel gewisser illustrativer Codedifferenzen, die von dem Codedifferenzierwerk identifiziert werden können, die von Interesse sein mögen. Wie in dem Diagramm 700 gezeigt, kann die Codedifferenz 702 Codeverbesserungen 704 beinhalten. Man kann daran Interesse haben, zu wissen, warum der Code verbessert ist und welche atomaren Quellenaspekte die Verbesserung in dem generierten Programmcode bewirken. Das Codedifferenzierwerk 702 kann in Verbindung mit anderen Werkzeugen (wie etwa Debuggern) auch Bugs und/oder Regressionen identifizieren, die zwischen Versionen von generiertem Programmcode gefunden werden. Andere Arten von Unterschieden können ebenso identifiziert werden al sein Ergebnis der Codedifferenzierung 708. Codedifferenzen sind nicht auf Codeverbesserungen 704 oder Codefehler und Regressionen 706 beschränkt. Insbesondere durch Bestimmen von Assoziationen zwischen Merkmalen oder Teilen von generiertem Programmcode und Quellenaspekten, welche zu den Merkmalen oder Teilen von generiertem Programmcode beitragen, erlauben es Ausführungsformen der vorliegenden Offenbarung daher, effizient zu bestimmen, warum ein Merkmal oder Teil von generiertem Programmcode sich geändert hat, zum Beispiel verbessert ist, und welche® Quellenaspekt(e) diese Änderung in dem generierten Programmcode verursacht haben. Dadurch wird zum Beispiel eine Mensch-Maschine-Interaktion signifikant verbessert.
Wie oben diskutiert können Konfigurationseinstellungen den Programmcode, der generiert wird, beeinflussen. 8A zeigt ein Beispiel des Typs von atomaren Konfigurationseinstellungen, welcher generierten Programmcode beeinflussen kann. Insbesondere beinhaltet, wie in 8A gezeigt, die Benutzerschnittstelle 800 eine Option 804 im linken Fensterbereich 802, welche, wenn sie ausgewählt wird, in der Anzeige von Einstellungen, die sich auf die Auswahl des Lösers beziehen, resultiert. Wie im rechten Fensterbereich 806 gesehen werden kann, kann ein Benutzer Simulationszeitparameter 808 spezifizieren. Der Benutzer kann auch einen Typ von Löser 812 und einen bestimmten Löser 814 spezifizieren in der Löserauswahl des Abschnitts 810. Die Auswahl des Lösertyps und eines bestimmten Lösers kann den Programmcode, der generiert wird, beeinflussen. In dem in 8A gezeigten Beispiel wird der Typ von Löser 812 als ein Löser mit fester Schrittweite ausgewählt. Der bestimmte Löser wird durch den Eintrag 814 als ein diskreter Löser ohne kontinuierliche Zustände spezifiziert. Andere Löserkonfigurationswerte 816 können angezeigt und spezifiziert werden mittels dem rechten Fensterbereich 806. 8A zeigt ein Beispiel, in welchem bestimmte erweiterte Parameter 818 ausgewählt oder abgewählt werden können.
8B zeigt eine Benutzerschnittstelle 800, in welcher Datenimport/-export Parameterwerte eingestellt werden. Der Benutzer hat den Eintrag 820 im linken Fensterbereich 802 so ausgewählt, um den rechten Fensterbereich 807 anzuzeigen. Der rechte Fensterbereich 807 stellt im Abschnitt 822 verschiedene Optionen zum Laden von Eingaben oder eines initialen Zustands von einem Arbeitsbereich bereit. MATLAB, zum Beispiel, beinhaltet einen Arbeitsbereich zum Halten von Variablen mit Werten, wie etwa Arbeitswerten, die während der Ausführung von MATLAB Code und/oder Simulink Modellen geändert werden können. Der rechte Fensterbereich 807 beinhaltet auch einen Abschnitt 824, um verschiedene Parameter zu spezifizieren, die sich auf das Speichern von Werten in dem Arbeitsbereich oder in einer Datei beziehen. Das Spezifizieren dieser Parameter kann den Programmcode modifizieren, der aus dem Modell generiert wird.
8C zeigt ein Beispiel eines Fensters 800, in welchem ein Benutzer eine Hardwareimplementierungsoption 826 aus dem linken Fensterbereich 802 ausgewählt hat. Die Hardwareimplementierung bezieht sich auf die Hardwareimplementierung, für welche der Code generiert wird. Man kann dann ein Hardwareboard 828, einen Vorrichtungshersteller 830 und einen Vorrichtungstyp 832 spezifizieren. Es können auch verschiedene andere Parameter 834 spezifizieren, die sich auf die Hardwareimplementierung beziehen. Zum Beispiel können die Bitgrößen für Datentypen spezifiziert werden, wie etwa char, short und long. In 8C ist die Bitgröße für char als 8 Bit spezifiziert, für short als 16 Bit und für long als 32 Bit.
Die Konfigurationseinstellungen können sich auch auf Namensgebungsregeln beziehen, wie etwa in 8D gezeigt. 8D zeigt zwei Versionen eines Fensters 800 und 801, in welchem ein Benutzer eine Symboloption 836 im linken Fensterbereich 802 auswählt. Wie in 8D gesehen werden kann, enthält der rechte Fensterbereich 811 eine Anzahl von unterschiedlichen Namensgebungsregeln für Dinge wie etwa globale Variablen und globale Typen. Das Fenster 801 beinhaltet ein Popup 838, welches einen Teil der Syntax der Namensgebungsregeln erläutert. Das Popup identifiziert, welche Makros angewandt werden können, um spezifische Teile des Identifikatornamens für eine globale Variable abzuleiten. Insbesondere bezieht sich $M auf das Makro mangle, $R bezieht sich auf das Wurzelmodellnamensmakro, $G bezieht sich auf das Speicherklassennamensmakro, $N bezieht sich auf das Marko des Namens des Objekts, das identifiziert wird, und $V bezieht sich auf das Benutzertokentext-Makro. Die Makronamen spiegeln ihre Funktionalität wieder. Beispielsweise erhält $G, das Speicherklassenmakro, Zeichen, welche die Speicherklasse der Variablen wiederspiegeln. Die Auswahl der Namensgebungsregeln kann den Programmcode beeinflussen, der von dem Modell generiert wird.
Eine andere Konfigurationseinstellung, welche den Programmcode beeinflussen kann, der von dem Modell generiert wird, ist eine Codierstileinstellung. In dem in 8E gezeigten Beispiel hat der Benutzer die „Codierstil“ Option 840 aus dem linken Fensterbereich 802 ausgewählt, um die Codierstilparameter zu etablieren, die in dem rechten Fensterbereich 842 aufgelistet sind. Der Benutzer kann dann eine Anzahl von unterschiedlichen Optionen auswählen unter Verwendung von Checkboxen und Ausklapplisten, welche den Programmcode beeinflussen können, der von dem Modell generiert wird. Zum Beispiel kann die Klammerebene gesetzt werden, wie etwa die nominelle Ebenenoption, die in 8E gezeigt ist. Parameter, wie etwa umwandeln von if-then-else Pattern in switch case Ausdrücke, oder das Beibehalten von static Schlüsselwörtern in Funktionsdeklarationen können gesetzt werden. Was die Codeeinrückung betrifft, kann ein Einrückstil gesetzt und eine Einrückgröße ausgewählt werden.
Wie oben diskutiert können bestimmte Einstellungen für die Codegenerierung ausgewählt werden, die den Programmcode beeinflussen, der aus dem Modell generiert wird. Wie in 9A gezeigt, zeigt das Fenster 900 eine Codegenerationsoption 902 an, die ausgewählt werden kann, um den rechten Fensterbereich 904 anzuzeigen. Unter den Werten, die eingestellt werden können, ist ein Name einer Systemzieldatei 906 und die Programmiersprache 908, in welcher der Code generiert werden soll. Die Systemzieldatei ist eine Datei, die verwendet wird, um ein Modell in generierten Programmcode umzusetzen. Die Systemzieldatei beschreibt, wie Code für ein gegebenes Ziel bzw. Target zu generieren ist. Der rechte Fensterbereich 904 zeigt auch eine Anzahl von Optionen an, die den Bau- bzw. Buildprozess 910 betreffen, wie etwa ob lediglich Code generiert werden soll (beispielsweise ob weiter fortgefahren und der generierte Code kompiliert werden soll oder nicht) und/oder den Code und Artefakte zu packen.
Wie oben diskutiert kann die Auswahl von Optimierungen für die Codegenerierung den Programmcode beeinflussen, der generiert wird.
9B zeigt ein Beispiel, in welchem eine Optimierungsoption 910 so ausgewählt ist, dass der rechte Fensterbereich 911 eine Anzahl von Optimierungsgradeinstellungen 912 anzeigt. In dem in 9B gezeigten Beispiel spezifiziert eine Ausklappliste 914 den Optimierungsgrad. Diese Ebene kann minimal, maximal oder ein Zwischenwert sein. In dem in 9B gezeigten Beispiel ist der Optimierungsgrad auf maximal eingestellt, was dazu führt, dass die Ausklappliste 916 die drei Optionen von Ausbalancieren von RAM und Geschwindigkeit, Maximieren der Ausführungsgeschwindigkeit oder minimieren von RAM enthält. Abhängig davon, welche Option ausgewählt wird, kann eine Anzahl von Auswahlboxen unter dem Detailabschnitt 913 verfügbar sein. Zum Beispiel werden Optionen angezeigt, um lokale Blockausgaben zu aktivieren, lokale Blockausgaben wiederzuverwenden, Ausdrucksfaltung zu verwenden, globale Blockausgaben wiederzuverwenden, Feldindizierung zu vereinfachen, Puffer unterschiedlicher Größen und Dimensionen wiederzuverwenden, etc. Weiterhin werden Optionen dazu angezeigt, wie globaler Datenzugriff optimiert werden soll und/oder wie Blockausführungsreihenfolge in dem generierten Code optimiert werden soll. Die Auswahl der Option „Ausgleich zwischen RAM und Geschwindigkeit“ als Priorität (siehe 916) stellt die Werte für viele dieser anderen Parameter ein. Man kann sehen, dass nach dieser Wahl viele der Auswahlboxen gesetzt oder nicht gesetzt sind. Weiterhin werden Werte für „Globalen Datenzugriff optimieren“ auf „Verwende global, um Zwischenergebnisse zu speichern“ und für „Optimiere Blockausführungsreihenfolge in dem generierten Code“ auf „Verbesserte Codeausführungsgeschwindigkeit“ gesetzt werden.
9C das Erscheinungsbild des rechten Fensterbereichs 911, wenn die maximale Ebene 914 ausgewählt und die Priorität auf Maximieren der Ausführungsgeschwindigkeit 920 ausgewählt wird. Es ist dabei zu bemerken, dass einige der Auswahlen der Auswahlboxen und Listenboxen geändert sind im Vergleich zu 9B. Insbesondere ist in 9C die Box „Vereinfache Feldindizierung“ gesetzt und die Liste „ Globalen Datenzugriff optimieren“ hat „Ohne“ ausgewählt. Dies zeigt die Wirkung, die eine nichtatomare Auswahl auf die Einstellungen für atomare Quellen hat.
9D zeigt ein Beispiel, in welchem die maximale Ebene 914 ausgewählt wird und die Priorität Minimiere RAM 922 ausgewählt wird. Als ein Ergebnis werden die Auswahlboxen „Packe Boolsche Daten in Bitfelder“ und „Verwende Puffer unterschiedlicher Größen und Dimensionen“ ausgewählt. Weiterhin ist in der Listenbox „Optimiere Blockoperationsreihenfolge in dem generierten Code“ die ausgewählte Option „Aus“. Dies ist ein Beispiel davon, wie zwei nichtatomare Quellenaspekte (das heißt, maximiere Optimierungsgrad und minimiere RAM als eine Priorität) die Auswahl von atomaren Quellenaspekten (das heißt, die aufgeführten Auswahlboxen und Listenboxen) beeinflussen. Diese Benutzerschnittstellendarstellungen in den 8 und 9 sind nicht als Beschränkung gedacht, sondern sind vielmehr illustrierend gedacht. Es sei verstanden, dass eine Anzahl von unterschiedlichen Benutzerschnittstellen verwendet werden kann, um die atomaren Konfigurationseinstellungen auszuwählen. Die atomaren Konfigurationseinstellungen können mehr oder weniger enthalten als die dargestellten.
Die beispielhaften Ausführungsformen sind eingerichtet, Interdependenzen zwischen Quellenaspekten und den resultierenden Merkmalen in dem generierten Programmcode zu bestimmen. Die beispielhaften Ausführungsformen können die Beziehungen zwischen Quellenaspekten erfassen und beurteilen, wie die Quellenaspekte den generierten Programmcode beeinflussen. Diese Erfassung dieser Beziehungen ermöglicht das Bestimmen der Assoziationen zwischen Komponenten von Merkmalen in dem generierten Programmcode und Quellenaspekten. Die erfassten Assoziationen ermöglichen eine reverse Codegeneration, wo Code geändert werden kann und das System Änderungen an Quellenaspekten ableitet, um die gewünschten Codeänderungen zu erreichen.
Es können mehrere Beziehungen, die sich auf die Quellenaspekte beziehen, erfasst und gespeichert werden in einer Weise wie derjenigen, die mit Bezug auf 2C beschrieben wurde. Ein erstes Beispiel einer solchen Beziehung ist eine logische und Beziehung, in welcher mehrere Quellenaspekte notwendig sind, um einen spezifischen Codeeffekt zu erreichen. Wie zum Beispiel in 10A gezeigt ist eine Optimierungseinstellung 1006, welche eine Bezeichner-basierte Pufferwiederverwendung erlaubt, zusammen damit, dass mehrere Signalleitungen denselben Bezeichner aufweisen, ein Beispiel von Quellenaspekten, die eine logische und Beziehung aufweisen. 10A zeigt ein Fenster 1000, in welchem mit der Codegenerierung in Beziehung stehende Konfigurationseinstellungen gesetzt werden können. In diesem Fall wurden die „Optimierung“ Einstellungen 1002 ausgewählt. Der rechte Fensterbereich 1004 des Fensters 1000 weist eine Anzahl von Einstellungen auf, die gesetzt werden können, indem Auswahlboxen ausgewählt werden. Eine dieser Einstellungen 1006 stellt ein, dass die Signalbezeichner die Pufferwiederverwendung anleiten. In 10A ist diese Auswahl 1006 ausgewählt.
Dies ist ein Beispiel einer logischen und Beziehung, in welcher mehrere Quellenaspekte notwendig sind, um einen Effekt in dem generierten Programmcode zu produzieren. Der Effekt kann daher mit den mehreren Quellenaspekten assoziiert und durch die Pfeile in 10A angegeben werden. Oftmals wird diese Art von Beziehung zwischen einem breiten Quellenaspekt (beispielsweise einer modellweiten Einstellung) und einem engeren Quellenaspekt (beispielsweise einer lokalen Einstellung) gefunden. In diesem illustrativen Fall ist die „Verwende Signalbezeichner zur Anleitung der Pufferwiederverwendung“ Einstellung 1006 der breitere Quellenaspekt, da die Einstellung 1006 die gesamte Klasse von Signalbezeichnerinstanzen betrifft. Die mehreren Signalleitungen 1012 und 1014 (siehe Modell 1010), welche denselben Bezeichner haben, ist der engere Quellenaspekt, da sich dieser auf die bestimmten Instanzen der gleichen Bezeichner für Signalleitungen 1012 und 1014 bezieht. Die resultierende Komponente 1016 in dem generierten Programmcode ist in dem Codelisting 1008 gezeigt. Wenn ein beliebiger dieser Quellenaspekte nicht vorliegt, wie in 10B gezeigt, unterscheidet sich die Komponente 1020 darin, dass es keine Pufferwiederverwendung in dem Codelisting 1002 des generierten Programms gibt, im Gegensatz zur Komponente 1016 in 10A.
Quellenaspektvariablen können auch eine logische oder Beziehung aufweisen, wobei mehrere Quellenaspekten unabhängig voneinander einen Effekt auf den generierten Programmcode haben. Wie zum Beispiel in größerem Detail nachstehend mit Bezug auf 11B beschrieben kann ein Signalname in dem generierten Programmcode von einer Änderung des Signalnamens in dem Modell oder einer Änderung in der Speicherklasse, die für das Signal spezifiziert wird, resultieren.
Ein weiteres Beispiel einer Beziehung ist eine überschreibende bzw. überstimmende Beziehung, in welcher ein Konfigurationseinstellungswert einen anderen überschreibt, aber beide Einstellungen zu einem Effekt in dem generierten Programmcode beitragen.
10C zeigt eine überschreibende bzw. überstimmende Beziehung zwischen Quellenaspekten. Insbesondere überschreibt eine Einstellung einer Speicherklasse auf „ExportierelnDatei“ bzw. „ExportToFile“ für In1 in Ziele 1046 des Modelldateneditors 1042 die Default Speicherklasse für die Gruppe von Inports, die durch die Einstellung 1044 im Fenster 1040 angegeben sind.
10D zeigt ein Beispiel 1060, in welchem alle Inports die Default Speicherklasse haben. 10E zeigt den Fall, wo die Speicherklasse für In1 geändert wurde zu „ExportierelnDatei“ bzw. „ExportToFile“ 1062, während die Speicherklasse für die anderen Inports spezifiziert ist (siehe 1064), bei der Default Speicherklasse zu bleiben.
Ein weiteres Beispiel einer Beziehung zwischen Konfigurationseinstellungswerten, das von verschiedenen beispielhaften Ausführungsformen erfasst wird, ist eine Kombinationsbeziehung. In einer solchen Kombinationsbeziehung resultieren mehrere Konfigurationseinstellungswerte in Kombination in einem Effekt in dem generierten Programmcode. Ein beispielhafter Fall ist der einer Namensgebungsregel (siehe 838 in 8D), wo mehrere Teile einer Namensgebungsregel von unterschiedlichen Quellenaspektwerten (wie etwa Wurzel-Modellname, Speicherklassenname, etc.) stammen können. Zum Beispiel, wie in 838 gezeigt, haben die globalen Variablen eine Namensgebungsregel „rt$N$M“. Diese Regel zeigt an, dass das „rt“ ein führender Teil des Variablennamens wird, gefolgt von dem Namen des Objekts, welcher wiederum gefolgt wird von dem Makro Mangle, wie in 8D gezeigt.
Schließlich können die beispielhaften Ausführungsformen eine Kompositbeziehung zwischen Konfigurationseinstellungswerten erfassen. Eine solche Kompositbeziehung entsteht dadurch, dass rekursive irgendwelche der anderen Typen von Beziehungen, wie die oben beschrieben, angewandt werden.
Die beispielhaften Ausführungsformen können Empfehlungen erzeugen, wenn ein Benutzer eine Modifikation an einer bestimmten Zeile des generierten Programmcodes ausführt. 11A stellt ein Flussdiagramm 1100 der Schritte bereit, die bezüglich solcher Empfehlungen ausgeführt werden können. Zunächst wird in Schritt 1102 eine Änderung an dem generierten Programmcode vorgenommen. Das System bemerkt, dass die Änderung mit einer Änderung assoziiert ist (Schritt 1104). In diesem Beispiel ist das Subsystem ein Simulink Subsystem.-Es wird in Antwort auf die Änderung eine Empfehlung angezeigt (Schritt 1106). Zum Beispiel kann das System so konfiguriert sein, dass Änderungen an Variablennamen oder andre Änderungen assoziierte Empfehlungen erzeugen. Die Empfehlung erläutert, wie atomare Quellenaspekte so modifiziert werden können, dass der generierte Programmcode die Änderungen aufweist, ohne dass es einer manuellen Editierung der Änderung bedarf. Wenn es mehrere Empfehlungen gibt, können die Empfehlungen in einer priorisierten Reihenfolge angezeigt werden, basierend auf einem vorbestimmten Priorisierungssystem, oder können ohne eine priorisierte Reihenfolge angezeigt werden. Die Priorität kann auf Information wie etwa früherem Verhalten, einer empfangenen Präferenz (wie etwa von einem Benutzer), einer Regel oder einer anderen Basis basieren. In einigen Ausführungsformen kann der Benutzer die Option haben, die Empfehlung anzunehmen oder nicht. Daher wird in Schritt 1108 eine Bestimmung gemacht, ob die Empfehlung angenommen wird (das heißt, der bzw. die atomare(n) Quellenaspekt(en), die in der Empfehlung identifiziert sind, werden automatisch modifiziert). Wenn die Empfehlung nicht angenommen wird, werden die identifizierten atomaren Quellenaspekte nicht modifiziert. Wenn die Empfehlung jedoch angenommen wird, werden die empfohlenen Änderungen an den atomaren Quellenaspekten ausgeführt in Schritt 1110 und der generierte Programmcode kann (automatisch) erneut generiert werden, um die Änderungen in den Quellenaspekten andernorts in dem Modell zu berücksichtigen.
Die Empfehlungen können aus der gespeicherten Information bestimmt werden, wie etwa mit Bezug auf 2C diskutiert. Da die Entscheidungspunkte des Codegenerationsprozesses und die zugeordnete Information gespeichert werden kann, kann die gespeicherte Information verwendet werden, um zu identifizieren, wie die gewünschte Änderung zu erreichen ist. Man kann zum Beispiel die Effekte des Modifizierens einer Speicherklasse aus der gespeicherten Dateninformation bestimmen, und wenn einer der Effekte die gewünschte Änderung ist, kann eine geeignete Empfehlung generiert werden.
Das System erfasst und speichert die geeignete Information zum Erfassen der Interdependenzen und zum Generieren von Empfehlungen. Das System kann zum Beispiel Information bezüglich der oben genannten logischen und Beziehungen erfassen und speichern. Diese Information und die Information des effektiven Gültigkeitsbereichs kann verwendet werden, um Empfehlungen darüber zu geben, welche Quellenaspekte geändert werden müssen, um das gewünschte Merkmal in dem generierten Programmcode zu erhalten. Es wird daher eine verbesserte Mensch-Maschine-Interaktion bereitgestellt. Wenn zum Beispiel ein Benutzer die Pufferwiederverwendung für einen einzelnen Puffer deaktiviert, kann die Empfehlung sein, die Signale mit unterschiedlichen Bezeichnern neu zu benennen im Hinblick auf die logische und Beziehung.
Bei einer logischen oder Beziehung weiß das System, dass alle Quellen geändert werden müssen, um in der bzw. den assoziierten Komponente(n) in dem generierten Programmcode zu resultieren.
Im Fall einer überschreibenden bzw. überstimmenden Beziehung unter Quellenaspekten erfasst und speichert das System auf ähnliche Weise alle Quellenaspekte und die überschreibende bzw. überstimmende Beziehung. Wenn daher eine Default Speicherklasse überschrieben wird, wird die Information der Default Speicherklasse weiterhin erfasst, zusammen mit der überschreibenden Information. Wenn daher die überschreibende Einstellung entfernt wird, kann die Default Speicherklasse wiederhergestellt werden.
11B zeigt ein Beispiel 1120, welches in Tabellenform Änderungsempfehlungen 1122 anzeigt, die Ergebnisse des Akzeptierens der Änderungsempfehlung 1124 in derselben Zeile und die Nebenwirkungen 1125 des Akzeptierens der Empfehlungen. In einigen Ausführungsformen kann das Verfahren umfassen Anzeigen, auf einer Anzeigevorrichtung, von Information bezüglich dazu, wie eine oder mehrere Quellen und/oder Quellenaspekte modifiziert werden können, um eine Modifikation oder gewünschte Änderung von generiertem Programmcode mittels Codegeneration durch einen Codegenerator zu bewirken, Information bezüglich der Modifikation oder gewünschten Änderung an dem generierten Programmcode, wenn die eine oder die mehreren Quellen und/oder Quellenaspekte modifiziert werden, und Information bezüglich dazu, ob eine oder mehrere zusätzliche Änderungen und/oder Nebenwirkungen an dem generierten Programmcode verursacht werden, wenn die eine oder die mehreren Quellen und/oder Quellenaspekte modifiziert werden. Die angezeigte Information bezüglich dazu, wie eine oder mehrere Quellen und/oder Quellenaspekte modifiziert werden können, um eine Modifikation oder gewünschte Änderung von generiertem Programmcode durch Codegeneration durch einen Codegenerator erreicht werden kann, kann weiter mehrere Wege spezifizieren, wie die eine oder die mehreren Quellen und/oder Quellenaspekte modifiziert werden können, um die Modifikation oder gewünschte Änderung zu bewirken. In diesem Beispiel möchte ein Benutzer einen Variablenname von „ln1“ auf „rtln1“ ändern. Es gibt drei Empfehlungen, wie der Variablenname auf diese Weise zu ändern ist.
Die erste Änderungsempfehlung ist, direkt den entsprechenden Signalnamen in dem Modell zu ändern, aus welchem der generierte Programmcode generiert wird, wie durch das Element 1126 gezeigt. Die resultierende Änderung ist in dem Codelisting 1128 für den generierten Programmcode gezeigt. Es gibt keine Nebenwirkungen, wie durch das Element 1130 gezeigt.
Die zweite Änderungsempfehlung ist, die Speicherklassenbeschreibung für die Inports von „Default“ auf „ImportedExtern“ bzw. „ImportiertExtern“ bzw. „ImportedExtern“ zu ändern in dem Modell durch Modifizieren der Deklaration in der Einstellung Konfigurationseinstellungen, wie durch das Element 1132 identifiziert. Das Resultat in dem generierten Programmcode wird durch das Element 1134 gezeigt. Die Nebenwirkungen, wie im Element 1036 identifiziert, sind, dass die Namen aller Wurzel Inport Namen sich ändern, und dass e seine Änderung von struct Feldnamen zu individuellen Variablen gibt.
Die dritte Änderungsempfehlung ändert eine Identifikator Namensgebungsregel für die Namensgebungsregel für Feldnamen von globalem Typ. Die resultierenden Änderungen an dem generierten Programmcode sind in dem 1140 gezeigt. Die Nebenwirkung 1142 ist, dass sich die Namen aller Feldnamen globaler Variablen ändern.
Die Ergebnisse 1128, 1134, 1140 können generiert werden, indem eine partielle Codegeneration bezüglich Änderungen im Hintergrund vorgenommen wird. Für dieses Beispiel kann der Codegenerator die Variablendeklaration, die dessen Namen enthält, generieren, ohne die vollständige Codegeneration auszuführen. Daher kann er schnell Empfehlungen und erwartete Nebenwirkungen bereitstellen direkt nachdem der Benutzer den Variablennamen in dem Code ändert. Die Empfehlungen können für den Benutzer live oder sofort erscheinen, während der Benutzer den Variablennamen modifiziert.
11 C zeigt ein Beispiel einer Benutzerschnittstelle, die Änderungsempfehlungen zeigt. Wie in 11C gezeigt, beinhaltet ein Codelisting von generiertem Programmcode 1150 eine Änderung an einem Feldnamen 1152 von In1 zu rtln. Als ein Ergebnis dieser Änderung wird ein Tooltip 1154 mit zwei Änderungsempfehlungen 1156 und 1162 angezeigt. Die erste Empfehlung 1156 ist ein Hyperlink Menüelement, das, wenn es ausgewählt wird, das Modell 1160 in einem Benutzerschnittstellenelement 1158 anzeigt, um die empfohlene Änderung in dem Modell 1160 anzuzeigen. Das zweite Menüelement 1162 ist ebenfalls ein Hyperlink Menüelement, das, wenn es ausgewählt wird, die Anzeige eines Benutzerschnittstellenelements 1164 veranlasst, welches die Namensgebungsregeln und die Modifikation an den Namensgebungsregeln identifiziert. Wenn der Benutzer wählt, die Namensgebungsregel zu ändern, (siehe 1162) kann die Namensgebungsregel Editier-Ul 1164 angezeigt werden, mit dem Fokus auf die spezifische zu modifizierende Regel 1166.
12A zeigt ein Rechensystem 1200, das geeignet ist, um beispielhafte Ausführungsformen zu verwirklichen. Das Rechensystem 1200 kann eine Rechenvorrichtung 1202 mit einem oder mit zwei Prozessoren 1204 beinhalten. Die Rechenvorrichtung 1202 hat Zugriff auf oder beinhaltet einen Speicher 1206. Der Speicher 1206 kann eine Umgebung zum technischen Rechnen (TCE) beinhalten, wie etwa die MATLAB Umgebung zum technischen Rechnen, die auch Simulink, Stateflow und andere Komponenten beinhalten kann. Der Speicher 1206 kann einen Codegenerator 1210 beinhalten und kann Programmcode 1212 beinhalten, welcher von dem Codegenerator generiert wird. Der Speicher 1206 kann ein oder mehrere graphische Modelle 1214 beinhalten. Der Speicher kann einen Compiler 1216 zum Kompilieren von Code und zum Identifizieren von Kompilationsfehlern beinhalten. Der Speicher 1206 kann auch einen Codeanalysator beinhalten, der Probleme mit dem Code identifizieren kann, wie etwa Codierstandardverstöße, Logikfehler, Codebeweisfehler, Bugs und andere Artefakte. Die Programme in dem Speicher 1206 können von dem Prozessor 1204 der Rechenvorrichtung ausgeführt werden. Der Speicher 1206 kann nichttransitorische computerlesbare Speichermedien beinhalten zum Beinhalten von von einem Computer ausführbaren Anweisungen, die von dem Prozessor 1204 der Rechenvorrichtung ausgeführt werden können, um die Funktionalität der oben diskutierten beispielhaften Ausführungsformen auszuführen. Der Speicher 1206 kann eine Anzahl von unterschiedlichen Formen annehmen, welche unterschiedliche Typen von Speichervorrichtungen beinhalten können, einschließlich, ohne hierauf beschränkt zu sein, Magnetplattenspeicher, optische Plattenspeicher, RAM, Flash Speicher, Nur-Lese Speicher (ROM), Halbleiterspeicher und/oder ähnliches.
Die Rechenvorrichtung 1202 kann Zugriff auf eine Anzeigevorrichtung 1220 zum Anzeigen von Information haben, wie etwa die Benutzerschnittstelle und Elemente, die oben diskutiert sind. Die Rechenvorrichtung 1202 kann Zugriff auf einen Netzwerkadapter 1222 haben, welcher es der Rechenvorrichtung ermöglicht, mit Netzwerken zu interagieren, einschließlich lokalen Netzwerken und Weitbereichsnetzwerken.
Es sein verstanden, dass die beispielhaften Ausführungsformen auch in einer verteilten Umgebung verwirklicht sein können. 12B zeigt ein Beispiel einer geeigneten verteilten Umgebung 1250. Die verteilte Umgebung beinhaltet einen Client 1252 und einen Server 1254, welche über ein Netzwerk 1256, wie etwa das Internet, kommunizieren können. Der Client 1252 kann einen oder mehrere Prozessoren 1258 beinhalten. Ähnlich kann der Server einen oder mehrere Prozessoren 1260 beinhalten. Der Client 1252 kann Zugriff auf einen Speicher 1262 haben, der ein graphisches Modell beinhalten kann. Der Server 1254 kann Zugriff auf einen Speicher 1266 haben. Der Speicher kann einen Codegenerator 1268 und einen Codeanalysator 1270 beinhalten, die von dem einen oder den mehreren Prozessoren 1260 auf dem Server 1254 ausgeführt werden können. In einigen Ausführungsformen kann der Client 1252 das Modell dem Server bereitstellen, welcher den Codegenerator 1268 verwendet, um Code zu generieren, welcher dann von dem Codeanalysator 1270 analysiert wird. Es sei verstanden, dass andere Client Server Konfigurationen und andere verteilte Umgebungen ebenfalls verwendet werden können, um die beispielhaften Ausführungsformen zu verwirklichen.
Während beispielhafte Ausführungsformen der vorliegenden Erfindung hierin beschrieben wurden, werden die Fachleute verstehen, dass verschiedene Änderungen in Form und Detail gemacht werden können, ohne den angedachten Bereich der vorliegenden Erfindung wie durch die beigefügten Ansprüche definiert zu verlassen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62778101 [0001]

Claims

Verfahren, das ausgeführt wird durch einen Prozessor (1258, 1260) einer Rechenvorrichtung (1202), wobei das Verfahren umfasst: Generieren von Programmcode (106, 1150, 1212) mit einem Codegenerator (104, 162, 168,1210, 1268) für ein Modell (122, 160, 170, 532, 1160) und einen oder mehrere Konfigurationswerte, die für das Modell (122, 160, 170, 532, 1160) eingestellt sind, Ausführen des Modells (122, 160, 170, 532, 1160) oder des Programmcodes (106, 1150, 1212), das bzw. der das Verhalten eines Systems der echten Welt simuliert, wobei das Generieren umfasst Aufzeichnen von Information über Verhaltenseffekte des Modells (122, 160, 170, 532, 1160) und/oder des Codegenerators (104, 162, 168,1210, 1268) und einen oder mehrere Konfigurationseffekte auf den Programmcode (106, 1150, 1212) von dem Modell (122, 160, 170, 532, 1160) und/oder dem Codegenerator (104, 162, 168,1210, 1268) und dem einen oder den mehreren Konfigurationswerten, wobei zumindest einige der Verhaltenseffekte und dem einen oder der mehreren Konfigurationseffekte voneinander abhängig sind; für einen Teil des Programmcodes (106, 1150, 1212), Bestimmen welcher von dem einen oder den mehreren Konfigurationseffekten und/oder Verhaltenseffekten zu einem Merkmal des Teils des Programmcodes (106, 1150, 1212) beigetragen hat, wobei das Bestimmen umfasst Analysieren der aufgezeichneten Information und Ableiten, von den Verhaltenseffekten und dem einen oder den mehreren Konfigurationseffekten, einer Identität von dem einen oder den mehreren Konfigurationseffekten und/oder Verhaltenseffekten, der bzw. die zu dem Merkmal des Teils des Programmcodes (106, 1150, 1212) beigetragen hat bzw. haben; und Speichern einer Assoziation zwischen dem Identifizierten von dem einen oder den mehreren Konfigurationseffekten und/oder Verhaltenseffekten, der zu dem Merkmal des Teils des Programmcodes (106, 1150, 1212) beigetragen hat.
Verfahren nach Anspruch 1, wobei das Analysieren den einen oder die mehreren Konfigurationseffekte als zu dem Merkmal beitragend identifiziert.
Verfahren nach Anspruch 2, wobei der eine oder die mehreren identifizierten Konfigurationseffekte von einem oder von mehreren der folgenden Konfigurationswerte resultiert bzw. resultieren: Wahl einer Namensgebungsregel (144) für Identifikatoren, Wahl einer Speicherklasse, Wahl eines Lösertyps, Wahl eines Lösers (146, 812, 814), Wahl von zu importierenden Daten, Wahl von zu exportierenden Daten, Zielhardwaredetails (150), Codierstilparameter, oder Wahl einer Programmiersprache (908) von generiertem Programmcode (106, 1150, 1212).
Verfahren nach einem der vorstehenden Ansprüche, wobei das Analysieren einen oder mehrere der Verhaltenseffekte als zu dem Merkmal beitragend identifiziert.
Verfahren nach Anspruch 4, wobei der eine oder die mehreren identifizierten Verhaltenseffekte das Ergebnis von zumindest einem der folgenden ist bzw. sind: eine Wahl einer Optimierung (128, 164) in der Codegenerierung, ein hinzugefügtes Merkmal des Codegenerators (104, 162, 168,1210, 1268), ein Patch, der auf den Codegenerator (104, 162, 168,1210, 1268) angewandt wurde, ein Algorithmus des Modells (122, 160, 170, 532, 1160), eine Modifikation an dem Modell (122, 160, 170, 532, 1160), um einen Fehler zu beheben, oder eine Modifikation an dem Modell (122, 160, 170, 532, 1160), um den generierten Programmcode (106, 1150, 1212) mit einem Standard kompatibel zu machen.
Verfahren nach einem der vorstehenden Ansprüche, weiter umfassend: Verwenden der gespeicherten Assoziation, um zu identifizieren, welcher von dem einen oder den mehreren Konfigurationswerten, Aspekten des Modells (122, 160, 170, 532, 1160) und/oder Aspekten des Codegenerators (104, 162, 168,1210, 1268) zu dem Merkmal des Teils des Programmcodes (106, 1150, 1212) beigetragen hat bzw. haben; und Anzeigen eines visuellen Hinweises oder einer Anzeige, der bzw. die kenntlich macht, dass der bzw. die identifizierten Konfigurationswerte, Aspekte des Modells (122, 160, 170, 532, 1160) und/oder Aspekte des Codegenerators (104, 162, 168,1210, 1268) zu dem Merkmal des Teils des Programmcodes (106, 1150, 1212) beigetragen hat bzw. haben.
Verfahren nach Anspruch 6, wobei das Anzeigen automatisch ausgelöst wird durch einen programmatischen Mechanismus.
Verfahren nach Anspruch 6, wobei das Anzeigen in Antwort auf ein Benutzerschnittstellenereignis erfolgt.
Verfahren nach einem der vorstehenden Ansprüche, wobei das Modell (122, 160, 170, 532, 1160) eines ist von einem graphischen Modell (1214) oder einem textuellen Modell.
Verfahren nach einem der vorstehenden Ansprüche, wobei der eine oder die mehreren Konfigurationswerte zumindest einen atomaren Konfigurationswert beinhaltet.
Verfahren nach einem der vorstehenden Ansprüche, wobei zumindest zwei Quellenaspekte, welche Aspekte des Modells (122, 160, 170, 532, 1160), Aspekte des Codegenerators (104, 162, 168,1210, 1268) und/oder einen oder mehrere Konfigurationswerte umfassen, zumindest eine der folgenden Beziehungen aufweisen mit Bezug auf das Verursachen des einen oder der mehreren Konfigurationseffekte und/oder Verhaltenseffekte: eine logische UND Beziehung, eine logische ODER Beziehung, eine überschreibende bzw. überstimmende Beziehung, wobei einer der zumindest zwei Quellenaspekte einen anderen der zumindest zwei Quellenaspekte überschreibt bzw. überstimmt, oder eine Kombinationsbeziehung, wobei jeder der zumindest zwei Quellenaspekte zu dem einen oder den mehreren Konfigurationseffekten oder den Verhaltenseffekten beiträgt.
Verfahren nach einem der vorstehenden Ansprüche, wobei das Merkmal eines ist von Gültigkeitsbereich bzw. Scope, Sichtbarkeit, Lebensdauer, Datentyp oder Speichersektor.
Verfahren, das ausgeführt wird von einem Prozessor (1258, 1260) einer Rechenvorrichtung (1202), wobei das Verfahren umfasst: Identifizieren, dass generierter Code modifiziert wurde, um eine Modifikation aufzuweisen, wobei der generierte Code von einem Codegenerator (104, 162, 168,1210, 1268) generiert wurde aus mehreren Quellen (102, 222), die ein Modell (122, 160, 170, 532, 1160) und zumindest einen andern Typ von Quelle (102, 222), welche die Codegeneration durch den Codegenerator (104, 162, 168,1210, 1268) beeinflusst, beinhalten; Bestimmen, wie die Quellen (102, 222) modifiziert werden können, um die Modifikation durch Codegeneration durch den Codegenerator (104, 162, 168,1210, 1268) zu bewirken; und Anzeigen von Information auf einer Anzeigevorrichtung (1220), die sich darauf bezieht, wie die Quellen (102, 222) modifiziert werden können, um die Modifikation durch Codegeneration durch den Codegenerator (104, 162, 168,1210, 1268) zu bewirken.
Verfahren nach Anspruch 13, wobei die angezeigte Information mehrere Wege spezifiziert, wie die Quellen (102, 222) modifiziert werden können, um die Modifikation zu bewirken.
Verfahren nach einem der Ansprüche 13 bis 14, weiter umfassend Erfassen von Information bezüglich Beziehungen zwischen den Quellen (102, 222) und Verwenden der Information bezüglich der Beziehungen beim Bestimmen, wie die Quellen (102, 222) modifiziert werden können.
Verfahren nach einem der Ansprüche 13 bis 15, wobei das Anzeigen von Information anzeigt, wie die Quellen (102, 222) modifiziert werden können, in einer priorisierten Reihenfolge basierend auf einem vorbestimmten Priorisierungssystem.
Verfahren nach Anspruch 16, wobei das vorbestimmte Priorisierungssystem auf zumindest einem von einem früheren Verhalten, einer empfangenen Präferenz oder einer Regel basiert.
Verfahren nach einem der Ansprüche 13 bis 17, wobei die zumindest eine andere Quelle (102, 222) zumindest eines beinhaltet von Konfigurationsinformation für den Codegenerator (104, 162, 168,1210, 1268) oder Modifikationen, die an dem Codegenerator (104, 162, 168,1210, 1268) vorgenommen wurden.
Verfahren nach einem der Ansprüche 13 bis 18, wobei das Modell (122, 160, 170, 532, 1160) ein graphisches Modell (1214) ist.
Verfahren, das ausgeführt wird von einem Prozessor (1258, 1260) einer Rechenvorrichtung (1202), wobei das Verfahren umfasst: Ausführen einer Analyse (108, 110, 112, 422, 424, 426, 442) eines Teils von generiertem Code, der generiert wurde von einem Codegenerator (104, 162, 168,1210, 1268) aus mehreren Eingangsquellen (102, 222), unterschiedlichen Typs, beinhaltend ein graphisches Modell (1214) und eine andere Eingangsquelle (102, 222) von einem Typ, der kein graphisches Modell (1214) ist, wobei die Analyse (108, 110, 112, 422, 424, 426, 442) Ergebnisse liefert; Bestimmen, welche der Eingangsquellen (102, 222) zu den Ergebnissen der Analyse (108, 110, 112, 422, 424, 426, 442) beigetragen hat bzw. haben; und Anzeigen, auf einer Anzeigevorrichtung (1220), einer Nachverfolgung der Ergebnisse der Analyse (108, 110, 112, 422, 424, 426, 442) zu den bestimmten Eingangsquellen (102, 222), welche zu den Ergebnissen beigetraben haben.
Verfahren nach Anspruch 20, wobei die Analyse (108, 110, 112, 422, 424, 426, 442) eines der folgenden identifiziert: Verstöße gegen einen Codierstandard, Kompilationsfehler, Fehler im Programmcode (106, 1150, 1212), dass ein Teil des generierten Codes von einem Codebeweiser (444) nicht bewiesen werden kann, oder Änderungen in dem generierten Code relativ zu zuvor generiertem Code, der generiert wurde aus dem graphischen Modell (1214) durch den Codegenerator (104, 162, 168,1210, 1268).
Verfahren nach einem der Ansprüche 20 bis 21, wobei die Analyse (108, 110, 112, 422, 424, 426, 442) von einem Codebeweiser (444) ausgeführt wird, der Fehler in dem Teil des generierten Codes identifiziert.
Verfahren nach einem der Ansprüche 20 bis 22, wobei die Analyse (108, 110, 112, 422, 424, 426, 442) eine statische Analyse (110, 424) ist.
Verfahren nach einem der Ansprüche 20 bis 22, wobei die Analyse (108, 110, 112, 422, 424, 426, 442) eine dynamische Analyse (112, 426) ist.
Verfahren nach einem der Ansprüche 20 bis 24, wobei die andere Eingangsquelle (102, 222) von einem Typ, der kein graphisches Modell (1214) ist, das Generieren des generierten Codes durch den Codegenerator (104, 162, 168, 1210, 1268) beeinflusst.
Nichttransitorisches computerlesbares Speichermedium, welches Anweisungen speichert, die von einem Prozessor (1258, 1260) einer Rechenvorrichtung (1202) ausführbar sind, welche den Prozessor (1258, 1260) veranlasst, ein Verfahren nach einem der Ansprüche 1 bis 25 auszuführen.