System design learning device, system design learning method, and program

Abstract

This system design learning device comprises: a functional requirement training unit which trains a first learning model that executes a concretization process that converts an abstract portion of system requirements or a system configuration plan into a concrete portion, thereby outputting an evaluation value that represents the level of likelihood that a system requirement or a system configuration plan satisfies a system functional requirement and is converted to a system concrete configuration that is information representing the configuration of a system that does not include an abstract portion; a performance measurement unit which measures performance data by executing a performance measurement process for the performance of the concrete system configuration when the concrete configuration has been generated by the functional requirement training unit that performs the training and executes the concretization process; and a non-functional requirement training unit which trains a second learning model that outputs an evaluation value representing the level of likelihood that the system concrete configuration exhibits the performance that satisfies a non-functional requirement by using the performance data which is measured by the performance measurement unit and corresponds to the system concrete configuration.

Description

System design learning device, system design learning method, and computer-readable recording medium

[0001] The present disclosure relates to a system design learning device and a system design learning method used for designing a system, and further to a computer-readable recording medium on which a program for realizing these is recorded.

[0002] When designing an ICT (Information and Communication Technology) system, the first step is to define the requirements. The designer creates information (system requirements) that summarizes the customer's requirements and requests and represents the configuration of the ICT system, including both concrete and abstract elements.

[0003] The configuration of an ICT system can be represented as a graph based on concepts such as IBN (Intent-based networking). A graph represents the elements (components) included in the configuration of an ICT system using nodes or edges. A node is a component that represents, for example, a device or an application. An edge is a component that represents the connection between two nodes.

[0004] Next, in the automatic design, the abstract parts included in the system requirements are concretized based on the concretization rules created in advance, and information (system concrete configuration) that represents the configuration of the ICT system in a deployable state is derived.

[0005] The concretization rules are information used to gradually concretize an abstract part and convert it into a concrete part.

[0006] The concrete part represents a part or configuration that is determined to be actually used in an ICT system, while the abstract part represents an undetermined part or configuration whose function is determined but whose actual use in the system is not yet concretely determined.

[0007] As a related technique, Patent Document 1 discloses a system configuration derivation device that gradually concretizes abstract elements and derives a specific system configuration of a deployable ICT system. According to the system configuration derivation device of Patent Document 1, undetermined elements included in the system requirements are gradually concretized using concretization rules, and a final feasible specific system configuration is derived.

[0008] Specifically, the system configuration derivation device of Patent Document 1 uses concretization rules to detect one or more abstract parts contained in system requirements, and converts the detected abstract parts into concrete parts to generate a system configuration proposal or a concrete system configuration.

[0009] A system configuration plan is information that represents a configuration that includes abstract parts before a specific system configuration is derived. Therefore, system requirements can also be thought of as a system configuration plan.

[0010] If the system configuration plan contains abstract parts, they are converted again using the concretization rules. After that, the conversion is repeated, and when all parts are concretized, the system concrete configuration is derived.

[0011] However, when system requirements and system configuration proposals are concretized, multiple concretization rules are applied. In this case, the derived system configuration proposal or system concrete configuration changes depending on the selected concretization rules and the order in which the concretization rules are selected. In other words, different system configuration proposals and system concrete configurations are derived depending on the order in which the concretization rules are selected.

[0012] Furthermore, as the number of instantiation rules increases, the number of system configuration proposals and specific system configurations generated becomes enormous. Furthermore, the multiple different specific system configurations may include specific system configurations that do not satisfy the system requirements. Therefore, it is expected that the system configuration deriving device of Patent Document 1 will not be able to efficiently derive specific system configurations.

[0013] Therefore, in order to efficiently derive a system specific configuration, it is important to appropriately judge the merits of the selection of the instantiation rules and the order in which the instantiation rules are selected.

[0014] As a related technique, Non-Patent Document 1 discloses a technique for appropriately determining whether the selection of a concatenation rule and the order in which the concatenation rules are selected are good or bad.

[0015] International Publication No. 2019 / 216082

[0016] Takashi Maruyama et al., "Improving Search Efficiency by Reinforcement Learning in Search-Based Network Design Methods," IEICE Technical Report, vol. 118, no. 483, ICM2018-71, pp. 123-128, March 2019.

[0017] However, the reinforcement learning disclosed in Non-Patent Document 1 is related to functional requirements, but not to non-functional requirements.

[0018] The requirements definitions mentioned above are generally divided into two types: functional requirements and non-functional requirements. Functional requirements specify the functions that an ICT system should have. Non-functional requirements specify elements other than the functions that an ICT system should have, such as availability, performance, scalability, operability / maintainability, and security.

[0019] One object of the present disclosure is to provide a system design learning device, a system design learning method, and a computer-readable recording medium for comprehensively learning functional requirements and non-functional requirements.

[0020] In order to achieve the above object, a system design learning device according to one aspect of the present disclosure is characterized by having: a functional requirements learning unit that learns a first learning model that outputs an evaluation value representing a likelihood that a system requirement or a system configuration proposal to be concretized, which is information representing a system configuration including abstract parts, will satisfy the functional requirements of the system and will be converted into a specific system configuration, which is information representing the system configuration without including abstract parts, by performing a concretization process that converts abstract parts into concrete parts; a performance measurement unit that, when the specific system configuration is generated by performing the concretization process during learning, constructs a measurement system, which is a measurement environment, based on the specific system configuration, performs a performance measurement process using the measurement system for predetermined performance, and stores performance data resulting from the performance measurement process in a storage device; and a non-functional requirements learning unit that learns a second learning model that uses the performance data corresponding to the specific system configuration measured by the performance measurement unit, and outputs an evaluation value representing a likelihood that the specific system configuration will be able to perform and satisfy non-functional requirements.

[0021] In addition, to achieve the above object, in one aspect of the present disclosure, a system design learning method is characterized in that a computer executes: a functional requirements learning step in which a computer learns a first learning model that executes a concretization process for converting abstract parts of a system requirement or a system configuration proposal to be concretized, the system requirement or the system configuration proposal being information representing a system configuration including abstract parts, into concrete parts, thereby learning about a first learning model that outputs an evaluation value representing a likelihood that the system requirement or the system configuration proposal will satisfy the functional requirements of the system and will be converted into a specific system configuration, which is information representing the configuration of the system that does not include abstract parts; a performance measurement step in which, when the specific system configuration is generated by executing the concretization process during learning, the functional requirements learning step constructs a measurement system, which is a measurement environment, based on the specific system configuration, executes a performance measurement process using the measurement system for predetermined performance, and stores performance data resulting from the performance measurement process in a storage device; and a non-functional requirements learning step in which the performance measurement step uses the performance data corresponding to the measured specific system configuration to learn about a second learning model that outputs an evaluation value representing a likelihood that the specific system configuration will be able to perform to satisfy non-functional requirements.

[0022] Furthermore, in order to achieve the above-mentioned object, a computer-readable recording medium having a program recorded thereon according to one aspect of the present disclosure is characterized in that it records a program including instructions for causing a computer to execute: a functional requirements learning step in which a first learning model is learned, the first learning model executing a concretization process for converting abstract parts into concrete parts of system requirements or system configuration proposals to be concretized, the system requirements or the system configuration proposals being information representing the configuration of a system including abstract parts, so that the system requirements or the system configuration proposals satisfy the functional requirements of the system and output an evaluation value representing the likelihood of being converted into a specific system configuration, which is information representing the configuration of the system that does not include abstract parts; a performance measurement step in which, when the specific system configuration is generated by executing the concretization process during learning, the functional requirements learning step constructs a measurement system, which is a measurement environment, based on the specific system configuration, executes a performance measurement process using the measurement system for predetermined performance, and stores performance data resulting from the performance measurement process in a storage device; and a non-functional requirements learning step in which the performance measurement step uses the performance data corresponding to the measured specific system configuration to learn a second learning model, the second learning model outputting an evaluation value representing the likelihood of the specific system configuration being able to perform in a manner that satisfies non-functional requirements.

[0023] According to the present disclosure, functional requirements and non-functional requirements can be learned comprehensively.

[0024] FIG. 1 is a diagram illustrating the automated design of a face recognition system. FIG. 2 is a diagram illustrating the data structure of component information. FIG. 3 is a diagram illustrating the data structure of system requirements. FIG. 4 is a diagram illustrating concretization rules. FIG. 5 is a diagram illustrating the data structure of concretization rules. FIG. 6 is a diagram illustrating an example of a system design learning device. FIG. 7 is a diagram illustrating an example of a system having a system design learning device. FIG. 8 is a diagram illustrating an example of the operation of the system design learning device. FIG. 9 is a diagram illustrating an example of the operation of a functional requirement learning unit. FIG. 10 is a diagram illustrating an example of the operation of functional requirement learning. FIG. 11 is a diagram illustrating an example of the operation for generating a configuration path and a component path. FIG. 12 is a diagram illustrating an example of the data structure of search tree information. FIG. 13 is a diagram illustrating an example of a search tree. FIG. 14 is a diagram illustrating an example of the data structure of a configuration path. FIG. 15 is a diagram illustrating an example of the data structure of a component path. FIG. 16 is a diagram illustrating an example of the operation for updating reward information. FIG. 17 is a diagram illustrating an example of the operation for determining a reward and generating learning data. FIG. 18 is a diagram illustrating an example of the data structure of first learning data. FIG. 19 is a diagram illustrating an example of the data structure of learning data. FIG. 20 is a diagram illustrating an example of an operation of performance measurement. FIG. 21 is a diagram illustrating an example of an operation of a learning unit. FIG. 22 is a diagram illustrating an example of an operation of non-functional requirement learning. FIG. 23 is a diagram illustrating an example of an operation for generating a configuration path and a component path. FIG. 24 is a diagram illustrating an example of an operation for generating learning data. FIG. 25 is a diagram illustrating an example of the data structure of second learning data. FIG. 26 is a diagram illustrating an example of the data structure of second learning data. FIG. 27 is a diagram illustrating an example of a computer that realizes a system design learning apparatus.

[0025] First, an overview will be given to facilitate understanding of the embodiments to be described below.

[0026] (System Design) As an example, the design of a face authentication system will be described. When designing a face authentication system, first, the designer creates system requirements for the face authentication system.

[0027] Fig. 1 is a diagram for explaining the automated design of a face recognition system. Graph G1 in Fig. 1 is a graph representing the configuration of system requirements R1 of a face recognition system. Graph G1 in Fig. 1 is represented using nodes N1 to N4 and edges E1 to E3.

[0028] Node N1 represents a specific camera function (solid circle), node N2 represents a specific face recognition function (solid circle), node N3 represents a specific server computer function (solid circle), and node N4 represents an abstract server computer function (dashed circle). Edge E1 represents an abstract HTTP communication function (dashed arrow), and edges E2 and E3 represent specific join functions (solid arrow).

[0029] Fig. 2 is a diagram illustrating the data structure of part information. In part information P1 shown in Fig. 2, for each piece of part identification information that identifies a node or edge, function information that indicates the function of the node or edge and information (concrete (1) / abstract (0)) that indicates whether the node or edge is a concrete part configuration or an abstract part configuration are associated.

[0030] 2, the part identification information "N1," the function information "camera," and the information "1" indicating that the node is concrete are associated with each other. Similarly, the part identification information "N2" to "N4" and "E1" to "E3" are each associated with the function information and the information indicating whether the node or edge is concrete or abstract.

[0031] 3 is a diagram for explaining the data structure of a system requirement. As shown in Fig. 3, a system requirement R1 corresponding to the graph G1 shown in Fig. 1 is represented using two nodes (a start node and an end node) and an edge (a connection edge) connecting the two nodes.

[0032] Specifically, system requirement R1 is information that associates component identification information for identifying the starting node (starting node), component identification information for identifying the ending node (ending node), and component identification information for identifying the edge connecting two nodes (connecting edge).

[0033] In the above-mentioned Figures 1 to 3, the graph, part information, and system requirements are explained using the graph G1, part information P1, and system requirement R1, but the graph, part information, and system requirement are not limited to the graph G1, part information P1, and system requirement R1.

[0034] Next, in the automated design, the abstract parts are converted into concrete parts. In the example of Figure 1, by concretizing a graph G1 corresponding to a system requirement R1 based on the concretization rules, graphs G2, G3, G4, ... corresponding to multiple system configuration plans R2, R3, R4 as shown in Figure 1 are derived.

[0035] 4 is a diagram for explaining the instantiation rules, showing graphs G31, G32, G33, etc., which are graphs representing a plurality of instantiation rules.

[0036] Graph G31 is a graph representing concatenation rule Rule1 used to convert graph G1 shown in Fig. 1 into graph G2 shown in Fig. 1. Graph G32 is a graph representing concatenation rule Rule2 used to convert graph G1 shown in Fig. 1 into graph G3 shown in Fig. 1 (converting node N4 into node N5). Graph G33 is a graph representing concatenation rule Rule3 used to convert graph G1 shown in Fig. 1 into graph G4 shown in Fig. 1 (converting node N4 into node N6).

[0037] 5 is a diagram illustrating the data structure of a concretization rule. Concretization rule Rule1 shown in FIG. 5 corresponds to graph G31. Concretization rule Rule1 also includes detection information 51 used to detect abstract parts and conversion information 52 used to convert detection information 51 into concrete parts.

[0038] Although not shown, the graphs G32, G33, . . . also have instantiation rules Rule2, Rule3, .

[0039] When deriving graphs G2, G3, and G4 from graph G1 shown in Figure 1, first, the system requirement R1 is compared with multiple pieces of detection information (abstract parts of the concretization rules) to detect detection information that matches the abstract parts contained in the system requirement R1.

[0040] Next, the detected abstract part of the system requirement R1 is converted into conversion information (the concrete part of the concatenation rule) using the detection information corresponding to the detected abstract component configuration. In the conversion to graph G2, since the detection information 51 of the system requirement R1 matches the detection information 51 of the concatenation rule Rule1, the system requirement R1 is replaced (converted) with the conversion information 52 of the concatenation rule Rule1.

[0041] As a result, edge E1 is deleted from system requirement R1, edge E4 is added, and system configuration plan R2 (not shown) corresponding to graph G2 is generated. System configuration plans R3 and R4 (not shown) corresponding to graphs G3 and G4, respectively, are also generated.

[0042] Next, for each of the multiple system configuration plans generated, the abstract parts of the system configuration plan are converted into concrete parts using the concretization rules. When further system configuration plans are generated, the above-mentioned concretization process is repeated. When no more system configuration plans are generated and only the concrete system configuration remains without the abstract component configuration, the concretization process is stopped (automated design is terminated).

[0043] However, when concretizing the system requirements and the system configuration plan, multiple concretization rules are used, and the derived system configuration plan and system specific configuration change depending on the concretization rules selected and the order in which the concretization rules are selected. In other words, different system configuration plans and system specific configurations are derived depending on the order in which the concretization rules are selected.

[0044] Furthermore, as the number of instantiation rules increases, the number of system configuration proposals and system instantiations generated becomes enormous. Furthermore, among the multiple different system instantiations, there may be a system instantiation that does not satisfy the system requirements. Therefore, it is difficult to derive a system instantiation efficiently.

[0045] Furthermore, in order to efficiently derive a system instantiation, it is important to appropriately determine which instantiation rules to apply and the order in which the instantiation rules should be applied.

[0046] Therefore, the system configuration plan generated by executing the instantiation process is evaluated using a learning model acquired by machine learning, and the system configuration plan with the highest evaluation value is selected from the system configuration plans. In this way, by repeating the instantiation process using the learning model, the system configuration can be efficiently derived.

[0047] The learning model outputs an evaluation value (expected score, likelihood) that indicates the likelihood (possibility) that the target system configuration proposal can derive a specific system configuration that satisfies the functional requirements.

[0048] In the example of Figure 1, the learning model outputs "9" (number in circle) as the expected score for system configuration plan R2 corresponding to graph G2, outputs "1" (number in circle) as the expected score for system configuration plan R3 corresponding to graph G3, and outputs "3" (number in circle) as the expected score for system configuration plan R4 corresponding to graph G3.

[0049] Next, in the example of FIG. 1, the expected score "9" of system configuration plan R2 corresponding to graph G2 is the highest among system configuration plans R2 to R4, so system configuration plan R2 corresponding to graph G2 is selected.

[0050] Next, a concrete system configuration R2 corresponding to graph G2 is subjected to a concrete process to generate a new system configuration plan, and the expected score of the new system configuration plan is output. In the example of Figure 1, a concrete system configuration R5 corresponding to graph G5 is generated.

[0051] In this way, by selecting the system configuration plan with the highest expected score each time a specific system configuration is realized, the specific system configuration can be derived efficiently.

[0052] (Learning of the Learning Model) First, the above-mentioned system requirements, system configuration plan, and specific system configuration represent system configurations related to functional requirements. The above-mentioned learning model outputs an expected score for the system configuration plan related to the functional requirements.

[0053] Next, Non-Patent Document 1 discloses the use of reinforcement learning for the learning of the above-mentioned learning model. However, Non-Patent Document 1 does not clearly describe the learning of non-functional requirements.

[0054] Therefore, Non-Patent Document 1 does not disclose or suggest comprehensive learning of functional requirements and non-functional requirements.

[0055] Furthermore, if you simply try to learn functional requirements and non-functional requirements at the same time, the time required to measure the performance of the specific system configuration, which is necessary to learn about non-functional requirements, becomes a bottleneck and learning takes a long time.

[0056] Through this process, the inventors have discovered the above-mentioned problems and have also derived means for solving the problems.

[0057] In other words, the inventor has derived a means for comprehensively learning functional and non-functional requirements, which allows for a reduction in learning time even when learning functional and non-functional requirements comprehensively.

[0058] (Non-functional Requirements) Non-functional requirements are defined as constraints on the system configuration (the above-mentioned system requirements, or the system configuration proposal, or the specific system configuration) or constraints on the component configuration included in the system configuration.

[0059] For example, in the face authentication system of Figure 1, the face authentication function has the function of communicating with the camera function to capture video data, and the above-mentioned communication speed must be 10 Mbps (megabits per second; the same applies below) or higher.

[0060] In this case, the edge E1 of the system requirement R1 representing the configuration of the face recognition system in Fig. 1 has a constraint expression representing that the communication speed is 10 [Mbps] or more. The constraint expression can be expressed as, for example, communication speed >= 10 [Mbps].

[0061] Furthermore, if the cost of the entire face recognition system needs to be 10 million yen or less, the face recognition system has a constraint expression that indicates that the cost must be 10 million yen or less. The constraint expression can be expressed as, for example, cost<=10 million yen.

[0062] (Performance Measurement) The reasons why performance measurement takes time include the following (1) and (2).

[0063] (1) This is because it takes time to generate the specific system configuration of the ICT system for which performance measurement is to be performed. Even if the specific system configuration is constructed automatically in a virtual environment, currently, it takes several minutes for each element that makes up the ICT system, so it generally takes from several tens of minutes to several hours for the entire ICT system.

[0064] (2) Performance measurement itself takes time. Simple performance measurements require only a few minutes per performance measurement item, but if high-precision performance measurements are required, the system must be operated for long periods of time to obtain stable data. As a result, it is expected that performance measurement would take an unrealistic amount of time to perform simultaneously with training.

[0065] (Learning Model for Non-functional Requirements) The learning model that has learned about non-functional requirements is used to determine how to proceed with concretization in the design. Specifically, when determining how to concretize a certain system requirement or system configuration proposal, the concretization rules are applied to the system requirement or system configuration proposal just once to list the resulting system configuration proposals or specific system configurations, and the learning model calculates their evaluation values ​​for the non-functional requirements.

[0066] Then, based on the calculated evaluation value, it is determined which of the listed system configuration plans or specific system configurations to select. The evaluation value is preferably an expected value expressed as a scalar value or a parameter for defining the probability distribution. For example, if the probability distribution is a Gaussian mixture distribution, the parameter is preferably the mean, variance, or mixture number of each Gaussian distribution. However, the parameter is not limited to the mean, variance, or mixture number of each Gaussian distribution described above.

[0067] Hereinafter, an embodiment will be described with reference to the drawings. In the drawings described below, elements having the same or corresponding functions are denoted by the same reference numerals, and repeated description thereof may be omitted.

[0068] The configuration of the system design learning device 10 according to the embodiment will be described with reference to Fig. 6. Fig. 6 is a diagram showing an example of the system design learning device.

[0069] 6 is a device for comprehensively learning functional requirements and non-functional requirements. The system design learning device 10 includes a functional requirement learning unit 11, a performance measurement unit 12, and a non-functional requirement learning unit 13.

[0070] The functional requirement learning unit 11 learns about a first learning model that outputs an evaluation value representing the likelihood that the system requirements or system configuration proposal to be concretized, which is information representing the configuration of a system including abstract parts, will satisfy the functional requirements of the system and be further converted into a system concrete configuration, which is information representing the configuration of a system that does not include abstract parts, by performing a concretization process that converts abstract parts into concrete parts for the system requirements or system configuration proposal to be concretized.

[0071] When the functional requirement learning unit 11 generates a specific system configuration by executing a concretization process during learning, the performance measurement unit 12 constructs a measurement system, which is a measurement environment, based on the specific system configuration, executes a performance measurement process for pre-set performance using the measurement environment, and stores the performance data resulting from the performance measurement process in a storage device.

[0072] The non-functional requirements learning unit 13 learns about a second learning model that uses performance data corresponding to the specific system configuration measured by the performance measurement unit 12 to output an evaluation value that represents the likelihood that the specific system configuration will be able to perform in a way that satisfies the non-functional requirements.

[0073] In this manner, in the embodiment, the performance measurement unit 12 is provided, and functional requirement learning is performed first, followed by non-functional requirement learning, thereby making it possible to comprehensively perform functional requirement learning and non-functional requirement learning.

[0074] Furthermore, since functional requirements are learned first and performance data is obtained by executing performance measurement processing on the measurement system built based on the specific system configuration generated in the functional requirements learning, the performance measurement time can be shortened. As a result, the learning time can be shortened even when functional and non-functional requirements are learned comprehensively.

[0075] Furthermore, as functional requirement learning progresses, the time required to derive the specific system configuration is reduced, thereby reducing the time required to learn functional requirements and non-functional requirements.

[0076] [System Configuration] Next, the configuration of the system design learning device 10 in the embodiment will be described in more detail with reference to Fig. 7. Fig. 7 is a diagram showing an example of a system including a system design learning device.

[0077] The system 100 includes at least a system design learning device 10, a storage device 20, an input device 30, and an output device 40. The system design learning device 10, the storage device 20, the input device 30, and the output device 40 are communicatively connected via a network.

[0078] The system design learning device 10 is, for example, an information processing device such as a CPU (Central Processing Unit), a programmable device such as an FPGA (Field-Programmable Gate Array), a GPU (Graphics Processing Unit), or a circuit equipped with one or more of these, a server computer, a personal computer, or a mobile terminal.

[0079] The storage device 20 is a database, a server computer, a circuit having a memory, etc. The storage device 20 stores at least the information described below. In the example of Fig. 2, the storage device 20 is provided outside the system design learning device 10, but it may also be provided inside the system design learning device 10.

[0080] The input device 30 is, for example, a keyboard, a mouse, a touch panel, etc. The input device 30 is used when operating the system design learning device 10, the output device 40, etc.

[0081] The output device 40 acquires output information (described later) converted into an outputtable format by the output information generation unit 15, and outputs generated images, sounds, and the like based on the output information. The output device 40 is, for example, an image display device using a liquid crystal, an organic electroluminescence (EL) display, or a cathode ray tube (CRT). The image display device may also include an audio output device such as a speaker. The output device 40 may also be a printing device such as a printer.

[0082] The communication network is a general network constructed using communication lines such as the Internet, a LAN (Local Area Network), a dedicated line, a telephone line, an in-house network, a mobile communication network, Bluetooth (registered trademark), and Wi-Fi (Wireless Fidelity).

[0083] (System Design Learning Apparatus) The system design learning apparatus will be described in detail. The system design learning apparatus 10 in the embodiment includes a functional requirement learning unit 11, a performance measurement unit 12, a non-functional requirement learning unit 13, a learning control unit 14, and an output information generation unit 15.

[0084] The learning control unit 14 controls the functional requirement learning unit 11, the performance measurement unit 12, the non-functional requirement learning unit 13, etc. The functional requirement learning unit 11 has a design unit 111, a learning data generation unit 112, and a learning unit 113. The non-functional requirement learning unit 13 has a design unit 131, a learning data generation unit 132, and a learning unit 133.

[0085] The output information generation unit 15 generates output information for outputting to the output device 40, such as the system configuration, the proposed system configuration, the specific system configuration, graphs, search tree information, and information regarding the progress of learning (for example, the number of search steps by the current first learning model for the first learning model of functional requirements, the likelihood for each learning data for the second learning model of non-functional requirements, and their average values, etc.), and outputs the information to the output device 40.

[0086] The design unit 111 converts the abstract parts into concrete parts in stages based on the system requirements, which are information representing the configuration of a system including abstract parts, to generate a system configuration plan and a concrete system configuration.

[0087] The learning data generation unit 112 generates first learning data to be used for learning the first learning model.

[0088] The learning unit 113 uses the first learning data generated by the learning data generation unit 112 to perform learning of the first learning model.

[0089] Based on the system requirements, which are information representing the configuration of a system including abstract parts, the design unit 131 converts the abstract parts into concrete parts in stages to generate a system configuration plan and a concrete system configuration.

[0090] The learning data generation unit 132 generates second learning data to be used for learning the second learning model.

[0091] The learning unit 133 uses the second learning data generated by the learning data generation unit 132 to perform learning of the second learning model.

[0092] [Device Operation] The operation of the system design learning device in the embodiment will be described. In the following description, reference will be made to the figures as appropriate. In the embodiment, the system design learning method is implemented by operating the system design learning device. Therefore, the description of the system design learning method in the embodiment will be replaced by the description of the operation of the system design learning device below.

[0093] The operation of the system design learning device will now be described. Fig. 8 is a diagram for explaining an example of the operation of the system design learning device. First, the learning control unit 14 acquires system requirements to be learned from the storage device 20 (step S11).

[0094] Next, the functional requirement learning unit 11 uses the acquired system requirements to learn the functional requirements (step S12). Details of step S12 will be described later with reference to FIG.

[0095] The performance measurement unit 12 then executes a performance measurement process on the specific system configuration that satisfies the functional requirements generated in step S12 to obtain performance data, and stores the obtained performance data in the storage device 20 (step S13). Details of step S13 will be described later with reference to FIG.

[0096] Next, the non-functional requirement learning unit 13 uses the system requirements and the performance data to learn the non-functional requirements (step S14). Details of step S14 will be described later with reference to FIG.

[0097] The operation of the functional requirement learning unit 11 (step S12) will now be described. FIG. 9 is a diagram for explaining an example of the operation of the functional requirement learning unit. First, the functional requirement learning unit 11 uses the system requirements to perform reinforcement learning on the functional requirements for a preset learning period (step S121). Details of step S121 will be described later with reference to FIG. 10.

[0098] The learning period is determined, for example, by experiments, simulations, etc. Alternatively, the number of learning iterations may be used instead of the learning period. When a neural network is used for reinforcement learning, the number of learning iterations is the number of times the neural network weights are updated.

[0099] Next, the functional requirement learning unit 11 executes a concrete process (design) for the system requirements using the current first learning model (step S122).

[0100] The concrete processing is processing for concretely specifying the abstract parts (component configurations) included in the system requirements. For example, when a neural network is used for reinforcement learning, the first learning model uses the neural network.

[0101] Next, if the functional requirement learning unit 11 determines based on the result of step S122 that the learning of the functional requirements is sufficient (step S123: Yes), it ends the processing of step S12. If the functional requirement learning unit 11 determines that the learning of the functional requirements is insufficient (step S123: No), it repeats (continues) the processing of steps S121 and S122 until it determines that the learning of the functional requirements is sufficient.

[0102] The determination in step S123 is, for example, that the design is sufficient if the number of search steps in the design is equal to or less than a preset threshold A. Alternatively, the design performed in step S122 in the past may be determined to be sufficient if the number of search steps in the design is equal to or less than a preset threshold B for a specified number of consecutive times. However, the determination in S123 is not limited to the above-described determination.

[0103] The number of search steps depends on the design in step S122. The number of search steps is the number of configuration plans actually arrived at during the design. The number of search steps can also be rephrased as the number of instantiation rules actually applied during the design.

[0104] The thresholds A and B may be determined in any way as long as it is possible to determine that the number of steps required for design has been sufficiently shortened. For example, the shortest number of steps required for a search may be calculated in advance, and a value that allows a certain margin from the shortest number of steps (for example, 10%) may be set as the thresholds A and B. Alternatively, the number of search steps executed within a practically acceptable period of time (for example, 10 minutes) may be calculated in advance, and this may be set as the thresholds A and B.

[0105] The operation of functional requirement learning (step S121) will now be described: Fig. 10 is a diagram for explaining an example of the operation of functional requirement learning.

[0106] First, the design unit 111 generates a configuration path and a component path (step F11). Details of step F11 will be described later with reference to FIG.

[0107] Next, the training data generation unit 112 determines the initial value of the update candidate reward (step F12). Note that step F12 will be described in detail later.

[0108] Next, the training data generating unit 112 updates the reward for each system configuration in the configuration path (step F13). Details of step F13 will be described later with reference to FIG.

[0109] Next, the learning data generation unit 112 determines the reward for each system configuration in the configuration path and each component configuration in the component path, and then stores the learning data in the storage device 20 (step F14). Details of step F14 will be described later with reference to FIG. 17.

[0110] Next, the learning unit 113 executes learning (step F15), which will be described in detail later.

[0111] Then, the processes of steps F11 to F15 are repeated during a preset learning period (step F16), which will be described in detail later.

[0112] The operation of generating a configuration path and a component path (step F11) will now be described: Fig. 11 is a diagram for explaining an example of the operation for generating a configuration path and a component path.

[0113] First, the design unit 111 sets the system requirements as the current configuration (step F111). Next, the design unit 111 registers the current configuration as the root node of the search tree (step F112). Specifically, the design unit 111 stores system requirement identification information for identifying the current configuration (system requirements) as the root node in the search tree information.

[0114] 12 is a diagram illustrating an example of the data structure of search tree information. In the example of Fig. 12, system requirement identification information "R1" associated with system requirement R1 stored in storage device 20 is stored in the "parent node" of search tree information 121, and further, information indicating that system requirement R1 is the root node is stored in the "root node." In the example of Fig. 12, "1" is stored as the information indicating that it is the root node.

[0115] Fig. 13 is a diagram for explaining an example of a search tree. The search tree can be represented by a graph (search tree T1) as shown in Fig. 13. The root node (system requirement R1) shown in Fig. 12 corresponds to R1 in Fig. 13.

[0116] Next, the design unit 111 selects a concretization rule using the current first learning model, executes a concretization process using the selected concretization rule, and concretizes the component configuration included in the current configuration (step F113). Next, the design unit 111 sets the configuration concretized in step F113 (system configuration proposal) as the next configuration (step F114).

[0117] Next, if the next configuration (specific configuration (proposed system configuration)) is not stored in the search tree information (step F115: No), the design unit 111 proceeds to processing in step F116. Also, if the next configuration (specific configuration (proposed system configuration)) is stored in the search tree information (step F115: Yes), the design unit 111 proceeds to processing in step F117.

[0118] Next, the design unit 111 associates the current configuration with the next configuration and the concretized component configuration (the concrete component configuration of the concretization rule) as directed edges, and stores them in the search tree information (step F116), with the node representing the current configuration as the parent node, the next configuration (the concretized component configuration) as the child node, and the edge representing the concretized component configuration (the concrete component configuration of the concretization rule) as a directed edge.

[0119] For example, if the current configuration is a system configuration proposal R2 generated from system requirement R1, as shown in FIG. 12, the system configuration proposal identification information "R1" associated with system requirement R1 in search tree information 121, the system configuration proposal identification information "R2" associated with system configuration proposal R2 generated by the concretization process, and the concretization rule identification information "Rule1" associated with the concretization rule used in the concretization process are stored in association with each other.

[0120] Furthermore, when the current configuration is a system specific configuration R5 generated from a system configuration proposal R2, as shown in FIG. 12, the system configuration proposal identification information "R2" of the search tree information 121, the system specific configuration identification information "R5" associated with the system specific configuration generated by the concretization process, and the concretization rule identification information "Rule4" associated with the concretization rule used in the concretization process are stored in association with each other.

[0121] Next, the design unit 111 sets the next configuration as the current configuration (step F117). Next, if there is no instantiation rule that can be applied to the current configuration (step F118: No), the design unit 111 proceeds to the processing of step F119. Note that if the current configuration is a system concrete configuration, the instantiation rule cannot be applied. Furthermore, if there is an instantiation rule that can be applied to the current configuration (step F118: Yes), the design unit 111 repeats the processing of steps F113 to F117.

[0122] Next, the design unit 111 generates a path (configuration path information (configuration path) that stores the configurations that have resulted in the current configuration in chronological order) from the system configurations (system requirements, system configuration proposal, specific system configuration) that emerged in the processing of steps F111 to F118 described above to the path from the system requirements to the generation of the current specific system configuration (step F119).

[0123] Fig. 14 is a diagram illustrating an example of the data structure of a configuration path. In the example of Fig. 14, the configuration path CP1 is represented in the order of system requirement "R1", system configuration plan "R2", and specific system configuration "R5", as shown in Figs. 12 and 13.

[0124] Next, the design unit 111 stores the abstract component configurations realized in step F113 in chronological order to generate component path information (component path) (step F11A).

[0125] Fig. 15 is a diagram illustrating an example of the data structure of a part path. If we consider Fig. 13 (R1-R2-R5) to correspond to Fig. 1 (G1-G2-G5), the abstract part realized by the conversion from R1 to R2 is edge "E1," and the abstract part realized by the conversion from R2 to R5 is node "N4," so the part path is expressed as PP1 shown in Fig. 15.

[0126] In the embodiment, a method for learning the evaluation value (likelihood) for each component is described as an example, but it is not necessary to learn the evaluation value (likelihood) for each component. For example, the evaluation value for the entire system configuration may be learned. In this case, the edge registered in the processing of step F116 does not represent a specific component. Furthermore, since the component path PP1 is unnecessary, the processing of step F11A is not necessary.

[0127] The operation for determining the initial value of the reward for the update candidate (step F12) will be described. First, if the last configuration in the configuration path is a specific system configuration, the learning data generation unit 112 sets the initial value of the reward for the update candidate, for example, to "1" for the reward information representing the reward for that specific system configuration, and if it is not a specific system configuration, for example, to "0" for the reward information representing the reward corresponding to that specific system configuration.

[0128] The update candidate reward is a value used when updating the reward value obtained for each system configuration of the configuration path in step F13. This is the reward value that was found to be able to obtain the system configuration by the processing in the immediately preceding step F11.

[0129] In the example of Figure 14, since the last configuration of configuration path CP1 is system specific configuration R5, in the processing of step F132, reward information "1" is associated with "R5" representing the system specific configuration of configuration path CP1.

[0130] Next, if the last configuration in the configuration path is a specific system configuration, the learning data generation unit 112 sets the specific system configuration as a performance measurement target.

[0131] In the example of Figure 14, since the last configuration of configuration path CP1 is system specific configuration R5, system configuration identification information "R5" representing system specific configuration R5 associated with system specific configuration R5 is stored in the performance measurement target configuration list.

[0132] The operation for updating the reward information (step F13) will now be described. Fig. 16 is a diagram for explaining an example of the operation for updating the reward information. First, the training data generation unit 112 sets the last configuration of the configuration path as the configuration to be updated (step F131).

[0133] Next, the learning data generation unit 112 compares the reward associated with the configuration to be updated with the reward of the update candidate, selects the larger reward, and stores the selected reward in association with the configuration to be updated (step F132).

[0134] Specifically, in step F132, the reward for the update candidate is determined by comparing the reward associated with the configuration to be updated with the reward for the update candidate, and if the former reward does not yet exist (is not associated) before the comparison, it is assumed to be "0." After the comparison, the larger of the two is updated as the reward associated with the configuration to be updated and the reward for the update candidate. The configuration to be updated is then updated, and this process is repeated.

[0135] For example, since no reward is initially associated with any configuration, in the example of Figure 14, "R5" is initially set as the update candidate configuration in step F131, and since no reward is yet associated with it, its value is considered to be "0". Since the update candidate reward is initialized to "1" in step F12, "0" and "1" are compared, and since "1" is greater, a reward of "1" is associated with "R5". Next, the update candidate configuration is set to "R2", and the same process as described above is repeated.

[0136] Next, the training data generation unit 112 sets the reward selected in step F132 (the larger of the two) as the reward for the update candidate (step F133). Subsequently, for example, if a reward of "2" is associated with "R2," the "2" associated with "R2" is compared with the update candidate reward of "1." Since "2" is larger, the reward "2" is associated with "R2" (no substantial change), and the update candidate reward is changed to "2." After that, the configuration of the update candidate becomes "R1," and the above-described process is repeated.

[0137] Next, if the configuration to be updated is not the first configuration in the configuration path (step F134: No), the learning data generation unit 112 sets the configuration immediately before the configuration to be updated in the configuration path as the configuration to be updated (step F135) and proceeds to processing of step F132.

[0138] Furthermore, if the configuration to be updated is the first configuration in the configuration path (step F134: Yes), the learning data generation unit 112 ends the processing of step F13.

[0139] Specifically, in the process of step F13, data (reward) is generated from the design performed in step F11 based on the evaluation value of the final design configuration "R5" to learn the evaluation values ​​of the configurations "R2" and "R1" in the design process. At this time, if larger data (reward) has been obtained in the past, it is given priority, so the larger data is compared with the reward stored in association with the configuration, and the larger is retained.

[0140] The reason why the larger one is kept and propagated upwards ("R1" from the perspective of "R2") is because it is known that it is possible to transition from "R1" to "R2". What we want to learn is the expected reward to be obtained by continuing to select the best choice, and since it is known that it is possible to transition from "R1" to "R2" by applying the appropriate concretization rule, if the reward associated with "R2" is larger, it should be propagated to "R1" in preference to the reward of "R5".

[0141] It should be noted that a transition from "R1" to "R2" does not necessarily occur, but there is a possibility of this happening. For example, in the example of Figure 13, there is also the possibility of transition to "R3" or "R4". However, the automatic design function can choose which transition to make, so the larger reward is propagated upwards.

[0142] The operation for determining a reward and generating training data (step F14) will now be described. Fig. 17 is a diagram for explaining an example of the operation for determining a reward and generating training data. First, the training data generation unit 112 sets the first configuration of the configuration path as the configuration to be subjected to reward determination (step F141).

[0143] In the example of FIG. 14, the first configuration in the configuration path CP1 stores "R1" representing the system requirement R1, so the system requirement R1 is set as the configuration for which the remuneration is determined.

[0144] Next, the learning data generation unit 112 sets the first component configuration in the component path as the component configuration for which remuneration is to be determined (step F142).

[0145] In the example of FIG. 15, the first component configuration in the component path PP1 stores "E1" which represents an abstract component, and therefore the component "E1" is set as the component configuration for which the remuneration is determined.

[0146] Next, the learning data generation unit 112 detects all directed edges that represent the component configuration of the reward determination target among directed edges that have the reward determination target system configuration as their parent node (starting point) (step F143).

[0147] In the example of Fig. 13, the configuration for which compensation is determined is system requirement R1, so a directed edge representing the component configuration for which compensation is determined is detected. Note that, although there is one directed edge in the example of Fig. 13, multiple directed edges may be detected in examples other than the example of Fig. 13.

[0148] The learning data generation unit 112 determines the maximum reward among the rewards related to the functional requirements stored in association with the child nodes (end points) corresponding to each of the directed edges detected in step F143 as the final reward (step F144).

[0149] The learning data generation unit 112 associates the configuration of the remuneration determination target, the parts configuration of the remuneration determination target, and the determined remuneration, and stores them in the storage device 20 as first learning data (step F145).

[0150] 18 is a diagram illustrating an example of the data structure of the first learning data. Learning data 181 in FIG. 18 represents the data structure of learning data generated based on the above-described CP1 and PP1.

[0151] The fixed remuneration is the current evaluation value (likelihood) that the system configuration will satisfy the functional requirements when the component configuration for which the remuneration is fixed, which is included in the configuration for which the remuneration is fixed, is realized.

[0152] What we want to learn here is a quantitative indicator that shows the likelihood of reaching a specific configuration after concretizing a specific component of the configuration. Therefore, the fixed reward is part of the training data used to learn that indicator, and is also the provisional value of the indicator at the current time. It can also be thought of as an appropriately named variable used in the process of generating the training data. Note that all of the fixed rewards mentioned above represent that variable.

[0153] If the component configuration for which remuneration is to be determined is not the last component configuration in the component path (step F146: No), the learning data generation unit 112 sets the component configuration immediately following the current component configuration for which remuneration is to be determined in the component path as the component configuration for which remuneration is to be determined (step F147), and sets the configuration immediately following the current component configuration for which remuneration is to be determined in the configuration path as the configuration for which remuneration is to be determined (step F148), and then proceeds to processing in step F143.

[0154] If it is the last component configuration (step F146: Yes), the learning data generation unit 112 ends the processing of step F14.

[0155] If the part path is empty at the start of step F14, step F14 is skipped.

[0156] It should be noted that the processing related to the component path described above does not need to be executed. In this case, the processing of step F142 is unnecessary. The processing of step F143 is also unnecessary. In the processing of step F144, the reward related to the functional requirement recorded in the node representing the configuration of the configuration for which the reward is to be determined is set as the final reward. In step F145, the configuration for which the reward is to be determined and the final reward are associated with each other and stored in the storage device 20 as first learning data.

[0157] 19 is a diagram illustrating an example of the data structure of the learning data. Learning data 191 in FIG. 19 represents the data structure of the learning data generated based on the above-described CP1.

[0158] Also, since the processing of step F147 is unnecessary, in step F146, it is determined whether the configuration to be determined as a reward is not the last configuration in the configuration path, and if it is not the last configuration, the processing proceeds to step F148, and if the configuration to be determined as a reward is the last configuration in the configuration path, the processing of step F14 is terminated.

[0159] The operation of learning (step F15) will be described. When a configuration of a reward determination target included in the first learning data is input to the first learning model, the learning unit 113 executes learning to correct an error in the output of the first learning model so that an evaluation value output for the parts configuration of a reward determination target included in the first learning data approaches the value of the determined reward included in the first learning data.

[0160] A specific example of the operation of step F15 will be described below. The first learning model is a GNN (Graph Neural Network) that receives graph information in which each node and edge in the graph and the graph itself have attribute values ​​as input, and outputs graph information in a similar format.

[0161] One data item D1 is selected from the learning data, and a graph representing the reward determination target (configuration) included in the data D1 is input to the first learning model. As a result, the graph information output from the first learning model is designated as OG1.

[0162] In OG1, the attribute value of a node or edge corresponding to the parts configuration (parts) for which a reward is determined in data D1 is defined as PV1. The pair of PV1 and the determined reward included in data D1 is defined as VP1.

[0163] The VP1 generated for all data included in the training data is called VPS1. For each pair included in VPS1, the mean square error between the attribute value and the fixed reward is used as a loss function, and the first learning model is trained to minimize this loss function.

[0164] The following is an example of a more specific operation of step F15 when a component path is not generated. The first learning model is a GNN that receives graph information having attribute values ​​for each node and edge in the graph as input and outputs graph information in a similar format.

[0165] One data item D2 is selected from the learning data, and graph information representing the reward determination target (configuration) included in data D1 is input to the first learning model. As a result, the graph information output from the first learning model is designated as OG2.

[0166] In OG2, the attribute value of the graph itself is defined as PV2. The pair of PV2 and the fixed reward included in data D2 is defined as VP2. VPS2 is the product of generating this VP1 for all data included in the training data. For each pair included in VPS1, the mean squared error between the attribute value and the fixed reward is defined as a loss function, and the first learning model is trained to minimize this loss function.

[0167] The operation of performance measurement (step S13) will now be described. Fig. 20 is a diagram for explaining an example of the operation of performance measurement. First, the performance measurement unit 12 determines whether or not there is a performance measurement target (step S131).

[0168] Specifically, if the performance measurement target configuration list stores system configuration identification information representing a specific system configuration associated with the specific system configuration (until the performance measurement target configuration list becomes empty), the performance measurement unit 12 executes the processing of steps S132 to S135.

[0169] If the system configuration identification information is not stored in the performance measurement target configuration list (if the performance measurement target configuration list is empty), the performance measurement unit 12 waits until the configuration identification information is stored in the performance measurement target configuration list.

[0170] Next, the performance measurement unit 12 selects a specific system configuration to be used in performance measurement from the performance measurement target configuration list (step S132). The selection may be, for example, in the order in which the configurations were added to the performance measurement target configuration list. However, the selection is not limited to the above-mentioned selection, and may be random.

[0171] Next, the performance measurement unit 12 constructs a measurement system, which is a measurement environment, based on the specific system configuration selected in step S132 (step S133). The construction of the measurement system selected in step S133 uses, for example, a tool for automatically constructing a measurement system. As the tool, for example, Ansible (registered trademark), a configuration management tool, or a platform, is used. As the platform, for example, AWS (Amazon Web Services) (registered trademark) is used.

[0172] Next, the performance measurement unit 12 executes a performance measurement process for the measurement system constructed in step S133 to obtain performance data of the measurement system (step S134). For performance measurement, the type of performance to be measured may be set in advance or may be input separately.

[0173] As an example of performance measurement, communication bandwidth will be described below. For measuring communication bandwidth, for example, iPerf (registered trademark), which is a tool for measuring and tuning network performance, is used.

[0174] First, iPerf is installed on the information processing devices PC1 and PC2 at both ends of the communication whose bandwidth you want to measure. Then, one of the information processing devices PC1 is started in server mode and the other information processing device PC2 is started in client mode, thereby measuring the bandwidth of the communication.

[0175] Furthermore, the communication delay is measured using software such as ping. Ping is software that is pre-installed in operating systems (OSs) such as Windows (registered trademark) and Linux (registered trademark). Of the information processing devices PC1 and PC2 at both ends of the communication for which the delay is to be measured, ping is executed from the information processing device PC1 to the information processing device PC2 as the destination, thereby measuring the time required for the communication to travel round trip, i.e., the communication delay.

[0176] However, the above-described performance measurement is merely an example, and any method that can quantitatively evaluate performance is not limited to the above-described performance measurement. Furthermore, the measured performance may be something other than communication bandwidth and communication delay. In such cases, an appropriate measurement method is adopted depending on the type of performance to be measured.

[0177] Next, the performance measurement unit 12 stores performance information in the storage device 20, which associates system configuration identification information indicating the specific system configuration with the performance data obtained by the performance measurement process in step S134 (step S135). Next, when step S135 is completed, the performance measurement unit 12 proceeds to the process of step S131.

[0178] If the performance of the specific system configuration selected in step S132 has already been measured, the processes from step S133 to step S135 may be skipped.

[0179] Furthermore, whether or not the performance of the specific system configuration selected in step S132 has already been measured is determined, for example, by determining whether or not performance information of the same specific system configuration is stored in the storage device 20.

[0180] Furthermore, while the process of step S12 is being executed, the process of step S13 can be executed (steps S12 and S13 can be executed in parallel).

[0181] Furthermore, when the process of step S12 is completed, if step S13 is waiting at step S131, the process of step S13 is not executed.

[0182] The operation of the non-functional requirement learning unit 13 (step S14) will now be described. FIG. 21 is a diagram for explaining an example of the operation of the learning unit. First, the non-functional requirement learning unit 13 uses the system requirements and performance information to perform reinforcement learning on the non-functional requirements during a preset learning period (step S141). Details of step S141 will be described later with reference to FIG. 22.

[0183] The learning period may be, for example, the learning time, the number of learning iterations, etc. The learning period is determined, for example, by experiments, simulations, etc. When a neural network is used for reinforcement learning, the number of learning iterations is the number of times the neural network weights are updated.

[0184] Next, the non-functional requirement learning unit 13 uses the current second learning model to estimate the performance of one or more specific system configurations generated based on the system requirements (step S142).

[0185] Next, if the non-functional requirement learning unit 13 determines based on the result of step S142 (performance estimation result) that the learning of the non-functional requirements is sufficient (step S143: Yes), it ends the processing of step S14. If the learning of the non-functional requirements is determined to be insufficient (step S143: No), it repeats the processing of steps S141 and S142 until it determines that the learning of the non-functional requirements is sufficient.

[0186] The determination in S143 may be, for example, based on whether or not the average error of the performance estimation result is equal to or less than a preset threshold C, or based on whether or not the likelihood or log-likelihood of the performance estimation result is equal to or greater than a preset threshold D. However, the determination in S143 is not limited to the above-described determination.

[0187] The performance estimation result refers to an attribute value representing the performance value of a specific component of a specific configuration, which is included in a graph output as a result of inputting a graph representing the configuration into a second learning model when estimating the performance of the component. The judgment in step S143 is performed using the error between the attribute value and the performance value obtained by actually measuring the performance of the component. The thresholds C and D may be determined in any way that can determine that the accuracy of the performance estimation is sufficiently high. For example, the threshold C may be set to 10% and the threshold D may be set to 0.001.

[0188] The operation of learning non-functional requirements (step S141) will now be described: Fig. 22 is a diagram for explaining an example of the operation of learning non-functional requirements.

[0189] First, the design unit 131 generates a configuration path and a component path (step N11). Details of step N11 will be described later with reference to FIG.

[0190] Next, the training data generating unit 132 determines the value of the reward (step N12). Details of step N12 will be described later.

[0191] Next, the learning data generation unit 132 determines the reward for each system configuration in the configuration path and each component configuration in the component path, and then stores the learning data in the storage device 20 (step N13). Details of step N13 will be described later with reference to FIG. 24.

[0192] Next, the learning unit 133 executes learning (step N14). Details of step N14 will be described later.

[0193] Then, the processes of steps N11 to N14 are repeated during a preset learning period (step N15).

[0194] The appropriate period is preferably based on the learning time or the number of learning times (for example, in the case of reinforcement learning using a neural network, the number of updates of the weights of the neural network), but is not limited to these.

[0195] The operation of generating a configuration path and a component path (step N11) will now be described: Fig. 23 is a diagram for explaining an example of the operation for generating a configuration path and a component path.

[0196] First, the design unit 131 sets the system requirements as the current configuration (step N111). Next, the design unit 131 refers to the search tree information at the time when the processing of step S12 is completed, and selects one from one or more concatenation rules (directed edges) associated with the system requirements (parent node) that is the root node (step N112).

[0197] 12, one directed edge is selected from the directed edges "Rule1," "Rule2," and "Rule3" that represent system configuration plans and are associated with "R1," which represents system requirement R1 and is the root node and parent node of search tree information 121. In the example of Fig. 13, one directed edge is selected from the multiple directed edges Rule1 to Rule3 that are associated with root node R1 (parent node).

[0198] Next, the design unit 131 selects a system configuration plan (child node) associated with the concretization rule (directed edge) selected in step N112, and sets the selected system configuration plan as the current configuration (step N113).

[0199] Next, if there is a directed edge departing from a node in the search tree representing the current configuration (Step N114: Yes), the design unit 131 repeats the processing of Steps N112 to N113. If there is no directed edge departing from a node in the search tree representing the current configuration (Step N114: No), the design unit 131 proceeds to the processing of Step N115.

[0200] Next, the design unit 131 generates configuration path information (configuration path) by storing the configurations that have emerged in the processing of steps N111 to N114 described above (system requirements, system configuration proposal, specific system configuration) from the system requirements to the generation of the current specific system configuration (configuration path information is generated by storing the configurations that have previously become the current configuration in chronological order) (step N115).

[0201] Next, the design unit 131 stores the component configuration realized in the above-mentioned step N112 in chronological order and generates component path information (component path) (step N116).

[0202] In the embodiment, a method of learning the evaluation value (likelihood) for each component is described as an example, but it is not necessary to learn the evaluation value (likelihood) for each component. For example, the evaluation value for the entire system configuration may be learned. In this case, the edge registered in the processing of step N112 does not represent a specific component. Furthermore, since a component path is not required, the processing of step N116 is not required.

[0203] Furthermore, since the processes of the design unit 111 and the design unit 131 have equivalent functions, the processes of the design unit 131 may be performed by the design unit 111. In this way, the design unit 131 can be eliminated.

[0204] The operation for determining the reward information (step N12) will be described. The learning data generation unit 132 refers to the performance information, acquires performance data corresponding to the last configuration of the configuration path, and determines a reward based on the value of the acquired performance data.

[0205] Basically, the reward is simply the performance value itself. For example, if the bandwidth is 100 Mbps, the reward is set to 100. However, the unit to be used for each performance value is determined in advance (for example, based on frequency of use). For example, if it is decided to use Mbps as the unit of bandwidth, 1 Gbps (gigabit per second; the same applies below) is 1000 Mbps, so the reward is set to 1000. Furthermore, since it is more convenient for the value to be learned to have a small scale, the reward may be a value obtained by logarithmically transforming the performance value.

[0206] Rewards may be provided for each type of non-functional requirement, such as bandwidth or delay, or may be combined into one unified reward.

[0207] When providing rewards for each type of non-functional requirement, the value of the performance data may be used as the reward (reward determination method 1). Also, for performance where the larger the value, the better the reward, the reward for the corresponding non-functional requirement may be the value of the performance data, and for performance where the smaller the value, the better the reward, the reward for the corresponding non-functional requirement may be the reciprocal of the value of the performance (reward determination method 2).

[0208] Furthermore, when consolidating into a single unified reward, it is preferable to use a value obtained by adding together the rewards for each type of non-functional requirement determined by reward determination method 2 with appropriate weighting.

[0209] The operation for generating learning data (step N13) will now be described. Fig. 24 is a diagram for explaining an example of the operation for generating learning data. First, the learning data generation unit 132 sets the first configuration of the configuration path generated in the processing of step N11 as the configuration to be stored as learning data (the configuration to be stored as second learning data) (step N131).

[0210] Next, the learning data generation unit 132 sets the first component configuration in the component path as the component configuration to be stored as learning data (the component configuration to be stored as second learning data) (step N132).

[0211] Next, the learning data generation unit 132 associates the configuration of the learning data storage target, the parts configuration of the learning data storage target, and the reward determined in step N13, and stores them as second learning data in the storage device 20 (step N133).

[0212] 25 is a diagram illustrating an example of the data structure of the second learning data. The example of learning data 251 in FIG. 25 represents the data structure of learning data generated based on a configuration path, a component path, a bandwidth reward, and a delay reward.

[0213] The reward is the current evaluation value (likelihood) of the performance that the specific system configuration will exhibit when the component configuration of the above-mentioned target, which is included in the above-mentioned target configuration, is realized.

[0214] What we want to learn here is a quantitative index or its probability density function that indicates the likelihood of the performance that will be obtained after implementing a specific component of the configuration. The reward is part of the training data used to learn the index, and is also the obtained performance data itself. It can also be thought of as appropriately named variables used in the process of generating the training data. All of the rewards mentioned above represent these variables.

[0215] Next, if the component configuration for which learning data is to be stored in step N131 is not the last component configuration in the component path (step N134: No), the learning data generation unit 132 sets the component configuration immediately following the current component configuration for which learning data is to be stored in the component path as the component for which learning data is to be stored (step N135), and sets the configuration immediately following the current configuration for which learning data is to be stored in the configuration path as the configuration for which learning data is to be stored (step N136), and then proceeds to the processing of step N133.

[0216] If it is the last component configuration (step N134: Yes), the learning data generating unit 132 ends the process of step N13.

[0217] Note that the processing related to the component path described above does not have to be executed. In that case, the processing of step N132 is unnecessary. Furthermore, in the processing of step N133, the configuration to be stored as learning data is associated with the reward determined in the processing of step N13, and the associated configuration is stored in the storage device 20 as second learning data.

[0218] 26 is a diagram illustrating an example of the data structure of the second learning data. The example of learning data 261 in FIG. 26 represents the data structure of learning data generated based on the configuration path, the bandwidth reward, and the delay reward.

[0219] In addition, in the processing of step N134, it is determined whether the configuration for which learning data is to be stored is not the last configuration in the configuration path, and if it is not the last configuration, the processing proceeds to step N136, and if it is the last configuration, the processing of step N13 is terminated and the processing proceeds to step N14.

[0220] The operation of learning (step N14) will be described in detail. When the configuration of the learning data storage target included in the second learning data is input to the second learning model, the learning unit 133 executes learning to correct an error in the output of the second learning model so that the evaluation value output for the parts configuration included in the second learning data approaches the reward value included in the second learning data.

[0221] A more specific example of the operation of step N14 will be given below. The second learning model is a GNN that receives graph information in which each node and edge in the graph and the graph itself have attribute values ​​as input, and outputs a graph in a similar format.

[0222] A single piece of data D3 is selected from the training data, and graph information representing the configuration contained in data D3 is input to a second training model. The resulting graph information output from the second training model is designated OG3. The attribute value of a node or edge in OG3 corresponding to the component configuration (component) of data D3 is designated PV3.

[0223] The pair of PV3 and the reward included in data D3 is called VP3. The VP3 generated for all data included in the training data is called VPS3. For each pair included in VPS3, the mean squared error between the attribute value and the reward is used as a loss function, and a second learning model is trained to minimize this loss function.

[0224] The following is an example of a more specific operation of step N14 when a component path is not generated. The second learning model is a GNN that receives graph information in which each node and edge in the graph and the graph itself have attribute values ​​as input, and outputs graph information in a similar format.

[0225] A single piece of data D4 is selected from the training data, and graph information representing the structure contained in data D4 is input to the second training model. The resulting graph information output from the second training model is designated OG4. The attribute value of the graph itself in OG4 is designated PV4. The pair of PV4 and the reward contained in data D4 is designated VP4.

[0226] The VP4 generated for all data included in the training data is called VPS4. For each pair included in VPS4, the mean squared error between the attribute value and the reward is used as a loss function, and a second learning model is trained to minimize this loss function.

[0227] As an example of processing different from the processing in step N14 described above, a probability density function of rewards related to non-functional requirements may be learned. In this case, the following processing is performed using the second learning data stored in step N13.

[0228] When a configuration included in the second learning data is input to the second learning model, learning may be performed to correct the parameters of the probability density function so that the probability density function based on the parameters of the probability density function output for the component configuration included in the second learning data has a higher likelihood with respect to the reward value included in the learning data.

[0229] For example, when it is assumed that the probability density function of the reward follows a Gaussian mixture distribution, the parameters of the probability density function are the mean value μ, variance Σ, and mixing coefficient π of each Gaussian distribution constituting the Gaussian mixture distribution. The above example is a typical example, and is not limited to the above example.

[0230] The method of correcting the parameters of the probability density function so as to increase the likelihood of the probability density function is preferably, for example, to apply the EM algorithm, although it is not limited to the EM algorithm.

[0231] Effects of the Embodiment As described above, according to the embodiment, learning regarding functional requirements and non-functional requirements is separated, and learning regarding functional requirements is performed first, and then learning regarding non-functional requirements is performed.

[0232] By first learning only about the functional requirements, you can learn about the functional requirements efficiently without having to wait for performance measurements.

[0233] The specific system configuration discovered during learning about functional requirements can be measured for performance in parallel with the learning, thereby saving time.

[0234] As learning about functional requirements progresses, the frequency of discovering specific configurations increases, which in turn increases measurement efficiency, thereby shortening the time required for learning.

[0235] It can be applied to reinforcement learning aimed at acquiring efficient procedures for intellectual tasks such as the design process of ICT systems.

[0236] [Program] The program in the embodiment may be a program that causes a computer to execute steps S11 to S14 shown in Fig. 8. By installing and executing this program on a computer, the system design learning device and system design learning method in the embodiment can be realized. In this case, the processor of the computer functions as a functional requirement learning unit 11, a performance measurement unit 12, a non-functional requirement learning unit 13, a learning control unit 14, and an output information generation unit 15, and performs processing.

[0237] The program in the embodiment may be executed by a computer system constructed by a plurality of computers, in which case, for example, each computer may function as one of the functional requirement learning unit 11, the performance measurement unit 12, the non-functional requirement learning unit 13, the learning control unit 14, and the output information generation unit 15.

[0238] [Physical Configuration] A computer that realizes a system design learning device by executing a program in the embodiment will now be described with reference to Fig. 27. Fig. 27 is a diagram illustrating an example of a computer that realizes a system design learning device.

[0239] 27 , the computer 230 includes a CPU (Central Processing Unit) 231, a main memory 232, a storage device 233, an input interface 234, a display controller 235, a data reader / writer 236, and a communication interface 237. These components are connected to each other via a bus 241 so as to be able to communicate data with each other. Note that the computer 230 may include a GPU or an FPGA in addition to or instead of the CPU 231.

[0240] The CPU 231 loads the programs (codes) in the embodiment stored in the storage device 233 into the main memory 232 and executes them in a predetermined order to perform various calculations. The main memory 232 is typically a volatile storage device such as a DRAM (Dynamic Random Access Memory). The programs in the embodiment are provided in a state stored in a computer-readable recording medium 240. The programs in the embodiment may be distributed over the Internet connected via a communication interface 237. The recording medium 240 is a non-volatile recording medium.

[0241] Specific examples of the storage device 233 include a hard disk drive and a semiconductor storage device such as a flash memory. The input interface 234 mediates data transmission between the CPU 231 and input devices 238 such as a keyboard and a mouse. The display controller 235 is connected to a display device 239 and controls the display on the display device 239.

[0242] The data reader / writer 236 mediates data transmission between the CPU 231 and the recording medium 120, reads programs from the recording medium 120, and writes processing results from the computer 230 to the recording medium 240. The communication interface 237 mediates data transmission between the CPU 231 and other computers.

[0243] Specific examples of the recording medium 240 include general-purpose semiconductor storage devices such as CF (Compact Flash (registered trademark)) and SD (Secure Digital), magnetic recording media such as flexible disks, or optical recording media such as CD-ROMs (Compact Disk Read Only Memory).

[0244] The system design learning device in the embodiment can be realized by using hardware corresponding to each part, rather than a computer on which a program is installed. Furthermore, the system design learning device may be realized in part by a program and in the remaining part by hardware.

[0245] [Supplementary Note] The following supplementary note is further disclosed regarding the above-described embodiment. Part or all of the above-described embodiment can be expressed by (Supplementary Note 1) to (Supplementary Note 15) described below, but is not limited to the following description.

[0246] (Supplementary Note 1) A system design learning device comprising: a functional requirements learning unit that learns about a first learning model that executes a concretization process to convert abstract parts into concrete parts of system requirements or system configuration proposals to be concretized, the system requirements or the system configuration proposals being information representing the configuration of the system including abstract parts, so that the system requirements or the system configuration proposals satisfy the functional requirements of the system and output an evaluation value representing the likelihood of being converted into a specific system configuration, which is information representing the configuration of the system that does not include abstract parts; a performance measurement unit that, when the specific system configuration is generated by executing the concretization process during learning by the functional requirements learning unit, constructs a measurement system as a measurement environment based on the specific system configuration, executes performance measurement processing using the measurement system for preset performance, and stores performance data resulting from the performance measurement processing in a storage device; and a non-functional requirements learning unit that learns about a second learning model that uses the performance data corresponding to the specific system configuration measured by the performance measurement unit to output an evaluation value representing the likelihood of the specific system configuration being able to perform in a manner that satisfies non-functional requirements.

[0247] (Supplementary Note 2) The system design learning device described in Supplementary Note 1, wherein the functional requirement learning unit generates configuration path information using the system requirements, the system configuration proposal, and the specific system configuration used until the specific system configuration is generated from the system requirements, and generates first learning data by associating a reward with each of the system requirements, the system configuration proposal, and the specific system configuration included in the configuration path information.

[0248] (Supplementary Note 3) The system design learning device described in Supplementary Note 1, wherein the functional requirement learning unit generates component path information using the abstract parts that were converted when the system requirements and the system configuration plan were concretized and that were used until the specific system configuration was generated from the system requirements, and generates first learning data by associating a reward for each of the performance data with the abstract parts that correspond to the system requirements and the abstract parts that correspond to the system configuration plan, which are included in the component path information.

[0249] (Supplementary Note 4) The system design learning device described in Supplementary Note 1, wherein the non-functional requirements learning unit generates configuration path information using the system requirements, the system configuration proposal, and the specific system configuration used until the specific system configuration is generated from the system requirements, and generates second learning data by associating a reward with each of the system requirements, the system configuration proposal, and the specific system configuration included in the configuration path information.

[0250] (Supplementary Note 5) The system design learning device described in Supplementary Note 1, wherein the non-functional requirements learning unit generates component path information using the abstract parts that were used until the specific system configuration was generated from the system requirements and that were converted when the system requirements and the system configuration plan were concretized, and generates second learning data by associating a reward for each of the performance data with the abstract parts that correspond to the system requirements and the abstract parts that correspond to the system configuration plan, which are included in the component path information.

[0251] (Supplementary Note 6) A system design learning method comprising: a functional requirements learning step in which a computer learns a first learning model that executes a concretization process for converting abstract parts into concrete parts of system requirements or system configuration proposals to be concretized, the system requirements or the system configuration proposal being information representing the configuration of the system including abstract parts, so that the system requirements or the system configuration proposal satisfies the functional requirements of the system and outputs an evaluation value representing the likelihood of being converted into a specific system configuration, which is information representing the configuration of the system not including abstract parts; a performance measurement step in which, if the specific system configuration is generated by executing the concretization process during learning, the functional requirements learning step constructs a measurement system, which is a measurement environment, based on the specific system configuration, executes performance measurement processing using the measurement system for preset performance, and stores performance data resulting from the performance measurement processing in a storage device; and a non-functional requirements learning step in which the performance measurement step uses the performance data corresponding to the measured specific system configuration to learn a second learning model that outputs an evaluation value representing the likelihood of the specific system configuration being able to perform in a manner that satisfies non-functional requirements.

[0252] (Supplementary Note 7) The system design learning method described in Supplementary Note 6, wherein the functional requirement learning step generates configuration path information using the system requirements, the system configuration proposal, and the specific system configuration used until the specific system configuration is generated from the system requirements, and generates first learning data by associating a reward with each of the system requirements, the system configuration proposal, and the specific system configuration included in the configuration path information.

[0253] (Supplementary Note 8) The system design learning method described in Supplementary Note 6, wherein the functional requirements learning step generates component path information using the abstract parts that were used until the specific system configuration was generated from the system requirements and that were converted when the system requirements and the system configuration plan were concretized, and generates first learning data by associating a reward for each of the performance data with the abstract parts that correspond to the system requirements and the abstract parts that correspond to the system configuration plan, which are included in the component path information.

[0254] (Supplementary Note 9) The system design learning method described in Supplementary Note 6, wherein the non-functional requirements learning step generates configuration path information using the system requirements, the system configuration proposal, and the specific system configuration used until the specific system configuration is generated from the system requirements, and generates second learning data by associating a reward with each of the system requirements, the system configuration proposal, and the specific system configuration included in the configuration path information.

[0255] (Supplementary Note 10) The system design learning method described in Supplementary Note 6, wherein the non-functional requirements learning step generates component path information using the abstract parts that were used until the specific system configuration was generated from the system requirements and that were converted when the system requirements and the system configuration plan were concretized, and generates second learning data by associating a reward for each of the performance data with the abstract parts that correspond to the system requirements and the abstract parts that correspond to the system configuration plan, which are included in the component path information.

[0256] (Supplementary Note 11) A computer-readable recording medium having a program recorded thereon, the program including instructions for causing a computer to execute: a functional requirements learning step in which a first learning model is learned that outputs an evaluation value representing the likelihood that a system requirement or a system configuration proposal to be concretized, which is information representing a system configuration including abstract parts, will satisfy the functional requirements of the system and will be converted into a specific system configuration, which is information representing the configuration of the system that does not include abstract parts, by executing a concretization process that converts abstract parts into concrete parts; a performance measurement step in which, when the specific system configuration is generated by executing the concretization process during learning, the functional requirements learning step constructs a measurement system, which is a measurement environment, based on the specific system configuration, executes a performance measurement process using the measurement system for preset performance, and stores performance data resulting from the performance measurement process in a storage device; and a non-functional requirements learning step in which the performance measurement step learns a second learning model that uses the performance data corresponding to the measured specific system configuration and outputs an evaluation value representing the likelihood that the specific system configuration will be able to perform in a manner that satisfies non-functional requirements.

[0257] (Appendix 12) A computer-readable recording medium having recorded thereon the program described in Appendix 11, wherein the functional requirement learning step generates configuration path information using the system requirements, the system configuration proposal, and the specific system configuration used until the specific system configuration is generated from the system requirements, and generates first learning data by associating a reward with each of the system requirements, the system configuration proposal, and the specific system configuration included in the configuration path information.

[0258] (Supplementary Note 13) A computer-readable recording medium having recorded thereon the program described in Supplementary Note 11, wherein the functional requirement learning step generates component path information using the abstract parts that were used until the specific system configuration was generated from the system requirements and that were converted when the system requirements and the system configuration plan were concretized, and generates first learning data by associating a reward for each of the performance data with each of the abstract parts that correspond to the system requirements and the abstract parts that correspond to the system configuration plan, which are included in the component path information.

[0259] (Appendix 14) A computer-readable recording medium having recorded thereon the program described in Appendix 11, wherein the non-functional requirements learning step generates configuration path information using the system requirements, the system configuration proposal, and the specific system configuration used until the specific system configuration is generated from the system requirements, and generates second learning data by associating a reward with each of the system requirements, the system configuration proposal, and the specific system configuration included in the configuration path information.

[0260] (Supplementary Note 15) A computer-readable recording medium having recorded thereon the program described in Supplementary Note 11, wherein the non-functional requirements learning step generates component path information using the abstract parts that were used until the specific system configuration was generated from the system requirements and that were converted when the system requirements and the system configuration plan were concretized, and generates second learning data by associating a reward for each of the performance data with the abstract parts that correspond to the system requirements and the abstract parts that correspond to the system configuration plan, which are included in the component path information.

[0261] Although the present invention has been described above with reference to the embodiments, the present invention is not limited to the above-described embodiments. Various modifications that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.

[0262] According to the above description, functional and non-functional requirements can be comprehensively learned, which is useful in fields where automatic design of ICT systems is required.

[0263] 10 System design learning device 11 Functional requirement learning unit 12 Performance measurement unit 13 Non-functional requirement learning unit 14 Learning control unit 15 Output information generation unit 20 Storage device 30 Input device 40 Output device 111 Design unit 112 Learning data generation unit 113 Learning unit 111, 131 Design unit 112, 132 Learning data generation unit 113, 133 Learning unit 230 Computer 231 CPU 232 Main memory 233 Storage device 234 Input interface 235 Display controller 236 Data reader / writer 237 Communication interface 238 Input device 239 Display device 240 Recording medium 241 Bus

Claims

1. a functional requirement learning means for learning about a first learning model that executes a concretization process for converting abstract parts into concrete parts of a system requirement or a system configuration plan to be concretized, the system requirement or the system configuration plan being information representing the configuration of the system including abstract parts, and outputs an evaluation value representing the likelihood that the system requirement or the system configuration plan will satisfy the functional requirements of the system and be converted into a system concrete configuration, which is information representing the configuration of the system not including abstract parts; a performance measurement means for constructing a measurement system, which is a measurement environment, based on the system specific configuration when the functional requirement learning means executes the instantiation process during learning, and for executing a performance measurement process for a performance set in advance using the measurement system, and for storing performance data, which is a result of the performance measurement process, in a storage device; a non-functional requirements learning means for learning a second learning model that uses the performance data corresponding to the specific system configuration measured by the performance measurement means to output an evaluation value representing a likelihood that the specific system configuration will be able to exhibit performance that satisfies the non-functional requirements; A system design learning device having the above configuration.

2. The functional requirement learning means generates configuration path information using the system requirement, the system configuration plan, and the specific system configuration used until the specific system configuration is generated from the system requirement, and generates first learning data by associating a reward with each of the system requirement, the system configuration plan, and the specific system configuration included in the configuration path information.

2. The system design learning device according to claim 1.

3. The functional requirement learning means generates part path information using the abstract parts that were converted when the system requirements and the system configuration plan were concretely used until the system specific configuration was generated from the system requirements, and generates first learning data by associating a reward for each of the performance data with the abstract parts corresponding to the system requirements and the abstract parts corresponding to the system configuration plan, which are included in the part path information.

2. The system design learning device according to claim 1.

4. The non-functional requirement learning means generates configuration path information using the system requirement, the system configuration plan, and the specific system configuration used until the specific system configuration is generated from the system requirement, and generates second learning data by associating a reward with each of the system requirement, the system configuration plan, and the specific system configuration included in the configuration path information.

2. The system design learning device according to claim 1.

5. The non-functional requirement learning means generates part path information using the abstract part that was used until the system specific configuration was generated from the system requirement and was converted when the system requirement and the system configuration plan were specified, and generates second learning data by associating a reward for each of the performance data with the abstract part corresponding to the system requirement and the abstract part corresponding to the system configuration plan, which are included in the part path information.

2. The system design learning device according to claim 1.

6. The computer a functional requirement learning step of learning about a first learning model that executes a concretization process for converting abstract parts into concrete parts of a system requirement or a system configuration plan to be concretized, the system requirement or the system configuration plan being information representing the configuration of the system including abstract parts, and outputs an evaluation value representing the likelihood that the system requirement or the system configuration plan will satisfy the functional requirements of the system and be further converted into a system concrete configuration, which is information representing the configuration of the system not including abstract parts; a performance measurement step of constructing a measurement system as a measurement environment based on the system specific configuration, when the system specific configuration is generated by executing the instantiation process during learning in the functional requirement learning step, executing a performance measurement process for a performance set in advance using the measurement system, and storing performance data as a result of the performance measurement process in a storage device; a non-functional requirements learning step of learning a second learning model that uses the performance data corresponding to the measured specific system configuration in the performance measurement step to output an evaluation value representing a likelihood that the specific system configuration can exhibit performance that satisfies the non-functional requirements; A learning method for system design that executes the above.

7. On the computer, a functional requirement learning step of learning about a first learning model that executes a concretization process for converting abstract parts into concrete parts of a system requirement or a system configuration plan to be concretized, the system requirement or the system configuration plan being information representing the configuration of the system including abstract parts, and outputs an evaluation value representing the likelihood that the system requirement or the system configuration plan will satisfy the functional requirements of the system and be further converted into a system concrete configuration, which is information representing the configuration of the system not including abstract parts; a performance measurement step of constructing a measurement system as a measurement environment based on the system specific configuration, when the system specific configuration is generated by executing the instantiation process during learning in the functional requirement learning step, executing a performance measurement process for a performance set in advance using the measurement system, and storing performance data as a result of the performance measurement process in a storage device; a non-functional requirements learning step of learning a second learning model that uses the performance data corresponding to the measured specific system configuration in the performance measurement step to output an evaluation value representing a likelihood that the specific system configuration can exhibit performance that satisfies the non-functional requirements; A program that contains instructions to execute a program.

Images