Innovator 11. Einlagern von Header- Dateien. Karl Straußberger. HowTo.

Transkript

1 Innovator 11 Einlagern von Header- Dateien Karl Straußberger HowTo

2 Inhaltsverzeichnis Vorbemerkung... 2 Theoretischer Hintergrund... 2 Arbeitsweise der Aktualisierung... 2 Untersuchung der Dateien...2 Erstellung von DD-Einträgen...3 Erstellung von Daten und Operationen...3 Import von Header-Dateien...3 Voraussetzungen... 3 Einlagerung durchführen... 4 Untersuchung ausführen...4 Einlagerung ausführen...4 Aktualisierung anpassen... 4 Elementeigenschaften...4 Elementeigenschaften für alle Elementtypen...4 Elementeigenschaften für DD-Einträge...4 Elementeigenschaften für Operationen und Daten...5 Optionen der Engineering-Aktion...5 Anpassen der Modellkonfiguration... 6 Elementeigenschaften...6 Anlegevoreinstellungen...6 Abhängigkeiten...6 Vorbemerkung Theoretischer Hintergrund Damit Sie die Erweiterung nutzen können, benötigen Sie Innovator oder neuer. Bei älteren Versionen ist der Einsatz nur begrenzt möglich (siehe Abschnitt "Voraussetzungen"). Mit der skriptbasierten Einlagerung von Header-Dateien soll die Einbindung von C-Bibliotheken erleichtert werden. Deren Daten und Operationen liegen dann als externe Definitionen vor. Außerdem lassen sich auch die Datentypen im Modell einbinden. Beim Reverse-Engineering SD arbeitet Innovator auf den Quelldateien, um alle Aufrufbeziehungen zu finden. Dies ist für den Anwendungsfall gedacht, dass vorhandener Code nun mit Innovator weiterentwickelt werden soll. Häufig findet man aber auch die Situation vor, dass in ein Projekt der C-Code einer Bibliothek eingebunden werden soll, ohne ihn direkt weiterzuentwickeln. Diese Bibliotheken sind teilweise Standardbibliotheken, aber auch durch Code-Generatoren erstellt und meist nur in Form der Header-Dateien und vorkompilierten Bibliotheksdateien vorhanden. Aufgabe dieses Skriptes ist es, die Header-Dateien von Bibliotheken zu untersuchen und deren Elemente im Modell anzulegen. Mit Hilfe dieses Skriptes werden Daten, Operationen und Typdefinitionen im Modell erstellt. Arbeitsweise der Aktualisierung Untersuchung der Dateien Die Aktualisierung ist so aufgebaut, dass sie mehrfach gestartet werden kann, ohne ein existierendes Design zu gefährden. Insbesondere werden keine Zuordnungen überschrieben oder gelöst. Die Dateien werden in mehreren Phasen untersucht. Zuerst werden alle Kommentare entfernt. Danach erfolgt die Suche nach Makros, gefolgt von der Expansion der Makros. Bei der Expansion der Makros werden unter anderem auch Bereiche zur bedingten Kompilation (#ifdef, #ifndef etc.) beachtet und die darin enthaltenen Makros nicht ausgeführt. Zusätzlich können über den Parameter defines weitere Makros definiert werden, die sich auch auf die bedingte Kompilation auswirken. 2

3 Der letzte Schritt besteht darin, den verbleibenden Code zu untersuchen und alle darin deklarierten Operationen, Daten und Typen zu ermitteln. Zur Bestimmung der exakten Deklaration wird dann erneut der originale Code herangezogen (Anmerkung: Sollte das gefundene Element erst durch die Anwendung von Makros entstanden sein, kann die Deklaration nur aus dem bereinigten Code ermittelt werden). Alle gefundenen Elemente werden im Modell angelegt (Anlegevoreinstellungen beachten) und ggf. wieder der Header-Datei oder dem erzeugten/selektierten Modul zugeordnet. Erstellung von DD-Einträgen Erstellung von Daten und Operationen Import von Header-Dateien Folgende Varianten von Typdefinitionen werden erkannt (kursive Bestandteile sind optional): typedef struct sname { definition } name; typedef union sname { definition } name; struct name { definition }; union name { definition }; typedef enum ename { wertliste } name; enum name { wertliste }; Definitionen von Funktionspointern typedef typ name; Bei den Varianten 1 und 2 wird die gesamte Definition in die Elementeigenschaft ctypedef übernommen, der Name wird zum Namen des DD-Eintrags und ist die einzige Variable in der Definition. Der Strukturname wird in die Elementeigenschaft cstructname übernommen. Bei den Varianten 3 und 4 wird ebenfalls die Definition in die Elementeigenschaft ctypedef übernommen, der Name wird für den Typedef durch Anhängen von _t gebildet. Bei Varianten 5 und 6 wird jeweils die Wertliste in die Elementeigenschaft cenum geladen. Bei Variante 5 wird der Enum-Name in die Elementeigenschaft cstructname übernommen. Bei Variante 6 wird der Name für den Typedef durch Anhängen von _t gebildet. Bei Funktionspointern wird lediglich der Name durch die entsprechende Variable ersetzt. Aus Deklarationen von Funktionen und Variablen werden externe Operationen und externe Datenbereiche erzeugt. Bei Operationen wird die formale Definition aus der Deklaration ermittelt, bei Datenbereichen wird die Variable als einziges Element verwendet. Deklarationen mit dem Schlüsselwort static erhalten in der Elementeigenschaft cstatic den Wert 1. Für Operationen wird die Elementeigenschaft cforward mit der eigentlichen Deklaration gefüllt, wobei Rückgabetyp, Name und Parameter Verwendung finden. Compilerspezifische Deklaratoren werden aus dem Rückgabetyp der Operation gefiltert und nur in cforward verwendet. Wenn Sie die Option import verwenden, werden die originalen Header-Dateien in das Modell importiert. Normalerweise wählen Sie diese Option, wenn Sie eine Bibliothek zur Weiterentwicklung in das Modell laden wollen. Voraussetzungen Damit Sie die Einlagerung nutzen können, benötigen Sie Innovator oder neuer. Die Erweiterung funktioniert nur für die Programmiersprache C. In COBOL ist ihr Einsatz nicht sinnvoll. Ab Innovator existieren für die Modellkonfiguration die Add-Ons Migration V81 C-Implementation und C-Header-Reverse (de), welche Sie über Modell>Konfiguration>Modelloptionen laden aktivieren können. 3

4 Einlagerung durchführen Untersuchung ausführen Einlagerung ausführen Zum Untersuchen der Header-Dateien selektieren Sie das bereits erstellte Bibliotheksmodul im Modellbrowser oder Moduldiagramm. Falls Sie nichts selektieren, wird ein Modul mit dem Namen der Header-Datei erstellt. So gehen Sie vor Um die Untersuchung auszuführen:» Selektieren Sie genau ein Modul oder das Modulpaket.» Wählen Sie den Menübefehl Engineering>Aktion ausführen> Header-Dateien untersuchen.» Wählen Sie die gewünschte Header-Datei aus. Die Engineering-Aktion wird gestartet und gibt einige Informationen im Fenster Auswertung aus. Verfolgen Sie diese, um etwaige Fehlermeldungen zu erkennen. Die Aktion erstellt Daten, Operationen und Typdefinitionen und ordnet sie dem selektierten Modul zu. Mit der Meldung Auswertung beendet wird die Aktion beendet. Zum Einlagern der Header-Dateien selektieren Sie das Paket, in dem die Module erstellt werden sollen. Falls Sie nichts selektieren, wird versucht, ein Paket mit dem Namen "Module" zu finden. So gehen Sie vor Um die Aktualisierung auszuführen:» Selektieren Sie genau ein Paket, in dem die Erstellung von externen Modulen möglich ist.» Wählen Sie den Menübefehl Engineering>Aktion ausführen> Header-Dateien einlagern.» Geben Sie in der Eingabezeile das Verzeichnis ein, in dem sich die Header-Dateien für die Bibliothek befinden. Die Aktion wird gestartet und gibt einige Informationen im Fenster Auswertung aus. Verfolgen Sie diese, um etwaige Fehlermeldungen zu erkennen. Die Aktion erstellt Module, Daten, Operationen und Typdefinitionen und ordnet sie dem jeweiligen Modul zu. Mit der Meldung Auswertung beendet wird die Aktion beendet. Aktualisierung anpassen Elementeigenschaften Die Engineering-Aktion verwendet einige Elementeigenschaften, deren Werte im Laufe der Aktualisierung gesetzt werden. Elementeigenschaften für alle Elementtypen Folgende Elementeigenschaft sollte auf (externen und internen) Modulen, Operationen und Daten angelegt werden. chheaderfile In dieser Elementeigenschaft wird der Name der Header-Datei (ohne Endung) abgelegt. Diese Elementeigenschaft wird bei der erweiterten Generierung von Header-Dateien wieder ausgelesen. Elementeigenschaften für DD-Einträge Folgende Elementeigenschaften sollten auf DD-Einträgen angelegt werden bzw. bereits existieren. chisexternal Data-Dictionary-Einträge existieren nicht als extern, deshalb kann über diese Elementeigenschaft diese Information gespeichert werden. Hier werden nur die Wert 0 und 1 benötigt. cstructname Diese Elementeigenschaft aus der C-Erweiterung von Innovator speichert den Namen einer Struktur, damit eine Typdefinition der Form: typedef struct name1 {... } name2; möglich ist. In der Elementeigenschaft wird der beim Einlesen gefundene Strukturname gespeichert. 4

5 Optionen der Engineering-Aktion ctypedef Bei struct und union wird diese Elementeigenschaft mit der tatsächlichen Definition gefüllt. cenum Bei Aufzählungstypen wird diese Elementeigenschaft mit der Liste der Aufzählungswerte belegt. Elementeigenschaften für Operationen und Daten Folgende Elementeigenschaften sollten auf Operationen und Daten bereits existieren. cstatic Diese Elementeigenschaft aus der C-Erweiterung von Innovator führt dazu, dass die Operation nicht in der Header-Datei deklariert wird. Außerdem wird die Vorwärtsdeklaration mit static generiert. Bei Daten wird die Vorwärtsdeklaration unterdrückt, da static-daten nicht deklariert werden können, sondern definiert werden müssen. cforward Diese Elementeigenschaft aus der C-Erweiterung von Innovator wird dazu verwendet, um die Vorwärtsdeklaration zu speichern. Dadurch werden compiler-spezifische Deklarationen aus dem Rückgabetyp der Operation herausgehalten. Die Engineering-Aktion kann mit einigen Optionen auf den jeweiligen Einsatzbereich angepasst werden. Diese Optionen sind auch in der Hilfe zum TCL-Skript sdimphdr.tcl dokumentiert. -dir <dirlist> Mit dieser Option wird die Liste der zu durchsuchenden Verzeichnisse angegeben. Es werden darin alle Header-Dateien (Endung *.h) gesucht und abgearbeitet. -ext <fileextension> Sollte die Endung der Header-Dateien nicht *.h sein, so lässt sich dies über diese Option einstellen (nur im Zusammenhang mit dir möglich). -file <filelist> Statt ganze Verzeichnisse mit der Option dir zu durchsuchen, können auch einzelne Dateien angegeben werden (vollständiger Pfad). -import Mit dieser Option werden die Dateien auch in das Modell importiert (Anlegevoreinstellungen beachten). -comnesting Für den Fall, dass Ihr Compiler verschachtelte Kommentare unterstützt, müssen Sie diese Option verwenden, da sonst der Parser im Skript die Kommentare nicht richtig behandelt. Ist die Option nicht gesetzt, so beendet das erste */ den Kommentar, unabhängig von der Anzahl der /* innerhalb des Kommentars. -defines <definelist> Bei der Anwendung der Makros auf die Dateien werden auch Bereiche mit bedingter Kompilation (#ifdef, #ifndef etc.) beachtet und die darin definierten Makros ggf. nicht angewendet. Mit dieser Option können weitere Makros definiert werden, um die bedingte Kompilation zu beeinflussen. -tokens <tokenlist> Bei der Deklaration von Funktionen werden von manchen Compilern zusätzliche Deklaratoren erwartet. Damit diese aber nicht in den Rückgabetyp der Operation eingehen, können sie als Token eingestellt werden (reguläre Ausdrücke möglich) und werden so nur in die Elementeigenschaft cforward übernommen. -default_return <type> Funktionsdeklarationen, die keinen eigenen Rückgabetyp spezifizieren, werden in C als int behandelt. Dies entspricht auch der Standardeinstellung dieser Option. Sollte Ihr Compiler von einer anderen Einstellung ausgehen, können Sie diese beim Import angeben, damit das Modell korrekt ist. -ilabel <labelname> Für alle erstellten Operationen und Datenbereiche wird der Name der originalen Header- Datei in einer Elementeigenschaft hinterlegt. Diese Elementeigenschaft wird vom sog. Header-Skript (sdcrthdr.tcl) zur Generierung der richtigen Include-Anweisung (Standard: chheaderfile) ausgewertet. -extlabel <labelname> Bei Einträgen im Data Dictionary wird nicht zwischen intern und extern unterschieden. Damit aber die Einträge, die durch den Import der Header-Datei entstanden sind, leichter erkannt werden können, wird auf all diese Einträgen eine Elementeigenschaft mit dem Wert 1 gesetzt (Standard: chisexternal). 5

6 Anpassen der Modellkonfiguration Für die Durchführung der Aktualisierung sind einige Einstellungen in der Modellkonfiguration nötig, die Ihnen im Folgenden näher erläutert werden. Sollten Sie nicht mit der Konfiguration von Innovator-Modellen vertraut sein, so können Sie hier die Lektüre dieses Dokuments beenden. Die unten beschriebenen Einstellungen sind im Add-On C-Header-Reverse (de) bereits durchgeführt. Nach dessen Laden müssen Sie die Modellstrukturvorlage Header- Reverse AddOn (de) über Modell>Konfiguration>Modellstruktur nachladen. Elementeigenschaften Anlegevoreinstellungen Alle Elementeigenschaften, die im Abschnitt Elementeigenschaften spezifiziert sind, müssen definiert sein. Teilweise sind diese bereits in der Standardkonfiguration enthalten. Für die Definition der Anlegevoreinstellungen muss ein weiterer Stereotypwert für den Elementtyp Abhängigkeit[Paket] definiert werden: «create header». Einige Anlegevoreinstellungen müssen definiert werden (Menübefehl Modell>Konfiguration>Pakete>Eigenschaften, Registerkarte Anlegevoreinstellungen): Stereotyp Einträge Element Abhängigkeit Neue Pakete «module» DD-Eintrag Alle create data dictionary data dictionary «module» Externe Daten Alle create external data data operation «module» «module» Externe Operation Alle create external operation Include- Implementierung Alle create header implementation «operation» DD-Eintrag Alle create data dictionary data dictionary Abhängigkeiten Als Konsequenz der Anlegevoreinstellungen ist eine Abhängigkeit zwischen den Paketen Funktionsmodell und Typdefinitionen mit dem Stereotyp «create header» anzulegen. Copyright 2010 MID GmbH Bei Fragen wenden Sie sich bitte an unsere Hotline Telefon: +49 (0)911 / , support@mid.de. Dieses Dokument finden Sie neben anderen auch im exklusiven Login-Download-Bereich für Innovator-Wartungskunden unter 22http:// Ihre MID MID GmbH, Eibacher Hauptstr. 141, D Nürnberg Telefon: +49 (0)911 / , Fax: +49 (0)911 / info@mid.de, Internet: Innovator_11.2_HowTo_HeaderFiles_Einlagerung_ doc 6