System design device, system design method, and program

Abstract

This invention adopts a configuration element selection method that is indicated in constraint condition generation information, which is linked to system configuration information indicating a subject system configuration that is one of candidates to be subjected to system design involving repeated application of an implementation rule to a system configuration that includes an abstract configuration element, and which indicates a method for generating a constraint condition for a subject system configuration. In accordance with said method, this system design device: selects one or more configuration elements of a subject system configuration; applies the method for generating a constraint condition indicated in the constraint condition generation information or the system configuration information to information set to the selected configuration element(s), thereby generating a constraint condition for the subject system configuration; determines whether the subject system configuration can satisfy the constraint condition; and, when it is determined that the subject system configuration cannot satisfy the constraint condition, excludes the subject system configuration from the candidates to be subjected to system design, and applies the implementation rule to the candidates to be subjected to system design, thereby advancing design of the system.

Description

System design device, system design method, and recording medium

[0001] The present invention relates to a system design device, a system design method, and a recording medium.

[0002] Several technologies related to system design have been proposed. For example, a system configuration derivation device described in Patent Document 1 concretizes an abstract configuration, which is a system configuration that has uncertain parts, so as to satisfy quantitative requirements required for the system, and obtains a concrete configuration, which is a system configuration that does not have uncertain parts.

[0003] In addition, when the system configuration derivation device described in Patent Document 2 applies concretization rules to the configuration requirements of the system to be constructed to update the configuration requirements, it calculates a score indicating the degree of appropriateness of the concretization rules based on a calculation method obtained by machine learning, and determines the concretization rules to be applied to the configuration requirements of the system to be constructed based on the score.

[0004] Furthermore, Patent Document 3 describes a client-server system configuration support method that supports the task of calculating the costs of clients and servers that realize multiple operations. In this method, a requirement specification model that can represent various requirement specifications and an optimal configuration of the client and server hardware and software that realizes this requirement specification model are prepared as a system configuration model that is classified into shared items and individual items.

[0005] This method selects a requirements specification model according to the user's systemization work, and then selects a system configuration model for each selected requirements specification model. This method then integrates items that can be integrated in the selected system configuration model, integrates the cost unit prices of the shared items and individual items per client and server in the system configuration model, and calculates the cost from the number of clients and servers.

[0006] In addition, the system configuration derivation device described in Patent Document 4 generates system configuration information that shows the configuration of a system that does not include any uncertain parts by using concretization rules to concretize the uncertain parts of abstract configuration information that shows the configuration of a system that includes uncertain parts.

[0007] Furthermore, Non-Patent Document 1 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.

[0008] Japanese Patent Publication No. 2021-135625 International Publication No. 2019 / 244446 Japanese Patent Publication No. 07-152809 International Publication No. 2019 / 216082

[0009] Takuya KUWAHARA, Takayuki KURODA, Takao OSAKI, Kozo SATODA, “An Intent-Based System Configuration Design for IT / NW Services with Functional and Quantitative Constraints”, IEICE Transactions on Communications Vol.E104-B, No.7, pp.791-804, 2021

[0010] In system design by repeatedly applying the concretization rules to the system configuration, if it is possible to determine with higher accuracy whether the system configurations that are candidates for the system design can satisfy the constraints, it is possible to eliminate system configurations that cannot satisfy the constraints from the candidates, and in this respect, the system design can be carried out efficiently. In particular, it is preferable to be able to determine whether multiple components of the system configuration can satisfy the constraints, not just two components whose relationship is directly shown.

[0011] An example of an object of the present invention is to provide a system design device, a system design method, and a recording medium that can solve the above-mentioned problems.

[0012] According to a first exemplary aspect of the present invention, a system design apparatus includes: a constraint generation means linked to system configuration information indicating a target system configuration that is one of candidates for system design by repeatedly applying concatenation rules to a system configuration including abstract components; a constraint generation means that selects one or more components of the target system configuration based on a component selection method indicated in constraint generation information that indicates a method for generating constraints for the target system configuration, and generates constraints for the target system configuration based on information set in the selected components and the concatenation rules or the constraint generation method indicated in the constraint generation information; a constraint verification means that determines whether the target system configuration can satisfy the constraints; a candidate narrowing means that, when the constraint verification means determines that the target system configuration cannot satisfy the constraints, excludes the target system configuration from the candidates for system design; and a concatenation means that proceeds with the system design by applying the concatenation rules to the candidates for system design.

[0013] According to a second exemplary aspect of the present invention, a system design apparatus includes: constraint generation information registration means for accepting input of constraint generation information indicating a method for generating constraints to be satisfied by a system configuration that is a candidate for system design by repeatedly applying concretization rules to a system configuration including abstract components; constraint generation means for generating constraints to be satisfied by a target system configuration based on system configuration information indicating a target system configuration that is one of the candidate targets for system design and the constraint generation information; constraint verification means for determining whether the target system configuration can satisfy the constraints; candidate narrowing means for excluding the target system configuration from the candidate targets for system design when it is determined that the target system configuration cannot satisfy the constraints; and concretization means for advancing the system design by applying the concretization rules to the candidate targets for system design.

[0014] According to a third exemplary aspect of the present invention, a system design method is linked to system configuration information indicating a target system configuration that is one of candidates for system design by repeatedly applying concatenation rules to a system configuration including abstract components, and includes: selecting one or more components of the target system configuration based on a component selection method indicated in constraint generation information that indicates a method for generating constraints for the target system configuration; generating constraints for the target system configuration based on information set for the selected components and the concatenation rules or the constraint generation method indicated in the constraint generation information; determining whether the target system configuration can satisfy the constraints; and, if it is determined that the target system configuration cannot satisfy the constraints, excluding the target system configuration from candidates for system design, and proceeding with the system design by applying the concatenation rules to the candidates for system design.

[0015] According to a fourth exemplary aspect of the present invention, a recording medium is a recording medium that records a program for causing a computer to execute the following operations: linking to system configuration information indicating a target system configuration that is one of candidates for system design by repeatedly applying concatenation rules to a system configuration including abstract components, selecting one or more components of the target system configuration based on a component selection method indicated in constraint generation information that indicates a method for generating constraints for the target system configuration, generating constraints for the target system configuration based on information set in the selected components and the concatenation rules or the constraint generation method indicated in the constraint generation information, determining whether the target system configuration can satisfy the constraints, excluding the target system configuration from the candidates for system design if it is determined that the target system configuration cannot satisfy the constraints, and proceeding with the system design by applying the concatenation rules to the candidates for system design.

[0016] According to the present invention, it is possible to determine whether or not a plurality of components of a system configuration can satisfy constraint conditions, even for components other than those whose relationships are directly indicated.

[0017] 8 is a diagram showing an example of the configuration of a system design device according to the first embodiment. FIG. 9 is a diagram showing an example of an expression of a system configuration according to the first embodiment. FIG. 10 is a diagram showing an example of a system configuration expressed in text according to the first embodiment. FIG. 11 is a diagram showing an example of system requirements according to the first embodiment. FIG. 12 is a diagram showing an example of definitions of component parts according to the first embodiment. FIG. 13 is a diagram showing an example of definitions of relationships between component parts according to the first embodiment. FIG. 14 is a diagram showing an example of definitions of concretization rules according to the first embodiment. FIG. 15 is a diagram showing an example of concretization of a system configuration performed by the system design device according to the first embodiment using system requirements, components, and concretization rules. FIG. 16 is a diagram showing a list of constraints that must be satisfied by the system configuration obtained by the concretization in FIG. 10. FIG. 17 is a diagram showing an example of the flow of processing performed by the constraint condition generation unit according to the first embodiment by executing a configuration search means. FIG. 18 is a flowchart showing an example of the procedure of processing performed by the system design device according to the first embodiment. FIG. 19 is a diagram showing an example of definitions of App_X2 representing a specific application used in the second embodiment, Machine representing an abstract machine, and Machine_Z2 representing a specific machine. FIG. 19 is a diagram showing an example of definitions of concretization rules used by the system design device in the second embodiment. FIG. 19 is a diagram showing an example of definitions of component parts of a processing topology according to the second embodiment. FIG. 19 is a diagram showing an example of graphical representation of six types of relationships necessary for constructing a processing topology according to the second embodiment. FIG. 10 is a diagram showing an example of a textual expression of six types of relationships necessary for constructing a processing topology in the second embodiment. FIG. 11 is a diagram showing a first example of a definition of a processing topology instantiation rule in the second embodiment. FIG. 12 is a diagram showing a second example of a definition of a processing topology instantiation rule in the second embodiment. FIG. 13 is a diagram showing a third example of a definition of a processing topology instantiation rule in the second embodiment. FIG. 14 is a diagram showing a fourth example of a definition of a processing topology instantiation rule in the second embodiment. FIG. 15 is a diagram showing a fifth example of a definition of a processing topology instantiation rule in the second embodiment. FIG. 16 is a diagram showing an example of a definition of a system requirement in the second embodiment. FIG. 17 is a diagram showing a first example of a system configuration instantiation in the second embodiment. FIG. 18 is a diagram showing a second example of a system configuration instantiation in the second embodiment. FIG. 19 is a diagram showing a third example of a system configuration instantiation in the second embodiment.1 is a diagram showing a fourth example of a specific system configuration according to the second embodiment. FIG. 2 is a diagram showing a fifth example of a specific system configuration according to the second embodiment. FIG. 3 is a diagram showing a sixth example of a specific system configuration according to the second embodiment. FIG. 4 is a flowchart showing an example of a processing procedure by which a constraint generation unit according to the second embodiment generates constraints. FIG. 5 is a diagram showing an example of a constraint generated by a constraint generation unit according to the second embodiment based on the TATConstraintOf2(1000,20) function. FIG. 6 is a diagram showing an example of a constraint generated by a constraint generation unit according to the second embodiment based on the ResourceConstraintOf() function using constraint generation example 1. FIG. 7 is a diagram showing an example of a constraint generated by a constraint generation unit according to the second embodiment based on the ResourceConstraintOf() function using constraint generation example 2. FIG. 8 is a diagram showing an example of a configuration of a system design device according to a third embodiment. FIG. 9 is a diagram showing an example of a configuration of a system design device according to a fourth embodiment. FIG. 10 is a diagram showing an example of a configuration of a system design device according to a fifth embodiment. FIG. 11 is a diagram showing an example of a processing procedure in a system design method according to a sixth embodiment. FIG. 12 is a schematic block diagram showing the configuration of a computer according to at least one embodiment.

[0018] 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.

[0019] <First Embodiment> (Configuration Description) Fig. 1 is a diagram showing an example of the configuration of a system design device according to a first embodiment. In the configuration shown in Fig. 1, a system design device 80 includes an input / output unit 10, a system design unit 20, a constraint verification unit 30, a design information recording unit 40, a constraint condition generation unit 50, a constraint function recording unit 60, and a constraint function registration unit 70. The system design unit 20 includes a candidate narrowing unit 21 and a concretization unit 22.

[0020] The system design device 80 performs system design by repeatedly applying the concretization rules to the system configuration indicated by the input system requirement information. The system design device 80 may be configured using a computer such as a personal computer (PC) or a workstation (WS).

[0021] System requirement information is information indicating the requirements that a user of the system design device 80 expects from the system being designed. The system requirement information includes information indicating the system configuration that the system being designed should have. The system requirement information may further include information indicating functional requirements that the system being designed should satisfy, information indicating non-functional requirements that the system being designed should satisfy, or either one of these. The requirements indicated by the system requirement information are also referred to as system requirements. The user of the system design device 80 is also simply referred to as the user.

[0022] The system configuration information is information indicating a system configuration obtained during the system design performed by the system design device 80, or information indicating a concretized system configuration finally obtained in the system design performed by the system design device 80. The system configuration information includes information indicating a system configuration obtained by repeatedly concretizing the system configuration indicated by the system requirement information by applying concretization rules. The system configuration information is also simply referred to as configuration information.

[0023] The system configuration information may further include information indicating the functional requirements included in the system requirements information as they are realized in accordance with the system configuration, and / or information indicating the non-functional requirements included in the system requirements information as they are realized in accordance with the system configuration.

[0024] The following describes an example in which the system design device 80 performs automatic system design. The automatic design here refers to the system design device 80 acquiring system requirement information and then acquiring a system design result without requiring user operation. The system design result here refers to information obtained as a result of the system design performed by the system design device 80.

[0025] The system design device 80 obtains, as a system design result, information indicating a specific system configuration that satisfies the system requirements, or information indicating that the system design has failed. A failure in the system design means that a specific system configuration that satisfies the system requirements has not been obtained.

[0026] However, the system design device 80 may also be configured to accept user instructions during system design. For example, when selecting one of the candidates for the system configuration to be realized, if the system design device 80 accepts a user operation to specify one of the candidates, the specified candidate may be selected.

[0027] The input / output unit 10 inputs and outputs data from and to the outside of the system design device 80. The input / output unit 10 may be equipped with a display device such as a liquid crystal panel and input devices such as a mouse and keyboard, and function as a user interface. The input / output unit 10 may also have a communication function and communicate with other devices.

[0028] The input / output unit 10 receives input of system requirements and passes the input system requirements to the system design unit 20. The input / output unit 10 also receives configuration information of a specific system configuration that satisfies the system requirements, obtained as a result of the system design, from the system design unit 20, and outputs the obtained configuration information. If the input / output unit 10 does not receive configuration information of a specific system configuration that satisfies the system requirements from the system design unit 20, it may output a message indicating that the system design has failed.

[0029] The system design unit 20 acquires system requirement information from the input / output unit 10 and derives a system configuration that satisfies the system requirements. The concretization unit 22 of the system design unit 20 acquires concretization rules from the design information recording unit 40 according to the system configuration to be concretized, and concretizes the system configuration in stages by applying the concretization rules to the system configuration to be concretized. The concretization unit 22 corresponds to an example of a concretization means.

[0030] The candidate narrowing unit 21 of the system design unit 20 also passes system configuration information indicating the system configuration under design to the constraint condition generation unit 50 and receives information indicating the constraint conditions that the system configuration must satisfy. The candidate narrowing unit 21 also passes the constraint conditions included in the system configuration information and all of the constraint conditions generated by the constraint condition generation unit 50 to the constraint verification unit 30. The candidate narrowing unit 21 then receives a verification result from the constraint verification unit 30 as to whether the system configuration under design satisfies the constraint conditions. The candidate narrowing unit 21 proceeds with the concretization by limiting the system configurations to be concretized to those that satisfy the constraint conditions. Furthermore, the system design unit 20 returns the system configuration information obtained as the system design result or information indicating that the system design has failed to the input / output unit 10. The candidate narrowing unit 21 is an example of a candidate narrowing means.

[0031] The constraint verification unit 30 receives constraint conditions that the system configuration must satisfy from the system design unit 20, and verifies whether or not those constraint conditions are contradictory. The constraint verification unit 30 then returns the verification results to the system design unit 20. The constraint verification unit 30 is an example of a constraint verification means.

[0032] The design information recording unit 40 stores various information related to the system configuration, such as definition information and instantiation rules for the system components, and various information related to the instantiation of the system configuration. The design information recording unit 40 provides this information in response to a request from the system design unit 20.

[0033] The constraint condition generation unit 50 receives system configuration information of a system in the process of being designed from the system design unit 20. The constraint condition generation unit 50 also receives constraint functions that define specific means for outputting constraint conditions included in the system configuration information from the constraint function recording unit 60. The constraint condition generation unit 50 then generates constraint conditions based on the structure of the system configuration and the properties assigned to the system configuration, and returns the obtained constraint conditions to the system design unit 20. The constraint condition generation unit 50 is an example of constraint condition generation means.

[0034] The process in which the constraint generating unit 50 acquires system configuration information from the system design unit 20 and generates constraints is performed not only for system configurations for which instantiation has been completed, but also for system configurations in the process of being designed. For example, the system design unit 20 may pass the system configuration information to the constraint generating unit 50 each time it applies one instantiation rule to a system configuration in the process of being designed, and the constraint generating unit 50 may generate constraints. However, the timing at which the constraint generating unit 50 generates constraints is not limited to a specific timing.

[0035] The system configuration for which the constraint generating unit 50 generates constraints is also referred to as a target system configuration. The target system configuration is a system configuration that is being considered as a candidate for system design and is being examined to determine whether or not to exclude it from the system design.

[0036] The constraint function recording unit 60 stores constraint functions, which are functions including definitions of specific means for outputting constraint conditions that the system configuration should satisfy, and returns the constraint functions in response to a request from the constraint condition generating unit 50. The constraint function recording unit 60 corresponds to an example of constraint condition generation information storage means.

[0037] A constraint function is information that includes definitions of specific means for outputting constraints that must be satisfied by the system configuration, and outputs the constraints. If the constraint function has arguments, it outputs constraints according to the input argument values. The constraint function is called a "function" because it outputs constraints. Specifically, the constraint generation unit 50 executes the means indicated in the constraint function to generate constraints.

[0038] The constraint function is an example of constraint generation information, which is information indicating a method for generating constraints. However, the constraint generation information handled by the system design device 80 is not limited to information expressed in the form of a constraint function. For example, the constraint generation information may be configured as a module (subroutine) without a return value, and the generated constraints may be stored in global variables. Alternatively, the constraint generation information may be configured simply as information rather than a program, and the constraint generation unit 50 may operate while referring to the constraint generation information to generate constraints.

[0039] The constraint function registration unit 70 receives definition information of a constraint function as an input and records the input definition information of the constraint function in the constraint function recording unit 60. A user can set a constraint function in the constraint function recording unit 60 via the constraint function registration unit 70. The constraint function registration unit 70 corresponds to an example of constraint condition generation information registration means.

[0040] The system requirement information and system configuration information will be further explained. In both the system requirement information and the system configuration information, the system configuration is expressed by nodes and edges. The nodes represent the components that make up the system, and the edges represent the relationships between the components. The components and their relationships are collectively called components. Any information that represents the characteristics of the component can be set for the component. Furthermore, constraints can be set for the nodes or edges, which are conditions that the node or edge itself, or other nodes or edges, must satisfy.

[0041] Figure 2 is a diagram showing an example of a system configuration representation. In the example in Figure 2, circles represent nodes. Arrows connecting the circles represent edges. Names attached to nodes indicate the type names of component parts. Names attached to edges indicate the type names of relationships. Dotted lines represent abstract components, and solid lines represent concrete components.

[0042] Figure 2 shows that an App_X node, which represents a specific application program, is running on some machine. The system configuration shown in Figure 2 uses nodes and edges to express that "the App_X node is connected to an abstract Machine node through a HostedOn relationship." An application program is also called an application.

[0043] The method of representing the system configuration is not limited to the diagrammatic representation exemplified in FIG. 2. For example, the system configuration may be represented in text. The method of representing the system configuration in text is not limited to a specific method. Various representation methods can be used that can uniquely convert the textual representation of the system configuration into a diagrammatic representation of the system configuration.

[0044] FIG. 3 is a diagram showing an example of a system configuration expressed in text. The system configuration expressed in text includes a list of nodes and a list of edges. Each node included in the list of nodes is indicated with an identifier that identifies the node and the type of the node. Each edge included in the list of edges is indicated with the type of the edge, the identifier of the node from which the edge is connected, and the identifier of the node to which the edge is connected. In FIG. 3, "$" indicates a reference to the identifier of the variable name. For example, "$app" refers to an identifier named "app".

[0045] FIG. 4 is a diagram showing an example of system requirements. The system requirements are input by the user. FIG. 4 shows the requirement to build an environment in which an App_X node, which represents an application, runs. Furthermore, in FIG. 4, a maximum TAT value, which indicates the TAT (Turn Around Time) value that the App_X node can tolerate, is set as a property as a performance requirement that the App_X node must satisfy. The example in FIG. 4 shows that the performance requirement for the operating environment of the App_X node is to build a system in which the TAT is within 1 second (= 1000 milliseconds).

[0046] In the following explanation using a specific example, it is assumed that a TAT requirement (requirement regarding a TAT value) is specified in the system requirements, and a specific example is used in which it is assumed that a system configuration that satisfies the TAT requirement is designed. However, the requirements handled by the system design device 80 are not limited to a specific type of requirement.

[0047] Next, a method for defining components and instantiation rules will be described. FIG. 5 is a diagram showing an example of a component definition. As shown in FIG. 5, a component definition can specify information on the inheritance source, abstraction level, used functions, properties, and constraints. Because a component is represented by a node, the component is also referred to as a node, and the component definition is also referred to as a node definition. Furthermore, the node indicated in the definition is also referred to as the node type or the component type. In the example of FIG. 5, "App", "App_X", "OS", "OS_Y", "Machine", and "Machine_Z" are also referred to as node names and node type names.

[0048] The "Inheritance Source" item indicates the other components (component type) that the component being defined inherits from. If no inheritance source is specified, it means that nothing is inherited. By inheriting from another component, you can inherit the properties and constraints of the component from which you are inheriting.

[0049] The "abstraction level" item indicates whether the component being defined is an abstract component or a concrete component. The abstraction level is indicated by the value of a flag. If the abstraction level is true, it indicates that the component is an abstract component. If the abstraction level is false, it indicates that the component is a concrete component. In system design, when the abstraction levels of all components included in the system configuration are false and all components have the relationships defined in the usage functions, it means that the system configuration is completely concrete.

[0050] The "Used Function" item indicates the relationship required by the component being defined. In other words, the used function indicates that the component being defined must be connected to other components through the relationship defined by the used function. The "Property" item is information that represents the characteristics or attributes of the component being defined. The user can freely specify properties depending on the type of component. The "Constraint" item indicates the conditions that the component being defined must satisfy.

[0051] Figure 5(a) shows the definition of a component called App (App node) that represents an abstract application, and the definition of a component called App_X (App_X node) that represents a specific application. The definition of the App node indicates that an application must be installed on some operating system (OS) in order to run, as indicated by the HostedOn in the "Used Functions" item.<App, OS> This is expressed in the following relationship.

[0052] Furthermore, it is common for applications to have specified conditions (e.g., minimum specifications (specifications, performance)) required for the application to operate. To incorporate these conditions into the system design, the conditions can be set in the "Properties" item. In Figure 5(a), the properties for the required CPU and required memory are set in the App node, and the properties for the CPU and memory resources available to the application in the system configuration being designed are set as used CPU and used memory.

[0053] Here, specific values ​​are set for the required CPU and required memory according to the specific application. On the other hand, specific values ​​are not set in advance (before the system requirements are specified) for the used CPU and used memory. The settings for the used CPU and used memory are used to determine whether specific values ​​exist that can satisfy the conditions specified as constraints. In the App node in Figure 5(a), the item "Constraints" indicates that the amount of CPU and memory resources available to the App node must be greater than or equal to the required CPU and required memory.

[0054] The constraints specified for each component affect the constraints of other components during the process of realizing the system configuration. The system design is completed when the system design device 80 finally derives a system configuration that satisfies the constraints set for all components in the system configuration.

[0055] For example, the conditions that must be met for a certain App node are that the used CPU is equal to or greater than the required CPU, and the used memory is equal to or greater than the required memory, as shown in the "Constraints" section. As mentioned above, the used CPU indicates the CPU that the App node can use. The used memory indicates the memory that the App node can use.

[0056] On the other hand, the Machine node that hosts this App node has an upper limit on the CPU and memory that can be installed. The CPU and memory that the App node can use must be set to at least equal to or less than the CPU and memory installed on the Machine node. In this way, the "Constraints" item sets constraints that must be satisfied by each component or the entire system configuration.

[0057] In the definition of the App_X node in Figure 5(a), the "Inheritance Source" item indicates that the App_X node inherits from the App node. Specific values ​​are set in the "Properties" item. The "Properties" item indicates that the minimum specifications for running this application are a CPU of 1.8 GHz (gigahertz) or more and a memory of 500 MB (megabytes) or more. The "Properties" item also sets the service time of the App_X node to 100 ms (milliseconds), as a way of expressing the basic performance of this App_X node.

[0058] Furthermore, in the "Properties" item, a maximum TAT property is set, which specifies the maximum allowable TAT as a performance requirement expected of this application. The specific value of the maximum TAT is specified by the user in the system requirements, for example, as shown in the example of Figure 4.

[0059] As a method of expressing the constraints in the "Constraints" item, specific conditional expressions may be directly set. Alternatively, as in the example of FIG. 5, a function for outputting the constraints may be indicated. As described above, a function for outputting the constraints is called a constraint function. In the example of FIG. 5(a), "TATConstraintOf(Maximum TAT)" represents a constraint function that outputs a specific constraint on the response time to satisfy the TAT value (maximum TAT) given as input.

[0060] The definition of an operating system component also shows the same items as the definition of an application component. Figure 5(b) shows the definition of an OS node, which represents an abstract operating system, and the definition of an OS_Y node, which represents a specific operating system. The "Properties" item in the definition of OS_Y shows the required resource values, used resource values, and basic performance values.

[0061] 5(c) shows the definition of a Machine node representing an abstract machine and the definition of a Machine_Z node representing a specific machine. The "Properties" item in the definition of the Machine_Z node indicates the clock frequency and number of cores of the CPU and specific memory values ​​of the machine represented by the Machine_Z node.

[0062] FIG. 6 is a diagram showing an example of a definition of a relationship between components. The definition of a relationship shown in FIG. 6 shows each item, or some of these items, of the inheritance source, abstraction level, connection source and connection destination, and property. The inheritance source, abstraction level, and property are the same as those for components. The connection source and connection destination represent the type of the component at the connection source of the edge and the type of the component at the connection destination. If the type name is "*", it means that no particular type is specified.

[0063] In Figure 6, a relationship "HostedOn" is defined, which indicates that one node is hosted on another node. Also in Figure 6, a relationship "HostedOn(App, Machine)" is defined, which indicates that the source and destination are an App node and a Machine node, respectively, by inheriting the relationship "HostedOn." Furthermore, in Figure 6, a relationship "HostedOn(OS, Machine)" is defined, which indicates that the source and destination are an OS node and a Machine node, respectively, by inheriting the relationship "HostedOn."

[0064] 7 is a diagram showing an example of a definition of a concretization rule. The definition of a concretization rule includes items such as a concretization target, a desired peripheral configuration, a configuration after concretization, and constraint conditions, or some of these. The item "concretization target" indicates the target to be concretized (concretization target). A node or an edge is specified as the object to be concretized.

[0065] The "Expected Peripheral Configuration" item indicates the configuration that must be satisfied around the instantiation target as a prerequisite for instantiating the instantiation target. For example, if you want to define an instantiation rule that applies only to "OS nodes on which some application is installed" rather than to any OS node, you can enter the configuration information, such as "App node is connected to OS node by an edge called HostedOn(App, OS)," as the expected peripheral configuration in the "Expected Peripheral Configuration" item.

[0066] The item "Configuration after instantiation" indicates how the node or edge to be instantiated will be changed to after instantiation. The item "Constraints" indicates the conditions that the component must satisfy when applying the instantiation rule.

[0067] In the example shown in Figure 7, reification rule 1 reifies an abstract OS node into a concrete OS_Y node. Reification rule 2 reifies an abstract Machine node into a concrete Machine_Z node. Reification rule 3 targets the App node as the reification target and reifies the relationship that an OS node that hosts an application is required for the application to run. Reification rule 3 creates a new OS node and connects the App node and the OS node with an edge called HostedOn(App, OS).

[0068] Furthermore, the "Constraint" item in Instantiation Rule 3 indicates the constraint that each component must satisfy when applying Instantiation Rule 3 to a system configuration. Specifically, the "Constraint" item indicates the following conditions: the CPU specifications available to the operating system must be greater than or equal to the CPU specifications available to each program connected via the relationship between the OS node and HostedOn; and the sum of the memory available to these programs and the memory available to the operating system itself must be less than or equal to the value of the cumulative memory usage, which is a variable held by the OS node. Each program connected via the relationship between the OS node and HostedOn is represented by the identifier "program" in Instantiation Rule 3 in Figure 7.

[0069] This constraint also takes into account the case where multiple applications are installed in the operating system. This constraint indicates that the CPU specifications available to the operating system must be greater than or equal to the CPU specifications required by each of the one or more applications installed in the operating system, and that the cumulative memory usage (available memory amount) recognized by the operating system must be greater than or equal to the sum of the memory usage of each application installed in the operating system and the memory usage of the operating system itself.

[0070] The constraint expressions indicated in the constraint conditions of the concatenation rules correspond to examples showing a method for generating the constraint conditions indicated in the concatenation rules. The concatenation unit 22 applies the concatenation rules to the system configuration to concretize it, thereby concretizing the constraint expressions. The constraint condition generation unit 50 generates the constraint conditions by inputting values ​​into the constraint expressions. The constraint condition generation unit 50 extracts values ​​indicated in the properties of the components of the system configuration based on the constraint function, and inputs the extracted values ​​into the constraint expressions. Alternatively, the constraint verification unit 30 may input values ​​into the constraint expressions when determining whether the system configuration satisfies the constraint conditions.

[0071] In the example of Figure 7, the constraint expression "$os.usedCPU >= each($program.usedCPU)" and the constraint expression "$os.cumulative memory used >= $os.used memory + sum($program.usedmemory)" are both examples of methods for generating constraints indicated in the instantiation rules. A character string prefixed with "$" indicates a portion that will be instantiated by the instantiation unit 22 instantiating the system configuration. For example, in "$program.usedCPU", "$program" is replaced with the node type of a program, such as an operating system or application. For example, if "$program.usedCPU" is replaced with "App_X.usedCPU", the constraint generation unit 50 replaces this portion with the value indicated in the usedCPU property of the App_X node.

[0072] Both "each" and "sum" in the constraint expression can be expanded to multiple nodes extracted by the constraint generation unit 50 by executing a constraint function configuration search means described later. For "each," the constraint generation unit 50 generates a constraint expression for each extracted node. For "sum," the constraint generation unit 50 expands the "sum" term into the sum of the values ​​indicated in the properties of each extracted node.

[0073] Instantiation rule 4 instantiates the relationship that an operating system indicated by an OS node requires a machine on which to install that operating system in order to run. Instantiation rule 4 specifies that the OS node is the object of instantiation, a new Machine node is generated, and the OS node and the Machine node are connected by an edge called HostedOn(OS, Machine).

[0074] The "Constraint" item in instantiation rule 4 indicates a constraint that takes into account the case where multiple operating systems are installed on one machine. This constraint indicates that the CPU specifications of the machine must be higher or equal to the CPU specifications required by each of the operating systems, and that the amount of memory installed on the machine must be higher or equal to the total memory usage recognized by each OS node hosted by the Machine node, i.e., the sum of the memory usage including the memory usage by the applications installed on each operating system.

[0075] Fig. 8 is a diagram showing an example of the instantiation of a system configuration performed by the system design device 80 using the system requirements, components, and instantiation rules defined in Fig. 4 to Fig. 7. Fig. 9 is a diagram showing a list of constraints that must be satisfied by the system configuration obtained by the instantiation in Fig. 8.

[0076] The system requirement S1 in Fig. 8 corresponds to the system requirement in Fig. 4. In the example of Fig. 8, the system design device 80 starts system design by specifying the system requirement S1 as the object of specification. Then, the system design device 80 applies specification rule 3 in Fig. 7 to the system requirement S1 to specify the system configuration S2, which includes the OS node required for the App_X node to operate.

[0077] Next, the system design device 80 applies concretization rule 1 to the system configuration S2 to obtain a system configuration S3 in which the OS node is concretized into an OS_Y node. After that, the system design device 80 applies concretization rule 4 to the system configuration S3 to obtain a system configuration S4 in which a Machine node necessary for the OS to run is provided. Then, the system design device 80 applies concretization rule 2 to the system configuration S4 to obtain a system configuration S5 in which the Machine node is concretized into a Machine_Z node.

[0078] Furthermore, the system design device 80 acquires a list of constraints shown in Fig. 9 based on the constraints specified by the types of the components and the constraints specified by the instantiation rules in the system design shown in Fig. 8. Specifically, when applying instantiation rule 3 to the system requirement S1, the system design device 80 assigns the property "Maximum TAT: 1000" shown in the system requirement of Fig. 4 to the constraint "TATConstraintOf (Maximum TAT)" shown in the definition of the App_X node of Fig. 5(a), and acquires the constraint "TATConstraintOf(1000)" shown in Fig. 9.

[0079] Furthermore, when applying concretization rule 3 to system requirement S1, the system design device 80 substitutes the property "required CPU: 1.8" shown in the definition of the App_X node for the constraint "used CPU >= required CPU" shown in the definition of the App node in FIG. 5(a), thereby obtaining the constraint "used CPU >= 1.8" shown in FIG. 9.

[0080] Furthermore, when applying concretization rule 3 to system requirement S1, the system design device 80 substitutes the property "required memory: 500" shown in the definition of the App_X node for the constraint "used memory >= required memory" shown in the definition of the App node in FIG. 5(a), thereby obtaining the constraint "used memory >= 500" shown in FIG. 9.

[0081] Furthermore, when applying instantiation rule 1 to system configuration S2, the system design device 80 substitutes the property "required CPU: 1.5" shown in the definition of the OS_Y node for the constraint "used CPU >= required CPU" shown in the definition of the OS node in FIG. 5(b) to obtain the constraint "used CPU >= 1.5" shown in FIG. 9.

[0082] Furthermore, when applying instantiation rule 1 to system configuration S2, the system design device 80 substitutes the property "required memory: 1000" shown in the definition of the OS_Y node for the constraint "used memory >= required memory" shown in the definition of the OS node in FIG. 5(b), thereby obtaining the constraint "used memory >= 1000" shown in FIG. 9.

[0083] Furthermore, when applying instantiation rule 3 to system requirement S1, the system design device 80 substitutes "type: APP_X" shown in the system requirement of Fig. 4 for the constraint expression "$os.used CPU >= each($program.used CPU)" shown in the definition of instantiation rule 3 of Fig. 7 to obtain the constraint expression "$os.used CPU >= App_X.used CPU". Furthermore, when applying instantiation rule 1 to system configuration S2, the system design device 80 substitutes the type "OS_Y" shown in the definition of OS_Y of Fig. 5 for the constraint expression "$os.used CPU >= App_X.used CPU" to obtain the constraint condition "OS_Y.used CPU >= App_X.used CPU" shown in Fig. 9.

[0084] Furthermore, when applying instantiation rule 3 to system requirement S1, system design device 80 substitutes "type: APP_X" shown in the system requirement of FIG. 4 for the constraint expression "$os. cumulative memory used >= $os. memory used + sum($program. memory used)" shown in the definition of instantiation rule 3 of FIG. 7 to obtain the constraint expression "$os. cumulative memory used >= $os. memory used + App_X. memory used."

[0085] Furthermore, when applying instantiation rule 1 to system configuration S2, system design device 80 substitutes the type "OS_Y" indicated in the definition of the OS_Y node in FIG. 5 into the constraint expression "$os. cumulative memory used >= $os. memory used + App_X. memory used" to obtain the constraint condition "OS_Y. cumulative memory used >= OS_Y. memory used + App_X. memory used" shown in FIG. 9.

[0086] Furthermore, when applying instantiation rule 4 to system configuration S3, the system design device 80 substitutes the type "OS_Y" shown in system configuration S4 into the constraint expression "$machine.CPU.clock frequency >= each($program.used CPU)" shown in instantiation rule 4, thereby obtaining the constraint expression "$machine.CPU.clock frequency >= OS_Y.used CPU". Then, when applying instantiation rule 2 to system configuration S4, the system design device 80 substitutes the property "CPU:clock frequency:2.6" shown in the definition of Machine_Z in FIG. 5C into the constraint expression "$machine.CPU.clock frequency >= OS_Y.used CPU", thereby obtaining the constraint condition "2.6 >= OS_Y.used CPU" shown in FIG.

[0087] Furthermore, when applying instantiation rule 4 to system configuration S3, the system design device 80 substitutes the type "OS_Y" shown in system configuration S4 into the constraint expression "$machine.memory >= sum($program.cumulatively used memory)" shown in instantiation rule 4, thereby obtaining the constraint expression "$machine.memory >= OS_Y.cumulatively used memory". When applying instantiation rule 2 to system configuration S4, the system design device 80 substitutes the property "memory: 32000" shown in the definition of Machine_Z in FIG. 5C into the constraint expression "$machine.memory >= OS_Y.cumulatively used memory", thereby obtaining the constraint condition "32000 >= OS_Y.cumulatively used memory" shown in FIG.

[0088] In the system configuration S5, there are no abstract components and the relationships required for the functions of each component are also satisfied. Therefore, the system design device 80 acquires the specific system configuration S5.

[0089] On the other hand, for the system design to be completed successfully, all constraints specified for the components of the system configuration and all constraints specified in the applied instantiation rules must be satisfied. If the constraints that the system configuration S5 shown in Figure 9 must satisfy are not contradictory, that is, if there are values ​​that satisfy all of these constraints, then the constraints of the system configuration can be said to be satisfied. Here, since the constraints on the response time are specified as constraint functions rather than specific conditional expressions, the constraint generator 50 generates specific constraints.

[0090] The following describes the constraint functions handled by the system design device 80, followed by a description of the process flow in which the constraint generator 50 generates constraints based on the constraint functions. The constraint functions are functions that output constraints that must be satisfied by the system configuration, and define a configuration search means and a constraint generation means. These definitions may be implemented using any means for describing data processing, and may be written in a general programming language such as Python.

[0091] For example, the constraint function may be configured as a function in a program, and the configuration search means and the constraint generation means may be configured as modules (subroutines) executed within the function. However, as described above, the constraint condition generation information handled by the system design device 80 is not limited to that expressed in the form of a constraint function.

[0092] The configuration search means is a means for extracting specific components from the system configuration. The constraint generation means is a means for generating constraint conditions based on information about the components extracted by the configuration search means. One example of the configuration search means is a method for extracting a series of components that are linked in a chain of relationships, such as a component that hosts a specified application and a component that further hosts that component, as components that affect the performance of an application for which a TAT requirement is specified.

[0093] Fig. 10 is a diagram showing an example of the flow of processing performed by the configuration search means executed by the constraint condition generation unit 50. In the processing shown in Fig. 10, the constraint condition generation unit 50 receives as input a system configuration for which a TAT requirement is specified among the components of the system (step F1), and extracts the components (step F2).

[0094] Then, the constraint generation unit 50 searches the system configuration and determines whether there is a HostedOn edge whose source is the component extracted in step F2 (step F3). If it determines that a corresponding HostedOn edge exists (step F3: YES), the constraint generation unit 50 selects a destination node of the HostedOn edge (step F4). After step F4, the process returns to step F2.

[0095] On the other hand, if it is determined in step F3 that there is no corresponding HostedOn edge (step F3: NO), the constraint condition generation unit 50 outputs all the components extracted up to that point (step F5). After step F5, the constraint condition generation unit 50 ends the process of FIG.

[0096] Furthermore, as a specific example of processing performed by the constraint generation unit 50 by executing the constraint generation means, it is conceivable to generate a constraint condition such that the sum of the service times set for the components extracted by the configuration search means should be equal to or less than the maximum TAT value specified by the argument of the constraint function.

[0097] The following describes the process flow for generating specific constraints when the constraint generation unit 50 receives the system configuration shown in S5 of FIG. 8, which includes the constraint function TATConstraintOf() equipped with the configuration search means and constraint generation means exemplified above. A constraint function name such as "TATConstraintOf" is an example of constraint function identification information that identifies the constraint function. The constraint function identification information is an example of constraint generation information identification information that identifies the constraint generation information. The constraint generation unit 50 receives the constraint function TATConstraintOf(1000), in which a maximum TAT value of 1 second is set for App_X, and starts the process of FIG. 10.

[0098] In step F1 of FIG. 10 , the constraint generation unit 50 selects App_X, for which a TAT requirement is specified. Next, in the loop of steps F2 to F4, the constraint generation unit 50 selects components of the OS_Y node connected to the App_X node by a HostedOn edge, and extracts the OS_Y node. Similarly, the constraint generation unit 50 selects components of the Machine_Z node connected to the OS_Y node by a HostedOn edge, and extracts the Machine_Z node. Because the Machine_Z node does not have a HostedOn edge as its source, the process proceeds to step F5, and the constraint generation unit 50 outputs the extracted App_X node, OS_Y node, and Machine_Z node. Then, the constraint generation unit 50 ends the process of FIG. 10 .

[0099] 10 , the constraint generation unit 50 executes the constraint generation means to generate a constraint that the total service time of the extracted three components is less than or equal to the maximum TAT value, based on the maximum TAT value specified in the system requirements and the three extracted components. Specifically, the constraint generation unit 50 generates the constraint "maximum TAT value >= App_X.service time + OS_Y.service time + Machine_Z.service time." The constraint generation unit 50 returns the generated constraint to the system design unit 20.

[0100] The constraint generation means of the constraint function TAT ConstraintOf() in the first embodiment can be said to indicate a method for generating a constraint condition that the total service time of the extracted three components is less than or equal to the specified maximum TAT value. In this way, the constraint generation means corresponds to an example of a method for generating a constraint condition indicated in a constraint function.

[0101] The expression format of the constraint generation means is not limited to a specific format. For example, the constraint generation means may be configured as a program, such as a subroutine as described above. Alternatively, the constraint generation means may be configured as information indicating an algorithm.

[0102] When specific values ​​are set for the properties of each component, the constraint verification unit 30 determines whether the constraint is satisfied based on those values. For example, the constraint generation unit 50 may generate and output constraints that include the values ​​of those properties.

[0103] In the example of FIG. 5, specific values ​​are set for App_X.service time and OS_Y.service time. The constraint verification unit 30 determines whether the constraint condition is met based on these specific values. Note that no service time value is set for the Machine_Z node. Therefore, the constraint verification unit 30 determines whether the constraint condition is met by regarding the service time of the Machine_Z node as 0.

[0104] As described above, the constraint generation process in the constraint generator 50 is performed not only for a specified system configuration in which no abstract components exist, as in S5 of Fig. 8, but also for a system configuration in the process of being specified, as shown in S2 to S4 of Fig. 8. This is to eliminate system configurations that cannot satisfy constraints in the middle of the design process from the design candidates as early as possible, thereby enabling the system to be designed in a shorter time.

[0105] When generating constraints for a system configuration that is currently being realized, the constraint generation unit 50 generates the constraints within the scope of information included in the system configuration information. For example, when the constraint generation unit 50 generates constraints for the system configuration shown in S2 of FIG. 8, neither an OS_Y node indicating a specific performance value nor a Machine_Z node indicating a specific performance value exists in the system configuration. Therefore, the constraint generation unit 50 generates constraints by considering only the components of the App_X node.

[0106] As described above, the constraint verification unit 30 determines whether the system configuration satisfies the constraints. For example, the system design unit 20 passes system configuration information to which the constraints shown in FIG. 9 have been assigned to the constraint verification unit 30. For the constraints related to response time, the system design unit 20 replaces the constraint function with a specific constraint, "Maximum TAT value >= App_X.service time + OS_Y.service time + Machine_Z.service time," received from the constraint generation unit 50, and passes this to the constraint verification unit 30 together with the specific values ​​set in the properties of each component.

[0107] 9, if the values ​​are App_X.available CPU=2.0, App_X.available memory=2000, OS_Y.available CPU=2.0, and OS_Y.available memory=2000, it can be determined that all of these constraints can be met without contradiction. Therefore, the constraint verification unit 30 returns to the system design unit 20 a message indicating that the constraints are met.

[0108] In this way, if the CPU specs available to the App_X node are 2.0GHz and the memory size is 2GB, the amount of resources required for the App_X node to operate is met. Similarly, if the CPU specs available to the OS_Y node are 2.0GHz and the memory size is 2GB, the amount of resources required for the OS_Y node to operate is met.

[0109] Here, the Machine_Z node is equipped with a 2.6 GHz CPU and 32 GB of memory, and it can be determined that there is no problem even if the App_X node and the OS_Y node use the required resources. Therefore, the constraint verification unit 30 can determine that it is possible to build a system configuration that satisfies all the specified constraint conditions.

[0110] (Explanation of Operation) Next, the operation of the system design device 80 according to the first embodiment will be described. Fig. 11 is a flowchart showing an example of the procedure of processing performed by the system design device 80 according to the first embodiment. In the processing of Fig. 11, the input / output unit 10 acquires system requirements input by the user (step G1). Next, the system design unit 20 gradually specifies the system requirements acquired in step G1 (steps G2 to G9), and outputs a completely specified system configuration or a notice of design failure (steps G10 and G11).

[0111] The system design unit 20 first performs a step-by-step concretization (steps G2 to G6) and determines whether the resulting system configuration in the midst of design includes a concrete system configuration (step G7). A concrete system configuration is one in which there are no abstract components and in which the relationships required for the functions of each component are satisfied.

[0112] If it is determined that a specific system configuration is included (step G7: YES), the system design unit 20 outputs the obtained specific system configuration via the input / output unit 10 (step G10). After step G10, the system design device 80 ends the processing of FIG.

[0113] On the other hand, if it is determined in step G7 that a specific system configuration is not included (step G7: NO), the system design unit 20 determines whether any abstract system configurations in the middle of design remain (step G8). If it is determined that any abstract system configurations in the middle of design remain (step G8: YES), the system design unit 20 selects the next system configuration in the middle of design to be realized (step G9). The method by which the system design unit 20 selects the next system configuration in the middle of design to be realized is not limited to a specific method. After step G9, the process returns to step G2.

[0114] On the other hand, if it is determined in step G8 that no system configurations remain in the abstract design process (step G8: NO), the system design unit 20 outputs a message to the effect that the design has failed via the input / output unit 10 (step G11). This is because no system configurations remain to be instantiated, and further instantiation is not possible. After step G11, the system design device 80 ends the processing of FIG. 11.

[0115] In the first stage of instantiation, the system design unit 20 generates a system configuration by applying applicable instantiation rules to the system requirements input in step G1 or the system configuration selected in step G9 (step G2).The system design unit 20 then determines whether one or more system configurations have actually been generated in step G2 (step G3).

[0116] If the system design unit 20 determines that the system configuration has not been generated (step G3: NO), the process proceeds to step G8. In this case, the first stage of realization has failed, so the system design device 80 proceeds to realizing another system configuration that is currently being designed.

[0117] On the other hand, if the system design unit 20 determines in step G3 that one or more system configurations have been generated (step G3: YES), the constraint condition generation unit 50 generates constraint conditions for each generated system configuration based on the constraint functions included in that system configuration (step G4).

[0118] Thereafter, the constraint verification unit 30 determines, for each system configuration generated in step G2, whether all of the constraints assigned to that system configuration can be satisfied, and rejects any system configuration that does not satisfy the constraints (step G5). In this way, by rejecting a system configuration in the middle of design that ultimately leads to a system configuration that cannot satisfy the system requirements at an early stage of system configuration realization, the efficiency of system design can be improved.

[0119] Thereafter, the system design unit 20 determines whether one or more system configurations that can satisfy the constraint conditions remain (step G6). If the system design unit 20 determines that there are system configurations that can satisfy the constraint conditions remaining (step G6: YES), the process proceeds to step G7. In this case, it can be said that the system design device 80 has succeeded in one stage of concretization, and it is determined whether the remaining system configurations are concrete.

[0120] On the other hand, if the system design unit 20 determines in step G6 that there are no remaining system configurations that can satisfy the constraints (step G6: NO), the process proceeds to step G8. In this case, the system design device 80 can be said to have failed in one stage of realization, and so proceeds to realizing another system configuration that is currently being designed.

[0121] (Explanation of Effects) According to the first embodiment, specific constraints that the system to be designed must satisfy are generated based on the structure of the system configuration and the assigned properties, thereby enabling the design of a high-quality system that more accurately satisfies the requirements for the system.

[0122] As described above, the constraint generation unit 50 is linked to system configuration information indicating a target system configuration, which is one of the candidates for system design by repeatedly applying concretization rules to a system configuration including abstract components. The constraint generation unit 50 selects one or more components of the target system configuration based on a component selection method indicated in the constraint generation information, which indicates a method for generating constraints for the target system configuration. The constraint verification unit 30 applies the constraint generation method indicated in the system configuration information or the constraint generation information to the information set for the selected components to generate constraints for the target system configuration. The constraint verification unit 30 determines whether the target system configuration can satisfy the constraints. If the constraint verification unit 30 determines that the target system configuration cannot satisfy the constraints, the candidate narrowing unit 21 excludes the target system configuration from the candidates for system design. The concretization unit 22 proceeds with the system design by applying the concretization rules to the candidates for system design.

[0123] The system design device 80 can determine whether multiple components of a system configuration, not limited to two components whose relationship is directly shown, can satisfy the constraints. For example, the system design device 80 can generate constraints for multiple nodes extracted based on the configuration search means, not limited to nodes directly connected by edges, and determine whether the system configuration can satisfy the constraints. The system design device 80 can exclude system configurations that cannot satisfy the constraints from candidates for system design, thereby enabling efficient system design.

[0124] The constraint function recording unit 60 also stores constraint functions. The constraint functions include constraint function identification information that identifies the constraint functions themselves. The system configuration information to which the constraint functions are linked includes constraint function identification information that identifies the linked constraint functions. The system design device 80 can acquire constraint functions using a relatively simple method of extracting the constraint function identification information by referring to the system configuration information, and acquiring the constraint functions from the constraint function recording unit 60 based on the constraint function identification information.

[0125] The constraint function registration unit 70 also accepts input of a new constraint function and stores the input constraint function in the constraint function recording unit 60. The system design device 80 allows a user to register a desired constraint function. In this respect, the system design device 80 allows a system that satisfies the user's desired conditions to be designed.

[0126] Second Embodiment (Configuration Description) Next, a system design device according to a second embodiment will be described. The configuration of the system design device according to the second embodiment is the same as that of the first embodiment. The second embodiment will also be described using the configuration of the system design device 80 shown in FIG. 1.

[0127] In the second embodiment, when evaluating a system configuration, the system design device 80 generates constraints related to the processes executed in that system configuration in addition to the constraints generated in the first embodiment. As a result, the system design device 80 according to the second embodiment evaluates the system configuration with higher accuracy than in the first embodiment. In all other respects, the second embodiment is similar to the first embodiment.

[0128] In the second embodiment, the system configuration further includes a process topology that models the processes executed on the system. This process topology can represent the flow of processes executed on the system, the types of resources used by each process, and how the resources are shared by each process. When generating constraints to be satisfied by the system, the constraint generation unit 50 generates constraints that take into account the flow of processes executed on the system and the resource usage status, including this process topology. This allows the constraint generation unit 50 to set more detailed constraints to be satisfied by the system configuration.

[0129] What is referred to as a system configuration in the first embodiment is referred to as a configuration topology in the second embodiment. Also, in the second embodiment, a combination of a configuration topology and a processing topology is referred to as a system configuration. The system configuration in the first embodiment corresponds to an example of the system configuration in the second embodiment in which the display of the processing topology is omitted.

[0130] In the second embodiment, the constraint generating unit 50 also generates constraints on resource usage that each component must satisfy, which were defined in the instantiation rules in the first embodiment. The design information recording unit 40 in the second embodiment also stores, as system configuration information, information on the components of the processing topology and information on the instantiation rules of the processing topology. The instantiation rules of the processing topology are instantiation rules for instantiating the processing topology. In response to a request from the system design unit 20, the design information recording unit 40 also returns information on the components of the processing topology and information on the instantiation rules of the processing topology.

[0131] The system design unit 20 in the second embodiment also instantiates a processing topology during system design. Specifically, when selecting one instantiation rule to apply to a system configuration in the middle of design, the system design unit 20 selects either the instantiation rule shown in the first embodiment or the instantiation rule for the processing topology. The method by which the system design unit 20 selects the instantiation rule is not limited to a specific method. For example, the system design unit 20 may randomly select an instantiation rule, or may preferentially select an instantiation rule for the processing topology.

[0132] The constraint generator 50 in the second embodiment generates constraints on response time and resource usage based on the processing topology. Therefore, in the second embodiment, the definitions of component parts, instantiation rules, and system requirements are also changed from those in the first embodiment. First, examples of definitions of component parts and instantiation rules used in the second embodiment are shown, which are added to those in the first embodiment, and then processing topology-related data that is newly handled in the second embodiment is described.

[0133] FIG. 12 is a diagram showing an example of definitions of an App_X2 node representing a specific application, a Machine node representing an abstract machine, and a Machine_Z2 node representing a specific machine, which are used in the second embodiment.

[0134] Compared to the definition of the App_X node shown in Figure 5, the definition of the App_X2 node further indicates a property that represents the expected throughput. Also, the "Constraints" item in the definition of the App_X2 node indicates the TATConstraintOf2 function, which is a constraint function related to response time. The TATConstraintOf2 function takes the maximum TAT value and the expected throughput as arguments. Compared to the TATConstraintOf function, which is a constraint function shown in Figure 5, the TATConstraintOf2 function is a function that adds a throughput value as an input. The TATConstraintOf2 function outputs constraints for the application represented by the App_X2 node to satisfy the specified maximum TAT value when the expected throughput load is applied.

[0135] Compared to the definition of the Machine node shown in FIG. 5, the definition of the Machine node shown in FIG. 12 has a new execution process information property added. The execution process information is information about a process that uses the resource (the resource for which the execution process information is displayed). The execution process information includes four types of information: information indicating the throughput, which represents the load on the process that uses the resource; information indicating the service time, which represents the basic performance of the process that uses the resource; information indicating the measurement environment for that service time; and information indicating the amount of resource available to the component that executes the process that uses the resource. The execution process information may be displayed in the form of an array. When multiple processes use the CPU resources of a certain machine, the above four types of information about all of those processes are stored in the execution process information properties.

[0136] 12, a constraint function called ResourceConstraintOf is defined as a resource constraint. The ResourceConstraintOf function is a constraint function for generating constraints on the amount of resources used by each node, which was defined in the instantiation rules in the first embodiment. The Machine_Z2 node represents a specific machine that inherits the Machine node.

[0137] Fig. 13 is a diagram showing an example of definition of a concretization rule used by the system design device 80 in the second embodiment. Concretization rule 1 in Fig. 13 is the same as concretization rule 1 in Fig. 7. Concretization rule 5 in Fig. 13 is a concretization rule for concretizing an abstract Machine node into a concrete Machine_Z2 node.

[0138] Compared to concatenation rule 3 in Fig. 7, concatenation rule 6 in Fig. 13 has the item "constraint" deleted. Also, compared to concatenation rule 4 in Fig. 7, concatenation rule 7 in Fig. 13 has the item "constraint" deleted. The reason for deleting the item "constraint" in this way is that, as described above, in the second embodiment, constraints related to resource usage are generated by the constraint generating unit 50, and therefore there is no need to define them in individual concatenation rules.

[0139] Next, we will explain data related to the processing topology used in the second embodiment. The processing topology is part of the system configuration, and the methods for notating the components of the processing topology and the instantiation rules for the processing topology are the same as the methods for notating the components and instantiation rules described in the first embodiment.

[0140] Here, a processing topology is a topology for expressing the processing flow of each process and the resources used, and the minimum number of components and instantiation rules required to construct a processing topology are limited. Below, we will explain examples of the types and definitions of the minimum components and instantiation rules required to construct a processing topology. However, processing topology components and processing topology instantiation rules may be added as necessary.

[0141] The minimum components that make up a processing topology are the load generated by each process, the smallest unit of processing executed within a process, and the resources used by that smallest unit of processing. The smallest unit of processing is further classified into internal processing, which represents the processing of the process itself, and external processing, which calls other processes.

[0142] Figure 14 is a diagram showing an example of the definition of components of a processing topology. Figure 14(a) shows an example of the definition of a Workload node that represents the load generated in each process, with the expected throughput set as a property. Workload(App_X2) and Workload(OS_Y) are Workload nodes that represent the load on the App_X2 node and the OS_Y node, respectively, and the default value for the throughput property is set to λ. As will be described later, λ represents the average arrival rate of processing requests in the entire system.

[0143] If the expected load value is specified by the user as a system requirement, the Workload(App_X2) node and the Workload(OS_Y) node will use the specified value. On the other hand, if the expected load value is not specified, the Workload(App_X2) node and the Workload(OS_Y) node will use this default value. Furthermore, the Workload(App_X2) node, which is the node for the load on the App_X2 node, has a CalledBy relationship defined as a function used. This means that the App_X2 node is called from another process.

[0144] Figure 14(b) shows an example of a node definition that represents the smallest unit of processing executed within a process. The InnerProcessing node (an InnerProcessing type node) represents the internal processing executed by the process itself, and the service time and measurement environment are set as properties that represent the basic performance of that internal processing. Furthermore, "Used function: Resource" indicates that resources are required to execute the program.

[0145] In the first embodiment, the service time, which is one of the properties of an internal processing node, is a value having the same meaning as the service time indicated as a property of the App_X2 node and the OS_Y node. In the second embodiment, the service time of the processes of the App_X2 node and the OS_Y node is set not in the App_X2 node and the OS_Y node themselves, but in the InnerProcessing node, which is the smallest unit of processing. By including any InnerProcessing node in a processing topology that models the processing of the App_X2 node and the OS_Y node, various processing flows can be expressed in the processing topology.

[0146] The measurement environment property indicates the actual environment in which the service time was measured. The actual measured value of the service time for each process is greatly affected by the environment in which the service time was measured, for example, the CPU performance of the machine on which it was measured. Therefore, an InnerProcessing type node represents the basic performance value of each process by combining the measurement environment and the service time in that environment.

[0147] An OuterProcessing type node represents an external process that calls an external program from a process within a process. In Figure 14(b), the InnerProcessing(App_X2) node and the InnerProcessing(OS_Y) node are defined as the smallest unit of internal processing within the App_X2 node and the OS_Y node processes. Also, the OuterProcessing(OS_Y) node is defined as an external process in which the OS_Y process (the process of the OS_Y node) calls an external program.

[0148] Figure 14(c) shows an example of a node definition that indicates the type of resource used in internal processing. The Resource type shown in Figure 14(c) and the CPUResource node that inherits the Resource type are nodes that simply specify the type of resource to be used, so in order to specifically specify the CPU to be used, a relationship that utilizes the Machine node that contains the CPU is required. This is indicated by "Utilize function."

[0149] Next, relationships related to processing topology will be described. There are six types of relationships that are the minimum required to construct a processing topology. Fig. 15 is a diagram showing an example of a graphical representation of the six types of relationships that are required to construct a processing topology. Fig. 16 is a diagram showing an example of a textual representation of the six types of relationships that are required to construct a processing topology.

[0150] The first relationship represents the order in which processes are called. In (a) of Figure 15 and (a) of Figure 16, the fact that one process is executed after another is represented by an edge called ProcessFlow(Processing, Processing). The second relationship represents the type of resource used by the internal process. In (b) of Figure 15 and (b) of Figure 16, the fact that the internal process uses a certain type of resource is represented by an edge called Utilize(InnerProcessing, Resource).

[0151] The third relationship is a relationship that expresses the type of load placed on internal processing. In (c) of Figure 15 and (c) of Figure 16, the load placed on internal processing is expressed by an edge called Input(Workload, InnerProcessing). The fourth relationship is a relationship that expresses which component of the configuration topology each component of the processing topology represents. In (d) of Figure 15 and (d) of Figure 16, the edge ProcessInclude(*, *) expresses that a component of the processing topology is included in a processing topology that models the processing executed by a component of the configuration topology. Here, "*" indicates that the type of the source and destination nodes is not limited. For example, the source could be an App node or an OS node, and the destination could be the component of the processing topology shown in Figure 14.

[0152] The fifth relationship is a relationship that expresses that a certain process is called by a process in another process. In (e) of Figure 15 and (e) of Figure 16, the edge "CalledBy (Workload, OuterProcessing)" expresses that the load generated in a certain process is generated by the call of an external process in another process.

[0153] The sixth relationship is a relationship that specifies a specific resource to be actually used based on the resource type. In (f) of Figure 15 and (f) of Figure 16, the edge Utilize(Resource, Machine) represents the specification of a specific resource (or the machine on which it is installed) to be used based on the specified resource type.

[0154] Next, we will explain the reification rules for constructing a processing topology. The information that a processing topology can express is the flow of processes executed by system components such as applications, middleware, and operating systems, the processes that call other programs within those processes, and the specific resources used in each process.

[0155] Here, the processing flow of processes executed by the components of a system is specific to each component and can be defined regardless of the system structure. Therefore, instantiation rules are generated in advance to instantiate the processing topology that represents the processing executed by each component. Then, by applying these instantiation rules to the processing topology during system design, the processing topology that represents the processing executed by each component is instantiated.

[0156] On the other hand, the relationships between which external programs are called within a process and which machine resources are used by internal processing within a process cannot be defined before design because they differ depending on the type of software installed in the system components and the type of machine hosting the components on which the processing is executed.For this reason, instantiation rules are generated to determine which programs are called and which resources are used according to the system configuration, and these instantiation rules are applied to the processing topology during system design, thereby dynamically instantiating the relationships according to the system configuration being designed.

[0157] 17 to 21 show examples of definitions of reification rules for processing topology. FIG. 17 is a diagram showing a first example of definitions of reification rules for processing topology. FIG. 17 shows an example of definition of reification rule 10. FIG. 18 is a diagram showing a second example of definitions of reification rules for processing topology. FIG. 18 shows an example of definition of reification rule 11. FIG. 19 is a diagram showing a third example of definitions of reification rules for processing topology. FIG. 19 shows an example of definition of reification rule 12. FIG. 20 is a diagram showing a fourth example of definitions of reification rules for processing topology. FIG. 20 shows an example of definition of reification rule 13. FIG. 21 is a diagram showing a fifth example of definitions of reification rules for processing topology. FIG. 21 shows an example of definition of reification rule 14.

[0158] Instantiation rule 10 and instantiation rule 11 are instantiation rules that construct a processing topology that represents the processing within a process executed by a system component. Instantiation rule 10 is a instantiation rule that constructs a processing topology that represents the processing flow of the App_X2 process. Specifically, instantiation rule 10 constructs a processing topology that represents the execution of internal processing that uses CPU resources when some kind of load occurs.

[0159] Concretization rule 11 constructs a processing topology that expresses the processing flow of OS_Y's process: when some kind of load occurs, internal processing that uses CPU resources is executed, followed by external processing that calls an external program. Concretization rule 12 is an example of a concretization rule for a relationship in which the load on a process is generated by a call from another process. Concretization rule 12 concretizes the relationship in which the load on the App_X2 process is called from the OS_Y process that hosts App_X2 by extending a CalledBy edge from Workload in App_X2's processing topology to OuterProcessing in OS_Y's processing topology.

[0160] Reification rule 13 is a reification rule for specifically specifying the resources used in the internal processing of the App_X2 node process. Reification rule 13 reifies the relationship that the CPU resources used in the internal processing of the App_X2 node are the CPU resources of the Machine_Z2 node on which the App_X2 node and the OS_Y node hosting the App_X2 node are installed.

[0161] Instantiation rule 14 is an instantiation rule for specifically specifying the resources to be used in the internal processing of the process of node OS_Y. Instantiation rule 14 instantiates the relationship that the CPU resources to be used in the internal processing of node OS_Y are the CPU resources of node Machine_Z2 on which node OS_Y is installed.

[0162] Next, an example of the definition of the system requirements in the second embodiment will be described. Fig. 22 is a diagram showing an example of the definition of the system requirements in the second embodiment. In the system requirements shown in Fig. 22, throughput is added as a property compared to the system requirements shown in Fig. 4. The system requirements shown in Fig. 22 indicate a requirement that the TAT value shown in the property be satisfied in the throughput environment shown in the property.

[0163] 23 to 28 show examples of concretizing a system configuration using the components and concretization rules defined in FIGS. 5, 6, 12 to 14, 16, and 17 to 21 when the system requirements shown in FIG. 22 are given. FIG. 23 is a diagram showing a first example of concretization of a system configuration in the second embodiment. FIG. 24 is a diagram showing a second example of concretization of a system configuration in the second embodiment. FIG. 24 shows an example of concretization performed by the system design device 80 after the concretization in FIG. 23.

[0164] Fig. 25 is a diagram showing a third example of a concrete system configuration in the second embodiment. Fig. 25 shows an example of concrete system configuration that the system design device 80 performs after the concrete system configuration in Fig. 24. Fig. 26 is a diagram showing a fourth example of a concrete system configuration in the second embodiment. Fig. 26 shows an example of concrete system configuration that the system design device 80 performs after the concrete system configuration in Fig. 25.

[0165] Fig. 27 is a diagram showing a fifth example of a concrete system configuration in the second embodiment. Fig. 27 shows an example of concrete system configuration that the system design device 80 performs after the concrete system configuration in Fig. 26. Fig. 28 is a diagram showing a sixth example of a concrete system configuration in the second embodiment. Fig. 28 shows an example of concrete system configuration that the system design device 80 performs after the concrete system configuration in Fig. 27.

[0166] The system requirement T1 in Fig. 23 represents the system requirement in Fig. 22. When the system requirement T1 is given as an input, the system design device 80 applies the instantiation rule 10 to the system requirement T1. As a result, the system design device 80 acquires a system configuration T2 in which the processing topology representing the processing of the App_X2 node is instantiated.

[0167] In the system configurations shown in Figures 23 to 28, the portions enclosed by dashed lines correspond to examples of processing topologies. In the system configurations shown in Figures 23 to 28, the portions other than the portions enclosed by dashed lines correspond to examples of configuration topologies. In the system configurations shown in Figures 23 to 28, when a ProcessInclude edge is extended from a node to a dashed rectangle, this indicates that a ProcessInclude edge is extended to all nodes included in the dashed rectangle.

[0168] Next, the system design device 80 applies the instantiation rules for generating an OS node and instantiating it into an OS_Y node shown in Fig. 13 to the system configuration T2 to obtain a system configuration T3. In the examples of Fig. 23 to Fig. 28, two overlapping arrows indicate that multiple instantiation rules are applied.

[0169] Next, the system design device 80 applies instantiation rule 11 to the system configuration T3 to obtain a system configuration T4 in which the processing topology of the OS_X node is instantiated. Next, the system design device 80 applies instantiation rule 12 to the system configuration T4 to obtain a system configuration T5 in which the relationship in which the process of the App_X2 node is called from the processing of the OS_Y node is instantiated.

[0170] 13 to generate a Machine node and instantiate it into the Machine_Z2 node, to obtain system configuration T6. Next, system design device 80 applies instantiation rule 13 to system configuration T6 to obtain system configuration T7 in which the Machine_Z2 node hosting the App_X2 node is specified as the CPU resource to be used by the internal processing of the App_X2 node. Furthermore, system design device 80 applies instantiation rule 14 to system configuration T7 to obtain system configuration T8 in which the Machine_Z2 node hosting the OS_Y node is specified as the CPU resource to be used by the internal processing of the OS_Y node.

[0171] Here, the concretization of the system configuration does not necessarily require that the concretization rules be applied in the order shown in Figures 23 to 28. If there are multiple concretization rules applicable to a certain system configuration, any of the multiple concretization rules can be applied first. For example, the system design device 80 may apply a concretization rule that concretizes OS_Y or a concretization rule that concretizes the Machine_Z2 node from the state of system requirement T1 in Figure 23 before applying concretization rule 10.

[0172] When there are multiple applicable concatenation rules, the method by which the system design device 80 selects the concatenation rule to be applied is not limited to a specific method. For example, the system design device 80 may randomly select one of the multiple concatenation rules. Alternatively, the system design device 80 may select one of the multiple concatenation rules based on the results of machine learning.

[0173] Next, the constraint functions in the second embodiment will be described. As examples of the constraint functions in the second embodiment, specific examples of a constraint function (TATConstraintOf2) that generates a constraint condition related to response time and a constraint function (ResourceConstraintOf) that generates a constraint condition related to resource usage will be shown. These constraint functions generate constraint conditions based on the system configuration including the processing topology. However, the constraint functions used by the system design device 80 are not limited to these. The user can edit the constraint functions via the constraint function registration unit 70.

[0174] The TATConstraintOf2 function takes the maximum TAT value and throughput value as input, and generates and returns constraints on the response time that the system must satisfy. The configuration search means provided in the TATConstraintOf2 function searches the system structure, including the processing topology, and extracts the path of the InnerProcessing node, which is a component that represents processing within the system configuration, as a node that affects the TAT requirement. The InnerProcessing node is an example of a node that represents a process. The configuration search means of the TATConstraintOf2 function is an example of a process extraction method shown in the constraint function.

[0175] Specifically, the constraint generator 50 executes the configuration search means. The constraint generator 50 starts from a component in the system configuration for which a TATConstraintOf2 function is set, and extracts an internal processing (InnerProcessing node) from the processing topology representing the process of that component. The constraint generator 50 also sets the throughput value provided as input to the TATConstraintOf2 function to the throughput property of the Workload node that has an edge connected to the extracted internal processing node.

[0176] The constraint generation unit 50 then determines whether the processing of the target component is called by a process of another component. That is, the constraint generation unit 50 determines whether a CalledBy edge is established from the Workload node in the processing topology of the target component to an OuterProcessing node in the processing topology of the other component. If it is determined that a calling component exists, the constraint generation unit 50 selects the calling component and returns to the initial processing. On the other hand, if it is determined that a calling component does not exist, the constraint generation unit 50 outputs a path consisting of the InnerProcessing nodes extracted up to that point and terminates processing as configuration search means. The node path here can be a set whose elements are nodes. The InnerProcessing node is an example of a node representing a process, and the path of the InnerProcessing node is an example of a process group.

[0177] The constraint generation means provided in the TATConstraintOf2 function generates constraints to be satisfied by the entire path based on the path information output by the configuration search means. Specifically, the constraint generation unit 50 executes the constraint generation means. The constraint generation unit 50 generates a constraint that the sum of the execution times of each process represented by the InnerProcessing node on the path output by the processing as the configuration search means is equal to or less than the maximum TAT value given as input to the TATConstraintOf2 function. The constraint generation unit 50 then returns all of the constraints generated by executing the constraint generation means as the output of the TATConstraintOf2 function.

[0178] The ResourceConstraintOf function generates and returns constraints on resource usage that must be satisfied by the resource. The ResourceConstraintOf function has two configuration search methods. The first configuration search method extracts all components hosted by the component for which the ResourceConstraintOf function is specified.

[0179] Specifically, the constraint generation unit 50 executes the first configuration search means. The constraint generation unit 50 searches the system configuration and extracts the source node connected by the HostedOn edge to the component for which the ResourceConstraintOf function is specified. The constraint generation unit 50 then treats the extracted source node as a new target and extracts the source node connected to this node by the HostedOn edge. The constraint generation unit 50 repeats this process until no node that satisfies the condition exists.

[0180] The second configuration search means adds the following four types of information regarding all processes that use the resources of a component for which a ResourceConstraintOf function is specified to the properties of the resources within that component. Specifically, the constraint generation unit 50 executes the second configuration search means. The constraint generation unit 50 searches the system configuration including the processing topology, and traces Resource nodes that extend Utilize edges to components for which a ResourceConstraintOf function is specified, and InnerProcessing nodes that extend Utilize edges to those Resource nodes.

[0181] The constraint generation unit 50 then adds the service time value and measurement environment value, which are properties of the InnerProcessing node, to the properties of the Resource node. Furthermore, the constraint generation unit 50 adds an id indicating the CPU usage property defined in the component that has a ProcessInclude edge to the InnerProcessing node, and an id indicating the throughput property defined in the Workload node that has an Input edge to the InnerProcessing node, to the throughput and resource usage properties of the resource.

[0182] The reason why variables containing values ​​are stored in the latter two properties, rather than the values ​​themselves, is that these two properties may not contain specific values ​​at the time, and their values ​​may be updated as other processing is performed.

[0183] When multiple processes use one resource, that is, when there are multiple Resource nodes with Utilize edges to a certain Machine node, the constraint generation unit 50 executes this process for all of those Resource nodes.The constraint generation unit 50 then outputs all nodes extracted by the first configuration search means.

[0184] The ResourceConstraintOf function also has two constraint generation means. The first constraint generation means generates constraints on the amount of resources used by the component for which the ResourceConstraintOf function is specified. Specifically, the constraint generation unit 50 executes the first constraint generation means.

[0185] The constraint generating unit 50 generates a constraint on CPU resources for all nodes output by executing the configuration searching means, stating that the value of the CPU clock frequency property of the component for which the ResourceConstraintOf function is specified is equal to or greater than the value of the CPU usage property set for each node. The constraint generating unit 50 also generates a constraint on memory resources for the component, stating that the value of the memory property of the component is equal to or greater than the sum of the memory usage property values ​​set for each node.

[0186] The second constraint generation unit generates a constraint on the execution time of a process that uses a resource included in a component for which a ResourceConstraintOf function is specified. Specifically, the constraint generation unit 50 executes the second constraint generation unit.

[0187] Two methods for generating constraints on the execution time of processing are shown below: one is to generate them by estimating performance more precisely using a queueing model, and the other is to generate them by estimating performance more roughly using a simple formula. Hereinafter, the former will be referred to as constraint generation method example 1, and the latter will be referred to as constraint generation method example 2.

[0188] While constraint generation method example 1 allows for the design of a system with high performance accuracy, it may be difficult to apply because it is difficult to derive a value that satisfies the constraint, or because it takes a long time to derive the value. Therefore, the constraint generation unit 50 selects an appropriate method depending on the situation. In constraint generation method example 1, the constraint generation unit 50 generates a constraint that the execution time of each process that uses a resource that is the target of calculation of the ResourceConstraintOf function is equal to or greater than the sum of the service time of each process and the processing wait time for that resource.

[0189] The service time and processing wait time of each process are derived by the constraint generation unit 50 based on four types of information added to the execution process information property of the machine node by executing the configuration search means. Equation (1) can be used as a formula for deriving the service time of each process in the constraint generation method example 1.

[0190]

[0191] "x" represents multiplication. Based on formula (1), the constraint generating unit 50 derives the service time of a certain process by multiplying the service time set as a property of the InnerProcessing node representing that process by the ratio obtained by dividing the value of the property "Basic performance of process.Measurement environment.CPU" representing the CPU environment in which that service time was measured by the value of the property "Component.Available CPU" representing the CPU that can be used by a component that executes that process in the designed system configuration.

[0192] Equation (1) indicates that the service time will be shorter if the specifications of the CPU that the target component can use in the designed system configuration are higher than the CPU used to measure the service time. In other words, the "component" in equation (1) represents the component that executes the process for which the service time is to be calculated.

[0193] The constraint generator 50 derives the processing wait time using queuing theory based on the service time values ​​of multiple processes that share the same resource and the throughput values ​​that represent the load on those processes. For example, Equation (2) can be used to derive the processing wait time when two processes share one CPU.

[0194]

[0195] λ represents the average arrival rate of processing requests in the entire system. The sum of the throughputs of the two processes can be used as λ. In other words, it can be expressed as "average arrival rate λ of the entire system = throughput of process 1 + throughput of process 2." Ts represents the average service time of the entire system. Ts can be expressed as an M / M / s queuing model, where Ts is the weighted average of the service time of each process obtained from equation (1) and the throughput of each process. s represents the number of resources. In the case of a CPU resource, s represents the number of CPU cores. For example, Ts can be expressed as equation (3), according to the formula for deriving waiting time in the M / M / s model.

[0196]

[0197] ρ is expressed as in equation (4).

[0198]

[0199] If the system configuration includes internal processes that use different resources, the constraint generator 50 calculates the service time and waiting time for each resource, and calculates the service time and waiting time for all processes included in the system configuration. The constraint generator 50 then generates a constraint for each process that states that the execution time of the process is equal to or greater than the sum of the calculated service time and waiting time.

[0200] In the example constraint generation method 2, the constraint generation unit 50 estimates the execution time by taking into account the percentage of the CPU that each process can use. Equation (5) can be used to derive the service time of each process in the example constraint generation method 2.

[0201]

[0202] The constraint generation unit 50 estimates the execution time of each process by multiplying the service time of each process by the reciprocal of the rate at which the query (processing request) including that process can use the CPU, based on equation (5). The method for deriving the service time of each process is the same as the method for deriving the service time in constraint generation method example 1.

[0203] The percentage of CPU usage for a query is set to 100% if that query is the only one that uses the CPU. On the other hand, if multiple types of queries share the CPU, the constraint generation unit 50 calculates how many seconds per second each query uses the CPU from the sum of the arrival rate of each query and the service time of the processing corresponding to that query, and determines the percentage of the CPU usage time value of the target query to the total value of the CPU usage time of all queries.

[0204] The constraint generation unit 50 executes the constraint generation means to generate constraints for all processes that use the resources of the component parts for which the ResourceConstraintOf function is specified. The constraint generation unit 50 then returns all the generated constraints to the system design unit 20 as the output of the ResourceConstraintOf function.

[0205] Next, the flow of processing in which the constraint condition generating unit 50 in the second embodiment outputs constraint conditions that should be satisfied by the system configuration will be described using an example in which constraint conditions that should be satisfied by the system configuration T8 in Fig. 28 are generated. First, the flow of processing in which the constraint condition generating unit generates constraint conditions in the second embodiment will be described.

[0206] 29 is a flowchart showing an example of the processing procedure by the constraint generating unit 50 to generate constraints. The constraint generating unit 50 acquires the system configuration T8 of FIG. 28 from the system design unit 20 in the form of system configuration information (step H1). In the system configuration T8, a constraint function related to response time, TATConstraintOf(1000, 20), is set in the App_X2 node. Also, in the system configuration T8, a constraint related to resource usage, ResourceConstraintOf(), is set in the Machine_Z2 node.

[0207] Having acquired the system configuration T8 including the constraint function, the constraint generation unit 50 executes the configuration search means for the TATConstraintOf(1000,20) function and the configuration search means for the ResourceConstraintOf() function (step H2). When executing the configuration search means for the TATConstraintOf(1000,20) function, the constraint generation unit 50 sets the App_X2 node as the starting point of processing and extracts the InnerProcessing(App_X2) node, which represents the internal processing of this node. The constraint generation unit 50 also sets 20 to the throughput property of the Workload(App_X2) node, which represents the load on this internal processing.

[0208] The constraint generation unit 50 then traces the OuterProcessing node to which Workload in the processing topology of App_X2 has a CalledBy edge, and sets the OS_Y node as the new target node. The constraint generation unit 50 then similarly extracts the InnerProcessing(OS_Y) node, which represents the internal processing of OS_Y, and sets the throughput property of the Workload(OS_Y) node to 20.

[0209] When executing the configuration search means of the TATConstraintOf2(1000, 20) function, the constraint generation unit 50 outputs a path consisting of the InnerProcessing(App_X2) node and the InnerProcessing(OS_Y) node. When executing the configuration search means of the ResourceConstraintOf() function, the constraint generation unit 50 sets the Machine_Z2 node as the starting point and extracts two nodes: the OS_Y node connected to that node by a HostedOn edge, and the App_X2 node connected to the OS_Y node by a HostedOn edge.

[0210] Furthermore, the constraint generating unit 50 refers to the CPUResource node that establishes a Utilize edge to Machine_Z2, for which the ResourceConstraintOf() function is specified, and the InnerProcessing(App_X2) node as the InnerProcessing node that establishes a Utilize edge to the CPUResource node.

[0211] Then, the constraint generation unit 50 adds the following four values ​​to the execution processing information property of the Machine_Z2 node as information about the processing of the InnerProcessing(App_X2) node: - the service time of the InnerProcessing(App_X2) node is 100; - the measurement environment value of that service time is 1.8; - $Workload(App_X2).Throughput, which indicates the throughput property of the Workload(App_X2) node that has an Input edge to the InnerProcessing(App_X2) node; and - $App_X2.UsedCPU, which indicates the used CPU property of the App_X2 node, which is a component that executes the processing of the InnerProcessing(App_X2) node.

[0212] Similarly, the constraint generation unit 50 also adds the following four values ​​to the properties of the execution processing information of the Machine_Z2 node as processing information for the InnerProcessing(OS_Y) node, which is another process that uses the Machine_Z2 node: - the service time of the InnerProcessing(OS_Y) node, 20; - the measurement environment value of that service time, 2.0; - $Workload(OS_Y).Throughput, which indicates the throughput property of the Workload(OS_Y) node that has an Input edge to the InnerProcessing(OS_Y) node; and - $OS_Y.UsedCPU, which indicates the CPU usage property of the App_X2 node, which is a component that executes the processing of the InnerProcessing(OS_Y) node.The constraint generation unit 50 then outputs the two nodes, the App_X2 node and the OS_Y node, extracted by executing the first configuration search means.

[0213] Next, the constraint generation unit 50 executes the constraint generation means for the TATConstraintOf(1000,20) function and the constraint generation means for the ResourceConstraintOf() function (step H3). In executing the constraint generation means for the TATConstraintOf(1000,20) function, the constraint generation unit 50 generates the constraint "1000 >= ProcessingTime_App_X2 + ProcessingTime_OS_Y", which indicates the condition that the sum of the execution times of the processes represented by the InnerProcessing nodes on the paths extracted by executing the configuration search means should be less than or equal to the maximum TAT of 1000. Here, ProcessingTime_App_X2 and ProcessingTime_OS_Y are variables representing the execution times of the processes represented by the InnerProcessing(App_X2) node and the InnerProcessing(OS_Y) node, respectively.

[0214] When the constraint generation unit 50 executes the constraint generation means of the ResourceConstraintOf() function, it generates three constraints: "2.6 >= App_X2.CPU used", "2.6 >= OS_Y.CPU used", and "32000 >= App_X2.Memory used + OS_Y.Memory used" based on the resource usage of the App_X2 node and OS_Y node extracted by the execution of the configuration search means and the resources installed in Machine_Z2.

[0215] Furthermore, the constraint generation unit 50 generates constraints on the execution times of the processes represented by the InnerProcessing(App_X2) node and the InnerProcessing(OS_Y) node based on the information stored in the execution process information property of the Machine_Z2 node. When using constraint generation example 1, the constraint generation unit 50 derives the service time Ts(App_X2) of the process represented by the InnerProcessing(App_X2) node based on equation (1) as Ts(App_X2) = 100 × (1.8 / App_X2.CPU used), where " / " represents division. The constraint generation unit 50 also derives the service time Ts(OS_Y) of the process represented by the InnerProcessing(OS_Y) node as Ts(OS_Y) = 20 × (2.0 / OS_Y.CPU used).

[0216] Furthermore, the CPU resources of the Machine_Z2 node are shared by two processes: the process of the App_X2 node, which has a throughput of 20 and a service time of Ts(App_X2), and the process of the OS_Y node, which has a throughput of 20 and a service time of Ts(OS_Y). From this, the constraint generation unit 50 can derive the average arrival rate of the entire system as 40, and the average service time of the entire system as the waiting time in an M / M / 4 queuing model of {20 × Ts(App_X2) + 20 × Ts(OS_Y)} / 40.

[0217] If the waiting time derived by this formula is represented as Tw, the constraint generating unit 50 generates two constraints, "ProcessingTime_App_X2 >= Ts(App_X2) + Tw" and "ProcessingTime_OS_Y >= Ts(OS_Y) + Tw", as constraints on the execution time of each process. Thereafter, the constraint generating unit 50 outputs a total of five constraints generated by executing the constraint generating means of the ResourceConstraintOf() function.

[0218] When using generation condition generation example 2, the constraint condition generation unit 50 estimates the execution time of the App_X2 node as the service time derived using equation (1) multiplied by the reciprocal of the proportion of CPU usage available to a query including the App_X2 node. In the examples of FIGS. 23 to 28, there is only one type of query that includes processing of the App_X2 node and the OS_Y node. Based on this, the constraint condition generation unit 50 calculates the proportion of CPU usage available to a query including the App_X2 node as {(20+100) × 20} / {(20+100) × 20} = 1 based on the second term on the right-hand side of equation (5). The constraint condition generation unit 50 similarly derives the execution time for processing the OS_Y node.

[0219] Then, the constraint generating unit 50 generates two constraints: "ProcessingTime_App_X2 ≥ Ts(App_X2) × 1" and "ProcessingTime_OS_Y ≥ Ts(OS_Y) × 1". After that, the constraint generating unit 50 outputs a total of five constraints generated by the constraint generating means of the ResourceConstraintOf() function. After step H4, the constraint generating unit 50 ends the processing of FIG. 29.

[0220] 30 to 32 show a summary of the constraints generated by the constraint generating unit 50 based on the TATConstraintOf2(1000,20) function and the ResourceConstraintOf() function in the above example. FIG. 30 shows an example of a constraint generated by the constraint generating unit 50 based on the TATConstraintOf2(1000,20) function. FIG. 31 shows an example of a constraint generated by the constraint generating unit 50 based on the ResourceConstraintOf() function using Constraint Generating Example 1. FIG. 32 shows an example of a constraint generated by the constraint generating unit 50 based on the ResourceConstraintOf() function using Constraint Generating Example 2.

[0221] (Explanation of Effects) The system design device 80 according to the second embodiment generates constraints on response times that a system must meet, based on a processing topology that models the state of processing to be executed and the amount of resources that can be used for each processing. As a result, the system design device 80 according to the second embodiment can design a high-quality system that meets response time requirements with a higher degree of accuracy.

[0222] As described above, the system configuration information includes a model indicating the configuration of a process executed by the system configuration. The constraint generating unit 50 generates constraints related to the process based on the model indicating the configuration of the process. The system design device 80 can generate constraints related to the process executed by a target system configuration and determine whether the target system configuration satisfies the constraints. In this respect, the system design device 80 can design a system that satisfies the process constraints desired by the user. Furthermore, the system design device 80 can exclude system configurations that cannot satisfy the process constraints from candidates for system design, thereby enabling efficient system design.

[0223] The system configuration information also includes information on the processing time for each process. The constraint condition generation unit 50 extracts a group of processes that constitute a series of operations executed by a predetermined process call specified in the system configuration information based on the process extraction method indicated in the constraint function, and generates a constraint condition that the total processing time of each process included in the extracted group of processes is within the allowable time range specified for the process call.

[0224] The system design device 80 can generate constraints on process processing times and determine whether a target system configuration satisfies the constraints on process processing times. In this respect, the system design device 80 can design a system that meets the user's needs.

[0225] The system configuration information also includes information on the amount of computational resources used by each process. The constraint condition generation unit 50 extracts a group of processes that use the predetermined computational resources indicated in the system configuration information based on the process extraction method indicated in the constraint function, and generates a constraint that the total amount of computational resources required for each process included in the extracted group of processes to perform processing within the service time and processing request arrival rate specified for that process, for the group of processes, is within the range of the amount of computational resources that the computational resources can provide.

[0226] The system design device 80 can generate constraints on the use of computational resources by processes and determine whether a target system configuration satisfies the constraints on the use of computational resources by processes. In this respect, the system design device 80 can design a system that the user desires.

[0227] <Third Embodiment> (Explanation of Configuration) Next, a system design device according to a third embodiment will be described. Fig. 33 is a diagram showing an example of the configuration of a system design device according to the third embodiment. In the configuration shown in Fig. 33, a system design device 180 includes an input / output unit 10, a system design unit 20, a constraint verification unit 30, a design information recording unit 40, a constraint condition generation unit 50, a constraint function recording unit 60, a constraint function registration unit 70, and a design state determination unit 90.

[0228] The parts in Fig. 33 that correspond to the parts in Fig. 1 are given the same reference numerals (10, 20, 30, 40, 50, 60, 70). The system design device 180 further includes a design state determination unit 90 in addition to the parts included in the system design device 80 in Fig. 1. In all other respects, the system design device 180 is similar to the system design device 80.

[0229] In the system design device 80 according to the first and second embodiments, the constraint generating unit 50 generates constraints for the system configuration generated during system design by the system design unit 20. However, in the first and second embodiments, there is no limitation on the point in time at which the system design unit 20 passes the system configuration information to the constraint generating unit 50.

[0230] Concerning the timing at which the constraint generator 50 generates constraints, a method can be considered in which constraints are generated each time the system configuration is concretized one step further, that is, each time a concretization rule is applied. This method allows the system design device to detect system configurations that cannot satisfy constraints at a relatively early stage of system design and to exclude such system configurations from being concretized, which is expected to enable efficient system design.

[0231] On the other hand, in order to generate more accurate constraints, it is desirable that the system configuration be specified so that a specific operating system and machine are included in the system configuration. In the above-mentioned method of generating constraints at each stage of the system configuration specification, when the system configuration specification is not yet advanced, the accuracy of the obtained constraints may be relatively low, and in this respect, the effectiveness of generating constraints may be relatively low.

[0232] Regarding the timing at which the constraint generator 50 generates constraints, it is also possible to generate constraints when a concrete system configuration that does not include abstract components is obtained as the system configuration to be designed. This method can relatively reduce the processing load of the constraint generator 50 when generating constraints.

[0233] On the other hand, when a concrete system configuration is obtained in which the system configuration to be designed does not include abstract components, the method of generating constraints cannot exclude system configurations that cannot satisfy the constraints during the intermediate stage of the system configuration concretization.

[0234] In contrast, in the system design device 180, when the design state determination unit 90 detects that a pre-specified condition is satisfied, the constraint condition generation unit 50 generates a constraint condition. This allows the system design device 180 to specify the timing at which the constraint condition generation unit 50 generates a constraint condition. In this respect, it is possible to eliminate system configurations that cannot satisfy the constraint conditions at a relatively early stage of system design, while reducing the number of times the constraint condition generation unit 50 generates a constraint condition. The system design device 180 corresponds to an example that further embodies the system design device 80 according to the first embodiment or the system design device 80 according to the second embodiment. The design state determination unit 90 corresponds to an example of design state determination means.

[0235] The design state determination unit 90 stores in advance information indicating the conditions under which the constraint condition generation unit 50 generates constraint conditions. The information indicating the conditions under which the constraint condition generation unit 50 generates constraint conditions can be said to be information indicating the conditions under which the system configuration under design must be satisfied before the system design unit 20 passes system configuration information to the constraint condition generation unit 50. The conditions under which the constraint condition generation unit 50 generates constraint conditions are also referred to as constraint generation conditions.

[0236] The constraint generation condition is not limited to a specific condition. For example, the constraint generation condition may be a condition that a machine is instantiated in the system configuration being designed. Alternatively, the constraint generation condition may be a condition that five additional instantiation rules are applied.

[0237] The design state determination unit 90 receives system configuration information from the system design unit 20 , determines whether or not the constraint generation conditions are met, and returns the determination result to the system design unit 20 .

[0238] Each time the system design unit 20 applies one instantiation rule to a system configuration in the middle of design, it passes information about the instantiated system configuration to the design state determination unit 90. The system design unit 20 then receives from the design state determination unit 90 a determination result as to whether or not the constraint generation condition is satisfied.

[0239] If the system design unit 20 receives a determination result indicating that the constraint generation conditions are met, it passes the system configuration information to the constraint condition generation unit 50. The constraint condition generation unit 50 generates constraint conditions using the received system configuration information. On the other hand, if the system design unit 20 receives a determination result indicating that the constraint generation conditions are not met, it does not pass the system configuration information to the constraint condition generation unit 50, and continues the system design concretization process.

[0240] (Explanation of Operation) Next, the operation of the system design device 180 according to the third embodiment will be explained using a specific example. Here, it is assumed that the constraint generation condition is set to "there is a specified machine node in the system configuration," and the processing flow will be explained using an example in which the system design device 180 specifies the system configurations shown in FIGS. 23 to 28.

[0241] Each time the system design unit 20 applies one concretization rule to a system requirement or a system configuration, it passes the system configuration information at that time to the design state determination unit 90. For example, the system design unit 20 applies concretization rule 10 to a system requirement T1 to concretize it into a system configuration T2, and passes the configuration information of the system configuration T2 to the design state determination unit 90.

[0242] The design state determination unit 90 refers to the received system configuration T2 and determines whether or not there is a concretized machine node. Since there is no concretized machine node in the system configuration T2, the design state determination unit 90 returns a message to the system design unit 20 indicating that the constraint generation condition is not satisfied. Upon receiving the notification indicating that the constraint generation condition is not satisfied, the system design unit 20 further proceeds with concretizing the system configuration.

[0243] Thereafter, similarly, the system design unit 20 passes the system configuration information at that time to the design state determination unit 90 each time it applies one instantiation rule, and the design state determination unit 90 determines whether the constraint generation condition is satisfied. In the instantiation examples shown in Figures 23 to 28, system configuration T5 and previous system configurations do not include any instantiated machine nodes. Therefore, for system configuration T5 and previous system configurations, the design state determination unit 90 returns a determination result to the system design unit 20 that the constraint generation condition is not satisfied.

[0244] 23 to 28, the system configuration T6 includes a Machine_Z2 node, which is an instantiated machine node. Therefore, the design state determination unit 90 returns a determination result to the system design unit 20 that the constraint generation condition is satisfied for the system configuration T6.

[0245] Upon receiving the determination result indicating that the constraint generation conditions are satisfied, the system design unit 20 passes the configuration information of system configuration T6 to the constraint condition generation unit 50. Thereafter, each unit of the system design device 180 performs processing similar to that of the second embodiment. System configuration T7 and all subsequent system configurations include a Machine_Z2 node, which is an instantiated machine node. Therefore, for system configuration T7 and subsequent system configurations, the constraint condition generation unit 50 generates constraint conditions each time the system design unit 20 applies the instantiation rules to the system configuration, and thereafter, each unit of the system design device 180 performs processing similar to that of the second embodiment.

[0246] (Explanation of Effects) According to the system design device 180 of the third embodiment, it is possible to arbitrarily specify the timing for generating constraints for a system configuration under design. In this respect, according to the system design device 180 of the third embodiment, it is possible to efficiently determine whether or not to exclude a system configuration that cannot satisfy the constraints at an intermediate stage of design, thereby enabling efficient system design.

[0247] As described above, the design state determination unit 90 determines whether the target system configuration satisfies the preset candidate determination start condition. The constraint generation unit 50 generates constraints when the design state determination unit 90 determines that the target system satisfies the candidate determination start condition. When the constraint generation unit 50 generates constraints, the constraint verification unit 30 determines whether the target system configuration can satisfy the constraints. As described above, the system design device 180 allows the timing of generating constraints for the system configuration being designed to be arbitrarily specified. In this respect, the system design device 180 can efficiently determine whether to exclude system configurations that cannot satisfy constraints during the design stage, thereby enabling efficient system design.

[0248] 34 is a diagram showing an example of the configuration of a system design device according to a fourth embodiment. In the configuration shown in Fig. 34, a system design device 610 includes a constraint condition generation unit 611, a constraint verification unit 612, a candidate narrowing unit 613, and a concretization unit 614.

[0249] In this configuration, the constraint generation unit 611 is linked to system configuration information indicating a target system configuration that is one of candidates for system design by repeatedly applying concatenation rules to a system configuration including abstract components, and selects one or more components of the target system configuration based on a component selection method indicated in the constraint generation information that indicates a method for generating constraints for the target system configuration.The constraint generation unit 611 then applies the constraint generation method indicated in the system configuration information or the constraint generation information to the information set for the selected components to generate constraints for the target system configuration.

[0250] The constraint verification unit 612 determines whether the target system configuration can satisfy the constraint conditions. If the constraint verification unit 612 determines that the target system configuration cannot satisfy the constraint conditions, the candidate narrowing down unit 613 excludes the target system configuration from candidates for system design. The concretization unit 614 advances system design by applying concretization rules to the candidates for system design. The constraint generation unit 611 is an example of a constraint generation means. The constraint verification unit 612 is an example of a constraint verification means. The candidate narrowing down unit 613 is an example of a candidate narrowing down means. The concretization unit 614 is an example of a concretization means.

[0251] The system design device 610 can determine whether multiple components of a system configuration, not just two components whose relationship is directly shown, can satisfy the constraints. The system design device 80 can exclude system configurations that cannot satisfy the constraints from candidates for system design, thereby enabling efficient system design.

[0252] 35 is a diagram showing an example of the configuration of a system design device according to a fifth embodiment. In the configuration shown in Fig. 35, a system design device 620 includes a constraint generation information registration unit 621, a constraint generation unit 622, a constraint verification unit 623, a candidate narrowing unit 624, and a concretization unit 625.

[0253] In this configuration, the constraint generation information registration unit 621 accepts input of constraint generation information indicating a method for generating constraints that must be satisfied by a system configuration that is a candidate for system design by repeatedly applying concretization rules to a system configuration that includes abstract components.

[0254] The constraint generation unit 622 generates constraints that the target system configuration must satisfy based on the system configuration information indicating the target system configuration, which is one of the candidates for system design, and the constraint generation information. The constraint verification unit 623 determines whether the target system configuration can satisfy the constraints.

[0255] If the constraint verification unit 623 determines that the target system configuration cannot satisfy the constraint conditions, the candidate narrowing unit 624 excludes the target system configuration from candidates for system design. The concretization unit 625 advances the system design by applying concretization rules to the candidates for system design.

[0256] The constraint generation information registration unit 621 corresponds to an example of a constraint generation information registration means. The constraint generation unit 622 corresponds to an example of a constraint generation means. The constraint verification unit 623 corresponds to an example of a constraint verification means. The candidate narrowing down unit 624 corresponds to an example of a candidate narrowing down means. The concretization unit 625 corresponds to an example of a concretization means.

[0257] According to the system design device 620, the user can input desired constraint generation information from the constraint generation information registration unit 621. In this respect, the system design device 620 can design a system that satisfies the conditions desired by the user.

[0258] Furthermore, the system design device 620 can determine whether or not multiple components of the system configuration can satisfy the constraints, not just two components whose relationship is directly indicated, based on the constraint generation information input from the constraint generation information registration unit 621. The system design device 80 can exclude system configurations that cannot satisfy the constraints from candidates for system design, thereby enabling efficient system design.

[0259] Sixth Embodiment Fig. 36 is a diagram showing an example of a processing procedure in a system design method according to a sixth embodiment. The method shown in Fig. 36 includes generating constraint conditions (step S611), verifying whether the constraint conditions are satisfied (step S612), narrowing down candidates (step S613), and specifying them (step S614).

[0260] In generating constraints (step S611), constraints are generated by linking the system configuration information indicating the target system configuration, which is one of the candidates for system design by repeatedly applying concatenation rules to a system configuration including abstract components, to the system configuration information, selecting one or more components of the target system configuration based on a component selection method indicated in the constraint generation information, which indicates a method for generating constraints for the target system configuration, and applying the constraint generation method indicated in the system configuration information or the constraint generation information to the information set for the selected components.

[0261] In verifying the success or failure of the constraints (step S612), it is determined whether the target system configuration can satisfy the constraints. In narrowing down the candidates (step S613), if it is determined that the target system configuration cannot satisfy the constraints, the target system configuration is excluded from the candidates for system design. In concretization (step S614), the system design is advanced by applying concretization rules to the candidates for system design.

[0262] According to the system design method shown in Fig. 36, it is possible to determine whether or not multiple components of a system configuration can satisfy the constraint conditions, not just two components whose relationship is directly shown. According to the system design method shown in Fig. 36, system configurations that cannot satisfy the constraint conditions can be excluded from candidates for system design, which allows for efficient system design.

[0263] 37 is a schematic block diagram illustrating the configuration of a computer according to at least one embodiment. In the configuration shown in FIG. 37, a computer 700 includes a CPU (Central Processing Unit) 710, a main memory device 720, an auxiliary memory device 730, and an interface 740.

[0264] One or more of the above-described system design devices 80, 180, 610, and 620, 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 storage areas in the main storage device 720 corresponding to each of the above-described storage units 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.

[0265] When the system design device 80 is implemented in a computer 700, the input / output unit 10, the system design unit 20, the constraint verification unit 30, the design information recording unit 40, the constraint condition generation unit 50, the constraint function recording unit 60, the constraint function registration unit 70, and the operations of each of these units 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-mentioned processing in accordance with the program.

[0266] Furthermore, the CPU 710, in accordance with the program, allocates storage areas in the main storage device 720 for processing by the system design device 80, such as storage areas for the design information recording unit 40 and the constraint function recording unit 60. Communication between the system design device 80 and other devices is performed by the interface 740, which has a communication function, and performs communication under the control of the CPU 710. Interaction between the system design device 80 and a user, such as accepting registration of a constraint function by the constraint function registration unit 70, is performed by the interface 740, which has a display device and an input device, displaying various images under the control of the CPU 710 and accepting user operations.

[0267] When the system design device 180 is implemented in a computer 700, the input / output unit 10, system design unit 20, constraint verification unit 30, design information recording unit 40, constraint condition generation unit 50, constraint function recording unit 60, constraint function registration unit 70, design state determination unit 90, and the operations of each of these units 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-mentioned processing in accordance with the program.

[0268] Furthermore, the CPU 710, in accordance with the program, allocates storage areas in the main storage device 720 for processing by the system design device 180, such as storage areas for the design information recording unit 40 and the constraint function recording unit 60. Communication between the system design device 180 and other devices is performed by the interface 740, which has a communication function, and performs communication under the control of the CPU 710. Interaction between the system design device 180 and a user, such as accepting registration of a constraint function by the constraint function registration unit 70, is performed by the interface 740, which has a display device and an input device, displaying various images under the control of the CPU 710 and accepting user operations.

[0269] When the system design device 610 is implemented in a computer 700, the operations of the constraint condition generation unit 611, the constraint verification unit 612, the candidate narrowing down unit 613, and the concretization unit 614 are stored in the form of a program in the 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-mentioned processing in accordance with the program.

[0270] Furthermore, the CPU 710 allocates a storage area for processing of the system design device 610 in the main storage device 720 in accordance with the program. Communication between the system design device 610 and other devices is achieved by the interface 740 having a communication function and performing communication under the control of the CPU 710. Interaction between the system design device 610 and a user is achieved by the interface 740 having a display device and an input device, displaying various images under the control of the CPU 710, and accepting user operations.

[0271] When the system design device 620 is implemented in a computer 700, the operations of the constraint generation information registration unit 621, the constraint generation unit 622, the constraint verification unit 623, the candidate narrowing down unit 624, and the concretization unit 625 are stored in the form of a program in the 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-mentioned processing in accordance with the program.

[0272] Furthermore, the CPU 710 allocates a storage area in the main memory device 720 for processing by the system design device 620 in accordance with the program. Communication between the system design device 620 and other devices is achieved by the interface 740 having a communication function and performing communication under the control of the CPU 710. Interaction between the system design device 620 and a user is achieved by the interface 740 having a display device and an input device, displaying various images under the control of the CPU 710, and accepting user operations.

[0273] Alternatively, a program for executing all or part of the processing performed by the system design devices 80, 180, 610, and 620 may be recorded on a computer-readable recording medium, and the program may be loaded into a computer system and executed to perform the processing of each unit. Note that the term "computer system" here includes hardware such as an operating system (OS) and peripheral devices. Furthermore, the term "computer-readable recording medium" refers to portable media such as flexible disks, optical magnetic disks, read-only memories (ROMs), and compact disc read-only memories (CD-ROMs), as well as storage devices such as hard disks built into the computer system. The program may be designed to implement part of the aforementioned functions, or may be capable of implementing the aforementioned functions in combination with a program already stored in the computer system.

[0274] Although an embodiment of the present invention has been described in detail above with reference to the drawings, the specific configuration is not limited to this embodiment, and includes designs within the scope of the gist of the present invention.

[0275] A part or all of the above-described embodiments can be described as, but not limited to, the following supplementary notes.

[0276] (Supplementary Note 1) A system design device comprising: constraint generation means linked to system configuration information indicating a target system configuration that is one of candidate targets for system design by repeatedly applying concretization rules to a system configuration including abstract components, the constraint generation means selecting one or more components of the target system configuration based on a component selection method indicated in constraint generation information that indicates a method for generating constraints for the target system configuration, and applying the constraint generation method indicated in the system configuration information or the constraint generation information to information set in the selected components to generate constraints for the target system configuration; constraint verification means determining whether the target system configuration can satisfy the constraints; candidate narrowing means for excluding the target system configuration from candidate targets for the system design when the constraint verification means determines that the target system configuration cannot satisfy the constraints; and concretization means for advancing the system design by applying the concretization rules to the candidate targets for system design.

[0277] (Supplementary Note 2) The system design device according to Supplementary Note 1, further comprising: a constraint generation information storage means for storing the constraint generation information, wherein the constraint generation information includes constraint generation information identification information for identifying the constraint generation information itself, and the system configuration information to which the constraint generation information is linked includes constraint generation information identification information for identifying the constraint generation information to which it is linked.

[0278] (Supplementary Note 3) The system design device according to Supplementary Note 2, further comprising: constraint generation information registration means for accepting input of new constraint generation information and storing the input constraint generation information in the constraint generation information storage means.

[0279] (Supplementary Note 4) The system design device according to any one of Supplementary Notes 1 to 3, wherein the system configuration information includes a model indicating a configuration of a process executed by the system configuration, and the constraint generation means generates constraints related to the process based on the model indicating the configuration of the process.

[0280] (Supplementary Note 5) The system design device according to Supplementary Note 4, wherein the system configuration information includes information on processing times for each of the processes, and the constraint generation means extracts a group of processes that constitute a series of processing executed by a predetermined process call specified in the system configuration information based on a process extraction method indicated in the constraint generation information, and generates a constraint that the total processing time of each process included in the extracted group of processes is within an allowable time range specified for the process call.

[0281] (Supplementary Note 6) The system design device according to Supplementary Note 4, wherein the system configuration information includes information on the amount of computational resources used by each of the processes, and the constraint generation means extracts a group of processes that utilizes specified computational resources indicated in the system configuration information based on a process extraction method indicated in the constraint generation information, and generates a constraint stating that the total amount of computational resources required for each process included in the extracted process group to perform processing at a service time and processing request arrival rate specified for that process is within the range of the amount of computational resources that can be provided by the computational resources.

[0282] (Supplementary Note 7) The system design device according to any one of Supplementary Notes 1 to 6, further comprising: a design state determination means for determining whether or not the target system configuration satisfies a preset candidate determination start condition; wherein the constraint generation means generates the constraint condition when the design state determination means determines that the target system satisfies the candidate determination start condition; and the constraint verification means, when the constraint generation means generates the constraint condition, determines whether or not the target system configuration can satisfy the constraint condition.

[0283] (Supplementary Note 8) A system design device comprising: a constraint generation information registration means for accepting input of constraint generation information indicating a method of generating constraints to be satisfied by a system configuration that is a candidate for system design by repeatedly applying concretization rules to a system configuration including abstract components; a constraint generation means for generating constraints to be satisfied by a target system configuration based on system configuration information indicating a target system configuration that is one of the candidate targets for system design and the constraint generation information; a constraint verification means for determining whether the target system configuration can satisfy the constraints; a candidate narrowing means for excluding the target system configuration from the candidate targets for system design when the constraint verification means determines that the target system configuration cannot satisfy the constraints; and a concretization means for proceeding with the system design by applying the concretization rules to the candidate targets for system design.

[0284] (Supplementary Note 9) A system design method comprising: linking to system configuration information indicating a target system configuration that is one of candidates for system design by repeatedly applying concretization rules to a system configuration including abstract components, selecting one or more components of the target system configuration based on a component selection method indicated in constraint generation information that indicates a method for generating constraints for the target system configuration, applying the constraint generation method indicated in the system configuration information or the constraint generation information to information set in the selected components to generate constraints for the target system configuration, determining whether or not the target system configuration can satisfy the constraints, excluding the target system configuration from candidates for system design when it is determined that the target system configuration cannot satisfy the constraints, and proceeding with the system design by applying the concretization rules to the candidates for system design.

[0285] (Supplementary Note 10) A recording medium that records a program for causing a computer to execute the following: selecting one or more components of a target system configuration based on a component selection method indicated in constraint generation information that is linked to system configuration information indicating a target system configuration that is one of candidates for system design by repeatedly applying concretization rules to a system configuration including abstract components, and that indicates a method for generating constraints for the target system configuration, and applying the constraint generation method indicated in the system configuration information or the constraint generation information to information set in the selected components to generate constraints for the target system configuration; determining whether the target system configuration can satisfy the constraints; excluding the target system configuration from the candidates for system design when it is determined that the target system configuration cannot satisfy the constraints; and proceeding with the system design by applying the concretization rules to the candidates for system design.

[0286] (Appendix 11) The recording medium described in Appendix 10, wherein the constraint generation information is programmed as a function including a module that executes a component selection method to select one or more components of the target system configuration, and a module that applies a constraint generation method indicated in the system configuration information or the constraint generation information to information set in the selected components to generate constraints for the target system configuration.

[0287] The present invention may be applied to a system design device, a system design method, and a recording medium.

[0288] 10 Input / output unit 20 System design unit 21, 613, 624 Candidate narrowing unit 22, 614, 625 Materialization unit 30, 612, 623 Constraint verification unit 40 Design information recording unit 50, 611, 622 Constraint condition generation unit 60 Constraint function recording unit 70 Constraint function registration unit 80, 180, 610, 620 System design device 90 Design state determination unit

Claims

1. a constraint condition generation means for generating constraint conditions for the target system configuration based on information on the target system configuration, the constraint condition generation means being linked to system configuration information indicating a target system configuration which is one of candidates for system design by repeatedly applying concretization rules to a system configuration including abstract components, the constraint condition generation means being configured to select one or more components of the target system configuration based on a component selection method indicated in constraint condition generation information indicating a method for generating constraint conditions for the target system configuration, and generating constraint conditions for the target system configuration based on information set for the selected components and the concretization rules or the constraint condition generation method indicated in the constraint condition generation information; a constraint verification means for determining whether the target system configuration can satisfy the constraint conditions; a candidate narrowing means for excluding the target system configuration from candidates for the system design when the constraint verification means determines that the target system configuration does not satisfy the constraint conditions; a concretization means for applying the concretization rules to candidates for the system design to advance the system design; A system design device comprising:

2. A constraint condition generation information storage means for storing the constraint condition generation information. Further comprising: the constraint generating information includes constraint generating information identification information for identifying the constraint generating information itself, the system configuration information to which the constraint condition generation information is linked includes constraint condition generation information identification information for identifying the constraint condition generation information to which the constraint condition generation information is linked; The system design apparatus according to claim 1 .

3. a constraint condition generating information registering means for accepting input of new constraint condition generating information and storing the input constraint condition generating information in the constraint condition generating information storage means; The system design apparatus of claim 2 , further comprising:

4. the system configuration information includes a model indicating a configuration of a process executed by the system configuration; the constraint generating means generates constraints for the process based on a model indicating a configuration of the process; The system design device according to any one of claims 1 to 3.

5. the system configuration information includes information on a processing time for each of the processes; the constraint condition generation means extracts a process group constituting a series of processing executed by a predetermined process call specified in the system configuration information based on a process extraction method indicated in the constraint condition generation information, and generates a constraint condition stating that the total processing time of each process included in the extracted process group is within an allowable time range specified for the process call. The system design apparatus according to claim 4.

6. the system configuration information includes information on a computational resource usage amount for each process; the constraint condition generation means extracts a process group that utilizes a predetermined computational resource indicated in the system configuration information based on a process extraction method indicated in the constraint condition generation information, and generates a constraint condition stating that the total amount of computational resources required for each process included in the extracted process group to perform processing at a service time and a processing request arrival rate designated for that process, for the process group, is within a range of the amount of computational resources that can be provided by the computational resources; The system design apparatus according to claim 4.

7. A design state determination means for determining whether the target system configuration satisfies a preset candidate determination start condition. Further equipped with the constraint condition generating means generates the constraint condition when the design state determining means determines that the target system configuration satisfies the candidate determination start condition; the constraint verification means, when the constraint generation means generates the constraint, determines whether or not the target system configuration can satisfy the constraint; The system design apparatus according to any one of claims 1 to 6.

8. a constraint generation information registration means for receiving an input of constraint generation information indicating a method of generating constraints to be satisfied by a system configuration that is a candidate for a system design by repeatedly applying an instantiation rule to a system configuration including an abstract component; a constraint generating means for generating constraints to be satisfied by a target system configuration based on system configuration information indicating a target system configuration that is one of candidates for the system design and the constraint generating information; a constraint verification means for determining whether the target system configuration can satisfy the constraint conditions; a candidate narrowing means for excluding the target system configuration from candidates for the system design when the constraint verification means determines that the target system configuration does not satisfy the constraint conditions; a concretization means for applying the concretization rules to candidates for the system design to advance the system design; A system design device comprising:

9. a method for generating a constraint for the target system configuration by applying a method for generating a constraint for the target system configuration to the system configuration information including the abstract components, the method being linked to system configuration information indicating a target system configuration which is one of the candidates for a system design by repeatedly applying a concretization rule to the system configuration including the abstract components, the method being linked to system configuration information indicating a target system configuration which is one of the candidates for a system design by repeatedly applying a concretization rule to the system configuration including the abstract components, the method being linked to system configuration information indicating a target system configuration which is one of the candidates for a system design by repeatedly applying a concretization rule to the system configuration including the abstract components, the method being linked to system configuration information indicating a target system configuration which is one of the candidates for a system design by repeating the application of ... determining whether the target system configuration can satisfy the constraints; If it is determined that the target system configuration cannot satisfy the constraint condition, the target system configuration is excluded from candidates for the system design; and advancing the system design by applying the instantiation rules to candidates for the system design target. A system design method comprising:

10. On the computer, a method for generating a constraint for the target system configuration by applying a method for generating a constraint for the target system configuration to the system configuration information including the abstract components; determining whether the target system configuration can satisfy the constraints; excluding the target system configuration from candidates for the system design when it is determined that the target system configuration cannot satisfy the constraint condition; advancing the system design by applying the instantiation rules to candidates for the system design; A program for executing the above.