NL2017709B1 - A method of and system for transforming legacy computer programs. - Google Patents
A method of and system for transforming legacy computer programs. Download PDFInfo
- Publication number
- NL2017709B1 NL2017709B1 NL2017709A NL2017709A NL2017709B1 NL 2017709 B1 NL2017709 B1 NL 2017709B1 NL 2017709 A NL2017709 A NL 2017709A NL 2017709 A NL2017709 A NL 2017709A NL 2017709 B1 NL2017709 B1 NL 2017709B1
- Authority
- NL
- Netherlands
- Prior art keywords
- legacy
- data
- database
- unique
- routines
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/76—Adapting program code to run in a different environment; Porting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/214—Database migration support
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/74—Reverse engineering; Extracting design information from source code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/02—Knowledge representation; Symbolic representation
- G06N5/022—Knowledge engineering; Knowledge acquisition
- G06N5/025—Extracting rules from data
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Artificial Intelligence (AREA)
- Computational Linguistics (AREA)
- Evolutionary Computation (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The present disclosure generally relates to the field of transforming legacy software or computer program products. More particularly the present invention relates to a method of, and server for transforming, by a legacy software transformation server, a legacy data centric computer program product having legacy program code arranged to be executed on a legacy system, to a modern computer program product having modern program code arranged to be executed on a modern system. In accordance with an aspect of the invention a method is provided for a legacy data centric computer program product having legacy program code wherein in several steps of recording, analysing, devolving and testing the legacy software is migrated towards a modern system.
Description
Title A method of and system for transforming legacy computer programs.
Technical Field
The present disclosure generally relates to the field of transforming legacy software or computer program products. More particularly the present invention relates to a method of, and server for transforming, by a legacy software transformation server, a legacy data centric computer program product having legacy program code arranged to be executed on a legacy system, to a modern computer program product having modern program code arranged to be executed on a modern system.
Background
Legacy software are computer program products having legacy computer program code. Such code can be stored and executed within a legacy system, consisting of for example old hardware arranged for instruction set architectures that are mostly outdated, phased out and not manufactured and supported anymore. Legacy software may however in some examples also be considereds software for execution on modern systems which are arranged for instruction set architectures that are currently still widely deployed, manufactured and supported, but wherein the software component in stead of the hardware component is considered out dated.
Known examples of legacy software are software applications that are programmed in old programming languages such as COBOL or Pascal. Some large systems, often being the core application or ERP suits of a SME or large company have been up and running for many years and where originally programmed a long time ago in a programming language that was common those days. Support for these old fashioned programming languages rapidly drops since software engineers who are familiar with such languages due to the age become scarce. As such, obtaining and guarantying the required amount of maintenance and support for these applications becomes more and more difficult and hence costly and time-consuming.
Migrating from such legacy software towards more modern software in which use, implementation of new features, bug fixing and general maintenance becomes less of a challenge, is thus desired and becomes even more desirable over time.
Many methods exist for transforming legacy software into such more modern software. One of the most straightforward is by converting the source code. If source code of compiled applications can be obtained, these can be converted into modern programming languages. There are however some drawbacks to such straightforward conversion. Fist of all, the source code is not always available. Secondly, if available, often the old source code is badly documented making it hard to determine what logic is programmed into the code. Thirdly, over time, some code becomes obsolete since the logic is not used any more and logic that is used, could be optimized by recoding the code in smarter routines. As such, it is not very common to simply convert source code in such a straight forward manner.
To overcome some of these drawbacks, as an alternative to the straightforward conversion of the code, it is common to rebuild the legacy software into a modern software application coded in a modern programming language for which use, implementation of new features, bug fixing and general maintenance becomes less of a challenge, and which can be executed on widely available common hardware.
In such a rebuild process a software engineer investigates the legacy software by on the one hand investigating the client side by determining which User Interfaces, Ul, exist (either graphical Uls or text/command line based Uls), and which data fields they comprise. On the other hand, the server side is investigated by determining the database schema and the database transactions as well as the logic routines that are executed from the Ul or anywhere else within the application and the transactions in the database that are triggered by these routines.
Some of the information can be determined by simply looking at, and use of the client side applications, e.g. its Uls, and others by interviewing users and software engineers responsible for the database management, application maintenance and the like. Once all information is determined the database can be migrated to a new modern system and all program code can be reprogrammed in a modern programming language. Once all is done, the new system with the modern software can be tested to reveal any inconstancies and incorrect function in respect of the original legacy software.
Even such a rebuild process for transforming legacy software has drawbacks. Many information and logic of the legacy system is to be determined from the input of users and software engineers. It is however known that users sometimes use software in an incorrect manner and that users are not trained or equipped to determine whether routines can be performed more efficiently. Moreover, sometimes input is needed to determine logic of the software that can only be given by the programmer that originally created the program. Sometimes that person is not available anymore to provide such input, he or she can be retired, be working elsewhere or even deceased. Yet another problem with the process of rebuilding is that most of the work has to be performed by a skilled software engineer that is also experienced in both the old fashioned programming language, as well as the modern programming language. In rebuilding the software from scratch the newly created software is also often different from the original legacy software that it is not recognized by the users. Hence, the users have difficulties in understanding and getting used to the new software. Such rebuild process is furthermore hard to scale or not even scalable at all since the work is to be performed by unique persons and managing an even distribution in workload between a group of such unique persons is cumbersome. An import reason therefor is that in such a process the software engineer(s) have no idea of the progress of the migration since the amount of code to be converted or recoded is unknown as is the complexity thereof. Yet another drawback is that the legacy software is often critical at an operational level within the company and that only a limited amount of time is available to receive input from users and software engineers and that the legacy software can only be decommissioned for a minimum amount of time. As such there is a need for alternative processes for transforming legacy software in which at least some of these drawbacks are resolved.
Summary
It is an object of the present invention to provide an improved method for transforming legacy software in which at least some of the above mentioned drawbacks of the known transformation methods are resolved.
It is a further object of the present invention to provide an improved method for transforming legacy software which has at least one or more of the following improvements as compared to known methods, being automation of the process to a large degree, scalability, dividing transformation process into small work units that can easily be distributed over persons working on the transformation process and which can be distributed according to level of experience, a transformation process which can be performed without having to decommission the legacy software and/or wherein the impact of transformation on the users and software engineers is minimized.
In accordance with the object of the invention, in a first aspect, there is provided a method of transforming, by a legacy software transformation server, a legacy data centric computer program product having legacy program code arranged to be executed on a legacy system to a modern computer program product having modern program code arranged to be executed on a modern system, the legacy software transformation server being arranged for performing the recording steps of: providing, to at least one computer of the legacy system, a legacy recording routine arranged for recording frontend data and backend data during a period of use of the legacy system, the recorded frontend data at least comprising one or more screens dumps of an application running on the at least one computer of the legacy system and comprising input data from a user of the at least one computer of the legacy system into the application, and the recorded backend data at least comprising database transactions performed on a database of the legacy system; obtaining, a database schema of the database of the legacy system obtaining, from the at least one computer of the legacy system, the recorded frontend and backend data; wherein the legacy software transformation server is further arranged for performing the analyzing steps of: determining, by analyzing the recorded backend data, unique database transactions; determining, by analyzing the frontend data, unique screens for the application; determining one or more unique zones for each unique screen; determining one or more of a dynamic and static data field in each unique zone; determining one or more unique logic routines at least for the least one dynamic data field, wherein the logic routines correspond with at least one unique database transaction; determining for each logic routine whether the logic routine comprises a CRUD (create, read, update, delete) logic function or complex logic routines such as a calculation; determining a logic function for each unqiue logic routine, wherein the CRUD logic functions are determined by comparing a data input and a database transaction performed in response to the data input, and wherein the complex logic routines are determined by machine learning, by iterativly analyzing several data input with one or more database transactions performed in response to the data input; and wherein the legacy software transformation server is further arranged for performing the devolping steps of: creating on at least one computer of the modern system, a database having a database schema corresponding with the obtaining database schema and copying data from the database of the legacy system to the database created on the computer of the modern system; creating applications arranged to be executed on the modern system, the applications corresponding to the determined application, comprising Uls having screens and data fields as well as logic routines as determined; and wherein the legacy software transformation server is further arranged for performing the testing step of: testing the created applications on the modern computer system by executing test routines comprising execution of each unique logic routine and determining whether the database transactions and data presented in dynamic data fields on the modern system correspond with database transaction and data presented in dynamic data fields on the legacy system.
Legacy software is considered software having computer program code that is considered not up-to-date to modern standards. Not being up-to-date to modern standards could apply to the software and/or to the hardware. Hardware can be out-dated and not supported anymore and the software could be linked or restricted to some degree to the use of such out-dated hardware. On the other hand, the software itself could be out-dated, e.g. due to the fact that the software cannot be maintained anymore since it was written in a programming language that nobody understands anymore these days. Such out-dated software could run on out-dated, i.e. legacy, hardware, but could also run on modern hardware as well.
Up until a certain moment in time it is still beneficial to keep the legacy system up-and-running and not to migrate towards a new modern system having modern computer architectures and code written in modern programming languages. However, the problems relating to the legacy system will increase over time since bugs and new features can not be fixed or implemented and software engineers that have the skills required to work in the legacy code become even more scarce. In some situations, the software does not even have software engineers that are able to perform such maintenance since the only person(s) that are skilled enough have deceased, or the external service provider has gone bankrupt. As such, it is only a matter of time until a company that uses such legacy software needs to migrate towards a modern system with modern code.
Several ways are known to migrate from the legacy system. A way of migrating is to maintain the original code and to run the code within an emulated environment, e.g. within a virtual machine. Another common and straightforward way of migrating is to recode the software code into a modern programming language. For example, low level code is converted to a higher level language from where its functions/routines can be compiled by modern compilers into binary code that is arranged for computers with modern architectures like X86 and ARM. Amongst others, such way of migration has the drawback that bad coding is recoded into the newly migrated code. Software bugs, flaws/errors in the code etc. are also migrated and contained in the new code. As such, migration in such a way introduces new problems and the goal of migrating the legacy software in order to patch/fix such bugs, flaws/errors is not achieved. Moreover, code that has become obsolete or is only rarely used, is also recoded and becomes part of the new code. This unduly adds to the size and complexity of the new code making it a sloppy way of migration introducing new problems that need to be solved.
As an alternative, the legacy software can also be analysed by a highly skilled software engineer that is able to determine what user interfaces the software uses, what logic routines are behind it and what effect it has on the backend, e.g. the database and its transaction performed thereupon. Key users and current maintainers of the legacy software can inform the software engineer to determine what how the software works, and hence how the modern migrated version should work as well. Amongst other, this approach has the drawback that it is very hard to determine on forehand how big of a project the migration will be. Accordingly, it hard to determine the impact of the migration process which makes managing such a transition very difficult. Moreover, sometimes key user and current maintainers are unaware of incorrect use of the software, are not fully informed of all aspect of the software or what the function is of some undocumented routines. And these maintainers are sometimes external companies that have been hired to perform the maintained and sometimes these companies go bankrupt. This may result in legacy code can is unmaintainable. Finally, the key users and maintainers are often biased, since the current legacy software is their only reference and sometimes a product they actively contributed on. As such, they are not objective in evaluating the code and the necessity of its routines.
The present invention, in an aspect thereof, provides a solution by removing such subjectivity by introducing a method of transforming, by a legacy software transformation server, a legacy data centric computer program product having legacy program code arranged to be executed on a legacy system to a modern computer program product having modern program code arranged to be executed on a modern system.
The method is arranged to be performed by a legacy software transformation server which could be a single server solution, preferably a cloud based application, an application installed on a local server in the network of the legacy system or a hybrid solution of the foregoing.
The method consists of several steps wherein in the first step data and information in general is obtained through a recorder. Once the information is obtained, or even in parallel with the recording of the date/information, a step of analysing is performed. Once the analysing is completed the development step can be started wherein the new modern software is devolved. Once the rebuilding by the development step is complete the new modern software is tested before taking into operation.
In the first step of the process a recorder is provided by the legacy software transformation server, transformation server for short. The recorder is arranged to record frontend data and backend data. Preferably, a single recorder is provided that is arranged to record both. However, in an another example, two dedicated recorders are provided, one for the frontend that is arranged to be installed on a client computer of the legacy system and one for the backend that is arranged to be installed on a server of the legacy system. Due to the fact that the present method for migration of the legacy software is particularly suitable for data centric software applications, for example having tier 1, but preferably tier 2 or 3 computer architectures, the recording takes place both at a client side and at a server side, e.g. on the backend database.
The legacy recording routine is preferably a standalone software routine that can be provided or distributed by the transformation server or any other distribution device, e.g. a digital distribution platform like an app store for computer applications for mobile, portable and stationary devices. A user of the legacy software can download the frontend recorder on their computer, e.g. client or server. Once downloaded and installed, the legacy recorder records several aspects which can be attributed to the frontend data and the backend data.
What is recorded at least comprises screen dumps of one or more User Interfaces, Uls, which can be graphical user interfaces or command line user interfaces. Furthermore, the user input is recorded as well. The Uls are preferably recorded by a screen grabber routine, e.g. either through a series of images or through a video sequence, and the user input is preferably recorded by at least a key logger and preferably a routine to record other input commands for example from a mouse or another human input device. The recording is preferably done at certain fixed intervals or through continuously logging any action, or by only logging any transition on the screen, or input data from the keyboard or another input device such as a computer mouse. Preferably, the input data is a trigger for the screen capturing routine and new screen dumps are only made when input data is received, e.g. when a mouse click or keyboard input is detected.
In the recording phase the database of the legacy system is also recorded, or at least parts of the database. What is meant is that the database schema of the database of the legacy system is extracted such that in the devolvement phase a database can be created according to the same database schema. This has the advantage that the database transactions of the legacy system can be converted to the modern database without having to change the function of the database transactions. Once the new modern database is created, the data can be copied from the legacy system towards the modern database. The step of extracting the database schema and creating the new database can be done prior to recording the frontend data, during the recording of the frontend data or afterwards during the analysing or development phase.
Once all data is recorded the computer, e.g. one or more clients and/or one or more servers of the legacy system, the data can be uploaded towards the transformation server for further processing. Preferably, the transformation server starts with pre-processing the data by separating the screen recording elements from the data input from the user. The pre- processing can comprise an analysis of a video stream recorded at the computer and analysing the different screens in the stream. The different screens can be recognized by detecting changes in between the recorded images. By example, the detection can be performed by analysing the individual pixels and transitions of pixels which can be an indication for distinction between screens. The skilled person will appreciate that other techniques are also applicable to detect the different screen, e.g. image segmentation routines and the other computer vision techniques.
Once all data is pre-processes, needless to say is that the preprocessing is an optional step, the actual analysing can be performed. Even before all recordings have finished the analysis can start which is preferable done from a cloud based solution. For example, a long period of time can be defined in which the recording is performed. The time period of recording is preferable in correspondence with a time defined on forehand in which it is almost certain that at least all main functions of the legacy software have been used during that period of time, such that it is guaranteed that these main function at least can be analysed and hence taken into consideration for development in the development stage.
The analysis stage is aimed at determining all relevant aspect or element of the legacy software. More in particular by determining all screens that have been recognized and determining its properties and elements. Even more in particular, what is to be determined from the screens is what applications can be recognized, and what data fields these applications comprise. All the data fields within the applications are presented through one or more Uls. This Ul (or the Uls) has a layout in which several data fields can be recognized. One or more data fields together can form a zone.
In the analysis stage all screens are processed. For each screens one or more zones are defined. Defining the zone is preferably done by the transformation server receiving user input such that it is up to the decision and determination of a user to define the zones. In another example, the transformation server itself can automatically define the zones, for example by machine learning routines in which the server has access to a database containing a large amount of historical zone definitions from which the server can learn how to make such decisions.
However, as indicated, in the preferred method the definition of the zones within the screen is done by a user of the transformation server. This could be in principle any user, e.g. of the company of the legacy system, a service provider related to the transformation server, or a third party or an individual from a group of support members which are registered to participate in such transformation/migration projects.
Each zone is preferably defined according to its function. For example, a zone could have the function of receiving one or more input data fields in which the user of the legacy software can enter for example address details of a transaction order. A zone could also have the function of performing an action such as reading data from a database table, updating data into a database table, or performing a calculation on data in the database. The zone to this end can comprise static data fields and/or dynamic data fields. The static data fields could for example relate to a text label providing information to the user for a corresponding dynamic data field in which data records can be entered or in which data records can be showed, e.g. upon performing a database lookup.
The static data fields of the screens and in particular in the zones defined in the screens, is preferably recognized by Optical Character Recognition, OCR routines. These routines can be comprised in the transformation software of the transformation server, but can also be routines that are available from third parties. For example, through an API the transformation server can send a graphical image of a zone or static or dynamic data field of the zone through such an API to a third party. What is returned is a text based data field which can be used in the development stage to recreate the data field in an automated manner.
The screens preferably relate to a function and as such the method preferably comprises a step in which each screen is defined with a function, e.g. a function name and preferably a data table of the database to which the function relates.
Preferably each zone is defined with a zone type, which can be any one or more of the group consisting of menu, list, form, actions, filters, or other. As such, the function or type of the zone can be distinguished and recognized. Moreover, the elements of the zone, thus the dynamic and static fields may have labels. These labels are determined preferably by the transformation server, e.g. through internal or external OCR routines. The labels and label text can also be determined by a user of the server or initially by the server itself and validated by the user or only validated by the user when the server is not able to (guarantee) the correct recognition of the label and label text.
Dynamic data fields of the zones not only provide static information to the user of the Ul of the software application, but the content of the data field can change or can trigger certain actions in the application. As such, the dynamic data fields need to be determined whether or not to contain logic routines, e.g. routines to create, read, update, delete database records, perform calculations, initiate further actions, provide information through popups, etc. The method is preferably arranged to determine logic routines of the data fields by analysing the recordings. What is meant is that upon triggering the dynamic data field, e.g. by entering data or by clicking a button or pull-down menu, the action triggered will have effect on the application. Thus, either data fields in the screen, i.e. the Ul, or data in the database is effected by such action. By for example comparing data on the basis of corresponding (text) data strings and/or timing intervals, the transformation server is arranged to links between the logic routines and its result or output. As such, it is not only possible to determine how and where data fields of the application are linked, i.e. one dynamic data field is changed/updated when another dynamic data field is triggered, but also possible to determine what the function of the logic routine is.
Once all zones within all screens have been defined and all data fields have been determined it can be determined how many unique logic routines the data fields can trigger. In an example, the logic routines can also be triggered not from the Uls on the client side of the application, but in a background process thereof. An example thereof would be a scheduled updating of certain records, e.g. process all order receipt the last one hour and update the database table containing the stock levels such that the current stock levels are updated in accordance with all orders received. Other background processes may trigger logic routines that relate to frequent or non-frequent updates for example for making backups. These routines may be performed and/or initiated on the client but also on the server or directly from within the database or database management system. All logic routines in one way or the other will cause any change in the state of the system, thus either in the database which can be determined by the database transaction, and/or in the Ul which can be determined by (graphical) changes in the screens of the Ul.
Once all logic routines are determined, these can be linked to database transaction, and it can be determined whether the routines either comprise simple or complex logic functions. Simple logic functions would be considered those logic routines having logic functions that are linear, direct, straightforward, and thus only comprise Create, Read, Update, Delete, CRUD, logic functions. The content of the black box approach of the logic routine is then straightforward since the server only needs to determine if the content (logic function) is one of the CRUD functions.
The unique logic routines having non-CRUD logic functions difficult to determine. A black box approach in which input is compared with the output to determine the content of the black box and thus determine the set of operations that are performed in the black box is preferably performed by many iterations in which input data and output data is compared and analysed. Machine learning techniques can be used to perform such iterations and analysing. Several machine learning techniques can be applicable such as decision tree learning techniques, association rule learning, artificial neural networks, deep learning, inductive logic programming, support vector machines, clustering, Bayesian techniques, reinforcement learning, representation learning, similarity and metric learning, sparse dictionary learning, generic or genetic algorithms, rule-based machine learning, learner classifier systems etc. In many of these techniques, a data set is analysed and patterns are detected between input and response, such in several repeating, e.g. iterative, steps.
The data can be data specifically generated for that purpose or data contained in the recorded data by the recorder routine during use of the legacy software.
Preferably, the transformation server is arranged to determine a likeability or correctness level of the determined unique logic routine. For example by comparing the original logic routine with the rebuild logic routine and by testing several scenarios and determine if they respond exactly the same, mostly the same or only party. Those logic routines that do not respond exactly the same can be provided to a user for a manual validation step in which the user is able to determine if the rebuild logic routine should be accepted, rejected or modified.
Once everything is recorded and analysed, the transformation server starts developing. The development however could also be performed in parallel to the analysing, e.g. by starting to develop Uls and/or logic routines for those parts of the Ul and/or logic routines that have been determined so far during the analysing stage.
Each Ul of the original legacy application that is actually used during the period of recording, is recreated at the development step. The layout of each screen of the UI or Uls is determined from the screens recorded and graphically or in respect to its layout rebuild in the development step. All element in the Ul such as the dynamic and static data fields are rebuilt into the new Ul or Uls. In accordance with the data fields in the Ul or Uls of the legacy system the ones that are linked to a logic routine, e.g. the dynamic data fields, are linked to the determined logic routines that are built during the development stage as well. Accordingly, all functions of the modern software application correspond with the functions of the legacy software application.
Prior to testing the database is migrated as well, which means that a database scheme is obtained of the database of the legacy system and a new database is generated with the same scheme on the modern system. Once created, the data is migrated towards the new database.
Once all is completed the final step of testing is performed wherein the modern system and is newly created computer program is executed and put in use. The response of the newly created program is compared in a parallel session with the legacy system to determine if both systems respond equally. For any remaining element in which that is not the case, a software engineer is informed to for manual modification of the incorrect Ul elements, data fields, logic routines or database transactions.
Accordingly, in comparison with the known methods of migrating legacy software, in an aspect of the invention, a method is provided wherein the time needed to determine the specifications for the modern system by analysis of all Uls and logic routines or business rules, is significantly reduced. Moreover, significant increase in processing of the following is also obtained; creating copies of the Uls, determining which properties of the Ul or backend comprise hidden complex logic routines, creating test scenario’s, incorporating logic routines on the basis of the specifications, keeping the process of migration under control and providing information of the progress.
Moreover, in an aspect of the invention, a method is provided wherein management of the process is scalable since large migration projects can simply be scaled by adding server resources for recording, analysing, devolving and testing, optional manual operations on the migration can be divided over multiple software engineers and can be divided according to level of complexity (complex logic routines vs. Ul layout. Also, the subjectivity of the key users and current maintainers of the legacy software is removed as well by the automated objective computer implemented method of migration. Finally, obsolete code or code or routines that are not used very frequently can also be removed as well, or more in particular not migrated in to the new modern software.
In an example, prior to said steps of analysing, said legacy software transformation server is further arranged for performing the steps of: pre-processing said obtained recorded frontend and backend data, wherein said pre-processing preferably comprises any one or more of dividing said data into frontend and backend data, dividing user input from screen dumps, dividing screen dumps into separate screens.
As indicated, the recorded data is preferably pre-processed such that is can be analysed in the following steps. The advantage is that, once received and pre-processed, the data can be devided into several screens which can be easily distributed over several users for a team based, scalable approach in the transformation process of the legacy system.
In an example, the legacy software transformation server is further arranged for performing the steps of: determining for each screen a function definition at least comprising a function name declaration and a data table of the database relation.
Preferably, each screen comprises several zones, and each screen has a function definition declaration such that is can be recognized and preferably linked to data of the database, e.g. of a particular data table of the database.
In an example, one or more of the steps of determining unique database transactions, unique screens, unique zones of the screens, dynamic data fields, static data fields and logic routines are automatically performed by the transformation server.
In an example, the legacy software transformation server is arranged to receive a user input for validating at least one of the determinations of one or more of determining unique database transactions, unique screens, unique zones of the screens, dynamic data fields, static data fields and logic routines.
Preferably, any element in the steps of the analysing is performed fully automatically by the server. No user interaction is required. However, more preferably, user interaction is provided upon analysing of such element, e.g. zones, screens, data fields, logic routines, etc, in which the server is not a hundred process sure that the recorgitions is correct. This could for example be implemented by text recognition in which the recorgnized characters correspond only party with a original image, or wherein outcome of a certain routine is only linked to a limited amount of input data such that the exact logic fuction cannot be determined, or wherein the outcome of a logic function does not fully correspond with the outcome in response to input data in that is input in the corresponding logic routine of the legacy system, etc. For such cases, the server preferably provides the user with an input request wherein validation of the element is requested.
In an example, the legacy recording routine is arranged to receive for process by providing to the transformation server, additional interfaces, manuals, batch processing jobs through the legacy recording routine.
Prior to the analysing, and after obtaining the recorded data, the server can be arranged to provide a user, e.g. a user of the legacy system, with an interface in which the user can enter additional information relating to the legacy system. Examples thereof are information relating to the current use of hardware for the system, known hardware requirements, information relating to the current use of the software such as type of database, supplier, version, dependencies, etc. Also non hardware or software related questions can be asked such questions relating to the use like maximum amount of concurrent users, location of use, devices used as client computer etc. The information thus obtained can be used to specify the modern system such that for example it is not over-specified and corresponds with the modern version of the legacy software. The user interface is preferably provided in the form of a dashboard. The dashboard preferably provided information relating to the recorder, the analyser and the builder, i.e. the development. Through the dashboard the legacy system can be modelated to the new system in which the additional questions can add to reduction in hardware. Moreover, the dashboard can provide the user with information relating to a system status which has a criticality level wherein high criticality can indicate an urge for migration based on for example level of support available for the current hardware and software used. Moreover, the dashboard can provide info relating to the status of the overall process of the migration and can be used to divide individual tasks to individual employees working on the migration process.
In an example, the modern computer program product is arranged for a web-based client-server system.
Most preferably, the modern computer is modern server architecture which can be access through a web interface by several client devices. These could be desktop computer, portable computers like laptops or mobile devices like tablets or smarthones.
In an example, the legacy software transformation server is further arranged for performing the steps of: storing each unique logic routine determined during the steps of analysing in a storage means such as a database, and wherein the transformation server is further arranged for re-use of unique logic routines stored in the database in further legacy software transformation processes.
Upon finishin several migration processes the Uls and more preferably the logic routines determined therein can be stored and reused for further, future transformation processes. This can significantly save time in the devolpment stage.
In an example, a performance of the machine learning in determining logic functions of unique logic routines is increased by storing each unique logic routine determined during the steps of analysing in a storage means such as a database and by analysing corresponding stored unique logic routine of multiple further legacy software transformation processes.
Machine learning routines can be made more effective in iterations of performing the routines of recorgnizing the logic routines. This not only add on an individual logic routine level, but also on a large level over several projects and full processes of transformation and hence on the basis of a big data set of historic machine learned routines.
In an example, the text of a Ul of the computer program product of the legacy system is determined by OCR routines, and wherein the OCR routines are performed by the transformation server or through an external server.
Preferably, the text recorginition is done by an OCR routine. This could be build into the legacy system and thus form part of the method, but it can also be arranged to send an image (screen, zone or element thereof such as a data field) and receive a text string in return.
In an example,the legacy software transformation server is arranged to provide a legacy recording routine for frontend data recording to one or more client computer of the legacy system and a legacy recording routine for backend data recording to one or more server of the legacy system.
The recorder or legacy recording routine is preferably a single application that can be downloaded and installed on either a client and/or a server. The recorder can however also be dedicated for a client, i.e. frontend system, or for a server, i.e. backend sytem.
In an example, the step of analysing the obtained recorded frontend data comprises determining properties of the Ul being at least one or more of the group comprising Ul layout, position of static data fields in the Ul, position of dynamic data fields in the Ul, data type of the data fields, relations between the Ul and a further Ul, active buttons within the Ul, declarations of the data fields.
In an example, the step of determining the zones comprises determining a level of reliability of automatic recognition of data fields of the zones and wherein for data fields having a determined reliability recognition level below a pre-determined threshold the data fields are tagged for manual validation, and the method further comprises the step of providing a user of the legacy software transformation server for the purpose of manual validation, with the data fields tagged for manual validation and obtaining from the user an input value whether the data fields are correctly recognized.
Since machine learning and OCR is not considered fault proof, a reliability level can be defined which can be used as a threshold for the user to get involved and validate the suggestion of the server.
In an example, the step of analysing the obtained recorded backend data for determining database transactions comprises determining a transaction type for the transaction, wherein the transaction type in particular is any one of the group comprising batch transaction, interface transaction, user transaction or remaining transaction.
In an example, the step of analysing the obtained recorded backend data for determining database transactions comprises differentiating the transactions between CRUD functionality and complex transactions. CRUD functionality is straightforward, but on the otherhand some logic routines are complex. The CRUD functionality once recognized as such, can be separated from the complex routines since the latter require additional matter to determine its function, e.g. by artificial intelligence like machine learning routines.
In an example, the step of determining the unique logic routines comprises determining a level of reliability of automatic recognition of logic routines and wherein for logic routines having a determined reliability recognition level below a pre-determined threshold the logic routines are tagged for manual validation, and the method further comprises the step of providing a user of the legacy software transformation server for the purpose of manual validation, with the logic routines tagged for manual validation and obtaining from the user an input value whether the logic routines are correctly recognized.
In accordance with the reliability of the recognized text, a level of reliability of recorgnition of the logic routines is preferably provided. As such, logic routines with a reliability level below a pre-defined threshold are set for user involvement by manual validation by the user.
In an example, the legacy software transformation server defines for each step of the method being performed a sequential progress indication value and wherein the progress indication value is presented to a user of the legacy software transformation server for determining the progress of the transformation of the legacy software.
An advantage of the present invention is that not oly the way of migration is scalable but it is also arranged to indicate the progress of the process.
In an example, the legacy software transformation server comprises a database having a plurality of database transactions and unique logic routines determined during the steps of analysing.
In an example, the legacy software transformation server is arranged to generate a hash value for each transaction and unique logic routine stored in the database and wherein the hash value is stored in the database as well.
In an example, the legacy software transformation server is arranged to compare, prior to storing the transaction and unique logic routine in the database a hash value generated for a unique transaction or a unique logic routine is present in the database and for storing the unique transaction or a unique logic routines for which a corresponding hash value is absent in the database.
The re-use of logic routines is preferably arranged by storing each logic routine determined. Upon analysing new logic routines, in an example, a hash can be generated for the logic routine and the database can accessed to determine if such a hash is present therein. If that is the case, the logic routine can be re-used without the need for developing it.
In a second aspect of the invention legacy software transformation server, for transforming, by the legacy software transformation server, a legacy data centric computer program product having legacy program code arranged to be executed on a legacy system to a modern computer program product having modern program code arranged to be executed on a modern system, the legacy software transformation server comprising a recording module arranged for: providing, to at least one computer of the legacy system, a legacy recording routine arranged for recording frontend data and backend data during a period of use of the legacy system, the recorded frontend data at least comprising one or more screens dumps of an application running on the at least one computer of the legacy system and comprising input data from a user of the at least one computer of the legacy system into the application, and the recorded backend data at least comprising database transactions performed on a database of the legacy system; obtaining, a database schema of the database of the legacy system obtaining, from the at least one computer of the legacy system, the recorded frontend and backend data; wherein the legacy software transformation server comprising a analysing module arranged for: determining, by analysing the recorded backend data, unique database transactions; determining, by analysing the frontend data, unique screens for the application; determining one or more unique zones for each unique screen; determining one or more of a dynamic and static data field in each unique zone; determining one or more unique logic routines at least for the least one dynamic data field, wherein the logic routines correspond with at least one unique database transaction; determining for each logic routine whether the logic routine comprises a CRUD (create, read, update, delete) logic function or complex logic routines such as a calculation; determining a logic function for each unique logic routine, wherein the CRUD logic functions are determined by comparing a data input and a database transaction performed in response to the data input, and wherein the complex logic routines are determined by machine learning, by iteratively analysing several data input with one or more database transactions performed in response to the data input; and ; wherein the legacy software transformation server comprising a development module arranged for: creating on at least one computer of the modern system, a database having a database schema corresponding with the obtaining database schema and copying data from the database of the legacy system to the database created on the computer of the modern system; creating applications arranged to be executed on the modern system, the applications corresponding to the determined application, comprising Uls having screens and data fields as well as logic routines as determined; and the legacy software transformation server comprising a testing module arranged for: testing the created applications on the modern computer system by executing test routines comprising execution of each unique logic routine and determining whether the database transactions and data presented in dynamic data fields on the modern system correspond with database transaction and data presented in dynamic data fields on the legacy system.
In a third aspect of the invention a computer program product comprising a computer readable medium having computer program code stored on a non-volatile memory for causing a processor to execute the method according to any of the previous descriptions.
The above and other aspects of the disclosure will be apparent from and elucidated with reference to the embodiments described hereinafter.
Brief description of the Drawings
Figure 1 show a flowchart comprising the steps of a method of transforming a legacy compute program product according to the first aspect of the invention;
Figure 2 shows a legacy software transformation server according to a second aspect of the invention.
Detailed description
Reference numeral 10 in Figure 1 designates the flowchart of the computer implemented method according to an aspect of the invention. The method or computer implemented invention is arranged for transforming, by a legacy software transformation server, a legacy data centric computer program product having legacy program code arranged to be executed on a legacy system to a modern computer program product having modern program code arranged to be executed on a modern system.
The first step, step 11, is the recording step and step comprises providing, to at least one computer of the legacy system, a legacy recording routine arranged for recording frontend data and backend data during a period of use of the legacy system, the recorded frontend data at least comprising one or more screens dumps of an application running on the at least one computer of the legacy system and comprising input data from a user of the at least one computer of the legacy system into the application.
The recorded backend data at least comprises database transactions performed on a database of the legacy system and further comprises obtaining, a database schema of the database of the legacy system. Further the method comprises obtaining, from the at least one computer of the legacy system, the recorded frontend and backend data.
The second step, step 12, is the analysing step. This step comprises several further sub steps of determining, by analyzing the recorded backend data, unique database transactions, and determining, by analyzing the frontend data, unique screens for the application. Moreover, what is further determined is one or more unique zones for each unique screen and determining one or more of a dynamic and static data field in each unique zone as well as determining one or more unique logic routines at least for the least one dynamic data field, wherein the logic routines correspond with at least one unique database transaction. Finaly what is also determined is for each logic routine whether the logic routine comprises a CRUD (create, read, update, delete) logic function or complex logic routines such as a calculation. At last, what is determined is a logic function for each unqiue logic routine, wherein the CRUD logic functions are determined by comparing a data input and a database transaction performed in response to the data input, and wherein the complex logic routines are determined by machine learning, by iterativly analyzing several data input with one or more database transactions performed in response to the data input; and
The third step, step 13, is the building or development step. During this step, the code and Uls are created by creating on at least one computer of the modern system, a database having a database schema corresponding with the obtaining database schema and copying data from the database of the legacy system to the database created on the computer of the modern system.
Moreover, what also is created during the building step is creating the applications arranged to be executed on the modern system, the applications corresponding to the determined application, comprising Uls having screens and data fields as well as logic routines as determined.
The final fourth step, step 14, is the test step and it comprises at least the step of testing the created applications on the modern computer system by executing test routines comprising execution of each unique logic routine and determining whether the database transactions and data presented in dynamic data fields on the modern system correspond with database transaction and data presented in dynamic data fields on the legacy system.
In figure 2 a system is shown which at least consists of a transformation server 20 having a recording unit 21, a analysing unit 22, build or development unit 23, and a test unit 24. These are all connected to the central processing unit 25 of the device 20. The central processing unit consist of a processor and memory for storing and executing the code to enable the method in the first aspect of the invention.
While the disclosure has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive; the disclosure is not limited to the disclosed embodiments.
For example, it is possible to perform the several steps of the method on several devices, e.g. on a distributed system, a hybrid solution, remote and/or local devices, cloud bases architectures, etc.
Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measured cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. Any reference signs in the claims should not be construed as limiting the scope thereof.
Claims (22)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NL2017709A NL2017709B1 (en) | 2016-11-02 | 2016-11-02 | A method of and system for transforming legacy computer programs. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NL2017709A NL2017709B1 (en) | 2016-11-02 | 2016-11-02 | A method of and system for transforming legacy computer programs. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| NL2017709B1 true NL2017709B1 (en) | 2018-05-18 |
Family
ID=58402098
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| NL2017709A NL2017709B1 (en) | 2016-11-02 | 2016-11-02 | A method of and system for transforming legacy computer programs. |
Country Status (1)
| Country | Link |
|---|---|
| NL (1) | NL2017709B1 (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060235899A1 (en) * | 2005-03-25 | 2006-10-19 | Frontline Systems, Inc. | Method of migrating legacy database systems |
| US20110153530A1 (en) * | 2009-12-22 | 2011-06-23 | Software Ag | Method and system for analyzing a legacy system based on trails through the legacy system |
-
2016
- 2016-11-02 NL NL2017709A patent/NL2017709B1/en active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060235899A1 (en) * | 2005-03-25 | 2006-10-19 | Frontline Systems, Inc. | Method of migrating legacy database systems |
| US20110153530A1 (en) * | 2009-12-22 | 2011-06-23 | Software Ag | Method and system for analyzing a legacy system based on trails through the legacy system |
Non-Patent Citations (4)
| Title |
|---|
| A SULAIMAN: "The CRUD Cube", WIT TRANSACTIONS ON INFORMATION AND COMMUNICATION TECHNOLOGIES, vol. 29, 1 January 2003 (2003-01-01), XP055379440, ISSN: 1743-3517 * |
| ANONYMOUS: "Create, read, update and delete - Wikipedia", 27 October 2016 (2016-10-27), XP055379463, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Create,_read,_update_and_delete&oldid=746408761> [retrieved on 20170608] * |
| DI FRANCESCOMARINO C ET AL: "Reverse Engineering of Business Processes exposed as Web Applications", SOFTWARE MAINTENANCE AND REENGINEERING, 2009. CSMR '09. 13TH EUROPEAN CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 24 March 2009 (2009-03-24), pages 139 - 148, XP031448026, ISBN: 978-0-7695-3589-0 * |
| INÊS COIMBRA MORGADO ET AL: "GUI reverse engineering with machine learning", REALIZING AI SYNERGIES IN SOFTWARE ENGINEERING, IEEE PRESS, 445 HOES LANE, PO BOX 1331, PISCATAWAY, NJ 08855-1331 USA, 5 June 2012 (2012-06-05), pages 27 - 31, XP058057562, ISBN: 978-1-4673-1753-5, DOI: 10.1109/RAISE.2012.6227966 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10423403B1 (en) | Utilizing a machine learning model to predict metrics for an application development process | |
| JP7398068B2 (en) | software testing | |
| Lenarduzzi et al. | The technical debt dataset | |
| US10860312B1 (en) | Defect ownership assignment system and predictive analysis for codebases | |
| US20210279577A1 (en) | Testing of Computing Processes Using Artificial Intelligence | |
| US11907107B2 (en) | Auto test generator | |
| US11790256B2 (en) | Analyzing test result failures using artificial intelligence models | |
| US11954461B2 (en) | Autonomously delivering software features | |
| US11733975B1 (en) | System and method for migrating legacy software to a system common architecture | |
| Jia et al. | An empirical study on bugs inside tensorflow | |
| KR20210148346A (en) | Automated identification of code changes | |
| US11651272B2 (en) | Machine-learning-facilitated conversion of database systems | |
| US20190303115A1 (en) | Automated source code sample adaptation | |
| Dam et al. | DeepSoft: A vision for a deep model of software | |
| US10929159B2 (en) | Automation tool | |
| Schlie et al. | Clustering variation points in matlab/simulink models using reverse signal propagation analysis | |
| US11853196B1 (en) | Artificial intelligence driven testing | |
| NL2017709B1 (en) | A method of and system for transforming legacy computer programs. | |
| US11599454B2 (en) | Natural language processing (NLP)-based cross format pre-compiler for test automation | |
| Panikkar et al. | Operationalizing machine learning in processes | |
| US20220309335A1 (en) | Automated generation and integration of an optimized regular expression | |
| Siavvas et al. | A self-adaptive approach for assessing the criticality of security-related static analysis alerts | |
| NL2027854B1 (en) | Automatic testing of interrelated components of a software application | |
| Dwarakanath et al. | Software Defect Prediction Using Deep Semantic Feature Learning | |
| Eng et al. | Predicting Defective Visual Code Changes in a Multi-Language AAA Video Game Project |