WO2019026248A1 - Program development assistance device, program development assistance method, and program development assistance program - Google Patents

Abstract

Provided is a visual program device comprising: a local repository 58 for storing a third flow definition constituting a first flow definition as the basis whereon a change was made; a VCS association unit 55 for acquiring the first flow definition and a second flow definition constituting the first flow definition whereto a change is reflected, assessing whether the third flow definition and second flow definition conflict, and if so, detecting process node differences between the first flow definition and second flow definition while also detecting process node differences between the first flow definition and third flow definition; and a flow editing unit 54 for changing the display mode of an object of the second flow definition processing node and displaying same depending on the presence or absence of the process node differences between the first flow definition and second flow definition while also changing the display mode of an object of the third flow definition processing node and displaying same depending on the presence or absence of the process node differences between the first flow definition and third flow definition.

Description

Program development support apparatus, program development support method, and program development support program

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

In software development, visual programming is known in which program development is performed using visual objects. In visual programming, each node that is a collection of processing is expressed as a block (object), and operations such as connecting these blocks are performed to flow the program (nodes included in the program, connections between nodes, etc.) Can create According to this visual programming, it is possible to visually understand the flow of a program, and it is possible for a user who does not have knowledge of the programming language to easily develop the program.

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

Also, in software development, teams of multiple developers sometimes jointly develop the same program, but in this case, a version control system may be used to maintain program integrity. is there. Some version management systems provide not only version management of source code and the like, but also a change proposal function, a support function for efficiently performing development in a team, such as difference confirmation between versions, and the like. When promoting software development using such a function of a version control system, developers define a development procedure within a team and proceed with development accordingly.

The version control system manages text information and files. Therefore, it is also possible to manage the flow definition file output by the development support apparatus. However, the function of the difference display used when confirming the changed portion is for text, and it is difficult to grasp the correspondence with the visual expression on the development support device.

Also, in order to use a version control system, it is necessary to have knowledge of a CLI (Command Line Interface) command and a development procedure using the version control system. In particular, in a development support device capable of executing visual programming, it is difficult to efficiently use a version control system since a user who does not have specialized knowledge of software development is the main target of use. It is.

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

JP, 2015-162218, A JP, 2016-177668, A

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

If a collision occurs in this way, it is necessary to correct the flow definition. In this case, for example, it is conceivable to display the difference between one flow definition and another flow definition to correct the flow definition.

However, a situation may occur where it can not be understood how to modify the flow definition only by checking the difference between one flow definition and the other flow definition. For example, in the case where two flow definitions respectively modify the common ancestor flow definition, how to correct it if not considering the difference with the ancestor flow definition I can not grasp what is

The present invention has been made in view of the above circumstances, and an object thereof 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, a program development support apparatus according to one aspect according to a user's operation on an object indicating a processing node, a flow definition including a connection relationship between one or more processing nodes constituting the development target program and the processing node In the program development support apparatus to be created, a first flow definition acquisition unit that acquires a first flow definition that is a flow definition at a predetermined time of the development target program, and a predetermined time after the first flow definition of the development target program Storing a second flow definition acquisition unit for acquiring a second flow definition in which the change of the change is reflected, and storing a third flow definition changed after a predetermined time based on the first flow definition of the development target program Collision determination unit that determines whether the third flow definition storage unit, the third flow definition, and the second flow definition collide with each other A difference detection unit that detects a difference between processing nodes of the first flow definition and the second flow definition and detects a difference between processing nodes of the first flow definition and the third flow definition when it is determined that a collision occurs. The display mode of the object indicating the processing node of the second flow definition is changed and displayed depending on whether there is a difference between the processing nodes of the first flow definition and the second flow definition and the case where there is no difference. And a node display processing unit that changes and displays the display mode of the object indicating the processing node of the third flow definition depending on whether there is a difference between the flow definition and the third flow definition.

According to the present invention, it is possible to appropriately display information required to edit a flow definition in which there are multiple versions.

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

Embodiments will be described with reference to the drawings. The embodiments described below do not limit the invention according to the claims, and all of the elements described in the embodiments and their combinations are essential to the solution means of the invention. There is no limit.

In the following description, information may be described by the expression “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 indicate that the information does not depend on the data structure.

(System overall configuration)
FIG. 1 is an overall configuration diagram of a program development and 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 management system (VCS system) 61 as an example of a version management system. One version control system 61 can manage versions of programs (flow definitions) in a plurality of visual program devices 51.

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

The visual program device 51 and the VCS system 61 are connected via the communication network 20. The communication network 20 may be a wired Local Area Network (LAN), a wireless LAN, a Wide Area Network (WAN), 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 a development target program. The repository 62 can hold a branch 63 which can separate and manage different flow definitions of different concurrently developed versions of a predetermined development target program. The branch 63 manages the flow definition 64. If there is a change in the flow definition 64, 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 parts) constituting a program, for example, identification information of a node, a connection relationship between a node and another node, etc. It contains the information shown.

The branch 63 includes, for example, a branch (main branch) for managing a 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. There is a branch (development branch) that manages the flow definition that is created and edited. The development branch is created, for example, for each developer (user) who jointly edits the same development target program.

The visual program device 51 includes an input / output unit 52, a flow execution unit 53, a flow editing unit 54, and a version management 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. Also, 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 receiving unit.

The input / output unit 52 receives, for example, an input from 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 cooperates with the VCS system 61 to manage the flow definition.

The VCS cooperation 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 certain point in time. Therefore, at the beginning 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 update of the main branch or the like occurs in the VCS system 61, the main branch of the local repository 58 may be in a state different from the main branch of the VCS system 61. The local repository 58 comprises one or more branches 59. The branch 59 manages the flow definition 60. The branch 59 is created based on the main branch of the repository 62 (and the flow definition therein (first flow definition) at that time, when the user of the visual program device 51 starts editing the development target program. There is a development branch, and the user of the visual program device 51 changes the flow definition in this development branch, etc. 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 on change collision in the flow definition.

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

The visual program device 51 includes, for example, a single 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. And an apparatus 26. The respective 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 programs (program development support programs) for configuring the respective functional units of the visual program device 51. The CPU 21 executes various programs by executing programs stored in the memory 22. The storage device 23 is, for example, a non-volatile storage device such as a hard disk or a solid state drive (SSD), and stores various types of information including a program. The input device 24 is, for example, a keyboard or a mouse, and receives an 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 in FIG. 1 is configured by the input device 24 and the output device 25. The flow execution unit 53 and the flow editing unit 54 are configured by the CPU 21 executing a program in the memory 22. The processing executed by the VCS cooperation unit 55 is configured by the CPU 21 executing a 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 processing executed by the processor. The function of storing the repository management table 56, the change conflict 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 a repository management table according to an embodiment.

The repository management table 56 is a table holding information indicating the correspondence between the repository 62 of the VCS system 61 and the local repository 58, and an entry (record) corresponding to each pair of the corresponding repository 62 and the local repository 58 Store The entries of 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 location information (for example, a URL or the like) of the repository 62 held by the VCS system 61. The main branch field 562 is an area for storing identification information (for example, a branch name) of the branch 63 (main branch) as a base of development designated by the user 50. The local repository field 563 is an area for storing location information of the local repository 58 corresponding to the repository 62 corresponding to the entry (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, a name of a development branch) of a branch (development branch) under development 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 when the main branch and the development branch are branched (at the time when the development branch is created). It is. By using this commit ID, information (for example, flow definition) of the main branch at the time of branching can be acquired from the repository 62.

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

The change collision management table 57 is a table for holding information on 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 term "collision" means that each node in the flow definition of two branches can not be properly merged.

The entry of the change collision management table 57 includes a node ID field 571, a branch time 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 or the like determined by the visual program device 51 for each node) uniquely indicating a node in which a change collision has occurred. The branch time node definition field 572 is an area for storing information (for example, a node definition of JSON format) at the time when the main branch and the development branch branch about the node in which the change conflict occurs. . The main branch node definition field 573 is an area for storing information of the node in the main branch (for example, a node definition in JSON format) about the node in which the change conflict occurs. The development branch node definition field 574 is an area for storing information (for example, a node definition in JSON format) of a node in a development branch regarding a node in which a change conflict occurs.

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

FIG. 5 is a flowchart of a program development process according to an 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, and the user 50 may issue an operation instruction to the visual program device 51 to create the repository 62 in the VCS system 61 via the visual program device 51.

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

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

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

When the visual program device 51 receives an instruction to end editing from the user 50, the visual program device 51 executes a flow definition storage process shown in FIG. 7 for storing the flow definition in the VCS service 61 (step S45).

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

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

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

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

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

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 display flow Is displayed (step S436).

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

When the visual program device 51 receives a request from the user 50 to commit the flow definition to the development branch (step S 451), the VCS cooperation unit 55 refers to the repository management table 56 and 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 is updated after the development branch 59 is created (step S452).

As a result, when there is no update in the main branch 63 (step S452: No), the VCS cooperation unit 55 prevents the change collision between the development branch and the main branch and causes the development branch to be the main branch. Since this means that there is no problem in merging, the process proceeds to step S461.

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

Next, the VCS cooperation unit 55 executes rebase processing for connecting the development branch to the updated main branch (step S454). For the function of the rebase process, for example, the function of a VCS system such as git may be incorporated in the VCS cooperation unit 55. In the rebase process, for the flow definition of the development branch (the third flow definition) and the flow definition of the main branch (the second flow definition), change conflict (the flow definition node of the development branch in the flow definition of the main branch) When there is a part that can not be connected, information on the generated collision (changed collision information) is additionally recorded in the file of the flow definition 60 and saved. The changed collision information may be identification information of a node in which the collision has occurred, or information indicating that a collision has occurred.

Next, the VCS cooperation unit 55 determines whether or not there is a conflict in the change of the flow definition between the development branch and the main branch. Specifically, the file of the flow definition of the development branch includes the change collision information It is judged whether or not it is determined (step S455). As a result, if no change conflict occurs (step S455: No), this means that there is no problem in merging the development branch with the main branch, so the VCS cooperation unit 55 steps the processing. Proceed to S461.

On the other hand, if a change collision has occurred (step S455: Yes), that is, if the flow definition includes change collision information, the VCS cooperation unit 55 changes collision based on the change collision information. Identify all nodes where is occurring. Next, the VCS cooperation unit 55 refers to the repository management table 56 for each of the identified nodes, and the node definition in the flow definition (first flow definition) of the main branch at the time of branching and the flow definition of the latest main branch The node definition in (the second flow definition) and the node definition in the flow definition (the 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 has the node in which the collision has occurred. The identification information is stored, and the corresponding node definition already acquired is stored 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 editing unit 54 reads the flow definition including the change collision information and the change collision management table 57, and displays a flow for displaying the flow display screen 30 (see FIG. 9) including the information on the change collision of the node. A process (see FIG. 8) is performed (step S457).

Thereby, the user 50 can edit the flow definition for solving 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 editing content in the flow definition based on an operation on the input / output unit 52 by the user 50 (step S458).

Next, upon receiving a request from the user 50 to commit the flow definition in which the conflict has been resolved to the development branch, the VCS cooperation unit 55 executes processing for committing the flow definition in which the conflict has been eliminated to the development branch of the local repository 58 ( Step S459). As a result, when the commit of the flow definition to the development branch is successful, the VCS cooperation unit 55 deletes the entry corresponding to the node from which the collision has been eliminated from the change collision management table 57 (step S460). Are PUSHed to the VCS system 61, that is, the development branch is registered in 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 cooperation 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 process)
FIG. 8 is a flowchart of flow display processing according to an embodiment. The flow display process is a process corresponding to step S457 in FIG.

First, the flow editing unit 54 reads a flow definition including 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 editing unit 54 determines whether a node corresponding to the acquired node definition is registered in the change conflict 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 the flow editor 54 corresponds to this node. The block (object) to be selected is drawn in a display mode (for example, black) indicating that a change collision has not 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 editing unit 54 acquires the node definition at the time of branching corresponding to this node from the change collision management table 57, and the block corresponding to the node (first processing node) at the time of branching is the node related to the collision. It draws in the predetermined display mode (for example, gray) which shows that there exists (step S504).

Next, the node editing unit 54 acquires the node definition of the main branch of this node from the change collision management table 57, and determines whether 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 main branch node definition and the branch node definition (step S505: No), the node editing unit 54 branches the block corresponding to the main branch node. The drawing is performed in the same color (gray in this embodiment) as the block corresponding to the hour node (step S511), and the process proceeds to step S507.

On the other hand, when it is determined that there is a difference between the main branch node definition and the branch node definition (step S505: Yes), the node editing unit 54 branches the block corresponding to the main branch node. The drawing is performed in a display mode (for example, blue) different from the block corresponding to the node (step S506), and the process proceeds to step S507. When the main branch node is deleted in step S506, the node editing unit 54 can visually recognize that the node is deleted from the block corresponding to the main branch node. Draw in (for example, blue and dotted line). When displaying the block in this manner, it is visually checked whether there is a difference between these nodes by comparing the display mode of the block corresponding to the main branch node with the block corresponding to the node at the time of branch. Can be easily and properly grasped.

In step S507, the node editing unit 54 acquires the node definition in the development branch of this node from the change collision management table 57, and determines whether 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 editing unit 54 branches the block corresponding to the node of the development branch. The drawing is performed in the same color (gray in this embodiment) as the block corresponding to the hour node (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 editing unit 54 executes the main branch for the block corresponding to the node of the development branch. The drawing is performed in a display mode (for example, red) different from the block corresponding to the node and the block corresponding to the branch node (step S508), and the process proceeds to step S509. When the node of the development branch is deleted in step S508, the node editing unit 54 can visually recognize that the node is deleted in the block corresponding to the node of the development branch. Draw in (for example, red and dotted line). By displaying the blocks in this way, it is visually easy to see if there is a difference between the nodes corresponding to the nodes of the development branch and the display aspects of the blocks corresponding to the nodes at the time of branching. And you can grasp it properly. In addition, visually compare easily and appropriately whether or not there is a difference between the nodes corresponding to the nodes of the development branch and the blocks corresponding to the nodes of the main branch by visually comparing the display modes Can. When the next node is specified in the node definition for this node, the link line connecting from the block of each node to the block of the next node is drawn according to the color of the block of each node You may

In step S 509, the node editing unit 54 determines whether or not drawing of the block corresponding to the node is completed with all nodes included in the flow definition as the processing target, and sets all blocks as the processing target. If drawing has not been completed (step S509: No), the process proceeds to step S502, while if drawing of blocks having all nodes processed has been completed (step S509: Yes), 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 a block (object) 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, thereby selecting the block of the node selected in the flow editing area 32. It becomes possible to arrange and so on.

The flow editing area 32 is an area for displaying a flow according to the flow definition. The flows displayed in the flow editing area 32 include blocks (such as 321 to 325) corresponding to the nodes included in the flow definition, connection lines indicating connection relationships among the nodes, and the like. The user 50 operates the input / output unit 52 to edit the flow definition (that is, the program) by editing the arrangement of nodes in the flow definition, the connection relation of the nodes, and the like in the flow editing area 32. it can.

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

In the flow editing area 32, nodes that were not present or deleted are displayed in a display mode (for example, dotted line) different from the blocks of other nodes so that that can be visually grasped. The newly added node may be displayed in a display mode different from the other so that the newly added node can be grasped. Further, in the flow editing area 32, the contents of the node definition or the difference between the node definition of another node and the node definition may be displayed corresponding to the block corresponding to the node. Specifically, the contents of the node definition and the difference between the node definition and other node definitions may be displayed in the vicinity of the block, and when the block is selected, the node definition or the other node The content of the difference from the node definition may be displayed in the node information display area 33. Thereby, the contents of the node definition and 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 regarding 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 designate an operation related to management by performing an operation on the node operation area 34 by the input / output unit 52. In the flow operation area 34, for example, reading of the flow definition, saving of the flow definition (commit), execution of the flow definition, and the like can be selected as an operation related to management of the flow definition.

The present invention is not limited to the embodiments described above, 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, starting from committing the flow definition to the development branch, the main branch is acquired when the main branch of the VCS system 61 is updated, and the flow display processing is performed. However, the present invention is not limited to this. For example, the VCS cooperation unit 55 sequentially monitors whether or not the main branch in the repository 62 of the VCS system 61 is updated, and the main branch is updated. If it has been detected, the main branch may be acquired and flow display processing may be performed. In this way, change collisions that occur as a result of the main branch being updated can be grasped at an early stage, that is, at a point where there are relatively few parts involved in change collisions, and it is relatively easy to resolve change collisions. be able to. For this reason, the load at the time of eliminating the change collision to the user 50 can be reduced, and the development efficiency of the program can be improved.

Further, in the above embodiment, when there is a change conflict between the development branch and the main branch, the flow display screen 30 displays three blocks corresponding to the branch node, the main node, and the development node. However, the present invention is not limited to this, and two blocks of a block corresponding to the main node and a block corresponding to the development node may be displayed. Also in this case, it is possible to visually grasp whether the main node has a difference with the branch node and whether the development node has a difference with the branch node.

In the above embodiment, when there is a difference between nodes, the color or line type of the block corresponding to the node is changed, but the present invention is not limited to this, for example, to change the shape of the block The point is to change the visually recognizable display mode.

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

1 program development management system 20 communication network 21 CPU 22 memory 23 storage device 51 visual program device 52 input / output unit 53 flow execution unit 54 flow editing unit 55 ... VCS cooperation unit, 56 ... repository management table. 57: Change collision management table, 61: VCS system

Claims (15)

A program development support apparatus that creates a flow definition including connection relationships between one or more processing nodes that constitute a development target program and the processing nodes according to an operation of a user indicating the processing node.
A first flow definition acquisition unit that acquires a first flow definition that is a flow definition at a predetermined time of the development target program;
A second flow definition acquisition unit that acquires a second flow definition in which a change after the predetermined time is reflected on 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 after the predetermined time based on the first flow definition of the development target program;
A collision determination unit that determines whether the third flow definition and the second flow definition collide with each other;
When it is determined that there is a collision, 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. A difference detection unit,
The display mode of the object indicating the processing node of the second flow definition is changed and displayed depending on whether there is a difference between the processing nodes of the first flow definition and the second flow definition and the case where there is no difference. A node display processing unit that changes and displays the display mode of the object indicating the processing node of the third flow definition between the case where there is a difference between the first flow definition and the third flow definition and the case where there is no difference;
Program development support apparatus comprising: The node display processing unit displays an object indicating a 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 object of the node is displayed in the same display manner as the object indicating the first processing node, and indicates the processing node of the second flow definition having a difference between the first flow definition and the second flow definition. 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 having no difference between the first flow definition and the third flow definition, The first flow definition and the third are displayed in the same display manner as the object indicating the first processing node. Wherein a difference between the low definition for the third object indicating flow definition of processing nodes, the program development support apparatus according to claim 1 to be displayed in a display mode different from the object representing the first processing node. The node display processing unit makes the display mode of the object indicating the processing node 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. Or the program development assistance apparatus of Claim 2. It is connected to a version management system that manages the version of the flow definition via a communication network,
The first flow definition acquisition unit acquires the first flow definition from the version management system,
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 is updated, the version after the version management system is updated Get the second flow definition,
When the collision determination unit, the difference detection unit, and the node display processing unit acquire the second flow definition after the second flow definition acquisition unit acquires the updated second flow definition. The program development support device according to claim 4, which executes processing using the program. The system further includes a change receiving unit that receives a change to the third flow definition,
The collision determination unit determines whether 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 in which the change is reflected does not collide with the second flow definition, the version management system is transmitted to merge the third flow definition with the second flow definition. The program development support device according to claim 1, further comprising: a transmitting unit. The node display processing unit can display the difference between the node definition of the processing node in the second flow definition or the first flow definition in association with the object indicating the processing node of the second flow definition. The program according to claim 1, wherein the difference between the node definition of the processing node in the third flow definition or the third flow definition can be displayed in correspondence with an object indicating the processing node of the third flow definition. Development support device. A program development support method by a program development support apparatus, which creates a flow definition including a connection relationship between one or more processing nodes constituting a development target program and the processing nodes according to a user's operation on an object indicating the processing node,
(A) acquiring a first flow definition which is a flow definition at a predetermined time of the development target program;
(B) acquiring a second flow definition in which a change from the predetermined time point on the first flow definition of the development target program is reflected,
(C) storing, in the storage unit, a third flow definition that has been changed after the predetermined time based on the first flow definition of the development target program;
(D) determining whether the third flow definition and the second flow definition collide with each other;
(E) When it is determined that there is a collision, 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 To detect
(F) The display mode of the object indicating the processing node of the second flow definition is changed and displayed depending on whether there is a difference between the processing nodes of the first flow definition and the second flow definition or not. And a program development support method for changing and displaying the display mode of the object indicating the processing node of the third flow definition between the case where there is a difference and the case where there is no difference between the first flow definition and the third flow definition . In (f), an object indicating a first processing node included in the first flow definition is displayed, and a processing node of the second flow definition having no difference between the first flow definition and the second flow definition Object of the second flow definition in which the first flow definition and the second flow definition are different from each other while being displayed in the same display manner as the object indicating the first processing node 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 having no difference between the first flow definition and the third flow definition is While displaying the first processing node in the same display manner as the object indicating the first processing node, the first flow definition and the third flow Wherein for the third object indicating flow definition of processing nodes, the program development support method according to claim 8 to be displayed in a display mode different from the object representing the first processing node with differences defined. The display mode of the object indicating the processing node is made 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 in (f). The program development support method according to claim 9. The program development support device is connected to a version management system that manages a version of the flow definition via a communication network,
In the (a), the first flow definition is acquired from the version management system,
The program development support method according to claim 8, wherein in (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 being updated from the version management system Get the definition,
The program development support method according to claim 11, wherein in (d), (e) and (f), processing is performed using the updated second flow definition. (G) accept changes to the third flow definition;
In (d), it is determined whether the third flow definition reflecting the change accepted in (g) collides with the second flow definition.
(H) causing the version management system to merge the third flow definition with the second flow definition when it is determined that the third flow definition reflecting the change does not conflict with the second flow definition 9. The program development support method according to claim 8, wherein the program development support method is transmitted. In (f), the difference between the node definition of the processing node in the second flow definition or the first flow definition can be displayed in correspondence with the object indicating the processing node of the second flow definition. The program development according to claim 8, wherein the difference between the third flow definition and the node definition of the processing node in the third flow definition can be displayed in correspondence with an object indicating the processing node of the third flow definition. Support method. For making a computer constituting a program development support device to create a flow definition including a connection relationship between one or more processing nodes constituting the development target program and the processing nodes according to the user's operation on the object indicating the processing nodes Program development support program, and
The computer,
A first flow definition acquisition unit that acquires a first flow definition that is a flow definition at a predetermined time of the development target program;
A second flow definition acquisition unit that acquires a second flow definition in which a change after the predetermined time is reflected on 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 after the predetermined time based on the first flow definition of the development target program;
A collision determination unit that determines whether the third flow definition and the second flow definition collide with each other;
When it is determined that there is a collision, 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. A difference detection unit,
The display mode of the object indicating the processing node of the second flow definition is changed and displayed depending on whether there is a difference between the processing nodes of the first flow definition and the second flow definition and the case where there is no difference. A node display processing unit that changes and displays the display mode of the object indicating the processing node of the third flow definition between the case where there is a difference between the first flow definition and the third flow definition and the case where there is no difference; Program development support program to function.

Images