Background code automatic generation method of low-code development platform

Abstract

The invention relates to the technical field of low-code development platforms, and provides an automatic background code generation method for a low-code development platform, which comprises the following steps of: performing automatic generation processing on an interface code by utilizing a business process model, and automatically generating an interface code of the background code; automatically generating background function codes by utilizing the interaction model, and automatically generating the background function codes of the background codes; and according to the dependency relationship, automatically generating a related extension code of the background code, and detecting the consistency of the automatically generated background code and the model by utilizing a formalization method.

Description

Technical Field

[0001] The present invention relates to the technical field of low-code development platforms, and in particular to a method for automatically generating background code for a low-code development platform. Background Art

[0002] Low-Code Development Platforms (LCDP) is a software development platform for rapid application development. It aims to reduce the technical threshold and workload of developing software systems by using a graphical interface and a small amount of coding. Traditional LCDPs provide various predefined templates and components, but these components do not have clear definitions and meanings in the software system, and their correctness cannot be guaranteed during the software development process. When facing specific fields, the correctness and reliability of the software system generated by predefined components are difficult to guarantee. In other words, the software system generated by traditional LCDP is not trustworthy. Summary of the invention

[0003] The present invention provides a method for automatically generating background code for a low-code development platform, which solves the technical problem that traditional low-code platforms cannot fully automatically generate user interfaces.

[0004] An embodiment of the present invention provides a method for automatically generating background code for a low-code development platform, including: Use the business process model to automatically generate interface code and automatically generate interface code for the background code; Use the interactive model to automatically generate background function codes and automatically generate background function codes for background codes; According to the dependency relationship, the related extension code of the background code is automatically generated, and the consistency between the automatically generated background code and the model is detected using formal methods.

[0005] Preferably, the interface code is automatically generated by using the business process model, and the interface code for automatically generating the background code includes: Initialize non-deterministic information according to user selection and obtain basic interface functions; Processing interaction overview graphs based on sequence dependencies; According to the corresponding relationship between the interaction overview diagram and the interface information, the interface code of the background code is automatically generated.

[0006] Preferably, according to the corresponding relationship between the interaction overview diagram and the interface information, the interface code for automatically generating the background code includes: Generate deterministic information based on the initialization interface; Generate the interface name createCourse according to the information of the starting node e in the interaction overview diagram; In the interaction overview diagram The formal parameters generated by the node f of type are written into the interface; Write the interface parameter Data in the interaction overview diagram into the communication request; In the interaction overview diagram The backend instruction address information contained in the node g of type is written into the communication request; In the interaction overview diagram The return result of the node h of type is written into the callback function as a formal parameter; Perform branch judgment, use the node i following [res] in the interaction overview diagram to generate a callback function for successful communication, and use the node j following [err] in the interaction overview diagram to generate a callback function for failed communication.

[0007] Preferably, the background function code is automatically generated by using the interaction model, and the background function code automatically generated by the background code includes: Message sequence sorting is used to ensure that the code statements are consistent with the model process; The partial order relationship between messages and objects is constructed to ensure that the code is generated in the correct file; Global scanning to avoid duplication of generated files and code; Reference generation and object generation, used to handle file dependencies based on model object dependencies; Statement generation, used for each message acting on an object to generate code statements; Code and model consistency detection is used for formal method detection to ensure code correctness.

[0008] Preferably, the construction of the partial order relationship between the message and the object includes: According to the order of the message sequence, the sender object and the receiver object of the type element of the control class, service class and Dao layer are constructed in a partial order relationship.

[0009] Preferably, the global scan includes: According to the unified structure Scan the three categories and create three arrays of Controller, Service and Dao to store object information; Traverse the Controller, Service, and Dao objects in the sequence diagram to determine whether the object exists in the corresponding array; If it does not exist, store its object information in an array and create a file for subsequent code generation; If the object information already exists, the created file is found based on the object information, and the subsequently generated code will be appended to the file.

[0010] Preferably, statement generation includes: Traverse all objects in the sequence diagram, traverse all messages bound to each object, and determine the message type; Generate different types of messages into corresponding code statements according to the conversion rules.

[0011] Preferably, each message in the sequence diagram has five types of fields, which respectively represent the method name of the message 、The specified object name of the message return result , the actual parameters of the message , the formal parameters of the message And the return result type of the message .

[0012] The embodiments of this specification can at least achieve the following beneficial effects: Based on the technical architecture of the model-driven low-code development platform, the automatic generation algorithm of its background code is described, including the generation of interface code from the business process model and the generation of functional code from the interaction model. The abstract model and data format of the general interface code are summarized and corresponded to the model elements, providing a universal interface code generation strategy. The UML sequence diagram is refined as an LCDP interaction model for building real business processes. The UML sequence diagram is divided into levels, and language-independent and platform-independent code is automatically generated based on the Message element information according to the objects at different levels. Formal methods are also used to ensure the credibility of the automatically generated code, and the consistency between models and between models and codes is tested. The sequence diagram code of the newly created course is formally verified, providing an idea for model and code consistency detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Various other advantages and benefits will become apparent to those skilled in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only used for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. In the accompanying drawings: Figure 1 A schematic diagram of model conversion of the model-driven LCDP provided by the present invention; Figure 2 A schematic diagram of an interactive overview of a newly created course provided by the present invention; Figure 3 A schematic diagram of the sequence of newly created courses provided by the present invention; Figure 4 A schematic diagram of an example of the interface code provided by the present invention; Figure 5 A schematic diagram of interface information comparison provided by the present invention; Figure 6 This is a schematic diagram of an example of interface initialization provided by the present invention; Figure 7 A schematic diagram of the interface code generation process provided by the present invention; Figure 8 A schematic diagram of the background code generation algorithm provided by the present invention; Fig. 9 A schematic diagram of a contact query sequence diagram provided by the present invention; Fig.10 A schematic diagram of a class diagram for a course entity design provided by the present invention; Fig.11 The present invention provides a flowchart of the background code automatic generation method. DETAILED DESCRIPTION

[0014] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0015] The present invention provides a method for automatically generating background code for a low-code development platform, including: using a business process model to automatically generate interface code to automatically generate interface code for the background code; using an interaction model to automatically generate background function code to automatically generate background function code for the background code; automatically generating related extension code for the background code based on dependency relationships, and using a formal method to detect the consistency of the automatically generated background code with the model.

[0016] In an embodiment of the present invention, the business process model is used to automatically generate interface code, and the interface code of the background code is automatically generated, including: initializing non-deterministic information according to user selection to obtain basic interface functions; processing the interaction overview diagram according to sequence dependencies; and automatically generating the interface code of the background code according to the correspondence between the interaction overview diagram and the interface information.

[0017] In the embodiment of the present invention, according to the corresponding relationship between the interaction overview diagram and the interface information, the interface code for automatically generating the background code includes: generating deterministic information based on the initialization interface; generating the interface name createCourse according to the information of the starting node e in the interaction overview diagram; converting the interaction overview diagram into Write the formal parameters generated by the node f of the type into the interface; write the interface parameter Data in the interaction overview diagram into the communication request; The backend instruction address information contained in the node g of type is written into the communication request; The return result of the node h of the type is written into the callback function in the form of formal parameters; branch judgment is performed, and the callback function of successful communication is generated by the node i subsequent to [res] in the interaction overview diagram, and the callback function of failed communication is generated by the node j subsequent to [err] in the interaction overview diagram.

[0018] In an embodiment of the present invention, an interactive model is used to automatically generate background function codes, and the background function codes for automatically generating background codes include: message sequence sorting, which is used to ensure that code statements are consistent with model processes; partial order relationship construction between messages and objects, which is used to ensure that code is generated in the correct file; global scanning, which is used to avoid duplication of generated files and codes; reference generation and object generation, which are used to process file dependencies according to model object dependencies; statement generation, which is used to generate code statements for each message acting on the object; code and model consistency detection, which is used for formal method detection to ensure code correctness.

[0019] In the embodiment of the present invention, the construction of the partial order relationship between messages and objects includes: constructing the partial order relationship between the sender object and the receiver object of the type elements of the control class, service class and Dao layer in sequence according to the order of the message sequence.

[0020] In the embodiment of the present invention, the global scan includes: Scan the three categories and create three arrays of control class Controller, service class Service, and Dao layer Dao to store object information; traverse the Controller, Service, and Dao objects in the sequence diagram to determine whether the object exists in the corresponding array; if not, store its object information in the array and create a file for subsequent code generation; if this object information already exists, find the created file based on the object information, and the subsequently generated code will be appended to this file.

[0021] In the embodiment of the present invention, statement generation includes: traversing all objects in the sequence diagram, traversing all messages bound to each object, and determining the message type; generating different types of messages into corresponding code statements according to conversion rules.

[0022] In the embodiment of the present invention, each message in the sequence diagram has five types of fields, which respectively represent the method name of the message 、The specified object name of the message return result , the actual parameters of the message , the formal parameters of the message And the return result type of the message .

[0023] Combine the following Figure 1-Figure 11 Further explanation of the embodiments of the present invention The present invention extends the existing LCDP, based on the idea of ​​Model-Driven Engineering, and uses the Unified Modeling Language (UML) modeling software system. The extended LCDP automatically or semi-automatically completes the transition from design to implementation through the technology of Model Transformation, and finally automatically generates the corresponding code. The models used by the model-driven LCDP are: use case model (UML use case model), domain concept model (UML class diagram), representation model (extension of UML class diagram), business process model (UML interaction overview diagram), interaction model (UML sequence diagram) and formal model-unified structure-can fully describe any UML model and its extension, and can ensure the correctness of the model itself, the consistency between models, and the consistency between models and codes. Among them, design models such as use case model and domain concept model are used to build a complete software system, and the unified structure is used to formalize the modeling design model and automatically generate code. It is worth noting that in order to meet the requirements of LCDP, design models such as use case model and domain concept model are expanded without changing the basic semantics. Model-driven LCDP automatic code generation mainly includes four parts: UML model formalization, interface code automatic generation, background code automatic generation and configuration code automatic generation.

[0024] Architecture of Model-Driven LCDP A lightweight model-driven LCDP is implemented based on NodeJS and GoJS graphics libraries. It can perform UML modeling on software systems, and can manage models and generate code for the entire software development process. Model-driven LCDP uses use case models and domain concept models to model software system requirements, and automatically generates presentation models, business process models, and interaction models. Code is then automatically generated based on the design model of the software system, including data models, UI interface codes, and high-level language codes (such as Java codes). The conversion relationships between these models are as follows: Figure 1 shown.

[0025] exist Figure 1In the model transformation diagram of the model-driven LCDP, business requirements are divided into behavioral requirements and structural requirements. Behavioral requirements are used to generate use case models, while structural requirements generate domain concept models. The presentation model (display diagram) is a static interface model generated based on the operation information of the use case model and the data objects of the domain concept model. It contains the interface prototype and the operation of the system in response to user requests in the use case model. The presentation model also provides API interfaces (for buttons, forms or jump requests on the interface), and each provided interface corresponds to an interaction model. The interaction model is referenced as a node element of the business process model. After the business process model obtains the permissions and processes of the use case model, it uses the entity class of the domain concept model to build a specific business process. After the business process is built, the domain concept model, presentation model, business process model and the interaction model it contains are converted into a formal model without losing any information, and then combined with the required programming language to generate code. The formal model here is the Unified Structure, which can describe the complete information of any UML model.

[0026] Although the model-driven LCDP uses UML use case diagrams, UML class diagrams, UML interaction overview diagrams, and UML sequence diagrams that follow the UML standard, their functions or elements have been expanded to meet the needs of low-code development methods and model-driven development. Among them, the display diagrams, UML sequences, and UML interaction overview diagrams are closely related to the automatic generation of background code. The model expansion is as follows: Representation model: The representation model is a new model created based on the needs of low-code development and is an extension of the UML class diagram. It is based on the UML class diagram and is generated under the guidance of the use case model. The representation model contains two types of elements. One type is the interface node elements such as buttons, forms, and navigation bars that constitute the UI interface, and the other type is the interface node containing the UML class diagram object information. The former is used to build and generate the UI interface of the software system, and the latter is used to connect the UI interface with data objects and functional interfaces.

[0027] Interaction model: Follow the basic semantics of UML sequence diagrams and make the following extensions to map the software system structure and generate code: (11) Add two node elements, service class and Dao layer; (12) Modify the boundary class and control class definitions to make them fixedly described in the corresponding parts of the software system; (13) Add Message parameters so that the UML sequence diagram can contain all the information for automatically generating code. In addition to extending the UML sequence diagram elements, the development platform also provides the function of converting the sequence diagram into a formal mathematical model - unified structure, which is used for code generation and consistency testing.

[0028] Business process model: It follows the basic semantics of the UML interaction overview diagram, and no new elements are added, but specific constraints are added to its use: an interaction overview diagram is divided into three levels by swimlanes, representing user operations, interface operations, and specific activities. The user operation layer describes the operations (activities) performed by the user on the interface, which will involve UI interface elements and be consistent with the representation model; the interface operation layer is the response made by the software system based on user operations (activities), and it will generate interface action scripts; the specific activity layer is the back-end implementation of specific business functions, which is represented as a sequence diagram that references the implementation of specific business. In addition, the interaction overview type also adds some new parameters to its control flow to carry information about data objects and interface requests. This information is consistent with the information contained in the interface node in the representation model, and is one of the indispensable information for automatically generating request interface code.

[0029] Unified structure This section presents a formal model for formally expressing UML models, the Unified Structure. The Unified Structure is based on the team's previous Dependency Structure model, which formalizes the UML model and analyzes and represents the UML model from a structural level.

[0030] Define a unified structure ( ) is a tuple ,in: 101) is a finite set of model elements; 102) For inclusion relation, it is a non-reflexive partial order; 103) For dependency; 104) To restrict model elements; 105) For restrictions on reliance; 106) is the set of model element types that satisfy the following conditions: .

[0031] The concept of model elements here is consistent with that of model elements in UML. It can have different types depending on the viewpoint. Containment is a non-reflexive partial order used to model parent-child relationships. The type and number of dependencies vary from model to model. Both containment and dependency relationships can have additional constraints added as needed.

[0032] Assume that any x,y ME, (i {1,...,n}) is called a dependency relationship, which is read as x depends on y (note that the sequence number of i indicates the specific type of dependency). And means that x is contained in y. Then it can be shortened to , which means that x and y are both contained in z. ,symbol ⊀w means w does not contain v. Tuple It is a grouping structure of model elements, which is used to classify and identify model elements. For example, the model elements in the software development process can be divided into requirements, design, implementation, test, and code types. The corresponding type sets of model elements are requirements set, design set, implementation set, test set, and code set, which can be expressed as

[0033] For any x, y are called the predecessor and successor elements of (x, y). In general, for any The prefix set y and the suffix set y are defined as ,y•=

[0034] If and only if,

[0035] sequence It is called the US relationship chain. Representing a relationship chain The model elements of = RC(US) represents all possible relationship chains of US.

[0036] If and only if sequence It is called the US dependency chain. Representing dependency chains The model elements of = DC(US) represents all possible dependency chains of US. Represents the number of model elements in the dependency chain. = =n.

[0037] Obviously, dependency chains are directional, while relationship chains are undirectional. If x depends on y, it does not follow that y depends on x. If x has a relationship with y, then y also has a relationship with x. Generally speaking, dependency chains are also relationship chains.

[0038] Example 3.1: Figure 2 is a simple interaction overview diagram, which can be represented by a unified structure as ,in: 201) , 202) , 203) , 204) , 205) , 206) , 207) , 208) , 209) , 210) , 211) , 212) , 213) .

[0039] Example 3.2: Figure 3 is a simple sequence diagram, which can be represented by a unified structure as , where (abbreviations are used to reduce space): 301) , 302) , 303) , 304) , 305) , 306) , 307) , 308)

[0040] 309) , 310) , 311) , 312) .

[0041] Automatically generate background code The conversion from model to code has always been an urgent problem that needs to be solved. Automatic code generation from models requires two types of information: deterministic factors and uncertain factors. Among them, deterministic factors are fixed information added during the generation process, and uncertain factors are information extracted from the model and added to the correct position. For example, to automatically generate an html file, you need tag information such as "", "". This is a deterministic factor, which does not need to be obtained from the model during the automatic code generation process. For information such as the name, length, and width of a certain interface element, it is an uncertain factor, and the correct information of the corresponding interface element needs to be obtained from the model before code generation can be performed. Automatic background code generation is divided into interface code generation, background code generation, and automatic generation of related extension code (cloud services, database manipulation statements), such as Fig.11 As shown, the following is a detailed description of the code generation of each part (taking the website system under the Springboot framework as an example).

[0042] 1.1. Interface code generation The software architecture idea adopted by model-driven LCDP is to separate the front-end and back-end. It uses the domain concept model, use case model and presentation model to build the front-end, and the domain concept model, use case model and interaction model to build the back-end. The information of the front-end and back-end is kept consistent through the domain concept model and use case model, and the connection between the front-end and back-end is guaranteed by the business process model.

[0043] At the model level, the business process model connects the presentation model and the interaction model; at the code level, the business process model also generates interface code to respond to the interface request of the front end and call the specific business instructions of the back end. The business process model here is similar to the interaction overview diagram in Example 3.1. Example 3.1 is now used to automatically generate interface code.

[0044] Figure 4 It is a common interface code example for website systems. In order to perform interface functions, it contains three parts: "before request", "during request" and "after request". Among them, "before request" includes interface name and interface parameter information, which are used to provide interface code generated by the presentation model; "during request" information is mainly used for communication, which includes basic information such as communication type, data format, communication address, content format, data object, etc.; "after request" information is used to process communication results, and it has two branches, corresponding to communication success and communication failure, and the corresponding branch will execute the corresponding callback function. In order to generate Figure 4 The actual code of the example first analyzes what uncertain information the interaction overview diagram needs to provide and what information does not need to be extracted from the interaction overview diagram. It is worth noting here that Figure 4 The example belongs to a high-level programming language, which contains an implicit time order, which should be consistent with the control flow direction of the interaction overview diagram.

[0045] The automatic generation of interface code is only related to the information in the second and third lanes of the interaction overview diagram. Figure 5 Describes the correspondence between the interaction overview diagram and the interface information. These correspondences are used to provide uncertain information to automatically generate interface code. Figure 5 In the figure, the corresponding relationships are represented by diamond-shaped arrows from 1 to 11, which are now described one by one: 401) e. The triggering event corresponds to the execution interface, and the name of the added event is consistent with the interface name; 402) Send type node f.@Param Course information corresponding to the interface parameter; 403) Interface parameters are the actual data objects passed in during communication; 404) The external sequence diagram node g.CreateCourses referenced by the interaction overview diagram provides the backend instruction address; 405) Receive type node h.@Return adds the result information corresponding to the callback parameter of successful communication; 406) The Receive type node h.@Return adds the result information corresponding to the callback parameter of communication failure; 407) D2 determines whether the corresponding communication of the node is successful or failed; 408) [res] Branch corresponding communication successful; 409) [err] Branch corresponding communication failed; 410) i displays the callback function body of the returned result corresponding to the successful interface call; 411) j displays an error message corresponding to the callback function body of the failed interface call.

[0046] After clarifying the generated interface framework and corresponding relationships, the unified structure of the interaction overview diagram can be used to automatically generate interface code. Taking Example 3.1 to generate the above type of interface as an example, the specific algorithm flow is as follows: Step 1: Initialize non-deterministic information Model-driven LCDP supports the development of various types of software systems, so it is necessary to initialize non-deterministic information based on user selection. Figure 4 As an example, we initialize it. The result of initialization is a Figure 6 The basic interface function shown has its information missing and is unusable.

[0047] Step 2: Process the interaction overview diagram based on sequence dependencies Using the unified structure represented by Example 3.1, we only consider the node elements associated with the S2.Course management interface lane and the S3.Course subsystem lane and the node elements contained in the S2.Course management interface lane and the S3.Course subsystem lane. . The implicit control flow execution order is (c, e, f, g, h, D2, ([res], i), ([err, j])) according to its elements and types. Traverse the node elements in sequence according to the execution order and perform operations on the nodes: 1. Determine which lane the current node belongs to. If it belongs to S1, end the operation on the current node; 2. Determine whether the current node has a sequence dependency. If so, perform operation 3. If not, end the operation on the current node; 3. Determine which lane the node that the current node depends on belongs to. If it belongs to S1, start interface information processing. If it does not belong to S1, end the operation on the current node.

[0048] Starting from node c, since there is , so node c is included in lane S1, and the operation of node C ends. For node e, , so node e is included in lane S2, and operation 2 is executed; and , node e depends on node c and executes operation 3; and , so node c is included in lane S1, node e is determined to be the starting node of the interface, and interface information processing begins.

[0049] When the start node e is defined, it will have a type attribute, and the value can be "create", "delete", "update" or "query", which means the start node of the activity with the function type of "add", "delete", "modify" or "query". , Lane S2 will pass the data object Course it manages to Node e. Node e will also combine the function type with the data object name to serve as the interface name. The generated interface name here should be "createCourse". It should be noted that the data object here is exactly the same as the corresponding data model in the domain concept model. After the interface name is combined, Node e passes the data object Course to Node e in the form of an object flow. Node f of type; Node f generates a formal parameter code from the data object that allows the interface to receive data and continues to pass the data object information to the external reference node g; Node g belongs to , is the sequence diagram that implements the "CreateCourse" business referenced by the interaction overview diagram and contains the backend instruction address that implements the "CreateCourse" function; the call result of node g is returned to node h, which can contain both the call result of failed communication and the call result of successful communication; according to the return result of node h, the branch node D2 is judged. If the communication is successful, the node i under the [res] branch is executed to display the return result (node ​​i stores the callback function information under successful communication); if the communication fails or an error occurs, the node j under the [res] branch is executed to display the error information (node ​​i stores the callback function information under failed communication).

[0050] Step 3: Generate interface code based on the corresponding relationship After completing operations a and b, all information about interface code generation has been prepared. Figure 5 The corresponding relationship can be filled in, such as Figure 7 As shown, the specific processing flow is as follows: 501. Generate deterministic information based on the initialization interface; 502. Generate an interface name createCourse according to the information of the starting node e; 503. Will The formal parameters generated by the node f of the type (the formal parameters generated by different types of interfaces should be different, and the interface formal parameters here are Data) are written into the interface; 504. Write the interface parameter Data into the communication request; 505. Will The backend instruction address information contained in the node g of type is written into the communication request; 506. Will The return result of the node h of type is written into the callback function in the form of formal parameters (the formal parameters generated by different types of interfaces should be different, and the interface formal parameters here are data); 507. Perform branch judgment, use [res] and the subsequent node i to generate a callback function for successful communication, and use [err] and the subsequent node j to generate a callback function for failed communication.

[0051] 1.2. Background code generation The background code of the model-driven LCDP is automatically generated based on the extended UML sequence diagram. It converts the sequence diagram that implements the specific background process into a unified structure after normalization and generates programming code through the code generator. Different from the basic semantics of the UML sequence diagram, it has: ① Boundary class: transmits and receives routing information, binds to the functional interface, and requests the control class to complete specific business; ② Control class: The control class is associated with the boundary class and the service class. After accepting the request of the boundary class, it calls the encapsulated service in the service class to complete the specified function; ③ Service class: The service class is associated with the control class and the Dao layer. The Dao layer here refers to a hierarchical structure that can directly communicate with the database, rather than a structure under a specific framework. The service class executes complex processes according to demand and completes the interaction with the database through the Dao layer; ④ Dao layer: stores database operation information, creates database connections, receives service class call instructions, and completes interactive operations with the database; ⑤ Object: Objects exist in the boundary class, control class, service class, and Dao layer, and can be created, called, modified, and deleted by them. It corresponds to the instantiated variable in the programming code and is an indispensable part of completing specific business functions;⑥ Lifeline: The beginning of the lifeline is when an element is created, and the end of the lifeline is when the element is destroyed or no longer functions. The lifelines in the sequence diagram are from top to bottom and from left to right, clearly reflecting the progress of the business process;⑦ Message: Messages are divided into multiple types such as synchronous, asynchronous, and return. Information transmission between elements must be carried out through messages;⑧ Fragment: A time fragment usually contains conditions, a lifeline, and multiple messages, which are used to implement the logical structure of selection, judgment, and loop;⑨ Condition: Conditions are used for logical selection in time fragments.

[0052] The converted unified structure must contain all the information of the interaction model, including the information of the elements themselves and the information between the elements, in order to be converted into specific programming language codes by the code generator without changing the meaning of the interaction model. Figure 3 Taking the new course sequence diagram as an example, the background code generation process is as follows Figure 8 shown.

[0053] Step 11: Message sequence sorting The message of the sequence diagram is used to describe the interaction between objects. It represents the information transmission from the sender (object) to the receiver (object). The behavior represented by the sequence diagram is the business process represented by the sequence of all messages it contains. It should be noted that the order of messages cannot be changed. The same message represents completely different business processes in different execution orders. Therefore, it is necessary to ensure that the unified structure contains the same business processes as the sequence. Figure 1 The consistent relationship sequence is the key to generating code from sequence diagrams.

[0054] In the unified structure of Example 3.2, we have , according to the partial order, sequence dependency and message type elements, we can get the message sequence consistent with the business process represented by the sequence diagram. The order of messages in the sequence diagram is determined by time. The smaller the time value, the earlier the message execution sequence. You can compare the time values ​​of two elements, for example The elements (m2,m1) and (m3,m2) in , mean that the execution of m2 depends on the execution of m1, and the execution of m3 depends on the execution of m2. Therefore, the time value of m2 is greater than the time value of m1, and the time value of m3 is greater than the time value of m2. There is a message sequence (m1,m2,m3). Similarly, the complete message sequence MessageSequence={m1,m2,m3,m4,m5,m6} of Example 3.2 can be obtained.

[0055] It should be added that Figure 3 The newly created course sequence diagram does not contain time fragments, and cannot represent selection and looping to control the message sequence. There should be a specific way to handle the sequence diagram containing time fragments when sorting the message sequence. Figure 7 Provide explanation. Figure 7 The unified structure represented by Follow the above steps Figure 3 The way to Fig. 9 Sorting, we get the message sequence (m1, m2, m3, m4, m5, m6, m7). And because the fragment contains the message, and the execution of the message is controlled according to the Guard. There are (reslutcontact, m7), (m8, contact1!==null), (m9, contact1==null), in There are (m8, reslutcontact), (m9, reslutcontact), (contact1!==null, reslutcontact), (contact1==null, reslutcontact), the execution of the time segment reslutcontact depends on the execution of m7, the execution of m8 depends on the condition contact1!==null in Guard, and the execution of m9 depends on the condition contact1==null in Guard. m8, m9, contact1!==null, and contact1==null are all included in reslutcontact. Therefore, there is a message sequence (m7, (reslutcontact, (contact1!==null, m8) (contact1==null, m9))), which means that after m7 is executed, the reslutcontact time segment is executed and judged. When contact1!==null is true, m8 is executed, and when contact1==null is true, m9 is executed. After the above operations, we get the message sequence MessageSequence={m1,m2,m3,m4,m5,m6,m7,(reslutcontact,(contact1!==null,m8)(contact1==null,m9))}.

[0056] Step 12: Construct the partial order relationship between the message sequence from and to objects For any message, there is a sender (from) and a receiver (to). This is the basic semantics of the message element. Each sequence diagram message that conforms to the basic semantics will have information about the sender and receiver. For example, m1={router,courseController, CreateCourse(Course course):Integer}, its sender is the object router, and the receiver is the object courseController.

[0057] According to the order of the message sequence MessageSequence, the objects of the control class, service class, Dao layer and other types of elements are constructed in a partial order relationship. Taking the courseCotoller object as an example, the message sequence MessageSequence is traversed. When the sender or receiver of the element in the message sequence is the courseCotoller object, a partial order relationship is constructed. In particular, when the element in the message sequence is a Fragment, the sub-messages it contains should be judged. If the sender or receiver of the sub-message is the courseCotoller object, a partial order relationship between the Fragment and the courseCotoller object is constructed. The final partial order relationship of the courseCotoller object ={(m1,courseCotoller),(m2,courseCotoller)(m5,courseCotoller)(m6,courseCotoller)}.

[0058] Step 13: Global Scan When automatically generating background code for sequence diagrams, it is often necessary to generate multiple sequence diagrams. These sequence diagrams may be related, such as a course creation sequence diagram and a course deletion sequence diagram, and their Controller objects are both courseController. In order to prevent conflicts during generation or errors in the generated code, a scan operation is required first. Scan the three categories and create three arrays of Controller, Service, and Dao to store object information. Traverse the Controller, Service, and Dao objects in the sequence diagram to determine whether the object exists in the corresponding array. If not, determine that it appears for the first time, store its object information in the array, and create a file for subsequent code generation; if the object information already exists, determine that it appears again, find the created file based on the object information, and the subsequent generated code will be appended to the file.

[0059] Step 14: Reference and object generation The operations in this section are slightly different from those in the next section because of the framework and language selected by the user. Here we use the JAVA high-level programming language and the SpringBoot framework to illustrate. "Reference generation" generates the file reference code required for the actual execution of the file. , it will also be different. As shown in the courseContoller reference code, the courseContoller object needs to interact with the boundary class object courseRouter, so it needs to reference the files RequestBody and ResponseBody; the courseContoller object interacts with the courseService object in the message sequence {m2, m5}, so it needs to reference the file CourseService. As shown in the CourseService reference code, the courseSevice object does not need to interact with the courseRouter, so no code is generated to reference the files RequestBody or ResponseBody; the courseSevice object and the courseMapper object have a message sequence {m3, m4}, so it needs to reference the file CourseMapper.

[0060] CourseContoller reference code:

[0061] CourseService reference code:

[0062] Object generation includes "self-object generation" and "reference object generation". You can fill in the object information according to the language and framework. The code for generating the courseContoller object in Example 3.2 is as follows, where courseContoller is the self-object and courseService is the reference object.

[0063] The courseController object generates code:

[0064] Step 15: Statement generation After the above steps, the sequence diagram has been generated according to and many files distinguished by object information, e.g. Figure 3 When you create a new course sequence diagram, three JAVA files will be generated: CourseController, CourseService, and CourseController. These files have already generated all the codes that are not related to the specific business. On this basis, "Statement Generation" finally uses the messages of the sequence diagram to generate the implementation background code.

[0065] In the previous article, we sorted the message sequence of the sequence diagram and bound the messages associated with each object. For example, the partial order relation generated by the courseCotoller object = {(m1,courseCotoller), (m2,courseCotoller)(m5,courseCotoller)(m6,courseCotoller)}, and bound {m1,m2,m5,m6} to the courseCotoller object. Similarly, {m2,m3,m4,m5} is bound to the CourseService object; {m3,m4} is bound to the CourseMapper object.

[0066] Traverse all objects in the sequence diagram in sequence. Taking the courseCotoller object as an example, there are Therefore, the courseCotoller object depends on the CourseCotoller class. All messages of the courseCotoller object can be found in the CourseCotoller class. The specific background code generated by the courseCotoller object should be written into the CourseCotoller file.

[0067] When traversing all objects in the sequence diagram, for each object, all messages bound to it must be traversed again to determine the message type. Then, different types of messages are generated into corresponding code statements according to the conversion rules. Message types and conversion rules vary in different frameworks and languages. The message types in the above example are as follows: ⑴The request message sent by the boundary class to the control class; ⑵The return message sent by the control class to the boundary class; ⑶ Request message sent by the control class to the service class; ⑷The return message sent by the service class to the boundary class; ⑸Control class creation object message; (6) The control class initiates a request message to itself; ⑺The control class sends a request message to the object; ⑻The return message sent by the object to the Controller; ⑼The request message sent by the service class to the Dao layer; ⑽The return message sent by the Dao layer to the service class; ⑾Time fragment (Fragment).

[0068] Each message in the sequence diagram has , , , , There are five types of fields (field information can be empty, but must exist. The unified structure of Example 3.2 is not shown due to space constraints), which respectively represent the method name of the message, the specified object name of the message return result, the actual parameters of the message, the formal parameters of the message, and the return result type of the message. The corresponding conversion rules are as follows: ⑴ For boundary objects, no operation; for control objects, define a method or function with a return value type of message Field, function name (method name) is the message field, the parameter is the message Fields; ⑵For boundary objects, no operation; for control objects, return message Fields; ⑶For control class, judge Whether the field is empty, if it is empty, directly generate a call Method statement; if it is not empty, then judge Whether the statement is empty. Empty, directly generate calls method statement; if Not empty, query whether to generate The object for the field. If the object does not exist, define one The object of the field type and assigned The result of calling the field method and skipping the conversion of the next message; if the object exists, assign the object to The result of calling the method and skip the conversion of the next message; for the service class, define a method or function with the return value type of the message Field, function name (method name) is the message field, the parameter is the message Fields; ⑷For boundary classes, no operation; for service classes, return message Fields; ⑸Create a The object of the field; ⑹Based on Field generation method call statement; ⑺Generate the object Field method call statement; ⑻Generate Message The statement that the field receives the result of the object method call; ⑼For service category, determine Whether the field is empty, if it is empty, directly generate a call Method statement; if it is not empty, then judge Whether the statement is empty. Empty, directly generate calls method statement; if Not empty, query whether to generate The object for the field. If the object does not exist, define one The object of the field type and assigned The result of calling the field method and skipping the conversion of the next message; if the object exists, assign the object to The result of calling the method and skip the conversion of the next message; for the Dao layer, define a method or function whose return value type is the message Field, function name (method name) is the message field, the parameter is the message Fields; ⑽For service classes, no operation; for boundary classes, return the message Fields; ⑾According to Determine the type of time segment (selection, loop). If it is a selection type, first The field generates a conditional statement for each selection branch, and then Sequence dependency, determine which branch the sub-message contained in the time segment belongs to, determine the type of all sub-messages and execute the corresponding conversion rules. If the sub-message contains a time segment (Fragment), recursive call; if it is a cyclic type, according to The field generates a loop end conditional statement, and then executes the corresponding conversion rules after determining the type of all sub-messages. If the sub-message contains a time fragment, it is called recursively; The type sequence of the message sequence {m1,m2,m5,m6} bound to the courseCotoller object is {(1),(3),(4),(2)}. According to the type sequence, the above conversion operations are performed on the messages m1, m2, m5 and m6 of the sequence diagram respectively, and the generated code is as follows.

[0069] Create a new course sequence diagram code:

[0070] Consistency Guarantee In order to generate a highly reliable software system, it is necessary to ensure the consistency between models and between models and code. Model-driven LCDP uses the requirement model to automatically generate the design model throughout the software development process, and uses a series of mechanisms to ensure consistency between models. Maintaining consistency between models is a prerequisite for generating correct code. On this basis, this section uses formal methods to illustrate the consistency relationship between models and code. To use formal methods to verify the consistency of code and model, simulation relationships and combination relationships are used. Their definitions are as follows: Definition 5.1 Order and are two unified structures. If there exists a simulation rule that makes the relationship Satisfy all ,in are model elements of the same type, and the following conditions hold: ,in are model elements of the same type, ,in are model elements of the same type, and is a set of the same dependent type, then R is and The simulated relationship between them.

[0071] if and There is a simulation relationship between Can simulate , expressed as .

[0072] Definition 5.2: and are two unified structures. If is a set of non-reflexive partial order relations, then and The combination of is defined as ,in , , , and , , then it is called and are composable.

[0073] Theorem 5.1 Let , , , There are four unified structures. and ,but .

[0074] Below Figure 3 Take the background code automatically generated by the newly created course sequence diagram as an example to illustrate the consistency guarantee between the model and the code. First, the background code generated by the Controller, Service, and Mapper levels are given respectively: CourseController.java CourseService.java CourseMapper.java

[0075] In order to formalize the automatically generated background code of modeling, it is also necessary to define it according to factors such as granularity and inclusion relationship. The code granularity is divided into four levels from small to large: "statement", "function", "class", and "file". Among them, "statement" and "function" correspond to the message (Meaasge) in the sequence diagram, and both have , , , , There are five types of attribute fields. Taking functions as an example, these attribute fields represent (2) the method name of the function, the actual parameters of the function, the formal parameters of the function, the name of the function return value object, and the type of the function return value. In addition, each function has from - the object that calls the function, to - the object that declares the function, and the name of the function. If function f1 calls function f2, then the execution of f2 depends on the execution of f1, which is recorded as ={(f2,f1)}, that is, the time value of f2 is greater than the time value of f1. The "class" granularity corresponds to the object instance in the sequence diagram, which is the sender or receiver of the message and the instantiation of the design class. The "file" granularity corresponds to the design class in the sequence diagram (CourseController class, CourseService class, CourseMapper class), which contains the functions used by all object instances of a certain entity class.

[0076] Figure 3 The parsing class diagram is as follows Fig.10 As shown, Course is an entity class, CourseRouter is a boundary class, CourseController, CourseService and CourseMapper are control classes, and they are related to each other. The following formalizes CourseController.java, CourseService.java, CourseMapper.java and the course entity design class diagram: (1)US1=

[0077] , ME={CS,cS,Rt,rt,CC,cC,f1,f2} , {(cS,cC),(f1,cC),(f2,cC),(f1,courseController),(f2,courseController),(res1,f1)}, ={(cC,CC),(cS,CS),(rt,Rt)}, ={(f2,f1)}, {rt,cC,cS}, {Rt,CC,CS}, ={f1,f2}, ={(f1,createCourese),(f2,createCourse)}, , , , , ={(cS,f2)}, {res1} res1={(courseController,createCouse),res1}; (2)US2=

[0078] , ME={CS,cS,CM,cM,f3,f4} , {(cM,cS),(f3,cS),(f4,cS),(f3,courseService),(f4,courseService),(res2,f3)}, ={(cS,CS),(cM,CM)}, ={(f4,f3)}, {cM,cS}, {CM, CS}, ={f3, f4}, ={(f3, createCourse), (f4, createCourse)}, , , , , ={(cM, F3)}, {res2}. (3)US3 =

[0079] ,ME = {bM, BM, CM, cM, f5}, {(f5, courseMapper), (res3, f5)}, {(cM, CM), ={(CM, BM)}, {cM}, {CM}, ={f5}, ={(f5, createCourse)}, , {res3}. (4)US4 = , ME = {Course, CourseRouter, CourseController, CourseService, CourseMapper},

[0080] , , , , , , . The following is based on Figure 3The consistency between the code and the model is explained by using the formal description of US and the course entity design class diagram US4, CourseContoller file US1, CourseService file US2, and CourseMapper file U3.

[0081] Definition 5.1 defines the simulation relation of unified structures, that is, for two unified structures US' and US", if 1. any element of a partial order relation in US' has a corresponding element in US", and 2. any element of a dependency relation in US' has a corresponding element in US", then US' simulates US", denoted as If US' simulates US", then the relations and some elements it contains are consistent. Therefore, to prove whether two unified structures are consistent, we only need to first determine whether they have a simulation relationship, and then test whether the elements of other types correspond on this basis. Also, due to Definition 5.2 and Theorem 5.1, if we want to test the consistency between the model and the code, we can test the consistency between the combination of each file and the combination of the model. The consistency between the interactive model and the code of the added course is Is it true?

[0082] For US1, US2, and US3, they can obviously be combined. have {(cS,cC),(f1,cC),(f2,cC),(f1,courseController),(f2,courseController),(res1,f1),(cM,cS),(f3,cS),(f4,cS),(f3,courseService),(f4,courseService),(res2,f3),(f5,courseMapper)}, {(cC,CC),(cS,CS),(rt,Rt)(cS,CS),(cM,CM)}, {(f2,f1),(f4,f3)}. For US and US4, US4 , , There are elements of the same type as US, so they can obviously be combined. Although the elements are not represented by symbols in the US, the US and This information is fully included, so US and US4 can also be combined.

[0083] Because the course entity design class diagram contains four methods: add, delete, modify, and query, and the course sequence diagram only implements its add method, the US4 Only createCourse is considered. have {(createCourse,CourseController),(createCourse,CourseService),(createCourse,CourseMapper)}, {(m2,m1),(m3,m2),(m4,m3),(m5,m4),(m6,m5)}.

[0084] According to the definition of simulation, of , If The same subset of defined symbols, then . of There are only three elements, indicating that the CourseController, CourseService, and CourseMapper classes each contain a createCourse method, which is reflected in the sequence diagram as follows Elements m1, m2, m3. According to the function method, the automatic generation strategy generates functions f1, f3, f5 from messages m1, m2, m3 in the sequence diagram. have {(f1,courseController),(f3,courseService),(f5,courseMapper)}, so '⊆ ", , where a and c are Message elements, and b and d are Function elements.

[0085] First, the above The {(f2,f1),(f4,f3)} representation indicates that, for example, functions f2 and f3: f2 and f3 are both automatically generated by message m2, f2 indicates the call information, and f3 indicates the function definition information. Then the elements (f2,f1),(f4,f3) are equal to (m2,m1),(m3,m2). However of The number of elements is obviously greater than of The number of elements, i.e. It can't be This is due to of There is no complete formal modeling. have , which indicates the return result of a function or a return statement, corresponds to messages m4, m5, and m6 in the sequence diagram. Because there are (res1, f1)(res2, f3)(res3, f5), the execution of res1, res2, and res3 depends on the execution of f1, f3, and f5. According to the transitive nature of dependencies, we have ,so of , which satisfies the second condition of the simulation.

[0086] In summary, , The automatically generated code has a simulation relationship with the sequence diagram and the design class diagram, and the two are consistent.

[0087] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments can still be used to modify the technical solutions or to perform equivalent replacements on some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for automatically generating background code for a low-code development platform, characterized in that: include: Use the business process model to automatically generate interface code and automatically generate interface code for the background code; Use the interactive model to automatically generate background function codes and automatically generate background function codes for background codes; According to the dependency relationship, the related extension code of the background code is automatically generated, and the consistency between the automatically generated background code and the model is detected using formal methods.

2. The method according to claim 1, characterized in that The business process model is used to automatically generate interface codes. The interface codes for automatically generating background codes include: Initialize non-deterministic information according to user selection and obtain basic interface functions; Processing interaction overview graphs based on sequence dependencies; According to the corresponding relationship between the interaction overview diagram and the interface information, the interface code of the background code is automatically generated.

3. The method according to claim 2, characterized in that According to the corresponding relationship between the interaction overview diagram and the interface information, the interface code of the background code is automatically generated, including: Generate deterministic information based on the initialization interface; Generate the interface name createCourse according to the information of the starting node e in the interaction overview diagram; In the interaction overview diagram The formal parameters generated by the node f of type are written into the interface; Write the interface parameter Data in the interaction overview diagram into the communication request; In the interaction overview diagram The backend instruction address information contained in the node g of type is written into the communication request; In the interaction overview diagram The return result of the node h of type is written into the callback function as a formal parameter; Perform branch judgment, use the node i following [res] in the interaction overview diagram to generate a callback function for successful communication, and use the node j following [err] in the interaction overview diagram to generate a callback function for failed communication.

4. The method according to claim 1, characterized in that The interactive model is used to automatically generate the background function code. The background function code automatically generated includes: Message sequence sorting is used to ensure that the code statements are consistent with the model process; The partial order relationship between messages and objects is constructed to ensure that the code is generated in the correct file; Global scanning to avoid duplication of generated files and code; Reference generation and object generation, used to handle file dependencies based on model object dependencies; Statement generation, used for each message acting on an object to generate code statements; Code and model consistency detection is used for formal method detection to ensure code correctness.

5. The method according to claim 4, characterized in that: The construction of partial order relationship between messages and objects includes: According to the order of the message sequence, the sender object and the receiver object of the type element of the control class, service class and Dao layer are constructed in a partial order relationship.

6. The method according to claim 5, characterized in that Global scan includes: According to the unified structure Scan the three categories and create three arrays of Controller, Service and Dao to store object information; Traverse the Controller, Service, and Dao objects in the sequence diagram to determine whether the object exists in the corresponding array; If it does not exist, store its object information in an array and create a file for subsequent code generation; If the object information already exists, the created file is found based on the object information, and the subsequently generated code will be appended to the file.

7. The method according to claim 6, characterized in that Statement generation includes: Traverse all objects in the sequence diagram, traverse all messages bound to each object, and determine the message type; Generate different types of messages into corresponding code statements according to the conversion rules.

8. The method according to claim 7, characterized in that Each message in the sequence diagram has five types of fields, representing the method name of the message. 、The specified object name of the message return result , the actual parameters of the message , the formal parameters of the message And the return result type of the message .

Images