Automatic system design device, automatic system design method, and program

Abstract

To treat in a graph form requirements which are not expressed in requirement data.SOLUTION: A system automatic designing apparatus (100A) comprises: a view generation unit (112) which generates a view obtained by converting requirement data, by using a viewpoint model, and outputs the view as a pre-update view; a graph conversion unit (1111) which converts the requirement data or the pre-update view, by using a graph conversion rule; a requirement data updating unit (113) which reflects, in the requirement data, contents of an updated view into which the pre-update view has been converted; and a system requirement embodiment unit (111) which obtains system configuration data in which the requirement data is embodied, by repeating a step of converting the requirement data by the graph conversion unit (1111), or converting the pre-update view into the updated view by the graph conversion unit (1111), and reflecting, in the requirement data, the contents of the updated view by the requirement data updating unit (113).SELECTED DRAWING: Figure 57

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] There is a technology that gradually concretizes abstract system requirements that represent the configuration of computer systems, Internet of Things (IoT) systems, Information and Communication Technology (ICT) systems, etc., and converts them into concrete system configurations. For example, Patent Document 1 discloses a technology in which system requirements are represented as graph-like requirements data consisting of nodes corresponding to system components and edges defining the relationship between two nodes, and the graph-like requirements data is converted into a specific system configuration using concatenation rules. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] International Publication No. 2019 / 216082 Summary of the Invention [Problem to be solved by the invention]

[0004] As described above, in related technologies such as the technology disclosed in Patent Document 1, a specific system configuration is generated by gradually concretizing graph-like requirement data. Here, "graph-like requirement data" refers to data (data set) that constitutes the configuration requirements (system requirements) of a system, expressed in the form of a graph (the same applies below). At this time, in the related technologies, the requirements to be concretized are the requirements expressed in a graph.

[0005] However, there is a problem with graph-like requirements data in that the properties that a system requirement should have are not necessarily expressed as entities of the graph. Specifically, there may be requirements that are not expressed by a certain graph, even though the certain graph is a property that the certain graph should have as a system requirement, because the property is not directly written in the certain graph. However, the related technology has a problem in that requirements that are not expressed in a graph cannot be handled because they are not subject to instantiation.

[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 can solve the above-mentioned problems and handle requirements that are not expressed in graph-like requirements data. [Means for solving the problem]

[0007] According to one aspect, an automatic system design apparatus includes: a view generator that inputs requirement data, which is a graph expressing a system requirement, and inputs a viewpoint model, which is a model that defines a conversion method for converting the requirement data into a graph that gives a different expression of the system requirement expressed by the requirement data, generates a view, which is a graph obtained by converting the requirement data using the viewpoint model, and outputs the generated view as a pre-update view; a graph conversion unit that inputs the requirement data or the pre-update view, and inputs graph conversion rules, which are data expressing rules for converting a substructure matching a specific structure into a more specific entity, for the requirement data or the pre-update view, and converts the requirement data or the pre-update view using the graph conversion rules; a requirements data update unit which inputs the requirements data and also inputs a post-update view which is a view obtained after the pre-update view is converted, and reflects the contents of the post-update view in the requirements data; a system requirement concretization unit that outputs system configuration data that is a graph in which the requirement data is concretized, Converting the requirement data by the graph conversion unit; or converting the pre-update view into the post-update view by the graph conversion unit, and reflecting the content of the post-update view in the requirement data by the requirement data update unit, thereby converting the requirement data; By repeating the above steps, the system configuration data is obtained.

[0008] A method for automatically designing a system according to one aspect includes the steps of: An automatic system design method performed by an automatic system design device, comprising: a view generation step of inputting requirement data which is a graph expressing a system requirement and a viewpoint model which is a model defining a conversion method for converting the requirement data into a graph which gives another expression of the system requirement expressed by the requirement data, generating a view which is a graph obtained by converting the requirement data using the viewpoint model, and outputting the generated view as a pre-update view; a graph transformation step of inputting the requirement data or the pre-update view, and inputting graph transformation rules, which are data expressing rules for transforming a substructure matching a specific structure into a more specific entity, for the requirement data or the pre-update view, and transforming the requirement data or the pre-update view using the graph transformation rules; a requirements data update step of inputting the requirements data and inputting a post-update view which is a view obtained after the pre-update view is converted, and reflecting the contents of the post-update view in the requirements data, Transforming the requirements data by the graph transformation step; or converting the pre-update view into the post-update view in the graph conversion step, and reflecting the contents of the post-update view in the requirements data in the requirements data update step, thereby converting the requirements data; By repeating the above steps, system configuration data is obtained, which is a graph that embodies the requirement data.

[0009] A program according to one aspect comprises: On the computer, a view generation function for inputting requirement data, which is a graph expressing a system requirement, and inputting a viewpoint model, which is a model defining a conversion method for converting the requirement data into a graph giving a different expression of the system requirement expressed by the requirement data, generating a view, which is a graph obtained by converting the requirement data using the viewpoint model, and outputting the generated view as a pre-update view; a graph conversion function for inputting the requirement data or the pre-update view, and inputting graph conversion rules, which are data expressing rules for converting a substructure matching a specific structure into a more specific entity, for the requirement data or the pre-update view, and converting the requirement data or the pre-update view using the graph conversion rules; a requirements data update function for inputting the requirements data and inputting a post-update view, which is a view obtained after the pre-update view is converted, and reflecting the contents of the post-update view in the requirements data; a system requirement specification function that outputs system configuration data, which is a graph in which the requirement data is specified; A program for achieving the above, In the system requirement specification function, Transforming the requirements data using the graph transformation function; or converting the pre-update view into the post-update view by the graph conversion function, and converting the requirements data by reflecting the contents of the post-update view in the requirements data by the requirements data update function; By repeating the above steps, the system configuration data is obtained. Effect of the Invention

[0010] According to the above-mentioned aspects, it is possible to provide an automatic system design device, an automatic system design method, and a program that can handle requirements that are not clearly expressed as entities in graph-like requirements data. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram for explaining an example of an image of an existing automated design process; [Diagram 2] FIG. 1 is a diagram for explaining a problem with an existing automated design process. [Diagram 3] FIG. 2 is a diagram illustrating an example of a view according to the present disclosure. [Figure 4] FIG. 1 illustrates an example of a requirements data materialization pattern and a view materialization pattern according to the present disclosure. [Diagram 5] FIG. 13 is a diagram illustrating an example application of a view materialization pattern according to the present disclosure. [Figure 6] FIG. 1 is a diagram illustrating an example of an automated design process according to the present disclosure. [Figure 7] 1 is a block diagram showing a configuration example of a system automatic design device according to a first embodiment. [Figure 8] 4 is a flowchart illustrating an example of a schematic operation flow of the automatic system design device according to the first embodiment. [Figure 9] 13 is a flowchart illustrating an example of a schematic operation flow when requirement data is converted using a second conversion method in the automatic system design device according to the first embodiment. [Figure 10] FIG. 11 is a diagram illustrating an example of node conversion mapping. [Figure 11] FIG. 13 is a diagram illustrating an example of edge transformation mapping. [Figure 12] FIG. 13 is a diagram illustrating an example of properties of node transformation mapping. [Figure 13] 13 is a flowchart illustrating an example of an operation flow when a viewpoint model is read. [Figure 14] FIG. 11 is a diagram illustrating an example of an abstract type stub(t) corresponding to a generating type t of a node conversion mapping. [Figure 15] FIG. 13 is a diagram illustrating an example of an abstract type stub(t) corresponding to a generative type t of an edge transformation mapping. [Figure 16] FIG. 13 is a diagram illustrating a special case of the abstract type stub(t). [Figure 17]FIG. 13 is a diagram illustrating a special case of the abstract type stub(t). [Figure 18] 11A to 11C are diagrams illustrating examples of structure generation patterns corresponding to node conversion mapping. [Figure 19] 11A and 11B are diagrams illustrating an example of a structure generation pattern corresponding to edge transformation mapping. [Figure 20] 13A and 13B are diagrams illustrating an example of how property mapping information of a node conversion mapping is handled. [Figure 21] 1 is a diagram illustrating an example of a node transformation mapping and an abstract type stub(t) corresponding to a generated type t of the node transformation mapping. [Figure 22] 11 is a diagram illustrating an example of a combination of a node conversion mapping, an abstract type stub(t) corresponding to a generation type t of the node conversion mapping, and a structure generation pattern corresponding to the node conversion mapping. FIG. [Figure 23] 11 is a diagram illustrating an example of a combination of an edge transformation mapping, an abstract type stub(t) corresponding to a generation type t of the edge transformation mapping, and a structure generation pattern corresponding to the edge transformation mapping. FIG. [Figure 24] 13 is a flowchart illustrating an example of the flow of a forward transformation operation by a view generation unit according to the first embodiment. [Diagram 25] 13 is a flowchart illustrating an example of the flow of a forward transformation operation by a view generation unit according to the first embodiment. [Figure 26] FIG. 25 is a diagram for explaining a specific example of the operations in steps S301 and S302 shown in FIG. 24. [Figure 27] FIG. 25 is a diagram illustrating a specific example of the operations in steps S303 to S306 shown in FIG. 24. [Figure 28] FIG. 25 is a diagram illustrating a specific example of the operations in steps S304 to S306 shown in FIG. 24. [Figure 29] FIG. 26 is a diagram illustrating a specific example of the operations in steps S308 to S311 shown in FIG. [Diagram 30] FIG. 26 is a diagram illustrating a specific example of the operations in steps S308 to S311 shown in FIG. [Diagram 31] FIG. 26 illustrates an example of a view and mapping table after the forward transformation operation shown in FIGS. 24 and 25 is completed. [Diagram 32] 13 is a flowchart illustrating an example of a flow of a reverse conversion operation by a requirement data update unit according to the first embodiment. [Diagram 33] 13 is a flowchart illustrating an example of a flow of a reverse conversion operation by a requirement data update unit according to the first embodiment. [Diagram 34] FIG. 33 is a diagram illustrating a specific example of the operation of step S401 shown in FIG. 32. [Diagram 35] FIG. 33 is a diagram illustrating a specific example of the operation in step S402 shown in FIG. 32. [Diagram 36] FIG. 33 is a diagram illustrating a specific example of the operation in step S403 shown in FIG. 32. [Figure 37] FIG. 33 is a diagram for explaining a specific example of the operations in steps S404 and S405 shown in FIG. 32. [Figure 38] FIG. 33 is a diagram for explaining a specific example of the operations in steps S404 and S405 shown in FIG. 32. [Figure 39] FIG. 34 is a diagram for explaining a specific example of the operations in steps S407 and S408 shown in FIG. 33. [Diagram 40] FIG. 34 is a diagram for explaining a specific example of the operations of steps S407, S408, and S410 shown in FIG. [Diagram 41] FIG. 34 is a diagram illustrating a specific example of the operation of step S410 shown in FIG. 33. [Diagram 42] FIG. 34 is a diagram illustrating a specific example of the operation in step S411 shown in FIG. 33. [Diagram 43] FIG. 34 is a diagram illustrating a specific example of the operation in step S411 shown in FIG. 33. [Diagram 44] 11 is a flowchart illustrating an example of a flow of an automatic design process by a system requirement instantiation unit according to the first embodiment. [Diagram 45] 45 is a diagram illustrating a specific example of a node of a search tree generated and updated in the automated design process shown in FIG. 44. [Figure 46] FIG. 45 is a diagram illustrating a specific example of the operations in steps S505 and S510 shown in FIG. 44. [Figure 47] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 48] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 49] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 50] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 51] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 52] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 53] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 54] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 55] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 56] FIG. 45 is a diagram illustrating a specific example of the operation in step S509 shown in FIG. 44. [Figure 57] FIG. 11 is a block diagram showing a configuration example of a system automatic design device according to a second embodiment. [Figure 58] FIG. 11 is a block diagram showing an example of a hardware configuration of a system automatic design apparatus according to a third embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Before describing the embodiments of the present disclosure, details of the problem to be solved by the present disclosure and an overview of the present disclosure will be described. <Problems and Outline of the Disclosure> First, the automated design process that is the premise of this disclosure will be described. In the automated design process, requirements data that represent abstract system requirements are gradually concretized and transformed into a concrete system configuration by applying concretization patterns. The requirements data is a graph that represents the system requirements, and is composed of entities that include nodes that correspond to system components and edges that define relationships between two nodes.

[0013] Generally, there are multiple concretization patterns that can be applied. Therefore, in the automated design process, multiple concretization patterns are applied to the requirements data, and processing (i.e., concretization) proceeds while exploring multiple possibilities through trial and error.

[0014] Therefore, the automated design process proceeds in the form of a search tree, as shown in Fig. 1. In Fig. 1, the dotted rectangles represent requirements data (the same applies in the following drawings). In the example of Fig. 1, the root of the search tree is node N1, and three concretization patterns are applied to the requirements data of node N1, two concretization patterns are applied to the requirements data of node N2, and one concretization pattern is applied to the requirements data of node N6. As a result, concrete system configuration data in which the requirements data is concretized is obtained at node N7.

[0015] However, in existing automated design processes, the requirements to be instantiated are those expressed in graph-like requirements data, so requirements that are not directly expressed as entities in the requirements data cannot be instantiated, and therefore cannot be handled.

[0016] Hereinafter, the above-mentioned problem will be specifically described with reference to FIG. The requirement data (requirements) shown in FIG. 2 are roughly assumed to be a system requirement that "antivirus agents should be installed on all machines that operate the service." Therefore, the requirements data shown in Figure 2 includes the requirement "AntiVirus must support these machines" even though it is not directly stated.

[0017] To generate a configuration that satisfies the above requirements, an edge (a dotted arrow in the diagram) indicating "Installation required" must first be established between the "machine that operates the service" and AntiVirus. To achieve this in an existing automated design process, an entity that directly associates AntiVirus with the machine in question must be expressed in the requirements data. However, since the requirement "AntiVirus must support these machines" is not expressed in the requirements data, it is not made concrete, and as a result, the edge "installation is required" mentioned above cannot be asserted.

[0018] Therefore, in this disclosure, a view is generated from the requirements data, which has requirements that are not expressed in the requirements data as explicit edges and nodes, as shown in Fig. 3. In Fig. 3, the dashed-dotted rectangle represents a view (the same applies to the following drawings). A viewpoint model is used when generating a view from the requirements data.

[0019] A viewpoint model is a model that defines a transformation method for converting requirements data into a graph that provides an alternative representation of the system requirements that the requirements data expresses. In other words, a viewpoint model is a model that defines a transformation method for converting substructures in the requirements data into entities. A view is a graph obtained by transforming the requirements data using a viewpoint model.

[0020] In the example of Figure 3, a view is generated from requirements data using a viewpoint model of antivirus protection. In the generated view, an edge "protect" is set from the node "AntiVirus" to each of the two nodes representing the machines that operate the service, indicating that "installation is required."

[0021] In addition, in this disclosure, as shown in Fig. 4, in addition to having an existing concatenation pattern for concatenating requirement data (hereinafter referred to as a requirement data concatenation pattern), there is also a concatenation pattern for concatenating a view (hereinafter referred to as a view concatenation pattern). Therefore, not only the requirements included in the requirement data but also the requirements included in the view can be concatenated.

[0022] An example of the application of the view materialization pattern will now be described with reference to FIG. As shown in FIG. 5, first, a view v0 is generated from requirements data t0 using a viewpoint model. Next, a view v0 is instantiated using a view instantiation pattern to obtain a view v1. After that, requirements data t1 is obtained by reflecting the contents of the view v1 in the requirements data t0. In other words, the view v1 is converted into requirements data t1. As a result, in this application example, an operation of instantiating the view v0 and converting it into the view v1 can be performed to instantiate the requirements data t0 and convert it into requirements data t1.

[0023] Now, with reference to FIG. 6, an image example of an automated design process according to the present disclosure will be described. As shown in FIG. 6, in the automated design process according to the present disclosure, the nodes of the search tree include requirement data and views.

[0024] The conversion from node N1 to node N2, and the conversion from node N2 to nodes N4 and N5 are the same as those in the existing automated design process shown in Fig. 1. That is, in this conversion, the requirements data is converted using a requirements data instantiation pattern.

[0025] On the other hand, the transformation from node N1 to node N3 and the transformation from node N5 to nodes N6 and N7 are transformations specific to the automated design process according to the present disclosure. That is, in these transformations, the view is transformed using a view instantiation pattern, and the contents of the transformed view are reflected in the requirements data.

[0026] In this way, according to the present disclosure, a mechanism is added for embodying not only the requirements included in the requirements data, but also the requirements included in the views, making it possible to handle requirements that could not be expressed by the requirements data.

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

[0028] <Embodiment 1> <Configuration of First Embodiment> First, a configuration example of an automatic system design device 100 according to the first embodiment will be described with reference to Fig. 7. As shown in Fig. 7, the automatic system design device 100 according to the first embodiment includes a system requirement concretization unit 101, a view generation unit 102, a requirement data update unit 103, a viewpoint model reading unit 104, a viewpoint model DB (Data Base) 105, a type information DB 106, and a graph conversion rule DB 107.

[0029] The system requirements concretization unit 101 inputs initial requirements data from an input / output device (not shown), inputs graph conversion rules from the graph conversion rule DB 107, inputs type information (data expressing entity types including the "abstract type stub(t)" described later) from the type information DB 106, and inputs a view (pre-update view) from the view generation unit 102. The requirements data and views are as described above. The graph conversion rules are data expressing rules for converting a substructure that matches a specific structure into a more specific entity for the requirements data or the view. The graph conversion rules include a requirements data concretization pattern for converting the requirements data and a view concretization pattern for converting the view. The type information will be described later.

[0030] The system requirement instantiation unit 101 also includes a graph conversion unit 1011. The graph conversion unit 1011 converts requirement data using a requirement data instantiation pattern, or converts a pre-update view using a view instantiation pattern.

[0031] The system requirement specification unit 101 converts the initial requirement data step by step, and when the data becomes sufficiently specific, outputs it to an input / output device (not shown) as system configuration data. The system configuration data is a graph that represents a specific system configuration.

[0032] According to the first embodiment, there are two types of conversion methods for converting requirement data: (1) First conversion method The first conversion method is a method of converting requirement data by applying a requirement data instantiation pattern using the graph conversion unit 1011. The conversion by the first conversion method is similar to that in existing automated design processes.

[0033] (2) The second conversion method The second conversion method is a method of converting requirements data by applying a view instantiation pattern using graph conversion unit 1011 to convert a view (pre-update view) and reflecting the contents of the view (post-update view) after the pre-update view is converted in requirements data using requirements data update unit 103. Conversion by the second conversion method is specific to the automatic design process according to the first embodiment. The operations of the view generating unit 102 and the requirement data updating unit 103 described below are operations for realizing the above-mentioned second conversion method.

[0034] The view generation unit 102 inputs requirement data from the system requirement concretization unit 101, inputs a viewpoint model from the viewpoint model DB 105, and inputs type information from the type information DB 106. The viewpoint models are as described above. Here, the view generation unit 102 is notified by the system requirement concretization unit 101 of the desired viewpoint model selected by the system requirement concretization unit 101 (hereinafter referred to as the "selected aspect model"). Therefore, the view generation unit 102 inputs the selected aspect model from the viewpoint model DB 105.

[0035] Moreover, the view generating unit 102 generates a view from the requirement data using the selected viewpoint model, and outputs the generated view to the system requirement specifying unit 101 as a pre-update view.

[0036] The requirements data updating unit 103 inputs the requirements data and the updated view from the system requirements concretization unit 101. The updated view is a view obtained after the pre-update view is converted by the graph conversion unit 1011 of the system requirements concretization unit 101. The requirements data updating unit 103 then reflects the contents of the updated view in the requirements data. In other words, the requirements data updating unit 103 converts the updated view into requirements data. The requirements data updating unit 103 then outputs the requirements data converted from the updated view to the system requirements concretization unit 101.

[0037] The viewpoint model reading unit 104, the viewpoint model DB 105, the type information DB 106, and the graph conversion rule DB 107 will be described in detail later.

[0038] <Overview of Operation of First Embodiment> Next, with reference to FIG. 8, an example of a schematic operation flow of the system automatic design device 100 according to the first embodiment will be described. 8, first, the system requirement specification unit 101 inputs initial requirement data from an input / output device (not shown) (step S100). After that, the system requirement specification unit 101 converts the initial requirement data step by step, and when the data becomes sufficiently specific, outputs the data to an input / output device (not shown) as specific system configuration data (step S110). At this time, the method for converting the requirement data is either the first conversion method or the second conversion method described above.

[0039] Next, with reference to FIG. 9, an example of a schematic operation flow when the requirement data is converted using the second conversion method in the automatic system design device 100 according to the first embodiment will be described. As shown in FIG. 9, first, the system requirements concretization unit 101 uses the graph conversion unit 1011 to apply a view concretization pattern to convert the pre-update view into a post-update view, and outputs the converted post-update view together with the requirements data to the requirements data update unit 103 (step S111).

[0040] After that, the requirement data update unit 103 reflects the contents of the updated view in the requirement data, and outputs the requirement data in which the contents of the updated view are reflected to the system requirement instantiation unit 101 (step S112). This converts the requirement data.

[0041] The automatic system design device 100 according to the first embodiment will be described in detail below. <Perspective Model> First, a plurality of viewpoint models prepared in advance in the viewpoint model DB 105 will be described. As described above, a viewpoint model is a model that specifies a method for converting requirements data into a graph that provides another expression of the system requirements expressed by the requirements data. In other words, a viewpoint model is a model that indicates information on how to convert and display requirements data.

[0042] The viewpoint models are manually generated according to purposes such as "virus countermeasures," "application deployment," "NW (Network) continuity," and "service-to-service cooperation," and are registered in advance in the viewpoint model DB 105. Note that the viewpoint models may be customized as necessary even after they are registered in the viewpoint model DB 105.

[0043] A viewpoint model to be referred to for view generation (i.e., the above-mentioned "selected viewpoint model") is selected by the system requirement specification unit 101. The viewpoint model selected by the system requirement specification unit 101 is provided as an input to the view generation unit 102 from the viewpoint model DB 105.

[0044] Among such viewpoint models, one viewpoint model includes node transformation mapping and edge transformation mapping, both of which transform substructures in requirements data into entities that are nodes or edges.

[0045] Of these, node conversion mapping converts a partial structure in the requirements data into a node. With reference to FIG. 10, an example of "AppContainer" mapping will be described as an example of node conversion mapping. In the example of FIG. 10, the partial structure to the left of the arrow in the requirements data (hereinafter referred to as the converted structure as appropriate) is converted into the node "AppContainer" by "AppContainer" mapping. Note that the condition for node conversion mapping is that there is only one node specified as "target". Furthermore, one node having the same ID (Identity) as the "target" is generated by node conversion mapping.

[0046] Moreover, edge conversion mapping converts a partial structure in the requirement data into an edge. With reference to FIG. 11, an example of "join" mapping, which is an example of edge conversion mapping, will be described. In the example of FIG. 11, the conversion structure on the left side of the arrow included in the requirement data is converted into an edge by "join" mapping. The image is converted to TIFF0007600748000001.tif833. Note that the condition for edge conversion mapping is that there must be one node specified by "start" and one node specified by "end". In addition, the edge conversion mapping creates an edge from the node specified by "start" to the node specified by "end".

[0047] Hereinafter, the type generated as a result of mapping is called the generated type of the mapping. In the example of FIG. 10, the node “AppContainer” is the generated type, and in the example of FIG. 11, the edge TIFF0007600748000002.tif833 is the generated type. These generated types will be added as entities to the view.

[0048] Furthermore, the mapping can have property mapping information indicating the correspondence between the property associated with the entity in the requirement data and the property associated with the entity in the view. An example of the property of the "AppContainer" mapping will be described with reference to FIG. 12. The property associated with the entity on the left side of the arrow in the requirement data and the property associated with the entity on the right side of the arrow in the view are in one-to-one correspondence. In the example of FIG. 12, the property "IPAddress" of the node "Container" on the left side of the arrow is in one-to-one correspondence with the property "IPAddress" of the node "AppContainer" on the right side of the arrow. Also, the property "port" of the node "App" on the left side of the arrow is in one-to-one correspondence with the property "port" of the node "AppContainer" on the right side of the arrow.

[0049] <Operation when loading viewpoint model> Next, the operation when reading the viewpoint model will be described. First, an example of the flow of operations when reading a viewpoint model will be described with reference to FIG.

[0050] As shown in FIG. 13, first, the viewpoint model reading unit 104 reads a viewpoint model that has been manually generated (step S201), and adds each of the node conversion mappings and edge conversion mappings contained in the read viewpoint model to the viewpoint model DB 105 (step S202). Next, the viewpoint model reading unit 104 adds an "abstract type stub(t)" corresponding to the generated type t of each mapping to the type information DB 106 (step S203).

[0051] After that, the viewpoint model reading unit 104 adds a "structure generation pattern" corresponding to each mapping to the graph conversion rule DB 107 as a requirement data instantiation pattern (step S204).

[0052] Next, the "abstract type stub(t)" added to the type information DB 106 will be described. First, an example of an "abstract type stub(t)" corresponding to a generated type t of an "AppContainer" mapping will be described with reference to Fig. 14. In the example of Fig. 14, the generated type t of the "AppContainer" mapping is a node type "AppContainer". The abstract type stub(t) corresponding to this generated type t is a node type abstract type stub(AppContainer).

[0053] Next, an example of an "abstract type stub(t)" corresponding to the generation type t of the "join" mapping will be described with reference to Fig. 15. In the example of Fig. 15, the generation type t of the "join" mapping is the edge type "join". The abstract type stub(t) corresponding to this generation type t is the edge type abstract type stub(join).

[0054] Next, a special case of the "abstract type stub(t)" will be described with reference to Figs. The "AppContainer" mapping in FIG. 10 and the "join" mapping in FIG. 11 are not one-to-one mappings in which the entities before and after the conversion have a one-to-one correspondence. In contrast, the "Service" mapping in FIG. 16 and the "join" mapping in FIG. 17 are one-to-one mappings.

[0055] In the case of one-to-one mapping, the viewpoint model reading unit 104 does not add the abstract type stub(t) to the type information DB 106, but instead reads the corresponding original generated type t orig Using the formula "stub(t):=t orig In the example of FIG. 16, the abstract type stub(t) is defined as stub(Service) := App, and in the example of FIG. 17, it is defined as stub(join) := os. In this case, the viewpoint model reading unit 104 may define "stub(t):=t orig " is not added to the type information DB 106. However, if another mapping is defined for the same generation type, the viewpoint model reading unit 104 cannot perform the above definition.

[0056] Next, a "structure generation pattern" that is added to the graph transformation rule DB 107 as a requirement data instantiation pattern will be described. First, an example of a structure generation pattern corresponding to the "AppContainer" mapping will be described with reference to Fig. 18. As shown in Fig. 18, a stub(AppContainer) resolution pattern corresponding to a pattern obtained by reversing the conversion direction of the "AppContainer" mapping becomes the structure generation pattern.

[0057] Next, an example of a structure generation pattern corresponding to the "join" mapping will be described with reference to Fig. 19. As shown in Fig. 19, a stub(join) solution pattern corresponding to a pattern obtained by reversing the conversion direction of the "join" mapping becomes a structure generation pattern.

[0058] Next, with reference to FIG. 20, an example of handling of mapping information of a property of a mapping will be described. In the example of FIG. 20, the "AppContainer" mapping has the mapping information of the property shown in FIG. 12. The structure generation pattern corresponding to the "AppContainer" mapping is a pattern similar to the stub(AppContainer) resolution pattern shown in FIG. 18. Therefore, the viewpoint model reading unit 104 transfers the mapping information of the property of the "AppContainer" mapping to "constraint" of the stub(AppContainer) resolution pattern. At this time, the viewpoint model reading unit 104 converts the arrow (→) representing the mapping to an equal sign (==). In addition, the viewpoint model reading unit 104 eliminates meaningless constraints. In the example of FIG. 20, the constraint "{1}.IPAddress == {1}.IPAddress" is eliminated.

[0059] Next, with reference to Figs. 21 to 23, examples of combinations of mapping, "abstract type stub(t)" corresponding to the generation type t of the mapping, and "structure generation pattern" corresponding to the mapping will be described.

[0060] Fig. 21 shows an example of one-to-one mapping. In the example of Fig. 21, the "App" mapping is one-to-one mapping. Therefore, the viewpoint model reading unit 104 defines "stub(App) := App", but does not add this to the type information DB 106 as an abstract type stub(t). Furthermore, since the viewpoint model reading unit 104 does not add the abstract type stub(t), it does not add a structure generation pattern to the graph conversion rule DB 107.

[0061] FIG. 22 shows an example in which multiple mappings exist for one generation type. In the example of FIG. 22, two mappings, "Base" mapping (1) and "Base" mapping (2), exist for the node "Base", which is a generation type. Therefore, the viewpoint model reading unit 104 adds an abstract type stub(Base) corresponding to the node "Base" to the type information DB 106. In addition, the viewpoint model reading unit 104 adds a structure generation pattern including a stub(Base) solution pattern 1 corresponding to the "Base" mapping (1) and a stub(Base) solution pattern 2 corresponding to the "Base" mapping (2) to the graph conversion rule DB 107 as a requirement data instantiation pattern.

[0062] Fig. 23 shows an example of a mapping including a node of a parent class of a certain node. In the example of Fig. 23, the node "Field" included in the "join" mapping corresponds to the parent class of the node "Building" and the node "Cloud". The viewpoint model reading unit 104 adds an abstract type stub(join) corresponding to the generation type of the "join" mapping to the type information DB 106. In addition, the viewpoint model reading unit 104 adds a structure generation pattern, which is a stub(join) solution pattern corresponding to the "join" mapping, to the graph conversion rule DB 107 as a requirement data instantiation pattern.

[0063] <Forward transformation> Next, a description will be given of a conversion operation for converting requirement data into a view (pre-update view) by the view generating unit 102. Hereinafter, this conversion will be appropriately referred to as a forward conversion.

[0064] 24 and 25, an example of the flow of the forward transformation operation by the view generation unit 102 will be described. Here, it is assumed that a viewpoint model has already been selected by the system requirement specification unit 101, and the selected viewpoint model has been notified to the view generation unit 102. As shown in FIG. 24 and FIG. 25, first, the view generator 102 receives requirement data t ALL (Step S301). Next, the view generator 102 generates an empty view v and an empty mapping table T (step S302). ALL The entities in the requirements data are listed in the Mapped From column. ALL A table in which an entity in the view that corresponds to an entity in the view is represented in the mapped column of the same row.

[0065] Next, the view generation unit 102 selects one node conversion mapping for which the following steps S304 to S306 have not been performed (step S303) from the viewpoint model selected by the system requirement specification unit 101. Then, the view generation unit 102 performs the following steps S304 to S306 for the node conversion mapping selected in step S303.

[0066] That is, the view generator 102 generates the requirement data t ALL Then, the view generating unit 102 extracts all the structures t that match the transformation structure of the node transformation mapping selected in step S303 (the structure on the left side of the arrow of the node transformation mapping). Then, the view generating unit 102 extracts all the nodes C t Generate node C t is added to the view v (step S304). For example, if a structure t matches a transformation structure on the left side of an arrow of a node transformation mapping, the node on the right side of the arrow of the node transformation mapping is the node C corresponding to the structure t. t It becomes.

[0067] Next, for each structure t that matches the conversion structure in step S304, the view generating unit 102 selects an entity e that will be a target node from among the entities e included in the structure t. Then, the view generating unit 102 adds the selected entity e to the mapping source column of the mapping table T (step S305).

[0068] Next, for each entity e added to the mapping source column of the mapping table T in step S305, the view generating unit 102 generates a node C t is added to the mapping destination column of the mapping table T and to the same row as the entity e (step S306).

[0069] Next, the view generation unit 102 judges whether or not there is a node conversion mapping for which steps S304 to S306 have not been performed in the viewpoint model selected by the system requirement specification unit 101 (step S307). If there is a node conversion mapping for which steps S304 to S306 have not been performed (YES in step S307), the process returns to step S303.

[0070] On the other hand, if there is no node conversion mapping for which steps S304 to S306 have not been performed (NO in step S307), then the view generation unit 102 selects one edge conversion mapping for which steps S309 to S311 have not been performed (step S308) from the viewpoint model selected by the system requirement specification unit 101. Then, the view generation unit 102 performs the following steps S309 to S311 for the edge conversion mapping selected in step S308.

[0071] That is, the view generator 102 generates the requirement data t ALL Then, the view generating unit 102 extracts all the structures t that match the transformation structure of the edge transformation mapping selected in step S308 (the structure on the left side of the arrow of the edge transformation mapping). Generate TIFF0007600748000003.tif1017 and the generated edges TIFF0007600748000004.tif1017 is added to view v (step S309). For example, if structure t matches a transformation structure on the left side of an arrow of an edge transformation mapping, then the edge on the right side of the arrow of the edge transformation mapping is the edge corresponding to structure t. The result is TIFF0007600748000005.tif1017.

[0072] Next, for each structure t that matches the converted structure in step S309, the view generating unit 102 adds the entity e included in the structure t to the mapping source column of the mapping table T (step S310).

[0073] Next, for each entity e added to the mapping source column of the mapping table T in step S310, the view generating unit 102 generates an edge TIFF0007600748000006.tif1017 is added to the mapping destination column of mapping table T and to the same row as entity e (step S311).

[0074] Next, the view generation unit 102 judges whether or not there is an edge conversion mapping for which steps S309 to S311 have not been performed in the viewpoint model selected by the system requirement specification unit 101 (step S312). If there is an edge conversion mapping for which steps S309 to S311 have not been performed (YES in step S312), the process returns to step S308.

[0075] On the other hand, if there is no node conversion mapping for which steps S309 to S311 have not been performed (NO in step S312), then the view generation unit 102 determines the view v and the mapping table T, and outputs the determined view v as the pre-update view v0 to the system requirements concretization unit 101 (step S313).

[0076] Next, a specific example of the forward conversion operation shown in FIGS. 24 and 25 will be described with reference to FIGS. First, with reference to FIG. 26, a specific example of the operations in steps S301 and S302 shown in FIG. 24 will be described.

[0077] In step S301, the view generator 102 receives requirement data t as shown in FIG. 26 from the system requirement instantiation unit 101. ALL Enter. Furthermore, in step S302, the view generator 102 generates an empty view v and an empty mapping table T as shown in FIG.

[0078] Next, a specific example of the operations in steps S303 to S306 shown in FIG. 24 will be described with reference to FIGS. In step S303, the view generator 102 selects one node conversion mapping for which steps S304 to S306 have not been performed from the viewpoint model selected by the system requirement instantiation unit 101. In the example of FIG. 27, ALL The node “App1” in the requirement data t matches the conversion structure of the node conversion mapping selected in step S303. ALL The node “APP1” in the is the target node in the conversion structure of the node conversion mapping.

[0079] Therefore, in step S304, the view generator 102 ALL In this case, the view generating unit 102 generates a node “App1” corresponding to the node “App1” in the view v, and adds the generated node “App1” to the view v. At this time, the view generating unit 102 adds the ID of the node “App1” in the view v to the requirement data t ALL The view generator 102 also converts the ID of the requirement data t ALLThe property of the node “App1” in the view v (here, “port:80”) is set to the property of the node “App1” in the view v.

[0080] In step S305, the view generator 102 also ALL The target node “App1” in the table is added to the mapping source column of the mapping table T as an entity e. In step S306, the view generator 102 also ALL The node “App1” in view v that corresponds to the node “App1” in the view v is a mapping destination column of the mapping table T and is also a requirement data t ALL Add it to the same row as entity e, which is the node “App1” in

[0081] FIG. 28 shows an example of a view v and a mapping table T after steps S304 to S306 have been performed for all node transformation mappings included in the viewpoint model.

[0082] Next, a specific example of the operations in steps S308 to S311 shown in FIG. 25 will be described with reference to FIGS. 29 and 30. FIG. In step S308, the view generator 102 selects one edge conversion mapping for which steps S309 to S311 have not been performed from the viewpoint model selected by the system requirement instantiation unit 101. In the example of FIG. 29, ALL The structure C101 in matches the transformation structure of the edge transformation mapping selected in step S308.

[0083] Therefore, in step S309, the view generator 102 ALL The edge corresponding to structure C101 in Generate TIFF0007600748000007.tif1043 and the generated edges TIFF0007600748000008.tif1043 is added to view v. At this time, if the edge transformation mapping has property mapping information, the property is processed in the same manner as described in FIG.

[0084] In step S310, the view generator 102 also ALL An entity e included in the structure C101 in is added to the mapping source column of the mapping table T. In step S311, the view generator 102 generates the requirement data t ALL The edges in view v corresponding to each entity e in structure C101 in TIFF0007600748000009.tif1043 is a mapping destination column of mapping table T and is also a requirement data ALL Add it to the same row as each entity e contained in the structure C101 in the table.

[0085] An example of FIG. 30, which is different from FIG. 29, will be described. In the example of FIG. 30, the requirement data t ALL The structure C102 in matches the transformation structure of the edge transformation mapping selected in step S308.

[0086] Therefore, in step S309, the view generator 102 ALL The edge corresponding to structure C101 in Generate TIFF0007600748000010.tif1043 and the generated edges Add TIFF0007600748000011.tif1043 to view v.

[0087] In step S310, the view generator 102 also ALL An entity e included in the structure C102 in the table is added to the mapping source column of the mapping table T. In addition, in step S311, the view generation unit 102 generates an edge in the view v corresponding to each entity e included in the structure C102. TIFF0007600748000012.tif1043 is a mapping destination column of mapping table T and is also a requirement data ALL Add it to the same row as each entity e contained in the structure C102 in the structure C102.

[0088] In the mapping table T shown in FIG. ALL Entities contained in structure C102 in Edges to which TIFF0007600748000013.tif961 is mapped TIFF0007600748000014.tif1043 has already been added.

[0089] Fig. 31 shows an example of a view v and a mapping table T after the forward transformation operation shown in Fig. 24 and Fig. 25 is completed. The view v shown in Fig. 31 is output to the system requirement instantiation unit 101 as a pre-update view v0.

[0090] <Reverse conversion> Next, a description will be given of a conversion operation for converting a view (updated view) into requirement data by the requirement data update unit 103. Hereinafter, this conversion will be referred to as a reverse conversion as appropriate. First, an example of the flow of the forward conversion operation by the requirement data update unit 103 will be described with reference to FIGS.

[0091] As shown in FIG. 32 and FIG. 33, first, the requirement data update unit 103 inputs the updated view v1 updated by the system requirement instantiation unit 101 from the system requirement instantiation unit 101, and also inputs the requirement data t ALL (Step S401).

[0092] Next, the requirement data update unit 103 updates the requirement data t ALL, and obtains the pre-update view v0 and the mapping table T (step S402). Here, it is assumed that the system requirement instantiation unit 101 has already selected a viewpoint model, and notified the requirement data update unit 103 of the selected viewpoint model. ALL The forward transformation above has already been performed in the view generation unit 102. Therefore, step S402 may be replaced with an operation of acquiring the pre-update view v0 and the mapping table T from the view generation unit 102.

[0093] Next, the requirement data update unit 103 compares the pre-update view v0 with the post-update view v1, and calculates all the add operations (ADD e1:t1, ADD e2:t2, ...) and all the delete operations (DEL e1:t1, DEL e2:t2, ...) performed on the pre-update view v0 (step S403). Note that the add operation is an operation of adding an entity e to the pre-update view v0, and the delete operation is an operation of deleting an entity e from the pre-update view v0.

[0094] Next, the requirement data update unit 103 selects one of the adding operations calculated in step S403 for which the following step S405 has not been performed (step S404). Then, the requirement data update unit 103 performs the following step S405 for the adding operation selected in step S404.

[0095] That is, the requirement data update unit 103 updates all entities e' included in the substructure t(e) corresponding to the entity e added by the addition operation selected in step S404 to the requirement data t ALL (Step S405). For example, if entity e is the entity on the right side of a mapping arrow, the structure on the left side of the mapping arrow becomes the substructure t(e) corresponding to entity e. In other words, if entity e is the entity on the left side of a structure generation pattern arrow, the structure on the right side of the structure generation pattern arrow becomes the substructure t(e) corresponding to entity e.

[0096] Next, the requirement data update unit 103 judges whether or not there is an addition operation for which step S405 has not been performed among the addition operations calculated in step S403 (step S406). If there is an addition operation for which step S405 has not been performed (YES in step S406), the process returns to step S404.

[0097] On the other hand, if there is no adding operation for which step S405 has not been performed (NO in step S406), then the requirement data updating unit 103 selects one deleting operation for which step S408 has not been performed from among the deleting operations calculated in step S403 (step S407).The requirement data updating unit 103 then performs step S408 for the deleting operation selected in step S407.

[0098] That is, the requirement data updating unit 103 checks all entities e' included in the substructure t(e) corresponding to the entity e deleted by the delete operation selected in step S407 in the mapping source column of the mapping table T. For example, if the entity e is the entity on the right side of a mapping arrow, the structure on the left side of the mapping arrow becomes the substructure t(e) corresponding to the entity e. In other words, if the entity e is the entity on the left side of a structure generation pattern arrow, the structure on the right side of the structure generation pattern arrow becomes the substructure t(e) corresponding to the entity e. Then, for each of the confirmed entities e', the requirement data updating unit 103 deletes the entity e from the mapping destination column of the mapping table T and from the same row as the entity e' (step S408).

[0099] Next, the requirement data update unit 103 judges whether or not there is a deletion operation for which step S408 has not been performed among the deletion operations calculated in step S403 (step S409). If there is a deletion operation for which step S408 has not been performed (YES in step S409), the process returns to step S407.

[0100] On the other hand, if there is no delete operation that has not been performed in step S408 (NO in step S409), the requirement data update unit 103 next checks the entities e' whose mapping destination columns in the mapping table T have become empty. Then, the requirement data update unit 103 adds all the checked entities e' to the requirement data t ALL (Step S410).

[0101] Next, the requirement data update unit 103 refers to the mapping table T and updates the property settings of the updated view v1 with the requirement data t ALL (step S411). After that, the requirement data update unit 103 updates the requirement data t ALL Confirm the confirmed requirements data t ALL The updated requirement data ALL to the system requirement instantiation section 101 (step 412).

[0102] Next, a specific example of the reverse direction conversion operation shown in FIGS. 32 and 33 will be described with reference to FIGS. First, with reference to FIG. 34, a specific example of the operation of step S401 shown in FIG. 32 will be described.

[0103] In step S401, the requirement data update unit 103 receives, for example, requirement data t as shown in FIG. ALL Enter. Furthermore, the requirement data update unit 103 receives, for example, an updated view v1 as shown in Fig. 34 from the system requirement instantiation unit 101. In this updated view v1, the following operations are performed on the pre-update view v0. -Delete nodes “App1” and “App2” Edge Delete TIFF0007600748000015.tif1043 -Added node “App6” Edge Add TIFF0007600748000016.tif1043 Update the port property

[0104] Next, a specific example of the operation of step S402 shown in FIG. 32 will be described with reference to FIG. In step S402, the requirement data update unit 103 updates the requirement data t ALL As a result, the requirement data update unit 103 obtains, for example, the pre-update view v0 and the mapping table T as shown in FIG.

[0105] Next, a specific example of the operation in step S403 shown in FIG. 32 will be described with reference to FIG. In step S403, the requirement data update unit 103 compares the pre-update view v0 and the post-update view v1, for example, as shown in Fig. 36. Then, based on the comparison result, the requirement data update unit 103 calculates all the addition operations (ADD e1:t1, ADD e2:t2, ...) and all the deletion operations (DEL e1:t1, DEL e2:t2, ...) performed on the pre-update view v0. As a result, the requirement data update unit 103 obtains, for example, the addition operations and deletion operations as shown in Fig. 36.

[0106] Next, a specific example of the operations in steps S404 and S405 shown in FIG. 32 will be described with reference to FIGS.

[0107] In step S404, the requirement data update section 103 selects an adding operation for which step S405 has not been performed from among the adding operations calculated in step S403. In the example of Fig. 37, the following adding operations are selected. -Added node “App6”

[0108] In this case, in the next step S405, the requirement data update unit 103 updates the node “App6”, which is the entity e′ included in the substructure t(e) corresponding to the node “App6”, to the requirement data t ALL Add to. At this time, the requirement data update unit 103 updates the requirement data t ALL Set the property (here, port: 2030) for the node “App6” added to the “App6” list.

[0109] Then, it is assumed that the process returns to step S404. In this case, in step S404, the requirement data update unit 103 selects another adding operation that has not been performed in step S405 from among the adding operations calculated in step S403. In the example of FIG. 38, the following adding operations are selected. Edge Add TIFF0007600748000017.tif1043

[0110] In this case, in the next step S404, the requirement data update unit 103 Edge that is entity e' included in substructure t(e) corresponding to TIFF0007600748000018.tif1043 TIFF0007600748000019.tif1158 is the requirement data t ALL Add to.

[0111] Next, a specific example of the operations in steps S407 and S408 shown in FIG. 33 will be described with reference to FIGS. In step S407, the requirement data update section 103 selects one deletion operation for which step S408 has not been performed, from among the deletion operations calculated in step S403. Furthermore, in step S408, the requirement data updating unit 103 checks all entities e' included in the substructure t(e) corresponding to the entity e deleted by the delete operation selected in step S407, in the mapping source column of the mapping table T. Then, for each of the confirmed entities e', the requirement data updating unit 103 deletes the entity e from the mapping destination column of the mapping table T and from the same row as the entity e'.

[0112] FIG. 40 shows an example of a mapping table T after performing step S408 for all delete operations calculated in step S403, i.e., after deleting all applicable entities e, and FIG. 39 shows an example of a mapping table T before deleting all applicable entities e.

[0113] Next, a specific example of the operation of step S410 shown in FIG. 33 will be described with reference to FIGS. In step S410, the requirement data update unit 103 checks an entity e' for which the mapping destination column in the mapping table T has become empty.

[0114] For example, in the example of FIG. 40, the column to which the following entity e' is mapped in the mapping table T is empty. Node “App1” Node “App2” Node “Server1” Edge TIFF0007600748000020.tif1163 Edge TIFF0007600748000021.tif1164 Edge TIFF0007600748000022.tif1164 Edge TIFF0007600748000023.tif963

[0115] Therefore, the requirement data update unit 103 updates all entities e' whose mapping destination columns are now empty, as shown in FIG. 41, to the requirement data t ALL Delete from. In FIG. 41, entities (edges) TIFF0007600748000024.tif953 has been deleted in conjunction with the deletion of the node.

[0116] Next, a specific example of the operation of step S411 shown in FIG. 33 will be described with reference to FIGS. In step S411, the requirements data update unit 103 refers to the mapping table T. When the entity e', whose mapping destination column is now empty, is deleted from the mapping table T shown in FIG. 40, the table becomes as shown in FIG. 42. As a result of referring to the mapping table T shown in FIG. 42, the requirements data update unit 103 determines that each entity in the updated view v1 is a member of the requirements data t ALL Therefore, as shown in FIG. 43, the requirement data update unit 103 updates the properties of the entities in the updated view v1 to those in the requirement data t ALL In step S405 described in FIG. 37, the requirement data t ALL The properties of the node “App6” in the table have already been set. Therefore, the properties of the requirement data t ALL For the node "App6" in the "AppList" section, there is no need to set properties in step S411.

[0117] <System Requirements Specifications Department> Next, the system requirement instantiation unit 101 will be described in detail. First, with reference to FIG. 44, an example of a schematic operational flow of an automatic design process by the system requirement instantiation unit 101 will be described.

[0118] As shown in FIG. 44, first, the system requirement instantiation unit 101 accepts an input of requirement data of configuration requirements described as abstract configurations and a list of viewpoint models from an input / output device (not shown) (step S501).

[0119] Next, the system requirement concretization unit 101 generates a search tree whose root is a node (hereinafter called a "draft") of the search tree consisting of the accepted requirement data and auxiliary information (described later) related to the viewpoint model (step S502). The system requirement concretization unit 101 records the generated search tree.

[0120] Next, the system requirement specification unit 101 checks whether the search for all the drafts in the search tree is completed (step S503). If the search is completed (YES in step S503), the system requirement specification unit 101 ends the entire processing of the automatic design process.

[0121] If the search has not been completed for all the drafts in the search tree (NO in step S503), the system requirement instantiation unit 101 selects one draft to search next (step S504). As a method for selecting the draft to search next, the system requirement instantiation unit 101 can use a method such as random selection, depth-first selection, or breadth-first selection.

[0122] Next, the system requirement concretization unit 101 checks whether or not the concretization attempt has been completed for all abstract entities included in the selected draft (step S505). The abstract entities checked in step S505 include not only the abstract entities in the requirement data, but also the abstract entities in each view (pre-update view) generated from the requirement data. If the concretization attempt has been completed for all abstract entities (YES in step S505), the system requirement concretization unit 101 performs the process of step S503 again.

[0123] If the concretization attempts for all abstract entities have not been completed (NO in step S505), the system requirement concretization unit 101 selects an abstract entity to be concretized from among the abstract entities that have not been completed (step S506). As a method for selecting an abstract entity to be concretized, the system requirement concretization unit 101 can use a method such as random selection, depth-first selection, or breadth-first selection.

[0124] Next, the system requirement concretization unit 101 uses the selected abstract entity to be concretized as a key to inquire about graph conversion rules that can be used to convert the abstract entity to be concretized from the graph conversion rule DB 107. Next, the system requirement concretization unit 101 acquires the graph conversion rules from the graph conversion rule DB 107 (step S507).

[0125] Next, the system requirement concretization unit 101 checks whether all the options of the concretization method described in the acquired graph conversion rule have been tried (step S508). If all the options have been tried (YES in step S508), the system requirement concretization unit 101 performs the process of step S503 again.

[0126] If all of the concretization method options have not been tried (NO in step S508), the system requirement concretization unit 101 selects an option indicating the concretization method to be applied from among the unselected options. As a method for selecting the concretization method, the system requirement concretization unit 101 can use a method such as random selection, depth-first selection, or breadth-first selection.

[0127] Next, the system requirement concretization unit 101 converts a part of the configuration including the selected abstract entity according to the conversion rule indicated by the selected concretization method. At this time, if the abstract entity is an abstract entity in the requirement data, the system requirement concretization unit 101 uses the graph conversion unit 1011 to apply the requirement data concretization pattern to perform the above-mentioned conversion, and generates a new draft in which the requirement data in the draft selected in step S504 is converted by this conversion. On the other hand, if the abstract entity is an abstract entity in the view (pre-update view), the system requirement concretization unit 101 uses the graph conversion unit 1011 to apply the view concretization pattern to perform the above-mentioned conversion, and further uses the requirement data update unit 103 to reflect the contents of the converted view (post-update view) in the requirement data in the draft selected in step S504, thereby generating a new draft in which the draft selected in step S504 is converted.

[0128] Next, the system requirement instantiation unit 101 adds the generated new draft to the search tree as a child element of the draft selected in step S504. By executing the above processing, the system requirement instantiation unit 101 updates the search tree (step S509).

[0129] Furthermore, the system requirement instantiation unit 101 records, as additional information of the draft selected in step S504, that the instantiation method selected in step S509 has been applied to the abstract entity selected in step S506.

[0130] Furthermore, if all of the concretization methods have been applied to the abstract entity selected in step S506, the system requirement concretization unit 101 further records, as additional information of the draft, that all of the options have been tried for the abstract entity.

[0131] Furthermore, when it is recorded that all options have been tried for all abstract entities in the draft selected in step S504, the system requirement concretization unit 101 records, as additional information of the draft, that concretization has been tried for all abstract entities. In each of the judgment processes in steps S503, S505, and S508, the system requirement concretization unit 101 can use the recorded additional information of the draft.

[0132] Next, the system requirement concretization unit 101 checks whether all entities in the new draft generated by the conversion are concrete (step S510). The entities to be checked in step S510 include not only the entities in the requirement data, but also the entities in each view (pre-update view) generated from the requirement data. If the new draft includes an entity that is not concrete (NO in step S510), the system requirement concretization unit 101 performs the process of step S503 again.

[0133] If all entities included in the new draft are concrete (YES in step S510), the system requirements concretization unit 101 outputs the requirements data linked to the new draft generated in step S509 as concrete system configuration data to an input / output device not shown (step S511).

[0134] Next, a specific example of the automatic design process shown in FIG. 44 will be described with reference to FIGS. First, with reference to FIG. 45, a specific example of a node of a search tree generated and updated in the automated design process shown in FIG. 44 will be described.

[0135] In existing automated design processes, the nodes of the search tree contain only requirement data (see Figure 1). In contrast, the nodes of the search tree in the automated design process according to the first embodiment include, in addition to requirement data, the following two types of data related to each viewpoint model to be used, as shown in FIG. (1) View A view is a view generated from requirements data. (2) List of resolved entities A resolved entity is an entity in a view that has already been transformed using the view materialization pattern. FIG. 45 shows an example of nodes when the system request instantiating unit 101 selects two viewpoint models, "antivirus measures" and "application deployment."

[0136] Next, with reference to FIG. 46, a specific example of the operations in steps S505 and S510 shown in FIG. 44 will be described. In step S505, the system requirement instantiation unit 101 searches for an abstract entity for which an instantiation attempt has not been completed, and if such an abstract entity is found, performs the process of step S506. Also, in step S510, the system request instantiation unit 101 searches for a non-concrete entity (that is, an abstract entity), and if such an abstract entity is found, performs the process of step S503 again.

[0137] The abstract entity found in step S505 or S510 is selected as the abstract entity to be instantiated in the following step S506, and is transformed using the graph transformation rules in the following step S509.

[0138] Existing automated design processes only find abstract entities in the requirements data. In contrast, the automated design process according to the first embodiment finds the following two types of abstract entities: (1) Abstract entities within requirements data (2) Abstract entities in the view that are not in the list of resolved entities

[0139] For example, in the view shown in Fig. 46, the edge "protect" is assumed to be an abstract edge. In the example of Fig. 46, two edges "protect" are spanned. But one edge TIFF0007600748000025.tif976 has been marked as resolved. Therefore, in the example of FIG. 46, the abstract entity found by the system requirement instantiation unit 101 in step S505 or S510 is the other edge Only TIFF0007600748000026.tif977 will be displayed.

[0140] Next, a specific example of the operation of step S509 shown in FIG. 44 will be described with reference to FIGS. In step S509, the system requirement instantiation unit 101 uses the graph conversion unit 1011 to convert the requirement data by applying a requirement data instantiation pattern, or to convert the view (pre-update view) by applying a view instantiation pattern.

[0141] First, a specific example of the operation when the requirement data is converted using a requirement data instantiation pattern in step S509 shown in FIG. 44 will be described with reference to FIGS. 47 to 50.

[0142] When the system requirements instantiation unit 101 uses the graph conversion unit 1011 to apply a requirements data instantiation pattern to convert requirements data, it uses the view generation unit 102 to regenerate a view (pre-update view) from the converted requirements data.

[0143] The above-mentioned procedure for converting requirement data will be explained below step by step. Here, as shown in FIG. 47, the node to be processed in step S509 is the requirement data t 10 and requirement data t 10 From the viewpoint model of “virus protection”, a view v 20 and requirement data t 10 From the view v, generated using the "application deployment" perspective model 30 and

[0144] Step S509a: First, as shown in FIG. 48, the system requirement instantiation unit 101 converts the requirement data t 10 By applying the requirement data materialization pattern to the requirement data t 10 The requirement data 11 Convert to.

[0145] Step S509b: Next, as shown in FIG. 49, the system requirement instantiation unit 101 uses the view generation unit 102 to generate requirement data t 11From the viewpoint model of "virus protection", view v 21 In addition, the system requirement instantiation unit 101 uses the view generation unit 102 to regenerate the requirement data t 11 From the perspective model of "application deployment", view v 31 Regenerate the following.

[0146] Step S509c: Then, as shown in FIG. 50, the system requirement instantiation unit 101 creates a view v 20 List of resolved entities in view v 21 The system requirements concrete unit 101 inherits the list of resolved entities of the view v as it is. 30 List of resolved entities in view v 31 The list of resolved entities is carried over as is.

[0147] Next, with reference to FIGS. 51 to 56, a specific example of the operation when a view (pre-update view) is converted by applying a view instantiation pattern using graph conversion unit 1011 in step S509 shown in FIG. 44 will be described.

[0148] When the system requirements concretization unit 101 uses the graph conversion unit 1011 to apply a view concretization pattern to convert a view (pre-update view), it updates the list of resolved entities of the converted view (post-update view) and reflects the contents of the post-update view in the requirements data using the requirements data update unit 103. After that, the system requirements concretization unit 101 uses the view generation unit 102 to regenerate another view.

[0149] In this case, the view reification pattern can designate the transformed abstract entity in the transformed view (updated view) as "resolved" (simply add it to the list of resolved entities), as shown in Figure 51. In the example in Figure 51, the edge TIFF0007600748000027.tif977 can be added to the list of resolved entities.

[0150] The above-mentioned procedure for converting a view (pre-update view) will be explained step by step below. Here, as shown in FIG. 52, the node to be processed in step S509 is the requirement data t 40 and requirement data t 40 From the viewpoint model of “virus protection”, a view v 50 and requirement data t 40 From the view v, generated using the perspective model "application deployment" 60 and

[0151] Step S509A: First, as shown in FIG. 53, the system requirement instantiation unit 101 uses the graph conversion unit 1011 to convert the view v 50 By applying the view materialization pattern to 50 View V 51 In addition, the system requirement specification unit 101 converts the edge Add TIFF0007600748000028.tif976 to the list of resolved entities.

[0152] Step S509B: Next, as shown in FIG. 54, the system requirement instantiation unit 101 uses the requirement data update unit 103 to update the view v 51 The contents of the requirement data 40 By reflecting in the requirements data, 40 The requirement data 41 Convert to.

[0153] Step S509C: Next, as shown in FIG. 55, the system requirement instantiation unit 101 uses the view generation unit 102 to generate requirement data t 41 From the perspective model of "application deployment", view v 61 Regenerate the following.

[0154] Step S509D: Then, as shown in FIG. 56, the system requirement instantiation unit 101 creates a view v 60 List of resolved entities in view v 61 The list of resolved entities is carried over as is.

[0155] <Advantages of the First Embodiment> As described above, according to the first embodiment, the view generating unit 102 generates a view from the requirement data using a viewpoint model, and outputs the generated view as a pre-update view. The graph converting unit 1011 converts the requirement data or the pre-update view using a graph conversion rule. The requirement data updating unit 103 reflects the contents of the post-update view after the pre-update view is converted in the requirement data. The system requirement concretizing unit 101 converts the requirement data using the graph converting unit 1011, or converts the pre-update view into a post-update view using the graph converting unit 1011, and converts the requirement data by reflecting the contents of the post-update view in the requirement data using the requirement data updating unit 103. Then, the system requirement concretizing unit 101 outputs the requirement data as concrete system configuration data at a stage where the requirement data is sufficiently concretized.

[0156] In this way, according to the first embodiment, it is possible to generate a view from the requirements data that explicitly has requirements that are not expressed in the requirements data as edges or nodes. Furthermore, a mechanism is added that concretizes not only the requirements included in the requirements data, but also the requirements included in the view. This makes it possible to handle requirements that could not be expressed in the requirements data.

[0157] <Embodiment 2> Next, a configuration example of the automatic system design device 100A according to the second embodiment will be described with reference to Fig. 57. As shown in Fig. 57, the automatic system design device 100A according to the second embodiment includes a system requirement concretization unit 111, a view generation unit 112, and a requirement data update unit 113. The system requirement concretization unit 111 also includes a graph conversion unit 1111. Note that, although the graph conversion unit 1111 is provided inside the system requirement concretization unit 111 in Fig. 57, it may be provided outside the system requirement concretization unit 111.

[0158] The view generating unit 112 inputs requirement data, which is a graph expressing a system requirement, and also inputs a viewpoint model, which is a model that specifies a conversion method for converting the requirement data into a graph that gives another expression of the system requirement expressed by the requirement data. The view generating unit 112 generates a view, which is a graph obtained by converting the requirement data, using the viewpoint model, and outputs the generated view as a pre-update view. The view generating unit 112 corresponds to the view generating unit 102.

[0159] The graph conversion unit 1111 inputs the requirement data or the pre-update view, and also inputs graph conversion rules, which are data expressing rules for converting a substructure matching a specific structure into a more specific entity, for the requirement data or the pre-update view. The graph conversion unit 1111 converts the requirement data or the pre-update view using the graph conversion rules. The graph conversion unit 1111 corresponds to the graph conversion unit 1011.

[0160] The requirement data update unit 113 inputs requirement data and also inputs a post-update view which is a view obtained after the pre-update view is converted by the graph conversion unit 1111. The requirement data update unit 113 reflects the contents of the post-update view in the requirement data. The requirement data update unit 113 corresponds to the requirement data update unit 103.

[0161] The system requirement concretization unit 111 outputs system configuration data which is a graph in which the requirement data is concretized. At this time, the system requirement concretization unit 111 obtains the system configuration data by repeating the following steps: converting the requirement data by the graph conversion unit 1111, or converting a pre-update view into an updated view by the graph conversion unit 1111, and reflecting the contents of the updated view in the requirement data by the requirement data update unit 113. The system requirement concretization unit 111 corresponds to the system requirement concretization unit 101.

[0162] In this way, according to the second embodiment, it is possible to generate a view from the requirements data that explicitly has requirements that are not expressed in the requirements data as edges or nodes. Furthermore, a mechanism has been added that concretizes not only the requirements included in the requirements data, but also the requirements included in the view. This makes it possible to handle requirements that could not be expressed in the requirements data.

[0163] The graph conversion rule may include a requirement data instantiation pattern for converting requirement data and a view instantiation pattern for converting a pre-update view. The graph conversion unit 1111 may convert requirement data using the requirement data instantiation pattern, or convert a pre-update view using the view instantiation pattern.

[0164] Furthermore, when the system requirement instantiation unit 111 converts requirement data using the graph conversion unit 1111, the view generation unit 112 may regenerate a pre-update view from the converted requirement data.

[0165] Furthermore, in a situation where multiple pre-update views are generated from requirements data, the system requirements concretization unit 111 converts one of the multiple pre-update views into a post-update view using the graph conversion unit 1111, and the requirements data update unit 113 reflects the contents of the post-update view in the requirements data. In this case, when the requirements data is converted, the view generation unit 112 may re-generate pre-update views other than the one pre-update view from the converted requirements data.

[0166] Furthermore, the system requirement instantiation unit 111 may add the converted entities in the updated view to the list when the pre-update view is converted into the updated view by the graph conversion unit 1111. Furthermore, when the system requirement instantiation unit 111 subsequently converts the updated view again by the graph conversion unit 1111, it may convert a substructure that is not on the list in the updated view.

[0167] Furthermore, the requirements data update unit 113 may obtain a pre-update view and compare the pre-update view with the post-update view to calculate an add operation for adding an entity among the operations performed on the pre-update view. Then, the requirements data update unit 113 may add an entity corresponding to the entity added to the pre-update view by the add operation to the requirements data.

[0168] Furthermore, the requirements data updating unit 113 may further acquire a mapping table which is table data in which an entity in the requirements data is shown in a first column, and an entity in the pre-update view corresponding to the entity in the requirements data is shown in a second column of the same row. Furthermore, the requirements data updating unit 113 may calculate a delete operation for deleting an entity among the operations performed on the pre-update view by comparing the pre-update view with the post-update view. Then, the requirements data updating unit 113 may delete the entity deleted from the pre-update view by the delete operation from the second column of the mapping table, and delete from the requirements data the entity shown in the first column for which the second column of the same row is now empty.

[0169] <Embodiment 3> Next, an example of a hardware configuration of the automatic system design device 100B according to the third embodiment will be described with reference to Fig. 58. As shown in Fig. 58, the automatic system design device 100B according to the third embodiment includes a processor 120 and a memory 121.

[0170] The processor 120 may be, for example, a microprocessor, a micro processing unit (MPU), or a central processing unit (CPU). The processor 120 may include multiple processors. The memory 121 is configured by a combination of volatile memory and non-volatile memory. The memory 121 may include storage located away from the processor 120. In this case, the processor 120 may access the memory 121 via an I (Input) / O (Output) interface (not shown).

[0171] The automatic system design apparatuses 100, 100A according to the first and second embodiments described above may have a hardware configuration shown in Fig. 58. The system requirement concretization units 101, 111, the view generation units 102, 112, the requirement data update units 103, 113, and the viewpoint model reading unit 104 in the automatic system design apparatuses 100, 100A described above may be realized by the processor 120 reading and executing a program stored in the memory 121. Also, the viewpoint model DB 105, the type information DB 106, and the graph conversion rule DB 107 in the automatic system design apparatus 100 described above may be realized by the memory 121.

[0172] The above-mentioned program can be stored and provided to a computer using various types of non-transitory computer readable media. The non-transitory computer readable medium includes various types of tangible storage media. Examples of the non-transitory computer readable medium include magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), compact disc-ROMs (CD-ROMs), CD-recordables (CD-Rs), CD-rewritables (CD-R / Ws), semiconductor memories (e.g., mask ROMs, programmable ROMs (PROMs), erasable PROMs (EPROMs), flash ROMs, and RAMs). The program may be provided to a computer by various types of transitory computer readable media. Examples of the transitory computer readable medium include electric signals, optical signals, and electromagnetic waves. The transitory computer readable medium can provide the program to a computer via a wired communication path such as an electric wire and an optical fiber, or via a wireless communication path.

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

[0174] 100, 100A, 100B System Automatic Design Equipment 101,111 System Requirements Specifications Department 102,112 View Generation 103,113 Requirement Data Update Section 104 Viewpoint model reading unit 105 Viewpoint Model DB 106 Type information DB 107 Graph transformation rule database 120 processors 121 Memory

Claims

1. a view generator that inputs requirement data, which is a graph expressing a system requirement, and inputs a viewpoint model, which is a model that defines a conversion method for converting the requirement data into a graph that gives a different expression of the system requirement expressed by the requirement data, generates a view, which is a graph obtained by converting the requirement data using the viewpoint model, and outputs the generated view as a pre-update view; a graph conversion unit that inputs the requirement data or the pre-update view, and inputs graph conversion rules, which are data expressing rules for converting a substructure matching a specific structure into a more specific entity, for the requirement data or the pre-update view, and converts the requirement data or the pre-update view using the graph conversion rules; a requirements data update unit which inputs the requirements data and also inputs a post-update view which is a view obtained after the pre-update view is converted, and reflects the contents of the post-update view in the requirements data; a system requirement concretization unit that outputs system configuration data that is a graph in which the requirement data is concretized, Converting the requirement data by the graph conversion unit; or converting the pre-update view into the post-update view by the graph conversion unit, and reflecting the content of the post-update view in the requirement data by the requirement data update unit, thereby converting the requirement data; The system configuration data is obtained by repeating the steps. System automatic design device.

2. The graph transformation rule is a requirements data instantiation pattern for transforming the requirements data; and a view instantiation pattern for transforming the before-update view; The graph conversion unit is transforming the requirements data using the requirements data instantiation pattern, or transforming the pre-update view using the view instantiation pattern; The system automatic design apparatus according to claim 1.

3. The system requirement specification unit when the requirement data is converted by the graph conversion unit, the view generation unit regenerates the pre-update view from the converted requirement data.

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

4. The system requirement specification unit in a situation where a plurality of pre-update views are generated from the requirements data, when the requirements data is converted by converting one of the plurality of pre-update views into the post-update view by the graph conversion unit and reflecting the content of the post-update view in the requirements data by the requirements data update unit, the view generation unit regenerates the pre-update view other than the one of the plurality of pre-update views from the converted requirements data; The system automatic design apparatus according to any one of claims 1 to 3.

5. The system requirement specification unit when the graph transformation unit transforms the pre-update view into the post-update view, adding the transformed entities in the post-update view to a list; thereafter, when the updated view is converted again by the graph conversion unit, a substructure in the updated view that is not included in the list is converted; The system automatic design apparatus according to any one of claims 1 to 4.

6. The requirement data update unit Obtaining the pre-update view; Calculating an add operation that adds an entity among the operations performed on the pre-update view by comparing the pre-update view with the post-update view; adding, to the requirements data, an entity corresponding to the entity added to the pre-update view by the add operation; The system automatic design apparatus according to any one of claims 1 to 5.

7. The requirement data update unit obtain a mapping table, which is table data in which an entity in the requirements data is shown in a first column and an entity in the pre-update view corresponding to the entity in the requirements data is shown in a second column of the same row; Calculating a delete operation for deleting an entity among the operations performed on the pre-update view by comparing the pre-update view with the post-update view; removing from the second column of the mapping table any entities that were deleted from the pre-update view by the delete operation; Among the entities shown in the first column, an entity in which the second column of the same row is empty is deleted from the requirements data; The system automatic design apparatus according to claim 6.

8. An automatic system design method performed by an automatic system design device, comprising: a view generation step of inputting requirement data which is a graph expressing a system requirement and a viewpoint model which is a model defining a conversion method for converting the requirement data into a graph which gives another expression of the system requirement expressed by the requirement data, generating a view which is a graph obtained by converting the requirement data using the viewpoint model, and outputting the generated view as a pre-update view; a graph transformation step of inputting the requirement data or the pre-update view, and inputting graph transformation rules, which are data expressing rules for transforming a substructure matching a specific structure into a more specific entity, for the requirement data or the pre-update view, and transforming the requirement data or the pre-update view using the graph transformation rules; a requirements data update step of inputting the requirements data and inputting a post-update view which is a view obtained after the pre-update view is converted, and reflecting the contents of the post-update view in the requirements data, Transforming the requirements data by the graph transformation step; or converting the pre-update view into the post-update view in the graph conversion step, and reflecting the contents of the post-update view in the requirements data in the requirements data update step, thereby converting the requirements data; By repeating the above steps, system configuration data is obtained, which is a graph in which the requirement data is embodied. System automation design method.

9. On the computer, a view generation function for inputting requirement data, which is a graph expressing a system requirement, and inputting a viewpoint model, which is a model defining a conversion method for converting the requirement data into a graph giving a different expression of the system requirement expressed by the requirement data, generating a view, which is a graph obtained by converting the requirement data using the viewpoint model, and outputting the generated view as a pre-update view; a graph conversion function for inputting the requirement data or the pre-update view, and inputting graph conversion rules, which are data expressing rules for converting a substructure matching a specific structure into a more specific entity, for the requirement data or the pre-update view, and converting the requirement data or the pre-update view using the graph conversion rules; a requirements data update function for inputting the requirements data and inputting a post-update view, which is a view obtained after the pre-update view is converted, and reflecting the contents of the post-update view in the requirements data; a system requirement specification function that outputs system configuration data that is a graph in which the requirement data is specified; A program for achieving the above, In the system requirement specification function, Transforming the requirements data using the graph transformation function; or converting the pre-update view into the post-update view by the graph conversion function, and converting the requirements data by reflecting the contents of the post-update view in the requirements data by the requirements data update function; The system configuration data is obtained by repeating the steps. program.

Images