JP4963070B2 - Software component template management system - Google Patents

Description

  The present invention relates to a software component template management system that holds tested software components in the form of templates.

When developing software, by reusing reusable functions in advance as parts, it is possible to reduce the man-hours for creating the same functions over and over again. This is effective for improving development efficiency.
In many projects that reuse the software component source code, the software component source code is customized to meet the rules of each project and then reused. For example, the names of items such as packages, classes, functions, and attributes declared in the source code are items that change according to a naming convention defined for each project. However, it is troublesome for developers to make these changes manually, and mistakes are likely to be mixed, which is inefficient.

Therefore, there is a method of creating a template in which variable items in the source code are replaced with special symbols in advance so that other values can be embedded later. A technique for automatically generating target source code by automatically embedding customization information separately designated by a developer in this template is known.
As publicly known technical documents relating to means for generating software component source code based on templates and customization information, there are the following patent documents.

JP 2001-256049 A

By the way, as a method of preparing a template for software parts, after creating executable software and testing it, edit the variable items in the source code for the source code where it can be converted into parts. It is common to make a template.
However, it takes time and effort to manually edit the source code and create a template. In software development projects, even if source code is created, it is often not done to edit and create a template for cost reduction, which may hinder the accumulation of templates. .
Also, when using software components in combination, if there is a dependency such that one side references or inherits an item defined on the other side, when one side is customized, the other side also performs customization accordingly. Therefore, there is a problem that consistency must be maintained. The above-mentioned consistency problem may occur when combining automatically generated source codes. However, at the stage of creating a template that is the source of automatic generation, the consistency of the template of software components with dependencies is determined. If it is retained, it is possible to prevent the occurrence of the problem of consistency between the source codes after the automatic generation.

  It is an object of the present invention to automatically generate a software component source code as a template and store it, and automatically generate a software component source code requested by the user based on the stored template. It is an object of the present invention to provide a software component template management system that can provide and maintain consistency between automatically generated source codes.

In order to achieve the above object, a software component template management system of the present invention includes a server for storing a software component that has been tested in the form of a template in a storage means, and a user registering the software component to the server, A software component template management system comprising a client terminal that instructs acquisition,
The server is
After generating a syntax tree of the source code of the software component transmitted from the client terminal, a variable item that appears in the syntax tree is extracted and replaced with a variable item ID for uniquely identifying the variable item And registering in the storage means, and component acquisition means for generating the source code of the software part from the template registered in the storage means and transmitting it to the client terminal. To do.
The component registration means includes means for correcting the variable item ID so as to match the variable item ID of the existing template by comparison with an existing template having a dependency relationship with the template of the software component to be registered. And
The component acquisition means includes source code generation means for generating a source code by embedding customization information transmitted from a client terminal in a variable item of a registered template.

The software component template management system of the present invention has the following effects.
(1) Since variable items in the source code of software parts are automatically extracted and templated, there is no omission of extraction of variable items and the burden on the software part provider can be reduced.
(2) Since the source code of the software component acquired from this system maintains the consistency between the software components, it can be normally compiled and executed without modification by the developer.

Hereinafter, an embodiment of a software component template management system to which the present invention is applied will be described.
FIG. 1 is a system configuration diagram showing an example of an embodiment of the present invention.
The software component template management system according to the present embodiment includes a server 101 that stores software component templates and a plurality of client terminals 102 that a user issues a request. The server 101 and the client terminals 102 are connected via a network. Yes.
The server 101 includes a repository 103, a component registration unit 104, and a component acquisition unit 105.
The component registration unit 104 includes a source code analysis unit 106, a template generation unit 107, and a variable item ID issuing unit 108 as units for registering software components as templates.
The component acquisition unit 105 includes a source code generation unit 109 as a unit for providing a software component requested by a user.
The repository 103 appears in a template 110 of registered software components, a component management table 111 that manages registered software components, a component dependency management table 112 that manages dependencies between software components, and a template 110. A variable item management table 113 for managing variable items to be stored is stored.

FIG. 2 is a diagram illustrating an example of the component management table 111.
The component ID 201 is a key that is assigned to uniquely identify each component.
The part name 202 is the name of the part that the user inputs when registering the part.
The component function description 203 is an explanatory text about the function of the component that is input by the user when the component is registered.
For example, for the component with the component ID = P000001, “character string converter” is registered as the component name, and the function description sentence “It is necessary to comply with the conversion rules” is registered as the component function description. .
Each time one component is registered in the system, one row related to the component is added to the component management table 111.

FIG. 3 is a diagram illustrating an example of the component dependency relationship management table 112.
In the component dependency management table 112, a component ID 301 and a dependent component ID 302 are registered.
Both the component ID 301 and the dependent component ID 302 indicate the component ID 201 recorded on the component management table 111, and indicate that the component indicated by the component ID 301 is dependent on the component indicated by the dependent component ID 302. That is, the dependent component ID is the ID of the parent component. For example, when there are a plurality of parent components such as component ID = P0004, all IDs of these parent components are registered as dependent component IDs.
In the component dependency relationship management table 112, a row is added only when the dependent component information is specified when the user registers a component in the system.

FIG. 4 is a diagram illustrating an example of the variable item management table 113.
In this variable item management table 113, a variable item ID 401, a default value 402, an item type 403, an upper item 404, and an issue date 405 are registered.
The variable item ID 401 is a key for uniquely identifying a variable item in the template 110, and “$” is always added at the beginning and end in order to facilitate identification from other words when embedded in the template. It shall be added.
A default value 402 is a default value of customization information embedded in the variable item. In the source code transmitted when the user registers the software component in the system, the value originally assigned to the variable item is acquired by the source code analysis unit 106 and registered as the default value 402.
The item type 403 indicates the type of the variable item.
The upper item 404 indicates the variable item ID of the upper variable item when the variable item is found to belong to another variable item as a result of the source code analysis by the source code analysis unit 106.
The issue date / time 405 indicates the issue date / time of the variable item.

FIG. 5 is a flowchart showing a software component registration procedure in this system.
First, when the client terminal 102 accesses the component registration unit 104 of the server 101, the component registration unit 104 displays a component registration screen on the client terminal 102 (step 501).
The user of the client terminal 102 inputs the registered component information and the dependent component information on the displayed component registration screen, and transmits them to the component registration unit 104 (step 502).
The component registration unit 104 branches subsequent processing depending on whether or not the dependent component information is included in the information input in step 502.
When the dependent component information is not input in step 502 and only the registered component information is input, the source code analyzing means 106 analyzes the received source code of the registered component and generates a registered component syntax tree (step). 503).
Note that the technique for generating the syntax tree is a well-known technique conventionally used in compilers and the like, and thus detailed description thereof is omitted.
The variable item ID issuing means 108 receives the parsing result of the syntax tree in step 503, sets the package name, class name, method name, field name, and variable name in the parsing result as variable items, and can uniquely identify each variable item. A variable item ID is issued (step 504). Then, the process proceeds to Step 511.

On the other hand, when both the registered component information and the dependent component information are input in step 502, the source code analyzing unit 106 analyzes the source code of the registered component and the source code of the dependent component in a lump (step 505). .
The variable item ID issuing means 108 receives the analysis result of step 505, sets the package name, class name, method name, field name, and variable name in the analysis result as variable items, and is a temporary variable that can uniquely identify each variable item. An item ID is issued (step 506).
Next, the template generation means 107 receives the dependent component source code and the temporary variable item ID list issued in step 506, and replaces each variable item in the source code of the registration target component with the temporary variable item ID. Generate (step 507).

Next, the variable item ID issuing means 108 acquires the dependent component template from the repository 103, compares it with the template of the registration target component generated in step 507, and compares the variable item IDs described in the template with each other. And a correspondence table is created (step 508).
Further, the variable item ID issuing unit 108 resolves the conflict of the existing variable item ID in the variable item ID correspondence table created in step 508 so that the temporary variable item ID and the existing variable item ID have a one-to-one relationship. (Step 509).
If part of the existing variable item ID is changed due to the conflict resolution of the existing variable item ID in step 509, the component registration unit 104 updates the existing template and variable item management table 113 stored in the repository 103. To reflect the change of the existing variable item ID. (Step 510)
Then, the process proceeds to Step 511.

The template generation unit 107 uses the variable item ID list created in step 504 or 509 and replaces each variable item in the source code of the registration target part input by the user in step 502 with the variable item ID. Generate (step 511).
Then, the component registration unit 104 stores the template generated in step 511 in the repository 103 (step 512). Further, the part registration unit 104 registers the part name and part function description input by the user in step 502 in the part management table 111, and in the part dependency management table 112 based on the dependent part information input by the user in step 502. Data is registered, and data is registered in the variable item management table 113 based on the source code analysis result in step 503 or step 505 and the variable item ID list created in step 504 or step 509 (step 513).
Finally, the component registration unit 104 returns a registration completion notification to the client terminal 102 (step 514).

FIG. 6 is a diagram showing an example of the variable item ID correspondence table created in step 508. For one variable item of temporary variable item ID = $ V001200002 $, two variable item IDs with two parent parts are shown. = $ V00000000002 $ and $ V000800001 $ are issued.
Therefore, a process for unifying the variable item ID with the oldest issue date is performed by the conflict resolution process in step 509. Thereby, the variable item IDs of the parent part and the child part are matched in a one-to-one relationship.

FIG. 7 is a flowchart showing the conflict resolution processing of the variable item ID.
First, in the variable item ID correspondence table of FIG. 6, the issue date and time is acquired with reference to the variable item management table 113 for the location where two or more variable item IDs of existing parts are specified, and the variable item with the oldest issue date and time is obtained. The ID is specified (steps 701 and 702).
Next, all the variable item IDs to be updated are replaced with the variable item IDs with the oldest issue date and time, and the variable item management table 113 is updated (steps 703 to 705).
Next, all variable item IDs except the variable item ID with the oldest issue date and time are deleted, and the variable item ID correspondence table is updated (steps 706 to 708).

FIG. 8 is a flowchart showing a procedure for the client 102 to acquire the software component registered in this system.
When the client terminal 102 accesses the component acquisition unit 105 of the server 101 to acquire software components, the component acquisition unit 105 acquires data from the component management table 111 and the component dependency management table 112 and creates a component list screen. Is displayed on the client terminal 102 (step 801).
The user selects all the parts to be acquired on the parts list screen displayed on the client terminal 102 (step 802).

Next, the component acquisition unit 105 searches the full text of the templates 110 of all the components selected in step 802, creates a list of variable items that appear in the template, and sets the data corresponding to the variable items as variable items. Obtained from the management table 113, a customization information input screen is created and displayed on the client terminal 102 (step 803).
The user inputs a customization value corresponding to each variable item on the customization information input screen (step 804).
The component acquisition unit 105 acquires the corresponding template 110 from the repository 103 for all the components selected in step 802, and embeds the customized value input in step 804 in the variable item in the template 110 to generate the source code. Generate (step 805).
Finally, the component acquisition unit 105 transmits the source code generated in step 805 to the client terminal 102 (step 806).

FIG. 9 is an example of a component registration screen displayed on the client terminal 102.
The component registration screen includes an input column for registered component information 901, an input column for dependent component information 902, and a component registration execution button 903.
The registered component information 901 includes a registered component name 904, a component function description 905, and a registered component source code file path 906, all of which are mandatory.
The dependent component information 902 is required to be input only when the software component to be registered depends on some software components already registered in the system, and the dependent component component ID 907 and the dependent component source code file path 908 are input. Consists of.
As for the registered component source code file path 906 and the dependent component source code file path 908, the source code file of the component is stored in advance in the local disk of the client terminal 102, and the path of the file is designated.

When there are a plurality of files, the path of the file that has been compressed and archived into one file is designated. In addition, it is confirmed that the source code files specified by the registered component source code file path 906 and the dependent component source code file path 908 have been successfully compiled and tested after being combined with each other in the development environment. To do. The dependent component source code file path 908 can specify only the source code of a component already registered in the system, that is, the source code file acquired through the component acquiring unit 105.
When the user presses the registration execution button 903, the registered component information 901, the dependent component information 902, the file body specified by the registered component source code file path 906, and the file body specified by the dependent component source code file path 908 are input by the user. Is transmitted to the component registration means 104.

FIG. 10 is an example of a component list screen displayed on the client terminal 102.
A component ID 1001, a component name 1002, and a component function description 1003 display data acquired from the component management table 111.
The dependent component 1004 acquires the component ID of another component on which the component is dependent from the component dependency relationship management table 112 and displays it.
In the acquisition check column 1005, a check box for the user to check a part to be acquired is displayed. In addition, when the component checked by the user depends on another component, the check box of the dependent component is automatically checked, and the dependent component is forcibly acquired at the same time.
When the user presses the customization information input button 1006, the screen transits to the customization information input screen.

FIG. 11 is an example of a customization information input screen displayed on the client terminal 102.
In the input field of the customization information 1101, the user can specify a customization value for all variable items that appear in the part template checked on the part list screen.
The input field of the customization information 1101 acquires data from the variable item management table 113, displays each item hierarchically based on the data of the upper item 404, and sets the default value 402 of each item in the text box. The item type 403 is displayed on the text box.
The user can input a customized value for each item by editing the value in the text box.
When the user presses a component registration execution button 1102, customization information 1101 is transmitted to the component acquisition unit 105.

FIG. 12 shows a template generation example in the template generation unit 107 and a source code generation example in the source code generation unit 109.
The registered component source code 1201 is an example of source code transmitted by a user who wants to register a component through the component registration screen.
The template 1202 is an example of a template generated by editing the source code 1201 by the template generation unit 107 and replacing the variable item with the variable item ID 401.
The generated source code 1203 is an example of source code generated based on the template 1202 by the source code generating unit 109, and the variable item ID in the template 1202 is replaced with customization information input by the user. It is.

  The source code and template of the software component are generally composed of a plurality of files. However, in this embodiment, the plurality of files are compressed and managed as a single file. When a compressed file is processed, it is decompressed and processed one file at a time, and after processing, it is compressed again and returned.

1 is a system configuration diagram showing an embodiment of the present invention. It is a figure which shows an example of the components management table stored in a repository. It is a figure which shows an example of the component dependence management table stored in a repository. It is a figure which shows an example of the variable item management table stored in a repository. It is a flowchart which shows the registration procedure of components. It is explanatory drawing of the process which eliminates the competition of variable item ID. It is a flowchart of the process which cancels | releases the competitive relationship of variable item ID. It is a flowchart of the acquisition procedure of components. It is an example of the components registration screen displayed on a client terminal. It is an example of the components list screen displayed on a client terminal. It is an example of the customization information input screen displayed on a client terminal. It is a figure which shows the example of template generation, and a source code generation example.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Server 102 Client terminal 103 Repository 104 Parts registration means 105 Parts acquisition means 106 Source code analysis means 107 Template generation means 108 Variable item ID issuing means 109 Source code generation means 110 Template

Claims (2)

A software component template management system comprising a server that stores a software component that has been tested in a storage means in the form of a template, and a client terminal that instructs the server to register and acquire the software component.
The server is
After generating a syntax tree of the source code of the software component transmitted from the client terminal, a variable item that appears in the syntax tree is extracted and replaced with a variable item ID for uniquely identifying the variable item Component registration means for generating and registering in the storage means;
Component acquisition means for generating a source code of a software component from a template registered in the storage means and transmitting it to a client terminal ;
Further, the component registration means determines whether or not a plurality of existing template variable item IDs representing the same variable item are issued for each variable item of the registration target software component template. If a template is examined and compared with an existing template that has a dependency, it is unified with the variable item ID with the oldest issue date among the variable item IDs of the plurality of existing templates, and the issue date is the oldest All other variable item IDs except the variable item ID are deleted, and the variable item ID conflict is corrected so that the variable item ID in the template of the software component to be registered matches the variable item ID of the existing template in a one-to-one correspondence. A software component template management system comprising a resolution processing means . 2. The software according to claim 1, wherein the component acquisition unit includes a source code generation unit configured to generate a source code by embedding customization information transmitted from a client terminal in a variable item of a registered template. Component template management system.

Images