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

Abstract

This system configuration derivation device comprises: an embodiment rule application evaluation means which calculates a first evaluation value that indicates the evaluation of the similarity between a specific embodiment rule application and a candidate of the embodiment rule application that is used for a new configuration that is an abstract configuration of a system design target when an embodiment configuration is obtained, wherein the specific embodiment rule application is included in a design history, which indicates a history, in a case where the embodiment configuration is obtained, which is a system configuration that does not include an abstract element, by repeating the embodiment rule application for the abstract configuration that is a system configuration including the abstract element; and an embodiment means which selects, among abstract configurations obtained by applying the embodiment rule to the new configuration one or more times, a specific abstract configuration and repeats the embodiment rule application for the selected specific abstract configuration, wherein the specific abstract configuration is selected on the basis of a second evaluation value that is calculated on the basis of the first evaluation value and indicates the evaluation of the similarity, with the design history, of the entirety of one or more applications of the embodiment rule until the abstract configuration is obtained from the new configuration.

Description

[Technical Field]

[0001] The present invention relates to a system configuration derivation device, a system configuration derivation method, and program Regarding. [Background technology]

[0002] It has been proposed to design a system by repeatedly applying concretization rules to an abstract description of the system configuration to be designed, thereby concretizing the system configuration. For example, a system configuration derivation device described in Patent Document 1 calculates a score for each pair consisting of a concretization rule and an object to which the concretization rule is applied, when applying one of a plurality of concretization rules to the configuration requirements of a system to be constructed, and selects the pair based on the score to determine the application of the concretization rule to the configuration rule. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent No. 6989014 Summary of the Invention [Problem to be solved by the invention]

[0004] When designing a system by repeatedly applying concretization rules to an abstract description of the system configuration to be designed to concretize the system configuration, if it is possible to approximate a system designed in the past, it is expected that a system that is relatively close to a system that has a proven track record of use and, in this respect, relatively reliable will be obtained.

[0005] An example of an object of the present invention is to provide a system configuration derivation device, a system configuration derivation method, and program The purpose is to provide [Means for solving the problem]

[0006] According to a first aspect of the present invention, a system configuration derivation device includes a concretization rule application evaluation means for calculating a specific application of a concretization rule included in a design history indicating a history when a concrete configuration, which is a system configuration that does not include abstract elements, is obtained by repeatedly applying a concretization rule to an abstract configuration, which is a system configuration that includes abstract elements, and a first evaluation value indicating an evaluation of similarity between a candidate for application of the concretization rule used when deriving the concrete configuration and a new configuration, which is the abstract configuration to be designed as a system; and a concretization means for selecting a specific abstract configuration from the abstract configurations obtained by applying the concretization rule one or more times to the new configuration based on a second evaluation value indicating an evaluation of similarity between the abstract configurations obtained by applying the concretization rule one or more times to the new configuration and the design history, the second evaluation value being calculated based on the first evaluation value, and indicating an evaluation of similarity between the abstract configurations obtained by applying the concretization rule one or more times to the new configuration and the candidate for application of the concretization rule, and

[0007] According to a second aspect of the present invention, a system configuration derivation method includes: a computer calculating a first evaluation value indicating an evaluation of similarity between a specific application of a concretization rule included in a design history indicating a history when a concrete configuration, which is a system configuration that does not include abstract elements, is obtained by repeatedly applying a concretization rule to an abstract configuration, which is a system configuration that includes abstract elements; and a candidate application of the concretization rule to be used when obtaining the concrete configuration for a new configuration, which is the abstract configuration to be designed; selecting a specific abstract configuration from the abstract configurations obtained by applying the concretization rule one or more times to the new configuration based on a second evaluation value indicating an evaluation of similarity with the design history for the entire one or more applications of the concretization rule from the new configuration to the abstract configuration, the second evaluation value being calculated based on the first evaluation value; and repeatedly applying the concretization rule to the selected specific abstract configuration.

[0008] According to a third aspect of the present invention, programa program for causing a computer to execute the following steps: calculating a first evaluation value indicating an evaluation of similarity between a specific application of a concretization rule included in a design history indicating a history when a concrete configuration, which is a system configuration not including abstract elements, is obtained by repeatedly applying a concretization rule to an abstract configuration, which is a system configuration including abstract elements, and a candidate for application of the concretization rule used when obtaining the concrete configuration for a new configuration, which is the abstract configuration to be designed; selecting a specific abstract configuration from the abstract configurations obtained by applying the concretization rule one or more times to the new configuration based on a second evaluation value indicating an evaluation of similarity between the abstract configuration and the design history for the entire one or more applications of the concretization rule from the new configuration to the abstract configuration, the second evaluation value being calculated based on the first evaluation value; and repeating the application of the concretization rule to the selected specific abstract configuration. In be. [Effects of the Invention]

[0009] According to the present invention, it is expected that a system can be designed that is relatively similar to systems designed in the past. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a block diagram showing an example of the configuration of a system configuration derivation device according to a first embodiment. [Figure 2] FIG. 10 is a block diagram showing an example of the configuration of a system configuration derivation device according to a second embodiment. [Figure 3] FIG. 1 illustrates an example of an abstract configuration according to an embodiment. [Figure 4] FIG. 10 is an explanatory diagram illustrating an example of a concretization rule according to the embodiment. [Figure 5] 10A-10C illustrate examples of applying reification rules in two different ways according to an embodiment. [Figure 6] FIG. 1 is an explanatory diagram illustrating an example of a design history according to an embodiment. [Figure 7] 4 is a flowchart illustrating an example of a procedure in which a configuration information instantiation unit according to the first embodiment derives a specific configuration of a system. [Figure 8] 10 is a flowchart illustrating an example of the operation of a matching degree calculation unit according to the embodiment. [Figure 9] 10 is a flowchart illustrating an example of an operation of a similarity calculation unit according to the embodiment. [Figure 10] 10 is a flowchart illustrating an example of a procedure in which a concretization application / similarity reflection unit according to the embodiment generates a list of concretization candidates. [Figure 11] 10 is a flowchart illustrating an example of the operation of a configuration information instantiation unit according to the second embodiment. [Figure 12] 4 is a diagram showing an example of a tree searched by a configuration information instantiation unit according to the first embodiment; FIG. [Figure 13] FIG. 10 is a diagram illustrating an example of the configuration of a system configuration derivation device according to a third embodiment. [Figure 14] FIG. 10 is a diagram illustrating an example of a processing procedure in a system configuration derivation method according to the fourth embodiment. [Figure 15] FIG. 1 is a schematic block diagram illustrating the configuration of a computer according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

[0012] First Embodiment (Configuration explanation) Fig. 1 is a block diagram showing an example of the configuration of a system configuration deriving device 100 according to the first embodiment. In the configuration shown in Fig. 1, the system configuration deriving device 100 includes a configuration information concretization unit 101, a concretization application / similarity reflection unit 102, a similarity calculation unit 103, and a matching coincidence calculation unit 104.

[0013] The configuration information instantiation unit 101 receives an abstract configuration as input, and derives a concrete configuration by sequentially applying instantiation rules applicable to the acquired abstract configuration.

[0014] The similarity calculation unit 103 receives the abstract configuration, the design history, the instantiation action, and the primary design history as input, calculates the similarity between the acquired instantiation action and the primary design history, and further calculates a new identifier mapping for the instantiation action.

[0015] The matching agreement calculation unit 104 receives as input two instantiation actions A and B and a list of identifiers (prohibited identifier list), calculates the similarity between the two obtained instantiation actions, and further calculates a new identifier mapping for instantiation action A.

[0016] The concretization application / similarity reflection unit 102 receives an abstract configuration, a design history, and a concretization action as input, and returns a list of pairs of results of applying the concretization action to the acquired abstract configuration and associated similarity scores.

[0017] In the following, an example will be described in which the system configuration deriving device 100 is used to design an ICT (Information and Communication Technology) system, although the application of the system configuration deriving device 100 is not limited to a specific one.

[0018] The following describes an abstract configuration and its data structure according to an embodiment. The term "abstract configuration" here refers to an abstract system configuration that includes undetermined configuration and setting aspects. The abstract configuration is information that is determined, for example, by an entity that desires an ICT system. In other words, the abstract configuration is information that defines a desired system without specifically mentioning the details of the system, by having a user write down only information indicating "what requirements the system should satisfy and what functions it should have" using, for example, a GUI (Graphical User Interface) in accordance with the following format (see, for example, Figure 3: details will be described later).

[0019] In other words, the abstract configuration described above is represented in a form using a graph consisting of "nodes" that correspond to the functions and logical and physical components of a system, and "edges" that are stretched between two nodes and represent the relationship between those two nodes. Edges in an abstract configuration have 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 will be collectively called "entities."

[0020] An entity has an "identifier" that uniquely identifies the entity throughout the entire system, and "type information" that describes the concept to which the entity corresponds. 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 are treated as "the same entity."

[0021] We will now explain in more detail the "type information" that accompanies entities.

[0022] Type information has the role of indicating what type of information the entity to which it is attached is. There are two types of types: "abstract type" and "concrete type." Abstract types indicate entities that do not directly correspond to concrete components or connection relationships that exist in the real world, such as "Machine" or "HTTP connection available," and require further concreteness. Concrete types, on the other hand, indicate entities that correspond to concrete components or connection relationships that exist in the real world, such as "(concrete machine model number)" or "wired LAN connection."

[0023] Types have the concept of abstraction, and between type information, the concept of parent-child relationships is defined based on the relationship, such as "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, or parent type, of type t2, and type t2 is said to be the child, or child type, of type t1.

[0024] By applying the concatenation rules described below to the type of a node, the type of that node can be converted into its child type. This corresponds to the operation of narrowing down the candidates so that the type of the node becomes more specific according to the concatenation rules.

[0025] In addition, a node type (node type) may have information indicating a "requested part." A single node type may have multiple requested parts, or may not have any requested parts at all.

[0026] This concludes the explanation of the "type information" that accompanies entities. Next, we will provide a more detailed explanation of the "requested parts" that accompany node types.

[0027] Intuitively, required components attached to a node type indicate the dependent components that are required for the correct operation of the component corresponding to the node with that node type. For example, the "App" type, which represents an application, has a required component of "Machine." This indicates that the application requires a machine to host it in order to function.

[0028] When a node has a node type that has a required part attached to it, it is also simply said that the node has a required part. By extending an edge with a special concrete edge type "WIRE:req" from node N1 to another node N2 for the required part req that node N1 has, the part requested by node N1 can be connected to node N1. The description of the "req" part here will vary depending on the required part.

[0029] Extending this edge is equivalent to selecting node N2 as the part req requested by node N1. The request can be fulfilled by connecting an appropriate part to the requested part held by the node.

[0030] For example, in the App type example above, by connecting the App type node MyApp to the Machine type node Machine1 via a "WIRE:Machine" edge, the host destination of the node MyApp can be specified as node Machine1.

[0031] 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 via a "WIRE:Machine" edge.

[0032] This concludes the explanation of the "requested parts" that accompany node types.

[0033] Next, the abstract configuration will be described.

[0034] FIG. 3 is a diagram showing an example of an abstract configuration. In FIG. 3, icons labeled 300, 301, and 302 represent nodes. Arrows labeled 303 and 304 represent edges. Nodes are labeled with a format of "(identifier):(type name)". Edges, on the other hand, are labeled with only the type name. Nodes 300 and 301 are also labeled with speech bubbles indicating required components. To make the diagram easier to read, information about requirements and labels is omitted as appropriate.

[0035] Both nodes 300 and 301 represent applications. Here, both nodes 300 and 301 correspond to concrete system components that do not contain any uncertain parts. Both of these nodes have a "Machine" requirement component. The requirement of node 300 is satisfied by connecting Machine1. On the other hand, the requirement of node 301 is not satisfied.

[0036] Node 302 is a node that indicates "some machine." In other words, it is determined that node 302 is a machine that can run an application, but it is not determined what specific product will be used here.

[0037] Edge 303 is an edge that indicates a specific relationship, indicating that source node 300 is hosted on destination node 302. By connecting node 302 to node 300 via edge 303, the "Machine" requirement of node 300 is fulfilled.

[0038] Edge 304 indicates that it is guaranteed that source node 300 can send an HTTP request in some way to destination node 301. Edge 304 is an edge that indicates an abstract relationship in that the specific communication path is undefined.

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

[0040] Next, the reification rules will be explained. A reification rule includes information that represents the target of reification and information that represents the configuration after reification. The information in the reification rule that represents the target of reification is called the "left side (of the reification rule)." The information in the reification rule that represents the configuration after reification is called the "right side (of the reification rule)."

[0041] The left-hand side of the concatenation rule and the right-hand side of the concatenation rule are attributed graphs, as are the basic structures of abstract compositions.

[0042] The entities on the left and right sides of the reification rule must satisfy all of the following three conditions (c11), (c12), and (c13).

[0043] (c11) A node that exists on the left side must also exist on the right side. Condition (c11) is a constraint to ensure that the existence of a component that has already been added to the abstract configuration by concretization does not disappear.

[0044] (c12) Concrete entities on the left side are not deleted. Condition (c12) is a constraint to ensure that a concrete rewrite that retracts a part that has already been determined is not performed.

[0045] (c13) 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." Condition (c13) is a constraint to ensure that the rewriting of component types that occurs through reification is only a "narrowing of the type to a more specific one," and that they are not rewritten into a completely different type of component.

[0046] Next, we explain how abstract constructs are instantiated by instantiation rules.

[0047] 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 (c21) a subgraph of abstract configuration d contains a subgraph with exactly the same shape as the left-hand side of reification rule r, and (c22) in the one-to-one relationship between entities based on (c21) above, "the type of the entity on the left-hand side of reification rule r" is a parent type of "the type of the entity on the abstract configuration d".

[0048] The "subgraph of abstract configuration d that corresponds to the left-hand side of concatenation rule r" is called the object of concatenation by concatenation rule r of abstract configuration d.

[0049] In other words, when a reification rule r is applicable to an abstract construction d, the abstract construction d has a reification target, which is a substructure that corresponds one-to-one to the left-hand side of the reification rule r. Rewriting an abstract construction d using a reification rule r means replacing the reification target with the structure expressed on the right-hand side of the reification rule r.

[0050] When there is an entity e[new] that is not on the left side of a reification rule but exists only on the right side, a new corresponding entity is generally created. However, if an entity e[reused] with the same type or a subtype as entity e[new] already exists in the abstract structure in a different part from the one being reified, e[reused] can be used instead of creating a new entity. This is called "reusing" entity e[reused] in the application of the reification rule.

[0051] 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. The combination of the reification rule and the information on the application point is called a "reification action." A reification action is an example of the application of a reification rule.

[0052] In the case where there is an entity e[new] that exists only on the right side of the reification rule and not on the left side, and a new entity corresponding to entity e[new] is to be created, the application point may or may not contain information about the "identifier to assign to e[new]."

[0053] If such information is included, the target identifier is assigned to e[new] at the time of instantiation. If such information is not included, a new identifier not included in the target abstract configuration is generated at the time of instantiation, and that identifier is assigned to the newly created entity corresponding to e[new]. When two or more new identifiers are generated, there is no overlap between them.

[0054] Next, we will illustrate reification rules and their application using specific examples. Figure 4 is a diagram showing examples of reification rules. Figure 4 shows three reification rules: "APP-HOST", "USE-SERVER-A", and "USE-SERVER-B". In Figure 4, the left side of the reification rule is shown to the left of the arrow, and the right side of the reification rule is shown to the right.

[0055] The reification rule "APP-HOST" indicates that the graph is transformed so that the "Machine" requirement is met by connecting a "Machine" type node to an "App" type node whose "Machine" requirement is not met. The reification rule "APP-HOST" represents an operation to connect a "Machine" type node {2} to an "App" type node {1} already included in the abstract configuration with a "WIRE:Machine" type edge. This operation satisfies the "Machine" requirement of node {1}.

[0056] "USE-SERVER-A" indicates that the graph is transformed so that "Machine" type nodes are replaced with "Server-A" type nodes. The transformation rule "USE-SERVER-A" indicates that a concrete server represented by a "Server-A" type node is adopted for an abstract machine represented by a "Machine" type node.

[0057] "USE-SERVER-B" indicates that the graph is transformed so that "Machine" type nodes are replaced with "Server-B" type nodes. The transformation rule "USE-SERVER-B" indicates that a concrete server represented by a "Server-B" type node is adopted for an abstract machine represented by a "Machine" type node.

[0058] FIG. 5 shows a specific example of applying the instantiation rule "APP-HOST" in two different ways as shown in FIG.

[0059] Application example 500 is a case where the reification rule "APP-HOST" is applied to the application point "{1}:App2". In application example 500, the reification rule "APP-HOST" is applied by matching the node {1} in the reification rule with the node App2 in Figure 3. A new Machine type node corresponding to {2} is created and given the identifier "Machine2".

[0060] On the other hand, application example 501 is a case where the reification rule "APP-HOST" is applied to the application point "{1}:App2, {2}:Machine1". In application example 501, node Machine1 is reused, and the existing node Machine1 is used as a Machine type node corresponding to node {2}, which exists only on the right side of the reification rule "APP-HOST".

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

[0062] This concludes the explanation of rewriting abstract constructs by applying concretization rules.

[0063] Next, a specific configuration derived by the system configuration deriving device 100 will be described.

[0064] The concrete configuration here refers to a fully concretized abstract configuration. Here, an abstract configuration being "fully concretized" means that it satisfies all three of the following concretization conditions: (Concretization Condition 1), (Concretization Condition 2), and (Concretization Condition 3).

[0065] (Concrete Condition 1) The abstract configuration does not contain any nodes with abstract types.

[0066] (Concretized condition 2) The abstract configuration does not contain any edges with abstract types.

[0067] (Concrete Condition 3) The abstract structure does not contain any unsatisfied requirements.

[0068] From the definition of the concretized condition, it can be said that a fully concretized abstract configuration indicates a state in which there are no ambiguous parts in the ICT system and all the components necessary for operation are present. Therefore, a concrete configuration corresponds to a system that is functionally fully operational.

[0069] Next, the design history will be described.

[0070] Applying a concretization action to an abstract construct generates another abstract construct that is more concrete than the original, and this procedure can be repeated multiple times.

[0071] When applying concretization actions a[1], a[2], ..., a[n] to an abstract configuration D1 in this order results in an abstract configuration D2 that is different from abstract configuration D1, the sequence of concretization actions a[1], a[2], ..., a[n] is called the "design history of abstract configuration D2 starting from abstract configuration D1." Also, when the starting abstract configuration D1 is obvious from the context, the sequence of concretization actions is also simply called the "design history of abstract configuration D2."

[0072] Next, the design history will be explained using an example. Figure 6 is an explanatory diagram showing an example of the design history.

[0073] Figure 6 shows the process by which abstract configuration T0 is transformed into abstract configuration T4 through T1, T2, and T3. Figure 6 shows an example of a design history composed of four concretization actions a1, a2, a3, and a4.

[0074] (a1) Reification rule: APP-HOST, Applicable location: {{1}: App1, {2}: Machine1}

[0075] (a2) Reification rule: APP-HOST, Applicable location: {{1}: App2, {2}: Machine2}

[0076] (a3) Reification rule: USE-SERVER-A, Applied to: {{1}: Machine1}

[0077] (a4) Reification rule: USE-SERVER-B, Applied to: {{1}: Machine2}

[0078] (Explanation of operation) The system configuration derivation device 100 receives an abstract configuration representing requirements as input, and outputs a concrete configuration that satisfies the requirements indicated by the input abstract configuration. This series of processes is called an automated design process. To distinguish from primary requirements, which will be described later, the abstract configuration input to the system configuration derivation device 100 as the target for calculating a concrete configuration is called a "new requirement."

[0079] Furthermore, the system configuration deriving device 100 reads a list of instantiation rules to be used in the automatic design process as a preprocessing step before the automatic design process is executed.

[0080] Furthermore, the system configuration derivation device 100 receives as inputs "primary requirements," which are abstract configurations that represent information on requirements like new requirements, and "primary design history," which is a design history that concretizes the primary requirements into concrete configurations.

[0081] Below, we provide additional information about the primary design history.

[0082] The primary design history may be, but is not limited to, a design history obtained as a result (secondarily) of applying an automated design process to the primary requirements, as in the case of new requirements. For example, a design history obtained as a result of manually configuring and applying applicable instantiation actions to the primary requirements may be input as the primary design history to the system configuration deriving device 100.

[0083] Furthermore, unlike normal application locations, application locations of each reification action included in the primary design history are assumed to have a "complete" identifier correspondence with the reification rules of that reification action. Generally, application locations of a reification action do not necessarily contain correspondences for all identifiers used in (the right-hand side of) the reification rules, and if no correspondence exists, a new identifier is generated. In contrast, if an application location of a reification action included in the primary design history contains an identifier for which no correspondence is defined, it is assumed to always contain a correspondence indicating information on "what identifier will be generated and assigned to that identifier (by applying the reification rules in the primary design history)."

[0084] In addition, the specific configuration obtained as a result of designing the primary requirements according to the primary design history is called the "primary specific configuration."

[0085] For example, the concatenation action in the application example 500 of the concatenation rule shown in Fig. 5 has information on the application location "{1}:App2", and for {2}, where no correspondence exists, the identifier "Machine2" is newly generated and assigned. When the information on this concatenation action is included in the primary design history, this concatenation action is considered to have the application location "{1}:App2, {1}:Machine2".

[0086] The above is a supplementary explanation of the primary design history.

[0087] Next, the processing of each unit of the system configuration deriving device 100 will be described in detail.

[0088] First, a description will be given of the operation of the matching degree calculation unit 104. FIG.

[0089] (Step S800) The matching coincidence calculation unit 104 receives as input two concretization actions (a[new]: new concretization action, a[prev]: primary concretization action) and a prohibited identifier list L. The new concretization action a[new] is a concretization action that can be applied in a system design by concretizing a new requirement. The primary concretization action a[prev] is a concretization action included in the primary design history.

[0090] Here, the instantiation action a[new] is made up of the instantiation rule R[new] and the application location M[new]. The instantiation action a[prev] is made up of the instantiation rule R[prev] and the application location M[prev]. After step S800, the process proceeds to step S801.

[0091] (Step S801) The matching agreement calculation unit 104 sets the initial value of SCORE to 0, the initial value of MAP to empty identifier assignment information, and the initial value of USED to an identifier list having the same contents as the prohibited identifier list L. SCORE is a variable for calculating a similarity score indicating the similarity between the left side of the concatenation rule and the application location. MAP is a variable for calculating the new identifier mapping. USED is a variable used for calculating SCORE. The new identifier mapping is a list of application locations obtained by the matching agreement calculation unit 104 in evaluating the similarity between the new concatenation action a[new] and the primary concatenation action a[prev]. The concatenation application and similarity reflection unit 102 includes the application locations included in the new identifier mapping as candidates for application locations in the system design by concretizing the new requirement.

[0092] Here, "identifier assignment information" is dictionary-format data that has the same format as the application location of the concatenation action and indicates the correspondence between the identifier of the concatenation rule and another identifier. "Empty" identifier assignment information refers to identifier assignment information that does not include any correspondence. After step S801, the process proceeds to step S802.

[0093] (Step S802) The matching degree calculation unit 104 compares the concatenation rule R[new] with the concatenation rule R[prev]. If the matching degree calculation unit 104 determines that the concatenation rule R[new] and the concatenation rule R[prev] are the same concatenation rule (step S802: YES), the process proceeds to step S804. On the other hand, if the matching degree calculation unit 104 determines that the concatenation rule R[new] and the concatenation rule R[prev] are not the same concatenation rule (step S802: NO), the process proceeds to step S808.

[0094] (Step S803) The matching coincidence calculation unit 104 executes a loop L81 for processing each correspondence "ID[rule]:ID[prev]" included in the application point M[prev]. After step S803, the process proceeds to step S804.

[0095] (Step S804) The matching degree calculation unit 104 determines whether a correspondence relationship for the identifier ID[rule] is included in the application location M[new] (step S804). If the matching degree calculation unit 104 determines that the correspondence relationship "ID[rule]:ID[new]" for the identifier ID[rule] is included in the application location M[new] (step S804: YES), the process proceeds to step S805. On the other hand, if the matching degree calculation unit 104 determines that a correspondence relationship for the identifier ID[rule] is not included in the application location M[new] (step S804: NO), the process proceeds to step S806.

[0096] (Step S805) The matching degree calculation unit 104 determines whether ID[new] and ID[prev] match. If it is determined that ID[new] and ID[prev] match, the matching degree calculation unit 104 increments the value of SCORE by 1. After step S805, the process proceeds to step S807.

[0097] (Step 806) The matching agreement calculation unit 104 determines whether ID[prev] is included in USED. If it determines that ID[prev] is not included in USED, the matching agreement calculation unit 104 increases the value of SCORE by 1, adds ID[prev] to USED, and adds the correspondence "ID[rule]:ID[prev]" to MAP. After step S806, the process proceeds to step S807.

[0098] (Step S807) The matching degree calculation unit 104 performs the termination process of the loop L81. Specifically, the matching degree calculation unit 104 determines whether or not the process of the loop L81 has been performed on all of the correspondence relationships "ID[rule]:ID[prev]" included in the application point M[prev]. If it is determined that there is a correspondence relationship "ID[rule]:ID[prev]" for which the process of the loop L81 has not been performed, the matching degree calculation unit 104 returns to step S803 and continues to perform the process of the loop L81 on the unprocessed correspondence relationship "ID[rule]:ID[prev]". On the other hand, if it is determined that the process of the loop L81 has been performed on all of the correspondence relationships "ID[rule]:ID[prev]", the matching degree calculation unit 104 ends the loop L81. After the end of the loop L81, the process proceeds to step S808.

[0099] (Step S808) The matching agreement calculation unit 104 divides SCORE by the number N of nodes included on the right side of the concatenation rule R[new], sets the value obtained by dividing SCORE by the number N of nodes included on the right side of the concatenation rule R[new], outputs the obtained SCORE value as the similarity score, and outputs the MAP value as the new identifier mapping. The similarity score calculated by the matching agreement calculation unit 104 corresponds to an example of a first evaluation value. The matching agreement calculation unit 104 corresponds to an example of a concatenation rule application evaluation means. After step S808, the matching agreement calculation unit 104 ends the processing of FIG. 8.

[0100] This concludes the description of the operation of the matching coincidence calculation unit 104.

[0101] Next, four examples will be given of the operation of the matching coincidence calculation unit 104. In the following four examples, the concretization rules are as shown in FIG. 4, and the primary concretization action is the same for all, and the following concretization action a[prev] is used.

[0102] (a[prev]) Reification rule APP-HOST, applied to {{1}: App1, {2}: Machine2}

[0103] (Example 1) Assume that the concatenation action a[new] has the "concretization rule APP-HOST, application location {{1}: App1, {2}: Machine1}" and the prohibited identifier list is "App1, Machine1, Machine2." In this case, the correspondence relationship for all two identifiers included on the left side of the concatenation rule APP-HOST is included in the application location of the concatenation action a[new], and only one correspondence destination matches. Therefore, the matching agreement calculation unit 104 calculates the similarity score as 1 / 2 = 0.5. In addition, the matching agreement calculation unit 104 outputs the initial value, empty identifier assignment information, as is as the new identifier mapping.

[0104] (Example 2) Assume that the concatenation action a[new] is "concretization rule APP-HOST, application location {{1}: App1, {2}: Machine2}" and the prohibited identifier list is "App1, Machine1, Machine2." In this case, the correspondence relationship for all two identifiers included on the left side of the concatenation rule APP-HOST is included in the application location of the concatenation action a[new], and both identifiers correspond to the same destination. Therefore, the matching agreement calculation unit 104 calculates the similarity score as 2 / 2=1. Furthermore, the matching agreement calculation unit 104 outputs the initial value, empty identifier assignment information, as is, as the new identifier mapping.

[0105] (Example 3) Assume that the concatenation action a[new] has the "concretization rule APP-HOST, application location {{1}: App1}" and the prohibited identifier list is "App1, Machine1." In this case, among the identifiers included on the left side of the concatenation rule APP-HOST, the correspondence relationship with {2} is not included in the application location of the concatenation action a[new], and is also not included in the prohibited identifier list. Therefore, the matching agreement calculation unit 104 calculates the similarity score as 2 / 2=1. In addition, the matching agreement calculation unit 104 sets the new identifier mapping to "{2}: Machine2."

[0106] (Example 4) Assume that the instantiation action a[new] has the "insertion rule APP-HOST, application location {{1}: App1}" and the prohibited identifier list is "App1, Machine1, Machine2." In this case, among the identifiers included on the left side of the instantiation rule APP-HOST, the correspondence with {2} is not included in the application location of the instantiation action a[new], but is included in the prohibited identifier list. Therefore, the matching agreement calculation unit 104 calculates the similarity score as 1 / 2 = 0.5. Furthermore, the matching agreement calculation unit 104 outputs the initial value, empty identifier assignment information, as is, as the new identifier mapping.

[0107] The above is an example of the operation of the matching coincidence calculation unit 104.

[0108] Next, a description will be given of the operation of the similarity calculation unit 103. FIG.

[0109] (Step S900) The similarity calculation unit 103 receives as input an abstract construction D and a concretization action a[new] applicable to the abstract construction D. After step S900, the process proceeds to step S901.

[0110] (Step S901) The similarity calculation unit 103 generates a list L of extracted identifiers of all nodes used in the abstract construction D. After step S901, the process proceeds to step S902.

[0111] (Step S902) The similarity calculation unit 103 sets the initial value of SCORE to 0, and also sets the initial value of MAP to null identifier assignment information. After step S902, the process proceeds to step S903.

[0112] (Step S903) The similarity calculation unit 103 executes a loop L91 for processing each instantiation action a[i] included in the primary design history a[1], a[2], ..., a[n] received as input by the system configuration deriving device 100. After step S903, the process proceeds to step S904.

[0113] (Step S904) The similarity calculation unit 103 inputs a[new] as the new instantiation action, a[i] as the primary instantiation action, and L as the prohibited identifier list to the matching coincidence calculation unit 104, and obtains as output the similarity SCORE[i] between the new instantiation action a[new] and the primary instantiation action a[i] and the new identifier mapping MAP[i]. After step S904, the process proceeds to step S905.

[0114] (Step S905) The similarity calculation unit 103 compares SCORE[i] with SCORE, and if SCORE[i] is greater, updates SCORE to SCORE[i] and MAP to MAP[i]. After step S905, the process proceeds to step S906.

[0115] (Step S906) The similarity calculation unit 103 performs the termination process of the loop L91. Specifically, the similarity calculation unit 103 determines whether the process of the loop L91 has been performed for all the concretization actions a[i] included in the primary design history a[1], a[2], ..., a[n]. If it is determined that there is a concretization action a[i] for which the process of the loop L91 has not been performed, the similarity calculation unit 103 returns to step S903 and continues to perform the process of the loop L91 for the unprocessed concretization action a[i]. On the other hand, if it is determined that the process of the loop L91 has been performed for all the concretization actions a[i], the similarity calculation unit 103 ends the loop L91. After the end of the loop L91, the process proceeds to step S907.

[0116] (Step S907) The similarity calculation unit 103 outputs the similarity score SCORE and the new identifier mapping MAP After step S907, the similarity calculation unit 103 ends the process of FIG.

[0117] The similarity calculation unit 103 returns the similarity score value of the most similar instantiation action (i.e., the action with the highest similarity score) among the instantiation actions included in the primary design history to the input instantiation action.

[0118] The above is the description of the operation of the similarity calculation unit 103.

[0119] The operation of generating a list of concretization candidates by the concretization application and similarity reflection unit 102 will be described with reference to the drawing. Fig. 10 is a flowchart showing an example of a procedure by which the concretization application and similarity reflection unit 102 generates a list of concretization candidates.

[0120] (Step S1000) The concretization application / similarity reflection unit 102 receives the abstract construction D and the similarity score S[D] as input. After step S1000, the process proceeds to step S1001.

[0121] (Step S1001) The instantiation application / similarity reflection unit 102 initializes the list L of candidates to be output as a result to an empty list. After step S1001, the process proceeds to step S1002.

[0122] (Step S1002) The concretization application / similarity reflection unit 102 generates all concretization actions applicable to the abstract configuration D based on the list of available concretization rules read by the system configuration deriving device 100 as preprocessing, and constructs a list of concretization actions Actions. Note that when multiple concretization actions are possible for the same concretization rule as illustrated in Figure 5, all possible concretization actions may be included in the list Actions, but this is not limited to this. After step S1002, the process proceeds to step S1003.

[0123] (Step S1003) The instantiation application / similarity reflection unit 102 executes a loop L101 for processing all instantiation actions a included in the list Actions After step S1003, the process proceeds to step S1004.

[0124] (Step S1004) The concretization application / similarity reflection unit 102 inputs the abstract configuration D and the concretization action a to the similarity calculation unit 103, and obtains the output, that is, the similarity score S[a] and the new identifier mapping MAP. After step S1004, the process proceeds to step S1005.

[0125] (Step S1005) The instantiation application / similarity reflection unit 102 adds all correspondences included in the new identifier mapping MAP obtained in step S1004 to the application points of the instantiation action a. After step S1005, the process proceeds to step S1006.

[0126] (Step S1006) The instantiation application and similarity reflection unit 102 generates a new abstract construction D(a) by rewriting the abstract construction D using the instantiation action a.

[0127] The rewriting of the abstract construction in step S1006 does not rewrite the data of the original abstract construction D itself. That is, in step S1006, a new abstract construction D(a) is generated by the rewriting using the concretization action, and is newly generated as data separate from the abstract construction D. After step S1006, the process proceeds to step S1007.

[0128] (Step S1007) The concretization application / similarity reflection unit 102 calculates the similarity score S[D(a)] for the abstract structure D(a) using the similarity score S[D] of the abstract structure D and the similarity score S[a] obtained in step S1004, according to the following score update formula Sc:

[0129] (Score update formula Sc) S[D(a)] = w1 × S[D] + w2 × S[a] (where w1 and w2 are positive constants)

[0130] w1 and w2 are weighting constants that determine the degree to which the original similarity score S[D] and the score S[a] of the newly applied concretization action are reflected in the similarity score of the abstract configuration D(a). For example, if w1 = w2 = 1, a simple cumulative sum is obtained. Alternatively, if w1 = 0.5 and w2 = 1, the score of the old concretization action is attenuated by half and added together. The weighting values can be any positive constant value. The similarity score S[D(a)] for the abstract configuration calculated by the concretization application and similarity reflection unit 102 is an example of a second evaluation value. The combination of the configuration information concretization unit 101 and the concretization application and similarity reflection unit 102 is an example of a concretization means. After step S1007, the process proceeds to step S1008.

[0131] (Step S1008) The instantiation application / similarity reflection unit 102 adds the pair (D[a], S[D(a)]) to the list L. After step S1008, the process proceeds to step S1009.

[0132] (Step S1009) The concretization application and similarity reflection unit 102 performs the termination process of loop L101. Specifically, the concretization application and similarity reflection unit 102 determines whether or not the process of loop L101 has been performed for all concretization actions included in Actions. If it is determined that there is a concretization action for which the process of loop L101 has not been performed, the concretization application and similarity reflection unit 102 returns to step S1003 and continues to perform the process of loop L101 for the unprocessed concretization actions. On the other hand, if it is determined that the process of loop L101 has been performed for all concretization actions, the concretization application and similarity reflection unit 102 ends loop L101. After the end of loop L101, the process proceeds to step S1010.

[0133] (Step S1010) The concretization application and similarity reflection unit 102 returns the list L as an output. After step S1010, the concretization application and similarity reflection unit 102 ends the processing of FIG.

[0134] The above is the description of the operation of the instantiation application and similarity reflection unit 102.

[0135] The operation of the configuration information instantiation unit 101 for designing an ICT system will be described with reference to the drawings. Figure 7 is a flowchart showing an example of the procedure by which the configuration information instantiation unit 101 derives a specific configuration of a system.

[0136] (Step S700) The configuration information instantiation unit 101 receives as input a new requirement D_init expressed in the form of an abstract configuration from an input / output device. The input / output device functions as an interface between the system configuration deriving device 100 and the outside. After step S700, the process proceeds to step S701.

[0137] (Step S701) The configuration information instantiation unit 101 initializes the search candidate list T to an empty list. After step S701, the process proceeds to step S702.

[0138] (Step S702) The configuration information instantiation unit 101 adds a pair whose first element is an abstract configuration and whose second element is its similarity score value to the search candidate list T. The configuration information instantiation unit 101 adds the pair (D_init, 0) to the search candidate list T. After step S702, the process proceeds to step S703.

[0139] (Step S703) The configuration information instantiation unit 101 determines whether to continue searching the tree. Specifically, the configuration information instantiation unit 101 determines whether a sufficient number of concrete configurations have not been added to the search candidate list T and whether abstract configurations to be searched for have disappeared from the search tree. The threshold value here, "a (sufficient) number," is, for example, a value input through an input / output device, or is specified as a value built into the device from the beginning.

[0140] If the configuration information instantiation unit 101 determines that a sufficient number of specific configurations have not been added to the search candidate list T and that abstract configurations to be searched for have not disappeared from the search tree (step S703: YES), the process proceeds to step S704. On the other hand, if the configuration information instantiation unit 101 determines that a sufficient number of specific configurations have been added to the search candidate list T or that abstract configurations to be searched for have disappeared from the search tree (step S703: NO), the process proceeds to step S706.

[0141] (Step S704) The configuration information instantiation unit 101 selects one of the pairs (D, S) included in the search candidate list T that satisfies all of the following three conditions (c31), (c32), and (c33).

[0142] (c31) The abstract construction D is not fully instantiated.

[0143] (c32) A set having the same first element as the abstract configuration D has not been previously selected in step S704.

[0144] (c33) The similarity score S is the highest among the similarity scores of the pairs included in the search candidate list T.

[0145] After step S704, the process proceeds to step S705.

[0146] (Step S705) The configuration information instantiation unit 101 inputs the abstract configuration D and the similarity score S selected in step S704 to the instantiation application / similarity reflection unit 102, and obtains a list of pairs of abstract configurations and similarity scores as an output. The configuration information instantiation unit 101 then adds all pairs included in the list to the search candidate list T. After step S705, the process returns to step S703.

[0147] (Step S706) The configuration information instantiating unit 101 outputs the obtained concrete configuration to the input / output device as the result of the system configuration deriving device 100. The configuration information instantiating unit 101 may output the concrete configuration and the similarity score for the concrete configuration in association with each other. After step S706, the configuration information instantiating unit 101 ends the processing of FIG. 7.

[0148] The above is a description of the operation of configuration information instantiation unit 101.

[0149] Here, the operation of the configuration information concretization unit 101 will be described using an example. Fig. 12 is a diagram showing an example of a tree searched by the configuration information concretization unit 101. In the example of Fig. 12, it is assumed that the concretization application / similarity reflection unit 102 calculates the similarity score of the abstract configuration (after concretization) as a simple sum of the similarity score of the abstract configuration to be concretized and the similarity score of the concrete configuration.

[0150] The boxes with single or double lines and numbers in them shown in Figure 12 represent pairs of abstract constructs and similarity scores added to the search candidate list T. In Figure 12, the abstract constructs are omitted, and the similarity scores are represented by the numbers in the boxes. In the explanation of Figure 12, the pairs of abstract constructs and similarity scores will be referred to as "search states" for convenience.

[0151] A rectangle with a single line frame represents a search state that was not selected in step S704. A rectangle with a double line frame represents a search state that was selected in step S704. In addition, a number surrounded by "<" and ">" is written in the upper right corner of each rectangle with a double line frame. This number indicates how many times the search state represented by that rectangle has been selected in step S704.

[0152] The search state D1200 at the top of FIG. 12 is a search state corresponding to a new requirement given as input, and is added to the search candidate list T in step S702 of FIG.

[0153] The arrows extending from one rectangle to another shown in Fig. 12 can be associated with the loop portion of the flowchart shown in Fig. 7, and represent the processing in step S705 when the search state corresponding to the starting point of the arrow is selected in step S704. Specifically, the arrows indicate that in this case, the configuration information instantiation unit 101 generated the search state corresponding to the end point of the arrow in step S705. In the explanation of Fig. 12, these arrows will also be referred to as "transitions" for convenience.

[0154] Also, a numerical value is assigned to each transition (each arrow). This numerical value indicates the similarity score of the concretization action corresponding to the transition. Here, the concretization application / similarity reflection unit 102 generates exactly one transition (in one-to-one correspondence) corresponding to a concretization action applicable to the starting search state (the abstract configuration it includes). The numerical value assigned to each transition indicates the similarity score of the concretization action associated with this generated transition.

[0155] 12, the configuration information instantiation unit 101 selects the search state with the highest similarity score from among the search states that exist at the stage of executing step S704 in FIG. 7. For example, immediately after the configuration information instantiation unit 101 selects the search state D1200, the similarity scores of the search states added to the search candidate list T are the search state D1201 with a similarity score of 0.8, the search state D1202 with a similarity score of 0.0, and the search state D1203 with a similarity score of 2.0. The configuration information instantiation unit 101 next selects the search state D1203 with the highest similarity from among these search states.

[0156] 12, the similarity score assigned to each exploration state is the sum of the similarity scores of the concretization actions that have been applied up to that point. For example, exploration state D1204 is obtained by applying concretization actions a1205, a1206, and a1207 to exploration state D1200. The exploration state D1204 has a similarity score of 2.2, which is the sum of the similarity score of concretization action a1205 (0.8), the similarity score of concretization action a1206 (0.6), and the similarity score of concretization action a1207 (0.8).

[0157] The above is a description of an example of the operation of configuration information instantiation unit 101.

[0158] 12, the configuration information instantiation unit 101 exhibits a behavior of preferentially proceeding with the search from a search state obtained by applying as many instantiation actions as possible similar to those used in the primary design history. As a result, the concrete configuration obtained as a result of this tree search is designed by the same instantiation procedure as the primary design history, and therefore a result similar to the primary concrete configuration is obtained.

[0159] (Explanation of effect) The configuration information instantiation unit 101 of the system configuration derivation device 100 receives new requirements and information (primary design history) corresponding to the procedure for designing primary requirements similar to the new requirements, and repeatedly instantiates the new requirements by applying instantiation rules. The configuration information instantiation unit 101 performs a tree search on a tree with the new requirements as the root and the abstract configurations as nodes, and finally outputs configuration information (concrete configuration) of a completely instantiated ICT system.

[0160] Furthermore, the configuration information instantiation unit 101 queries the instantiation application / similarity reflection unit 102 at the branch of the tree search, and associates information on a similarity score indicating "how much an instantiation similar to a given primary design history has been applied" with each branch destination.

[0161] Furthermore, the configuration information instantiation unit 101 searches preferentially for items with higher similarity scores.

[0162] The system configuration derivation device 100 can prioritize concretization starting from the abstract configuration that has been concretized similar to the primary design history, and can output configuration information of a fully concretized ICT system that is similar to the ICT system obtained as the primary concretized configuration.

[0163] As described above, the matching coincidence calculation unit 104 calculates a similarity score indicating an evaluation of the similarity between a concretization action included in the design history and a candidate concretization action for a new design. The combination of the configuration information concretization unit 101 and the concretization application / similarity reflection unit 102 selects an abstract configuration based on the similarity score for the abstract configuration, which indicates an evaluation of the similarity between the one or more applications of the concretization action included in the design history and the entire one or more applications of the concretization action from the new configuration to the abstract configuration obtained by applying the concretization action to the new configuration one or more times, calculated based on the similarity score, and then repeatedly applies the concretization rules to the selected abstract configuration.

[0164] According to the system configuration derivation device 100, a concrete configuration that is relatively close to a concrete configuration shown in the design history can be obtained by selecting an abstract configuration based on the similarity to the abstract configuration calculated by the concrete configuration application / similarity reflection unit. According to the system configuration derivation device 100, a concrete configuration that is relatively close to a concrete configuration designed in the past shown in the design history can be obtained, and in this respect, a relatively reliable system can be obtained.

[0165] In addition, the matching agreement calculation unit 104 calculates a similarity score based on whether the concatenation rules applied to the concatenation action included in the design history and the candidate concatenation action included in the repeated application of the concatenation action to the new configuration are the same, and based on the degree of agreement between the system partial configurations to which the concatenation rules are applied.

[0166] According to the system configuration deriving device 100, it is expected that a specific configuration closer to the specific configuration included in the design history can be obtained in that the similarity is evaluated based on both the instantiation rule and the application location.

[0167] In addition, the combination of the configuration information concretization unit 101 and the concretization application / similarity reflection unit 102 manages each of the abstract configurations obtained by applying the concretization rules to the new configuration and the abstract configuration one or more times, linking them to a similarity score with respect to the abstract configuration, and selects the abstract configuration with higher priority when the similarity indicated by the similarity score with respect to the abstract configuration is higher, and repeatedly applies the concretization rules to the selected abstract configuration.

[0168] The system configuration deriving device 100 is expected to obtain a specific configuration that is relatively close to the specific configuration included in the design history.

[0169] <Second embodiment> (Configuration explanation) Fig. 2 is a block diagram showing an example of the configuration of a system configuration deriving device 200 according to the second embodiment. In the configuration shown in Fig. 2, the system configuration deriving device 100 includes a configuration information instantiation unit 201, an instantiation application / similarity reflection unit 102, a similarity calculation unit 103, and a matching coincidence calculation unit 104. Of the units in Fig. 2, parts having similar functions to those in Fig. 1 are given the same reference numerals (102, 103, 104), and detailed description thereof will be omitted here.

[0170] The system configuration deriving device 200 includes a configuration information instantiation unit 201 instead of the configuration information instantiation unit 101 of the system configuration deriving device 100 .

[0171] Except for the above points, the configuration of the system configuration deriving device 200 is similar to the configuration of the system configuration deriving device 100.

[0172] (Explanation of operation) The concrete application / similarity reflection unit 102 , the similarity calculation unit 103 , and the matching coincidence calculation unit 104 of the system configuration deriving device 200 are the same as those of the system configuration deriving device 100 .

[0173] 11 is a flowchart showing an example of the operation of the configuration information instantiation unit 201. In the second embodiment, an example will be described in which the configuration information instantiation unit 201 designs an ICT system. However, the system that the configuration information instantiation unit 201 designs is not limited to a specific one.

[0174] (Step S1100) The configuration information instantiation unit 201 receives as input from an input / output device a configuration requirement D_init expressed in the form of an abstract configuration. After step S1100, the process proceeds to step S1101. The configuration requirement D_init is referred to as a new requirement.

[0175] (Step S1101) The configuration information instantiation unit 201 initializes the search candidate list T to an empty list. After step S1101, the process proceeds to step S1102.

[0176] (Step S1102) The configuration information instantiation unit 201 adds to the search candidate list T a triplet in which the first element is an abstract configuration, the second element is its similarity score value, and the third element is its overall score value.

[0177] The configuration information instantiation unit 201 adds the triplet (D_init, 0, 0) to the search candidate list T. After step S1102, the process proceeds to step S1103.

[0178] (Step S1103) The configuration information instantiation unit 201 determines whether to continue searching the tree. Specifically, the configuration information instantiation unit 201 determines whether a sufficient number of concrete configurations have not been added to the search candidate list T and whether abstract configurations to be searched for have disappeared from the search tree. The threshold value here, "a (sufficient) number," is, for example, a value input through an input / output device, or is specified as a value built into the device from the beginning.

[0179] If the configuration information instantiation unit 201 determines that a sufficient number of specific configurations have not been added to the search candidate list T and that abstract configurations to be searched for have not disappeared from the search tree (step S1103: YES), the process proceeds to step S1104. On the other hand, if the configuration information instantiation unit 101 determines that a sufficient number of specific configurations have been added to the search candidate list T or that abstract configurations to be searched for have disappeared from the search tree (step S1103: NO), the process proceeds to step S1111.

[0180] (Step S1104) The configuration information instantiation unit 201 selects one of the pairs (D, Ss, Si) included in the search candidate list T that satisfies all of the following three conditions (c41), (c42), and (c43).

[0181] (c41) The abstract construction D is not fully instantiated.

[0182] (c42) A set having the same first element as the abstract configuration D has not been previously selected in step S1104.

[0183] (c43) Score Si is the highest overall score of the pairs included in the search candidate list T.

[0184] After step S1104, the process proceeds to step S1105.

[0185] (Step S1105) The configuration information instantiation unit 201 inputs the abstract configuration D and the similarity score Ss selected in step S1104 to the instantiation application / similarity reflection unit 102, and obtains a list Results of pairs of abstract configurations and similarity scores as an output. After step S1105, the process proceeds to step S1106.

[0186] (Step S1106) The configuration information instantiation unit 201 executes a loop L111 for processing each pair (D', Ss') included in the list Results. After step S1106, the process proceeds to step S1107.

[0187] (Step S1107) The configuration information concretization unit 201 calculates a likelihood score Sp' based on the abstract configuration D'. Here, the likelihood score of an abstract configuration is calculated as the likelihood that the concrete configuration can be traced from the abstract configuration. The specific index that the configuration information concretization unit 201 adopts for the likelihood score is not limited to a specific one.

[0188] Regarding the feasibility score of an abstract configuration, for example, the number of abstract components contained in the abstract configuration, that is, the number of elements to be resolved by concretization, N, can be counted, and the reciprocal of that number, 1 / N, can be used as the feasibility score. This is based on the idea that the fewer elements to be resolved by the concretization process, the faster it will be possible to arrive at a concrete configuration.

[0189] Alternatively, the likelihood score of an abstract configuration may be a value obtained by determining the likelihood of the abstract configuration using the method described in Patent Document: Japanese Patent No. 6989014 (or a method similar thereto).

[0190] However, the method for calculating the potential score by the configuration information instantiating unit 201 is not limited to these. After step S1107, the process proceeds to step S1108.

[0191] (Step S1108) The configuration information instantiation unit 201 calculates the overall score Si' based on the likelihood score Sp' and the similarity score Ss' of the abstract configuration D'. The specific method by which the configuration information instantiation unit 201 calculates the overall score Si' is not limited to a specific method.

[0192] For example, in step S1108, the configuration information instantiating unit 201 may calculate the overall score Si' by a simple sum Si' = Sp' + Ss'.

[0193] Alternatively, in step S1108, the configuration information instantiation unit 201 may calculate the overall score Si' by the weighted sum Si' = w1 × Sp' + w2 × Ss'. In addition, the weights w1 and w2 can be set not to real values but to a value ω that represents a kind of "infinity" that is guaranteed to be absolutely large relative to Sp' and Ss'. This makes it possible to realize the behavior that, for example, when w1 = ω, w2 = 1, the magnitude of the value of Si' is determined by the value of Sp' if there is a difference in the magnitude of the value of Sp', and is determined by the value of Ss' if there is no difference.

[0194] However, the method by which the configuration information instantiation unit 201 calculates the overall score is not limited to these. The overall score corresponds to an example of a third evaluation value. The combination of the configuration information instantiation unit 201 and the instantiation application / similarity reflection unit 102 corresponds to an example of an instantiation means. After step S1108, the process proceeds to step S1109.

[0195] (Step S1109) The configuration information instantiation unit 201 adds the triplet (D', Ss', Si') to the search candidate list T. After step S1109, the process proceeds to step S1110.

[0196] (Step S1110) The configuration information instantiation unit 201 performs the termination process of loop L111. Specifically, the configuration information instantiation unit 201 determines whether or not the process of loop L111 has been performed on all pairs (D', Ss') included in the list Results. If it is determined that there are pairs (D', Ss') for which the process of loop L111 has not been performed, the configuration information instantiation unit 201 returns to step S1106 and continues to perform the process of loop L111 on the unprocessed pairs (D', Ss'). On the other hand, if it is determined that the process of loop L111 has been performed on all pairs (D', Ss'), the configuration information instantiation unit 201 terminates loop L111. After the end of loop L111, the process returns to step S1103.

[0197] (Step S1111) The configuration information instantiating unit 201 outputs the obtained specific configuration to the input / output device as the result of the system configuration deriving device 200. The configuration information instantiating unit 201 may be configured to output the specific configuration in association with the overall score, the promising score, or the similarity score for the specific configuration, or a combination of these. After step S1111, the system configuration deriving device 200 ends the processing of FIG. 11.

[0198] For efficient execution of step S1104, the system configuration deriving device 200 may hold a data structure used that manages a list of "abstract configurations included in the search candidate list T that have been previously selected in this step." For example, when the configuration information instantiation unit 201 selects a pair (D, S) in step S1104, it adds D to used. Also, in step S1109, if the first element of the pair to be added is already included in used, the configuration information instantiation unit 201 does not add it to T. This eliminates the need for the configuration information instantiation unit 201 to check condition (c42) in step S1104.

[0199] To efficiently execute step S1104, the search candidate list T can be implemented not as a simple list but as a prioritized queue (a data structure that can efficiently perform a "pop operation" to extract the largest element among the elements it contains). In this case, the order between pairs is determined simply by the size of the similarity score, ignoring the abstract structure. This makes it possible to extract elements that satisfy condition (C43) simply by performing a pop operation on T in step S1104.

[0200] However, the method of executing step S1104 is not limited to this.

[0201] The above is a description of the operation of configuration information instantiation unit 201.

[0202] (Explanation of effect) The configuration information concretization unit 201 differs from the configuration information concretization unit 101 in that it determines the abstract configuration to be concretized with priority not only based on the similarity score but also on a value that takes into account the similarity score and the likelihood score.

[0203] The configuration information instantiation unit 101, which determines the abstract configuration to be instantiated preferentially based on the similarity score, is expected to quickly obtain a configuration close to the primary concrete configuration, as described above. On the other hand, if the primary design history is incorrect as a procedure for instantiating the new requirements due to some reason (caused by the difference between the new requirements and the primary requirements), it may take a considerable number of search steps to arrive at the concrete configuration.

[0204] The configuration information instantiation unit 201 can control the tree search using an index that takes into account not only the similarity score but also the likelihood score, which indicates the ease of completing the instantiation. Therefore, even if the primary design history results in an incorrect procedure for instantiating new requirements, as described above, it is expected that a concrete configuration can be obtained in a relatively short time. In this respect, the system configuration deriving device 200 is expected to be able to reduce the decrease in search efficiency.

[0205] As described above, the combination of the configuration information concretization unit 201 and the concretization application / similarity reflection unit 102 selects an abstract configuration based on not only the similarity score for the abstract configuration but also the likelihood score indicating the likelihood that a concrete configuration can be obtained from the abstract configuration by repeatedly applying the concretization rules to the abstract configuration.

[0206] According to the system configuration deriving device 200, even if the primary design is an incorrect procedure for concretizing new requirements, it is expected that a concrete configuration can be obtained in a relatively short time.

[0207] <Third embodiment> 13 is a diagram illustrating an example of the configuration of a system configuration deriving device according to the third embodiment. In the configuration illustrated in FIG. 13, a system configuration deriving device 610 includes a concretization rule application evaluation unit 611 and a concretization unit 612.

[0208] In this configuration, the concretization rule application evaluation unit 611 calculates a first evaluation value indicating an evaluation of the similarity between a specific concretization rule application included in the design history, which indicates the history, when a concrete configuration, which is a system configuration that does not include abstract elements, is obtained by repeatedly applying concretization rules to an abstract configuration, which is a system configuration that includes abstract elements, and a candidate concretization rule application to be used when obtaining a concrete configuration for a new configuration, which is an abstract configuration that is the target of system design.

[0209] The concretization unit 612 selects a specific abstract configuration from among abstract configurations obtained by applying the concretization rules to the new configuration one or more times based on a second evaluation value that indicates an evaluation of the similarity with the design history for the entire application of the concretization rules from the new configuration to the abstract configuration obtained, the evaluation value being calculated based on the first evaluation value, and repeats application of the concretization rules to the selected specific abstract configuration. The concretization rule application evaluation unit 611 corresponds to an example of a concretization rule application evaluation means. The concretization unit 612 corresponds to an example of a concretization means.

[0210] The system configuration derivation device 610 is expected to obtain a specific configuration that is relatively close to a specific configuration shown in the design history in that it selects an abstract configuration based on the second evaluation value. The system configuration derivation device 610 is expected to obtain a specific configuration that is relatively close to a specific configuration designed in the past that is shown in the design history, and in this respect, it is expected to obtain a relatively reliable system.

[0211] <Fourth embodiment> Fig. 14 is a diagram showing an example of a processing procedure in the system configuration deriving method according to the fourth embodiment. The system configuration deriving method shown in Fig. 14 includes evaluating the application of the concretization rules (step S611) and performing concretization (step S612).

[0212] In evaluating the application of the concretization rules (step S611), the computer repeatedly applies the concretization rules to the abstract configuration, which is a system configuration including abstract elements, to obtain a concrete configuration, which is a system configuration that does not include abstract elements, and calculates a first evaluation value that indicates the evaluation of the similarity between a specific application of the concretization rules included in the design history, which indicates the history, and a candidate application of the concretization rules to be used when obtaining a concrete configuration for a new configuration, which is an abstract configuration that is the target of system design.

[0213] In performing concretization (step S612), the computer selects a specific abstract configuration from among the abstract configurations obtained by applying the concretization rules to the new configuration one or more times, based on a second evaluation value that indicates an evaluation of the similarity with the design history for the entire application of the concretization rules from the new configuration to the abstract configuration, the evaluation value being calculated based on the first evaluation value, and repeats the application of the concretization rules to the selected specific abstract configuration.

[0214] According to the system configuration derivation method shown in Fig. 14, it is expected that a specific configuration relatively close to a specific configuration shown in the design history can be obtained by a processing configuration that selects an abstract configuration based on the second evaluation value. According to the system configuration derivation method shown in Fig. 14, it is expected that a specific configuration relatively close to a specific configuration designed in the past shown in the design history can be obtained, and therefore it is expected that a relatively reliable system can be obtained in this respect.

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

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

[0217] When the system configuration deriving device 100 is implemented in a computer 700, the operations of the configuration information instantiation unit 101, the instantiation application / similarity reflection unit 102, the similarity calculation unit 103, and the matching coincidence calculation unit 104 are stored in the form of a program in an auxiliary storage device 730. The CPU 710 reads the program from the auxiliary storage device 730, loads it into the main storage device 720, and executes the above-mentioned processing in accordance with the program.

[0218] Furthermore, the CPU 710 allocates a storage area in the main storage device 720 for the system configuration deriving device 100 to perform processing in accordance with the program. Communication between the system configuration deriving device 100 and other devices is performed by the interface 740, which has a communication function and operates under the control of the CPU 710. Interaction between the system configuration deriving device 100 and a user is performed by the interface 740, which has an input device and an output device, presenting information to the user via the output device under the control of the CPU 710 and accepting user operations via the input device.

[0219] When the system configuration deriving device 200 is implemented in a computer 700, the operations of the configuration information instantiation unit 201, the instantiation application / similarity reflection unit 102, the similarity calculation unit 103, and the matching coincidence calculation unit 104 are stored in the form of a program in an auxiliary storage device 730. The CPU 710 reads the program from the auxiliary storage device 730, loads it into the main storage device 720, and executes the above-mentioned processing in accordance with the program.

[0220] Furthermore, the CPU 710 allocates a storage area in the main storage device 720 for the system configuration deriving device 200 to perform processing in accordance with the program. Communication between the system configuration deriving device 200 and other devices is performed by the interface 740, which has a communication function and operates under the control of the CPU 710. Interaction between the system configuration deriving device 200 and a user is performed by the interface 740, which has an input device and an output device, presenting information to the user via the output device under the control of the CPU 710 and accepting user operations via the input device.

[0221] When the system configuration derivation device 610 is implemented in the computer 700, the operations of the concretization rule application evaluation unit 611 and the concretization unit 612 are stored in the form of a program in the auxiliary storage device 730. The CPU 710 reads the program from the auxiliary storage device 730, loads it into the main storage device 720, and executes the above-mentioned processing in accordance with the program.

[0222] Furthermore, the CPU 710 allocates a storage area in the main storage device 720 for the system configuration derivation device 610 to perform processing in accordance with the program. Communication between the system configuration derivation device 610 and other devices is performed by an interface 740 having a communication function and operating under the control of the CPU 710. Interaction between the system configuration derivation device 610 and a user is performed by the interface 740 having an input device and an output device, presenting information to the user via the output device under the control of the CPU 710, and accepting user operations via the input device.

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

[0224] Note that the processing of each part may be performed by recording a program for executing all or part of the processing performed by system configuration derivation device 100, system configuration derivation device 200, and system configuration derivation device 610 on a computer-readable recording medium, and loading and executing the program recorded on this recording medium into a computer system. Note that the term "computer system" here includes hardware such as an OS and peripheral devices.

[0225] Furthermore, "computer-readable recording media" refers to portable media such as flexible disks, optical magnetic disks, ROMs (Read Only Memory), and CD-ROMs (Compact Disc Read Only Memory), as well as storage devices such as hard disks built into computer systems. The program may be one that realizes part of the aforementioned functions, or may be one that can realize the aforementioned functions in combination with a program already stored in the computer system.

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

[0227] The present invention may be applied to a system configuration deriving device, a system configuration deriving method, and a recording medium. [Explanation of symbols]

[0228] 100, 200 System configuration derivation device 101, 201 Configuration Information Specifications 102 Reification application / similarity reflection part 103 Similarity calculation unit 104 Matching coincidence calculation unit

Claims

1. application of a specific concretization rule included in a design history indicating a history when a concrete configuration, which is a system configuration that does not include abstract elements, is obtained by repeatedly applying a concretization rule to an abstract configuration, which is a system configuration that includes abstract elements; and When determining the concrete configuration for the new configuration that is the abstract configuration of the system design target, the candidate for applying the concrete rule is a first evaluation value indicating an evaluation of the similarity between the first and second images; the abstract structure obtained by applying the reification rules to the new structure one or more times, a second evaluation value calculated based on the first evaluation value and indicating an evaluation of the degree of similarity between the new configuration and the design history for the entire process of applying the concretization rules one or more times until the abstract configuration is obtained from the new configuration; a concretization means for selecting a specific abstract structure based on the above-mentioned formula and repeating the application of the concretization rules to the selected specific abstract structure; A system configuration deriving device comprising:

2. the concatenation rule application evaluation means calculates the first evaluation value based on whether or not the concatenation rules applied between the concatenation rule application included in the design history and the candidate concatenation rule application included in the repeated application of the concatenation rule to the new configuration are the same, and based on how closely the system partial configurations to which the concatenation rules are applied match. The system configuration deriving device according to claim 1 .

3. the concretization means manages each of the new configuration and the abstract configuration obtained by applying the concretization rule to the abstract configuration one or more times in association with the second evaluation value, selects an abstract configuration with higher priority as the similarity indicated by the second evaluation value becomes higher, and performs system design by repeatedly applying the concretization rule to the selected abstract configuration; 3. The system configuration deriving device according to claim 1.

4. the concretization means selects an abstract configuration based on, in addition to the second evaluation value, a third evaluation value indicating a likelihood that a concrete configuration can be obtained from the abstract configuration by repeatedly applying the concretization rules to the abstract configuration; The system configuration deriving device according to claim 1 .

5. a concretization means for repeatedly applying concretization rules to an input of a new configuration that is a system configuration to be designed and that includes abstract elements, to obtain a concrete configuration that is a system configuration that does not include abstract elements, and for repeatedly applying the concretization rules to an abstract configuration that is a system configuration that includes abstract elements, and for linking the evaluation value of the similarity between the repeated application of the concretization rules to the concrete configuration obtained from the new configuration and outputting the evaluation value of the similarity between the repeated application of the concretization rules to the abstract configuration that is a system configuration that includes abstract elements, and the multiple applications of the concretization rules included in the design history that indicates the history of obtaining the concrete configuration; A system configuration deriving device comprising:

6. The computer application of a specific concretization rule included in a design history indicating a history when a concrete configuration, which is a system configuration that does not include abstract elements, is obtained by repeatedly applying a concretization rule to an abstract configuration, which is a system configuration that includes abstract elements; and When determining the concrete configuration for the new configuration that is the abstract configuration of the system design target, the candidate for applying the concrete rule is calculating a first evaluation value indicating an evaluation of the similarity between the the abstract structure obtained by applying the reification rules to the new structure one or more times, a second evaluation value calculated based on the first evaluation value and indicating an evaluation of the degree of similarity between the new configuration and the design history for the entire process of applying the concretization rules one or more times until the abstract configuration is obtained from the new configuration; and repeating the application of the concretization rules to the selected specific abstract construct. A system configuration deriving method comprising:

7. On the computer, application of a specific concretization rule included in a design history indicating a history when a concrete configuration, which is a system configuration that does not include abstract elements, is obtained by repeatedly applying a concretization rule to an abstract configuration, which is a system configuration that includes abstract elements; and When determining the concrete configuration for the new configuration that is the abstract configuration of the system design target, the candidate for applying the concrete rule is calculating a first evaluation value indicating an evaluation of the similarity between the the abstract structure obtained by applying the reification rules to the new structure one or more times, a second evaluation value calculated based on the first evaluation value and indicating an evaluation of the degree of similarity between the new configuration and the design history for the entire process of applying the concretization rules one or more times until the abstract configuration is obtained from the new configuration; selecting a particular abstract construct based on the given abstract construct and repeating the application of the concretization rules to the selected particular abstract construct; A program to execute.

Images