System configuration derivation device, system configuration derivation method, and program

Abstract

A system configuration derivation device (300) according to this disclosure comprises: an embodiment policy specification unit (302) that specifies, from among embodiment actions which are concrete conversions of an abstract configuration according to embodiment rules, an essential embodiment action that must be applied to the input abstract configuration; a comprehensiveness verification unit (303) that verifies whether the essential embodiment action capable of removing abstract elements included in the input abstract configuration can be applied comprehensively to the input abstract configuration; and a configuration information embodiment unit (301) that converts the input abstract configuration to a much less abstract configuration, until unit abstract elements are no longer included, by applying the essential embodiment action specified by the embodiment policy specification unit (302), on the basis of the verification result by the comprehensiveness verification unit (303).

Description

[Technical field]

[0001] The present disclosure relates to a system configuration deriving device, a system configuration deriving method, and a computer-readable medium. [Background technology]

[0002] The tasks required to build an ICT (Information and Communication Technology) system for the purpose of operating a service or the like include designing the system configuration and the deployment procedure.

[0003] Of these, the system configuration design work in particular requires the construction of all the system components and their connections (collectively referred to as the "system configuration") necessary to satisfy the requirements for the desired system (hereinafter referred to as the "system requirements"), and the correct setting of all the settings required for the entire system to operate normally. This work can be very labor-intensive in some cases.

[0004] Automatic design technology is a technology that automates the design process mentioned above, that is, the process of concretizing system requirements into a system configuration. Many existing automatic design technologies limit the problem to a specific domain of ICT systems, such as network routes or the placement of computing resources, and then perform automatic design by solving certain optimization problems. However, research has recently been progressing on technology that can handle general-purpose requirements descriptions.

[0005] For example, Non-Patent Document 1 describes a technology for automatically deriving a system configuration based on requirements described using a general-purpose system configuration information model in a graph-like format. According to the automatic design method described in Non-Patent Document 1, by preparing the necessary model, automatic design is possible by inputting general-purpose and multifaceted requirements.

[0006] The requirements that can be described by the general-purpose model described in Non-Patent Document 1 are configurations (hereinafter referred to as "abstract configurations") that are specified by a graph representation in which functions, devices, and other components are represented as nodes, and the relationships between the nodes are represented by edges (directed edges). For example, the requirement that "two servers are capable of communication via TCP (Transmission Control Protocol)" is represented as an abstract configuration in which nodes corresponding to the two servers are connected by edges that represent "TCP communication possible." The method described in Non-Patent Document 1 is a mechanism that automatically derives a method for concretizing the abstract "TCP communication possible" edge included in the above-mentioned abstract configuration.

[0007] It should be noted that the automated design method described in Non-Patent Document 1 does not concretize given requirements all at once. In the automated design method described in Non-Patent Document 1, rules for rewriting an abstract configuration into another abstract configuration that is one step more concrete (hereinafter, these will be called "concretization rules") are stored as data, and the abstract configuration that represents the requirements is converted into a concrete abstract configuration in stages by sequentially applying the concretization rules. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] Japanese Patent Application Publication No. 6-090235 [Patent Document 2] International Publication No. 2013 / 072978 [Non-patent literature]

[0009] [Non-Patent Document 1] Takayuki Kuroda, Takuya Kuwahara, Takashi Maruyama, Kozo Satoda, Hideyuki Shimonishi, Takao Osaki and Katsushi Matsuda, “Weaver: A Novel Configuration Designer for IT / NW Services in Heterogeneous Environments”, 2019 IEEE Global Communications Conference(GLOBECOM), 2019, pp. 1-6. [Non-Patent Document 2] Doron Peled, “All from One, One for All: on Model Checking Using Representatives”, 5th International Conference on Computer Aided Verification(CAV), 1993, pp. 409-423. [Non-Patent Document 3] Harmen Kastenberg, Arend Rensink, “Dynamic Partial Order Reduction Using Probe Sets”, 19th International Conference on Concurrency Theory(CONCUR), 2008, pp. 233247. Summary of the Invention [Problem to be solved by the invention]

[0010] However, the automatic design method described in Non-Patent Document 1 has a problem in that it is not possible to efficiently find a specific configuration that embodies the system requirements.

[0011] Therefore, an object of the present disclosure is to provide a system configuration derivation device, a system configuration derivation method, and a computer-readable medium that can solve the above-mentioned problems and efficiently derive a specific configuration that embodies system requirements. [Means for solving the problem]

[0012] A system configuration derivation device according to one aspect includes: A system configuration derivation device receives as input an abstract configuration that expresses a configuration of a system including undetermined abstract elements by a graph-like data structure composed of nodes corresponding to parts and edges indicating relationships between the parts, generates a search tree rooted at the input abstract configuration, converts the input abstract configuration into a more concrete abstract configuration by applying concretization rules that describe a method for removing abstract elements included in the abstract configuration, and adds the abstract configuration obtained by the conversion to the search tree, thereby repeatedly deriving a concretized system, a concatenation policy specification unit that specifies a concatenation action that must be applied to the input abstract configuration among concatenation actions that are concrete transformations of the abstract configuration according to the concatenation rules; a comprehensiveness verification unit that verifies whether the required instantiation action capable of removing the abstract element included in the input abstract configuration is applicable to the input abstract configuration comprehensively; a configuration information instantiation unit that converts the input abstract configuration into a more specific abstract configuration until the abstract configuration does not include the abstract element by applying the required instantiation action identified by the instantiation policy identification unit based on a verification result by the coverage verification unit; Equipped with.

[0013] A system configuration derivation method according to one aspect includes: A system configuration derivation method by a system configuration derivation device, which receives as input an abstract configuration expressing a configuration of a system including undetermined abstract elements by a graph-like data structure composed of nodes corresponding to parts and edges indicating relationships between the parts, generates a search tree rooted at the input abstract configuration, converts the input abstract configuration into a more concrete abstract configuration by applying concretization rules describing a method for removing abstract elements included in the abstract configuration, and adds the abstract configuration obtained by the conversion to the search tree, repeatedly deriving a concretized system, comprising: A first step of identifying a concretization action that must be applied to the input abstract configuration among concretization actions that are concrete transformations of the abstract configuration according to the concretization rules; a second step of verifying whether the required instantiation actions capable of removing the abstract elements included in the input abstract configuration are applicable to cover the input abstract configuration; a third step of converting the input abstract configuration into a more concrete abstract configuration by applying the required concretization actions identified in the first step based on the verification result of the second step, until the input abstract configuration does not contain the abstract element; Includes.

[0014] According to one aspect, a computer readable medium includes: A non-transitory computer-readable medium storing a program for causing a computer to execute the program to derive a concretized system by repeatedly receiving, as an input, an abstract configuration that represents a configuration of a system including undetermined abstract elements using a graph-like data structure composed of nodes corresponding to parts and edges that indicate relationships between the parts, generating a search tree rooted at the input abstract configuration, converting the input abstract configuration into a more specific abstract configuration by applying concretization rules that describe a method for removing abstract elements included in the abstract configuration, and adding the abstract configuration obtained by the conversion to the search tree, The program is A first step of identifying a concretization action that must be applied to the input abstract configuration among concretization actions that are concrete transformations of the abstract configuration according to the concretization rules; a second step of verifying whether the required instantiation actions capable of removing the abstract elements included in the input abstract configuration are applicable to cover the input abstract configuration; a third step of converting the input abstract configuration into a more concrete abstract configuration by applying the required concretization actions identified in the first step based on the verification result of the second step, until the input abstract configuration does not contain the abstract element; Includes. Effect of the Invention

[0015] According to the above-described aspects, it is possible to provide a system configuration deriving device, a system configuration deriving method, and a computer-readable medium that are capable of efficiently deriving a specific configuration that embodies system requirements. [Brief description of the drawings]

[0016] [Figure 1] FIG. 11 is an explanatory diagram showing an example of a concrete path. [Diagram 2] FIG. 11 is an explanatory diagram showing an example of a concretization rule. [Diagram 3] FIG. 1 is an explanatory diagram showing an example of a search tree including redundant paths, which is a problem in the related automatic design technology; [Figure 4] FIG. 4 is an explanatory diagram showing an example of redundant paths that reach the same specific configuration included in FIG. 3. [Diagram 5] 1 is a block diagram showing an example of the configuration of a system configuration derivation device according to a first embodiment. [Figure 6] FIG. 2 is an explanatory diagram showing an example of an abstract configuration given as one of the inputs of the system configuration deriving device according to the first embodiment. [Figure 7] FIG. 11 is an explanatory diagram showing an example of application of a concretization rule (=execution of a concretization action). [Figure 8]FIG. 13 is an explanatory diagram showing an example of resolving an “abstract edge” abstract element by a concretization action. [Figure 9] 5 is a flowchart illustrating an example of the operation of a solution target detection unit according to the first embodiment. [Figure 10] 5 is a flowchart illustrating an example of the operation of a concretization rule recording unit according to the first embodiment. [Figure 11] 5 is a flowchart for explaining an operation example of a concretization policy determination unit according to the first embodiment. [Figure 12] 6 is a flowchart illustrating an example of the operation of a coverage verification unit according to the first embodiment. [Figure 13] FIG. 10 is an explanatory diagram showing an example of a specific situation in which a reification rule is judged to be "essentially inapplicable." [Figure 14] 11 is a flowchart for explaining an example of the operation of a configuration information instantiation unit according to the first embodiment. [Figure 15] FIG. 2 is an explanatory diagram showing a specific example of a search performed by the system configuration derivation device according to the first embodiment. [Figure 16] FIG. 11 is a block diagram showing an example of the configuration of a system configuration derivation device according to a second embodiment. [Figure 17] 13 is a flowchart illustrating an example of the operation of a solution target combination unit according to the second embodiment. [Figure 18] FIG. 11 is a block diagram showing an example of the configuration of a system configuration derivation device according to a third embodiment. [Figure 19] FIG. 11 is a block diagram showing an example of a hardware configuration of a system configuration derivation device according to a fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Hereinafter, the related art and the embodiments of the present disclosure will be described with reference to the drawings. Note that the following description and drawings are omitted and simplified as appropriate for clarity of explanation. In addition, in each of the following drawings, the same elements are given the same reference numerals, and duplicate explanations are omitted as necessary.

[0018] <Related Technology> Before describing the embodiments of the present disclosure, a related art related to the present disclosure will be described first. An abstract construction contains abstract elements (hereafter, these will be referred to as "abstract elements"). A reification rule is data detailing how to transform an abstract element contained in an abstract construction into another more concrete component (hereafter, this will be referred to as "resolving an abstract element"). Formally speaking, a reification rule is data defining how to resolve an abstract element by transforming an abstract construction, and is composed of two pieces of data (hereafter, these two pieces of data will be referred to as the "left side" and the "right side") that are graphs of the same format as the abstract construction.

[0019] Applying a concretization rule to an abstract configuration is called executing a "concretization action" on the abstract configuration. Formally, a "concretization action" is data consisting of two pieces of information: a "concretization rule" and an "application point." When a structure corresponding to the left-hand side of a concretization rule R exists as a substructure of an abstract configuration T, the concretization rule R is "applicable" to the abstract configuration T. In this case, the correspondence between the "left-hand side or right-hand side of a concretization rule" and the "substructure of an abstract configuration" is called the "application point" in this application.

[0020] When a reification action consisting of a reification rule R and an application point M is executed on an abstract structure T, the substructure of T corresponding to M is replaced with the structure corresponding to the right-hand side of R. In this case, the structure that is not included on the left-hand side but is included only on the right-hand side can be newly created, but if a corresponding structure is already included in the abstract structure to which it is applied, it can also be used as part of the structure on the right-hand side when replacing the structure.

[0021] If an abstract configuration in which all abstract elements included in requirements are resolved can be obtained by applying the concretization rules, this abstract configuration can be considered to be a completely concretized system configuration (hereinafter simply referred to as a "concrete configuration") that does not contain any abstract elements.

[0022] Therefore, for an abstract construction given as a requirement, a concrete construction can be arrived at by sequentially applying the concretization rules for concretizing the abstract elements contained in this abstract construction. However, since there are generally multiple concretization rules for resolving a given abstract element, a choice appears as to which concretization rule to use to resolve each abstract element. Furthermore, since each concretization rule has conditions for being applicable to the abstract construction, there may be cases where there is no way to resolve an abstract element even if it remains in the abstract construction.

[0023] Therefore, in the automated design process, it is necessary to "search" and discover concrete configurations while generating a tree structure (hereafter simply called a "search tree") with abstract configurations as nodes and concrete rule applications as branches. In general, the larger, more complex, and more difficult a requirement is to satisfy, the more difficult it is to arrive at a concrete configuration and the longer the search takes.

[0024] Problems with the related art will be described below. The present disclosure relates to a technique for performing general-purpose automatic system design, similar to Non-Patent Document 1, which is a general-purpose automatic system design technique. According to the automated design method described in Patent Document 1, models of necessary components are prepared, and these models are combined to specify system requirements as abstract configurations. Then, automated design can be performed by applying predefined instantiation rules.

[0025] As already explained, the abstract elements included in the abstract construction can be resolved by the "application" of the above-mentioned concretization rules. Therefore, by repeatedly applying the "application" of the concretization rules, a search can be performed with the abstract construction as a state space, and a concrete construction can be obtained in which all of the abstract elements included in the abstract construction have been resolved.

[0026] However, according to Non-Patent Document 1, an experimental evaluation of the calculation time required to complete an automatic design revealed that when the size of the graph specified as a requirement is large, the calculation time increases rapidly in proportion to the size of the graph.

[0027] One of the main causes of this sudden increase in calculation time is the overlapping searches of multiple paths consisting of the exact same combination of instantiation rules. Below, we will explain this issue using a specific example.

[0028] FIG. 1 is an explanatory diagram showing the application of a series of reification rules that determine the server product for each machine when two similar applications, App1 and App2, are hosted on each machine. The dotted rounded rectangle (and the graph enclosed within it) indicates an abstract configuration, and the arrows (and the labels attached thereto) indicate the application of the reification rules. FIG. 1 includes five abstract configurations, including requirement T0 and concrete configuration T4. As a premise, it is assumed here that the three reification rules APP-HOST, USE-SERVER-A, and USE-SERVER-B shown in FIG. 2 are registered as available reification rules. It is also assumed that applications App1 and App2 can be hosted on either server A or B, but that two or more applications cannot be hosted at the same time.

[0029] Under the above assumptions, the configurations that can be reached from requirement T0 by executing a concretization action are only the configurations shown in concrete configuration T4 and the configurations shown in concrete configuration T4 with the server type changed. In other words, the only variation in configurations that can be reached from requirement T0 is whether the host server for applications App1 and App2 is A or B. Therefore, there are 2 x 2 = 4 concrete configurations that can be reached from requirement T0.

[0030] As mentioned above, the number of concrete configurations that can be reached from requirement T0 is relatively small, but the size of the search tree starting from requirement T0 can be large. Figure 3 is an explanatory diagram showing a part of the search tree that can be created by applying the automated design process described in Non-Patent Document 1 starting from requirement T0. The black arrow indicates the instantiation action by APP-HOST, the white arrow with the label "A" indicates the instantiation action by USE-SERVER-A, and the white arrow with the label "B" indicates the instantiation action by USE-SERVER-B, and information on the application location is omitted.

[0031] Two concretization actions can be applied to requirement T0, a ,T b In Figure 3, T a All abstract constructs reachable from T are illustrated. b is T a It has a symmetric structure with T a In other words, if a search is performed starting from T0, it is possible to reach as many abstract configurations as 44 abstract configurations through concretization. In an actual automated design process, these 44 abstract configurations are not all explored. However, for example, if a general breadth-first search is adopted as the search strategy for tree search, in the case of Figure 3, the 21st abstract configuration (for example, T goal etc.), the concrete configuration is finally discovered.

[0032] The search tree shown in Figure 3 contains many "redundant" search paths in the following sense. Figure 4 shows the six "concretization paths (= a sequence of execution of a series of concretization actions that start from requirement T0 and reach a concrete configuration)" contained in the entire search tree of Figure 3.

[0033] The six concretization paths shown in Figure 4 all execute the same concretization actions, and only the order in which they are executed differs. Therefore, these six concretization paths ultimately reach the same concretization configuration. Since the purpose of automated design is to discover a concretization configuration that can be reached from requirements, it is redundant and meaningless to search the six concretization paths mentioned above individually. In other words, ideally, one of these six concretization paths should be searched as a representative path, and the other five should be omitted as redundant paths.

[0034] Figure 3 contains many other redundant paths like the one mentioned above. Specifically, for one reachable instantiation, there are six instantiation paths as well, and these six instantiation paths are redundant instantiation paths that can be considered equivalent if their order is changed.

[0035] The above is an explanation of the overlapping search of redundant instantiation paths, which is one of the major causes of the rapid increase in calculation time in existing automatic system design.

[0036] Partial-Order Reduction (POR, see Non-Patent Document 2) is a well-known method for dealing with such redundant route searches. POR is a method that determines one representative route for the redundant routes described above, and omits searches for other redundant routes by searching only this representative route.

[0037] Furthermore, Non-Patent Document 3 proposes “Probe Set POR,” a POR method specialized for a mechanism for rewriting graph-like structures (Graph Rewriting System) such as those used in automated system design.

[0038] However, it is considered that Probe Set POR needs to be improved from two viewpoints when applied to an automatic design process. The first viewpoint is that the process of calculating a representative path is heavy, resulting in a large overhead in calculation time. The second viewpoint is that Probe Set POR includes a process of complementing a concrete path to a state already searched during the search (i.e., adding a branch that was not originally present), which complicates the entire process. This second viewpoint itself does not directly affect the calculation speed. However, there is a concern that this second viewpoint, including exceptional behavior as a tree search, may be incompatible with other general tree search speed-up methods (such as a method of optimizing the progress direction of tree search by reinforcement learning, as mentioned in Non-Patent Document 1). The embodiments described below contribute to solving the above-mentioned problems.

[0039] <Embodiment 1> <Configuration of First Embodiment> First, the configuration of the first embodiment of the present disclosure will be described with reference to the drawings. Fig. 5 is a block diagram showing an example of the configuration of a system configuration derivation device 100 according to the first embodiment.

[0040] 5, the system configuration deriving device 100 according to the first embodiment includes a configuration information concretization unit 101, a concretization policy determination unit 102, a coverage verification unit 103, a concretization rule recording unit 104, and a solution target detection unit 105.

[0041] The configuration information concretization unit 101 inputs system requirements as abstract configurations from an external input / output device (not shown), derives concrete configurations by sequentially applying applicable concretization rules to the input abstract configurations, and outputs the derived concrete configurations to the external input / output device.

[0042] The instantiation policy decision unit 102 inputs an abstract configuration from the configuration information instantiation unit 101, and outputs to the configuration information instantiation unit 101 a list of instantiation actions to be applied to the input abstract configuration.

[0043] The comprehensiveness verification unit 103 inputs an abstract configuration, abstract elements included in this abstract configuration, and a list of concatenation actions capable of resolving these abstract elements from the concatenation policy determination unit 102. Then, the comprehensiveness verification unit 103 verifies whether concatenation actions capable of resolving the input abstract elements in the future are included in the input list of concatenation actions, and outputs the verification result to the concatenation policy determination unit 102.

[0044] The solution target detection unit 105 inputs a list of concatenation rules from an external input / output device, detects all abstract elements that can be resolved by applying the input concatenation rules, creates a database that returns a list of concatenation rules appropriate for the type of abstract element, and outputs the created database to the concatenation rule recording unit 104.

[0045] The concretization rule recording unit 104 receives the above-mentioned database from the solution target detection unit 105 and holds the received database. The concretization rule recording unit 104 also receives abstract elements from the concretization policy determination unit 102 and responds to the concretization policy determination unit 102 with a list of concretization rules that can resolve the received abstract elements based on the above-mentioned database.

[0046] The abstraction configuration and the data structure of the abstraction configuration in the first embodiment will be described below. As already explained, an abstract configuration refers to an abstract system configuration that includes undetermined aspects regarding configuration and settings. An abstract configuration is a configuration written down by an entity that desires an ICT system. An abstract configuration is a configuration that plays the role of defining a desired system without specifically mentioning the details of the system by writing down only definite information, i.e., information that indicates "what requirements the system should satisfy and what functions it should have."

[0047] The basic structure of an abstract configuration is a graph made up of "nodes" that correspond to the functions and logical and physical components of a system, and "edges" that are stretched between two nodes to express the relationship between those two nodes. The above-mentioned edges have a direction. For an edge going from node A to node B, node A is called the "source" and node B is called the "destination". In the following, when referring to nodes and edges interchangeably, they are collectively called "entities."

[0048] The above-mentioned entities have an "identifier" that uniquely identifies the entity throughout the entire system, and "type information" that describes what concept the entity corresponds to. The identity of entities in two different abstract configurations, such as "abstract configurations before and after reification" or "left and right sides of a reification rule", is determined by the identifier. In other words, even if the type information is different, if the identifier is the same, they will be treated as "the same entity".

[0049] The "type information" associated with an entity is explained in more detail below. The type information mentioned above has the role of indicating what kind of entity the entity to which the type is attached is. There are two kinds of types: "abstract type" and "concrete type." Abstract types indicate types of entities that do not intuitively correspond to concrete parts or connection relationships that exist in the real world, such as "Machine" or "HTTP (Hypertext Transfer Protocol) connectable," and that require further concretization. On the other hand, concrete types indicate entities that correspond to concrete parts or connection relationships that exist in the real world, such as "(concrete machine model number)" or "wired LAN connection."

[0050] As mentioned above, there is a concept of abstraction for types. According to this concept of abstraction, the concept of parent-child relationship is defined between the above type information based on the relationship that "type t2 is more specific than type t1." When type t2 is more specific than type t1, type t1 is said to be the parent type of type t2, and conversely, type t2 is said to be the child type of type t1.

[0051] As will be explained in detail later in the explanation of the reification rules, the type of a node can be converted to its child type by applying the reification rules. This operation is equivalent to narrowing down the candidates for the node type to a more specific type according to the reification rules.

[0052] In addition to the above-mentioned "identifier" and "type information," the information associated with a node also includes a "required component (of the node type)." A node may have multiple "required components," or none at all.

[0053] The above is an explanation of the "type information" associated with an entity.

[0054] The "requested part" associated with a node will be described in more detail below. A node associated with a "requested part" is simply expressed as having the requested part itself. Intuitively, the required parts associated with a node indicate the dependent parts that are necessary for the correct operation of the part corresponding to that node. For example, a node of the node type "App" that represents an application has "Machine" as a required part. This means that a machine that hosts the application is required for the application to operate.

[0055] When node N1 has a requested part req, the requested part can be connected to node N1 by extending a special edge type "WIRE:req" (the "req" part changes depending on the requested part) from node N1 to another node N2. This is equivalent to selecting N2 as the requested part req requested by N1. When a node has a requested part, the request can be fulfilled by connecting the appropriate part to that node.

[0056] For example, taking the example of the App type node mentioned above, by connecting an edge of type "WIRE:Machine" from the App type node MyApp to the Machine type node Machine1, the host destination of the node MyApp can be specified as node Machine1.

[0057] A node can only connect to one other node at a time. For example, in the previous example, after connecting to node Machine1, node MyApp cannot be connected to another Machine type node Machine2 by a "WIRE:Machine" edge.

[0058] This concludes the explanation of the "requested parts" associated with the nodes.

[0059] 6 is an example of an abstract configuration. Labeled icons, such as nodes 600, 601, and 602, indicate nodes, and labeled arrows, such as edges 603 and 604, indicate edges. Node labels are in the format of "(identifier):(type name)". Edge labels, on the other hand, are only the type name. Also, nodes 600 and 601 are provided with speech bubbles indicating requested parts. Note that, to simplify the drawing, information on requests and labels is omitted as appropriate.

[0060] Both the node 600 and the node 601 represent an application. Here, both the node 600 and the node 601 correspond to concrete components that do not include undetermined parts. Both the node 600 and the node 601 have a request component "Machine", and the request of the node 600 is satisfied by connecting Machine1, while the request of the node 601 is not satisfied.

[0061] Node 602 is a node indicating "some kind of machine." In other words, it is determined that node 602 is a machine capable of running an application, but it is not determined what specific product is used.

[0062] Edge 603 is an edge indicating a specific relationship, indicating that source node 600 is hosted on destination node 602. Node 602 is connected to node 600 by edge 603, thereby satisfying the "Machine" requirement of node 600.

[0063] Edge 604 is an edge indicating an abstract relationship (in the sense that a specific communication path is undefined), indicating that it is guaranteed that source node 600 can send an HTTP request to destination node 601 in some way.

[0064] The above is a description of a specific example of an abstract configuration.

[0065] The concretization rules in the present embodiment 1 will be described below. As already described, the concretization rules are composed of information representing the subject of concretization (hereinafter, referred to as the "left side (of the concretization rule)") and information representing the configuration after concretization (hereinafter, referred to as the "right side (of the concretization rule)").

[0066] The left and right sides of a reification rule are attributed graphs, similar to the basic structures of abstract constructs. The entities on the left and right sides of a reification rule must satisfy the following three conditions (1), (2), and (3).

[0067] (1) A node on the left side must also exist on the right side. This is a constraint to ensure that the existence of a component that has already been added to the abstract configuration by concreteness does not disappear.

[0068] (2) There is no concrete entity on the left side. This is a constraint to ensure that no concreteness is performed that would retract and rewrite a part that has already been determined.

[0069] (3) For a node v that exists in both the left and right sides, the "type of v on the left side" must be the same as or a parent type of the "type of v on the right side." This is a constraint to ensure that the rewriting of the type of a component caused by reification is only a "narrowing of the type to a more specific one," and that it is not rewritten into a completely different type of component.

[0070] We now provide details on how abstract constructs are made concrete by the concrete rules.

[0071] When an abstract configuration d contains a structure corresponding to the left-hand side of reification rule r, the reification rule r is said to be applicable to the abstract configuration d. Here, "abstract configuration d has a structure corresponding to the left-hand side of reification rule r" means that (1) a subgraph of d contains one with exactly the same shape as the left-hand side of r, and (2) in the one-to-one relationship between entities based on (1) above, "the type of the entity on the left-hand side of r" is the parent type of "the type of the entity on d".

[0072] The above-mentioned "subgraph of abstract configuration d corresponding to the left-hand side of concatenation rule r" is called the concatenation target of abstract configuration d by concatenation rule r.

[0073] In other words, when a concatenation rule r is applicable to an abstract structure d, d has a substructure, i.e., a concatenation target, that has a one-to-one correspondence with the left-hand side of r. Rewriting an abstract structure d using a concatenation rule r means replacing the above-mentioned concatenation target with the structure expressed on the right-hand side of the concatenation rule r.

[0074] Entity e that is not on the left side of the reification rule but is on the right side new If there is a corresponding entity, then the entity is basically created and given a new identifier that is not included in the abstract configuration. new An entity e that has the same type as, or a subtype of, reused If already exists (in a different part from the object to be instantiated), instead of creating a new entity, we use the existing e reused This can be used to define the entity e in the application of the reification rule. reused This is called "recycling."

[0075] When applying a reification rule to an abstract configuration, we can consider the correspondence between entities that represent the targets of reification and reuse. This correspondence is called the "application point" in the application of the reification rule, and the combination of the reification rule and the information on the application point is called the "reification action."

[0076] The concretization rules and their application will be illustrated below using concrete examples. As already explained, Fig. 2 is an explanatory diagram showing three concrete examples of the concretization rules in the first embodiment. Rule 200R is a diagram showing the concatenation rule "APP-HOST" that shows, on the left and right sides, a method of transforming a graph so that the "Machine" requirement is satisfied by connecting a "Machine" type node to an "App" type node where the "Machine" requirement is not satisfied. Rule 200R represents an operation of connecting a "Machine" type node {2} to an "App" type node {1} that is already included in the abstract configuration with a "WIRE:Machine" type edge. This operation satisfies the "Machine" requirement of node {1}.

[0077] FIG. 7 illustrates an example of applying rule 200R in two different ways as described in FIG.

[0078] 7, application example 700 is a case where rule 200R is applied to application point "{1}:App2, {2}:Machine2". In other words, rule 200R is applied by associating node {1} in the reification rule with node App2 in Fig. 3. A new Machine type node corresponding to {2} is created and given the identifier "Machine2".

[0079] On the other hand, application example 701 is a case where rule 200R is applied to application point "{1}:App2,{2}:Machine1". In this case, node Machine1 is reused. That is, the already existing node Machine1 is used as a Machine type node corresponding to node {2} that exists only on the right side of rule 200R.

[0080] Thus, for the same reification rule and the same abstract construct, multiple reification actions may be possible.

[0081] This concludes the description of the rewriting of abstract constructs by application of reification rules.

[0082] Next, the abstract elements included in the abstract configuration of the present embodiment 1 will be described. There are three types of abstract elements: "abstract node", "abstract edge", and "unreached request". In addition, the exact definition of each abstract element being resolved by a concretization action will also be described.

[0083] "Abstract Node" Abstract element refers to a node with an abstract type included in the abstract requirement. In the following, an abstract element corresponding to node v with abstract type t will be represented as v:t. "Resolving" abstract element v:t by concretization action a is defined as "the type of node v changes from t after application of concretization action a."

[0084] Below is a concrete example of the "Abstract Node" abstract element and its resolution. Machine1 of T2 in Figure 1 is a "Machine" type node. This indicates that Machine1 is a part that is determined to be a computer on which applications can run, but it is not yet determined what specific product will be used. In other words, T2 has an "abstract node" abstract element Machine1:Machine.

[0085] The concretization action applied to T2 (here, "a3") changes the type of Machine1 to "Server-A" which corresponds to a concrete server product. Thus, by applying the concretization action a3, the abstract element Machine1:Machine of T2 is resolved.

[0086] The above is a description of an example of the "abstract node" abstract element and its resolution.

[0087] "Abstract edge" refers to an edge with an abstract type included in the abstract requirement. Hereinafter, an edge v with abstract type t s →v d The abstract element corresponding to v s →v dLet us express it as :t. Abstract element v s →v d :t is "resolved" by concretization action b if, after application of concretization action b, edge v s →v d The definition of "deletion" is "the deletion of

[0088] Below is a concrete example of the "abstract edge" abstract element and its resolution. Edge 802 extending from node App1 to node App2 included in abstract configuration 800 shown in Fig. 8 is an "HTTP" type edge. This indicates that edge 802 is an edge in which it is determined that HTTP communication is possible from App1 to App2, but it is not determined specifically how the communication will be performed. In other words, abstract configuration 800 has an "abstract edge" abstract element App1→App2:HTTP.

[0089] Concrete action 801 applied to abstract configuration 800 deletes edge 802. Therefore, with the application of concrete action 801, abstract element App1→App2:HTTP of abstract configuration 800 is resolved.

[0090] The above is a description of an example of the "abstract edge" abstract element and its resolution.

[0091] An "unmet request" abstract element is a request held by a node included in an abstract requirement, and refers to an element in which the requested part is not connected by an appropriate edge. Hereinafter, the abstract element corresponding to request p held by node v will be represented as vp. "Resolving" abstract element vp by concretization action c is defined as "after application of concretization action c, an appropriate part is properly connected to request p of node v."

[0092] Below, we will give a concrete example of the "unfulfilled request" abstract element and its resolution. App1 in T0 in Figure 1 has "Machine" as a required part. This indicates that App1 requires a machine for its operation. In addition, there is no part connected to the required part "Machine" of App1. In other words, T0 has an "unfulfilled request" abstract element App1.Machine.

[0093] The concretization action (here, "a0") applied to T0 connects Machine1 to App1 via an edge of type "WIRE:Machine". Therefore, the abstract element App1.Machine of T0 is resolved by applying the concretization action a0.

[0094] The above is an explanation of the "unfulfilled request" abstract element and a specific example of its solution.

[0095] Finally, a specific configuration derived from the first embodiment will be described. In the first embodiment, a concrete configuration refers to a completely concretized abstract configuration. Here, an abstract configuration being "completely concretized" refers to an abstract requirement that does not include any abstract elements. An abstract configuration that does not include any abstract elements is a state in which there are no ambiguous parts in the system and all the parts necessary for operation are present. Therefore, a concrete configuration corresponds to a system that operates completely functionally.

[0096] <Operation of the First Embodiment> The system configuration deriving device 100 according to the first embodiment receives system requirements (abstract configuration) as input, and outputs a concrete configuration that satisfies the system requirements. This series of processing is called an automatic design process. The automatic design process is processed by a configuration information instantiation unit 101, an instantiation policy judgment unit 102, a coverage verification unit 103, and an instantiation rule recording unit 104.

[0097] Furthermore, the system configuration deriving device 100 according to the first embodiment reads in advance a list of instantiation rules to be used in the automatic design process as preprocessing before the automatic design process is executed. This preprocessing is executed by the solution target detection unit 105.

[0098] The processing of each unit of the system configuration deriving device 100 will be described in detail below.

[0099] First, the operation of the solution object detection unit 105 according to the present embodiment 1 will be described with reference to the drawings. Fig. 9 is a flowchart showing the process in which the solution object detection unit 105 according to the present embodiment 1 reads a concretization rule.

[0100] Referring to FIG. 9, first, the solution object detection unit 105 receives a list of instantiation rules R=r1,...,r from an external input / output device. n is received as an input (step S900).

[0101] Next, the solution target detection unit 105 checks the three databases DB node ,DB edge ,DB req (Step S901). Here, the database DB node ,DB edge ,DB req is a database that returns a "list of reification rules" for a key value, and the above-mentioned "initialization" refers to a state in which an empty list is returned for any key.

[0102] The solution target detection unit 105 detects each instantiation rule r included in the list R of instantiation rules received as an input. i Steps S903 to S905 are executed for (i=1,...,n) (step S902).

[0103] The solution target detection unit 105 detects the concretization rule r i If such a node exists, a reification rule r iSince the abstract node can be resolved, the resolution target detection unit 105 uses the type t on the left side of each node as a key to obtain a list DB node [t] instantiates rule r i Add the database DB node is updated (step S903).

[0104] The solution target detection unit 105 detects the concretization rule r i Check all edges that exist on the left side of but not on the right side of . If such an edge exists, then the reification rule r i Since the abstract edge can be resolved, the resolution target detection unit 105 uses the type t of each edge as a key to obtain a list DB edge [t] instantiates rule r i Add the database DB edge is updated (step S904).

[0105] The solution target detection unit 105 detects the concretization rule r i If there are such required parts, the reification rule r i Since the uncompleted request can be resolved, the resolution target detection unit 105 uses a list DB obtained by using each requested part p as a key. req [p] is instantiation rule r i Add the database DB req is updated (step S905).

[0106] When the solution object detection unit 105 has completed the process for all the instantiation rules included in R (YES in step S902), the solution object detection unit 105 checks the three databases DB node ,DB edge ,DB req is output to the instantiation rule recording unit 104 as inquiry response data (step S906), and the process ends.

[0107] The above is a description of the operation when the solution object detection unit 105 according to the first embodiment reads the concatenation rule.

[0108] Next, the operation of the concatenation rule recording unit 104 according to the first embodiment will be described with reference to the drawings. Fig. 10 is a flowchart showing the process when the concatenation rule recording unit 104 according to the first embodiment responds to an input abstract element with a list of concatenation rules capable of resolving that abstract element. Note that the preprocessing in Fig. 9 has already been performed before the operation in Fig. 10, and the concatenation rule recording unit 104 receives the three databases DB node ,DB edge ,DB req is assumed to already be held.

[0109] Referring to FIG. 10, first, the concatenation rule recording unit 104 receives the abstract element u as an input from the concatenation policy decision unit 102 (step S1000).

[0110] The instantiation rule recording unit 104 records whether an abstract element is “abstract node v:t” or “abstract edge v s →v d The process branches depending on whether the request is "request part vp" or "request part vp" (step S1001).

[0111] If the abstract element is "abstract node v:t", the instantiation rule recording unit 104 vinegar DB node A list of reification rules included in node [t] is output to the instantiation policy decision unit 102, and the process ends (step S1002).

[0112] The abstract element is "abstract edge v s →v d :t", the instantiation rule recording unit 104 stores the database DB edge A list of reification rules included in edge [t] is output to the instantiation policy decision unit 102, and the process ends (step S1003).

[0113] When the abstract element is a "request part vp", the instantiation rule recording unit 104 stores the database DB req A list of reification rules included inreq [p] is output to the instantiation policy decision unit 102, and the process ends (step S1004).

[0114] The above is an explanation of the process performed by the instantiation rule recording unit 104 according to the first embodiment when responding to an input abstract element with a list of instantiation rules capable of resolving that abstract element.

[0115] Next, the operation of the embodiment 1 of the concrete policy determination unit 102 will be described with reference to the drawings. Fig. 11 is a flowchart showing the overall operation of the embodiment 1 of the concrete policy determination unit 102.

[0116] Referring to FIG. 11, first, the instantiation policy decision unit 102 receives the abstract configuration D as an input from the configuration information instantiation unit 101 (step S1100).

[0117] The concretization policy decision unit 102 sequentially executes the processes from step S1102 onward for each abstract element u included in the abstraction construction D (step S1101).

[0118] The concatenation policy decision unit 102 inquires of the concatenation rule recording unit 104 about concatenation rules that can resolve the abstract element u of the abstract construction D, and obtains a list R of such concatenation rules (step S1102).

[0119] The concatenation policy decision unit 102 inputs the abstract configuration D, the abstract element u, and the list R of concatenation rules acquired in step S1102 to the exhaustiveness verification unit 103, and obtains an output from the exhaustiveness verification unit 103 (step S1103). As will be described later, the output from the exhaustiveness verification unit 103 is a list S of concatenation actions obtained as a result of checking the application of the concatenation rules included in R to the abstract requirement D. u The pair is a combination of "Yes (certainly exhaustive)" or "No (may not be exhaustive)" and the above. The subsequent process branches into two depending on the output result of the exhaustiveness verification unit 103 obtained in step S1103.

[0120] If the output result of the coverage verification unit 103 in step S1103 is "Yes", the instantiation policy decision unit 102 creates a list S of instantiation actions. u As an output, the instantiation policy decision unit 102 returns the above to the configuration information instantiation unit 101 (step S1105). Then, even if there are still abstract elements remaining that have not been selected in step S1101, the instantiation policy decision unit 102 ends the process.

[0121] If the output result of the coverage verification unit 103 in step S1103 is "No", the instantiation policy decision unit 102 creates a list S of instantiation actions. u Let us define all instantiation actions in all Then, the process returns to step S1101 (step S1104).

[0122] (supplement) In addition, the above-mentioned S all Note that is a set of reification actions, and the same reification action cannot be added more than once. Here, two reification actions are "same" if they apply the same reification rule to the same application point.

[0123] When the process from step S1102 onwards is completed for all abstract elements included in the abstract construction D (YES in step S1101), the instantiation policy decision unit 102 calculates a set S all is returned as an output to configuration information instantiation unit 101 (step S1106), and the process ends.

[0124] The above is a description of the operation of the embodiment policy determination unit 102.

[0125] Next, before a specific description of the operation of the coverage verification unit 103 according to the first embodiment, an overview of the output of the coverage verification unit 103 will be given.

[0126] The coverage verification unit 103 first receives an abstract configuration D, an abstract element u, and instantiation rules r1, r2, ..., r mTakes as input.

[0127] The comprehensiveness verification unit 103 generates a set of instantiation rules r1, r2, ..., r m List of concrete actions by S u is returned as output to the instantiation policy decision unit 102.

[0128] In addition, the comprehensiveness verification unit 103 compiles a list of instantiation actions S u covers all of the concatenation actions that resolve the abstract element u of the abstract configuration D. As a result, the coverage verification unit 103 returns "Yes" to the concatenation policy decision unit 102 if it can be determined that all have been covered, or "No" if not.

[0129] The definition of the situation where "all instantiation actions that resolve abstract element u of abstract configuration D are exhausted" will be explained below.

[0130] If an abstract configuration D containing an abstract element u can reach a concrete configuration as a result of applying a concretization rule, then since the concrete configuration does not contain any abstract elements, the abstract element u is resolved by some concretization action included in the concretization path from D to C.

[0131] That is, all concretization paths from an abstract configuration D to any concrete configuration must include some concretization action a(D,u) that resolves an abstract element u. We call such a concretization action a(D,u) a "mandatory concretization action (for abstract element u included in abstract configuration D)." Note that once an abstract configuration and an abstract element (and a list of concretization rules) are determined, what concretization actions are possible as such mandatory concretization actions are uniquely determined.

[0132] Then, we can say that for all the required instantiation actions a(D,u)1, a(D,u)2, ..., a(D,u) for an abstract element u in an abstract configuration D. nis applicable to abstract configuration D, then a(D,u)1, a(D,u)2, ..., a(D,u) are the branches of the search tree (= applicable concretization actions) when expanding abstract configuration D in the automated design process. n Even if the above method is used, the variation of concrete configurations that can be reached by the search is not lost.

[0133] Because the set of required instantiation actions a(D,u)1, a(D,u)2, ..., a(D,u) n is a set of all possible mandatory concretization actions for an abstract element u included in an abstract configuration D. Therefore, in order to reach a concrete configuration by following a concretization path from an abstract configuration D, one of the set of mandatory concretization actions must be applied, but conversely, it does not matter when such mandatory concretization actions are applied to an abstract configuration.

[0134] "All concretization actions that resolve abstract element u of abstract configuration D are covered" refers to the above-mentioned situation where "all required concretization actions for abstract element u of abstract configuration D are covered in the list of concretization actions applicable to abstract configuration D." In such a case, the branching of abstract configuration D in the search tree can be limited to only "all covered required concretization actions," which is generally a smaller number than "all applicable concretization actions," and therefore the number of branches in the search tree can be reduced.

[0135] This concludes the description of the strict definition of the situation verified by the coverage verification unit 103 according to the first embodiment, namely, "whether all of the instantiation actions that resolve the abstract element u of the abstract configuration D have been covered."

[0136] The operation of the coverage verification unit 103 according to the first embodiment will be described below with reference to the drawings. Fig. 12 is a flowchart showing the overall operation of the coverage verification unit 103 according to the first embodiment.

[0137] 12, first, the coverage verification unit 103 receives an abstract configuration D, an abstract element u, and a list of instantiation rules R=r1, r2,...,r m is received as an input (step S1200).

[0138] Next, the coverage verification unit 103 generates a list of instantiation rules R=r1, r2,...,r m First, remove the reification rules that are essentially unusable for resolving the abstract element u of the abstract configuration D (step S1201).

[0139] Here, the meaning of a concatenation rule being "essentially unusable for resolving abstract element u of abstract configuration D" is as follows. As described in the explanation of the operation of concatenation policy decision unit 102, list R of concatenation rules is a list of concatenation rules that can resolve abstract element u, obtained from concatenation rule recording unit 104, and includes a concatenation rule in which the abstract configuration D (and the abstract element u contained therein) never matches the structure of the left hand side. Such a concatenation rule is referred to as "essentially unusable for resolving abstract element u of abstract configuration D."

[0140] 13 is a diagram illustrating a specific situation in which a reification rule becomes essentially unusable, taking the same reification as used in FIG.

[0141] 13, the reification rule 1300 is a reification rule that resolves an http-type edge indicating communication between two applications {1} and {2} hosted on machines {3} and {4}, respectively, and creates a new ip-type edge indicating IP (Internet Protocol) communication between the two machines. This clearly makes it possible to resolve abstract edge-type abstract elements using http-type edges.

[0142] Abstract configuration 1301, abstract configuration 1302, and abstract configuration 1304 are three abstract configurations having an abstract element App1→App2:http. Abstract configuration 1301 shows a situation where App1 and App2 are hosted on machines Machine1 and Machine2, respectively. Abstract configuration 1302 shows a situation where App1 is hosted on machine Machine1, while the host machine for App2 has not yet been determined. Abstract configuration 1304 shows a situation where both App1 and App2 are hosted on machine Machine1.

[0143] The abstract element App1→App2:http included in the abstract configuration 1301 can be resolved by the instantiation rules 1300.

[0144] The abstract element App1→App2:http included in the abstract configuration 1302 cannot be immediately resolved by the concatenation rule 1300. However, if the abstract configuration 1302 is further concatenated to such a extent that a Machine type node other than Machine1 is connected to App2 (abstract configuration 1303), it can be resolved by the concatenation rule 1300. In such a case, the concatenation rule 1300 is not "essentially unusable."

[0145] On the other hand, the abstract element App1→App2:http included in the abstract configuration 1304 cannot be immediately resolved by the reification rule 1300, and even if the abstract configuration 1304 is reified by applying another reification rule, it will not be in a situation where it can be resolved by the reification rule 1300. This is because the abstract configuration "App1 and App2 are hosted on different machines," which is necessary to apply the reification rule 1300, cannot be reached by reifying the abstract configuration 1304. This case is an example of a situation where the reification rule 1300 is said to be "essentially unusable."

[0146] The above is a concrete illustration of a situation in which reification rules are essentially disabled.

[0147] Referring again to FIG. 12, the coverage verification unit 103 then checks each instantiation rule r i Let us enumerate all the instantiation actions that resolve the abstract element u of the abstract configuration D, and create a list S u In addition, in this process, the coverage verification unit 103 calculates the information of the application part, and therefore, the entity e corresponding to the abstract element u is constructed from the information of the application part. i is calculated and recorded (step S1202).

[0148] (supplement) However, here, "entity e corresponding to abstract element u" i " means that if abstract element u is "abstract node n:t" or "unfulfilled request np", then r corresponding to node n i The abstract element u is an abstract edge n s →n d :t" for edge n s →n d r corresponding to i refers to the edge of

[0149] In step S1202, the next process branches depending on whether there is even one concatenation rule that does not match abstract configuration D (step S1203). Here, "abstract configuration D does not match concatenation rule R" means that "abstract configuration D does not have a structure corresponding to the left side of concatenation rule R."

[0150] In step S1202, if there is even one concatenation rule that does not match the abstract configuration D (YES in step S1203), the coverage verification unit 103 u ) is returned as an output to the instantiation policy decision unit 102 (step S1207), and the process ends.

[0151] In step S1202, if there is no concretization rule that does not match the abstract configuration D (NO in step S1203), the process of the coverage verification unit 103 proceeds to step S1204.

[0152] Next, the coverage verification unit 103 sequentially executes steps S1205 to S1206 for each instantiation rule included in R (step S1204).

[0153] The comprehensiveness verification unit 103 checks the instantiation rule r i (1) Entity e i is the instantiation rule r i and (2) the reification rule r i The left side of is the entity e i It is checked whether the object is composed only of entities subordinate to e (step S1205). i is the "entity corresponding to abstract element u" obtained in step S1202.

[0154] Here, the relationship "entity e1 is subordinate to entity e2" is defined as a case where any of the following three conditions is met: (1) e1 is a node, has a part p as a requirement, and e2 is an edge of type “WIRE:p” extending from e1. (2) e1 is an edge and e2 is its end point (start point or end point). (3) e1 is an entity e m is subordinate to and e m is dependent on e2

[0155] (supplement) reification rule r i The left side of the equation is the entity e that corresponds to the abstract element u. i The fact that it is composed only of entities subordinate to the reification rule r i (e i This means that a concretization action such as "resolves abstract element u (corresponding to the above)" has exactly the same application pattern on the left side. In other words, it is guaranteed that at least the application pattern on the left side has been covered as soon as the check in step S1205 is passed.

[0156] In step S1205, if it is found that either of the conditions (1) and (2) is not satisfied (NO in step S1205), the coverage verification unit 103 u ) is returned as an output to the instantiation policy decision unit 102 (step S1207), and the process ends.

[0157] In step S1205, if it is found that both conditions (1) and (2) are satisfied (YES in step S1205), the processing of the coverage verification unit 103 proceeds to step S1206.

[0158] The comprehensiveness verification unit 103 checks the instantiation rule r i A list of all parent types of the node types that are on the right side of TYPE and not on the left side of TYPE i Refer to the TYPE in the abstract construct D. i It is verified that there is no node having a type included in (step S1206).

[0159] In addition, TYPE i is the reification rule r i Since it is uniquely determined for each, it may be calculated and stored in advance when the instantiation rules are read, or it may be calculated each time step S1206 is executed.

[0160] (supplement) TYPE i A child type tc of a node type t that is an element of i In other words, if an abstract configuration D contains a node with type t, then it may be reused in the application of reification rule r. iThis means that there is a node npos that may be reused in a concretization action by , but at least not now. Therefore, if the abstract configuration D contains a node with type t, it means that a concretization action that includes node npos as its application point may appear as a branch of the search in the future. Conversely, if such a node is not contained, this possibility can be eliminated, so the check in step S1206 makes it clear whether all concretization actions, including the reuse of the nodes on the right side, have been covered.

[0161] In step S1206, "TYPE i The next step depends on whether there is no node of a type contained in ".

[0162] In step S1206, TYPE i If it is found that there is a node having a type included in (YES in step S1206), the coverage verification unit 103 u ) is returned as an output to the instantiation policy decision unit 102 (step S1207), and the process ends.

[0163] In step S1206, TYPE i If it is found that there is no node having a type included in (NO in step S1206), the process of the coverage verification unit 103 returns to step S1204.

[0164] When the processes from step S1205 to step S1206 have been completed for all the instantiation rules included in R (YES in step S1204), the coverage verification unit 103 returns (Yes, S u ) is returned as output to the instantiation policy decision unit 102, and the process ends.

[0165] The above is an explanation of the operation of the coverage verification unit 103.

[0166] Next, the operation of the configuration information instantiation unit 101 according to the present embodiment 1 to design an ICT system will be described with reference to the drawings. Fig. 14 is a flowchart showing the process of the configuration information instantiation unit 101 according to the present embodiment 1 to derive a specific configuration of the system.

[0167] First, configuration information instantiation unit 101 receives abstract configuration D as an input from an external input / output device (Step S1400).

[0168] Next, configuration information instantiation unit 101 generates a search tree with abstract configuration D received in step S1400 as its root (step S1401).

[0169] The configuration information instantiation unit 101 repeats the process described below to update the search tree, thereby deriving a concrete configuration (step S1402).

[0170] First, the configuration information instantiation unit 101 selects one abstract configuration D that (1) has not been completely instantiated and (2) has not been previously selected in this step from among the abstract configurations D included in the search tree (step S1403). Note that the specific method of this "selection" is not limited to a specific means as long as it is selected from candidates that satisfy (1) and (2). For example, a list of candidates that satisfy (1) and (2) may be presented to the user, and the user may be able to select from the list, or a mechanical selection may be made based on a specific criterion (including completely random selection).

[0171] (Supplementary Note 1) To efficiently execute the above-mentioned step S1403, the system configuration deriving device 100 according to the first embodiment can also hold a data structure cand for managing a list of "abstract configurations included in the search tree that have not been completely instantiated and have not been previously selected in this step." This data structure cand behaves as follows: (1) When adding an abstract configuration to the search tree, if the abstract configuration is not a completely instantiated configuration, the abstract configuration is also added to cand. (2) In step S1403, one abstract configuration is selected from cand, and the selected abstract configuration is deleted.

[0172] (Supplementary Note 2) The method of using the data structure cand described above is one implementation method of the configuration information concretization unit 101 according to this embodiment 1, and the method of realizing the configuration information concretization unit 101 according to this embodiment 1 is not limited to this.

[0173] Next, the configuration information instantiation unit 101 inputs the abstract configuration D selected in step S1403 to the instantiation policy decision unit 102, and acquires a list of instantiation actions actions=a1, a2,...,ak which is the output of the instantiation policy decision unit 102 (step S1404). As will be described later, all the instantiation actions acquired in step S1404 are instantiation actions applicable to the abstract configuration D selected in step S1403.

[0174] Next, the configuration information instantiation unit 101 applies the instantiation actions actions=a1, a2, ..., ak acquired in step S1404 to the abstract configuration D selected in step S1403, and adds all the resulting abstract configurations to the search tree (step S1405). After that, the processing of the configuration information instantiation unit 101 returns to step S1402 where the iterative processing started.

[0175] The configuration information instantiation unit 101 repeats the process until a sufficient number of concrete configurations are added to the search tree or until there are no more abstract configurations to be searched for in the search tree. Here, the above-mentioned "sufficient number" is specified, for example, through an input / output device or as a value built into the system configuration deriving device 100 from the beginning.

[0176] Thereafter, the configuration information instantiating unit 101 outputs the finally obtained concrete configuration as a processing result of the system configuration deriving device 100 to an external input / output device.

[0177] The above is a description of the operation of configuration information instantiation section 101.

[0178] Fig. 15 is an explanatory diagram showing a search tree generated as a result of executing the configuration information instantiation unit 101 on the same set of abstract configuration / concretization rules as the case exemplified in Fig. 3. Here, the result of continuing the search until four concrete configurations are found is shown.

[0179] 3, there are two variations of concretization actions that can be executed for abstract configuration 1500, each of which applies "APP-HOST" to a different application point. One of them is concretization action 1501 that resolves abstract element App1.Machine, and since this is comprehensive, the only concretization action to be executed for abstract configuration 1500 is concretization action 1501.

[0180] (supplement) In addition, since the other concretization action is also a comprehensive concretization action that resolves the abstract element App2.Machine, it may be the only concretization action executed for the abstract configuration 1500. In such a case, which one the concretization policy determination unit 102 should return depends on the order in which the abstract elements were checked in the internal procedure of the concretization policy determination unit 102 in the first embodiment.

[0181] 3, there are three concretization actions that can be executed for the abstract configuration 1502. One of them is a concretization action 1503 that resolves the abstract element App2.Machine, and since this is exhaustive, the concretization action to be executed for the abstract configuration 1502 is only the concretization action 1503.

[0182] Similarly, in the case shown in Fig. 15, the configuration information instantiation unit 101 develops only the minimum necessary branches at each branch. Therefore, in the case shown in Fig. 15, it is possible to output all the concrete configurations that can be generated as the instantiation result of the abstract configuration 1500 without generating any redundant paths such as those included in Fig. 3.

[0183] <Effects of the First Embodiment> In the system configuration derivation device 100 according to this embodiment 1, the configuration information concretization unit 101 receives the input configuration requirements in the form of an abstract configuration, and repeatedly concretizes the abstract configuration by applying concretization rules, thereby performing a tree search in a search tree with the configuration requirements as the root and the abstract configurations as the nodes, and finally outputs configuration information of a completely concretized ICT system.

[0184] Furthermore, the configuration information instantiation unit 101 queries the instantiation policy decision unit 102 at the branch of the tree search, and if the instantiation actions that can resolve the abstract elements contained in the abstract configuration are covered at that point, the instantiation policy decision unit 102 returns only those instantiation actions. This number is generally smaller than all the instantiation actions that can be applied to the abstract configuration, but the variation of reachable concrete configurations does not change due to this branch restriction.

[0185] Therefore, the system configuration derivation device 100 according to this embodiment 1 can quickly find a concrete configuration that satisfies an abstract configuration including undetermined abstract elements by searching a small search tree, and can therefore efficiently find and output information on ICT systems that satisfy requirements.

[0186] <Embodiment 2> <Configuration of the Second Embodiment> Next, a configuration of a second embodiment of the present disclosure will be described with reference to the drawings. Fig. 16 is a block diagram showing an example of the configuration of a system configuration derivation device 200 according to the second embodiment.

[0187] With reference to FIG. 16, a system configuration deriving device 200 according to the second embodiment includes a solution target combining unit 201 instead of the solution target detecting unit 105 of the system configuration deriving device 100 according to the first embodiment described above.

[0188] The solution target combining unit 201 differs from the solution target detecting unit 105 in that it receives an input of "(a list of) abstract elements to be resolved" from an external input / output device in a form linked to a concatenation rule.

[0189] Except for the above points, there is no difference in configuration between the system configuration deriving device 200 and the system configuration deriving device 100 .

[0190] <Operation of the second embodiment> As described above, the system configuration deriving device 200 according to the second embodiment has no difference in configuration from the system configuration deriving device 100 other than the solution target combining unit 201, and therefore the operation is also the same except for the solution target combining unit 201.

[0191] Therefore, hereinafter, only the operation of the solution target combining unit 201 according to the present embodiment 2 will be described with reference to the drawings. Fig. 17 is a flowchart showing the process in which the solution target combining unit 201 according to the present embodiment 2 reads the concatenation rules.

[0192] Referring to FIG. 17, first, the solution target combination unit 201 receives a list of instantiation rules R=r1,...,r from an external input / output device. n , and a list of data U1,...,U indicating the abstract elements that each of these reification rules resolves. n As an input (step S1700), i (i=1,...,n) is a list of abstract elements.

[0193] (supplement) In addition, when receiving an input, the solution target combination unit 201 i U i may check whether each abstract element contained in actually resolves, and if not, issue an error and fail the loading procedure.

[0194] Next, the solution target merging unit 201 merges the three databases DB node ,DB edge ,DB req (Step S1701). Here, the database DB node ,DB edge ,DB req is a database that returns a "list of reification rules" for a key value, and the above-mentioned "initialization" refers to a state in which an empty list is returned for any key.

[0195] The solution target combination unit 201 receives as input a list R of instantiation rules, and i Steps S1703 to S1705 are executed for (step S1702).

[0196] The solution target joint 201 is U i If v:t contains an abstract element v:t, then U i For each "abstract node" abstract element v:t contained in node [t] instantiates rule r i Add the database DB node is updated (step S1703).

[0197] The solution target joint 201 is U i "Abstract Edge" Abstract element v s →v d If it contains :t, U i Each "abstract edge" abstract element v contained in s →v d A list DB that can be obtained for t by using the type t of each edge as a key. edge [t] instantiates rule r iAdd the database DB edge is updated (step S1704).

[0198] The solution target joint 201 is U i If U contains the "undelivered request" abstract element vp, i For each "unfulfilled request" abstract element vp contained in req [p] is instantiation rule r i Add the database DB req is updated (step S1705).

[0199] When the solution target combining unit 201 completes the process for all the instantiation rules included in R (YES in step S1702), node ,DB edge ,DB req is output as inquiry response data to the instantiation rule recording unit 104 (step S1706), and the process ends.

[0200] The above is an explanation of the operation when the solution target combination unit 201 according to the second embodiment reads the concatenation rule.

[0201] <Effects of the second embodiment> In the system configuration derivation device 200 according to the second embodiment, the solution target combination unit 201 adopts abstract elements directly specified by a user via an external input / output device, unlike the solution target detection unit 105 which mechanically determines, from a concretization rule, an abstract element to be resolved by that concretization rule.

[0202] Although the concatenation rules are basically written as data for resolving abstract elements, there are cases where the concatenation rules do not end up resolving only the abstract elements that are the goal of the solution. The solution target detection unit 105 also registers such concatenation rules in the database.

[0203] Basically, it is considered that each abstract element included in a requirement can be resolved to a concrete configuration by a concatenation rule that is created for the purpose of resolving that abstract element. Therefore, if a concatenation rule r ends up resolving an abstract element u that it did not intend to resolve, considering r as one of the concatenation rules that can resolve u will lead to a decrease in the efficiency of pruning in the concatenation policy decision unit 102.

[0204] Therefore, in the second embodiment, the solution target combination unit 201 limits "abstract elements that can be resolved by each concatenation rule" to abstract elements specified by the user, thereby improving the pruning efficiency in the concatenation policy decision unit 102, and as a result, the automatic design process by the system configuration deriving device 200 can be completed more efficiently.

[0205] <Embodiment 3> Next, a configuration of a third embodiment of the present disclosure will be described with reference to the drawings. Fig. 18 is a block diagram showing a configuration example of a system configuration derivation device 300 according to the third embodiment. The third embodiment corresponds to an embodiment that conceptualizes the first and second embodiments described above.

[0206] The system configuration derivation device 300 according to the third embodiment is a device that receives as input an abstract configuration that represents the configuration of a system including undetermined abstract elements using a graph-like data structure composed of nodes corresponding to components and edges indicating relationships between the components, generates a search tree rooted at the input abstract configuration, converts the input abstract configuration into a more concrete abstract configuration by applying concretization rules that describe a method for removing abstract elements included in the abstract configuration, and repeatedly adds the abstract configuration obtained by the conversion to the search tree, thereby deriving a concrete system.

[0207] 18, a system configuration deriving device 300 according to the third embodiment includes a configuration information concretization unit 301, a concretization policy specifying unit 302, and a coverage verification unit 303. The configuration information concretization unit 301, the concretization policy specifying unit 302, and the coverage verification unit 303 correspond to the configuration information concretization unit 101, the concretization policy determination unit 102, and the coverage verification unit 103, respectively.

[0208] The concatenation policy specifying unit 302 specifies a concatenation action that must be applied to the input abstract configuration among concatenation actions that are concrete transformations of the abstract configuration according to the concatenation rules.

[0209] The comprehensiveness verification unit 303 verifies whether or not the essential instantiation actions capable of removing abstract elements included in the input abstract configuration are applicable to cover the input abstract configuration.

[0210] The configuration information concatenation unit 301 converts the input abstract configuration into a more specific abstract configuration by applying the required concatenation actions identified by the concatenation policy identification unit 302 based on the verification results by the comprehensiveness verification unit 303, until the input abstract configuration does not contain any abstract elements. Among concatenation actions, which are concrete transformations of abstract configurations according to concatenation rules, a concatenation action that must be applied to the input abstract configuration is identified.

[0211] In the system configuration deriving device 300 according to the third embodiment, the configuration information concretization unit 301 converts the input abstract configuration into a more concrete abstract configuration by applying the required concretization actions identified by the concretization policy identification unit 302 based on the verification result by the coverage verification unit 303. This makes it possible to reduce the number of branches in the tree search of the search tree, and to find a concrete configuration by searching a small search tree. As a result, it becomes possible to efficiently derive a concrete configuration.

[0212] In addition, when branching in the tree search of the search tree, the configuration information concretization unit 301 may input the abstract configuration from which the branch originates to the concretization policy determination unit 302, and receive a presentation of required concretization actions to be applied to the abstract configuration from which the branch originates from the concretization policy determination unit 302.

[0213] In addition, the comprehensiveness verification unit 303 may verify whether or not a required concatenation action capable of removing an abstract element included in the input abstract configuration is comprehensively applicable to the input abstract configuration by determining the following (1) and (2) for a concatenation rule capable of resolving the input abstract element, based on the characteristics of a graph indicating the conditions for the concatenation rule to be applicable. (1) Whether the reification rules can be applied to abstract structures in the future (2) If the reification rules are applicable to the abstract structure in the future, are the reification rules immediately applicable to the abstract structure in all the ways in which the abstract elements can be resolved?

[0214] The system configuration deriving device 300 may further include a solution target detection unit and a concretization rule recording unit. The solution target detection unit and the concretization rule recording unit correspond to the solution target detection unit 105 and the concretization rule recording unit 104, respectively. The solution target detection unit may receive a list of concretization rules as an input, detect abstract elements that can be resolved by the concretization rules included in the list, and create a database that can extract information on the concretization rules using information on the resolvable abstract elements as a key. The concretization rule recording unit may receive an abstract element as an input, and respond with a list of concretization rules that can resolve the input abstract element based on the database. In this case, the concretization policy identification unit 302 may input the abstract element to the concretization rule recording unit and obtain a list of concretization rules that can resolve the abstract element from the concretization rule recording unit. The concretization policy identification unit 302 may then input the abstract configuration, the abstract element, and the list of concretization rules to the comprehensiveness verification unit 303 and request verification.

[0215] Alternatively, the system configuration deriving device 300 may further include a solution target combining unit and a concretization rule recording unit. The solution target combining unit and the concretization rule recording unit correspond to the solution target combining unit 201 and the concretization rule recording unit 104, respectively. The solution target combining unit may receive a list of pairs of concretization rules and abstract elements resolved by the concretization rules as an input, and may create a database capable of extracting information on the concretization rules using information on the abstract elements resolved by the concretization rules as a key. The concretization rule recording unit may receive an abstract element as an input, and may respond with a list of concretization rules capable of resolving the input abstract element based on the database. In this case, the concretization policy identifying unit 302 may input the abstract element to the concretization rule recording unit and obtain a list of concretization rules capable of resolving the abstract element from the concretization rule recording unit. The concretization policy identifying unit 302 may then input the abstract configuration, the abstract element, and the list of concretization rules to the comprehensiveness verifying unit 303, and request verification.

[0216] Furthermore, the configuration information instantiation unit 301 may repeatedly convert the input abstract configuration into a more specific abstract configuration until it does not contain any abstract element.

[0217] <Fourth embodiment> Next, a configuration of the fourth embodiment of the present disclosure will be described with reference to the drawings. Fig. 19 is a block diagram showing an example of a hardware configuration of a system configuration derivation device 400 according to the fourth embodiment. Referring to FIG. 19, a system configuration deriving device 400 according to the fourth embodiment includes a processor 401 and a memory 402.

[0218] The processor 401 may be, for example, a microprocessor, a micro processing unit (MPU), or a central processing unit (CPU). The processor 401 may include multiple processors.

[0219] The memory 402 is configured by a combination of volatile memory and non-volatile memory. The memory 402 may include storage located away from the processor 401. In this case, the processor 401 may access the memory 402 via an I (Input) / O (Output) interface (not shown).

[0220] The system configuration derivation devices 100 to 300 according to the above-mentioned first to third embodiments may have a hardware configuration shown in FIG. 19. A program is stored in the memory 402. This program includes a set of instructions (or software code) for making the computer perform one or more functions described in the above-mentioned embodiments when the program is read into the computer. The configuration information concretization units 101 and 301, the concretization policy determination unit 102, the concretization policy specification unit 302, the coverage verification units 103 and 303, the solution target detection unit 105, and the solution target combination unit 201 in the above-mentioned system configuration derivation devices 100 to 300 may be realized by the processor 401 reading and executing the program stored in the memory 402. Also, the concretization rule recording unit 104 in the above-mentioned system configuration derivation devices 100 to 300 may be realized by the memory 402.

[0221] The above-mentioned programs may also be stored on non-transitory computer-readable media or tangible storage media. By way of example and not limitation, computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disc (DVD), Blu-ray® disk or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The programs may also be transmitted on a transitory computer-readable medium or communication medium. By way of example and not limitation, transitory computer-readable medium or communication medium includes electrical, optical, acoustic or other form of propagated signal.

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

[0223] 100~400 System configuration derivation device 101,301 Configuration Information Specifications Department 102 Specific Policy Judgment Department 103,303 Comprehensive Verification Department 104 Concrete Rules Recording Section 105 Solution target detection unit 201 Resolved Joint 302 Specific Policy Identification Department 401 Processor 402 Memory

Claims

1. A system configuration derivation device receives as input an abstract configuration that expresses a configuration of a system including undetermined abstract elements by a graph-like data structure composed of nodes corresponding to parts and edges indicating relationships between the parts, generates a search tree rooted at the input abstract configuration, converts the input abstract configuration into a more concrete abstract configuration by applying concretization rules that describe a method for removing abstract elements included in the abstract configuration, and adds the abstract configuration obtained by the conversion to the search tree, thereby repeatedly deriving a concretized system, a concatenation policy specification unit that specifies a concatenation action that must be applied to the input abstract configuration among concatenation actions that are concrete transformations of the abstract configuration according to the concatenation rules; a comprehensiveness verification unit that verifies whether the required instantiation action capable of removing the abstract element included in the input abstract configuration is applicable to the input abstract configuration comprehensively; a configuration information instantiation unit that converts the input abstract configuration into a more specific abstract configuration until the abstract configuration does not include the abstract element by applying the required instantiation action identified by the instantiation policy identification unit based on a verification result by the coverage verification unit; A system configuration deriving device comprising:

2. the configuration information instantiation unit inputs the abstract configuration of the branch source to the instantiation policy determination unit at a branch of the tree search of the search tree, and receives a presentation of the required instantiation action to be applied to the abstract configuration of the branch source from the instantiation policy determination unit. The system configuration deriving device according to claim 1 .

3. The comprehensiveness verification unit verifies whether the required concretization actions capable of removing the abstract element included in the input abstract configuration are comprehensively applicable to the input abstract configuration by determining, based on the characteristics of a graph indicating the conditions for the concretization rule to be applicable, whether (1) the concretization rule is applicable to the abstract configuration in the future, and (2) if the concretization rule is applicable to the abstract configuration in the future, whether the concretization rule is immediately applicable to the abstract configuration by all application methods capable of resolving the abstract element. The system configuration deriving device according to claim 1 .

4. a solution object detection unit that receives the list of instantiation rules as an input, detects abstract elements that can be solved by the instantiation rules included in the list, and creates a database from which information on the resolvable abstract elements can be extracted using information on the instantiation rules as a key; a concatenation rule recording unit that receives the abstract element as an input and responds with a list of the concatenation rules that can resolve the input abstract element based on the database; The embodiment policy specification unit inputting the abstract element into the concretization rule recording unit, and obtaining, from the concretization rule recording unit, a list of the concretization rules capable of resolving the abstract element; inputting the abstract configuration, the abstract elements, and the list of instantiation rules to the comprehensiveness verification unit and requesting the comprehensiveness verification unit to perform the verification; The system configuration deriving device according to claim 1 .

5. a solution object combination unit that receives as an input a list of pairs of the instantiation rules and the abstract elements resolved by the instantiation rules, and creates a database from which information on the instantiation rules can be extracted using information on the abstract elements resolved by the instantiation rules as a key; a concatenation rule recording unit that receives the abstract element as an input and responds with a list of the concatenation rules that can resolve the input abstract element based on the database; The embodiment policy specification unit inputting the abstract element into the concretization rule recording unit, and obtaining, from the concretization rule recording unit, a list of the concretization rules capable of resolving the abstract element; inputting the abstract configuration, the abstract elements, and the list of instantiation rules to the comprehensiveness verification unit and requesting the comprehensiveness verification unit to perform the verification; The system configuration deriving device according to claim 1 .

6. the configuration information instantiation unit repeatedly converts the input abstract configuration into a more specific abstract configuration until the abstract configuration does not include any of the abstract elements; The system configuration deriving device according to claim 1 .

7. A system configuration derivation method by a system configuration derivation device, which receives as input an abstract configuration expressing a configuration of a system including undetermined abstract elements by a graph-like data structure composed of nodes corresponding to parts and edges indicating relationships between the parts, generates a search tree rooted at the input abstract configuration, converts the input abstract configuration into a more concrete abstract configuration by applying concretization rules describing a method for removing abstract elements included in the abstract configuration, and adds the abstract configuration obtained by the conversion to the search tree, repeatedly deriving a concretized system, comprising: A first step of identifying a concretization action that must be applied to the input abstract configuration among concretization actions that are concrete transformations of the abstract configuration according to the concretization rules; a second step of verifying whether the required instantiation actions capable of removing the abstract elements included in the input abstract configuration are applicable to cover the input abstract configuration; a third step of converting the input abstract construction into a more concrete abstract construction by applying the required concretization actions identified in the first step based on the verification result of the second step, until the input abstract construction does not contain the abstract element; A system configuration deriving method comprising:

8. A program for causing a computer to execute the program, which receives as input an abstract configuration that represents a configuration of a system including undetermined abstract elements by using a graph-like data structure composed of nodes corresponding to parts and edges indicating relationships between the parts, generates a search tree rooted at the input abstract configuration, converts the input abstract configuration into a more specific abstract configuration by applying concretization rules that describe a method for removing abstract elements included in the abstract configuration, and adds the abstract configuration obtained by the conversion to the search tree, thereby deriving a concretized system, A first step of identifying a concretization action that must be applied to the input abstract configuration among concretization actions that are concrete transformations of the abstract configuration according to the concretization rules; a second step of verifying whether the required instantiation actions capable of removing the abstract elements included in the input abstract configuration are applicable to cover the input abstract configuration; a third step of converting the input abstract configuration into a more concrete abstract configuration by applying the required concretization actions identified in the first step based on the verification result of the second step, until the input abstract configuration does not contain the abstract element; Including, the program.

Images