JP2731385B2 - Software design information acquisition device - Google Patents

Description

Description: BACKGROUND OF THE INVENTION The present invention relates to an apparatus for porting existing software to another system, and in particular, obtains design information from the existing software as a table (table format data). The present invention relates to a software design information acquisition device suitable for the present invention. [Conventional technology] Expert systems have been developed for the purpose of acquiring know-how such as the knowledge and experience of experts and solving problems similar to experts even for non-experts.
A conventional technique for acquiring information according to the present invention is a technique for acquiring knowledge information of the expert system. Known examples related to the expert system include, for example,
-16771, JP-A-60-540, JP-A-60-7539, JP-A-60-63639, JP-A-60-63640, JP-A-60-74040
And JP-A-61-5344 and JP-A-61-7937. [Problems to be Solved by the Invention] In the above-mentioned conventional technology, no consideration is given to acquiring, retaining, and reconfiguring software design information directly from a description, and effectively utilizing existing software design information. There was a problem that could not be done. SUMMARY OF THE INVENTION It is an object of the present invention to provide a software design information acquisition apparatus for directly acquiring, retaining, and reconfiguring software design information from a description. [Means for Solving the Problems] The object of the present invention is to register and manage a table (data in tabular form) analyzed in order to acquire design information in a design specification acquiring system as shown in FIG. Table management means;
Item management means for registering and managing items constituting table columns and their definition information, in-table relationship management means for managing table item information, and inter-table relationship management for managing derived relationships between tables Means, an inter-item relation management means for expressing and managing the derivation relation by an operation relation between the items, and an item area management means for managing all the items to be used. The process of converting the tabular data by decomposing the design information into a table-to-table relationship, a table-to-item relationship, and an item-to-item relationship, which is tabular data composed of item data as shown in FIG. (2) The change information of the specification is restructured by changing the relation (structure) of the table,
(3) It is achieved by a software design information acquisition device that can generate necessary software from a table relationship. [Operation] The operation of the means added to the design specification acquisition system in the above-described software design information acquisition apparatus will be sequentially described using examples. FIG. 2 is a conceptual diagram showing a process of acquiring software design information according to the present invention. First, an input of a program A used for explanation is a table (tabular data) 1 composed of items a ₁ , b ₁ and c ₁ and a table (tabular data) composed of items a ₂ and b _2. 2, and the output is shown in Table 3 including items a ₃ , b ₃ , and c ₃ . Here, the data of Table 3 (table format data) is a set (record) of items a ₃ , b ₃ , and c ₃ , and Table 1
Table ₁ when item a ₁ of Table 2 and item a _{2 of} Table 2 have the same value AA
From the set of items a ₁ , b ₁ , c ₁ in Table 2 and the set of items a ₂ , b _{2 in} Table 2, the arithmetic relation a ₃ ← a ₁ , b ₃ ← b ₁ × b ₂ , c ₃ ← c ₁ + b ₂ Item a ₃ ,
b ₃ and c ₃ are calculated, and item a ₃ in Table ₃ is the value of item a _{1 in} Table 1.
AA is substituted as it is, the value of the item b ₁ of Table 1 in item b ₃ 2
And is substituted product 40 in Table 2 item b ₂ values 20 are derived is assigned the sum 24 of Table 1 of item c ₁ value 2 and Table 2 item b ₂ values 20 to item c ₃ Thus, the function of the program A is represented as a conversion (transition) process of tabular data. FIGS. 3 (a), (b), (c) and FIGS. 4 (d), (e), (f) are explanatory diagrams showing the results of obtaining the design information in FIG. Next, when the program A shown in FIG. 2 is input to the design specification acquiring system shown in FIG.
Is interpreted as a conversion of tabular data from the description, thereby interpreting the program A in FIG. 2 as a program having a function of inputting Tables 1 and 2 and outputting Table 3 as described above. As a result, the table management means added to the system based on the result of the analysis includes a table constituting the program A as shown in the table management contents shown in FIG. 2 and Table 3, wherein Tables 1 and 2 are inputs and Table 3 is outputs and the contents are managed and the item management means is the item management shown in FIG. 3 (b). program item in a a ₁ as a list of attributes and lengths of the used is in which items in a program a as the _{content, a 2, a 3, b} 1, b 2, b 3, c 1, c 2 Is used, and the attributes and lengths of the items a ₁ , a ₂ , and a ₃ are character strings and are 8 bytes long, and the items b ₁ , b ₂ , b ₃ , c ₁ , and c ₂ are integers and 4 bytes long The in-table relation management means obtains and manages the table. As shown in FIG. 3 (c), the in-table relation management means shows that the table and its constituent items are the constituent items a ₁ , B ₁ , c ₁ , and Table 2 shows the configuration items a ₂ ,
b ₂ from become table 3 manages won consist of configuration items _{a 3, b 3, c 3} , Table relations between management means derived as table between relationship management content shown in FIG. 4 (d) Table 3 is derived from Table 1 and Table 2 as a table, its input table, and key items, and in that case, item a ₁
Attribute a ₂ manages won The key and, the relation management means between items Table 3 as an arithmetic relationship deriving entry and its input items as item among related management contents shown in FIG. 4 (e) is the item a ₃ product of the operation a ₁ by item b ₃ values of the items a ₁ in Table 1 is substituted as operation b ₁ × b ₂ by item b ₁ of Table 1 and Table 2 item b ₂ Table 1 is obtained by substituting the operation c ₁ + b ₂ into the substituted item c _3.
Item c ₁ and table sum of items b ₂ of 2 is acquired by the management from being substituted, the item area management means all items in the program A as the item area management contents shown in Figure No. 4 (f) Are a, b ₁ , c ₁ ,
b _2, b _3, won consist of c ₃ managed Incidentally item a represents the items a _1, a _2, a ₃ are the same items. In this manner, the relation between the tables and the relation between the tables and the items are acquired and managed from the program A. Next, FIG. 5 is a conceptual diagram showing a process of changing the specifications of software design information according to the present invention. FIG. 6 (a),
FIGS. 7 (b) and 7 (c) and FIGS. 7 (d), 7 (e) and 7 (f) are explanatory diagrams showing the results of changing the specifications of the design information in FIG. First modify specifications for program A when porting programs A of FIG. 2 tables as 5 (tabular data) 1 item c ₁ and Table 2 arithmetic relationship from the item b ₂ of (tabular data) d ₃ ← c ₁ × b ₂ , item c _{1 in} table (tabular data) 3
And the value 4 and the product 80 item b ₂ values 20 is changed to add items d ₃ to the value. Next, when the changed specification shown in FIG. 5 is input to the design specification obtaining system shown in FIG. 1, the system changes the changed specification and the second specification to change the specification for the program A.
The acquisition specifications shown in FIGS. 3 and 4 are edited and reconfigured. Then, based on the result of the editing, the item management means adds the item d ₃ and the integer and length 4 of the attribute to the list of the attribute and the length.
Managed by additionally registers the byte length, management in relation management unit table additionally registered item d ₃ in Table 3 as a configuration item as a table as in table relation management contents shown in Figure No. 6 (c) Then, as shown in FIG. 7 (e), the inter-item relation management means calculates the derived items and their input items and the derived items d ₃ of Table 3 by the operation c ₁ × b ₂ as the operational relationship with the derived items. Item ₁ and Table 2
Item b product of ₂ additionally registers from being substituted, item area management unit additionally registers the item d ₃ in the item area as item area management contents shown in Figure No. 7 (f). In this way, the specification change information for porting the program A is reconfigured and managed as a change in the relation (structure) of the table. In this way, the design information of the already developed software is obtained directly from the description as a conversion (transition) process of the tabular data, and the specification change part is performed by adding, changing, and deleting the relationship between the table and the item. Design information can be easily reconstructed. [Embodiment] An embodiment of the present invention will be described below with reference to FIGS. 1 and 8 to 14.
This will be described with reference to the drawings. First, FIG. 8 is a hardware configuration diagram of a computer on which a porting system (design specification acquiring system) operates, showing an embodiment of a software design information acquiring apparatus according to the present invention.
In FIG. 8, the computer of the transplant system is a multi-bus
11, a bus control device 12 for controlling the multi-bus 11, a central processing unit 13 connected to the multi-bus 11, a disk control device 14, and a main storage device 15 connected to the central processing unit 13.
, A display device 16, a keyboard 17, and a disk 18 connected to the disk control device. With this configuration, data input from the keyboard 17 is taken into the main storage device 15 by the central processing unit 13 and displayed on the display device 16, and the data on the main storage device 15 is transmitted by the central processing unit 13 via the multibus 11. Is sent to the disk controller 14 and the disk controller 14
Stored in 18. FIG. 1 is a software configuration diagram of a porting system (design specification acquisition system) functioning on a computer shown in FIG. 8 showing an embodiment of a software design information acquisition apparatus according to the present invention. In FIG. 1, the porting system has an input / output control unit 19 connected to a main storage device 15, a display device 16, a keyboard 17, disks 18a and 18b, etc. A system input unit 20 for inputting an application system described in a programming language suitable for expressing each connected process as a conversion (transition) process of tabular data.
And a program analysis unit 21 that analyzes the input application system program to obtain design specifications, and a specification editor that inputs required specification changes to the input application system and edits and reconfigures the changed specifications and the obtained specifications. A table analyzed in a porting system (design specification acquisition system) including a unit 22, a program generation unit 23 that generates a program of another system from the edited specifications, and a system output unit 24 that outputs the generated program. A table management unit 25 for registering and managing the items, an item management unit 26 for registering and managing the items constituting the columns of the table and their definition information,
In-table relationship management unit 27 that manages which items the table is composed of, and inter-table relationship management unit that manages the derived relationship between tables
28, an inter-item relationship management unit 29 that expresses and manages the above-described derivation relationship by an operation relationship between items, and an item area management unit 30 that manages all items used in the application system. It is configured so that the design information of the application system can be obtained as a process of converting (transitioning) the tabular data, and the input design information can be changed only by inputting the specification change to generate a program of another system. FIG. 9 is a structural diagram of software to be processed by the porting system (design specification acquiring system) of FIG. 1 (FIG. 2). This embodiment deals with an example in which the production management software A developed for the workplace A is ported to the production management software B for the workplace B (design specification change). First, a specific process of the transplantation system will be described. To explain the program EXPLODE in software A, the program EXPLODE function calculates the quantity and time of parts required to make a product in a specified quantity by a specified delivery date according to a planned production plan. Requirements development function,
FIG. 9 shows the EXPLODE function as a conversion (transition) process of tabular data. In the figure,
Item: product, quantity, delivery date table: production planning table,
Item: table consisting of product and number of days: Inputting a reference schedule table and calculating the start date = delivery date−number of days + 1 for products in the production plan table equal to the product in the reference schedule table, and the items in the production plan table: Substitute the start date. By inputting the production plan table and the items: products, parts, and the number of components: the component configuration table, the required quantity of necessary parts for the product having the same product in the production plan table and the product in the component configuration table = quantity x The number of components and the delivery date = start date-1 are calculated, and are output to a table including items: parts, quantity, and delivery date: a parts requirement table. EXPLOD like this
Function E is a function that obtains a parts requirement table from a production plan table, a reference schedule table, and a parts configuration table. If this program EXPLODE is described in a relational database language, the description (A) UPDATE Production planning table KEY = (product) Reference schedule KEY = (product) SET Start date = delivery date-number of days + 1;… INSERT INTO Parts requirement table ( (Parts, quantity, delivery date) SELECT Parts, quantity x number of components, start date -1 FROM Production planning table KEY = (product) Parts configuration table KEY = (product); Furthermore, if the information is described in the same language to define the information of the production plan table, the reference schedule table, the parts configuration table, and the parts request table, the description (B) CREATE TABLE production plan table (product C8, quantity I4, delivery date I4, start date) I4);… CREATE TABLE Reference schedule (product C8, number of days 14); …… CREATE TABLE Parts configuration table (product C8, parts C8, number of components I)
4);… CREATE TABLE Parts request table (parts C8, quantity I4, delivery date I4); Here, C8 is a character string C with a length of 8
I4 indicates that the attribute is an integer I and the length is 4 bytes. FIG. 10 is a processing flowchart of a process of acquiring the design information of the processing target software A of FIG. 9 in the transplant system of FIG. 1 (FIG. 2). FIG. 11 (a),
FIGS. 12 (b) and 12 (c) and FIGS. 12 (d), (e) and (f) are explanatory diagrams showing the acquisition results of the design information of the software A. The process of acquiring the design information of the software A and the acquisition result in the transplantation system of FIG. 1 (FIG. 2) will be described with reference to the processing flow of FIG. 10 and the acquisition result diagrams of FIG. 11 and FIG. Now, assuming that the software A is stored on the disk 18a, the operator inputs a command from the keyboard 17 to start the transplant system, and then inputs the software to be transplanted to the display device 16 from the started transplant system. The guidance is displayed, and the operator designates the disk 18a storing the software A and requests the transplant system to input the guidance in accordance with the guidance. As a result, the transplant system activates the system input unit 20, and reads the software A from the disk 18a into the main storage device 15 via the input / output control unit 19 (step 100). Next, the transplant system starts the analysis unit 21 and reads the read main storage device 15.
The above software A is taken out (step 101), and the software A is analyzed and decomposed into a table data conversion (transition) process. The process of this disassembly can be explained by the program EXPLODE in the software A described above.
Is described as described above (A) and (B), and the analysis unit 21 analyzes the descriptions (A) and (B) while decomposing the data into a table data conversion (transition) process shown in FIG. I do. In this way, the description of (A) is analyzed first, and it is determined that the input tables are the production plan table and the reference schedule table, the input table is also used as the output table from the description of UPDATE, and the production plan table is determined from the description of SET. It is determined that the table is also an output table, and the information of the production plan table and the reference schedule is passed to the table management unit 25 (step 102). As a result, the table management unit 25 registers and manages all the passed tables and their inputs and outputs as in the table management contents shown in FIG. 11A (step 103). Then, the description in (B) is analyzed, and the production plan table is composed of items of product, quantity, delivery date, and start date, and the attribute and length are respectively character string 8 bytes, integer 4 bytes, integer 4 bytes, integer 4 It interprets that it is a byte, and in the same way, interprets that the standard schedule consists of items of product and number of days, and that the attribute of the number of days and the length are integers of 4 bytes, the production schedule table and the standard schedule table The item information is passed to the item management unit 26, and the table and the item information are transferred to the in-table relationship management unit.
27, the item management unit 26 registers and manages all the transferred items and their attributes and lengths as shown in the item management contents shown in FIG. 11 (b) (step 104). The relation management unit 27 registers and manages the passed table and its constituent items as in-table relation management content shown in FIG. 11 (c) (step 105). Next, the analysis unit 21 continues the analysis of the description (A), interprets that the key is a product item in both the production plan table and the reference schedule, and passes the key information to the table relationship management unit 28,
As a result, the inter-table relation management unit 28 registers and manages the derived table, its input table, and key items as in the inter-table relation management content shown in FIG. 12 (d) (step 106). Then, the description of the SET is analyzed, and it is interpreted that the start date of the production planning table is obtained by subtracting the number of days from the delivery date and adding 1, and the information is passed to the item-to-item relationship management unit 29, and the The inter-relationship management unit 29 registers and manages derived items, their input items, and operation relationships as in the inter-item relationship management content shown in FIG. 12 (e) (step 107). This is passed to the area management unit 30, and the item area management unit 30 registers the items of the product, the quantity, the delivery date, the start date, and the number of days except for the duplication of the items as in the item area management content shown in FIG. 12 (f). And manage it (step 108). Hereinafter, the same description (A)
By executing the processing of the description (B), the expression of the EXPLODE function shown in FIG. 9 was completed, and the processing of all the programs of the software A was performed in the same manner as the processing for the EXPLODE. To obtain the design information of the software A shown in FIGS. 11 and 12 (step 109). Next, FIG. 13 is a structural diagram of specification change software of the transplant system (design specification acquisition system) of FIG. 1 (FIG. 2). FIG. 14 is a processing flowchart of a specification change process of the specification change software B of FIG. 13 in the transplant system of FIG. 1 (FIG. 2). The processing flow of FIG. 14, the structural diagram of FIG. 13, and the additional and modified portions of the acquisition results of FIGS. 11 (a), (b) and (c) and FIGS. 12 (d), (e) and (f) The specification change process and the result of the addition change for porting the software A to the software B for the workplace B in the porting system of FIG. 1 (FIG. 2) will be described with reference to FIG. When the transfer of the design information from the software A is completed, the transplant system requests the operator to input the changed specification through the display device 16. The operator inputs, from the keyboard 17, a change specification of the change content in which a start date is set in the parts request table of the software A and a date for arranging the parts is output (step 110). FIG. 13 shows this change specification as a conversion (transition) process of the tabular data. The operator then added the items to the parts request table without any additional tables:
Enter the start date additionally. Then, the editing unit 22 receives additional information on the item: start date in the parts request table through the input / output control unit 19, and the editing unit 22 sends the item: additional information on the start date in the parts request table to the in-table relation management unit 27. hand over. As a result, the table management unit 25
No table management content is added (step 111), and no item management content is added by the item management unit 26 (step 11).
2), the in-table relationship management unit 27 additionally registers and manages the start date in the component item of the parts request table as in the in-table relationship management content shown in FIG. 11 (c) (step 113). Next, the operator inputs information of the reference schedule required for calculating the start date.
Then, the editing unit 22 determines that it is necessary to derive the parts request table and the reference schedule table as input tables in order to calculate the start date of the parts request table in response to this information, and sends the information to the inter-table relationship management unit 28. give. As a result, the inter-table relation management unit 28 stores the parts request table of the derived table, the parts request table reference schedule table of the input table, and the parts and products of the key items as in the contents of the inter-table relation management shown in FIG. Additional registration and management (Step 11
Four). There is no addition of the item-to-item relationship management content of the item-to-item relationship management unit 29 (step 115), and no addition of the item area management content of the item-area management unit 30 (step 116). When the input of the changed specification is completed as described above (step 117), the transplantation system generates the software B by the generation unit 23 based on the acquired design information after the specification change. The generation process will be described. The generation unit 23 has a table management unit 25, an item management unit 26, an in-table relationship management unit 27, an inter-table relationship management unit 28, and an A specific description is generated using the inter-relationship management unit 29 and the item area management unit 30. For example, in the case of the program EXPLODE, add UPDATE parts request table KEY = (parts) reference schedule KEY = (product) SET start date = delivery date-number of days + 1; EXPLODE is generated by changing to: CREATE TABLE parts request table (parts C8, quantity I4, delivery date I4, start date I4); Next, the software B generated on the main storage device 15 is stored in the disk 18b by the system output unit 24 via the input / output control unit 19 (step 119). As described above, according to the present embodiment, the design information of existing software can be directly obtained from its description and reused, so that the efficiency of software porting work can be greatly improved. [Effects of the Invention] According to the present invention, design information is obtained directly from the description of existing software, is retained as a conversion (transition) process of tabular data, and reconfiguration is easy. The productivity of software can be improved by using the design information to create other software. (2) The acquired design information can be easily used because the software design information is stored as a table data conversion (transition) process. (3) Since the specification of existing software can be easily changed, there is an effect that expansion, addition and change of software are easy.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a software configuration diagram showing one embodiment of a software design information acquiring apparatus according to the present invention, FIG. 2 is a conceptual diagram of a process of acquiring software design information of FIG. 1, 3 (a), (b), (c) and FIGS. 4 (d), (e),
(F) is an explanatory diagram of the acquisition result of the design information in FIG. 2, FIG. 5 is a conceptual diagram of a process of changing the specifications of the software design information in FIG. 1, and FIGS. 6 (a), (b), and (c). ) And FIGS. 7 (d), (e) and (f) are explanatory diagrams of the result of changing the specification of the design information of FIG. 5, and FIG. 8 shows an embodiment of the software design information acquiring apparatus according to the present invention. FIG. 9 is a structural diagram of software to be processed in FIG. 1 (FIG. 2), FIG. 10 is a processing flowchart of a process of acquiring software design information in FIG. 9, and FIG. ), (B), (c)
12 (d), (e), and (f) are explanatory diagrams of the acquisition results of the design information in FIG. 10, FIG. 13 is a structural diagram of the specification change software in FIG. 1, and FIG. 14 is a processing flowchart of a specification change process of the specification change software of FIG. 11 multi bus, 12 bus control device, 13 central processing unit, 14 disk control device, 15 main storage device, 16 display device, 17 keyboard, 18, 18a, 18b disk, 19 input / output Control unit, 20: system input unit, 21: analysis unit, 22: editing unit, 23: generation unit, 24: system output unit, 25
... Table management part, 26 ... Item management part, 27 ... Table relation management part, 28
... Table relationship management unit, 29 ... Item relationship management unit, 30 ... Item area management unit.

Claims (1)

(57) [Claims] A system input means for inputting an application system described in a programming language capable of describing a function as a table conversion process of tabular data, a table representing the function by analyzing the input application system program, and items constituting the table Program analysis means for decomposing the relationship, clarifying the conversion process from the input table to the output table of the application system from the output table to the input table in the reverse order of the function, and obtaining the design specification; In a design specification acquisition system comprising specification editing means for inputting specification changes necessary for an application system and editing and reconfiguring the changed specifications and the obtained specifications by using a disassembled table, items and their relationships, Item area management means for managing all items used in the application system, Table management means for distinguishing and registering the entered table as an input table or an output table and managing the same, and items managed by the item area management means and for registering and managing the items constituting the table columns and their definition information Management means and in-table relationship management for managing the interdependency between items indicating which items are registered and managed in the table management means and which items are registered and managed in the item management means; Means, an inter-table relation management means for managing an inter-table derivation relationship between tables registered and managed in the table management means, and the derivation relation registered and managed in the inter-table relation management means. Using the interdependency between items registered and managed in the above-mentioned in-table relationship management means, an inter-item derivation relationship expressed by an operational relationship between items (inter-item derivation relationship: representing a relationship between at least two items, A relationship means that the value of one item is The above-mentioned one item is called a child item, and the remaining items are called parent items). A software design information obtaining apparatus, wherein system design information is obtained as a conversion process of tabular data, and a specification change is input so that the obtained design information can be changed.