-
ALLGEMEINER STAND DER TECHNIK
-
Die
vorliegende Erfindung betrifft die Softwareentwurfsmodellierung
und insbesondere die Round-Trip-Software-Engineering-Technik, bei
der eine Softwareanwendung durch Reverse-Engineering in ein Softwaremodell
rückentwickelt
wird, wobei das Softwaremodell verändert werden kann und der Code,
der von dem Softwaremodell dargestellt wird, dann neu codiert werden
kann.
-
Aufgrund
einer unangemessenen Softwareentwurfsmodellierung ist es in der
Regel schwierig gewesen, Anwendungsentwicklungsprojekte mit irgendeiner
Art von stetigem Erfolg zu liefern. Ein sehr geringer Anteil bedeutender
Anwendungsentwicklungsprojekte wird pünktlich und innerhalb des Budgets
vollendet. Da der Umfang an Projekten zugenommen hat, haben Organisationen
damit begonnen, Anwendungen und entsprechende untergeordnete Systeme
in eine Vielzahl von Stufen zu partitionieren, wobei jede Stufe
unabhängig
von den anderen entwickelt und verwaltet wird. Dies befähigt Anwendungen
dazu, auf die Unternehmensebene heraufgesetzt zu werden. Da komplexere
Sprachprojekte der 3. Generation entwickelt werden, hat ein entsprechender
Bedarf an der formalen Analyse und der Entwurfsmodellierung zugenommen.
Dementsprechend müssen
zur Kombinierung verschiedener zerlegter Anwendungen in eine einzige
Großlösung vorhandene
Anwendungen visualisiert und verstanden werden, ohne auf das Graben
durch den Quellcode zurückzugreifen.
Darüber
hinaus müssen
Projekte unter Verwendung von auf Komponenten basierenden Entwicklungstechniken
neu entwickelt werden, um verschiedene entstehende Objekttechnologien wie
CORBA, Microsoft ActiveX (OCX) und das World Wide Web vorteilhaft
zu nutzen.
-
US 5,590,270 beschreibt
ein Reverse-Engineering-Verfahren zur Unterstützung von Softwarewiederverwendung.
Das in
US 5,590,270 beschriebene
Verfahren betrifft das Abbilden von Änderungen in einem Softwaremodell
auf einer hohen Ebene auf Änderungen
in einem Softwaremodell auf einer niedrigeren Ebene. Nachfolgende Änderungen
an dem Modell auf niedrigerer Ebene können zu Änderungen in dem Modell auf
der höheren
Ebene führen.
-
US 3,711,863 beschreibt
ein Verfahren zum Vergleichen von zwei Versionen eines Quellprogramms
und das Identifizieren von Unterschieden zwischen den zwei Programmen.
-
"Rational Rose/C++ – Round-Trip
engineering with Rational Rose/C++", Rational Software Corporation, beschreibt
das Generieren von C++-Code ausgehend von einem Rational-Rose-Modell. Code, der
für jede
ausgewählte
Modellkomponente generiert wird, ist eine Funktion der Spezifikation
dieser Komponente und Codegenerierungseigenschaften. Diese Eigenschaften
stellen sprachspezifische Information bereit, die zur Abbildung
des Modells in C++ erforderlich ist.
-
Platinum
Technology "Paradigm
Plus: Round-Trip Engineering for Java 1.1.x, Release 3.6 for UNIX
and Windows Workstations" beschreibt
das Mischen von Information, die aus einem objektorientierte Analyse-
und Entwurfsprogramm (OOAD) exportiert wird, mit einer vorhandenen
Anwendung in Java. Nach Vollendung der Codegenerierung verbindet
eine inkrementale Codegenerierung die neue Information in Java-Quellcodedateien.
Während
des Mischens wird nur die Information, die von dem OOAD-Programm
gesammelt wird, gemischt und die gesamte andere Information von
den Java-Quelldateien wird im „Ist-Zustand" gelassen.
-
Der
erste erforderliche Schritt betrifft das Hinzufügen einer objektorientierten
Analyse und Entwurfs zu dem vorhandenen Entwicklungsprozess. Da Softwareanforderungen
immer komplexer werden, wird eine Umgebung benötigt, um den Lebenszyklus der
dritten Generation mit einem Front-End der objektorientierten Analyse
und Entwurfs zu ergänzen, wobei der
Anwendungsschreiber dazu befähigt
wird, wieder verwendbare Komponenten vorteilhaft zu nutzen und die
Entwicklung des Projekts zu verfolgen. Viele Modellierungsprodukte
wie Platinum Technology, Inc.s Paradigm Plus sind zu diesem Zweck
entwickelt worden. Die Herausforderung in solchen Produkten besteht
in der Beibehaltung der Synchronisation der Entwurfsinformation
mit dem Code.
-
Wie
in 1 dargestellt, muss die Capability ein Softwaremodell 2 mit
sich änderndem
Quellcode 4 aktualisiert halten, wobei die Generierung
von leicht verständlichen
Diagrammdarstellungen des Softwareentwurfs ermöglicht wird. Diese Capability
ist in den meisten, wenn nicht in allen Objektmodellierungswerkzeugen
enthalten. Ohne dieses Merkmal muss ein Softwaremodell manuell aktualisiert
werden, immer wenn Veränderungen
in dem Entwurf vorgenommen werden, während der Quellcode geschrieben
wird. Dies führt
oft zu vergessenen Aktualisierungen des Softwaremodells und zu einem
Softwaremodell, das in Bezug auf den darzustellenden Quellcode veraltet
ist.
-
Wie
in dem Venn-Diagramm in 2 dargestellt, wird das Problem
durch die Tatsache verschärft,
dass das Softwaremodell im Allgemeinen nur ein untergeordnetes Set
der Information darstellt, die in dem Quellcode dargestellt ist,
wobei eine große Menge
an Metadaten, die das Projekt betreffen, das in dem Softwaremodell
gespeichert ist, nicht in dem Quellcode dargestellt ist. Zum Beispiel
werden in das Softwaremodell im Allgemeinen weder Kommentare in
dem Quellcode noch Eigenschaften von Objekten, die sich auf ihre
Formatierung beziehen, integriert. Entwurfsprinzipien und Beziehungen
zwischen Objekten in der angewendeten Modellierungsmethodologie,
die in dem Softwaremodell dargestellt sind, werden nicht explizit
in den Quellcode aufgenommen.
-
Mehrere
Werkzeuge in der Branche haben eine Round-Trip-Engineering-Technologie hinzugefügt, die
den Quellcode lesen kann und das Softwaremodell mit dem Quellcode
synchronisieren kann. Allerdings sind diese Werkzeuge darauf angewiesen, Marker
in dem Quellcode 4 anzuordnen, um Bereiche des Codes zu
definieren, die dem Softwaremodell 2 entsprechen. Diese
Marker bringen den Quellcode mit fremden Markierungen in Unordnung
und verursachen Lesbarkeitsprobleme. Außerdem ist diese Technik anfällig für Fehler,
wenn einer der Marker gelöscht
oder versehentlich von dem Entwickler editiert werden.
-
Es
ist ein Round-Trip-Engineering-Verfahren erforderlich, das ermöglicht,
dass ein Softwaremodell mit entsprechendem Quellcode oder äquivalenten Objekten
synchronisiert bleibt, ohne dass Codemarker den Code in Unordnung
bringen.
-
KURZDARSTELLUNG DER ERFINDUNG
-
Die
vorliegende Erfindung stellt ein System zum Synchronisierthalten
eines Softwaremodells, das eine Softwareanwendung darstellt, mit
dem sie darstellenden Quellcode bereit, ohne die Notwendigkeit für jegliche
Art von Quellcodemarkern, die Teile des Codes begrenzen, die mit
dem Softwaremodell synchronisiert werden sollen. Der Code in der
Softwareanwendung wird analysiert, und ein Softwaremodell der Aspekte
der Anwendung, die in das Softwaremodell integriert werden können, wird
generiert. Das Softwaremodell wird dann benutzt, um den Quellcode,
der durch das Softwaremodell dargestellt wird, erneut zu generieren,
wobei jeglicher Quellcode, der in dem Softwaremodell nicht dargestellt
ist, von dem ursprünglichen
Code in den generierten Quellcode beigemischt wird.
-
Gemäß der vorliegenden
Erfindung wird ein Verfahren zum Synchronisieren eines Softwaremodells
(2) und vorhandenen Quellcodes (4) bereitgestellt,
indem ein aktualisierter Quellcode generiert wird, wobei der Quellcode
Elemente, die in dem Softwaremodell (2) dargestellt werden
können,
und Elemente, die in dem Softwaremodell nicht dargestellt werden
können,
umfasst, wobei das Softwaremodell eine grafische Darstellung der
Interkommunikation zwischen den darstellbaren Elementen des Quellcodes
ermöglicht;
wobei das Verfahren die folgenden Schritte umfasst: Generieren eines
ursprünglichen Softwaremodells
unter zumindest teilweiser Verwendung des vorhandenen Quellcodes;
Generieren des Softwaremodells (2) in Reaktion auf die
Aktualisierung von Elementen im ursprünglichen Softwaremodell; Vergleichen
von Darstellungen jedes Softwaremodellelements mit einem entsprechenden
Element, sofern vorhanden, in dem Quellcode; Bestimmen eines Unterschieds
zwischen dem Softwaremodell (2) und dem vorhandenen Quellcode
(4) durch den Vergleich einer Darstellung jedes einzelnen
Softwaremodellelements mit einer Darstellung eines entsprechenden
Elements, sofern vorhanden, im Quellcode, wobei die Darstellungen
in einem Zwischenformat sind; Generieren von neuem Quellcode (8)
für jedes Softwaremodellelement,
nur wenn sich das Element von seinem entsprechenden Element im vorhandenen
Quellcode unterscheidet, da das Element im Softwaremodell aktualisiert
wurde; Integrieren des neuen Quellcodes (8) in den vorhandenen
Quellcode (2); und Speichern des kombinierten neuen Quellcodes
und des verbleibenden vorhandenen Quellcodes auf einem Speichermedium.
-
Auch
werden eine Vorrichtung und ein computer-lesbares Medium zum Ausführen des
oben beschriebenen Verfahrens bereitgestellt.
-
Diese
und andere Aufgaben der Erfindung werden aus dem restlichen Teil
dieser Beschreibung ersichtlich.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 ist
ein Diagramm, das eine Übersicht der
Anforderungen eines Round-Trip-Engineering-Werkzeugs darstellt.
-
2 ist
ein Venn-Diagramm, das die Information darstellt, die in dem Quellcode
für ein
Projekt und ein Softwaremodell des gleichen Projekts gespeichert
ist.
-
3A zeigt
ein Beispiel eines exportierten PowerBuilder-Objekts.
-
3B zeigt
das PowerBuilder-Objekt aus 3B nach
Anwendung einer Reverse-Engineering-Technik und Forward-Engineering-Technik
gemäß bidirektionaler
Engineering-Techniken
des Standes der Technik.
-
4 zeigt
eine Übersicht
eines Round-Trip-Engineering-Verfahrens
gemäß einer ersten
Ausführungsform
der Erfindung.
-
5 zeigt
beispielhaft eine Probe von C++-Quellcode.
-
6 zeigt
ein Metamodell, das aus dem Quellcode in 5 generiert
ist.
-
7 zeigt
Tabellen in einer Datenbank, die ein Softwaremodell darstellen.
-
8 zeigt
modifizierte Tabellen in einer Datenbank, die ein Softwaremodell
darstellen.
-
9A zeigt
ein Metamodell, das aus dem Quellcode in 5 generiert
ist.
-
9B zeigt
ein Metamodell, das aus dem Softwaremodell in 8 generiert
ist.
-
9C zeigt
ein aktualisiertes Metamodell, das auf den Metamodellen von 9A und 9B beruht.
-
10 zeigt
einen vorläufigen
Mischcode.
-
11 zeigt
einen endgültigen
Mischcode.
-
12 zeigt
eine Übersicht
der Reverse-Engineering-Technik
(PowerBuilder).
-
13 zeigt
eine Übersicht
der Forward-Engineering-Technik.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Wie
in 1 dargestellt, betrifft die nachstehend beschriebene
Ausführungsform
der Erfindung die Round-Trip-Engineering-Technik
eines Softwareprojekts zwischen einem Softwaremodell 2 und
dem Projektquellcode 4, wobei das Softwaremodell und die
Software synchronisiert gehalten werden können.
-
Das
primäre
Beispiel, das zur Verdeutlichung der Betriebsweise der Ausführungsform
benutzt und in 5 bis 11 dargestellt
ist, beruht auf der Programmiersprache C++, wenngleich es keinen
Grund dafür
gibt, dass die Erfindung nicht auch auf anderen objektorientierten
Sprachen oder anderen Sprachtypen betrieben werden könnte, wie
ersichtlich werden wird. Sprachen, in denen die Objekte im Normalfall
in firmeneigenen binären
Formaten gespeichert sind, können
oft in Flachdateiformate wie ASCII-Textdateien mit Darstellungen
aller Merkmale der Objekte exportiert werden, so dass die Objekte
zurück
in die Anwendung reimportiert werden können. Beispiele solcher Anwendungen
sind Microsofts Visual BASIC, Visual C++, Access und Sybase PowerBuilder.
Häufig werden
bestimmte Module in diesen Anwendungen sowieso als Quellcode-Flachdateien
wie C++-.cpp-Dateien
und BASIC-.bas-Dateien gespeichert.
-
Das
Softwaremodell 2 muss nicht alle Konzepte der Sprache des
Quellcodes bereitstellen und stellt im Normalfall eine Modellierung
für Konzepte auf
höherer
Ebene in dem Quellcode wie Klassen, Attribute, Vorgänge/Verfahren
usw. oder eine Datenflussmodellierung zwischen Komponenten bereit. Viele
Aspekte des Quellcodes wie die Formatierung von Objekten darin werden
oft nicht in dem Softwaremodell gespeichert, allerdings ist es sehr
wichtig, dass solche Information bei dem Round-Trip-Engineering
nicht verloren geht. Zum Beispiel weist Code, der aus einer Sybase
PowerBuilder-Anwendung exportiert wird, die in 3A dargestellt
ist, Information hinsichtlich der Breite, Höhe und Position einer Klasse
des Fenstertyps w_sort auf. Solche Information würde im Allgemeinen in einem
Softwaremodell nicht enthalten sein. Wenn dieser Code in ein Softwaremodell 2 einem
Reverse-Engineering-Verfahren unterzogen und dann unter Verwendung
des Softwaremodells per se wiederhergestellt würde, dann könnte der generierte Code die
Erscheinung des Codes in 3B haben,
wobei viel Formatierungsinformation auf der Rundreise verloren ginge.
-
Darüber hinaus
ist die Sprache, in der das Softwaremodell 2 generiert
wird, im Idealfall dazu fähig,
verschiedene Softwareentwicklungssprachen zu modellieren, wodurch
es unwahrscheinlich ist, dass jede beliebige bestimmte Sprache,
die modelliert wird, alle Konzepte unterstützen wird, die von der Modellierungssprache
unterstützt
werden.
-
Dementsprechend
entsteht eine Situation, die durch das Venn-Diagramm in 2 beispielhaft dargestellt
ist, wobei das Softwaremodell und die Softwareentwicklungssprache
zwar gemeinsame Konzepte nutzen, jedoch jeweils Konzepte aufweisen,
die von dem anderen nicht bereitgestellt werden.
-
Wenn
die Quellcodesprache zum Beispiel C++ ist, könnte das Softwaremodell die
Modellierung von C++-Klassen, -Structs, -Verbindungen und -Aufzählungsklassen
mit ähnlichen
Strukturen bereitstellen, obwohl die Aufzählungsklassen als ein Datentyp betrachtet
werden könnten
und nicht als eine Klasse in dem Softwaremodell. C++-Attribute könnten auf Softwaremodellattribute,
Assoziationen und/oder Aggregationen abgebildet werden, je nach
den Optionen, die an das Reverse-Engineering-Dienstprogramm geliefert
werden, und den Codesituationen. Zusätzliche Information wie "static" oder "const" könnte in
den Vorgangseigenschaften entsprechend markiert sein. Globale Verfahren
könnten
auf globale Vorgänge
in der Modelliersprache abgebildet werden. C++-Verfahren könnten als Vorgänge in der
Modelliersprache modelliert werden und überladenen Verfahren könnte eine
ganzzahlige ID gegeben werden, die mit ihrem Namen verknüpft ist,
um sie in dem Softwaremodell eindeutig zu identifizieren.
-
Derzeit
sind viele Softwaremodellierungsprodukte wie Platinum Technology,
Inc.s Paradigm Plus erhältlich,
die die Generierung von Softwaremodellen aus Quellcode unter Verwendung
verschiedener unterschiedlicher Modellierungsmethodologien ermöglichen
und auch die Generierung von Quellcode aus dem Softwaremodell ermöglichen.
Die folgende Beschreibung der Betriebsweise der Erfindung setzt
voraus, dass die notwenige Funktionalität bereits vorhanden ist, um
solche Softwaremodelle zu generieren und Quellcode aus diesen Softwaremodellen
zu regenerieren, und bezieht sich dementsprechend nicht auf die
tatsächliche
Darstellung des Softwaremodells, außer in beispielhafter Weise.
-
Der
Quellcode 4 eines Softwareprojekts besteht im Allgemeinen
aus einem Dateiset, das auf einem Computer oder einem Netzwerk oder
Computern gespeichert ist. Die vorliegende Erfindung stellt ein
Verfahren zum Round-Trip-Engineering von Quellcode bereit, indem
ein verbessertes System zum Forward-Engineering benutzt und implementiert wird.
-
Wie
oben erwähnt,
werden Standardtechniken benutzt, um ein Softwaremodell zu generieren oder
ein bereits generiertes Softwaremodell 2 zu erweitern.
Das Softwaremodell kann dann einem Forward-Engineering-Verfahren
unterzogen werden, um für
das Projekt Quellcode zu generieren, wie dargestellt. Es ist wichtig,
dass, wenn ein Softwareprojekt einem Reverse-Engineering-Verfahren
von Quellcode unterzogen wird und das generierte Softwaremodell
einem Forward-Engineering-Verfahren
unterzogen wird, der resultierende Code im Wesentlichen der gleiche
sein sollte, ungeachtet dessen, welche Information in dem Quellcode
in dem Softwaremodell dargestellt wird. Dies ermöglicht ein angemessenes „Round-Trip"-Engineering des
Softwareprojekts, so dass das Softwaremodell und der Quellcode synchronisiert
gehalten werden können,
Aktualisierungen sowohl im Quellcode als auch dem Softwaremodell
beibehalten werden, wenn der Quellcode aus dem Softwaremodell generiert
wird und umgekehrt, und Kommentare und andere Merkmale des Quellcodes,
die in dem Softwaremodell nicht dargestellt sind, nicht auf die
Rundreise geschickt werden oder sogar während des Rundreisenprozesses
verschwinden.
-
Die
Funktionsweise des Round-Trip-Engineering-Verfahrens der beschriebenen
spezifischen Ausführungsform
der Erfindung ist in 4 allgemein dargestellt.
-
Ein
Reverse-Engineering-Verfahren 10 wird in normaler Weise
ausgeführt,
jedoch ist von Bedeutung, dass während
des Forward-Engineering-Verfahrens 12 der vorhandene Quellcode 4 mit
den Daten aus dem Softwaremodell 2 gemischt wird, wodurch
neuer Quellcode 8 generiert wird, der dann den vorhandenen
Quellcode ersetzt. Entsprechende Abschnitte des Quellcodes werden
für jedes
Element in dem Softwaremodell 2 identifiziert und jegliche Änderungen,
Hinzufügungen
oder Löschungen,
die in dem Softwaremodell vorgenommen wurden und die nicht dem Quellcode
entsprechen, werden in den neuen Quellcode 8 integriert,
ohne irgendwelche Teile des Quellcodes, der von dem Softwaremodell
nicht dargestellt wird, zu beeinträchtigen.
-
Die
Betriebsweise der spezifischen Ausführungsform der Erfindung wird
nachstehend mit Bezug auf 5 bis 11 beschrieben.
Die Erfindung betrifft Forward-, Reverse- und Round-Trip-Engineering-Verfahren
von jeder beliebigen Softwaresprache in ein Softwaremodell, das
die Software darstellt. Ein Beispiel der Betriebsweise der Ausführungsform
ist mit Bezug auf die Programmiersprache C++ gegeben, wenngleich
die Ausführungsform
gleichermaßen
auf andere Programmiersprachen anwendbar ist und im Idealfall eine
Vielzahl von Programmiersprachen handhaben könnte. Die Erfindung ist in
keiner Weise auf die von der Programmiersprache C++ verwendeten
Konstrukte eingeschränkt.
Die Erfindung betrifft primär
das Mischen des Quellcodes und der Daten in dem Softwaremodell,
wobei ein Zurückhalten
des ursprünglichen
Quellcodes ohne Zurückgreifen
auf Marker in dem Code möglich
ist. Die tatsächlichen
Inhalte des Codes sind für
die Erfindung nicht relevant.
-
Der
Quellcode 4 in den Quellcodedateien 40, der in
einer bestimmten Programmiersprache geschrieben ist, wird durch
ein Reverse-Engineering-Verfahren in ein neues Softwaremodell 2 rückentwickelt
oder in ein vorhandenes Softwaremodell 2 integriert und
dann von dem Softwaremodell 2 durch ein Forward-Engineering-Verfahren
in ein neues Set von Quellcodedateien 80 überführt oder
mit vorhandenen Quellcodedateien 40 ohne Rückgriff
auf neue Quellcodedateien gemischt.
-
REVERSE-ENGINEERING
-
Das
Reverse-Engineering-Verfahren gemäß dieser Ausführungsform
wird durch syntaktisches Analysieren des Codes und Umwandeln aller
Elemente des Codes, die durch das Softwaremodell dargestellt werden
können,
in ein generisches Metamodell, zum Beispiel unter Verwendung des
CASE Data Interchange Formats (CDIF), das im Allgemeinen als ein
generisches standardmäßiges Darstellungsformat
für Softwareeinheiten
benutzt wird, ausgeführt.
Einzelheiten des CDIF-Standardsets
können von
dem Electronic Industries Association CDIF Technical Committee erhalten
werden. Aus dem generischen Metamodell werden die Elemente des Codes,
die in dem ausgewählten
Softwaremodell dargestellt werden können, in das Softwaremodell
exportiert. Das Verfahren zum Exportieren der Daten aus dem Metamodell
in das Softwaremodell hängt
von dem Format des generierten Softwaremodells und Metamodells ab,
bezieht jedoch in den meisten Fällen
einfach das Füllen
einer Datenbank von Elementen ein. Das Softwaremodell 2 dieser
Ausführungsform
der Erfindung benutzt eine Datenbank, die die Tabellen 22, 23, 24, 25 umfasst,
um die Daten darzustellen.
-
Das
Softwaremodell 2 muss nicht im Datenbankformat vorliegen
und kann in einer beliebigen Art von Datenstruktur gespeichert sein.
In der in 7 dargestellten Datenbank sind
verschiedene Elemente der Anwendung bezüglich des Typs in die Tabellen 22, 23, 24, 25 mit
angemessenen Feldern klassifiziert, um alle Eigenschaften der Elemente
darzustellen und sie bezüglich
anderer zugehöriger
Elemente angemessen mit Querverweisen zu versehen. Das Format dieser
Tabellen variiert hauptsächlich
in Abhängigkeit
der Methodologie, die von dem Softwaremodell verkörpert wird,
um die modellierte Software darzustellen. Zum Beispiel stellt das
Softwaremodell, das in 7 dargestellt ist, Klassen,
Attribute, Vorgänge,
Assoziationen, die Beziehungen dazwischen und andere Merkmale davon
dar. Diese Konstrukte können
benutzt werden, um Konstrukte in vielen objektorientierten Sprachen
darzustellen. Zum Beispiel können
C++- Verfahren als
Vorgänge
in dem Softwaremodell dargestellt werden und C++-Konstrukte der
Arten CLASS, STRUCT, UNION und ENUM können alle als Klassen in dem
Softwaremodell dargestellt werden. Das Softwaremodell könnte auch
Information bezüglich
anderer Softwareeinheiten wie Objekte oder einen Datenfluss zwischen
Einheiten aufweisen. Vier Tabellen sind in 7 dargestellt,
die jeweils Information bezüglich
Klassen, Attributen, Vorgängen
und Assoziationen aufweisen. Die zwei Klassen X und Y in der Klassentabelle 2 weisen
ganzzahlige Identifikatoren auf, die das Softwaremodell benutzt,
um sie zu identifizieren. Andere Merkmale der Klassen sind auch
in der Tabelle gespeichert, wie die Quelldatei der betreffenden
Klasse und der Typ der betreffenden Klasse wie CLASS oder STRUCT.
Bestimmte Felder, die von dem Softwaremodell für jede Klasse bereitgestellt
werden, könnten
auf die modellierte Softwaresprache nicht anwendbar sein und können leer
bleiben.
-
Jeder
Eintrag in der Attributtabelle 23 weist ein Feld auf, das
den Namen des Attributs und die Besitzklasse darstellt. Andere Felder
könnten
der Bereich des Attributs, des Typs und der Quelldatei sein. Da
Attribute überladen
sein könnten,
das heißt,
verschiedene Attribute in verschiedenen Klassen den gleichen Namen
benutzen, könnte
es sein, das der Name, der dem Attribut in dem Softwaremodell gegeben
wurde, modifiziert werden muss, um zwischen gleich bezeichneten
Attributen und einem Alias, der für das betreffende Attribut
gegeben wurde, zu unterscheiden. Als Alternative könnten Attributen
willkürliche
Identifikatoren wie Schlüsselwerte
in der Tabelle gegeben werden, so dass mehr als ein Attribut den gleichen
Namen benutzen könnte.
Das gleiche Prinzip wird für
andere Konstrukte benutzt, die überladen sein
könnten,
wie Vorgänge.
-
Datensätze in den
Vorgangstabellen 24 enthalten Vorgänge, die in diesem Beispiel
C++-Verfahren und -Funktionen aufweisen. Diese Datensätze weisen
ebenfalls Felder für
die Besitzklasse auf, falls diese vorhanden ist. In diesem auf C++
basierenden Beispiel bezieht sich ein Quelldateifeld in dieser Tabelle
auf die tatsächliche
Datei, die den Quellcode für das
Verfahren enthält,
und nicht auf die Quelldatei, die die Erklärung des Verfahrens enthält, da letztere von
der Quelldatei der Besitzklasse abgeleitet sein könnte.
-
Schließlich enthält die Assoziationstabelle 25 Assoziationen
zwischen Klassen. In diesem Beispiel werden Attribute, die mindestens
eines Klassentyps sind, als Assoziationen gespeichert, wenngleich
sie in der Attributtabelle mit dem auf den Klassennamen eingestellten
Typ gespeichert werden könnten.
Das Besitzklassenfeld speichert die Klasse, in der das Attribut
definiert ist und über
die darauf zugegriffen wird. Die Mitgliedsklasse speichert die Klasse,
von der das Attribut ein Typ ist, das heißt, den Klassentyp des Attributs.
-
Das
Reverse-Engineering von objektbasierten Sprachen und nicht von Quellcode
kann erreicht werden, indem die gesamte Information, die in den Objekten
eingekapselt ist, in ein Flachdateiformat, zum Beispiel ASCII, exportiert
wird und dann jegliche Information, die durch das Softwaremodell 2 dargestellt
werden kann, von der exportierten Datei in das CDIF-Metamodell importiert
und von dort in das Softwaremodell importiert wird. Der Schritt
des Darstellens der Daten im CDIF-Format könnte vermieden werden. Allerdings
hat die Verwendung des Zwischenschritts des Generierens einer CDIF-Formatdatei den Vorteil,
dass Standarddienstprogramme, die zur Umwandlung von Daten aus verschiedenen Quellsprachen
in das CDIF-Format bereits vorhanden sind, benutzt werden können und
dann ein einziges Dienstprogramm benutzt werden kann, um die Daten
aus dem CDIF-Format in das Softwaremodell zu importieren. Wenn das
Softwaremodell direkt aus dem Quellcode generiert werden sollte,
müsste
ein anderes Dienstprogramm für
jede Quellsprache, die von irgendeinem bestimmten Softwaremodellformat unterstützt wird,
generiert werden. 12 zeigt ein Beispiel der Betriebsweise
des Reverse-Engineering gemäß der Erfindung
auf einem Set von PowerBuilder-Objekten. Wenn die Erfindung auf
C++-Quellcode betrieben werden sollte, wäre der Exportierschritt nicht
notwendig und der Code könnte
direkt in das CDIF-Format umgewandelt werden.
-
Falls
ein Softwaremodell 2 bereits vorhanden ist, wenn die Daten
aus der Quelldatei in das Softwaremodell importiert werden, und
Daten aus der Quelldatei in das Softwaremodell gemischt werden sollen
und dieses nicht ersetzen sollen, wird eine Überprüfung ausgeführt, bevor Elemente in die
Datenbank für
entsprechende Elemente, die bereits in der Datenbank vorhanden sind,
hinzugefügt
werden. Wenn ein entsprechendes Element nicht gefunden wird, wird
das Element einfach zu der Datenbank hinzugefügt.
-
Wenn
ein entsprechendes Element in der Datenbank gefunden wird und die
Datenfelder, die sowohl in dem zu mischenden Element als auch dem entsprechenden
Element definiert sind, das bereits in der Tabelle vorhanden ist, übereinstimmen,
werden sämtliche
Datenfelder, die nur in dem importierten Element definiert sind,
in die vorhandenen Felder für die
entsprechenden Elemente integriert und die anderen Felder werden
unberührt
gelassen.
-
Wenn
ein entsprechendes Element in der Datenbank gefunden wird und die
Datenfelder, die sowohl in dem zu mischenden Element als auch dem bereits
in der Tabelle vorhandenen entsprechenden Element definiert sind,
nicht übereinstimmen,
wird eine Konfliktlösung
benutzt, um zu bestimmen, ob das importierte Element oder das bereits
vorhandene Element Priorität
hat. Zum Beispiel könnte
ein Meldungsfenster angezeigt werden, das über den Konflikt informiert
und nachfragt, welche Daten in dem Softwaremodell benutzt werden
sollten. Welche der importierten Daten und der bereits vorhandenen
Daten Priorität
haben, könnte
auch vor dem Beginn des Imports festgelegt werden, so dass keine
Konfliktlösung
notwendig ist.
-
Darüber hinaus
könnte
auch eine Überprüfung ausgeführt werden,
ob sich alle Daten in dem Softwaremodell, die mit der importierten
Quelldatei oder Quelldateien assoziiert sind, tatsächlich unter den
importierten Elementen befanden. Jegliche Nichtübereinstimmung würde entweder
den Elementen, die zu dem Softwaremodell hinzugefügt wurden, oder
Elementen, die aus dem Quellcode entfernt wurden, entsprechen, da
das Softwaremodell und der Quellcode zuletzt synchronisiert wurden.
Wenn ein Protokoll von Hinzufügungen
zu dem Softwaremodell erstellt wird, würde eine einfache Überprüfung der protokollierten
Hinzufügungen
dem importierenden Dienstprogramm ermöglichen, zu bestimmen, ob das Element
zu dem Softwaremodell hinzugefügt
worden ist oder aus dem Quellecode entfernt worden ist, und geeignete
Maßnahmen
ergreifen. In letzterem Fall könnte
ein Meldungsfenster bereitgestellt werden, das fragt, ob das Element
aus dem Softwaremodell entfernt werden soll.
-
FORWARD-ENGINEERING
-
Das
Forward-Engineering wird durch Mischen der Daten in dem Softwaremodell 2 mit
jedem beliebigen vorhandenen Quellcode 4, Hinzufügen von
neuem Code, Ändern
von Code oder gegebenenfalls Entfernen von Code, um neuen Quellcode 8 zu
erschaffen, ausgeführt.
Wichtig ist hierbei, dass vorhandener Quellcode, der durch Änderungen
in dem Softwaremodell nicht beeinflusst wird, unverändert bleibt.
Ein Beispiel des Forward-Engineering-Verfahrens, das zur Generierung
eines PowerBuilder-Projekts benutzt werden könnte, ist nach dem Reverse-Engineering-Verfahren
gemäß 12 in 13 dargestellt.
Das Forward-Engineering-Verfahren wird im Allgemeinen benutzt, um
Quellcode basierend auf Modifikationen an dem Softwaremodell zu
modifizieren oder neuen Quellcode zu schaffen. Die vorliegende Erfindung
stellt ein System zur Ausführung
des letztgenannten bereit, wobei das Verfahren mit Bezug auf 8 bis 11 erläutert wird
und wobei 8 ein Softwaremodell 2 darstellt,
das eine modifizierte Version des in 7 dargestellten
Softwaremodells ist.
-
Wie
bereits erwähnt,
könnten
Felder in dem Softwaremodell 2 möglicherweise nicht in Quellcode transferierbar
sein. Zum Beispiel könnte
ein Feld in der Darstellung einer Klasse in dem Softwaremodell bereitgestellt
werden, das ein Dokument identifiziert, das eine Erläuterung
der Funktion der betreffenden Klasse enthält. Solche Felder können in
dem Softwaremodell angesiedelt werden, um den Softwareentwurf zu
unterstützen,
ohne in den Quellcode integriert zu werden, und, wie oben beschrieben,
beeinträchtigen
das Reverse-Engineering des Quellcodes nicht, da entsprechende Daten,
die einen Konflikt verursachen könnten,
niemals aus dem Quellcode importiert würden.
-
Mit
erneutem Bezug auf 9A und 9B werden
bei der Ausführung
eines Forward-Engineering-Verfahrens einer Quellcodedatei zunächst ein generisches
Metamodell 80 der Daten in der durch Forward-Engineering überführten Quelldatei
oder Quelldateien und ein generisches Metamodell 82 der Daten
in dem Softwaremodell generiert. Metamodelle, die aus dem modifizierten
Softwaremodell in 8 und dem ursprünglichen
Quellcode in 5 generiert werden könnten, sind
jeweils in 9A und 9B dargestellt.
Die Metamodelle könnten
zum Beispiel im CDIF-Format generiert werden, wie oben mit Bezug
auf das Reverse-Engineering-Verfahren erläutert. Das verwendete generische
Metamodellformat muss eine Darstellung aller Elemente des Quellcodes,
die in dem Softwaremodell dargestellt werden können und umgekehrt, ermöglichen.
Die Verwendung des generischen Metamodells macht einen Vergleich
der zwei unterschiedlichen Datenquellen möglich. Abbildungen von jeder
spezifischen Umgebung auf das generische Metamodell werden entwickelt,
um zu gewährleisten,
dass keine Daten verloren gehen und die angemessene Information
verglichen wird. Darüber
hinaus werden nur die Elemente, die in der durch Forward-Engineering überführten Quellcodedatei
vorhanden sein sollten, aus dem Softwaremodell extrahiert. Zum Beispiel
werden alle Klassen, die in dem Softwaremodell 2 mit ihrem Quellcodedateifeld
gespeichert sind, das der Quellcodedatei entspricht, und alle Attribute,
Vorgänge und
Assoziationen, die diese Klassen besitzen, in das Metamodell 82 gebracht.
Klassen und andere Objekte aus Quellcodedateien, die nicht die generierte
Quellcodedatei sind, werden nicht in dem Metamodell angeordnet.
Zum Beispiel wird, wie in 9A dargestellt,
die Klasse Z nicht in dem Metamodell angeordnet, da sie nicht zu
der Quellcodedatei A (siehe 8) gehört. Wenn
mehr als eine Quelldatei in dem Forward-Engineering-Verfahren generiert
werden soll, wird das für
Forward-Engineering beschriebene Verfahren für jede Quelldatei ausgeführt und
die angemessenen Daten werden in jedem Fall aus dem Softwaremodell 2 extrahiert.
-
Die
Betriebsweise der Metamodellgenerierung und die Natur der generierten
Metamodelle hängt
von der Struktur der Programmiersprache und den Konstrukten darin
sowie von den in dem Softwaremodell benutzten Konstrukten ab. Es
muss möglich
sein, die Elemente in dem Quellcode-Metamodell 80 zu durchsuchen
und die entsprechenden Elemente aus dem Softwaremodell 2 und
dem Quellcode 4 zu identifizieren. Zum Beispiel könnten unterschiedliche
Klassen, Variablen und andere unabhängige Strukturen in dem Quellcode
wie STRUCT- und UNION-Strukturen
in einer verketteten Liste gespeichert sein. Elemente, die im Besitz
dieser Strukturen sind, könnten
in einer verketteten Liste angeordnet werden, auf die von dem angemessenen
Element in der verketteten Hauptliste gezeigt wird. Das Suchen nach
Elementen wird dann ohne weiteres erreicht, indem die verkettete
Liste hinuntergegangen wird, die angemessenen Elemente gefunden
werden und, falls notwendig, dann die angehängte verkettete Liste, die
mit diesem Element assoziiert ist, durchsucht wird.
-
Es
ist wichtig, das jedes Element in dem generischen Metamodell, das
aus dem Quellcode generiert wird, eine damit assoziierte Zeilenzahl 84 und einen "Änderungszustand" 86 aufweist.
Die Zeilenzahl entspricht der Zeilenzahl des betreffenden Elements
in dem ursprünglichen
Quellcode. In alternativen Ausführungsformen
der Erfindung könnten
die tatsächlichen
Anfangs- und Endpunkte in dem Code, die mit irgendeinem bestimmten
Element assoziiert sind, in dem Softwaremodell gespeichert werden, und
nicht nur die Zeilenzahl, so dass eine Vielzahl von Elementen auf
einer Zeile unabhängig
gemischt werden kann. Zum Beispiel sind in dem beispielhaften Metamodell,
das aus dem in 9A dargestellten Quellcode generiert
wird, die Zeilenzahlen 84 in der mittleren Spalte dargestellt.
-
Der Änderungszustand 86 ist
in der rechten Spalte für
jedes der Elemente in 9A dargestellt. Er kann einen
von vier Werten aufweisen: Hinzugefügt, Gelöscht, Modifiziert und Keiner.
Wenn das Metamodell anfangs generiert wird, weisen die Elemente
alle einen undefinierten Änderungszustand
auf, um darzustellen, dass das Mischen noch nicht begonnen hat,
wobei keine Änderungen
an dem Metamodell vorgenommen worden sind, wie in 9A dargestellt.
-
Das
für das
Softwaremodell 2 generierte Metamodell 82 erfordert
die Zeilenzahlen 84 und die Änderungszustände 86 nicht,
wie offensichtlich werden wird. Eine Darstellung eines für das Softwaremodell 2 generierten
Metamodells ist in 9B dargestellt.
-
Das
generische Metamodell 80 des Quellcodes 4 wird
nach einem entsprechenden Element für jedes Element in dem Metamodell 82 für das Softwaremodell 2 durchsucht.
-
Wenn
ein entsprechendes Element nicht gefunden wird, wird das Element
zu dem Metamodell für
den Quellcode hinzugefügt
und der „Änderungszustand" wird auf „Hinzugefügt" festgelegt.
-
Wenn
das Element gefunden wird, jedoch eine Parameternichtübereinstimmung
vorliegt, werden die Parameter in die aktualisierten Parameter geändert und
der Änderungszustand
des entsprechenden Elements wird auf „Modifiziert" festgelegt. Eine Darstellung
der ersetzten Parameter würde
in einer Datei oder in dem Metamodell gespeichert, so dass am Ende
des Forward-Engineering-Verfahrens ein angemessenes Protokoll erstellt
werden kann.
-
Wenn
das Element gefunden wird und die Parameter des Elements übereinstimmen,
wird der Änderungsuzstand
auf Keiner" festgelegt,
um widerzuspiegeln, dass keine Änderungen
vorliegen.
-
Nachdem
alle Elemente durchsucht worden sind, müssen sämtliche Elemente, deren Änderungszustand
nicht festgelegt wurde, aus dem Softwaremodell entfernt worden sein.
Der Änderungszustand dieser
Elemente ist auf "Gelöscht" eingestellt. Die Änderungszustände aller
Elemente könnten
anfangs vor der Suche auf „Gelöscht" eingestellt werden,
anstatt leer gelassen zu werden, um ein zweites Durchlaufen aller
Elemente zu vermeiden.
-
Um
die Notwendigkeit der Generierung des zweiten generischen Metamodells 82 zu
vermeiden, könnten
die Elemente in dem Metamodellformat, die aus dem Softwaremodell 2 generiert
werden, stattdessen mit dem Metamodell 80 verglichen werden, während sie
generiert werden. Während
jedes Element verglichen wird, würden
die gleichen Vorgänge wie
oben beschrieben ausgeführt,
um die Änderungszustände festzulegen,
was zu dem gleichen gemischten Metamodell führt.
-
Es
sei klargestellt, dass bei der obigen Verarbeitung davon ausgegangen
wird, dass das Softwaremodell die korrekte Version ist und der Quellcode
veraltet ist. Die zwei könnten
jedoch synchronisiert werden,* wenn Aktualisierungen an dem Quellcode
und dem Softwaremodell vorher protokolliert würden und die Information in
dem Protokoll benutzt würde,
um zu entscheiden, welches der zwei entsprechenden Elemente in den
zwei Metamodellen Priorität
hat, wenn das Softwaremodell und Quellcode nicht übereinstimmen.
Ein Reverse-Engineering-Verfahren
würde dann
ausgeführt,
um das Softwaremodell mit dem neuen generierten Quellcode in Übereinstimmung
zu bringen. Dies würde
in der Tat das entgegensetzte Round-Trip-Engineering-Verfahren sein,
das mit dem Forward-Engineering-Verfahren beginnt. Es ist im Allgemeinen
einfacher als das Round-Trip-Engineering-Verfahren in der herkömmlichen
Reihenfolge und das assoziierte Mischverfahren mit dem Softwaremodell,
das Priorität
hat, ist folglich das Verfahren, das hierin ausführlich behandelt wird.
-
Das
aktualisierte Metamodell 88, das aus diesem Verfahren folgt,
ist in 9C dargestellt, wobei der Vorgang
doThat() hinzugefügt
und das Attribut 3 aus dem Quellcode-Metamodell gelöscht ist.
-
Eine
neue Version der Quellcodedatei wird dann aus der ursprünglichen
Quellcodedatei, die in 5 dargestellt ist, und dem generischen
Metamodell generiert. Die neue Version könnte in einer Datei, in einer
eindimensionalen Textanordnung mit einem Eintrag für jede Codezeile
oder durch Anordnen des Quellcodes in einer verketteten Liste mit
einem Eintrag für
jede Codezeile konstruiert werden. Zwei im Wesentlichen unterschiedliche
Ansätze könnten für das Einfügen neuer
Codezeilen in den Quellcode benutzt werden. Der neue Quellcode könnte am
Ende hinzugefügt
werden und angemessene Abbildungen, die aus einem Index generiert werden,
oder der untere Teil der betreffenden Datenstruktur könnte expandiert
nach unten verschoben und der neue Code eingepasst werden. Dies
wäre im Allgemeinen
einfacher, wenn die Konstruktion in einer verketteten Liste oder
Anordnung stattfände.
In diesem Beispiel wird angenommen, dass neuer Code zu dem Ende
einer Datei hinzugefügt
wird und ein Index von Positionen in der Datei für jede Codezeile angemessen
aktualisiert wird, wie in 10 dargestellt.
Die folgende Verfahrensweise wird dann für jedes Element in dem generischen
Metamodell des Codes ausgeführt:
Wenn
der Änderungszustand
Keiner ist, wird an dem assoziierten Quellcode keine Änderung
vorgenommen.
-
Wenn
der Änderungszustand "Gelöscht" ist, wird die entsprechende
Zeile in der neuen Quellcodedatei unter Verwendung des Index gefunden
und die Zeile wird mittels syntaxspezifischer Kommentare entfernt
(das heißt,
auskommentiert). Zum Beispiel würde
dies in C++ die Verwendung von Kommentaren /* und /* am Anfang und
am Ende der Zeile bedeuten. Als Alternative könnte der Code tatsächlich entfernt
werden und der entfernte Text könnte
in einer Protokolldatei aufgezeichnet werden. In diesem Fall würde die
Indexposition für
die entfernte Zeile gelöscht
und alle anderen Indexstellen darunter würden eine nach der anderen
nach oben bewegt.
-
Wenn
der Änderungszustand "Hinzugefügt" ist, wird die geeignete
Stelle zum Hinzufügen
des neuen Codes bestimmt. Wenn das neue Element zum Beispiel ein
Mitglied einer Klasse ist, wird die letzte Zeile in der Klasse durch
Durchsuchen aller Elemente in der Klasse und Addieren von 1 zu der höchsten gefundenen
Zeilenzahl gefunden. Als Alternative könnte das Ende der Klasse tatsächlich in
dem generischen Metamodell mit dem betreffenden Klassenelement zusammen
mit der ersten Zeilenzahl in der Klasse enthalten sein oder der
tatsächliche
Quellcode könnte
durchsucht werden, um die letzte Zeile in der Klasse zu finden.
Eine neue Zeile oder neue Zeilen werden am Ende des Quellcodes hinzugefügt und angemessener
Code für
das Element wird darin eingetragen. Der geeignete Punkt hinsichtlich
der letzten Zeile in der Klasse in dem ursprünglichen Quellcode wird in
dem Index gefunden und Verweise auf die neuen Codezeilen werden
eingefügt.
Alle Indexeinträge
unterhalb dieses Punktes werden angemessen nach unten bewegt. Das
Ergebnis dieses Vorgangs Einfügen
des Verfahrens doThat() ist in 10 dargestellt.
-
Wenn
der Änderungsuzstand „geändert" ist, wird der geeignete
Indexeintrag für
die Zeile gefunden und geeignete Änderungen werden an dem Code
vorgenommen.
-
Nachdem
alle notwendigen Änderungen
und Hinzufügungen
vorgenommen worden sind, wird ein Durchgang durch den Index ausgeführt und
die entsprechenden Codezeilen aus der gemischten Quellcodedatei
oder der sie darstellende Datenstruktur werden extrahiert und in
der korrekten Reihenfolge in eine neue Datei geschrieben, wie in 11 dargestellt.
Die ursprüngliche
Quellcodedatei wird dann durch die neue Quellcodedatei ersetzt.
-
Der
generierte Code gleicht dem ursprünglichen Code, außer an den
Stellen, an denen Änderungen
in dem Softwaremodell vorgenommen worden sind.
-
In
einer Modifikation dieser Ausführungsform wird
ein vorläufiger
Quellcode aus dem Quellcode generiert und der so generierte Quellcode
wird mit dem ursprünglichen
Quellcode gemischt. Das Mischen der zwei Quellcodesets könnte durch
Generieren eines wie oben beschriebenen Metamodells für sowohl
das ursprüngliche
als auch das genierte Quellcodeset erreicht werden. In diesem Fall
würde das
Metamodell für
den generierten Quellcode genau mit dem Metamodell 82 für das Softwaremodell übereinstimmen
und das Verfahren würde
exakt wie oben beschrieben ausgeführt. In der Tat wäre ein zusätzlicher
Schritt des Konvertierens in Quellcode in die Generierung des Softwaremodell-Metamodells 82 aus
dem Softwaremodell 2 eingefügt worden.
-
Als
Alternative könnte
der Schritt des Vereinigens beider Quellcodesets in ein Metamodell
beseitigt werden und ein Dienstprogramm könnte beide Quellsets syntaktisch
analysieren und nach entsprechenden Elementen suchen und den ursprünglichen Quellcode
angemessen aktualisieren. Die Betriebsweise dieses Dienstprogramms
wäre der
Betriebsweise des Systems zum Vergleichen der zwei oben beschriebenen
Metamodelle ähnlich,
jedoch würde sie
das Verfolgen, zu welcher Klasse oder Struktur der durchsuchte Code
gehört,
erfordern. Jedoch wäre
es im Allgemeinen viel einfacher, ein Metamodell zu schaffen, das
den Code in einer Datenstruktur darstellt, als tatsächlich zu
versuchen, den Code ohne Vorbereitung zu analysieren, wobei dieses
Verfahren des Mischens des Softwaremodells und des Quellcodes nicht
als bevorzugt betrachtet wird.
-
Wenngleich
bevorzugte Ausführungsformen der
vorliegenden Erfindung dargestellt und beschrieben worden sind,
wird der Durchschnittsfachmann verstehen, dass Änderungen und Modifikationen
vorgenommen werden können.