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

[Technical Field]

[0001] The present disclosure relates to a system design learning device and a system design learning method used in designing a system, as well as a program for realizing these. Mu Regarding. [Background technology]

[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 automated design process, the abstract parts included in the system requirements are concretized based on the concretization rules created in advance, and information representing the configuration of the ICT system in a deployable state (system concrete configuration) 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 the components or configurations that are determined to be actually used in the ICT system, while the abstract part represents the components or configurations whose functions are determined but whose actual use in the system is not yet determined.

[0007] As a related technique, Patent Document 1 discloses a system configuration derivation device that concretizes abstract elements in a stepwise manner 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 concretized in a stepwise manner using concretization rules, and a feasible specific system configuration is ultimately 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. [Prior art documents] [Patent documents]

[0015] [Patent Document 1] International Publication No. 2019 / 216082 [Non-patent literature]

[0016] [Non-Patent Document 1] 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. Summary of the Invention [Problem to be solved by the invention]

[0017] However, the reinforcement learning disclosed in Non-Patent Document 1 relates 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 of the objectives of the present disclosure is to provide a system design learning device, a system design learning method, and program The purpose is to provide [Means for solving the problem]

[0020] In order to achieve the above object, a system design learning device according to one aspect of the present disclosure includes: a functional requirement learning unit that learns a first learning model that executes a concretization process for converting abstract parts into concrete parts for 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 that indicates 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 unit that, when the functional requirement learning unit executes the instantiation process during learning to generate the specific system configuration, constructs a measurement system that is a measurement environment based on the specific system configuration, executes performance measurement process for a predetermined performance using the measurement system, and stores performance data that is a result of the performance measurement process in a storage device; a non-functional requirements learning unit that uses the performance data corresponding to the specific system configuration measured by the performance measurement unit to learn a second learning model that outputs an evaluation value that represents the likelihood that the specific system configuration will be able to demonstrate performance that satisfies the non-functional requirements; and The present invention is characterized by having the following.

[0021] In order to achieve the above object, a system design learning method according to one aspect of the present disclosure includes: The computer a functional requirement learning step of learning a first learning model that performs a concretization process to convert abstract parts into concrete parts for 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 in which, when the specific system configuration is generated by executing the instantiation process during learning in the functional requirements learning step, a measurement system that is a measurement environment is constructed based on the specific system configuration, a performance measurement process is executed using the measurement system for performance that has been set in advance, and performance data that is a result of the performance measurement process is stored in a storage device; 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 that the specific system configuration will be able to demonstrate performance that satisfies the non-functional requirements; The present invention is characterized by carrying out the following.

[0022] Furthermore, in order to achieve the above object, a program according to one aspect of the present disclosure M is , On the computer, a functional requirement learning step of learning a first learning model that performs a concretization process to convert abstract parts into concrete parts for 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 in which, when the specific system configuration is generated by executing the instantiation process during learning in the functional requirements learning step, a measurement system that is a measurement environment is constructed based on the specific system configuration, a performance measurement process is executed using the measurement system for performance that has been set in advance, and performance data that is a result of the performance measurement process is stored in a storage device; 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 that the specific system configuration will be able to demonstrate performance that satisfies the non-functional requirements; Contains instructions to execute son-in-law It is characterized by the following. [Effects of the Invention]

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

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

[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] Figure 1 is a diagram for explaining the automated design of a face recognition system. Graph G1 in Figure 1 is a graph that represents the configuration of system requirements R1 of the face recognition system. Graph G1 in Figure 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 (affiliation) functions (solid arrow).

[0029] Fig. 2 is a diagram for explaining 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] In the example of Figure 2, part identification information "N1," function information "camera," and information "1" indicating that the node is concrete are associated with each other. Similarly, part identification information "N2" to "N4," and "E1" to "E3" are each associated with function information and information indicating whether the node or edge is concrete or abstract.

[0031] Figure 3 is a diagram for explaining the data structure of a system requirement. As shown in Figure 3, a system requirement R1 corresponding to the graph G1 shown in Figure 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 graph G1, part information P1, and system requirement R1, but the graph, part information, and system requirement are not limited to graph G1, part information P1, and system requirement R1.

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

[0035] Fig. 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 Figure 1 into graph G2 shown in Figure 1. Graph G32 is a graph representing concatenation rule Rule2 used to convert graph G1 shown in Figure 1 into graph G3 shown in Figure 1 (converting node N4 into node N5). Graph G33 is a graph representing concatenation rule Rule3 used to convert graph G1 shown in Figure 1 into graph G4 shown in Figure 1 (converting node N4 into node N6).

[0037] Fig. 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 has 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, etc. also have instantiation rules Rule2, Rule3, etc. corresponding to the graphs G32, G33, etc.

[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 find detection information that matches the abstract parts contained in 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 and the concatenation rule Rule1 match, the system requirement R1 is replaced (converted) into 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" (the number inside the circle) as the expected score for system configuration plan R2 corresponding to graph G2, and outputs "1" (the number inside the circle) as the expected score for system configuration plan R3 corresponding to graph G3. 4 The expected score for the corresponding system configuration proposal R4 is output as "3" (the number inside the circle).

[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 instantiated, a new system configuration is generated, the expected score of the new system configuration is output, and the system configuration with the highest expected score is selected. 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 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 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, the facial recognition system in Figure 1 has a facial recognition function that communicates with a 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, which represents the configuration of the face recognition system in Figure 1, has a constraint expression that indicates that the communication speed is 10 [Mbps] or more. The constraint expression can be expressed as, for example, communication speed >= 10 [Mbps].

[0061] Also, 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 can be performed in 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 will take an unrealistic amount of time to perform simultaneously with learning.

[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 decided 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, when the probability distribution is a Gaussian mixture distribution, the parameters are the mean, variance, and mixture coefficient of each Gaussian mixture distribution. Person in charge However, the parameters are the mean, variance, and mixture of the above-mentioned Gaussian distributions. Person in charge It is not limited to the number.

[0067] (Embodiment) Hereinafter, embodiments 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 in 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] [Device configuration] 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 having 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. 7 In this example, 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 (to be described later) converted into an outputtable format by the output information generation unit 15, and outputs generated images, sounds, etc. based on the output information. The output device 40 is, for example, an image display device using a liquid crystal, an organic EL (Electro Luminescence), or a CRT (Cathode Ray Tube). Furthermore, 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 WiFi (Wireless Fidelity).

[0083] (System Design Learning Device) The system design learning device 10 according to 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, system configuration proposal, 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] Based on the system requirements, which are information representing the configuration of a system including abstract parts, the design unit 111 converts the abstract parts into concrete parts in stages 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 execute 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 execute 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, a 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 explained. 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 about the functional requirements (step S12). Details of step S12 will be described later with reference to FIG.

[0095] Furthermore, the performance measurement unit 12 executes a performance measurement process on the specific system configuration that satisfies the functional requirements generated in step S12 to acquire performance data, and stores the acquired 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. 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 instantiation process is a process of instantiating an abstract part (component configuration) 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 predetermined 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 so 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 that 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 be described. FIG. 10 is a diagram for explaining an example of the operation of learning functional requirements.

[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 learning 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 learning data generation unit 112 updates the reward for each system configuration of 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.

[0110] Next, the learning unit 113 executes learning (step F15). Details of step F15 will be described later.

[0111] Then, the process of steps F11 to F15 is repeated for a preset learning period (step F16). Details of step F16 will be described later.

[0112] The operation of generating configuration paths and component paths (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] Fig. 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 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 (system configuration plan) concretized in step F113 as the next configuration (step F114).

[0117] Next, if the next configuration (specific configuration (system configuration plan)) 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 (system configuration plan)) 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 concretized component configuration) as a directed edge, 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 a child node, and the edge representing the concretized component configuration (the concretized component configuration of the concretization rule) as a directed edge.

[0119] For example, when a system configuration plan R2 is generated from a current system requirement R1, as shown in FIG. 12, the system requirement R1 in the search tree information 121 is generated from the system requirement R2. Requirements The identification information "R1", the system configuration plan identification information "R2" associated with the system configuration plan 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 configuration proposal R2 to which a specific system configuration R5 is generated, as shown in FIG. 12, the system configuration proposal identification information "R2" in the search tree information 121, the specific system configuration identification information "R5" associated with the specific system 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, an instantiation rule cannot be applied. Also, 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 configurations that have become the current configuration in chronological order) from the system configurations (system requirements, system configuration proposal, specific system configuration) that emerged in the processing of the above-mentioned steps F111 to F118 to generate 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 Fig. 12 and Fig. 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 for explaining an example of the data structure of a part path. If we consider that Fig. 13 (R1-R2-R5) corresponds 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 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 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 now 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" as the reward information representing the reward for that specific system configuration; if it is not a specific system configuration, for example, it sets the reward information representing the reward corresponding to that specific system configuration to "0."

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

[0129] In the example of FIG. 14, since the last configuration in the configuration path CP1 is the specific system configuration R5, in the processing of step F132, the remuneration information "1" is associated with "R5" representing the specific system configuration of the 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 remuneration information (step F13) will now be described. 16 is a diagram illustrating an example of an operation for updating reward information. First, the learning 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. If the former reward does not yet exist (is not associated) before the comparison, it is considered 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, initially, no reward is associated with any configuration, so in the example in Figure 14, "R5" is updated first in step F131. subject Since the reward is not yet associated with it, its value is considered to be "0". The reward of the update candidate is initialized to "1" in step F12, so "0" and "1" are compared, and since "1" is larger, "R5" is associated with reward "1". Next, subject The configuration is set to "R2" and the same process as described above is repeatedly executed.

[0136] Next, the learning data generation unit 112 sets the reward selected in step F132 (the larger one) as the reward for the update candidate (step F133). Next, for example, if a reward "2" is associated with "R2", the "2" associated with "R2" is compared with the update candidate reward "1", and since "2" is larger, the reward "2" is associated with "R2" (no actual change), and the update candidate reward is changed to "2". After that, subject The configuration becomes "R1" and the above process is repeated in the same manner.

[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 one is kept.

[0140] The reason we keep the larger one and propagate it upwards ("R1" from the perspective of "R2") is because we know that we can transition from "R1" to "R2". What we want to learn is the expected reward if we continue to choose the best choice, and we know that we can transition from "R1" to "R2" by applying the appropriate reification rule, so 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 in Figure 13, there is also the possibility of transitioning to "R3" or "R4". However, the automatic design function can choose which transition to take, so the comparatively larger reward is propagated upward.

[0142] The operations for determining rewards and generating training data (step F14) will now be described. 17 is a diagram illustrating an example of an operation for determining a reward and generating learning data. First, the learning data generation unit 112 determines 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 determines the first part configuration in the part path as the part configuration to be subject to remuneration determination (step F142).

[0145] In the example of FIG. 15, "E1" representing an abstract part is stored in the first part configuration of part path PP1, so part "E1" is set as the part configuration to be subject to remuneration determination.

[0146] Next, the learning data generation unit 112 detects all directed edges that represent the parts configuration for which remuneration is determined, from among the directed edges whose parent node (starting point) is the system configuration for which remuneration is determined (step F143).

[0147] In the example of Figure 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 in the example of Figure 13, there is one directed edge, but in examples other than Figure 13, multiple directed edges may be detected.

[0148] The learning data generation unit 112 determines the maximum reward among the rewards related to the function 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 as first learning data in the storage device 20 (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] Note 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 addition, in step F145, the configuration for which the reward is to be determined and the final reward are associated with each other and stored as first learning data in the storage device 20.

[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-mentioned CP1.

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

[0159] The learning operation (step F15) will now be described. When the configuration of the reward determination target included in the first learning data is input to the first learning model, the learning unit 113 performs learning to correct errors in the output of the first learning model so that the evaluation value output for the component configuration of the 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 is as follows: The first learning model is a GNN (Graph Neural Network) that takes 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 D1 is selected from the training data, and a graph representing the reward determination target (configuration) included in the data D1 is input to the first training model. The resulting graph information output from the first training model is designated as OG1.

[0162] In OG1, the attribute value of the node or edge corresponding to the parts configuration (parts) for which the 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 squared error between the attribute value and the fixed reward is used as the 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 component paths are not generated. The first learning model is a GNN that takes graph information with attribute values for each node and edge in the graph as input and outputs graph information in a similar format.

[0165] One data set, D2, is selected from the training data, and the graph information representing the reward determination target (configuration) included in data D1 is input to the first training model. The resulting graph information output from the first training 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 result 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 the 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. 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 processes 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 measuring 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). Measurement The measurement system is constructed using, for example, a tool for automatically constructing a measurement system. The tool may be, for example, a configuration management tool such as Ansible (registered trademark), or a platform. The platform may be, for example, AWS (Amazon Web Services) (registered trademark).

[0172] Next, the performance measurement unit 12 executes a performance measurement process for the measurement system constructed in step S133, and obtains 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, install iPerf on the information processing devices PC1 and PC2 at both ends of the communication whose bandwidth you want to measure. Then, start one of the information processing devices PC1 in server mode and start the other information processing device PC2 in client mode to measure 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, a ping is executed from the information processing device PC1 to the information processing device PC2 as the destination, thereby measuring the time it takes for the communication to go 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 which system configuration identification information indicating the specific system configuration and the performance data obtained by the performance measurement process in step S134 are associated with each other in the storage device 20 (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 be described. 21 is a diagram for explaining an example of the operation of the learning unit. First, the non-functional requirement learning unit 13 executes reinforcement learning on the non-functional requirements using the system requirements and performance information for 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 requirements 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-mentioned determination.

[0187] The performance estimation result is an attribute value representing the performance value of a part 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 part. The judgment in step S143 is made based on the error between the attribute value and the performance value obtained by actually measuring the performance of the part. 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 be described. FIG. 22 is a diagram for explaining an example of the operation of non-functional requirement learning.

[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 learning data generation unit 132 determines the value of the reward (step N12). Note that the 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.

[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 configuration paths and component paths (step N11) will now be described. FIG. 23 is a diagram for explaining an example of an operation for generating a configuration path and a component path.

[0196] First, the design unit 131 sets the system requirement 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 instantiation rules (directed edges) associated with the system requirement (parent node) which is the root node (step N112).

[0197] In the example of Fig. 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 instantiation 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. On the other hand, 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 (configuration path) by storing the configurations that have 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 to generate component path information (component path) (step N116).

[0202] In the embodiment, a method for learning an evaluation value (likelihood) for each component is described as an example, but it is not necessary to learn an evaluation value (likelihood) for each component. For example, an 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 processing of the design unit 111 and the processing of the design unit 131 have equivalent functions, the processing of the design unit 131 may be performed by the design unit 111. By doing so, the design unit 131 can be eliminated.

[0204] The operation for determining the remuneration information (step N12) will now 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 should be decided 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 (gigabits per second; same below) is 1000 Mbps, so the reward should be set to 1000. Also, since it is more convenient for the values to be learned to have a smaller scale, the reward can be set to the 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 setting 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 performance, the reward for the corresponding non-functional requirement will be the value of the performance data, and for performance where the smaller the value, the better the performance, the reward for the corresponding non-functional requirement will be the value of the performance data. data Alternatively, the reciprocal of the value of (reward determination method 2) may be used.

[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 using reward determination method 2 with appropriate weighting.

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

[0210] Next, the learning data generation unit 132 sets the first component configuration of 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 part configuration targeted for learning data storage in step N131 is not the last part configuration in the part path (step N134: No), the learning data generation unit 132 selects the part configuration immediately following the part configuration targeted for learning data storage in the part path as the part configuration targeted for learning data storage. composition (Step N135), and in the configuration path, the configuration immediately following the current configuration for which learning data is to be stored is set as the configuration for which learning data is to be stored (Step N136), and then the process proceeds to Step N133.

[0216] If it is the last component configuration (step N134: Yes), the learning data generation 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 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. 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 learning (step N14) operation will now 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 performs learning to correct errors in the output of the second learning model so that the evaluation value output for the component configuration included in the second learning data approaches the reward value included in the second learning data.

[0221] The second learning model takes graph information, in which each node and edge in the graph and the graph itself have attribute values, as input, and generates a graph of the same format. information It is a GNN that outputs

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

[0223] Let VP3 be the pair of PV3 and the reward contained in data D3. Let VPS3 be the result of generating this VP3 for all data contained in the training data. For each pair contained in VPS3, the mean squared error between the attribute value and the reward is used as the loss function, and the 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 component paths are not generated. The second learning model is a GNN that takes 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 the graph information representing the structure contained in data D4 is input to the second learning model. The resulting graph information output from the second learning model is called OG4. The attribute value of the graph itself in OG4 is called PV4. The pair of PV4 and the reward contained in data D4 is called 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 the 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 computer's processor 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] Here, a computer that realizes the system design learning device by executing the program in the embodiment will be described with reference to Fig. 27. Fig. 27 is a diagram showing an example of a computer that realizes the 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 is a data reader / writer that reads and writes data from the CPU 231 and the recording medium. 240 Mediate data transmission between the recording medium 240 The computer 230 reads out programs from the storage medium 240 and writes the processing results in the computer 230 to the storage 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 not by a computer with a program installed, but by hardware corresponding to each part. Furthermore, the system design learning device may be realized in part by a program and in the remaining part by hardware.

[0245] [Note] The following supplementary notes are further provided with respect to the above-described embodiments. Some or all of the above-described embodiments can be expressed by (Supplementary Note 1) to (Supplementary Note 15) described below, but are not limited to the following descriptions.

[0246] (Appendix 1) a functional requirement learning unit that learns a first learning model that executes a concretization process for converting abstract parts into concrete parts for 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 that indicates 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 unit that, when the functional requirement learning unit executes the instantiation process during learning to generate the specific system configuration, constructs a measurement system that is a measurement environment based on the specific system configuration, executes performance measurement process for a predetermined performance using the measurement system, and stores performance data that is a result of the performance measurement process in a storage device; a non-functional requirements learning unit that uses the performance data corresponding to the specific system configuration measured by the performance measurement unit to learn a second learning model that outputs an evaluation value that represents the likelihood that the specific system configuration will be able to demonstrate performance that satisfies the non-functional requirements; and A system design learning device having:

[0247] (Appendix 2) The functional requirement learning unit generates configuration path information using the system requirements, the system configuration plan, 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 plan, and the specific system configuration included in the configuration path information. 2. The system design learning device according to claim 1.

[0248] (Appendix 3) The functional requirement learning unit generates component path information using the abstract parts converted when the system requirements and the system configuration plan were specified, which 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 corresponding to the system requirements and the abstract parts corresponding to the system configuration plan, which are included in the component path information. 2. The system design learning device according to claim 1.

[0249] (Appendix 4) The non-functional requirement learning unit generates configuration path information using the system requirements, the system configuration plan, 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 plan, and the specific system configuration included in the configuration path information. 2. The system design learning device according to claim 1.

[0250] (Appendix 5) The non-functional requirement 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 specified, and generates second 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 that are included in the component path information. 2. The system design learning device according to claim 1.

[0251] (Appendix 6) The computer a functional requirement learning step of learning a first learning model that performs a concretization process to convert abstract parts into concrete parts for 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 in which, when the specific system configuration is generated by executing the instantiation process during learning in the functional requirements learning step, a measurement system that is a measurement environment is constructed based on the specific system configuration, a performance measurement process is executed using the measurement system for performance that has been set in advance, and performance data that is a result of the performance measurement process is stored in a storage device; 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 that the specific system configuration will be able to demonstrate performance that satisfies the non-functional requirements; A system design learning method that performs the above.

[0252] (Appendix 7) The functional requirement learning step generates configuration path information using the system requirements, the system configuration plan, 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 plan, and the specific system configuration included in the configuration path information. 6. A system design learning method as set forth in claim 6.

[0253] (Appendix 8) 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 specified, 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. 6. A system design learning method as set forth in claim 6.

[0254] (Appendix 9) The non-functional requirement learning step generates configuration path information using the system requirements, the system configuration plan, 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 plan, and the specific system configuration included in the configuration path information. 6. A system design learning method as set forth in claim 6.

[0255] (Appendix 10) The non-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 specified, and generates second 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 that are included in the component path information. 6. A system design learning method as set forth in claim 6.

[0256] (Appendix 11) On the computer, a functional requirement learning step of learning a first learning model that performs a concretization process to convert abstract parts into concrete parts for 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 in which, when the specific system configuration is generated by executing the instantiation process during learning in the functional requirements learning step, a measurement system that is a measurement environment is constructed based on the specific system configuration, a performance measurement process is executed using the measurement system for performance that has been set in advance, and performance data that is a result of the performance measurement process is stored in a storage device; 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 that the specific system configuration will be able to demonstrate performance that satisfies the non-functional requirements; Contains instructions to execute Mup Logura Hmm.

[0257] (Appendix 12) The functional requirement learning step generates configuration path information using the system requirements, the system configuration plan, 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 plan, and the specific system configuration included in the configuration path information. The program described in Appendix 11 Hmm.

[0258] (Appendix 13) 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 specified, 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. The program described in Appendix 11 Hmm.

[0259] (Appendix 14) The non-functional requirement learning step generates configuration path information using the system requirements, the system configuration plan, 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 plan, and the specific system configuration included in the configuration path information. The program described in Appendix 11 Hmm.

[0260] (Appendix 15) The non-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 specified, and generates second 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 that are included in the component path information. The program described in Appendix 11 Hmm.

[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. [Industrial Applicability]

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

[0263] 10 System Design Learning Device 11 Functional Requirements Learning Section 12 Performance measurement section 13 Non-functional Requirements Learning Section 14 Learning control unit 15 Output information generation unit 20 Storage device 30 Input Devices 40 Output Devices 1 11, 131 Design Department 112, 132 Learning data generation unit 113, 133 Learning Department 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 Devices 239 Display Device 240 Recording Media 241 Bus

Claims

1. a functional requirement learning means for learning a first learning model that executes a concretization process for converting abstract parts into concrete parts for 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 means for, when the functional requirement learning means executes the instantiation process during learning to generate the specific system configuration, constructing a measurement system as a measurement environment based on the specific system configuration, executing a performance measurement process for a predetermined performance 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 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 that indicates the likelihood that the specific system configuration will be able to exhibit performance that satisfies the non-functional requirements; and A system design learning device having:

2. The functional requirement learning means generates configuration path information using the system requirements, the system configuration plan, 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 plan, and the specific system configuration included in the configuration path information. The system design learning device according to claim 1 .

3. The functional requirement learning means generates component path information using the abstract parts converted when the system requirements and the system configuration plan were specified, which 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 corresponding to the system requirements and the abstract parts corresponding to the system configuration plan, which are included in the component path information. The system design learning device according to claim 1 .

4. The non-functional requirement learning means generates configuration path information using the system requirements, the system configuration plan, 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 plan, and the specific system configuration included in the configuration path information. The system design learning device according to claim 1 .

5. The non-functional requirement learning means 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 specified, and generates second 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 that are included in the component path information. The system design learning device according to claim 1 .

6. The computer a functional requirement learning step of learning a first learning model that performs a concretization process to convert abstract parts into concrete parts for 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 in which, when the specific system configuration is generated by executing the instantiation process during learning in the functional requirements learning step, a measurement system that is a measurement environment is constructed based on the specific system configuration, a performance measurement process is executed using the measurement system for performance that has been set in advance, and performance data that is a result of the performance measurement process is stored in a storage device; 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 that the specific system configuration will be able to demonstrate performance that satisfies the non-functional requirements; A system design learning method that performs the above.

7. On the computer, a functional requirement learning step of learning a first learning model that performs a concretization process to convert abstract parts into concrete parts for 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 in which, when the specific system configuration is generated by executing the instantiation process during learning in the functional requirements learning step, a measurement system that is a measurement environment is constructed based on the specific system configuration, a performance measurement process is executed using the measurement system for performance that has been set in advance, and performance data that is a result of the performance measurement process is stored in a storage device; 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 that the specific system configuration will be able to demonstrate performance that satisfies the non-functional requirements; A program containing instructions to execute

Images