JPH11296359A - Program development support tool - Google Patents

Abstract

PROBLEM TO BE SOLVED: To generate the stub or skeleton of a program without constraints on a data type to be used by an objective program. SOLUTION: This program development support tool is provided with a type conversion table 709 having a specific table 711 in which the type information of the data type of objective program language and type definition information being the description of the data type according to a preliminarily decided rule are preliminarily registered to correspond to each other, means 751 for extracting the type definition information described according to the preliminarily decided rule, means 752 for converting the extracted type definition information into the type information of the program language by using the type conversion table 709, and registering the type information as code generation information 712, and means 706 for generating a stub 707 or a skeleton 708 by using the code generation information 712.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a support tool for developing a program using IDL (Interface Definition Language).

[0002]

2. Description of the Related Art In computer program development, programs (or data) are sometimes created in units of functional blocks. According to this method, the program development efficiency can be improved, and the program can be reused. However, when the target process is realized by linking a plurality of program processes, an interface such as a calling rule between the programs needs to be defined in advance. IDL (interface definition language) may be used for the definition of this interface.

[0003] As IDL, OMG (Object
C proposed by the Management Group
IDL used in ORBA (Common Object Request Broker Architecture) is known. References to the CORBA language mapping specification include “The Commo published by OMG.
n Object Request Broker:
Architecture and Specific
ation Revision 2.0, July
1995 Updated July 1996 ". Also, as a reference for a general background on CORBA, “Distributed Object Oriented Technology CORB” published by Hirofumi Onozawa, Soft Research Center
A ".

[0004] In CORBA, IDL, a mapping specification between various program languages and IDL, and an ORB (Object Request Broker) for managing communication between programs are specified. The developer describes the interface of each program in IDL according to the mapping specification. By compiling the IDL source with a dedicated compiler (IDL compiler), a stub for a client program and a skeleton for a server program are generated. Here, the stub and the skeleton are sub-programs for mediating between the client program and the server program and the ORB.

[0005] Program development using IDL has the further advantage that it is easy to use programs written in different languages and to use programs executed on computers having different architectures.

Hereinafter, a processing system for generating a stub or a skeleton from an IDL source, such as a CORBA IDL compiler, is generally called an IDL language processing system. Also,
A processing system that generates an IDL source from an existing program is generically called an IDL generation system. The IDL generation system is effective when an existing program is diverted to perform processing in cooperation with another program.

FIG. 8 shows an example of a functional configuration of a conventional IDL language processing system.

[0010] The IDL syntax analysis unit 102 receives the IDL source 101 as input, performs IDL syntax analysis, and outputs analysis information 103. Here, the analysis information 103 includes
Procedure and method names, argument data types, list, etc.
IDL information that defines a calling rule between programs is included.

The code generator 104 comprises an interface information analyzer 105, a program code generator 106, and a type conversion table 109. In the type conversion table 109, information on the data type of the IDL included in the analysis information 103 and the data type incorporated in the program code 108 are stored in advance in association with each other. The interface information analysis unit 105 includes the type conversion table 10
With reference to No. 9, the information of the data type of IDL in the analysis information 103 is converted into the data type used in the stub or skeleton. Using this conversion result, the program code generation unit 106 generates a stub 107 and a skeleton 108.

FIG. 9 shows an example of a functional configuration of a conventional IDL generation system.

The syntax analysis unit 202 is used for the source program 20.
1 is analyzed to generate analysis information 203. The interface information extraction unit 204 extracts, from the analysis information 203, interface information such as names of procedures and methods, data types of arguments, arrangement, and the like, and outputs them as intermediate language 205.
In the type conversion table 206 in the IDL generation system, information on the data type included in the intermediate language 205 and information on the data type used in IDL are stored in advance in association with each other. The code generation unit 207 converts the data type information in the intermediate language 205 into data type information used in the IDL source with reference to the type conversion table 206. Using this conversion result, the IDL output unit 211 generates an IDL source 212 so as to satisfy the IDL grammar.

In general, when data is transferred between programs written in different languages, the data type needs to be a type that can be commonly used in both program languages. Therefore, the above-described IDL language processing system and IDL generation system can also process only data types that can be commonly used in a plurality of target program languages (for example, C language, C ++ language, etc.).

[0013]

The above-described conventional IDL language processing system and IDL generation system cannot process data types that cannot be commonly used in a plurality of target program languages. , The IDL source may not be generated properly.

For this reason, for example, when a data type that cannot be processed by the IDL generation system is specified in an existing application program to be diverted, the developer modifies the interface specifications of the diverted program, It is necessary to perform a complicated manual operation such as creating a wrapper function that functions to change the calling method.

An object of the present invention is to develop a program capable of generating a subprogram that realizes an interface function of a program without restriction on data types used in the program described in a target programming language. To provide support tools.

[0016] Another object of the present invention is to provide an arbitrary program described in a target programming language.
An object of the present invention is to provide a program development support tool capable of generating IDL source information that can be processed by the program development support tool.

[0017]

According to the present invention, there is provided a subroutine for realizing an interface function of a program based on IDL source information which describes a calling rule between a plurality of programs. In a program development support tool for generating a program (for example, a stub or a skeleton), type information of a data type used in a programming language that describes the program and type definition information that describes the data type according to a predetermined rule Means for extracting a type conversion table having a special table registered in advance in association with the type definition information described in accordance with the predetermined rule from the IDL source information; Using the type conversion table, the type information is converted into type information of the programming language, and the type information is Means for registering as a de generation information, using the code generation information, to provide a program development support tool, characterized in that it comprises means for generating the subprograms.

According to the present invention, there is provided an information processing system comprising: an ID code describing a calling rule of a program based on a source code of the program;
In a program development support tool for generating L source information, type information of a data type used in a programming language that describes the program and type definition information that describes the data type according to a predetermined rule are stored in advance. The type conversion table having the special table registered in association with the type information of the data to be transferred by the program, and the type information registered in the special table is defined by using the type conversion table. A program development support tool characterized by comprising means for converting information into information and registering the type definition information as code generation information, and means for generating the IDL source information from the code generation information.

[0019]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A program development support tool according to an embodiment of the present invention will be described below with reference to the drawings.

The program development support tool of this embodiment is for supporting program development in an environment in which a plurality of application programs (client programs and server programs) operate in cooperation. The functions of the program development support tool are divided into an IDL language processing system that generates a stub and a skeleton from an IDL source, and an IDL generation system that generates an IDL source from an existing program.

FIG. 1 shows a configuration of a computer 1 on which a program development support tool is mounted. 1, the computer 1 includes a processor 2, a RAM 3, a ROM 4, a display 5, a keyboard 6, a mouse 7, an internal disk device 8, an external disk device 9, and various interface circuits (I / Fs) 10 to 15. Have. Here, for example, a hard disk device is used as the internal disk device, and a CD-ROM reader or a floppy disk device is used as the external disk device. The communication interface circuit 15 is connected to the network 16 and exchanges files (programs and the like) with other computers.

The function of the program development support tool is stored as a program on the recording medium of the external disk device 8 and is realized by the processor 2 executing this program.

In this embodiment, the COBOL language is used as a language for creating an application program. In the COBOL language, the definition of the data type of the argument of the external program can be described using the number of digits when the numerical value is expressed in decimal, the decimal point position, and the use. For example, the declaration statement 501 in FIG.
A PACKED decimal number with three digits and a decimal part is defined. Such data types may be used in defining arguments when called from an external program. However, this data type is CORBA IDL
Cannot be described by For this reason, conventionally, it has been necessary for the developer to perform troublesome operations such as modifying the interface specifications.

In this embodiment, the data type of the COBOL language that matches the data type supported by the CORBA IDL is described as before, and the unsupported COBOL data type is described.
The data type of the L language is TY, which is one of the syntax elements of IDL.
A new description rule (hereinafter referred to as a new description rule) described using the PEDEF syntax is used. In addition, I of CORBA
In the grammar of the DL, the type definition name in the TYPEDEF syntax can be freely set by the developer.

According to the new description rule, the data type of the COBOL language, which is not defined by the CORBA IDL, is
It is defined by predetermined IDL type information and a type definition name in the EF syntax. For example, as shown in FIG. 3A, the variable “ARG” of the declaration 501 in FIG. 2 is defined by IDL type information “unsigned long” 600 and a type definition name “CBL_PACK_9_4V9_3” 605.

The description of the type definition name 605 is also made according to the new description rule. Specifically, first, the description language is COB
A character string “CBL_” 601 indicating the OL language is described. Next, a character string 602 corresponding to the application is described. In the example of FIG. 3A, “PACKED-DECI
“PACK_” 602 corresponding to “MAL” is described. For “BINARY”, which is the application,
“_” And “DISPLAY” are respectively described as “DISP”. Subsequently, if necessary, “S” (not shown) indicating a sign is described, followed by “9_” 603 indicating a numerical value. Then, 10
The number of digits of the integer part of the hexadecimal number (“4” in the example in the figure) is described, and if necessary, the number of digits of the decimal part (“3”) is described following “V9_” (604).

In this manner, data types not supported by the CORBA IDL are described. An IDL language processing system and an IDL generation system according to the present embodiment described below have a function to cope with the above-described new description rule.

FIG. 4 shows a functional configuration of the IDL language processing system (hereinafter, IDL compiler) of the present embodiment.

The illustrated IDL compiler 700 has a syntax analyzer 702 and a code generator 704. The syntax analysis unit 702 and the code generation unit 704 are functions realized by executing programs in the storage areas of the disk devices 8 and 9 of the computer 1.

The IDL compiler 700 receives the IDL source 701 as an input and outputs a stub 707 and a skeleton 708 described in the COBOL language. In this process, analysis information 703 and code generation information 712 are generated.

Here, the IDL source 701 is information in which the interface of the target server program is described in IDL according to the new description rule. IDL source 7
01, analysis information 703, code generation information 712, stub 707, and skeleton 708 are stored as files in the disk device of the computer 1.

The IDL compiler 700 includes a COB incorporated in the syntax analysis unit 702 to comply with the new description rule.
It has an OL dependence information analysis unit 751, a COBOL type information conversion unit 752 incorporated in the code generation unit 704, and a special table 711 incorporated in the type conversion table 709.

As shown in FIG. 5, the type conversion table 709
In the special table 711, a type definition name (605) described according to the new description rule and type information of the COBOL language are registered in association with each other in advance. Type conversion table 70
9 has IDL type information and CO
BOL language type information is registered in advance in association with each other. As a result, the COBO is stored in the type conversion table 709.
All type information of the L language is registered.

The type conversion table 709 is arranged in the program of the IDL compiler 700 for speeding up access. Of course, it may be stored as a file in the disk device of the computer 1.

Next, the processing of the IDL compiler 700 will be described with reference to FIG.

When a command for compiling the IDL source 701 is input to the computer 1, the processing of the IDL compiler 700 is started. First, the parsing unit 70
2 generates the analysis information 703 by analyzing the syntax of the IDL source 701. The definition of the data type supported by IDL is processed in the same manner as in the related art, and is incorporated in the analysis information 703.

At this time, the COBOL dependency information analyzer 751
Checks the TYPEDEF syntax described in the IDL source 701 as shown in FIG.
If there is a type definition name (605) having the following, the type definition name is extracted as type information for COBOL and incorporated into the analysis information 703 (S101, S1).
02). For example, when there is a TYPEDEF syntax shown in FIG. 3A, "CBL_PACK_9_4V9_3"
605 is extracted and incorporated into the analysis information 703 as type information for COBOL.

The COBOL dependence information analysis unit 751
Since only the type definition information described by the new description rule is extracted, no error occurs in the subsequent processing even if the TYPEDEF syntax includes other information unrelated to the new description rule.

The syntax analyzer 702 checks the grammar of the IDL source 701. In the present embodiment, the ID
Since data types not supported by L are defined using the TYPEDEF syntax, no error occurs in the grammar check.

Subsequently, the code generation unit 704 reads the analysis information 703 and performs a process of converting IDL type information into COBOL type information, thereby generating a stub 707 and a skeleton 708.

At this time, the interface information analysis unit 70
5 converts the IDL type information included in the analysis information 703 into the COBOL language type information with reference to the standard table 710 of the type conversion table 709. This conversion result is registered as code generation information 712. In parallel with this, the COBOL type information conversion unit 752 refers to the special table 711 of the type conversion table 709 and adds the COBOL type information contained in the analysis information 703 to the COBOL.
Convert to L language type information.

More specifically, the COBOL type information converter 75
2 reads out the type information for COBOL included in the analysis information 703 (S103), and acquires the type information of the COBOL registered in the special table 711 of the type conversion table 709 corresponding to the type information (S104). And
A parameter is set in the acquired type information, and the result is registered as code generation information 712 (S105).

For example, if the information read from the analysis information 703 is “CBL_PACK_9_4V9_3”, “CBL_PA
“P” registered corresponding to “CK_9_xV9_y”
ic 9 (x) v9 (y) PACKED-DECIMA
L ”is acquired, and '3' and '4' are set to the parameters x and y, respectively.

The program code generator 706 uses the code generation information 712 to generate a stub 707 and a skeleton 708 described in the COBOL language.

The stub 707 and the skeleton 708 are
PROGR with defined method name set to itself
It has an AM-ID statement and a CALL statement in which the name of a program (method) to be called is defined. The CALL statement of the stub 707 calls the function of the ORB, and the skeleton 708
CALL statement is for calling a server program.

The stub 707 and the separately created client program are executed by a computer on which the
The BOL is compiled and linked into an executable program. Similarly, the skeleton 708 and the server program also execute
The BOL is compiled and linked into an executable program.

The IDL compiler 700 has a mode in which only one of the stub 707 and the skeleton 708 is generated. Also, the stub 707 and the skeleton 708
, The computer 1 continuously compiles the COBOL and outputs the stub 707 and the skeleton 708 as an executable program. ID
The L compiler 700 selects these modes according to the parameters of a command instructing the compilation of IDL.

The stub 707 is activated by a CALL statement in the client program that calls the server program. The activated stub 707 calls the function of the ORB with the specification of the method name and the information of the argument by the CALL statement. In response to this, the ORB performs processing for specifying the computer on which the corresponding server program and the skeleton 708 are arranged, and calls the skeleton 708 of the computer on which the ORB is arranged with the designation of the method name and the information of the argument. . Skeleton 7 activated by this
08 calls the server program with the specification of the argument. As a result, the server program is executed. The execution result is transferred by the reverse route and passed to the client program.

As described above, the ID of the present embodiment
According to the L compiler 700, the stub 70 of the COBOL language program including the specification of the data type not supported by the IDL is obtained from the IDL described by the new description rule.
7 and skeleton 708 can be generated.

FIG. 6 shows a functional configuration of the IDL generation system of this embodiment.

The illustrated IDL generation system 800 includes a syntax analysis unit 802, an interface information extraction unit 804, a conversion table 806, and a code generation unit 807.
Each of the units 802, 804, 806, and 807 is a function realized by executing a program in a storage area of the disk device 8, 9 of the computer.

The IDL generation system 800 includes a source file 80
1 is input, and the IDL source 809 is output. In this process, analysis information 803, intermediate language 805, and code generation information 823 are generated.

Here, the source file 801 is a COBO file.
It consists of a server program written in L language. In addition,
Source file 801, analysis information 803, intermediate language 805,
The code generation information 823 and the IDL source 809 are stored as files in the disk device of the computer 1. The source file 801 is transferred, for example, from another computer that has been developed via the network 16.

The IDL generation system 800 has a function to cope with the new description rule.
COBOL type TYP incorporated in EDEF generation unit 808
An EDEF generation unit 811 and a special table 821 incorporated in the type conversion table 806 are provided.

As shown in FIG. 7, the type conversion table 806
In the special table 821, the type information of COBOL and the T
YPEDEF information is registered in association with each other in advance.
Here, the TYPEDEF information is a type definition name (605) described according to the new description rule. On the other hand, in the standard table 820 of the type conversion table 806, type information of the COBOL language and type information of the IDL are registered in association with each other in advance. As a result, the type conversion table 806 contains C
All type information of the OBOL language is registered.

The type conversion table 806 is arranged in the program of the IDL generation system 800 to speed up access. Of course, it may be stored as a file in the disk device of the computer 1.

Next, the processing of the IDL generation system 800 will be described with reference to FIG.

When a message instructing the generation of the IDL source is input to the computer, first, the syntax analyzer 802
The syntax analysis of the source program 801 is performed, and the analysis information 8
03 is generated.

From the analysis information 803, an interface information extraction unit 804 extracts interface information and generates an intermediate language 805. Here, the intermediate language 805 includes a program name of each program constituting the source file 801 and argument information (name and type information of the argument).

Subsequently, the code generator 807 determines that the intermediate language 8
05, and converts the type information in the argument information into IDL type information or TYPEDEF information.
An IDL source 809 is generated.

At this time, the code generator 807 first searches the standard table 820 of the type conversion table 806 for type information of the COBOL language included in the intermediate language 805. If the type information is registered in the standard table 820 (for example, “PIC S9 (9)”), the code generation unit 807 determines the corresponding IDL type information (“long”).
Is extracted and registered as code generation information 823. This is performed for all programs and argument information.

A COBOL type TYPEDEF generation unit 811
Then, a TYPEDEF syntax is generated for type information of the COBOL language not registered in the standard table 820.
First, the TYPEDEF generation unit 811 reads a program name from the intermediate language 805 (S201), and reads argument information not registered in the standard table 820 (S20).
2). Then, the type information in the read argument information is searched in the special table 821 of the type conversion table 806 (S
203, S205). If the target type information is not registered, a type conversion error process is performed and an error message is displayed (S206).

If the target type information is registered, the TYPEDEF information associated with the type information is obtained (S207). And the obtained TYPEDEF
The type definition name that matches the information has already been added and output
The code generation information 823 is searched for whether or not it is in the YPEDEF chain (TYPEDEF information group) (S208,
(S210) If not (NO in S29), the TYP
A TYPEDEF syntax using the EDEF information is generated, and additionally output to the TYPEDEF chain in the code generation information 823 (S211). With this additional output, FIG.
Character data of TYPEDEF syntax in the form of (a) is added.

As shown in FIG. 3A, TYPEDEF
In generating the syntax, first, "typedef long"
Set the character data of 600 to the syntax, and then type
Set the parameter in the DEF information and type definition name (60
5) is generated, and the character data of the type definition name is set in the syntax. Then, the type definition name (605) is added to the line following the syntax.
And an argument name 606 are set.

On the other hand, when a type definition name that matches the acquired TYPEDEF information already exists in the TYPEDEF chain (YES in S209), the type definition name and the argument information are added to the corresponding type definition name in the TYPEDEF chain. It is added (S212). For example, TYPEDE
If the type definition name 605 of FIG. 3A exists in the F-chain and the type definition name of another argument name “ARG2” matches that of FIG. 3A, it has already been set. "CBL_PACK_9_4V9_3 ARG2" is added to the line following the line of the type definition name 605 and the argument name 606.
Is added. This allows the same information 600 and 60
Because it is not necessary to set 5 repeatedly, TYPEDEF
The amount of syntax information can be kept small.

Subsequently, the TYPEDEF generation unit 808 repeats the above processing for other argument information of the same program (S213), and further repeats the above processing for another program (S214).

Code generation information 82 created as described above
3 is passed to the code output unit 810. Code output unit 81
0 indicates to the IDL source 809 that the code generation information 82
The definition statement of the IDL variable / numerical value is set using the IDL type information in No. 3, and each information in the TYPEDEF chain is set as the TYPEDEF syntax of the IDL source 809.

As described above, the ID of the present embodiment
According to the L generation system 800, an IDL source 809 described according to the new description rule can be generated from a COBOL language program including a data type specification not supported by IDL. Developers can use this IDL source 80
9 is compiled by the above-described IDL compiler 700, whereby a stub 707 and a skeleton 708 can be obtained.

That is, by using the IDL compiler 700 and the IDL generation system 800, the developer does not need to modify the interface specifications even when diverting an existing client program or server program. 707 and skeleton 708 can be easily obtained. Further, a client program or a server program can be created by freely using the data type of the COBOL language.

In the above, an example has been described in which a data type that is not supported by IDL is defined by using the TYPEDEF syntax. This definition is based on IDL variables that can be freely described by the developer in IDL. It may be performed using the name of a constant or a comment sentence of IDL.

When using the names of variables and constants, FIG.
As shown in (b), in the IDL data type definition statement, a partition symbol “_” is inserted before the name 606 of the variable or constant to be defined, and the above-described type definition name 605 is added.
In this case, the IDL compiler uses the data type definition statement to
The name 606 to which "CBL_" is added is extracted, and the same processing as that in FIG. 4 described above is performed. The IDL generation system also describes the argument information of the source file in the format of FIG. 3B, and performs the same processing as that of FIG. 6 described above.

When a comment is used, as shown in FIG. 3C, in the IDL data type definition statement, a comment symbol “/” is added after the name 606 of the variable or constant to be defined.
The above type definition name 605 is added by inserting “/”. Also in this case, the IDL compiler and IDL generation system
And the same processing as that of FIG. 6 is performed.

In the above description, the case where the development of a program created in the COBOL language is supported has been described.
++ language, Java language, etc.). In this case, the IDL language processing system is provided with a dependency information analysis unit and a type conversion unit for the target program language, instead of the COBOL dependency information analysis unit 751 and the COBOL type information conversion unit 752, respectively. The IDL generation system is a COBOL type TYPE
Instead of the F generator 811, the TY of the target programming language is used.
A PEDEF generation unit is provided. Then, the data types of the target program language are registered in the type conversion tables 709 and 806. Furthermore, the new description rule describes the type definition name so that the data type of the target programming language can be uniquely identified.

[0074]

As described above, according to the present invention, a subprogram that realizes an interface function of a program without restriction on data types used in the program described in a target programming language is provided. A program development support tool that can be generated can be provided.

Further, according to the present invention, there is provided a program development support tool capable of generating IDL source information which can be processed by the program development support tool for an arbitrary program described in a target program language. can do.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration example of a computer on which a program development support tool of the present invention is mounted.

FIG. 2 is a diagram showing an example of a type declaration in a COBOL program.

FIG. 3 is a diagram showing a description example of IDL to which a new description rule of the present invention is applied.

FIG. 4 is a diagram showing a functional configuration of an IDL language processing system corresponding to COBOL.

FIG. 5 is a diagram showing functions of a dependency information analysis unit and a type information conversion unit.

FIG. 6 is a diagram showing a functional configuration of an IDL generation system corresponding to COBOL.

FIG. 7 is a diagram illustrating a function of a TYPEDEF generation unit.

FIG. 8 is a diagram showing a functional configuration of a conventional IDL language processing system.

FIG. 9 is a diagram showing a functional configuration of a conventional IDL generation system.

[Explanation of symbols]

501 Type declaration statement of COBOL 600 to 606 Type declaration using TYPEDEF syntax 605 Type definition name 700 IDL language processing system 701 IDL source 702 Syntax analysis unit of IDL language processing system 751 COBOL dependency information analysis unit in syntax analysis unit 703 IDL language Analysis information obtained by parsing of the processing system 704 Code generation unit of the IDL language processing system 705 Interface information analysis unit of the IDL language processing system 706 Program code generation unit of the IDL language processing system 707 Stub obtained by the code generation unit 708 Code Skeleton 709 obtained by generation unit Type conversion table of IDL language processing system 710 Standard table in type conversion table 711 Special table in type conversion table 712 Code generation information 752 COBOL type information conversion unit 800 ID L generation system 801 Source program file 802 IDL generation system syntax analysis unit 803 IDL generation system analysis information 804 IDL generation system interface information extraction unit 805 IDL generation system intermediate language information 806 IDL generation system type conversion table 807 IDL generation Code generation unit 808 TYPEDEF generation unit in code generation unit 810 IDL output unit in IDL generation system 811 COBOL type TYPE in TYPEDEF generation unit
EDEF generation unit 809 IDL source 820 Standard table in type conversion table 821 Special table in type conversion table 823 Code generation information

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Wataru Takagi 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Inside Software Development Division, Hitachi, Ltd. Hitachi, Ltd. Software Development Division

Claims (9)

[Claims] 1. A program development support tool for generating a subprogram that realizes an interface function of a program based on IDL (interface definition language) source information that describes a calling rule between a plurality of programs, A type conversion table having a special table in which type information of a data type used in a program language for describing the program and type definition information in which the data type is described according to a predetermined rule are registered in association with each other in advance. Means for extracting type definition information described according to the predetermined rule from the source information of the IDL; and using the type conversion table to extract the extracted type definition information,
A program development support tool, comprising: means for converting the type information into the type information of the programming language and registering the type information as code generation information; and means for generating the subprogram using the code generation information. 2. The program development support tool according to claim 1, wherein the type definition information described according to the predetermined rule is:
A program development support tool characterized by being extracted from the TYPEDEF syntax in the IDL source information. 3. The program development support tool according to claim 1, wherein the type definition information described in accordance with the predetermined rule is:
A program development support tool characterized by having information indicating a display type, a length, and a use of data. 4. A program development support tool for generating IDL (Interface Definition Language) source information in which a calling rule of the program is described based on a source code of the program, wherein data used in the program language describing the program is provided. A type conversion table having a special table in which type information of a type and type definition information in which the data type is described according to a predetermined rule are registered in advance, and a type of data to be transferred by the program. Means for converting type information registered in the special table into type definition information using the type conversion table, and registering the type definition information as code generation information; Means for generating the IDL source information. 5. The IDL program development support tool according to claim 4, wherein the converted type definition information is set in a TYPEDEF syntax in the IDL source information. . 6. The program development support tool according to claim 4, wherein the type definition information described according to the predetermined rule is:
A program development support tool characterized by having information indicating a display type, a length, and a use of data. 7. A recording medium on which IDL (interface definition language) source information in which a calling rule between a plurality of programs is described is recorded. Characterized in that type definition information in which is described in accordance with a predetermined rule is set. 8. The recording medium according to claim 7, wherein the type definition information described according to the predetermined rule is set in a TYPEDEF syntax in the IDL source information. 9. The recording medium according to claim 7, wherein the type definition information described according to the predetermined rule is:
A recording medium having information indicating a display type, a length, and a use of data.