JP2019204373A - Apparatus for and method of supporting creation of program using visual programming tool - Google Patents

Abstract

To avoid modifying properties necessary for individual modules consisting of sub flows if necessary.SOLUTION: A program creation support apparatus determines P modules (P is 2 or greater and M or smaller) respectively having P properties among sub flows of M modules (M is an integer which is 2 or greater and N or smaller) selected from N modules (N is an integer which is 2 or larger) consisting of a program created by using a visual programming tool. If in the P property, there is one or greater property item groups of Q property items (Q is 2 or greater and P or smaller) which can be commonly used as a single property item and on which update of the one property item is reflected, then the apparatus presents that each of the one or greater property item groups can be commonly used.SELECTED DRAWING: Figure 4

Description

  The present invention generally relates to support for program development using visual programming tools.

  In recent years, a visual programming tool that can quickly create an application program (an example of a development target program) has been attracting attention even for users who do not have deep knowledge of programming.

  According to the visual programming tool, a module having a specific process represented by an icon is arranged on a dedicated workspace, and these are connected by a line representing a connection relationship between modules such as a wire, so that an application program can be executed. Created.

  One of the advantages of visual programming is that it is easier to understand the processing of the entire program than programming that directly edits the source code with a text editor, etc. If you organize the processing in the form of modules, you can reuse it for programming This may reduce the amount of work.

  Some visual programming tools (such as Node-RED) have a function (subflow function) that makes a subflow, which is a set of a plurality of modules that make up an application program, and a wire that connects them together as one module. ing. The plurality of modules constituting the subflow are, for example, a plurality of modules having relatively high relevance. Patent Document 1 discloses a technique for evaluating the relationship between modules. Specifically, for example, the measurement device disclosed in Patent Document 1 divides a program into modules, and quantifies the degree of dependence between modules by measuring data belonging to the modules and module call operations.

Japanese Unexamined Patent Publication No. 2000-215045

  Visual programming tools have properties for each module. A property includes one or more (typically multiple) property elements. Each property element includes a set of a property item (for example, “IP address”) and a property value (for example, “1.1.1.1”).

  Even if a plurality of modules are made into one subflow by the subflow function, in order to reuse the subflow (for example, to reuse in another application program), it is necessary to move to a hierarchy representing the internal structure of the subflow. The properties required for the module must be reviewed and modified as necessary. As a result, the user's setting man-hours increase.

  The program creation support device selects M modules (M is greater than or equal to 2 and less than or equal to N) out of N modules (N is an integer greater than or equal to 2) that make up a program created using a visual programming tool. P modules having P properties (P is not less than 2 and not more than M) are determined. The device can be shared as one property item, and Q property items (Q is 2 or more and P or less) that reflect the update of the one property item are converted into P properties. If there are one or more items, it indicates that each of the one or more property item groups can be shared.

  User-set man-hours for subflow properties are reduced.

1 is a block diagram illustrating an example of a computer system according to Embodiment 1 of the present invention. It is a figure which shows the outline | summary of an example of the aggregation module production | generation in Example 1 of this invention. FIG. 3 is a diagram showing an outline of a comparative example of Example 1 of the present invention. It is a figure which shows an example of the outline | summary of the property setting in Example 1 of this invention. It is a figure which shows an example of the module management table in Example 1 of this invention. It is a figure which shows an example of the policy management table in Example 1 of this invention. It is a figure which shows an example of the infrastructure management table in Example 1 of this invention. It is a figure which shows an example of the selection range management table in Example 1 of this invention. It is a figure which shows an example of the module comparison table in Example 1 of this invention. It is a figure which shows an example of the property table in Example 1 of this invention. It is a figure which shows an example of the display condition table in Example 1 of this invention. It is a figure which shows an example of the display group table in Example 1 of this invention. An example of processing performed by the policy registration unit according to the first embodiment of the present invention will be described. An example of the process performed by the infrastructure relevant generation part in Example 1 of this invention is shown. The front part of an example of the process performed by the aggregation candidate part in Example 1 of this invention is shown. The middle part of an example of the process performed by the aggregation candidate part in Example 1 of this invention is shown. The back part of an example of the process performed by the aggregation candidate part in Example 1 of this invention is shown. An example of the process performed by the display group production | generation part in Example 1 of this invention is shown. An example of the process performed by the aggregation execution part in Example 1 of this invention is shown. It is a figure explaining an example of the property commonization screen in Example 1 of this invention. It is a figure explaining an example of the confirmation screen in Example 1 of this invention. An example of the process performed by the change execution part in Example 2 of this invention is shown.

  In the following description, the “interface unit” may be one or more interfaces. The one or more interfaces may include at least a communication interface unit among a user interface unit and a communication interface unit. The user interface unit may be at least one I / O device of one or more I / O devices (for example, an input device (for example, a keyboard and a pointing device), an output device (for example, a display device)), and a display computer. Instead of or in addition, an interface device (I / O interface) for the at least one I / O device may be used. The communication interface unit may be one or more communication interface devices. The one or more communication interface devices may be one or more similar communication interface devices (for example, one or more NIC (Network Interface Card)) or two or more different types of communication interface devices (for example, NIC and HBA (Host Bus Adapter)).

  In the following description, the “memory unit” is one or more memories, and may typically be a main storage device. At least one memory in the memory unit may be a volatile memory or a non-volatile memory.

  In the following description, the “PDEV portion” is one or more PDEVs, and typically an auxiliary storage device. “PDEV” means a physical storage device, typically a non-volatile storage device such as a hard disk drive (HDD) or a solid state drive (SSD).

  In the following description, the “storage unit” is at least one of the memory unit and the PDEV unit (typically at least the memory unit).

  In the following description, the “processor unit” is one or more processors. The at least one processor is typically a microprocessor such as a CPU (Central Processing Unit), but may be another type of processor such as a GPU (Graphics Processing Unit). At least one processor may be a single core or a multi-core. The at least one processor may be a broad processor such as a hardware circuit (for example, a field-programmable gate array (FPGA) or an application specific integrated circuit (ASIC)) that performs part or all of the processing.

  In the following description, the function may be described by the expression “kkk part” (excluding the interface part, the storage part, and the processor part). The function is executed by one or more computer programs by the processor part. It may be realized by one or more hardware circuits (for example, FPGA or ASIC). When the function is realized by the program being executed by the processor unit, the predetermined process is appropriately performed using the storage unit and / or the interface unit. Therefore, the function is at least a part of the processor unit. May be. The processing described with the function as the subject may be processing performed by the processor unit or a device having the processor unit. The program may be installed from a program source. The program source may be, for example, a program distribution computer or a computer-readable recording medium (for example, a non-transitory recording medium). The description of each function is an example, and a plurality of functions may be combined into one function, or one function may be divided into a plurality of functions.

  In the following description, information that can be output with respect to an input may be described using an expression such as “xxx table”. The information may be data of any structure, and may be output with respect to an input. A learning model such as a neural network that generates Therefore, the “xxx table” can be referred to as “xxx information”. In the following description, the configuration of each table is an example, and one table may be divided into two or more tables, or all or some of the two or more tables are one table. May be.

  Several embodiments of the present invention will be described below with reference to the accompanying drawings. The identification information used for the table used in the embodiment may omit the identification information column if the table entry can be specified using one or more columns in the table. In addition, identification information may be automatically assigned identification numbers in ascending order. In each figure, the same reference numerals are given to common components. When explaining without distinguishing the same kind of component, a common code among the reference symbols is used, and when distinguishing the same kind of component, a reference code may be used. For example, when modules are not distinguished, they are referred to as “module 205”, and when modules are distinguished, they are referred to as “module 205A” and “module 205B”.

  The management server, which is an example of the program creation support apparatus according to the first embodiment, specifies the aggregation module when the user designates a plurality of modules and aggregates them into one module (creates an aggregation module (subflow)). Property elements that are considered to have the same content are detected in a plurality of modules constituting the, and whether or not to share them is presented to the user. The update of the common property element of the aggregation module becomes the update of the property element of each of two or more modules belonging to the aggregation module. Thereby, the user can reduce the number of properties of the aggregation module, and as a result, the setting man-hour for the aggregation module of the user is reduced.

  Specifically, in the first embodiment, when the management server creates a module (subflow) by aggregating a plurality of modules constituting an application program (an example of a program), a connection relationship between modules, a workspace The relationship between modules is evaluated based on which of the multiple policies including the location information in the (display space provided by the visual programming tool) and the IT infrastructure information of the module matches between the modules. To do. The management server extracts a set of modules having high relevance (for example, relatively high relevance, or the relevance is equal to or greater than a predetermined threshold). For each extracted set, the management server has a high relevance (for example, a relatively high relevance or a predetermined relevance among the two properties of each of the two modules constituting the set) Extract a set of property elements that are greater than or equal to the threshold value. Then, the management server presents the extracted set of property elements to the user as a set that is highly likely to be shared by one property element. Then, the management server accepts selection of a set shared by the user among the set of property elements presented to the user. For each set of property elements selected by the user, the management server determines two property elements belonging to the set as one property element to be shared, and sets the property element in the properties of the aggregation module. One property element.

  Hereinafter, Example 1 will be described in detail. Note that “displaying information” by the management server may mean displaying display information on the display device of the management server, or the management server sends display information to the display computer. (In the latter case, display information is displayed by a display computer).

  FIG. 1 is a block diagram illustrating an example of a computer system according to the first embodiment.

  The computer system according to the first embodiment includes a management server 101, an execution environment 102 for deploying and executing application programs, and a visual programming tool 106, which are connected to each other via a management network (for example, an IP network) 103. The

  The execution environment 102 may include a plurality of computers, a plurality of storage devices, a plurality of network devices, and the like. The execution environment 102 may be an environment that uses a physical device itself as a resource, or an environment that uses a virtual device as a resource.

  The visual programming tool 106 displays the processing flow of the application program. Program creation using the visual programming tool 106 is supported by the management server 101. The visual programming tool 106 may be executed by a client terminal as an input / output console, or may be executed by the management server 101 that can communicate with the input / output console (the input device 104 and the display device 105 in this embodiment). . The screen provided by the visual programming tool 106 is displayed on the input / output console. In the present embodiment, programming using the visual programming tool 106 is supported by processing performed by the control unit 120 based on the table group 130 in the management server 101.

  Management server 101 evaluates the relationship between modules to be aggregated and the relationship between properties used when aggregating multiple modules in visual programming, and implements processing to share similar properties To do. Here, the hardware configuration and software configuration of the management server 101 will be described.

  The management server 101 includes a CPU (Central Processing Unit) 111, a memory 112, a network interface 113, and an I / O interface 114. These hardwares are connected to each other via an internal bus (not shown). The CPU 111 is an example of a processor unit, the memory 112 is an example of a storage unit, and the network interface 113 and the I / O interface 114 are examples of an interface unit.

  The CPU 111 executes one or more programs stored in the memory 112. The CPU 111 operates as the control unit 120 that realizes a predetermined function by operating according to a program stored in the memory 112.

  The memory 112 stores one or more programs executed by the CPU 111 and a management table group 130 that is a plurality of management tables that are referred to or updated in the execution of the one or more programs. The memory 112 includes a work area (not shown) temporarily used by the program.

  The network interface 113 is an interface for communicating with an external device via an IP network or the like. The I / O interface 114 is an interface connected to the input device 104 and the display device 105. The I / O interface 114 may be connected to an external storage medium such as a USB memory or an external storage device.

  The input device 104 is a device for inputting data to the management server 101 (for example, a keyboard, a mouse, a touch panel, etc.). The display device 105 is a device (for example, a display and a touch panel) for displaying the processing result of the management server 101 and the like.

  In FIG. 1, the number of each component as hardware is one, but may be two or more. For example, when the management server 101 is connected to a plurality of networks, the management server 101 and the visual programming tool 106 may have a plurality of network interfaces connected to each network.

  Here, programs and information stored in the memory 112 of the management server 101 will be described. The memory 112 stores a program for realizing the control unit 120 and a management table group 130.

  The control unit 120 includes a policy registration unit 121 (see FIG. 13), an aggregation candidate generation unit 122 (see FIGS. 15A to 15C), a display group generation unit 123 (see FIG. 16), an aggregation execution unit 124 (see FIG. 17), It includes an infrastructure information acquisition unit 125 and an infrastructure related generation unit 126 (see FIG. 14).

  The management table group 130 includes a module management table 131 (see FIG. 5), a policy management table 132 (see FIG. 6), a selection range management table 133 (see FIG. 8), a module comparison table 134 (see FIG. 9), and a property table 135. (See FIG. 10), a display condition table 136 (see FIG. 11), a display group table 137 (see FIG. 12), and an infrastructure management table 138 (see FIG. 7).

  The visual programming tool 106 displays modules, wires, a dedicated workspace for arranging them as a GUI (Graphical User Interface) to the user, and allows the user to perform programming visually. The visual programming tool 106 includes a screen display unit 141 and a program management unit 142.

  The screen display unit 141 displays an application program visually, and displays a GUI for allowing the user to edit it. The program management unit 142 transmits a user operation on the application program acquired through the screen display unit 141 to the program execution unit 151 existing on the management server 101 or the execution environment 102, or creates an aggregation module generated by the management server 101 When receiving the information, the user receives information (such as information for determining whether or not the property is to be shared) that needs to be visualized and passes it to the screen display unit 141.

  In this embodiment, the visual programming tool 106 having the screen display unit 141 and the program management unit 142 is executed on a server different from the management server 101, but this is an example. For example, the visual programming tool 106 may be executed by the CPU 111 of the management server 101, or may be executed by a computer resource such as a physical server or a virtual server that exists in the execution environment 102.

  The program execution unit 151 and the source code data 152 are developed and processed on computer resources such as a physical server and a virtual server that exist in the execution environment 102.

  The program execution unit 151 receives the source code data 152 of the application program (information on the modules constituting the application program, wire information connecting the modules, etc.) from the program management unit 142 of the visual programming tool 106, and the received source code The process described in the data 152 is executed. As for the execution method, the program execution unit 151 reads the source code data 152, and further executes the processing defined by each module in the source code data 152 in order based on the connection relationship such as a wire. When data is exchanged between modules, the data is relayed. In addition, depending on the processing defined in the module, a SaaS (Software that is external to the execution environment 102 via the computer on the execution environment 102 other than the computer that executes the program execution unit 151 or the network such as the management network 103 is used. as a Service) and other IT services and computer resources may be called. Alternatively, instead of the program execution unit 151, a binary executable on the computer may be generated.

  FIG. 2 shows an outline of an example of the aggregate module generation in this embodiment.

  A processing flow 204 representing at least a part of the application program is displayed on the display device 105 on a workspace (GUI) provided by the visual programming tool 106. The process flow 204 includes modules 205A-205F and a plurality of wires 206. When the input device 104 receives a designation from the user (developer) 202 as the aggregation range 207, for example, the modules 205B to 205E, which are part of the processing flow 204, are received by the visual programming tool 106 as shown in FIG. 208.

  FIG. 3 shows an outline of one comparative example of the present embodiment.

  In many cases, since the module 205 executes processing in the module 205, it is necessary to set a property value for each property item in the property 211 prepared for each module 205. Dashed arrows 312B to 312E represent the relationship between the modules 205B to 205E and the properties 311B to 311E.

  When an attempt is made to change a property value with respect to the aggregation module 208, the user 202 may have a plurality of components constituting the aggregation module 208 as shown in the aggregation module internal 314, although the aggregation module 208 is a single module. It is necessary to expand the modules 205B to 205E so that the module 205 needs to change the property, and to change the property value via the setting screen (for example, GUI) of the property 311 of the module 205. That is, the user 202 needs to perform complicated operations such as redeployment of the aggregation module and searching for the module 205 and the property 311 to be corrected. In addition, when a plurality of modules 205 are used together, there are cases in which settings for the same property item are used across a plurality of modules 205. It is necessary to open the property setting screen for each and enter the same value.

  FIG. 4 shows an example of an outline of property setting in the present embodiment.

  In the present embodiment, when the user 202 generates the aggregation module 208, the control unit 120 displays a property sharing screen (for example, GUI) 1800, in which the sharing recommendation 1804 (for example, see FIG. 18). I do. The common recommendation 1804 is a visualization of a combination of property elements 421C and 421D that may be shared among a group of modules 205 to be aggregated. The user 202 determines whether or not to share the combination of property elements 421C and 421D that are the targets of the sharing recommendation 1804. A combination (combination of property elements 421) that is specified to be shared via the property sharing screen 1800 is stored in the management server 101, and the control unit 120 aggregates the set of the shared property elements. Created as property 423 of module 208. The control unit 120 may display the property 423 of the aggregation module 208.

  By creating the property 423 of the aggregation module, the user 202 shifts to the editing screen of the aggregation module internal 314 every time in order to find the property element to be modified regarding the property setting change for the aggregation module 208, There is no need to search for the module 205 having the property element to be corrected from the processing flow representing the aggregation module internal 314 or to open and set the property setting screen for each module 205. In other words, if the property element to be changed is found from the property 423 of the aggregation module 208 and changed, the corresponding property element of each of the two or more modules 205 belonging to the aggregation module 208 is changed.

  FIG. 5 is a diagram illustrating an example of the module management table 131 according to the first embodiment.

  The module management table 131 is information for managing the module 205. The module management table 131 has an entry for each module 205. Each entry stores information such as a module ID 501, a module name 502, an X coordinate 503, a Y coordinate 504, a connection destination ID 505, a property 506, a creation commit 507, an update commit 508, a category 509, and a display order 510. Hereinafter, a single module 205 is taken as an example (“target module 205” in the description of FIG. 5). The entry may store information other than the illustrated information (this applies to the other tables 132 to 138).

  Module ID 501 indicates an identifier for identifying the target module 205.

  A module name 502 indicates a name when the target module 205 is displayed.

  The X coordinate 503 and the Y coordinate 504 correspond to position information indicating the position of the target module 205 on the work space. The X coordinate 503 indicates the X coordinate on the workspace, and the Y coordinate 504 indicates the Y coordinate on the workspace. In this embodiment, as an example, the X coordinate and Y coordinate indicate the distance from the upper left corner of the workspace to the center of the target module 205 in units of pixels.

  The connection destination ID 505 indicates the module ID of the connection destination module 205, which is the module 205 connected to one end (output side) of the target module via one wire (without the intervention of another module 205).

  A property 506 indicates a property including a setting value necessary for processing by the target module 205. For example, in the case where the target module 205 is a module that transmits mail, the property items in the property include an IP address, a port number, a login user name, a login password, and the like for connecting to the mail service.

  The creation commit 507 is a source code management system (such as git) for which the user first generates source code including the target module 205 (in the case of visual programming, information such as the module 205 including the property and the wire 206 connecting the module 205). Indicates the commit ID issued by the source code management system when registering in (not shown). It is possible to determine that two or more modules 205 having the same commit ID are modules registered in the source code management system at the same time. As the commit ID, the creation date and time of the target module 205 may be used as long as it can be confirmed that the source code is saved at the same time. The “source code management system” is a system that manages source code data and registers the source code data.

  The update commit 508 indicates a commit ID (commit ID issued when the updated source code is registered in the source code management system) when the user edits and updates the source code. As for the commit ID, if it can be confirmed that the source code is stored (updated) at the same time, the update date and time may be used.

  The category 509 indicates a category to which the module or module template created in the past belonged when the target module 205 is a module created based on a module or module template created in the past.

  The display order 510 indicates the order of the modules 205 to be displayed when the module aggregation process proceeds. In this embodiment, the smaller the numerical value, the earlier the display. This order may be calculated based on the information of the X coordinate 503 and Y coordinate 504 of each module. In the example of the first embodiment, how far each module is from the coordinate (0,0) is calculated from the X coordinate 503 and the Y coordinate 504, and the order is given in ascending order from the module close to the coordinate (0,0). Is done.

  FIG. 6 is a diagram illustrating an example of the policy management table 132 according to the first embodiment.

  The policy management table 132 stores information on various policies used for evaluating the degree of relationship between modules 205, the degree of relationship between properties, property characteristics, and the like. The policy management table 132 has an entry for each policy. Each entry stores information such as policy ID 601, type name 602, policy content 603, point 604, and prior policy 605. Hereinafter, a single policy is taken as an example (“target policy” in the description of FIG. 6).

  Policy ID 601 indicates an identifier for identifying the target policy.

  A type 602 indicates the type of the target policy. In this embodiment, there are three types of policy: “module comparison”, “property comparison”, and “property”. The “module comparison” policy is a policy used for evaluating the relationship between modules. The “property comparison” policy is a policy used for evaluating the relationship between properties. The “property” policy is a policy used for evaluating whether a property satisfies a specific condition.

  The policy content 603 indicates the content of the target policy (specifically, the module 205, a pattern for evaluating properties, etc.).

  A point 604 indicates a point added when the target policy is satisfied. When the target policy is a “module comparison” policy, the points are added to the module-related points described later. When the target policy is a “property comparison” or “property” policy, points are added to property-related points described later. In this embodiment, the evaluation values such as module-related points and property-related points are the total of points corresponding to the satisfied policy, but may be other than the total (for example, low points (for example, relative points) May be excluded from the addition target because it may become noise). Further, for example, as additional information in the policy, the policy may not be applied to a specific module or property, so that comparison by an excessive policy may be avoided. The point 604 may be changed by the user in view of the balance with other policies.

  The prior policy 605 is policy identification information that should be evaluated in advance before applying another policy and performing the evaluation.

  If the property names are the same, but the property names are different, the same property item may be specified by a dictionary or the like.

  FIG. 7 is a diagram illustrating an example of the infrastructure management table 138 according to the first embodiment.

  The infrastructure management table 138 stores information related to the IT infrastructure such as a physical server, a virtual server, and a container execution platform on which the module is actually deployed, and stores information indicating a relationship with the module operating on the IT infrastructure. It is. Also, if the module is connected to a service such as SaaS (Software as a Service) for processing, store information related to SaaS as information related to the infrastructure, and link with the module that uses SaaS. Stores information to represent. The infrastructure management table 138 has an entry for each IT infrastructure. Each entry stores information such as infrastructure ID 701, management IP address 702, authentication information 703, OS 704, configuration 705, and related module 706. In the following, a single infrastructure is taken as an example ("target IT infrastructure" in the description of FIG. 7).

  The infrastructure ID 701 is an identifier for uniquely identifying the target IT infrastructure.

  The management IP address 702 indicates an IP address assigned to the target IT infrastructure. The authentication information 703 is authentication information (for example, user ID and password) related to the target IT infrastructure. Information on the target IT infrastructure can be acquired from the target IT infrastructure based on the IP address and the authentication information.

  The OS 704 is information related to the OS of the target IT infrastructure. The configuration 705 is information such as the OS of the target IT infrastructure and middleware serving as a container base. The configuration 705 may be information including information on hardware such as a CPU and a memory.

  The related module 706 indicates an identifier of a module operating on the target IT infrastructure. As a result, the connection between the target IT infrastructure and the module 205 is expressed. The connection between the target IT infrastructure and the module indicates the identifier of the related IT infrastructure in the entry of the module management table 131 instead of or in addition to the related module 706 being stored in the entry of the infrastructure management table 138. It may be expressed by storing information.

  FIG. 8 is a diagram illustrating an example of the selection range management table 133 according to the first embodiment.

  The selection range management table 133 stores information indicating the identifier of each module to be aggregated when the user designates a specific module group and starts aggregation processing. In addition, information indicating the registration date and time may be stored to include information as a history of aggregation processing. The selection range management table 133 has an entry for each selection range (aggregation module). Each entry stores information such as a selection range ID 801, a module ID 802, and a registration date and time 803. Hereinafter, a single selection range is taken as an example (“target selection range” in the description of FIG. 8).

  The selection range ID 801 is an identifier (target selection range identifier) for identifying the aggregation process and the module group selected by the user when performing the aggregation process.

  The module ID 802 indicates the module ID of each module (belonging to the target selection range) selected by the user when performing the aggregation process.

  The registration date and time 803 indicates the date and time when the aggregation process is started (target selection range is specified). Note that the date and time indicated by the registration date and time 803 is for the user to confirm the aggregation processing performed in the past, and may not be the start date and time as long as it can be determined that the aggregation processing has been performed. .

  FIG. 9 is a diagram illustrating an example of the module comparison table 134 according to the first embodiment.

  The module comparison table 134 is a table used for comparing two modules and recording the degree of relevance. The module comparison table 134 has an entry for each comparison group (a set of two modules 205). Each entry stores information such as a comparison group ID 901, a comparison group 902, a module related point 903, a related property 904, a property related point 905, an aggregation 906, a non-aggregation 907, and a selection range ID 908. Hereinafter, a single comparison group is taken as an example (“target comparison group” in the description of FIG. 9).

  The comparison group ID 901 indicates an identifier for identifying the target comparison group.

  The comparison group 902 indicates the module ID of each of the two modules belonging to the target comparison group.

  The module relation point 903 indicates a module relation point which is a numerical value indicating the degree of relevance between modules belonging to the target comparison group. In the present embodiment, as described above, when the target comparison group satisfies the “module comparison” policy, the points previously assigned to the policy are added to the module-related points of the target comparison group. For example, the initial value of the module-related point is “0”, and each time the “module comparison” policy is adapted, a point corresponding to the policy may be added.

  The related property 904 is a combination of property items that are highly relevant when evaluated by a specific policy among the properties of the two modules belonging to the target comparison group. Indicates a combination of property items that are proposed.

  A property related point 905 indicates a property related point which is a numerical value indicating the level of relevance between the properties of the modules belonging to the target comparison group. In this embodiment, as described above, when the target comparison group satisfies the “property comparison” or “property” policy, the points assigned in advance to the policy are added to the property-related points of the target comparison group. The For example, the initial value of the property-related point is “0”, and each time the “property comparison” or “property” policy is adapted, a point corresponding to that policy may be added.

  An aggregation 906 indicates a common property item among the properties of the two modules belonging to the target comparison group. On the other hand, the non-aggregation 907 indicates property items that have not been shared among the properties of the two modules belonging to the target comparison group.

  The selection range ID 908 is an identifier of the selection range to which the target comparison group belongs.

  FIG. 10 is a diagram illustrating an example of the property table 135 according to the first embodiment.

  The property table 135 is a table for registering whether or not a policy is satisfied when a policy whose type is “property” in the policy management table 132 is applied to the module property. In this embodiment, the property table 135 is generated during the aggregation process. However, a policy whose policy type is “property” for a property may be registered in advance as a prior policy.

  The property table 135 has an entry for each property element. Each entry stores information such as a property ID 1001 and a prior policy 1002. Hereinafter, a single property element is taken as an example (“target property element” in the description of FIG. 10).

  The property ID 1001 is an identifier for identifying the target property element. The identifier includes, for example, a property item (for example, a property item name) in the target property element and a module ID of a module related to the property having the property item.

  The prior policy 1002 indicates the policy ID of the “property” policy that the target property element satisfies.

  FIG. 11 is a diagram illustrating an example of the display condition table 136 according to the first embodiment.

  The display condition table 136 stores conditions such as the number of modules to be displayed when the user performs module aggregation processing using a GUI (work space). The display condition table 136 has an entry for each display condition. Each entry stores information such as a display condition ID 1101 and a maximum module display number 902. Hereinafter, one display condition is taken as an example (“target display condition” in the description of FIG. 11).

  The display condition ID 1101 indicates an identifier for uniquely identifying the target display condition.

  The maximum module display number 902 indicates the maximum module display number that is the upper limit of the number of modules displayed on the workspace. The maximum module display number may be set by the user, or the system (for example, the control unit 120) automatically uses information on the user's usage environment such as the screen size of the input device used by the user. A value may be set for. The maximum number of modules displayed is an example of screen display restrictions, but the maximum number of modules displayed may not be the screen size, but may be a value arbitrarily determined by the system or user, or the active window display of the configuration wizard screen When the magnification is dynamically changed (when enlargement or reduction is dynamically performed), the maximum module display number may be dynamically changed according to the display magnification. Further, the display size of the module may be automatically adjusted so that all the comparison groups whose module-related points are a certain value or more are displayed.

  FIG. 12 is a diagram illustrating an example of the display group table 137 according to the first embodiment.

  The display group table 137 stores information on a display group, which is a unit to be displayed at the same time when a user performs module aggregation processing using the GUI. The display group table 137 has an entry for each display group. Each entry stores information such as a display group ID 1201, a comparison group ID 1202, a common target 1203, a display condition 1204, and a selection range ID 1205. Hereinafter, a single display group is taken as an example (“target display group” in the description of FIG. 12).

  The display group ID 1201 indicates an identifier for uniquely identifying the target display group.

  The comparison group ID 1202 indicates an identifier of each of one or more comparison groups constituting the target display group.

  The common target 1203 indicates a comparison group ID of a comparison group that the user has determined to share among the comparison groups that constitute the target display group.

  The display condition 1204 indicates the display condition ID of the display condition applied when displaying the target display group. For example, according to the display group ID: DG2, two comparison groups can be displayed on one screen.

  The selection range ID 1205 indicates the selection range ID of the selection range related to one aggregation process corresponding to the target display group.

  FIG. 13 is a flowchart for explaining an example of the policy registration unit 121. Note that “S” in FIGS. 13 to 17 and FIG. 20 is an abbreviation for “step”.

  The policy registration unit 121 registers a policy used to generate a candidate group for the user to determine whether or not the modules or properties of the aggregation module can be shared.

  Specifically, the policy registration unit 121 receives a user policy registration start request from the input device 104 of the management server 101 (step 1301). In response to the start request, the policy registration unit 121 causes the user to set a policy to be newly registered through the input device 104, the display device 105, or the like of the management server 101 (step 1302). Although a policy registration screen (for example, GUI) is not shown, policy information input via the policy registration screen is input. The policy registration unit 121 registers the policy information input by the user in the policy management table 132 (step 1303).

  The policy may be input from the user as described above, or may be registered in advance in the system (the policy management table 132 may be prepared in advance). Further, the policy registration unit 121 may determine whether or not a policy to be newly registered has already been registered, and whether or not there is a policy similar to the policy to be newly registered by the user. It may be confirmed by showing a list of policies. Further, the policy information input from the user may be performed from the visual programming tool 106 or other computer connected via a network such as the management network 103 in addition to the management server 101.

  FIG. 14 is a flowchart for explaining an example of the infrastructure-related generation unit 126.

  The infrastructure related generation unit 126 performs processing for linking a module and information of an IT infrastructure in which the module is executed.

  Specifically, the infrastructure-related generation unit 126 executes a program execution instruction after programming such as placing modules in the workspace displayed by the screen display unit 141 of the visual programming tool 106 and connecting them is completed. Is detected and transmitted to the program execution unit 151 through the program management unit 142 (step 1401).

  The infrastructure related generation unit 126 acquires information (such as an infrastructure ID) that can uniquely identify the module to be deployed and the IT infrastructure to which the infrastructure is deployed from the program execution unit 151 (step 1402).

  When the program execution unit 151 receives a program execution command, the infrastructure generation unit 126 may be notified of IT infrastructure information related to processing within the program.

  Alternatively, the infrastructure information acquisition unit 125 that acquires IT infrastructure information (a flowchart relating to processing is omitted) acquires information directly from the IT infrastructure based on the management IP address 702 and authentication information 703 of the infrastructure management table 138. Also good. In that case, information acquisition methods include a method of acquiring via an information acquisition agent, a method of acquiring information by using communication means installed by default in an OS such as SSH (Secure Shell), A method of acquiring information from hardware such as IPMI (Intelligent Platform Management Interface) is conceivable, but the method is not particularly limited. Alternatively, the management server 101 may register information acquired from the cooperation destination software or service in the infrastructure management table 138 in cooperation with the operation management software or service of the IT infrastructure. Also, instead of starting the process when the deployment execution command is detected as in step 1401, the management server 101 may periodically acquire IT infrastructure information according to the schedule, or the configuration of the IT infrastructure IT infrastructure information acquisition may be performed when a change is detected.

  The infrastructure relation generation unit 126 registers the module ID of the module to be deployed as the related module 706 of the infrastructure management table 138 (step 1403).

  The infrastructure related generation unit 126 notifies the management server 101 of the completion of processing (step 1404).

  The infrastructure-related generation unit 126 allows the management server 101 to manage information by linking modules and IT infrastructure information, and uses information related to the IT infrastructure such as policy ID: MP3 policy in the policy management table 132. It becomes possible to evaluate the relevance between modules with the policy to do.

  15A to 15C are flowcharts for explaining an example of the aggregation candidate generation unit 122.

  The aggregation candidate generation unit 122 evaluates the degree of relevance of each module group selected by the user and the degree of relevance of the properties of each of the plurality of modules belonging to the module group. Thereby, an index for determining whether or not the property can be shared when the user aggregates the modules can be obtained.

  The aggregation candidate generation unit 122 detects the start of module aggregation and designation of a module group to be aggregated from the user (step 1501). When a user designates a module group, a rectangular box can be generated by dragging the mouse on the workspace of the visual programming tool 106, and a module group covered with the box can be designated as a module group of a selection range. Anyway.

  Next, the aggregation candidate generating unit 122 stores the module IDs of all modules 205 in the selection range (the range selected by the user) as the module ID 602 in the selection range management table 133 (step 1502).

  Next, the aggregation candidate generating unit 122 acquires information on the module 205 from the module management table 131 for each module 205 in the selection range, using the module ID of the module 205 as a key (step 1503).

  Next, the aggregation candidate generation unit 122 performs an aggregation candidate generation process using the module information acquired in step 1503 and the policy information acquired from the policy management table 132.

  In the aggregation candidate generation process, a combination of all two modules is generated from the selection range (step 1504). As shown in Fig. 8, when four modules with Mod IDs Mod1, Mod2, Mod3, and Mod4 are selected, Mod1-Mod2, Mod1-Mod3, Mod1-Mod4, Mod2-Mod3, Mod2-Mod4, Mod3- Six pairs (six comparison groups) such as Mod4 are generated. However, if there are more than a certain number of modules in the selection range, the combination of modules becomes enormous, so the connection relationship between the two modules described in step 1508 and the number of hops that indicate the distance between the modules, etc. By calculating combinations of modules having high relevance, it is possible not to generate all combinations of modules.

  Next, the aggregation candidate generating unit 122 registers information on all comparison groups generated in step 1504 in the module comparison table 134 (step 1505). Here, valid values are registered as the comparison group ID 901, the comparison group 902, and the selection range ID 908, and the other information 903 to 907 are initial values or invalid values.

  Next, the aggregation candidate generating unit 122 acquires (selects) the policy having the highest point 604 from the “module comparison” policies from the policy management table 132. According to the example of FIG. 6, “(number of hops between modules) == 1?” Of policy ID: MP1 is acquired (step 1506). This policy is used to evaluate whether modules are connected with wires and are adjacent (no other modules between them). The “hop count” between modules is the number of wires between modules. That is, if the number of wires between modules is 1 (in other words, if the number of modules interposed between modules is 0), the number of hops is 1.

  Next, the aggregation candidate generating unit 122 performs loop processing (loop 1) for each comparison group specified from the module comparison table 134 (step 1507). In this example, the module comparison table 134 is registered with information on the six comparison groups (Mod1-Mod2, Mod1-Mod3, Mod1-Mod4, Mod2-Mod3, Mod2-Mod4, Mod3-Mod4). To do. Hereinafter, a single comparison group is taken as an example (“target comparison group” in the description of loop 1).

  The aggregation candidate generation unit 122 determines whether the target comparison group satisfies the policy “(number of hops between modules) == 1?” Of the policy ID: MP1 acquired in advance in Step 1506 (Step 1508). . Specifically, the aggregation candidate generation unit 122 determines whether one of the module IDs is included in the connection destination ID 505 corresponding to the module ID of each module belonging to the target comparison group. If one of the module IDs is included in the connection destination ID 505, the number of hops is one.

  If the determination result at step 1508 is true, the process moves to step 1509. Otherwise, the process moves to step 1510.

  In step 1509, the aggregation candidate generator 122 adds the point “5” corresponding to the policy ID: MP1 to the module-related point 903 corresponding to the target comparison group because the target comparison group satisfies the policy ID: MP1. To do.

  When the processing is completed for all the comparison groups, the aggregation candidate generating unit 122 ends the loop processing (loop 1) started from step 1507 (step 1510).

  Next, the aggregation candidate generating unit 122 acquires a policy having the next highest point among the “module comparison” policies (step 1511). According to the example of FIG. 6, “(distance between modules) <200 pixel?” Of policy ID: MP2 is acquired. This policy is used to evaluate whether a module is located nearby on the visual programming tool workspace. This is a policy that is set when it is assumed that there is a high possibility that modules will be used at the same time if the modules are located close to each other. Even if modules that are far from each other in the topology of the processing flow (for example, have a large number of hops), it may be preferable for the user to place them close to each other in the workspace. There is a high possibility that there is some meaning as a unit. In the present embodiment, according to a policy such as policy ID: MP2, modules that are close to each other in the workspace can be evaluated as highly related modules.

  Next, the aggregation candidate generating unit 122 starts loop processing (loop 2) for the comparison group in which the module-related point 903 is the point threshold value “5” or more (step 1512). Hereinafter, a single comparison group is taken as an example (“target comparison group” in the description of loop 2). Note that the point threshold value “5” refers to the point added in the evaluation with the policy ID: MP1 in step 1509, and “5” is merely an example. Further, although the number of comparison groups to be evaluated increases, loop processing may be performed on all comparison groups in the module comparison table 134.

The aggregation candidate generating unit 122 determines whether or not the target comparison group satisfies the policy “(distance between modules) <200 pixels?” Of the policy ID: MP2 acquired in advance in step 1511 (step 1513). Specifically, the aggregation candidate generation unit 122 acquires the X coordinate and the Y coordinate corresponding to the module ID of each module of the target comparison group. If the target comparison group is Mod1-Mod2, the values of x_Mod1 (x coordinate of Mod1), y_Mod1 (y coordinate of Mod1), x_Mod2 (x coordinate of Mod2), y_Mod2 (y coordinate of Mod2) can be acquired. For this reason, the distance between the module Mod1 and the module Mod2 is as follows.
(Distance between module Mod1 and module Mod2)
= sqrt ((x_Mod1 (Mod1 x coordinate)-x_Mod2 (Mod2 x coordinate)) ^ 2 + (y_Mod1 (Mod1 y coordinate)-y_Mod2 (Mod2 y coordinate)) ^ 2)

  According to the example of FIG. 5, the distance between the modules Mod1 and Mod2 is 182 pixels, which is less than 200 pixels. Therefore, the target comparison group satisfies the policy with policy ID: MP2.

  If the judgment result at step 1513 is true, the process moves to step 1514. Otherwise, the process moves to step 1515.

  In step 1514, the aggregation candidate generator 122 adds the point “4” corresponding to the policy ID: MP2 to the module-related point 903 corresponding to the target comparison group because the target comparison group satisfies the policy ID: MP2. To do.

  If the processing is completed for all the comparison groups, the aggregation candidate generating unit 122 ends the loop processing (loop 2) started from step 1512 (step 1515).

  Next, the aggregation candidate generating unit 122 acquires a policy having the next highest point among the “module comparison” policies (step 1516). According to the example of FIG. 6, the policy ID: MP3 “Deployed on the same host?” Is acquired (step 1516). This policy is used to determine whether or not a module operates on the same host, and to determine that the relevance is high if the module exists on the same host.

  Next, the aggregation candidate generating unit 122 starts loop processing (loop 3) for the comparison group in which the module-related point 903 is the point threshold value “5” or more (step 1517). The point threshold value “5” is merely an example. For example, if you want to further limit the comparison group for loop processing to reduce the amount of calculation, consider the point “4” added in the evaluation with the policy ID: MP2 in step 1514, module related points A loop process may be performed on the comparison group 903 of “9” or more. Further, although the number of comparison groups to be evaluated increases, loop processing may be performed on all comparison groups in the module comparison table 134. Hereinafter, a single comparison group is taken as an example (“target comparison group” in the description of loop 3).

  The aggregation candidate generation unit 122 determines whether the target comparison group satisfies the policy “MP3 deployed on the same host?” With the policy ID: MP3 acquired in advance in step 1516 (step 1518). Specifically, the aggregation candidate generation unit 122 refers to the infrastructure management table 138 and determines whether or not the related module 706 includes module IDs of two modules belonging to the target comparison group.

  If the judgment result at step 1518 is true, the process moves to step 1519. Otherwise, the process moves to step 1520.

  In step 1519, the aggregation candidate generator 122 adds the point “3” corresponding to the policy ID: MP3 to the module related point 903 corresponding to the target comparison group because the target comparison group satisfies the policy ID: MP3. To do.

  If the processing is completed for all the comparison groups, the aggregation candidate generating unit 122 ends the loop processing (loop 3) started from step 1517 (step 1520).

  Although not shown in the figure, as a method for evaluating the relationship between modules not only from the connection relationship of the aforementioned modules, the position information and the IT infrastructure information but also from another viewpoint, the IT between step 1506 and step 1520 Processing for applying a policy that uses information related to infrastructure may be inserted.

  For example, according to the example of FIG. 6, the policy ID: MP4 is the policy that the user first has the source code including the module (in visual programming, the module including the property information and the information such as the wires connecting the modules). Compared to the commit ID issued by the source code management system when registering in a source code management system (not shown) such as git, and if the commit IDs match, the module developed at the same time The point corresponding to the policy ID: MP4 is added to the module-related point 903. In this embodiment, a commit ID is stored in the module management table 131 as the creation commit 507.

  In addition, according to the example in FIG. 6, the policy ID: MP5 policy is the same as the policy ID: MP4 policy described above when the source code including the module is edited and updated. The commit ID issued from the management system is compared between the modules. If the commit IDs match, it can be determined that the module has been changed at the same time, and the point corresponding to policy ID: MP5 is the module. It is added to the related point 903. In this embodiment, the commit ID is stored as the update commit 508 of the module management table 131.

  In addition, according to the example of FIG. 6, the policy with the policy ID: MP6 is registered as the author in the module management table 131 when the source code including the module is registered in the source code management system such as git. Registered (omitted in the module management table 131 of this embodiment). If modules are compared based on that information, and the Authors match, the same user (module developer) is likely to be involved in the development, and its configuration properties are also likely to match. Is assumed. In such a case, a point corresponding to the policy ID: MP6 is added to the module-related point 903.

  In addition, according to the example in Fig. 6, the policy with policy ID: MP7 categorizes modules created in the past for reuse such as data acquisition, data analysis, data storage, etc. Register with a code management system. When a new application program is created by reusing it, information for identifying the category is registered as a category 509 in the module management table 131. A comparison is made between modules based on that information. If the categories match, the point corresponding to the policy ID: MP7 is added to the module-related point 903.

  From here, the aggregation candidate generating unit 122 evaluates the relationship between the properties in the module. By evaluating the degree of relevance between these properties using a policy, it is used to present as a property group that is likely to be shared later by the user.

  The aggregation candidate generation unit 122 acquires a policy of type 602 == “property” and policy type == “property comparison” from the policy management table 132 (step 1521).

  The aggregation candidate generating unit 122 acquires information on the comparison group from the module comparison table 134 (step 1522). The aggregation candidate generation unit 122 detects a possibility that the two modules belonging to each comparison group acquired in this step can be shared. By the way, when acquiring information of this comparison group, if processing is performed for all the comparison groups, there is a possibility that a huge amount of calculation is required. The aggregation candidate generation unit 122 may exclude the property from being evaluated later.

  Next, the aggregation candidate generating unit 122 performs loop processing (loop 4) for each comparison group in the module comparison table 134 (step 1523). Hereinafter, a single comparison group is taken as an example (“target comparison group” in the description of loop 4). Note that the calculation amount may be reduced by excluding a comparison group having a low module-related point 903 at the time of this loop processing.

  The aggregation candidate generation unit 122 registers all the property elements of the two modules constituting the target comparison group in the property table 135 (step 1524).

  Next, the aggregation candidate generating unit 122 applies all the “property” policies in the policy management table 132 to all the property elements registered in the property table 135 in step 1524 (loop 5). Is started (step 1525). Hereinafter, a single property element is taken as an example (“target property element” in the description of loop 5). In this case, the policy is applied to each property element, but the aggregation candidate generator 122 avoids applying the policy to the specific policy and property element, or the property element satisfies the specific policy. In some cases, it may be possible to avoid applying all policies to each property element by applying restrictions such as avoiding application of other policies. Further, the policy may be applied to the property element periodically, not at the timing of the aggregation process, or at a timing when a new policy or property element is registered, and as a result, the loop process (loop 5) may be omitted.

  The aggregation candidate generating unit 122 starts a loop process for applying the policy of the type 602 “property” to the target property element (step 1526). Hereinafter, one policy out of the “property” policies is taken as an example (“target policy” in the description of loop 6).

  The aggregation candidate generator 122 applies the target policy to the target property element (step 1527). The aggregation candidate generating unit 122 determines whether or not the target property element satisfies the target policy (step 1528).

  If the determination result in step 1528 is true, the process moves to step 1529; otherwise, the process moves to step 1530.

  For example, referring to FIG. 5, if the target property element is the property element “IP.Mod2” of the module Mod2, the property value is “1.1.1.1”. Referring to FIG. 6, if the target policy is policy ID: PP1 policy (a policy for detecting whether it is in IP format), the target property element satisfies the target policy. Therefore, the process moves to step 1529. However, if the target policy is policy ID: PP2 policy (a policy that detects whether it is in the Port format, as an example, whether or not it falls within the range between the minimum port number 0 and the maximum port number 65535) If the target property element does not satisfy the target policy, the process moves to step 1530.

  The policy whose type 602 is “property” is applied to the target property, and the loop processing (loop 6) from step 1526 ends (step 1530).

  When the processing is completed for all the property elements in the property table 135, the loop processing (loop 5) from step 1525 ends (step 1531), and the processing moves to step 1532.

  Next, the aggregation candidate generating unit 122 creates a combination of two property elements from the two properties respectively included in the two modules constituting the target comparison group (step 1527). One property element in the target comparison group is any property element in the properties of one module. The other property element in the target comparison group is any property element in the property of the other module. In this embodiment, in the case of a combination of module Mod2 and module Mod3, {detection pattern.Mod1, IP.Mod2}, {detection pattern.Mod1, Port.Mod2}, {detection pattern.Mod1, User.Mod2}, { A combination is generated in the form of detection pattern .Mod1, Password.Mod2}. Since the number of property combinations affects the amount of processing thereafter, specific properties may be set so as not to be combined. For example, data types that do not match may be excluded as combinations.

  Next, the aggregation candidate generation unit 122 performs a loop process (loop 7) for all the combinations of property elements until the process is completed (step 1533). Hereinafter, a single combination (pair) of property elements is taken as an example (“target combination” in the description of loop 7).

  The aggregation candidate generation unit 122 starts a loop process (loop 8) for applying all the policies of the type 602 “property comparison” in the policy management table 132 to each property element belonging to the target combination (step 8). 1534). Hereinafter, one property of the “property comparison” policy is taken as an example (“target policy” in the description of the loop 8).

  The aggregation candidate generation unit 122 determines whether or not the prior policy 605 is set for the target policy (step 1535). If the determination result at step 1535 is true, the process moves to step 1536. Otherwise, the process moves to step 1538.

  In step 1536, the aggregation candidate generation unit 122 acquires information as to whether or not the prior policy is satisfied for each of the two properties constituting the target combination. The information to be acquired is information on the prior policy 1002 of the property table 135.

  Next, based on the information of the pre-policy 605 (the pre-policy 605 corresponding to the target policy) of the policy management table 132 and the information of the pre-policy 1002 acquired in step 1536, the aggregation candidate generation unit 122 performs property processing in the next step. It is determined whether or not the policy should be applied to the combination (step 1537). The processing here is processing for determining whether or not the target policy satisfies the set precondition from the result of the prior policy. For example, the policy ID: PPC1 (policy that determines whether two property values in the IP format match), the policy ID: PP1 (policy that detects whether it is in IP format) as the prior policy 605 ) Is set. This means that each of the two property elements constituting the target combination to which the policy of policy ID: PPC1 is applied should be a property element satisfying the policy ID: PP1. When considering the application of the policy ID: PPC1 for the combination of property elements {detection pattern.Mod1, IP.Mod2}, the processing in step 1537 is the policy ID: PP1 policy that corresponds to the policy ID: PPC1 prior policy. Since the detection pattern .Mod1 does not satisfy the policy (the prior policy 1002 of the property table 135 does not include “PP1”), the policy ID: PPC1 is not applied. If the target combination is {IP.Mod1, IP.Mod4} and the target policy is a policy with policy ID: PPC1, the process of step 1537 is the policy ID: PP1 corresponding to the prior policy 605 of policy ID: PPC1. Since both .Mod1 and IP.Mod4 satisfy the policy (the prior policy 1002 of the property table 135 includes “PP1”), the policy ID: PPC1 is applied.

  Next, the aggregation candidate generating unit 122 determines whether the target combination satisfies the target policy (step 1538). If the determination result at step 1538 is true, the process moves to step 1539. Otherwise, the process moves to step 1540. For example, the target policy is policy ID: PPC1 (policy that determines whether two property values in IP format match), and the target combination is {IP.Mod2 (property value is 1.1. 1.1), IP.Mod3 (property value is 1.1.1.1)} (that is, when the property values are the same), the target combination satisfies the target policy, and the process moves to step 1539. Temporarily, the target policy is policy ID: PPC2 (policy that determines whether two property values in the Port format match), and the target combination is {Port.Mod2 (property value is 8000) , Port.Mod3 (property value is 8080)}, the target combination does not satisfy the target policy, and the process moves to step 1540.

  When the target policy is satisfied in step 1538, the aggregation candidate generating unit 122 adds the point of the target policy (the numerical value of the point 604 in the policy management table 132) to the property related point 905 of the target comparison group (step 1539). ). Note that a point corresponding to the policy ID as the prior policy 605 of the target policy may be added to the property-related point 905 of the target comparison group.

  When application of all policies of type 602 “property comparison” to the combination of properties is completed, the loop processing (loop 8) started from step 1535 is ended (step 1540).

  When the processing is completed for all the combinations of property elements, the loop processing (loop 7) started from step 1533 ends (step 1541).

  When the processing is completed for all the comparison groups in the module comparison table 134, the loop processing (loop 4) started from step 1523 ends (step 1542).

  Next, the aggregation candidate generation unit 122 notifies the display group generation unit 123 of the start of processing, and completes a series of processing (step 1543). In addition, in step 1543 (or in the previous stage), the aggregation candidate generating unit 122 has information indicating a combination satisfying the applied “property comparison” policy among the combination of property elements for the comparison group. , It may be registered in the module comparison table 134 as at least a part of the related property 904.

  FIG. 16 is a flowchart for explaining an example of the display group generation unit 123.

  The display group generation unit 123 is a property element candidate (group of modules in the GUI displayed by the screen display unit 141 of the visual programming tool 106) that can be shared in the process in which the user aggregates a plurality of modules to generate an aggregate module. (Display group)).

  Basically, a module having a high module-related point is displayed on one screen as much as possible, so that the user can easily determine whether to share the properties in the displayed module.

  Specifically, the display group generation unit 123 detects a processing start command from the aggregation candidate generation unit 122 and starts processing. (Step 1601).

  The display group generation unit 123 acquires the display condition (maximum module display number) from the display condition table 136 (step 1602). When there are a plurality of display conditions in the display condition table 136, the display group generation unit 123 accepts selection of a user-desired display condition at the time of starting aggregation processing from the user, or automatically selects a default display condition Display conditions may be automatically selected based on the environment information of the input device used by the user.

  The display group generation unit 123 acquires module information (for example, all information in the entry) of each module belonging to the selection range corresponding to the current aggregation process from the module management table 131 (step 1603).

  The display group generation unit 123 acquires information of each comparison group (for example, all information in the entry) belonging to the selection range corresponding to the current aggregation process from the module comparison table 134 (step 1604).

  The display group generation unit 123 starts loop processing (loop 1) for all modules belonging to the selection range corresponding to the current aggregation processing (step 1605). The processing order of the modules when performing the loop processing may be the display order 510 of the module management table 131 (in ascending order of the number). Hereinafter, a single module is taken as an example (“target module” in the description of loop 1).

  The display group generation unit 123 extracts a comparison group including the target module as a component based on the information acquired in Step 1604 (Step 1606). When the target module is module Mod1, the comparison groups are [Mod1, Mod2], [Mod1, Mod3], and [Mod1, Mod4]. At this time, the display group generation unit 123 may exclude [Mod1, Mod3] whose module-related points are equal to or less than a certain value (for example, “0”) from the comparison group extracted in step 1603, for example. In other words, the display group generation unit 123 may exclude the comparison group that is unlikely to perform the aggregation process by simultaneously displaying the modules.

  Next, the display group generation unit 123 generates a display group from the comparison group so that the number of modules to be displayed is equal to or less than the maximum module display number acquired in Step 1602 (Step 1607). The display group generated here is referred to as a “target display group” in this paragraph. For example, when the maximum module display number is “3”, the display group generation unit 123 has a margin for displaying two modules in addition to the target module Mod1, and therefore the comparison group [Mod1 , Mod2] and [Mod1, Mod4] are configured as target display groups. At this time, the display group generating unit 123 may create a comparison group [Mod1, Mod3] that does not fall within the target display group and store it in another display group, or display it as a comparison group with low relevance. It is not necessary to create a group. In step 1607, the display group generation unit 123 registers information 1201 to 1205 regarding the generated display group in the display group table 137. The display group ID 1201 is an ID determined by the display group generating unit 123 (or an ID specified by the user). The display group ID 1201 indicates an ID (or an ID specified by the user) determined by the display group generation unit 123 for the target display group. The comparison group 1202 indicates the ID of each comparison group included in the target display group. The common target 1203 is an invalid value “-” at this point. A display condition 1204 indicates the display condition acquired in step 1604. The selection range ID 1206 indicates the ID of the selection range corresponding to the current aggregation process. In step 1607, a comparison group having a module-related point that is greater than or equal to a certain value may be selected. In addition to a module-related point, a comparison group having a property-related point that is relatively higher than a certain value is selected. Also good.

  When processing has been performed for all modules belonging to the selection range corresponding to the current aggregation processing, the display group generation unit 123 completes the loop processing (loop 1) (step 1608).

  Next, the display group generation unit 123 notifies the aggregation execution unit 124 of the start of processing (Step 1609).

  FIG. 17 is a flowchart illustrating an example of the aggregation execution unit 124.

  The aggregation execution unit 124 displays the property group to the user by displaying the comparison group (candidate property to be shared) on the GUI (workspace) displayed by the screen display unit 141 of the visual programming tool 106. Determine whether or not to share. When the selection of property element sharing is received from the user, the aggregation executing unit 124 sets the shared property element as a property element for the aggregation module.

  Specifically, the aggregation execution unit 124 detects the start of processing from the aggregation execution unit 124 (step 1701).

  The aggregation execution unit 124 acquires information on all display groups (for example, all information on entries) from the display group table 137 (step 1702).

  The aggregation execution unit 124 starts loop processing (loop 1) for all display groups (step 1703). Hereinafter, a single display group is taken as an example (“target display group” in the description of loop 1).

  The aggregation execution unit 124 displays each module included in the target display group on the GUI (work space) (step 1704). An example of the result of step 1704 is shown in FIG. The display of a module may be a display of at least a part of detailed information related to the module, in addition to a display object representing the module (for example, a module icon that is a rounded rectangle). Here, “at least part of detailed information” means at least part of information acquired from the module relation table 131 for the module and at least part of module comparison table 134 for the comparison group to which the module belongs. And at least some of the information about the policy satisfied by each of the module and the comparison group.

  The user determines whether to share the displayed comparison group (property element set), and inputs the determination result to the GUI using the input device 104. At this time, if there is a comparison group determined to be shared, the aggregation executing unit 124 registers the ID of the comparison group as the common target 1203 in the display group table 137 (step 1705). If the user makes corrections retroactively to the previous display group, the user may return to the display screen of the previous display group.

  The aggregation execution unit 124 ends the loop processing (loop 1) when the processing is completed for all the display groups (step 1706).

  The aggregation execution unit 124 displays a screen as shown in FIG. 19 (for example, a GUI), that is, a confirmation screen as a list of property elements shared with the aggregation module (step 1707). In other words, the aggregation execution unit 124 causes the user to confirm information regarding the aggregation module.

  The aggregation execution unit 124 detects that the user has finished confirming the aggregation module and the properties to be shared (step 1708). The detection in step 1708 is, for example, acceptance of a confirmation end input from the user. If the user wants to change the property element to be shared, it may be possible to return to the screen for displaying the display group and to make the determination of sharing again.

  FIG. 18 shows an example of a property sharing screen that is a GUI that displays properties to be shared with the user.

  The property sharing screen 1800 is used to present information when the control unit 120 detects that there is a possibility that the user can share the property elements of the aggregated modules when the user aggregates multiple modules. Used. Further, the property sharing screen 1800 is also used by the user to select a property element to be shared based on the presented information.

  The property sharing screen 1800 is displayed by the screen display unit 141 of the visual programming tool 106.

  The property sharing screen 1800 displays a set of property elements determined by the control unit 120 to be shared. The property sharing screen 1800 displays a module icon 1801, a wire icon 1802, a property element list 1803, a sharing recommendation 1804, an explanation box 1805, a module related area 1806, and buttons 1807 to 1809.

  The module icon 1801 is an icon for expressing a module on a visual programming tool. In the illustrated example, module icons 1801C and 1802D of two modules “error ticket registration” and “log registration” are displayed. These are connected by a wire icon 1802. In the example shown in the figure, module icons 1801C and 1802D of two modules are displayed, but three or more modules are displayed on one screen within the range of the display conditions (maximum module display number) adopted. May be. Further, the number of modules (module icon 1801) displayed on one screen may be changed according to the display magnification.

  The wire icon 1802 is an icon indicating a wire for connecting modules, and is a GUI component prepared so that the relationship between modules can be visually determined.

  The property element list 1803 is a list of property elements displayed for each module and belonging to the module.

  The module icon 1801 and the wire icon 1802 may be displayed based on the connection destination ID 505 for each module in the module management table 131. The module icon 1801 and the wire icon 1802 are visual programming tools based on the connection destination ID 505 (or the flow information managed by the visual programming tool 106 (information on the connection relationship of each module) for each module in the module management table 131. 106 may be displayed.

  The standardization recommendation 1804 corresponds to presentation of a set of property elements determined by the control unit 120 as to be communicable. In the illustrated example, the common recommendation 1804 is composed of a box surrounding property elements and a line connecting them. Also, in the example shown in the figure, there are a solid line and a broken line as a box (frame line) surrounding the property element and a line connecting them. The recommended recommendation (that is, the recommendation determined (selected) by the user to share the set of target property elements) is shown. For example, the user switches between a solid line (to be shared) and a broken line (not to be shared) by specifying (for example, clicking) a set of property elements as a recommendation one or more times. Specify (input).

  An explanation box 1805 displays the reason for the common recommendation 1804, that is, the reason that the control unit 120 determines that commonality is possible. The user can determine whether or not to share a set of target property elements of the common recommendation 1804 with reference to the description in the description box 1805. An explanation box 1805 presents the value indicated by the module-related point 903 corresponding to the comparison group that is the target of the common recommendation 1804. In the illustrated example, the explanation box 1805 shows the reason for each common recommendation 1804 in advance, but instead, when the common recommendation 1804 is moused over, the common recommendation 1804 An explanation box 1805 may be displayed.

  The module-related area 1806 visually shows the range described by the explanation box 1805. In the example shown, two modules are displayed, so even if there is no module related area 1806, the modules in the range described in the explanation box 1805 can be determined, but three or more modules are displayed on the screen 1800. In this case, the module-related area 1806 is useful because it is difficult to determine the range covered by the explanation box 1805 without the module-related area 1806.

  A button 1807 is a button that the user presses when the determination of sharing is completed for the currently displayed property element list and the next property sharing determination is started. If there is no property that needs to be determined for sharing, the screen transitions to the confirmation screen in FIG.

  A button 1808 is a button that the user presses when returning to the property sharing screen before the present time. This is used when the user reconsider the property that he / she once tried to share. In the case of the first property sharing screen, since there is no previous property sharing screen, the screen does not have to change even if it is pressed, or the button 1808 may not be displayed.

  A button 1809 is a button that the user presses to cancel the aggregation process. As a result, the user can cancel the aggregation of modules on the way.

  Further, in this embodiment, it is described that a plurality of screens are switched by dividing the screen, but for example, the entire selection range to be aggregated is displayed and a part of the selection region is enlarged. GUI may be adopted. In this case, the screen may be switched not by the button 1807 or the button 1808 but by the user dragging with the mouse pointer.

  FIG. 19 shows an example of a confirmation screen that is a GUI that displays a list of property elements of the aggregation module.

  The confirmation screen 1901 is a screen for final confirmation after all determinations for sharing properties of modules to be aggregated are completed when a user aggregates a plurality of modules. The confirmation screen 1901 is displayed by the screen display unit 141 of the visual programming tool 106.

  A confirmation screen 1901 is a list of results obtained by determining whether to share property elements on the screen 1800 of FIG.

  The confirmation screen 1901 has a list box 1902. The list box 1902 includes a text box 1903, a common property element list 1904, and an individual property element list 1905. The confirmation screen 1901 has buttons 1906 to 1908.

  A text box 1903 displays the module name of the aggregation module. The module name of the aggregation module may be changed via the text box 1903, or the text box 1903 is initially blank, and the module name may be input by the user for the first time here.

  The common property element list 1904 is a list of property elements determined by the user to be shared. The common property element may be categorized so that the module to which the property element before commonization belongs can be determined. In this embodiment, when the property element to be shared belongs to each of the “error ticket registration” module and the “log registration” module, the property element to be shared is “[common] error ticket registration / log. It can be categorized as “Register”. In this example, the property value in the property element to be shared (in the case of IP property, for example, “1.1.1.1”) is also displayed, but among the property elements, the property value is not displayed. Property items in the common property element may be displayed.

  The individual property element list 1905 is a list of property elements other than the property elements determined to be shared in the process of sharing the property elements. Since each module belongs individually, an individual property element list 1905 is created for each module. In the present embodiment, as a representative, the property elements that are not made common to the “error ticket registration” module and the “log registration” module are displayed in a list for each module.

  A button 1906 is a button that is pressed when the user determines that an aggregation module may be generated by setting the displayed modules and properties.

  A button 1907 is a button used to cancel the aggregation process in the middle. As a result, the user can cancel the aggregation of modules on the way.

  A button 1908 is a button that the user presses when returning to the property sharing screen 1800 of FIG.

  According to the first embodiment, by executing the above-described processing, the user can reduce the number of properties of the aggregation module, and as a result, the setting man-hour for the aggregation module of the user is reduced. Note that since the aggregation module corresponds to one module, the control unit 120 registers the information of the aggregation module in the module management table 131. Also, the property element information shared by the control unit 120 with respect to the aggregation module is registered as the aggregation 906 in the module comparison table 134, and the property element information that has not been shared with respect to the aggregation module is stored in the module comparison table 134. Registered as non-aggregated 907.

  Example 2 will be described. At that time, differences from the first embodiment will be mainly described, and description of common points with the first embodiment will be omitted or simplified.

  In the second embodiment, when it is necessary to change the specifications of the modules constituting the aggregation module, the properties of the aggregation module can be reset by the user with the minimum necessary judgment.

  FIG. 20 is a flowchart illustrating an example of the change execution unit according to the second embodiment of the present invention.

  The change execution unit 2000 is a function added to the control unit 120, and specifies a display group for changing the property of the aggregation module based on the information of the module that needs to be changed.

  Specifically, the change execution unit 2000 accepts selection (designation) of an aggregation module and a module whose specifications are to be changed among modules constituting the module, and receives information on the aggregation module and information on the module of the specification change. Is acquired from the module management table 131 (step 2001).

  The change execution unit 2000 identifies the selection range ID 801 corresponding to the selected aggregation module and the ID of the module whose specification is to be changed from the selection range management table 133 (step 2002).

  The change execution unit 2000 refers to the module comparison table 134 and specifies a comparison group 902 having a selection range ID 908 that matches the specified selection range ID 801 and having a module ID whose specification is to be changed (step 2003).

  The change execution unit 2000 refers to the display group table 137 and identifies a display group corresponding to the comparison group 1202 including the comparison group ID that matches the comparison group ID 902 identified in step 2003 (step 2004).

  The change execution unit 2000 notifies the aggregation execution unit 124 of the display group ID of the specified display group (step 2005), and the processing is completed.

  Since the display group corresponding to the ID notified to the aggregation execution unit 124 in step 2005 has a comparison group including the module whose specifications are to be changed, this is applied to the processing after step 1703 of the aggregation execution unit 124 for this display group. By doing so, the property element list of the aggregation module can be reset by the user with the minimum necessary judgment.

  By the way, instead of starting after the user knows the module specification change, for example, the control unit 120 may detect the module specification change, or the control unit 120 or management that the module processing failed It may be detected by a monitoring system linked with the server 101. Also, the aggregation module property change processing may be triggered by the detection of these.

  Although several embodiments have been described above, the above description can be summarized as follows, for example. Note that the following summary may include matters not described above.

  In the management server 101 (an example of a program creation support device), the aggregation candidate generation unit 122 selects from among N modules (N is an integer of 2 or more) constituting a program created using the visual programming tool 106 Among the sub-flows that are the M modules (M is an integer not less than 2 and not more than N), P modules each having P properties (P is not less than 2 and not more than M) are determined. In the management server 101, the aggregation execution unit 124 can be shared as one property item, and the property items are Q property items (Q is 2 or more and P or less) that reflects the update of the one property item. If there are one or more groups in the P properties, it is indicated that each of the one or more property item groups can be shared. As a result, the user's setting man-hour for the property of the subflow is reduced.

  Each of the P modules is a module that belongs to a module group in which module-related points are relatively high or higher than a certain value among a plurality of module groups each including a plurality of modules. For each module group, the module-related point is one or more module comparison policies (for example, type 602 is “module comparison”), each of which is one or more policies prepared for evaluating the relationship between modules. The evaluation value calculated based on one or more module comparison policies satisfied by the module group. Since P modules are determined based on the module-related points, it is avoided that the property items are shared even if the property elements are the same or similar between the modules having low relationships.

  An example of the “module group” may be the display group described above or a comparison group. Specifically, in the above-described embodiment, one or more comparison groups are display groups, and module-related points are calculated for each comparison group, but multiple types of groups such as comparison groups and display groups are prepared. Instead of this, one type of group called a module group may be prepared, and a module-related point may be calculated for each module group.

  Further, “the module-related point is relatively high or higher than a certain value” may mean that the evaluation value is substantially high with respect to the relationship between the modules. Specifically, for example, one or a plurality of points It may be that one or more predetermined module comparison policies among the module comparison policies are satisfied.

  The plurality of module comparison policies include a connection relation policy (for example, policy ID: MP1 policy) that is a policy related to the number of hops between modules, and a position policy that is a policy related to the module position in the workspace provided by the visual programming tool 106 ( For example, policy ID: MP2 policy). For each module group, at least one of the connection relationship policy and the location policy is preferentially used in comparison with other module comparison policies for the calculation of module-related points. According to visual programming, the closer the distance between modules in the processing flow or the closer the distance in the workspace, the higher the relationship between the modules, and the higher the module group that satisfies such characteristics, the higher the module. We can expect to get related points. Note that “at least one of the connection relationship policy and the location policy is preferentially used over other module comparison policies” means that in at least one of the connection relationship policy and the location policy in the above-described embodiment. This is realized when the associated point 604 is higher than the point 604 of another module comparison policy, but may be realized by other methods.

  The plurality of module comparison policies include an IT infrastructure policy that is a policy related to an IT infrastructure that is a physical or virtual computer resource in which a module is deployed. As a result, it is possible to influence the module-related points that are the basis of whether or not the modules are included in the P modules from the viewpoint of the IT infrastructure where the modules are deployed.

  Each of the one or more property item groups described above includes one or a plurality of property comparison policies (for example, type 602 having one or a plurality of policies each prepared for evaluating the relationship between property elements. Property item group that satisfies the property comparison policy applied to the property item group. Thereby, two or more appropriate property items can be presented as property items that can be shared. In other words, even if the property item and the property element are the same, it is possible to avoid presenting the property item that is inappropriate for sharing as being able to be shared.

For each of the one or more property item groups described above, the “applied property comparison policy” is a property comparison policy in which the following (x) conforms to the following (y). Thereby, it can be expected that an appropriate property comparison policy is applied to each property item group.
(X) Among one or a plurality of property policies (for example, a policy whose type 602 is “property”), each of which is one or a plurality of policies prepared for evaluation related to property elements, Property policy satisfied by the property item to which it belongs (for example, the property policy set as the pre-policy 1002 in step 1529).
(Y) A property policy previously associated with the property comparison policy (for example, a property policy set in advance as the prior policy 605 for the property comparison policy).

  Each of the P modules may be a module belonging to a module group in which the property-related point is relatively high or higher than a certain value among the module groups whose module-related points are relatively high or higher than a certain value. For each module group, the property-related point is an evaluation value calculated based on one or more property comparison policies satisfied by the module group among one or a plurality of property comparison policies. In this way, narrow down modules that have common property items based on property-related points in addition to module-related points (for example, narrow down modules that have high relationships between properties as well as relationships between modules. ) Is possible.

  When any module in the subflow is changed, the aggregation execution unit 124 performs P module including the module after the change (for example, a module belonging to the comparison group specified by the change execution unit 2000). A presentation that can be shared (for example, after step 1903) is executed. Thereby, even if the module in the subflow is changed, it is possible to maintain common module items for the subflow including the module after the change (subflow after the change).

  A plurality of module comparison policies include a policy that defines that source codes of all modules belonging to a module group are newly created at the same time for the source code management system (for example, policy ID: MP4 policy), It includes at least one policy with a policy (for example, policy ID: MP5 policy) defining that the source code of all modules belonging to the module group is updated at the same time with respect to the source code management system. It is considered that there is a high relationship between modules whose creation date and update date and time managed by the source code management system are in the same period (for example, the difference between the creation date and update date is less than a certain value). From such a viewpoint, it is possible to influence the module-related points that are the basis of whether or not they are included in P modules.

  The plurality of module comparison policies include a policy that defines that all modules belonging to the module group are developed by the same developer. The relationship between modules developed by the same developer is considered to be high, but from this point of view, it is possible to influence the module-related points that are the basis of whether or not they are included in P modules .

  The plurality of module comparison policies include a policy that defines that all modules belonging to the module group have the same category of the base module or module template. Although it is considered that the relationship between the underlying modules or modules with the same module template category is high, from this point of view, it affects the module-related points that are the basis of whether or not they are included in P modules. Can be given.

  Although several embodiments have been described above, these are examples for explaining the present invention, and the scope of the present invention is not intended to be limited to these embodiments. The present invention can be implemented in various other forms. For example, a visual programming tool may be referred to as a “model development environment”. A module that is a component of a program (software) or a processing unit may be referred to as a “node”, and a wire that is a connection between nodes may be referred to as an “edge”. Nodes and edges are terms in a directed graph, and the flow diagram in Node-RED can also be considered as a directed graph. A flow diagram, a block diagram, and a directed graph are synonymous, a flow diagram can be simply called “flow”, and “flow” and “graph” can be synonymous. An aggregation module of two or more modules constituting a flow corresponds to a “subflow”.

101: Management server

Claims (13)

(A) M modules selected from among N modules (N is an integer of 2 or more) constituting a program created using a visual programming tool (M is an integer of 2 or more and N or less) Among P sub-flows, P modules each having P properties (P is 2 or more and M or less) are determined,
Each of the P properties includes one or more property elements;
Each property element contains a pair of property item and property value,
(B) A property item group that is Q property items (Q is 2 or more and P or less) that can be shared as one property item and that reflects the update of the one property item is included in the P properties. If there are one or more items, it is indicated that each of the one or more property item groups can be shared.
A computer program that causes a computer to execute. Each of the P modules is a module belonging to a module group in which a module-related point is relatively high or higher than a certain value among a plurality of module groups each including a plurality of modules.
For each module group, the module-related points are one or more module comparison policies, each of which is one or a plurality of policies prepared for evaluating the relationship between modules. An evaluation value calculated based on the module comparison policy of
The computer program according to claim 1. The plurality of module comparison policies include at least one of a connection relation policy that is a policy related to the number of hops between modules and a position policy that is a policy related to a module position in a workspace provided by the visual programming tool,
For each module group, at least one of the connection relationship policy and the location policy is used preferentially over the module comparison policy other than the connection relationship policy and the location policy in calculating the module related point. To be
The computer program according to claim 2. The plurality of module comparison policies include an IT infrastructure policy that is a policy related to an IT infrastructure that is a physical or virtual computer resource in which a module is deployed.
The computer program according to claim 2. Each of the one or more property item groups is a property item group of one or more property comparison policies, each of which is one or more policies prepared for evaluating the relationship between property elements. A property item group that satisfies the applied property comparison policy.
The computer program according to claim 1. For each of the one or more property item groups, the applied property comparison policy is a property comparison policy in which the following (x) conforms to the following (y):
(X) a property policy satisfied by a property item belonging to the property item group among one or a plurality of property policies, each of which is one or a plurality of policies prepared for evaluation of property elements;
(Y) a property policy associated in advance with the property comparison policy among the one or more property policies;
The computer program according to claim 5. Each of the P modules has a relatively high module-related point among a plurality of module groups each including a plurality of modules or a relatively high property-related point among module groups higher than a certain value. Or a module belonging to a module group higher than a certain value,
For each module group
The module-related point is one or more module comparison policies each of which is one or more policies prepared for evaluating the relationship between modules, and is one or more module comparison policies satisfied by the module group. The evaluation value calculated based on
The property-related point is an evaluation value calculated based on one or more property comparison policies satisfied by the module group among the one or more property comparison policies.
The computer program according to claim 5. When any module in the subflow is changed, execute (B) on the P modules including the changed module.
The computer program according to claim 1. The plurality of module comparison policies are:
A policy that defines that the source code of all modules belonging to the module group is newly created at the same time for the source code management system that manages the source code data,
Including at least one policy with a policy defining that source codes of all modules belonging to a module group are updated at the same time with respect to the source code management system;
The computer program according to claim 2. The plurality of module comparison policies include a policy that defines that all modules belonging to a module group are developed by the same developer.
The computer program according to claim 2. The plurality of module comparison policies include a policy that defines that all modules belonging to a module group have the same base module or module template category.
The computer program according to claim 2. A subflow that is selected M modules (M is an integer not less than 2 and not more than N) out of N modules (N is an integer not less than 2) constituting a program created using the visual programming tool Among these, an aggregation candidate generating unit that determines P modules each having P properties (P is 2 or more and M or less);
Each of the P properties includes one or more property elements;
Each property element contains a pair of property item and property value,
There can be at least one property item group of Q property items (Q is 2 or more and P or less) that can be shared as one property item and the update of the one property item is reflected in the P properties. For example, a program creation support apparatus including an aggregation execution unit that presents that each of the one or more property item groups can be shared. A subflow that is selected M modules (M is an integer not less than 2 and not more than N) out of N modules (N is an integer not less than 2) constituting a program created using the visual programming tool Determine P modules each having P properties (P is 2 or more and M or less),
Each of the P properties includes one or more property elements;
Each property element contains a pair of property item and property value,
There can be at least one property item group of Q property items (Q is 2 or more and P or less) that can be shared as one property item and the update of the one property item is reflected in the P properties. For example, it is suggested that each of the one or more property item groups can be shared.
Program creation support method.