Method, system, electronic device and medium for multi-person collaborative programming

Abstract

The application discloses a kind of multi-person collaborative programming method, system, electronic equipment and medium, the method includes: providing the canvas task designer of supporting multiple canvas visual design, each canvas corresponds a subtask;The subtask designed in single or multiple canvas is saved as independent module file, each module file can be developed by different developers;The module file developed is stored to local persistently, and module ID is created for module file;Each module file is imported into uniform project engineering, and the data reference relationship and execution logic between each module file are edited.The multi-person collaborative programming method, system, electronic equipment and medium provided by the application, by the canvas task designer, the entire project is split into multiple independent subtasks, each subtask is saved in the form of module file, and can be independently developed by different developers.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of form development, and particularly relates to a multi-person collaborative programming method and system, an electronic device and a medium. BACKGROUND

[0002] With the development of information technology and the diversification of application scenarios, low-code software and configuration software have become important tools for modern software development. These software, with their visual operation interface, modular development method and rapid deployment capability, significantly reduce the technical threshold of developers and are widely used in enterprise management, industrial control, intelligent manufacturing and other fields. However, the existing low-code software and configuration software still have some limitations and problems in actual use, especially in multi-person collaborative development and modular management.

[0003] Currently, the mainstream low-code software or configuration software on the market usually adopts the form of engineering directory tree for development management. Under this structure, an engineering generates a series of associated user files, including interface files, data files, etc., which are organized into an organic whole through the engineering directory tree. Although this way has certain convenience in single development or small-scale projects, the design and running logic of these files determines that they are highly coupled with each other and cannot be used or deleted individually. This file organization method not only limits the flexibility of the engineering, but also poses challenges to the scalability and maintainability of the project.

[0004] Therefore, in view of the above technical problems, it is necessary to provide a new solution. SUMMARY

[0005] The present application aims to provide a multi-person collaborative programming method, system, electronic device and medium, which can solve the problems of poor portability, difficulty in collaboration among multiple developers, insufficient modular support, etc.

[0006] To achieve the above-mentioned purpose, the technical solution provided by the present application is as follows:

[0007] In a first aspect, the present application provides a multi-person collaborative programming method, which comprises: providing a canvas task designer supporting multiple canvas visual design, each canvas corresponding to a subtask; saving the subtasks designed in a single or multiple canvases as independent module files, each module file being developed by different developers; persistently storing the developed module files to the local and creating a module ID for the module files; importing each module file into a unified project engineering, editing the data reference relationship and execution logic between each module file, and completing the collaborative programming of the project engineering.

[0008] In one or more embodiments, the method further comprises: creating a canvas display control for displaying attribute information of objects within the canvas, the attribute information including object name, input data name, output data name, input node, output node, whether configured, whether there is a breakpoint, whether locked, whether disabled, and node color for representing data type.

[0009] In one or more embodiments, the method further comprises: creating operator object corresponding to the subtask in the canvas, configuring each operator object based on the attribute information displayed by the canvas display control, and setting data reference relationship and logical relationship between each operator object.

[0010] In one or more embodiments, the method further comprises: recording each operator object and its attribute and operator ID, and recording the order and reference relationship between operators; persisting the operator object file and the canvas resource file to the local as a module file that can be imported into an engineering project. In one or more embodiments, importing each module file into a unified project engineering comprises: detecting whether the module ID of the imported module file conflicts with the module ID of the existing module file in the project engineering; if there is a conflict, modifying the module ID of the imported module file or replacing the existing module file that conflicts with the imported module file.

[0011] In one or more embodiments, the method further comprises: detecting whether the operator ID of the operator object in the imported module file conflicts with the operator ID of the existing operator object in the project engineering; if there is a conflict, modifying the operator ID of the operator object in the imported module file or replacing the existing operator object that conflicts with the imported operator object.

[0012] In one or more embodiments, modifying the operator ID of the operator object in the imported module file comprises: adding a prefix, suffix, serial number or character to the original operator ID.

[0013] In a second aspect, the application provides a multi-person collaborative programming system, comprising: a canvas unit, a module unit, a persistence unit and an import unit; the canvas unit is used to provide a canvas task designer supporting visual design of multiple canvases, each canvas corresponding to a subtask; the module unit is used to save the subtasks designed in a single or multiple canvases as independent module files, each module file being developed by different developers; the persistence unit is used to persistently store the developed module files to the local and create a module ID for the module file; and the import unit is used to import each module file into a unified project engineering, edit data reference relationship and execution logic between each module file, and complete collaborative programming of the project engineering.

[0014] In a third aspect, the present invention provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the multi-person collaborative programming method as described above when executing the program.

[0015] In a fourth aspect, the present invention provides a computer-readable medium carrying computer-executable instructions, which, when executed by a processor, are used to implement the multi-person collaborative programming method as described above.

[0016] Compared with the existing technology, the method, system, electronic device and medium for multi-person collaborative programming provided by the present invention split the entire project into multiple independent subtasks through a canvas task designer. The subtasks are saved in the form of module files and can be independently developed by different developers; the persistent storage of module files and the creation of module IDs ensure the independence and uniqueness of the modules, support cross-project reuse and version management, and reduce the cost of repeated design. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments described in the present invention. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0018] Figure 1 A flowchart of a method for multi-person collaborative programming according to an embodiment of the present invention;

[0019] Figure 2 This is a schematic diagram of the interface of a canvas task designer in one embodiment of the present invention;

[0020] Figure 3 This is a structural block diagram of a multi-person collaborative programming system according to an embodiment of the present invention;

[0021] Figure 4 FIG. 1 is a structural block diagram of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0023] With the diversification and complexity of software development needs, low-code development platforms have gradually become mainstream tools. However, traditional low-code platforms usually adopt the management mode of engineering directory tree. This structure has certain advantages when dealing with small projects, but its limitations gradually appear in complex projects. The high coupling between files makes it difficult to separate modules independently, poor migration makes it difficult to reuse functions, and file conflicts and version management problems in the process of multi-person collaborative development further restrict the development efficiency and quality of the project. These problems have become the key bottleneck restricting the further development of low-code platforms.

[0024] To overcome the above shortcomings, the present application provides a multi-person collaborative programming method based on modularization and collaborative optimization. The core idea of this method is to change the traditional engineering directory tree working mode through modular task splitting. The present application introduces a task designer supporting multi-canvas visual design, divides the complex project into multiple sub-tasks, and presents each sub-task in an independent canvas. This canvas-based design makes the boundaries between tasks clearer, laying the foundation for multi-person parallel development.

[0025] In addition, the present application solves the problem of module migration and reuse of traditional directory tree through modular storage and identification mechanism. Single or multiple sub-tasks can be saved as module files independently and managed through unique identifiers. This modular file form not only simplifies cross-project migration, but also provides technical support for function reuse. When implementing multi-person collaborative development, the present application ensures that the modules completed by each developer can be integrated in a unified project through module import and conflict detection mechanism, and the logical and data reference relationship between modules is accurately maintained.

[0026] Please refer to Figure 1 The flowchart of the multi-person collaborative programming method in an embodiment of the present application is shown. The multi-person collaborative programming method specifically includes the following steps:

[0027] S101: Provide a canvas task designer supporting multi-canvas visual design, each canvas corresponding to a sub-task.

[0028] It should be noted that the canvas task designer can be understood as a visual development environment that allows developers to design, manage and configure sub-tasks in an independent canvas, so that the tasks have clear logical and data boundaries. For example, the canvas task designer can be created based on the GraniStudio zero-code development platform. Figure 2 The interface diagram of the canvas task designer in an embodiment of the present application is shown.

[0029] The canvas task designer is presented in a modular manner, with each canvas designed as an independent workspace supporting operations such as dragging components, defining operators, and data flow. Developers can intuitively draw the execution logic of tasks through the canvas, for example, by connecting lines to represent data flow between tasks and by nodes to identify the input-output relationship of tasks. In addition, the canvas task designer provides rich interactive functions, including the configuration interface of task nodes, property display windows, and real-time preview functions, ensuring that developers can quickly understand and modify task logic.

[0030] The task management method of traditional low-code platforms often lacks flexibility, with all tasks concentrated in one workspace, making it difficult to intuitively express the dependency relationship between tasks. Especially when facing complex projects, the blurred boundaries between tasks are more likely to cause logic conflicts and version management difficulties. With the multi-canvas designer, each task can be isolated in an independent workspace, which not only simplifies the development process of tasks but also provides higher flexibility for task collaboration.

[0031] S102: Save the sub-tasks designed in the single or multiple canvases as independent module files, which can be developed by different developers.

[0032] The core of step S102 is to save the sub-tasks designed in the single or multiple canvases as independent module files, which can be developed by different developers. This design is to solve the problems of unclear task boundaries, high file coupling, and low efficiency of multi-person collaborative development in traditional development mode. By modularizing and giving independence to task modules, not only the development process is simplified, but also technical support is provided for multi-person parallel development.

[0033] In actual implementation, step S102 relies on a system architecture that supports modular storage. After the canvas task designer completes the design of sub-tasks, it can save the logic, configuration, and related data of the canvas as an independent module file through the built-in storage function. The module file adopts a unified standard format (such as XML, JSON, or a specific platform-defined file format), ensuring the portability and compatibility of the module in different environments.

[0034] In an exemplary embodiment, the method further includes creating a canvas display control for displaying attribute information of objects within the canvas, the attribute information including object name, input data name, output data name, input node, output node, whether configured, whether there is a breakpoint, whether locked, whether disabled, and node color representing data type.

[0035] The canvas display control is the core interactive unit in the canvas task designer, which visually displays the object's attribute information to the user. Each control represents a task object (such as a control algorithm module, a sensor data node, etc.), which can be a logic node, an operator, or a data interface. In the canvas display control, the basic attributes of the object can be displayed, including the object name, input and output data names, input and output node identifiers, and the object's state information (such as whether it has been configured, whether there is a breakpoint, whether it is locked or disabled). In addition, to enhance the understanding of data types, the canvas display control uses a color coding mechanism, with different colors representing different data types, helping developers quickly identify and ensure the legality of the connection.

[0036] The specific way to achieve this function includes: in the canvas designer, each control has a dynamically generated attribute display box, which lists the object's attribute information in a table or card form. When the developer drags the control into the canvas, the system automatically generates the attribute display box corresponding to the control and updates its content in real time. For example, the input and output node identifiers can be represented by icons or arrows, and the node color is automatically assigned according to the data type. Developers can modify the object's attribute settings by clicking the display box, or define the data flow between nodes by dragging the connection line.

[0037] In combination with the application scenario of industrial automation motion control, suppose the developer is designing a motion control program for an industrial robot joint. In the canvas task designer, the "speed control module" can be added to the canvas as an object, and its display control shows the module name, input data (target speed), output data (actual speed), input node (target speed input end), and output node (feedback speed output end). In addition, the node color can be used to distinguish different data types, such as blue for control signals and green for feedback signals. When the developer connects the module with the "acceleration planning module", the display control will update the connection status in real time and prompt whether there is a data type mismatch or a logical breakpoint.

[0038] The role of the canvas display control is to convert complex system logic into intuitive visual information. Through the clear display of object attribute information, developers can quickly understand the relationship between objects and avoid common design errors such as node connection errors or data type mismatches. At the same time, state information (such as breakpoint or lock status) provides key debugging information at runtime, helping developers identify and solve potential problems. In addition, the introduction of color coding simplifies the management of data types, significantly improving operational efficiency.

[0039] In an exemplary embodiment, the method further includes: creating operator objects corresponding to the subtasks in the canvas, configuring each operator object based on the attribute information displayed by the canvas display control, and setting data reference relationships and logical relationships between the operator objects.

[0040] An operator object can be thought of as a functional unit within a system; it may represent a compute node, logic module, or interface node. In industrial automation motion control, these operator objects can be speed control modules, path planning modules, position detection modules, and so on. The canvas display control provides a complete view of each operator object's properties, including the type and name of input and output data, node connection status, and logical configuration options. By configuring the operator object's properties, developers can define its data reference relationships (such as input data sources and output destinations) and logical relationships (such as execution order and conditional judgment).

[0041] To implement this feature, developers place operator objects onto the canvas by dragging or adding them. Once the object is created, the system automatically generates a corresponding display control and displays the operator's default property information. Developers can click the control to enter the property editing interface and modify the operator's input and output data types, logical conditions, execution priority, and other properties. Developers can also connect the output nodes of operator objects to the input nodes of other operators by dragging lines, thereby establishing data reference relationships. In addition, the system verifies the legitimacy of these connections in real time, for example, ensuring that the input and output data types are consistent and that the connection relationship does not form circular logic.

[0042] For example, in an industrial automation motion control scenario, suppose a path-following control program for a robotic arm is required. Developers can create the following operator objects on the canvas: a "path planning module," a "speed control module," and a "position feedback module." Using the displayed controls, developers can configure the "path planning module" with input path points and output target position data; connect its output to the input node of the "speed control module" to implement path-to-speed mapping; and then connect the output of the "speed control module" to the "position feedback module" for real-time position monitoring. These connecting lines visually display the logical relationship of the entire process on the canvas, allowing developers to understand and adjust the control flow at a glance.

[0043] S103: The developed module file is persistently stored locally, and a module ID is created for the module file.

[0044] A module file is a complete record of the subtask design, containing operator object attribute information, data reference relationships, logical execution order, and canvas resource configuration. Persistent storage refers to saving these module files to local storage media, such as a hard drive, cloud storage, or other storage devices that support a file system. The core purpose of persistence is to ensure that module files can be saved across sessions while maintaining their integrity and consistency in different environments. To achieve this, module files typically use structured file formats such as JSON, XML, or proprietary formats to ensure high compatibility of file content during storage, reading, and parsing.

[0045] The creation of a module ID assigns a unique identifier to each module file, used to identify the module's attributes and functions. Module IDs can be generated in a variety of ways, such as a dynamic ID based on a timestamp, a UUID (universally unique identifier), a filename hash value, or a custom naming convention. In scenarios of multi-person collaboration and cross-project development, the uniqueness of the module ID minimizes conflicts between module files, facilitating module tracking, management, and version control.

[0046] For example, in an industrial automation motion control scenario, suppose the development team designs a control system for an automated production line, which includes a "raw material conveying control module," a "processing equipment motion control module," and a "finished product inspection module." Developers complete the canvas design for each module and save these modules as independent module files. Taking the "processing equipment motion control module" as an example, the module file records the operator properties of the equipment motion control (such as speed and acceleration configuration), data reference relationships (such as the connection between position sensor feedback and control logic), and logical sequence (such as executing trajectory planning before speed control). After the design is completed, the system stores the module file in JSON format and assigns a module ID, such as "MOD-20231120-001," which indicates the module category and creation time. This module file can be imported into other projects at any time or modified and reused in subsequent projects.

[0047] For example, consider the inspection of product appearance defects on a production line. Using a modular approach, the inspection system can be broken down into multiple subtasks, each independently completed by different developers. The Canvas Task Designer provides a development environment where these subtasks can be saved as separate module files and ultimately integrated into a complete intelligent inspection system.

[0048] The goal of this intelligent inspection system is to identify surface defects in products through visual inspection and convey and sort them using motion control. Developers first used the canvas task designer to divide the task into multiple modules: a "conveyor motion control module," a "visual image acquisition module," a "image preprocessing and inspection module," and a "result classification module." Each module was designed and developed by a different developer.

[0049] The "conveyor belt motion control module" can be designed by motion control engineers, and its main task is to control the start, stop and speed adjustment of the conveyor belt to ensure that each product stays accurately in the inspection area; the "visual image acquisition module" can be developed by vision engineers, and its function is to capture images in real time through industrial cameras and pass the image data to subsequent modules; the "image preprocessing and detection module" can be completed by algorithm engineers, and mainly realizes defect detection functions through operations such as image denoising, edge detection and target classification; finally, the "result classification module" can be the responsibility of system integration engineers, who control the movement of the robotic arm according to the inspection results, send qualified products to the designated area, and remove unqualified products.

[0050] After development, each module can be persisted as a separate file (e.g., in ".mod" format) and uniquely identified by a module ID. The module file not only stores the core logic of each module but also records the data input and output relationships and call sequences between modules. This modular design not only simplifies task division but also supports cross-project module reuse.

[0051] In an exemplary embodiment, the method further includes: recording each operator object and its attributes and operator ID, and recording the sequence and reference relationship between operators; persisting the operator object file and canvas resource file locally and saving them as module files that can be imported into the engineering project.

[0052] Operator objects, their attributes, and unique identifiers (operator IDs) are recorded, along with the order and reference relationships between operators. This information is then persistently stored as a module file. This process aims to provide clear unique identifiers and data relationships for operator objects, enabling modular management in system design and providing technical support for the import, reuse, and integration of subsequent engineering projects. This design is particularly suitable for the field of industrial automation motion control, supporting the efficient development and flexible expansion of complex control systems.

[0053] In the implementation process, the properties of an operator object include its name, the types of input and output data, node connection information, logical priority, and state information (such as whether it is enabled or configured). Each operator object is assigned a unique operator ID to identify its uniqueness in the entire system. This ID generation method can use system automatic allocation (such as UUID) or user-defined method. Recording the order and reference relationship between operators ensures the accuracy of data flow and execution logic, for example, the output data of one operator needs to be used as the input data of another operator, and this reference relationship needs to be clearly marked and recorded.

[0054] In the detailed implementation, when the user completes the design and configuration of the operator object in the canvas task designer, the system extracts and saves the attribute information and logical relationship of each operator as structured data (such as JSON or XML format). At the same time, the resource information of the canvas itself (including the layout of the operators, the coordinates of the connection lines, etc.) is also stored synchronously. These data are finally packaged as module files (such as files in a specific format, for example, “.mod”) and persisted to the local storage device. The standardized storage method of such module files ensures the consistency, integrity, and portability of operator data.

[0055] S104: Import each module file into a unified project engineering, edit the data reference relationship and execution logic between each module file, and complete the collaborative programming of the project engineering.

[0056] By importing multiple independent module files into a unified project engineering and editing the data reference relationship and execution logic between the module files, the collaborative programming of the entire project engineering is completed. This process integrates scattered sub-tasks or functional modules, and constructs a complete and coordinated system through reasonable logical relationship and data flow definition.

[0057] In the implementation step S104, a system platform that supports module import and integration (such as GraniStudio zero-code development platform) can be relied on. Module files, as independently designed functional units, can contain input and output interfaces, internal logic, and state information. During the import process, the platform parses the module file, reads its data reference relationship and logic configuration, and maps it to the canvas of the project engineering. In the canvas, module files are usually displayed in the form of visual nodes, and developers can adjust the relationship between modules through dragging, connecting, and configuring. For example, the input and output relationship between modules is defined through data connection lines, or the execution priority and trigger rules of modules are set through logic conditions.

[0058] Considering the practical scenario of industrial automation motion control, let's assume the need to design a control system for an intelligent production line, involving multiple functional modules, including a "conveyor control module," a "robotic arm motion module," and a "quality inspection module." Each module has been completed in early development and saved as a separate module file. In step S104, the developer first imports these module files into a unified project. After importing, the system displays the module's properties, interfaces, and logic as nodes on the canvas. For example, the "conveyor control module" includes input interfaces (start signal, speed setpoint) and output interfaces (actual speed feedback); the "robotic arm motion module" includes a position input interface and a control output interface. Subsequently, the developer can use the canvas editing tool to connect the output speed feedback of the "conveyor control module" to the position input of the "robotic arm motion module" to achieve coordinated operation. Simultaneously, a logical relationship is set up so that the "quality inspection module" automatically starts after the robotic arm completes its operation, thereby completing product quality monitoring.

[0059] In an exemplary embodiment, each module file is imported into a unified project project, including: detecting whether there is a conflict between the module ID of the imported module file and the module ID of the existing module file in the project project; if there is a conflict, modifying the module ID of the imported module file or replacing the existing module file with the conflict with the imported module file.

[0060] The module ID is a crucial identifier for module files, uniquely identifying each module file and its corresponding functions, data interfaces, and logical configuration. In collaborative development, different developers may assign duplicate IDs to the same module file type. Alternatively, during cross-project integration, module IDs may overlap across different projects. If such conflicts go undetected and resolved, they can disrupt the logical relationships between modules in the system and even cause serious runtime errors.

[0061] When a module file is imported into a project, the system scans all existing module IDs in the project and compares them with the ID of the imported module. If a duplicate ID is detected, the system triggers a conflict resolution mechanism; at this point, the system prompts the user to choose to overwrite the existing module or create a new one.

[0062] If the user chooses to overwrite, the imported module will replace the existing module, ensuring that the latest version of the function module is used in the project. This method is suitable for situations where existing function modules need to be updated, ensuring the system is up to date and consistent.

[0063] If you choose to create a new module, the system generates a new unique ID for the imported module to avoid duplication with existing module IDs. This process is achieved by automatically adding a prefix, suffix, or sequence number, such as changing a conflicting module ID "MOD-001" to "MOD-001-A" or "MOD-001-1." This approach is suitable for reusing existing modules without overwriting their original functionality, enhancing system flexibility and module reusability.

[0064] In an exemplary embodiment, the method further includes detecting whether an operator ID of an operator object in the imported module file conflicts with an operator ID of an existing operator object in the project; if a conflict exists, modifying the operator ID of the operator object in the imported module file or replacing the conflicting existing operator object with the imported operator object. Modifying the operator ID of the operator object in the imported module file may include adding a prefix, suffix, sequence number, or character to the original operator ID, or recreating the ID.

[0065] The operator ID uniquely identifies each operator object, representing its uniqueness and logical data location within the project. The core goal of this mechanism is to maintain the independence and consistency of operator objects within the project, ensuring accurate data flow and logical relationships between operator objects. This is particularly true in the field of industrial automation and motion control, where complex task logic and data flow management place particularly stringent requirements on operator ID consistency.

[0066] When a module file is imported into a project, the system automatically scans all operator object IDs in the imported module and compares them one by one with the IDs of existing operator objects in the project. If a conflict is found, the system prompts the user to choose to overwrite the existing operator object or create a new one.

[0067] If you choose to create a new operator object, the system will generate a new unique ID for the conflicting operator object and replace the old ID. This new operator ID generation mechanism can be based on various rules, such as:

[0068] Add a prefix or suffix to the original ID, appending information such as a timestamp, module name, or auto-incremental number (e.g., changing "Node-001" to "Node-001-ModA"). Generate a new ID using a UUID (universally unique identifier) ​​or a new independent ID based on module and operator characteristics. Recursively check and update. If the newly generated ID still has the possibility of conflicting with an existing ID, the system will continue to generate new IDs until uniqueness is guaranteed.

[0069] In summary, the method of multi-person collaborative programming provided by the present invention divides the entire project into multiple independent subtasks through the canvas task designer. The subtasks are saved in the form of module files and can be independently developed by different developers; the persistent storage of module files and the creation of module IDs ensure the independence and uniqueness of the modules, support cross-project reuse and version management, and reduce the cost of repeated design.

[0070] Please refer to Figure 3 As shown, based on the same inventive concept as the aforementioned multi-person collaborative programming method, the present invention provides a multi-person collaborative programming system 300, which includes: a canvas unit 301, a module unit 302, a persistence unit 303 and an import unit 304.

[0071] The canvas unit 301 is used to provide a canvas task designer that supports visual design of multiple canvases, each canvas corresponding to a subtask. The module unit 302 is used to save the subtasks designed in a single or multiple canvases as independent module files, and each module file can be developed by different developers. The persistence unit 303 is used to store the developed module files persistently locally and create a module ID for the module file. The import unit 304 is used to import each module file into a unified project project, edit the data reference relationship and execution logic between each module file, and complete the collaborative programming of the project project.

[0072] Please refer to Figure 4 As shown, an embodiment of the present invention further provides an electronic device 400, which includes at least one processor 401, a memory 402 (e.g., a non-volatile memory), a storage 403, and a communication interface 404, and the at least one processor 401, the storage 402, the storage 403, and the communication interface 404 are connected together via a bus 405. The at least one processor 401 is used to call at least one program instruction stored or encoded in the storage 402, so that the at least one processor 401 performs various operations and functions of the multi-person collaborative programming method described in various embodiments of this specification.

[0073] In the embodiments of the present specification, the electronic device 400 may include but is not limited to: a personal computer, a server computer, a workstation, a desktop computer, a laptop computer, a notebook computer, a mobile electronic device, a smart phone, a tablet computer, a cellular phone, a personal digital assistant (PDA), a handheld device, a messaging device, a wearable electronic device, a consumer electronic device, and the like.

[0074] An embodiment of the present invention also provides a computer-readable medium carrying computer-executable instructions. When the computer-executable instructions are executed by a processor, they can be used to implement various operations and functions of the multi-person collaborative programming method described in various embodiments of this specification.

[0075] The computer-readable medium in the present invention can be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device.

[0076] In the present invention, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination thereof.

[0077] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0078] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatuses, systems, and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0079] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above and that the invention can be embodied in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments should be considered in all respects as illustrative and non-restrictive, and the scope of the invention is defined by the appended claims, not the foregoing description, and all variations within the meaning and range of equivalents of the claims are intended to be included therein. Any reference sign in a claim should not be construed as limiting the claim to which it relates.

[0080] In addition, it should be understood that although this specification is described in terms of implementation methods, not every implementation method contains only one independent technical solution. This narrative method of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other implementation methods that can be understood by those skilled in the art.

Claims

1. A multi-person collaborative programming method, characterized in that: include: Provides a canvas task designer that supports visual design of multiple canvases, each canvas corresponding to a subtask; The canvas task designer includes a canvas display control, which is used to display attribute information of operator objects in the canvas; Save the subtasks designed in a single or multiple canvases as independent module files, each of which can be developed by different developers; Create operator objects corresponding to subtasks in the canvas, configure each operator object based on the attribute information displayed by the canvas display control, and set data reference relationships and logical relationships between the operator objects; the data reference relationship includes the input data source and output data target of the operator object, and the logical relationship includes the execution order and conditional judgment of the operator object; Record each operator object and its attributes and operator ID, as well as the sequence and reference relationship between operator objects, to form the operator object file and canvas resource file of the module file; The developed module file is persistently stored locally in a structured file format, and a module ID is created for the module file. The operator object file is a structured data file containing the attribute information and logical relationships of the operator object, and the canvas resource file includes the layout of the operator object and the coordinates of the connecting lines. Each module file stores the core logic of its corresponding functional module, as well as the data input and output relationships and calling sequence between the functional modules corresponding to each module file. Import each module file into a unified project. During the import process, the module file is parsed, the data reference relationship and logical configuration in the module file are read, and then mapped to the project canvas in the form of visual nodes and connecting lines; Edit the data reference relationship and execution logic between each module file in the canvas to complete the collaborative programming of the project.

2. The multi-person collaborative programming method according to claim 1, characterized in that: The attribute information includes object name, input data name, output data name, input node, output node, whether configured, whether breakpoint exists, whether locked, whether disabled, and node color used to characterize data type.

3. The multi-person collaborative programming method according to claim 1, characterized in that: Import each module file into a unified project, including: Check whether the module ID of the imported module file conflicts with the module file already in the project; If there is a conflict, the module ID of the imported module file is modified or the existing module file with the conflict is replaced with the imported module file.

4. The multi-person collaborative programming method according to claim 1, characterized in that: The method further comprises: Check whether the operator ID of the operator object in the imported module file conflicts with the operator ID of the operator object already in the project; If there is a conflict, modify the operator ID of the operator object in the imported module file or replace the existing conflicting operator object with the imported operator object.

5. The multi-person collaborative programming method according to claim 4, characterized in that: Modify the operator ID of the operator object in the imported module file, including: Add a prefix, suffix, sequence number, or character to the original operator ID, or rebuild the ID.

6. A multi-person collaborative programming system, characterized in that: include: Canvas unit, used to provide a canvas task designer that supports visual design of multiple canvases, each canvas corresponding to a subtask; The canvas task designer includes a canvas display control, which is used to display attribute information of operator objects in the canvas; Module unit, used to save subtasks designed in a single or multiple canvases as independent module files. Each module file can be developed by different developers. Create operator objects corresponding to the subtasks in the canvas, configure each operator object based on the attribute information displayed by the canvas display control, and set data reference relationships and logical relationships between the operator objects; the data reference relationship includes the input data source and output data target of the operator object, and the logical relationship includes the execution order and conditional judgment of the operator object; The persistence unit records each operator object, its attributes, and the operator ID, as well as the sequence and reference relationship between operator objects, forming the operator object file and canvas resource file of the module file; The developed module file is persistently stored locally in a structured file format, and a module ID is created for the module file. The operator object file is a structured data file containing the attribute information and logical relationships of the operator object, and the canvas resource file includes the layout of the operator object and the coordinates of the connecting lines. Each module file stores the core logic of its corresponding functional module, as well as the data input and output relationships and calling sequence between the functional modules corresponding to each module file. The import unit is used to import various module files into a unified project. During the import process, the module files are parsed, the data reference relationships and logical configurations in the module files are read, and they are mapped to the project canvas in the form of visual nodes and connecting lines. And edit the data reference relationship and execution logic between each module file in the canvas to complete the collaborative programming of the project.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the multi-person collaborative programming method according to any one of claims 1 to 5 is implemented.

8. A computer-readable medium, characterized in that The computer-readable medium carries computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the multi-person collaborative programming method according to any one of claims 1 to 5.

Images