Information processing apparatus, information processing method, and program
The information processing device ensures appropriate modeling in ICT system design by verifying self-containedness and self-solvability of components, addressing inefficiencies and failures in existing automated design technologies.
Patent Information
- Application Number
- JP2024112881
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-07-12
- Publication Date
- 2026-01-23
AI Technical Summary
Existing automated design technologies for ICT systems struggle with appropriately modeling the design target, leading to potential design failures and inefficiencies due to unclear definitions of appropriate modeling.
An information processing device and method that determines whether a computer system model satisfies component specifications through self-containment checks, ensuring all components can be concretized into a specific configuration by verifying self-containedness and self-solvability of components and their expected peripheral configurations.
Enables accurate determination of appropriate modeling in ICT system design, ensuring the design process reaches a concrete configuration and avoids design failures by clarifying necessary conditions for successful modeling.
Smart Images

Figure 2026011902000001_ABST
Abstract
Description
[Technical Field]
[0001] This disclosure relates to a technology for automated design of ICT (Information and Communication Technology) systems and machine learning of such systems. In particular, this disclosure relates to a technology for automating the design of ICT systems by having a computer calculate the scope of the ICT system design as a state transition space based on design requirements and component definitions that are declaratively defined by humans, and then having AI (Artificial Intelligence) explore that state transition space. [Background technology]
[0002] Patent Document 1 discloses a technology for automatically designing an ICT system that meets customer requirements. The technology disclosed in Patent Document 1 gradually concretizes the abstract elements included in the customer's abstract system requirements, and derives a system configuration that is detailed to a deployable level.
[0003] In the technology disclosed in Patent Document 1, the customer's abstract "system requirements" (hereinafter simply referred to as "requirements"), a "system configuration plan" (hereinafter simply referred to as "configuration plan") in the process of specifying the system requirements, and a "specific system configuration" (hereinafter simply referred to as "specific configuration") in which the system requirements have been completely specified are represented by data with a graph structure as shown in FIG. 25. FIG. 25 is a diagram showing an example of a graph structure showing the requirements of an ICT system. FIG. 26 is a diagram explaining the components included in the requirements of the ICT system shown in FIG. 25.
[0004] Furthermore, the three components - system requirements, proposed system configuration, and specific system configuration - are collectively called the "system configuration" (hereinafter simply referred to as "configuration"). The nodes and edges that make up the graph structure of the system configuration are called components. Nodes refer to the individual components (e.g., servers, routers, etc.) included in the system configuration, and edges refer to the relationships between components (e.g., network connections, etc.).
[0005] The concrete implementation is then achieved by rewriting the graph. There may be multiple graph rewriting methods for the system requirements and system configuration proposals. Depending on how the graph is rewritten and the order in which the rewriting is performed, the design branches and the concrete configuration of the derived system changes. As a result, differences arise in the design, and in some cases, the design may fail (it may not satisfy the input system requirements).
[0006] Therefore, in order to perform efficient design using the technology disclosed in Patent Document 1, it is important to decide which of the multiple graph rewriting techniques described above to use and whether the order in which the rewriting should be performed is appropriate.
[0007] Furthermore, Non-Patent Document 1 discloses a technology that uses reinforcement learning to determine the appropriateness of the content of the implementation of the above-mentioned system and the order in which the implementation is carried out. Generally, in reinforcement learning technology, a variety of trials are repeatedly performed for problems in which the results obtained vary depending on the content of actions and the order of actions, and the system learns to determine the appropriateness of the content of actions and the order of actions based on the rewards obtained according to the results of the trials. Reinforcement learning technology has a proven track record in, for example, learning AI for playing Go. [Prior art documents] [Patent documents]
[0008] [Patent Document 1] Patent No. 7036205 [Non-patent literature]
[0009] [Non-Patent Document 1] Takashi Maruyama et al.: "Improving the Efficiency of Search by Reinforcement Learning in Search-Based Network Design Methods," IEICE Technical Report, vol. 118, no. 483, ICM2018-71, pp. 123-128, March 2019. Summary of the Invention [Problem to be solved by the invention]
[0010] The most important point in the automated design of ICT systems is that the design target is modeled appropriately. However, in the field of automated design of ICT systems, although the grammatical specifications of models have been defined, what constitutes appropriate modeling has not been clearly stated. As a result, there have been cases where the design target was not modeled appropriately, and as a result, the design target could not be designed appropriately.
[0011] Applying the technology disclosed in Non-Patent Document 1 to the technology disclosed in Patent Document 1 mentioned above makes it possible to achieve efficient design of ICT systems, but it is difficult to determine whether the design object has been appropriately modeled using only these two technologies.
[0012] One example of a purpose of the present disclosure is to be able to determine whether a design object is adequately modeled. [Means for solving the problem]
[0013] In order to achieve the above object, an information processing device according to one aspect of the present disclosure includes: a specification determination unit that determines whether a model of a computer system satisfies specifications for components included in the definition based on the self-containment of the components; an output unit that outputs a result of a determination as to whether the model of the computer system satisfies the specification; The present invention is characterized in that it is provided with:
[0014] In order to achieve the above object, an information processing method according to one aspect of the present disclosure includes: a specification determination step of determining whether the model of the computer system satisfies the specifications for the components included in the definition based on the self-containment of the components; an output step of outputting a result of the determination as to whether the model of the computer system satisfies the specification; The present invention is characterized by having the following:
[0015] Furthermore, in order to achieve the above object, a program according to one aspect of the present disclosure includes: On the computer, a specification determination step of determining whether the model of the computer system satisfies the specifications for the components included in the definition based on the self-containment of the components; an output step of outputting a result of the determination as to whether the model of the computer system satisfies the specification; The method is characterized in that: [Effects of the Invention]
[0016] As described above, according to the present disclosure, it is possible to determine whether or not a design object has been appropriately modeled. [Brief explanation of the drawings]
[0017] [Figure 1] FIG. 1 is a diagram showing how a configuration is generated by repeated branching in a search process for the automated design of an ICT system. [Figure 2] FIG. 2 is a diagram showing an example in which information included in the configuration of an ICT system is expressed in a graph structure. [Figure 3] FIG. 3 is a diagram showing an example in which information included in the configuration of an ICT system is expressed in text. [Figure 4] FIG. 4 is a diagram showing an example of a format for defining the types of components that make up an ICT system. [Figure 5] FIG. 5 is a diagram showing an example of component type definition information representing the definition of the type of a component in accordance with the format shown in FIG. [Figure 6] FIG. 6 is a diagram showing a first example of an expected peripheral configuration for explaining self-containment. [Figure 7] FIG. 7 is a diagram showing a second example of an expected peripheral configuration for explaining self-containment. [Figure 8] FIG. 8 is a diagram showing an example of an expected peripheral configuration for explaining the concept follow. [Figure 9] FIG. 9 is a diagram illustrating a configuration of an example of an information processing device. [Figure 10] FIG. 10 is a flow diagram showing an example of the overall operation of the information processing device. [Figure 11] FIG. 11 is a flow diagram for explaining in more detail step S12 of detecting a specification violation shown in FIG. [Figure 12] FIG. 12 is a flow diagram illustrating in more detail step S113 of checking the self-containedness of component types shown in FIG. [Figure 13] FIG. 13 is a flow diagram illustrating step S123 for checking the self-containment of the expected peripheral configuration shown in FIG. [Figure 14] FIG. 14 is a flow diagram illustrating step S133 for checking whether the components shown in FIG. 13 are followed by the expected peripheral configuration. [Figure 15] FIG. 15 is a flow diagram illustrating step S143 for checking whether the expected peripheral configuration shown in FIG. 14 is followed by another expected peripheral configuration. [Figure 16] FIG. 16 is a flow diagram illustrating step S151 of collecting the prerequisite components that cannot be solved by themselves shown in FIG. [Figure 17] FIG. 17 is a flowchart illustrating step S163 for checking the self-solvability of the prerequisite components shown in FIG. [Figure 18] FIG. 18 is a flow diagram illustrating step S173 for checking whether the prerequisite constituent shown in FIG. 17 is generated from another prerequisite constituent. [Figure 19] FIG. 19 is a flow diagram illustrating step S183 for checking whether the prerequisite components shown in FIG. 18 can be generated from the expected peripheral configuration. [Figure 20]FIG. 20 is a flow diagram illustrating step S152 shown in FIG. 15, in which it is confirmed whether all the prerequisite components that are not self-solvable can be generated from the expected peripheral configuration. [Figure 21] FIG. 21 is a flowchart showing another example of the overall operation of the information processing device. [Figure 22] FIG. 22 is a flow diagram illustrating step S22 of detecting specification violations in the ICT system model. [Figure 23] FIG. 23 is a flow diagram illustrating step S213 of checking the self-containedness of each expected peripheral configuration of a component type. [Figure 24] FIG. 24 is a block diagram illustrating an example of a computer that realizes an information processing device. [Figure 25] FIG. 25 is a diagram illustrating an example of a graph structure indicating requirements of an ICT system. [Figure 26] FIG. 26 is a diagram illustrating components included in the requirements of the ICT system shown in FIG. DETAILED DESCRIPTION OF THE INVENTION
[0018] (Concepts of the present disclosure) As described above, the objective of the present disclosure is to enable determination of whether a design object has been appropriately modeled in the automated design of an ICT system model, thereby facilitating modeling of the design object. Furthermore, the objective of the present disclosure can be divided into the following objectives 1 to 3, and in other words, the objectives will be ultimately achieved by achieving objectives 1 to 3. Objective 1: "Ensure that the design exploration process based on the requirements specification can reach a concrete configuration." Objective 2: "To clarify the conditions that a model must satisfy in order for the search process to reach a specific configuration." Objective 3: "Provide a means to verify whether a given model satisfies the above conditions" The following describes the above three objectives in detail.
[0019] [Explanation of Objective 1] We will explain in detail Objective 1, "Ensuring that the search process for a design based on the concretization of requirements can reach a concrete configuration." First, we will explain what a search process is, and then we will explain what it means for a search process to be able to reach a concrete configuration.
[0020] [Explanation of the search process] The search process in the automated design of ICT systems is a process that aims to discover the concrete system configuration by repeatedly concretizing the proposed system configuration and backtracking. The concretization process consists of two types of processes: one that concretizes each component itself into a concrete component for all components included in the system configuration, and one that concretizes the system configuration so that it satisfies the expected peripheral configuration defined for each component. The expected peripheral configuration represents the configuration that must be satisfied around a component in order for that component to be realized, and the existence of the expected peripheral configuration indicates that the component is realized. These two types of concretization and backtracking are repeatedly executed, and the design is determined to be complete when a concrete configuration is discovered.
[0021] [Explanation of how the search process can reach a specific configuration] The fact that a search process can reach a specific configuration means that a specific configuration that satisfies the requirements exists, that the specific configuration can be reached by repeating the search, and that the components and the requirements that combine them are defined in such a way. On the other hand, depending on how the components and requirements are defined, there may be cases where the specific configuration cannot be reached no matter how many times the search is repeated, and in such cases, the model is inappropriate. The present disclosure aims to avoid such cases.
[0022] Furthermore, if the requirements for combining components are defined so that a specific configuration can be reached, the design of the ICT system can be completed. However, in reality, it is desirable that the requirements be defined so that a specific configuration can be reached even if the design is based only on the individual components included in the requirements and their expected peripheral configurations.
[0023] The reason for this is as follows: First, when creating requirements by combining components, it is necessary to consider whether it is possible to concretize all of them, including the components that will be added to the system configuration as the concretization proceeds, to arrive at the concrete configuration. However, if each component is defined so that the concrete configuration can be reached using only itself and its expected peripheral configuration, the above difficult consideration becomes unnecessary.
[0024] [Explanation of Objective 2] Objective 2, "To clarify the conditions that a model must satisfy in order for the search process to arrive at a specific configuration," will be explained in detail. First, we will explain what a model is, and then we will explain the conditions for arriving at a specific configuration and the concepts necessary to define the conditions. Note that these conditions and concepts are based on new findings obtained by the inventors of this application in the process of studying this disclosure.
[0025] [Model Description] The model used in the automated design of ICT systems defines the abstract elements contained in the requirements, the concrete elements contained in the concrete configuration, and the method for concretizing from the former to the latter. This model will be explained in more detail using Figure 1. Figure 1 shows how configurations are generated by repeated branching in the search process of the automated design of ICT systems.
[0026] In Figure 1, each of (a) to (g) represents a configuration. Each configuration contains graph-structured information that indicates the configuration of the ICT system itself. Of the information contained in the configuration, the nodes indicated by circles represent component parts, and the edges indicated by arrows represent the relationships between the component parts. The node icons represent the type of component part, and their correspondence is as shown in the legend in Figure 1. The character string attached to the component part represents the identifier of that component part. As mentioned above, the components and the relationships between them are collectively called components.
[0027] The information included in the configuration is not limited to the example expressed by a graph structure as shown in FIG. 1, and may be expressed in text. The method of expression in text is not particularly limited as long as it can be converted into a unique diagram. For example, the graph structure shown in FIG. 2 may be expressed by text as shown in FIG. 3. FIG. 2 is a diagram showing an example in which information included in the configuration of an ICT system is expressed in a graph structure. FIG. 3 is a diagram showing an example in which information included in the configuration of an ICT system is expressed in text.
[0028] In the example of Figure 2, the names attached to the nodes and edges indicate the component and relationship type names, respectively. In other words, the graph structure shown in Figure 2 is a configuration that indicates that a specific application App_Y can communicate with another application App, and uses nodes and edges to express that "App and App_Y are connected by the Conn_to relationship."
[0029] In the example of Figure 3, the configuration is defined in text format and includes a list of components and the relationships between them. Each component is defined by an identifier that identifies it and its type. A relationship between components is defined by an identifier that identifies the relationship, the type of the relationship, and the identifiers of the source and destination components of the relationship. The symbol "$" shown in Figure 3 indicates a reference to the identifier of the variable name attached to it. If the definition of an identifier for a component is unnecessary because it is not referenced in other definitions of the component, the definition of the identifier may be omitted.
[0030] Next, we will explain how to define the types of components included in the system configuration. The format for defining the types of components is shown in Figure 4. Figure 4 is a diagram showing an example of a format for defining the types of components that make up an ICT system.
[0031] The type of a component specifies the name of the component type (type name), the inheritance source, the specificity, and the expected peripheral configuration. The expected peripheral configuration is the configuration that a component of that type is expected to exist in its surroundings in order to exist within the system configuration. The type of a component is also called a "component type." Data that defines a component type is also called "component type definition information."
[0032] The inheritance source indicates the type of other components that the component type inherits from; if not specified, it means that nothing is inherited. Components can inherit the expected peripheral configuration information of the inheritance source type by inheriting the types of other components, and relationships can inherit the types of other relationships. The components of a type that inherits a certain type are both the inheritance type and the inheritance source type. For example, if an OS type and a Windows type that inherits from the OS type are defined, the components of the Windows type are both the Windows type and the OS type.
[0033] Concreteness is a flag that indicates whether the component type itself is an abstract component type that can be further concretized, or a concrete component type that cannot be further concretized. If concreteness is True, it indicates a concrete component type. If concreteness is False, it indicates an abstract component type that can be concretized into other component types that inherit from it.
[0034] The expected peripheral configuration represents the configuration that must be met in the surroundings of a component of that type in order for that component to be valid. The existence of the configuration described in the expected peripheral configuration indicates that the component of that type is valid. For example, since it is considered that an OS that hosts an application is essential for its existence, the expected peripheral configuration of an App-type component that represents an application describes a configuration in which the App itself is hosted by some OS-type component. Multiple expected peripheral configurations can be defined for a single component. If even one expected peripheral configuration of a component exists in the configuration, the expected peripheral configuration of that component is said to be satisfied.
[0035] For each expected peripheral configuration, the name of the expected peripheral configuration, as well as the prerequisite configuration and required configuration can be described. The prerequisite configuration is a configuration that is assumed to be specified one step further so that the required configuration, described below, is included in the system configuration. Only if the system configuration currently being designed includes the configuration described in the prerequisite configuration, will the system configuration be specified one step further so that the required configuration, described below, is included. The required configuration represents the configuration that will be included in the system configuration as a result of specifying the system configuration one step further (this also includes cases where the configuration is already included in the system configuration before it is specified). Note that components included in the prerequisite configuration are also called "prerequisite components," and components included in the required configuration are called "required components."
[0036] An example of a component type definition is shown in Figure 5. Figure 5 is a diagram showing an example of component type definition information that represents the definition of a component type according to the guidelines shown in Figure 4. The example in Figure 5 shows an example of a definition of OS, which is an abstract component type representing an operating system, and examples of definitions of Windows and Ubuntu, which are types that inherit from OS. Since an OS must be hosted on some kind of machine in order to exist, it is defined as an expected peripheral configuration that a Hosted_on relationship must exist between the OS itself and the machine. In addition, components of Windows and Ubuntu, which are specific OSes, are defined as types that inherit from OS.
[0037] [Explanation of the conditions for arriving at a concrete configuration and the concepts necessary for its definition] Here, we explain the conditions for the design of an ICT system model to reach a specific configuration, and the concepts necessary for its definition, and provide specific examples as needed. ·Self-sufficiency Follow ·Self-solving possibility ·Generating components
[0038] [Explanation of the conditions for reaching a specific configuration] In automated design using a model defined in the above-mentioned way, the condition for the search process to arrive at a specific configuration is that "all components included in the definition of the ICT system model are self-contained." Therefore, the model specification is defined as "all components included in the definition of the ICT system model must be self-contained." The definition of a component being self-contained is given below.
[0039] [Self-contained explanation] This section explains the property of self-containment of a component. The conceptual meaning of self-containment of a component is the property that a concrete configuration can be reached when designed using only the component and its expected surrounding configuration. A component with such a property is expressed as a "self-contained component" or "this component is self-contained." Conversely, a component that cannot reach a concrete configuration when designed using only the component and its expected surrounding configuration is expressed as a "non-self-contained component" or "this component is not self-contained." The condition for a component to be self-contained is that "all expected surrounding configurations of the component type are self-contained." The definition of self-contained expected surrounding configuration is described below.
[0040] This section explains the self-contained nature of the expected peripheral configuration. The conceptual meaning of the self-contained nature of the expected peripheral configuration is the property that a specific configuration can be reached when designed using only the components that have that expected peripheral configuration and the configuration described in that expected peripheral configuration. An expected peripheral configuration with such a property is expressed as a "self-contained expected peripheral configuration" or "this expected peripheral configuration is self-contained."
[0041] Conversely, an expected peripheral configuration that cannot reach a specific configuration when designed using only the components that have that expected peripheral configuration and the configuration described in that expected peripheral configuration is expressed as an "expected peripheral configuration that is not self-contained" or "this expected peripheral configuration is not self-contained." The condition for an expected peripheral configuration to be self-contained is that "the expected peripheral configuration follows all the components it contains." The definition of an expected peripheral configuration following a component will be explained later.
[0042] Here, an example of a component that is not self-contained will be shown using FIG. 6. FIG. 6 is a diagram showing a first example of an expected peripheral configuration for explaining self-containedness. In FIG. 6, a double line indicates that the expected peripheral configuration is of the type of the component indicated by the double line. Therefore, the example in FIG. 6 shows an expected peripheral configuration of the relationship type Conn_To between a local terminal type component and an SVI (Switch Virtual Interface) type component.
[0043] Note that components of a certain type may be simply referred to by the name of that type. For example, a local terminal-type component may simply be called a local terminal, and a Conn_To-type relationship may simply be called Conn_To. A single line indicates a prerequisite configuration, and a dashed line indicates a required configuration. In other words, in the example of Figure 6, if the prerequisite configurations of a local terminal and an SVI exist as the Conn_To endpoints, when Conn_To is instantiated, a required configuration, a virtual local area network (VLAN), is added to the system configuration. Also, in the example of Figure 6, an expected peripheral configuration is expressed in which the required configuration, Conn_To, is added between the local terminal and VLAN, and between the SVI and VLAN, included in the system configuration.
[0044] Next, another example of components will be shown using FIG. 7. FIG. 7 is a diagram showing a second example of an expected peripheral configuration for explaining self-containment. Assume that an expected peripheral configuration is defined as shown in FIG. 7. In the example of FIG. 7, the expected peripheral configuration of Conn_To (double line) between a local terminal and a VLAN is shown. The Conn_To (double line) shown in FIG. 7 is added to the system configuration as a required configuration in the expected peripheral configuration of Conn_To (double line) shown in FIG. 6. Meanwhile, in the expected peripheral configuration shown in FIG. 7, in addition to the endpoints of Conn_To, a core switch and a Conn_To between a VLAN and a core switch are prerequisite configurations.
[0045] Here, the aforementioned backbone switch and the Conn_To between the backbone switch and the VLAN are not included in the prerequisite configuration or the required configuration of the expected peripheral configuration in the example of Fig. 6. On the other hand, in the example of Fig. 6, the expected peripheral configuration of the Conn_To between the local terminal and the SVI includes the Conn_To between the local terminal and the VLAN, so if the Conn_To between the local terminal and the SVI is to be specified, the Conn_To between the local terminal and the VLAN must also be specified.
[0046] However, in the example of Figure 6, although the above-mentioned realization requires a core switch and a Conn_To between a VLAN and a core switch, these are not included in the expected peripheral configuration of the Conn_To between the local terminal and the SVI. Therefore, even if the expected peripheral configuration of the Conn_To between the local terminal and the SVI is complete, the prerequisite configuration required for realizing the Conn_To between the local terminal and the VLAN is not complete. As a result, it becomes impossible to proceed with the design of the Conn_To between the local terminal and the SVI. In other words, in the example of Figure 6, the expected peripheral configuration of the Conn_To between the local terminal and the SVI is not self-contained. As can be seen from the examples of Figures 6 and 7, a non-self-contained expected peripheral configuration is a factor that prevents the design from reaching a concrete configuration, and therefore such modeling must be avoided.
[0047] [Following instructions] We will explain what it means for an expectation configuration to follow a component. The conceptual meaning of an expectation configuration following a component is that the components necessary to design that component are included in that expectation configuration. The condition for an expectation configuration following a component is that "the expectation configuration follows one or more of the expectation configurations of the component type." The definition of an expectation configuration following another expectation configuration is given below.
[0048] This section explains the situation where an expectation configuration follows another expectation configuration. The conceptual meaning of an expectation configuration following another expectation configuration is that the components necessary for designing the latter expectation configuration are included in the former expectation configuration. The condition for an expectation configuration following another expectation configuration is that "there are no prerequisite components included in the latter expectation configuration, or all prerequisite components included in the latter expectation configuration satisfy conditions 1 to 3."
[0049] Condition 1 is that "the prerequisite component in question is self-solvable in the expected peripheral configuration that includes it." The definition of "self-solvable" will be explained later. Condition 2 is that "the prerequisite component in question is included in the prerequisite configuration of the former expected peripheral configuration." Condition 3 is that "the prerequisite component in question is generated from the former expected peripheral configuration." The definition of a component being generated from the expected peripheral configuration will be explained later.
[0050] Here, an example is shown in which an expected peripheral configuration follows a component and its expected peripheral configuration. Assume that a certain expected peripheral configuration is defined as shown in FIG. 8. FIG. 8 is a diagram showing an example of an expected peripheral configuration for explaining the concept of following. FIG. 8 shows the expected peripheral configuration of Conn_To between SVI and VLAN, which is added to the system configuration as a required configuration by the expected peripheral configuration of Conn_To shown in FIG. 6.
[0051] In the expected peripheral configuration shown in the example of Figure 8, if the peripheral configuration of Conn_To has an SVI and a VLAN as endpoints of the prerequisite configuration Conn_To, a backbone switch, which is a required component, is added to the system configuration. Also, Conn_To, which is a required component, is added between the VLAN and the backbone switch in the system configuration. Also, Hosted_On, which is a required component, is added between the SVI and the backbone switch in the system configuration. The configuration added as a required component of this expected peripheral configuration includes a configuration equivalent to the prerequisite configuration of the expected peripheral configuration shown in Figure 7.
[0052] Therefore, when the expected peripheral configuration is defined as shown in Figures 6 to 8, although the expected peripheral configuration in Figure 6 does not include the prerequisite configuration of the expected peripheral configuration in Figure 7, it is obvious that the prerequisite configuration of the expected peripheral configuration in Figure 7 will be added as a required configuration of the expected peripheral configuration in Figure 8, and the design can proceed without any problems.
[0053] In other words, the expected peripheral configuration in Figure 6 includes the components necessary to design the expected peripheral configurations in Figures 7 and 8. In other words, it can be said that the expected peripheral configuration in Figure 6 follows the expected peripheral configurations in Figures 7 and 8. At the same time, it can be said that the expected peripheral configuration in Figure 6 follows the Conn_To between the local terminal and VLAN having the expected peripheral configuration in Figure 7, and the Conn_To between the SVI and VLAN having the expected peripheral configuration in Figure 8.
[0054] [Explanation of self-solvability] We will now explain the self-resolvability of premise components. The conceptual meaning of self-resolvability of premise components is that they have the property of being judged to exist trivially (= the premise is true) in the definition of the expected surrounding configuration that includes them. A premise component with such a property is expressed as a "self-resolvable premise component" or "this premise component is self-resolvable." Conversely, a premise component that cannot be judged to exist trivially is expressed as a "non-self-resolvable premise component" or "this premise component is not self-resolvable." The condition for a premise component to be self-resolvable is that "the premise component is generated from any other component included in the premise configuration that includes it." The definition of a component being generated from another component will be discussed later.
[0055] [Explanation of component generation] This section explains how a component is generated from another component. The conceptual meaning of generating a component from another component is that the former component is added to the system configuration by complementing the expected peripheral configuration of the latter component. However, this includes not only cases where the former component is added to the system configuration directly by complementing the expected peripheral configuration of the latter component, but also cases where it is added indirectly.
[0056] For example, if component B is added to the system configuration by complementing the expected peripheral configuration of component A, and component C is added to the system configuration by complementing the expected peripheral configuration of component B, then component C can be expressed not only as being generated from component B, but also as being generated from component A.
[0057] Furthermore, in the above example, if component D is added to the system configuration by complementing the expected peripheral configuration of component C, it can be expressed as "component D is generated from component C," "component D is generated from component B," or "component D is generated from component A."
[0058] In this way, when a component is added to a system configuration by complementing the expected peripheral configuration from another component multiple times, the latter component is said to be generated from the former component (= the former component generates the latter component). The condition for a component to be generated from another component is that "the former component is added to the system configuration by complementing the expected peripheral configuration from the latter component multiple times."
[0059] However, when implementing a means to check whether the above conditions are met, if the "multiple times" part of the above conditions were allowed to be any number of times, the processing would become very heavy, so in practice it is considered to divide it into an appropriate number of times. This number is called the "order of generation."
[0060] We will now explain how a component is generated from an expected peripheral configuration. This concept is similar to the previously mentioned concept of "a component is generated from another component." The conceptual meaning of generating a component from an expected peripheral configuration is that the component is added to the system configuration by complementing the expected peripheral configuration.
[0061] However, this includes not only cases where components are added directly to the system configuration by complementing the expected peripheral configuration, but also cases where they are added indirectly. For example, if component A is added to the system configuration by complementing a certain expected peripheral configuration X, and component B is added to the system configuration by complementing component A's expected peripheral configuration Y, component B can be expressed not only as being generated from expected peripheral configuration Y, but also as being generated from expected peripheral configuration X. Furthermore, in the above example, if component C is added to the system configuration by complementing component B's expected peripheral configuration Z, it can be expressed as "component C is generated from expected peripheral configuration Z," "component C is generated from expected peripheral configuration Y," or "component C is generated from expected peripheral configuration X."
[0062] In this way, when a component is added to a system configuration by complementing an expected peripheral configuration from a certain expected peripheral configuration multiple times, the component is said to be generated from the expected peripheral configuration (= the expected peripheral configuration generates the component). The condition for a component to be generated from an expected peripheral configuration is that "the component is added to the system configuration by complementing the expected peripheral configuration from the expected peripheral configuration multiple times."
[0063] However, when implementing a means to check whether the above conditions are met, if the "multiple times" part of the above conditions were allowed to be any number of times, the processing would become very heavy, so in practice it is considered to be divided into appropriate numbers. This number is called the "degree of generation," similar to the concept of "a component being generated from another component." [Explanation of Objective 3] Objective 3, "to provide a means for confirming whether a given model satisfies the above conditions," will now be described. The means for objective 3 can be provided by the configurations shown in the following embodiments. Therefore, the description of objective 3 will be replaced by the following embodiments.
[0064] (Embodiment 1) Hereinafter, in the first embodiment, an information processing device, an information processing method, and a program will be described with reference to FIGS.
[0065] [Device configuration] First, the configuration of an example of an information processing device will be described with reference to Fig. 9. Fig. 9 is a configuration diagram showing the configuration of an example of an information processing device.
[0066] 9 is a device for determining specification violations in the design of a computer system, specifically, an ICT system. As shown in FIG. 9, the information processing device 10 includes a specification determination unit 11 and an output unit 12.
[0067] The specification determination unit 11 determines whether the computer system model satisfies the specifications for the components included in its definition based on the self-containment of the components. The output unit 12 outputs the result of the determination as to whether the computer system model satisfies the specifications.
[0068] In this way, the information processing device 10 can determine whether the model of the designed computer system violates the specifications. The information processing device 10 makes it possible to determine whether the design object has been appropriately modeled. As a result, the above-mentioned Objectives 1 to 3 are achieved.
[0069] 9, the information processing device 10 is connected to a terminal device 20 via a network or the like so as to be able to communicate data with each other. In the embodiment, an example of the computer system is an ICT system. The model of the computer system will hereinafter also be referred to as an ICT system model. Furthermore, the "specification" specifically means that all components included in the definition of the computer system model can be configured to arrive at a specific configuration when each is designed using only the component and its expected peripheral configuration.
[0070] Furthermore, the specification determination unit 11 determines whether a component is generated from another component or its expected peripheral configuration, thereby determining whether the model of the computer system satisfies the specifications. Specifically, the specification determination unit 11 performs a determination as to whether the type of the component matches the type of a required component included in the expected peripheral configuration of the other component up to a number of times determined by the degree, and if they match, determines that the component is generated from the other component or its expected peripheral configuration. In this case, the degree may be set in advance, may be set randomly, or may be specified by input.
[0071] [Device operation] Next, the operation of the information processing device 10 will be described with reference to Figs. 10 to 20. In the following description, Fig. 1 will be referred to as appropriate. In addition, in the first embodiment, an information processing method is implemented by operating the information processing device 10. Therefore, the description of the information processing method will be substituted for the description of the operation of the information processing device 10 below.
[0072] First, the overall operation of the information processing device 10 will be described with reference to Fig. 10. Fig. 10 is a flow chart showing an example of the overall operation of the information processing device.
[0073] 10, first, the specification determination unit 11 receives an ICT system model as a model of a computer system (step S11). Specifically, the specification determination unit 11 receives an input of the ICT system model from a terminal device 20 connected via a network or the like.
[0074] Next, the specification determination unit 11 determines whether the ICT system model satisfies the specifications for the components included in the definition, based on the self-containment of the components (step S12).
[0075] Finally, the output unit 12 outputs the result of the determination made by the specification determination unit 11 as to whether the ICT system model satisfies the specifications (step S13). The output destination of the determination result may be the external terminal device 20 described above.
[0076] Next, step S12 of detecting a specification violation of the ICT system model will be described in detail with reference to Fig. 11. Fig. 11 is a flow diagram illustrating step S12 of detecting a specification violation shown in Fig. 10 in more detail.
[0077] 11, in step S12, the specification determination unit 11 first determines whether or not there are any unselected types among all types of components prepared in advance (step S111). If the result of the determination in step S111 indicates that there are any unselected types (step S111: Yes), the specification determination unit 11 selects one unselected type (step S112).
[0078] Next, the specification determination unit 11 checks whether the type selected in step S112 is self-contained (step S113). If the result of the check in step S113 is that the type is self-contained (step S114: Yes), the specification determination unit 11 returns to step S111.
[0079] If the result of the check in step S113 is that the ICT system model is not self-contained (step S114: No), the specification determination unit 11 determines that the ICT system model received in step S11 violates the specifications (step S115) and terminates the operation of step S12.
[0080] Also, if the result of step S111 is that there are no unselected types (step S111: No), the specification determination unit 11 determines that there is no specification violation in the ICT system model received in step S11 (step S116), and terminates the operation of step S12.
[0081] Next, step S113 of checking the self-containedness of the component type will be described in detail with reference to Fig. 12. Fig. 12 is a flow diagram illustrating in more detail step S113 of checking the self-containedness of the component type shown in Fig. 11.
[0082] 12, in step S113, the specification determination unit 11 first determines whether there is an unselected expected peripheral configuration of the type selected in step S112 (step S121). If the result of the determination in step S121 is that there is an unselected expected peripheral configuration (step S121: Yes), the specification determination unit 11 selects one unselected expected peripheral configuration (step S122).
[0083] Next, the specification determining unit 11 checks whether the expected peripheral configuration selected in step S122 is self-contained (step S123). If the result of checking in step S123 is that the expected peripheral configuration is self-contained (step S124: Yes), the specification determining unit 11 returns to step S121.
[0084] If the result of the check in step S123 is that the type is not self-contained (step S124: No), the specification determination unit 11 determines that the type selected in step S112 is not self-contained (step S125), and ends the operation of step S113.
[0085] If the result of the determination in step S121 is that there is no unselected type (step S121: No), the specification determination unit 11 determines that the type selected in step S112 is self-contained (step S126), and ends the operation of step S113.
[0086] Next, step S123 of checking the self-containment of the expected peripheral configuration will be described in detail with reference to Fig. 13. Fig. 13 is a flow diagram illustrating step S123 of checking the self-containment of the expected peripheral configuration shown in Fig. 12.
[0087] 13, in step S123, first, the specification determination unit 11 determines whether or not there are any unselected components included in the expected peripheral configuration selected in step S122 (step S131). If the result of the determination in step S131 is that there are any unselected components (step S131: Yes), the specification determination unit 11 selects one of the unselected components (step S132).
[0088] Next, the specification determining unit 11 checks whether the component selected in step S132 is followed by the expected peripheral configuration selected in step S122 (step S133). If the result of the check in step S133 is that the component is followed (step S134: Yes), the specification determining unit 11 returns to step S131.
[0089] If the result of the check in step S133 is that the expected peripheral configuration has not been followed (step S134: No), the specification determination unit 11 determines that the expected peripheral configuration selected in step S122 is not self-contained (step S135), and terminates the operation of step S123.
[0090] If the result of the determination in step S131 is that there are no unselected components (step S131: No), the specification determination unit 11 determines that the expected peripheral configuration selected in step S122 is self-contained (step S136) and ends the operation of step S123.
[0091] Next, step S133 of checking whether the components are followed by the expected peripheral configuration will be described in detail with reference to Fig. 14. Fig. 14 is a flow diagram illustrating step S133 of checking whether the components shown in Fig. 13 are followed by the expected peripheral configuration.
[0092] 14, first, in step S133, the specification determination unit 11 determines whether there is an unselected expected peripheral configuration of the type of component selected in step S132 (step S141). If the result of the determination in step S141 is that there is an unselected expected peripheral configuration (step S141: Yes), the specification determination unit 11 selects one unselected expected peripheral configuration (step S142).
[0093] Next, the specification determination unit 11 checks whether the expected peripheral configuration selected in step S142 follows the expected peripheral configuration selected in step S122 (step S143). If the result of the check in step S143 shows that the expected peripheral configuration does not follow (step S144: No), the specification determination unit 11 returns to step S141.
[0094] If the result of the check in step S143 is that the type is followed (step S144: Yes), the specification determination unit 11 determines that the type selected in step S132 is followed by the expected peripheral configuration selected in step S122 (step S145), and terminates the operation of step S133.
[0095] If the result of the judgment in step S141 is that there is no unselected expected peripheral configuration (step S141: No), the specification judgment unit 11 judges that the component selected in step S132 is not followed by the expected peripheral configuration selected in step S122 (step S146), and terminates the operation of step S133.
[0096] Next, step S143 for checking whether the expected peripheral configuration selected in step S142 is followed by the expected peripheral configuration selected in step S122 will be described in detail with reference to Fig. 15. Fig. 15 is a flow diagram for explaining step S143 for checking whether the expected peripheral configuration shown in Fig. 14 is followed by another expected peripheral configuration.
[0097] 15, first, in step S143, the specification determination unit 11 collects non-self-solvable prerequisite components from among the components included in the expected peripheral configuration selected in step S142 (step S151). Next, the specification determination unit 11 checks whether all the non-self-solvable prerequisite components collected in step S151 can be generated from the expected peripheral configuration selected in step S122 (step S152).
[0098] If the result of the check in step S152 is that all of the prerequisite components collected in step S151 that are not self-solvable are generated (step S153: Yes), the specification determination unit 11 determines that the expected peripheral configuration selected in step S142 is followed by the expected peripheral configuration selected in step S122 (step S154), and terminates the operation of step S143.
[0099] If the result of checking in step S152 is that all of the prerequisite components that are not self-solvable and collected in step S151 are not generated (step S153: No), the specification determination unit 11 determines that the expected peripheral configuration selected in step S142 does not follow the expected peripheral configuration selected in step S122 (step S155), and terminates the operation of step S143.
[0100] Next, step S151 of collecting prerequisite components that cannot be solved by themselves, which are included in the expected peripheral configuration, will be described in detail with reference to Fig. 16. Fig. 16 is a flow diagram illustrating step S151 of collecting prerequisite components that cannot be solved by themselves, which is shown in Fig. 15.
[0101] 16, first, in step S151, the specification determining unit 11 determines whether or not there is an unselected prerequisite component included in the expected peripheral configuration selected in step S142 (step S161). If the determination result in step S161 indicates that there is an unselected prerequisite component (step S161: Yes), the specification determining unit 11 selects one of the unselected prerequisite components (step S162).
[0102] Next, the specification determining unit 11 checks whether the prerequisite configuration element selected in step S162 is self-solvable (step S163). If the result of checking in step S163 shows that the prerequisite configuration element is self-solvable (step S164: Yes), the specification determining unit 11 returns to step S161.
[0103] If the result of the check in step S163 shows that the problem cannot be solved by itself (step S164: No), the specification determination unit 11 adds the prerequisite component selected in step S162 to the set of prerequisite components that cannot be solved by themselves (step S165), and returns to step S161.
[0104] If the result of the judgment in step S161 is that there are no unselected prerequisite components (step S161: No), the specification judgment unit 11 determines that the prerequisite components that are not self-solvable among the components included in the expected peripheral configuration are currently included in the set of prerequisite components that are not self-solvable, completes the collection process (step S166), and ends the operation of step S151.
[0105] Next, step S163 of checking the self-solvability of the prerequisite components will be described in detail with reference to Fig. 17. Fig. 17 is a flow diagram illustrating step S163 of checking the self-solvability of the prerequisite components shown in Fig. 16.
[0106] As shown in FIG. 17, in step S163, first, the specification determination unit 11 determines whether there are any prerequisite components other than the prerequisite components selected in step S162 that have not been selected in step S172 described later (step S171).
[0107] As a result of the determination in step S171, if there is another unselected prerequisite component (step S171: Yes), the specification determining unit 11 selects one other unselected prerequisite component (step S172).
[0108] Next, the specification determining unit 11 checks whether the prerequisite components selected in step S162 are generated from the prerequisite components selected in step S172 (step S173). If the result of the check in step S173 is that the prerequisite components are not generated (step S174: No), the specification determining unit 11 returns to step S171.
[0109] If the result of the check in step S173 is that the prerequisite components are generated (step S174: Yes), the specification determination unit 11 determines that the prerequisite components selected in step S162 are self-solvable (step S175), and ends the operation of step S163.
[0110] If the result of the judgment in step S171 is that there are no other unselected prerequisite components (step S171: No), the specification judgment unit 11 judges that the prerequisite components selected in step S162 are not self-solvable (step S176), and terminates the operation of step S163.
[0111] Next, step S173 for checking whether the prerequisite constituent selected in step S162 is generated from the prerequisite constituent selected in step S172 will be described in detail with reference to Fig. 18. Fig. 18 is a flow diagram illustrating step S173 shown in Fig. 17 for checking whether the prerequisite constituent is generated from another prerequisite constituent.
[0112] 18, in step S173, first, the specification determining unit 11 determines whether or not there is an unselected expected peripheral configuration of the prerequisite configuration element selected in step S172 (step S181). If the determination result in step S181 indicates that there is an unselected expected peripheral configuration (step S181: Yes), the specification determining unit 11 selects one unselected expected peripheral configuration (step S182).
[0113] Next, the specification determining unit 11 checks whether the prerequisite components selected in step S162 are generated from the expected peripheral configuration selected in step S182 (step S183). If the result of the check in step S183 is that the prerequisite components are not generated (step S184: No), the specification determining unit 11 returns to step S181.
[0114] If the result of the check in step S183 is that the prerequisite components are generated (step S184: Yes), the specification determination unit 11 determines that the prerequisite components selected in step S162 are generated from the prerequisite components selected in step S172 (step S185), and terminates the operation of step S173.
[0115] If the result of the determination in step S181 is that there is no unselected expected peripheral configuration (step S181: No), the specification determination unit 11 determines that the prerequisite components selected in step S162 are not generated from the prerequisite components selected in step S172 (step S186), and terminates the operation of step S173.
[0116] Next, step S183 for checking whether the prerequisite components selected in step S162 can be generated from the expected peripheral configuration selected in step S182 will be described in detail with reference to Fig. 19. Fig. 19 is a flow diagram illustrating step S183 for checking whether the prerequisite components shown in Fig. 18 can be generated from the expected peripheral configuration.
[0117] 19, first, in step S183, specification determination unit 11 sets the value of a variable that stores the number of loops to 0 (step S1A1). Next, specification determination unit 11 sets the content of a variable that stores the expected peripheral configuration group to be confirmed to the expected peripheral configuration selected in step S182 (step S1A2).
[0118] Next, the specification determination unit 11 determines whether the number of loops is less than the predetermined number of times (step S1A3). If the result of the determination is that the number of loops is less than the predetermined number of times (step S1A3: Yes), the specification determination unit 11 sets the content of the variable that stores the expected peripheral configuration group to be next checked to null (step S1A4).
[0119] Next, the specification determination unit 11 determines whether there is an unselected expected peripheral configuration in the contents of the variable that stores the expected peripheral configuration group to be confirmed (step S1A5). If the result of the determination in step S1A5 is that there is an unselected expected peripheral configuration (step S1A5: Yes), the specification determination unit 11 selects one unselected expected peripheral configuration (step S1A6).
[0120] Next, the specification determination unit 11 determines whether there are any unselected required components in the required configuration of the expected peripheral configuration selected in step S1A6 (step S1A7). If the result of the determination in step S1A7 is that there are any unselected required components (step S1A7: Yes), the specification determination unit 11 selects one unselected required component (step S1A8).
[0121] Next, the specification determination unit 11 determines whether the essential components selected in step S1A8 match the types of the prerequisite components selected in step S162 (step S1A9). If the result of the determination in step S1A9 is that they match (step S1A9: Yes), the specification determination unit 11 determines that the prerequisite components selected in step S162 are generated from the expected peripheral configuration selected in step S182 (step S1AA), and ends the operation of step S183.
[0122] On the other hand, if the result of the judgment in step S1A9 is that there is no match (step S1A9: No), the specification judgment unit 11 adds the expected peripheral configuration group of the essential component selected in step S1A8 to the variable that stores the expected peripheral configuration group of the next target to be checked (step S1AB), and returns to step S1A7.
[0123] Furthermore, if the result of the determination in step S1A7 is that there are no unselected components (step S1A7: No), specification determining unit 11 returns to step S1A5.
[0124] Furthermore, if the result of the judgment in the above-mentioned step S1A5 is that there are no unselected contents of the variable that stores the expected peripheral configuration group to be confirmed (step S1A5: No), the specification judgment unit 11 replaces the contents of the variable that stores the expected peripheral configuration group to be confirmed with the contents of the variable that stores the expected peripheral configuration group to be confirmed next (step S1AC).
[0125] Next, after executing step S1AC, specification determining unit 11 increments the value of the variable that stores the loop count by 1 (step S1AD) and returns to step S1A3. Then, specification determining unit 11 executes the determination of step S1A3. As a result, if the loop count is equal to or greater than the predetermined count (step S1A3: No), specification determining unit 11 determines that the prerequisite configuration element selected in step S162 cannot be generated from the expected peripheral configuration selected in step S182 (step S1AE), and ends the operation of step S183.
[0126] The predetermined number of times referred to in step S1A3 represents the "order of generation," and the method for determining the value is not limited. The order may be, for example, set as a fixed value in advance in the information processing device 10, or may be a value input by the user of the information processing device 10 when the operation of the information processing device 10 is started.
[0127] Next, step S152 for checking whether all prerequisite components that cannot be self-solved and collected in step S151 can be generated from the expected peripheral configuration selected in step S122 will be described in detail with reference to Fig. 20. Fig. 20 is a flow diagram for explaining step S152 for checking whether all prerequisite components that cannot be self-solved can be generated from the expected peripheral configuration shown in Fig. 15.
[0128] 20, first, in step S152, the specification determining unit 11 determines whether or not there are any unselected prerequisite components among the non-self-solvable prerequisite components collected in step S151 (step S191). If the determination result in step S191 indicates that there are unselected prerequisite components (step S191: Yes), the specification determining unit 11 selects one of the unselected prerequisite components (step S192).
[0129] Next, the specification determining unit 11 checks whether the prerequisite components selected in step S192 are generated from the expected peripheral configuration selected in step S122 (step S193). If the result of checking in step S193 is that the prerequisite components are generated (step S194: Yes), the specification determining unit 11 returns to step S191.
[0130] If the result of the check in step S193 is that they are not generated (step S194: No), the specification determination unit 11 determines that all prerequisite components that are not self-solvable collected in step S151 will not be generated (do not appear) from the expected peripheral configuration selected in step S122 (step S195), and terminates the operation of step S152.
[0131] Furthermore, if the result of the determination in step S191 described above is that there are no unselected prerequisite components (step S191: No), the specification determination unit 11 determines that all prerequisite components that are not self-solvable and collected in step S151 are generated (appear) from the expected peripheral configuration selected in step S122 (step S196), and terminates the operation of step S152.
[0132] Furthermore, step S193, which checks whether the prerequisite components selected in step S192 can be generated from the expected peripheral configuration selected in step S122, is performed in the same manner as step S183 described with reference to Fig. 19. That is, steps S1A1 to S1AD are executed in step S193 as in the example of Fig. 19. Therefore, a detailed description of step S193 will be omitted.
[0133] [Effects of the First Embodiment] In this way, in the first embodiment, it is possible to check whether the ICT system model violates the specifications and determine whether the ICT system model needs to be modified. Therefore, according to the first embodiment, if the ICT system model is not modeled appropriately, this can be pointed out, making it easier to carry out appropriate design.
[0134] [program] The program in the first embodiment may be any program that causes a computer to execute steps S11 to S13 shown in Fig. 10. By installing and executing this program in a computer, the information processing device and information processing method in the first embodiment can be realized. In this case, the processor of the computer functions as the specification determination unit 11 and the output unit 12 and performs the processing. In addition to a general-purpose PC, examples of the computer include a smartphone and a tablet terminal device.
[0135] The program according to the first embodiment may be executed by a computer system constructed by a plurality of computers. In this case, for example, each computer may function as either the specification determination unit 11 or the output unit 12.
[0136] (Embodiment 2) Next, an information processing device, an information processing method, and a program according to a second embodiment will be described with reference to FIGS.
[0137] [Device configuration] First, in the second embodiment, the configuration of the information processing device is the same as the configuration of the information processing device 10 shown in Fig. 1. Therefore, in the following description, Fig. 1 will be referred to as appropriate. However, in the second embodiment, the information processing device 10 is different in the function of the specification determination unit 11.
[0138] In the second embodiment, the specification determination unit 11 detects parts that do not satisfy the specifications when determining whether the ICT system model satisfies the specifications. The output unit 12 outputs the determination result including the detected parts. Note that, in the second embodiment as well, the "specification" means that all components included in the definition of the computer system model can reach a specific configuration when each is designed using only the component and its expected peripheral configuration.
[0139] [Device operation] Next, the operation of the information processing device 10 in the second embodiment will be described with reference to Figs. 21 to 23. In the following description, Fig. 1 will be referred to as appropriate. Also in the second embodiment, an information processing method is implemented by operating the information processing device 10. Therefore, the description of the information processing method will be substituted for the description of the operation of the information processing device 10 below.
[0140] First, the overall operation of the information processing device 10 in the second embodiment will be described with reference to Fig. 21. Fig. 21 is a flow chart showing another example of the overall operation of the information processing device.
[0141] 21, first, the specification determination unit 11 receives an ICT system model as a model of a computer system (step S21). Specifically, the specification determination unit 11 receives an input of the ICT system model from a terminal device or the like connected via a network or the like.
[0142] Next, in the second embodiment, the specification determination unit 11 detects a portion where the ICT system model does not satisfy the specifications for the components included in its definition (a portion violating the specifications) based on the self-containment of the components (step S22). Specifically, the specification determination unit 11 identifies which type of the ICT system model and which expected peripheral configuration thereof violates the specifications, and detects the identified portion as a portion violating the specifications.
[0143] Finally, the output unit 12 outputs information including the specification violation points detected in step S22 as specification violation information (step S23). The specification violation information is information that identifies which type of the ICT system model and which expected peripheral configuration thereof violates the specifications.
[0144] Next, step S22 of detecting specification violations in the ICT system model will be described in detail with reference to Fig. 22. Fig. 22 is a flow diagram illustrating step S22 of detecting specification violations in the ICT system model.
[0145] 22, first, in step S22, the specification determination unit 11 determines whether or not there is an unselected type among all types of the component (step S211). If the result of the determination in step S211 indicates that there is an unselected type (step S211: Yes), the specification determination unit 11 selects one unselected type (step S212).
[0146] Next, the specification determination unit 11 checks whether each expected peripheral configuration of the type selected in step S212 is self-contained (step S213).
[0147] If the result of checking in step S213 is that there is an expected peripheral configuration that is not self-contained (step S214: Yes), the specification determination unit 11 saves the type selected in step S212 and the expected peripheral configuration that is not self-contained confirmed in step S213 as specification violation information (step S215), and returns to step S211.
[0148] If it is determined in step S213 that there is no expected peripheral configuration that is not self-contained (step S214: No), the specification determining unit 11 returns to step S211.
[0149] Furthermore, if the result of the judgment in the above-mentioned step S211 is that there are no unselected types (step S211: No), the specification judgment unit 11 judges that it has finished collecting the specification violation information for the ICT system model received in step S21 (step S216), and terminates the operation of step S22.
[0150] Next, step S213 of checking the self-containment of each expected peripheral configuration of the type selected in step S212 will be described in detail with reference to Fig. 23. Fig. 23 is a flow diagram illustrating step S213 of checking the self-containment of each expected peripheral configuration of the component type.
[0151] 23, first, in step S213, the specification determination unit 11 determines whether or not there is an unselected expected peripheral configuration among the expected peripheral configurations of the type selected in step S212 (step S221). If the result of the determination in step S221 is that there is an unselected expected peripheral configuration (step S221: Yes), the specification determination unit 11 selects one unselected expected peripheral configuration (step S222).
[0152] Next, specification determination unit 11 checks the self-containment of the expected peripheral configuration selected in step S222 (step S223). The operation of step S223 is the same as the operation of step S123 shown in Fig. 12 in the first embodiment. Since the details of step S123 are shown in Fig. 13, the details of step S223 will not be described here.
[0153] If the result of the check in step S223 is that the expected peripheral configuration selected in step S222 is self-contained (step S224: Yes), the specification determination unit 11 determines that the expected peripheral configuration selected in step S222 is self-contained (step S225) and returns to step S221.
[0154] If the check result in step S223 shows that the expected peripheral configuration selected in step S222 is not self-contained (step S224: No), the specification determination unit 11 determines that the expected peripheral configuration selected in step S222 is not self-contained (step S226), and returns to step S221.
[0155] If the result of the subsequent judgment in step S221 is that there are no unselected expected peripheral configurations (step S221: No), the specification judgment unit 11 judges that it has finished checking the self-containedness of each expected peripheral configuration of the type selected in step S212 (step S227), and terminates the operation of step S213.
[0156] [Effects of the second embodiment] In this way, in the second embodiment, it is possible to check for any violations of the specifications of the ICT system model. Therefore, according to the second embodiment, if the ICT system model is not modeled appropriately, it is possible to present the part in question, making it easy to eliminate the violations of the specifications. As a result, it becomes easy to appropriately model the ICT system model and design it.
[0157] [program] The program in the second embodiment may be any program that causes a computer to execute steps S21 to S23 shown in Fig. 21. By installing and executing this program in a computer, the information processing device and information processing method in the second embodiment can be realized. In this case, the processor of the computer functions as the specification determination unit 11 and the output unit 12 and performs the processing. In addition to a general-purpose PC, examples of the computer include a smartphone and a tablet terminal device.
[0158] The program in the second embodiment may be executed by a computer system constructed by a plurality of computers. In this case, for example, each computer may function as either the specification determination unit 11 or the output unit 12.
[0159] [Physical configuration] A computer that realizes the information processing device by executing the programs in the first and second embodiments will now be described with reference to Fig. 24. Fig. 24 is a block diagram showing an example of a computer that realizes the information processing device.
[0160] 24, a computer 110 includes a CPU (Central Processing Unit) 111, a main memory 112, a storage device 113, an input interface 114, a display controller 115, a data reader / writer 116, and a communication interface 117. These components are connected to each other via a bus 121 so as to be able to communicate data with each other.
[0161] Furthermore, the computer 110 may include a GPU (Graphics Processing Unit) or an FPGA (Field-Programmable Gate Array) in addition to or instead of the CPU 111. In this aspect, the GPU or FPGA can execute the programs in the embodiments.
[0162] The CPU 111 loads a program in the embodiment, which is composed of a group of codes and stored in the storage device 113, into the main memory 112 and executes each code in a predetermined order to perform various calculations. The main memory 112 is typically a volatile storage device such as a DRAM (Dynamic Random Access Memory).
[0163] The program in the embodiment is provided in a state stored in a computer-readable recording medium 120. The program in the embodiment may be distributed over the Internet connected via the communication interface 117.
[0164] Specific examples of the storage device 113 include a hard disk drive and a semiconductor storage device such as a flash memory. The input interface 114 mediates data transmission between the CPU 111 and input devices 118 such as a keyboard and a mouse. The display controller 115 is connected to a display device 119 and controls the display on the display device 119.
[0165] The data reader / writer 116 mediates data transmission between the CPU 111 and the recording medium 120, reads programs from the recording medium 120, and writes processing results from the computer 110 to the recording medium 120. The communication interface 117 mediates data transmission between the CPU 111 and other computers.
[0166] Specific examples of the recording medium 120 include general-purpose semiconductor storage devices such as CF (Compact Flash (registered trademark)) and SD (Secure Digital), magnetic recording media such as flexible disks, or optical recording media such as CD-ROMs (Compact Disk Read Only Memory).
[0167] The information processing device can be realized not by a computer with a program installed, but by hardware corresponding to each unit, for example, an electronic circuit. Furthermore, the information processing device may be realized in part by a program and in the remaining part by hardware. In the embodiments, the computer is not limited to the computer shown in FIG. 24.
[0168] Some or all of the above-described embodiments can be expressed by (Supplementary Note 1) to (Supplementary Note 15) described below, but are not limited to the following descriptions.
[0169] (Appendix 1) a specification determination unit that determines whether a model of a computer system satisfies specifications for components included in the definition based on the self-containment of the components; an output unit that outputs a result of a determination as to whether the model of the computer system satisfies the specification; An information processing device comprising:
[0170] (Appendix 2) the specification determination unit detects a portion that does not satisfy the specifications in determining whether the model of the computer system satisfies the specifications; the output unit outputs the determination result including the detected portion. 2. The information processing device according to claim 1.
[0171] (Appendix 3) The specification states that all of the components included in the definition of the model of the computer system can reach a specific configuration when designed using only the component and its expected peripheral configuration. 2. The information processing device according to claim 1.
[0172] (Appendix 4) the specification determination unit determines whether the model of the computer system satisfies the specification by determining whether the component is generated from another component or its expected peripheral configuration; 4. The information processing device according to claim 3.
[0173] (Appendix 5) the specification determination unit determines whether a type of the component matches a type of a required component included in the expected peripheral configuration of the other component up to a number of times determined by a degree, and if they match, determines that the component is generated from the other component or its expected peripheral configuration; The order is preset, randomly set, or specified. 5. The information processing device according to claim 4.
[0174] (Appendix 6) a specification determination step of determining whether the model of the computer system satisfies the specifications for the components included in the definition based on the self-containment of the components; an output step of outputting a result of the determination as to whether the model of the computer system satisfies the specification; An information processing method comprising:
[0175] (Appendix 7) In the specification determination step, in determining whether the model of the computer system satisfies the specifications, a portion that does not satisfy the specifications is detected; In the output step, the determination result including the detected portion is output. 1. The information processing method described in Appendix 6.
[0176] (Appendix 8) The specification states that all of the components included in the definition of the model of the computer system can reach a specific configuration when designed using only the component and its expected peripheral configuration. 1. The information processing method described in Appendix 6.
[0177] (Appendix 9) determining whether the model of the computer system satisfies the specification by determining whether the component is generated from another component or its expected peripheral configuration in the specification determination step; 10. The information processing method according to claim 8.
[0178] (Appendix 10) In the specification determination step, a determination is made as to whether the type of the component matches the type of a required component included in the expected peripheral configuration of the other component up to a number of times determined by a degree, and if they match, it is determined that the component is generated from the other component or its expected peripheral configuration; The order is preset, randomly set, or specified. 10. The information processing method according to claim 9.
[0179] (Appendix 11) On the computer, a specification determination step of determining whether the model of the computer system satisfies the specifications for the components included in the definition based on the self-containment of the components; an output step of outputting a result of the determination as to whether the model of the computer system satisfies the specification; A program that executes.
[0180] (Appendix 12) In the specification determination step, in determining whether the model of the computer system satisfies the specifications, a portion that does not satisfy the specifications is detected; In the output step, the determination result including the detected portion is output. 11. The program described in Appendix 11.
[0181] (Appendix 13) The specification states that all of the components included in the definition of the model of the computer system can reach a specific configuration when designed using only the component and its expected peripheral configuration. 12. The program described in Appendix 11.
[0182] (Appendix 14) determining whether the model of the computer system satisfies the specification by determining whether the component is generated from another component or its expected peripheral configuration in the specification determination step; 13. The program described in Appendix 13.
[0183] (Appendix 15) In the specification determination step, a determination is made as to whether the type of the component matches the type of a required component included in the expected peripheral configuration of the other component up to a number of times determined by a degree, and if they match, it is determined that the component is generated from the other component or its expected peripheral configuration; The order is preset, randomly set, or specified. 14. The program described in Appendix 14. [Industrial Applicability]
[0184] As described above, the present disclosure makes it possible to determine whether a design object is appropriately modeled. The present disclosure is suitably applicable to, for example, the creation and modification of models for automating intellectual tasks such as the design process of ICT systems. [Explanation of symbols]
[0185] 10. Information processing equipment 11 Specification Judgment Section 12 Output section 20 Terminal equipment 110 Computer 111 CPU 112 main memory 113 Storage device 114 Input Interface 115 Display Controller 116 Data Reader / Writer 117 Communication Interface 118 Input Devices 119 Display Device 120 Recording Media 121 Bus
Claims
1. a specification determination unit that determines whether a model of a computer system satisfies specifications for components included in the definition based on the self-containment of the components; an output unit that outputs a result of a determination as to whether the model of the computer system satisfies the specification; An information processing device comprising:
2. the specification determination unit detects a portion that does not satisfy the specifications in determining whether the model of the computer system satisfies the specifications; the output unit outputs the determination result including the detected portion. The information processing device according to claim 1 .
3. The specification states that all of the components included in the definition of the model of the computer system can reach a specific configuration when designed using only the component and its expected peripheral configuration. The information processing device according to claim 1 .
4. the specification determination unit determines whether the model of the computer system satisfies the specification by determining whether the component is generated from another component or its expected peripheral configuration; The information processing device according to claim 3 .
5. the specification determination unit determines whether a type of the component matches a type of a required component included in the expected peripheral configuration of the other component up to a number of times determined by a degree, and if they match, determines that the component is generated from the other component or its expected peripheral configuration; The order is preset, randomly set, or specified. The information processing device according to claim 4 .
6. a specification determination step of determining whether the model of the computer system satisfies the specifications for the components included in the definition based on the self-containment of the components; an output step of outputting a result of the determination as to whether the model of the computer system satisfies the specification; An information processing method comprising:
7. In the specification determination step, in determining whether the model of the computer system satisfies the specifications, a portion that does not satisfy the specifications is detected; In the output step, the determination result including the detected portion is output. The information processing method according to claim 6.
8. The specification states that all of the components included in the definition of the model of the computer system can reach a specific configuration when designed using only the component and its expected peripheral configuration. The information processing method according to claim 6.
9. determining whether the model of the computer system satisfies the specification by determining whether the component is generated from another component or its expected peripheral configuration in the specification determination step; The information processing method according to claim 8.
10. In the specification determination step, a determination is made as to whether the type of the component matches the type of a required component included in the expected peripheral configuration of the other component up to a number of times determined by a degree, and if they match, it is determined that the component is generated from the other component or its expected peripheral configuration; The order is preset, randomly set, or specified. The information processing method according to claim 9.
11. On the computer, a specification determination step of determining whether the model of the computer system satisfies the specifications for the components included in the definition based on the self-containment of the components; an output step of outputting a result of the determination as to whether the model of the computer system satisfies the specification; A program that executes.
12. In the specification determination step, in determining whether the model of the computer system satisfies the specifications, a portion that does not satisfy the specifications is detected; In the output step, the determination result including the detected portion is output. The program according to claim 11.
13. The specification states that all of the components included in the definition of the model of the computer system can reach a specific configuration when designed using only the component and its expected peripheral configuration. The program according to claim 11.
14. determining whether the model of the computer system satisfies the specification by determining whether the component is generated from another component or its expected peripheral configuration in the specification determination step; The program according to claim 13.
15. In the specification determination step, a determination is made as to whether the type of the component matches the type of a required component included in the expected peripheral configuration of the other component up to a number of times determined by a degree, and if they match, it is determined that the component is generated from the other component or its expected peripheral configuration; The order is preset, randomly set, or specified. The program according to claim 14.
Citation Information
Patent Citations
System configuration derivation device and system configuration derivation method
JP7036205B2