EP1920357A1 - Migration und transformation von datenstrukturen - Google Patents

Migration und transformation von datenstrukturen

Info

Publication number
EP1920357A1
EP1920357A1 EP05784106A EP05784106A EP1920357A1 EP 1920357 A1 EP1920357 A1 EP 1920357A1 EP 05784106 A EP05784106 A EP 05784106A EP 05784106 A EP05784106 A EP 05784106A EP 1920357 A1 EP1920357 A1 EP 1920357A1
Authority
EP
European Patent Office
Prior art keywords
format
functional unit
data structure
filter
source
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05784106A
Other languages
English (en)
French (fr)
Inventor
Veit Florian Lier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LIER, VEIT FLORIAN
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of EP1920357A1 publication Critical patent/EP1920357A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion
    • G06F16/88—Mark-up to mark-up conversion

Definitions

  • the invention relates to a functional unit, a system, a description frame, a method for transforming a data structure, a computer program and a computer program product.
  • the functional unit according to the invention is suitable for the migration and transformation of data structures of at least one source system into data structures of at least one target system.
  • the functional unit is designed for coupling between at least one source system and at least one target system.
  • the at least one import filter is designed to transform a data structure present in a source-system-dependent format into an overall description format.
  • the at least one export filter is designed to transform the data structure present in the comprehensive description format into a target system-dependent format.
  • IT systems provide a way to store data in database systems.
  • the structure of these storage systems i. for example, the name of the tables as well as the names and specifications of these fields, such as type number, type date, etc., are commonly referred to as "data structure”.
  • data structure refers to the structure of a considered IT system, i. on the source or the target system, respectively their respective design. Accordingly, the term “data structure” encompasses not only a definition of used storage media but also a correspondingly used processing program logic as well as available input and display interfaces, a so-called user frontend and administrative design elements.
  • the core of the present invention is the migration and transformation of the design of IT systems, ie the design of the source system and the design of the target system, between different platforms and not just lent the migration of the data contained in the respective systems.
  • Data structure in the context of the present invention focuses on the structure of the design, which may also contain data in the true sense, but this need not.
  • the functional unit according to the invention can have an import filter for each source system and an export filter for each target system.
  • this is decomposed into structure elements.
  • These structural elements are checked and / or identified and then compared with structural elements stored in a configuration table. This is called “parsing" (English, for analyzing) the data structure.
  • a so-called DOM parser Document Object Model
  • New structure elements can be included in the configuration table.
  • the functional unit can expand continuously.
  • Structural elements which are classified as unidentifiable but are present in the data structure can be included in a protocol provided for such structural elements and, if necessary, analyzed and transformed by an administrator unit in an additional step.
  • a source-system-dependent or source-system-compliant structure element can be imported into a structure element of the overall description format via the import filter and then exported to a target system via the export filter. pending or target system compliant structural element are translated.
  • the comprehensive description format can also be referred to as an intersystem description format between two systems, that is, between the at least one source system and the at least one target system.
  • the comprehensive description format is to be understood as an auxiliary format, via which a transformation and migration between the source-system-dependent format and the target-system-dependent format is made possible.
  • the overall description format can therefore be regarded as a general or higher-level format under source-system-dependent and target-system-dependent formats.
  • the functional unit is in particular designed to perform at least one step of the inventive method presented below.
  • the present invention relates to a transformation system having the features of patent claim 8.
  • This transformation system is provided for the migration and transformation of data structures of at least one source system into data structures of at least one target system.
  • the transformation system has at least one source system, at least one destination system and a functional unit coupled between the at least one source system and the at least one destination system, wherein the functional unit has at least one import filter and at least one export filter.
  • the at least one import filter is designed to provide a source code that is provided by the source system.
  • the at least one export filter is designed to transform the data structure present in the overall description format into a target system-dependent format and to provide it to the target system.
  • the present invention also encompasses a description framework, a so-called framework, having the features of patent claim 9.
  • the inventive description frame is suitable for transforming and migrating a data structure of at least one source system into at least one destination system and is adapted to provide one provided by the at least one source system to represent in a source system dependent format present and transformed via at least one import filter data structure in a comprehensive description format, and to transform the data structure shown in the overall description format via at least one export filter in a target system dependent format.
  • the inventive method further provided for the migration and transformation of a data structure of at least one source system in at least one target system.
  • the data structure provided by the at least one source system and present in a source-system-dependent format is transformed via at least one import filter into a data structure which is present in an overall description format.
  • the data structure present in the overall description format is converted to at least one export filter in a format dependent on a target system present data structure transformed and provided to the at least one target system.
  • the at least one import filter and the at least one export filter are each derived from a source code by the processing frame according to the invention.
  • This source code can be generated from structural information stored in a configuration table or a configuration file.
  • the computer program with program code means according to the invention is suitable for carrying out all the steps of the method according to the invention when the computer program is executed on a computer or a corresponding arithmetic unit, in particular in the functional unit according to the invention.
  • the computer program product according to the invention with program code means which are stored on a computer-readable data carrier is designed to perform all steps of the method according to the invention when the computer program is carried out on a computer or a corresponding computing unit, in particular in the functional unit according to the invention.
  • the present invention provides a preferably software-based mutual migration solution and Transformation of data structures, such as various database systems or various computer applications on various development platforms ready.
  • the data structures are based, for example, on the XML format (Extensible Markup Language).
  • XML format Extensible Markup Language
  • a migration and transformation of database systems and computer applications across various development platforms based on XML is made possible by means of the present invention. Any other suitable format in addition to the XML format is also conceivable.
  • D 2 D-squared
  • D 2 objects The data structures presented in the general description format are referred to below as D 2 objects.
  • this data structure can be transformed again via at least one preferably dedicated export filter into a valid and compliant manufacturer-specific and system-dependent XML format for the at least one target system, so that the representation of the processing logic and the design elements are now available in a target-system-specific XML format.
  • All EDP systems can be supported, which allow a representation of their design in XML or XML dialects, such as Lotus Domino, MS Office 2003, .Net, etc., enable.
  • the description frame according to the invention referred to below as the D 2 framework, which is integrated in the functional unit, is based on a programming-language-independent and self-learning procedure for the interpretation and migration of data structures.
  • the data structures can be applications.
  • Translatable structure elements of the source-system-dependent data structure or corresponding design elements such as program code elements are identified as "positive” and do not present any problems in the context of a planned conversion.
  • non-translatable structure elements are identified as "negative” and into a for written such negative structural elements protocol provided.
  • This protocol can be edited by additional measures so that a suitable translation is provided for negatively identified structural elements and this translation is included in the configuration table for the future. If this protocol is evaluated with time and / or material costs, realistic estimates can be made for the planned changes via their aggregations.
  • the newly created data structure or application can be tested for functionality and evaluated. If no problems occurred during the migration, the source system-dependent data structure can be removed. If previously unknown code elements in the source system have been identified during the migration, these are logged in the protocol (D 2 - Log) of the functional unit. These unknown code elements or structural elements identified as "negative” can be revised and / or commented out in an evaluation of the protocol, so that a suitable translation can be assigned to these code elements or structural elements within the framework of the comprehensive description format. Now it is possible to extend the existing import and export filters and to achieve a more complete and therefore better result in another migration pass. In this way, complex migration projects can be processed in a modular and application-specific manner and automatically completed on a key date.
  • the corresponding inverse import filter is used to export the data structure. If, for example, an import filter is used for the transformation of a data structure from MS Word to D 2 , then the corresponding inverse import filter conversely serves as the export filter for the transformation from D 2 to MS Word. To do this, the import and export filters must be configured inversely to each other. Accordingly, in a preferred embodiment with an import filter and a corresponding export filter, a bidirectional transformation of a data structure which is present in a specific format dependent on a first system can be included in the general or general writing format and vice versa. This particular first system can be operated both as a source system by the import filter and as a target system by the corresponding export filter.
  • the transformation of the data structure takes place in two steps.
  • the data structure that exists in the source system-dependent format is transformed by the import filter by analysis, identification and assignment of structural elements in the overall description format.
  • This import filter can itself generate from the transferred data structure and the information that can be specified in a configuration system by processing, modifying and supplementing structural elements.
  • This import filter is thus a so-called self-learning code.
  • the information about the data structure present in the now comprehensive description format is temporarily stored in the overarching description frame of the functional unit.
  • a storage can in this case in a hierarchical class model or class System successes gen r wherein this class model is transferred to the base in the transformation or migration from the at least one source system reaped structural elements or a corresponding data structure.
  • the data structure present in the general description format can be transferred in a second step by analysis, identification and assignment of structural elements in any target system or platform for which the export filter is deposited.
  • the export filter identifies the structural elements stored in the description frame, for example litter or design elements or code blocks, and converts them into that target system-dependent format that can be interpreted by the target system. Unknown or non-existent structural elements within the target system are logged in this process for documentation purposes and carried along, these structural elements can be subsequently commented out and edited by an administrator unit and in particular translated manually.
  • computer systems can be transferred via an intermediate step of the comprehensive description frame with storage in the overall description format from a first platform or the source system to any other supported second platform or the target system.
  • the functional unit can be used, for example, to estimate the expected costs for an IT system conversion or to provide an overview of the code quality of the applications considered.
  • the functional unit according to the invention or the comprehensive description frame it is thus possible to analyze an IT infrastructure and to estimate how many percent of the data structures or applications associated with this IT infrastructure are simple, difficult or even impossible to migrate , If the results obtained from the protocol are brought into a so-called normal form, in which every unknown element is contained only once more, so that the results are clearly presented, a simple effort estimate can be derived about what a conversion to To devour resources and costs. If this estimation seems appropriate and acceptable to a user, the conversion of the original system, ie the source system, for example by replacing Word forms or Excel spreadsheets, can take place automatically via the comprehensive description frame or the functional unit.
  • a global filter or a transformation filter of the functional unit according to the invention which includes the import filter and the export filter, it is possible to develop a new platform or the target system in two steps.
  • an import filter can be created from the source system-dependent data structure or application in the overall description format.
  • a corresponding export filter for the target system-dependent data structure can be generated.
  • the processing frame from structural information which are stored in configuration tables for the respective data structures, each generates a source code from such source codes can then be derived the import and export filters. If both filters are present, this source system is integrated into the overall description frame and can be used at any time.
  • the functional unit according to the invention makes it possible to lift existing applications onto a new platform or to transform them into the target system, thereby providing a much simpler and faster conversion process.
  • the functional unit according to the invention can cover a much wider range of platforms or systems, ie source and target systems, since this is based on dynamic import filters and export filters.
  • the functional unit analyzes a recorded code and, if necessary, extends the stored configuration table.
  • This configuration table can be checked and modified by an administrator, so that the user can customize the functional unit to his needs, whereby this user decides which options are offered to him with the functional unit. Possibly occurring during the transformation or a translation of the code or a design errors are merely configuration problems and can be subsequently adapted without an update of the software support make the functional unit mandatory.
  • the user is thus able to analyze his existing infrastructure and deduce therefrom a cost estimate for the transformation and to focus on identifying obstacles.
  • the user is provided a wider range of functionality.
  • the functional unit according to the invention as well as the overarching description frame according to the invention as part of the functional unit offer the possibility of developing a global storage possibility of data structures which are present in any formats, in particular XML formats.
  • the hierarchical and possibly generalized class model may be provided in this case.
  • a number of translation filters necessary for the transformation can be considerably reduced with the functional unit or the comprehensive description frame. For example, assuming six different platforms or systems, a total of 30 transformation filters are needed for these six platforms, as each system translates into five other systems.
  • the functional unit according to the invention as a global container, which comprises the import and export filters and using the general description format, a number of the required transformation filters is reduced to two per system or platform used. Therefore, you only need one import filter and one export filter per system. Assuming a total of six platforms or systems, this functional unit has only 12 transformation filters. ter, ie six import filters and six export filters.
  • the functional unit is self-learning in that the functional unit includes new structural elements in a configuration table and independently extended programming interfaces (D 2 -API) and adapted to new conditions. Accordingly, the functional unit can automatically adapt the resulting changes to new versions of source or target data from corresponding source or target systems.
  • D 2 -API independently extended programming interfaces
  • the functional unit allows the data structure, ie a file or application, to be opened in a source-system-dependent format, for example in an XML format, and transfers the structural elements contained therein into a target system-dependent data structure and imports them automatically. Structural elements that can not be translated without error are marked accordingly and displayed in the log.
  • the user of the functional unit can derive from this protocol what and to what extent corrections have to be made before this part or application exactly meets the requirements that the original file or application had. All activities of the functional unit can be sorted, displayed and evaluated by application, user, date or type of individual steps performed in a report.
  • a user front-end or programming front-end that is used for interactive request, input, and display of data which can also be referred to as a user interface, is based on the specifications of a design study for Creation of an intuitive frontend and implements this technically possible.
  • the functional unit according to the invention is particularly suitable for users or companies that are considering an orientation in a field of computer-supported collaboration ("CSCW") or groupware.
  • CSCW computer-supported collaboration
  • a competitive situation prevailing in this market lends itself to the application of the functional unit and of the method.
  • the functional unit is suitable for companies that have a high need for support through largely automated IT tools.
  • the functional unit provides these companies with the opportunity to rethink their IT strategy against the backdrop of currently used systems, in this case source systems, and, if necessary, to improve them by converting or transforming them to more modern, more powerful systems, ie target systems.
  • the description frame according to the invention of the functional unit can be designed such that requirements of the standard "DIN EN ISO 9241 Part 10" can be taken into account in the area of a design of the user front-end and implemented as far as possible. Due to technical conditions, the following aspects can be emphasized:
  • the XML format can be used in an innovative manner with the functional unit.
  • XML was used as a data exchange format between IT systems, e.g. Web services thought.
  • the XML format can be used innovatively by using XML import and export options for replacing or setting up systems.
  • a migration is imminent, there are two options for the IT department or departments concerned: either a) a manual migration, which usually will be very time-consuming, or b) a tool-driven migration with subsequent manual check and correction. Since the aspect of quality assurance occurs in both cases, it can be neglected in a rating. If more than about 20 data structures are to be transformed as part of the IT changeover, it is advisable, from a mathematical point of view, to use the functional unit or the method according to the invention.
  • FIG. 1 shows a schematic representation of a preferred embodiment of a transformation system according to the invention.
  • FIG. 2 shows a schematic illustration of a preferred embodiment of a plane model of a functional unit according to the invention.
  • FIG. 3 shows a phase model for carrying out individual steps of a preferred embodiment of a method according to the invention.
  • Figure 4 shows a schematic representation of a preferred embodiment of a description frame according to the invention.
  • the transformation system 1 shown schematically in FIG. 1 in a preferred embodiment comprises a functional unit 3 which has at least one import filter 5, at least one export filter 7 and at least one programming interface 9 (API).
  • the functional unit 3 or the at least one export filter 7 and the at least one import filter 5 have access to various objects 11, such as tables required for transformation, in particular configuration tables or definition tables, as well as protocols.
  • a transformation and / or migration is intended with the functional unit 3 as well as with the executable by the functional unit 3 method feasible.
  • the data structure present in the source-system-dependent format 17 and provided by the source system 13 is transformed via the import filter 5 into a data structure present in an overall description format 18 and stored in the functional unit 3.
  • the data structure present in the overall descriptive format 18 is transformed via the export filter 7 into the data structure present in the target system-dependent format 19 and thus provided to the target system 15.
  • the functional unit 3 is therefore a platform and the method is a procedure for an automated transformation or migration of EDP systems via or between different platforms.
  • FIG. 2 shows a schematic representation of the procedure for an interpretation and migration of data structures or applications.
  • the basis of a description frame of the functional unit of FIG. 1 is the plane model illustrated in FIG. 2, which is designed to carry out the transformation 21 of data structures, and which has a computer application embedded in a display plane 23, a processing plane 25 with at least a global filter or a corresponding transformation filter, which has at least one import filter 24 and at least one export filter 26, and a data plane 27, which comprises the general description format 28.
  • the source system-dependent XML representation of the corresponding data structure or a source application from the source system is transferred to the overall description format 28 (D 2 format).
  • the data structure can be converted from the representation via the export filter 26 into a form for a the target system or a target platform can be transferred to an understandable target system-dependent XML representation.
  • the functional unit is adapted by constant updating to a high dynamics in the IT environment, thus new versions of a software or new design elements and thus also new XML structures can be transformed.
  • FIG. 3 shows a phase model corresponding to a process of transformation in a preferred embodiment of the method.
  • the method essentially comprises four phases or steps, namely an analysis 29, an extension 31 or an upgrade, a design 33 or a design and a transformation 35.
  • a provided source-system-dependent XML file is, for example, broken down into its structural elements or elements by means of a standard XML parser (DOM parser) in the phase of the analysis 29.
  • DOM parser a standard XML parser
  • Each identified feature or attribute, such as an XML node, and each XML attribute is compared against a configuration table.
  • the result of this check can have one of the following characteristics: a) The structure element is not yet included in the configuration table of the functional unit. b) The structural element is already included in the configuration table and in this neither as positive, ie known and translatable, nor negative, ie known and untranslatable, marked or identified.
  • the import filter logs that it is an undefined structure element, this structure element is included in a protocol provided for this purpose, so that it can be edited individually. If the structure element is contained in the configuration or definition table and marked as known and interpretable (case c), then this structure element is included in the description frame or a D 2 structure of the import filter. If the structure element has been identified as known but not translatable (case d), the import filter eliminates an associated node, in particular an XML node.
  • this point is taken up by the reference filter or a D 2 structure of the import filter.
  • Negative structural elements that are stored in the protocol provided for this purpose can be assigned an appropriate translation by an administrator.
  • the extension 31 is provided in the next phase. If the import filter encounters structures or structure elements that are not yet known to it, they are included in the configuration tables as described above. Based on the now changed configuration table, an object model of the description frame or the functional unit expands around the added structure elements and remembers these for the future. This automatically generates new object classes and integrates them into already integrated structure or code elements.
  • the source system-dependent data structure or a source file in the process step provided as draft 33 becomes a hierarchical class model based on the at least one transformation or migration Source system imported structural elements or Data structure transferred and a processing platform (D 2 platform) of the processing framework provided.
  • D 2 platform processing platform
  • the information contained in the overall description format or stored in a D 2 structure is validated against the export filter and logged as part of the transformation 35.
  • the export filter transfers the information stored in the overall description format or D 2 format into a data structure that conforms to the target system, in particular an XML file, on the basis of the new assignments and / or translation rules stored in the import and export filters.
  • An extension of the configuration table improves the import filter and export filter over time. If required, the import filter independently extends the general description format to dynamically adapt it to new situations. If new structural proposals are accepted by an administrator, they are permanently available for the future.
  • Figure 4 shows a schematic representation of the description frame 37 of the functional unit with a programming or user frontend 39, the import filter 41, the export filter 43, a class library 45, a base library 47 and a configuration table 49, the the arrows are displayed interacting by exchanging data, information and structural elements.
  • the processing framework 37 (D 2 framework) follows an object-oriented programming paradigm and uses the properties of inheritance in common programming languages through the use of classes.
  • the description frame 37 is - as far as an integration of code resources in the selected programming language is possible - language-independent.
  • DD_Base global objects can be defined and global functions can be made available. These are available in the system-dependent classes derived from the base class and use these for standard functions. From the structure information stored in the configuration table 49, the processing frame 37 automatically generates a source code for the manufacturer-specific and / or system-dependent data structure.
  • Import filter 41 and export filter 43 are then derived from this source code, which perform a corresponding transformation of data structures between different formats via the API interface stored in the class libraries 45.
  • these import filters 41 and export filters 43 Via the corresponding user front-end 39 in a selected platform, such as, for example, "Domino. Designer” in “Lotus Domino” or “Visual Studio” in “.Net Applications”, these import filters 41 and export filters 43 be addressed and adapted via the appropriately stored programming interface (API).
  • API appropriately stored programming interface
  • the base library 47 represents a base class on which all other classes build. It provides basic functions for interpreting XML files and transferring them to a class model.
  • the functional unit contains the cross-class objects required for further processing, such as a structure tree or basic XML node.
  • the XML elements identified in a base library 47 are - if not yet present - included in the configuration table 49, which serves to define the structure elements. Depending on the format, for example, "Lotus Domino", “MS Word”, etc., this creates a separate structure tree dynamically for each analyzed system or platform.
  • the functional unit and the programming interface (API) are dynamically generated from the information stored in the configuration table 49, by means of which the information stored in the D 2 structure can be displayed.
  • API programming interface
  • XML node XML node
  • class libraries 45 are generated in different programming languages and written as resources in a defined repository.
  • the import filters 41 and export filters 43 used in the method by the functional unit access and inherit the class libraries 45 from these properties and methods.
  • these functions are used to write the information from the XML file into the functional unit.
  • the information stored in the functional unit is passed to the corresponding class library 45 and rendered in a valid XML format.
  • Unknown or known, but not translatable structural elements and / or code elements are hereby recorded in protocols and thus commented out mitre. Such structural elements must and / or can be reworked manually in the target system if necessary. If there is a need to intervene in the transformation process via program code, which includes, for example, setting update information or creating technical documentation, this takes place in the selected language via the integrated programming interface (API).
  • API integrated programming interface

Abstract

Die erfindungsgemässe Funktionseinheit (1) zur Migration und Transformation von Datenstrukturen mindestens eines Quellsystems (13) in Datenstrukturen mindestens eines Zielsystems (15) weist mindestens einen Import-Filter (5) und mindestens einen Export-Filter (7) auf. Dabei ist der mindestens eine Import-Filter (5) dazu ausgebildet, eine von dem Quellsystem (13) bereitgestellte, in einem quellsystemabhängigen Format (17) vorliegende Datenstruktur in ein übergreifendes Beschreibungsformat (18) zu transformieren, der mindestens eine Export-Filter (7) ist dazu ausgebildet, die in dem übergreifenden Beschreibungsformat (18) vorliegende Datenstruktur in ein zielsystemabhängiges Format (19) zu transformieren und dem Zielsystem (15) bereitzustellen.

Description

MIGRATION ITND TRANSFORMATION VON DATENSTRUKTUREN
Die Erfindung betrifft eine Funktionseinheit, ein System, einen Beschreibungsrahmen, ein Verfahren zur Transformation einer Datenstruktur, ein Computerprogramm und ein Computerprogrammprodukt .
Zur Migration oder Transformation von Gestaltungen von IT- bzw. Datenbanksystemen zwischen verschiedenen Plattformen sind unterschiedliche übersetzende Verfahren bekannt. Bei derartigen Migrationen werden jedoch lediglich Daten transformiert. Anwendungen, die die Daten enthalten, respektive deren Struktur und Gestaltung werden hierbei nicht berücksichtigt. Deshalb ist eine Umstellung von existierenden Infrastrukturen bislang zu aufwendig.
Vor diesem Hintergrund wird eine Funktionseinheit mit den Merkmalen des Patentanspruchs 1, ein System mit den Merkmalen des Patentanspruchs 8, ein Beschreibungsrahmen mit den Merkmalen des Patentanspruchs 9, ein Verfahren mit den Merkmalen des Patentanspruchs 10, ein Computerprogramm mit den Merkmalen des Patentanspruchs 20 und ein Computerprogrammprodukt mit den Merkmalen des Patentanspruchs 21 vorgeschlagen .
Die erfindungsgemäße Funktionseinheit ist zur Migration und Transformation von Datenstrukturen mindestens eines Quellsystems in Datenstrukturen mindestens eines Zielsystems ge- eignet und weist mindestens einen Import-Filter und mindestens einen Export-Filter auf. Die Funktionseinheit ist zur Kopplung zwischen mindestens einem Quellsystem und mindestens einem Zielsystem ausgebildet. Dabei ist der mindestens eine Import-Filter dazu ausgebildet, eine in einem quell- systemabhängigen Format vorliegende Datenstruktur in ein übergreifendes Beschreibungsformat zu transformieren. Der mindestens eine Export-Filter ist dabei dazu ausgebildet, die in dem übergreifenden Beschreibungsformat vorliegende Datenstruktur in ein zielsystemabhängiges Format zu transformieren.
Allgemein bieten IT-Systeme eine Möglichkeit Daten in Datenbanksystemen zu speichern. Der Aufbau dieser Speicherungssysteme, d.h. bspw. der Name der Tabellen sowie die Namen und Spezifikation dieser Felder, wie etwa Typ Zahl, Typ Datum, usw. wird allgemein als "Datenstruktur" bezeichnet .
Im Rahmen der vorliegenden Erfindung bezieht sich der Begriff "Datenstruktur" jedoch auf die Struktur eines betrachteten IT-Systems, d.h. auf das Quell- bzw. das Zielsystem, respektive deren jeweiligen Gestaltung. Demnach umfasst der Begriff "Datenstruktur" nicht nur eine Definition verwendeter Speichermedien sondern auch eine entsprechend eingesetzte verarbeitende Programmlogik sowie zur Verfügung stehende Eingabe- und Anzeigeoberflächen, ein sog. Benutzer- frontend und administrative Gestaltungselemente.
Der Kern der vorliegenden Erfindung ist die Migration und Transformation der Gestaltung von IT-Systemen, d.h. der Gestaltung des Quellsystems und der Gestaltung des Zielsystems, zwischen verschiedenen Plattformen und nicht ledig- lieh die Migration der in den jeweiligen Systemen enthaltenen Daten.
"Datenstruktur" im Kontext der vorliegenden Erfindung setzt den Fokus auf die Struktur der Gestaltung, welche auch Daten im eigentlichen Sinne enthalten kann, dies aber nicht muss .
Die erfindungsgemäße Funktionseinheit kann für jeweils ein Quellsystem einen Import-Filter und für jeweils ein Zielsystem einen Export-Filter aufweisen. Bei einer Analyse der im quellsystemabhängigen Format vorliegenden Datenstruktur wird diese in Strukturelemente zerlegt. Diese Strukturelemente werden überprüft und/oder identifiziert und dann mit in einer Konfigurationstabelle hinterlegten Strukturelementen verglichen. Man spricht dabei von "Parsen" (engl, für analysieren) der Datenstruktur. Ein sog. DOM-Parser (Docu- ment Object Model) kann dazu verwendet werden, eine Datenstruktur in Strukturelemente zu zerlegen und in einem sog. Syntaxbaum zur weiteren Verarbeitung bereitzustellen. Neue Strukturelemente können in die Konfigurationstabelle aufgenommen werden. Somit kann sich die Funktionseinheit fortlaufend erweitern.
Strukturelemente, die als nicht identifizierbar eingestuft sind, aber in der Datenstruktur vorhanden sind, können in ein für derartige Strukturelemente vorgesehenes Protokoll aufgenommen und in einem zusätzlichen Schritt ggf. durch eine Administratoreinheit analysiert und transformiert werden. Ein quellsystemabhängiges oder quellsystemkonformes Strukturelement kann über den Import-Filter in ein Strukturelement des übergreifenden Beschreibungsformats und ausgehend hiervon über den Export-Filter in ein zielsystemab- hängiges oder zielsystemkonformes Strukturelement übersetzt werden.
Das übergreifende Beschreibungsformat kann auch als ein zwischen zwei Systemen, also zwischen dem mindestens einen Quellsystem und dem mindestens einen Zielsystem stehendes, intersystemisches Beschreibungsformat bezeichnet werden. Das übergreifende Beschreibungsformat ist als Hilfsformat zu verstehen, über das eine Transformation und Migration zwischen dem quellsystemabhängigen Format und dem zielsys- temabhängigen Format ermöglicht wird. Das übergreifende Beschreibungsformat kann demnach als ein allgemeingültiges bzw. übergeordnetes Format unter quellsystemabhängigen und zielsystemabhängigen Formaten angesehen werden.
Weitere Ausgestaltungen der vorliegenden Funktionseinheit ergeben sich aus den abhängigen Patentansprüchen 2 bis 7. Hierbei ist die Funktionseinheit insbesondere dazu ausgebildet, mindestens einen Schritt des nachfolgend vorgestellten erfindungsgemäßen Verfahrens durchzuführen.
Ferner betrifft die vorliegende Erfindung ein Transformationssystem mit den Merkmalen des Patentanspruchs 8. Dieses Transformationssystem ist zur Migration und Transformation von Datenstrukturen mindestens eines Quellsystems in Datenstrukturen mindestens eines Zielsystems vorgesehen. Das Transformationssystem weist mindestens ein Quellsystem, mindestens ein Zielsystem und eine zwischen dem mindestens einen Quellsystem und dem mindestens einen Zielsystem gekoppelte Funktionseinheit auf, wobei die Funktionseinheit mindestens einen Import-Filter und mindestens einen Export- Filter aufweist. Dabei ist der mindestens eine Import- Filter dazu ausgebildet, eine von dem Quellsystem bereitge- stellte, in einem quellsystemabhängigen Format vorliegende Datenstruktur in ein übergreifendes Beschreibungsformat zu transformieren, und der mindestens eine Export-Filter ist dazu ausgebildet, die in dem übergreifenden Beschreibungsformat vorliegende Datenstruktur in ein zielsystemabhängi- ges Format zu transformieren und dem Zielsystem bereitzustellen.
Die vorliegende Erfindung umfasst auch einen Beschreibungsrahmen, ein sog. Framework, mit den Merkmalen des Patentanspruchs 9. Der erfindungsgemäße Beschreibungsrahmen ist zur Transformation und Migration einer Datenstruktur von mindestens einem Quellsystem in mindestens ein Zielsystem geeignet und dazu ausgebildet, eine von dem mindestens einen Quellsystem bereitgestellte, in einem quellsystemabhängigen Format vorliegende und über mindestens einen Import-Filter transformierte Datenstruktur in einem übergreifenden Beschreibungsformat darzustellen, und die in dem übergreifenden Beschreibungsformat dargestellte Datenstruktur über mindestens einen Export-Filter in ein zielsystemabhängiges Format zu transformieren.
Das von der Erfindung ferner bereitgestellte erfindungsgemäße Verfahren ist zur Migration und Transformation einer Datenstruktur von mindestens einem Quellsystem in mindestens ein Zielsystem vorgesehen. Bei dem Verfahren wird die von dem mindestens einen Quellsystem bereitgestellte, in einem quellsystemabhängigen Format vorliegende Datenstruktur über mindestens einen Import-Filter in eine in einem übergreifenden Beschreibungsformat vorliegende Datenstruktur transformiert. Die in dem übergreifenden Beschreibungsformat vorliegende Datenstruktur wird über mindestens einen Export-Filter in eine in einem zielsystemabhängigen Format vorliegende Datenstruktur transformiert und dem mindestens einen Zielsystem bereitgestellt.
Weitere Vorteile des erfindungsgemäßen Verfahrens ergeben sich aus den abhängigen Patentansprüchen 11 bis 19. Es ist vorgesehen, dass das Verfahren insbesondere durch die erfindungsgemäße Funktionseinheit durchgeführt werden kann.
In einer bevorzugten Ausführungsform kann vorgesehen sein, dass der mindestens eine Import-Filter und der mindestens eine Export-Filter jeweils durch den erfindungsgemäßen Bearbeitungsrahmen aus einem Quellcode abzuleiten sind. Dieser Quellcode kann aus Strukturinformationen, die in einer Konfigurationstabelle bzw. einer Konfigurationsdatei hinterlegt sind, generiert werden.
Das erfindungsgemäße Computerprogramm mit Programmcodemitteln ist dazu geeignet, alle Schritte des erfindungsgemäßen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in der erfindungsgemäßen Funktionseinheit, ausgeführt wird.
Das erfindungsgemäße Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, ist dazu ausgebildet, alle Schritte des erfindungsgemäßen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in der erfindungsgemäßen Funktionseinheit, durchgeführt wird.
Die vorliegende Erfindung stellt eine vorzugsweise softwaregestützte Lösung zur wechselseitigen Migration und Transformation von Datenstrukturen, beispielsweise verschiedener Datenbank-Systeme oder verschiedener EDV-Anwendungen über verschiedene Entwicklungs-Plattformen bereit. Die Datenstrukturen basieren dabei bspw. auf dem XML-Format (Extensible Markup Language) . Eine Migration und Transformation von Datenbank-Systemen und EDV-Anwendungen über verschiedene Entwicklungs-Plattformen hinweg auf Basis von XML wird mittels der vorliegenden Erfindung ermöglicht. Jedes andere geeignete Format neben dem XML-Format ist jedoch auch denkbar.
Zahlreiche Datenbank- und IT-Systeme ermöglichen eine Darstellung einer zu verarbeitenden Logik und von Gestaltungselementen in einem XML-Format. Die erfindungsgemäße Funktionseinheit, wobei diese Funktionseinheit sowie deren Komponenten im Folgenden die Bezeichnung D2 (D-Quadrat) tragen können, transformiert diese in der Regel in hersteiler- und systemabhängigen XML-Formaten oder -Darstellungen vorliegenden Datenstrukturen ausgehend von dem mindestens einen Quellsystem über den mindestens einen Import-Filter in ein übergreifendes Beschreibungsformat. Die in dem übergreifenden Beschreibungsformat dargestellten Datenstrukturen werden im Folgenden als D2-Objekte bezeichnet. Durch reversen Einsatz der erfindungsgemäßen Funktionseinheit lässt sich in einem zweiten Schritt diese Datenstruktur wieder über mindestens einen vorzugsweise dedizierten Export-Filter in ein für das mindestens eine Zielsystem valides und konformes hersteller- und systemabhängiges XML-Format transformieren, so dass die Darstellung der verarbeitenden Logik und die Gestaltungselemente nunmehr in einem zielsystemspe- zifischen XML-Format vorliegt. Dabei können alle EDV-Systeme unterstützt werden, die eine Darstellung ihrer Gestaltung in XML oder XML-Dialekten, wie Lotus Domino, MS Office 2003, .Net, etc., ermöglichen.
Der erfindungsgemäße Beschreibungsrahmen, im Folgenden als D2-Framework bezeichnet, der in die Funktionseinheit eingebunden ist, basiert auf einer programmiersprachenunabhängigen und selbstlernenden Vorgehensweise für die Interpretation und Migration von Datenstrukturen. Bei den Datenstrukturen kann es sich, wie bereits erwähnt, um Anwendungen handeln.
Mögliche Einsatzmöglichkeiten der erfindungsgemäße Funktionseinheit und/oder des erfindungsgemäßen Verfahrens finden sich bspw. in den folgenden Teilbereichen: Analyse von Umstellungsaufwänden, Migration von IT-Systemen und/oder Modifikation von IT-Systemen.
Durch den Import von bestehenden Anwendungen in den Beschreibungsrahmen der Funktionseinheit wird ein den Anwendungen zugrundeliegender Code geprüft und identifiziert. Somit ist eine Analyse von Umstellungsaufwänden einer Datenstruktur von einem Quellsystem in ein Zielsystem möglich.
Übersetzbare Strukturelemente der quellsystemabhängigen Datenstruktur bzw. entsprechende Gestaltungselemente wie Pro- grammecodeelemente werden hierbei als "positiv" identifiziert und stellen im Rahmen einer geplanten Umstellung keine Probleme dar. Nicht übersetzbare Strukturelemente werden bei der Analyse der quellsystemabhängigen Datenstrukturen als "negativ" identifiziert und in ein für derartige negative Strukturelemente vorgesehenes Protokoll geschrieben. Dieses Protokoll kann durch zusatzliche Maßnahmen entsprechend bearbeitet werden, so dass für negativ identifizierte Strukturelemente eine geeignete Übersetzung bereitgestellt und diese Übersetzung für die Zukunft in die Konfigurationstabelle aufgenommen wird. Bewertet man dieses Protokoll mit Aufwanden zeitlicher und/oder materieller Art, können über deren Aggregationen realitatsnahe Abschatzungen für die geplanten Umstellungen getätigt werden.
Bei einer Migration für IT-Systeme werden bestehende Strukturelemente bzw. eine bestehende Gestaltung des Quellsystems ausgelesen und in eine analoge Gestaltung bzgl. Formularaufbau, Darstellung der Daten, verarbeitende Logik, usw., in dem gewählten Zielsystem überfuhrt. Da das Quellsystem hierbei nicht modifiziert wird, wird dessen Daten- und Funktionsintegritat gewahrleistet.
Nach erfolgter Migration kann die neugeschaffene Datenstruktur bzw. Anwendung hinsichtlich ihrer Funktionalität getestet und evaluiert werden. Sind im Verlaufe der Migration keine Probleme aufgetreten, kann die quellsystemabhan- gige Datenstruktur abgelost werden. Sind im Verlaufe der Migration bisher unbekannte Codeelemente in dem Quellsystem identifiziert worden, werden diese in dem Protokoll (D2- Log) der Funktionseinheit protokolliert. Diese unbekannten Codeelemente oder als "negativ" identifizierte Strukturelemente, können bei einer Auswertung des Protokolls überarbeitet und/oder auskommentiert werden, so dass diesen Co- deelemten bzw. Strukturelementen im Rahmen des übergreifenden Beschreibungsformats eine geeignete Übersetzung zugewiesen werden kann. Nun besteht die Möglichkeit, die bestehenden Import- und Export-Filter zu erweitern und in einem weiteren Migrationsdurchgang ein vollständigeres und somit besseres Ergebnis zu erzielen. Auf diese Weise können komplexe Migrationsprojekte modular und anwendungsbezogen abgearbeitet und zu einem Stichtag automatisch abgeschlossen werden.
Zahlreiche in einem Unternehmen oder einer Organisation befindliche IT-Systeme weisen ein beträchtliches Alter auf und sind nach den zum Zeitpunkt der Entwicklung gegebenen technischen Möglichkeiten erstellt worden, weshalb eine Modifikation derartiger IT-Systeme in Erwägung zu ziehen wäre. Ein manuelles Upgrade auf den aktuellen Stand (Status Quo) des technischen Fortschritts birgt ein hohes Kosten- und Zeitrisiko. Im Regelfall sind an dieser Stelle zahlreiche einfache Einzelschritte manuell abzuarbeiten, wie Anpassung des Datenmodells, Änderung von Feldnamen und Bezeichnungen usw.
Mittels der erfindungsgemäßen Funktionseinheit können diese Schritte automatisiert werden. Das bedeutet, dass für den Export der Datenstruktur der entsprechende inverse Import- Filter verwendet wird. Wird bspw. ein Import-Filter für die Transformation einer Datenstruktur von MS Word nach D2 verwendet, so dient der entsprechende inverse Import-Filter umgekehrt für die Transformation von D2 nach MS Word als Export-Filter. Dazu müssen der Import- und der Export- Filter entsprechend invers zueinander konfiguriert sein. Demnach kann in bevorzugter Ausgestaltung mit einem Import- Filter und einem dazu korrespondierenden Export-Filter eine bidirektionale Transformation einer Datenstruktur, die in einem bestimmten, von einem ersten System abhängigen Format vorliegt, in das übergreifende oder allgemeingültige Be- schreibungsformat und umgekehrt ermöglicht werden. Dieses bestimmte erste System kann dabei sowohl als Quellsystem von dem Import-Filter als auch als Zielsystem von dem dazu korrespondierenden Export-Filter bedient werden.
Die Transformation der Datenstruktur erfolgt in zwei Schritten. In einem ersten Schritt wird die Datenstruktur, die in dem quellsystemabhängigen Format vorliegt, durch den Import-Filter durch Analyse, Identifizierung und Zuordnung von Strukturelementen in das übergreifende Beschreibungsformat transformiert. Dieser Import-Filter kann sich aus der übergebenen Datenstruktur und den in einem Konfigurationssystem hinterlegten bspw. vorgebbaren Informationen durch Bearbeitung, Modifikation und Ergänzung von Strukturelementen selbst generieren. Bei diesem Import-Filter handelt es sich somit um einen sogenannten selbstlernenden Code. Die Informationen zu der in dem nunmehr übergreifenden Beschreibungsformat vorliegenden Datenstruktur werden in dem übergreifenden Beschreibungsrahmen der Funktionseinheit temporär gespeichert. Eine Speicherung kann hierbei in einem hierarchischen Klassenmodell oder Klassensystem erfol- genr wobei dieses Klassenmodell auf Basis der bei der Transformation oder Migration aus dem mindestens einen Quellsystem eingelesener Strukturelemente oder einer entsprechenden Datenstruktur überführt wird.
Die in dem allgemeinen Beschreibungsformat vorliegende Datenstruktur kann in einem zweiten Schritt durch Analyse, Identifizierung und Zuordnung von Strukturelementen in ein beliebiges Zielsystem oder eine entsprechende Plattform überführt werden, für die der Export-Filter hinterlegt ist. Der Export-Filter identifiziert die in dem Beschreibungsrahmen gespeicherten Strukturelemente, beispielsweise Ent- wurf- oder Designelemente oder Code-Bausteine, und überführt diese in jenes zielsystemabhängige Format, das von dem Zielsystem interpretiert werden kann. Nicht bekannte oder nicht existierende Strukturelemente innerhalb des Zielsystems werden bei diesem Vorgang zu Dokumentationszwecken protokolliert und mitgeführt, diese Strukturelemente können nachträglich auskommentiert und durch eine Administratoreinheit bearbeitet und insbesondere manuell übersetzt werden. Auf diese Weise können EDV-Systeme über einen Zwischenschritt des übergreifenden Beschreibungsrahmens unter Speicherung in dem übergreifenden Beschreibungsformat von einer ersten Plattform bzw. dem Quellsystem auf eine beliebige andere unterstützte zweite Plattform bzw. das Zielsystem überführt werden.
Unterstützt werden hierbei insbesondere alle Plattformen oder Systeme, die auf XML-Dateien oder deren Derivaten zur Definition von Strukturelementen wie deren Layout und Code zurückgreifen können, beispielsweise "Lotus Domino", "MS Office 2003", ".Net" usw. Es ist vorgesehen, dass ein Zugriff auf den übergreifenden Beschreibungsrahmen während dieser Transformation über jede Programmiersprache erfolgen kann, die das Einbinden von externen Code-Ressourcen, in diesem Fall in einer Programmierschnittstelle (D2-API (Application Programming Interface) ) der Funktionseinheit erlaubt, z.B. "Lotus Script", "Java", "VB" usw.
Neben der eigentlichen Migration von Anwendungen ist mit der Funktionseinheit beispielsweise eine Schätzung zu erwartender Aufwände bei einer IT-System-Umstellung oder ein Überblick über eine Code-Qualität von betrachteten Anwendungen möglich. Mit der erfindungsgemäßen Funktionseinheit bzw. dem übergreifenden Beschreibungsrahmen ist es somit möglich, eine IT-Infrastruktur zu analysieren und eine Abschätzung zu gewinnen, wie viel Prozent der mit dieser IT-Infrastruktur verbundenen Datenstrukturen bzw. Anwendungen einfach, schwierig oder vielleicht gar nicht zu migrieren sind. Werden die hierbei gewonnenen Ergebnisse, die aus dem Protokoll hervorgehen, in eine sog. Normalform gebracht, bei der jedes unbekannte Element nur noch einmal enthalten ist, so dass die Ergebnisse übersichtlich aufbereitet sind, kann eine einfache Aufwandsschätzung darüber abgeleitet werden, was eine Umstellung an Ressourcen und Kosten verschlingen wird. Sofern einem Nutzer diese Abschätzung als angemessen und akzeptabel erscheint, kann über den übergreifenden Beschreibungsrahmen oder die Funktionseinheit die Umstellung des ursprünglichen Systems, also des Quellsystems, bspw. durch Ablösen von Word-Formularen oder Excel-Spreadsheets automatisiert erfolgen.
Im Regelfall werden Migrationen zwischen Plattformen bzw. Systemen entweder manuell durchgeführt oder es wird ein individueller Code verfasst, durch den eine Umstellung von einem ersten System zu einem zweiten System möglich ist. Durch den Einsatz eines globalen Filters oder eines Transformationsfilters der erfindungsgemäßen Funktionseinheit, der den Import-Filter und den Export-Filter umfasst, ist es möglich, eine neue Plattform bzw. das Zielsystem in zwei Schritten zu erschließen. In einem ersten Schritt kann ein Import-Filter aus der quellsystemabhängigen Datenstruktur bzw. Anwendung im übergreifenden Beschreibungsformat erstellt werden. In einem zweiten Schritt kann ein entsprechender Export-Filter für die zielsystemabhängige Datenstruktur erzeugt werden. Hierzu kann in einer Ausgestaltung vorgesehen sein, dass der Bearbeitungsrahmen aus Strukturinformationen, die in Konfigurationstabellen für die jeweiligen Datenstrukturen hinterlegt sind, jeweils einen Quellcode erzeugt, aus derartigen Quellcodes können dann die Import- und Export-Filter abgeleitet werden. Liegen beide Filter vor, ist dieses Quellsystem in den übergreifenden Beschreibungsrahmen eingebunden und kann jederzeit eingesetzt werden. Somit können erhebliche Einsparungspotentiale erzielt werden. Es ergibt sich im Vergleich zu bisherigen Vorgehensweisen eine erhebliche Kostenreduktion und eine schnellere Umsetzbarkeit, da die eigentliche Arbeit der Transformation nunmehr von der erfindungsgemäßen Funktionseinheit übernommen wird. Mit der erfindungsgemäßen Funktionseinheit ist man in der Lage, bestehende Anwendungen auf eine neue Plattform zu heben bzw. in das Zielsystem zu transformieren, wodurch ein wesentlich einfacherer und schnellerer Umstellungsprozess bereitgestellt ist.
Die erfindungsgemäße Funktionseinheit kann ein wesentlich weitläufigeres Spektrum an Plattformen bzw. Systemen, also Quell- und Zielsystemen abdecken, da dieses auf dynamischen Import-Filtern und Export-Filtern aufbaut. Während einer Laufzeit analysiert die Funktionseinheit einen eingespielten Code und erweitert gegebenenfalls die hinterlegte Konfigurationstabelle. Diese Konfigurationstabelle kann von einem Administrator überprüft und modifiziert werden, so dass der Nutzer die Funktionseinheit individuell an seine Bedürfnisse anpassen kann, womit dieser Nutzer entscheidet, welche Optionen ihm mit der Funktionseinheit geboten sind. Möglicherweise bei der Transformation bzw. einer Übersetzung des Codes oder einer Gestaltung auftretende Fehler sind lediglich Konfigurationsprobleme und können nachträglich angepasst werden, ohne ein Update der softwaregestütz- ten Funktionseinheit zwingend erforderlich zu machen. Der Nutzer ist somit in der Lage, seine bestehende Infrastruktur zu analysieren und hieraus eine Aufwandsabschatzung für die Transformation abzuleiten und einen Fokus auf eine Identifikation von Hindernissen zu setzen. Somit wird dem Nutzer ein breiteres Spektrum an Funktionalitaten zur Verfugung gestellt .
Die erfindungsgemaße Funktionseinheit sowie der erfindungs- gemaße übergreifende Beschreibungsrahmen als Teil der Funktionseinheit bieten die Möglichkeit einer Entwicklung einer globalen Speicherungsmoglichkeit von Datenstrukturen, die in beliebigen Formaten, insbesondere XML-Formaten, vorliegen. Zur Speicherung der Datenstrukturen kann hierbei vorzugsweise das hierarchische und ggf. generalisierte Klassenmodell vorgesehen sein.
Mit der Funktionseinheit oder dem übergreifenden Beschreibungsrahmen kann zudem eine Anzahl der zur Transformation notwendigen Übersetzungsfilter erheblich reduziert werden. Geht man beispielsweise von sechs verschiedenen Plattformen bzw. Systemen aus, benotigt man für diese sechs Plattformen insgesamt 30 Transformationsfilter, da jedes System in jeweils fünf andere Systeme zu übersetzen ist. Durch den Einsatz der erfindungsgemaßen Funktionseinheit als globaler Container, der die Import- und Export-Filter umfasst und unter Nutzung des übergreifenden Beschreibungsformats ist eine Anzahl der benotigten Transformationsfilter auf zwei pro eingesetztem System oder eingesetzter Plattform reduziert. Demnach benotigt man pro System nur einen Import- Filter und einen Export-Filter. Geht man insgesamt von sechs Plattformen oder Systemen aus, so sind bei der vorliegenden Funktionseinheit lediglich 12 Transformationsfil- ter, also sechs Import-Filter und sechs Export-Filter nötig.
Zusätzlich zu einer Reduktion benötigter Filter und damit benötigter Codes ist die Funktionseinheit selbstlernend, indem die Funktionseinheit neue Strukturelemente in eine Konfigurationstabelle aufnimmt und zugrundeliegende Programmierschnittstellen (D2-API) eigenständig erweitert und neuen Gegebenheiten anpasst. Die Funktionseinheit kann demnach bei neuen Versionen von Quell- oder Zieldaten aus entsprechenden Quell- oder Zielsystemen den sich dabei ergebenden Änderungen selbsttätig anpassen.
Die Funktionseinheit erlaubt ein Öffnen der in einem quell- systemabhängigen Format, bspw. in einem XML-Format, vorliegenden Datenstruktur, also einer Datei oder Anwendung, und überführt die darin enthaltenen Strukturelemente in eine zielsystemabhängige Datenstruktur und importiert diese automatisch. Strukturelemente, die nicht fehlerfrei übersetzt werden können, werden entsprechend markiert und in dem Protokoll angezeigt. Der Nutzer der Funktionseinheit kann aus diesem Protokoll ableiten, was und in welchem Umfang noch Korrekturen vorgenommen werden müssen, bevor dieser Teil oder diese Anwendung genau jenen Anforderungen genügt, die die ursprüngliche Datei oder Anwendung hatte. Sämtliche Aktivitäten der Funktionseinheit können nach Applikation, Anwender, Datum oder Art einzelner durchgeführter Schritte in einem Bericht sortiert, angezeigt und ausgewertet werden. Ein Benutzer-Frontend bzw. Programmier-Frontend, das zur interaktiven Anforderung, Eingabe sowie Anzeige von Daten verwendet wird und auch als Benutzeroberfläche bezeichnet werden kann, basiert auf Vorgaben einer Designstudie für eine Erstellung eines intuitiven Frontends und setzt diese soweit technisch möglich um.
Die erfindungsgemäße Funktionseinheit ist insbesondere für Nutzer oder Unternehmen geeignet, die eine Ausrichtung in einem Bereich der computergestützten Zusammenarbeit ("CSCW" (Computer Supported Collaborative Work) oder Groupware) überdenken. Eine auf diesem Markt herrschende Konkurrenzsituation, bietet sich zur Anwendung der Funktionseinheit sowie des Verfahrens an. Die Funktionseinheit ist für Unternehmen geeignet, die einen hohen Bedarf an Unterstützung durch weitgehend automatisierte Tools im IT-Bereich haben. Mit der Funktionseinheit wird diesen Unternehmen die Möglichkeit geboten, ihre IT-Strategie vor dem Hintergrund aktuell genutzter Systeme, in diesem Fall von Quellsystemen, zu überdenken und gegebenenfalls durch Umstellung oder Transformation auf modernere, leistungsstärkere Systeme, also Zielsysteme, zu verbessern.
Der erfindungsgemäße Beschreibungsrahmen der Funktionseinheit kann derart ausgebildet sein, dass im Bereich einer Gestaltung des Benutzer-Frontends Anforderungen der Norm "DIN EN ISO 9241 Teil 10" berücksichtigt und soweit wie möglich umgesetzt werden können. Hierbei kann aufgrund technischer Gegebenheiten auf folgende Aspekte Wert gelegt werden:
- Aufgabenangemessenheit durch Nutzung von Standard- Werten und Auswahlfeldern zur Fehlerreduktion,
Selbstbeschreibungsfähigkeit durch Verwendung von Statuszeilen, kostenextensiven Hilfen oder Anmerkungen,
Steuerbarkeit, indem Eingabemöglichkeiten über einen sogenannten Wizard für Anfänger oder komplexere Masken für Experten möglich ist, Erwartungskonformitat durch konsistente Gestaltung aller Interaktionsmoglichkeiten durch Anordnung von Aktionen.
Mit der Funktionseinheit kann insbesondere das XML-Format in innovativer Weise genutzt werden. Ursprünglich war XML als Datenaustauschformat zwischen IT-Systeinen, z.B. WebSer- vices gedacht. Mit der durch das Verfahren oder der Funktionseinheit durchfuhrbaren Transformation von Datenstrukturen, also Anwendungen, Daten oder auch Gestaltungen, kann unter Nutzung von XML-Import- und Exportmöglichkeiten zur Ablösung oder Einrichtung von Systemen das XML-Format innovativ genutzt werden.
Bei Durchfuhrung des erfindungsgemaßen Verfahrens bzw. bei Nutzung der erfindungsgemaßen Funktionseinheit werden nicht nur einfach Buchstaben oder Worte, sondern komplette Strukturelemente inklusive deren technischer Sinngehalt hinsichtlich einer Anwendung transformiert oder ausgetauscht.
Für einen Praxiseinsatz erscheinen insbesondere drei verschiedene Szenarien denkbar und lukrativ:
1) Abschätzung von Aufwanden im Vorfeld einer Migration: Wahrend einer Überführung der Datenstruktur aus dem Quellsystem, also einer Quellapplikation m das übergreifende Beschreibungsformat fuhrt die Funktionseinheit eine Analyse der Strukturelemente und somit eines Codes dieser Datenstruktur durch. Im Rahmen dieser Analyse werden nicht bekannte oder nicht übersetzbare Struktur-, Code- und/oder Designelemente protokolliert. Der Inhalt des dabei bereitgestellten Protokolls ist die Summe aller nicht automatisch übersetzbaren Strukturelemente oder Fragmente. Erfahrungsgemäß sind es bei verschiedenen Datenstrukturen oder Anwen- düngen identische Strukturelemente, die nicht übersetzt werden können, so dass nur eines von mehreren gleichartigen Strukturelementen für eine Aufwandsschätzung relevant ist und in die Normalform gebracht wird. Bewertet man von jedem Objekttyp ein Strukturelement mit einer pekuniären oder zeitlichen Größe, erhält man einen Überblick über einen im Rahmen der tatsächlichen Umstellung anfallenden Aufwand zur Anpassung.
2) Durchführung einer Migration:
Steht eine Migration bevor, ergeben sich für den IT-Bereich oder betroffene Fachbereiche zwei Möglichkeiten zu deren Durchführung: Entweder a) eine manuelle Migration, die in der Regel sehr aufwendig sein wird, oder b) eine toolgesteuerte Migration mit anschließender manueller Prüfung und Korrektur. Da der Aspekt der Qualitätssicherung in beiden Fällen auftritt, kann dieser bei einer Bewertung vernachlässigt werden. Sind im Rahmen der IT-Umstellung mehr als ca. 20 Datenstrukturen zu transformieren, empfiehlt sich aus finanzmathematischer Sicht der Einsatz der erfindungsgemäßen Funktionseinheit bzw. des erfindungsgemäßen Verfahrens .
3) Upgrade von bestehenden Datenstrukturen oder Anwendungen :
Besteht das Interesse, bestehende Datenstrukturen auf ein einheitliches Format anzuheben und die ihnen zugrundeliegende Codelogik zu vereinfachen, kann dies mit dem durch die Funktionseinheit zur Verfügung gestellten Beschreibungsrahmen (Framework) und den darin enthaltenen Programmierschnittstellen (API) durchgeführt werden. Mit Hilfe der Funktionseinheit kann sichergestellt werden, dass auch tatsächlich alle Feldbezeichnungen innerhalb eines zu trans- formierenden Systems, insbesondere Quellsystems oder einer zu transformierenden Datenbank umgesetzt werden. Auch in diesem Szenario macht der Einsatz der Funktionseinheit aus finanzieller Sicht Sinn, sobald es sich um mehr als 20 Datenstrukturen handelt.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im folgenden unter Bezugnahme auf die Zeichnung ausführlich beschrieben.
Figur 1 zeigt in schematischer Darstellung eine bevorzugte Ausführungsform eines erfindungsgemäßen Transformationssystems .
Figur 2 zeigt in schematischer Darstellung eine bevorzugte Ausführungsform eines Ebenenmodells einer erfindungsgemäßen Funktionseinheit .
Figur 3 zeigt ein Phasenmodell zur Durchführung einzelner Schritte einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens. Figur 4 zeigt in schematischer Darstellung eine bevorzugte Ausführungsform eines erfindungsgemäßen Beschreibungsrahmens .
Das in Figur 1 in bevorzugter Ausführungsform schematisch dargestellte Transformationssystem 1 umfasst eine Funktionseinheit 3, die mindestens einen Import-Filter 5, mindestens einen Export-Filter 7 sowie mindestens eine Programmierschnittstelle 9 (API) aufweist. Die Funktionseinheit 3 bzw. der mindestens eine Export-Filter 7 sowie der mindestens eine Import-Filter 5 haben Zugriff auf diverse Objekte 11, wie bspw. auf zur Transformation benötigte Tabellen, insbesondere auf Konfigurationstabellen oder Definitionstabellen sowie auf Protokolle.
Ist vorgesehen, eine Datenstruktur, die in einem quellsys- temabhängigen Format 17 vorliegt, von einem Quellsystem 13 in eine in einem zielsystemabhängigen Format 19 vorliegende Datenstruktur in ein Zielsystem 15 zu transformieren und/oder zu migrieren, so ist eine derartige Transformation und/oder Migration mit der Funktionseinheit 3 sowie mit dem durch die Funktionseinheit 3 ausführbaren Verfahren durchführbar. Hierbei ist vorgesehen, dass die in dem quellsys- temabhängigen Format 17 vorliegende und von dem Quellsystem 13 bereitgestellte Datenstruktur über den Import-Filter 5 in eine, in einem übergreifenden Beschreibungsformat 18 vorliegende Datenstruktur transformiert und in der Funktionseinheit 3 abgespeichert wird. Danach wird die in dem übergreifenden Beschreibungsformat 18 vorliegende Datenstruktur über den Export-Filter 7 in die im zielsystemabhängigen Format 19 vorliegende Datenstruktur transformiert und somit dem Zielsystem 15 bereitgestellt. In den Konfigurationstabellen unter den Objekten 11 sind Informationen hinterlegt. Diese Informationen dienen bei der Transformationen zur Interpretation und Übersetzung oder Übertragung von Strukturelementen, in die die im quellsystemabhängigen Format 17 vorliegende Datenstruktur zu zerlegen ist. In den Protokollen unter den Objekten 11 werden nicht übersetzbare Strukturelemente protokolliert.
Bei der Funktionseinheit 3 handelt es sich demnach um eine Plattform und bei dem Verfahren um eine Vorgehensweise für eine automatisierte Transformation bzw. Migration von EDV- Systemen über bzw. zwischen verschiedenen Plattformen.
Figur 2 verdeutlicht in schematischer Darstellung die Vorgehensweise für eine Interpretation und Migration von Datenstrukturen bzw. Anwendungen. Grundlage eines Beschreibungsrahmens der Funktionseinheit aus Figur 1 ist hierbei das in Figur 2 in bevorzugter Ausführungsform dargestellte Ebenen-Modell, das zur Durchführung der Transformation 21 von Datenstrukturen ausgebildet ist, und das eine in einer Darstellungsebene 23 eingebettete EDV-Anwendung, eine Verarbeitungsebene 25 mit mindestens einem globalen Filter oder einem entsprechenden Transformationsfilter, der mindestens einen Import-Filter 24 und mindestens einen Export- Filter 26 aufweist, und eine Datenebene 27, die das übergreifende Beschreibungsformat 28 umfasst, aufweist.
Über den mindestens einen Import-Filter 24 wird die quell- systemabhängige XML-Darstellung der entsprechenden Datenstruktur bzw. eine Quellanwendung aus dem Quellsystem in das übergreifende Beschreibungsformat 28 (D2-Format) überführt. Ist die Gestaltung in diesem Beschreibungsformat 28 zwischengespeichert, kann die Datenstruktur ausgehend von dieser Darstellung über den Export-Filter 26 in eine für das Zielsystem bzw. eine Zielplattform verständliche ziel- systemabhängige XML-Darstellung überführt werden. Die Funktionseinheit ist durch ständige Aktualisierung an eine hohe Dynamik im IT-Umfeld angepasst, somit können neue Versionen einer Software oder neue Design-Elemente und somit auch neue XML-Strukturen transformiert werden.
Figur 3 zeigt ein Phasenmodell entsprechend einem Prozess der Transformation bei einer bevorzugten Ausführungsform des Verfahrens. Das Verfahren umfasst im wesentlichen vier Phasen oder Schritte, nämlich eine Analyse 29, eine Erweiterung 31 bzw. ein Upgrade, einen Entwurf 33 bzw. ein Design und eine Transformation 35.
Bei Durchführung des Verfahrens wird in der Phase der Analyse 29 eine bereitgestellte quellsystemabhängige XML-Datei bspw. mittels eines Standard-XML-Parsers (DOM-Parser) in ihre Strukturelemente oder Elemente zerlegt. Jedes identifizierte Strukturelement oder Attribut, beispielsweise ein XML-Knoten, sowie jedes XML-Attribut wird gegen eine Konfigurationstabelle verglichen. Das Ergebnis dieser Überprüfung kann eine der folgenden Ausprägungen haben: a) Das Strukturelement ist noch nicht in der Konfigurationstabelle der Funktionseinheit enthalten. b) Das Strukturelement ist bereits in der Konfigurationstabelle enthalten und in dieser weder als positiv, d.h. bekannt und übersetzbar, noch negativ, d.h. bekannt und nicht übersetzbar, markiert oder identifiziert. c) Das Strukturelement ist bereits in der Konfigurationstabelle enthalten und als bekannt und interpretierbar markiert, dies entspricht einer positiven Definition dieses Strukturelements. d) Das Strukturelement ist bereits in der Konfigurationstabelle enthalten und als nicht interpretierbar markiert, dies entspricht einer negativen Definition dieses Strukturelements.
Handelt es sich um ein neues Strukturelement (Fall a) , wird dieses in die Konfigurationstabelle aufgenommen und als unbekannt markiert. Durch eine manuelle Überprüfung kann dieses dann entweder als übersetzbar, d.h. positiv, oder nicht übersetzbar, d.h. negativ, markiert werden. Ist das Strukturelement zwar in der Konfigurations- oder Definitionstabelle enthalten (Fall b) , aber noch nicht beurteilt worden, protokolliert der Import-Filter, dass es sich um ein Undefiniertes Strukturelement handelt, dieses Strukturelement wird dabei in ein dafür vorgesehenes Protokoll aufgenommen, so dass es individuell bearbeitet werden kann. Ist das Strukturelement in der Konfigurations- oder Definitionstabelle enthalten und als bekannt und interpretierbar markiert (Fall c) , so wird dieses Strukturelement in den Beschreibungsrahmen bzw. eine D2-Struktur des Import-Filters aufgenommen. Ist das Strukturelement als bekannt aber nicht übersetzbar identifiziert worden (Fall d) , eliminiert der Import-Filter einen damit verbundenen Knoten, insbesondere einen XML-Knoten.
Bei einem positiv definierten Strukturelement wird dieses iinn ddeenn BBeesscchhrreeiibbuunnggssrraahhmm«en bzw. eine D2-Struktur des Im- port-Filters aufgenommen.
Durch die automatische Aufnahme neuer Strukturelemente in die Konfigurations- oder eine entsprechende Definitionstabelle stellt sich der Import-Filter als selbstlernendes System dar. Neue Situationen erweitern den zugrundeliegenden Beschreibungsrahinen (D2-Struktur) automatisch.
Positiv- und Negativdefinitionen für Strukturelemente garantieren, dass nur den Import- und Export-Filtern bekannte Strukturelemente importiert und in das Zielsystem exportiert werden können. Neben der eigenständigen Erweiterung der Funktionseinheit handelt es sich hierbei um die zweite entscheidende Eigenschaft zur Durchführung von fehlerresis- tenten Transformationen und/ oder Migrationen von Datenstrukturen. Negativen Strukturelementen, die in dem hierfür vorgesehenen Protokoll abgelegt sind, kann durch einen Administrator eine geeignete Übersetzung zugeordnet werden.
Bei dem Verfahren ist in der nächsten Phase die Erweiterung 31 vorgesehen. Stößt der Import-Filter auf ihm noch nicht bekannte Strukturen oder Strukturelemente werden diese, wie voranstehend beschrieben, in die Konfigurationstabellen aufgenommen. Auf Basis der nun veränderten Konfigurationstabelle erweitert sich ein Objektmodell des Beschreibungsrahmens oder der Funktionseinheit um die hinzugekommenen Strukturelemente und merkt sich diese für die Zukunft. Hierbei werden automatisiert neue Objektklassen generiert und in bereits eingebundene Struktur- oder Codeelemente integriert .
Ist die zu importierende Datenstruktur analysiert worden und das Objektmodell im Rahmen der Erweiterung 31 aktualisiert, wird in dem als Entwurf 33 vorgesehenen Prozessschritt die quellsystemabhängige Datenstruktur bzw. eine Quell-Datei in ein hierarchisches Klassenmodell auf Basis der bei der Transformation oder Migration aus dem mindestens einen Quellsystem eingelesenen Strukturelemente oder Datenstruktur überführt und einer Bearbeitungsplattform (D2-Plattform) des Bearbeitungsrahmens zur Verfügung gestellt. Nach dem Abschluss dieser Phase ist somit ein Import-Vorgang abgeschlossen und der eingelesene Code bzw. die eingelesenen Strukturelemente der Datenstruktur liegt bzw. liegen zur Weiterbearbeitung vor.
Analog zu dem Programmablauf beim Import werden im Rahmen der Transformation 35 die in dem übergreifenden Beschreibungsformat vorliegenden bzw. in einer D2-Struktur gespeicherten Informationen gegen den Export-Filter validiert und protokolliert. Unbekannte Struktur- bzw. Codeelemente werden hierbei aus Gründen der Dokumentation nicht gelöscht, sondern in das Protokoll aufgenommen und später auskommentiert. Der Export-Filter überführt die im übergreifenden Beschreibungsformat bzw. D2-Format gespeicherten Informationen in eine für das Zielsystem konforme Datenstruktur, insbesondere XML-Datei auf Basis der in den Import- und Export-Filtern hinterlegten Neuzuweisungen und/oder Übersetzungsregeln. Durch eine Erweiterung der Konfigurationstabelle werden der Import-Filter und Export-Filter im Laufe der Zeit verbessert. Der Import-Filter erweitert bei Bedarf eigenständig das allgemeine Beschreibungsformat, um dieses auf neue Situationen dynamisch anzupassen. Werden neue Strukturvorschläge durch einen Administrator akzeptiert, stehen sie für die Zukunft dauerhaft zur Verfügung.
Figur 4 zeigt in schematischer Darstellung den Beschreibungsrahmen 37 der Funktionseinheit mit einem Programmieroder Benutzer-Frontend 39, dem Import-Filter 41, dem Export-Filter 43, einer Klassenbibliothek 45, einer Basisbibliothek 47 und einer Konfigurationstabelle 49, die, durch die Pfeile angezeigt, durch Austausch von Daten, Informationen und Strukturelementen miteinander wechselwirken.
Der Bearbeitungsrahmen 37 (D2-Framework) folgt einem objektorientierten Programmier-Paradigma und nutzt über den Einsatz von Klassen die Eigenschaften der Vererbung in gängigen Programmiersprachen. Der Beschreibungsrahmen 37 ist - soweit eine Einbindung von Code-Ressourcen in der gewählten Programmiersprache möglich ist - sprachunabhängig. In einer Basisklasse "DD_Base" können globale Objekte definiert und globale Funktionen zur Verfügung gestellt werden. Diese stehen in den aus der Basisklasse abgeleiteten systemabhängigen Klassen zur Verfügung und verwenden diese für Standardfunktionen. Aus den in der Konfigurationstabelle 49 hinterlegten Strukturinformationen generiert der Bearbeitungsrahmen 37 automatisch einen Quellcode für die hersteiler- und/oder systemabhängige Datenstruktur.
Aus diesem Quellcode werden dann Import-Filter 41 und Export-Filter 43 abgeleitet, die über die in den Klassenbibliotheken 45 hinterlegte API-Schnittstelle eine entsprechende Transformation von Datenstrukturen zwischen verschiedenen Formaten durchführen. Über das entsprechende Be- nutzer-Frontend 39 in einer gewählten Plattform, wie beispielsweise "Domino. Designer" bei "Lotus Domino" oder "Visual Studio" bei ".Net-Anwendungen", können diese Import- Filter 41 und Export-Filter 43 über die entsprechend hinterlegte Programmierschnittstelle (API) angesprochen und angepasst werden. Hierbei werden alle Programmiersprachen unterstützt, welche das Einbinden von externen Code-Ressourcen zulassen. Die Basisbibliothek 47 (DD_Base-Bibliothek) repräsentiert eine Basisklasse, auf der alle anderen Klassen aufbauen. Sie stellt Grundfunktionen zum Interpretieren von XML- Dateien und die Überführung in ein Klassenmodell dar. Darüber hinaus enthält die Funktionseinheit die für die weitere Bearbeitung notwendigen klassenübergreifenden Objekte, beispielsweise einen Strukturbaum oder Basis-XML-Knoten. Die in einer Basisbibliothek 47 identifizierten XML- Elemente werden - solange noch nicht vorhanden - in die Konfigurationstabelle 49, die einer Definition der Strukturelemente dient, aufgenommen. Auf diese Weise entsteht dynamisch für jedes analysierte System oder jede analysierte Plattform je nach Format, beispielsweise "Lotus Domino", "MS Word" usw., ein eigener Strukturbaum. Über die Klassenbibliotheken 47 der Funktionseinheit werden aus den in der Konfigurationstabelle 49 hinterlegten Informationen die Funktionseinheit und die Programmierschnittstelle (API) dynamisch generiert, durch die die in der D2-Struktur hinterlegten Informationen darstellbar sind. Ein derart dynamisch erzeugter Code wird automatisch dokumentiert und versio- niert, und kann im weiteren Verlaufe von Transformationen angesprochen werden.
Für alle Attribute eins XML-Knotens (XML-node) werden bspw. die folgenden Eigenschaften und Methoden zur Verfügung gestellt:
- "get<AttributName>" (liest den Wert des Attributes aus)
- "set<AttributName>" (verändert den aktuellen Wert des Attributes)
- "append<ElementName>" (fügt ein neues Objekt dieses Typs in die Struktur ein)
"remove<ElementName>" (löscht ein bestehendes Objekt dieses Typs) - "New(MyNode as XMLNode) " (initialisiert eine neue Klasse für dieses XML-Element)
- "getXMLAsStream(stream_out as Stream) " (überführt das aktuelle Klassemodell in einen Stream)
- "getXMLAsString(str_DDOut as String) " (überführt das aktuelle Klassenmodell in einen Text-String) .
Auf diese Weise entsteht eine einheitliche und konsistente Schnittstelle (API) , die von einem beliebigen anderen Code angesprochen werden kann.
Um einen System- oder plattformunabhängigen Einsatz der Funktionseinheit zu gewährleisten, werden diese Klassenbibliotheken 45 in unterschiedlichen Programmiersprachen generiert und als Ressourcen in eine definierte Ablage (Reposi- tory) geschrieben.
Die in bei dem Verfahren durch die Funktionseinheit verwendeten Import-Filter 41 und Export-Filter 43 greifen auf die Klassenbibliotheken 45 zu und erben von diesen Eigenschaften und Methoden. Über diese Funktionalitäten werden für den Fall eines Imports die Informationen aus der XML-Datei in die Funktionseinheit geschrieben. Im Falle des Exports werden die in der Funktionseinheit gespeicherten Informationen in die entsprechende Klassenbibliothek 45 geführt und in einem validen XML-Format wiedergegeben. Nicht bekannte oder bekannte, jedoch nicht übersetzbare Strukturelemente und/oder Codeelemente werden hierbei in Protokollen festgehalten und somit auskommentiert mitübergeben. Derartige Strukturelemente müssen und/oder können dann bei Bedarf in dem Zielsystem manuell nachbearbeitet werden. Besteht der Bedarf in den Transformationsprozess via Programmcode einzugreifen, was beispielsweise ein Setzen von Update-Informationen oder Erstellen einer technischen Dokumentation umfasst, erfolgt dies in der gewählten Sprache über die eingebundene Programmierschnittstelle (API). Hierbei können, wie voranstehend gezeigt, alle Eigenschaften der Funktionseinheit sowie der Import-Filter 41 und Export- Filter 43 manipuliert werden.

Claims

Patentansprüche
1. Funktionseinheit zur Migration und Transformation von Datenstrukturen mindestens eines Quellsystems (13) in Datenstrukturen mindestens eines Zielsystems (15) , die mindestens einen Import-Filter (5, 24, 41) und mindestens einen Export-Filter (7, 26, 43) aufweist, wobei der mindestens eine Import-Filter (5, 24, 41) dazu ausgebildet ist, eine von dem Quellsystem (13) bereitgestellte, in einem quellsystemabhängigen Format (17) vorliegende Datenstruktur in ein übergreifendes Beschreibungsformat (18, 28) zu transformieren, und wobei der mindestens eine Export-Filter (7, 26, 43) dazu ausgebildet ist, die in dem übergreifenden Beschreibungsformat (18, 28) vorliegende Datenstruktur in ein zielsystemabhängiges Format (19) zu transformieren und dem Zielsystem (15) bereitzustellen.
2. Funktionseinheit nach Anspruch 1, die zur wechselseitigen Migration und Transformation von Datenstrukturen des mindestens einen Quellsystems (13) und Datenstrukturen des mindestens einen Zielsystems (15) geeignet ist.
3. Funktionseinheit nach Anspruch 1 oder 2, die einen übergreifenden Beschreibungsrahmen (37) mit einer Klassenbibliothek (45) und einer Basisbibliothek (47) aufweist.
4. Funktionseinheit nach Anspruch 3, bei der die Basisbibliothek (47) dazu ausgebildet ist, globale Objekte zu definieren sowie globale Funktionen und systemabhängige Klassen zur Verfügung zu stellen, wobei die systemabhängi- gen Klassen dazu ausgebildet sind, diese globalen Objekte und Funktionen als Standardfunktionen zu benutzen.
5. Funktionseinheit nach Anspruch 3 oder 4, bei der die Basisbibliothek (47) mindestens eine Basisklasse repräsentiert, wobei die Basisklasse Grundfunktionen zur Interpretation von Dateien und eine Überführung in ein Klassenmodell darstellt.
6. Funktionseinheit nach einem der Ansprüche 3 bis 5, bei der der Beschreibungsrahmen (37) dazu ausgebildet ist, aus Strukturinformationen, die in einer Konfigurationstabelle (49) hinterlegt sind, einen Quellcode der zielsystemabhän- gigen Datenstruktur zu generieren.
7. Funktionseinheit nach einem der voranstehenden Ansprüche, die dazu ausgebildet ist, ein Verfahren nach einem der Ansprüche 10 bis 19 durchzuführen.
8. Transformationssystem zur Migration und Transformation von Datenstrukturen mindestens eines Quellsystems (13) in Datenstrukturen mindestens eines Zielsystems (15) , das mindestens ein Quellsystem (13) , mindestens ein Zielsystem (15) und eine zwischen dem mindestens einen Quellsystem (13) und dem mindestens einen Zielsystem (15) gekoppelte Funktionseinheit (3) aufweist, wobei die Funktionseinheit (3) mindestens einen Import-Filter (5, 24, 41) und mindestens einen Export-Filter (7, 26, 43) aufweist, wobei der mindestens eine Import-Filter (5, 24, 41) dazu ausgebildet ist, eine von dem Quellsystem (13) bereitgestellte, in einem quellsystemabhängigen Format (17) vorliegende Datenstruktur in ein übergreifendes Beschreibungsformat (18, 28) zu transformieren, und wobei der mindestens eine Export- Filter (7, 26, 43) dazu ausgebildet ist, die in dem übergreifenden Beschreibungsformat (18, 28) vorliegende Daten- struktur in ein zielsystemabhängiges Format (19) zu transformieren und dem Zielsystem (15) bereitzustellen.
9. Beschreibungsrahmen, der zur Migration und Transformation von Datenstrukturen mindestens eines Quellsystems (13) in Datenstrukturen mindestens eines Zielsystems (15) geeignet und dazu ausgebildet ist, eine von dem mindestens einen Quellsystem (13) bereitgestellte, in einem quellsystemab- hängigen Format (17) vorliegende und über mindestens einen Import-Filter (5, 24, 41) transformierte Datenstruktur in einem übergreifenden Beschreibungsformat (18, 28) darzustellen, und die in dem übergreifenden Beschreibungsformat (18, 28) dargestellte Datenstruktur über mindestens einen
Export-Filter (7, 26, 43) in ein zielsystemabhängiges Format (19) zu transformieren.
10. Verfahren zur Migration und Transformation von Datenstrukturen mindestens eines Quellsystems (13) in Datenstrukturen mindestens eines Zielsystems (15), bei dem die von dem mindestens einen Quellsystem (13) bereitgestellte, in einem quellsystemabhängigen Format (17) vorliegende Datenstruktur über mindestens einen Import-Filter (5, 24, 41) in eine in einem übergreifenden Beschreibungsformat (18, 28) vorliegende Datenstruktur transformiert wird, und bei dem die in dem übergreifenden Beschreibungsformat (18, 28) vorliegende Datenstruktur über mindestens einen Export- Filter (7, 26, 43) in eine in einem zielsystemabhängigen Format (19) vorliegende Datenstruktur transformiert und dem mindestens einen Zielsystem (15) bereitgestellt wird.
11. Verfahren nach Anspruch 10, bei dem die in dem quellsystemabhängigen Format vorliegende Datenstruktur in Strukturelemente zerlegt wird.
12. Verfahren nach Anspruch 11, bei dem die Strukturelemente mit einer Konfigurationstabelle (49) verglichen und identifiziert werden.
13. Verfahren nach einem der Ansprüche 10 bis 12, bei dem ein neues Strukturelement automatisch in die Konfigurationstabelle (49) aufgenommen wird.
14. Verfahren nach einem der Ansprüche 10 bis 13, bei dem überprüft wird, ob Strukturelemente übersetzbar sind.
15. Verfahren nach einem der Ansprüche 10 bis 14, bei dem Strukturelemente markiert werden.
16. Verfahren nach einem der Ansprüche 10 bis 15, bei dem die /Ln dem quellsystemabhängigen Format (17) vorliegende Datenstruktur in ein hierarchisches Klassenmodell überführt und einer Bearbeitungsplattform zur Verfügung gestellt wird.
17. Verfahren nach einem der Ansprüche 10 bis 16, bei dem die in dem übergreifenden Beschreibungsformat (18, 28) vorliegende Datenstruktur gegen den mindestens einen Export- Filter (7, 26, 43) validiert und protokolliert wird.
18. Verfahren nach einem der Ansprüche 10 bis 17, bei dem aus Informationen, die in der Konfigurationstabelle (49) hinterlegt sind, dynamisch eine Programmierschnittstelle (9) generiert wird.
19. Verfahren nach einem der Ansprüche 10 bis 18, das mit einer Funktionseinheit (3) nach einem der Ansprüche 1 bis 7 durchgeführt wird.
20. Computerprogramm mit Programmcodemitteln, um alle Schritte eines Verfahrens nach einem der Ansprüche 10 bis 19 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in der Funktionseinheit (3) nach einem der Ansprüche 1 bis 7, ausgeführt wird.
21. Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines Verfahrens nach einem der Ansprüche 10 bis 19 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer Funktionseinheit (3) nach einem der Ansprüche 1 bis 7, ausgeführt wird.
EP05784106A 2005-08-30 2005-08-30 Migration und transformation von datenstrukturen Withdrawn EP1920357A1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2005/009340 WO2007025557A1 (de) 2005-08-30 2005-08-30 Migration und transformation von datenstrukturen

Publications (1)

Publication Number Publication Date
EP1920357A1 true EP1920357A1 (de) 2008-05-14

Family

ID=35500821

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05784106A Withdrawn EP1920357A1 (de) 2005-08-30 2005-08-30 Migration und transformation von datenstrukturen

Country Status (4)

Country Link
US (1) US20090055421A1 (de)
EP (1) EP1920357A1 (de)
CN (1) CN101288072B (de)
WO (1) WO2007025557A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7818665B1 (en) * 2006-06-22 2010-10-19 Advanced Micro Devices, Inc. Method and system for schema version transform verification
US8667382B2 (en) * 2006-06-28 2014-03-04 International Business Machines Corporation Configurable field definition document
CN101944128A (zh) * 2010-09-25 2011-01-12 中兴通讯股份有限公司 数据导出、导入的方法和装置
US20140122121A1 (en) * 2012-10-31 2014-05-01 Oracle International Corporation Interoperable case series system
CN104035754A (zh) * 2013-03-05 2014-09-10 北大方正集团有限公司 一种基于xml的自定义代码生成方法及生成器
CN107578168B (zh) * 2017-09-05 2020-12-29 北京首钢冷轧薄板有限公司 一种用于缺陷库移植的方法、装置及电子设备
US11182174B2 (en) * 2019-02-10 2021-11-23 Hewlett Packard Enterprise Development Lp System configuration analysis for migration
CN115037610B (zh) * 2022-04-24 2023-09-22 浙江清捷智能科技有限公司 一种自动配置系统及自动配置方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5629846A (en) * 1994-09-28 1997-05-13 General Electric Company Method and system for document translation and extraction
US5708828A (en) * 1995-05-25 1998-01-13 Reliant Data Systems System for converting data from input data environment using first format to output data environment using second format by executing the associations between their fields
FR2742245B1 (fr) * 1995-12-08 1998-01-23 Transtar Procede de manipulation de modeles de donnees utilises en genie logiciel
US6032147A (en) * 1996-04-24 2000-02-29 Linguateq, Inc. Method and apparatus for rationalizing different data formats in a data management system
US6314429B1 (en) * 1997-10-08 2001-11-06 Mitel Corporation Bi-directional conversion library
US20020099735A1 (en) * 2001-01-19 2002-07-25 Schroeder Jonathan E. System and method for conducting electronic commerce
US6748402B1 (en) * 2001-04-02 2004-06-08 Bellsouth Intellectual Property Corporation System and method for converting and loading interactive pager address books
US7016963B1 (en) * 2001-06-29 2006-03-21 Glow Designs, Llc Content management and transformation system for digital content
US20030037031A1 (en) * 2001-08-16 2003-02-20 Birder Matthew D. Mechanism for automatically generating a transformation document
US7664795B2 (en) * 2003-09-26 2010-02-16 Microsoft Corporation Apparatus and method for database migration

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007025557A1 *

Also Published As

Publication number Publication date
CN101288072A (zh) 2008-10-15
CN101288072B (zh) 2012-05-23
US20090055421A1 (en) 2009-02-26
WO2007025557A1 (de) 2007-03-08

Similar Documents

Publication Publication Date Title
DE10121790B4 (de) Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem
DE69937332T2 (de) Verfahren und Gerät zur Software-Entwicklung
DE69819188T2 (de) Programmschnittstellenumsetzer für rechner mit mehreren umgebungen
DE60220662T2 (de) Methode und system zum ausgeben von xml daten basierend auf vorberechneten kontexten und einem dokument objekt modell
WO2007025557A1 (de) Migration und transformation von datenstrukturen
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung
DE19960050A1 (de) Grafische Benutzerschnittstelle zur Entwicklung von Anwendungsbeispielen unter Verwendung einer Testobjektbibliothek
EP1176482A1 (de) Verfahren und Computerprogramm zum Herstellen einer Regelung oder Steuerung
DE19712946A1 (de) Methode zum Generieren einer Implementierung wiederverwendbarer Teile von Containern eines Workflow-Prozessmodells
DE102005046996A1 (de) Anwendungs-generischer Sequenzdiagrammerzeuger, getrieben durch eine nicht-proprietäre Sprache
DE10308725A1 (de) System und Verfahren zum Verwalten und zum Austausch von Daten eines technischen Projektes, einer technischen Anlage sowie einzelner Anlagenkomponenten
WO2015185328A1 (de) Computerimplementiertes verfahren und signalfolge für ein programm zur wiederverwendung von ausführbaren softwarekonfigurationen für softwaresysteme sowie rechneranlage und ein computerprogramm mit programmcode zur durchführung des verfahrens
DE102006039829A1 (de) Verfahren und Vorrichtung zur Anbringung von Anmerkungen oder Kommentaren an Bildern
EP2425331A1 (de) Verfahren zur erzeugung mindestens einer anwendungsbeschreibung
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
DE102021116315A1 (de) Verfahren zum Zusammenführen von Architekturinformationen
DE102004009676A1 (de) Verfahren und Systeme zum Erzeugen von Unterstützungsdateien für Befehle
DE4417393A1 (de) Eine Methode zur Herstellung spezifischer Programm-Systeme und Sammlungen von Unterstützungsprogrammen (Tools) zur Erleichterung von Programmsystem-Herstellungsarbeiten
EP2479664B1 (de) System und Verfahren zum Erzeugen eines Quellcodes für ein Computerprogramm
EP1202166B1 (de) System zur Verifikation von Software-Anwendungsmodellen in Ketten von Software-Entwurfswerkzeugen
DE102016005519A1 (de) Verfahren zur Erstellung eines Metadaten-Datenmodells für eine BI-Infrastruktur
DE102015115797B4 (de) Verfahren zum Erzeugen von elektronischen Dokumenten
EP3441919A1 (de) Verfahren zum austausch von daten zwischen engineering-tools eines engineering-systems sowie engineering-system zur durchführung des verfahrens
DE69925108T2 (de) Ableitung einer objektklasse durch vererbung, instanzierung oder klonierung
EP2757466B1 (de) Computerimplementiertes Verfahren zum Generieren von Computerprogrammcode

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080322

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20080606

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: LIER, VEIT FLORIAN

RIN1 Information on inventor provided before grant (corrected)

Inventor name: LIER, VEIT FLORIAN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20100611