System requirements editing device, system requirements editing method, and program

Abstract

To allow a user to easily edit a system requirement.SOLUTION: A system requirement editing apparatus (100A) has: a requirement data management unit (121) for registering requirement data that is a graph expressing a system requirement; a view generating unit (122) for inputting the requirement data, inputting a viewpoint model that is a model prescribing a conversion method of converting the requirement data into a graph giving another expression of the system requirement expressed by the requirement data, generating a view that is a graph obtained by converting the requirement data by using the viewpoint model, and outputting the generated view as a view before updating; and a requirement data updating unit (123) for inputting the requirement data, inputting a view after updating that is a view after updating the view before updating, and reflecting contents of the view after updating in the requirement data.SELECTED DRAWING: Figure 38

Description

[Technical field]

[0001] The present disclosure relates to a system requirement editing device, a system requirement editing method, and a program. [Background technology]

[0002] There is technology that converts abstract system requirements that represent the configuration of computer systems, Internet of Things (IoT) systems, Information and Communication Technology (ICT) systems, etc., into concrete system configurations. For example, Patent Document 1 discloses a technology in which a designer edits graph-like system requirements consisting of nodes corresponding to system components and edges defining relationships between two nodes, and a system configuration derivation device converts the system requirements edited by the designer 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, according to the technique disclosed in Patent Document 1, a user (designer) edits system requirements. However, the system requirements edited by the user are graph-like system requirements consisting of nodes and edges, and the nodes corresponding to all the components included in the system requirements and the edges corresponding to the functional dependencies between them are integrated into a single graph.

[0005] Therefore, when a user edits large-scale or complex system requirements by leaving all nodes and edges as they are, it becomes difficult for the user to understand the true nature of the system requirements, which may lead to editing errors or oversights.

[0006] Therefore, an object of the present disclosure is to provide a system requirement editing device, a system requirement editing method, and a program that solve the above-mentioned problems and allow a user to easily edit system requirements. [Means for solving the problem]

[0007] According to one aspect, a system requirement editing device includes: a requirement data management unit in which requirement data, which is a graph expressing system requirements, is registered; a view generating unit that receives the requirements data and a viewpoint model that is a model that defines a conversion method for converting the requirements data into a graph that provides another expression of the system requirements expressed by the requirements data, generates a view that is a graph obtained by converting the requirements data using the viewpoint model, and outputs the generated view as a pre-update view; and a requirements data update section for inputting the requirements data and inputting a post-update view which is a view after the pre-update view has been updated, and for reflecting the contents of the post-update view in the requirements data.

[0008] A system requirement editing method according to one aspect includes: A system requirement editing method performed by a system requirement editing device, comprising: A step of registering requirement data which is a graph representing a system requirement; a step of inputting the requirements data and a viewpoint model which is a model defining a conversion method for converting the requirements data into a graph which gives another expression of the system requirements expressed by the requirements data, generating a view which is a graph obtained by converting the requirements data using the viewpoint model, and outputting the generated view as a pre-update view; The method includes a step of inputting the requirements data, inputting a post-update view which is a view after the pre-update view has been updated, and reflecting the contents of the post-update view in the requirements data.

[0009] A program according to one aspect comprises: On the computer, A procedure for registering requirements data, which is a graph that represents system requirements; a step of inputting the requirements data and a viewpoint model which is a model defining a conversion method for converting the requirements data into a graph which gives another expression of the system requirements expressed by the requirements data, generating a view which is a graph obtained by converting the requirements data using the viewpoint model, and outputting the generated view as a pre-update view; a step of inputting the requirements data and inputting a post-update view, which is a view after the pre-update view has been updated, and reflecting the contents of the post-update view in the requirements data; Execute the command. Effect of the Invention

[0010] According to the above-mentioned aspects, it is possible to provide a system requirement editing device, a system requirement editing method, and a program that allow a user to easily edit system requirements. [Brief description of the drawings]

[0011] [Figure 1] 1 is a block diagram showing a configuration example of a system requirement editing device according to a first embodiment. [Diagram 2] 3 is a diagram showing an example of a user interface of the system requirement editing device according to the first embodiment; FIG. [Diagram 3] 4 is a flowchart illustrating an example of a schematic operation flow of the system requirement editing device according to the first embodiment. [Figure 4] FIG. 11 is a diagram illustrating an example of node conversion mapping. [Diagram 5] FIG. 13 is a diagram illustrating an example of edge transformation mapping. [Figure 6] FIG. 13 is a diagram illustrating an example of properties of node transformation mapping. [Figure 7] 13 is a flowchart illustrating an example of an operation flow when a viewpoint model is read. [Figure 8] 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 9] 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 10] FIG. 13 is a diagram illustrating a special case of the abstract type stub(t). [Figure 11] FIG. 13 is a diagram illustrating a special case of the abstract type stub(t). [Figure 12] 11A to 11C are diagrams illustrating examples of structure generation patterns corresponding to node conversion mapping. [Figure 13] 11A and 11B are diagrams illustrating an example of a structure generation pattern corresponding to edge transformation mapping. [Figure 14] 13A and 13B are diagrams illustrating an example of how property mapping information of a node conversion mapping is handled. [Figure 15] 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 16] 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 17] 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 18] 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 19] 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 20] 20 is a diagram for explaining a specific example of the operations in steps S301 and S302 shown in FIG. 18. [Figure 21] 19 is a diagram illustrating a specific example of the operations in steps S303 to S306 shown in FIG. 18. FIG. [Figure 22] 19 is a diagram illustrating a specific example of the operations in steps S304 to S306 shown in FIG. 18. FIG. [Figure 23] 20 is a diagram illustrating a specific example of the operations in steps S308 to S311 shown in FIG. 19. [Figure 24] 20 is a diagram illustrating a specific example of the operations in steps S308 to S311 shown in FIG. 19. [Diagram 25] FIG. 20 illustrates an example of a view and mapping table after the forward transformation operations shown in FIGS. 18 and 19 are completed. [Figure 26] 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. [Figure 27] 13 is a flowchart illustrating an example of the flow of a reverse conversion operation by a requirement data update unit according to the first embodiment. [Figure 28] FIG. 27 is a diagram illustrating a specific example of the operation of step S401 shown in FIG. 26. [Figure 29] FIG. 27 is a diagram illustrating a specific example of the operation in step S402 shown in FIG. 26. [Diagram 30] FIG. 27 is a diagram illustrating a specific example of the operation in step S403 shown in FIG. 26. [Diagram 31] FIG. 27 is a diagram for explaining a specific example of the operations in steps S404 and S405 shown in FIG. 26. [Diagram 32] FIG. 27 is a diagram for explaining a specific example of the operations in steps S404 and S405 shown in FIG. 26. [Diagram 33] FIG. 28 is a diagram illustrating a specific example of the operations in steps S407 and S408 shown in FIG. 27. [Diagram 34] FIG. 28 is a diagram for explaining a specific example of the operations of steps S407, S408, and S410 shown in FIG. 27. [Diagram 35]FIG. 28 is a diagram illustrating a specific example of the operation of step S410 shown in FIG. 27. [Diagram 36] FIG. 28 is a diagram illustrating a specific example of the operation in step S411 shown in FIG. 27. [Figure 37] FIG. 28 is a diagram illustrating a specific example of the operation in step S411 shown in FIG. 27. [Figure 38] FIG. 11 is a block diagram showing a configuration example of a system requirement editing device according to a second embodiment. [Figure 39] FIG. 11 is a block diagram showing an example of a hardware configuration of a system requirement editing device according to a third embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0013] <Embodiment 1> <Configuration of First Embodiment> First, a configuration example of a system requirement editing device 100 according to the first embodiment will be described with reference to Fig. 1. As shown in Fig. 1, the system requirement editing device 100 according to the first embodiment includes a requirement data management unit 101, a view generation unit 102, and a requirement data update unit 103. It is assumed that a viewpoint model reading unit 201, a viewpoint model DB (Data Base) 202, a type information DB 203, and a concretization pattern DB 204 are provided outside the system requirement editing device 100 according to the first embodiment.

[0014] Requirement data is registered in the requirement data management unit 101. The requirement data is a graph expressing system requirements, and is composed of entities including nodes corresponding to system components and edges defining relationships between two nodes.

[0015] The view generation unit 102 inputs requirement data from the requirement data management unit 101 and also inputs a viewpoint model from the viewpoint model DB 202. The viewpoint model is a model that specifies a conversion method for converting requirement data into a graph that gives another expression of the system requirement expressed by the requirement data. In other words, the viewpoint model is a model that specifies a conversion method for converting a substructure in the requirement data into an entity. The view generation unit 102, for example, uses a user interface described later to display a list of viewpoint models to a user using the terminal 900, allows the user to select a desired viewpoint model from the multiple viewpoint models displayed in the list, and inputs the desired viewpoint model selected by the user (hereinafter referred to as a "selected aspect model") from the viewpoint model DB 202.

[0016] The view generator 102 also generates a view from the requirements data using the selected viewpoint model. The view is a graph obtained by converting the requirements data using the selected viewpoint model. The view generator 102 also outputs the generated view to the terminal 900 as a pre-update view.

[0017] The requirements data update unit 103 inputs requirement data from the requirements data management unit 101, and also inputs an updated view obtained by updating the pre-update view by a user from the terminal 900. The requirements data update unit 103 then reflects the contents of the updated view in the requirements data. In other words, the requirements data update unit 103 converts the updated view into requirements data.

[0018] <User Interface of First Embodiment> Next, an example of the user interface 110 of the system requirement editing device 100 according to the first embodiment will be described with reference to Fig. 2. The user interface 110 shown in Fig. 2 is used for exchanging information and data between the system requirement editing device 100 and the terminal 900, and includes a requirement editing screen 111, an edited content save button 112, and a viewpoint model selection interface 113.

[0019] A list of viewpoint models is displayed in the viewpoint model selection interface 113, for example, in a drop-down format. The user can select a viewpoint model to be used from the viewpoint models displayed in the list. When a viewpoint model is selected by the user, the view generation unit 102 generates a view from the requirement data using the selected viewpoint model. The generated view is displayed on the requirement editing screen 111 as a pre-update view.

[0020] The user can view the pre-update view and can edit the pre-update view on the requirement editing screen 111. Specifically, the user can add and delete nodes / edges as well as edit properties associated with the nodes / edges, as editing the pre-update view.

[0021] The save edited content button 112 is a button (software button) for saving the edited content edited on the requirement editing screen 111. When the user completes editing the pre-update view, he / she clicks the save edited content button 112. Then, the requirement data update unit 103 inputs the view edited by the user as a post-update view, and reflects the contents of the post-update view in the requirement data.

[0022] <Overview of Operation of First Embodiment> Next, with reference to FIG. 3, an example of a schematic operation flow of the system requirement editing device 100 according to the first embodiment will be described. As shown in FIG. 3, first, the view generation unit 102 inputs requirement data from the requirement data management unit 101, and also inputs a desired viewpoint model selected by the user (i.e., the above-mentioned "selected viewpoint model") from the viewpoint model DB 202 (step S101).

[0023] Next, the view generating unit 102 generates a view obtained by converting the requirement data using the selected viewpoint model, and outputs the generated view to the terminal 900 as a pre-update view (step S102).

[0024] The requirement data update section 103 inputs requirement data from the requirement data management section 101, and also inputs an updated view obtained by updating the pre-update view by the user from the terminal 900 (step S103). After that, the requirement data update unit 103 reflects the contents of the updated view in the requirement data (step S104).

[0025] The system requirement editing device 100 according to the first embodiment will be described in detail below.

[0026] <Perspective Model> First, a plurality of viewpoint models prepared in advance in the viewpoint model DB 202 will be described. As described above, each viewpoint model is a model that specifies a conversion 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.

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

[0028] A viewpoint model to be referenced for view generation (i.e., the above-mentioned "selected viewpoint model") is selected by the user. At this time, the view generation unit 102 may display a list of a plurality of viewpoint models registered in the viewpoint model DB 202 using a user interface 110 as shown in Fig. 2, and allow the user to select a viewpoint model (selected viewpoint model) from the viewpoint models displayed in the list. The viewpoint model selected by the user is provided as an input from the viewpoint model DB 202 to the view generation unit 102.

[0029] 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.

[0030] Of these, node conversion mapping converts a partial structure in the requirement data into a node. With reference to FIG. 4, an example of "AppContainer" mapping will be described. In the example of FIG. 4, the partial structure to the left of the arrow in the requirement 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, node conversion mapping generates one node having the same ID (Identity) as "target".

[0031] Moreover, edge conversion mapping converts a partial structure in the requirement data into an edge. With reference to FIG. 5, an example of "join" mapping, which is an example of edge conversion mapping, will be described. In the example of FIG. 5, 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 TIFF0007651863000001.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".

[0032] Hereinafter, the type generated as a result of mapping is called the generated type of the mapping. In the example of Figure 4, the node “AppContainer” is the generated type, and in the example of Figure 5, the edge TIFF0007651863000002.tif833 is the generated type. These generated types will be added as entities to the view.

[0033] Moreover, 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. 6. 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 have a one-to-one correspondence. In the example of FIG. 6, the property “IPAddress” of the node “Container” on the left side of the arrow has a 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 has a one-to-one correspondence with the property “port” of the node “AppContainer” on the right side of the arrow.

[0034] <Behavior when loading a 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.

[0035] As shown in FIG. 7, first, the viewpoint model reading unit 201 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 202 (step S202). Next, the viewpoint model reading unit 201 adds an "abstract type stub(t)" corresponding to the generated type t of each mapping to the type information DB 203 (step S203).

[0036] After that, the viewpoint model reading unit 201 adds a "structure generation pattern" corresponding to each mapping to the concrete pattern DB 204 (step S204). The "structure generation pattern" is used by a system configuration derivation device (not shown). Specifically, the system configuration derivation device (not shown) converts the system requirements edited by the system requirement editing device 100 into a concrete system configuration by using the "structure generation pattern".

[0037] Next, the "abstract type stub(t)" added to the type information DB 203 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. 8. In the example of Fig. 8, the generated type t of the "AppContainer" mapping is the node "AppContainer". The abstract type stub(t) corresponding to this generated type t is the node type abstract type stub(AppContainer).

[0038] 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. 9. In the example of FIG. 9, the generation type t of the "join" mapping is The resulting output is TIFF0007651863000003.tif833. The abstract type stub(t) corresponding to this generated type t is the edge-type abstract type stub(join).

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

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

[0041] Next, the "structure generation pattern" added to the concrete pattern DB 204 will be described. First, an example of a structure generation pattern corresponding to the "AppContainer" mapping will be described with reference to Fig. 12. As shown in Fig. 12, a stub(AppContainer) resolution pattern corresponding to a pattern obtained by reversing the conversion direction of the "AppContainer" mapping becomes the structure generation pattern.

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

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

[0044] Next, with reference to Figs. 15 to 17, 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.

[0045] Fig. 15 shows an example of one-to-one mapping. In the example of Fig. 15, the "App" mapping is one-to-one mapping. Therefore, the viewpoint model reading unit 201 defines "stub(App) := App", but does not add this to the type information DB 203 as an abstract type stub(t). In addition, since the viewpoint model reading unit 201 does not add the abstract type stub(t), it does not add a structure generation pattern to the concrete pattern DB 204.

[0046] FIG. 16 shows an example in which multiple mappings exist for one generation type. In the example of FIG. 16, two mappings, "Base" mapping (1) and "Base" mapping (2), exist for node "Base", which is a generation type. Therefore, the viewpoint model reading unit 201 adds an abstract type stub(Base) corresponding to the node "Base" to the type information DB 203. In addition, the viewpoint model reading unit 201 adds 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 concretization pattern DB 204 as structure generation patterns.

[0047] Fig. 17 shows an example of a mapping including a node of a parent class of a certain node. In the example of Fig. 16, the node "Field" included in the "join" mapping corresponds to the parent class of the nodes "Building" and "Cloud". The viewpoint model reading unit 201 adds an abstract type stub(join) corresponding to the generation type of the "join" mapping to the type information DB 203. In addition, the viewpoint model reading unit 201 adds a stub(join) solution pattern corresponding to the "join" mapping to the concrete pattern DB 204 as a structure generation pattern.

[0048] <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.

[0049] First, an example of the flow of the forward transformation operation by the view generation unit 102 will be described with reference to Fig. 18 and Fig. 19. Here, it is assumed that a viewpoint model has already been selected by the user. As shown in FIG. 18 and FIG. 19, first, the view generating unit 102 receives the 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.

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

[0051] 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.

[0052] 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).

[0053] 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).

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

[0055] 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 view generation unit 102 selects one edge conversion mapping for which steps S309 to S311 have not been performed from the viewpoint model selected by the user (step S308). Then, view generation unit 102 performs steps S309 to S311 for the edge conversion mapping selected in step S308.

[0056] 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 TIFF0007651863000004.tif1017 and the generated edges TIFF0007651863000005.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, the edge on the right side of the arrow of the edge transformation mapping is the edge corresponding to structure t. The result is TIFF0007651863000006.tif1017.

[0057] 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).

[0058] 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 TIFF0007651863000007.tif1017 is added to the mapping destination column of the mapping table T and to the same row as the entity e (step S311).

[0059] 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 user (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.

[0060] 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 to the terminal 900 as the pre-update view v0 (step S313).

[0061] Next, a specific example of the forward conversion operation shown in FIGS. 18 and 19 will be described with reference to FIGS. First, with reference to FIG. 20, a specific example of the operations in steps S301 and S302 shown in FIG. 18 will be described.

[0062] In step S301, the view generation unit 102 receives, for example, requirement data t as shown in FIG. 20 from the requirement data management 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.

[0063] Next, a specific example of the operations in steps S303 to S306 shown in FIG. 18 will be described with reference to FIGS. In step S303, the view generation unit 102 selects one node conversion mapping for which steps S304 to S306 have not been performed from the viewpoint model selected by the user. In the example of FIG. 21, 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.

[0064] 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 ALL The 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.

[0065] 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 a node “App1” in

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

[0067] Next, a specific example of the operations in steps S308 to S311 shown in FIG. 19 will be described with reference to FIGS. In step S308, the view generation unit 102 selects one edge conversion mapping for which steps S309 to S311 have not been performed from the viewpoint model selected by the user. In the example of FIG. 23, ALL The structure C101 in matches the transformation structure of the edge transformation mapping selected in step S308.

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

[0069] 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 tALL The edges in view v corresponding to each entity e in structure C101 in TIFF0007651863000010.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.

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

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

[0072] 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. TIFF0007651863000013.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.

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

[0074] Fig. 25 shows an example of a view v and a mapping table T after the forward transformation operations shown in Fig. 18 and Fig. 19 are completed. The view v shown in Fig. 25 is output to the terminal 900 as a pre-update view v0.

[0075] <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.

[0076] As shown in FIG. 26 and FIG. 27, first, the requirement data update unit 103 inputs an updated view v1 updated by a user from the terminal 900, and also receives requirement data t ALL (Step S401).

[0077] Next, the requirement data update unit 103 updates the requirement data t ALL Then, the forward transformation of the requirement data t is performed to obtain the pre-update view v0 and the mapping table T (step S402). 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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).

[0084] 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.

[0085] 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).

[0086] 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). Then, the view generator 102 generates the requirement data t ALL Confirm the confirmed requirements data t ALL The updated requirement data ALL to the requirement data management unit 101 (step 412).

[0087] Next, a specific example of the reverse conversion operation shown in FIGS. 26 and 27 will be described with reference to FIGS. First, with reference to FIG. 28, a specific example of the operation of step S401 shown in FIG. 26 will be described.

[0088] In step S401, the requirement data update unit 103 receives, from the requirement data management unit 101, for example, requirement data t ALL Enter. Furthermore, the requirement data update unit 103 inputs, for example, an updated view v1 as shown in Fig. 28 from the terminal 900. In this updated view v1, the following operations are performed on the pre-update view v0. -Delete nodes “App1” and “App2” Edge Delete TIFF0007651863000016.tif1043 -Added node “App6” Edge Add TIFF0007651863000017.tif1043 Update the port property

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

[0090] Next, a specific example of the operation in step S403 shown in FIG. 26 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. 30. 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. 30.

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

[0092] 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. 31, the following adding operations are selected. -Added node “App6”

[0093] 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.

[0094] 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. 32, the following adding operations are selected. Edge Add TIFF0007651863000018.tif1043

[0095] 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 TIFF0007651863000019.tif1043 TIFF0007651863000020.tif1158 is the requirement data t ALL Add to.

[0096] Next, a specific example of the operations in steps S407 and S408 shown in FIG. 27 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'.

[0097] FIG. 34 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. 33 shows an example of a mapping table T before deleting all applicable entities e.

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

[0099] For example, in the example of FIG. 34, the column to which the following entity e' is mapped in the mapping table T is empty. Node “App1” Node “App2” Node “Server1” Edge TIFF0007651863000021.tif1163 Edge TIFF0007651863000022.tif1164 Edge TIFF0007651863000023.tif1164 Edge TIFF0007651863000024.tif963

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

[0101] Next, a specific example of the operation of step S411 shown in FIG. 27 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. 34, the table becomes as shown in FIG. 36. As a result of referring to the mapping table T shown in FIG. 36, the requirements data update unit 103 determines that each entity in the updated view v1 is a member of the requirements data t ALLTherefore, as shown in FIG. 37, 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. 31, 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.

[0102] <Advantages of the First Embodiment> As described above, according to the first embodiment, the requirement data management unit 101 registers requirement data, which is a graph expressing a system requirement. The view generation unit 102 inputs the requirement data and also inputs a viewpoint model, which is a model that defines 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 generation unit 102 then 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 requirement data update unit 103 inputs the requirement data and also inputs a post-update view, which is a view after the pre-update view is updated, and reflects the contents of the post-update view in the requirement data.

[0103] Therefore, a user can edit system requirements by referring to and editing a view of the system requirements from a specific viewpoint. This allows the user to easily edit the system requirements. As a result, the human cost required for editing system requirements can be significantly reduced.

[0104] <Embodiment 2> Next, a configuration example of a system requirement editing device 100A according to the second embodiment will be described with reference to Fig. 38. As shown in Fig. 38, the system requirement editing device 100A according to the second embodiment includes a requirement data management unit 121, a view generation unit 122, and a requirement data update unit 123.

[0105] Requirement data, which is a graph expressing a system requirement, is registered in requirement data management unit 121. Requirement data management unit 121 corresponds to requirement data management unit 101. The view generating unit 122 inputs the requirement data 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 122 then 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 122 corresponds to the view generating unit 102.

[0106] The requirements data update unit 123 receives the requirements data and also receives a post-update view, which is a view after the pre-update view has been updated, and reflects the contents of the post-update view in the requirements data. The requirements data update unit 123 corresponds to the requirements data update unit 103.

[0107] Therefore, the user can edit the system requirements by viewing and editing a view of the system requirements from a specific point of view, which allows the user to easily edit the system requirements.

[0108] The requirements data update unit 123 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 123 may add an entity corresponding to the entity added to the pre-update view by the add operation to the requirements data.

[0109] The requirements data updating unit 123 may further acquire a mapping table, which is a table in which entities in the requirements data are shown in a first column, and entities in the pre-update view corresponding to the entities in the requirements data are shown in a second column of the same row. The requirements data updating unit 123 may also 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. The requirements data updating unit 123 may then 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.

[0110] Furthermore, the requirements data update unit 123 may set the property set for the entity in the updated view as the property for the corresponding entity in the requirements data. Alternatively, the view generation unit 122 may present a list of at least one viewpoint model to the user, and input a viewpoint model selected by the user from the list of viewpoint models. Furthermore, the viewpoint model may be a model that specifies a conversion method for converting a substructure in the requirements data into an entity. The requirements data may also include special entities that are types of entities not included in the original requirements data. The view generator 122 may also receive a viewpoint model as input and output model data necessary to interpret the meaning of the special entities.

[0111] <Embodiment 3> Next, a hardware configuration example of the system requirement editing device 100B according to the third embodiment will be described with reference to Fig. 39. As shown in Fig. 39, the system requirement editing device 100B according to the third embodiment includes a processor 130 and a memory 131.

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

[0113] The system requirement editing devices 100, 100A according to the above-mentioned first and second embodiments may have the hardware configuration shown in Fig. 39. The view generating units 102, 122 and the requirement data updating units 103, 123 in the above-mentioned system requirement editing devices 100, 100A may be realized by the processor 130 reading and executing a program stored in the memory 131. Also, the requirement data managing units 101, 121 in the above-mentioned system requirement editing devices 100, 100A may be realized by the memory 131.

[0114] 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.

[0115] 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]

[0116] 100, 100A, 100B System requirements editor 101,121 Requirement Data Management Department 102,122 View Generation 103,123 Requirement Data Update Section 110 User Interface 111 Requirement Editing Screen 112 Edit content save button 113 Viewpoint Model Selection Interface 130 processors 131 Memory 201 Viewpoint model reading unit 202 Viewpoint Model DB 203 Type information DB 204 Concrete Pattern DB 900 terminals

Claims

1. a requirement data management unit in which requirement data, which is a graph expressing system requirements, is registered; a view generating unit that receives the requirements data and a viewpoint model that is a model that defines a conversion method for converting the requirements data into a graph that provides another expression of the system requirements expressed by the requirements data, generates a view that is a graph obtained by converting the requirements data using the viewpoint model, and outputs the generated view as a pre-update view; a requirements data update unit which inputs the requirements data and also inputs a post-update view which is a view after the pre-update view has been updated, and reflects the contents of the post-update view in the requirements data; System requirements editor.

2. 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; 2. The system requirement editing device according to claim 1.

3. The requirement data update unit obtain a mapping table, which is a table in which entities in the requirements data are shown in a first column and entities in the before view that correspond to entities in the requirements data are 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; 3. The system requirement editing device according to claim 2.

4. The requirement data update unit setting a property set for an entity in the updated view to a property of a corresponding entity in the requirements data; The system requirement editing device according to any one of claims 1 to 3.

5. The view generating unit is presenting a list of at least one of said viewpoint models to a user; inputting a viewpoint model selected by a user from the list of viewpoint models; The system requirement editing device according to any one of claims 1 to 4.

6. The viewpoint model is a model that specifies a conversion method for converting a substructure in the requirements data into an entity. The system requirement editing device according to any one of claims 1 to 5.

7. A system requirement editing method performed by a system requirement editing device, comprising: A step of registering requirement data which is a graph representing a system requirement; a step of inputting the requirements data and a viewpoint model which is a model defining a conversion method for converting the requirements data into a graph which gives another expression of the system requirements expressed by the requirements data, generating a view which is a graph obtained by converting the requirements data using the viewpoint model, and outputting the generated view as a pre-update view; inputting the requirements data, and inputting a post-update view which is a view after the pre-update view has been updated, and reflecting the contents of the post-update view in the requirements data; How to edit system requirements.

8. On the computer, A procedure for registering requirements data, which is a graph that represents system requirements; a step of inputting the requirements data and a viewpoint model which is a model defining a conversion method for converting the requirements data into a graph which gives another expression of the system requirements expressed by the requirements data, generating a view which is a graph obtained by converting the requirements data using the viewpoint model, and outputting the generated view as a pre-update view; a step of inputting the requirements data and inputting a post-update view, which is a view after the pre-update view has been updated, and reflecting the contents of the post-update view in the requirements data; A program for executing the above.

Images