GACSAL KAROLY (HU)
HICZ GABOR (HU)
MEUNIER REGINE (DE)
TÖDTER KAI (DE)
| US20090198727A1 | 2009-08-06 | |||
| US20090094014A1 | 2009-04-09 |
| Patentansprüche 1. Verfahren zur modellbasierten Softwareentwicklung von Programmen mit Datenbankzugriff, - bei dem mit Hilfe eines Editors (ED) Metamodelle (Ml, M2) einer alten und neuen Programmversion erzeugt oder geändert werden, derart dass für eine jeweilige Programmversion eine jeweilige Historienliste (HL1, HL2) erzeugt und jede Änderung eines Metamodells durch einen entsprechenden Historieneintrag (HEI, HE2) in der jeweiligen Historienliste festgehalten wird, - bei dem mit Hilfe eines Klassengenerators (KG) aus Metamo- dellen (Ml) der alten Programmversion alte Datentypen (DT1) erzeugt werden, die über Datenbankschemata (DS1) einer alten Datenbank (DB1) auf alte Datenbankeinträge (DE1) der alten Datenbank (DB1) abgebildet werden, - bei dem mit Hilfe des Klassengenerators (KG) aus Metamodel- len (M2) der neuen Programmversion neue Datentypen (DT2) erzeugt werden, die über neue Datenbankschemata (DS2) einer neuen Datenbank (DB2) auf neue Datenbankeinträge (DE2) der neuen Datenbank (DB2) abgebildet werden, - bei dem mit Hilfe einer Migrationsmaschine (ME) aus den Historienlisten (HL1, HL2) der alten und der neuen Programmversion ein Skript (S) zur Änderung der Datenbankschemata (DS1) und Einträge (DE1) gebildet wird und - bei dem die alte Datenbank (DB1) mit Hilfe des Skripts (S) zur neuen Datenbank (DB2) migriert wird, wobei die alten Datenbankeinträge (DE1) in neue Datenbankeinträge (DE2) und/oder die alten Datenschemata (DS1) in neue Datenbanksche- mata (DS2) umgewandelt werden. 2. Verfahren nach Anspruch 1, - bei dem durch Vergleich der Historieneinträge (HE2) in der Historienliste (HL2) eines jeweiligen Modells (M2) der neuen Programmversion und der Historieneinträge (HEI) in der Histo¬ rienliste (HL1) eines jeweiligen Modells (Ml) der alten Programmversion ein Einstiegszeitpunkt bestimmt wird, - bei dem eine Liste aller relevanten Historieneinträge (HEI, HE2) für alle betroffenen Metamodelle erzeugt wird und aus den darin enthaltenen jeweilige Historieneinträgen jeweilige Objekte einer Programmiersprache erzeugt werden die dann an einen jeweiligen Handler übergeben werden, wobei der jeweilige Handler dann das Persistenzschema für eine objektrelatio¬ nale Abbildung entsprechend ändert und einen jeweiligen SQL- Code zur Änderung der Datenbankschemata und Datenbankeinträge erzeugt, und - bei dem der SQL-Code von allen Handlern entsprechend der zeitlichen Reihenfolge der Historieneinträge in einem SQL- Skript gesammelt wird und nach Abarbeitung aller Objekte für Historieneinträge ein vollständiges SQL-Skript S ausgegeben wird . 3. Verfahren nach Anspruch 1 oder 2, bei dem beim Sammeln der SQL-Codes von allen Handlern auch eine Kommentierung mit Hinweisen auf das Metamodell dessen Änderung die Ursache war erfolgt. 4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Daten der alten Datenbank (DB1) dadurch auf die neue Datenbank (DB2) migriert werden, dass mit Hilfe des SQL- Scripts (S) das Persistenzschema der alten Datenbank (DB1) geändert wird. 5. Verfahren nach Anspruch 4, bei dem anschließend kann die Migration dadurch validiert wird, dass das veränderte Persistenzschema mit den Datenbank- Schemata (DS2) der neuen Datenbank (DB2) verglichen wird. 6. Vorrichtung zur Durchführung eines der vorhergehenden Verfahren, - bei der eine Einrichtung zum Zugriff auf Metamodell- Container (Ml, HL1, M2, HL2) der alten und der neuen Programmversion vorhanden ist, - bei der eine Einrichtung zur Bestimmung eines Einstiegszeitpunkts derart vorhanden ist, dass durch Vergleich der Historieneinträge (HE2) in der Historienliste (HL2) eines je¬ weiligen Modells (M2) der neuen Programmversion und der Historieneinträge (HEI) in der Historienliste (HL1) eines jewei¬ ligen Modells (Ml) der alten Programmversion ein Einstiegs- Zeitpunkt bestimmt wird, - bei der Einrichtung zur Erzeugung von SQL-Code derart vorhanden ist, dass eine Liste aller relevanten Historieneinträ¬ ge (HEI, HE2) für alle betroffenen Metamodelle erzeugt wird und aus den darin enthaltenen jeweilige Historieneinträgen jeweilige Objekte einer Programmiersprache erzeugt werden die dann an einen jeweiligen Handler übergeben werden, wobei der jeweilige Handler dann das Persistenzschema für eine objekt¬ relationale Abbildung entsprechend ändert und einen jeweili¬ gen SQL-Code zur Änderung der Datenbankschemata (DS1) und Da- tenbankeinträge (DE1) erzeugt, und - bei dem eine Einrichtung zum Sammeln von SQL-Code derart vorhanden ist, dass der SQL-Code von allen Handlern entsprechend der zeitlichen Reihenfolge der Historieneinträge in ei¬ nem SQL-Skript gesammelt wird und nach Abarbeitung aller Ob- jekte für Historieneinträge ein vollständiges SQL-Skript S ausgegeben wird. |
Verfahren zur modellbasierten Softwareentwicklung von Programmen mit Datenbankzugriff
Die Erfindung betrifft ein Verfahren zu Softwareentwicklung, bei dem verschiedene Programmversionen unterschiedliche
Persistenzschemata aufweisen und somit auch eine Datenbank- Migration erfordern.
Eine typische Situation besteht beispielsweise darin, dass ein Anwender eine alte Version eines Softwaresystems mit Da ¬ tenbank einsetzt und eine neue Version des Softwaresystems mit Datenbank erstellt wurde, bei der sich vom Anwender ge- speicherte Datentypen und Datenstrukturen ändern. Der Anwender möchte die neue Version des Softwaresystems verwenden und dabei seine bereits gespeicherten Daten weiter verwenden.
In diesem Fall reicht es nicht aus, dass der Anwender die neue Version installiert, sondern er muss seine alte
Datenbank migrieren, damit die neue Software mit den bereits gespeicherten Daten ablaufen kann. Dies beinhaltet zwei
Schritte: es müssen die Datenbankschemata geändert werden und es müssen die Datenbankeintrage in Form der neuen Schemata abgespeichert werden.
Dieses Problem wurde bisher so gelöst, dass von Hand ein SQL- Skript erstellt wurde. Dieses Skript enthielt Anweisungen, um die neuen Schemata zu erstellen. Weiterhin enthielt dieses Skript für jeden Datenbankeintrag, dessen Datentyp geändert wurde, SQL-Anweisungen, die ihn durch einen Eintrag des neuen Datentyps unter Übernahme der Werte aus dem alten Datenbank ¬ eintrag ersetzen. Die der Erfindung zu Grunde liegende Aufgabe besteht nun da ¬ rin, ein Verfahren zur modellbasierten Softwareentwicklung von Programmen mit Datenbankzugriff anzugeben, bei dem eine möglichst einfache und sichere Datenbank-Migration ermöglicht wird .
Diese Aufgabe wird durch die Merkmale des Patentanspruchs 1 erfindungsgemäß gelöst. Die weiteren Ansprüche betreffen be ¬ vorzugte Ausgestaltungen der Erfindung und eine Vorrichtung zur Durchführung des Verfahrens.
Die Erfindung betrifft im Wesentlichen ein Verfahren zur mo- dellbasierten Softwareentwicklung von Programmen mit Datenbankzugriff, bei dem gleichzeitig mit der Erzeugung oder Änderung von Metamodellen Einträge in eine Historienliste gene ¬ riert werden und diese dann zur automatischen Erzeugung eines SQL-Skriptes verwendet werden, das eine validierte Migration vom alten zum neuen Schema sowie eine Migration aller Daten erlaubt. Der Vorteil besteht darin, dass Aufwand gespart wird und Qualität durch automatisches Validieren und Testen gewon ¬ nen wird. Nachfolgend wird die Erfindung anhand eines in der Zeichnung dargestellten Ausführungsbeispiels näher erläutert.
In der modellgetriebenen Softwareentwicklung werden domänenspezifische Sprachen verwendet, um Klassen im Sinne objekt- orientierter Programmierung mit Metamodellen programmiersprachenunabhängig zu beschreiben.
In der Zeichnung ist eine Anordnung mit einem Editor ED, der sowohl ein jeweiliges Metamodell Ml, M2 erzeugt/löscht oder ändert als auch eine jeweilige Historienliste HL1 , HL2 mit diesen Änderungen erzeugt/löscht oder ändert, einem Generator KG, der aus dem jeweiligen Modell jeweilige Datentypen DT1 , DT2 erzeugt, einer jeweiligen Datenbank DB1 , DB2, bei der diese Datentypen über jeweilige Datenbankschemata DS1, DS2 auf jeweilige Datenbankeinträge DE1 , DE2 abgebildet werden, und einer Migrationsmaschine (Migration Engine) ME, die aus Einträgen HEI, HE2 der jeweiligen Historienlisten HL1 , HL2 ein Skript S zur Änderung der jeweiligen Datenbankschemata und jeweiligen Datenbankeinträge bildet, gezeigt.
Die jeweiligen Metamodelle Ml einer alten Programmversion werden zusammen mit den Historieneinträgen HEI als Attribut in einem Container verwaltet und die Metamodelle M2 einer neuen Programmversion werden zusammen mit Historieneinträgen HE2 als Attribut in einem weiteren Container verwaltet. Bei Erzeugung, Änderung, Löschung eines Metamodells wird au ¬ tomatisch auch ein Eintrag HEI, HE2 in dieser Historienliste HL1 , HL2 erzeugt. Dieser Eintrag enthält alle Informationen, die notwendig sind, um ein entsprechendes Datenbankschema
DS1, DS2 zu erzeugen, zu ändern oder zu löschen, wie z.B. den Namen und den Datentyp eines neu zu einem Metamodell hinzuge ¬ fügten Attributes. Ein Historieneintrag ist selbst auch als Metamodell modelliert.
Mit Hilfe des programmierten Generators KG werden aus den Me- tamodellen Programmiersprachenkonstrukte, z.B. Java Klassen, erzeugt, die typischerweise die Eigenschaften von Objekten definieren .
Für die Abbildung von Objekten in eine relationale Datenbank wird ein Framework für objektrelationales Mapping (ORM) verwendet. Typischerweise bieten die Datenbank-Hersteller dort eigene Implementierungen an, es gibt aber auch Open-Source Persistenzprovider . Der Open-Source Persistenzprovider „Hibernate" ermöglicht z. B., gewöhnliche Objekte mit Attri- buten und Methoden in relationalen Datenbanken zu speichern und aus entsprechenden Datensätzen wiederum Objekte zu erzeugen. Beziehungen zwischen Objekten werden dabei auf entsprechende Datenbank-Relationen abgebildet. Die Migrationsmaschine ME arbeitet wie folgt:
Sie hat Zugriff auf den Metamodell-Container des alten Systems und auf den des neuen Systems. Durch Vergleich der Historieneinträge in der Historienliste HL2 für ein Metamodell M2 im neuen System und der Historieneinträge in der Historienliste HL1 für ein Metamodell Ml im alten bzw. ursprünglichen System wird ein Einstiegszeitpunkt (entry point) bestimmt. Dies ist der Zeitpunkt, ab dem die Historieneinträge im neuen System berücksichtigt werden müs ¬ sen . Es wird eine Liste aller relevanten Historieneinträge für al ¬ le betroffenen Metamodelle, bspw. die Modelle Ml und M2, er ¬ zeugt. Aus diesen Historieneinträgen HEI und HE2, die ja Instanzen eines Metamodells „Historieneintrag" sind, werden entsprechende Objekte einer Programmiersprache, z.B. Java, erzeugt. Alle diese Javaobjekte zusammen bilden eine
Persistenzhistorie ab, die auf der alten bzw. ursprünglichen Datenbank ausgeführt werden muss, wobei eine
Persistenzhistorie allgemein beschreibt wie die Daten oder Objekte in nichtflüchtigen Speichermedien, wie Dateisystemen oder Datenbanken, gespeichert wurden und werden.
Je nach Art des Historieneintrags, z. B. „add attribute", „remove attribute" usw., wird ein entsprechendes Javaobjekt für einen Historieneintrag an einen spezifischen Handler übergeben. Dieser ändert dann das Persistenzschema, z.B. für „Hibernate", entsprechend und erzeugt SQL-Code, der notwendig ist, um erforderliche Datenbankschemaänderungen vorzunehmen und Datenbankeinträge zu ändern. Als „Handler" (Handhaber) wird üblicherweise eine asynchrone Rückruffunktion verstan- den, die einer anderen Funktion als Parameter übergeben und von dieser unter gewissen Bedingungen aufgerufen wird.
In der Migrationsmaschine ME wird der SQL-Code von allen Handlern entsprechend der zeitlichen Reihenfolge der Histo- rieneinträge in einem SQL-Skript gesammelt und optional auch kommentiert mit Hinweisen auf das Metamodell, dessen Änderung die Ursache war. Nach Abarbeitung aller Objekte für Histo- rieneinträge gibt die Migrationsmaschine ME das vollständige SQL-Skript S aus.
Dieses SQL-Skript S kann nun auf die alte Datenbank angewen ¬ det werden um sie auf die neue Version des Systems zu migrie ren .
Anschließend kann optional die Migration validiert werden, dadurch dass das Persistenzschema des neuen Systems mit den Datenbankschemata der neuen Datenbank auf Übereinstimmung verglichen wird.