JP2002342078A - Program development system and method - Google Patents

Abstract

(57) [Summary] To implement a client program or a server program in a procedural language such as COBOL,
It was necessary to describe a conversion process between data described in a programming language and dynamic data. Kind Code: A1 A data type defined in a program description language is compared with a data type used when actually communicating between programs, and an appropriate conversion is performed in a program that mediates between an application program and a communication infrastructure. A program development system that automatically generates processing.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a program development system for supporting the construction of a software system using an existing program as a part thereof, and more particularly, to the development of a program for constructing a software system using distributed object technology. About the system.

[0002]

2. Description of the Related Art Japanese Patent Application Laid-Open No. 2000-99345 discloses a program conversion method used for compiling a user program operating on a parallel distributed system in which a plurality of computers are connected via a network. There is a technique disclosed in a gazette. Here, a description related to communication via the network included in the program is searched for and specified using a predetermined identification phrase as a key, and the specified description is translated into a predetermined description. Compiles a description other than a description related to communication via a network, and a translated description.

[0003]

SUMMARY OF THE INVENTION CO which is a common specification of software by the object management group
RBA (Common Object Request Broker Architectur)
Can be used to reuse existing program assets to improve software production efficiency, and to implement quality-guaranteed programs in a manner consistent with CORBA specifications. It can be used as a part.

[0004] The program components actually provided may use a data type (dynamic data type) whose type is dynamically determined at the time of execution of the program, because of its versatility. For example, the any type defined in the CORBA specification can be used as an arbitrary data type defined in CORBA. CORBA mentioned above
As described in the specification, the any type is implemented as an object having both data and type information (TypeCode) of the data. By using such data types, it is possible to create program parts that can be used from programs that use various data types.

When a new application is implemented in an object-oriented language such as C ++ having a function of redefining operators as a language specification, it is relatively easy to operate a dynamic data type. However, when developing an application that uses a program component that handles dynamic data types in a programming language such as the programming language COBOL (JIS X 3002-1998 computer programming language COBOL) that does not have operator redefinition as a language specification. Is the data type used in the language specification,
It is necessary to newly create data type conversion processing between dynamic data types used in program components. In many cases, a conversion-only routine called a wrapper program is newly created, and the data type is converted by calling the wrapper program from an application program. Alternatively, a conversion process may be performed before and after calling the application program. In any case, since a program handling a data type that is unfamiliar to the programmer of the application program is newly created, it is difficult to secure learning and program quality.

An object of the present invention is to reduce the load on a programmer by automatically generating a conversion process between a data type used in an application program and a data type used in a program component.

[0007]

In order to achieve the above object, a program development environment according to the present invention has a function of analyzing a difference between a data type used in an application program and interface information of a program component. If necessary, a conversion program between a data type used in an application program and a data type used in a program component is automatically generated.

[0008]

DESCRIPTION OF THE PREFERRED EMBODIMENTS A program development system according to an embodiment of the present invention uses a program created in the COBOL language and program components implemented in another language such as C ++ implemented in accordance with the CORBA specification. This is applied when a system is constructed by using FIG. 1 is a configuration diagram of a program development system to which the present invention is applied. Hereinafter, a case will be described in which a program component is called from an application program created by a programmer. However, the present invention can be applied in a similar procedure when a program called by a program component is created by a programmer.

Information such as a call name, an argument, and a return value of a program component (hereinafter, collectively referred to as an interface)
It is given in the form of IDL according to the CORBA specification (101). In order to use this program component, an application source program created by the programmer describes a process of calling an external program for calling the program component.

From an application source program, by using an appropriate application program development tool, interface information of the application program itself and a call interface of an external program called by the application program (hereinafter collectively referred to as AP interface information) are obtained. Can be extracted. This extraction process can be realized by a known technique. As an example, FIG. 14 shows a procedure for acquiring AP interface information using a part of a language processing system of an application program description language. The AP interface information creation unit 1402 stores the AP source program 14
01 is read, the syntax analysis unit 1403 analyzes the syntax according to the grammar of the programming language, and
Extract 404. The semantic analysis unit 1405 performs semantic analysis of the token sequence 1404 according to the grammar of the programming language, and creates a dictionary table 1406. The interface information generation unit 1407 extracts only information related to the interface from the dictionary 1406 and outputs an AP interface information file 1408. A program development system to which the present invention is applied defines an IDL by an IDL reading unit (103) for reading an IDL (101) provided by a program component and an IDL syntax analysis unit (104) for analyzing a syntax of the read IDL. The obtained information is temporarily stored as inter-program interface internal information (105). The AP interface information reading unit (106) and the AP interface analyzing unit (107) also accumulate AP interface internal information (108). An interface matching determination unit (109) analyzes and compares the internal information of each of 105 and 108, and outputs an extended stub / skeleton output unit (11
0) outputs a stub skeleton including a conversion process for the difference between the internal information.

Regarding the positioning of the stub skeleton,
This will be described with reference to FIGS.

FIG. 2 is a logical configuration diagram of a client-server system created in accordance with the CORBA specification. The CORBA client program is created by a programmer and executed by the client computer (201), and the client side communication infrastructure (204) corresponding to the communication processing interface of the client computer (201).
To convert the data of the client program (202) into a format defined by the client-side communication infrastructure (204), or conversely, from the data defined by the client-side communication infrastructure (204) to data operable by the client program. It is composed of a program called a stub (203) that performs processing. The CORBA server program is created by a programmer and executed by the server computer (205).
And the server-side communication infrastructure (208) corresponding to the communication processing interface of the server computer (205) and the data of the server program (206) are converted into a data type defined by the server-side communication infrastructure (208). It is composed of a program called a skeleton (207) that performs a process of converting data in a format defined by the server-side communication infrastructure (208) into data that can be operated by a server program.

The stub and skeleton are obtained from IDL describing the interface of the server program (205).
Generated using a program called an IDL compiler.

The stub is generated as a program that mediates between the client-side communication infrastructure and the client program, as a program described in a description language of the client program. The stub stores data received as an argument in a communication buffer in a format determined by the communication infrastructure, and performs transmission processing to the server. Also, the return value of the server and the data of the output argument returned via the communication infrastructure are extracted from the communication buffer and set as if they were the return value of the stub program itself and the output argument. With such processing, the client program can call the processing of the server program by calling the stub program as if calling a subprogram.

The skeleton is generated as a program for mediating between the server-side communication infrastructure and the server program as a program described in a description language of the server program. The skeleton retrieves data from the communication buffer received from the communication infrastructure, sets it as an argument of the server program, and calls the server program.
After executing the server program, the return value and the output argument are set in the communication buffer and sent back to the communication infrastructure. By such processing, the server program can process a request issued from another computer by describing it as if it were one subprogram.

In FIG. 2, the client computer (201) and the server computer (205)
Although an example is shown in which connection is made via a communication line such as the Internet, the CORBA client-server system is not limited to this example. In particular, even if the client computer and the server computer have the same hardware, Good.

FIG. 3 shows a processing flow of a stub created by the present invention. The stub performs initialization processing (301) such as securing a communication buffer and setting a callee method if necessary, and stores the argument data passed from the client program as an input parameter in the communication buffer (302). The contents of the communication buffer are transmitted to the server via the communication infrastructure (303). here,
If the data type of the client and the data type of the IDL do not match, the input parameter conversion processing 311 is performed between the initialization processing 301 and the storage processing 302 in the communication buffer. After the processing of the server, the communication infrastructure stores the processing result of the server in the communication buffer, and returns the processing to the stub again. If the content of the communication buffer is exception information, the stub notifies the client program of the exception (30).
4, 305). Here, when the exception data type of the IDL does not match the data type of the client, the data type conversion processing 313 is performed before the processing 305. If the content of the communication buffer is the return value of the server in the normal case, the content of the communication buffer is set to the output parameter and the return value, and the process is returned to the client program (306). Here, if the exception data type of the IDL does not match the exception data type of the client, the data type conversion processing 312 inserted by the effect of the present invention performs the processing 306.
Done before. FIG. 4 shows the flow of skeleton processing. The skeleton performs initial processing such as determining the method to be called from the information in the communication buffer (4
01), the input parameters are extracted from the buffer and set as parameters of the server program (402),
Call the server method (403). If the data type of the server does not match the data type of the IDL, a data conversion process 411 is inserted between the initialization process 401 and the data setting process 402 for parameters.
If an exception occurs during the invocation of the server method, the exception information is stored in the communication buffer (406). If the exception data type of the server does not match the exception data type of the IDL, a data type conversion process 413 is performed. If the server method ends normally, set the output parameters and return value of the server in the communication buffer (40
5) Return the processing to the communication infrastructure. The communication infrastructure sends the buffer to the communication infrastructure on the client side. Where IDL
If the data type does not match the data type of the server, a data conversion process 412 is performed. When an interface having no argument or return value is specified, the corresponding processing described in FIGS. 3 and 4 is omitted.

The present invention analyzes a difference between a data structure described in IDL and a data structure used in a client or a server, and outputs data conversion processing in a stub, so that a programmer can convert data. The purpose is to reduce the effort to describe the process.

In CORBA, additional information (context and the like) can be transmitted and received in addition to arguments and return values. The present invention can be applied to such additional information as well. Since there is no essential difference in the embodiment, an explanation will be given below using an argument and a return value as examples.

FIG. 5 is an example of the IDL (101) of FIG. Here, the description will be made as IDL that defines the interface of the program component. In 501, the IDL “a
ny type ”is used. The any type is a data type that can correspond to any IDL data type. Any data corresponding to the any type is implemented as an object having type information and value information in a program implemented in an object-oriented language, and the type information is referred to at the time of execution by referring to the type information. Perform processing. In a procedural language such as the COBOL language, a data structure included in the any type is hidden by the processing system. In an application program created by a programmer, a function group provided by the processing system is provided through a pointer pointing to any type data. Need to be manipulated. In this case, the programmer needs to describe the data conversion process using a function group provided by the processing system.

FIG. 6 shows an example of a data type used by an application program created in COBOL. Here, the data 601 indicates that it is structured data including numeric data 602 and character string data 603. When using the program component having the interface shown in FIG. 5, it is necessary to convert the data shown by 601 into any type which is the dynamic data of 501.

FIG. 7 shows an example of a data conversion process described for associating the data of FIG. 6 with the IDL data type of FIG. In order to store data in the any type, it is necessary to create an object called "TypeCode" indicating information on the type of data. Therefore, as shown in 701 to 705, a function group provided by the processing system is used. Process must be described. In 701, a function for securing a TypeCode object corresponding to the structural type is called. In 702 and 703, respectively, 602,
A function for acquiring a TypeCode object corresponding to 603 is called. In 704 and 705, 70
In the TypeCode object corresponding to 601 secured in 1 and the TypeCode corresponding to 602 and 603
An object, that is, a function for storing a return value of the function call of 704 or 705 is called. By the processing of 701 to 705, TypeCo corresponding to 601
Since a de object has been created, in 706, Ty
Any value of 601 along with the peCode object
Store in type object. FIG. 8 shows a COBO corresponding to the IDL data type shown in FIG.
It is an example of L data. Even if the data type actually used in the application program is as shown in FIG.
In order to match the data type defined by IDL in FIG. 5,
The programmer must describe the processing in FIG. 7 and perform data conversion from the data in FIG. 6 to the data in FIG.
According to the present invention, since the data conversion processing conventionally described by the programmer can be performed in the stub skeleton, the programmer can concentrate on the implementation of the business processing without describing the conversion processing. Hereinafter, a detailed processing procedure of the present invention will be described.

First, according to the present invention, 10 shown in FIG.
Through the processing of steps 3 and 104, the data structure used by the program component is acquired from the interface information of the program component indicated in the form of IDL or the like. For example, from the IDL shown in FIG. 5, the data structure of the IDL is conceptually shown in FIG.
Can be represented as a tree structure shown in FIG.

Further, from the given AP interface information, by the processing shown in 106 and 107 in FIG.
Get the structure of the data used in the application program. For example, the data structure of the application program shown in FIG. 6 can be conceptually represented as a tree structure shown in FIG. The interface matching determination unit (109) compares these structures and outputs data type conversion processing.

FIG. 11 shows the flow of the processing of the interface matching judgment section (109).

After performing an initial process (1101) such as securing a necessary work area, the interface matching determination unit performs an internal program interface information (105),
That is, the data as shown in FIG. 9 and the AP interface internal information (108), that is, the data as shown in FIG. 10 are sequentially scanned and compared. Hereinafter, the inter-program interface internal information is referred to as IDL data, and the AP interface internal information is referred to as AP data.

First, IDL data and AP data are read one by one (1102). It is determined whether or not the IDL data is of any type (1104), and if not, the process of transferring between the IDL data and the AP data is output as a simple data type (1106).

In the case of the any type, the any type transfer processing output processing of FIG. 12 is performed.

FIG. 12 is a flow chart showing a part of the processing of the interface matching judging unit.
It shows a flow of processing corresponding to the y-type.

In order to exchange any type data, as described above, it is necessary to create type information called TypeCode along with the value. TypeCode
Is different when data stored in the any type has more dependent data, that is, when the data has a structure and when it does not. Therefore, in the any-type transcription process, it is determined whether the AP data has a structure (1201). If it has a structure, the TypeC corresponding to the structured data
Type for storing the mode (structural type Ty
(peCode) is output (120).
2).

FIG. 13 shows the flow of the output of the structural type TypeCode generation processing. In step 1301, the structural type Ty
A process for securing the peCode object “STRTC” is generated. Note that “STRTC” and the variable names used below are named for convenience of explanation, and in the actual generation process, unique names are given so that no name collision occurs. By this processing, for example, a function call 701 is output. Subordinate data of the AP data is substituted as the AP data (1302), and it is determined whether or not the AP data has a lower-order structure. If the AP data has no lower-level structure, a process of generating a TypeCode “APTC” corresponding to the AP data is output (1304), and “APTC” is changed to “STRTC”.
Is output (1305). 1304, 1
The processing generated by the processing 305 is generated in the form of a function call provided by the processing system. For example, 1304
Output 702 and 1305 output 703, respectively. If the AP data has a lower-level structure, the structural type
After the code generation processing output is recursively called and the TypeCode generation processing for the lower structure is output (1
306), TypeC generated by recursive call
The result of the last generation process of the
The processing to be assigned to "C" is output (1307). Structural type T
When the AP data passed to the typeCode output process includes a plurality of data, the type code is used for all the data.
de must be generated. At 1309, the next AP
Determines whether data exists, and if so, determines
The next AP data is substituted for the data, and the processing after 1303 is repeated. By this repetition processing, for example, FIG.
704 and 705 are generated. By the above processing, the structural type TypeCo in FIG.
The de generation processing has been output. After outputting the structured type TypeCode generation processing, any
A process of assigning TypeCode and a value to the type object is output (1203).

The process of assigning the AP data saved in the temporary area and the structure type TypeCode to the any object is output (1209). For example, 706
This corresponds to this processing.

On the other hand, if the AP data is single data, a process of generating TypeCode corresponding to the AP data is output (1204), and a process of substituting the TypeCode and the AP data into the any object is output (1205). . Finally, processing for storing the any object in the communication buffer is output (1206).

With the processing shown in FIGS. 11, 12, and 13, it is possible to generate a stub skeleton that performs appropriate conversion processing when the data types are different between IDL and AP data.

Note that, depending on the processing system, the IDL str
Data conversion processing may be required for other data types such as the ing type and the sequence type. Generating a data conversion process in these stubs and skeletons for these data types can be easily realized by modifying the processes described below. That is, in the determination process in 1104 in FIG. 11, a determination process of a corresponding data type is added, and
1105 is replaced with a call to a process for outputting a data conversion process corresponding to each data type. In FIG. 12, 1203, 1205, and 1206 are replaced with output processing corresponding to the corresponding data type. Furthermore, for data types that do not require TypeCode in the conversion process, the processes 1202 and 1204 are deleted.

According to the present embodiment, it is possible to construct a system using general-purpose program parts without describing the conversion processing in the application program, which has the effect of reducing the load on the programmer. .

[0037]

According to the present invention, the burden of programming can be reduced and the chance of creating a program defect can be reduced.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a configuration of a program development system.

FIG. 2 is a block diagram illustrating a configuration of a client-server program.

FIG. 3 is a flowchart illustrating a process performed by a stub.

FIG. 4 is a flowchart illustrating a process performed by a skeleton.

FIG. 5 is an example of IDL.

FIG. 6 is an example of a data type used by an application program created in COBOL.

FIG. 7 is an example of a data conversion process.

FIG. 8 is an example of COBOL data corresponding to the IDL data type;

FIG. 9 is a tree structure conceptually showing the data structure of IDL.

FIG. 10 is a tree structure conceptually showing a data structure of an application program.

FIG. 11 illustrates a flow of a process performed by an interface matching determination unit.

FIG. 12 shows a flow of an any-type transcription process output process.

FIG. 13 shows a flow of a process of outputting a structured type Code.

FIG. 14 shows a flow of processing for extracting interface information from a source file.

[Explanation of symbols]

Reference Signs List 101 IDL 102 Interface information 103 IDL reading unit 104 IDL parsing unit 105 Inter-program interface internal information 106 Application program interface reading unit 107 Application program interface analyzing unit 108 Application program interface internal information 109 Interface matching determining unit 110 Extended stub / skeleton output Part 112 Program development system 111 Extended stub skeleton

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Hiroshi Sahara 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture F-term in Hitachi Software Corporation Software Division (reference) 5B076 DD04 DD08

Claims (3)

[Claims] A means for comparing a result of analyzing a data type used in a program with a result of analyzing a data type used in a program which calls the program; Means for automatically generating a data type conversion process for the difference. Means for comparing a result of analyzing a data type used in a program with a result of analyzing a data type used in a program for calling the program; Means for automatically generating data type conversion processing for the difference. 3. A means for comparing a result of analyzing a data type used in a program with a result of analyzing a data type used in a program that calls the program, and means for comparing the result of the comparison when there is a difference. Means for automatically generating a data type conversion process for the difference.