JP2005038244A - Automatic program generation device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enable the efficient generation of a program by preventing retry at the time of preparing a program, and to enable the support of a test process. <P>SOLUTION: A specification input means 110 stores an inputted communication service operation specification 10 as internal data 150 based on input element provision data 140 with information for transmitting and receiving signals preliminarily defined as communication service operation specifications and the like. The means further assigns route numbers to all routes of the service operation specification inputted by a user. A specification conversion means 120 executes the automatic completion of an insufficiently defined part as necessary based on the internal data 150 to generate communication service software 20, and further outputs an entire route pattern file 30 describing patterns of the input and output signals corresponding to all the route numbers. An automatic test control means 160 reads an automatic test pattern definition file 40 and the service software 20, and executes a test to collect logs. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to an automatic program generation device that inputs a communication service operation specification and generates a communication service software program. More specifically, the communication service operation specification is described using a flowchart, and the description content is converted into a program language. In addition to supplementing missing parts when necessary, verifying specification errors, etc., preventing rework when creating programs, and an automatic program generator that enables efficient testing of generated communication service software .

  The conventional automatic program generation device of this type is defined by using a message sequence diagram based on a communication service operation specification based on a PSTN network (Public Switched Telephone Network), and based on the current call state. The call state transition diagram for extracting the previous and next call states is defined, and the semi-normal procedure is automatically complemented based on the call state transition diagram (see, for example, Patent Document 1).

  However, since there is a part that depends on the service specifications in the semi-normal, when the state transition of the newly developed service is not a subset of the conventional service, it is necessary to add conversion knowledge for each service development. In addition, since auto-completion was performed while performing conversion, there was no means for confirming the auto-completion part at the input specification level, leading to a decrease in efficiency during testing. If the service specification is reworked after automatic completion for the semi-normal procedure part, it is impossible to correct the auto-completed specification on the editor. It took a lot of man-hours to rework. Only the developer of the automatic program generator could correct the conversion knowledge.

  On the other hand, in order to realize automatic program generation that can define communication services not only on the PSTN network but also on the IP network and the mobile network, the call state is not changed regardless of the quasi-normal automatic complement based on the call state transition. It has become necessary to automatically generate programs that support multiple unrelated protocols and distributed environments. In addition, the part entered by the user and the part automatically supplemented by the automatic program generation device are clearly displayed at the input icon level, and can be corrected by the user after the automatic supplementation. There is a need to do.

  For this reason, the inventors first input the communication service specifications, convert the description contents into a programming language with multiple conversion patterns, and complement the missing parts when necessary to identify the complemented parts. An automatic program generation apparatus that can verify specification errors and prevent rework during program creation has been proposed (Japanese Patent Application No. 2003-66721; automatic program generation apparatus).

  In the automatic program generation device of Japanese Patent Application No. 2003-66721, in the flowchart in which an icon is pasted and described based on the service operation specification, the information of the signal transmission / reception icon is based on the input element provision data for the input signal transmission / reception icon. In order to use the created internal data, it is not necessary to add conversion knowledge every time the service is developed or every API is added, and it is automatically complemented at the level where the service operation specifications are entered. Conversion information that can be easily changed by users by generating service software based on conversion patterns corresponding to conversion information data in multiple formats prepared in advance Including data prevents rework during program creation and makes the program more efficient It can be formed. However, test process support is not considered. Generally, in the development of communication services, the test process is the process with the largest amount of work, so in order to achieve higher productivity in communication service development, support the test process of the generated service software. It is also necessary.

Japanese Patent Laid-Open No. 9-81380 “Communication Service Software Specification Generation System”

  The present invention solves the above-described problems. The service operation specification input for automatically generating a program is effectively utilized, and in addition to the function of the automatic program generation device of Japanese Patent Application No. 2003-66721, the present invention automatically An object of the present invention is to provide an automatic program generation apparatus capable of performing a test.

  According to the present invention, it is possible to visually input an operation specification of a communication service using a graphical representation, and information on a selected signal transmission / reception icon is provided to specification conversion means as internal data based on input element provision data. Operation specification of a communication service in a program automatic generation apparatus having specification input means capable of inputting, specification verification means for verifying an inputted service specification, and specification conversion means for converting into service software based on the inputted service specification Based on the state transition information of each input / received signal, means for automatically complementing, means for selecting whether or not to automatically complement, input the automatically complemented part as specifications Means to display in means, means to verify when the automatically complemented part has been modified, multiple formats prepared in advance In addition to some or all of the means described in Japanese Patent Application No. 2003-66721, such as means for converting service software using a program template based on a conversion pattern corresponding to conversion information data, Based on this, all routes are extracted in units of icons, and a test pattern (test data) describing the processing of all icons is read, and the test data and the communication service software to be tested are read and processed one by one. Means for collecting logs while executing.

  In the flowchart in which an icon is pasted and described based on the service operation specification by the automatic program generation device of Japanese Patent Application No. 2003-66721, the signal transmission / reception icon information is separated as input element provision data for the input signal transmission / reception icon. However, it is not necessary to add conversion knowledge every time a service is developed or API is added, and it is automatically complemented. At the level where service operation specifications are entered, the automatically complemented part is clearly specified and can be modified. Service software is generated based on conversion patterns corresponding to conversion information data in a plurality of formats prepared in advance, and conversion information data that can be easily changed by the user is included in the conversion information data in a plurality of formats To prevent rework during program creation and generate programs efficiently It can be. According to the present invention, in addition to this, the generated program can be automatically tested, and the generated service software can be easily tested.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is a functional block diagram showing an embodiment of an automatic program generation device of the present invention. In FIG. 1, an automatic program generation apparatus 100 includes specification input means 110 that allows a user to visually input an operation specification 10 of a communication service using a graphical representation, and the input communication service operation specification 10 as a communication service. In addition to conversion to software 20, specification conversion means 120 for generating all route pattern files 30, specification verification means 130 for verifying specifications, automatic test pattern definition file 40, and communication service software 20 to be tested are read to perform automatic testing. Automatic test control means 160 for executing / controlling, input element providing data 140 and internal data 150. The input element provision data 140 and the internal data 150 are actually held in the memory device.

  The specification input unit 110 receives an input of the communication service operation specification 10 from the user, and the information of the selected signal transmission / reception icon is converted into the internal data 150 based on the input element provision data 140 from the specification conversion unit 120 and the specification verification unit 130. Save in a custom format available. Further, the specification input means 110 extracts all processing routes for operation use of the communication service input by the user in units of icons (input / output signals), and assigns route numbers to all the processing routes. The specification conversion unit 120 performs automatic complement processing on the input communication service operation specification 10 based on the internal data 150, such as a lack of definition or program code that does not depend on the service, if necessary, and depends on a service prepared in advance. The communication service software 20 is generated based on a plurality of conversion pattern formats not to be generated, and in addition, an all route pattern file 30 in which patterns of input / output signals corresponding to all processing (all route numbers) routes are generated. The specification verification unit 130 verifies specifications such as state transition verification based on parameter check and state transition information during input and conversion. The automatic test control means 160 reads the automatic test pattern definition file 40 created by the user based on the communication service software 20 to be tested and all the route pattern files 30, and collects the logs by executing each process. To do.

FIG. 2 shows an example of communication service software. An example of this is Open API (Application Programming).
This shows a case where a transmission / reception signal (method) is selected based on Parlay API (http://www.parlay.org), which is one of the interfaces), and each state transition information is indicated using a message sequence. Yes. Reference numeral 211 denotes a control logic, which is a class group for realizing a communication service based on an operation specification of the communication service. 212 is Parlay
It is a Parlay service class defined by API, and the control logic 211 selects and uses the transmission / reception methods of these classes. Reference numeral 213 denotes a state transition of the control logic 211. In this example, there are four states. Reference numeral 214 denotes a state transition of the Parlay service class 212 defined in the specification. 215 is a transmission / reception method of the Parlay service class 212 specified in the specification.
It is called API. In this embodiment, communication service software as shown in FIG. 2 is assumed.

FIG. 3 shows an input screen, which is an implementation example of the specification input unit 110 that allows the operation specification of the communication service to be visually input to the system using a graphical representation by means of GUI (Graphical User Interface). FIG. The user selects an icon as an input element on the input element selection screen 112, pastes it on the input screen 111, and inputs a service operation specification. In the example, the icons are selected in the order of 1-5. The icon information on the input element selection screen 111 is displayed based on the input element provision data 140 held in advance. The input element provision data 140 is, for example, OMG (Object
All the CORBA (Common Object Request Broker) standardized and provided by the Management Group
Architecture: Common specification for exchanging messages between objects in a distributed system environment) IDL (Interface) which defines the interface of objects
Data automatically generated from a definition language file. FIG. 4 shows an example of the input element provision data 140. Note that the process of generating input element provision data from the IDL file has been previously proposed by the present inventors (Japanese Patent Application No. 2002-122399), and is not the gist of the present invention. .

  Based on the input element provision data 140, the specification input means 110 stores a service specification input from the user as internal data 150 together with information such as a transmission / reception number previously defined as an operation specification of the communication service. Further, the specification input unit 110 assigns route numbers to all the processing routes of the service operation specifications input by the user.

  FIG. 5 shows an example of the internal data 150. Internal data 150 is generally composed of a plurality of tables, but FIG. 5 simply shows only table A and table B. In the table A, 1 to 5 correspond to the icons (input elements) 1 to 5 shown on the input screen 111 of FIG. The table A and the table B are associated with each other by a pointer as necessary, for example, B-2 and B-8. As shown in FIG. 5, information such as transmission / reception signals (methods) defined mainly in the input element provision data 40 is held in the table B.

  FIG. 6 shows a configuration example of the specification conversion means 120. The specification conversion means 120 includes a conversion control unit 121 that is a logic for converting a service specification into a program code based on the internal data 150, a conversion information data 122 that is used by the logic to convert a service specification into a program code, and depends on the service A template file 123 in which the program code is not templated, a skeleton code 124 required when generating a program premised on distributed processing such as CORBA, an all route pattern format file 25 describing the format of all route pattern files 30, and an internal Based on the data 150, an automatic complement control unit 126 for complementing a program code that does not depend on a lack of definition or a service, and a complement determination flag used by the automatic complement control unit 125 for each icon to perform complement processing. Consisting autocomplete definition data 127 that has been defined. Actually, the conversion information data 122, the template file 123, the skeleton code 124, the entire route pattern format file 125, and the automatic complement definition data 127 are stored in the memory device in the same manner as the input element provision data 140 and the internal data 150. .

  7 is an example of the conversion information data 122, FIG. 8 is an example of the template file 123, and FIG. 9 is an example of the skeleton code 124. Here, the skeleton code 124 indicates a program code in which a client-side method generated when an IDL file is compiled is described. FIG. 10 shows an example of the automatic complement definition data 127. As will be described later, the auto-complementation control unit 125 refers to the flag of the auto-complementation definition data 127 for each icon, and classifies the complement process according to ON / OFF of the corresponding flag. FIG. 10 shows only a part of the complementary determination flags.

  FIG. 11 shows a series of processing operation examples in the specification conversion means 120 of FIG. In FIG. 11, steps 1100, 1110 to 1114, 1120 to 1124, and 1130 to 1133 indicate processing in the conversion control unit 121, and step 1200 indicates processing in the automatic complement control unit 126.

  When the conversion button 121 on the keyboard or input screen is pressed, the conversion control unit 121 of the specification conversion unit 120 inquires of the user whether to perform automatic complementation (step 1100). When automatic completion is not performed, the conversion control unit 121 immediately proceeds to steps 1110, 1120, and 1130, and starts conversion according to each conversion pattern. When performing auto-complementation, the conversion control unit 121 transfers control to the auto-complementation control unit 126, and after the auto-complementation control unit 126 performs auto-complementation processing (step 1200), the process proceeds to steps 1110, 1120, and 1130. . The automatic complement process in step 1200 will be described later. Below, the process of each conversion pattern is demonstrated.

  In the conversion pattern 1, first, the conversion information data 122 (FIG. 7) managing the comment text to be output to the program is read (step 1111). Next, the template file 123 (FIG. 8) for each programming language is read (step 1112). Next, based on the auto-completed or original internal data 40 (FIG. 5), the conversion information data 122 and the template file 123 are used to replace the program source, and the communication service software 20 is generated. Next, based on the information obtained in step 1113 and the entire route pattern format 125, an all route pattern file for use in an automatic test describing the processing of all routes of the input service specification is generated (step 1114). ).

  In the conversion pattern 2, first, the skeleton code 124 (FIG. 9) is read (step 1121). Next, the currently used method is searched and extracted based on the automatically completed or original internal data 40 (FIG. 5) (step 1122). Next, the source code based on the internal data is inserted into the skeleton code usage method to generate the communication service software 20 (step 1123). Next, based on the information obtained in step 1123 and the entire route pattern format 125, an all route pattern file for use in the automatic test is generated (step 1114).

  In the conversion pattern 3, first, the template file 123 (FIG. 8) is read (step 1131). Next, the template file 123 is generated as the communication service software 20 by inserting necessary information based on the auto-complemented or original internal data 40 (FIG. 5) (step 1132). Next, based on the information obtained in step 1132 and the entire route pattern format 125, an all route pattern file for use in the automatic test is generated (step 1133).

  FIG. 12 shows a detailed operation example of the automatic complementing process in step 1200 in FIG. The user can select whether or not the input service specification is automatically supplemented with a lack of definition or program code that does not depend on the service. When the user selects auto-complement, the conversion control unit 121 passes control to the auto-complement control unit 126, and the auto-complement control unit 126 starts auto-complement processing.

  When the control is transferred from the conversion control unit 121, the automatic complement control unit 126 reads the internal data 40 (FIG. 5) (step 1201). Thereafter, the processing after step 1202 is repeated for the number of icons to which the internal data 40 is input.

  First, it is checked whether or not the input icon is an auto-completion target selected by the user (step 1202). If it is an object of auto-completion, it is checked whether or not auto-completion has been completed (step 1203). Whether or not automatic completion is to be performed is determined based on an icon attribute (see FIG. 5).

  If the input icon is an object of auto-completion and is not auto-completed, auto-completion definition data 127 (FIG. 10) is acquired for the input icon (step 1204), and the auto-completion definition data is included in the auto-completion definition data. It is checked whether the defined complement determination flag is ON or OFF (step 1205). If the flag is ON, the template file 123 (FIG. 8) is read (step 1206), and the icons describing the processing in the template file 123 are automatically complemented (step 1207). If the flag is OFF, icon exception information (see FIG. 5) in the internal data of the input icon is acquired (step 1208), and the exception processing icon is automatically complemented (step 1209). Thereafter, the auto-completed flag is turned ON as the icon attribute (step 1210).

  In step 1211, it is checked whether or not the icon is the final icon. If the icon is not the final icon, the process returns to step 1202 to repeat the process. If the icon is the final icon, the automatic complement process is terminated. When the automatic completion process ends, the automatic completion control unit 126 returns control to the conversion control unit 121.

  FIG. 13 shows an example of an input screen after automatic completion. A shaded icon is an automatically complemented icon. The automatically complemented process is, for example, log output. In FIG. 13, icons such as log (transmission [before]) and log (transmission [after]) are automatically complemented in the case of the auto-completion flag ON, and exception (log output), exception (process call), An icon such as an exception is automatically complemented in the case where the auto-completion flag is OFF. The specification input unit 110 takes in the automatically completed internal data, and displays the icon with a different color when the automatic completion flag is on, for example, so that the automatically complemented portion can be identified. This allows the user to make corrections or changes if necessary. Whether or not the user has made corrections / changes is reflected in the icon attribute (see FIG. 5).

  FIG. 14 shows a format example of the entire route pattern file 30 to be generated. The user creates a test pattern definition file 40 that describes the processing required for each processing (for example, definition of return value at the time of signal transmission) based on the entire route pattern file 30. To do. FIG. 15 shows an example of the test pattern definition file 40.

  FIG. 16 shows a series of verification processing operation examples in the specification verification unit 130 of FIG. The specification verification unit 130 reads internal data (step 1301). Thereafter, the processing after step 1302 is repeated for each icon. First, it is checked whether or not the icon has been automatically completed (step 1302). If the icon has not been automatically completed, the process proceeds directly to the specification verification process (step 1304). If it has been automatically completed, it is checked whether the user has made corrections / changes (step 1303). If the user has made corrections / changes, the process proceeds to specification verification processing (step 1304), and the user makes corrections. If no change has been made, go to step 1305. In the specification verification processing in step 1304, the specification is verified, such as state transition verification, based on the state check information such as parameter check and verification information knowledge base. In step 1305, it is checked whether or not it is the final icon. If it is not the final icon, the process returns to step 1301 to repeat the process. If it is the final icon, the verification ends.

  FIG. 17 is a configuration example of the automatic test control means 160 shown in FIG. The automatic test control means 160 includes an automatic test execution control unit 161 that executes and controls the automatic test of the generated communication service software 20 step by step based on the automatic test pattern definition file 40 (FIG. 15). The test pattern definition file 40 and the communication service software 20 to be tested are read, and a file reading unit 162 that checks whether the file 40 is correct and an automatic test log output unit 163 that outputs a test execution result log Is done.

  FIG. 18 shows a processing flow example of the automatic test control means 160. Hereinafter, a series of processing operation examples in the automatic test control means 160 will be described with reference to FIG.

  The file reading unit 162 reads the automatic test pattern definition file 40 and the communication service software 20 to be tested (step 1401), and checks whether the automatic test pattern definition file 40 is correct (step 1402). If the automatic test pattern definition file 40 is not correct, an error notification is sent to the user (step 1403), and the automatic test process is terminated. If the automatic test pattern definition file 40 is correct, the file reading unit 162 passes control to the automatic test execution control unit 162.

  Based on the automatic test pattern definition file 40, the automatic test execution control unit 161 executes and controls the automatic test of the communication service software 20 step by step as follows. First, it is checked whether there is an unexecuted test route (processing route) (step 1404). If there is no unexecuted test route, the automatic test is terminated. If there is an unexecuted test route, the test of the next route (first in the first case) is started (step 1405). Then, whether or not there is a next execution process in the route is checked (step 1406). If there is no next execution process, a log is output (step 1407), and the process returns to step 1404. If there is a next execution process, one of the processes is executed (step 1408). Then, it is checked whether an error has been detected in the processing (step 1409). If an error is detected in the process, a log including the error is output (step 1410), and the process returns to step 1406. If no error is detected, the log is output (step 1411), and the process returns to step 1406. Thereafter, the same processing is repeated and the automatic test is executed. The test execution log is output from the automatic test log output unit 163.

  It should be noted that the processing functions of some or all of the units in the program automatic generation apparatus shown in FIG. 1 can be configured by a computer program, and the present invention can be realized by executing the program using a computer, or Needless to say, the processing procedures shown in FIG. 11, FIG. 12, FIG. 16, FIG. 18 and the like can be configured by a computer program and the program can be executed by the computer. In addition, a computer-readable recording medium such as an FD, MO, ROM, memory card, CD, or the like is stored in the computer. In addition, the program can be recorded and stored on a DVD, a removable disk, etc., and the program can be distributed through a network such as the Internet.

It is a functional block diagram which shows one Example of the program automatic generation apparatus of this invention. It is a figure which shows the structural example of communication service software. It is an example of a screen of a specification input means. It is an example of input element provision data. It is an example of internal data. It is a figure which shows the structural example of a specification conversion means. It is an example of conversion information data. It is an example of a template file. It is an example of a skeleton code. It is an example of automatic completion definition data. It is a processing operation example of a specification conversion means. It is an example of a detailed flow of the automatic complement process in FIG. It is an example of the input screen after automatic completion. It is an example of all the route pattern files. It is an example of an automatic test pattern definition file. It is an example of processing operation of a specification verification means. It is a figure which shows the structural example of an automatic test control means. It is an example of processing operation of an automatic test control means.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Communication service operation specification 20 Communication service software 30 All route pattern file 40 Automatic test pattern definition file 100 Program automatic generation apparatus 110 Specification input means 120 Specification conversion means 121 Conversion control part 122 Conversion information data 123 Template file 124 Skeleton code 125 All routes Pattern format 126 Automatic completion control unit 127 Automatic completion definition data 130 Specification verification means 140 Input element provided data 150 Internal data 160 Automatic test control means 161 Automatic test execution control part 162 File reading part 163 Automatic test log output part

Claims (4)

In an automatic program generation device that converts communication service operation specifications visually input using graphical representation into communication service software,
Means for storing the operation specifications of the input communication service as internal data together with information such as transmission / reception signals defined in advance as the operation specifications of the communication service based on the input element provision data for displaying the input elements;
Means for extracting information necessary for conversion based on the stored internal data, and generating communication service software based on a plurality of conversion formats not depending on a service prepared in advance;
Means for extracting all processing routes from the operation specifications of the service visually input using the graphic representation, and assigning route numbers to all the processing routes;
Means for outputting test data describing input / output signal patterns corresponding to all route numbers;
An automatic program generation device comprising: In a specification input means that can be visually input using a graphical representation, and an automatic program generation device that converts operation specifications of an input communication service into communication service software,
Means for storing the operation specifications of the input communication service as internal data together with information such as transmission / reception signals defined in advance as the operation specifications of the communication service based on the input element provision data for displaying the input elements;
Based on the stored internal data, information necessary for conversion is extracted, communication service software is generated based on a plurality of conversion formats that do not depend on services prepared in advance, and the operation specifications of communication services are insufficiently defined. Means for automatically completing necessary specification input elements when automatic completion of program code independent of part or service is selected;
Means for extracting all processing routes from the operation specifications of the service visually input using the graphic representation, and assigning route numbers to all the processing routes;
Means for outputting test data describing input / output signal patterns corresponding to all route numbers;
An automatic program generation device comprising: In a specification input means that can be visually input using a graphical representation, and an automatic program generation device that converts operation specifications of an input communication service into communication service software,
Means for storing the operation specifications of the input communication service as internal data together with information such as transmission / reception signals defined in advance as the operation specifications of the communication service based on the input element provision data for displaying the input elements;
Based on the stored internal data, information necessary for conversion is extracted, communication service software is generated based on a plurality of conversion formats that do not depend on services prepared in advance, and the operation specifications of communication services are insufficiently defined. Means for automatically completing necessary specification input elements when automatic completion of program code independent of part or service is selected;
Specification verification means for verifying the operation specifications of the input communication service;
Means for extracting all processing routes from the operation specifications of the service visually input using the graphic representation, and assigning route numbers to all the processing routes;
Means for outputting test data describing input / output signal patterns corresponding to all route numbers;
An automatic program generation device comprising:   The automatic program generation device according to any one of claims 1 to 3, comprising means for reading test data and generated communication service software, controlling execution of an automatic test, and means for outputting an automatic test result. An automatic program generation device further comprising the program generation device.

Images