Device, method and program for automatic system design

Abstract

To provide an automatic system design device for automatically designing a configuration of a system while evaluating performances, etc. to be satisfied by the system when an ICT system is designed.SOLUTION: An automatic system design device includes: a configuration plan creation means for creating a configuration plan of a system embodied from abstract requirements of the system; a view point model creation means for embodying a model related to items that are required for the system in a view point other than the configuration of the system; and an evaluation means for creating information necessary for evaluation of the configuration plan on the basis of the embodied model and, on the basis of the information, evaluating the configuration plan.SELECTED DRAWING: Figure 25

Description

[Technical field]

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

[0002] For industrial development, active use of ICT (Information Communication Technology) systems (hereinafter simply referred to as systems) is necessary. In general, the configuration of a system is complex, and the difficulty of providing or modifying it quickly is an obstacle to utilizing the system. In response to such problems, Patent Document 1 discloses an automatic design technology that generates specific system configuration information based on requirements for the system (requirements related to the configuration). According to the technology disclosed in Patent Document 1, it is possible to generate completely specific configuration information by repeating an operation of gradually specifying an abstract system configuration included in a given requirement. In each specification step, multiple different configuration plans are generated, these configuration plans are evaluated, and the most promising one is selected as the configuration plan to be specified next, thereby devising a way to efficiently derive a higher quality system configuration with fewer reworks.

[0003] To actually introduce a system automatically designed using the technology of Patent Document 1 and the like, it is necessary to evaluate whether the system can withstand use in a real environment from the viewpoints of performance and operation. To properly evaluate the performance, etc. of a system, information from various viewpoints is required, such as the processing flow when the system is running and the work flow to be performed in the event of a failure. However, Patent Document 1 does not disclose a technology for evaluating a configuration proposal in the middle of being realized by using information from such viewpoints. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 2021-135625 Summary of the Invention [Problem to be solved by the invention]

[0005] A technology is provided that automatically designs a system configuration while evaluating a configuration plan in the process of being realized, generated by an automatic design technology, from a viewpoint other than the configuration.

[0006] Therefore, an object of the present disclosure is to provide an automatic system design device, an automatic system design method, and a program that solve the above-mentioned problems. [Means for solving the problem]

[0007] According to one aspect of the present disclosure, an automatic system design apparatus includes a configuration plan generation means for generating a configuration plan of the system that is concretized from abstract requirements of the system, a viewpoint model generation means for concretizing a model related to matters required of the system from viewpoints other than the configuration of the system, and an evaluation means for generating information necessary for evaluating the configuration plan based on the concretized model, and for evaluating the configuration plan based on the information.

[0008] According to one aspect of the present disclosure, a system automatic design method generates a configuration proposal for the system that is concretized from abstract requirements of the system, concretizes a model relating to matters required of the system from viewpoints other than the configuration of the system, generates information necessary for evaluating the configuration proposal based on the concretized model, and evaluates the configuration proposal based on the information.

[0009] According to one aspect of the present disclosure, the program causes a computer to execute a process of generating a configuration proposal for the system that is concretized from the system's abstract requirements, concretizing a model for matters required of the system from perspectives other than the system's configuration, generating information necessary for evaluating the configuration proposal based on the concretized model, and evaluating the configuration proposal based on the information. Effect of the Invention

[0010] According to the automatic system design device, the automatic system design method, and the program disclosed herein, it is possible to automatically design a system configuration while evaluating a configuration proposal in the process of being realized from a viewpoint other than the configuration. [Brief description of the drawings]

[0011] [Figure 1] 1 is a block diagram showing an example of a functional configuration of an automatic design apparatus; [Diagram 2] FIG. 11 is a diagram illustrating an example of configuration information. [Diagram 3] FIG. 11 is a diagram showing an example of type information of a component part. [Figure 4] FIG. 13 is a diagram showing another example of type information of a component part. [Diagram 5] FIG. 13 is a diagram illustrating an example of relationship type information. [Figure 6] FIG. 13 is a diagram illustrating an example of a visual representation of relationship type information. [Figure 7] FIG. 1 is a diagram illustrating an example of a design process of an automatic design. [Figure 8] FIG. 1 is a diagram illustrating an example of system requirements. [Figure 9] FIG. 1 is a diagram illustrating an example of a Process Facet. [Figure 10] FIG. 13 is a diagram illustrating an example of a type definition of a Process Facet. [Figure 11] FIG. 13 is a diagram illustrating another example of a type definition of a Process Facet. [Figure 12] FIG. 13 is a diagram illustrating an example of a derived type of a type definition of a Process Facet. [Figure 13] FIG. 13 is a diagram showing an example of a process for realizing a Process Facet. [Figure 14] FIG. 2 is an explanatory diagram showing an example of an Operational Facet. [Figure 15] FIG. 13 is a diagram showing an example of a type definition of an Operational Facet. [Figure 16]FIG. 13 is a diagram showing another example of a type definition of an Operational Facet. [Figure 17] FIG. 13 is a diagram showing an example of an instantiation process of an Operational Facet. [Figure 18] FIG. 1 is a diagram illustrating an example of a Security Facet. [Figure 19] FIG. 13 is a diagram showing an example of a type definition of a Security Facet. [Figure 20] FIG. 13 is a diagram showing another example of a type definition of a Security Facet. [Figure 21] FIG. 13 is a diagram showing an example of a process for realizing a Security Facet. [Figure 22] 1 is a flowchart showing an example of an outline of an automatic design operation; [Diagram 23] 1 is a first flowchart showing an example of a detailed operation of the automatic design device. [Figure 24] 13 is a second flowchart showing an example of a detailed operation of the automatic design apparatus. [Diagram 25] FIG. 2 is a block diagram showing an example of a minimum configuration of a system automatic design apparatus. [Figure 26] 1 is a flowchart of a method for automatically designing a system having a minimum configuration. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, the automatic design process of a system according to each embodiment of the present invention will be described with reference to the drawings. In the drawings used in the following description, the configuration of parts that are not related to the present invention may be omitted or not illustrated.

[0013] <Embodiment> (composition) FIG. 1 is a block diagram illustrating an example of a functional configuration of an automatic design apparatus. As shown in FIG. 1, the automated design device 100 in the first embodiment includes a configuration instantiation unit 110, a viewpoint model instantiation unit 120, and a model information storage unit . The configuration instantiation unit 110 receives information on system requirements from an external input / output device (not shown), converts this information into concrete configuration information, and outputs it. The viewpoint model instantiation unit 120 operates in cooperation with the configuration instantiation unit 110 to instantiate a "viewpoint model," which is information other than the configuration that is necessary for evaluating a configuration proposal in the process of being instantiated, and to generate an evaluation formula that is necessary for evaluating the configuration proposal. The model information storage unit 130 records information required for generating configuration plans and viewpoint models.

[0014] The configuration instantiation unit 110 includes a configuration search unit 111 , a configuration plan generation unit 112 , and a configuration plan evaluation unit 113 . The configuration search unit 111 cooperates with the configuration plan generation unit 112 and the configuration plan evaluation unit 113 to search for and output a completely specific system configuration that satisfies given system requirements. The configuration plan generation unit 112 concretizes the configuration plan provided by the configuration search unit 111 in one step by using the model type information recorded in the model information storage unit 130, thereby generating multiple configuration plans and outputting them to the configuration search unit 111 and the viewpoint model generation unit 121. The configuration plan evaluation unit 113 evaluates the configuration plan from various viewpoints, including whether or not the configuration plan provided from the configuration search unit 111 satisfies the conditions specified in the system requirements, and outputs the configuration plan and a constraint function including the constraint conditions assigned to the configuration plan to the viewpoint model evaluation unit 122.

[0015] The viewpoint model instantiation unit 120 includes a viewpoint model generation unit 121 and a viewpoint model evaluation unit 122 . The viewpoint model generation unit 121 updates the viewpoint model linked to each configuration plan generated by the configuration plan generation unit 112 in accordance with the contents of the partial configuration into which the configuration plan is newly realized. The viewpoint model evaluation unit 122 uses information on the viewpoint model linked to a given configuration plan to generate an evaluation formula for evaluating the configuration plan.

[0016] The configuration search unit 111 is communicatively connected to the configuration plan generation unit 112 and the configuration plan evaluation unit 113. The configuration plan generation unit 112 is further communicatively connected to the viewpoint model generation unit 121 and the model information storage unit 130. The configuration plan evaluation unit 113 is further communicatively connected to the viewpoint model evaluation unit 122 and the model information storage unit 130. The viewpoint model generation unit 121 is further communicatively connected to the model information storage unit 130. The viewpoint model evaluation unit 122 is further communicatively connected to the model information storage unit 130.

[0017] Next, data used by the automatic design device 100 of this embodiment will be described. First, data used in a general automatic design device that does not use a viewpoint model will be described, and then data in three types of viewpoint models will be described in order. First, configuration information, which is the most basic data structure in the present invention, will be described.

[0018] FIG. 2 shows an example of configuration information in this embodiment. A visual representation of the configuration information is shown in a diagram 201 on the left side of FIG. 2, and a textual representation is shown in a diagram 202 on the right side. The configuration information is expressed in the form of a graph consisting of nodes and edges. The nodes represent the parts that make up the system, and are called component parts. The edges represent the relationships between the component parts, and are called relationships. The component parts and relationships are collectively called components. Each component has at least the ID of the component and type information that indicates the type of the component. It may also have additional information such as properties.

[0019] In the visual representation in Figure 2, circles represent components (nodes), and arrows connecting the circles represent relationships (edges). The labels attached to the components indicate their type and ID, with the type name on the left side of the colon (":") and the ID on the right side. Either the type name or the ID, or both, may be omitted as appropriate. An icon corresponding to the type type is displayed inside the component circle as appropriate.

[0020] In the text representation of Figure 2, the information is written in YAML format. The configuration information can have a "configuration" and a "constraint". An example of a "constraint" will be described later. The IDs of the components contained in the "configuration" are listed, and information about each component is described as an attribute of each ID. The "type" is the type of each component. The "relationship" is the relationship from each component to other components. The relationship is expressed as an array, and the "type" and "destination" are described as attributes of each relationship. The type of the relationship is made up of a pair of a base type, which is the type of the relationship itself, and a double-ended type, which is the type of the components at both ends. For example, if HostedOn(WebApp, APServer) is written, HostedOn is the base type, and WebApp and APServer are the double-ended types. The ID of the component that is the other end of the relationship is specified in the "destination" in the reference format. The reference format is a string with "$" at the beginning of the id string, which indicates that it is referring to another element. The configuration information shown in Figure 2 includes four components: "app", "aps", "rdb", and "sv1". Taking "app" as an example, it is a WebApp type, and has a HostedOn(WebApp, APServer) type relationship with "aps" as the connection destination, and an AccessDB(WebApp, RDB) type relationship with "rdb" as the connection destination.

[0021] The system requirements, the configuration plan during the design, and the specific system configuration, which correspond to the input information, intermediate generation information, and output information of the automated design device 100 of this embodiment, are all expressed by configuration information. Next, the type information of each component will be described.

[0022] The type information of a component has attributes such as type name, inheritance source, concreteness flag, properties, and expected configuration. Each component type can inherit other component types by specifying the name of the inheritance source. By inheriting other component types, a component type can inherit the information of the inheritance source and extend or overwrite it by adding only the parts that differ from the type information of the inheritance source. An inherited type is called a derived type or extended type, and is considered to be a type of the inheritance source type. The concreteness flag is a flag that indicates whether the type is a concrete type. The properties are information that indicate the attribute values ​​that the type can hold. The expected configuration is the surrounding configuration that must be satisfied for a component part having a certain type to establish concrete configuration information. For example, a WebApp type component must be connected to an APServer type component through a HostedOn(WebApp, APServer) type relationship, and an RDB type component must be connected to an AccessDB(WebApp, AccessDB) type relationship, and the APServer type component must be connected to the RDB type component through a ConnTo(APServer, RDB) type relationship. Such conditions that a component requires of its surrounding components are specified as expected configurations. Although one component can include multiple expected configurations, this specification does not deal with examples of type information that includes two or more expected configurations. As will be described later, the concreteness flag and expected configuration are used as termination conditions for the search process of automatic design. In other words, for all components included in a certain configuration, the fact that their types are concrete types and that the expected configurations are satisfied forms part of the termination conditions for the search process of automatic design.

[0023] An example of type information of a component part is shown in Fig. 3. A visual representation of type information of the component part is shown in a left diagram 301 in Fig. 3, and a textual representation is shown in a right diagram 302. In the following diagrams, a visual representation and a textual representation may be shown side by side, or only one of the representations may be shown, but an explanation as to whether the depicted representation is a visual representation or a textual representation and a reference number for each diagram will be omitted.

[0024] The visual representation in FIG. 3 represents one expected configuration. The expected configuration is represented as a partial configuration including the component part type itself that desires it. In the visual representation of type information of a component in this specification, the component itself is represented as a double-lined component. As mentioned above, a single component can include multiple expected configurations, but since this specification does not deal with examples of type information that includes two or more expected configurations, the visual representation of the type information is simply represented as one expected configuration. The types at both ends of the relationship type may be appropriately omitted.

[0025] The text representation in Figure 3 includes "inheritance source," "concreteness flag," "properties," and "expected configuration." Since one component can contain multiple expected configurations, the name of the expected configuration is specified and information about that expected configuration is described as its attribute. In the example text representation in Figure 3, "base" is the name of the expected configuration. The content of the expected configuration is the configuration information itself. However, the id of the defining type itself is described as $self, a special reference name.

[0026] Note that when the types at both ends of a relationship type are abbreviated with "_", the types of the components at both ends specified in the definition information will be used. For example, in the text representation in Figure 3, the first relationship that $self has, HostedOn(_, _), is described as having $self as the source and $aps as the destination. Since $self is the WebApp type itself and the type of $aps is described as APServer, the formal type name of this relationship will be interpreted as HostedOn(WebApp, APServer).

[0027] Another example of type information of a component is shown in Fig. 4. In the example in Fig. 4, APserver type, RDB type, Server type, SmallServer type and LargeServer type which inherit the Server type, Switch type, NormalSwitch type and SecureSwitch type which inherit the Switch type are defined.

[0028] Figure 5 shows an example of relationship type information. The contents of relationship type information are generally similar to the contents of component type information. However, in the expected configuration of a relationship type, in addition to $self, $src and $dest are used as special reference names. $src represents the component that is the connection source of the relationship type, and $dest represents the component that is the connection destination.

[0029] An example of a visual representation of relationship type information is shown in Fig. 6. In the example of Fig. 6, visual representations of a relationship type of ConnTo(AppServer, RDB) type and a relationship type of ConnTo(Server, Server) type are illustrated.

[0030] FIG. 7 shows an example of a design process by the automatic design device of the present invention. A series of configuration information from (a) to (g) in FIG. 7 shows how the configuration information starts from the system requirements, and the contents are gradually concretized, and finally reaches completely concrete configuration information. That is, (a) is an example of a system requirement, and expresses a user's request to build a WebApp. A configuration plan (b) is obtained by applying the expected configuration base of the WebApp type to the component of the WebApp type in (a). Similarly, a configuration plan (c) is obtained by applying the expected configuration base of the APServer type to the component of the APServer type in (b). By the same process, (d), (e), and (f) are obtained. At the stage of (f), all the expected configurations are completed, but since the Server type and the Switch type are not concrete types, a step is taken to replace these types with any of the extended types that inherit them, and replace them with concrete types. By proceeding with such steps three times, an example (g) is generated.

[0031] In FIG. 7, the design process is illustrated as a one-way process, but in reality, the design process can branch into many branches because the expected configuration can have multiple candidates, the extended type that inherits an abstract type can have multiple candidates, and which component is to be concretized can be selected arbitrarily. The automated design device 100 of this embodiment derives specific configuration information by exploratory tracing such branchable processes. Above, data used in a general automated design device that does not use a viewpoint model has been described. In the following, data in the automated design device 100 that uses a viewpoint model in this embodiment will be described.

[0032] FIG. 8 is an example of a sample system requirement for explaining automatic design using a viewpoint model in this embodiment. The system requirement in FIG. 8 describes a configuration and constraint conditions. The constraint conditions express the conditions that the configuration should satisfy, and satisfaction of the conditions described in the constraint conditions is one of the conditions for terminating the search process of the automatic design of the present invention. The system requirement in FIG. 8 describes only one WebApp type component in the configuration section, and the content is the same as the system requirement exemplified in FIG. 7(a), but three further conditional expressions are added to the constraint conditions.

[0033] Here, the first conditional expression, "TAT(component: $app, service: execute) <= 200", requires that when this is called to execute a service named "execute" that belongs to $app, a response must be returned within 200 milliseconds. Here, TAT is an abbreviation for Turn Around Time, and means the time it takes from calling a function to receiving a response. The "TAT(component: $app, service: execute)" part is a function that returns the Turn Around Time when a service named "execute" that belongs to $app is executed, and it specifies that the value must be 200 or less as a condition.

[0034] The second conditional expression, "OPT(Component: $app, Operation: [S, R]) <= 60", requires that when an operation that changes the state of $app to S and then to R, in other words a restart, is performed, it must be completed within 60 seconds. Here, OPT is an abbreviation for OPeration Time, and refers to the time required to execute an operation in a system. The "OPT(Component: $app, Operation: [S, R])" part is a function that returns the time required to perform an operation that changes the state of a running $app to S, then R, and specifies that the value must be 60 or less as a condition. The strings S and R that represent the state mean that S is in the Stop state and R is in the Run state, respectively. In other words, this operation represents the operation of restarting the app.

[0035] The third conditional expression, "Secure() == true", requires that the system is secure. As will be explained later, secure here means that there are no actionable threats. The "Secure()" part is a function that returns true if there are no actionable threats in the configuration and returns false if there are, and specifies that the value must be true as a condition.

[0036] In the above examples of constraint conditions, TAT(), OPT(), and Secure() represent examples of functions that generate and return expressions and values ​​based on configuration information and information on a viewpoint model described later. Hereinafter, these functions are also called TAT functions, OPT functions, and Secure functions. In addition, such functions are called constraint functions in this specification. The specific operation of each constraint function will be described later.

[0037] These functions are implemented in advance and recorded so as to be callable. These functions are merely examples for explaining the embodiments of the present invention, and any constraint function different from these may be used instead of or in addition to these examples.

[0038] In order to calculate the Turn Around Time, the TAT function may use information on a process flow consisting of a chain of processes executed by each component in addition to the configuration information. For this purpose, the automated design device 100 of this embodiment instantiates information on the viewpoint of the process flow in parallel with the configuration information. The information on the viewpoint of the process flow generated here is hereinafter referred to as Process Facet.

[0039] In order to calculate Operation Time, the OPT function may use information on state transitions occurring in each component in addition to the configuration information. For this purpose, the automated design device 100 of this embodiment instantiates information on the viewpoint of state transitions in parallel with the configuration information. The information on the viewpoint of state transitions generated here is hereinafter referred to as Operational Facet.

[0040] The Secure function may use information about threats inherent in each component in addition to the configuration information to calculate a true / false value that indicates whether or not the component is secure. To achieve this, the automated design system of the present invention instantiates information from the perspective of threats in parallel with the configuration information. The information from the perspective of threats generated here is hereinafter referred to as a Security Facet.

[0041] Below, we will explain examples of Process Facet, Operational Facet, and Security Facet, as well as the additional information associated with the type required for generation and how they are instantiated. We will also show examples of how to make desirable design decisions using the information from these Facets.

[0042] An example of a Process Facet is shown in Fig. 9. A Process Facet is a model that represents a series of processing flows to execute a certain service and the resources used to execute the service. A Process Facet consists of information on the source of a request, a process, the order relationship between processes, resources, and the use relationship between the process and the resources. In Fig. 9, a circle with a face indicates the source of a request. The source of a request may have an attribute value of the arrival rate (i.e., the frequency of calling the service). A circle with a "p" and a number inside indicates a process (i.e., a computation process). The arrows between processes indicate the order relationship of execution between the processes, and the processes are executed in the order from the base of the arrow to the head of the arrow. The dotted frame indicates a resource, and when a process is inside the frame, it means that the process uses the resource. In other words, the Process Facet in Fig. 9 represents a service that is composed of a processing flow consisting of 17 processes across three resources. As will be described later, this example represents a specific Process Facet when the execute service of a WebApp is called.

[0043] Figures 10 and 11 show examples of Process Facet type definitions. The example in Figure 10 shows the definition of a Process Facet linked to the WebApp type component shown in Figure 3. In the type definition of a Process Facet, the elements "type with this Facet" and "process_facet" are written first. "Type with this Facet" is the name of the component type to which this Facet is linked. In the example in Figure 10, WebApp is specified as the "type with this Facet". Detailed content is written in the "process_facet" element. A Process Facet may be defined for each expected configuration, and for that purpose, the name of the expected configuration held by the component type to which this Facet is linked is written first. In the example in Figure 10, "base" is the name of the expected configuration. A Process Facet mainly consists of information on services and resources. Service definitions are listed in "services", and resource definitions are listed in "resources". In the example in Figure 10, services such as execute and _acceptRequest are defined, and a resource named cpu_of_webApp is defined.

[0044] There are two types of services: composites and primitives. A composite is a group of services that contains other services, while a primitive is a processing entity that does not contain other services. A service always has a "composite" attribute, and if the value of "composite" is true, it also contains a "process" attribute, while if the value of "composite" is false, it also contains "resource" information. The "process" definition of a composite service describes an array of information about the invocation of other services.

[0045] In the example in Figure 10, the _callDb service is a composite. Here, we take the first three of the process as an example. The first one states _makeDbRequest. This is a service that this type itself holds, and the information for invoking such a service is simply the name of the service. The second one states $aps.sendDbRequest. This means that the service named sendDbRequest held by the component referenced by $aps is invoked. Here, $aps is a component defined in the expected configuration named base of the WebApp type that is linked to this Process Facet (see Figure 3). The components listed in the expected configuration are guaranteed to exist in the configuration proposal being designed, so the service can be invoked. In this way, in the definition of a Facet, it is possible to reference the components in the expected configuration to which the Facet is linked. The third one states $($aps,$rdb).send(10). The $($aps,$rdb) part represents a reference to the relationship that connects the components of $aps and $rdb. Moreover, send is the name of the service, and the part "(10)" after it indicates the value of the argument passed to the service side when calling the service. In this example, send is a service that sends data, and the argument indicates that the amount of data to be communicated is 10 MB. The send service is defined in the Conn(APServer, RDB) type Process Facet shown in FIG. 11. The send service holds an "argument" item, and the first element of the item is specified as "name" being data_amount. In this way, a service may have an "argument" attribute, and in this specification, a name is specified for each argument element to reference this. The description "@data_amount" in the same send service definition means that the value of the argument mentioned above is referenced.Here, the value of data_amount is passed as an argument to another service, and is ultimately referenced as the value of the amount of data to be sent by a resource named channel used by a Switch-type send service.

[0046] In the example in Figure 10, the _getRequestData service is a primitive. A primitive service defines information about the resources to be used and the amount of usage. The _getRequestData service indicates that the CPU is used as a resource, and it is instructed to allocate the resource referenced by $cpu_of_webApp as the actual CPU. The basic processing time is the processing time when this process is executed on a CPU with standard performance, and 10 milliseconds is specified here. In the example in Figure 11, the Switch-type send service holds a channel as a resource, and data volume is recorded here instead of the basic processing time. The value of the attribute described in the resource definition is determined by the type of the referenced resource. As will be described later, cpu refers to a CPU-type resource, and channel refers to a CommunicationChannel-type resource.

[0047] Examples of resource entity definitions are defined in the Server and Switch type Process Facets in Figure 11. The cpu defined in the Server type Process Facet is specified as a resource of type CPU, with a "relative speed" attribute of 1. On the other hand, the channel defined in the Switch type Process Facet is specified as a resource of type CommunicationChannel, with a "transfer volume per second" of 100. Relative speed and transfer volume per second are attributes that indicate the performance of each resource. Here, relative speed indicates how many times the processing speed is compared to a CPU with standard performance. Transfer volume per second indicates how many MB of data can be transferred per second. All resources defined in Process Facets other than the Server and Switch types are defined as references to these resources. For example, in an RDB type Process Facet, a resource is specified as a direct reference by writing something like $sv.cpu in the "allocation destination".

[0048] In the visual representation in Figure 10, the dotted rectangles with rounded corners represent composite services, and the dotted circles represent processes that are not visible because they reference other component services.

[0049] Figure 12 shows an example of a derived type of a Process Facet type definition. In the example in Figure 12, Process Facets of SmallServer type and LargeServer type, which are derived types of Server type, are defined. In these types, the value of the relative speed of the CPU resource is overwritten, thereby expressing the performance difference between the CPUs of the SmallServer type and LargeServer type. In the example in Figure 12, the relative speed of the CPU of the SmallServer type is specified as 1, and the relative speed of the CPU of the LargeServer type is specified as 5.

[0050] FIG. 13 shows an example of the process of instantiating a Process Facet. Each time a configuration plan is instantiated by applying an expected configuration, a Process Facet is instantiated in stages by adding type definition information for the Process Facet linked to the applied expected configuration. The symbols (a) to (g) in FIG. 13 correspond to (a) to (g) in FIG. 7. In (b), the base expected configuration of $app is deployed, so the Process Facet of the WebApp linked to it is deployed around $app. In (c), the base expected configuration of $aps is deployed, so the Process Facet of the APServer linked to it is deployed around $aps. Note that resource information is omitted in FIG. 13 to avoid complication of expression, but resource information is also deployed as necessary.

[0051] In this way, the type of Facet information is defined in correspondence with the type definition of the configuration information, and an entity is generated in correspondence with the entity of the configuration information. By using the Process Facet information, for example, it is possible to evaluate the Turn Around Time of a specific service in a certain configuration proposal. The time required to execute each process can be calculated from the amount of processing required and the performance of the resources used, and the Turn Around Time of a service (i.e., the time required for the entire execution) can be calculated by adding up the processing times of the related processes.

[0052] In the example of Fig. 9, first, the cpu in (a) is the cpu resource held by the Server connected to the APServer via HostedOn, and since SmallServer is selected in the example of Fig. 7(g), the relative speed is 1 as shown in Fig. 12. Next, the cpu in (b) is the cpu resource held by the Server connected to the RDB via HostedOn, and since LargeServer is selected in the example of Fig. 7(g), the relative speed is 5 as shown in Fig. 12. The channel in (c) is the channel resource held by the Switch that connects the above-mentioned Servers, and since no overwrite is defined in the derived class for Process Facet in the Switch, the transfer volume per second is 100 as shown in the definition of the Switch in Fig. 11.

[0053] In Figure 9, there are 12 processes using (a), each with a base processing time of 10 and a relative CPU speed of 1, so the total time required to execute this part is 10 * 12 / 1 = 120. There are two processes using (b) with a base processing time of 10 and one with a base processing time of 200, and the relative CPU speed is 5, so the total time required to execute this part is (10 + 200) / 5 = 44. There are two processes using (c) with a data amount of 10 and one with a data amount of 100, and the channel's transfer rate per second is 100, so the total time required to execute this part is (10 + 100) / 100 = 1.1. In other words, the total is 120 + 44 + 1.1 = 165.1.

[0054] In other words, the TAT function part of the constraint "TAT(element: $app, service: execute) <= 200" specified in the system requirements in Figure 8 is 165.1, which is smaller than 200, so we can see that this constraint is satisfied.

[0055] If, in the design process shown in Figure 7, SmallServer is selected as the specific type of Server connected to the RDB by HostedOn, the total processing time of the processes using the resources in Figure 9(b) will be 210, and the total processing time will be 331.1, so it can be seen that the above constraints are no longer satisfied.

[0056] In the process of automatic design, if the constraints of the generated configuration plan are not satisfied, such a configuration plan is rejected and other configuration plans are searched for, resulting in a high-quality design that satisfies the constraints. In other words, high-quality designs can be derived by defining and evaluating advanced constraints using the TAT function.

[0057] Each constraint condition is evaluated each time a configuration plan is generated, so that configuration plans that are confirmed not to satisfy the conditions can be discarded and pruned early. Pruning is expected to have the effect of omitting unnecessary searches and speeding up design. Since a configuration plan in the middle of concrete processing has some undefined or abstract parts, the Process Facets associated with the configuration plan are also incomplete information, but evaluation may be performed within the range that can be interpreted. In a configuration plan generated during design in the automatic design device of the present invention, the number of components basically increases gradually, so the return value of the TAT function is basically expected to increase monotonically. Therefore, when a condition using the TAT function is no longer satisfied, it is considered appropriate to determine that a configuration plan that satisfies the above condition cannot be obtained by further concrete processing, and to perform pruning. For example, in the example shown in FIG. 7 and FIG. 13, when SmallServer is selected as the concrete type of Server connected to RDB by HostedOn, the above condition is no longer satisfied, so that further consideration of concrete processing may be omitted.

[0058] It is considered that by using the information of the Process Facet, it is possible to evaluate not only the TAT but also the Throughput in a similar manner. In this way, multiple constraint functions using one Facet may be defined.

[0059] Figure 14 shows an example of an Operational Facet. An Operational Facet is a model that represents the state transition systems of each component that makes up a system and the dependencies between the state transition systems. From the information in an Operational Facet, it is possible to derive a series of tasks required to transition the target system from one state to another. An Operational Facet consists of the state transition systems of each component and information on the dependencies between the state transition systems. One state transition system contains information on multiple states that a component can take and the state transitions that can be performed. The dependencies between state transition systems are represented by the specific states of one or more other components that must be satisfied in order for a component to execute a certain state transition.

[0060] For example, when an RDB is hosted on a server, the server must be running before the RDB can be started. To express such a condition, the server and the RDB can be assumed to be either in a stopped state or in a running state, and both can transition between the stopped and running states. The transition of the RDB from a stopped state to a running state can be defined as having a dependency on the running state of the server.

[0061] The Operational Facet in Figure 14 visually represents a collection of multiple state transition systems that have dependencies on each other, as described above. In Figure 14, rectangles represent the state transition systems of each component. The ellipses within the rectangles represent states, and the solid arrows connecting the ellipses represent state transitions. Dotted arrows represent dependencies, and are drawn from small circles placed on the state transitions to the states of other components. The ID of each state transition system is written in reference format near each state transition system. Figure 14 shows the Operational Facet corresponding to the configuration information in Figure 7 (g).

[0062] Examples of operational facet type definitions are shown in Figure 15 and Figure 16. Figure 15 shows both a visual and textual representation of the operational facet type definition associated with the WebApp type, while Figure 16 shows the textual representation of operational facet type definitions for several other types.

[0063] As with Process Facet, the type definition of an Operational Facet first describes the elements “Type with this Facet” and “operational_facet”. In the example in Figure 15, WebApp is specified as the “Type with this Facet”. Detailed information is described in the “operational_facet” element. An Operational Facet may also be defined for each expected configuration, and for this purpose, the name of the expected configuration held by the component type to which this Facet is linked is first described. In the examples in Figures 15 and 16, “base” is the name of the expected configuration. The definition of one Operational Facet corresponding to one expected configuration is expressed by a set of “State” definitions. “Transition” and “Dependent Transition” are described for each state. In the “Transition” element, the transition destination states are first listed, and since each transition destination state corresponds to one state transition, the attributes of each state transition are described inside it. The transition time and the array of dependent states are described as attributes of each state transition. The dependent transition is the array of state transitions of other components that have a dependency on the state described in this element. Each element contains a component, a source state, and a destination state. The component contains the ID of the component that has a state transition, and the source and destination states contain the names of the states.

[0064] In the example of Fig. 15, S and R are defined as states. State S describes a state transition with R as the transition destination, and the state transition from S to R has a transition time of 10, and $aps.R, $($aps,$rdb).R, and $rdb.R are specified as dependency destination states. Here, for example, $aps.R means state R of the component indicated by $aps.

[0065] Figure 17 shows an example of the instantiation process of an Operational Facet. Like Process Facets, Operational Facets are also instantiated step by step by adding the type definition information of the Operational Facet linked to the applied expected configuration each time a configuration plan is instantiated by applying the expected configuration. The symbols (a) to (g) in Figure 17 correspond to (a) to (g) in Figure 7. In (b), the base expected configuration of $app is deployed, so the Operational Facet of the WebApp linked to it is deployed around $app. In (c), the base expected configuration of $aps is deployed, so the Operational Facet of the APServer linked to it is deployed around $aps.

[0066] By using the information of Operational Facet, the time required for a specific task in a certain configuration plan, i.e., Operation Time, can be evaluated as the time required for transition from a specific state to another specific state. For example, JP 2015-215885 A describes a method for calculating possible state transition procedures from a current state to a specific target state in the above-mentioned state transition system. The time required for each state transition included in the obtained state transition procedures is obtained from the state transition times described in the type definition of Operational Facet, and these are added together to calculate Operation Time.

[0067] Figure 18 shows an example of a Security Facet. A Security Facet is a model that represents the threats inherent in each component that makes up a system and the dependencies between threats. From the information in the Security Facet, it is possible to derive feasible attack paths for the target system, making it possible to evaluate whether the system is secure or not. A Security Facet is made up of information on the threats inherent in each component and the dependencies between threats. A threat represents computer processing or attacker work that can harm the system's users or administrators, such as eavesdropping on communications. A dependency between threats is a relationship in which the execution of a certain threat requires the execution of another specific threat beforehand.

[0068] The Security Facet in Figure 18 is a visual representation of a collection of multiple threats that have dependencies on one another. In Figure 18, a virus icon represents one threat, and arrows drawn from one threat to another represent the dependencies between the threats. Next to each threat is a string consisting of the ID of the component that contains the threat and the name of the threat, connected by a dot (".") Figure 18 shows the Security Facet that corresponds to the configuration information in Figure 7 (g).

[0069] Examples of Security Facet type definitions are shown in Figure 19 and Figure 20. Figure 19 shows both a visual and textual representation of the Security Facet type definition associated with the ConnTo(APServer, RDB) type. Figure 20 shows the textual representation of the Security Facet type definitions for several other types.

[0070] As with Process Facets and Operational Facets, the type definition for a Security Facet first describes the "type with this Facet" and the "security_facet" elements. In the example in Figure 19, ConnTo(APServer, RDB) is specified for the "type with this Facet". Detailed information is described in the "security_facet" element.

[0071] A security facet may also be defined for each expected configuration, and for this purpose, the name of the expected configuration held by the component type to which this facet is linked is written first. In the examples of Figures 19 and 20, "base" is the name of the expected configuration. A definition of one security facet corresponding to one expected configuration is expressed by a set of "threat" definitions. First, the name of the threat is specified, and information on each threat is written as its attributes. The information on each threat includes "type", "feasibility", and "threats that depend on it". "Type" is the type of the threat, "feasibility" is a boolean value that indicates whether this threat can be executed, and "threats that depend on it" represent other threats that should be executed before this threat is executed. In the visual representation in Figure 19, the dotted virus icon represents a threat whose content is not clear because it refers to other components.

[0072] In Figure 20, two Security Facets are defined that are linked to the NormalSwitch type and the SecureSwitch type, which are derived types of the Switch type. The feasibility of sniffing in the Security Facet of the NormalSwitch type is set to true, while the feasibility of sniffing in the Security Facet of the SecureSwitch type is set to false.

[0073] Figure 21 shows an example of the Security Facet instantiation process. Like Process Facets and Operational Facets, Security Facets are instantiated step by step by adding the type definition information of the Security Facet linked to the applied expected configuration each time a configuration plan is instantiated by applying the expected configuration. The symbols (e) to (g) in Figure 21 correspond to (e) to (g) in Figure 7.

[0074] By using the information of the Security Facet, an attack path can be generated for a certain configuration plan, and this allows evaluation of whether the configuration plan is secure or not. An attack path is a route consisting of a chain of executable threats and dependencies, and refers to a path that starts with a threat that does not have a particular dependency. In the Security Facet shown in (g) of FIG. 21, there is an attack path that starts with the threat of sniffing on the Switch. Since there is an attack path, the configuration plan corresponding to this Security Facet is evaluated as not secure. Here, when the configuration plans shown in (f) to (g) of FIG. 7 are generated, if SecureSwitch is selected instead of NormalSwitch when the specific type of the Switch-type component is selected, the feasibility of sniffing will be false as shown in FIG. 20, so the attack path shown in (g) of FIG. 21 will not be established, and the configuration plan is evaluated as secure. As a result, the automatic design device of the present invention can selectively derive a secure system configuration by specifying a constraint using a Secure function as a system requirement as shown in FIG. 8.

[0075] (operation) Next, the operation of the automatic design device 100 of this embodiment will be described. FIG. 22 is a flowchart showing the operation of the automatic design system of this embodiment. First, an overall outline of the operation will be described. First, the configuration search unit 111 accepts input of system requirements from a user terminal (not shown) via an input / output unit (not shown) (S101). Next, the configuration search unit 111 and the like repeatedly execute a process (S102 to S108) for gradually concretizing the system requirements, and output the completely concretized system configuration to the user terminal via the input / output unit (not shown) (S109).

[0076] More specifically, the configuration plan generating unit 112 generates a specific configuration plan (S102), and judges whether one or more configuration plans have been generated (S103). If one or more configuration plans have been generated (S103; Y), the configuration plan evaluating unit 113 evaluates the configuration plan (S104). The configuration plan evaluating unit 113 evaluates whether the specific configuration plan generated by the configuration plan generating unit 112 satisfies the system requirements, and returns the evaluation result to the configuration searching unit 111. Next, the configuration searching unit 111 judges whether one or more configuration plans that have been evaluated to satisfy the system requirements and constraint conditions have been generated (S105). If one or more configuration plans have been generated (S105; Y), proceed to S106. If one or more configuration plans have not been generated (S103; or S105; N), proceed to S107.

[0077] The configuration search unit 111 and the like first perform the above-mentioned one-stage concretization (S102 to S105) as a stepwise concretization, and check whether a concrete configuration plan is included in the obtained multiple configuration plans (S106). A configuration plan is judged to be concrete when all included components are complete and all constraint conditions are satisfied. Each component is judged to be complete depending on whether the concretization flag of its type is true and the expected configuration is satisfied. Information on the component type required to judge whether a configuration plan is complete is stored in the model information storage unit 130, and the configuration plan generation unit 112 and the configuration plan evaluation unit 113 of the configuration concretization unit 110 read it from the model information storage unit 130. If a concrete configuration plan is included (S106; Y), the configuration search unit 111 outputs the concrete configuration plan as the system configuration of the design result (S109). If no concrete configuration plan is included (S106; No), the configuration search unit 111 checks whether any other abstract configuration plans remain among the configuration plans pending concretization (S107). If any abstract configuration plans remain (Yes in S107), the configuration search unit 111 appropriately selects the next configuration plan to be concretized (S108) and performs one stage of concretization again. If no configuration plans remain (S107; No), the configuration search unit 111 cannot consider any more designs and ends in failure (S110).

[0078] To explain the process of the first stage of concretization in more detail, first, the configuration plan generating unit 112 applies an applicable expected configuration to the system requirement input in S101 or the configuration plan selected to be concretized next in S108, or generates multiple configuration plans by replacing an abstract type with its derived type (S102). Information on the component type required for generating the configuration plan is stored in the model information storage unit 130, and the configuration plan generating unit 112 reads it from the model information storage unit 130. After that, the configuration search unit 111 checks whether one or more configuration plans have actually been generated (S103). If no configuration plan has been generated (S103; N), the first stage of concretization has failed, and the configuration plan generating unit 112 proceeds to concretization of other configuration plans among the pending configuration plans (S107). When one or more configuration plans are generated (S103; Y), the configuration search unit 111 passes each of the generated configuration plans to the configuration plan evaluation unit 113 and receives the evaluation results (S104). Information on component types (particularly information on constraint conditions) required for evaluating the configuration plans is stored in the model information storage unit 130, and the configuration plan evaluation unit 113 reads this information from the model information storage unit 130. The configuration search unit 111 selects the next configuration plan to be realized based on the evaluation results given to each configuration plan here (S108).

[0079] FIG. 23 is a flowchart showing the detailed operation of the automatic design apparatus of this embodiment. In FIG. 23, the details of generating a configuration plan (S102) will be particularly described together with the operation of the viewpoint model instantiation unit 120. In generating a configuration plan (S102), the configuration instantiation unit 110 first extracts incomplete components from the configuration plan to be instantiated (S102a). Next, the configuration instantiation unit 110 applies either type replacement or application of expected configuration to each incomplete component extracted, thereby generating a configuration plan that is one step more concrete (S102b). Type replacement is possible when the type of the target component is an abstract type, and by replacing it with each derived type, different configuration plans are generated as many times as the number of types of derived types. Application of expected configuration is possible when the configuration surrounding the target component does not satisfy the expected configuration, and by applying each expected configuration, different configuration plans are generated as many times as the number of types of expected configurations. Next, the configuration instantiation unit 110 transmits information on the configuration plan generated by applying the expected configuration and identification information (a pair of the ID of the component and the name of the expected configuration) of the applied expected configuration to the viewpoint model generation unit 121, and obtains various Facet information from the viewpoint model generation unit 121 and assigns it to the configuration plan (S102c). When the viewpoint model generation unit 121 receives an identifier of a configuration proposal and an expected configuration from the configuration concretization unit 110, it retrieves corresponding type information from the model information storage unit 130 using the type name of the component specified by the identifier, retrieves information on various Facets linked to the expected configuration named by the identifier, updates the information on each Facet according to the application method for each type of Facet, and returns this to the configuration concretization unit 110.

[0080] FIG. 24 is a flowchart showing the detailed operation of the automatic design apparatus of this embodiment. In FIG. 24, the details of the evaluation of the configuration plan (S104) will be described together with the operation of the viewpoint model instantiation unit 120. In the evaluation of the configuration plan (S104), the configuration plan evaluation unit 113 first transmits the configuration plan and the constraint function including the constraint condition assigned to the configuration plan to the viewpoint model evaluation unit 122, and obtains the evaluation value of the function from the viewpoint model evaluation unit 122 (S104a). The viewpoint model evaluation unit 122 receives the evaluation value of each constraint function from the configuration plan evaluation unit 113, replaces the function part of the constraint condition with the evaluation value, thereby updating the formula to an evaluable content, and evaluates whether all the constraint conditions are satisfied (S104b). For example, as described with reference to Figs. 9 to 11, the viewpoint model evaluation unit 122 generates an evaluation formula for calculating the processing time, calculates the processing time (TAT), and evaluates whether the calculated processing time satisfies the constraint condition (for example, 200 or less) using the evaluation value. The configuration plan evaluation unit 113 finally evaluates whether the configuration plan is effective based on information such as whether the constraint condition is satisfied (S104c). In making the final evaluation, the configuration plan may be evaluated using another method. For example, a configuration plan may be evaluated based on statistical judgments based on evaluations of past design results using AI (artificial intelligence) or the like.

[0081] (effect) For example, to properly evaluate the performance and availability of a system, information from various viewpoints, such as the process flow at run time and the work flow to be executed in the event of a failure, is required. More specifically, for example, to accurately estimate the time it takes from calling the function of the system to obtaining the output result (hereinafter referred to as TAT, for short, Turn Around Time), calculations such as calculating the time it takes to execute each process block while considering the way in which each process block included in the process flow is connected and the amount of resources allocated to each process block, and adding them up are required. Or, to accurately estimate the time it takes to recover the system when a failure occurs (hereinafter referred to as RTO, for short, Recovery Time Objective), calculations such as deriving the contents of a series of failure recovery operations based on information such as the operations for each component affected by the failure, the dependencies between the operations, and the time it takes for each operation, and adding up the time it takes for each operation included in the series of operations are required. Therefore, with general techniques, it is difficult to accurately evaluate the validity of a configuration proposal in the middle of being realized according to general standards such as performance and availability, and it is difficult to derive a high-quality design. On the other hand, if one tries to introduce information from various perspectives as described above, the number and types of components included in the configuration proposal will increase significantly, making the content complicated and difficult for people to understand. In addition, the search process at the design stage will become more complicated, making it take an enormous amount of time to derive a specific system configuration.

[0082] In contrast, according to the present embodiment, the definition of a model from a viewpoint other than the configuration is received as additional information for a type definition, which is information describing the properties of each type of component from the viewpoint of the configuration, and is described separately while being associated with the configuration. Then, during the design process, the configuration information and the model for each viewpoint are recorded separately so as to be easily distinguishable, and the model for each viewpoint is specified in parallel with the configuration information being specified. In addition, in the calculation process of the evaluation information of the configuration plan, the evaluation value is calculated by referring to the model from the other viewpoint as necessary. As a result, information from various viewpoints required for the evaluation of the system configuration plan (e.g., evaluation of requirements related to TAT, RTO, security, etc.) can be defined in an easily understandable manner, and can be introduced in a format that allows the automatic design device 100 to efficiently execute the search process, so that a high-quality system configuration can be efficiently automatically designed in a short time. For example, by introducing information from various viewpoints other than the configuration information so that it can be referred to during the automatic design process, a highly accurate evaluation of the configuration plan can be realized, and the quality of the design can be improved. In addition, by introducing information separately so that it is not necessary to refer to information other than the configuration information when generating a configuration plan, it is possible to avoid complication of the search process at the design stage and to avoid an increase in the time required to derive a specific system configuration. Also, type definition information can be defined separately for each viewpoint, which avoids the content becoming complicated and makes it easy for people to understand. In the above embodiment, three models, a processing process, an operation for operation, and a threat attack process, are given as examples of the viewpoint model, but the viewpoint model is not limited to these and may be a model for evaluating the system from other viewpoints. In addition, the contents of each viewpoint model such as the processing process are not limited to those exemplified in the above embodiment (e.g., FIG. 9, FIG. 14, FIG. 18).

[0083] (Minimum configuration) FIG. 25 is a block diagram showing an example of a minimum configuration of an automatic system design apparatus. The automatic system design device 800 includes a configuration plan generating means 810, a viewpoint model generating means 820, and an evaluation means 830. The configuration plan generating means 810 generates a configuration plan for the system that is realized from the requirements of the system. The viewpoint model generating means 820 realizes a model relating to matters required of the system from a viewpoint other than the configuration of the system. The evaluation means 830 generates information necessary for evaluating the configuration plan based on the instantiated model, and evaluates the configuration plan based on the information.

[0084] The configuration plan generating means 810 can be realized, for example, by using the function of the configuration concretization unit 110. The viewpoint model generating means 820 can be realized by using the function of the viewpoint model generating unit 121. The evaluation means 830 can be realized, for example, by using the function of the viewpoint model evaluation unit 122. The automatic system design device 800 is a device that automatically designs a specific system configuration that satisfies given system requirements, and in particular, while introducing information from various viewpoints other than the configuration, such as a process flow at run time and an operation to be performed in the event of a failure, which is necessary to accurately evaluate the configuration plan of the system being designed, the automatic system design of a high-quality system configuration is realized by preventing the input of the information and the search process at the time of design from becoming complicated.

[0085] FIG. 26 is a flowchart of a method for automatically designing a system having a minimum configuration. The configuration plan generating means 810 generates a configuration plan for the system that is realized from the system requirements (S801). The viewpoint model generating means 820 realizes a model related to items required for the system from viewpoints other than the configuration of the system (S802). The evaluation means 830 generates information required for evaluating the configuration plan based on the realized model, and evaluates the configuration plan based on the information (S803).

[0086] It should be noted that the automated design device 100 and the automated system design device 800 in the above-described embodiments may be partially realized by a computer. In this case, a program for realizing the functions may be recorded in a computer-readable recording medium, and the program recorded in the recording medium may be read into a computer system and executed. Note that the "computer system" referred to here is a computer system built into the automated design device 100 and the automated system design device 800, and includes an OS (Operating System) and hardware such as peripheral devices.

[0087] In addition, "computer-readable recording medium" refers to portable media such as flexible disks, optical magnetic disks, ROMs, and CD-ROMs, and storage devices such as hard disks built into computer systems. Furthermore, "computer-readable recording medium" may also include devices that dynamically hold a program for a short period of time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, and devices that hold a program for a certain period of time, such as volatile memory inside a computer system that serves as a server or client in such cases. Furthermore, the above program may be one that realizes part of the above-mentioned functions, or may be one that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

[0088] In addition, the automatic design device 100 and the automatic system design device 800 in the above-mentioned embodiments may be partly or entirely realized as an integrated circuit such as an LSI (Large Scale Integration). Each functional unit of the automatic design device 100 and the automatic system design device 800 may be individually implemented as a processor, or partly or entirely integrated into a processor. The integrated circuit implementation method is not limited to LSI, and may be implemented by a dedicated circuit or a general-purpose processor. In addition, when an integrated circuit implementation technology that replaces LSI appears due to the advancement of semiconductor technology, an integrated circuit based on that technology may be used.

[0089] Although one embodiment of the present invention has been described in detail above with reference to the drawings, the specific configuration is not limited to the above, and various design changes and the like can be made within the scope of the gist of the present invention. In addition, one aspect of the present invention can be modified in various ways within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present invention. In addition, configurations in which elements described in the above embodiments and modified examples are replaced with elements that have the same effect are also included.

[0090] As described above, several embodiments according to the present disclosure have been described, but all of these embodiments are presented as examples and are not intended to limit the scope of the invention. These embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the gist of the invention. These embodiments and their modifications are included in the scope of the invention and its equivalents as described in the claims, as well as in the scope and gist of the invention.

[0091] <Additional Notes> The automatic system design apparatus, the automatic system design method, and the program according to the embodiments can be understood, for example, as follows.

[0092] (1) A first aspect of an automatic system design apparatus includes a configuration plan generation means for generating a configuration plan for a system that is concretized from abstract requirements of the system, a viewpoint model generation means for concretizing a model related to matters required of the system from viewpoints other than the configuration of the system, and an evaluation means for generating information necessary for evaluating the configuration plan based on the concretized model, and for evaluating the configuration plan based on the information.

[0093] (2) An automatic system design apparatus according to a second aspect is the automatic system design apparatus according to (1), further comprising a search means for searching for a configuration plan of the system that is highly evaluated and completely realized by repeating the generation of a configuration plan by the configuration plan generation means, the concretization of the model by the viewpoint model generation means, and the evaluation of the configuration plan by the evaluation means.

[0094] (3) An automatic system design device according to a third aspect is the automatic system design device according to any one of (1) to (2), in which the model is a model of a processing process executed by the system.

[0095] (4) An automatic system design device according to a fourth aspect is the automatic system design device according to any one of (1) to (3), wherein the model is a model of a work process for operating the system.

[0096] (5) A fifth aspect of the automatic system design apparatus is the automatic system design apparatus according to any one of (1) to (4), in which the model is a model of an attack process that poses a threat to the system.

[0097] (6) A sixth aspect of the automatic system design device is an automatic system design device according to any one of (1) to (5), wherein the matters required of the system from a viewpoint other than the configuration of the system are any one of matters related to the processing time of the system, matters related to the time required to recover the system, and matters related to the security of the system.

[0098] (7) A seventh aspect of an automatic system design method is a method for automatically designing a system, in which a computer generates a configuration plan for the system that is concretized from abstract requirements of the system, concretizes a model for matters required of the system from viewpoints other than the configuration of the system, generates information necessary for evaluating the configuration plan based on the concretized model, and evaluates the configuration plan based on the information.

[0099] (8) A program according to an eighth aspect causes a computer to execute the following processes: generate a configuration plan for the system that is concretized from abstract requirements of the system; concretize a model for matters required of the system from viewpoints other than the configuration of the system; generate information necessary for evaluating the configuration plan based on the concretized model; and evaluate the configuration plan based on the information. [Explanation of symbols]

[0100] 100...Automatic design equipment 110. Configuration Specifications Department 111...Configuration search section 112...Configuration plan generation unit 113. Configuration Proposal Evaluation Section 120... Viewpoint model realization unit 121... Viewpoint model generation unit 122... Viewpoint model evaluation unit 130...Model information storage unit 800···System automatic design device 810...Configuration plan generation means 820....Viewpoint model generation means 830...Evaluation means

Claims

1. A configuration plan generating means for generating a configuration plan of the system that is embodied from an abstract requirement of the system; A viewpoint model generating means for realizing a model relating to matters required for the system from a viewpoint other than the configuration of the system; an evaluation means for generating information necessary for evaluating the configuration plan based on the embodied model, and evaluating the configuration plan based on the information; An automatic system design device comprising:

2. a search means for searching for a configuration plan of the system that is highly evaluated and completely realized by repeating the steps of generating a configuration plan by the configuration plan generating means, instantiating the model by the viewpoint model generating means, and evaluating the configuration plan by the evaluation means; The system automatic design apparatus according to claim 1 , further comprising:

3. the model is a model of a process executed by the system; 3. The system automatic design apparatus according to claim 1.

4. The model is a model of a work process for operating the system.

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

5. The model is a model of an attack process that threatens the system.

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

6. The requirements for the system from the viewpoint other than the configuration of the system are any one of the following: a processing time of the system, a time required for recovery of the system, and a security of the system.

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

7. The computer generating a configuration plan for the system that is materialized from the abstract requirements of the system; Concretely defining a model for requirements for the system other than the system configuration; generating information necessary for evaluating the configuration plan based on the model that has been embodied, and evaluating the configuration plan based on the information; System automation design method.

8. On the computer, generating a configuration plan for the system that is materialized from the abstract requirements of the system; Concretely defining a model for requirements for the system other than the system configuration; generating information necessary for evaluating the configuration plan based on the model that has been embodied, and evaluating the configuration plan based on the information; A program that executes the following.

Images