System automatic design device, system automatic design method and program

Abstract

To provide a technique for efficiently, in other words, quickly performing automatic design of a redundant system configuration.SOLUTION: A system automatic design device includes means for receiving a system requirement, and means for applying a previously defined embodiment pattern of each component based on the system requirement, and thereby deriving a specific system configuration, wherein the means for deriving the system configuration progresses the embodiment of a plurality of elements expressing a plurality of the same type of components as one component as they are, without decomposing the plurality of elements into individual components, when the plurality of elements are embodied, and thereby designs a redundant system configuration.SELECTED DRAWING: Figure 20

Description

[Technical Field]

[0001] The present disclosure relates to an automatic system design device, an automatic system design method, and a program. [Background technology]

[0002] As information technology (IT) and digital transformation (DX) become more prevalent, the systems being constructed are becoming increasingly diverse and larger in scale. Because it is extremely difficult to manually design, build, and manage these systems, autonomous operation technologies that autonomously perform the entire process of system design, build, and operation management are attracting attention. One of the key technologies is automated system design technology, which automatically designs a system configuration that meets the diverse requirements of users (designers). System automation technology derives a specific system configuration that meets the user's abstract requirements, known as intent. There are a wide variety of system requirements that users can specify, but one of the most important is the availability requirement. Availability requirements are requirements for the continued use of a system, and it is important to be able to automatically design a redundant system configuration that satisfies the availability requirement, i.e., that allows the system to continue operating even if part of the system fails.

[0003] The automated system configuration design techniques disclosed in Patent Document 1 and Non-Patent Document 1 automatically design a specific system configuration that satisfies the functional and non-functional requirements requested by a user. The techniques disclosed in these documents predefine information (hereinafter referred to as an instantiation pattern) that expresses how each system component is instantiated. Various system configuration proposals are generated by arbitrarily combining these instantiation patterns, and the system can be automatically designed by searching for an appropriate one from among the generated configuration proposals. In addition to the instantiation patterns, conditions that each system component itself or its surrounding components must satisfy are defined. This immediately rejects configuration proposals that do not meet the conditions, thereby limiting the search range and streamlining the design. However, these documents only describe a framework for automatically designing a system configuration that satisfies various system requirements, but do not provide information on specific instantiation patterns for automatically designing a system with a specific configuration. Therefore, it is difficult to design a redundant system configuration based solely on the information described in these documents.

[0004] Furthermore, Patent Document 2 achieves automatic design using a different approach from the aforementioned documents. In this document, in an environment where redundant network paths already exist but the network devices to be used to mediate those paths have not yet been determined, a physical configuration is designed by selecting physical devices that satisfy communication requirements entered by a user. In this case, the design time is shortened by treating the redundant paths and devices as a single unified element, but the redundant configuration itself is not designed. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] International Publication No. 2019 / 216082 [Patent Document 2] Patent Application No. 2021-136692 [Non-patent literature]

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

[0007] There is a need for a technique for automatically designing a redundant system configuration efficiently, i.e., in a short time. One of the objects of the present disclosure is to provide an automatic system design method for achieving automatic design of a redundant configuration in a short time. [Means for solving the problem]

[0008] According to one aspect of the present disclosure, an automatic system design apparatus includes means for accepting system requirements and means for deriving a specific system configuration by applying predefined instantiation patterns for each component based on the system requirements, wherein the means for deriving the system configuration has a function for designing a redundant configuration from a plurality of elements including an undetermined number of components or two or more components when the plurality of elements are a combination of a plurality of components of the same type expressed as a single component, and when instantiating the plurality of elements, the means for deriving the system configuration designs a redundant system configuration by proceeding with the instantiation of the plurality of elements as they are without breaking them down into individual components.

[0009] According to one aspect of the present disclosure, an automated system design method receives system requirements, and derives a specific system configuration by applying predefined instantiation patterns for each component based on the system requirements. In the derivation, when multiple elements are formed by integrating multiple components of the same type and expressing them as a single component, the multiple elements are not decomposed into individual components, but are instantiated as they are, thereby deriving a redundant system configuration from the multiple elements, the number of which is undetermined or which includes two or more of the components.

[0010] According to one aspect of the present disclosure, a program causes a computer to receive system requirements, and derive a specific system configuration by applying a predefined concretization pattern for each component based on the system requirements. In the derivation, when multiple elements are formed by combining multiple components of the same type and expressing them as a single component, the program causes the computer to execute a process of deriving a redundant system configuration from multiple elements, the number of which is undetermined or includes two or more of the components, by proceeding with concretization of the multiple elements as they are without breaking them down into individual components. [Effects of the Invention]

[0011] According to the present disclosure, in the automatic design of a system, by proceeding with the design while keeping together components that will be embodied in the same partial configuration (a partial configuration of the system as opposed to the overall system configuration), the amount of processing required to complete the system design can be reduced, and a specific system configuration can be automatically designed in a short amount of time. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram showing an example of a configuration of an automatic system design apparatus. [Figure 2] FIG. 10 is a diagram illustrating an example of an expression of system configuration information. [Figure 3] FIG. 10 is a diagram illustrating an example of a text representation of system configuration information. [Figure 4] FIG. 10 is a diagram illustrating an example of a definition format of a component. [Figure 5] FIG. 10 is a diagram illustrating an example of a definition of a component part. [Figure 6] FIG. 10 is a diagram illustrating an example of a definition of a relationship between component parts. [Figure 7A] FIG. 1 is a first diagram showing an example of a specific system configuration. [Figure 7B] FIG. 2 is a second diagram showing an example of a specific system configuration. [Figure 8] FIG. 10 is a diagram illustrating an example of a process for making a plurality of elements redundant and implementing them; [Figure 9] FIG. 10 illustrates an example of a textual representation of an expected surrounding configuration that can be applied to multiple elements. [Figure 10] 10A and 10B are diagrams illustrating examples of implementations in which priority is given to decomposition of multiple elements and in which priority is given to expansion. [Figure 11] FIG. 10 is a diagram showing an example of the flow of a process for expanding a plurality of elements when an absolute number is specified. [Figure 12] FIG. 10 is a diagram showing an example of the flow of a process for expanding a plurality of elements when a relative number is specified. [Figure 13] FIG. 10 is a diagram illustrating an example of a textual representation of configuration information of a system including deployment dependencies. [Figure 14] FIG. 10 is a diagram illustrating an example of the flow of a decomposition process for multiple elements specified by absolute numbers. [Figure 15] FIG. 10 is a diagram illustrating an example of the flow of a decomposition process for multiple elements specified by relative numbers. [Figure 16] FIG. 10 is a diagram illustrating an example of a system configuration designed based on differences in timing of decomposition of multiple elements. [Figure 17] 10 is a flowchart illustrating an example of an operation of the automatic system design device. [Figure 18] 10 is a flowchart showing an example of details of a process for extracting a system configuration that can be generated in one stage of instantiation processing. [Figure 19] 10 is a flowchart showing an example of details of the expansion process and decomposition process of a plurality of elements. [Figure 20]FIG. 2 is a second block diagram showing an example of the configuration of an automatic system design apparatus. [Figure 21] 10 is a second flowchart illustrating an example of a configuration showing an example of an operation of the automatic system design device. [Figure 22] FIG. 1 illustrates an example of a hardware configuration of an automatic system design apparatus. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, an automatic system design device according to each embodiment of the present disclosure will be described with reference to the drawings. In the drawings used in the following description, the description of parts not related to the present disclosure may be omitted or not shown. The same or equivalent parts in all drawings will be denoted by the same reference numerals, and common descriptions may be omitted.

[0014] First Embodiment [Configuration Description] An automatic system design apparatus according to an embodiment of the present disclosure will be described. Fig. 1 is a block diagram showing the configuration of the automatic system design apparatus. As shown in Fig. 1, the automatic system design apparatus 10 includes an input / output unit 100, a configuration instantiation unit 200, design information 300, and a verification unit 400.

[0015] The input / output unit 100 shown in FIG. 1 has a function of accepting system requirements, such as the configuration, functions, and performance expected of the system, as input and passing them to the configuration instantiation unit 200. It also has a function of receiving system configuration information that satisfies the system requirements from the configuration instantiation unit 200 and outputting the system configuration information. If the configuration instantiation unit 200 does not receive system configuration information that satisfies the system requirements, it outputs information indicating that the design of a system configuration that satisfies the system requirements has failed. The configuration instantiation unit 200 receives the system requirements from the input / output unit 100 and derives a specific system configuration based on the received system requirements. Specifically, the configuration instantiation unit 200 obtains design information applicable to the system requirements or the system configuration under design from the design information 300 and applies it to the system requirements or the system configuration under design, thereby gradually instantiating the system configuration. Design information applicable to the system requirements or the system configuration refers to design information that is applicable to components included in the system requirements or the system configuration that have not yet been instantiated. If there are multiple applicable design information, multiple pieces of design information can be obtained. The configuration instantiation unit 200 further passes system configuration information under design to the verification unit 400 and receives the verification results from the verification unit 400. The design information 300 is design information that defines attribute information of the system components and the instantiation method (concretization pattern). The verification unit 400 acquires the system configuration information under design and the constraints that the system configuration must satisfy from the configuration instantiation unit 200 and verifies whether or not those constraints are satisfied. The verification unit 400 then returns the verification results to the configuration instantiation unit 200. The timing at which the configuration instantiation unit 200 sends the system configuration information and the constraints to the verification unit 400, i.e., the timing at which the verification unit 400 verifies the constraints, can be specified arbitrarily. For example, verification may be performed each time one piece of design information is applied to the system configuration under design, or after multiple pieces of design information are applied.

[0016] As shown in FIG. 1, the configuration instantiation unit 200 is composed of a design information application unit 210 and an expansion dependency instantiation unit 220. The design information application unit 210 applies design information acquired from design information 300 to the system requirements or the system configuration being designed, instantiating the system configuration in one stage. When the design information is applied to multiple elements, the expansion dependency instantiation unit 220 performs processing to instantiate the multiple elements so that there are no contradictions in the system configuration. Multiple elements are components that are multiple components of the same type grouped together and expressed as a single element.

[0017] As shown in Fig. 1, design information 300 includes decomposition design information 310 and expansion design information 320. Decomposition design information 310 is information that defines a specific instantiation method for multiple elements, taking into account the characteristics of the multiple elements, and defines a method for instantiating multiple elements by decomposing the components, i.e., by creating multiple components of the same type as the components themselves. Expansion design information 320 is information that defines a method for instantiating a component by generating surrounding components that are required for the existence of the component, regardless of whether it is multiple elements or not.

[0018] [Data Representation] Next, we will explain the data handled by the automatic system design device 10. The data handled by the automatic system design device 10 is mainly system requirements and system configuration. System requirements are information about the requirements that a user who designs a system expects from the system, and include information that represents the functional requirements and non-functional requirements of the system to be designed. System configuration is configuration information of a system being designed by the configuration instantiation unit 200, or configuration information of a system whose instantiation is finally completed and output by the automatic system design device 10.

[0019] System requirements and system configuration are expressed using nodes and edges. Nodes represent the components that make up a system, and edges represent the relationships between them. Components and their relationships are collectively referred to as components. Hereafter, the term "relationship" refers to the relationship between components. Components can be assigned any information that describes their characteristics. Nodes and edges can also be assigned constraints, which are expected conditions for themselves or surrounding components. Figure 2 shows an example of a system configuration. Circles represent nodes, and arrows connecting the circles represent edges. The names attached to nodes and edges indicate the type names of components and relationships, respectively. Dotted lines represent abstract components, i.e., components that have not yet been fully realized, while solid lines represent concrete components. For example, Figure 2 shows system configuration information representing a system in which an application (Application) communicates with a specific MySQL® database server (Conn_To).

[0020] Since Application is an abstract node that represents some kind of application, it is displayed as a dotted line at this point, and will be instantiated into a specific application in the process of instantiating the system configuration.

[0021] The configuration information shown in Figure 2 may be expressed not only graphically but also in text. There are no particular limitations on the method of textual expression as long as it can be converted into a uniquely equivalent diagram. Figure 3 shows an example of textual expression. Configuration information in text format consists of a list of component parts and the relationships between them. For each component part, at least an identifier that identifies the component part and the type of the component part are defined, and property information for the component part is defined as needed. For a relationship, at least an identifier that identifies the relationship, the type of the relationship, and identifiers of the component parts at the source and destination of the relationship are defined, and property information for the relationship is defined as needed. In Figure 3, "$" indicates a reference to the identifier of the variable name. If it is not necessary to define the identifier of a component part because it is not referenced in other definitions of the component part, the identifier definition may be omitted.

[0022] [Component Definition] Next, we will explain how to define a component. Figure 4 shows the format for defining a component. For a component, you can specify information that defines its characteristics, such as its type name, inheritance source, concreteness, and properties, as well as the configuration information that the component expects from its surroundings. Hereafter, the configuration information expected from its surroundings will be referred to as the "expected peripheral configuration." The type name is the name of the type of the component. The inheritance source indicates the type of other components that the component inherits; if not specified, it indicates that nothing is inherited. By inheriting the type of other components, a component inherits the properties and expected peripheral configuration information of the inheritance source type. Concreteness is information that indicates whether the component itself is an abstract component that can be further concreted, or a concrete component that cannot be further concreted; if it is true, it is a concrete component, and if it is false, it is an abstract component. The properties are attribute information that indicates the characteristics of the component, and any attribute information can be specified depending on the type of the component.

[0023] The expected peripheral configuration is the configuration information that must exist around a component for it to be valid. The presence of the configuration described here indicates that the component itself is valid. For example, for an application to exist within a system, the application must be installed on some kind of OS. Therefore, the expected peripheral configuration of an application-type component defines configuration information indicating that the application is hosted by some kind of OS-type component. Multiple expected peripheral configurations can be defined for a single component, and each expected peripheral configuration can describe the name of the expected peripheral configuration, prerequisite configuration information, required configuration information, and constraints. Prerequisite configuration information is the condition for applying the expected peripheral configuration. If the system configuration in the design phase satisfies the configuration information described in the prerequisite configuration information, the system configuration will be realized by applying the required configuration information described below. The required configuration information represents one step in realizing the system configuration by realizing the configuration information described here. Constraints represent the constraints that each component must satisfy when applying this expected peripheral configuration.

[0024] The process of instantiating a system configuration based on input system requirements consists of two steps: instantiating the components contained in the system requirements or the system configuration under design into concrete components, and instantiating the system configuration by generating the necessary components to satisfy the expected peripheral configurations defined for each component. The system design is considered complete when these two steps are completed for all components in the system configuration. That is, the design of the system configuration is considered complete when the concreteness of all components in the system configuration is true and the expected peripheral configurations of all components are satisfied. If multiple expected peripheral configurations are defined for a single component, it is sufficient that any one of those expected peripheral configurations is satisfied. Furthermore, when instantiating a system to satisfy the expected peripheral configurations of components, if all or some of the components listed in the required configuration information already exist in the system configuration, the system may instantiate a new configuration that generates new components, or it may instantiate a configuration that reuses existing components without generating new components. For example, if the expected peripheral configuration of an application-type component defines configuration information that it is hosted by some OS-type component, a new OS may be added to the system configuration being designed to satisfy the expected peripheral configuration of this application, or if an OS already exists in the system configuration where another application is hosted, a new OS may be instantiated as a configuration where the application is hosted by the existing OS without adding a new OS.In this way, when applying the expected peripheral configuration, it is possible to arbitrarily choose whether to instantiate the component into a newly generated configuration or into a configuration that reuses existing components, and different system configurations will be designed depending on the choice.

[0025] Below, we will show examples of defining components and their relationships. First, Figure 5 shows an example of component definitions for an application, database server, OS, and machine. In Figure 5(a), Application is a component that represents an application. Application is a component that abstracts individual specific application software and is instantiated into some specific application. Therefore, concreteness is set to false. Furthermore, because "an application must be hosted on an OS in order to run," this configuration information is defined in the expected peripheral configuration called "App_is_hosted_on_OS." This expected peripheral configuration specifically defines that a partial configuration with a Hosted_On relationship between Application and OS will be instantiated. An identifier in the expected peripheral configuration uniquely identifies a component within that expected peripheral configuration. For example, if multiple OS-type components appear in the expected peripheral configuration, an identifier is necessary to clearly identify which OS-type component it is. In the Conn_To(Application, DBServer) shown in Figure 6 (described later), multiple OS-type components are defined within the expected peripheral configuration, so the identification "os1" and "os2" are assigned to each OS-type component. Figure 5(a) also defines a component called App_a, which represents a specific application by inheriting Application. By inheriting the Application type, App_a inherits the properties and expected peripheral configuration defined in the Application type. Furthermore, because App_a is a component that represents a specific application, such as some kind of application product, specificity is set to true.

[0026] DBServer in Figure 5(b) is a component that represents a database server. DBServer is an abstract component that represents various specific database server products, and its concreteness is set to false. Like Application, DBServer requires that it be hosted on some OS, as defined in the expected configuration "DBServer_is_hosted_on_OS." Furthermore, a component called MySQL (registered trademark) is defined that inherits DBServer and represents a specific DBServer product. OS in Figure 5(c) is an abstract component that represents an operating system, and has a property called required_memory, which represents the amount of memory used by the OS. However, because OS-type components are abstract OSs, no specific value is set. Since an OS must be hosted on some machine to run, this is defined in the expected configuration "OS_is_hosted_on_Machine." Furthermore, a constraint for applying the expected configuration is that the amount of memory installed on the hosting machine must be greater than or equal to the memory usage of the OS itself. In addition, specific OS components, Windows (registered trademark) and Ubuntu (Ubuntu is a registered trademark) are defined by inheriting the OS, with specificity set to true and specific memory usage values set. Machine in Figure 5(d) is an abstract component representing the medium that hosts the OS and applications, and has a property called memory, which indicates the amount of memory installed on the machine. Furthermore, a Physical_Server component representing a general physical server is defined by inheriting Machine, with specificity set to true and the specific amount of installed memory specified.

[0027] Next, Figure 6 shows an example of the definition of the relationships between the components defined in Figure 5. Hosted_On in Figure 6(a) is a relationship that indicates that a component is hosted by another component, and defines three relationships: Hosted_On(Application, OS), which indicates that an Application is hosted on an OS; Hosted_On(DBServer, OS), which indicates that a DBServer is hosted on an OS; and Hosted_On(OS, Machine), which indicates that an OS is hosted on a Machine. The Hosted_On relationship is a concrete relationship, and is defined as not having any properties or expected peripheral configurations.

[0028] Conn_To is a relationship that indicates a logical or physical connection between two components, and three types are defined: Conn_To(Application, DBServer), which indicates a connection between an Application and a DBServer; Conn_To(OS, OS), which indicates a connection between OSs; and Conn_To(Machine, Machine), which indicates a connection between Machines. Conn_To(Application, DBServer) defines a configuration in which the OSs hosting the Application and DBServer at both ends are connected to each other via Conn_To as an expected peripheral configuration. This indicates that in order for an application and a database server to communicate, the OSs hosting them must be able to communicate with each other. Conn_To(OS, OS), which indicates a configuration in which the Machines hosting the OSs at both ends are connected to each other via Conn_To as an expected peripheral configuration.

[0029] Figures 7A and 7B show an example of a system configuration instantiation using the components and the relationships between them defined in Figures 5 and 6. The edge names in Figure 7 omit the type names of the nodes at both ends. In Figures 7A and 7B, the system requirement is to build a system that runs Application A, which uses a database. A configuration in which App_a and DBServer are connected via Conn_To is provided as input (S1 in Figure 7A). At this point, there are three components in the system configuration being designed. The system configuration is instantiated by instantiating these components themselves or by progressing to instantiation of a configuration that satisfies the expected peripheral configuration of the components. Here, App_a and Conn_To (Application, DBServer) have true concreteness, meaning they are not components that can be instantiated further. Furthermore, to apply the expected peripheral configuration of Conn_To (Application, DBServer), the Application and DBServer at both ends must each be hosted by an OS, so it cannot be applied at this point. For the above reasons, the three types of instantiation that can be applied at this point are (1) instantiating the expected peripheral configuration of App_a, (2) instantiating the expected peripheral configuration of DBServer, and (3) instantiating DBServer itself. Here, we will continue the explanation using the example where (1) instantiating the expected peripheral configuration of App_a is selected. App_a generates an OS to satisfy its expected peripheral configuration and instantiates a system configuration with a Hosted_On relationship with the OS (S2 in Figure 7A). Then, DBServer instantiates itself as MySQL (registered trademark) (S3 in Figure 7A) and instantiates the relationship between the OS and Hosted_On to satisfy DBServer's expected peripheral configuration (S4 in Figure 7A). Then, each OS itself is instantiated as Windows (registered trademark) or Ubuntu (registered trademark) (S5 in Figure 7A), and a Machine is instantiated to satisfy the OS's expected peripheral configuration (S6 in Figure 7A). Furthermore, each Machine is instantiated into a concrete Physical_Server (S7 in FIG. 7B).At this point, the prerequisite for applying the expected peripheral configuration of Conn_To(Application, DBServer) is that the Application and DBServer are each hosted on an OS, and so Conn_To(OS, OS) is instantiated between the OSs hosting the Application and DBServer to satisfy the expected peripheral configuration of Conn_To(Application, DBServer) (S8 in Figure 7B). Finally, Conn_To(Machine, Machine) is instantiated between the Machines hosting each OS to satisfy the expected peripheral configuration of Conn_To(OS, OS) (S9 in Figure 7B). At this point, the concreteness of all components in the system configuration being designed is true, and all components have a configuration that satisfies the expected peripheral configuration, so instantiation of the system configuration is complete.

[0030] Here, the system configuration does not necessarily have to be instantiated in the order shown in Figures 7A and 7B. If there are multiple instantiation patterns that can be applied to a certain component, any of them can be applied. For example, in addition to the pattern in which the S1 configuration in Figure 7A is instantiated into the S2 configuration, the system configuration can also be instantiated by first instantiating the DBServer itself into MySQL (registered trademark) from the S1 configuration. Furthermore, if there are multiple applicable instantiation patterns, the instantiation pattern to be applied can be selected randomly or can be determined using other techniques such as machine learning.

[0031] [Redundant configuration design] The automated design methods described so far basically assume that each component exists in a single instance. That is, each node represents one component, and each edge represents one relationship. However, in system design, there are cases where multiple components are desired, or where multiple components may exist but the number is undetermined. For example, when there are many terminals, such as PCs, the design may involve representing multiple terminals as a single component. Or, considering performance and availability, it may be necessary to run multiple copies of the same application, but the exact number is unknown at the pre-design stage. In this way, components with multiple or potentially multiple but undetermined numbers are called multiple elements. When system requirements or the system configuration being designed include multiple elements, the system configuration must be instantiated while taking into account the possibility of multiple components. However, the automated design methods described so far do not offer a special mechanism for easily designing a system configuration assuming the presence of multiple elements. In the following, we will explain mechanisms and instantiation patterns for consistently instantiating a system configuration containing multiple elements.

[0032] First, to handle multiple elements, we introduce the concept of number into each component. Specifically, we define a quantity property for all components, which represents the number of components themselves. Furthermore, we define an expected peripheral configuration that can be applied only to multiple elements whose quantity value is 2 or greater, or whose number is undetermined but can be 2 or greater. An expected peripheral configuration that applies only to multiple elements specifically instantiates a multiple element component by generating the same number of components with a quantity of 1 and the same type as the component itself. Figure 8 shows an example of an expected peripheral configuration that can be applied only to the components and relationships of multiple elements. Figure 8(a) represents the existence of three Applications using a single node, with quantity=3 set as the node property. The expected peripheral configuration for this multiple element is instantiated as a configuration that generates three nodes of the same Application type and with quantity=1, the quantity value of the multiple element. Furthermore, Figure 8(a) connects the multiple element to the same type of component instantiated from the multiple element using a "One_Of" relationship. In Figure 8(b), the existence of three edges between NodeA and NodeB is represented by a single edge, and the edge property is set to quantity = 3. The expected peripheral configuration of this edge is realized by generating three edges of the same Edge type as itself and with quantity = 1, which is the quantity value of multiple elements.

[0033] Figures 9(a) and 9(b) show examples of textual representations of expected peripheral configurations applicable to the components and relationships of multiple elements. The expected peripheral configurations applicable to multiple elements are not unique to each component type; instead, the same expected peripheral configuration is defined for all components of multiple elements and their relationships. Therefore, rather than defining the expected peripheral configurations applicable to each component, it is effective to define the expected peripheral configurations applicable to the components of multiple elements and the expected peripheral configurations applicable to the relationships of multiple elements together, and have each component inherit these configurations. Figure 9(a) defines the Component type as the expected peripheral configuration applicable to the components of multiple elements, while Figure 9(b) defines the Relationship type as the expected peripheral configuration applicable to the relationships of multiple elements. By defining each component by inheriting these types, it is possible for the component to have information about the expected peripheral configuration corresponding to multiple elements. In the following explanation, the term "decomposition" refers to the concrete implementation of the expected peripheral configuration of each component, which creates the same type of components as the quantity, as shown in Figures 8 and 9.

[0034] In this way, by adding properties to components and decomposing them accordingly, a redundant system configuration can be designed. However, this instantiation method involves prioritizing decomposition of multiple components to instantiate the system configuration, and each component generated by the decomposition is instantiated independently, resulting in a problem of increased design time. For example, as shown in FIG. 8(a), an application with quantity = 3 is decomposed into three applications with quantity = 1, and then each application is instantiated independently. In other words, the operating systems and machines required directly or indirectly by the applications are created. Therefore, a simple estimate shows that the number of components in the system configuration is three times greater than when an application with quantity = 1 is instantiated. In the automated design technology according to this embodiment, there are multiple expected peripheral configurations for each component, and a system configuration that meets the requirements is searched for from among various system configurations that can be designed by combining these configurations. Therefore, as the number of components in the system configuration increases, the number of possible configurations increases, and the system design time also increases.

[0035] Here, redundant configurations may have some structurally identical parts, making it unnecessary to design each redundant system completely independently. For example, when designing a system configuration with triplexed applications, it may be desirable to standardize the configuration to three physical servers of the same manufacturer and model number, each with the same type and version of the OS, MW, and application installed, in an on-premises environment. Regarding common subconfigurations, as shown in Figure 8(a), rather than immediately decomposing multiple elements and instantiating each of the decomposed components independently, the design can be efficiently advanced by proceeding with instantiation of the common subconfiguration without decomposing multiple elements, and then decomposing multiple elements after the instantiation of the common parts is completed. In the following explanation, the instantiation of components into a configuration other than decomposition, i.e., the instantiation of components by applying the expected peripheral configuration applicable to the components regardless of the number of components, is referred to as "expansion."

[0036] Figures 10(a) and 10(b) show examples of instantiation flows that prioritize decomposition of multiple elements and expansion of multiple elements, respectively. In Figure 10, the number enclosed in brackets "[ ]" following the name of a component indicates the quantity value of that component; no brackets indicate a quantity of 1. When decomposition of multiple elements is prioritized, an application with a quantity of 3 (a-1) is instantiated in one instantiation step into a configuration containing three applications with a quantity of 1 (a-2). Then, the middleware required by each application, the operating system required by the middleware, and the machine required by the operating system are instantiated in stages, completing the instantiation of one application system in three stages. Applying this to three applications requires a total of 10 stages of instantiation (a-3). On the other hand, if the deployment of multiple elements is prioritized, the application with quantity=3 (b-1) is instantiated by generating the middleware required by the application as its expected peripheral configuration without decomposition (b-2).The design then proceeds by instantiating the OS required by the middleware as its expected peripheral configuration, and the machine required by the OS as its expected peripheral configuration (b-3).Finally, the application with quantity=3 is decomposed to design a specific system configuration (b-4).In this case, the final system configurations shown in (a-3) and (b-4) are the same, but if the decomposition of multiple elements was prioritized, 10 stages of instantiation are required to complete the instantiation, whereas if the deployment were to continue with multiple elements, it would be completed in 4 stages of instantiation.

[0037] Here, when designing by expanding multiple elements as they are and then decomposing the multiple elements, it is not sufficient to simply decompose and instantiate only the multiple elements themselves, as shown in Figure 8. It is necessary to instantiate the system configuration while maintaining the relationships with the components generated by expanding the multiple elements and the components that have relationships with the multiple elements (i.e., components connected to the multiple elements by some kind of edge). Therefore, when expanding multiple elements and proceeding with the design, instantiation is carried out while retaining, as necessary, information that the components are generated by expanding multiple elements and information about the number of multiple elements from the expansion source. When decomposing the multiple elements, decomposition is carried out while maintaining the relationships required for the system configuration based on this information. Below, we will explain methods for expanding multiple elements and methods for decomposing multiple elements to achieve automatic system design that allows for the expansion of multiple elements.

[0038] [Multiple Element Expansion] First, we will explain how to expand multiple elements. When expanding multiple elements without decomposing them, that is, when concretizing multiple elements to satisfy the expected surrounding configuration required by the multiple elements, there are two possible ways to specify the number of components generated by expanding multiple elements.

[0039] The first method is to specify an absolute value, i.e., the total number of components generated by deployment, i.e., the number of components present in the system. For example, if you want to design a configuration in which multiple VMs (Virtual Machines) run on one physical server, it is effective to specify an absolute value, such as "1," for the number of components (quantity) representing the physical server generated by deploying multiple VMs.

[0040] The second method is to specify a relative value, i.e., the number of components generated by deployment per source multiple element. For example, if you want to design a configuration in which multiple VMs each run on independent physical servers, it is difficult to specify a specific value in advance because the total number of physical servers depends on the number of source VMs. Therefore, it is effective to specify a relative number, i.e., the number per source multiple element, such as requiring one physical server per source VM, and proceed with the specification.

[0041] In the former case, when multiple elements are decomposed after specifying absolute values and proceeding with expansion, it is necessary to materialize the system configuration in a way that maintains the relationships between each decomposed component and the components expanded from the decomposition source.On the other hand, in the latter case, when multiple elements are decomposed after specifying relative values and proceeding with expansion, it is necessary to materialize the system configuration by decomposing not only the components to be decomposed themselves but also the components that depend on the number of components to be decomposed.

[0042] The following describes the process of expanding by specifying an absolute value and the process of expanding by specifying a relative value.

[0043] (When specifying the number of components to be expanded as an absolute value) First, we will explain the process of expanding multiple elements when the number of elements at the expansion destination is specified as an absolute value. The multiple elements at the expansion source are instantiated into a configuration that satisfies their own expected peripheral configuration. Components newly generated during this instantiation, or components already instantiated in the system configuration and reused as the expected peripheral configuration of the multiple elements, set the total number of their own components to the quantity value. If the number is not clearly determined at that point, it can be specified in the form of a variable, but this value is determined independently of the number of elements at the expansion source.

[0044] Figure 11 shows the flow of the deployment process for multiple elements when the number of components to be deployed is specified as an absolute value. In Figure 11, Node_A has Node_B and Edge_1 defined as its expected peripheral configuration, and Node_B has Node_C and Edge_2 defined as its expected peripheral configuration. The number in brackets "[ ]" following the component name indicates the quantity value of that component. In other words, Figure 11 shows how Node_A, whose quantity is "n1," is deployed as multiple elements. Node_A is deployed by generating Edge_1 and Node_B to satisfy Node_A's expected peripheral configuration (Figure 11(b)). At this time, the generated Node_B and Edge_1 retain the values represented by the variables "n2" and "e1," respectively, as their total number on the system. If Node_B is then also deployed as multiple elements, it is instantiated by generating Edge_2 and Node_C to satisfy Node_B's expected peripheral configuration. Similarly in this case, the created Node_C and Edge_2 hold the values represented by the variables "n3" and "e2" as the quantity values, respectively, which represent the total number of nodes on the system.

[0045] (When specifying the number of components to be expanded as a relative value) Next, we will explain the deployment process of multiple elements when the number of deployment destination components is specified as a relative value. The deployment source components are instantiated into a configuration that satisfies their expected peripheral configuration. During this instantiation, the generated component, or a component already instantiated in the system configuration and reused as the expected peripheral configuration of the multiple elements, retains information indicating which multiple elements it was deployed from (called the "deployment dependency relationship"), the number of itself per deployment source component, and the number of deployment source components, as information indicating that it was deployed from multiple elements. If the deployment dependency relationship is multi-level, i.e., the element generated by the deployment of multiple elements is also a multiple element, and the expansion of that multiple element generates another component, the last generated component retains the number of itself per component in direct deployment dependency relationships, the number of components in direct deployment dependency relationships, and the number of components in indirect deployment dependency relationships. Figure 12 shows the flow of the deployment process of multiple elements when the number of deployment destination components is specified as a relative value. First, Node_A is instantiated by generating Edge_1 and Node_B to satisfy its expected peripheral configuration. At this time, the generated Node_B and Edge_1 retain information indicating that they have a deployment dependency relationship with Node_A (the "depend_on" relationship represented by the dashed line in Figure 12(b)), as well as the value "n2" or "e1" which indicates the number of Node_B itself per Node_A, which is the source of the deployment, and the value "n1" which indicates the number of Node_As in the deployment (Figure 12(b)). At this point, the value of "quantity" for Node_B depends on "n2", which indicates the number of Node_B itself per Node_A, which is the source of the deployment, and "n1", which is the quantity value for Node_A. Therefore, Node_B retains "n2 on n1" as the value of "quantity". This means that there are n1 Node_As, and n2 Node_Bs per Node_A. Similarly, Edge_1 retains "e1 on n1" as the value of "quantity". If Node_B is subsequently deployed as multiple elements, Edge_2 and Node_C are generated to satisfy the expected peripheral configuration of Node_B.The generated Node_C and Edge_2 hold information indicating that they have a deployment dependency relationship with Node_B, "n3" or "e2" which is the number of Node_C per Node_B that is the deployment source, "n2" which is the number of Node_Bs that are the deployment source, and "n1" which is the number of Node_As that have an indirect deployment dependency relationship with Node_C and Edge_2. That is, Node_C holds "n3 on n2 on n1" as the quantity value, and Edge_2 holds "e2 on n2 on n1" as the quantity value (Fig. 12(c)).

[0046] An example of a text representation of the system configuration information in the state shown in Figure 12(c) is shown in Figure 13. The representation example in Figure 13 follows the system configuration information description method shown in Figure 3, but adds the number of components and information added when multiple elements are expanded. Specifically, identifiers node_a, node_b, and node_c are set for the Node_A, Node_B, and Node_C type components, respectively, and a quantity property indicating the number of each component and a depend_on property indicating the expansion dependency are set. Node_b has an expansion dependency relationship with node_a, and holds the identifier of node_a, its expansion dependency target, as the depend_on value, and holds the number of itself per expansion dependency target node_a (n2) and the number of node_as ($node_a.quantity) as the quantity value. Similarly, node_c holds the identifier of node_b, the deployment dependency, as the depend_on value, and holds the number of itself per node_b (n3) and a value containing the number of node_b and node_a per node_a ($node_b.quantity) as the quantity value. Similarly, for relationships between components, the quantity property and depend_on property are additionally defined, and the Edge_1 type relationship with the identifier edge_1 holds the identifier of node_a, the deployment dependency, as the depend_on value, and the number of itself per node_a (e1) and the number of node_a ($node_a.quantity) as the quantity value. Similarly, edge_2 holds the identifier of node_b, the deployment dependency, as the depend_on value, and holds the number of itself per node_b (e2) and a value containing the number of node_b and node_a per node_a ($node_b.quantity) as the quantity value.

[0047] When deploying multiple elements, you can choose to specify the number of components generated by the deployment using either an absolute value or a relative value. If no specification is made, both configuration plans will be designed based on the respective specification method. Furthermore, the same system configuration may contain both components specified using absolute values and components specified using relative values. For example, when deploying multiple elements, you can specify the number of generated components using a relative value, and when deploying the newly generated components, you can specify the number of generated components using an absolute value.

[0048] Also, depending on the type of component, it may be necessary to limit the instantiation method to one of the two. In that case, it is possible to define information about which method to use for instantiation within the definition of the component type. For example, you could define "dependency" as a property of the component type, and if its value is "True", specify a relative value, and if its value is "False", specify an absolute value.

[0049] [Multiple Element Explosion] Next, we will explain how to decompose multiple elements. Decomposition of multiple elements is performed according to [Step 1] to [Step 6] shown below.

[0050] [Step 1] Decide on multiple elements to decompose First, select multiple elements to be decomposed from the system configuration under design. Multiple element decomposition can be performed on any multiple elements within the system configuration. Hereafter, the multiple elements selected as decomposition targets will be referred to as "decomposition target elements."

[0051] [Step 2] Decomposition of the target element itself The selected element to be decomposed is itself decomposed. Specifically, components of the same type as the element to be decomposed are created in the same number as the quantity of the element to be decomposed, and the created components are connected to the element to be decomposed using a "One_Of" relationship. The quantity of each component generated from multiple elements is set to 1. This is the same as applying the concatenation pattern shown in Figure 8(a).

[0052] [Step 3] Copy the relationship between the decomposition target element and its expansion dependency If the element to be decomposed has other components as its deployment dependencies, the relationship between the deployment dependencies and the element to be decomposed is copied to the element that the element to be decomposed into is decomposed. At this time, the information on the deployment dependency is also copied. In other words, each component generated by decomposition holds the information on the relationship in which the element that is the deployment dependency of the element to be decomposed is its deployment dependency, and the value of the number of deployment dependencies (including indirect deployment dependencies).

[0053] [Step 4] Duplicate components that directly and indirectly depend on the decomposition target element If there are components in the system configuration that are directly and indirectly expansion-dependent on the element to be decomposed, the partial configurations made up of these components are duplicated so that they are connected to each component generated by decomposing the element to be decomposed. A component that is indirectly expansion-dependent on the element to be decomposed is a component that can be indirectly traced through a relationship called expansion dependency, such as a component that is expansion-dependent on a component that is directly expansion-dependent on the element to be decomposed. Partial configurations made up of components that are directly and indirectly expansion-dependent on the element to be decomposed are duplicated so that they are connected to each component generated by decomposing the element to be decomposed, while retaining the relationships between those components, the number held by each component, and information on expansion dependency relationships. However, the number of elements to be decomposed held by components that directly and indirectly depend on the element to be decomposed is updated to "1". This is because the element to be decomposed was decomposed into a component that is not a multiple element with quantity=1.

[0054] [Step 5] Duplicating other peripheral elements If there is a relationship between the component that was the source of decomposition in [Step 2] and the component that was the source of duplication in [Step 4], that is, if there is a relationship between the component that was the source of decomposition in [Step 2] or the component that was the source of duplication in [Step 4] and the component that was the source of connection, that relationship is also duplicated by connecting it to the component that was the destination of decomposition in [Step 2] or the component that was the destination of duplication in [Step 4].

[0055] [Step 6] Delete unnecessary elements Components that are directly and indirectly dependent on the decomposition target element, and relationships in which the components are the connection source or destination, are deleted from the system configuration being designed.

[0056] Specific examples of decomposition of multiple elements based on [Step 1] to [Step 6] above are shown in Figures 14 and 15. Figure 14 shows the decomposition process when multiple elements are expanded and the number of components to be expanded is specified as an absolute value, as shown in Figure 11, while Figure 15 shows the decomposition process when multiple elements are expanded and the number of components to be expanded is specified as a relative value, as shown in Figure 12. In Figures 14 and 15, the names of each component are listed as identifiers rather than type names. That is, node_a represents a Node_A type component, node_b, node_b1, node_b2, and node_b3 represent Node_B type components, node_c, node_c1, node_c2, and node_c3 represent Node_C type components, and node_d represents a Node_D type component, while edge_a, edge_a1, edge_a2, and edge_a3 represent Edge_A type relationships, edge_b, edge_b1, edge_b2, and edge_b3 represent Edge_B type relationships, edge_c, edge_c1, edge_c2, and edge_c3 represent Edge_C type relationships, and one_of1, one_of2, and one_of3 represent One_Of type relationships. In the figure, components that differ only in the last digit of their identifiers, such as node_b1, node_b2, and node_b3, are grouped together and represented as node_b1 to 3.

[0057] First, using FIG. 14, a specific example of decomposition processing when the number of components to be expanded is specified as an absolute value will be described. The configuration shown in FIG. 14(a) is based on the system configuration shown in FIG. 11(c) and is an example of a system configuration in which multiple elements are expanded without being decomposed and the number of components to be expanded is specified as an absolute value. However, for the configuration shown in FIG. 11(c), the numbers of each component are specifically set as n1=2, n2=3, n3=2, e1=1, and e2=1. The parentheses "()" following variables indicate the specific values of the variables in this example. Furthermore, node_d and edge_c are added. These node_d and edge_c do not have an expansion dependency relationship with the element to be decomposed, but represent an example of a component that has a relationship with the element to be decomposed. These components are added to explain a specific example of the processing shown in [Step 5] of the decomposition of multiple elements in this embodiment. First, multiple elements to be decomposed are selected. In Figure 14(a), decomposition processing can be performed on any of the components node_a, node_b, and node_c, but node_b is selected from among them. Then, according to [Step 2], the selected node_b itself is decomposed. Specifically, three components of the same Node_B type as the decomposition target and with quantity = 1 are generated (node_b1, node_b2, node_b3), and the decomposition target element node_b is connected to the generated nodes_b1 to 3 by one_of1 to 3 relationships, respectively (Figure 14(b)). In the configuration of Figure 14(b), the decomposition target element node_b does not have other components as its deployment dependencies, so the processing of [Step 3] is not performed. Furthermore, since there are no components that are directly or indirectly deployment-dependent on the decomposition target element node_b, the processing of [Step 4] is not performed, and the process proceeds to [Step 5]. According to [Step 5], edge_b, which is a relationship with node_b, which was the decomposition source in [Step 2], as the connection source, is duplicated by connecting it to node_b1-3 after decomposition (Figure 14(c)). Finally, since there are no components that have node_b as an expansion dependency, the deletion process in [Step 6] is not performed, and the decomposition process of multiple elements is completed.

[0058] Next, a specific example of decomposition processing in which the number of components to be expanded is specified as a relative value will be described using Figure 15. The configuration shown in Figure 15(a) is based on the system configuration in Figure 12(c), and is an example of a system configuration in which multiple elements are expanded without being decomposed, and the number of components to be expanded is specified as an absolute value. Similar to the configuration shown in Figure 12(c), specific values are set for the number of each component, and node_d and edge_c are added.

[0059] First, multiple elements to be decomposed are selected. In Figure 15(a), node_b is selected ([Step 1]), as in Figure 14(a). Then, following [Step 2], the selected node_b itself is decomposed. Specifically, three components of the same Node_B type as the decomposition target and with quantity = 1 are generated (node_b1, node_b2, node_b3), and the decomposition target element node_b is connected to node_b1 to node_b3 generated by the decomposition with a one_of1 to one_of3 relationship (Figure 15(b)). Because the decomposition target element node_b has node_a as its deployment dependency, according to [Step 3], edge_a, the relationship between node_b and node_a, is duplicated by connecting it to node_b1 to node_b3 (edge_a1 to edge_a3). At this time, the information that node_b1 to node_b3 and edge_a1 to node_a3 are also duplicated. Specifically, node_b1-3 hold "1 on n1(2)" as the number information they hold, which indicates the number of themselves per node_a and the number of node_a, and edge_a1-3 hold "e1(1) on n1(2)" (Fig. 15(c)). Next, according to [Step 4], the partial configurations that are directly and indirectly deployment-dependent on node_b, the element to be decomposed, are replicated by connecting them to node_b1-3. In Fig. 15, since node_c and edge_b are deployment-dependent on node_b, the partial configuration consisting of node_c and edge_b is replicated by connecting them to node_b1-3 while retaining the number and deployment-dependency information held by each component (Fig. 15(d)). However, among the number of components that node_c and edge_b hold as deployment-dependent targets, the value of "n2" which indicates the number of node_b is updated to "1" before replication. For example, the number information held by node_c1 is [n3(2) on n2(3) on n1(2)] to [n3(2) on 1on n1(2)]. After that, according to [Step 5], edge_c, which has node_b, the source of decomposition in [Step 2], as its destination, is duplicated by connecting it to the decomposed nodes_b1 to 3 (Fig. 15e)). Finally, according to [Step 6], node_c and edge_b, which are directly and indirectly dependent on node_b, the element to be decomposed, are deleted, and the decomposition process for the multiple element node_b is completed (Fig. 15(f)). By performing the above process on node_a and node_c as well, it is possible to design a configuration in which all multiple elements are finally decomposed.

[0060] [Designing a wide variety of system configurations by varying the timing of decomposition of multiple elements] In the technology according to this embodiment, when embodying multiple elements, it is not limited to either decomposing the elements and proceeding with the design, or developing the elements as they are without decomposing them and proceeding with the design, and either option is possible. Furthermore, when developing the elements as they are, the timing for decomposing the elements can also be selected arbitrarily. In this way, by being able to select the timing for decomposing the elements arbitrarily, various redundant configurations can be designed.

[0061] For example, if you want to design a redundant configuration consisting of multiple systems that operate with different configurations, it is effective to proceed with the design by prioritizing the decomposition of multiple elements. When prioritizing the decomposition of multiple elements, the components generated by the decomposition are subsequently realized independently. This makes it possible to design a system configuration in which each decomposed component operates with a different configuration.

[0062] On the other hand, if you want to design a redundant configuration consisting of multiple systems that operate with the same configuration, that is, if you want to design a redundant configuration consisting of multiple systems with the same software installed on the same type of machine, it is effective to proceed with deployment while keeping the multiple elements together.By prioritizing the deployment of the multiple elements and then decomposing them, the configuration that has been completed as multiple elements is replicated in each of the components after decomposition, making it possible to design a redundant configuration consisting of multiple redundant systems that have a common partial configuration.

[0063] Figure 16 shows examples of system configurations designed with different timings for decomposition of multiple elements. Given the abstract requirement of three applications (App_a) (T1), if decomposition of multiple elements is prioritized, App_a is first instantiated into a configuration that generates three App_a instances with a quantity of 1 (T2). Then, each of the three App_a instances is instantiated independently by generating the necessary components (T3). Specifically, when generating the OS to host App_a, the OS type is arbitrarily selected, such as Ubuntu (registered trademark), Windows (registered trademark), or RHEL (Red Hut Enterprise Linux) (registered trademark). Furthermore, while some of the OSes are instantiated as physical machines, others are instantiated as virtual machines (Virtual_Machines) on Elastic Compute Cloud (EC2) on Amazon Web Services (AWS). Thus, prioritizing decomposition of multiple elements makes it possible to design redundant configurations that include a wide variety of configurations.

[0064] On the other hand, if the deployment of multiple elements is prioritized, App_a is not decomposed, but is realized by generating Ubuntu (registered trademark) as the OS, which is the expected peripheral configuration of App_a, and is further realized by generating Physical_Server as the Machine, which is the expected peripheral configuration of the OS (T7). Finally, as a decomposition of App_a[3], the partial configuration consisting of Ubuntu (registered trademark) and Physical_Server is replicated by connecting it to the decomposed App_a (T8). By prioritizing the deployment of multiple elements in this way, the configuration that was realized before the decomposition is realized by replicating it to each component after the decomposition, making it possible to efficiently design redundant configurations with common partial configurations.

[0065] Furthermore, Figure 16 shows an example of the instantiation flow when deployment is performed at any timing, rather than prioritizing either decomposition or deployment of multiple elements. Instead of immediately decomposing App_a[3], it is instantiated as multiple elements, generating Ubuntu® (registered trademark) (T4). At this point, App_a[3] is decomposed, resulting in three redundant configurations that share a common partial configuration consisting of App_a and Ubuntu® (T5). Each Ubuntu® is then instantiated independently, resulting in different instantiation configurations, such as a configuration where the OS is installed on a physical server or on EC2 (T6).

[0066] The technology according to the present embodiment allows for the free selection of the timing for disassembling multiple elements, enabling the design of various types of redundant configurations. However, when designing a system configuration that includes common components, the technology can efficiently shorten the automated system design time by disassembling the components after deployment. However, it does not guarantee the design of a specific redundant configuration. Therefore, if you want to limit the design to a specific redundant configuration, it is effective to combine this technology with some mechanism for limiting the system configuration to be designed. For example, if you want to design a configuration using various types of software, taking security into consideration, you can incorporate a constraint in the system configuration realization process that rejects configurations in which the same software is selected and prioritizes the selection of a configuration that prioritizes the disassembly of multiple elements. Conversely, if you want to design a redundant configuration with common components for reasons of cost or management, you can incorporate a constraint that rejects configurations in which different software is selected. Furthermore, it is believed to be effective to combine this technology with AI technology to predict the configuration to be selected based on the designer's desired requirements, thereby prioritizing the design of the configuration desired by the designer.

[0067] Furthermore, depending on the intended use of the designed system configuration, it may be effective to complete the design as it is, without necessarily breaking down the multiple elements. This is because presenting the multiple elements in a consolidated state rather than breaking them down into individual elements makes it easier to grasp the overall system configuration. As the number of components in a system increases, the system configuration becomes more complex, making it difficult to grasp the overall system configuration, such as the types of components the system is made up of and the connections between the components. Therefore, displaying redundant components with the same configuration together makes it easier to grasp the overall system configuration. For example, in the case of a redundant configuration consisting of multiple systems with a common partial configuration, such as T8 in Figure 16, the design can be completed at the state of T7 in Figure 16 before the multiple components are broken down, and the design can be output as complete.

[0068] [Explanation of operation] Next, the flow of the automatic system design process of this embodiment will be described. FIG. 17 is a flowchart showing the overall operation of the automatic system design device 10 according to this embodiment. A user inputs system requirements (F1). The automatic system design device 10 concretizes the system requirements step by step (F2 to F9), outputs a completely concretized system configuration, or outputs a design failure notification (F10, F11), and then terminates the automatic system design process. As a flow of step by step concretization of the system configuration, the configuration concretization unit 200 first performs one concretization step (F2 to F7) and checks whether a concrete system configuration is included among the multiple system configurations obtained during design (F8). A concrete system configuration is a system configuration in which there are no abstract components in the system configuration and the expected peripheral configurations of all components are satisfied, and thus signifies a system configuration for which design has been completed. If a concrete system configuration is included (Yes in F8), the input / output unit 100 outputs the concrete system configuration (F10), and the process terminates. If no concrete system configuration is included (No in F8), the configuration instantiation unit 200 checks whether any other abstract system configurations remain (F9). An abstract system configuration is a system configuration in which there is one or more components that do not satisfy the abstract or expected peripheral configuration, and refers to a system configuration that is in the middle of design. If an abstract system configuration exists (Yes in F9), the process returns to the step of selecting the next system configuration in the middle of design to be instantiated (F2), and one step of instantiation is executed again. If no abstract system configurations remain (No in F9), further instantiation cannot be executed, and the input / output unit 100 outputs a message indicating that the design has failed (F11), and ends the process.

[0069] In the first stage of instantiation processing, the configuration instantiation unit 200 selects one of the system requirements acquired by the input / output unit 100 or one of the system configurations currently being designed (F2) and extracts all reifiable components contained in the selected system configuration (F3). Reifiable components are those that are abstract types or whose expected peripheral configurations are not satisfied. The design information application unit 210 of the configuration instantiation unit 200 then generates a system configuration by applying applicable instantiation patterns to each of the components extracted in F3. There are two types of instantiation patterns: a pattern that instantiates a configuration that instantiates the component's type, and a pattern that instantiates a configuration that satisfies the component's expected peripheral configuration. These patterns are collectively referred to as instantiation patterns. If there are multiple instantiation patterns applicable to a single component, a configuration is generated by applying each of the instantiation patterns (F4). The configuration instantiation unit 200 then checks whether one or more system configurations have been generated (F5). If one or more system configurations have not been generated (No in F5), the first stage of instantiation for the system configuration selected in F2 has failed, and the configuration instantiation unit 200 checks whether other abstract system configurations exist (F9). If one or more system configurations have been generated (Yes in F5), the configuration instantiation unit 200 uses the verification unit 400 to verify the constraints included in the system configurations and rejects system configurations that do not satisfy the constraints (F6). The configuration instantiation unit 200 then checks whether one or more system configurations that have not been rejected exist (F7). If one or more system configurations exist (Yes in F7), the first stage of instantiation is deemed successful, and the configuration instantiation unit 200 checks whether any concrete system configurations exist among them (F8). If no system configurations remain (No in F7), the first stage of instantiation has failed, and the configuration instantiation unit 200 proceeds to check whether other abstract system configurations exist (F9).

[0070] FIG. 18 is a detailed flowchart of the process executed in F4 of FIG. 17 to extract all system configurations that can be generated in one stage of instantiation processing for one abstract system configuration. The following processes G1 through G9 are executed by the design information application unit 210, and process G10 is executed by the deployment dependency instantiation unit 220. One component to be instantiated is selected from the components extracted in F3 of FIG. 17 (G2), and all instantiation patterns applicable to that component are extracted (G3). Then, one of all the extracted instantiation patterns is selected (G5). If the selected instantiation pattern instantiates the type of the component itself (Yes in G6), a configuration plan that instantiates the type of that component is generated (G7), and the process for generating one system configuration plan is terminated. If the selected instantiation pattern does not instantiate the type of the component itself, i.e., if the pattern instantiates a configuration that satisfies the expected peripheral configuration of the component (No in G6), it is checked whether the component to be instantiated has multiple elements (G8). If there are not multiple elements (No in G8), the system configuration is instantiated in a way that satisfies the expected peripheral configuration of the component to be instantiated (G9), and the process of generating one system configuration proposal is terminated.If there are multiple elements (Yes in G8), the expansion and decomposition process of the multiple elements is executed to instantiate the system configuration (G10), and the process of generating one system configuration proposal is terminated.The processes described in G5 to G10 are executed for all instantiation patterns extracted in G3 (G4), and the processes G2 to G10 are executed for all components extracted in F3 of Figure 17 (G1), thereby completing the process of extracting system configurations that can be generated by one-stage instantiation for one system configuration.

[0071] FIG. 19 is a flowchart showing the details of the expansion / decomposition process for multiple elements, which is executed in G10 of FIG. 18. The following process is executed by the expansion dependency instantiation unit 220. The expansion / decomposition process for multiple elements begins by checking whether the instantiation pattern selected in G5 of FIG. 18 is an instantiation pattern for decomposing multiple elements (H1). If it is not an instantiation pattern for decomposing multiple elements (No in H1), the multiple elements are expanded, that is, instantiated into a configuration that satisfies the expected peripheral configuration of the multiple elements in a form other than decomposition (H11). Then, it is checked whether the number of components generated by the expansion is specified as a relative value (H12). If it is not a relative value, that is, if it is specified as an absolute value (No in H12), the process ends. If it is a relative value (Yes in H12), the component generated by the expansion in H11 is assigned information on the expansion dependency relationship with the multiple elements to be instantiated and the number of components from the expansion source (H13), and the process ends. If the instantiation pattern is for decomposing multiple elements (Yes in H1), the multiple elements themselves are decomposed, that is, instantiated by generating the number of components to be instantiated equal to the quantity (H2). Then, it is checked whether the element to be instantiated has any deployment dependencies (H3). If it does (Yes in H3), the deployment dependencies are duplicated for the components created by the decomposition (H4). After the process shown in H4 is executed, or if it does not have any deployment dependencies (No in H3), it is checked whether any components that directly or indirectly have deployment dependencies on the element to be instantiated exist in the system configuration (H5). If they exist, the partial configuration consisting of the deployment-dependent components is duplicated by connecting them to the components into which the element to be instantiated is decomposed, and the information on the number of elements to be instantiated held by the deployment-dependent components is updated to "1" (H6). After the process shown in H6 is executed, or if there are no dependent components (No in H5), it is checked whether there is a relationship between the decomposition source component in process H2 or the duplication source component in process H6 and either the connection source or the connection destination (H7). If such a relationship exists, the relationship is duplicated by connecting it to each component in the decomposition destination or duplication destination (H8).After the process shown in H8 is executed, or if the above-mentioned relationship does not exist, finally, it is checked whether there are any components that directly or indirectly depend on the element to be decomposed (H9). If such components exist (Yes in H9), those components are deleted (H10) and the process ends. If such components do not exist (No in H9), the process ends.

[0072] (effect) As described above, when specifying multiple elements that represent the existence of multiple components, it is possible to proceed with specifying the system configuration while keeping the multiple elements, and it is possible to efficiently automatically design a redundant configuration that has a common partial configuration.

[0073] Second Embodiment 20 is a second diagram showing an example of an automatic system design apparatus according to an embodiment. The automatic system design apparatus 800 includes a receiving unit 801 that receives system requirements and a derivation unit 802 that derives a specific system configuration by applying predefined instantiation patterns for each component based on the system requirements. The derivation unit 802 has a function of designing a redundant configuration from multiple elements, the number of which is undetermined or including two or more components, when the multiple elements are a combination of multiple components of the same type expressed as a single component. When the multiple elements are instantiated, the multiple elements are instantiated as they are without being broken down into individual components, thereby designing a redundant system configuration.

[0074] 21 is a second flowchart showing an example of a configuration illustrating an example of the operation of the automatic system design apparatus. The receiving means 801 receives system requirements, and the derivation means 802 derives a specific system configuration by applying a predefined instantiation pattern for each component based on the system requirements. When a plurality of components of the same type are collectively expressed as a single component, the derivation means 802 designs a redundant system configuration by proceeding with the instantiation of the plurality of components as they are without breaking them down into individual components.

[0075] 22 is a diagram showing an example of the hardware configuration of an automatic system design apparatus according to an embodiment. A computer 900 includes a CPU 901, a main storage device 902, an auxiliary storage device 903, an input / output interface 904, and a communication interface 905. The above-described automatic system design apparatus 10 is implemented in the computer 900. The above-described functions are stored in the auxiliary storage device 903 in the form of a program. The CPU 901 reads the program from the auxiliary storage device 903, loads it into the main storage device 902, and executes the above-described processing in accordance with the program. The CPU 901 also allocates a storage area in the main storage device 902 in accordance with the program. The CPU 901 also allocates a storage area in the auxiliary storage device 903 for storing data being processed in accordance with the program.

[0076] A program for implementing all or part of the functions of the system automatic design device 10 may be recorded on a computer-readable recording medium, and the program may be loaded into a computer system and executed to perform processing by each functional unit. The term "computer system" herein includes hardware such as an OS and peripheral devices. If a WWW system is used, the term "computer system" also includes a homepage provision environment (or display environment). The term "computer-readable recording medium" refers to portable media such as CDs, DVDs, and USBs, as well as storage devices such as hard disks built into the computer system. If the program is distributed to the computer 900 via a communication line, the computer 900 may load the program into the main storage device 902 and execute the above-described processing. The program may be for implementing part of the above-described functions, or may be capable of implementing the above-described functions in combination with a program already stored in the computer system.

[0077] Although one embodiment of the present disclosure has been described in detail above with reference to the drawings, the specific configuration is not limited to the above, and various design modifications are possible within the scope of the gist of the present invention. Furthermore, one aspect of the present disclosure may be modified in various ways within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present disclosure. Furthermore, configurations in which elements described in the above embodiments and variations are substituted with elements that achieve the same effect are also included. Furthermore, each embodiment may be combined with other embodiments as appropriate.

[0078] Some or all of the above embodiments can be described as, but are not limited to, the following supplementary notes.

[0079] (Appendix 1) The automatic system design device includes means for accepting system requirements and means for deriving a specific system configuration by applying a predefined instantiation pattern for each component based on the system requirements, wherein the means for deriving the system configuration has a function for designing a redundant configuration from multiple elements including an undetermined number or two or more components when the multiple elements are a combination of multiple components of the same type expressed as a single component, and when instantiating the multiple elements, the device designs a redundant system configuration by proceeding with the instantiation of the multiple elements as they are without breaking them down into individual components.

[0080] (Appendix 2) the means for deriving the system configuration further has a function of decomposing the plurality of elements into the individual components and specifying them; When the multiple elements are instantiated, if the multiple elements are instantiated without being decomposed, the instantiation proceeds while retaining information that the multiple elements have been instantiated, and if the multiple elements are instantiated by being decomposed, the multiple elements are instantiated together with the peripheral components that are necessary for the existence of the multiple elements, based on the information that the multiple elements have been instantiated. This is the automatic system design device described in appendix (1).

[0081] (Appendix 3) When concretization proceeds without decomposing the multiple elements, the component generated by the concretization holds, as information indicating that the multiple elements have been concretized, relationship information indicating which of the multiple elements the component was developed from and a value of the number of the multiple elements to be concretized. This is the automatic system design apparatus according to appendix (1) or appendix (2).

[0082] (Appendix 4) The automatic system design device according to any one of appendices (1) to (3) includes, as processing for decomposing the plurality of elements and proceeding with concretization, a first processing for decomposing the plurality of elements themselves, a second processing for decomposing partial configurations related to the plurality of elements, and a processing for deleting the components that have become unnecessary as a result of the first processing and the second processing.

[0083] (Appendix 5) The system automatic design apparatus according to appendix (4) includes, as a process of decomposing the plurality of elements themselves, a decomposition process of generating a plurality of the components of the same type as the plurality of elements themselves, and further includes, when the plurality of elements to be decomposed hold information that they have been materialized from other plurality of elements, a process of assigning the information to the plurality of the components generated by the decomposition process.

[0084] (Appendix 6) The system automatic design device according to Supplementary Notes (4) to (5) extracts a configuration including components directly required by the plurality of elements themselves and components indirectly required by the plurality of elements as a partial configuration related to the plurality of elements.

[0085] (Appendix 7) The automatic system design device according to appendix (1) to appendix (6) is capable of designing a system configuration having different redundancy configurations depending on the point in time at which the multiple elements are decomposed, by allowing a choice to be made as to whether to proceed with the design by decomposing the multiple elements or to proceed with the design without decomposing the multiple elements when concretizing the multiple elements.

[0086] (Appendix 8) This is an automated system design method that accepts system requirements, and derives a specific system configuration by applying predefined instantiation patterns for each component based on the system requirements, and in the derivation, when multiple elements are formed by integrating multiple components of the same type and expressing them as a single component, the multiple elements are not broken down into individual components, but rather the instantiation of the multiple elements proceeds as is, thereby deriving a redundant system configuration from the multiple elements, the number of which is undetermined or which include two or more of the components.

[0087] (Appendix 9) This is a program that causes a computer to accept system requirements, derive a specific system configuration by applying predefined instantiation patterns for each component based on the system requirements, and in the derivation, when multiple elements are formed by combining multiple components of the same type and expressing them as a single component, the multiple elements are not broken down into individual components, but are instead instantiated as a single component, thereby deriving a redundant system configuration from multiple elements that include an undetermined number or two or more of the components. [Explanation of symbols]

[0088] 10. System automatic design equipment 100...Input / output section 200···Configuration Specifications Department 210...Design information application section 220... Deployment dependency instantiation unit 300...Design information 310...Disassembly design information 320...Deployment design information 400...Verification Department 800···System automatic design equipment 801... Reception method 802...Derivation means 900···Computer 901 CPU 902...Main memory 903...Auxiliary storage device 904 Input / Output Interface 905···Communication Interface

Claims

1. a means for accepting system requirements; A means for deriving a specific system configuration by applying a predefined instantiation pattern for each component based on the system requirements; Equipped with The means for deriving the system configuration has a function of designing a redundant configuration from a plurality of elements including an undetermined number of elements or two or more elements, when the plurality of elements are a group of elements of the same type expressed as a single element, and when the plurality of elements are realized, the means for deriving the system configuration designs a redundant system configuration by continuing to realize the plurality of elements as they are without breaking them down into the individual elements. Automatic system design equipment.

2. the means for deriving the system configuration further has a function of decomposing the plurality of elements into the individual components and specifying them; When the multiple elements are materialized, if the multiple elements are materialized without being decomposed, materialization is carried out while maintaining information that the multiple elements have been materialized; and if the multiple elements are materialized by being decomposed, the multiple elements are materialized by being decomposed, including the peripheral components that are necessary for the existence of the multiple elements, based on the information that the multiple elements have been materialized. The system automatic design device according to claim 1 .

3. When concretization is carried out without decomposing the plurality of elements, the component generated by the concretization holds, as information indicating that the component has been concretized from the plurality of elements, information on the relationship indicating from which of the plurality of elements the component has been developed and the value of the number of the plurality of elements to be concretized.

3. The system automatic design device according to claim 1.

4. The process for decomposing the plurality of elements to proceed with the materialization includes a first process for decomposing the plurality of elements themselves, a second process for decomposing partial configurations related to the plurality of elements, and a process for deleting the components that have become unnecessary as a result of the first process and the second process.

3. The system automatic design device according to claim 1.

5. The process of decomposing the plurality of elements themselves includes a decomposition process of generating a plurality of the components of the same type as the plurality of elements themselves, and further includes a process of, when the plurality of elements to be decomposed hold information that they have been materialized from other plurality of elements, assigning the information to the plurality of components generated by the decomposition process. The system automatic design device according to claim 4.

6. extracting a configuration including components directly required by the plurality of elements and components indirectly required by the plurality of elements as partial configurations related to the plurality of elements; The system automatic design device according to claim 4.

7. When embodying multiple elements, it is possible to select whether to proceed with the design by breaking down the multiple elements or to proceed with the design without breaking down the multiple elements, thereby enabling the design of a system configuration having different redundancy configurations depending on the point in time at which the multiple elements are broken down.

3. The system automatic design device according to claim 1.

8. A specific system configuration is derived by accepting system requirements and applying a predefined instantiation pattern for each component based on the system requirements, and in the derivation, when a plurality of components of the same type are expressed as a single component, the multiple elements are instantiated as they are without being broken down into individual components, thereby deriving a redundant system configuration from the multiple elements including an undetermined number or two or more of the components. Automated system design methods.

9. On the computer, A process of receiving system requirements, applying a predefined instantiation pattern for each component based on the system requirements, and deriving a specific system configuration, in which, in the derivation, when a plurality of components of the same type are collectively expressed as a single component, the plurality of elements are instantiated as they are without being broken down into individual components, thereby deriving a redundant system configuration from the plurality of elements including an undetermined number or two or more of the components; A program that executes the following.

Images