JPS62221728A - Backup system for development of program - Google Patents

Abstract

PURPOSE:To quickly and accurately grasp the genuine request of a user for synthesization of programs by replacing the internal information on the picture transition based on the internal state information on the picture transition as well as the input information received from an interactive picture then outputting a picture format. CONSTITUTION:A picture image memory device 3 used in a picture transition simulation mode is provided together with a picture transition rule memory device 4 used in the picture transition simulation mode, a program parts data base 5 used for synchronization of picture processing programs, and a dictionary memory means 14 used for analysis of the specifications of the picture processing program. Both the interactive picture format of an interactive processing system and the inter-picture transition rule are previously provided. Then the transition rule of the corresponding picture is interpreted from the input information received from each interactive picture as well as the internal information on the picture transition. Thus the interactive picture to be outputted next is decided and displayed. While the internal state of the picture transition is repetitively replaced to attain the simulation of the picture operation.

Description

[Detailed Description of the Invention] [Industrial Application Field] The present invention relates to a program development support method, and in particular to a program development support method for prototyping an interaction processing system, program synthesis, and reproduction/conversion of existing programs. It is.

[Conventional technology]

In conventional software development methods, users of the completed software are asked to make decisions without having a clear image of how it will be realized on a computer at the stage of solidifying the requirements specifications, and they are often asked to make decisions based on incorrect specifications. Programs are often developed. In this case, modifications are required later, which poses a major obstacle to improving software productivity. For this type of method, related reference materials include, for example, Hitachi Hyōmen's March 1984 issue of ``Online data entry development support tool'' HTSPO.
There are T”J etc.

Additionally, systems for reusing existing software are being considered for software development. In this method, program parts are created from an existing source program, but the existing program is not necessarily a structured program suitable for being made into parts. Traditionally, structuring existing programs was done manually.

In addition, as one approach to improving software productivity, a prototyping method has traditionally been used to present the input/output behavior of the software system to be developed to the user before the actual system is put into operation, in order to quickly determine the required specifications. Proposed. The prototype method of the dialog processing system is generally limited to the display function of the dialog screen format. In addition, there are methods for prototyping screen transition control, but because they are limited in scope, they involve selecting from several screen transition patterns, and it is not possible to freely define the rules for screen transitions. I couldn't do it. Therefore, there was no function to return to any screen and re-execute the prototype while it was running. About this.

As can be seen in the above references.

In addition, in the prototype pink method of the conventional dialogue processing system, when displaying the screen format of the dialogue screen, in the actual system, the content is not displayed for the output field that should display different content depending on the calculation, or the content is not displayed. A method is adopted in which predefined sample values are displayed on the screen format. For this reason, (a
(b) It is necessary to define sample data in advance. Regarding these, for example, see the Information Processing Society of Japan, Proceedings of the National Conference of the First Half of 1981, ``Software Development and Expansion Reuse Facility SEA Using Real Image Direct Processing Method.''
/Realization of I''.

[Problem that the invention seeks to solve]

In this way, in the conventional software development stage, revisions are required after the software is developed with incorrect specifications, and even when existing programs are reused, the program does not necessarily have a structure suitable for componentization. do not have. Furthermore, in the prototyping method, since the target is limited, a method of selecting from several screen transition patterns is used, and rules for screen transition cannot be freely defined.

The objects of the present invention are (a) when creating an interaction processing program, to be able to quickly and accurately grasp the user's true requirements and synthesize the program, and (b) to convert an existing program into a structured program. Cc,) the external specifications of the dialogue processing system can be determined early, and (d)
The purpose of the present invention is to provide a program development support method that can display content similar to the data that actually appears.

[Means for solving problems]

In order to achieve the above object, the program development support method of the present invention provides (1) dialogue screen format information, transition rule information between each dialogue screen, internal state information regarding screen transitions, and cumulative information of internal states regarding screen transitions. Accumulated in the system, based on human power information from the dialog screen and internal state information related to screen transitions, update internal state information related to screen transitions, output dialog screen format after transition, and screen transitions according to the dialog screen transition rules. After adding the cumulative information of the internal state related to the screen transition, extract the internal information related to the screen transition of the specified screen from the cumulative information of the internal state related to the screen transition, update the internal information related to the screen transition, and update the screen format. The feature is that it outputs . In addition, after adding input information and cumulative information, the output screen format and input data from the dialogue screen are sequentially searched in the cumulative order according to the cumulative information of the input data from the output screen format and the dialogue screen, and Another feature is that the corresponding output screen format and the data input from that screen are sequentially displayed on the interactive screen.

In addition, using screen images that have been defined or screen images extracted from existing systems and screen transition rules, the development target program is demonstrated through dialog screen simulation, and the final user's required specifications are determined by modifying it. After generating the dialog screen transition control program from the determined result, a screen processing program corresponding to each screen is synthesized using program parts stored in advance based on an analysis of the specifications of the screen processing program input by the user. Finally, the screen processing program is combined with the screen processing portion of the dialog screen transition control program to synthesize the entire interactive program. In addition, the definition of the dialog screen format used in the dialog processing system and the definition of sample data to be output to the dialog screen are stored in the system, and based on the definition of the specified dialog screen format, the output fields therein are After searching for the number data to be displayed, modifying it as necessary, and accumulating it in relation to the screen format definition, it is associated with the sample data and stored (specified from the screen format definition The feature is that it edits the data and outputs the dialog screen used in the dialog processing system in the form of displaying sample data.

Furthermore, in an interaction processing system that has a process of inputting an existing random logic program, analyzing its structure, creating a data flow and a control flow, and a process of structuring the program, the created control flow is The process of referencing and deleting jump instructions, the process of separating parts that perform the same processing as common processing, and checking the data flow every time the program is converted to confirm that the meaning of the program has not changed. It is characterized by the process of

[For production]

(a) In the first embodiment (Claim 3), in order to quickly and accurately grasp the user's required specifications, a screen image based on an existing program screen image or a registered screen definition and one screen transition rules are used. By doing so, we perform rapid prototyping to extract the true requirements from users, and immediately use the results to synthesize a δ- program, contributing to improved software productivity. In addition, in the second embodiment, by detecting random logic parts using a control flow created from an existing program, deleting jump instructions, etc., and extracting the same process as a common process, the existing program can be improved. Be structured. Each time a program is converted, a comparison check is performed with the data flow created from the existing program to confirm that the meaning of the program has not changed.

Further, in the third embodiment (Claim 1), the dialog screen format of the dialog processing system and the transition rules between screens are given in advance, and the input information from each dialog screen and the internal state regarding screen transition are used to By interpreting the transition rules of this screen, determining and displaying the next dialog screen to be output, and repeating the process of updating the internal state of screen transitions, it is possible to simulate screen operations.
In addition, the internal states related to screen transitions are sequentially accumulated and stored for each process, and the state at any point in time is extracted when necessary, the internal state is updated, and the corresponding screen is displayed. allows re-execution from any point in time.

In addition, in the fourth embodiment, sample values to be displayed in the output field of the display screen are accumulated in advance, and information such as the name, type, number of digits, etc. of each output field of the screen to be displayed during prototyping is used to accumulate sample values. By selecting matching or similar sample data candidates from the sample data provided, modifying them as necessary, and storing them in association with the display screen, it is possible to
This makes it possible to display screens that closely resemble the production system. Furthermore, in the fifth embodiment (if search range 2),
By giving the dialog screen format and transition rules between screens in advance for the dialog processing system, the transition rules for this screen are interpreted based on the input information of each dialog screen and the internal state related to screen transitions, and the next dialog to be output is determined. By repeating the process of determining and displaying the screen and updating the internal state related to screen transitions, it is possible to simulate screen operations. Furthermore, data input from the dialog screen and the display screen are sequentially accumulated for each process. By memorizing, the information accumulated after the simulation is
It is possible to reproduce a simulation that has already been performed by sequentially searching in the accumulated order and sequentially displaying the screen displayed based on this information and the information input from that screen on the dialog screen.

-1,1- 〔Example〕 Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

FIG. 1 is a block diagram of a dialog processing system showing a first embodiment of the present invention. This paper shows a method for synthesizing programs by effectively utilizing the results of this understanding.

With conventional software development methods, (a) program development is done manually, which takes time; and (b) the created program may not meet the true needs of the user. , Productivity was low due to the fact that it often had to be reworked. In this embodiment, we focus on this point, and in order to quickly and accurately grasp the user's required specifications, we use screen images and screen transition rules based on existing program screen images or registered screen definitions. The purpose is to conduct rapid prototyping, extract the true requirements from users, and immediately use the results to synthesize programs using computers, thereby improving software productivity. In Figure 1, 1 is a terminal device that performs screen display and keyboard input for the final user, and input/output for program creation, and 2 is a computer that performs screen transition simulation for prototype pink and computation for program synthesis. It is a processing device.

Further, 3 is a screen image storage device used during screen transition simulation, 4 is a screen transition rule storage device used during screen transition simulation, and 5 is a program component database used when synthesizing a screen processing program. Further, 14 is a dictionary storage device used for analyzing the program specifications of the screen processing program.

FIG. 2 is a functional configuration diagram of the arithmetic processing device in FIG. 1. In FIG. 2, 6 is a screen transition simulation function section, including an image storage device 3 and a rule storage device 4.
are connected to and receive data from them. 7 is a functional unit for modifying screen transition rules and screen definitions (by modifying screen images). The rule screen definition modification function section 7 stores the modified results in the image storage device 3 and the rule storage device 4. The processing results of the screen transition rule and screen definition correction function section 7 can be immediately demonstrated to the user for confirmation by the screen transition simulation function section 6. 8 is an interactive screen transition control program generation function unit. The transition control program generation function unit 8 generates an interactive screen transition control program (M corresponds to the program skeleton part) from the screen transition rules determined by the user.

Reference numeral 9 denotes a screen processing program specification analysis function unit, which uses the analysis dictionary 14 to analyze the specification (input by a human) of the screen processing program corresponding to one screen in the program to be developed. 10 is a program component search/combination function section, which based on the results of analyzing the screen processing program,
Search for the necessary parts from the program parts database 5,
Combine to match the program specification algorithm.

Reference numeral 11 denotes a data type correction/check function unit of the program based on data type inference. The correction/check function unit 11 corrects/checks the consistency of data types according to the data flow set in the function unit 10 in order to determine the interface between the parts merged in the component search/combination function unit 10. I do. Reference numeral 12 denotes a source code generation function unit for a screen processing program, which generates a screen processing program from the connection relationship of program components whose data types have been checked by the data type correction/check function unit 11. Reference numeral 13 denotes an overall program synthesis function section, which combines a screen processing program section with a corresponding portion of the dialog screen transition control program to synthesize the entire completed program. Specifically, each of these functional units is composed of a small-sized arithmetic processing device such as a microprocessor, and some of them also include programs.

Next, the operation of this embodiment will be explained using FIG. 3 and FIG. 4. FIG. 3 is a diagram showing the relationship among the program created according to this embodiment, the screen and screen processing program, and the screen transition rule and interactive screen transition control program.

(b) shows the dialog screen transition control block "I-gram part 27," and (a) shows the other zologram parts.aT3rMl As shown in (a) and (h), The program includes an interactive screen transition control program section 27 representing the framework of the entire program;
For each qto screen +8.19, 20°21, the corresponding screen processing block 1gram part 22°23.24.25 and more neatly made. :J, ,By rapid prototyping using the screen transition simulation function section 6 and the screen transition rule modification function section 7, after the user's required specifications are determined at an early stage based on the screen transition simulation, the screen transition rules are generated. Ru.

On the other hand, the screen processing programs 22 to 25 shown in (a) are
Based on the program specifications input by the user for each m-screen 18 to 21, the screen processing program specification analysis function unit 9
is analyzed by the program component search/combination function section 11.
The used program parts are retrieved from the program parts database 5, and they are combined so as to match the algorithm of the program specifications, thereby clarifying the data flow between the parts. The program data type correction/checking function unit 11 determines the data type by inferring the data type along the data flow between the combined program parts, and generates the source code of the screen processing program. The synthesized screen processing program is executed by the data definition section 31 and the procedure definition section 2 of the control program section 27 in (b).
9, and the entire program is synthesized.

Next, with reference to FIG. 4, a process of generating a complete program by combining the dialogue screen transition control program serving as the framework and the screen processing programs corresponding to each screen corresponding to the branches will be explained. In FIG. 4, 32 in (a) is the entire program synthesized by this example, and (b) and (c)
22 and 23 are screen processing program sections.

The overall program 32 is broadly divided into a data definition section and a procedure definition section. The data definition section includes a screen transition control data definition section 34 required by the dialog screen transition control program section 27 and a screen processing data definition section 35 required by the screen processing program. The procedure definition section includes an initial processing procedure definition section 36, a screen state procedure definition section 37 corresponding to each screen, and a termination processing procedure definition section 38. The screen state procedure definition section 37 is composed of a procedure definition section 39 of a screen processing program section and a procedure definition section 40 representing screen transition rules from the screen state. The screen processing program section 22 includes a screen processing data definition section 41 and a screen processing procedure definition section 42.

First, the dialog screen transition control program generation function section 8 generates the screen processing data definition section 3 of the overall program 32.
5 and the procedure definition section 39 of the screen processing program section are blank.

Next, the screen processing program specification analysis function section 9. Program parts search/combination function section 10. The screen processing program sections 22, 23, 24, and 25 are synthesized by the program data type correction/check function section 11 based on data type inference. Next, the screen processing data definition section 41 in the screen processing program 22 is embedded into the screen processing data definition section 35, and the screen processing procedure definition section 4 in the screen processing program section 22 is embedded.
2 is embedded in the procedure definition section 39. Next, the interface is confirmed by checking the data type between the interactive screen transition control program section 27, which forms the skeleton of the synthesized program, and the embedded screen processing program section, and a complete program is generated.

In this way, in this embodiment, the program after synthesis is divided into the screen processing program part and the screen transition rule definition part, corresponding to the screen to be displayed when the program is executed. maintenance or function/
To improve performance, etc., users can easily understand the content when referring to the source code. In this embodiment, when developing an interaction processing program, in order to determine the required page specifications of the user at an early stage, a screen image output from an existing program or a screen image based on an already registered screen definition is used. Screen transition rules allow prototyping, and the results of prototyping can be used as they are to automatically generate the skeleton part of the program to be developed, while other parts can be synthesized using program parts, making it easier for users to It is possible to improve the productivity of program development that accurately reflects requirements.

Next, FIG. 5 is a functional block diagram of an interactive program development support system showing a second embodiment of the present invention. In this example, an existing random logic program is modified by deleting jump instructions and consolidating common processing.
A method for reproducing and converting into structured programs is realized. In other words, in this embodiment, an existing program can be modified by using a control flow created from an existing program to identify random logic parts, delete jump instructions, etc., and extract parts of the same processing as common processing. Be structured. In that case, each time you convert the program,
Comparison checks are performed with data flows created from existing programs, so you can confirm that the meaning of the program has not changed.

In FIG. 5, 51 is a video data terminal;
52 is a computer processing device, 53 is an inference rule accumulation database, 54 is a part of the reproduction conversion inference control 20, 55 is a cheetah flow creation unit, 56 is a control flow creation unit, 57 is a jump instruction deletion unit, and 58 is a common processing unit. The output section 59 is a cheetah flow check section. Each of the functional units is composed of a small arithmetic processing device such as a microprocessor.

FIG. 6 is a flowchart 1-1 showing the processing procedure of this embodiment.
It is. First, an existing random logic program is input (step 61), its structure is analyzed, and a data flow indicating the flow of data for each procedure in the program is created (step 62). The data flow of the entire program is represented as a data flow diagram with each procedure as a box and the input/output data to the procedure as arrows. Each box shall be expressed as the following structure.

((Input/output data type) (Data flow) (Function) ・・・・・・・・・) Next, from the program input in the same way, create a control flow showing the steps of computer processing and create a flowchart diagram. (Step 63).

Then, with reference to the flowchart, random logic parts of the program are detected and it is determined which part to move (steps 64 and 65).

However, skip statements in file END processing of file input and jump statements to file input after completion of processing for a code are not considered here.

Once the part to be moved is determined, that part is moved to the location where the jump statement was, and the jump command is deleted. and,
A comparison check is performed with the initially created data flow (step 66) to confirm that the meaning of the program has not changed. Repeat the same process until there are no more jump sentences.

Next, if there is a jump statement in the file END process (step 67), replace the jump statement in the END process with the file end flag setting wheel, and from that part to the jump statement to the file input, It is placed in a repetitive statement based on the determination of the file end flag (step 68). Thereafter, in the same manner, a comparison check with the cheetah flow is performed (step 69). Now you can remove all the jump sentences.

Next, if there is something that appears many times in the same process (step 70), step 71 divides it into a common process.
), replace the part that performed that processing with the call statement for the common processing that was extracted.

Then, in the same way, a comparison check with the cheetah flow is performed (step 72). This completes the structured program.

Next, a procedure for structuring an existing program will be described using a simple example with reference to FIGS. 7 to 11.

FIG. 7 is a diagram showing a part of an existing program written in the COB OL language, and FIG. 8 is a diagram showing a part of a data flow diagram created from the program in FIG.
Figure 9 is a part of a flowchart representing the control flow created from the program in Figure 7, and Figure 10 is a part of a structured program created by reproducing and converting the program in Figure 7. FIG. 11 is a diagram showing a part of a PAD diagram representing a control flow created from the program of FIG. 1O.

In each figure, parts such as the data declaration section, variable initialization, and files 0PEN-CLO8E are omitted.

First, the program shown in FIG. 7 is input and analyzed to create the data flow diagram shown in FIG. In Figure 7, file read and key set.

Instructions are arranged in the order of detail light, key condition, and end. The data flow diagram in FIG. 8 shows the flow and processing of each data in this program, and even if the control structure changes, the data flow remains the same.

Next, in the same way, a flowchart representing the control flow shown in FIG. 9 is created from the program shown in FIG. By creating this flowchart, it is possible to easily detect where random logic is used in program control. Note that 5-1.5-2 is a jump instruction related to file input, so 5-3.5-4 is first executed.
．． Delete 5-5.

From the relationship of arrows 5-3.5-4.5-5 in Figure 9, 5
-17 to 5-20 are moved into the conditional statement of 5-8, and the condition of 5-8.5-1.7 is moved to the front of 5-14 where all three arrows meet. It turns out that it is sufficient to make it an executable sentence within a sentence.

First, since 5-3 is a goto instruction of 3-2, the jump destinations from 3-13 to 3-18 are executed as 3-2's g.
Move to the oto statement.

And, since the part before 5-1.4, that is, before 3-9, is an executable statement, the goto in 3-13
Since the instruction jumps to 3-9, it is replaced with rcontinueJ, which does not execute anything.

Next, change the rcontjnueJ part of 3-14 to 3-1
Replace from 5 to 3-18. Then, 3-18 indicates to jump to 3-8, which means that the part before 3-9 is replaced, so 3-18 is replaced with 3-8.

Next, rcont and 1nueJ of 3-3 are replaced with 3-4 and after, but from 3-4 to 3-8 because of the condition that they are also before 3-9.

And about the data flow of this program,
Perform a data float comparison check in the figure to confirm that the meaning of the program does not change.

Next, delete the jump instruction in 5-1.5-2, but since this is a jump instruction for file end processing and reading the next L7 code, 3-1 is endfl
Replace the statement 6-1 that sets the ag, and en
The repetitive sentences 6-2 to 6-6 are based on the determination of dflag.

Then, 3-12 is replaced with statement 6-5, which inputs the following code and sets endflag when the file ends.

As a result, all the jump statements have been deleted, so the labels in the program can also be deleted. Then, the data flow of this converted program is compared and checked with the data flow of FIG.

Next, common processing is extracted.

In Figure 7, 3-5 to 3-7 and 3-15 to 3-1
7 was the same process, but 3-18 was replaced with 3-8, so the number after 3-7 and the number after 3-17 became 3-8. Therefore, these four lines are extracted as 6-7. Then, 3-5 to 3-8.3-15 to 3-8 are replaced by statements 6-3.6-/l that call 6-5, respectively. Here, the name of the extracted perform is assumed to be a unique name given by the system, and is not necessarily a meaningful name as in this embodiment.

And here again, regarding the program after conversion, the 8th
Confirm the meaning by checking the data flow in the diagram and comparing it. In this case, by creating endfJag, the data flow for setting and determining en df ] a g increases, but the meaning of the program does not change. Note that when this conversion is performed, the data declaration section is
Declare endfJag with a unique name.

In this way, the reproduction conversion into a structured program is completed. As is clear from the PAD diagram of FIG. 11, the created program is structured. In this embodiment, it is possible to automatically reproduce and convert the existing progera t1, which is a random logic program, into a structured program. In addition, in this embodiment, COB
Although the OL program has been described, it is of course possible to process programs in other languages in the same way.

As is clear from the above explanation, in the second embodiment, an existing random logic program can be automatically regenerated and converted into a structured program. By structuring the program, even if the program is not clearly defined, it becomes easier to understand and maintain the program. Furthermore, by structuring a program, even when creating program parts from an existing program, there are advantages such as the ability to create program parts with a good structure and the ability to automatically extract program parts.

FIG. 12 is a functional block diagram of an interactive program development support system showing a third embodiment of the present invention. In the third embodiment, it is possible to simulate the operation of the dialog processing system based on the screen format of the dialog processing system and the definition of the screen transition rules, and the internal state of the computer accompanying screen transitions is sequentially stored and the simulation is performed. By making it re-executable from any point,
To realize a method for easily determining external specifications of a dialogue processing system at an early stage. That is, in this embodiment, the dialog screen format of the dialog processing system and the transition rules between screens are provided in advance.

Based on the input information from each dialog screen and the internal state related to screen transition, the transition rules for that screen are interpreted, the next dialog screen to be output is determined and displayed, and the internal state of the screen transition is updated. By repeating it, it is possible to simulate screen operations, and the internal state related to screen transitions is stored cumulatively for each step, and the state at any time is extracted from this when necessary, the internal state is updated, and the corresponding By displaying a screen that allows you to rerun past simulations from any point in time.

In FIG. 12(a), ], OOa is a central processing unit including memory, 200a is a display and keyboard of a video data terminal that simulates the interaction operation of the interaction processing system, and 300a is a format of the screen displayed in the simulation. This is a file memory that stores information and history information of internal states used to control screen transitions during simulation.

Moreover, FIG. 12(b) shows the central processing bag @
FIG. 100a is a configuration diagram of an operational functional unit.

In FIG. 12(b), 81 is a keyboard of the video terminal 200a shown in FIG. 12(a), and 82 is a display of the video terminal 200a. 83
is a portion that stores a large amount of screen format information displayed during simulation in the file memory 300a shown in (a). 84 is the file memory 300a
This is a part that accumulates history information of internal states used for screen transitions displayed during simulation. 85 is
A portion for inputting data from the keyboard 82, and a portion 86 for temporarily storing the input data.

87 is a screen transition rule for determining the next screen to be displayed and updating the internal state based on the internal state and input data at the time of displaying each screen for each screen format defined in the format information storage section 83. information and accumulate it. 88
89 is a storage unit that temporarily stores internal state information regarding screen transitions, and 89 is a screen transition rule interface that stores rule information based on the input data of the storage unit 86 and the internal state information of the storage unit 88IJ. In accordance with the screen transition rules of the section 87, the internal state information is updated, a screen to be displayed next is determined, and the screen is displayed by the screen display function section 90.

The screen display function section 90 includes a screen transition rule interpreter 8.
9 or specified by the simulation re-execution starting section 94, the specified screen format is selected and inputted from the screen format information storage N188 and displayed on the display 82 of the video data terminal 31-. The input data analysis section 91 starts the screen transition rule interpreter 89 based on the input data from the screen stored in the storage section 86 to continue the simulation, or the simulation re-execution starting function section 94 starts the screen transition rule interpreter 89 to continue the simulation. Determines whether to re-run the simulation from a specified screen among the screens on which simulation has already been performed. As specified by the screen transition rule interpreter 89, the internal state information saving unit 92 adds and accumulates the internal state information 8 related to the screen transition in the current display screen to the history information storage unit 84 as cumulative information of internal states related to the screen transition. The information setting unit 93 extracts the internal information of the screen transition on the screen specified by the simulation re-execution starting unit 94 from the accumulated information of the internal state regarding the screen transition in the history information storage unit 84, and Internal state information storage unit 8
Set to 8. The simulation re-execution unit 94 instructs the screen display unit 90 to display the screen format in the state specified by the input data analysis unit 91 on the display, and also resets the internal state information regarding the screen transition of the specified screen. This is specified in the information setting unit 93.

Next, the screen operation simulation operation of this embodiment will be described in detail. It is assumed that a dialog processing screen to be simulated is displayed on the display 82, and internal state information regarding the screen is stored in the storage section 88.

When data is input from the keyboard 81, the input section 85
temporarily stores the input data in the temporary storage section 8G. The input analysis unit 91 analyzes the input data, decides to continue the simulation, and passes control to the rule interpreter 89. The rule interpreter 89 has a temporary storage section 86.
Based on the input data stored in the input data and the internal state information regarding screen transition (in the storage unit 88), the screen transition rules for the exit screen in the rule storage unit 87 are interpreted, and (a) the next screen to be displayed is determined. the display control unit 90 selects the screen format in the format information storage unit 83 and displays it on the display 82; (b) also updates internal state information regarding screen transitions in the storage unit 88;
(c) The information saving unit 92 additionally stores information regarding screen transitions set in the storage unit 88 in the history information storage unit 84.

By repeating the above two steps, screen transitions of the dialog processing system can be simulated.

The instruction to re-execute the simulation from the specified screen is performed as follows.

It is assumed that a screen operation simulation has already been performed and the history information storage unit 84 has accumulated internal state information regarding one screen transition. When command data specifying simulation re-execution is input from the keyboard 81,
The data input section 85 temporarily stores input data in the temporary storage section 86 . The input analysis unit 91 analyzes input data,
It is decided to re-execute the simulation, and control is passed to the re-execution starting unit 94. The re-execution starting unit 94 instructs the display control unit 90 to select a specified screen format from the format information storage unit 83 and display the display 82.
At the same time, the information setting section 93 is instructed to extract internal state information related to screen transitions of the designated screen in the history information storage section 84 and reset it in the storage section 88 .

Thereafter, using the screen operation simulation function described above, simulations can be sequentially executed from the redisplayed screen. Note that in this embodiment, the simulation re-execution function was explained only as a function to re-display the screen that has already been used during the simulation, but the simulation re-execution function is limited to the function that re-displays the screen that has already been used during the simulation. By providing a function to sequentially extract the internal states of screen transitions in chronological order, it becomes possible to completely reproduce past simulations from any screen.

In this way, in this embodiment, it is possible to present the screen operation movements of the dialogue processing system to the user before the production system is developed, and it is also possible to reproduce the screen operation once performed from any screen. Therefore, the external specifications of the dialogue processing system can be determined at an early stage.

FIG. 13 is a functional block diagram of an interaction processing system showing a fourth embodiment of the present invention. In this example, when executing prototyping, there is no need to define each sample data to be displayed for the output field, and by displaying content similar to the data that is actually output, the screen can be displayed in a form similar to that of the production system. can be displayed.

That is, in this embodiment, sample values to be displayed in output fields on the display screen are accumulated in advance, and information such as the name, type, number of digits, etc. of each output field on the screen to be displayed during prototyping is used.

By selecting matching or similar sample data candidates from the accumulated sample data, modifying them as necessary, and storing them in association with the display screen, you can easily integrate them into the production system during prototyping. Display it on the screen in a close manner.

FIG. 13(a) is the same as FIG. 12(a), and 2
00b is a video data terminal, and 300b is a file memory that stores a screen format i- that associates definitions of screen formats used in prototype pink, sample data to be displayed, and sample data to be output and displayed.

In FIG. 13(b), 104 is a part of the file memory 300b in (a), which is used for prototyping and stores definitions of screen formats that do not include sample data, and 105 is also a part in (a). File memory 3
This is a part of 00b that stores the contents, name, type, etc. of the sample data value to be displayed. 106 also
This is a part of the file memory 300b shown in (a), and stores definitions of screen formats including sample data. Reference numeral 107 is a part of the video data terminal 200b in (a), which is a keyboard for specifying the screen format to which sample data should be added; 108 is a part for inputting screen format specification data from the keyboard 107; a part for selecting and inputting a specified screen format definition from the file memory 104;
Reference numeral 110 denotes a part that stores input screen format definitions, and 111 stores data in the file memory 105 based on attributes such as the name, shape, or number of digits of each output field specified in the screen format definition in the input part 110. A part that selects and inputs matching or similar sample data by comparing the attributes such as the name, type, number of digits, etc. of the stored sample data; 112 a part that temporarily stores the input sample data; 113 stores the sample data stored in the temporary storage section 112 as needed, and stores the attributes (number of digits, number of digits,
114 is the modified part 113
A part that stores sample data corrected by 115
is the definition of the screen format in the storage part 110, and 11
116 is a keyboard of the video data terminal 200b in (a), which specifies the screen to be displayed during prototyping.

117 is a part for inputting screen specification data from the keyboard 116; 118 is a part for selecting and editing the screen definition specified from the screen data input part 117 from the file memory 106 and outputting it to the display 119; 119 is a part (
This is the display of the video data terminal 200b in a), and displays a screen containing sample data in the output field.

Next, the operation of this embodiment will be explained in detail in (b).

The conversion of the sample data to the screen format definition is performed as follows. It is assumed that the screen format 1 definition that does not include sample data is stored in the file memory 104, and the contents of the sample data are stored in the file memory 105 in advance. keyboard 107
Screen designation data is input through the input section 108, and the corresponding screen format definition in the file memory 104 is selected and input through the selection input section 109, and set in the formats 1 to definition storage section 110. Next, for each output field in the accumulation section 110, the sample data selection input section 111 inputs the name of each output field,
Based on attributes such as type, number of digits, etc.

Sample data in the file memory 105 is selected and input to the sample cheater temporary storage section 112. moreover,
The data input into the temporary storage section 112 is transferred to the correction section 11.
3, the index, type, etc. are corrected and stored in the storage section 114. The above process is repeated for each output field in storage section 110. Finally, the storage activation section 115 stores the screen field definition in the storage section 110 and the sample data in the storage section 114 in the file memory 106 in association with each other.

Pro1-typing is performed as follows.

The screen designation data specified by the keyboard 116 is input through the data input section 117, and the data is inputted into the display output section 118.
The screen format with the corresponding sample data is selected and displayed on the display 119.

When selecting sample data, the usefulness can be further increased by adding a function to select from among several alternatives using random numbers or an interactive method.

In this way, in this embodiment, it is easy to create the display screen used for prototyping the interaction processing system in a form close to the actual image with sample data. This has the advantage of eliminating early confirmation of specifications.

FIG. 14 is a functional block diagram of an interaction processing system showing a fifth embodiment of the present invention. In this embodiment, based on the screen format of the dialog processing system and the definition of screen transition rules, it is possible to simulate the operation of the dialog processing system, and to sequentially store the screens displayed during the simulation and the data input from the screens. This makes it possible to reproduce simulations that have already been performed. This makes it easy to quickly determine the external specifications of the dialog processing system. That is, in this embodiment, the format of the dialogue screen of the dialogue processing system! - By giving the transition rules between screens in advance and the input information from each dialog screen and the internal state related to screen transitions, the transition rules for the moment are interpreted, and the next dialog screen to be output is determined and displayed. At the same time, by repeating the step of updating the internal state related to screen transitions, it is possible to simulate screen operations. Furthermore, by sequentially cumulatively storing the data input from the dialog screen and the display screen for each step, it is possible to simulate screen operations after the simulation. It is possible to reproduce a simulation that has already been performed by sequentially retrieving cumulatively stored information according to the order in which it was accumulated, and sequentially displaying a screen displayed based on this information and information input from that screen on an interactive screen.

In FIG. 14(a), 100C is a central processing unit including memory, and 200C is a video processor that simulates the dialog operation of the dialog processing system and reproduces the simulation.
Data terminal display and keyboard, 30
0C is a file memory that stores format information of screens displayed in simulation, identifiers of screens displayed during simulation execution, and history information of data input from the screens. In addition, in FIG. 14(b), 121 is the keyboard of the video data terminal 200C in FIG. 14(a), 122 is the display,
123 is a part in the file memory 300c that stores the screen format displayed during the simulation;
Reference numeral 4 denotes a portion in the file memory 300C that stores identifiers of screens displayed during simulation execution and history information of data input from the screen. Further, 125 is a part for inputting data from the keyboard 121, 126 is a part for storing input data, and 127 is a part for inputting data from the keyboard 1.
128 is a screen format defined in the file memory 123; 128 is a screen format defined in the file memory 123; Correspondingly, a part that stores screen transition rules for determining the next screen to be displayed and updating the internal state based on the data input from each screen and the internal state,
129 is a part that stores internal state information necessary for screen transitions, 130 is a part that stores display screen identifiers, and 131 is a part that stores display screen identifiers and data input from the screen in the file memory 124. 132 is a part that activates the input unit 133 at fixed time intervals; 133 is a part that activates the input unit 133 at fixed time intervals; 133 is a part that displays the identifier of the display screen stored in the file memory 124 and the data input from that screen each time the activation part 132 activates the input unit 133; 134 is a part that accumulates the input information from the display screen during simulation inputted by the input part 133. 135 is a part that searches the file memory 123 for the corresponding screen format based on the screen identifier. death,
This is the part to be outputted and displayed on the display 122, and if the storage part 134 contains input information to the screen, it is outputted and displayed on the display 122 together with the screen format.

Next, the operation of the screen operation simulation will be described. It is assumed that a screen format to be simulated is displayed on the display 122, the identifier of the screen is stored in the storage section 130, and the internal state in the side display state is stored in the internal state information storage section 129. .

When data is input from the keyboard 121, the input section 125 temporarily stores the input data in the temporary storage section 126. The additional storage section 131 additionally stores the screen input data in the input section 125 and the identifier of the screen in the identifier storage section 130 in the file memory 124 . Next, the display screen determination section 127 determines the input data based on the contents of the internal state information storage section 129 regarding the screen transition.
Interprets the screen transition rule for the screen in the rule storage section 128, determines the next screen to be output, sets the identifier of that screen in the identifier storage section 130, and further internal state information storage section 129 regarding screen transitions. Update the contents of. Finally, the output display section 135 displays the file memory 12 based on the screen identifier in the identifier storage section 130.
Select the screen format in 3 and display 12.
Output and display on 2.

By repeating the above steps, the screen operation of the dialog processing system 11 can be simulated.

Furthermore, reproduction of a simulation that has already been executed is performed as follows. It is assumed that the simulation of the interactive screen operation has already been executed, and the identifier of the screen displayed during the execution of the simulation and the data input from the screen are stored in the file memory 124. Starting part 13
By activating the input part 133 at two fixed time intervals, the input part 133 inputs the identifier of the display screen stored in the file memory 124 and the information input from the screen in the stored order, and inputs the identifier A screen identifier 5 is set in the storage section 130 and screen input data is set in the input section 134, respectively. Next, the output display section 135 selects and inputs the screen format in the file memory 123 based on the screen identifier in the identifier storage section 130, further adds the screen input data in the input section 134, and displays the screen on the display 122. Display the output.

By repeating the following steps, it is possible to reproduce the display screen, data input, and screen transitions in the double-sided operation simulation described above.

In this embodiment, a case has been described in which screen transitions in simulation reproduction are automatically performed at fixed time intervals, but it is of course possible to perform each screen transition by inputting from a keyboard or the like.

In this embodiment, it is possible to present the screen operation movements of the interaction processing system to the user before the production system, and it is also possible to automatically reproduce the screen operations once performed. , the external specifications of the dialogue processing system can be determined quickly.

〔Effect of the invention〕

As described below, according to the present invention, when creating a dialogue processing program, it is possible to quickly and accurately grasp the user's true request, and to effectively utilize the results of this grasp. , to synthesize programs, to reconvert existing programs into structured programs, to enable re-execution of operation simulations, and to display content close to the data that is actually displayed. It is possible to confirm the semester of the external specifications of Systemo.

[Brief explanation of drawings]

FIG. 1 is a functional block diagram of an interaction processing system showing a first embodiment of the present invention, FIG. 2 is a detailed functional configuration diagram of the arithmetic processing unit shown in FIG. 1, and FIGS. 3 and 4 are the same as those shown in FIG. FIG. 5 is a functional block diagram of an interaction processing system showing the second embodiment of the present invention, FIG. 6 is a flowchart showing the processing procedure in FIG. 5, and FIG. 7 is a part of an existing program. , Figure 8 is a diagram showing part of the data flow created from Figure 7, Figure 9 is a flowchart showing the control flow created from Figure 7, and Figure 10 is a reproduction of Figure 7. Diagram showing part of the program created by conversion,
FIG. 11 is a PAD diagram showing the control flow created from FIG. 10, FIG. 12 is a functional block diagram of an interaction processing system showing the third embodiment of the present invention, and FIG. 13 is a PAD diagram showing the control flow created from FIG. FIG. 14 is a functional block diagram of an interaction processing system showing a fifth embodiment of the present invention. 1.5], 200a, 200b, 200c: Video data terminal, 2+ 52. ]OOa. 100b, 100c: Arithmetic (central) processing unit, 53,
300a, 300b, 300c: file memory, 3: screen image storage device, 4: screen transition rule storage device, 5: program parts database, 1
4 Niprogram specification analysis dictionary storage line, 54: Reproduction conversion inference control unit, 55: Data flow creation unit, 56: Control flow creation unit, 57: Jump instruction deletion unit, 58: Common extraction unit, 59: Data check unit ,8],107,
116,1.2] :keyboard, 82,119,12
2: Display, 83: Information accumulation file for format 1, 84: History information accumulation file, 89: Rule, interpreter, 91: Input analysis section, 94: Re-execution section, IO
2: Definition storage file for screen format 1, 105: Sample data value, content, type storage file, 106: Screen format 1 to definition replacement file, 123: Screen format storage file, 124: Identifier, history information storage file, 127 :Display screen determination part, 128: Screen transition rule storage part. 1st Figure 1N opening U62-221728 (15)'fJ 7
Figure rILEREAD Yeo-rL i revision ik at end-gρ
vinegar. LAS7T 73-7r+ +lag
= l dimensionhen-tj77 to KEYCρ
7~'D -3-2else conf+'r)ae
end=4. -3-3rnove I to +I
Kug -1/--3-4rrlove 1nta-t
e −po htia−+e−−〜−＼3−5mθ
Ve inkeg to hKe';J
3-6wri+e ov-f
GIereo horn heJrec,
, -7KEY5E move-1nkel to kg -1/-
--3-ghEIsA 工WR ding ding E noVe ini 士 o (mo-, -3-'7
moIe inb to θUt b -3-1
ρ1, &ris e o(B-f, 1erec
もYIM θutrec-3-/1(jOfo
7: ILEREAD-1-3-/2'IEYCOND 1 child 1nKe'j = Ke% fAen
p fo MEISAIWRITE 3-
13else ct>nsu1'ntte a71
d-if -3-74HHe 1ndJe to
hto-fe, -3-6move ryy,
ey −1, nKev :>−/i+itv,
'+phrt+l:IA, th, L-'haJv. rj
+-■g Kokui! ρ Figure Yety-d-1nTile a-+ eJ
moVe "ri11' So(7e)-Nozu/
"ff, 75-/per4oyrn I
A/if)+ +esf beloreanf+l
e. 10Lf10Lg = 'erntL'
6-2i'r 4kg ==I +her<i
+ rnkep 2Ke3 sunhen co
hf；naeelSe peyfrrrrn HE
ADvJRITE ent! -i'r 15-3
else moVel for Figperfor
m HEADWRITE fhd-:'r 6
-4rnOVe 1n(IL t. OtL+
(LmOVe inb to θvtblj/
r 1士e 0uHrleYet, 4y-ρrn
avfrecYeo, Lrnl1ecf esd
. mtwe md-(Oes+jj1g t-5欽tL-per子θ帥76J HEADWRI RN SEC 工 ρN'HEADWR
I Ding ε-0/. mavc rnda+e fo htlJe,
6-7rnOue 1nkej(to
HaHt4゜write 0uNHJerec
'rrom heJ and ecmOVf-ink+J
fo KeyHEADWRA Dingqiu-qqq XIT = te 11 Figure 13 (L) (b) '? f open I]: 62-221728 (1B) Tomi 14
Illustration (b)

Claims (1)

[Scope of Claims] 1. In a dialog processing system having a terminal device equipped with a keyboard display and an arithmetic processing unit that processes requests from the terminal device, dialog screen format information, transition rule information between each dialog screen, and Internal state information related to screen transitions and cumulative information of internal states related to screen transitions are accumulated in the system, and based on the input information from the dialog screen and the above internal state information, and according to the above transition rule information, the internal state related to screen transitions is calculated. After updating information, outputting the dialogue screen format after transition, and adding cumulative information on internal states related to screen transitions, extract internal information regarding screen transitions of the specified screen from cumulative information on internal states regarding screen transitions. A program development support method characterized by updating internal information regarding screen transitions and outputting the corresponding screen format. (2) After adding the above cumulative information, search the output screen format and input data from the dialogue screen in the cumulative order from the cumulative information of the output screen format and input data from the dialogue screen, and output the corresponding output. 2. The program development support method according to claim 1, wherein the screen format and the data input from the screen are sequentially displayed on the dialog screen. (3) In an interactive processing system that has a terminal device equipped with a keyboard and display and an arithmetic processing unit that processes requests from the terminal device, screen images with screen definitions or screen images extracted from an existing system and screen transitions Using the rules, perform a simulation demonstration of the development target program on the dialog screen, fix the required specifications of the end user by modifying the screen, and generate the dialog screen transition control program from the determined results. After that, based on the analysis of the specifications of the screen processing program input by the user, a screen processing program corresponding to each aspect is synthesized using program parts stored in advance, and the screen is added to the corresponding processing part of the transition control program. A program development support method characterized by combining processing programs to synthesize an interactive program.