CN113608727A - Code processing method, device and system for visual programming - Google Patents

Code processing method, device and system for visual programming Download PDF

Info

Publication number
CN113608727A
CN113608727A CN202110890840.XA CN202110890840A CN113608727A CN 113608727 A CN113608727 A CN 113608727A CN 202110890840 A CN202110890840 A CN 202110890840A CN 113608727 A CN113608727 A CN 113608727A
Authority
CN
China
Prior art keywords
data
view
code
layer
pin
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110890840.XA
Other languages
Chinese (zh)
Other versions
CN113608727B (en
Inventor
孟玉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Netease Hangzhou Network Co Ltd
Original Assignee
Netease Hangzhou Network Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Netease Hangzhou Network Co Ltd filed Critical Netease Hangzhou Network Co Ltd
Priority to CN202110890840.XA priority Critical patent/CN113608727B/en
Publication of CN113608727A publication Critical patent/CN113608727A/en
Application granted granted Critical
Publication of CN113608727B publication Critical patent/CN113608727B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/31Programming languages or programming paradigms
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/34Graphical or visual programming
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The application provides a code processing method, a device and a system of visual programming, wherein in the method, execution flow data of a view is acquired from an engine layer, and the execution flow data comprises the following steps: the method comprises the steps of obtaining subcode data by disassembling a code view and functional data corresponding to the code view, drawing the code view, carrying out data structure disassembly on the code view to obtain subcode data, storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain data after unloading, and finally converting the data after unloading into hard disk data according to a preset format to be stored in a storage layer. According to the technical scheme, after the data of the engine layer is disassembled, the disassembled data are stored according to the user-defined data structure, so that the blueprint codes are extracted, and a plaintext data basis is provided for other development processes.

Description

Code processing method, device and system for visual programming
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, and a system for processing a code of a visual programming.
Background
The visual programming (blueprint) has the characteristics of quick operation, low learning threshold, visual graph and the like, is widely applied to the non-programming professional programming and development fields, has high use value for technical personnel in the fields, and can reduce communication and labor cost and shorten the design and development period.
When a technician develops a host job using an engine (e.g., a ghost engine), the related functions of the blueprint are often used, i.e., the blueprint can be opened in the ghost engine.
In practical application, since the blueprint can only be opened by the ghost engine, the blueprint cannot be automatically analyzed by the ghost engine, and further cannot provide use value for other development processes, so that various development requirements cannot be met.
Disclosure of Invention
The embodiment of the application provides a code processing method, device and system for visual programming, and aims to solve the problems that visual codes can only be opened through an adaptation engine and cannot be automatically analyzed by the engine, so that the use value cannot be provided for other development processes, various development requirements cannot be met, and the like.
In a first aspect, an embodiment of the present application provides a visualized programming code processing method, which is applied to a computer device, and the method includes:
obtaining execution flow data for a view from an engine layer, the execution flow data comprising: the method comprises the steps of code view and drawing function data corresponding to the code view;
performing data structure disassembly on the code view to obtain sub-code data, wherein the sub-code data comprises: information of at least one node, an identification of the view, and an identification of other views associated with the view;
storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain data after unloading;
and converting the data after the unloading into hard disk data according to a preset format and storing the hard disk data in a storage layer.
In a possible design of the first aspect, the information of each node includes: at least one pin information, an identification of the node, and an identification of other nodes associated with the node, each pin information comprising: an identification of at least one pin and an identification of other pins associated with the at least one pin.
In another possible design of the first aspect, the preset data structure includes: an execution flow data table, the execution flow data table comprising: a data area of the view and a data area of a function associated with the view, the data area of the view including: at least one nodal region, said nodal region comprising: at least one pin area, the functional data area associated with the view including pin information for at least one pin.
In yet another possible design of the first aspect, the obtaining execution flow data of the view from the engine layer includes:
and acquiring execution flow data of the view from resource data corresponding to the view of the engine layer.
In this possible design, the obtaining execution flow data of the view from the resource data corresponding to the view of the engine layer includes:
acquiring first resource data corresponding to a new version view and second resource data corresponding to an old version view which are stored by adopting a tree structure from the engine layer, wherein the code view comprises the first resource data and the second resource data;
acquiring different parts of the first resource data and the second resource data as the function data.
In yet another possible design of the first aspect, the storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain data after being transferred includes:
establishing a data object with a structure of the preset data structure in the memory layer;
assigning and overloading the subcode data and the functional data to obtain extracted execution stream data;
and copying the extracted execution stream data into the data target according to the data structure to obtain the data after the unloading.
In yet another possible design of the first aspect, the preset format includes: and in the JSON format, converting the transferred and stored data into hard disk data according to a preset format, and storing the hard disk data in a storage layer, including:
converting the data after being transferred and stored into the hard disk data in a JSON format by adopting a serialization method;
and storing the hard disk data in the JSON format to the storage layer.
In a second aspect, an embodiment of the present application provides a visually programmed code processing apparatus, which is applied to a computer device, and the apparatus includes: the device comprises an acquisition module, a processing module and a storage module;
the obtaining module is configured to obtain execution stream data of the view from an engine layer, where the execution stream data includes: the method comprises the steps of code view and drawing function data corresponding to the code view;
the processing module is configured to perform data structure disassembly on the code view to obtain sub-code data, where the sub-code data includes: information of at least one node, an identification of the view, and an identification of other views associated with the view;
and the storage module is used for storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain data after unloading, and converting the data after unloading into hard disk data according to a preset format to be stored to a storage layer.
In one possible design of the second aspect, the information of each node includes: at least one pin information, an identification of the node, and an identification of other nodes associated with the node, each pin information comprising: an identification of at least one pin and an identification of other pins associated with the at least one pin.
In another possible design of the second aspect, the preset data structure includes: an execution flow data table, the execution flow data table comprising: a data area of the view and a functional data area associated with the view, the data area of the view comprising: at least one nodal region, said nodal region comprising: at least one pin area, the functional data area associated with the view including pin information for at least one pin.
In yet another possible design of the second aspect, the obtaining module is specifically configured to:
and acquiring execution flow data of the view from resource data corresponding to the view of the engine layer.
In this possible design, the obtaining module is specifically configured to:
acquiring first resource data corresponding to a new version view and second resource data corresponding to an old version view which are stored by adopting a tree structure from the engine layer, wherein the code view comprises the first resource data and the second resource data;
acquiring different parts of the first resource data and the second resource data as the function data.
In yet another possible design of the second aspect, the storage module stores the subcode data and the functional data to a memory layer according to a preset data structure to obtain data after being transferred, and is specifically configured to:
establishing a data object with a structure of the preset data structure in the memory layer;
assigning and overloading the subcode data and the functional data to obtain extracted execution stream data;
and copying the extracted execution stream data into the data target according to the data structure to obtain the data after the unloading.
In yet another possible design of the second aspect, the preset format includes: and in the JSON format, the storage module converts the transferred and stored data into hard disk data according to a preset format, and stores the hard disk data into a storage layer, wherein the storage module is specifically configured to:
converting the data after being transferred and stored into the hard disk data in a JSON format by adopting a serialization method;
and storing the hard disk data in the JSON format to the storage layer.
In a third aspect, an embodiment of the present application provides a visually programmed code processing system, including: the system comprises a user layer, an engine layer, a memory layer and a storage layer;
the user layer is used for displaying a view;
the engine layer is configured to provide execution flow data in the resource data corresponding to the view, where the execution flow data includes: the method comprises the steps of obtaining a code view and drawing functional data corresponding to the code view, wherein the data structure of the code view is disassembled to obtain sub-code data;
the memory layer is used for storing the subcode data and the functional data which are transferred and stored according to a preset data structure to obtain data after transfer and storage;
and the storage layer is used for storing the hard disk data converted from the data subjected to the dump according to a preset format.
In a fourth aspect, an embodiment of the present application provides a computer device, including: a processor, a memory;
the memory stores computer-executable instructions;
the processor executes the computer-executable instructions to cause the computer device to perform visually programmed code processing methods as described in the first aspect and various possible designs above.
In a fifth aspect, embodiments of the present application provide a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the computer-executable instructions are used to implement a visualization programming code processing method as described in the first aspect and various possible designs.
In a sixth aspect, the present application provides a computer program product, including a computer program, which when executed by a processor is configured to implement the code processing method of visual programming as described in the first aspect and various possible designs.
In the method, execution flow data of a view is acquired from an engine layer, and the execution flow data includes: the method comprises the steps of obtaining subcode data by disassembling a code view and functional data corresponding to the code view, then storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain data after unloading, and finally converting the data after unloading into hard disk data according to a preset format to be stored to a storage layer. According to the technical scheme, after the data of the engine layer is disassembled, the disassembled data are stored according to the user-defined data structure, so that the blueprint codes are extracted, and a plaintext data basis is provided for other development processes.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.
FIG. 1 is a block diagram of a visually programmed code processing system according to an embodiment of the present disclosure;
fig. 2 is a schematic flowchart of a first embodiment of a code processing method for visual programming according to an embodiment of the present application;
fig. 3 is a schematic diagram illustrating acquisition of execution stream data according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a data structure disassembly according to an embodiment of the present application;
FIG. 5 is a diagram illustrating assignment override processing according to an embodiment of the present application;
FIG. 6 is a schematic diagram of a data store provided by an embodiment of the present application;
FIG. 7 is a diagram illustrating a default data structure according to an embodiment of the present application;
FIG. 8 is a schematic diagram of format storage provided by an embodiment of the present application;
fig. 9 is a schematic diagram of a visually programmed code processing apparatus provided in an embodiment of the present application;
fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application.
With the foregoing drawings in mind, certain embodiments of the disclosure have been shown and described in more detail below. These drawings and written description are not intended to limit the scope of the disclosed concepts in any way, but rather to illustrate the concepts of the disclosure to those skilled in the art by reference to specific embodiments.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.
Before introducing the embodiments of the present application, the terms referred to in the present application will first be explained:
phantom 4 Engine (absolute Engine 4, UE 4): a game engine for opening source, commercial charging and free learning is the 4 th generation at present, has very powerful functions and is mainly used for making host games;
UE resource file (uaset): the resource file format of the UE stores all types of resources in a binary form, and only the UE can analyze the resources;
JS Object Notation (JavaScript Object Notation, JSON): a lightweight data exchange format adopts a text format completely independent of a programming language to store and represent data, is easy for a user to read and write and machine to analyze, and can effectively improve the network transmission efficiency;
difference File (Difference File, Diff): an executable utility program for comparing the difference between two files and recording and displaying the different information, whereby the resulting file is a Diff file;
source Code Control System (SCCS): a set of system scheme for managing and controlling source codes of various versions is indicated, so that development of software and cooperative work of users are facilitated;
subversion (svn)): the version control system of the open source code is used for realizing the management of shared resources and centralized type by adopting the high-efficiency management of a branch management system, namely, the version control system is used for jointly developing the same project by a plurality of persons;
performance (P4): a version management tool has the advantages of being light and fast, and supports multiple using modes such as a Graphical User Interface (GUI) and a command line.
Next, the background art related to the present application will be explained:
with the rapid development of visual programming ideas, the method is widely applied to the design and development fields of art, procedures, industry, aerospace, medical treatment and the like. Various business engines also have great support and recommendation for visual programming, such as UE 4 (fantasy engine), Unity, and the engine Messiah (mydia), among others.
Among them, visual programming (blueprints) is commonly used for various 3A game (triple a game) hosts developed by using a UE 4 engine.
The visual programming has the characteristics of visible graphs, low learning threshold and quick operation, has high practical value for non-programming professional design or developers, can reduce communication and labor cost, and shortens the design and development period. But also has some disadvantages, such as poor portability, great difficulty in collaboration, no universality and the like, wherein the strong binding of the visualized code and the engine is a big disadvantage affecting the application value and development of the visualized code and the engine.
Taking the UE 4 as an example, the blueprint has strong functions and is convenient to use, but the blueprint can only be opened by using the UE 4 engine, cannot be automatically analyzed by being separated from the engine, conflicts with the traditional development process of the department of the inventor, and a common tool cannot be used, so that the project development efficiency is greatly influenced. Because the blueprint can only check Diff in the engine editor and does not provide merge auxiliary function, the blueprint can only be manually completed by developers, the maintenance cost is high, the multi-branch development cannot be supported, the project development mode is directly influenced, the project version stability is extremely poor, and the maintenance cost of the developers is forced to be improved. For most UE 4 projects, development using blueprints is avoided, and text programming is desirable to replace or bypass the blueprint functionality of the UE 4.
However, the blueprint itself is closely related to the UE 4 engine, many powerful functions are based on the blueprint, and discarding the blueprint results in having to discard some engine functions, thereby affecting the practical value of the engine and additionally generating redundant working cost for bypassing the blueprint.
Taking the Diff exposure function of the UE 4 engine as an example, the UE 4 provides the Diff viewing function only in the graphical editor mode, and discusses with Graph (i.e. visual view) in the blueprint. Taking a certain blueprint resource as an example, the specific view Diff content can be viewed through a graphical interface.
Specifically, in the Diff browsing list of the display interface, the changed graphs are listed, and the user can freely browse the changed contents of a certain Graph in the operation interface. The UE 4 provides visual comparison of the new version and the old version, supports functions of moving, dragging, zooming, comment specification and the like, and a user can conveniently compare Diff contents between the two versions. The technical implementation of this function is outlined as follows:
1. carrying out Diff processing on the resources;
2. drawing a Diff browsing interface and filling data required by the interface;
3. initializing data and drawing a User Interface (UI) Interface;
4. generating detailed Diff content and data;
5. drawing a view module interface, and filling related data;
6. and drawing blueprint views for the new version and the old version respectively.
Specifically, the application of Diff in the prior art has the following problems:
firstly, automation is not supported, and the monitoring cost is high;
for the tester, it is usually necessary to monitor whether the code modification by the user is correct, and the code modification is frequent, the cost is high only by manpower, and the omission is easy to occur. Therefore, the monitoring is required to be carried out in an automatic mode, and the monitoring quality can be ensured under the condition of reducing the labor cost. However, the Diff of the UE 4 is displayed through the interface, and the Diff information can be viewed only through manual interface operation, so that the automation operation cannot be performed.
Secondly, the code is strongly bound with the engine and cannot be used independently;
the blueprint resource of the UE 4 can be edited only by opening an editor of an engine of the UE 4, a user cannot use the code for other purposes under the condition of not using the engine, and cannot manage the code by using an existing development auxiliary tool, so that the working capacity of the user is greatly limited, and particularly for large projects, the problem brings a lot of difficulties to team cooperation development.
Thirdly, the method has limitation, and the function expansion cannot be carried out;
the Diff function provided by UE 4 is already established, only the conventional Diff is displayed, and the expansion of more other functions is required to be developed by self, and the development, the expansion and the migration are limited to a certain extent based on the editor work performance of UE 4. However, if the Diff data can be extracted, any desired processing of the Diff data can be performed by any technique, including presentation, comparison, inspection, alarming, error correction, etc., and the migration is not so limited, and can be changed at will according to the needs and circumstances, including direct application to other existing tools.
Based on the above problems in the prior art, fig. 1 is a schematic diagram of a framework structure of a visually programmed code processing system according to an embodiment of the present application, so as to solve the above technical problems. As shown in fig. 1, the schematic structural diagram includes: a user layer 11, an engine layer 12, a memory layer 13 and a storage layer 14.
Wherein the user layer 11 includes views that can be seen by the user; the engine layer 12 is configured to provide execution flow data in the resource data corresponding to the view, where the execution flow data includes: the method comprises the steps of obtaining a code view and drawing functional data corresponding to the code view, wherein the data structure of the code view is disassembled to obtain sub-code data; the memory layer 13 is used for storing the subcode data and the functional data according to a preset data structure to obtain the data after unloading; the storage layer 14 is used for storing hard disk data obtained by converting the data subjected to the dump according to a preset format.
In one possible design, the displaying a view by the user layer 11, obtaining execution flow data of the view from resource data corresponding to the view of the engine layer 12, and performing data structure disassembly on a code view in the execution flow data (a code view and function data corresponding to the drawing of the code view) to obtain child code data may include: the child code data and the functional data are stored in the memory layer 13 according to a preset data structure to form a data structure (data after being transferred) that can be customized by a user, and for convenience of use, the data in the memory layer 13 is converted into hard disk data (a data file in a general format, for example, a JSON format) that is required by the user and is stored in the storage layer 14.
In order to solve the technical problems, the technical conception process of the inventor is as follows: the inventor finds that the visualized codes can be extracted from the engine layer when the engine runs, the extracted visualized codes are analyzed and finally transferred into a convenient-to-use general data format, and the use value can be provided for other development processes, so that various development requirements are met.
The technical solution of the present application is described in detail by specific embodiments with a schematic frame structure shown in fig. 1. It should be noted that the following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
Fig. 2 is a schematic flowchart of a first embodiment of a code processing method for visual programming according to an embodiment of the present application. As shown in fig. 2, the method may include the steps of:
step 21, obtaining the execution flow data of the view from the engine layer.
In this step, since the visualization code is strongly bound to the engine, the code cannot be used separately from the engine, and at this time, it is necessary to acquire, in the engine layer of the computer device, information related to an interface that can be used for drawing a certain function in a view, that is, execution flow data, for example, Diff data of the engine layer.
Specifically, the execution flow data of the view is acquired from the resource data corresponding to the view of the engine layer.
In a specific implementation, the manner of obtaining the execution stream data of the view from the engine layer may be specifically implemented as: that is, Diff comparison is performed between resource data corresponding to two different versions of resource data (an old version view and a new version view), and then the Diff comparison is processed as an example, and fig. 3 is a schematic diagram of obtaining execution stream data according to the embodiment of the present application. As shown in fig. 3, resource data 31, related data 32 for rendering different (Diff), execution flow data 33, Diff data backup 34.
Optionally, the method includes obtaining, from an engine layer, first resource data corresponding to a new version view and second resource data corresponding to an old version view stored by using a tree structure, where a code view includes the first resource data and the second resource data; different portions of the first resource data and the second resource data are acquired as functional data.
Among them, Diff processing may be performed by the generatedifferences list method of the UE 4 engine itself, to obtain masterdifferences list (related data required for drawing the current blue-map Diff interface is stored in a tree form), RealDifferences (a copy of Diff data of the current blue-map, which does not include information required for drawing, is stored in a tree form), and Graphs (only Diff data of a code view of the current blue-map is drawn in the Diff interface and is stored in an array form).
The masterdifferences list, RealDifferences and Graphs are coupled, and useful information is extracted from the data according to needs.
Further, the execution stream data 33 includes: and drawing the function data corresponding to the code view.
Specifically, the code view in the execution stream data 33 may be represented by Graphs, where the Graphs include an old version code view of GraphOld and a new version code view of graphynew. The functional data in the execution stream data is DiffListSource, i.e., graphfdiffinfo described below.
Wherein, the Graphold \ GraphNew contains all node information and can be used for drawing a visual blueprint. DiffListSource can be used to draw the difference between views whose Diff embodies the old and new versions, as long as it contains the information of different parts in the views between the old and new versions, i.e. only contains the information of difference.
And 22, disassembling the data structure of the code view to obtain subcode data.
In this step, data disassembly needs to be performed on the code view (GraphOld \ graphynew) to obtain each node information of the code view, an Identity card identification number (ID) of the code view, and other view identifications related to the code view; further disassembling each node information to obtain each pin information, the ID of the node and the identification of other nodes related to the node; and further, disassembling the information of each pin to obtain the identifier of the pin and the identifiers of other pins related to the pin.
Wherein, the information of each node comprises: at least one pin information, an identification of the node, and an identification of other nodes associated with the node, each pin information comprising: an identification of at least one pin and an identification of other pins associated with the at least one pin.
In addition, taking graphfnfo for drawing functional data as an example, it contains new node difference information and old node difference information; old pin information, new pin information; a difference type identifier; a displayable summary of differences, etc.
Illustratively, the structures of the two data, GraphOld \ graphynew, are actually the same, but the contents are different, taking GraphOld as an example, and fig. 4 is a schematic diagram for disassembling the data structure provided by the embodiment of the present application. As shown in fig. 4, the child code data (taking the old version code view as an example) includes: information 41 of the node, identification 42 of the view, and identification 43 of other views associated with the view; the information 41 of the node includes: pin information 411, identification of the node 412, and identification of other nodes associated with the node 413; the pin information 411 includes: an identification 4111 of a pin and an identification 4112 of other pins associated with the pin.
The node information 41, the pin information 411, and the pin identifier 4111 are at least one each.
Specifically, the node information 41(Nodes) includes node names, types, locations, pins, and the like;
pin information 411(Pins) including pin name, type, direction, default, color, etc.; the identification 4111(PinGuid) of the pin may be a pin ID, which is used to identify the pin identity and is unique in the full blueprint; the identification 4112(OtherPinInfo) of other pins, information and data types of other pins are all different and are not listed one by one here; the node identifier 412(NodeGuid) may be a node ID, which is used to identify the node identity and is unique in the full blueprint; the identifiers 413(OtherNodeInfo) of other nodes, information and data types of other nodes are all different and are not listed one by one here; an identification 42 of the view (GraphGuid), a view ID, a blueprint possibly containing a plurality of different views for identifying identity, a full blueprint being unique; the other view identifiers 43(OtherGraphInfo), other view information, and data types are all different and are not listed individually herein.
Optionally, the data acquired at this time are all engine layers, and other technologies described below are also needed to process the data.
And step 23, storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain the data after unloading.
In this step, in order to facilitate development and implementation and reduce code complexity, a method of a heavy-load assignment operator may be used to complete data extraction operation, and assignment heavy load corresponding to engine (taking UE 4 as an example) data is completed in each custom data, that is, in this embodiment, assignment heavy load processing is performed on sub-code data and functional data to obtain extracted execution stream data.
The user-defined data are subcode data and functional data.
For example, to assign and reload the sub-code data and the function data, continuing with the above example, it is enough to execute GraphToDiff — FGraphToDiff operation, specifically, fig. 5 is a schematic diagram of assignment and reload processing provided in the embodiment of the present application. As shown in FIG. 5, the assignment override processing diagram includes: an assignment override 51 for the execution stream data, an assignment override 52 for the subcode data, an assignment override 53 for the function data, an assignment override 54 for the information of the node, an assignment override 55 for the pin information, and an assignment override 56 for the chained pin data.
Wherein, the assignment override 51 for executing the streaming data GraphToDiff may be: GraphToDiff & & operator ═ (FGraphToDiff); the assignment override 52 of child code data Graph may be: GraphToDiff & operator ═ (UEdGraph); the assignment override 53 for the functional data GraphDiffInfo may be: graphfnffo & operator (fdiffsingleesult); the assignment override 54 of the information GraphNode of the node may be: GraphNode operator (UEdGraphNode); the assignment override 55 for the pin information grapphpingraph may be: graphping operator (UEdGraphPin); the assignment override 56 of the chained pin data LinkPin may be: LinkPin operator (UEdLinkPin).
It is worth mentioning that in the assignment overloading process, the difficulty lies in the initialization, assignment and type conversion of the custom data, such as the default value of the pin, and different default values can be obtained according to different data types, and the custom data can be uniformly converted into character string types; and enumeration types such as pin direction and the like can also be converted into a character string type by processing unification by self.
In addition, a data mark with a preset data structure is established in the memory layer, and the data mark is used for indicating that the subcode data and the functional data are stored in corresponding positions in the memory layer.
Wherein, the data object of the preset data structure comprises: executing a flow data table, the executing the flow data table comprising: a data area of a view and a data area of a function associated with the view, the data area of the view including: at least one nodal region, the nodal region comprising: at least one lead area.
In this step, in order to record the extracted execution stream data in the memory layer for subsequent use, a set of available custom data structures needs to be customized for storing the execution stream data.
Illustratively, fig. 6 is a schematic data storage diagram provided in an embodiment of the present application. As shown in fig. 6, the data storage diagram is illustrated by taking the data copy from the engine layer to the memory layer as an example:
at the engine layer, the method comprises the following steps: the execution stream data (Graphs, class fgraphtdiff) is specifically: old version code view (GraphOld, class UEdGraph); new version code view (GraphNew, class UEdGraph); function data (DiffListSource, class FDiffResultem).
In the memory layer, include: the custom execution stream data (mygraphics, class GraphToDiff) specifically includes: custom old version code view (MyGraphOld, class Graph); customizing a new version code view (MyGraphNew, class Graph); custom function data (MyDiffListSource, class diffresult).
Optionally, the extracted execution stream data is copied to a data object according to the data structure, so as to obtain the data after being transferred.
In a possible implementation, the Graphs are disassembled into Graphold, GraphNew and DiffListSource, the three data are subjected to assignment and overloading processing, and the three data are stored to the corresponding MyGraphold, MyGraphNew and MyDiffListSource, so that MyGraphs are formed.
Fig. 7 is a schematic diagram of a preset data structure provided in an embodiment of the present application. As shown in fig. 7, the data structure includes: execution stream data GraphToDiff71, function data graphtdiffinfo 72, subcode data Graph73, node information graphnnode 74, pin information graphngraph 75, and chained pin data LinkPin 76.
The execution stream data 71 table records all child code data Graph73 and functional data Graph diffinfo72, and specifically includes: old code version view (Graph-Old Graph), New code version view (Graph-New Graph), and inter-version difference information (TArra < Graph diffinfo > diffinfo).
The functional data (data area of function) 72 records all Diff difference information, the difference information is for each view, the difference type is operation identification such as adding node, deleting node, modifying pin, etc., the difference summary is a literal description of the difference type, specifically: old node difference information (GraphNode-OldNodelnfo), new node difference information (GraphNode-NewNodelnfo), old pin difference information (GraphPin-OldPinnfo), new pin difference information (GraphPin-NewPinnfo), difference type identification (FString-DiffType), displayable difference summary (FString-DisplayString).
The subcode data (data area of view) 73 is used for recording view data, specifically: view name (FString-GroupName), view ID (FGuid-GroupID), and all nodes contained in the view (TArra < GroupNode > GroupNodes).
The node information (node area) 74 records node data, the node name is also the name of the visual code function, and the node position is a position drawn on the plane background in the UE 4, and can be used for redrawing reference, specifically: node ID (FGuid-NodeID), node name (Ftext-NodeTitle), node name color (FLinarColor-NodeTitleColor), node position-abscissa (int32-NodePosX), node position-ordinate (int32-NodePosY), and all Pins contained in the node (TArra < GroupPin > Pins).
The pin information (pin area) 75 records pin data, a pin name is a name of an entry parameter or a return value of a visual code function, a pin data type is a data type of the entry parameter or the return value, a pin direction is used for distinguishing the entry parameter or the return value, and a chain is a pin, that is, a pin of the next other node linked with the current pin, and can be understood as parameter transfer, specifically: subordinate node ID (FGuid-OwningNodeID), pin ID (FGuid-PinID), pin name (FName-PinName), pin data type (FName-PinTypeName), pin default value (FString-DefaultValue), other pins of the chain Direction (Tarra < LinkPin > LinkToPin), and pin Direction (TenumacByte < enum EEdGraphPinDirection > Direction).
The chain-direction pin data (chain-direction pin area) 76 records the chain-direction pin data, specifically: subordinate node ID (FGuid-OwningNodeID), and pin ID (FGuid-PinID).
In summary, by the data structure, various information of the blueprint code view and Diff data can be recorded.
On the basis of the above steps, in order to use the extracted execution stream data stored in the memory layer, the following steps may be further performed.
And 24, converting the data after the dump into hard disk data according to a preset format and storing the hard disk data in a storage layer.
In this step, according to a preset format defined by a user, the execution stream data of the memory layer is converted into the storage layer, so that the function in a certain engine is applied to other development processes (code formats for realizing the function).
In a possible implementation, when the preset format includes a JSON format, fig. 8 is a format storage diagram provided in the embodiment of the present application. As shown in fig. 8, the method conversion using the reload sequence includes: the conversion 81 of the stream data graptodif, the conversion 82 of the subcode data Graph, the conversion 83 of the functional data graphfinfo, the conversion 84 of the information graphnnode of the node, the conversion 85 of the pin information grapnpraph, and the conversion 86 of the pin data LinkPin in the chain direction are performed.
Among them, the conversion 81 to perform stream data may be: GraphToDiff-FJsonObject secret (); the conversion 82 of the subcode data may be: GraphF-JsonObject Serialize (); the conversion 83 of the functional data may be: graphddiffinfo-FJsonObject secret (); the conversion 84 of the information of the node may be: GraphNode-FJsonObject secret (); the conversion 85 of pin information may be: graphping-FJsonObject secret (); the conversion 86 of the chain-wise pin data may be: LinkPin-FJsonObject Serialize ().
Optionally, the method for reloading the sequence is to convert the data after being transferred into the hard disk data in the JSON format by using a serialization method, where a JSON output class fjson object carried by the UE 4 is used, and custom encapsulation is performed on the basis, and the functions can be divided into the following classes:
1. inserting a character string key value pair into the FJsonObject;
2. inserting FJsonObject nested objects into the FJsonObjects;
3. inserting an FJsonObject array into the FJsonObject;
4. acquiring a FJsonObject nested object in a certain FJsonObject object;
5. the FJsonObject objects are serialized into Json strings and stored as Json files.
If other data types which are not included, such as integer, floating point, Boolean, enumeration and the like, can be converted into character string key value pairs for processing, so that the custom data in the memory can be simply and conveniently stored into a general Json file.
Further, the hard disk data in the JSON format is stored to the storage layer. In the storage layer, it can be freely copied or used for other blueprint function implementations.
In one possible implementation, after the above steps are combined, to convert a UE 4 blueprint visualization code into an example of a Json file, at a Diff display interface of another blueprint, Diff content is to add a node, that is, the execution stream data is applied by another blueprint.
The DiffInfo data in the Json file after partial parsing is shown below, and comparing the part of the double-solid box with the part of the single-solid box shows that a new node is added, which results in a change in the pins:
Figure BDA0003195834090000151
Figure BDA0003195834090000161
Figure BDA0003195834090000171
the new and old view Graph data in the Json file after partial resolution is shown as follows, and partial pin names, data types and default values in the newly added node "Print String" are shown from the part of the solid line box, and are consistent with the actual visualized code content:
Figure BDA0003195834090000172
Figure BDA0003195834090000181
the code processing method for visual programming provided by the application acquires execution flow data of a view from an engine layer, wherein the execution flow data comprises: the method comprises the steps of obtaining subcode data by disassembling a code view and functional data corresponding to the code view, then storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain data after unloading, and finally converting the data after unloading into hard disk data according to a preset format to be stored to a storage layer. According to the technical scheme, after the data of the engine layer is disassembled, the disassembled data are stored according to the user-defined data structure, so that the blueprint codes are extracted, and a plaintext data basis is provided for other development processes.
On the basis of the above method embodiment, fig. 9 is a schematic diagram of a visually programmed code processing apparatus provided in the embodiment of the present application. As shown in fig. 9, the processing apparatus includes: the device comprises an acquisition module 91, a processing module 92 and a storage module 93.
An obtaining module 91, configured to obtain, from the engine layer, execution stream data of the view, where the execution stream data includes: the code view and the functional data corresponding to the drawing code view;
the processing module 92 is configured to perform data structure disassembly on the code view to obtain sub-code data, where the sub-code data includes: information of at least one node, an identification of a view, and an identification of other views associated with the view;
and the storage module 93 is configured to store the subcode data and the functional data in the memory layer according to a preset data structure to obtain data after being transferred and stored, and convert the data after being transferred and stored into hard disk data according to a preset format and store the hard disk data in the memory layer.
In one possible design of the embodiment of the present application, the information of each node includes: at least one pin information, an identification of the node, and an identification of other nodes associated with the node, each pin information comprising: an identification of the at least one pin and an identification of other pins associated with the at least one pin.
In another possible design of the embodiment of the present application, the preset data structure includes: executing a flow data table, the executing the flow data table comprising: a data area of the view and a functional data area associated with the view, the data area of the view comprising: at least one nodal region, the nodal region comprising: at least one pin area, the functional data area associated with the view including pin information for the at least one pin.
In yet another possible design of the embodiment of the present application, the obtaining module 91 is specifically configured to obtain execution stream data of a view from resource data corresponding to the view of the engine layer.
In this possible design, the obtaining module 91 is specifically configured to:
acquiring first resource data corresponding to a new version view and second resource data corresponding to an old version view which are stored by adopting a tree structure from an engine layer, wherein a code view comprises the first resource data and the second resource data;
different portions of the first resource data and the second resource data are acquired as functional data.
In another possible design of the embodiment of the present application, the storage module 93 stores the subcode data and the functional data to the memory layer according to a preset data structure to obtain the data after being transferred, and is specifically configured to:
establishing a data object with a preset data structure in a memory layer;
carrying out assignment overloading processing on the subcode data and the functional data to obtain extracted execution stream data;
and copying the extracted execution stream data into a data object according to the data structure to obtain the data after the dump.
In another possible design of the embodiment of the present application, the preset format includes: in the JSON format, the storage module 93 converts the data after being transferred into hard disk data according to a preset format, and stores the hard disk data in a storage layer, and is specifically configured to:
converting the data after the transfer into hard disk data in a JSON format by adopting a serialization method;
and storing the hard disk data in the JSON format to a storage layer.
The code processing apparatus for visual programming provided in the embodiment of the application may be used to execute the technical scheme corresponding to the code processing method for visual programming in the embodiment of fig. 2, and the implementation principle and the technical effect are similar, which are not described herein again.
It should be noted that the division of the modules of the above apparatus is only a logical division, and the actual implementation may be wholly or partially integrated into one physical entity, or may be physically separated. And these modules can be realized in the form of software called by processing element; or may be implemented entirely in hardware; and part of the modules can be realized in the form of calling software by the processing element, and part of the modules can be realized in the form of hardware. In addition, all or part of the modules can be integrated together or can be independently realized. The processing element described herein may be an integrated circuit having signal processing capabilities. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in the form of software.
Fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 10, the computer apparatus may include: a processor 101, a memory 102, and computer program instructions stored on the memory 102 and operable on the processor 101.
The processor 101 executes computer-executable instructions stored by the memory 102, causing the processor 101 to perform the aspects of the embodiments described above. The processor 101 may be a general-purpose processor including a central processing unit CPU, a Network Processor (NP), and the like; but also a digital signal processor DSP, an application specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components.
The memory 102 is connected to the processor 101 via a system bus and communicates with each other, and the memory 102 is used for storing computer program instructions.
The system bus may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The system bus may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.
The computer device provided in the embodiment of the present application may be configured to execute the technical solution corresponding to the code processing method for visual programming in the foregoing embodiment, and the implementation principle and the technical effect are similar, which are not described herein again.
The embodiment of the application further provides a chip for running the instructions, and the chip is used for executing the technical scheme of the code processing method for the visual programming in the embodiment.
The embodiment of the present application further provides a computer-readable storage medium, where a computer instruction is stored in the computer-readable storage medium, and when the computer instruction runs on a computer device, the computer device is enabled to execute the technical solution of the code processing method of the visualization programming in the foregoing embodiment.
The embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program is used to execute the technical solution of the code processing method of the visual programming in the foregoing embodiment.
The computer-readable storage medium described above may be implemented by any type of volatile or non-volatile memory device or combination thereof, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk. Readable storage media can be any available media that can be accessed by a general purpose or special purpose computer device.
It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims (11)

1. A visually programmed code processing method, the method comprising:
obtaining execution flow data for a view from an engine layer, the execution flow data comprising: the method comprises the steps of code view and drawing function data corresponding to the code view;
performing data structure disassembly on the code view to obtain sub-code data, wherein the sub-code data comprises: information of at least one node, an identification of the view, and an identification of other views associated with the view;
storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain data after unloading;
and converting the data after the unloading into hard disk data according to a preset format and storing the hard disk data in a storage layer.
2. The method of claim 1, wherein the information for each node comprises: at least one pin information, an identification of the node, and an identification of other nodes associated with the node, each pin information comprising: an identification of at least one pin and an identification of other pins associated with the at least one pin.
3. The method according to claim 1 or 2, wherein the preset data structure comprises: an execution flow data table, the execution flow data table comprising: a data area of the view and a functional data area associated with the view, the data area of the view comprising: at least one nodal region, said nodal region comprising: at least one pin area, the functional data area associated with the view including pin information for at least one pin.
4. The method of claim 1 or 2, wherein the obtaining of the execution flow data of the view from the engine layer comprises:
and acquiring execution flow data of the view from resource data corresponding to the view of the engine layer.
5. The method of claim 4, wherein the obtaining the execution flow data of the view from the resource data corresponding to the view of the engine layer comprises:
acquiring first resource data corresponding to a new version view and second resource data corresponding to an old version view which are stored by adopting a tree structure from the engine layer, wherein the code view comprises the first resource data and the second resource data;
acquiring different parts of the first resource data and the second resource data as the function data.
6. The method as claimed in claim 1 or 2, wherein the storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain the data after unloading comprises:
establishing a data object with a structure of the preset data structure in the memory layer;
assigning and overloading the subcode data and the functional data to obtain extracted execution stream data;
and copying the extracted execution stream data into the data target according to the data structure to obtain the data after the unloading.
7. The method according to claim 1 or 2, wherein the preset format comprises: and in the JSON format, converting the transferred and stored data into hard disk data according to a preset format, and storing the hard disk data in a storage layer, including:
converting the data after being transferred and stored into the hard disk data in a JSON format by adopting a serialization method;
and storing the hard disk data in the JSON format to the storage layer.
8. A visually programmed code processing apparatus for use with a computer device, the apparatus comprising: the device comprises an acquisition module, a processing module and a storage module;
the obtaining module is configured to obtain execution stream data of the view from an engine layer, where the execution stream data includes: the method comprises the steps of code view and drawing function data corresponding to the code view;
the processing module is configured to perform data structure disassembly on the code view to obtain sub-code data, where the sub-code data includes: information of at least one node, the identifier of the view and identifiers of other views related to the view, and assignment reloading processing is carried out on the subcode data and the functional data to obtain extracted execution stream data;
the storage module is used for storing the extracted execution stream data to a memory layer according to a preset data structure, converting the extracted execution stream data into hard disk data according to a preset format and storing the hard disk data to the storage layer of the computer equipment.
9. A visually programmed code processing system, comprising: the system comprises a user layer, an engine layer, a memory layer and a storage layer;
the user layer is used for displaying a view;
the engine layer is configured to provide execution flow data in the resource data corresponding to the view, where the execution flow data includes: the method comprises the steps of obtaining a code view and drawing functional data corresponding to the code view, wherein the data structure of the code view is disassembled to obtain sub-code data;
the memory layer is used for storing the subcode data and the functional data which are transferred and stored according to a preset data structure to obtain data after transfer and storage;
and the storage layer is used for storing the hard disk data converted from the data subjected to the dump according to a preset format.
10. A computer device, comprising: processor, memory and computer program instructions stored on the memory and executable on the processor, characterized in that the processor implements the visually programmed code processing method according to any of the preceding claims 1 to 7 when executing the computer program instructions.
11. A computer-readable storage medium having stored thereon computer-executable instructions for implementing a visually programmed code processing method according to any one of claims 1 to 7 when executed by a processor.
CN202110890840.XA 2021-08-04 2021-08-04 Code processing method, device and system for visual programming Active CN113608727B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110890840.XA CN113608727B (en) 2021-08-04 2021-08-04 Code processing method, device and system for visual programming

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110890840.XA CN113608727B (en) 2021-08-04 2021-08-04 Code processing method, device and system for visual programming

Publications (2)

Publication Number Publication Date
CN113608727A true CN113608727A (en) 2021-11-05
CN113608727B CN113608727B (en) 2023-07-25

Family

ID=78306788

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110890840.XA Active CN113608727B (en) 2021-08-04 2021-08-04 Code processing method, device and system for visual programming

Country Status (1)

Country Link
CN (1) CN113608727B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115934086A (en) * 2022-12-28 2023-04-07 苏州峰之鼎信息科技有限公司 Information sharing method, device, equipment and medium for blueprint and page design

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020004804A1 (en) * 2000-03-24 2002-01-10 Georg Muenzel Industrial automation system graphical programming language storage and transmission
US20120313953A1 (en) * 2011-06-07 2012-12-13 The Mathworks, Inc. Graphical data conversion/translation
WO2015192555A1 (en) * 2014-06-20 2015-12-23 中兴通讯股份有限公司 Data transmission method, base station, and storage medium
CN105204980A (en) * 2014-05-26 2015-12-30 腾讯科技(深圳)有限公司 Method for testing virtual engine software and testing equipment
WO2018034585A1 (en) * 2016-08-17 2018-02-22 Huawei Technologies Co., Ltd Techniques for data transmission based on irregular connection graphs
DE102017101848A1 (en) * 2017-01-31 2018-08-02 Gritworld GmbH Data visualization system for industrial design
US20190139321A1 (en) * 2017-11-03 2019-05-09 Samsung Electronics Co., Ltd. System and method for changing a virtual reality environment dynamically
CN109966742A (en) * 2019-03-21 2019-07-05 深圳市腾讯信息技术有限公司 The method and device of rendering performance data is obtained in game running
CN110705219A (en) * 2019-10-21 2020-01-17 网易(杭州)网络有限公司 Game data processing method and device, storage medium and electronic equipment
CN111596903A (en) * 2020-03-27 2020-08-28 完美世界(北京)软件科技发展有限公司 Data processing method and device in rendering engine
CN111949607A (en) * 2020-09-03 2020-11-17 网易(杭州)网络有限公司 Method, system and device for monitoring UDT file
CN112883102A (en) * 2021-03-05 2021-06-01 北京知优科技有限公司 Data visualization display method and device, electronic equipment and storage medium
CN113018870A (en) * 2021-04-17 2021-06-25 腾讯科技(深圳)有限公司 Data processing method and device and computer readable storage medium

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020004804A1 (en) * 2000-03-24 2002-01-10 Georg Muenzel Industrial automation system graphical programming language storage and transmission
US20120313953A1 (en) * 2011-06-07 2012-12-13 The Mathworks, Inc. Graphical data conversion/translation
CN105204980A (en) * 2014-05-26 2015-12-30 腾讯科技(深圳)有限公司 Method for testing virtual engine software and testing equipment
WO2015192555A1 (en) * 2014-06-20 2015-12-23 中兴通讯股份有限公司 Data transmission method, base station, and storage medium
WO2018034585A1 (en) * 2016-08-17 2018-02-22 Huawei Technologies Co., Ltd Techniques for data transmission based on irregular connection graphs
DE102017101848A1 (en) * 2017-01-31 2018-08-02 Gritworld GmbH Data visualization system for industrial design
US20190139321A1 (en) * 2017-11-03 2019-05-09 Samsung Electronics Co., Ltd. System and method for changing a virtual reality environment dynamically
CN109966742A (en) * 2019-03-21 2019-07-05 深圳市腾讯信息技术有限公司 The method and device of rendering performance data is obtained in game running
CN110705219A (en) * 2019-10-21 2020-01-17 网易(杭州)网络有限公司 Game data processing method and device, storage medium and electronic equipment
CN111596903A (en) * 2020-03-27 2020-08-28 完美世界(北京)软件科技发展有限公司 Data processing method and device in rendering engine
CN111949607A (en) * 2020-09-03 2020-11-17 网易(杭州)网络有限公司 Method, system and device for monitoring UDT file
CN112883102A (en) * 2021-03-05 2021-06-01 北京知优科技有限公司 Data visualization display method and device, electronic equipment and storage medium
CN113018870A (en) * 2021-04-17 2021-06-25 腾讯科技(深圳)有限公司 Data processing method and device and computer readable storage medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SEBQUIT: "【UE4】 结构体数据转为Json的保存和读取(当存档使用)", 《HTTPS://BLOG.CSDN.NET/WEIXIN_44052668/ARTICLE/DETAILS/106784149》 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115934086A (en) * 2022-12-28 2023-04-07 苏州峰之鼎信息科技有限公司 Information sharing method, device, equipment and medium for blueprint and page design

Also Published As

Publication number Publication date
CN113608727B (en) 2023-07-25

Similar Documents

Publication Publication Date Title
CN111241454B (en) Method, system and device for generating webpage codes
US7133874B2 (en) Prototyping model for components of a software program
US7484223B2 (en) System and method for building a run-time image from components of a software program
US7428559B2 (en) Versioning model for software program development
US7210131B2 (en) Method and system for migrating computer state
CN112036736A (en) Workflow creating method and device
WO2018036342A1 (en) Csar-based template design visualization method and device
US9043757B2 (en) Identifying differences between source codes of different versions of a software when each source code is organized using incorporated files
WO2020235085A1 (en) Operation log visualization device, operation log visualization method, and operation log visualization program
WO2022188780A1 (en) Visual software development system, method and apparatus, and computer storage medium
JP5076381B2 (en) Software development apparatus and software development method
US8615729B2 (en) Extending existing model-to-model transformations
JPH10254689A (en) Application constitution design supporting system for client/server system
US8701086B2 (en) Simplifying analysis of software code used in software systems
CN113608727B (en) Code processing method, device and system for visual programming
Gómez et al. An approach to the co-creation of models and metamodels in Enterprise Architecture Projects.
Baxter et al. SPIRE: the SPIDER reconstruction engine
US10884711B2 (en) Code management system and code management method using a visual programming tool
US10956136B2 (en) User interface resource file optimization
KR20060079690A (en) Component-based programming automation process using templates and patterns
Eyl et al. Traceability in a fine grained software configuration management system
US10891412B1 (en) Offline analysis of hierarchical electronic design automation derived data
CN111124548B (en) Rule analysis method and system based on YAML file
Mathony Deployment-technology-agnostic management of running applications
van de Laar et al. Renaissance-Ada: Tools for Analysis and Transformation of Ada code

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant