JP6801086B2 - Program development support device, program development support method, and program development support program - Google Patents

Description

The present invention relates to a program development support device or the like that displays a node indicating a set of processes as an object and creates a flow definition indicating a node configuration in the program based on a user's operation on the object.

In software development, visual programming that develops programs using visual objects is known. In visual programming, each node, which is a group of processes, is represented by blocks (objects), and by performing operations such as connecting these blocks, the program flow (nodes included in the program and connections between nodes, etc.) Can be created. According to this visual programming, the flow of the program can be visually understood, and even a user who does not have knowledge of the programming language can easily develop the program.

In addition, in the development support device that can execute visual programming, it is possible to output and save the definition of the flow of the created program as a file. The development support device can continue to develop similar programs by reading the flow definition file.

Also, in software development, a team of multiple developers may jointly develop the same program, but in this case, a version control system may be used to maintain the integrity of the program. is there. Some version control systems provide not only version control of source code, but also change proposal functions, confirmation of differences between versions, and other support functions for efficient team development. When promoting software development by utilizing the functions of such a version control system, developers will establish a development procedure within the team and proceed with development according to it.

The version control system manages text information and files. Therefore, the flow definition file output by the development support device can also be managed. However, the difference display function used when confirming the changed part targets the text, and it is difficult to grasp the correspondence with the visual expression on the development support device.

In addition, in order to use the version control system, knowledge of CLI (Command Line Interface) commands and development procedures using the version control system is required. In particular, in development support devices that can execute visual programming, it is difficult to use the version control system efficiently because users who do not have specialized knowledge of software development may be the main users. Is.

As a technique related to visual programming, for example, Patent Document 1 discloses a technique for registering a control logic created by a software development device in a version control system. Further, Patent Document 2 discloses a technique capable of easily confirming the difference between the block diagram before the change and the block diagram after the change.

JP-A-2015-162218 Japanese Unexamined Patent Publication No. 2016-177668

For example, when a plurality of developers jointly develop one program, there are a plurality of flow definitions having different versions for one program to be developed. In this case, in order to create the final program, it is necessary to merge one flow definition with another flow definition. In such a case, there is a possibility that a collision occurs between one flow definition and another flow definition, and the merge cannot be performed as it is.

When a collision occurs in this way, it is necessary to revise the flow definition. In this case, for example, it is conceivable to modify the flow definition by displaying the difference between one flow definition and another flow definition.

However, there may be a situation where it is not possible to grasp how to modify the flow definition only by checking the difference between one flow definition and another flow definition. For example, if two flow definitions modify each of the flow definitions that have a common ancestor, how should they be modified without considering the difference from the flow definition that is the ancestor? I can't figure out properly.

The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a technique capable of appropriately displaying information necessary for editing a flow definition in which a plurality of versions exist.

In order to achieve the above object, the program development support device according to one viewpoint defines a flow definition including one or more processing nodes constituting the development target program and the connection relationship of the processing nodes according to the user's operation on the object indicating the processing node. In the program development support device to be created, the first flow definition acquisition unit that acquires the first flow definition, which is the flow definition at a predetermined time of the development target program, and the first flow definition of the development target program after the predetermined time. The second flow definition acquisition unit that acquires the second flow definition that reflects the changes in the above, and the third flow definition that has been changed since a predetermined time based on the first flow definition of the development target program are stored. A collision determination unit that determines whether or not the third flow definition storage unit, the third flow definition, and the second flow definition collide, and a first flow definition and a second flow definition when it is determined that they collide with each other. There is a difference between the processing node between the first flow definition and the second flow definition, and the difference detection unit that detects the difference between the processing nodes of the first flow definition and the third flow definition. When there is a difference and when there is no difference, the display mode of the object indicating the processing node of the second flow definition is changed and displayed, and when there is a difference between the first flow definition and the third flow definition and there is no difference. A node display processing unit that displays the object indicating the processing node of the third flow definition in a different display mode is provided.

According to the present invention, it is possible to appropriately display the information necessary for editing a flow definition in which a plurality of versions exist.

FIG. 1 is an overall configuration diagram of a program development management system according to an embodiment. FIG. 2 is a hardware configuration diagram of the visual program device according to the embodiment. FIG. 3 is a diagram showing an example of the repository management table according to the embodiment. FIG. 4 is a diagram showing an example of a modified collision management table according to an embodiment. FIG. 5 is a flowchart of the program development process according to the embodiment. FIG. 6 is a flowchart of the flow definition reading process according to the embodiment. FIG. 7 is a flowchart of the flow definition saving process according to the embodiment. FIG. 8 is a flowchart of the flow display process according to the embodiment. FIG. 9 is a diagram showing an example of a flow display screen according to an embodiment.

The embodiment will be described with reference to the drawings. It should be noted that the embodiments described below do not limit the invention according to the claims, and all of the elements and combinations thereof described in the embodiments are indispensable for the means for solving the invention. Is not always.

In the following description, the information may be described by the expression of "AAA table", but the information may be expressed by a data structure other than the table (for example, a list or an associative array). That is, the "AAA table" can be called "AAA information" to show that the information does not depend on the data structure.

(Overall system configuration)
FIG. 1 is an overall configuration diagram of a program development management system according to an embodiment.

The program development management system 1 includes a visual program device 51 as an example of one or more program development support devices, and a version control system (VCS system) 61 as an example of a version control system. One version control system 61 can manage the version of the program (flow definition) in the plurality of visual program devices 51.

The visual program device 51 may be composed of one or more computers. Further, the visual program device 51 may be composed of a virtual machine composed of one or more computers, and may be composed of, for example, a virtual machine realized by executing a container on the computer. Further, the version control system 61 may be composed of one or more computers. Further, the version control system 61 may be configured by a virtual machine composed of one or more computers, and may be configured by, for example, a virtual machine realized by executing a container on the computer.

The visual program device 51 and the VCS system 61 are connected to each other via the communication network 20. The communication network 20 may be a wired LAN (Local Area Network), a wireless LAN, a WAN (Wide Area Network), or the like.

The VCS system 61 holds one or more repositories 62. The repository 62 manages and holds a plurality of flow definitions for the program to be developed. The repository 62 can hold a branch 63 that can separate and manage different flow definitions of different versions developed simultaneously and concurrently for a predetermined development target program. Branch 63 manages the flow definition 64. When the flow definition 64 is changed, the branch 63 also manages the history of the change. In the flow definition 64, a definition (node definition) of a node (processing node) which is a group of processes (program components) constituting a program, for example, node identification information, a connection relationship between a node and another node, and the like are provided. Contains information to indicate.

The branch 63 is based on, for example, a branch (main branch) that manages the main flow definition (second flow definition) of the program to be developed, and a flow definition (first flow definition) of the main branch at a predetermined time point. There is a branch (development branch) that manages flow definitions that are created and edited. A development branch is created for each developer (user) who jointly edits the same development target program, for example.

The visual program device 51 includes an input / output unit 52, a flow execution unit 53, a flow editing unit 54, and a version control system cooperation unit (VCS cooperation unit) 55. Here, the VCS cooperation unit 55 corresponds to an example of a first flow definition acquisition unit, a second flow definition acquisition unit, a collision determination unit, a difference detection unit, and a transmission unit. Further, the flow editing unit 54 corresponds to an example of the node display processing unit. Further, the input / output unit 52 corresponds to an example of the change reception unit.

The input / output unit 52 receives input from, for example, a user who uses the visual program device 51, and displays and outputs various information. The flow execution unit 53 executes a flow (program) corresponding to the created flow definition. The flow editing unit 54 creates a flow (display flow) to be displayed on the screen based on the flow definition. The VCS cooperation unit 55 performs a process of managing the flow definition in cooperation with the VCS system 61.

The VCS linkage unit 55 holds one or more local repositories 58 (an example of a third flow definition storage unit). The local repository 58 is created based on the state of the repository 62 of the VCS system 61 at a given time. Therefore, at the initial stage of creation, the local repository 58 has a branch (main branch on the local side) in the same state as the main branch existing in the repository 62 at that time. After that, when the main branch of the VCS system 61 is updated or the like, the main branch of the local repository 58 may be in a different state from the main branch of the VCS system 61. The local repository 58 includes one or more branches 59. Branch 59 manages the flow definition 60. The branch 59 is created based on the main branch of the repository 62 at that time (and the flow definition (first flow definition) in the repository 62) when the user of the visual program device 51 starts editing the program to be developed. There is a development branch. The user of the visual program device 51 makes changes to the flow definition in this development branch. This flow definition corresponds to the third flow definition.

Further, the VCS cooperation unit 55 has a repository management table 56 for managing the local repository 58 and a change collision management table 57 for managing information regarding change conflicts in the flow definition.

(Hardware configuration)
FIG. 2 is a hardware configuration diagram of the visual program device according to the embodiment.

The visual program device 51 is composed of, for example, one computer, and communicates with a CPU (Central Processing Unit) 21 as an example of a processor, a memory 22, a storage device 23, an input device 24, and an output device 25. A device 26 is provided. The components 21 to 26 are communicably connected via, for example, a bus.

The memory 22 is, for example, a RAM (Random Access Memory), and stores various programs including a program (program development support program) for configuring each functional unit of the visual program device 51. The CPU 21 executes various processes by executing the program stored in the memory 22. The storage device 23 is, for example, a non-volatile storage device such as a hard disk or SSD (Solid State Drive), and stores various information including a program. The input device 24 is, for example, a keyboard or a mouse, and receives input from the user of the visual program device 51. The output device 24 is, for example, a display, and displays and outputs various information. The communication device 26 communicates with an external device (VCS system 61 or the like) via the communication network 20.

Here, the input / output unit 52 of FIG. 1 is composed of an input device 24 and an output device 25. Further, the flow execution unit 53 and the flow editing unit 54 are configured by the CPU 21 executing the program of the memory 22. The process executed by the VCS cooperation unit 55 is configured by the CPU 21 executing the program of the memory 22. Therefore, the processing executed by the flow execution unit 53, the flow editing unit 54, and the VCS cooperation unit 55 can be said to be the processing executed by the processor. The function of storing the repository management table 56, the change collision management table 57, and the local repository 58 in the VCS cooperation unit 55 is configured by the storage device 23.

(Repository management table)
FIG. 3 is a diagram showing an example of the repository management table according to the embodiment.

The repository management table 56 is a table that holds information indicating the correspondence between the repository 62 of the VCS system 61 and the local repository 58, and is an entry (record) corresponding to each pair of the corresponding repository 62 and the local repository 58. To store. The entries in the repository management table 56 include an external repository field 561, a main branch field 562, a local repository field 563, a development branch field 564, and a branch commit field 565.

The external repository field 561 is an area for storing the location information (for example, URL) of the repository 62 held by the VCS system 61. The main branch field 562 is an area for storing the identification information (for example, the branch name) of the branch 63 (main branch) that is the base of development specified by the user 50. The local repository field 563 is an area for storing the location information of the repository 62 corresponding to the entry and the local repository 58 (for example, the path name of the local repository 58 in the visual program device 51). The development branch field 564 is an area for holding identification information (for example, the name of the development branch) of the branch (development branch) being developed in the visual program device 51. The branch commit field 565 is an area for storing information (for example, the commit ID of the main branch at the time of branching) indicating the state of the repository 62 at the time when the main branch and the development branch branch (when the development branch is created). Is. By using this commit ID, information on the main branch at the time of branching (for example, flow definition) can be obtained from the repository 62.

(Change collision management table)
FIG. 4 is a diagram showing an example of a modified collision management table according to an embodiment.

The change collision management table 57 is a table that holds information on the conflicted nodes when there is a change conflict between two branches (between the main branch and the development branch), and corresponds to each conflicted node. Store the entry. Here, the collision means a state in which each node in the flow definition of two branches cannot be properly merged.

The entries in the change conflict management table 57 include a node ID field 571, a branching node definition field 572, a main branch node definition field 573, and a development branch node definition field 574.

The node ID field 571 is an area for storing identification information (for example, a hash value defined by the visual program device 51 for each node) uniquely indicating the node in which the change collision has occurred. The node definition field 572 at the time of branching is an area for storing the node information (for example, JSON format node definition) at the time when the main branch and the development branch branch off for the node in which the change conflict occurs. .. The main branch node definition field 573 is an area for storing the node information (for example, JSON format node definition) in the main branch for the node in which the change conflict occurs. The development branch node definition field 574 is an area for storing node information (for example, JSON format node definition) in the development branch for the node in which the change conflict occurs.

(Development flow in visual programming)
Next, the operation of the visual programming device 51 according to the present embodiment will be described along with an example of the development flow in visual programming.

FIG. 5 is a flowchart of the program development process according to the embodiment.

The user 50 creates a repository (external repository) 62 for storing the flow definition of the development target program in the VCS system 61 (step S41). The visual program device 51 may be activated, the user 50 may give an operation instruction to the visual program device 51, and the repository 62 may be created in the VCS system 61 via the visual program device 51.

Next, the user 50 activates the visual program device 51 (step S42).

When the visual program device 51 is started, it acquires the flow definition from the VCS system 61 by executing the flow definition reading process shown in FIG. 6 and displays the flow corresponding to the flow definition (step S43).

Next, the visual program device 51 executes editing on the displayed flow according to the operation input to the input / output unit 52 by the user 50 (step S44).

Upon receiving the editing end instruction from the user 50, the visual program device 51 executes the flow definition saving process shown in FIG. 7 for saving the flow definition in the VCS service 61 (step S45).

Note that FIG. 5 shows a process when developing a program for which the repository 62 has not been created in the VCS system 61. For example, when developing a program for which the repository 62 has already been created, FIG. 5 shows the process. The process from step S42 may be executed.

(Flow of flow definition reading process)
FIG. 6 is a flowchart of the flow definition reading process according to the embodiment. The flow definition reading process is a process corresponding to step S43 in FIG.

First, the VCS cooperation unit 55 receives the designation of the repository 62 of the VCS system 61 that manages the flow definition of the program to be developed from the user 50, and does the local repository corresponding to the accepted repository 62 exist as the local repository 58? Whether or not it is determined with reference to the repository management table 56 (step S431).

As a result, when the local repository 58 corresponding to the designated repository 62 does not exist (step S431: No), the VCS linkage unit 55 acquires the designated repository 62 from the VCS system 61 and corresponds to the repository 62. Create the local repository 58 to be used (step S432). When acquiring the repository 62 from the VCS system 61, for example, when the VCS system 61 is a git, the git command may be used.

On the other hand, when the local repository 58 corresponding to the designated repository 62 exists (step S431: Yes), or when the local repository 58 is created in step S432, the VCS linkage unit 55 sends the local repository 58 to the local repository 58. A new development branch 59 is created (step S433). Here, the development branch 59 is created by copying various information of the main branch (main branch acquired from the repository 62) in the local repository 58. After creating the development branch 59, the VCS linkage unit 55 adds an entry to the repository management table 56, and adds the location information of the repository 62 of the VCS system 61, the identification information of the main branch, the location information of the local repository 58, and so on. In the corresponding field of the entry that added the identification information of the development branch and the information indicating the state of the repository at the time of branching between the main branch and the development branch (when the development branch was created) (for example, the commit ID at the time of branching). Register (step S434). The commit ID at the time of branching may be obtained from the VCS system 61 when the development branch 59 is created, for example.

Next, the flow editing unit 54 reads the flow definition 60 stored in the development branch 59, creates a display flow corresponding to the flow definition 60 (step S435), and the input / output unit 52 includes a screen including the display flow. Is displayed (step S436).

(Flow of flow definition storage process)
FIG. 7 is a flowchart of the flow definition saving process according to the embodiment. The flow definition saving process is a process corresponding to step S45 in FIG.

When the visual program device 51 receives a request from the user 50 to commit the flow definition to the development branch (step S451), the VCS linkage unit 55 refers to the repository management table 56 and of the VCS system 61 corresponding to the development branch 59. The main branch 63 and the external repository 62 are specified, and it is determined whether or not the main branch 63 has been updated since the time when the development branch 59 was created (step S452).

As a result, when there is no update in the main branch 63 (step S452: No), the VCS linkage unit 55 does not cause a change conflict between the development branch and the main branch, and makes the development branch the main branch. Since it means that there is no problem even if they are merged, the process proceeds to step S461.

On the other hand, when there is an update in the main branch 63 (step S452: Yes), the VCS linkage unit 55 acquires the updated contents of the main branch 63 from the VCS system 61 and updates the main branch 59 of the local repository 58 (step S452: Yes). Step S453).

Next, the VCS cooperation unit 55 executes a rebase process for connecting the development branch to the updated main branch (step S454). As for the function of the rebase process, for example, the function of the VCS system such as git may be incorporated in the VCS cooperation unit 55. In the rebase process, there is a conflict of changes between the flow definition of the development branch (third flow definition) and the flow definition of the main branch (second flow definition) (the node of the flow definition of the development branch is placed in the flow definition of the main branch). When (there is a part that cannot be connected) occurs, information regarding the occurrence of the collision (change collision information) is added and saved in the file of the flow definition 60. The change collision information may be the identification information of the node in which the collision has occurred, or the information indicating that the collision has occurred.

Next, the VCS cooperation unit 55 determines whether or not there is a conflict of change in the flow definition between the development branch and the main branch. Specifically, the change conflict information is included in the flow definition file of the development branch. It is determined whether or not it is satisfied (step S455). As a result, when there is no change conflict (step S455: No), it means that there is no problem in merging the development branch into the main branch, so the VCS linkage unit 55 steps the process. Proceed to S461.

On the other hand, when a change collision has occurred (step S455: Yes), that is, when the change collision information is included in the flow definition, the VCS cooperation unit 55 determines the change collision based on the change collision information. Identify all nodes where is occurring. Next, the VCS linkage unit 55 refers to the repository management table 56 for each of the identified nodes, and refers to the node definition in the flow definition of the main branch at the time of branching (first flow definition) and the latest flow definition of the main branch. The node definition in (second flow definition) and the node definition in the flow definition (third flow definition) of the development branch are acquired from the repository 62 or the local repository 59. Next, the VCS cooperation unit 55 adds a new entry corresponding to the node in which the change collision has occurred to the change collision management table 57, and the node ID field 571 of the added entry contains the node in which the collision has occurred. The identification information is stored, and the corresponding node definition already acquired is saved in each of the branch time node definition field 572, the main branch node definition field 573, and the development branch node definition 574 (step S456).

Next, the flow editorial unit 54 reads the flow definition including the change collision information and the change collision management table 57, and displays the flow display 30 (see FIG. 9) including the information regarding the change collision of the node. A process (see FIG. 8) is performed (step S457).

As a result, the user 50 can edit the flow definition for resolving the collision by operating the input / output unit 52 with reference to the displayed flow display screen 30. At this time, the visual program device 51 reflects the edited content in the flow definition based on the operation of the user 50 on the input / output unit 52 (step S458).

Next, when the user 50 receives a request to commit the flow definition that resolves the conflict to the development branch, the VCS linkage unit 55 executes a process of committing the flow definition that resolves the conflict to the development branch of the local repository 58 ( Step S459). As a result, when the commit to the development branch of the flow definition is successful, the VCS linkage unit 55 deletes the entry corresponding to the node that resolved the conflict from the change collision management table 57 (step S460), and the development branch of the local repository 58. PUSH to the VCS system 61, that is, register the development branch to the VCS system 61 (step S461). In the VCS system 61, the registered development branch is merged with the main branch, so that the content edited by the user 50 of the visual program device 51 is reflected in the flow definition of the main branch.

Next, the VCS linkage unit 55 deletes the development branch pushed from the local repository 58 to the VCS system 61 (step S462), and deletes the entry corresponding to this development branch from the repository management table 56 (step S463).

(Flow of flow display processing)
FIG. 8 is a flowchart of the flow display process according to the embodiment. The flow display process is a process corresponding to step S457 in FIG.

First, the flow editorial unit 54 reads the flow definition including the change collision information (step S501), and acquires one node definition to be processed from one or more node definitions included in the flow definition (step S502).

Next, the flow editorial unit 54 determines whether or not the node corresponding to the acquired node definition is registered in the change collision management table 57 (step S503). As a result, when this node is not registered in the change collision management table 57 (step S503: No), it indicates that no change collision has occurred, so that the flow editorial unit 54 corresponds to this node. The block (object) to be changed is drawn in a display mode (for example, black) indicating that no change collision has occurred (step S510), and the process proceeds to step S509.

On the other hand, when this node is registered in the change collision management table 57 (step S503: Yes), it indicates that a change collision has occurred between the main branch and the development branch for this node. The flow editorial unit 54 acquires the node definition at the time of branching corresponding to this node from the change collision management table 57, and sets the block corresponding to the node at the time of branching (first processing node) with the node related to the collision. Drawing is performed in a predetermined display mode (for example, gray) indicating that there is (step S504).

Next, the node editorial unit 54 acquires the node definition in the main branch of this node from the change collision management table 57, and determines whether or not there is a difference between the node definition of the main branch and the node definition at the time of branching ( Step S505).

As a result, when it is determined that there is no difference between the node definition of the main branch and the node definition at the time of branching (step S505: No), the node editorial unit 54 branches the block corresponding to the node of the main branch. It is drawn in the same color as the block corresponding to the node of time (gray in this embodiment) (step S511), and the process proceeds to step S507.

On the other hand, when it is determined that there is a difference between the node definition of the main branch and the node definition at the time of branching (step S505: Yes), the node editorial unit 54 sets the block corresponding to the node of the main branch at the time of branching. Drawing is performed in a display mode (for example, blue) different from the block corresponding to the node of (step S506), and the process proceeds to step S507. In step S506, when the node of the main branch is deleted, the node editorial unit 54 can visually recognize that the node has been deleted from the block corresponding to the node of the main branch. Draw in (for example, blue and dotted line). When the blocks are displayed in this way, it is possible to visually check whether or not there is a difference between these nodes by comparing the display modes of the blocks corresponding to the nodes of the main branch and the blocks corresponding to the nodes at the time of branching. Can be easily and appropriately grasped.

In step S507, the node editorial unit 54 acquires the node definition in the development branch of this node from the change collision management table 57, and determines whether or not there is a difference between the node definition in the development branch and the node definition at the time of branching. ..

As a result, when it is determined that there is no difference between the node definition of the development branch and the node definition at the time of branching (step S507: No), the node editorial unit 54 branches the block corresponding to the node of the development branch. It is drawn in the same color as the block corresponding to the node of time (gray in this embodiment) (step S512), and the process proceeds to step S509.

On the other hand, when it is determined that there is a difference between the node definition of the development branch and the node definition at the time of branching (step S507: Yes), the node editorial unit 54 sets the block corresponding to the node of the development branch to the main branch. The block corresponding to the node of No. 1 and the block corresponding to the node at the time of branching are drawn in a different display mode (for example, red) (step S508), and the process proceeds to step S509. When the node of the development branch is deleted in step S508, the node editorial unit 54 can visually recognize that the node has been deleted from the block corresponding to the node of the development branch. Draw in (for example, red and dotted line). When the blocks are displayed in this way, it is easy to visually check whether or not there is a difference between these nodes by comparing the display mode of the block corresponding to the node of the development branch and the block corresponding to the node at the time of branching. And it can be grasped appropriately. In addition, by comparing the display mode of the block corresponding to the node of the development branch and the block corresponding to the node of the main branch, it is possible to visually and appropriately grasp whether or not there is a difference between these nodes. Can be done. For the link line connecting the block of each node to the block of the next node, if the next node is specified in the node definition for this node, draw it according to the color of the block of each node. You may.

In step S509, the node editorial unit 54 determines whether or not the drawing of the block corresponding to the node is completed with all the nodes included in the flow definition as the processing target, and the node editing unit 54 determines whether or not the drawing of the block corresponding to the node is completed. If the drawing is not completed (step S509: No), the process proceeds to step S502, while if the drawing of the block for all the nodes to be processed is completed (step S509: Yes), the process proceeds to step S502. End the flow display process.

(Flow display screen)
FIG. 9 is a diagram showing an example of a flow display screen according to an embodiment.

The flow display screen 30 has a node selection area 31, a flow editing area 32, a node information display area 33, and a flow operation area 34.

The node selection area 31 is an area for displaying blocks (objects) indicating a plurality of nodes available in the visual program device 51. The user 50 operates the input / output unit 52 to select the block of the node to be used from the blocks displayed in the node selection area 31, and thereby selects the block of the node selected in the flow editing area 32. You will be able to arrange them.

The flow editing area 32 is an area for displaying a flow according to the flow definition. The flow displayed in the flow editing area 32 includes blocks (321 to 325, etc.) corresponding to the nodes included in the flow definition, connection lines indicating the connection relationship between the nodes, and the like. By operating the input / output unit 52, the user 50 can edit the flow definition (that is, the program) by editing the arrangement of the nodes in the flow definition, the connection relationship of the nodes, and the like in the flow editing area 32. it can.

In the flow editing area 32, when there is a change conflict between the development branch and the main branch, the block corresponding to the node at the time of branching (node at the time of branching) and the node of the main branch (main node) are supported. The blocks to be used and the blocks corresponding to the nodes (development nodes) of the development branch are displayed so that the difference in the node definitions corresponding to each node can be easily grasped. For example, block 322 corresponds to a branching node, block 323 corresponds to a main node, and block 324 corresponds to a development node. By looking at the display mode of blocks 322, 323, 324, it is possible to easily visually grasp whether or not there is a difference in the node definitions of the nodes corresponding to each block. In the example shown in FIG. 9, there is a difference in the node definition between the branching node corresponding to block 322 and the main node corresponding to block 323, and the branching node corresponding to block 322 and block 324 are supported. It shows that there is a difference in the node definition with the development node.

In the flow editing area 32, nodes that did not exist or deleted nodes are displayed in a display mode (for example, a dotted line) different from the blocks of other nodes so that they can be visually grasped. In addition, the newly added node may be displayed in a display mode different from the others so that the newly added node can be grasped. Further, in the flow editing area 32, the content of the node definition or the difference from the node definition of another node may be displayed corresponding to the block corresponding to the node. Specifically, the node definition or the content of the difference from the node definition of another node may be displayed in the vicinity of the block, and when the block is selected, the node definition or the node definition of another node may be displayed. The content of the difference from the node definition may be displayed in the node information display area 33. As a result, the node definition and the contents of the difference can be appropriately displayed on the flow display screen 30, and the user can easily and appropriately grasp the contents.

The node information display area 33 is an area in which the contents of the node definition related to the node selected in the node selection area 31 or the flow editing area 32 are displayed.

The flow operation area 34 is an area for selecting and designating an operation related to the management of the flow definition. The user 50 can specify an operation related to management by performing an operation by the input / output unit 52 on the node operation area 34. In the flow operation area 34, as the operation related to the management of the flow definition, for example, reading the flow definition, saving (committing) the flow definition, executing the flow definition, and the like can be selected.

The present invention is not limited to the above-described embodiment, and can be appropriately modified and implemented without departing from the spirit of the present invention.

For example, in the above embodiment, as shown in FIG. 7, when there is an update in the main branch of the VCS system 61 starting from committing the flow definition to the development branch, the main branch is acquired and the flow display process is performed. However, the present invention is not limited to this. For example, the VCS cooperation unit 55 is made to sequentially monitor whether or not the main branch in the repository 62 of the VCS system 61 has been updated, and the main branch is updated. When it is detected that the main branch has been acquired, the flow display process may be performed. In this way, the change collision caused by the update of the main branch can be grasped at an early stage, that is, at a time when the part related to the change collision is relatively small, and the change collision can be resolved relatively easily. be able to. Therefore, the load when resolving the change collision with the user 50 can be reduced, and the program development efficiency can be improved.

Further, in the above embodiment, when there is a change conflict between the development branch and the main branch on the flow display screen 30, three blocks corresponding to the branching node, the main node, and the development node are displayed. However, the present invention is not limited to this, and two blocks, a block corresponding to the main node and a block corresponding to the development node, may be displayed. Even in this way, it is possible to visually grasp whether or not the main node has a difference from the branch node and whether or not the development node has a difference from the branch node.

Further, in the above embodiment, when there is a difference between the nodes, the color and line type of the block corresponding to the node are changed, but the present invention is not limited to this, and for example, the shape of the block is changed. However, the point is that the visually recognizable display mode may be changed.

Further, in the above embodiment, a part or all of the processing performed by the CPU may be performed by the hardware circuit. In addition, the program in the above embodiment may be installed from the program source. The program source may be a program distribution server or storage media (eg, portable storage media).

1 ... Program development management system, 20 ... Communication network, 21 ... CPU, 22 ... Memory, 23 ... Storage device, 51 ... Visual program device, 52 ... Input / output section, 53 ... Flow execution section, 54 ... Flow editing section, 55 … VCS cooperation department, 56… Repository management table. 57 ... Change collision management table, 61 ... VCS system

Claims (15)

In a program development support device that creates a flow definition including one or more processing nodes constituting the development target program and the connection relationship of the processing nodes according to the user's operation on the object indicating the processing node.
The first flow definition acquisition unit that acquires the first flow definition, which is the flow definition at a predetermined time in the development target program,
A second flow definition acquisition unit that acquires a second flow definition that reflects changes after the predetermined time point with respect to the first flow definition of the development target program.
A third flow definition storage unit that stores a third flow definition that has been changed since the predetermined time point based on the first flow definition of the development target program.
A collision determination unit that determines whether or not the third flow definition and the second flow definition collide with each other.
When it is determined that a collision occurs, the difference between the processing nodes of the first flow definition and the second flow definition is detected, and the difference between the processing nodes of the first flow definition and the third flow definition is detected. Difference detector and
The display mode of the object indicating the processing node of the second flow definition is changed and displayed depending on whether the processing node is different or not between the first flow definition and the second flow definition. A node display processing unit that displays different display modes of objects indicating the processing nodes of the third flow definition depending on whether there is a difference between the first flow definition and the third flow definition or when there is no difference.
Program development support device equipped with. The node display processing unit displays an object indicating the first processing node included in the first flow definition, and processes the second flow definition in which there is no difference between the first flow definition and the second flow definition. The node object is displayed in the same display mode as the object indicating the first processing node, and the processing node of the second flow definition having a difference between the first flow definition and the second flow definition is shown. The object is displayed in a display mode different from the object indicating the first processing node, and the object indicating the processing node of the third flow definition in which there is no difference between the first flow definition and the third flow definition is shown. The object indicating the processing node of the third flow definition, which is displayed in the same display mode as the object indicating the first processing node and has a difference between the first flow definition and the third flow definition, is described in the first. 1. The program development support device according to claim 1, which is displayed in a display mode different from that of an object indicating a processing node. Claim 1 that the node display processing unit makes a display mode of an object indicating a processing node different depending on whether the difference about the processing node is addition of a processing node, change of a processing node, or deletion of a processing node. Alternatively, the program development support device according to claim 2. It is connected to the version management system that manages the version of the flow definition via the communication network.
The first flow definition acquisition unit acquires the first flow definition from the version management system, and obtains the first flow definition.
The program development support device according to claim 1, wherein the second flow definition acquisition unit acquires the second flow definition from the version management system. The second flow definition acquisition unit determines whether or not the second flow definition in the version management system has been updated, and if the second flow definition has been updated, after updating from the version management system. Get the second flow definition,
When the second flow definition acquisition unit acquires the updated second flow definition, the collision determination unit, the difference detection unit, and the node display processing unit obtain the updated second flow definition. The program development support device according to claim 4, wherein the process is executed by using the device. It also has a change reception unit that accepts changes to the third flow definition.
The collision determination unit determines whether or not the third flow definition reflecting the change received by the change reception unit collides with the second flow definition.
When it is determined that the third flow definition and the second flow definition to which the change is reflected do not collide, the third flow definition is transmitted to the version management system to be merged with the second flow definition. The program development support device according to claim 1, further comprising a transmitter. The node display processing unit can display a difference from the node definition of the processing node in the second flow definition or the first flow definition in correspondence with the object indicating the processing node of the second flow definition. The program according to claim 1, wherein the difference from the node definition of the processing node in the third flow definition or the third flow definition can be displayed in correspondence with the object indicating the processing node of the third flow definition. Development support device. A program development support method using a program development support device that creates a flow definition including one or more processing nodes constituting a development target program and a connection relationship between the processing nodes according to a user's operation on an object indicating the processing node.
(A) Acquire the first flow definition, which is the flow definition at a predetermined time point of the development target program.
(B) Acquire the second flow definition that reflects the changes after the predetermined time point with respect to the first flow definition of the development target program.
(C) The storage unit stores the third flow definition that has been changed since the predetermined time point based on the first flow definition of the development target program.
(D) It is determined whether or not the third flow definition and the second flow definition collide with each other.
(E) When it is determined that a collision occurs, the difference between the processing nodes of the first flow definition and the second flow definition is detected, and the difference between the processing nodes of the first flow definition and the third flow definition is detected. Detected
(F) The display mode of the object indicating the processing node of the second flow definition is displayed differently depending on whether the processing node is different or not between the first flow definition and the second flow definition. At the same time, a program development support method for displaying different display modes of objects indicating the processing nodes of the third flow definition depending on whether there is a difference between the first flow definition and the third flow definition or not. .. In the above (f), an object indicating the first processing node included in the first flow definition is displayed, and the processing node of the second flow definition having no difference between the first flow definition and the second flow definition. Is displayed in the same display mode as the object indicating the first processing node, and is an object indicating the processing node of the second flow definition having a difference between the first flow definition and the second flow definition. Is displayed in a display mode different from that of the object indicating the first processing node, and the object indicating the processing node of the third flow definition having no difference between the first flow definition and the third flow definition is described above. The object indicating the processing node of the third flow definition, which is displayed in the same display mode as the object indicating the first processing node and has a difference between the first flow definition and the third flow definition, is the first. The program development support method according to claim 8, wherein the object is displayed in a display mode different from that of the object indicating the processing node. In claim 8 or the above (f), the display mode of the object indicating the processing node is different depending on whether the difference regarding the processing node is the addition of the processing node, the change of the processing node, or the deletion of the processing node. The program development support method according to claim 9. The program development support device is connected to a version management system that manages the version of the flow definition via a communication network.
In (a), the first flow definition is acquired from the version management system.
The program development support method according to claim 8, wherein in the above (b), the second flow definition acquisition unit acquires the second flow definition from the version management system. In (b), it is determined whether or not the second flow definition in the version management system has been updated, and if the second flow definition has been updated, the second flow after the update from the version management system. Get the definition,
The program development support method according to claim 11, wherein in the above (d), (e), and (f), processing is executed using the updated second flow definition. (G) Accepting changes to the third flow definition
In (d), it is determined whether or not the third flow definition reflecting the change accepted in (g) and the second flow definition collide with each other.
(H) To have the version management system merge the third flow definition with the second flow definition when it is determined that the third flow definition and the second flow definition to which the change is reflected do not collide with each other. The program development support method according to claim 8, which is transmitted to. In (f), it is possible to display the difference from the node definition of the processing node in the second flow definition or the first flow definition in correspondence with the object indicating the processing node of the second flow definition. The program development according to claim 8, wherein the difference from the node definition of the processing node in the third flow definition or the third flow definition can be displayed in correspondence with the object indicating the processing node of the third flow definition. Support method. A computer for configuring a program development support device that creates a flow definition including one or more processing nodes constituting a development target program and a connection relationship between the processing nodes according to a user's operation on an object indicating the processing node. It is a program development support program
The computer
The first flow definition acquisition unit that acquires the first flow definition, which is the flow definition at a predetermined time in the development target program,
A second flow definition acquisition unit that acquires a second flow definition that reflects changes after the predetermined time point with respect to the first flow definition of the development target program.
A third flow definition storage unit that stores a third flow definition that has been changed since the predetermined time point based on the first flow definition of the development target program.
A collision determination unit that determines whether or not the third flow definition and the second flow definition collide with each other.
When it is determined that a collision occurs, the difference between the processing nodes of the first flow definition and the second flow definition is detected, and the difference between the processing nodes of the first flow definition and the third flow definition is detected. Difference detector and
The display mode of the object indicating the processing node of the second flow definition is changed and displayed depending on whether the processing node is different or not between the first flow definition and the second flow definition. A node display processing unit that displays different display modes of objects indicating the processing nodes of the third flow definition depending on whether there is a difference between the first flow definition and the third flow definition or when there is no difference. Program development support program that makes it work.