JPH096603A - Program design confirmation method - Google Patents

Abstract

PURPOSE: To separate roltes or a specification description tool and a program ming tool from each other to prevent these tools from being used independently of each other by confirming whether a realized program generated based on specifications of an application program meets the specifications or not in a computer provided with a display device, an input device, a main storage device, and a CPU device. CONSTITUTION: A display device 101, a computer main body 200, and input devices such as a keyboard device 203 and a mouse device 204 are used. The computer main body 200 is provided with a main storage device 102, a CPU device 201, and an auxiliary storage device 202. For the purpose of realizing a design confirmation tool, a design confirmation program 105 and a repository 106 are stored in the main storage device 102, and the design confirmation program 105 is operated by the CPU device 201 to display a design confirmation picture 103 and a realized program picture 104 on the display device 101. The repository 106 may be recorded in the auxiliary storage device 202 also to be permanently preserved.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for designing and developing a computer application program, and more particularly to a method for developing a computer application program by linking a method for defining the specification and breaking down the program.

[0002]

2. Description of the Related Art Due to the sophistication of computer hardware and network technology for connecting them, application programs that use these computer resources are required to have more sophisticated and complex processing. In particular, programs for personal computers that are directly operated by users are strongly required to have advanced user interfaces such as easy-to-understand display and easy input / output operation, as well as basic requirements such as calculation performance and amount of processable data. Came to be.
On the other hand, in a large-scale application program that constitutes a social system such as a bank terminal or a public service, a number of screens serving as a unit of a user interface is as large as several thousand. In developing such a large-scale program, it is not easy to improve both the basic requirements and the user interface. Conventionally, when developing a program including such a large-scale user interface, a specification description tool has been provided for describing specifications required on individual screens. For example, the SEWB3 online prototyping tool of Hitachi, Ltd. to which the inventor belongs (hereinafter abbreviated as OLPT: Hitachi SEWB
3 In the online prototyping guide, pages 2 to 44), the transitions of these interface screens can be described by connecting the figures that trace each interface screen. From the created diagram, it is possible to generate the program specifications and the source code that is the model of the program. The specification description tool does not describe detailed contents such as the actual operation of screen components. Since this depends on the implementation method, it is usually implemented by a programming language according to each case. Even in the above-mentioned OLTP, the description is limited to the screen transition, and the implementation of each screen is handled by the programmer modifying the generated source code.

A programmer uses a programming tool such as an editor for writing source code, a compiler or linker for converting the source code into an executable program, and a debugger for debugging the executable program. When the program includes a user interface, a programming tool often adds high-level functions. For example, Visual Basic, a product of Microsoft Corporation (US)
(Microsoft Visual Basic P
programming System for Win
pages 15 to 32 of the dows programming guide
(See page), you can also use tools for interactively designing the screen appearance and tools for selecting the elements that make up the screen and describing the processing when that element is operated. In recent years, it has been confirmed that high-performance programming tools including Visual BASIC have been widely provided and that their effects are great. Therefore, for large-scale development, it is becoming more common to adopt a method (prototyping method) in which a prototype is developed using only these tools, and then connected to the production program while confirming that it actually works.

Although not related to programming work, the hypertext structure is a mechanism for executing an item in a document and a program for explaining the item. For example, when a document containing an item such as "Tokyo" is displayed on the display device, double-clicking this item with a mouse device launches a program that displays a map of Tokyo and displays "Koto" in this map. Ward "
You can double-click an item to start a program that displays a map of Koto Ward. HyTime is a typical document processing technology for realizing a hypertext structure (Commun
ications of ACM November 1991 issue, pages 67-83, "The" Ht
Time "Hypermedia / Time-base
d Document Structuring La
nguage ”). Here, the structure that associates an item with a program that represents this is the basic
In the image, this structure is called a link. It is conceivable to create an instruction manual for the program by using the hypertext mechanism. This can be achieved by specifying each specification as an item and specifying the program that realizes the specification as the link destination of the item.

[0005]

The development method using the specification description tool is effective in breaking down a large-scale program from the specifications. However, if the programmer modifies the source code generated by this tool, it cannot be reflected in the specification description tool. For example, when the source code for screen transition is generated and then the source code is changed to a program for different screen transition, it is difficult to detect this with the specification description tool. Therefore, the method using this tool is premised on adhering to the specified specifications in the programming process. This premise creates a bottleneck in program development. For example, a case where the screen specifications are changed by the customer's request will be described. The specification writer first identifies the changed part on the specification description tool and then describes it. The programmer temporarily saves the modified source code somewhere. The specification writer generates the source code that reflects the changes on the specification description tool, and the programmer correctly embeds the saved source code here. By the time such a procedure is performed, the specification writer and the programmer also need to have a discussion and understand each other's changes. On the other hand, the prototype method using only programming tools allows changes to be stored only in the source code. However, it is difficult to handle everything in this way to cope with large-scale development. In addition, when creating a specification for explaining the contents of the program to the customer, it is necessary to analyze the contents of the program and newly write it. Compared with this case, a specification can be easily created from the specification description.

An object of the present invention is to provide a method of independently using a specification description tool and a programming tool as a method of developing an application program (including especially a large-scale user interface).
Another object of the present invention is to separate the roles of a specification description tool and a programming tool that performs detailed implementation, and to ensure consistency of the contents created by these tools so that they are not used independently. To provide a way to keep it.

[0007]

In order to achieve the above object, the present invention inputs to a display device whether a realization program created based on the specifications of an application program for realizing the specifications satisfies the specifications. This is a program design confirmation method for confirming in a computer having a device, a main storage device, and a CPU device, and is realized by specification data describing individual specifications in the main storage device and a program in which the specification description has already been created. A specification management record that stores realization confirmation data indicating whether or not the specification confirmation record has been realized, and a demonstration execution program for confirming that the specification has been realized when the realization confirmation data indicates that the specification has been realized; A specification management table with the specification management record as an element is provided, and the description of the specification data of each specification management record in the specification management table is By referring to the current confirmation data, it is clarified whether or not the description is realized and displayed on the display device, and when the display of the realized specification description is selected using the input device, the selected The specification management record having the specification data corresponding to the display is acquired, the demo execution program is acquired from the specification management record, and the realization program is actually operated by executing and applying the program to the already realized realization program. When the display of the specification description that has not been realized is selected using the input device, the fact that the specification has not been realized is displayed on the display device. In addition, the pre-processing program is stored in the specification management record in addition to the demo execution program, and the demo execution program is executed and applied to the already created realization program to obtain the realization program before actually operating the realization program. The preprocessing program is acquired from the specified specification management record, and the program is executed and applied to the already realized program. When an instruction to newly create a specification is input using the input device, a specification management record for the new specification is created based on the information input from the input device, and the input device is used as the specification data in the record. The contents of the specifications input from the device are recorded, and whether or not the specifications are realized by the program already created is recorded as the realization confirmation data in the record according to the instruction from the input device. When it is instructed by the input device as data, a program for operating the realization program is recorded as a demo operation program in accordance with the input from the input device. Further, the steps constituting the demo execution program are limited to the processes operated by using the input device during the operation of the realization program. Further, a series of steps representing the contents operated by the input device during the operation of the realization program are generated, and a demo execution program is created based on the series of steps. Further, the specification data is provided with type data indicating the type of the specification, and the description content of the specification data is changed by the type data. Further, the specification types include an object specification that represents a unit in which the created program is realized and a functional specification that represents a functional unit of the created program. Further, the unit of the object specification is made to coincide with each screen unit displayed on the display device. Further, the functional specifications include screen transition specifications that represent the display order of individual screens. Further, the execution of the demo execution program is executed step by step according to the execution instruction from the input device. Further, when one of the specifications depends on another specification, a dependent specification data area that points to another specification data is provided in the specification data, and data that points to the specification data that depends on the data area is recorded. When the management record is displayed on the display device, the dependency specification data area is referred to so as to explicitly display the dependency relationship of the specification. Further, the description of the specification data and the image data obtained from the screen display at the time of execution of the demonstration program are combined to create a guide document for using the created program.

[0008]

By the above means, even if the specification description and the program realization are performed in parallel, it is possible to directly confirm whether the specifications are correctly realized on the design confirmation tool by executing the program directly, so that there is a discrepancy between the two works. Can be avoided. Also, compared with the case of developing a program on the assumption that a specification description tool such as OLTP is used, items that must be taken into consideration in the programming process (the program code that realizes the screen transition specification must not be changed, etc. ) Is reduced. Similarly, even if the specifications of the screen appearance and operability are changed, the consistency between the two tasks can be maintained simply by changing the implementation program without using the specification description tool to generate code again.
Work efficiency is improved. In addition, Visual Basic
Compared with the case of developing a program using a high productivity programming tool such as, it is possible to control the development process at the specification level, make it easier to schedule work, and eliminate the missing functions of the realized program. It is also possible to detect. Further, as shown at the end of the embodiment, this repository structure can be used as a basic material for creating a usage method document of the realization program. Further, according to the above means, the relationship between the specification designer and the programmer becomes equal, so that both parties can freely think and proceed with the work.

[0009]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 2 shows a system configuration required to realize the design confirmation tool. Input devices such as the display device 101, the computer main body 200, the keyboard device 203, and the mouse device 204 are used. A main storage device 102, a CPU device 201, and an auxiliary storage device 202 are provided inside the computer main body. In order to realize the design confirmation tool, the design confirmation program 105 and the repository 106 are stored in the main storage device, and the design confirmation program 103 and the realization program screen 104 are displayed by operating the design confirmation program using the CPU device. Display on the device. Further, since the repository is permanently stored, it may be possible to record it in the auxiliary storage device. The input device is used to select the specification display in the design confirmation screen.

In the following, the data structure provided in the design confirmation tool provided by the present invention will be described by following the procedure of actually creating a simple inventory management application program.
The processing procedure will be described. The inventory management program corresponds to the realization program in FIG. This realization program is created by a programming tool that does not involve the present invention.

FIG. 3 shows windows constituting a part of the inventory management program created. The outline of this program will be described with reference to this figure. HtMai
n. The window indicated by ui has a function of designating the item and quantity to be ordered and displaying another window for designating the delivery date of the item. Element 301 is for selecting the type of item to be ordered, and when “male winter clothing” is selected, a list of winter clothing for men is displayed in table 302. You can enter quantities in this table. After specifying the item and quantity, press the mouse device with the mouse cursor on the button 303 (hereinafter, this mouse operation will be referred to as mouse click) to order the item and quantity specified earlier. NkMain. Which is a window for specifying the delivery date. transition to ui. Further, by designating an item and then clicking the button 304 with the mouse, HtSub01.h is a window for displaying the detailed contents of this item. transition to ui. NkMai
n. A calendar 311 is displayed on the ui window. By clicking the date on the calendar 311 and clicking the button 312, the ordering process is actually performed with this date as the delivery date. NkInf0 during order processing
1. The ui window is displayed. HtErr01. u
i-window is HtMain. This is displayed when the order quantity specified on the ui window is too large.
The outline of the inventory management program has been described above with a simple external specification.

Next, the structures of the specification management table and the specification management record, which are characteristic of the present invention, will be described with reference to FIGS. 4 to 12. As shown in Fig. 1, the specification management table is
It is a data structure that manages specification data that represents specifications that capture the program from various aspects. In this embodiment,
This "various aspects" is to be understood from the object that is the unit of program realization, screen transitions, and functional specifications. Although an object is a unit of realization here, it may be discussed as a specification in recent program design methodologies, and the present invention follows this. Further, here, as the object, a window object that matches the screen unit and a database object are handled.

FIG. 4 shows the configuration of the specification management table 117 in the inventory management program which is a realization program. In the configuration of the present invention shown in FIG. 1, the specification management table has a pointer to the specification management record, but for the sake of explanation, the outline of the specification management record will be listed. The identifier of the specification management record is recorded in the ID field 400 of this table. S0
Symbols that uniquely define the specification management record are assigned from 1 to S02, S03, .... Of the contents of each specification management record, a Name field 401 and a Description field 402 extracted from this are shown in the figure. The S01 record to S05 record represent the specifications of the window object. These correspond to the screens shown in FIG. It is assumed that the program will be realized in this unit. S0
The 6th record is a database object for inventory management. The instruction input from the window object becomes a process call to the database object. Here, it is assumed that all data handled by the inventory management program are managed. However, the implementation method is outside the scope of the present invention and will not be described here. The specification management record that continues for a while from the S07 record represents a screen transition specification. For example, the S07 record represents a transition from the HtMain window to the NkMain window. Since the number of screen transition specifications is large and eight specifications are possible in this embodiment as well, part of the figure display is omitted. S100 to S
The specification management records up to 107 represent functional specifications. S1
00 is a specification showing the entire order processing procedure, and S101 is a specification showing a procedure of designating an order item and its quantity in the order procedure. As described above, the functional specifications have a hierarchical structure, but the specification management table does not distinguish them. The hierarchical structure is managed by the specification data in the specification management record described later. Up to the specification of the order execution process in S107, the contents of the inventory management program handled in this embodiment are shown.

The specification management record 108 shown in FIG. 1 requires specification data, a realization flag (Implement area) which is realization confirmation data indicating whether or not the description of the specification data has been realized by the realization program, and a necessary realization program. A pre-processing program (Pr) for loading objects into memory and displaying the required initial screen
e-Pro area), demo execution program (Demo-P) that executes the same operation as the user's operation on the screen
The ro area indicates). The specification management record 108 is created using a design confirmation program. Details of the creation will be described later with reference to FIGS.

Of these, the structure of the specification data will be described with reference to FIG. In the specification data, both the “realized” content and the “realized” content live together. The "must be realized" contents should be referred to when developing the program,
This should be confirmed by comparing it with the “realized” content.
In the conventional specification description tool, only the contents to be realized were described, but in order to realize the purpose of the present invention to perform specification design and programming in parallel,
It has the configuration shown here. The specification data is configured separately from the actual data of the specification because the specification type and the specification name and the format of the specification description are different according to each type. As mentioned earlier, the types of specifications are window objects, database objects, screen transitions,
It deals with each specification of function. As the actual data of the window object specification, the name 511 of the file that stores the program that implements this object, the name 512 of the file that stores the appearance of the window, the list 513 of the elements that make up the window, and the external to this object Process that can be called from (public process)
List 514, and an explanation description 515 concerning the contents of the object.

Of these, the component list enumerates the operation targets on the screen, and in the example of the HtMain object, it is a check box for selecting the item classification op.
section (301 in FIG. 3), table (302 in FIG. 3) that is a table for displaying item data and entering quantities, and push1 (30 in FIG. 3) that is a button for designating delivery date.
3), push2 which is a button for instructing detailed information display
(304 in FIG. 3) are listed. In the present embodiment, the open processing list of the window object is used to be called by the preprocessing program. The Display process is a process for displaying a window, and the Erase process is a process for deleting it. These two processes are always included in the window object open process list.

The actual data of the database object specification is composed of a program file name 521, a disclosure processing list 522, and an explanation description 523 which are part of the window object. The actual data of the screen transition specification includes the window object name 531 of the transition source,
It is composed of a transition destination window object name 532 and an explanation description 533. The functional specifications are configured by the hierarchical structure as described above. This is managed by the actual data structure of this specification, which is composed of specification data (one) 541 of the higher-level function, specification data list (or plural) 542 of the lower-level function, and explanation description 543.

An implementation example in which the structure of the specification data shown in FIG. 5 is applied to the inventory management program will be described with reference to FIGS. 6 to 8. FIG. 6 shows an implementation example of the window object and the database object. S01-D
ata is the specification data of the window object HtMain, and GW01 is this actual data. S07-
Data is the specification data for the database object InvDB, and DB01 is this actual data. The contents are as shown in the figure.

FIG. 7 shows the entire screen transition specification in the inventory management program and an example of specification data realization in this case. The upper part of the figure shows the window objects and the connections with arrows indicating the transitions between them. This figure is the entire screen transition, and for example, the connection from HtMain to NkMain describes this transition. The specification data corresponding to this transition is S08-Data, and the actual data is DT01.

FIG. 8 shows the entire functional specification and an example of realizing the specification data in this case. The hierarchical structure of the functions is shown in the upper part of the figure. For example, the ordering process is an item specification process as a lower specification,
It has specifications that include deadline specification processing and order execution processing.
S100-Data is specification data for ordering processing, and F
T01 is this actual data. S101-Data is specification data for the item designation process, and FT02 is this actual data. S102-Data is the specification data of the item classification designation process, and FT03 is this actual data. A hierarchical structure is represented by the method shown here. Explaining the representation of the hierarchical structure, for example, the ordering process S100 of FIG.
01, the delivery date designation process S106, and the order execution process S107. Therefore, the order data specification data S10
A dependent specification data area (Children) is provided in the actual data FT01 of 1-Data, and S10 is set in the area.
1, S106 and S107 are registered. In addition, in the Parent of the actual data, information indicating the parent specification data one level higher (for example, S100 in FT02) is registered.

The preprocessing program and the demo execution program will be described with reference to FIGS. 9 to 12. The purpose of these programs is to confirm whether the specifications have been realized by applying the processing to the realization programs.
In the present embodiment, the preprocessing program and the demo execution program are distinguished as the former "processing before user operation" and the latter "processing representing user operation". This is because the program execution before the user operation is not directly related to the evaluation of the specification realization when the screen transition and the function specification are demo-executed. Further, while it is expected that the pre-processing program will be a complicated process of logic, it is expected that the demo execution program limited to the user operation will be a relatively simple program. Also, the preprocessing program requires coding using a programming language, but the demo execution program (1) the user actually operates the realization program, (2) the system monitors the operation sequence of (1). By recording (without using a programming language)
It is possible to program.

FIG. 9 shows an example of implementation of the preprocessing program.
Here, the HtMain window object and the ordering processing specification are the same. Here, as shown in the explanation, the object that is the program unit required for the demo execution is loaded in the memory, and HtM
Only the appearance of the object that loaded ain is displayed.

FIG. 10 shows an implementation example of the HtMain demo execution program. Here, SendEve shown in the figure
A program having the same effect as the user operation is executed by the nt process. As shown in the description, this program is to select (1) Men's winter clothing as the item classification on the HtMain window, and (2) order 3 units of the first item in the resulting item list. Since the information is input and (3) the delivery date is designated, the content is clicked with the mouse on the delivery date designation button.

Further, FIG. 11 shows an Event data structure required for SendEvent processing. Here, a screen element (target) that is a target of event transmission, an event type (type), and an input string (content) for keyboard operation are provided as fields. In the demo execution program, by setting data in each field of this event data and issuing the SendEvent process, the program can be the same as the user operation.

FIG. 12 shows a demo execution program for executing the specifications of the entire order processing. Here, the HtMain demo execution program is called, and in addition to this, (4) N
Specify the delivery date as February 3 on the kMain window,
(5) In order to specify order execution, the contents are clicked with the mouse on the order button. As shown here, in order to avoid duplication of program contents, a program specified by another specification is called. Here, the object demo execution program is called, but in the case of a functional specification, the function hierarchy can be utilized by sequentially calling the execution procedure described in the lower specification.

The structure of the specification management table and the specification management record in this embodiment has been described above with reference to FIGS. 4 to 12. How to perform "parallel work of specification description and realization program development" to be realized by the present invention using these data structures will be described below. FIG.
18 to 18 show the appearance of the design confirmation tool used in the work, and the specifications input here are displayed. 20 to 22 show the processing when the user operates this tool. Also, FIG. 23 shows a scene where the specifications are confirmed with this tool. Below, the process of developing the inventory management program to be created will be explained by combining the screen appearance and processing.

13 to 15 are appearances for designing and confirming specifications of objects, screen transitions, and functions. The contents of each specification are greatly different as shown in the description of the specification data. Therefore, the specifications of the window object and the specifications of the database object, which is this part, are handled on the screen shown in FIG.
The screen shown by 5 handles screen transitions and functional specifications, respectively. The screens are different only because the display contents are changed, and the processes other than the display are the same for the three screens. On the three design confirmation screens, a specification display is arranged on the left and a button group for control instruction is arranged on the right. An outline of the operation of these displays and buttons will be described below. Among the control buttons, "Objects" and "Disp"
By clicking a button of “Lay Trans” or “Functions” with a mouse, a transition is made to a design confirmation screen for object specifications, a screen design confirmation screen for screen transition specifications, and a design confirmation screen for functional specifications. For example, the "Objects" button cannot be selected on the design confirmation screen of the object specification so that the screen cannot be changed to its own screen (shown by a broken line). Add, delete, and change specifications for each type are "Add ..." and "De."
This is done by clicking the "lete""Change..." button. Of these, by clicking the "Add ..." button with the mouse, the buttons shown in FIGS.
The dialog shown in 8 is displayed, and the contents of the specifications to be added can be described here. Details of the dialog will be described later. After selecting the specification display with the mouse,
By clicking the "Delete" button with the mouse,
You can delete the selected specifications. In addition, after selecting the specification display with the mouse, "Change ..."
When the button is clicked with the mouse, the specification contents before the change are set and displayed in the dialogs shown in FIGS. 16 to 18 according to the type. By selecting the specification display and clicking the "Demo" button with the mouse, the preprocessing program and the demo execution program which are said to have realized the specifications for the type are executed. The screen at the time of execution is shown in FIG. Details of the screen of FIG. 24 will also be described later.

The processing flow of the design confirmation tool will be described below with reference to FIGS. 19 to 23. FIG. 19 shows an execution process of the design confirmation tool. When this tool is run,
First, three types of design confirmation screens are initialized and one of them is displayed (step 1901). For example, the object design confirmation screen is displayed first. Next, a display initialization process described later is executed (step 1902). This process causes the specifications to be displayed in the tool. From here, the process to be executed is determined according to the screen operation of the user. The items that can be selected here are the specification display and the control button group. The outline when the control button group is selected is described above. When the specification display is selected, the corresponding specification management record can be acquired from here. This setting can be realized by combining the graphic data when the specification display is selected and storing the specification management record identifier. If the user's input selects the specification display and then instructs the specification change (by clicking the "Change ..." button) (step 1904), the acquired specification management record is displayed in the dialog corresponding to each specification type. Is set (step 1905). Then, each specification dialog is displayed (step 1907), and the processing in the specification dialog described later is executed (step 1908). As a result, the specifications set in the dialog and the contents of the demo execution program are changed. If the user's input is an instruction to create a new specification (by clicking the "Add ..." button) (step 1906), the dialog is displayed in the same manner as when the change is designated (step 1907), and the processing in this dialog is performed. Execute (step 1908). As a result, the specifications set in the dialog and the contents of the demo execution program are newly created. If the user's input is to select the specification display and then instruct execution of the specification (by clicking the "Demo" button) (step 1909), a specification demonstration execution process (step 1910) for confirming this specification is executed. As a result, the user can compare the specifications with the contents of the realized program. If the user input is a termination instruction, the execution processing of this tool is terminated. The user input not shown in the drawing includes a specification deletion instruction (clicking the “Delete” button) and a screen transition instruction to each specification type, but these are omitted because they are clear in the above description.

FIG. 20 shows the details of the display initialization processing described with reference to FIG. This process is executed individually on the design confirmation screen for each specification type. Whether or not there is an unprocessed specification management record in the specification management table according to each type is checked (determination 2001), and if there is no unprocessed specification management record, this processing ends. In this case, the specification display is completed up to this point. If there is an unprocessed specification management record, this is set as a processing target (step 2002), and data indicating whether or not this record is realized (“Im
It is checked whether the "plement" field) is "Done" (decision 2003).
In the case of “ne”, since it has been realized, the content of the specification is displayed with a solid line and the fact that it has been realized is displayed (step 2004). If it is not “Done”,
The content of the specification is displayed with a broken line and the fact that it has not been realized clearly displayed (step 2005).

Since the actual display differs depending on the type of specifications, the display example will be described with reference to FIGS. 13 to 15. In the case of object specifications, the object name and the value of the "Implement" field are displayed side by side. In the case of the screen transition specifications, those in which the connection between each window object is a solid line have been realized, and those in a broken line have not been realized yet. In the case of functional specifications, a hierarchical structure is displayed and "Imp" is displayed next to it.
The value of the "element" field is displayed. When the specification display is selected by the user, the specification management record can be acquired (step 2006). This is the graphic data and specification of the display as described above. This can be achieved by combining and recording the management record identifiers.After executing step 2006, the process returns to the determination 2001 of whether or not there is an unprocessed record.

21 and 22 show details of the processing in the specification dialog. This figure shows the contents common to each specification type. By the time this process is entered, the specification dialog for each type is displayed. The user should have set the contents of the specifications in the display so far. As shown in FIG. 16, in the object dialog, an element 1601 for selecting the type of object (window or database), an element 1602 for setting an object name, an element 1608 for setting an explanation description, and whether or not they are realized are set. Elements 1607 are arranged, and the user sets the contents of each. When the specifications are realized, an element 1603 for setting a program file, an element 1604 for setting a window appearance file name, an element 1605 for setting a disclosure process, and an element 160 for setting a window element.
9. An element 1606 for setting the preprocessing program and an element 1610 for setting the demo execution program are also arranged. If the object type is a database, the window appearance (1604) setting and the window element (1609) setting cannot be performed. Although details of implementation are not described in the present embodiment, when setting the demo execution program, it is also possible to generate the program from the record of the actual operation of the implemented program by the user.

Although the screen transition specification and functional specification dialogs shown in FIGS. 17 and 18 have different settings from the object specification dialog, the overall configuration is similar. In other words, there are elements that set the name, elements that set the description, and elements that set whether or not they have been realized.
When implemented, it has unique setting contents, elements for setting the preprocessing program, and elements for setting the demo execution program.

The process shown in FIGS. 21 and 22 does not include the process corresponding to the user operation at the time of setting. Only the processing corresponding to the operation of either clicking the "OK" button or the "Cancel" button in each dialog after the user setting is completed is shown. This is because the processing at the time of setting is described for each setting element, so that the explanation is enormous, and the operation of the element is mainly focused on the text input and is interpreted as obvious. When the cancel instruction is given in the dialog (the "Cancel" button is clicked with the mouse) (decision 2101), the specification dialog processing is ended. When the setting instruction is given in the dialog (the "OK" button is clicked with the mouse) (determination 2102), the following processing is executed. That is, a specification management record for recording the newly set contents is newly created, specification data is newly created, and the specifications set in the dialog are recorded (step 22).
04). The “Spec” of the specification management record created earlier
A pointer to this specification data is set in the "information" field (step 2205). Next, it is checked whether or not this is set as "Done" for the element for setting whether or not it is realized in the dialog (decision 2206). If "Done" is set, two program storage data are created, and the preprocessing program and the demo execution program described in the dialog are recorded in each of them (step 2207). The pointers to the program recording data recording the preprocessing program and the demo execution program are stored in the "Pre-Pro" field and the "Demo-Pro" field, respectively (step 2208).
Further, the content of the specification data different for each other specification type is recorded (step 2209). For example, in the case of screen transition specifications, this corresponds to the transition source and transition destination window object names. In addition, the specification management record “Implme
The "nt" field is set to "Done" (step 22).
10). If it is not set to "Done",
Set the value of the "Implement" field to "Not Y".
“Et” (step 2211). If the dialog is displayed by the specification change instruction after the above condition processing (decision 2212), the specification management record used before is released and the corresponding processing is performed. The area of the specification management table is set to the unstored state (step 2213), and the pointer to the specification management record recorded so far is stored in the unstored area of the specification management table (step 2214). By the specification dialog processing shown in FIG. 22 and the specification, new creation or modification of each type is realized.

FIG. 23 shows a specification demo execution process. This processing is for "comparing the specification and the realization program", which is a feature of the present invention. In this process, the user selects the specification display and instructs the demo execution process ("Demo").
It is executed when the button is clicked with the mouse. In this process, the specification management record corresponding to the specification display selected first is acquired (step 2301). Then, it is checked whether the "Implement" field of the specification management record is "Done" (determination 230).
2). If this is not "Done", it is determined that this specification has not been realized, and "Not Yet Implement"
A dialog displayed as "ented" is displayed (step 2309), and this processing ends. If it is "Done", the following processing is executed. First, the process for executing the specification demo is started, Further, the execution instruction dialog is displayed (step 2303) The appearance of the execution instruction dialog is shown in Fig. 24. The contents of the demo execution program to be executed are displayed in the execution instruction dialog. The program pointed to by the "Pre-Pro" field is executed (step 2304), which is a preprocessing program.

In order to interactively execute the demo execution program, the execution is suspended so far and the continuous execution instruction from the execution instruction dialog is waited (decision 2305). If this is instructed, the specification management record “Demo-P”
The program pointed to by the "ro" field is executed (step 2306). This issues the procedure by which the specification is realized. By comparing this execution with the specification selected before execution, is this correctly realized? You can check it.

The screen being executed is also shown in FIG. Here, the appearance of HtMain is actually operated, and the item data acquired from the inventory database InvDB is also displayed in the table 302. Also, depending on the realization program, the instruction buttons push1 (303) and push2 (304) should be set so that the delivery date cannot be specified before the order quantity is set and the detailed information display cannot be specified before the item is selected.
It can be confirmed that is not selectable (unselectable is represented by surrounding the button with a broken line). In order to improve the interactivity of the demo execution program, it is possible to execute the program step by step. The “Step” button 2312 in the execution instruction dialog is provided to give an instruction therefor (however, its realization will not be described in detail in this embodiment). Further, in this case, a display 2316 showing the position of the program being executed is also required. After executing the demo execution program, wait until the end instruction is given from the execution instruction dialog (decision 230
7) If this is done, the started process is terminated and the execution instruction dialog is erased (step 230).
8). The embodiment of the present invention has been described above until the specification of the development procedure is confirmed. An object of the present invention is to allow specification description and programming work to proceed in parallel with consistency while confirming specifications. However, even after this work is completed and the implementation program is completed, the configuration of the present invention can be used for document creation, and therefore will be briefly described below. When the development is completed, a document that shows the user how to use the realized program is required. Of the specification management records created during development in the present invention, the functional specifications often directly describe this usage method. Considering an example of the ordering process of the previous embodiment, the item specifying process is realized by performing the item classification specifying process, the item selecting process, and the quantity input process in order. The demo realization program corresponding to each functional specification presents the most direct usage method in order to actually operate the realization program. It can be expected that the usage will be fully understandable to the user by extracting the screen image of each scene at the time of execution of the demo execution program and documenting this image in combination with the functional specification description. FIG. 25 is an example of documenting the method of using the order processing function in the previous embodiment. The description part of the functional specification is on the left, and the operation method of the execution screen is shown on the right. The operation target pointed by the shape of the hand is to be operated in order to realize the function. This operation target is
It can be extracted by analyzing the event data structure of the demo execution program. Therefore, this manual document can be automatically generated from the arrangement according to the invention. FIG. 26 shows the flow of processing for automatically generating a manual document.
Shown in In this processing, the specification data representing the functional specifications is selected (step 2601 to step 260).
4) The contents of the specification data are output to the manual document (steps 2605 to 2608). FIG.
Although the document format is not shown in the processing of
By specifying this separately, the document shown in FIG. 25 can be created.

[0037]

According to the present invention, even if specification specification and program realization are performed in parallel, it is possible to directly confirm whether or not the specifications are correctly realized on the design confirmation tool by executing the program. It is possible to avoid discrepancies between the two. Also, compared with the case of developing a program on the assumption that a specification description tool such as OLTP is used, items that must be taken into consideration in the programming process (the program code that realizes the screen transition specification must not be changed, etc. ) Is also reduced. Similarly, even if the specifications of the screen appearance and operability are changed, it is possible to maintain consistency between the two tasks simply by changing the implementation program without using the specification description tool to generate code again. It is possible to improve work efficiency. Further, compared with the case of developing a program using a high productivity programming tool such as Visual Basic, the management of the development process can be suppressed at the specification level, which has the effect of making it easy to schedule work. It can also be applied to work for detecting missing functionality in the implementation program. Further, as shown at the end of the embodiment, this repository structure can be used as a basic material for creating a usage method document of the realization program.
The program design / development work is a collaborative work between the specification designer and the programmer. According to the design confirmation tool realized by the present invention, the relationship between the specification designer and the programmer is equal. Therefore, there is an effect that both parties can freely think and proceed with the work.

[Brief description of drawings]

FIG. 1 is a schematic diagram for explaining a program design confirmation tool that is an embodiment of the present invention.

FIG. 2 is a diagram showing a configuration of a system to which the present invention is applied.

FIG. 3 is a diagram showing a window appearance group in an inventory management program.

FIG. 4 is a diagram showing a configuration of a specification management table in an inventory management program.

FIG. 5 is a diagram showing a structure of specification data.

FIG. 6 is a diagram showing an example of specification data of windows and database objects.

FIG. 7 is a diagram showing an example of screen transition specifications and related specification data.

FIG. 8 is a diagram showing an example of functional specifications and related specification data.

FIG. 9 is a diagram showing an example of a preprocessing program (common to HtMain and order processing).

FIG. 10 is a diagram showing an example of a demo execution program (in the case of HtMain).

FIG. 11 is a diagram showing an Event data structure.

FIG. 12 is a diagram showing an example of a demo execution program (in the case of order processing).

FIG. 13 is a diagram showing a design confirmation screen of object specifications.

FIG. 14 is a diagram showing a design confirmation screen for screen transition specifications.

FIG. 15 is a diagram showing a design confirmation screen for functional specifications.

FIG. 16 is a diagram showing an object specification dialog screen.

FIG. 17 is a diagram showing a screen transition specification dialog screen.

FIG. 18 is a diagram showing a functional specification dialog screen.

FIG. 19 is a diagram showing a flowchart of a design confirmation program.

FIG. 20 is a diagram showing a flowchart of a display initialization process.

FIG. 21 is a diagram showing a flowchart of specification dialog processing.

22 is a diagram showing a flowchart of the specification dialog process following FIG. 21. FIG.

FIG. 23 is a diagram showing a flowchart of a specification demo execution process.

FIG. 24 is a diagram showing an example of a screen when a demo of item classification designation processing is executed.

FIG. 25 is a diagram showing a generation example of a usage manual.

FIG. 26 is a diagram showing a flowchart of a usage manual generation process.

[Explanation of symbols]

 101 Display Device 102 Main Storage Device 103 Design Confirmation Screen 104 Realization Program Screen 105 Design Confirmation Program 106 Repository 200 Computer Main Body 201 CPU Device 202 Auxiliary Storage Device 203 Keyboard Device 204 Mouse Device

Claims (12)

[Claims] 1. A computer having a display device, an input device, a main storage device, and a CPU device confirms whether or not an implementation program, which is created based on the specifications of an application program, that implements the specifications satisfies the specifications. A method for confirming the design of a program, the specification data describing individual specifications in the main storage device, the realization confirmation data indicating whether or not the specification description is realized by a program already created, and the realization confirmation data. In the case of indicating that the specification has been realized, a specification management record storing a demo execution program for confirming that the specification is realized, and a specification management table having the specification management record as an element are provided. For the description of the specification data of each specification management record in the specification management table, refer to the realization confirmation data to realize the description. It is clarified whether or not it is displayed on the display device, and when the display of the realized specification description is selected using the input device, the specification management record having the specification data corresponding to the selected display is acquired. Then, the demo execution program is acquired from the specification management record, and the realization program is actually operated by applying the program to the realization program that has already been created. A program design confirmation method characterized by displaying on a display device that a specification is not realized when selected using. 2. The program design confirmation method according to claim 1, wherein a pre-processing program is stored in the specification management record in addition to the demo execution program, and the demo execution program is executed and applied to an already-implemented program. Thus, before actually operating the realization program, a preprocessing program is acquired from the acquired specification management record, and the program is executed and applied to the already realized program. 3. The program design confirmation method according to claim 1, wherein when an instruction to newly create a specification is input using an input device, specification management for the new specification is performed based on information input from the input device. A record is created, the content of the specification input from the input device is recorded as the specification data in the record, and whether or not the specification is realized by the program already created is recorded as the realization confirmation data in the record. It is recorded according to an instruction from the input device, and when the realization confirmation data indicates that the realization has been realized from the input device, a program for operating the realization program is recorded as a demonstration operation program in accordance with the input from the input device. A program design confirmation method characterized by the following. 4. The program design confirmation method according to claim 3, wherein the step of configuring the demo execution program is limited to a process of operating with an input device during operation of the realization program. Confirmation method. 5. The program design confirmation method according to claim 4, wherein a series of steps representing contents operated by an input device at the time of operation of the realization program is generated, and a demo execution program is executed based on the series of steps. A program design confirmation method characterized by creating. 6. The program design confirmation method according to claim 1, wherein the specification data is provided with type data representing a type of the specification, and the description content of the specification data is changed by the type data. Confirmation method. 7. The program design confirmation method according to claim 6, wherein the specification type includes an object specification representing a unit in which a created program is realized, and a functional specification representing a functional unit of the created program. A method for confirming program design, including: 8. The program design confirmation method according to claim 7, wherein the unit of the object specification is matched with each screen unit displayed on the display device. 9. The program design confirming method according to claim 7, wherein the functional specification includes a screen transition specification indicating a display order of individual screens. 10. The program design confirmation method according to claim 1, wherein the execution of the demo execution program is executed step by step according to an execution instruction from an input device. 11. The program design confirmation method according to claim 1, wherein when one of the specifications depends on another specification, a dependent specification data area pointing to the other specification data is provided in the specification data, and the data It is characterized by recording the data indicating the specification data that depends on the area, and displaying the specification management record on the display device by referring to the dependent specification data area and displaying the specification dependency relationship explicitly. Program design confirmation method. 12. The program design confirming method according to claim 1, wherein the created program is used by combining the description of the specification data and the image data obtained from the screen display when the demonstration program is executed. A program design confirmation method characterized by creating a guide document for