JP4846483B2 - Software parts reuse support system - Google Patents

Description

  The present invention has a function for finding and proposing the requested software component from the configuration management repository storing the software component based on the test data created by the developer for the software component requested by the developer, and developing The present invention relates to a software component reuse support system having a function of extracting information on source code, specifications, and test data as software components from source code existing in a repository managed by a user.

In system development, rather than creating a program from scratch and developing a system, improvement in development efficiency is inevitably required by reusing a software component to perform system development.
In the invention described in Patent Document 1, when extracting an object by pattern matching, feature extraction for positioning modeling data on a feature vector space based on a certain rule is performed. The requested software component is searched by executing the search based on the formal structure, the semantic structure based on the name, and the relationship between the classes.
JP 2004-287650 A

  However, in the case of the invention described in Patent Document 1, the accuracy of the search result can be increased as the system is used by the learning function of the system, but the learning function is not sufficiently exhibited when the system is started to be used. It is difficult to search for software components required by developers. In addition, since the search is performed based on the formal structure based on the type and number, the semantic structure based on the name, and the relationship between multiple classes, the searched software components are the functions required by the developer. It is not always a software component. Even if it is a software component requested by the developer, it is not easy to determine whether or not the proposed source code is appropriate as the software component requested by the developer. Therefore, it takes time and effort for the developer to determine whether or not the retrieved software component is appropriate.

  An object of the present invention is to retrieve a software component requested by a developer from test data created by the developer and category information of the software component, and to request the software component proposed to the developer when proposing the software component. The object is to provide a software component reuse support system that makes it easy to understand that the above is satisfied.

  In order to achieve the above object, a software component reuse support system according to the present invention includes a developer terminal having a function of inputting category information of a software component requested by a developer and a function of transmitting category information of the software component. A configuration management repository for development that stores information related to source codes, specifications, and test data of the software parts created by the developer; a data reception function that receives information transmitted from the developer terminal; and the development A component support apparatus having a component proposal function for searching and proposing a software component requested by a person and a component collection function for collecting a source code to be a software component from the development configuration management repository, and a source code of the software component To store information on specifications, test data, and test data A software component reuse support system comprising a configuration management repository and a component information database for storing usage status of software components and software component storage information, wherein the component proposal function in the component support device is the developer A component search unit that searches for software components satisfying the developer's request from the category information transmitted from the terminal and the test data of the software component requested by the developer stored in the development configuration management repository, and the component A component information display unit that displays information related to the source code, specification information, and related files of the software component searched by the search unit, and the software component of the information displayed in the component information display unit is transmitted to the developer terminal. A component transmitting unit, and the component collecting function is An analysis unit that analyzes the source code of a software component stored in the configuration management repository for an analysis tool, and a component candidate determination unit that determines whether it can be used as a software component from the information analyzed by the analysis unit And a component storage unit that stores the software component and the component information determined by the component candidate determination unit in the component configuration management repository and the component information database, respectively.

  According to the software component reuse support system of the present invention, a software component required by a developer can be proposed, and whether or not the proposed software component is a software component that can satisfy a developer's request. Can be easily recognized.

Hereinafter, an embodiment of a software component reuse support system to which the present invention is applied will be described.
First, the configuration of the software component reuse support system will be described.
As shown in FIG. 1, the software component reuse support system includes a developer terminal 101, a development configuration management repository 102, a component support apparatus 103, a component configuration management repository 104, a component information database 105, and a generalization person in charge terminal 106. It consists of These devices and the like are connected to each other via a network (not shown) so that data can be transmitted and received.

  The developer terminal 101 is operated by a developer, and the developer terminal 101 requests a software component (hereinafter also simply referred to as “component”) from the component support apparatus 103, and also includes a component information database. A part download or the like is executed from 105. The development configuration management repository 102 also stores information related to source code, specifications, test data, etc. completed by the developer, files created in other system development, and the like. In the component support apparatus 103, when a request for a component proposal is received from the developer, a search for a component that satisfies the required function, a component proposal, a component extraction, and the like are performed, and the usage status of the component and the component registration Information is aggregated. The component support apparatus 103 includes a data reception function 107, a component proposal function 108, a component collection function 109, and a total result notification function 110.

  The data receiving function 107 receives data relating to a developer request transmitted from the developer terminal 101. The component proposal function 108 searches for a component that satisfies the request from the developer based on the transmitted data related to the developer's request, and also proposes the developer terminal 101 to propose the data related to the searched component to the developer. Send to. Further, the component proposal function 108 includes a component search unit 111, a component information display unit 112, and a component transmission unit 113. The part search unit 111 searches the part configuration management repository 104 for parts requested by the developer. The component information display unit 112 displays the source code, specification information, and the like of the retrieved component by using the component retrieved by the component retrieval unit 111 as a proposed component. Then, when the developer receives data indicating that the developer functions to acquire the proposed component, the component transmission unit 113 transmits information on the source code, specifications, test data, and the like of the component to the developer terminal 101.

  The component collection function 109 analyzes the source code stored in the development configuration management repository 102 and determines and extracts the source code to be a component. The total result notification function 110 notifies the generalization person in charge of information on the usage status of parts and information on the extracted parts. Specifically, the component collection function 109 includes an analysis unit 114, a component candidate determination unit 115, and a product storage unit 116. The analysis unit 114 acquires information on the source code, specifications, and test data from the development configuration management repository 102, and analyzes the source code. The component candidate determination unit 115 determines whether the source code can be used as a component based on the information analyzed by the analysis unit 114. The component storage unit 116 stores the component data determined by the component candidate determination unit 115 and information on the component in the component configuration management repository 104 and the component information database 105.

  The component configuration management repository 104 stores information on components collected by the component collection function 109. The parts information database 105 stores information about parts. The generalization person in charge terminal 106 manages the parts stored in the part configuration management repository 104.

Next, a screen displayed on the developer terminal 101 will be described.
As shown in FIG. 2, a screen for inputting information related to a component proposal from a developer is displayed on the component search request screen 200 of the developer terminal 101. Specifically, the parts search request screen 200 displays a text box 201, a check box 202, a “search” button 203, and a “cancel” button 204. The text box 201 stores the test data storage location of the part stored in the development configuration management repository 102 and requested by the developer. In the check box 202, the classification of parts requested by the developer is designated. The “search” button 203 is a button for requesting a search execution request. A “cancel” button 204 is a button for canceling the part search.

  As shown in FIG. 3, the proposed component display screen 300 of the developer terminal 101 includes a file list 301, proposed component specification information 302, a source view 303, a search result 304, a coverage rate 305, a result matching rate 306, “ A “Next” button 307, a “Previous” button 308, a “Download” button 309, and a “Cancel” button 310 are displayed. The file list 301 displays files having a dependency relationship with the component proposed to the developer. In the proposed part specification information 302, the specification of the proposed part is displayed. The source view 303 displays the source code of the proposed component. As a source displayed in the source view 303, there is a function or method of a proposed part. In the search result 304, the number of parts to be proposed is displayed. The coverage rate 305 displays the result of coverage when testing is performed using the source code and test data of the proposed component. The result coincidence rate 306 indicates how much the source code of the proposed part matches the expected value described in the test data when the test is performed using the test data. The “next” button 307 is a button for transitioning to the next candidate component information when a plurality of items are found as a result of searching for the component. The “Previous” button 308 is a button for transitioning to the previous candidate part information. A “download” button 309 is a button for requesting a component transmission request when the developer wants to acquire a proposed component. The “Cancel” button 310 is a button for requesting termination when closing the proposed component information screen.

Next, a method for reusing components realized by the software component reuse support system configured as described above will be described.
Outline of Processing in the Component Support Device 103 As shown in FIG. 4, when data input by the developer is transmitted from the developer terminal 101, the data is received by the data receiving function 107 (step 401). . Next, the developer's request is satisfied from the parts group stored in the parts configuration management repository 104 based on the data received by the data receiving function 107 and the test data stored in the development configuration management repository 102. A part is searched (step 402). Subsequently, the source code and specification information of the component that satisfies the developer's request are transmitted to the developer terminal 101 and displayed on the proposed component display screen 300, so that the component is proposed to the developer (step) 403). Next, source code as a part is extracted from the development configuration management repository 102 (step 404). Then, information on the usage status of the parts and information on the newly registered parts are transmitted to the generalization person in charge terminal 106 (step 405).

Process Flow in Data Receiving Function 107 As shown in FIG. 5, the data receiving function 107 receives data related to category information and test data storage location information transmitted from the developer terminal 101 (step 501). Then, test data is acquired from the development configuration management repository 102 based on the test data storage location information (step 502).

Process Flow in Component Search Unit 111 As shown in FIG. 6, first, the component ID and source code storage information of the component registered in the component information database 105 using the category information received by the data reception function 107 as a key. Is acquired (step 601). Next, the source code of the part stored in the part configuration management repository 104 is acquired based on the source code storage information (step 602). Next, a test driver is created based on the acquired component source code and the test data acquired by the data receiving function 107 (step 604). Subsequently, the created test driver is executed and the test execution results are tabulated (step 605). Specifically, the ratios (hereinafter referred to as “result matching rate”) in which the coverage and execution results are as expected values described in the test data are totaled.

  Then, as a result of the aggregation of the test execution results, when the coverage and the result matching rate exceed the threshold for the coverage and the threshold for the result matching rate (step 606), a component satisfying the condition is proposed to the developer. Is added to the list as a part to be processed (step 607). Steps 604 to 607 are repeatedly executed for the number of parts functions (methods, etc.) acquired from the part configuration management repository 104 (step 603). In addition, the part ID, file name, function name, function start line, function end line, coverage result, result matching rate, etc. of the part are described in the list together with the part proposed to the developer. The function start line and function end line are extracted from the source code when the test driver is created.

Process Flow in Component Information Display Unit 112 As shown in FIG. 7, first, a list of components proposed by the component search unit 111 is acquired (step 701). Next, the dependent file of the proposed component and the specification storage information of the component are acquired from the component information database 105 using the component ID described in the acquired list as a key (step 702). Subsequently, based on the acquired specification storage information, information related to the component specification is acquired from the component configuration management repository 104 (step 703). Then, the file name on which the proposed component depends, the contents of the specification, and the source code of the component are output to the file list 301, the proposed component specification information 302, and the source view 303 on the proposed component display screen 300, respectively (step 704). . When the file name of the component is output on the proposed component display screen 300, the source code from the function start line to the function end line described in the list is in the source view 303, and the function specification information is the proposed component specification information. 302 are displayed respectively.

Processing flow in the component sending unit 113 When the “download” button 309 is pressed by the developer, as shown in FIG. 8, the component displayed on the suggested component display screen 300 of the developer terminal 101 is displayed. A component ID is acquired (step 801). Next, using the acquired component ID as a key, information on the area where the corresponding component is stored, specification storage information, and test data storage information are acquired from the component information database 105 (step 802). Subsequently, based on these pieces of information acquired from the component information database 105, information regarding the source code, specifications, and test data of the component is acquired from the component configuration management repository 104 (step 803). Each file acquired from the component configuration management repository 104 is transmitted to the developer terminal 101 (step 804). After the file is transmitted to the developer terminal 101, the usage frequency 1507 of the component information database 105 is updated (step 805).

Process Flow in Analysis Unit 114 As shown in FIG. 9, first, source code, specifications, and test data stored in the development configuration management repository 102 are acquired (step 901). Next, the aggregation degree of the acquired source code is calculated (step 903), and the coupling degree of the source code is calculated (step 904). The steps 903 and 904 are repeatedly executed for the number of acquired source codes (step 902). Information relating to the source code, specifications, and test data acquired in step 901 is for files updated since the previous check. In addition, the degree of aggregation and the degree of binding are calculated using existing tools.

Process Flow in Component Candidate Determining Unit 115 As shown in FIG. 10, first, the degree of aggregation and the degree of coupling calculated by the analyzing unit 114 are acquired (step 1002), and the degree of aggregation and the degree of coupling acquired are obtained. It is determined whether or not the threshold value exceeds the threshold value for the degree of aggregation and the threshold value for the degree of binding, respectively (step 1003). As a result of the determination, if the degree of aggregation and the degree of coupling exceed the respective thresholds, the number of parts similar to the extracted part (number of similar parts) among the parts stored in the part configuration management repository 104 A calculation is performed as to whether or not there is (step 1004). Further, a source code is extracted as a candidate for a part (step 1005). Steps 1002 to 1005 are repeatedly executed for the number of parts updated from the previous check among the parts stored in the development configuration management repository 102 (step 1001).

-About the flow of the calculation process of the number of similar components in FIG. 10 As shown in FIG. 11, first, the source code and test data stored in the component configuration management repository 104 are acquired (step 1101). Next, a test driver is created based on the test data of the source code that is a candidate for the component and the source code extracted from the component management repository 104 (step 1104). Next, a test driver is created from the component test data extracted from the component management repository 104 and the source code that is a candidate for the component (step 1105). Subsequently, the test is executed by the driver created in Step 1104 (Step 1106), and the test is executed by the driver created in Step 1105 (Step 1107). Then, based on the results of the tests executed in the above steps 1106 and 1107, the result coincidence rates are totaled (step 1108).

  Then, it is determined whether or not the aggregated result coincidence rate exceeds a threshold for the result coincidence rate (step 1109). If the result matching rate exceeds the threshold, it is determined that the component extracted from the component management repository 104 and the component candidate are similar components, and the component management repository 104 registered in the component information database 105 The number of similar parts is updated using the extracted part ID as a key (step 1110). Note that the processing from step 1104 to step 1110 is repeatedly executed for the number of parts functions (methods) acquired from the part configuration management repository 104 (step 1103). Further, the processing from step 1103 to step 1110 is repeatedly executed as many times as the number of functions (methods) in the part candidate source code (step 1102). Here, the threshold value of the result matching rate used in the component search unit 111 is different from the threshold value used in the calculation of the number of similar components.

Processing flow in the component storage unit 116 As shown in FIG. 12, the component ID, classification, summary, component storage information, specification storage information, test data storage information, usage frequency, number of similar components, The notification flag and the related file storage information are registered in the component information database 105 (step 1201). Next, source codes, specifications, and test data of candidate parts registered in the part information database 105 are stored in the part configuration management repository 104 (step 1202). The component ID is automatically issued when registered in the component information database 105. Information about classification and summary is extracted from specifications. Further, when the notification flag is registered in the component information database 105, the flag is set so that the generalization person is notified. The file stored in the component configuration management repository 104 is created with a folder with the name of the component ID, and a source code folder, a specification folder, and a test data folder are created in the folder to facilitate management. Yes.

Process Flow in Total Result Notification Function 110 As shown in FIG. 13, first, information on the component ID, classification, outline, usage frequency, and number of similar components is acquired from the component information database 105 (step 1301). Next, from the acquired data, those for which the usage frequency and the number of similar components exceed the threshold for the usage frequency and the threshold for the number of similar components are determined as general candidates (step 1302). Subsequently, the data of the aggregation result is transmitted to the generalization person in charge terminal 106 (step 1303). Next, the notification flag of the component information database 105 is updated so as to set the notification flag of the component acquired in step 1301 to “notified” (step 1304). Here, the component information acquired from the component information database 105 is targeted for components that have been used since the person in charge of generalization refers to the previous aggregation result and newly registered components. Further, whether or not the previous check has been made is determined from the information of the notification flag in the component information table.

  In addition, the thresholds for the result matching rate, the threshold for coverage, the threshold for cohesion, the threshold for coupling degree, the threshold for usage frequency, and the threshold for the number of similar parts used in advance for each function of the component support apparatus 108 are universal. The component support apparatus 108 is performed in advance by the person in charge of conversion. Here, the threshold value for the result matching rate includes a threshold value used when proposing parts to the developer and a threshold value used in calculating the number of similar parts.

Next, a summary result notification screen 1400 for notifying the usage status of components and information on newly registered components will be described.
As shown in FIG. 14, the general result column 1401, the component ID column 1402, the classification column 1403, the summary column 1404, the usage frequency column 1405, the number of similar components 1406, and the totalization result date 1407 are displayed on the aggregation result notification screen 1400. . The general-purpose column 1401 displays whether or not the part is a general-purpose part. The component ID column 1402 displays a component ID. In the classification column 1403, information about the field in which the part is a part is displayed. A summary column 1404 displays a summary of the part. The usage frequency column 1405 displays information on how much the component has been used so far. The number of similar parts 1406 displays information about how many other parts are similar to the part in the parts configuration management repository 105. The total result date 1407 displays the date when the generalization person was notified of the total result. These pieces of information are also used as information when the general-purpose component person in charge organizes the components stored in the component configuration management repository 105.

Next, the structure of the component information table 1500 when the component information is stored in the component information database 105 will be described.
As shown in FIG. 15, the component information table 1500 includes a component ID column 1501, a classification column 1502, a summary column 1503, a component storage information 1504, a specification storage information 1505, a test data storage information 1506, a usage frequency column 1507, and a similar component. It consists of a number 1508 and a notification flag 1509. In the column of the component ID column 1501, an ID consisting of alphanumeric characters unique to each component is displayed. The component ID 1501 is a main key, and a unique value is automatically issued when registering a component. In the column of the classification column 1502, information on which field is used for the part is displayed. In the column of the summary column 1503, a summary of the parts is displayed. In the part storage information 1504 column, information about where the part source code is stored in the part configuration management repository 104 is displayed.

  Also, in the column of specification storage information 1505, information about where in the component configuration management repository 104 the part specification is stored is displayed. In the column of test data storage information 1506, information about where the test data of the part is stored in the part configuration management repository 104 is displayed. The column of the usage frequency column 1507 displays information on how much the corresponding component has been used so far. In the column of the number of similar parts 1508, information on how many other parts similar to the part exist in the parts configuration management repository 104 is displayed. In the column of the notification flag 1509, information for determining whether or not to notify the generalization person in charge terminal 106 of the usage status of the component in the total result notification function 110 and information on the newly registered component is displayed.

Next, the structure of the component-related file information table 1600 for registering files necessary for executing components will be described.
As illustrated in FIG. 16, the component-related file information table 1600 includes a component ID column 1601 and file storage information 1602. In the column of the component ID column 1601, an ID consisting of alphanumeric characters unique to each component is displayed. The file storage information 1602 displays information about where in the component configuration management repository 104 a file having a dependency relationship with the component ID file is stored. In the component-related file information table 1600, a component ID column 1601 and a file storage information column 1602 are main keys.

As described above, the software component reuse support system of the present embodiment has the following effects.
The parts required by the developer can be proposed by the parts proposal function 108 in the parts support apparatus 103. In addition, the component support apparatus 103 uses the component group stored in the component configuration management repository 104 based on the data received from the developer terminal 101 and the test data stored in the development configuration management repository 102 as the developer's. Since the parts satisfying the requirements are searched, the developer can easily recognize whether or not the parts can satisfy the requirements of the developer.

○ It is determined whether or not the source code created by the developer and stored in the development configuration management repository 102 is usable as a part. If the source code is usable as a part, the source code is It can be extracted and stored as a part in the part configuration management repository 104.
In the column of the usage frequency column 1507 in the component information table 1500, information on how much the corresponding component has been used is displayed. Therefore, it is possible to grasp information on what kind of field is currently used.

The system block diagram which shows an example of embodiment of this invention. Parts search request screen for inputting information related to parts proposals from developers. Proposed component display screen that displays the source code of the component proposed to the developer. 5 is a flowchart showing an outline of processing in the component support apparatus 103; The flowchart which shows the flow of a process of the data reception function 107. FIG. The flowchart which shows the flow of a process of the components search part 111. FIG. The flowchart which shows the flow of a process of the components information display part 112. FIG. The flowchart which shows the flow of a process of the components transmission part 113. FIG. The flowchart which shows the flow of a process of the analysis part 114. FIG. The flowchart which shows the flow of a process of the component candidate determination part 115. FIG. 11 is a flowchart showing a flow of processing for calculating the number of similar parts in FIG. 10. The flowchart which shows the flow of a process of the components storage part. The flowchart which shows the flow of the total result notification function 110. FIG. A summary result notification screen that notifies the usage status of parts and information on newly registered parts. Part information table structure. Structure of part related file information table.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Developer terminal 102 Configuration management repository 103 Development component support apparatus 104 Parts configuration management repository 105 Parts information database 106 Generalization person in charge terminal 107 Data reception function 108 Parts proposal function 109 Parts collection function 110 Aggregation result notification function 111 Parts search part 112 Component information display unit 113 Component transmission unit 114 Analysis unit 115 Component candidate determination unit 116 Component storage unit

Claims (5)

A developer terminal having a function of inputting category information of a software component requested by a developer and a function of transmitting category information of the software component;
A configuration management repository for development that stores information on source code, specifications, test data of the software parts created by the developer;
Data reception function for receiving information transmitted from the developer terminal, part proposal function for searching and proposing software parts requested by the developer, and source code to be software parts collected from the development configuration management repository A component support device having a component collection function
A component configuration management repository for storing information on the source code, specifications, and test data of the software component;
A software component reuse support system comprising a component information database for storing usage status of software components and storage information of software components,
The component proposal function in the component support device is
A component search unit for searching for software components satisfying the developer's request from the category information transmitted from the developer terminal and the test data of the software component requested by the developer stored in the development configuration management repository; ,
A component information display unit for displaying information related to the source code, specification information, and related files of the software component searched by the component search unit;
A component transmission unit that transmits software components of information displayed on the component information display unit to the developer terminal;
The parts collection function is
An analysis unit for analyzing the source code of the software component stored in the development configuration management repository with an analysis tool;
A component candidate determination unit that determines whether or not the information can be used as a software component from the information analyzed by the analysis unit;
A software component reuse support system comprising a component storage unit that stores software components and component information determined by the component candidate determination unit in the component configuration management repository and the component information database, respectively. The software component reuse support system further receives information on the usage status of the software component and new registration information from the component support device, and stores the software component stored in the component configuration management repository based on these information It has a general-purpose person in charge terminal that manages
2. The software component re-use according to claim 1, wherein the component support apparatus further includes a total result notification function for notifying the general-purpose component person-in-charge terminal of information regarding the usage status of the software component and newly registered components. Use support system. The component retrieval unit retrieves a software component similar to the software component requested by the developer from the component configuration management repository based on category information and test data of the software component transmitted from the developer. The software component reuse support system according to claim 1 or 2. When searching for a software component similar to the software component requested by the developer, the component search unit selects a test driver based on the test data and the source code of the software component stored in the component configuration management repository. Generating and executing a test driver to calculate a result matching rate indicating a ratio of the test result to the coverage and the expected value of the test data, the coverage and the result matching rate being a threshold value for the coverage and 4. The software component reuse support system according to claim 3, wherein it is determined whether or not a threshold for the result matching rate is exceeded, and if the threshold is exceeded, it is determined that the software component is a similar software component. . The component collection function analyzes the source code stored in the configuration management repository for development, determines whether the source code can be used as a software component from the aggregation degree and coupling degree of the source code, If it is determined that the source code can be used as a software component, information on the source code, specifications, and test data of the software component is extracted from the development configuration management repository and stored in the component configuration management repository The software component reuse support system according to any one of claims 1 to 4, wherein the software component reuse support system is provided.