JP2016042317A - Software design support device, and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a software design support device and method for automatically performing the refactoring used for summarizing software requirements in model base development.SOLUTION: An analysis is made by a trace analysis unit 13 as to which portion of a model is assigned a requirement on the basis of a model data storage unit 11 in which a model designed in model base development is stored and a software requirement storage unit 12. Refactoring is carried out by a refactoring execution unit 15 on the basis of the result of analysis and an analysis requirement input unit 14 that designates the requirement to be focused on in the refactoring. A simulation is carried out by a simulation execution and result comparison unit 17 on the basis of the result of refactoring, the model present in the model data storage unit 11, and the input data held in a simulation input storage unit 16, and, after confirmation that the result does not have a difference, the portion altered by the refactoring is highlighted by a result display unit 18.SELECTED DRAWING: Figure 1

Description

  The present invention relates to refactoring to aggregate software requirements in model-based development of software.

  As software becomes more complex and development time is shortened, it is becoming increasingly important to design software with consideration for reusability and maintainability. A useful method for this software design is model-based development in which design is performed using a model that can be simulated. In model-based development, for example, Simulink (registered trademark) is used.

  In the design in Simulink (registered trademark), a model is described by a block for which processing is defined and a signal line connecting the blocks. In general, a model is described in a hierarchical structure, and block groups are grouped as subsystems in functional units. For example, in the source code, a block corresponds to one line of code, and a subsystem corresponds to a function.

  In model-based development, Japanese Patent Application Laid-Open No. 2004-133867 has proposed a model verification apparatus that highlights a place where a possibility of a failure is high by simulation. The operation of such a model verification apparatus is shown below.

  FIG. 7 is a flowchart of the comparison process of the model verification apparatus. In FIG. 7, the model verification apparatus reads the comparison model (S405, S410), and sequentially executes the block in the reference model and the block in the comparison model (S415). And while calculating the difference of the calculation result obtained in the same block, each block which comprises a reference | standard model (or comparison model) is displayed, Of these blocks, the difference of the block where the difference exceeded the tolerance | permissible_range Highlighting is performed (S425).

JP 2012-198404 A

  The model verification apparatus in the prior art identifies the cause of the defect by highlighting the block whose difference exceeds the allowable range. In addition, the conventional technology generally focuses on linking with codes and tests, and only supports design changes by highlighting blocks of defective models. Therefore, automatic design changes, particularly automatic design changes based on software requirements have not been made.

  Also, depending on the design, related software requirements may be distributed and assigned to multiple subsystems. It is desirable that the associated software requirements are aggregated into one subsystem and that the degree of aggregation for the software requirements is high. In addition, the subsystem may be corrected by reviewing the design. For example, in the case of compliance with the functional safety standard ISO26262, it is desirable to consolidate subsystems that assign software requirements for safety.

  Accordingly, an object of the present invention is to provide a software design support apparatus and method that automatically perform refactoring for aggregating software requirements.

  In order to solve the above-described object, the present invention provides a software design support apparatus for refactoring an existing model in accordance with software requirements in model-based development, which is based on information associated with the model subsystem and the software requirements. Trace analysis unit that analyzes which software requirement the subsystem is involved in, and expands the subsystem of the model to be refactored based on a plurality of the software requirements specified as input, and the dependency relationship between blocks A refactoring executor for analyzing the subset of the blocks to which the software requirements specified by the method are assigned and changing the subsystem of the model from the subset; and simulating the model before and after the refactoring Result display for displaying the simulation execution and result comparison unit, the block to which the software requirement is assigned, the subsystem changed by the refactoring, and the difference of the simulation result A section.

  The present invention is also a software design support method for refactoring an existing model in accordance with software requirements in model-based development, wherein from the model subsystem and the software requirement linking information, which subsystem is which Trace analysis of whether software requirements are involved, and expand the subsystem of the model to be refactored based on a plurality of the software requirements specified as inputs, and the software specified from the dependency between blocks Analyzing the subset of blocks to which requirements have been assigned, performing the refactoring by changing the subsystem of the model from the subset, and simulating the model before and after the refactoring Running down the steps of comparing the execution result, and the block in which the software requirement is allocated, is intended to include said subsystem changed by the refactoring, the simulation results difference, the method comprising: displaying a, a.

  The software design support apparatus and method according to the present invention can automatically refactor a model by analyzing a subset of blocks associated with an input software requirement. Therefore, the input software requirements are automatically aggregated, and it is possible to obtain a model design with a high degree of cohesion.

Schematic block diagram of a software design support apparatus in Embodiment 1 of the present invention Flowchart for explaining the operation of the software design support apparatus according to Embodiment 1 of the present invention. Model diagram before refactoring operation of software design support apparatus in Embodiment 1 of the present invention The figure which shows the example of an analysis by the search tree of the software design support apparatus in Embodiment 1 of this invention The flowchart which shows the search operation | movement of the software design support apparatus in Embodiment 1 of this invention. Model diagram after refactoring operation of software design support apparatus in Embodiment 1 of the present invention Flow chart for comparison processing of a conventional model verification device

  Hereinafter, a software design support apparatus and method according to the present invention will be described with reference to the drawings.

(Embodiment 1)
FIG. 1 is a schematic block diagram of a software design support apparatus according to the first embodiment. FIG. 2 is a flowchart for explaining the operation of the software design support apparatus according to Embodiment 1 of the present invention. FIG. 3 is a model diagram before the refactoring operation of the software design support apparatus according to Embodiment 1 of the present invention. FIG. 4 is a diagram showing an analysis example using a search tree of the software design support apparatus according to Embodiment 1 of the present invention. FIG. 5 is a flowchart showing the search operation of the software design support apparatus according to Embodiment 1 of the present invention. FIG. 6 is a model diagram after execution of refactoring of the software design support apparatus according to Embodiment 1 of the present invention.

  In FIG. 1, the software design support apparatus 1 is designated as an input and a trace analysis unit 13 that analyzes which subsystem is related to which software requirement from the association information of the model subsystem and software requirement. Expanding the subsystem of the model to be refactored based on a plurality of the software requirements, analyzing a subset of the blocks to which the software requirement specified from the dependency between blocks is assigned, and from the subset The software requirements are assigned to a refactoring execution unit 15 that changes the subsystem of the model, a simulation execution and result comparison unit 17 that executes a simulation of the model before and after the refactoring, and compares execution results. Comprising a said block, said sub-system has been changed by the refactoring, the simulation results difference, the result display unit 18 for displaying the.

  Thus, the model can be automatically refactored by analyzing a subset of blocks associated with the input software requirements. Therefore, the input software requirements are automatically aggregated, and a model design with a high degree of cohesion can be obtained.

  Hereinafter, the configuration and operation of the first embodiment will be described more specifically.

  In FIG. 1, a model designed by model-based development is recorded in the model data storage unit 11. The software requirement storage unit 12 stores software requirements. Therefore, from both, the trace analysis unit 13 analyzes to which part of the model the software requirement is assigned. On the other hand, the software requirement to be focused on by refactoring is designated by the user through the analysis requirement input unit 14.

  In this way, the refactoring execution unit 15 performs refactoring using the input software requirements and the analysis result by the trace analysis unit 13. A simulation is executed by the simulation execution and result comparison unit 17 from the result of the refactoring, the model in the model data storage unit 11, and the input data held in the simulation input storage unit 16. Then, after confirming that there is no difference in the simulation result before and after refactoring, the result display unit 18 highlights the subsystem changed by refactoring. In addition, the result display unit 18 also displays the difference between the simulation result and the block to which the software requirement is assigned.

  Note that the model data storage unit 11, the software requirement storage unit 12, and the simulation input storage unit 16 in FIG. 1 are configured by a storage device such as a hard disk or a memory. The analysis requirement input unit 14 is configured with a keyboard, for example. The result display unit 18 is configured by a color display, for example. The trace analysis unit 13, the refactoring execution unit 15, and the simulation execution and result comparison unit 17 are realized by a part of software shown in FIGS. 2 and 5 described below.

  FIG. 2 is an example of a flowchart for explaining the operation of the software design support apparatus 1. This flowchart is executed by a calculation unit (not shown) included in the software design support apparatus 1.

  When the flowchart of FIG. 2 is executed, the arithmetic unit first reads a file of a current model (hereinafter referred to as a base model) to be refactored in step S1. Next, in step S2, the calculation unit reads the association information between the software requirement and the base model. In step S3, the calculation unit creates a software requirement search tree in accordance with the hierarchical structure of the base model from the inputs in steps S1 and S2. FIG. 3 is a diagram illustrating an example of the base model before the refactoring operation. FIG. 4 is a diagram illustrating an analysis example using a search tree created from the base model of FIG.

  First, the model shown in FIG. 3 includes five subsystems M1 to M5. Further, the sub-system M1 has a hierarchical structure including sub-systems M11 and M12. Similarly, there are subsystems below the subsystems M2 to M5.

  Next, in the search tree shown in FIG. 4, the subsystem M1 in FIG. 3 corresponds to the node D1 in FIG. 4, the subsystem M11 corresponds to the node D11, and the subsystem M12 corresponds to the node D12. Similarly, in the subsystems M2 to M5, the subsystems in the base model are represented as nodes of the search tree. The lower subsystem is associated with software requirements from the association information, and the upper subsystem is associated with all the software requirements of the lower subsystem.

  The operations from step S1 to S3 described above correspond to the operation of the trace analysis unit 13 that analyzes which subsystem is related to which software requirement from the association information of the model subsystem and the software requirement.

  Here, referring back to FIG. 2, the arithmetic unit receives, as input from the analysis requirement input unit 14, a software requirement (hereinafter referred to as a reference requirement) focused on in refactoring in step S <b> 4. Next, in step S5, the calculation unit analyzes the subsystem to which the reference requirement input in step S4 is assigned from the search tree that is the result of step S3, and searches for a dependency (hereinafter referred to as search). To the target list).

  For example, if the requirements X13, X32, and X41 are designated as the standard requirements in step S4, the calculation unit determines that they are assigned to the subsystems A2, C2, and D1, respectively, from the search tree shown in FIG. Then, three subsystems A2, C2, and D1 are added to the search target list.

  Next, the calculation unit traces the dependency relationship of the subsystem in steps S6 and S7, and analyzes the subset of the subsystem related to the reference requirement. In step S6, the dependency relation in the output (previous) direction is traced to the subsystem added to the search target list. On the other hand, in step S7, the dependency relation in the input (rear) direction is traced to the subsystem added to the search target list. FIG. 4 also shows an image of tracing the model dependency.

  FIG. 5 is a flowchart for explaining the subset analysis method in step S6.

  First, in step S61, the calculation unit selects one subsystem (hereinafter referred to as a selected block) from the search target list. At this time, it is efficient to analyze the simulation execution order and select the last execution order. Next, in step S62, the arithmetic unit traces a signal line corresponding to the input of the selected block, and detects a subsystem (hereinafter referred to as an input block) that is an input of the selected block.

  Next, in step S63, the calculation unit determines whether there is a block further traced from the input block. When there is no input block for the selected block (input is received from outside the model), tracing the input from the selected block is terminated. At this time, the simulation execution order is analyzed, and when the execution order of the input blocks is executed before any of the blocks added to the search target list, it is efficient to change the input trace to the end condition.

  If it is determined in step S63 that the input is continued (No in S63), the calculation unit registers the selected block in the subset of the block traced from the input direction in step S64 (hereinafter referred to as a backward subset). . Next, in step S65, the calculation unit sets the input block as a new selection block. Thereafter, the calculation unit repeats steps S62 to S65.

  On the other hand, if it is determined in step S63 that tracing the input is to be terminated (Yes in S63), the calculation unit excludes the subsystem included in the backward subset from the search target list in step S66. Then, in step S67, the calculation unit confirms whether the search target list is empty. When the search target list is not empty (No in S67), the calculation unit repeats the process from S61, and when the search target list is empty (Yes in S67), the analysis ends.

  Also in step S7 of FIG. 2, the calculation unit analyzes in the same manner as in step S6. In the case of step S7, the arithmetic unit follows the subsystem in the output direction and extracts a subset (hereinafter referred to as a forward subset). The search target list is held independently at step S6 and step S7. The subsystems excluded in step S66 are related to the search target list used in step S6, and are not related to the search target list in step S7.

  From such an operation, as a result of step S6 for the model shown in FIG. 3, subsystems A1, A2, B1, B2, B3, C1, C2, C3, and D1 are extracted as backward subsets. Similarly, as a result of step S7, subsystems A2, C1, C2, C3, D1, D2, D3, and E1 are extracted as forward subsets.

  Here, the description returns to the operation shown in FIG.

  In step S8, the calculation unit extracts subsystems included in both the backward subset and the forward subset that are the results of steps S6 and S7. Next, in step S9, the arithmetic unit expands a higher-level subsystem including the extracted subsystem, and reorganizes the extracted subsystem group as a new subsystem (hereinafter, referred to as a refactoring model). A refactoring model). Also record the changed subsystem.

  Here, specific examples of these operations will be shown. In the execution result for the model shown in FIG. 3, subsystems A2, C1, C2, C3, and D1 are extracted as subsystems included in both the backward subset and the backward subset. FIG. 6 is a diagram illustrating an example of a model after refactoring with respect to the model illustrated in FIG. 3. The subsystems M1, M3, and M4 in FIG. 3 are expanded, and the subsets obtained in step S8 are combined into a subsystem R2 in FIG. Subsystem R2 includes subsystems R21, R22, R23 to which reference requirements are assigned. The subsystem R1 that is expanded in the subsystem M1 and is not included in the subsystem R2 is recorded as a changed subsystem. Similarly, the subsystem M4 is expanded, and subsystems R3 and R4 not included in the subsystem R2 are also recorded as changed subsystems.

  In steps S4 to S9 described above, the subsystem of the model to be refactored is expanded based on a plurality of software requirements designated as inputs, and the blocks designated with the software requirements designated from the dependency between blocks are assigned. This corresponds to the operation of the refactoring execution unit 15 that analyzes the subset and changes the subsystem of the model from the subset.

  In step S10, the calculation unit executes a simulation using the same input value for both the base model and the refactoring model. Specifically, the arithmetic unit executes a simulation from the refactoring result, the model in the model data storage unit 11, and the input data held in the simulation input storage unit 16. Then, the arithmetic unit compares the execution results, and records the difference information if the output value is different.

  This step S10 corresponds to the operation of the simulation execution and result comparison unit 17 that executes simulation of the model before and after refactoring and compares the execution results.

  Next, in step S11, the calculation unit displays the refactoring result in step S9 and the simulation result in step S10. As a refactoring result, the arithmetic unit highlights the subsystem changed from the base model, and also highlights the subsystem to which the reference requirement is assigned. Also displayed are blocks to which software requirements are assigned. When the output value is not different as the simulation result, that is, when there is no difference in the simulation result, the calculation unit indicates that there is no problem mixing due to refactoring. When the output values are different, that is, when there is a difference in the simulation result, the calculation unit indicates the difference and the input value.

  As a specific example of highlighting, the subsystems R1, R2, R3, and R4 in FIG. 6 are objects that are highlighted as changes due to refactoring. Further, the subsystems R21, R22, and R23 are distinguished and highlighted by using colors different from the changed points as subsystems to which reference requirements are assigned.

  This step S11 corresponds to the operation of the result display unit 18 for displaying the block to which the software requirement is assigned, the subsystem changed by the refactoring, and the difference between the simulation results.

  With the above configuration and operation, the model can be automatically refactored by analyzing a subset of the blocks associated with the input software requirements, so the input software requirements are automatically aggregated and the cohesion is reduced. The software design support apparatus 1 capable of obtaining a high model design is obtained.

  In the first embodiment, the software design support apparatus 1 is described. However, this may be a software design support method in which a computer executes the flowcharts of FIGS. 2 and 5.

  That is, a process of performing a trace analysis of which subsystem is related to which software requirement from the association information of the model subsystem and the software requirement, and a refactoring target based on the plurality of software requirements specified as inputs Expanding the subsystem of the model, analyzing a subset of the blocks to which the software requirements specified from the dependencies between the blocks are assigned, and changing the subsystem of the model from the subset A process of performing refactoring, a process of executing simulation of the model before and after the refactoring, comparing execution results, the block to which the software requirements are assigned, and the block changed by the refactoring And blanking system, the method comprising: displaying a a difference between the simulation result, a software design support method comprising. Also in this case, the same effect as in the first embodiment can be obtained.

(Embodiment 2)
The second embodiment of the present invention will be described below. In the second embodiment, the same components as those in the first embodiment are denoted by the same reference numerals, and detailed description thereof is omitted. That is, the trace analysis unit 13 records in advance the software requirements and the link information between the model block and the subsystem, which is a feature of the software design support apparatus 1 of the second embodiment. The trace analysis is executed only when the attached information is changed.

  Specifically, the calculation unit records the analysis result in the trace analysis unit 13 as an external file, and thereafter does not perform the trace analysis unless the association information is changed. This eliminates the need to create a model and software requirement search tree.

  In other words, the refactoring result obtained by the refactoring execution unit 15 is stored in the trace analysis unit 13 to specify a new reference requirement for the refactoring model and perform refactoring as shown in FIG. Steps S1 to S3 in the flowchart can be omitted.

  As described above, according to the second embodiment, the trace analysis is performed only when there is a change in the association information. Therefore, if there is no change in the association information, the trace analysis is not performed. Therefore, creation of a search tree can be omitted, and efficiency can be improved.

  In the second embodiment, the software design support apparatus 1 is described. However, this may be a software design support method.

  That is, in the software design support method described in the first embodiment, the trace analysis process records the software requirements and the link information between the model block and the subsystem in advance, and the link information is changed. This is a software design support method including a process of executing the trace analysis only when there is. In this case, the same effect as in the second embodiment can be obtained.

  Since the software design support apparatus and method according to the present invention can automatically perform refactoring of a model, it is particularly useful as a software design support apparatus and method for performing model-based development of software.

DESCRIPTION OF SYMBOLS 1 Software design support apparatus 13 Trace analysis part 15 Refactoring execution part 17 Simulation execution and result comparison part 18 Result display part

Claims (4)

A software design support device that refactors an existing model according to software requirements in model-based development,
A trace analysis unit that analyzes which subsystem is related to which software requirement from the association information of the model subsystem and the software requirement;
Expanding the subsystem of the model to be refactored based on a plurality of the software requirements specified as input, and analyzing a subset of the blocks to which the specified software requirements are assigned from a dependency between blocks; A refactoring execution unit for changing the subsystem of the model from the subset;
A simulation execution and result comparison unit for executing simulation of the model before and after the refactoring and comparing execution results;
A result display unit for displaying the block to which the software requirement is assigned, the subsystem changed by the refactoring, and a difference between simulation results;
A software design support apparatus comprising: The trace analysis unit records the software requirements and the association information between the block of the model and the subsystem in advance, and performs trace analysis only when the association information is changed. The software design support apparatus according to claim 1. A software design support method for refactoring an existing model according to software requirements in model-based development,
Trace analysis of which subsystem is related to which software requirement from the association information of the model subsystem and the software requirement;
Expanding the subsystem of the model to be refactored based on a plurality of the software requirements specified as input, and analyzing a subset of the blocks to which the specified software requirements are assigned from a dependency between blocks; Performing the refactoring by changing the subsystem of the model from the subset;
Performing a simulation of the model before and after the refactoring and comparing the execution results;
Displaying the block to which the software requirement is assigned, the subsystem changed by the refactoring, and a difference in simulation results;
A software design support method comprising: In the process of performing the trace analysis, the software requirements and the association information between the block of the model and the subsystem are recorded in advance, and the trace analysis is executed only when the association information is changed. 4. The software design support method according to claim 3, further comprising:

Images