IT202300003927A1 - METHOD FOR CONVERTING A SOURCE CODE AND COMPUTER PROGRAM TO IMPLEMENT THE SAID METHOD - Google Patents

Description

METHOD FOR CONVERTING A SOURCE CODE AND COMPUTER PROGRAM TO IMPLEMENT THE SAID METHOD

DESCRIPTION

Scope of application

The present invention relates to a method for converting a source code and to a computer program for implementing such method.

The method and the program in question are part of the IT sector, and in particular of the development of computer programs intended for application in various sectors, for example in that of IT platforms for banking systems.

In particular, the method and application in question are intended to be used to convert the source code of a program from one programming language (e.g. Cobol) to a different programming language.

State of the art

As is well known, the use of high-level programming languages is widespread in the IT sector, which allow programmers to develop computer programs without having to operate directly on machine language and without having to know the specific structures of the processor or processors that will execute such programs.

In recent years, there has been an increasing need to convert existing programs from the original programming language in which they were written (e.g. Cobol) into a different programming language, in order to execute the functionalities of that program with programming languages (such as Java, Swift, Python, C++, C#, etc.) that allow the use of different programming paradigms (e.g. object-oriented, structured, imperative, functional, event-based, etc.) based on more modern architectures, such as a microservices architecture, containerized, distributable on Cloud-based platforms, etc.

Such a programming language conversion activity, if performed manually, can require a high effort from the programmer in terms of energy and time required, as well as with the probability of making more mistakes when writing code in the new programming language.

For this reason, several techniques have been developed to automatically convert source code from one programming language to another. A particularly widespread technique is called "compiler to compiler", which involves the development of metaprograms that translate the code instruction by instruction.

This technique, however, is not without drawbacks.

In particular, translating instruction by instruction can compromise the efficiency of the code in the new programming language, as well as significantly reduce its readability.

Furthermore, the instruction-by-instruction translation makes the metaprogram particularly heavy when executed by the computer.

? also known is a different technique for adapting program codes written in old programming languages to current computer developments, which involves the use of so-called runtime environments. This technique involves the development of an interpreter program that runs the program (without translating its code) in a different computer environment (called runtime environment), which is able to load all the applications of the program and run them on a given platform.

However, this solution also has important limitations.

In particular, code execution in the runtime environment is very slow, because the code is executed in a less performant environment and requires additional processing by the interpreter program before the functionality can be implemented by the computer's CPU.

Presentation of the invention

The main purpose of the present invention is therefore to overcome the drawbacks manifested by the known solutions, by providing a method for the conversion of a source code and a computer program to implement this method, which allow the conversion of a source code from a programming language to a different programming language in a particularly high-performance and efficient manner.

Another object of the present invention is to provide a method for converting source code and a computer program for implementing such method, which allow the conversion of the code to be performed in particularly rapid times.

Another object of the present invention is to provide a method for converting source code and a computer program for implementing such method, which generate easily readable code.

Brief description of the drawings

The technical characteristics of the invention, according to the aforementioned purposes, are clearly evident from the content of the claims reported below and the advantages of the same will be more evident from the detailed description that follows, made with reference to the attached drawings, which represent a purely exemplifying and non-limiting embodiment thereof, in which:

? Figure 1 and Figure 2 show respective parts of a block diagram illustrating the main phases of the method in question;

? Figure 3 shows an interface of the program in question with several metadata classes indicated;

? Figure 4 shows the interface of the program in question with the metadata of a metadata class indicated;

? Figure 5 shows an example of a template code used in the method and program in question;

? Figure 6 shows a translated portion of converted source code obtained from the template code in Figure 5.

Detailed description of a preferred embodiment With reference to the attached figures, a non-limiting embodiment of the method for converting a source code and the related computer program is described below.

The method and the program in question are intended to be implemented by means of at least one electronic processor 1, in particular of a conventional type in itself, such as for example a computer, a server, a tablet, a smartphone, etc.

In particular, the program in question may be installed on a single computer, for example a programmer's computer, or be installed, at least in part, on a server (even in the cloud) and be accessible via client devices connected to the server - possibly equipped with a specific application of the program to access the functions of the latter implemented by the part of the program installed on the server.

Advantageously, in a traditional manner, the electronic computer 1 comprises a processor 2 and at least one memory 3 (also in the cloud) for storing data. Preferably, the electronic computer 1 comprises or is connected to input-output interfaces 4 (such as a monitor, a keyboard, a mouse, etc.) by means of which a user (such as a programmer) can interact with the program installed in the electronic computer 1 for the implementation of the method in question.

The characteristics of the electronic processor 1, being traditional in themselves, will not be specified further in the following as it is not necessary for the treatment of the present invention.

According to the present invention, the method in question comprises an input phase, in which the electronic processor is supplied with multiple PS portions of a source code written in a first programming language, preferably in Cobol.

Advantageously, in this input phase, the PS portions are selected by the programmer, using the input-output interfaces 4 of the electronic processor 1, in particular saving each PS portion in a corresponding file (for example of text type), preferably in the memory 3 of the latter.

Optionally, in the aforementioned input phase, the source code can be preliminarily stored all together in the memory 3 of the electronic processor 1 and subsequently the programmer proceeds to select the PS portions of interest by storing them in the corresponding files.

The method in question therefore includes an analysis phase of the aforementioned PS portions of the source code.

More specifically, this phase involves associating each PS portion of the source code with a corresponding CT category chosen from a list of CT categories stored in memory 3 of the electronic processor 1. Such CT categories may be, for example: ?Video Map?, ?Video Mask?, ?Queue Map?, ?Record Track?, ?Database Structure?, ?Queue Structure?, ?API Structure?. Each CT category is associated with corresponding MD metadata described in detail below.

The analysis phase also involves analyzing the syntactic structure of each PS portion of source code to identify certain EL elements of that PS portion, such as tables, fields, keys, data lists, value lists, functions, etc. The analysis phase then involves generating a first set I1 of MD metadata, where each MD metadata contains a corresponding EL element of the PS portion of source code.

Advantageously, this analysis phase is performed (at least in part) manually by the programmer, who associates the PS portion with one of the CT categories, identifies the EL elements of interest in the PS portion by analyzing the syntax of the latter and associates this EL element with a corresponding MD metadata.

Optionally, the analysis phase can be performed (at least in part) in an automated manner by the electronic processor 1. For this purpose, the latter has stored (in particular in its memory 3) multiple PA parsers, each associated with a corresponding CT category.

These PA parsers are pre-installed in the program installed on the computer by which the method in question is implemented, or they can also be created and added by the programmer when using the program.

In particular, each PA parser is a program that recognizes the syntactic linguistic constructs specific to the PS portion of code and translates them into MD metadata that will be used in the method in question.

In particular, according to this automatic mode, the analysis phase (at least for some PS portions of code) is performed by applying to the PS portion the corresponding parser associated with the category to which that PS portion is associated. Advantageously, MD metadata are organized in multiple CL classes, each of which includes corresponding specific metadata.

For example, MD metadata CL classes can include Domains, TypeAhead, Areas.

More specifically, the Domains CL class contains MT metadata designed to describe database data structures, such as tables, fields, keys, relations, etc. The TypeAheads CL class contains MT metadata designed to describe lists of data, in particular an MT metadata associated with each data item in the list. The Lookups CL class contains MT metadata designed to describe predefined lists of values, in particular associated with specific table fields; for example, for financial applications, they may be the status of an Invoice, such as: ?Inserted?, ?Approved?, ?Issued?, ?Cashed?.

The Areas CL class contains MT metadata designed to describe functional macro areas of the application implemented by the program defined by the source code; each of these macro areas operates on a specific set of data (for example: Customers, Invoices, Orders, Commissions, etc.).

Advantageously, each Area class contains metadata associated with corresponding functionalities, such as:

? List: displays a tabular, paginated list of data, which can be filtered by various criteria, sorted by table columns;

? Actions: actions that can be performed on single rows or on selected groups of rows, such as: invoking the modification of an element of the list, the deletion of one or more elements, the change of state, etc.;

? Insertion: functionality used to insert new elements into the macro area;

? Edit: functionality used to modify existing elements in the macro area;

? Delete: functionality used to delete existing elements in the macro area;

? Details: functionality used to show the details of an element of a macro area;

? Action: functionality used to apply transformations, even complex ones, on one or more elements of a macro area and, possibly, on several related elements of other macro areas.

Advantageously, at least following the aforementioned analysis phase, the electronic processor 1 generates a project file containing multiple cards, each containing in turn MD metadata of a corresponding CL class of metadata.

Advantageously, the electronic computer 1 is designed to implement (for example on the screen of the input-output interfaces 4) a graphical interface in which the organization of the aforementioned project file is shown and, by means of which the designer can manage the various phases of the method in question.

Some examples of this interface are illustrated in Figures 3 and 4. In particular, Figure 3 shows some CL classes of type Domain (?Audit?, ?Error?, ?Filiale?, ?Intestatario?, ?Login?, ?User?, ?Viewed?) generated using the method in the example of that figure. Figure 4 shows some metadata of one of these Domain classes, namely the ?Intestatario? class.

According to the invention, the subject method comprises a refactoring phase, in which the syntactic structure of the MD metadata of the first set I1 is modified, generating a second set I2 of MD metadata.

In particular, in this refactoring phase, it may include one or more operations, chosen for example between: deleting one or more specific MD metadata, adding one or more specific MD metadata, modifying the element contained in one or more MD metadata.

For example, referring to the example in figure 4, the operation of adding an MD metadata is enabled by the programmer using the (+) button, the operation of deleting an MD metadata using the "Delete" button, and the operation of adding an MD metadata using the "Edit" button.

In particular, the modification of the EL element of the MD metadata according to the refactoring phase involves reorganizing the code of this EL element by modifying only its syntactic structure but not its semantic structure. Some types of this modification involve:

1) rename the name of a column in a database table, for example from ?REC-AA-001? to ?ClienteId?;

2) change the data type of a column in a database table, for example from ?PIC X(30)? to ?int?;

3) change the type of an acceptance field of a video mask, for example from ?PIC X(50)? to ?ListBox?.

Advantageously, the refactoring phase is performed (at least in part) by the programmer acting through the input-output interfaces 4 of the electronic processor 1 and the interface of the program in question.

Optionally, the refactoring phase can be performed (at least partly) in an automated manner by the electronic processor 1, for example by means of specific refactoring parsers that are applied to the specific EL element of the MD metadata to modify its syntax in a certain way.

This refactoring phase, for example, allows to make the translated code more comprehensible and/or robust, and to structure the MD metadata with a configuration that makes them suitable for the implementation of the subsequent phases of the method, described below.

According to the invention, the method comprises a phase of generation of a target code, in which, in particular, the electronic processor 1 is enabled to perform operations aimed at obtaining, on the basis of the second set I2 of MD metadata discussed above, the aforementioned target code which corresponds to the translation of the original source code into a specific second programming language (for example: Java, Swift, Python, C++, C#).

Advantageously, this generation phase is enabled by the programmer using a specific command in the user interface of the program in question, indicated for example by the "build" button in the example in figure 4.

In the above generation phase, the electronic processor accesses at least one reference library LT containing multiple TP template codes written in the second programming language. An example of TP template code is shown in figure 5.

Each MD metadata is associated with one or more corresponding TP template codes, such that each such template code, when invoked, can be modified based on the corresponding MD metadata, as described below.

Then, in the generation phase, for each metadata MD, the electronic processor 1 calls at least one corresponding template code TP and, based on the element of such metadata MD, modifies the template code TP to generate a corresponding translated portion PT of source code written in the second programming language, an example of which is illustrated in figure 6. By applying the aforementioned operations of the generation phase, the method allows to obtain the target code (in the second programming language) corresponding to the entire original source code written in the first programming language.

Advantageously, each TP template code includes one or more VM placeholder variables (also called ?placeholders? in computer jargon), each of which is associated with a corresponding metadata.

In the generation phase, the electronic processor 1 replaces each placeholder variable VM with the element EL of the corresponding metadata MD, thus obtaining the corresponding translated portion PT of the target code.

Referring to the TP template code example shown in Figure 5, VM placeholder variables are indicated with the prefix ?@PLACEHOLDER? followed by the name of the corresponding MD metadata (e.g., ?DOMAIN_NAME?, ?CONTRUCTOR?, ?LIST_OF_FIELDS?, etc.).

As visible in the example in Figure 5, after the generation phase was executed, the VM placeholder variables were replaced by the EL elements of the corresponding MD metadata, thus obtaining the corresponding translated portion PT of target code.

Advantageously, in the generation phase, the electronic processor 1 executes specific emitter programs associated with corresponding TP template codes and preferably stored in the memory 3 of the electronic processor 1 itself.

More specifically, when the computer executes each of these emitter programs, it accesses the corresponding TP template code and the EL element of each corresponding MD metadata and replaces the VM placeholder variables of the TP template code with the EL element of the corresponding MD metadata.

In particular, each emitter program is a specific software module that is designed to read the structure of the TP template code and replace the VM placeholder variables with the part of the code that forms the EL element of the corresponding MD metadata.

Advantageously, the LT reference library (which contains the TP template codes) includes multiple FT families of TP template codes. Each of these FT families is associated with a corresponding CL class of MD metadata and includes corresponding TP template codes associated with corresponding MD metadata of the corresponding CL class.

In the analysis phase (discussed above), each PS portion of source code is associated with a corresponding CL class, whose MD metadata are associated with corresponding EL elements of that PS portion.

For example, if the PS portion of the source code contains a database table relating to an account holder, the PS portion is associated with a CL class ?Domain? which will be called ?Header? (as illustrated in the example in figure 3). In this last CL class, more MD metadata will be generated containing corresponding EL elements of the PS portion of the source code and indicated for example: ?Id?, ?Code?, ?name?, ?FirstName?, etc. (as illustrated in the example in figure 4).

The EL elements of such MD metadata will be modified in the refactoring phase, as discussed above, for example by changing the name of a certain variable (to make the code more readable) or the type of a variable (to make it compatible with the second programming language of the target code).

In the generation phase, the electronic processor 1 calls the TP template codes of the FT family associated with the corresponding CL class, in this case the ?Domain? class.

In this way, the VM placeholder variables of each called TP template code are replaced with the elements of the corresponding MD metadata, for example the VM placeholder variable ?@placeholder_external_domain_name? placed in the template code location relative to the table title, with the title ?Header? being the EL element of the corresponding MD metadata (as in the examples in figures 5 and 6).

Preferably, the metadata is organized in a multi-level data structure, where the first level is related to the CL class (e.g. ?Domain?, ?TypeAheads?, ?lookup?, ?Areas?), while the subsequent levels are related to the MD metadata of each CL class (e.g. as in the examples discussed above).

Advantageously, the LT reference library of TP template codes is also organized into several nested levels, in particular a first level relating to each FT family and subsequent levels relating to the TP template codes of each FT family. For example, the FT family associated with the ?Domains? class contains one or more template codes for fields, one or more template codes for indexes, etc., and each FT family associated with the corresponding ?Areas? class contains one or more template codes for List, Insert, Delete, Action, etc.

Preferably, each FT family of TP template codes (and preferably each CL class of MD metadata) is organized according to a tree data structure.

In this way, at each invocation of the generation phase, the electronic processor 1 is able, in a particularly rapid manner, to access the MD metadata and the requested TP template codes and to execute the corresponding emitter modules to generate the corresponding portions of the target code.

In particular, the electronic processor 1 accesses each FT family of TP template codes (and preferably each CL class of MD metadata) according to an "in order" visit algorithm.

As discussed above, the present invention also includes a computer program used to carry out the method described above.

In particular, such program includes at least the data structure containing the MD metadata as described above, and a reference library containing the template codes as described above,

Furthermore, this program contains instructions which, when executed by an electronic processor, the latter carries out the phases of the method described above. In particular, the phases of the method can be activated by the programmer through the components of the program interface discussed above.

The invention thus described therefore achieves the intended purposes.

Claims (10)

1. A method for converting a source code, which method is implemented by means of a computer (1) and comprises: ? an input phase, in which said electronic processor (1) is provided with input multiple portions (PS) of a source code written in a first programming language; ? an analysis phase, which includes: ? associate to each said portion (PS) a corresponding category (CT) chosen from a list of categories (CT) stored in said electronic processor (1), each category (CT) being associated with corresponding metadata (MD); ? analyze the syntactic structure of each said portion (PS) of said source code to identify certain elements (EL) of said portion (PS) of source code; ? generate a first set (I1) of metadata (MD), where each said metadata (MD) contains a corresponding said element (EL) of said portion (PS) of source code; ? a refactoring phase, in which the syntactic structure of said first set (I1) of metadata is modified, generating a second set (I2) of metadata; ? a target code generation phase, in which: ? said electronic processor (1) accesses at least one reference library (LT) containing multiple template codes (TP) written in a given second programming language, each said metadata (MD) being associated with one or more corresponding said template codes (TP); ? for each said metadata (MD), said electronic processor (1) calls at least one corresponding said template code (TP) and, on the basis of the element (EL) of said metadata (MD), modifies said template code (TP) to generate a corresponding translated portion (PT) of said source code written in said second programming language. 2. Method according to claim 1, characterized in that said metadata (MD) are organized into multiple classes (CL), each said class (CL) comprising corresponding said metadata (MD); wherein said reference library (LT) comprises multiple families (FT) of template codes (TP), each said family (FT) being associated with a corresponding said class (CL) and comprising corresponding said template codes (TP) associated with corresponding metadata (MD) of said corresponding class (CL); in said analysis phase, said portion (PS) of code being associated with a corresponding said class (CL), whose metadata (MD) are associated with corresponding said elements (EL) of said portion (PS) of source code; in said generation phase, said electronic processor (1) recalling the template codes (TP) of the family (FT) associated with the corresponding said class (CL). 3. Method according to claim 2, characterized in that each said family (FT) of template codes (TP) is organized according to a tree data structure. 4. Method according to claim 3, characterised in that said electronic processor (1) accesses each said family (FT) of template codes (TP) according to an "in order" visit algorithm. 5. Method according to any of the preceding claims from 2 to 4, characterised in that, following said analysis phase, said electronic processor (1) generates a project file containing multiple cards, each containing metadata (MD) of a corresponding said class (CL) of metadata (MD). 6. Method according to any of the preceding claims, characterized in that each said template code (TP) comprises one or more placeholder variables (VM), each of which is associated with a corresponding said metadata (MD); wherein, in said generation phase, said electronic processor (1) replaces each said placeholder variable (VM) with the element (EL) of the corresponding said metadata (MD). 7. Method according to claim 6, characterised in that in said generation phase said electronic processor (1) executes emitter programs associated with corresponding said template codes (TP), each of which emitter programs accesses the corresponding said template code (TP) and the element (EL) of each corresponding said metadata (MD) and replaces the placeholder variables (VM) of said template code (TP) with the element (EL) of the corresponding said metadata (MD). 8. Method according to any of the preceding claims, characterized in that said analysis phase is performed by applying to said portion (PS) of source code a parser (PA) associated with said category (CT) associated with said portion (PS). 9. A method according to any of the preceding claims, characterized in that said first programming language is Cobol. 10. Computer program, which includes: ? at least one data structure containing said metadata (MD); ? at least said reference library (LT) containing said template codes (TP); ? instructions which, when said program is executed by an electronic computer (1), said electronic computer (1) carries out the steps of the method according to any of the preceding claims.