System design device, system design method and program

Abstract

A system design device according to the present invention comprises: a probability distribution estimation means for estimating a probability distribution of values of evaluation indices of an embodied system configuration in cases where system configurations, which are candidates to be embodied, have been embodied in system design involving embodiment of system configurations; an expected value calculation means for calculating expected values of the evaluation indices on the basis of the probability distribution; and a system configuration embodiment means for selecting one of the system configurations which is a candidate to be embodied on the basis of the expected values of the evaluation indices.

Description

[Technical Field]

[0001] The present invention relates to a system design device. , S This invention relates to a system design method and program. [Background technology]

[0002] Several techniques have been proposed for the automated design of systems such as ICT (Information and Communication Technology) systems. For example, Non-Patent Document 1 describes a system design method in which input requirements are rewritten in accordance with pre-given conversion rules to repeatedly specify the content, thereby deriving a completely specified configuration.

[0003] Furthermore, Non-Patent Document 2 describes narrowing down the system configurations to be realized based on constraints that must be satisfied by quantitative evaluation indices such as the performance required of the system components. Specifically, in the system design method described in Non-Patent Document 2, if multiple constraints specified for one system configuration cannot be met, that system configuration is excluded from the targets for realization. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] Takayuki Kuroda, Takuya Kuwahara, Takashi Maruyama, Yutaka Yakuwa, Kazuki Tanabe, Tatsuya Fukuda, Kozo Satoda, Takao Osaki, "Acquiring Knowledge for ICT System Design Using Machine Learning," IEICE Transactions on Information and Communication Engineers, Vol. J104-B, No. 3, pp. 140-151, 2021. [Non-patent document 2] Takuya KUWAHARA, Takayuki KURODA, Takao OSAKI, Kozo SATODA, “An intent-based system configuration design for IT / NW services with functional and quantitative constraints”, IEICE Trans Commun. Vol.E104-B, No.7, pp.791-804, 2021 Summary of the Invention [Problem to be solved by the invention]

[0005] It is desirable that the system configuration obtained by the system design satisfies the specified constraints and also satisfies the constraints at the highest possible level with respect to the performance desired by the user.

[0006] An example of the object of this disclosure is to provide a system design device that can solve the above-mentioned problems. , S The present invention provides a system design method and program. [Means for solving the problem]

[0007] According to a first aspect of the present invention, a system design apparatus includes a probability distribution estimation means for estimating a probability distribution of an evaluation index value for an instantiated system configuration when the system configuration that is a candidate for instantiation is instantiated in a system design by instantiating a system configuration, an expected value calculation means for calculating an expected value of the evaluation index based on the probability distribution, and a system configuration instantiation means for selecting one of the system configurations that are candidates for instantiation based on the expected value of the evaluation index and instantiating the selected system configuration.

[0010] The present invention twoAccording to an aspect of the present invention, a system design method includes a computer estimating a probability distribution of values of an evaluation index for a concretized system configuration when concretizing a system configuration that is a candidate for concretization in system design by concretizing the system configuration, calculating an expected value of the evaluation index based on the probability distribution, selecting any one of the system configurations that are candidates for concretization based on the expected value of the evaluation index, and concretizing the selected system configuration.

[0011] According to a three According to an aspect of the present invention, a program causes a computer to estimate a probability distribution of values of an evaluation index for a concretized system configuration when concretizing a system configuration that is a candidate for concretization in system design by concretizing the system configuration, calculate an expected value of the evaluation index based on the probability distribution, select any one of the system configurations that are candidates for concretization based on the expected value of the evaluation index, and concretize the selected system configuration.

Advantages of the Invention

[0012] According to the present invention, it is expected that the system configuration obtained in system design satisfies specified constraint conditions and satisfies the performance desired by the user at a relatively high level with respect to the constraint conditions.

Brief Description of the Drawings

[0013] [Figure 1] It is a diagram showing an example of the configuration of a design system according to the first embodiment. [Diagram 2] It is a diagram showing an example of a branch of a method for concretizing a system configuration. [Figure 3] It is a diagram showing an example of the functional configuration of a configuration evaluation unit according to the first embodiment. [Figure 4] It is a diagram showing an example of a configuration draft that does not satisfy qualitative conditions. [Figure 5] It is a diagram showing an example of a configuration draft that does not satisfy qualitative conditions due to concretization. [Figure 6] FIG. 2 is a diagram illustrating an example of the configuration of a quantitative condition estimation unit according to the first embodiment. [Figure 7] 5 is a diagram illustrating an example of data transfer in a quantitative condition estimation unit according to the first embodiment. FIG. [Figure 8] FIG. 2 is a diagram showing an example of a graphical representation of configuration information according to the first embodiment. [Figure 9] FIG. 3 is a diagram showing an example of a text representation of configuration information according to the first embodiment. [Figure 10] FIG. 3 is a diagram showing an example of a definition of a type of a component part according to the first embodiment. [Figure 11] FIG. 4 is a diagram illustrating an example of a definition of a relationship type according to the first embodiment. [Figure 12] FIG. 3 is a diagram illustrating an example of definition of a concatenation rule according to the first embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of a situation regarding the distribution of observation probabilities of values of s1.conn according to the first embodiment. [Figure 14] 1 is a flowchart illustrating an example of the operation of the system design apparatus according to the embodiment. [Figure 15] FIG. 4 is a diagram showing an example of a design screen that an input / output unit according to the first embodiment causes a user terminal device to display. [Figure 16] FIG. 10 is a diagram illustrating an example of the configuration of a system design apparatus according to a second embodiment. [Figure 17] 10 is a flowchart showing an example of a processing procedure in a system design method according to a third embodiment. [Figure 18] FIG. 1 is a schematic block diagram illustrating the configuration of a computer according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0014] The following describes embodiments of the present invention, but the following embodiments do not limit the scope of the invention as claimed. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention.

[0015] <First Embodiment> FIG. 1 is a diagram showing an example of the configuration of a design system according to the first embodiment. In the configuration shown in FIG. 1, the design system 1 includes a system design apparatus 100 and a user terminal apparatus 300. The system design apparatus 100 includes a configuration information concretization unit 110, a configuration evaluation unit 120, a storage unit 130, and an input / output unit 140. The configuration information concretization unit 110 is configured to be able to transfer data with each of the configuration evaluation unit 120, the storage unit 130, and the input / output unit 140.

[0016] The system design apparatus 100 gradually concretizes the system configuration by repeatedly applying conversion rules for concretization to the system configuration of the system to be designed, and derives a completely concretized system configuration (that is, a system configuration concretized to such an extent that no further concretization is required). The conversion rules for concretizing the system configuration are also referred to as concretization rules. The concretization (concretization process) here can be said to be the system design apparatus's 100 making design judgments such as selecting an architecture (single configuration, multiple configuration, etc.) used for application deployment and selecting a server to be used (low-performance server, high-performance server, etc.). For one system configuration, there can be multiple options for the concretization method. Therefore, since the concretization method from one system configuration repeats branching as the concretization progresses, a large number of concretized system configurations can be generated.

[0017] The concretization method here is a series of concretization rules applied to the system configuration. Depending on the system configuration and the concretization rules, generally, when different concretization rules are applied to the same system configuration, the resulting system configurations are different. Also, when multiple concretization rules are applied to the same system configuration, the resulting system configurations may be different depending on the application order of the concretization rules.

[0018] FIG. 2 is a diagram showing an example of a branch in a method for concretizing a system configuration. In FIG. 2, system configurations R11 to R17 are shown. For the system configuration R11, each of the system configurations R12 to R17 corresponds to an example of a concretized system configuration. For example, from the system configuration R11, it is possible to concretize to the system configuration R12 and to the system configuration R13, and the concretization method branches. By repeating such a branch of concretization, a large number of concretized system configurations can be generated.

[0019] In the system design apparatus 100, the system configuration is represented in a graph format. Information indicating the system configuration is also referred to as configuration information. The nodes of the graph in the configuration information indicate various components that make up the system, such as physical or virtual devices used in the system, and software modules (applications).

[0020] The edges between the nodes of the graph in the configuration information indicate the relationship between the components. The edges here may be directed edges or undirected edges. Only some of the edges of the graph representing the system configuration may be directed edges. The components and edges are collectively referred to as constituent elements.

[0021] The configuration information may further include constraint condition information and priority information. The constraint condition information is information indicating the constraint conditions that the components should satisfy. The constraint conditions that the components should satisfy are represented by equations or inequalities indicating the conditions that the evaluation indicators for the components should satisfy.

[0022] The priority information is information indicating the priority for each evaluation indicator. The priority for each evaluation indicator is used as a weight value for determining how much to emphasize the values of each evaluation indicator when a plurality of evaluation indicators are shown for the components included in the system configuration for one system configuration. Note that in FIG. 2, the illustration of the priority information is omitted.

[0023] The system configuration expected by the user of the system design apparatus 100 is also referred to as system requirements. The system configuration generated by the system design apparatus 100 is also referred to as a configuration draft. The system configuration output by the system design apparatus 100 as a design result is also referred to as a design result system configuration. In the example of FIG. 2, the system configuration R11 corresponds to an example of system requirements. The system configurations R12 to R17 correspond to examples of configuration drafts. The system configurations R12 to R17 are also denoted as configuration drafts R12 to R17.

[0024] The system requirements and the configuration draft may include uncertain components, such as abstract components or components in a state where some of the components on which a certain component depends are missing. That the first component depends on the second component means that the second component is required for the first component to function. Examples of such a dependency relationship include that an operating system (OS) is required for an application program to operate, and that a machine (computer hardware) is required for the OS to operate. When the system configuration includes the first component and the second component on which the first component depends is missing, in order to reach a fully specified system configuration, it is necessary to specify the system configuration so that the second component is included in the system configuration. On the other hand, the design result system configuration is derived as a fully specified system configuration and does not include uncertain components.

[0025] A fully specified system configuration is a system configuration that does not include abstract components and satisfies the dependencies of all components. As a criterion for determining whether a component is concrete or abstract, for example, a criterion such as whether the component is specified to the extent that it can be implemented without further specification can be used.

[0026] In the example of FIG. 2, the icon of each component represents the type of the component. The correspondence between the icon and the type of the component is shown in the legend. The character string attached to a component represents the id (Identifier, identification information) of each component. Also, the inequality attached to a graph represents a constraint condition. For example, the inequality "$s1.conn >= 100" indicates a constraint condition that the value of "conn", which is an evaluation index associated with the component with the id "s1", is 100 or more. Here, "associated with" can also be referred to as "linked to". The specific method for generating a configuration draft will be described later.

[0027] The system design device 100 acquires system requirements, applies a concretization rule to the acquired system requirements to generate a configuration draft. The system design device 100 further applies the concretization rule to the configuration draft to generate a more concretized configuration draft. The system design device 100 repeats the application of the concretization rule to the configuration draft until a design result system configuration is obtained or it is determined that the system design has failed. When it is determined that the system design has failed, the system design device 100 traces back to the system requirements or the configuration draft in the middle of concretization, and attempts concretization by a concretization method of a branch different from the concretization method performed so far.

[0028] In this way, the system design device 100 uses an exploratory approach to derive an appropriate configuration draft that satisfies the specified conditions among the concretized configuration drafts. When exploring a configuration draft, if the promise of the configuration draft can be appropriately evaluated, an appropriate concretization method can be selected in the branch of the concretization method. As a result, the occurrence of rework (redo) due to design failure can be reduced, and a high-quality configuration can be derived. For example, in FIG. 2, if the promise of each of the configuration drafts R12 and R13 can be evaluated, a high-quality design can be efficiently reached by selecting the configuration draft with higher promise and preferentially proceeding with the exploration. In particular, it is possible to reduce the waste of processing time caused by rework when selecting the configuration draft with lower promise.

[0029] The input / output unit 140 functions as either an interface with other devices or an interface with a user, or both. For example, input / output unit 140 may include a communication device, receive information on system requirements from user terminal device 300, and output the received information on system requirements to configuration information instantiation unit 110. Furthermore, input / output unit 140 may receive input of information on the specific system configuration designed from configuration information instantiation unit 110, and transmit the input information on the specific system configuration to user terminal device 300.

[0030] The input / output unit 140 may also include input devices such as a keyboard and a mouse to accept various user operations, such as a user operation for inputting information about system requirements, etc. The input / output unit 140 may also include a display screen such as a liquid crystal panel or an LED (Light Emitting Diode) panel to display various images, such as information about the specific system configuration that has been designed. When the input / output unit 140 functions as an interface with the user, the user terminal device 300 does not need to be provided.

[0031] In the following, an example will be described in which the user terminal device 300 functions as an interface with the user (user interface), and the input / output unit 140 communicates with the user terminal device 300. The user terminal device 300 is equipped with input devices such as a keyboard and a mouse, and accepts various user operations, such as user operations to input information about system requirements.The user terminal device 300 also has a display screen, such as an LCD panel or an LED (Light Emitting Diode) panel, and displays various images, such as information about the specific system configuration that has been designed. The user terminal device 300 is an example of a display device.

[0032] The configuration information concretization unit 110 gradually concretizes system requirements in multiple steps and generates information on the system configuration as a result of the concretization. As described above for the system design apparatus 100, in the concretization step, the configuration information concretization unit 110 may generate a plurality of configuration drafts. The configuration information concretization unit 110 corresponds to an example of the system configuration concretization means.

[0033] In order to generate a configuration draft, the configuration information concretization unit 110 acquires information on components and information on concretization rules from the storage unit 130. When there are a plurality of configuration drafts that are candidates for concretization targets, the configuration information concretization unit 110 passes the configuration information of each configuration draft to the configuration evaluation unit 120 and acquires an evaluation result for each configuration draft. The configuration information concretization unit 110 selects a configuration draft to be further concretized from among the plurality of configuration drafts based on the acquired evaluation results.

[0034] When the configuration evaluation unit 120 receives the configuration information of a configuration draft from the configuration information concretization unit 110, it evaluates the configuration draft and returns an evaluation result. FIG. 3 is a diagram showing an example of the functional configuration of the configuration evaluation unit 120. In the configuration shown in FIG. 3, the configuration evaluation unit 120 includes an overall evaluation unit 121, a constraint condition verification unit 122, a qualitative condition estimation unit 123, and a quantitative condition estimation unit 124. The overall evaluation unit 121 is configured to be able to exchange data with each of the configuration information concretization unit 110, the constraint condition verification unit 122, the qualitative condition estimation unit 123, and the quantitative condition estimation unit 124.

[0035] When the constraint condition verification unit 122 acquires the configuration information of the configuration draft output by the configuration information concretization unit 110 via the overall evaluation unit 121, it verifies whether the constraint conditions included in the configuration draft are contradictory and returns the verification result to the overall evaluation unit 121. The configuration draft indicated by the configuration information acquired by the overall evaluation unit 121 from the configuration information concretization unit 110 is also referred to as the configuration draft to be evaluated. The configuration draft to be evaluated can also be said to be a candidate for the concretization target. The constraint condition verification unit 122 corresponds to an example of the constraint condition verification means.

[0036] In the example of FIG. 2, one or more constraint conditions are included in each configuration draft. Among these, the constraint conditions "$v1.mem >= 10" and "$v1.mem <= 8" included in the configuration draft R14 cannot be satisfied simultaneously and are contradictory. Therefore, the constraint condition verification unit 122 determines that the configuration draft R14 does not satisfy the constraint conditions. On the other hand, the configuration drafts other than the configuration draft R14 do not contain contradictions. Therefore, the constraint condition verification unit 122 determines that the configuration drafts other than the configuration draft R14 satisfy the constraint conditions.

[0037] When the qualitative condition estimation unit 123 obtains the configuration information of the evaluation target configuration draft output by the configuration information concretization unit 110 via the comprehensive evaluation unit 121, it obtains the satisfaction probability regarding the qualitative conditions in that configuration draft and returns the obtained satisfaction probability to the comprehensive evaluation unit 121. The qualitative condition estimation unit 123 corresponds to an example of the qualitative condition estimation means.

[0038] The qualitative conditions of the configuration draft are the qualitative conditions among the conditions that the configuration draft should satisfy. Specifically, the qualitative conditions of the configuration draft are the conditions regarding the topology of the graph representing the configuration draft. The qualitative conditions of the configuration draft are also simply referred to as qualitative conditions.

[0039] FIG. 4 is a diagram showing an example of a configuration draft that does not satisfy the qualitative conditions. In the example of FIG. 4, assume that there is a structural constraint that a Server_x type component cannot be connected to two Domain type components. This constraint corresponds to an example of the qualitative conditions. In the configuration draft shown in FIG. 4, a Server_x type component is connected to two Domain type components and does not satisfy the above constraint. Therefore, the configuration draft shown in FIG. 4 is determined not to satisfy the qualitative conditions.

[0040] FIG. 5 is a diagram showing an example of a configuration draft that does not satisfy the qualitative conditions due to concretization. In the example of FIG. 5, in addition to the constraints in the example of FIG. 4, it is assumed that there is a constraint that a Server_x type component connected by a certain App_x type component must be connected to a Domain type component of the same Domain type as the destination to which the App_x type component is connected. This constraint corresponds to an example of a qualitative condition.

[0041] The configuration draft shown in FIG. 5 satisfies the qualitative conditions at this point. On the other hand, as the concretization of this configuration draft progresses, due to the above constraints, a Server_x type component (the component with id "v1") needs to be connected to two Domain type components (the component with id "d1" and the component with id "d2"). This violates the qualitative condition that a Server_x type component cannot be connected to two Domain type components. In this way, the configuration draft shown in FIG. 5 cannot satisfy the two qualitative conditions simultaneously as the concretization progresses. Thus, the configuration draft shown in FIG. 5 results in a contradiction in the qualitative conditions as the concretization progresses, leading to a situation where further concretization cannot be carried out.

[0042] The satisfaction probability regarding the qualitative condition is the probability of reaching a configuration draft that is fully concretized and satisfies the qualitative condition from the configuration draft to be evaluated. The satisfaction probability regarding the qualitative condition can also be said to be the probability of reaching a fully concretized configuration draft without becoming an incompletely concretized state from the configuration draft to be evaluated, on the premise that the adequacy of the constraint conditions regarding the evaluation index is not an issue.

[0043] The fulfillment probability for the qualitative condition may be defined as, but is not limited to, "the ratio of the number of configuration drafts that are completely instantiated and satisfy the qualitative condition to the number of configuration drafts that are completely instantiated among the configuration drafts reachable from the configuration draft to be evaluated." Various definitions of the fulfillment probability for the qualitative condition are possible depending on the definition of the selection probability of each instantiation method in the branching of the instantiation methods.

[0044] The qualitative condition estimation unit 123 estimates the likelihood that a configuration draft that is completely concretized and satisfies the qualitative conditions will be obtained when concretization proceeds from the configuration draft to be evaluated indicated by the configuration information, and returns an index value indicating the estimation result to the overall evaluation unit 121 as the probability of fulfillment of the qualitative conditions. The qualitative condition estimation unit 123 may evaluate the configuration information using a graph neural network (GNN) to obtain the fulfillment probability for the qualitative condition.

[0045] This GNN is obtained by performing machine learning using training data that is a combination of configuration drafts and the probability that the instantiation of the configuration draft will not be incomplete. In this case, the training data is obtained by repeatedly performing design trials on a large number of configuration drafts and calculating the probability that the instantiation of the configuration draft will not be incomplete for each configuration draft. The definition formula for the satisfaction probability of qualitative conditions can be used as a formula for calculating the probability that the instantiation of the configuration draft will not be incomplete.

[0046] However, the method by which the qualitative condition estimation unit 123 calculates the fulfillment probability of the qualitative condition is not limited to a specific method. For example, the qualitative condition estimation unit 123 may calculate the fulfillment probability of the qualitative condition using a learning model other than the GNN.

[0047] When the quantitative condition estimation unit 124 obtains the configuration information of the configuration draft to be evaluated output by the configuration information materialization unit 110 via the comprehensive evaluation unit 121, it calculates the satisfaction probability regarding the quantitative conditions of the configuration draft and the expected value of the quality, and returns the obtained satisfaction probability and expected value to the comprehensive evaluation unit 121.

[0048] The quantitative conditions of the configuration draft are the quantitative conditions among the conditions that the configuration draft should satisfy. Specifically, the quantitative conditions of the configuration draft are the conditions regarding the evaluation indicators for the constituent elements included in the configuration draft, and are shown in the configuration information as the constraint conditions that the constituent elements should satisfy as described above. The quantitative conditions of the configuration draft are also simply referred to as quantitative conditions.

[0049] The satisfaction probability regarding the quantitative conditions is the probability of reaching a configuration draft that is fully materialized and satisfies the quantitative conditions from the configuration draft to be evaluated. The satisfaction probability regarding the quantitative conditions can also be said to be the probability that the constraint conditions regarding each evaluation indicator are satisfied when the configuration draft to be evaluated reaches a fully materialized configuration plan as a result of subsequent materialization.

[0050] The satisfaction probability regarding the quantitative conditions may be defined as "the ratio of the number of fully materialized configuration drafts that satisfy the quantitative conditions to the number of fully materialized configuration drafts among the configuration drafts reachable from the configuration draft to be evaluated", but is not limited to this. Depending on the definition of the selection probability of each materialization method in the branch of the materialization method, various definitions of the satisfaction probability regarding the quantitative conditions are possible.

[0051] The quality of the configuration draft is represented by the evaluation indicators for the constituent elements included in the configuration draft. The quality of the configuration draft is also simply referred to as quality. As the expected value of the quality, the expected value at the end of each materialization, that is, the expected value of the quality when reaching a fully materialized configuration draft from the configuration draft to be evaluated, is used.

[0052] FIG. 6 is a diagram showing an example of the configuration of the quantitative condition estimation unit 124. In the configuration shown in FIG. 6, the quantitative condition estimation unit 124 includes a single-entity evaluation unit 241, an AI (Artificial Intelligence) model selection unit 242, a probability density function parameter calculation unit 243, a probability density function calculation unit 244, a satisfaction probability calculation unit 245, and an expected value calculation unit 246. The single-entity evaluation unit 241 is configured to be able to transfer data with each of the comprehensive evaluation unit 121, the AI model selection unit 242, the probability density function parameter calculation unit 243, the probability density function calculation unit 244, the satisfaction probability calculation unit 245, and the expected value calculation unit 246.

[0053] FIG. 7 is a diagram showing an example of data transfer in the quantitative condition estimation unit 124. When the single-entity evaluation unit 241 of the quantitative condition estimation unit 124 receives the configuration information of the configuration draft to be evaluated from the comprehensive evaluation unit 121, the probability density function calculation unit 244 calculates, for each evaluation index (for example, the maximum number of connections that a certain component can provide) of each component included in the configuration draft, a probability density function representing the probability distribution for each index value when reaching the fully specified configuration draft from the configuration draft. Then, the single-entity evaluation unit 241 calculates the satisfaction probability regarding the quantitative condition and the expected value of the quality based on the obtained probability density function, the constraint conditions, and the priority information. The probability density function calculation unit 244 corresponds to an example of a probability distribution estimation means.

[0054] Specifically, the individual evaluation unit 241 extracts one evaluation index of one component included in the configuration draft to be evaluated, passes the evaluation index to the AI model selection unit 242, and receives a pre-trained GNN from the AI model selection unit 242. At this time, the AI model selection unit 242 uniquely determines a pre-trained GNN based on the type of the evaluation index and the type of the component to which the evaluation index applies, and passes it to the individual evaluation unit 241. The transfer of the pre-trained GNN can be performed, for example, by transferring the pre-trained model data of the GNN. In this case, the individual evaluation unit 241 (the receiving side of the pre-trained GNN) can obtain the pre-trained GNN by setting the received model data to the GNN (before learning).

[0055] The individual evaluation unit 241 sends the pre-trained GNN, the configuration information of the configuration draft to be evaluated, the id of the component extracted from the configuration draft to be evaluated, and the label of the evaluation index (identification information of the evaluation index) to the probability density function parameter calculation unit 243, and receives the probability density function parameter value from the probability density function parameter calculation unit 243.

[0056] Here, the probability density function parameter is information including one or more sets of three pieces of information: the mean μ, the variance σ, and the mixing coefficient π. A set of parameters of the mean μ, the variance σ, and the mixing coefficient π represents one normal distribution (Gaussian distribution). In particular, a probability density function forming one normal distribution can be restored from a set of information on the mean μ and the variance σ. The mixing coefficient π is a parameter representing the weight of each probability density function when there are a plurality of probability density functions.

[0057] For example, when synthesizing each probability density function composed of two sets of parameters to generate one probability density function, when the mixing coefficient of the first set is π1 and the mixing coefficient of the second set is π2, the values may be adjusted so that the ratio of the areas of the respective probability density functions is π1 to π2 and then synthesized. To synthesize two probability density functions, the values may simply be added together and then normalized so that the total probability is 1.

[0058] The pre-trained GNN can be obtained by performing machine learning by giving the GNN the learning data of a set of a configuration draft, evaluation metrics, and probability density function parameters in advance (before the start of design by the system design device 100). The learning data of the set of the configuration draft, evaluation metrics, and probability density function parameters required for learning can be obtained by repeatedly conducting design trials on a large number of configuration drafts in advance, collecting samples of the values obtained by observing the values of the evaluation metrics in the design results, and performing calculations for estimating the likelihood (calculations for estimating the probability density distribution of the evaluation metric values).

[0059] However, the method by which the probability density function parameter calculation unit 243 obtains the parameters of the probability density function is not limited to a specific method. For example, the probability density function parameter calculation unit 243 may use a pre-trained learning model other than the GNN to obtain the parameters of the probability density function.

[0060] The single-entity evaluation unit 241 passes the probability density function parameters to the probability density function calculation unit 244 and receives the probability density function from the probability density function calculation unit 244. The probability density function calculation unit 244 restores the normal distribution from the received probability density function parameters, adjusts the values of each normal distribution using the mixing coefficient as the weight coefficient, and then synthesizes them to restore the probability density function.

[0061] The single-entity evaluation unit 241 passes the probability density function and the constraint conditions to the satisfaction probability calculation unit 245 and receives the satisfaction probability from the satisfaction probability calculation unit 245. The satisfaction probability calculation unit 245 obtains the probability that the values within the range indicated by the constraint conditions (values that satisfy the constraint conditions) are obtained in the probability density function. Specifically, the satisfaction probability calculation unit 245 obtains the integral value (area) of the probability density for the range indicated by the constraint conditions and uses this as the satisfaction probability. The satisfaction probability calculation unit 245 corresponds to an example of the satisfaction probability calculation means.

[0062] The single-entity evaluation unit 241 passes all combinations of all the evaluation metrics with assigned priorities to the expected value calculation unit 246 and receives the expected value of the quality. The expected value calculation unit 246 calculates the expected value from the probability density function for each evaluation metric, multiplies it by the priority, sums up the values for all the evaluation metrics, and uses this as the expected value of the quality of the configuration draft to be evaluated. The expected value calculation unit 246 corresponds to an example of an expected value calculation means.

[0063] Here, for example, regarding the evaluation metric related to network bandwidth and the evaluation metric related to cost, the value ranges of the values that can be obtained are different, and also the optimization objectives of the evaluation metric values, such as whether to maximize or minimize, are different. Due to such differences in the value ranges or objectives of the evaluation metrics, simply adding the values obtained by multiplying the priority to the expected value may result in a meaningless value.

[0064] Therefore, when the expected value calculation unit 246 calculates the expected value from the probability density function, in order to align the value ranges and objectives of the expected values obtained from each evaluation metric, for each type of evaluation metric, post-processing predetermined for the expected value may be added. For example, the expected value calculation unit 246 may perform normalization on the expected value so as to align the value range of the expected value within the range of 0 to 1. Also, in order to align the objectives of the expected values, for the evaluation metrics to be minimized, the expected value calculation unit 246 may subtract the normalized expected value from 1.

[0065] The comprehensive evaluation unit 121 receives the verification result of the consistency of the constraint conditions from the constraint condition verification unit 122 for the configuration draft to be evaluated. Also, the comprehensive evaluation unit 121 receives the satisfaction probability regarding the qualitative conditions from the qualitative condition estimation unit 123 for the configuration draft to be evaluated. Also, the comprehensive evaluation unit 121 receives, for the configuration draft to be evaluated, from the quantitative condition estimation unit 124, the satisfaction probability regarding the quantitative conditions for each component and each evaluation metric, and the expected value of the quality of that configuration draft.

[0066] If the overall evaluation unit 121 obtains a verification result from the constraint condition verification unit 122 indicating that the constraint conditions are contradictory, the configuration draft to be evaluated may be rejected, and the estimation of the fulfillment probability for the qualitative conditions by the qualitative condition estimation unit 123, and the estimation of the fulfillment probability for the quantitative conditions and the calculation of the expected value of quality by the quantitative condition estimation unit 124 may be omitted.

[0067] The overall evaluation unit 121 adopts the minimum value of the fulfillment probability for the qualitative conditions and the fulfillment probability for the quantitative conditions for each component and each evaluation index as the fulfillment probability of the configuration draft. These fulfillment probabilities are fulfillment probabilities for conditions that must be met. Therefore, the overall evaluation unit 121 focuses on the minimum value of these fulfillment probabilities and evaluates the configuration draft with the highest possible value as the most promising configuration draft.

[0068] Alternatively, the overall evaluation unit 121 may calculate a single evaluation value for each configuration draft by weighting and summing the adopted fulfillment probabilities and expected values using separately determined weight values. There is a trade-off between the time required to derive a configuration plan and the quality of the derived configuration plan, and the weight value indicates which of the two is emphasized. If the weight value of the fulfillment probability is relatively increased, the probability of obtaining a configuration plan increases, but the obtained quality tends to be lower. Conversely, if the weight value of the expected value is relatively increased, it becomes easier to obtain a high-quality configuration, but it becomes more difficult to derive a configuration plan. The weight value may be set to a specific value in advance, or may be specified by the user via the input / output unit 140.

[0069] As described above, components and relationships are collectively referred to as components. Each component may be assigned an ID and a type name that indicates the type of the component. In addition, each component may be assigned an attribute value. In addition to nodes and edges, the configuration information may also include constraints that the nodes and edges must satisfy and priorities of evaluation indices.

[0070] As a method of expressing configuration information, there are a graphical expression method and a text expression method. Figure 8 is a diagram showing an example of the graphical expression of configuration information. In the example of Figure 7, circles represent nodes. Also, as in the example of Figure 2, arrows connecting the circles represent edges. In the graphical expression of configuration information, the type names of the components are omitted from the description and are expressed by differences in the icons' designs. An example of the correspondence between the icon designs and the type names is shown in the legend of Figure 2.

[0071] Also, in the graphical expression of configuration information, the description of the relationship type name may be omitted. In the graphical expression of configuration information, the id of the component may be shown beside the circle. The display of this component id may also be omitted. In the graphical expression of configuration information, the constraint conditions may be listed as an expression below the configuration information. In the example of Figure 8, the id with a dollar sign "$" at the beginning indicates that it refers to an id defined elsewhere.

[0072] Figure 9 is a diagram showing an example of the text expression of configuration information. Figure 9 shows an example of the text expression of the same configuration information as Figure 8. In the first embodiment, as an example of the text expression of configuration information, the case of expressing it in YAML format will be described. Specifically, the configuration information includes a list of nodes, a list of edges, and a list of constraint conditions. Each node has an id and a type defined. Each edge has the id of the source node, the type of relationship, and the id of the destination node defined. Note that the description of the edges is exemplified in the configured form after concretization included in each concretization rule described in Figure 12.

[0073] The two elements separated by a comma within the parentheses "<>" appended after the relationship type name exemplified in Figure 12 are each the type name of a node, specifying the type of node designated for each of the source and destination of that relationship. The part where the node type is not specified is indicated by an asterisk "*". In the constraint conditions, the conditions regarding the values of the evaluation indices for each component are listed as an expression. In terms of priority, the priority values for each evaluation index are specified. However, the text-based representation method of the configuration information is not limited to a specific method.

[0074] FIG. 10 is a diagram showing an example of the definition of the type of a component. FIG. 8 shows examples of the definitions of six types, namely, "System", "App", "Lb", "Server", "ServerSmall", and "ServerLarge". In the definition of the type of each component, any one or a combination of the inheritance source (parent, source of inherit), abstract flag, properties, provided functions, utilized functions, and expected peripheral configuration can be specified.

[0075] For the inheritance source, the type name of another component from which the type of that component inherits is specified. Since System, App, Lb, and Server are basic classes, they do not inherit from anything. In contrast, ServerSmall and ServerLarge inherit from Server. A type that inherits from another type inherits information regarding properties, provided functions, utilized functions, and expected peripheral configuration from the inheritance source. In a type that inherits from another type, the display of the information inherited from the inheritance source is omitted.

[0076] The abstract flag is a flag indicating whether the component of that type is an abstract component. The Server-type component is abstract, while the components of the other five types are concrete. For properties, the attribute values that the component of that type has are defined. For each attribute value, the type of the value is defined.

[0077] For provided functions, the relationships that are assumed to be connected to the component of that type from other components are defined. For utilized functions, the relationships that are assumed to connect from the component of that type to other components are defined.

[0078] The expected surrounding configuration shows the configuration around the component of that type that should be satisfied for the component of that type to operate. For example, for an App-type component to operate, a Server-type component is required, and the App-type component must be connected to the Server-type component in a HostedOn relationship. In the expected surrounding configuration of the App type, a surrounding configuration representing such a situation is defined. Note that in Figure 10, the reference destination in Figure 12 is shown for the expected surrounding configuration, and specific descriptions are omitted in Figure 10. Multiple expected surrounding configurations may be specified. When multiple expected surrounding configurations are specified, it is interpreted that any one of the surrounding configurations may be satisfied.

[0079] Figure 11 is a diagram showing an example of the definition of a relationship type. Figure 11 shows examples of the definitions of three relationship types: "Include<System, *>", "HostedOn<*, Server>", and "ConnTo<Lb, App>". In the definition of each relationship type, the inheritance source, the abstract flag, and the expected surrounding configuration can be specified. Include<System, *> is a relationship type representing the relationship in which a System-type component includes some component. HostedOn<*, Server> is a relationship type representing the relationship in which some component is hosted on a Server-type component. ConnTo<Lb, App> is a relationship type representing the relationship in which an Lb-type component and an App-type component are communicatively connected.

[0080] For the inheritance source, specify the type name of other relationships that the relationship of that type inherits. The abstract flag is a flag indicating whether the relationship of that type is an abstract relationship. In the expected surrounding configuration, the configuration around the relationship of that type that should be satisfied for the relationship of that type to operate is shown.

[0081] FIG. 12 is a diagram showing an example of the definition of the concretization rules. FIG. 12 shows examples of the definitions of six types of concretization rules: concretization rule 1-1, concretization rule 1-2, concretization rule 2, concretization rule 3, concretization rule 4-1, and concretization rule 4-2. As described above, the concretization rule is a conversion rule for rewriting the system configuration. In other words, the concretization rule is information indicating a method for concretizing the configuration information.

[0082] In the definition of each concretization rule, it is possible to specify the concretization target, the assumed surrounding configuration, and the configuration after concretization. For the concretization target, the type name of the component to be concretized is specified. In the example of FIG. 12, each concretization rule has only one component as the concretization target, and only one component is concretized in one-step concretization.

[0083] For the assumed surrounding configuration, the surrounding configuration that should be satisfied in advance when applying the concretization rule is specified. That is, the concretization rule is applicable only when the configuration shown in the assumed surrounding configuration is recognized around the component of the concretization target.

[0084] For the configuration after concretization, the configuration remaining after the concretization rule is applied is specified. When the concretization rule is applied, the component of the concretization target will be replaced with the configuration shown in the configuration after concretization. For example, the concretization rule 2 is a rule for hosting an App-type component on a Server-type component. The "$_self" described in the configuration after concretization indicates the component to be concretized, and thus the component to be concretized is preserved even after concretization. In addition, in the concretization rule 2, a new Server-type node (component) is prepared, and the node indicated by $_self and the above Server-type node are connected in a HostedOn-type relationship. Furthermore, in the concretization rule 2, a constraint condition is added to the added Server-type node (v1). Here, it is specified as a condition that the value of $v1.mem, which is a property indicating the amount of memory that v1 has, must be equal to or more than one-tenth of the value of $_self.conn, which is a property indicating the maxConnection of the App. This condition is represented as a constraint condition with $v1.mem as an evaluation index in the configuration draft after concretization by the concretization rule 2. Also, the concretization rule 4-1 is a rule for replacing an abstract Server-type component with a specific ServerSmall-type component.

[0085] Figure 2 shows an example of how the system requirements described in Figure 6 are gradually concretized based on the definitions and rules shown in Figures 10, 11, and 12. For example, by applying the concretization rule 1-1 described in Figure 12 to the node s1 in the system configuration R11 of Figure 2, a configuration draft R12 is generated. Also, by applying the concretization rule 4-1 or 4-2 to the abstract Server-type node generated by applying the concretization rule 2 described in Figure 12 to the node a1 of the configuration draft R12, a configuration draft R14 or a configuration draft R15 is generated.

[0086] Each component is determined to be concrete when two conditions are met: the abstract flag of its type is true and the expected surrounding configuration is satisfied. A configuration draft is determined to be concrete when all the components it contains are concrete.

[0087] The set of configuration drafts on the tree thus obtained is referred to as a configuration draft tree. From one system requirement, a huge number of configuration drafts can be generated. On the other hand, instead of actually generating all the configuration drafts that can be generated, by narrowing down to promising configuration drafts that satisfy the conditions and proceeding with the implementation, the system configuration can be efficiently derived. At this time, just using the expression of the constraint conditions cannot always sufficiently narrow down the configuration drafts. For example, in FIG. 2, the configuration where the constraint conditions conflict is only the configuration draft R14, and the other configuration drafts R15, R16, and R17 can all satisfy the constraint conditions.

[0088] On the other hand, among the configurations that satisfy the constraint conditions, differences in performance can occur. FIG. 13 is a diagram showing an example of a situation regarding the distribution of the observed probability of the value of s1.conn. s1.conn is an evaluation index representing the performance of the system. The graphs D11 to D17 of the probability distributions shown in FIG. 13 show the distributions of the observed probabilities of the values of s1.conn expected in the system configurations R11 to R17 shown in FIG. 2. Here, the configuration drafts R14 and R15 are both single configurations, while the configuration drafts R16 and R17 are both multiple configurations. In this regard, the probabilities in the graphs D16 and D17 of the probability distributions are distributed at higher performance values than the graphs D14 and D15 of the probability distributions.

[0089] Also, in the configuration drafts R14 and R16, low-performance servers are used, while in the configuration drafts R15 and R17, high-performance servers are used. In this regard, the probabilities in the graphs D15 and D17 of the probability distributions are distributed at higher performance values than the graphs D14 and D16 of the probability distributions.

[0090] The configuration draft R12 is the configuration draft in the process of deriving the configuration draft R14 or R15. Therefore, the graph D12 of the probability distribution is the graph of the distribution synthesized from the graphs D14 and D15 of the probability distribution. Similarly, the configuration draft R13 is the configuration draft in the process of deriving the configuration draft R16 or R17. Therefore, the graph D13 of the probability distribution is the graph of the distribution synthesized from the graphs D16 and D17 of the probability distribution.

[0091] In this case, since the system configuration that exhibits the highest performance is the system configuration of the configuration draft R17, when at least only the performance is considered as a condition, it is desirable to be induced to the configuration draft R17 in the search of the configuration draft tree. If the GNN can correctly estimate the actual situation, the probability distribution shown in FIG. 13 can be generated during the search.

[0092] The system design device 100 can determine that the configuration draft R13 is more promising by calculating the area in the range of s1.conn >= 100 for the probability distributions shown in the graphs D12 and D13 of the probability distribution to calculate the satisfaction probability. Similarly, the system design device 100 can determine that the configuration draft R17 is more promising by calculating the area in the range of s1.conn >= 100 for the probability distributions shown in the graphs D16 and D17 of the probability distribution to calculate the satisfaction probability.

[0093] On the other hand, the performance only needs to satisfy the constraint conditions. If it is desired to consider the optimal design considering both performance and price within that range, it is not always desirable to be induced to the configuration draft R17. For example, when the priority of price is high, it may be desirable to be induced to the configuration draft R15 with fewer components or the configuration draft R16 with lower server performance.

[0094] If the GNN can correctly estimate the situation for each evaluation metric, a probability distribution regarding price can be generated during the search, similar to the probability distribution regarding performance illustrated in FIG. 13. For each probability distribution, the system design apparatus 100 can calculate the expected values of s1.conn, which is an evaluation metric for performance, and s1.cost, which is an evaluation metric for price, and calculate the evaluation score for each configuration draft by multiplying each by a weight and adding them together. Thereby, the system design apparatus 100 can determine that a configuration draft with a higher evaluation score is more promising.

[0095] The evaluation score for each of these configuration drafts is also referred to as an optimization score. The optimization here refers to the optimization of system design, that is, the optimization to make the design result system requirements match the user's wishes as much as possible. This optimization may also be the optimization of the values of the evaluation metrics specified by the user. For example, this optimization may be to perform optimization such as making the values of the evaluation metrics specified by the user as large as possible or as small as possible according to the priorities specified by the user.

[0096] Next, the operation of the system design apparatus 100 will be described. FIG. 14 is a flowchart showing an operation example of the system design apparatus 100. First, an overall outline of the operation will be described. First, the configuration information concretization unit 110 receives an input of system requirements from the user terminal device 300 via the input / output unit 140 (step S101). Subsequently, the configuration information concretization unit 110 gradually concretizes the system requirements (steps S102 to S108), and outputs the fully concretized system configuration to the user terminal device 300 via the input / output unit 140 (step S109).

[0097] As the stepwise concretization, the configuration information concretization unit 110 first performs first-stage concretization (steps S102 to S106) and determines whether a specific configuration draft is included in the obtained plurality of configuration drafts (S106). The configuration information instantiation unit 110 determines that a configuration draft is concrete if all of the components contained in the configuration draft are concrete. The configuration information instantiation unit 110 determines that a component is concrete if two conditions are met: the abstract flag of the component type is true, and the expected peripheral configuration of the component is satisfied. Information on the component type required to determine whether a configuration draft is concrete is stored in the storage unit 130, and the configuration information instantiation unit 110 reads this information from the storage unit 130.

[0098] If it is determined that a specific configuration draft is included (step S106: YES), the configuration information instantiating unit 110 outputs the specific configuration draft as the design result system configuration (step S109). After step S109, the system design device 100 ends the processing of FIG.

[0099] On the other hand, if it is determined in step S106 that no concrete configuration draft is included (step S106: NO), the configuration information instantiation unit 110 determines whether or not any other abstract configuration drafts remain in the configuration draft tree (step S107). Specifically, the configuration information instantiation unit 110 determines whether or not there are any generated configuration drafts that have not been rejected and to which the instantiation rules can be applied.

[0100] If it is determined that abstract configuration drafts remain (step S107: YES), the configuration information instantiation unit 110 selects one of the remaining abstract configuration drafts to be instantiated next (step S108) and performs one stage of instantiation again. That is, after step S108, the process returns to step S102.

[0101] On the other hand, if the configuration information instantiation unit 110 determines that no abstract configuration drafts remain (step S107: NO), further design consideration is not possible, and the system design device 100 performs a process that is predetermined as a process to be performed in the event of a design failure (step S110). After step S110, the system design apparatus 100 ends the process of FIG. 14.

[0102] In the first-stage concretization, the configuration information concretization unit 110 performs a process of generating a configuration draft by applying applicable concretization rules to the system requirements input in step S101 or the configuration draft selected as the next configuration draft to be concretized in step S108 (step S102). When there are multiple applicable concretization rules, the configuration information concretization unit 110 generates multiple configuration drafts. On the other hand, when there are no applicable concretization rules, the configuration information concretization unit 110 does not generate a configuration draft. That is, the configuration information concretization unit 110 fails to generate a configuration draft.

[0103] Information on the component types required for generating the configuration draft (for example, the information shown in FIGS. 10 and 11) and information on the concretization rules (for example, the information in FIG. 12) are stored in the storage unit 130. The configuration information concretization unit 110 reads out this information from the storage unit 130. Then, the configuration information concretization unit 110 determines whether one or more configuration drafts have actually been generated (step S103).

[0104] If it is determined that no configuration draft has been generated (step S103: NO), since the first-stage concretization fails, the configuration information concretization unit 110 proceeds to the concretization of other configuration drafts on the configuration draft tree. Specifically, in the case of step S103: NO, the process proceeds to step S107.

[0105] On the other hand, if it is determined in step S103 that one or more configuration drafts have been generated (S103: YES), the configuration information concretization unit 110 passes each generated configuration draft to the configuration evaluation unit 120 and receives an evaluation result (step S104). Based on the evaluation results given to each configuration draft in step S104, the configuration information concretization unit 110 selects the next configuration draft to be concretized in step S108.

[0106] In the process of step S104, when the configuration evaluation unit 120 receives the configuration draft to be evaluated from the configuration information concretization unit 110, the comprehensive evaluation unit 121 passes the configuration draft to be evaluated to the constraint condition verification unit 122 and receives the verification result from the constraint condition verification unit 122.

[0107] The comprehensive evaluation unit 121 determines whether there is a contradiction in the constraint conditions of the configuration draft to be evaluated by referring to the received verification result. If it is determined that there is a contradiction in the constraint conditions, the comprehensive evaluation unit 121 returns a determination result that the configuration draft to be evaluated should be rejected to the configuration information concretization unit 110.

[0108] On the other hand, if it is determined that there is no contradiction in the constraint conditions, the comprehensive evaluation unit 121 passes the configuration draft to the qualitative condition estimation unit 123 and receives the satisfaction probability regarding the qualitative conditions from the qualitative condition estimation unit 123. The comprehensive evaluation unit 121 determines whether the received satisfaction probability regarding the qualitative conditions is equal to or greater than a predetermined threshold. If it is determined that the satisfaction probability regarding the qualitative conditions is less than the threshold, the comprehensive evaluation unit 121 returns a determination result that the configuration draft to be evaluated should be rejected to the configuration information concretization unit 110.

[0109] On the other hand, if it is determined that the satisfaction probability regarding the qualitative conditions is equal to or greater than the threshold, the comprehensive evaluation unit 121 passes the configuration draft to the quantitative condition estimation unit 124 and receives the satisfaction probability regarding the quantitative conditions and the expected value of quality from the quantitative condition estimation unit 124. The comprehensive evaluation unit 121 selects the minimum value from the satisfaction probability regarding the qualitative conditions and the satisfaction probabilities regarding the plurality of quantitative conditions, and sets this value as the satisfaction probability of the configuration draft to be evaluated. Also, the comprehensive evaluation unit 121 weights and sums the satisfaction probability of the configuration draft to be evaluated and the expected value, and returns the obtained value to the configuration information concretization unit 110 as the evaluation value of the configuration draft to be evaluated.

[0110] When the quantitative condition estimation unit 124 receives the configuration draft to be evaluated from the comprehensive evaluation unit 121, the individual evaluation unit 241 extracts each evaluation index for each component in the configuration draft. For each evaluation index, the quantitative condition estimation unit 124 performs selection of an AI model by the AI model selection unit 242, calculation of probability density function parameters by the probability density function parameter calculation unit 243, calculation of a probability density function by the probability density function calculation unit 244, and calculation of the satisfaction probability regarding the quantitative condition by the satisfaction probability calculation unit 245. Further, the individual evaluation unit 241 passes the set of all evaluation indexes with priorities and the priorities to the expected value calculation unit 246, and the expected value calculation unit 246 calculates the expected value of quality. The individual evaluation unit 241 returns the satisfaction probabilities regarding the obtained plurality of quantitative conditions and the expected value of one quality to the comprehensive evaluation unit 121.

[0111] Next, the input / output unit 140 will explain an example of a GUI (Graphical User Interface) screen to be displayed on the user terminal device 300. The input / output unit 140 may be provided with a display screen to display the GUI screen. FIG. 15 is a diagram showing an example of a design screen that the input / output unit 140 causes the user terminal device 300 to display. In the example of FIG. 15, the area A11 is an area for the user to edit system requirements. The area A11 is also referred to as a requirements editing pane.

[0112] The area A12 is an area where the designed result system configuration is displayed. The area A12 is also referred to as a design result confirmation pane. The area A13 is an area where a list of selectable components is displayed. The area A13 is also referred to as a list display area of selectable components.

[0113] The area A14 is an area where a list of evaluation indexes for which the user can set constraint conditions (quantitative conditions) and a bar for setting the values of the constraint conditions related to the evaluation indexes are displayed. The bar displayed in the area A14 is also referred to as a quantitative condition adjustment bar. The area A14 is also referred to as a display area of the quantitative condition adjustment bar.

[0114] In area A15, a list of evaluation metrics that can be specified by the user as optimization targets, check boxes for selecting whether to optimize each evaluation metric, and a bar for adjusting the optimization priority are displayed. The bar displayed in area A15 is also referred to as the priority adjustment bar. Area A15 is also referred to as the display area for the selection options of the metrics to be optimized and the priority adjustment bar.

[0115] However, the method by which the user terminal device 300 accepts input of the optimization priority is not limited to the method using the display of the bar. For example, the user terminal device 300 may display buttons for accepting user operations to increase the optimization priority and buttons for accepting user operations to decrease the optimization priority in area A15, and be configured to accept user operations for increasing or decreasing the optimization priority.

[0116] Area A15 corresponds to an example of a user operation area. The user terminal device 300 corresponds to an example of a display device. The optimization priority corresponds to an example of a weight value set for each evaluation metric. The input / output unit 140 that acquires the optimization priority from the user terminal device 300 corresponds to an example of an input / output means. The check box displayed in area A15 corresponds to an example of an icon for accepting a user operation indicating whether to use the evaluation metric for evaluating the system configuration.

[0117] The user edits the system requirements by selecting a desired component from the components listed in area A13 and operating the adjustment bars and check boxes listed in areas A14 and A15. Thus, according to the design screen shown in FIG. 15, the user can edit the system requirements while selecting the desired conditions to be considered in the system requirements.

[0118] As described above, the probability density function calculation unit 244 estimates the probability distribution of the values of the evaluation metrics for the system configuration obtained by materializing a candidate system configuration to be materialized in the system design by materializing the system configuration. The expected value calculation unit 246 calculates the expected value of the evaluation metrics based on the probability distribution of the values of the evaluation metrics. The configuration information materialization unit 110 selects one of the candidate system configurations to be materialized based on the expected value of the evaluation metrics, and materializes the selected system configuration.

[0119] In this way, by the configuration information materialization unit 110 selecting the system configuration to be materialized based on the expected value of the evaluation metrics, it is expected to select a system configuration such that the value of the evaluation metrics of the performance desired by the user is high. According to the system design apparatus 100, in this regard, it is expected to obtain a system configuration that satisfies the specified constraint conditions and satisfies the constraint conditions at a relatively high level for the performance desired by the user.

[0120] Also, the expected value calculation unit 246 calculates the expected value for each of the plurality of evaluation metrics for one system configuration. The configuration information materialization unit 110 weights and sums the expected values for each of the plurality of evaluation metrics using the weight values set for each evaluation metric, and selects one of the candidate system configurations to be materialized based on the obtained total value. According to the system design apparatus 100, system design can be performed in consideration of a plurality of evaluation metrics.

[0121] Also, the input / output unit 140 accepts the setting of the weight values by the user of the system design apparatus 100. According to the system design apparatus 100, in terms of performing system design according to the weight values set by the user for each of the plurality of evaluation metrics, it is expected that the wishes of the user can be more accurately reflected in the system design.

[0122] Further, the satisfaction probability calculation unit 245 calculates the probability that the constraint conditions set for the evaluation index are satisfied based on the probability distribution of the values of the evaluation index for the embodied system configuration. The configuration information embodiment unit 110 selects one of the candidate system configurations to be embodied based on the expected value of the evaluation index and the probability that the constraint conditions are satisfied. According to the system design device 100, it is possible to achieve both the satisfaction of the specified constraint conditions and relatively high performance desired by the user.

[0123] Also, the qualitative condition estimation unit 123 estimates the probability that the qualitative conditions regarding the embodied system configuration are satisfied when the candidate system configuration to be embodied is embodied. The configuration information embodiment unit 110 selects one of the candidate system configurations to be embodied based on the expected value of the evaluation index, the probability that the constraint conditions are satisfied, and the minimum value among the probabilities that the qualitative conditions are satisfied.

[0124] According to the system design device 100, by selecting the candidate system configuration to be embodied based on the minimum value of the probability that the conditions that are highly likely to prevent the success of the system design are satisfied, it is expected that a system configuration that is relatively easy to succeed in system design can be selected. According to the system design device 100, in this regard, it is expected that the system design can be performed efficiently.

[0125] Also, the constraint condition verification unit 122 determines whether there is a contradiction in the constraint conditions set for each evaluation index with respect to the candidate system configuration to be embodied. When it is determined that there is a contradiction in the constraint conditions, the probability density function calculation unit 244 suppresses the estimation of the probability distribution. According to the system design device 100, in terms of suppressing the estimation of the probability distribution, the processing load can be reduced, and it is expected that the time required for system design can be relatively short.

[0126] In addition, the user terminal device 300 displays a user operation area for receiving an input of a weight value for each of a plurality of evaluation indices for the system configuration generated in the system design. It is expected that the system design apparatus 100 can obtain a system configuration that more appropriately reflects the user's wishes by performing system design based on the weights set by the user.

[0127] In addition, the user terminal device 300 displays an icon for receiving a user operation for instructing whether or not to use at least one of a plurality of evaluation indices for the system configuration generated in the system design in the evaluation of the system configuration. The user can specify the evaluation indices to be used in the evaluation of the system configuration by operating on the display screen. In this regard, it is possible to relatively easily specify the evaluation indices to be used in the evaluation of the system configuration. It is expected that the system design apparatus 100 can obtain a system configuration that more appropriately reflects the user's wishes by performing system design according to the user's specification.

[0128] <Second Embodiment> FIG. 16 is a diagram showing an example of the configuration of the system design apparatus according to the second embodiment. In the configuration shown in FIG. 16, the system design apparatus 610 includes a probability distribution estimation unit 611, an expected value calculation unit 612, and a system configuration concretization unit 613. With such a configuration, the probability distribution estimation unit 611 estimates the probability distribution of the values of the evaluation indices for the concretized system configuration when concretizing a system configuration that is a candidate for the concretization target in the system design by concretizing the system configuration. The expected value calculation unit 612 calculates the expected value of the evaluation index based on the estimated probability distribution. The system configuration concretization unit 13 selects one of the system configurations that are candidates for the concretization target based on the expected value of the evaluation index, and concretizes the selected system configuration. The probability distribution estimation unit 611 corresponds to an example of probability distribution estimation means. The expected value calculation unit 612 corresponds to an example of expected value calculation means. The system configuration concretization unit 13 corresponds to an example of system configuration concretization means.

[0129] In this way, by the system configuration concretization unit 613 selecting a system configuration to be concretized based on the expected value of the evaluation index, it is expected to select a system configuration such that the value of the evaluation index of the performance desired by the user becomes high. According to the system design apparatus 610, in this regard, it is expected to obtain a system configuration that satisfies the specified constraint conditions and satisfies the constraint conditions at a relatively high level for the performance desired by the user.

[0130] <Third Embodiment> FIG. 17 is a flowchart showing an example of the processing procedure in the system design method according to the third embodiment. The system design method shown in FIG. 17 includes estimating a probability distribution (step S611), calculating an expected value (step S612), and concretizing a system configuration (step S613). In estimating a probability distribution (step S611), the computer estimates the probability distribution of the value of the evaluation index for the concretized system configuration when concretizing a system configuration that is a candidate for concretization in the system design by concretizing the system configuration. In calculating an expected value (step S612), the expected value of the evaluation index is calculated based on the estimated probability distribution. In concretizing a system configuration (step S613), based on the expected value of the evaluation index, one of the system configurations that are candidates for concretization is selected, and the selected system configuration is concretized.

[0131] In this way, in the system design method shown in FIG. 17, by selecting a system configuration to be concretized based on the expected value of the evaluation index, it is expected to select a system configuration such that the value of the evaluation index of the performance desired by the user becomes high. According to the system design method shown in FIG. 17, in this regard, it is expected to obtain a system configuration that satisfies the specified constraint conditions and satisfies the constraint conditions at a relatively high level for the performance desired by the user.

[0132] FIG. 18 is a schematic block diagram illustrating the configuration of a computer according to at least one embodiment. In the configuration shown in FIG. 18, a computer 700 includes a CPU 710, a main memory device 720, an auxiliary memory device 730, an interface 740, and a non-volatile recording medium 750.

[0133] One or more of the above-described system design device 100, user terminal device 300, and system design device 610, or a part thereof, may be implemented in a computer 700. In this case, the operation of each of the above-described processing units is stored in the auxiliary storage device 730 in the form of a program. The CPU 710 reads the program from the auxiliary storage device 730, loads it into the main storage device 720, and executes the above-described processing in accordance with the program. The CPU 710 also allocates a storage area in the main storage device 720 in accordance with the program. Communication between each device and other devices is performed by an interface 740 having a communication function and performing communication under the control of the CPU 710. The interface 740 also has a port for a nonvolatile storage medium 750, and reads information from the nonvolatile storage medium 750 and writes information to the nonvolatile storage medium 750.

[0134] When the system design device 100 is implemented in a computer 700, the operations of the configuration information instantiation unit 110 and the configuration evaluation unit 120 are stored in the form of a program in an auxiliary storage device 730. The CPU 710 reads the program from the auxiliary storage device 730, loads it into the main storage device 720, and executes the above-described processing in accordance with the program.

[0135] Furthermore, the CPU 710 allocates a storage area corresponding to the storage unit 130 in the main storage device 720 in accordance with the program. Communication with other devices via the input / output unit 140 is performed by the interface 740 having a communication function and operating under the control of the CPU 710 . The display by the input / output unit 140 is performed by the interface 740 having a display device and displaying various images under the control of the CPU 710. The reception of user operations by the input / output unit 140 is executed by the interface 740 having input devices such as a keyboard and a mouse to receive user operations and output information indicating the received user operations to the CPU 710.

[0136] When the user terminal device 300 is implemented in the computer 700, the operations of the user terminal device 300 are stored in the auxiliary storage device 730 in the form of a program. The CPU 710 reads the program from the auxiliary storage device 730, expands it in the main storage device 720, and executes the above processing according to the program.

[0137] Also, the CPU 710 secures a storage area in the main storage device 720 for the user terminal device 300 to perform processing according to the program. The communication between the user terminal device 300 and other devices is executed by the interface 740 having a communication function and operating according to the control of the CPU 710. The interaction between the user terminal device 300 and the user is executed by the interface 740 having a display device and an input device and operating according to the control of the CPU 710.

[0138] When the system design device 610 is implemented in the computer 700, the operations of the probability distribution estimation unit 611, the expected value calculation unit 612, and the system configuration concretization unit 613 are stored in the auxiliary storage device 730 in the form of a program. The CPU 710 reads the program from the auxiliary storage device 730, expands it in the main storage device 720, and executes the above processing according to the program.

[0139] Also, the CPU 710 secures a storage area in the main storage device 720 for the system design device 610 to perform processing according to the program. The communication between the system design device 610 and other devices is executed by the interface 740 having a communication function and operating according to the control of the CPU 710. The interaction between the system design device 610 and the user is executed by the interface 740 having a display device and an input device and operating according to the control of the CPU 710.

[0140] One or more of the above-described programs may be recorded on the non-volatile recording medium 750. In this case, the interface 740 may read the program from the non-volatile recording medium 750. Then, the CPU 710 may directly execute the program read by the interface 740, or may temporarily store it in the main storage device 720 or the auxiliary storage device 730 and then execute it.

[0141] Note that a program for executing all or part of the processing performed by the system design device 100, the user terminal device 300, and the system design device 610 may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be read into a computer system and executed to perform the processing of each part. Here, the "computer system" is assumed to include hardware such as an OS and peripheral devices. Also, the "computer-readable recording medium" refers to a portable medium such as a flexible disk, a magneto-optical disk, a ROM (Read Only Memory), a CD-ROM (Compact Disc Read Only Memory), or a storage device such as a hard disk built into a computer system. Further, the above program may be for realizing a part of the above-described functions, and may also be a program that can be realized in combination with a program already recorded in the computer system for realizing the above-described functions.

[0142] As described above, the embodiments of the present invention have been described in detail with reference to the drawings. However, the specific configuration is not limited to this embodiment, and designs and the like within the scope not departing from the gist of the present invention are also included.

[0143] Some or all of the above embodiments may be described as follows in the appended claims, but are not limited thereto.

[0144] (Appendix 1) Probability distribution estimation means for estimating a probability distribution of values of evaluation indices for a concretized system configuration when concretizing a system configuration that is a candidate for concretization in system design by concretizing the system configuration, Expected value calculation means for calculating an expected value of the evaluation index based on the probability distribution, System configuration concretization means for selecting one of the system configurations that are candidates for concretization based on the expected value of the evaluation index and concretizing the selected system configuration, A system design device comprising the same. (Appendix 2) The expected value calculation means calculates an expected value for each of a plurality of evaluation indices for one system configuration, The system configuration concretization means weights and sums the expected values for each of the plurality of evaluation indices using weight values set for each evaluation index, and selects one of the system configurations that are candidates for concretization based on the obtained total value. The system design device according to Appendix 1. (Appendix 3) The system design device further comprises input / output means for receiving setting of the weight value by a user of the system design device. The system design device according to Appendix 2. (Appendix 4) The system design device further comprises satisfaction probability calculation means for calculating a probability that a constraint condition set for the evaluation index is satisfied based on the probability distribution, The system configuration concretization means selects one of the system configurations that are candidates for concretization based on the expected value of the evaluation index and the probability that the constraint condition is satisfied. The system design device according to any one of Appendices 1 to 3. (Appendix 5) The system design device further comprises qualitative condition estimation means for estimating a probability that a qualitative condition regarding the concretized system configuration is satisfied when the system configuration that is a candidate for concretization is concretized. The system configuration concretization means selects one of the candidate system configurations to be concretized based on the expected value of the evaluation index, the probability that the constraint condition is satisfied, and the minimum value among the probabilities that the qualitative condition is satisfied. The system design apparatus according to Supplementary Note 4. (Supplementary Note 6) The system further includes constraint condition verification means for determining whether there is a contradiction in the constraint conditions set for each evaluation index with respect to the candidate system configuration to be concretized. When it is determined that there is a contradiction in the constraint conditions, the probability distribution estimation means suppresses the estimation of the probability distribution. The system design apparatus according to any one of Supplementary Notes 1 to 5. (Supplementary Note 7) A display device that displays a user operation area for receiving an input of a weight value for each evaluation index for a system configuration generated in system design. (Supplementary Note 8) A display device that displays an icon for receiving a user operation for instructing whether to use at least one of a plurality of evaluation indexes for evaluating a system configuration generated in system design. (Supplementary Note 9) A computer Estimates a probability distribution of the values of the evaluation indexes for the concretized system configuration when concretizing a candidate system configuration to be concretized in system design by concretizing the system configuration. Calculates the expected value of the evaluation index based on the probability distribution. Based on the expected value of the evaluation index, selects one of the candidate system configurations to be concretized, and concretizes the selected system configuration. A system design method including this. (Supplementary Note 10) To a computer Estimating the probability distribution of the value of an evaluation index for a system configuration obtained by materializing a candidate system configuration to be materialized in system design by materializing the system configuration, and calculating an expected value of the evaluation index based on the probability distribution, and selecting one of the candidate system configurations to be materialized based on the expected value of the evaluation index, and materializing the selected system configuration, and A recording medium for recording a program for causing the above to be executed.

Industrial Applicability

[0145] The present invention may be applied to a system design apparatus, a display apparatus, a system design method, and a recording medium.

Explanation of Signs

[0146] 1 Design system 100, 610 System design apparatus 110 Configuration information materialization unit 120 Configuration evaluation unit 121 Comprehensive evaluation unit 122 Constraint condition verification unit 123 Qualitative condition estimation unit 124 Quantitative condition estimation unit 130 Storage unit 140 Input / output unit 241 Individual evaluation unit 242 AI model selection unit 243 Probability density function parameter calculation unit 244 Probability density function calculation unit 245 Satisfaction probability calculation unit 246, 612 Expected value calculation unit 300 User terminal device 611 Probability distribution estimation unit 613 System configuration materialization unit

Claims

1. Probability distribution estimation means for estimating a probability distribution of values of evaluation indicators for a system configuration obtained by materializing a candidate system configuration to be materialized in system design by materializing the system configuration, Expected value calculation means for calculating an expected value of the evaluation indicator based on the probability distribution, System configuration materialization means for selecting any one of the candidate system configurations to be materialized based on the expected value of the evaluation indicator and materializing the selected system configuration, A system design apparatus comprising:

2. The expected value calculation means calculates an expected value for each of a plurality of evaluation indicators for one system configuration, The system configuration materialization means weights and sums the expected values for each of the plurality of evaluation indicators using weight values set for each evaluation indicator, and selects any one of the candidate system configurations to be materialized based on the obtained total value. The system design apparatus according to claim 1.

3. Further comprising input / output means for receiving setting of the weight value by a user of the system design apparatus, The system design apparatus according to claim 2.

4. The input / output means displays a user operation area for receiving input of the weight value. The system design apparatus according to claim 3.

5. The input / output means displays an icon for receiving a user operation for instructing whether or not to use at least one of the plurality of evaluation indicators in evaluating the system configuration. The system design apparatus according to claim 3 or claim 4.

6. Further comprising satisfaction probability calculation means for calculating a probability that a constraint condition set for the evaluation indicator is satisfied based on the probability distribution, The system configuration materialization means selects any one of the candidate system configurations to be materialized based on the expected value of the evaluation indicator and the probability that the constraint condition is satisfied. The system design apparatus according to any one of claims 1 to 5.

7. Further comprising qualitative condition estimation means for estimating a probability that a qualitative condition regarding the materialized system configuration is satisfied when the candidate system configuration to be materialized is materialized, The system configuration materialization means selects any one of the candidate system configurations to be materialized based on the expected value of the evaluation indicator, the probability that the constraint condition is satisfied, and the minimum value among the probability that the qualitative condition is satisfied. The system design device according to claim 6.

8. The system further includes constraint condition verification means for determining whether there is a contradiction in the constraint conditions set for each evaluation index with respect to the system configuration that is a candidate for the object to be materialized. When it is determined that there is a contradiction in the constraint conditions, the probability distribution estimation means suppresses the estimation of the probability distribution. The system design device according to any one of claims 1 to 7.

9. A computer estimates a probability distribution of the value of an evaluation index for a materialized system configuration when a system configuration that is a candidate for the object to be materialized in system design by materializing the system configuration is materialized. Based on the probability distribution, calculates an expected value of the evaluation index. Based on the expected value of the evaluation index, selects any one of the system configurations that are candidates for the object to be materialized, and materializes the selected system configuration. A system design method including the above.

10. In a computer estimating a probability distribution of the value of an evaluation index for a materialized system configuration when a system configuration that is a candidate for the object to be materialized in system design by materializing the system configuration is materialized; calculating an expected value of the evaluation index based on the probability distribution; selecting any one of the system configurations that are candidates for the object to be materialized based on the expected value of the evaluation index, and materializing the selected system configuration; A program for causing the above to be executed.

Images