Object-oriented system, and creation method of object-oriented system

The object-oriented system addresses the challenge of migrating from COBOL to Java by automating the generation of accessor and template classes, ensuring high-speed batch processing and improved maintainability.

JP2025160765APending Publication Date: 2025-10-23HITACHI LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2024063536
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-04-10
Publication Date
2025-10-23

AI Technical Summary

Technical Problem

Existing systems face challenges in migrating from COBOL to Java while ensuring high-speed batch processing and maintaining ease of implementation, readability, and reusability.

Method used

An object-oriented system that generates accessor source code for input and output files, utilizing an automatic generation mechanism to create input and output accessor classes and intermediate template classes, reducing dynamic conversion overhead.

Benefits of technology

Enables high-speed batch processing during migration from COBOL to Java, improving implementation ease and maintainability by automating the generation of accessor and template classes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025160765000001_ABST
    Figure 2025160765000001_ABST
Patent Text Reader

Abstract

To provide an object-oriented system capable of ensuring ease of implementation while ensuring high speed during batch processing of the system in migrating from an existing language to an object-oriented language.SOLUTION: The object-oriented system creates an accessor source code, of a business source code and an accessor source code corresponding to an application written in any object-oriented language, for each job in batch processing in which multiple jobs with different inputs and outputs are executed in a predetermined order. An input accessor source code 730 that performs binary data processing for each item included in the input file includes an unconverted source code that does not convert binary data into object-oriented language data for each item in the input file, and a conversion source code for converting binary data into object-oriented language data for each item in the input file.SELECTED DRAWING: Figure 7
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to an object-oriented system using an object-oriented language and a method for creating an object-oriented system. [Background technology]

[0002] Institutions that supply or intermediate funds include banks, Japan Finance Corporations, Shinkin banks, insurance companies, and securities companies. There are also institutions that operate systems aimed at protecting depositors and policyholders, and stabilizing the financial system.

[0003] Among the operations performed by these institutions, there are some that have characteristics that vary with each operation in terms of the amount of data handled by the information processing system. Due to these characteristics, the amount of data handled in these operations is expected to be in the hundreds of millions. Furthermore, the performance requirements for batch processing by the information processing system used for these operations may also require that all batch processing for such a huge amount of details be completed within a few days. Therefore, it is necessary to complete specific processing for the largest amount of details within a specified time.

[0004] Incidentally, current banking systems are often created using COBOL (Common Business Oriented Language). COBOL is a general-purpose procedural programming language suitable for accounting and administrative processing. The institutions mentioned above are replacing systems and data created using historical programming languages ​​like COBOL with systems that use modern programming languages.

[0005] For data volumes in the hundreds of millions, converting all input records (including unused fields) from COBOL to Java (registered trademark), an object-oriented language, would take too much time to process. As a result, it would be impossible to complete batch processing within the expected time. While it is possible to speed up conversion by directly handling binary data as input data, this is not easy to implement. There are concerns about reduced readability for Java-type data, reduced maintainability due to poor design, and reduced reusability for different batch processing.

[0006] For example, Patent Document 1 describes a method for creating an object-oriented system aimed at improving the productivity, maintainability, and reliability of software that handles data items. In the method for creating an object-oriented system described in Patent Document 1, object-oriented components consisting of a data section and a procedure section that define specification information related to input and output and procedure information indicating the processing content are created for each data item in a business processing program that processes the data items, and are stored in a library, an object-oriented component that responds to a request from the business processing program is selected from the library, an item object is generated as an executor for the data item that the business processing program is to process, and an object-oriented system that performs data item processing dependent on the business processing program is constructed using the item object. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Application Publication No. 7-152550 Summary of the Invention [Problem to be solved by the invention]

[0008] However, Patent Document 1 does not mention ensuring ease of implementation while ensuring high speed batch processing of the system in a migration scenario from an existing language such as COBOL to an object-oriented language such as Java.

[0009] The present invention has been made in consideration of the above situation, and aims to ensure ease of implementation while ensuring high speed during batch processing of the system when migrating from existing languages ​​such as COBOL to object-oriented languages ​​such as Java. [Means for solving the problem]

[0010] To solve the above problems, an object-oriented system according to one aspect of the present invention creates accessor source code from among business source code and accessor source code corresponding to applications written in an arbitrary object-oriented language, corresponding to each job in batch processing that executes a plurality of jobs with different inputs and outputs in a predetermined order. The object-oriented system includes a reception unit, an input accessor source code generation unit, an output accessor source code generation unit, and an accessor source code writing unit. The receiving unit receives a format definition, which is a definition of items that constitute input and output files of an application. The input accessor source code generation unit reads a format definition relating to the input file, identifies items included in the input file to the application, and generates input accessor source code that processes binary data for each item included in the input file. The output accessor source code generation unit reads a format definition for the output file, identifies items to be included in the output file to the application, and generates output accessor source code that converts object-oriented language data into binary data for each item included in the output file. The accessor source code writing unit writes the generated input accessor source code and output accessor source code into a source code file. The input accessor source code includes non-conversion source code that does not convert binary data into object-oriented language data for each item included in the input file, and conversion source code that converts binary data into object-oriented language data for each item included in the input file. [Effects of the Invention]

[0011] According to at least one aspect of the present invention, in a migration scenario from an existing language to an object-oriented language, it is possible to ensure ease of implementation while ensuring high speed during batch processing of the system. Problems, configurations, and effects other than those described above will become apparent from the following description of the preferred embodiments of the invention. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram showing an outline of a general Java development process. [Figure 2] FIG. 1 is a diagram showing an outline of a development process when applying the automatic generation mechanism of the present invention. [Figure 3] FIG. 1 illustrates an example of batch processing in an information processing system. [Figure 4] FIG. 2 is a block diagram illustrating an example of the hardware configuration of a computer included in an automatic generation mechanism according to an embodiment of the present invention. [Figure 5] FIG. 1 is a diagram illustrating an example of a mechanism of a conventional information processing system. [Figure 6] FIG. 1 is a diagram illustrating an example of a mechanism of an information processing system capable of achieving high-speed processing performance according to a conventional technique. [Figure 7] 1 is a diagram (1) showing a schematic configuration example of an information processing system according to an embodiment of the present invention. [Figure 8] FIG. 2 is a diagram (2) showing an example of a schematic configuration of an information processing system according to an embodiment of the present invention. [Figure 9] FIG. 10 is a diagram showing an example of a definition table used in one embodiment of the present invention. [Figure 10]FIG. 2 is a diagram illustrating an example of the configuration of a job and a definition according to an embodiment of the present invention. [Figure 11] FIG. 1 is a diagram showing the flow of a development process when an automatic generation mechanism is not applied (conventional). [Figure 12] FIG. 1 is a diagram showing an overview of a development process when an automatic generation mechanism according to an embodiment of the present invention is applied. [Figure 13] FIG. 1 is a diagram (1) showing details of an automatic generation mechanism (accessor generation function) according to an embodiment of the present invention. [Figure 14] FIG. 2 is a diagram (2) showing details of the automatic generation mechanism (template generation function) according to one embodiment of the present invention. [Figure 15] FIG. 10 illustrates an example file input in an auto-generation mechanism according to one embodiment of the present invention. [Figure 16] FIG. 10 is a diagram showing an example of record information of an input file in an automatic generation mechanism according to an embodiment of the present invention. [Figure 17] FIG. 10 is a diagram showing an example of a procedure for batch processing by a Java application when an automatic generation mechanism according to an embodiment of the present invention is applied. DETAILED DESCRIPTION OF THE INVENTION

[0013] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, examples of modes for carrying out the present invention (hereinafter referred to as "embodiments") will be described with reference to the accompanying drawings.

[0014] In this specification and the accompanying drawings, identical or similar components are given the same reference numerals, and redundant explanations may be omitted or only explanations focusing on the differences may be given. Furthermore, when there are multiple identical or similar components, they may be described using the same reference numerals with different subscripts. Note that when it is not necessary to distinguish between these multiple components, the subscripts may be omitted in the description. The number of each component may be singular or plural unless otherwise specified.

[0015] In the following embodiment, various types of information are described in table format, but the various types of information may be in a data format other than a table format. Furthermore, various names such as "XX information," "XX table," "XX list," and "XX list" are interchangeable. Furthermore, when describing identification information, expressions such as "identification information," "name," and "ID" are used, but these are interchangeable.

[0016] [General Java application development process] First, the development process of a typical Java application will be explained with reference to Figure 1. Figure 1 shows an overview of the development process for a typical Java application. In typical Java development and execution, development is carried out according to the following process to realize the functions of an information processing system.

[0017] A developer U1 operates a PC (Personal Computer) to create source code 20 based on a design document 10 that reflects the business processing content, and implements the source code 20 in an information processing system. Next, in a JDK (Java Development Kit) 30, which is required for software development in JAVA, a Java compiler 31 creates a class file 41 (Java compilation) of a Java application 40 using the source code 20 as input data. The Java compiler 31 is a program that reads and analyzes the source code 20 written in a high-level programming language (high-level language) and creates a binary language. The class file 41 is a binary file. Next, the class file 41 (binary file) is read in a Java operating environment (such as a Linux server). Linux is a registered trademark.

[0018] The JDK 30 includes a JRE (Java Runtime Environment) 32 for executing software developed in the Java language. The JRE 32 reads class files 41 of a Java application 40 and executes various processes implemented by the source code 20. Examples of the various processes include inputting a file 51, outputting a file 52, and updating a database (DB) 53.

[0019] The DB contains information handled by the information processing system, such as account information. The file is composed of information output from the DB, so it contains information equivalent to the DB.

[0020] [Development process when using the automatic generation mechanism] Next, the development process when the automatic generation mechanism of the present invention is used will be described with reference to FIG. Figure 2 is a diagram showing an outline of the development process when applying the automatic generation mechanism of the present invention. In Figure 2, developer U1 creates source code 20 based on design document 10 that reflects the business processing content and implements it in an information processing system, just like in Figure 1.

[0021] The present invention automatically generates in advance a process for dynamic interpretation using a common process. As shown in Fig. 2, in the present invention, an automatic generation mechanism 200 uses data from a design document 10 as input to generate source code 210. The automatic generation mechanism 200 automatically generates the source code itself in the Java language. Then, a JDK 30 combines the source code 20 by a developer U1 with the automatically generated portion (source code 210) by the automatic generation mechanism 200, and compiles it using a Java compiler 31 to create a Java application.

[0022] Batch Processing Next, batch processing in the information processing system will be described with reference to FIG. 3 is a diagram showing an example of batch processing in an information processing system. Batch processing in an information processing system is performed at night when online processing is not being performed, for example, for the purpose of system maintenance or the creation of reports that do not require real-time performance.

[0023] The job management system 300 shown in FIG. 3 is operation management software for an information processing system. The job management system 300 is a job scheduler that manages the execution of programs executed on the system. The job scheduler manages the execution of jobs, which are a series of programs that are repeatedly executed for the operation and management of the information processing system. The job management system 300 performs batch processing, such as starting programs at a fixed time daily. Batch processing is not realized by a single Java application, but is usually realized by combining multiple separate Java applications (jobs).

[0024] 3, the job management system 300 manages jobs 1, 2, 3, 4, and 5, and executes batch processing for jobs 1 to 5 at 11:00 PM every day. In job 1, Java application 1 reads data from DB1 and creates a data file in file format 1. Next, in job 2, Java application 2 changes file format 1 to file format 2. After job 2 ends, jobs 3 and 5 are executed. In job 3, Java application 3 changes file format 2 to file format 3. After job 3 finishes, job 4 is executed. In Job 4, Java application 4 saves a data file of file format 3 to file format 5 in DB2. In addition, in job 5, Java application 5 creates a report from a data file in file format 2.

[0025] In this way, batch processing continues towards the final process (in this case, report creation) while modifying the file. A single file is input / output from multiple Java applications. Generally, processing is performed to add configuration information for each file detail. For example, in the case of a file with details that include account information, the input file may contain information such as "account number, opening date, name, and address." In that job, another table is referenced using the account number as a key to determine whether the account is still active, and this information is converted into information such as "account number, opening date, name, address, and target account active flag." In this way, processing is performed while adding additional information to the file so that it will ultimately be reduced to its original form.

[0026] [Computer hardware configuration] Next, the hardware configuration of the computer 400 that constitutes the automatic generation mechanism 200 will be described. 4 is a block diagram showing an example of the hardware configuration of the calculator 400. The calculator 400 is an example of hardware used as a computer capable of operating as the automatic generation mechanism 200 according to this embodiment. The automatic generation mechanism 200 according to this embodiment realizes the generation of accessor source code and templates, which are performed in cooperation with each functional block shown in FIGS. 7 and 8, and FIGS. 13 and 14, which will be described later, by the calculator 400 (computer) executing a program.

[0027] The computer 400 shown in Fig. 4 includes a CPU (Central Processing Unit) 401, a ROM (Read Only Memory) 402, a RAM (Random Access Memory) 403, a display device 404, an input device 405, a non-volatile storage 406, and a communication interface 407. Each component can transmit and receive data to and from each other via a system bus. The CPU 401, the ROM 402, the RAM 403, and the non-volatile storage 406 constitute a control unit. This control unit is an example of a computer that controls the operation of each component of the automatic generation mechanism 200.

[0028] The CPU 401 reads out program code of software that realizes each function according to this embodiment from a ROM 402 (an example of a recording medium), loads it into a RAM 403, and executes it. Variables, parameters, etc. generated during the calculation processing of the CPU 401 are temporarily written to the RAM 403, and these variables, parameters, etc. are read out by the CPU 401 as appropriate. The CPU 401 executes the program code read out from the ROM 402, thereby realizing the functions of each functional block in the automatic generation mechanism 200. However, other processors such as an MPU (Micro Processing Unit) may be used instead of the CPU 401. Information is temporarily stored in the RAM 403 during the procedures of various classes, which will be described later.

[0029] The display device 404 is a monitor such as a liquid crystal display, and displays a GUI screen, the results of processing performed by the CPU 401, etc. The input device 405 generates an input signal according to a user's operation and outputs it to the CPU 401. The input device 405 may be, for example, a mouse or a keyboard, and the user can operate the input device 405 to input information and instructions.

[0030] The nonvolatile storage 406 is an example of a recording medium, and is capable of storing data used by a program, data obtained by executing a program, and the like. In addition to an operating system (OS) and various parameters, the nonvolatile storage 406 may also store programs for causing the computer 400 to function. As the nonvolatile storage 406, a hard disk drive (HDD), a solid state drive (SSD), an optical or magnetic disk medium, a semiconductor memory card, or the like may be used. Files and databases output by Java applications are permanently recorded in the nonvolatile storage 406 (for example, a disk medium).

[0031] For example, a network interface card (NIC) or the like is used as the communication interface 407. The communication interface 407 is configured to be able to transmit and receive various data to and from external devices via a communication network such as a LAN or the Internet connected to a terminal of the NIC or the like, or a dedicated line or the like.

[0032] A similar configuration can also be used for a computer used by a developer in a development environment for the Java language. Note that the display device 404 and the input device 405 may be omitted from the automatic generation mechanism 200.

[0033] [Mechanism of conventional information processing systems] Here, the mechanism of a conventional information processing system will be described with reference to FIG. Fig. 5 is a diagram showing an example of the structure of a conventional general information processing system. A business program 500 shown in Fig. 5 reads data from an input file 510, performs predetermined processing, and generates an output file 540. The business program 500 corresponds to the Java application shown in Fig. 3.

[0034] (1) First, the business program 500 reads a unit record of binary data from the input file 510. A unit record is, for example, one record, and corresponds to the data for one account in a bank. (2) Next, the business program 500 executes the generation of the input record class 520. The business program 500 generates an input record class (target data and method settings) every time one record is processed.

[0035] (3) The business program 500 divides one record into fields, converts them into Java types, and sets them in the input record class 520. As an example, the input record class 520 can be realized by a DTO (Data Transfer Object). A DTO is an object that brings together related data and defines methods for storing and reading data.

[0036] In business program 500, the input record class is dynamically created using the definition file for input file 510 as input. The definition file has a one-to-one relationship with the input file. Here, the read input record (binary data) is converted into a Java type, including unused fields and fields that do not need to be edited, and set in the input record class. Processes (2) and (3) are created generically and are executed dynamically according to the definitions. Therefore, when there is a large amount of detail, processes (2) and (3) become a bottleneck.

[0037] FIG. 5 shows examples of items A, B, and C of an input record. Item A is a String class, and the data of item A is string type data. Item B is a BigDecimal class, and the data of item B is numeric data. Item C is a String class, and is string type data.

[0038] (4) Next, the business program 500 executes the generation of the output record class 530. As an example, the input record class 520 can be realized by a DTO (Data Transfer Object). (5) The business program 500 obtains item A of the input record class 520 and sets it in the output record class 530. (6) The business program 500 also acquires item B of the input record class 520 and sets the calculation result in the output record class 530.

[0039] (7) The business program 500 also sets item D in the output record class 530 (in this case, the definition does not set item C). In the example of Figure 5, item D is a String class (character string data). For example, item D is generated by editing other items. In this example, three items, A, B, and D, are set in the output record class, but the number of items may be less than the number of items in the input record class. For example, of the details "account number," "name," and "balance," there may be a case where you want to use only two items, "account number" and "name," after data migration.

[0040] (8) Next, the business program 500 converts the output record class 530 into one record of data. In the case of a large number of details, this process (8) also becomes a bottleneck. (9) Next, the business program 500 writes the data of the one record to the output file 540. (10) The business program 500 repeats the above-mentioned processes (1) to (9) for the number of input records in the input file 510.

[0041] The conventional mechanism shown in Figure 5 has a configuration that can be said to be the de facto standard when developing in the Java language, and although it is easy to develop, it has a slow execution speed.

[0042] [Mechanism capable of achieving high-speed processing performance] Next, the mechanism of an information processing system that can achieve high-speed processing performance according to the prior art will be described with reference to FIG. FIG. 6 is a diagram showing an example of the structure of an information processing system that can achieve high-speed processing performance according to the prior art. (1) First, the business program 600 reads one record of data (binary data) from the input file 610.

[0043] (2) Next, the business program 600 allocates an output record area 630 in memory. Here, it allocates areas for items A, B, and D. At this stage, the actual data for items A, B, and D has not been set.

[0044] (3) Next, the business program 600 obtains item A of the input record and sets it in the output record area 630. The process of obtaining item A of the input record (which item to obtain) is implemented for each business program. In other words, which item to obtain from the input record differs for each business program.

[0045] (4) Next, the business program 600 obtains item B of the input record, converts it to a BigDecimal type, and then sets the calculation result in the output record area 630. Numerical items that require calculations are stored in little endian format, and by converting them to BigDecimal type, high-speed processing becomes possible. Little endian is one of the byte orders (endian) used when recording / transmitting data consisting of multiple bytes (multibyte), and is a method of handling data in order from the least significant byte to the most significant byte.

[0046] (5) Next, the business program 600 sets item D in the output record area 630.

[0047] (6) Next, the business program 600 writes the data of one record including items A, B, and D set in the output record area 630 to the output file 640. (7) The business program 600 repeats the above-mentioned processes (1) to (6) for the number of input records in the input file 610.

[0048] The mechanism shown in Figure 6, which can achieve high-speed processing, can achieve performance equivalent to that of current COBOL, i.e., high-speed processing. However, it is difficult to implement because it must be implemented in an information processing system while minimizing binary data conversion. In the Java language, binary data is not usually handled as is. The mechanism shown in Figure 6 is not easy to implement, so there are concerns about defects and reduced readability. Business program 600 can achieve high-speed processing, but it is not easy to maintain. In other words, a mechanism that can achieve this high-speed processing performance is not easy to develop, but has a fast execution speed. The processing generated by the present invention, described below, combines the contradictory functions of the mechanisms shown in Figures 5 and 6.

[0049] [Mechanism of the information processing system of the present invention] Next, the structure of an information processing system according to one embodiment of the present invention will be described with reference to Figures 7 and 8. Note that the various information such as items and files shown in Figures 7 and 8 and the above-mentioned Figures 5 and 6 are complete in their respective illustrative units and are not necessarily related to each other.

[0050] FIG. 7 is a diagram (1) showing an example of a schematic configuration of the mechanism of the information processing system according to this embodiment. FIG. 8 is a diagram (2) showing an example of a schematic configuration of the mechanism of the information processing system according to this embodiment. (1) As shown in Fig. 7, first, a business program 700 reads data (binary data) of one record from an input file 710. A business program 700 exists for each job.

[0051] (2) Next, the business program 700 executes generation of an input accessor class 730. In object-oriented programming such as Java, an accessor is a method provided for externally accessing member variables (attributes, properties) within an object.

[0052] (3) Next, the business program 700 sets the input data for one record in the input accessor extraction class 720. The input accessor extraction class 720 extracts each item from the input record and passes the data for each item to the input accessor class 730. Here, items A, B, and C are set in the input accessor extraction class 720. The input accessor class 730 and the input accessor extraction class 720 are automatically generated by the accessor generation unit 201 of the automatic generation mechanism 200 in Fig. 8. This automatic generation process will be described later.

[0053] Target data and a method are set for each item in the input accessor class 730. The input accessor class 730 basically acquires the data of the target item, selects whether to convert or not convert the acquired data as needed, and returns (outputs) the data after converting it as needed.

[0054] 7, a brief description will be given of the processing of the input accessor class 730 for item A. In the input accessor class 730, string type data, a string type conversion flag, binary type data, and a binary type conversion flag are set for item A. The accessor class itself is a well-known technique.

[0055] In the procedure for the retrieval process (String) for the first item A, (procedure 1) the binary corresponding to item A is extracted from the data of the input record, (procedure 2) it is converted to a string, (procedure 3) the string type conversion flag is set to "true", and (procedure 4) the data is returned. In the procedure for the second retrieval process (binary) for item A, (procedure 1) extracts the binary corresponding to item A from the input record data, (procedure 2) sets the binary type conversion flag to "true", and (procedure 3) returns the data. By setting the flag, the data type can be recognized.

[0056] Although not shown, procedures of the input accessor class are set for items B and C as well, for both conversion to character strings and non-conversion.

[0057] (4) The business program 700 copies the input record to the intermediate template class 740. The intermediate template class 740 processes the copied binary data. That is, the intermediate template class 740 acquires the binary data of each item from the input accessor class 730 and sets the binary data of each item in the output accessor class 760. The intermediate template class 740 is automatically generated by the template generation unit 202 of the automatic generation mechanism 200 in FIG. 8. This automatic generation process will be described later.

[0058] 7, the intermediate template class 740 (procedure 1) acquires item A (binary) from the input accessor class 730, and (procedure 2) sets item A (binary) in the output accessor class 760. The intermediate template class 740 also (procedure 3) acquires item B (binary) from the input accessor class 730, and (procedure 4) sets item B (binary) in the output accessor class 760. Processing not targeted by the intermediate template class 740 is executed in the next process (5).

[0059] In the output accessor class 760, target data and a method are set for each item. The output accessor class 760 basically sets the data of the target item. In the example of FIG. 7, in the procedure for the setting process (String) for item A, (procedure 1) character string data is converted to binary data, and (procedure 2) the data is set. Although not shown in the figure, for items that do not need to be converted to binary data, they are set directly in the output accessor class 760 via the intermediate template class 740. Output accessor class procedures are also set for items B and D.

[0060] (5) The business program 700 acquires items requiring calculation processing from the input accessor class, performs the necessary calculations, and then sets the items in the output accessor class. In the example of Fig. 7, the business program 700 acquires item B of the input accessor class 730 and sets the calculation results in the output accessor class 760. The output accessor class 760 and the output accessor extraction class 750 are automatically generated by the accessor generation unit 201 of the automatic generation mechanism 200 in Fig. 8. This automatic generation process will be described later.

[0061] (6) The business program 700 obtains an output record (binary) from the output accessor class 760. Here, the output accessor extraction class 750 extracts the items set in the output accessor class 760 and outputs them as one record data (output record). In the example of Fig. 7, one record data including items A, B, and D is output from the output accessor extraction class 750.

[0062] (7) Next, the business program 700 writes the one record data acquired from the output accessor class 760 to the output file 770 . (8) The business program 700 repeats the above-mentioned processes (1) to (8) for the number of input records in the input file 710.

[0063] In this way, the information processing system shown in Figure 7 automatically generates classes corresponding to data items in advance. The data is stored as binary data, and specific items are converted to Java types depending on the business processing. The business application uses accessors to associate one record of binary data with each item. In addition, an application programming interface (API) is created for each processing unit.

[0064] The business program also executes the following processes (1) to (8). (1) Read a unit record of binary data (one account in a bank) from the input file. (2) Generate an input accessor class for each item (item A, B, C, ...) (3) Set the input record (4) Copy the input record (5) Obtain the items that require calculation in the input accessor class and set the calculated results in the output record class. (6) Obtaining binary output records from the output accessor class (7) Write to the output file (8) Repeat steps (1) to (7) above for the number of input records.

[0065] (Automatic generation mechanism) Next, the outline of the configuration of the automatic generation mechanism 200 shown in FIG. 8 will be described. The automatic generation mechanism 200 comprises an accessor generation unit 201 and a template generation unit 202. The functions of the accessor generation unit 201 and the template generation unit 202 are realized by the CPU 401 of the computer 400 (FIG. 4) executing a program. The automatic generation mechanism 200 operates during development in the Java language, but does not operate during batch processing after development.

[0066] 7 based on the format definition. The accessor generation unit 201 also automatically generates an input accessor extraction class 720 associated with the input accessor class 730, and an output accessor extraction class 750 associated with the output accessor class 760.

[0067] FIG. 8 shows examples of an input format definition 810 (format A) and an output format definition 820 (format B). The input format definition 810 defines that item A is four-digit character string data. Similarly, item B is four-digit numeric data, and item C is four-digit character string data. The output format definition 820 defines that item A is four-digit character string data, item B is four-digit numeric data, and item C is four-digit character string data.

[0068] One input accessor class 730 is generated for each input file definition. The file definition can be reused in other Java applications in the same batch process. For example, in Figure 3, in the case of Java application 2 and Java application 3, the output file (file format 2) of the former becomes the input file of the latter. Since the output file and input file also have the same file definition, they can be reused in other Java applications.

[0069] The template generation unit 202 creates convenient APIs such as copy processing for each batch process. In this embodiment, an intermediate template class 740 is generated as the API. As will be explained in detail later, the template generation unit 202 automatically generates source code for performing common processing for the common parts (here, items A and B) between the input format definition 810 and the output format definition 820, as an example. By using various accessors in the procedures of the intermediate template class 740, the business program 700 can be implemented without having to be aware of binary data.

[0070] In FIG. 8, examples of input file definition 830 (file A), input file definition 840 (file B), and batch definition 850 are shown. The input file definition 830 (file A) defines that the file format is "fixed length binary" and the file format is "format A." The input file definition 840 (file B) defines that the file type is "fixed length binary" and the file format is "format B."

[0071] In the batch definition 850, it is defined that the file ID of input file 1 is "file A." It is also defined that the file ID of output file 1 is "file B."

[0072] In the conventional mechanism shown in Figure 5, process (2) and process (3) are created generically and change according to the definition. The automatic generation mechanism 200 does not dynamically use the definition, but automatically generates classes (input accessor extraction, input accessor, output accessor, intermediate template) in advance based on the definition file. This reduces the cost of generating dynamic DTOs (input record class 520, output record class 530).

[0073] Definition Table Next, the definition table used in this embodiment will be described with reference to FIG. In automatic generation, Java source code is output using batch definition, file definition and format definition. The positioning of each definition is as follows.

[0074] 9 is a diagram showing an example of a definition table 900. The definition table 900 includes the following fields: #, definition name, definition unit, management ID, and definition content. The # item stores information indicating the record number (row number) of the definition table. The definition name field stores information indicating the name of the definition. The definition unit item stores information indicating the element to which the definition applies or the range to which the definition applies. The management ID field stores information indicating an ID (an example of an identifier) ​​for managing the definition. The definition content item stores information indicating the content of the definition.

[0075] For example, in record #1, the definition name is "batch definition", the definition unit is "job unit", the management ID is "batch ID", and the definition content is "call class of target job, input / output file ID".

[0076] In record #2, the definition name is "file definition", the definition unit is "linked to batch definition, input / output unit of target job", the management ID is "file ID", and the definition content is "format ID of target file". In addition to the format ID, the definition content also includes the file type and record length as item elements of the target file. In other words, the file definition is information that defines the link with the format definition that stipulates the file type, record length, and format components. The length of one record is determined, for example, by the design of the business process, that is, by the record elements required for the Java application used in the business process. As an example, in the definition unit items, if there is one file input and one file output, it can be expressed as "input 1 and output 1".

[0077] In record #3, the definition name is "format definition", the definition unit is "linked to file definition, format unit of target file", the management ID is "format ID", and the definition content is "item elements of target format". Examples of item elements include item name, length, Java data type, padding, trimming, etc. The format definition defines the format of the file data. An accessor can be generated by using these three definitions.

[0078] [Job and definition configuration] Next, the configuration of jobs and definitions according to this embodiment will be described with reference to FIG. Fig. 10 is a diagram showing an example of the configuration of jobs and their definitions. The job management system 1000 shown in Fig. 10 manages jobs 1 and 2. A batch ID is set for each job as an argument when a Java application is executed.

[0079] Generally, the definition is linked from the specified batch ID and referenced while the Java application is running. In Fig. 10, the runtime argument 1020 for Java application 1 is the batch ID "BATCH0001". Below are examples of each definition when the batch ID is "BATCH0001".

[0080] An example of a batch definition 1030 with a batch ID of "BATCH0001" in which the input file ID is "FILE0001" and the output file ID is "FILE0002" is shown.

[0081] As a file definition 1040 for a file ID of "FILE0001", an example is shown in which the file type is "fixed length binary", the record length is "30", and the format ID is "FORMAT0001". An example of a file definition 1040 with a file ID of "FILE0002" is shown, where the file type is "fixed length binary" and the record length is "50." The format ID is header "FORMAT0002" and data "FORMAT0003."

[0082] Furthermore, examples of the format definition 1050 with the format ID "FORMAT0001" and the item names "key", "itemA", and "itemB" are shown. If the item name is "key", the length is "1", the Java data type is "String", padding is "none", and trimming is "none". If the item name is "itemA", the length is "20", the Java data type is "String", the padding is "half-width space", and the trimming is "half-width space". If the item name is "itemB", the length is "9", the Java data type is "String", the padding is "half-width space", and the trimming is "half-width space".

[0083] Also, examples of the format definition 1050 with a format ID of "FORMAT0002" are shown, each with item names of "key", "itemA", "itemB", and "itemC". If the item name is "key", the length is "1", the Java data type is "String", padding is "none", and trimming is "none". If the item name is "itemA", the length is "20", the Java data type is "String", the padding is "half-width space", and the trimming is "half-width space". If the item name is "itemB", the length is "9", the Java data type is "String", the padding is "half-width space", and the trimming is "half-width space". If the item name is "itemC", the length is "20", the Java data type is "String", the padding is "half-width space", and the trimming is "half-width space".

[0084] [Traditional development process before automatic generation] Next, the flow of the development process when the automatic generation mechanism of the present invention is not applied (conventional) will be described with reference to FIG. Figure 11 is a diagram showing the flow of the development process when the automatic generation mechanism is not applied (conventional). The flow of the development process shown in Figure 11 is a more detailed version of the outline of the development process shown in Figure 1. The following will focus on the parts of Figure 11 that are different from Figure 1.

[0085] As shown in Figure 11, the developer U1 creates source code 20 based on a design document 10 that reflects the business processing content and implements it in the information processing system. In Figure 11, developer U2 (which may be the same person as developer U1) operates a PC to implement a batch definition 1030, a file definition 1040, and a format definition 1050 in the information processing system.

[0086] JRE 32 reads class files 41 of Java applications 40 and executes various processes implemented by source code 20. JRE 32 reads various definition files when executing various processes and executes the processes. As mentioned above, when a definition file is dynamically referenced at runtime, all items in the read input record are converted to objects, and this conversion becomes an overhead that limits performance.

[0087] [Development process when applying the automatic generation mechanism] Next, the flow of the development process when the automatic generation mechanism of the present invention is applied will be described with reference to FIG. 12 is a diagram showing the flow of a development process when the automatic generation mechanism according to this embodiment is applied. The automatic generation mechanism 1200 in the diagram corresponds to the automatic generation mechanism 200 (FIGS. 2 and 8). In this embodiment, the automatic generation mechanism 1200 generates accessor source code 1210 in advance. The accessor source code 1210 corresponds to the source code 210 in FIG. 2 and the source code of various accessors in FIG. 8.

[0088] The accessor source code 1210 does not unconditionally convert all items, but automatically generates a conversion process for each item, as shown in FIG. 13, which will be described later. In this embodiment, when the source code 20 is implemented, the automatically generated API is executed. The Java compiler 31 reads the source code 20 and the accessor source code 1210, performs Java compilation, and creates a class file 41 of the Java application 40. In this embodiment, the JRE 32 does not read a format definition at runtime.

[0089] [Details of the automatic generation mechanism] Next, the automatic generation mechanism 1200 according to this embodiment will be described in detail with reference to FIGS. FIG. 13 is a diagram (1) showing the details (accessor generation function) of the automatic generation mechanism 1200. FIG. 14 is a diagram (2) showing the details (template generation function) of the automatic generation mechanism 1200.

[0090] As described above, the automatic generation mechanism 1200 automatically generates Java language source code (accessor source code 1210) using the batch definition 1030, file definition 1040, and format definition 1050 as input. The automatic generation mechanism 1200 itself is constructed as a Java application and runs on the developer's PC terminal. There are no physical restrictions, such as a specific server. The automatic generation mechanism 1200 runs as automatic generation software in the same way as Java source code implementation.

[0091] 13 and 14, automatic generation mechanism 1200 includes accessor generation function 1300 and template generation function 1400. Accessor generation function 1300 corresponds to accessor generation unit 201 (FIG. 8), and template generation function 1400 corresponds to template generation unit 202 (FIG. 8).

[0092] (Accessor generation function) First, the accessor generation function 1300 will be described with reference to FIG. The accessor generation function 1300 reads the format definition 1050 by reading the format definition 1301. Here, the format definition of the format ID "FORMAT0001" is shown as an example.

[0093] Next, the accessor generation function 1300 starts scanning the read format definition 1050 item by item, and executes accessor process generation 1302 for each item. The accessor process generation 1302 is repeated until the scanning for each item is completed. The accessor generation function 1300 generates the accessor source code 1210 (accessor class). The accessor generation function 1300 automatically generates a process based on the information set for each item of the format definition 1050.

[0094] 13, a non-conversion pattern (high speed) and a conversion pattern (low speed) are generated as key area acquisition processing. In key area acquisition processing (non-conversion) 1310 and key area acquisition processing (conversion) 1311, target item area acquisition is performed to acquire information from byte 0 to byte 1. In addition, in key area acquisition processing (conversion) 1311, target item conversion (conversion to String type) is performed.

[0095] Similarly, a non-conversion pattern (high speed) and a conversion pattern (low speed) are generated for the itemA area acquisition process. The itemA area acquisition process (non-conversion) 1320 and itemA area acquisition process (conversion) 1321 execute target item area acquisition to acquire information from the 1st byte to the 21st byte. The itemA area acquisition process (conversion) 1321 also executes target item conversion (convert to String type, trimming with half-width spaces).

[0096] Additionally, a non-conversion pattern (high speed) and a conversion pattern (low speed) are generated for the itemB area acquisition process. The itemB area acquisition process (non-conversion) 1330 and itemB area acquisition process (conversion) 1331 execute target item area acquisition to acquire information from the 22nd byte to the 31st byte. The itemB area acquisition process (conversion) 1331 also executes target item conversion (convert to BigDecimal type, trimming with half-width spaces).

[0097] Here, only the acquisition process in the accessor source code 1210 is shown, but the setting process is also automatically generated. As with the acquisition process, both a high-speed non-conversion version and a low-speed conversion version are prepared for the setting process. Both setting processes ultimately create binary data.

[0098] When implementing the business process designed in the design document 10, the source code 20 calls the accessor API (for example, the template source code 1410 in FIG. 14). The template source code 1410 corresponds to the intermediate template class 740 in FIG. 7. Basically, the processing speed is ensured by executing a non-conversion API. However, this embodiment also has flexibility, such as the ability to execute a conversion API as needed for calculation processing, etc. The source code 20 references the template source code 1410 by inheriting (extending). When inherited, methods present in the source from which it is inherited can be freely called.

[0099] As an example, the source code 20 has the following processes: get key area 1341, set key area to output area 1342, get itemB area 1343, calculation process for itemB area 1344, and set calculated value to output area 1345. The description of the process for itemA is omitted.

[0100] In the key area acquisition 1341 of the source code 20, the value of the key area is required. In the key area acquisition 1341, logically the same result is obtained whether the method of the non-conversion pattern or the conversion pattern of the automatically generated accessor source code 1210 is executed. However, the non-conversion pattern is faster and does not require conversion, so the key area acquisition process (non-conversion) 1310 of the non-conversion pattern is invoked.

[0101] In the setting of the key area to the output area 1342, although not explicitly stated, an accessor for the output file is also created, so the setting process for that is called.

[0102] In itemB area acquisition 1343, the value of the itemB area is required. Since calculation is required in subsequent processing, the conversion process (itemB area acquisition process (conversion) 1331) is called instead of the non-conversion process. Even if the result is obtained without conversion, it cannot be used for calculation processing. Although there is a processing cost for conversion, it is much faster than converting the entire data.

[0103] (Template generation function) Next, the template generation function 1400 will be described with reference to FIG. 14, first, the template generation function 1400 reads the batch definition 1030 by batch definition reading 1401. For example, the batch ID of the batch definition 1030 is "BATCH0001".

[0104] Next, the template generation function 1400 reads the file definition 1040 of the input file by reading input file definition 1402. For example, the file ID of the file definition 1040 is "FILE0001".

[0105] Next, the template generation function 1400 reads the format definition 1050 of the input file by reading input format definition 1403. For example, the format ID of the format definition 1050 is "FORMAT0001".

[0106] Next, the template generation function 1400 reads the file definition 1040 of the output file by reading the output file definition 1404. For example, the file ID of the file definition 1040 is "FILE0002".

[0107] Next, the template generation function 1400 reads the format definition 1050 of the output file by reading the output format definition 1405. For example, the format ID of the format definition 1050 is "FORMAT0002".

[0108] Next, the template generation function 1400 compares the format definitions with the format ID "FORMAT0001" and the format ID "FORMAT0002" and identifies matching items in the matching item identification 1406. In the example of Fig. 14, the key item, item A item, and item B item are the same items in the two format definitions with different format IDs.

[0109] Then, template generation function 1400 generates template source code 1410 (template class) by template generation 1407 based on the matching items in format definition 1050 identified by matching item identification 1406. Here, an example is shown in which template source code 1410 that executes a copy process from input file 1 to output file 1 is generated. For example, template source code 1410 has a function to acquire information from byte 0 to byte 30 (1+20+9) as input file 1 area acquisition. Template source code 1410 also has a function to set information from byte 0 to byte 30 as output file 1 area setting.

[0110] In this example, there is one input file and one output file, so there is only one copy method. However, if there are multiple input and output files, template source code may be output for each combination.

[0111] [File input example] Next, file input in the automatic generation mechanism 1200 will be described with reference to FIG. FIG. 15 is a diagram showing an example of file input in the automatic generation mechanism 1200.

[0112] Input files can be huge, and normally the entire data volume of an input file is not expanded into memory. The contents of the file are repeated data (records), such as account units in banking operations, so memory is expanded in units of repetition. When editing a file, the process for that repetition is implemented. Furthermore, file reading and memory expansion processes are complex, and implementing them in individual Java applications reduces maintainability. For this reason, the Java processing itself is implemented in a common process (business framework), and the implementers of individual Java applications only create definition files that define information about various files and information on a record-by-record basis. The common process reads the definition files created by the individual Java applications and performs dynamic processing.

[0113] 15 includes a common process 1510 and an individual process 1530. The common process 1510 includes input file open 1511, one record read 1512, one record analysis 1513, individual process call 1514, and one record write 1515.

[0114] In the input file open 1511, the file definition 1040 (for example, binary data of length 30) is interpreted, and the input file 51 is accessed and opened.

[0115] Next, in read one record 1512, data for one record is read from the file 51. In the example of FIG.

[0116] Next, in one record analysis 1513, the read data for one record is analyzed based on the format definition 1050 (for example, information on the length and data type of each item).

[0117] Next, in individual process call 1514, the record information (information expanded in memory) is passed to individual process 1530. Individual process 1530 is a process to be executed in business processing, and corresponds to the process executed by source code 20 in FIGS. 2 and 12. Alternatively, as a specific example, individual process 1530 corresponds to the calculation process of input data in process (5) shown in FIG. 7. Individual process 1530 obtains necessary items from the record information and performs predetermined individual processing. Individual process 1530 is created by the implementer for each individual Java application.

[0118] Then, in write one record 1515, data for one record that has been subjected to common processing and individual processing is written to file 51 based on format definition 1050. The destination for writing data for one record may not be the input file, but may be an output file (not shown).

[0119] The common process 1510 and the individual process 1530 repeat the process of reading one record 1512 to writing one record 1515 the number of times equal to the number of records. Since there is only one common process 1510 in the information processing system, dynamic file analysis processing is performed.

[0120] [Example of record information] Next, the record information of the file input in the automatic generation mechanism 1200 will be described with reference to FIG. FIG. 16 is a diagram showing an example of record information of an input file in the automatic generation mechanism 1200. As shown in FIG.

[0121] As described above, the record information is created by the common processing 1510. At this time, the common processing 1510 dynamically creates the record information (in Map format) based on the information in the format definition 1050.

[0122] In the reading of one record 1512, an area for each item included in one record is reserved in memory (for example, RAM 403) by area reservation 1601.

[0123] Next, in the read one record step 1512 , format information for each item is acquired from the format definition 1050 by the acquire format definition item step 1602 .

[0124] Next, in the read one record step 1512, an input item is acquired from the input file 51 by an acquire input item step 1603. Fig. 16 shows an example in which an item A with the item name "itemA-1" is acquired.

[0125] Next, in the read one record step 1512, the data type of the input item is converted by the input item conversion / setting 1604. When the input item is acquired, it is binary data, and the input item conversion / setting 1604 converts the data to make it easier to handle in Java and sets it in memory. If there are any unprocessed items, the same process is repeated for the unprocessed items (item B in FIG. 16).

[0126] In the conventional mechanism shown in Figure 5, all file input and output are general-purpose common processes. However, when the automatic generation mechanism of the present invention is applied, source code is automatically generated on a file-by-file basis, and the automatically generated parts can be explicitly separated as individual processes.

[0127] In the individual process 1530, a necessary item (item A with the item name "itemA-1" in FIG. 16) is obtained from the record information and editing processing is performed. For example, even if item C is not necessary in the individual process 1530, the conversion processing realized in the common process 1510 is performed on all items including item C. This is because, as mentioned above, the conversion processing is realized in the common process 1510 to improve productivity and maintainability, and therefore it is necessary to perform processing that is independent of the individual processes (= can withstand whatever processing the individual processes realize).

[0128] Batch Processing Next, batch processing by the Java application 1500 when the automatic generation mechanism 1200 is applied will be described with reference to FIG. FIG. 17 is a diagram showing an example of a batch processing procedure by a Java application 1500 when the automatic generation mechanism 1200 is applied.

[0129] First, the common processing 1510 acquires one record's worth of data from the input file 51 by reading one record 1512. Then, the common processing 1510 passes one record's worth of data from reading one record 1512 to calling individual processing 1514 via analyzing one record 1513 (FIG. 15). The calling individual processing 1514 calls individual processing 1530. The common processing 1510 acquires all of the information for one record and causes the individual processing 1530 to execute the individual processing.

[0130] The individual processing 1530 has a function of acquiring a necessary item from the record information (here, item A whose item name is "itemA-1" in FIG. 17) and performing editing processing, etc. At this time, the individual processing 1530 refers to the data acquisition processing 1700. The data acquisition processing 1700 corresponds to the input accessor class 730 in FIG. 7 and the various area acquisition processing of the accessor source code 1210 in FIG. 13.

[0131] The data acquisition process 1700 has an item A area acquisition process (non-conversion) 1710 with a non-conversion pattern (high speed) and an item A area acquisition process (conversion) 1711 with a conversion pattern (low speed) as the item A area acquisition process. If the individual process 1530 determines that conversion of item A is unnecessary based on the format information of item A in the format definition 1050, it selects the item A area acquisition process (non-conversion) 1710 and acquires the area A. In this way, the presence or absence of conversion is determined individually, and if conversion is unnecessary, no conversion process is performed, so item A can be processed at high speed. The data acquisition process 1700 automatically generates a process to access each format of each item.

[0132] Similarly, the data acquisition process 1700 includes, as item B area acquisition processes, an item B area acquisition process (non-conversion) 1720 for a non-conversion pattern (high speed) and an item B area acquisition process (conversion) 1721 for a conversion pattern (low speed).Furthermore, the data acquisition process 1700 includes, as item C area acquisition processes, an item C area acquisition process (non-conversion) 1730 for a non-conversion pattern (high speed) and an item C area acquisition process (conversion) 1731 for a conversion pattern (low speed).

[0133] As described above, the information processing system (one example of an object-oriented system) according to this embodiment creates accessor source code from among business source code (business program) and accessor source code corresponding to an application written in an arbitrary object-oriented language (Java) corresponding to each job in batch processing that executes multiple jobs with different inputs and outputs in a predetermined order. The information processing system is configured to include a reception unit, an input accessor source code generation unit, an output accessor source code generation unit, and an accessor source code writing unit. The reception unit (read format definition 1301) receives a format definition that is a definition of items that constitute the input and output files of an application. The input accessor source code generation unit (accessor processing generation 1302) reads the format definition for the input file, identifies the items included in the input file to the application, and generates input accessor source code (input accessor class 730) that processes binary data for each item included in the input file. The output accessor source code generation unit (accessor process generation 1302) reads the format definition for the output file, identifies the items to be included in the output file to the application, and generates output accessor source code (output accessor class 760) that converts object-oriented language data into binary data for each item included in the output file. The accessor source code writing unit (accessor process generation 1302) writes the generated input accessor source code and output accessor source code into a source code file (accessor source code 1210). The above input accessor source code includes non-conversion source code (e.g., area acquisition processing (non-conversion)) that does not convert binary data into object-oriented language data for each item included in the input file, and conversion source code (e.g., area acquisition processing (conversion)) that converts binary data into object-oriented language data for each item included in the input file.

[0134] Furthermore, in the information processing system (an example of an object-oriented system) according to this embodiment, the business source code (business program) selects either non-conversion source code (e.g., area acquisition processing (non-conversion)) or conversion source code (e.g., area acquisition processing (conversion)) from the input accessor source code based on the format definition of each item in the input file.

[0135] In the information processing system (an example of an object-oriented system) according to this embodiment, a reception unit (format definition read 1301) receives a batch definition, which is a definition related to a job, and a file definition, which is a definition related to an input file and an output file. The information processing system further includes a common part detection unit, a format source code generation unit, and a format source code writing unit. The common part detection unit (matching item identification 1406) reads the batch definition, the input file definition which is a file definition related to the input file, the input format definition which is a format definition, the output file definition which is a file definition related to the output file, and the output format definition which is a format definition, and detects items common to the input format definition and the output format definition. The format source code generation unit (template generation function 1400) creates format source code (template source code 1410) for performing common processing for the detected common parts. The format source code writing unit (template generating function 1400) writes the generated format source code into a format source code file (template source code 1410).

[0136] According to the object-oriented system having the above configuration, in a migration scenario from an existing language such as COBOL to an object-oriented language such as Java, it is possible to ensure data processing performance by directly handling binary data in a Java application, while ensuring ease of implementation equivalent to that of converting to Java objects. Therefore, in a migration scenario from an existing language to an object-oriented language, this embodiment can ensure ease of implementation while ensuring high speed during batch processing of the system.

[0137] Furthermore, according to this embodiment having the above configuration, it is possible to reduce the cost of dynamic input / output record class generation (for example, DTO) and the like. It also reduces the processing time of business programs and memory usage. In addition, business programs can be implemented without being aware of binary data by using accessor classes. In addition, the API can convert the required data when called, which reduces the processing time of business programs. Also, an accessor class is created for each format definition, which improves reusability and scalability for the same business process.

[0138] As described above, the present invention is not limited to the above-described embodiments, and various other modifications and applications are possible without departing from the spirit of the invention as set forth in the claims. For example, the above-described embodiments have been described in detail and specifically to clearly explain the present invention, and are not necessarily limited to those including all of the components described. Furthermore, it is also possible to add, replace, or delete other components from part of the configuration of the embodiments.

[0139] Furthermore, the above-described configurations, functions, processing units, etc. may be partially or entirely realized in hardware, for example, by designing them as integrated circuits, etc. As the hardware, a broad processor device such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit) may be used.

[0140] In the above-described embodiment, the control lines and information lines are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are connected to each other.

[0141] In addition, in this specification, processing steps describing chronological processing include not only processing that is performed chronologically in the order described, but also processing that is not necessarily performed chronologically but is performed in parallel or individually (for example, processing by objects). [Explanation of symbols]

[0142] 200...automatic generation mechanism, 201...accessor generation unit, 202...template generation unit, 210...source code, 1200...automatic generation mechanism, 1210...accessor source code, 1300...accessor generation function, 1301...format definition reading, 1302...accessor processing generation, 1400...template generation function, 1406...matching item identification, 1407...template generation, 1410...template source code, 1510...common processing, 1530...individual processing

Claims

1. 1. An object-oriented system for creating accessor source code among business source code and accessor source code corresponding to an application written in an arbitrary object-oriented language, the system comprising: a receiving unit that receives a format definition that is a definition regarding items that constitute the input file and output file of the application; an input accessor source code generation unit that reads the format definition related to the input file, identifies items included in the input file to the application, and generates input accessor source code that processes binary data for each item included in the input file; an output accessor source code generation unit that reads the format definition related to the output file, identifies items to be included in the output file to the application, and generates output accessor source code that converts data in the object-oriented language into binary data for each item included in the output file; an accessor source code writing unit that writes the generated input accessor source code and the generated output accessor source code to a source code file; The input accessor source code includes non-conversion source code that does not convert binary data into data in the object-oriented language for each item included in the input file, and conversion source code that converts binary data into data in the object-oriented language for each item included in the input file. Object-oriented systems.

2. The business source code selects either the non-conversion source code or the conversion source code from the input accessor source code based on the format definition of each item of the input file.

2. The object-oriented system of claim 1.

3. the receiving unit receives a batch definition that is a definition related to the job and a file definition that is a definition related to the input file and the output file; the batch definition; an input file definition, which is the file definition, and an input format definition, which is the format definition, for the input file; a common part detection unit that reads an output file definition, which is the file definition, and an output format definition, which is the format definition, related to the output file, and detects items common to the input format definition and the output format definition; a format source code generation unit that generates a format source code for performing common processing for the detected common portion; a format source code writing unit that writes the generated format source code to a format source code file.

3. The object-oriented system of claim 2.

4. The format definition includes information about a format ID, an item name, a data type in the object-oriented language, and a length of one record of the binary data.

4. The object-oriented system of claim 3.

5. The file definition includes a file ID, a length of one record, and a corresponding format ID; The batch definition includes a batch ID, the file IDs of corresponding input files, and the file IDs of corresponding output files.

5. The object-oriented system of claim 4.

6. A method for creating an object-oriented system for creating an accessor source code among business source code and accessor source code corresponding to an application written in an arbitrary object-oriented language, the business source code and accessor source code corresponding to each of the jobs in a batch processing for executing a plurality of jobs with different inputs and outputs in a predetermined order, the method comprising: a receiving process for receiving a format definition, which is a definition regarding items that constitute the input file and output file of the application; an input accessor source code generation process that reads the format definition related to the input file, identifies items included in the input file to the application, and generates input accessor source code that processes binary data for each item included in the input file; an output accessor source code generation process that reads the format definition related to the output file, identifies items to be included in the output file to the application, and generates output accessor source code that converts data in the object-oriented language into binary data for each item included in the output file; an accessor source code writing process for writing the generated input accessor source code and the generated output accessor source code to a source code file; The input accessor source code includes non-conversion source code that does not convert binary data into data in the object-oriented language for each item included in the input file, and conversion source code that converts binary data into data in the object-oriented language for each item included in the input file. How to create object-oriented systems.

Citation Information

Patent Citations

  • Method for preparing object-oriented system

    JP1995152550A