Plug-in dependency analysis and architecture extension method and system for low-code platform

Abstract

The application provides a plug-in dependency analysis and architecture extension method and system for a low-code platform, relates to the technical field of low-code platforms, and comprises the following steps: converting plug-in source code into an abstract syntax tree through static code analysis, extracting an interface contract and verifying compatibility; eliminating circular dependencies through dependency graph construction and topological sorting, determining a compatible version to generate a dependency relationship chain; calculating a minimum impact surface based on a plug-in call index table, constructing a function extension registration center and an interface directory, and realizing loose coupling calls between plug-ins. The application solves the plug-in dependency conflict problem and improves the platform extensibility and stability.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of low-code platform, and particularly relates to a plug-in dependency analysis and architecture extension method and system for a low-code platform. BACKGROUND

[0002] With the deepening of enterprise digital transformation, low-code platforms have received widespread attention due to their efficient application development capabilities. Low-code platforms enable non-professional developers to participate in the software development process through visual development tools and pre-built components. In the low-code platform ecosystem, the plug-in system is a key mechanism for functional extension and customization, allowing the platform to flexibly integrate third-party functional modules to meet the needs of different business scenarios.

[0003] The traditional plug-in dependency management of low-code platforms lacks automated verification mechanisms, making it difficult to effectively detect interface compatibility during plug-in installation or updates, resulting in unexpected errors at runtime. Developers need to conduct extensive manual testing to ensure normal interaction between plug-ins, increasing development and maintenance costs. Existing plug-in systems generally lack effective detection methods for circular dependencies and deadlocks between plug-ins. When the size of plug-ins grows, complex call relationships can cause the system to enter a deadlock state, and such problems are often difficult to detect during the development stage and only exposed at runtime under specific conditions, posing a serious threat to system stability. The current plug-in architecture of low-code platforms generally uses fixed extension point design, lacking dynamic adaptability. This design cannot be optimized and adjusted according to actual business needs and plug-in call relationships, resulting in a rigid system architecture that is difficult to adapt to rapidly changing business needs. When new function types need to be added or existing functions need to be adjusted, the platform core code often needs to be modified, increasing the complexity of platform upgrades and maintenance. SUMMARY

[0004] The embodiments of the present application provide a plug-in dependency analysis and architecture extension method and system for a low-code platform, which can solve the problems in the prior art.

[0005] In a first aspect of the embodiments of the present application, a plug-in dependency analysis and architecture extension method for a low-code platform is provided, including:

[0006] Obtaining a plug-in from a plug-in repository of the low-code platform;

[0007] The plugin source code is converted into an abstract syntax tree through static code analysis, the interface contract of the plugin is extracted from the abstract syntax tree, and interface compatibility is verified through type deduction, deadlock detection is performed by analyzing the interaction behavior between the plugins, the interface compatibility and the deadlock detection result are converted into dependency constraint conditions, the plugin repository is recursively traversed, the plugins meeting the dependency constraint conditions are screened, and the dependency declaration and version identification of the plugins are extracted, the directed dependency graph is constructed according to the dependency declaration, the circular dependency is eliminated through topological sorting in the directed dependency graph, the compatible version of each plugin is determined based on the version identification by using depth-first traversal, and the plugin dependency relationship chain is generated based on the directed dependency graph and the compatible version;

[0008] The calling relationship and influence range between the plugins are recorded during the plugin runtime, the plugin calling index table is obtained, the minimum influence surface is calculated based on the plugin calling index table, the functional extension registration center is constructed based on the minimum influence surface and the plugin dependency relationship chain, the plugin extension point interface is registered to the functional extension registration center to form an interface directory and perform functional classification, the loose coupling calling between the plugins of the same functional type is implemented based on the interface directory, and the dynamic extension of the plugin architecture is implemented.

[0009] The plugin source code is converted into an abstract syntax tree through static code analysis, the interface contract of the plugin is extracted from the abstract syntax tree, and interface compatibility is verified through type deduction, deadlock detection is performed by analyzing the interaction behavior between the plugins, including:

[0010] The plugin source code is subjected to lexical analysis to obtain a morpheme sequence, syntax analysis is performed based on the morpheme sequence, the recognized declaration, expression and control flow are respectively constructed into declaration nodes, expression nodes and control flow nodes, and an abstract syntax tree is assembled and constructed, and the interface contract of the plugin is obtained based on the declaration nodes of the abstract syntax tree;

[0011] Based on the interface contract, a type constraint set is constructed through a type deduction algorithm, a recursive unification operation is performed on the type constraint set to obtain a type unification result, type deduction is performed on the interface contract based on the type unification result, and structural compatibility results are obtained by judging the covariance relationship of return types in the interface contract; the calling relationship of the interface contract is analyzed based on the expression nodes to obtain preconditions, the execution path of the interface contract is analyzed based on the control flow nodes to obtain postconditions, and the structural compatibility results, the preconditions and the postconditions are combined to generate an interface compatibility verification result;

[0012] Based on the resource acquisition sequence and the resource release sequence of the control flow node extraction plug-in, a resource dependency graph is constructed by combining the resource acquisition sequence and the resource release sequence, strong connected components are detected in the resource dependency graph, whether there is a deadlock between plug-ins is judged based on the strong connected components, and a deadlock detection result is generated.

[0013] Based on the interface contract, a type constraint set is constructed by a type inference algorithm, a type unification result is obtained by performing a recursive unification operation on the type constraint set, type inference is performed on the interface contract based on the type unification result, and a structural compatibility result is obtained by judging the covariance relationship of the return type in the interface contract, including:

[0014] The formal parameters and return values in the interface contract are annotated with type variables, and a type environment is constructed; based on the type environment, the expressions in the interface contract are traversed, the variable reference expressions, function application expressions and state type expressions in the expressions are constructed into variable reference constraints, function application constraints and polymorphic instance constraints respectively, and the variable reference constraints, the function application constraints and the polymorphic instance constraints are combined to form a type constraint set;

[0015] Perform a recursive unification operation on the type constraint set, decompose the type constraints in the type constraint set into atomic constraints, detect the circular reference relationship in the atomic constraints to construct a type substitution mapping, based on the type substitution mapping, perform type substitution iteratively through substitution combination operation until no further substitution is possible or a type conflict is found, and generate a type unification result;

[0016] Apply the type unification result to the type variables of the interface contract, perform type generalization on the type variables that are not constrained to obtain polymorphic type variables, add the polymorphic type variables to the type environment to obtain an updated type environment, analyze the subtyping relationship of the return type in the interface contract based on the type unification result and the updated type environment, judge the covariance property according to the subtyping relationship, and verify the structural compatibility of the interface based on the covariance property.

[0017] A directed dependency graph is constructed according to the dependency declaration, circular dependencies are eliminated by topological sorting in the directed dependency graph, compatible versions of each plug-in are determined based on the version identifier using depth-first traversal, and a plug-in dependency relationship chain is generated based on the directed dependency graph and the compatible versions, including:

[0018] Based on the dependency declaration, dependencies between plugins are extracted, vertices are mapped to plugins, and directed edges are mapped to the dependencies, obtaining a directed dependency graph representing the plugin dependencies, strong connected components in the directed dependency graph are identified, based on the strong connected components, the directed dependency graph is decomposed into a set of strongly connected subgraphs, and topological sorting is performed on each strongly connected subgraph to eliminate circular dependencies, generating an acyclic dependency sequence;

[0019] Based on the acyclic dependency sequence, a depth-first traversal strategy is used to traverse the directed dependency graph from nodes with no outgoing edges, and in the traversal process, the version compatibility of adjacent plugins is calculated based on the version identifier, which includes the major version number and the minor version number, and for each plugin, a compatible version set containing all compatible versions is generated, the major version number of the compatible version is the same as that of the corresponding plugin, and the minor version number is greater than or equal to that of the corresponding plugin;

[0020] Based on the acyclic dependency sequence, a depth-first traversal strategy is used to traverse the directed dependency graph from nodes with no outgoing edges, and in the traversal process, the version compatibility of adjacent plugins is calculated based on the version identifier, which includes the major version number and the minor version number, and for each plugin, a compatible version set containing all compatible versions is generated, the major version number of the compatible version is the same as that of the corresponding plugin, and the minor version number is greater than or equal to that of the corresponding plugin;

[0021] In the plugin runtime, the calling relationship and the impact range between plugins are recorded to obtain a plugin calling index table, and based on the plugin calling index table, the minimum impact surface is calculated, and based on the minimum impact surface and the plugin dependency relationship chain, a functional extension registration center is constructed, including:

[0022] By using dynamic proxy and bytecode enhancement technology, the method call between plugins is tracked to obtain the calling event and the functional impact range of the call, the calling event is sorted according to time sequence to generate a calling event sequence, and based on the calling event sequence and the functional impact range, a plugin calling index table is constructed;

[0023] From the plugin calling index table, the calling path information between plugins is extracted, for any two plugins, when there is a calling path from the source plugin to the target plugin and the functional set of the two plugins has an intersection, the target plugin is added to the initial impact surface of the source plugin, the initial impact surface is iteratively processed using a forward slicing analysis method, redundant impact items are identified and removed, and the minimum impact surface is obtained;

[0024] From the minimum impact surface, the function identifier and the corresponding implementation plugin set are extracted, based on the function identifier and the implementation plugin set, a function registry is constructed, the compatible version set is extracted from the plugin dependency relationship chain, the compatible version set is mapped into the function registry to generate version constraint information and added to the corresponding function item, and a functional extension registration center is constructed.

[0025] registering the plug-in extension point interface to the function extension registry center forms an interface directory and performs function classification, and based on the interface directory, loose coupling calling between plug-ins of the same function type is realized, comprising:

[0026] submitting the plug-in extension point interface to the function extension registry center for registration, generating an interface directory, obtaining a registration identifier of the plug-in extension point interface and adding it to the interface directory, analyzing the annotation information of the plug-in extension point interface through a reflection mechanism and calculating a function classification similarity, and based on the function classification similarity, classifying the plug-in extension point interface to form a function classification tree;

[0027] based on the function classification tree, the interface directory is hierarchically organized, a multi-level index directory node is constructed, a compatible version set is added to the multi-level index directory node, and version constraint information is generated based on the multi-level index directory node and the registration identifier;

[0028] obtaining the function descriptor of the calling plug-in, matching the target function type in the interface directory according to the function descriptor, obtaining the implementation plug-in set corresponding to the target function type, and filtering the implementation plug-in set based on the version constraint information;

[0029] calculating the plug-in adaptation degree of the filtered implementation plug-in, selecting the implementation plug-in with the highest plug-in adaptation degree, realizing the runtime binding of the calling plug-in and the implementation plug-in by using dynamic proxy technology, and completing the loose coupling calling between plug-ins.

[0030] In a second aspect of the embodiment of the application, a plug-in dependency analysis and architecture extension system for a low-code platform is provided, comprising:

[0031] The first unit is configured to obtain a plug-in from a plug-in warehouse of the low-code platform.

[0032] The second unit is configured to convert the plug-in source code into an abstract syntax tree through static code analysis, extract the interface contract of the plug-in from the abstract syntax tree, and verify the interface compatibility through type inference, perform deadlock detection by analyzing the interaction behavior between plug-ins, convert the interface compatibility and deadlock detection results into dependency constraint conditions, recursively traverse the plug-in warehouse, filter plug-ins that meet the dependency constraint conditions and extract the dependency declaration and version identifier of the plug-in, construct a directed dependency graph according to the dependency declaration, eliminate circular dependencies by topological sorting in the directed dependency graph, determine the compatible version of each plug-in based on the version identifier using depth-first traversal, and generate a plug-in dependency relationship chain based on the directed dependency graph and the compatible version.

[0033] The third unit is configured to record the calling relationship and the influence range among the plug-ins during the running of the plug-ins, obtain a plug-in calling index table, calculate a minimum influence surface based on the plug-in calling index table, construct a function extension registration center based on the minimum influence surface and the plug-in dependency relationship chain, register a plug-in extension point interface to the function extension registration center to form an interface directory and perform function classification, realize loose coupling calling among plug-ins of the same function type based on the interface directory, and realize dynamic extension of the plug-in architecture.

[0034] A third aspect of the embodiments of the present application,

[0035] An electronic device is provided, comprising:

[0036] A processor;

[0037] A memory for storing processor-executable instructions;

[0038] The processor is configured to invoke the instructions stored in the memory to execute the method described above.

[0039] A fourth aspect of the embodiments of the present application,

[0040] A computer-readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method described above.

[0041] The beneficial effects of the present application are as follows:

[0042] The plug-in interface contract is extracted and compatibility is verified through static code analysis, dependency constraint conditions are generated in combination with deadlock detection, a directed dependency graph is constructed and circular dependency is eliminated through topological sorting, accurate analysis and conflict detection of plug-in dependency relationship are realized, and the version compatibility problem and the circular dependency problem in the plug-in system are effectively solved.

[0043] The plug-in calling index table is constructed based on the runtime-recorded plug-in calling relationship, the minimum influence surface is calculated, the influence range of plug-in changes can be accurately evaluated, system instability factors are reduced, and the reliability and maintainability of the low-code platform are improved.

[0044] By constructing the function extension registration center and the interface directory, the loose coupling calling mechanism among plug-ins of the same function type is realized, the plug-in architecture can be dynamically extended, the extensibility and adaptability of the low-code platform are improved, and the customized needs in different business scenarios are met. BRIEF DESCRIPTION OF DRAWINGS

[0045] Figure 1 A flowchart of the plug-in dependency analysis and architecture extension method for the low-code platform according to the embodiments of the present application is shown;

[0046] Figure 2Generate a flowchart for the plug-in dependency chain. DETAILED DESCRIPTION

[0047] To make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work are within the protection scope of the present application.

[0048] The technical solutions of the present application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and some embodiments may not be described again for the same or similar concepts or processes.

[0049] Figure 1 The flowchart of the plug-in dependency analysis and architecture extension method for the low-code platform-oriented embodiments of the present application is shown in FIG. 1. Figure 1 The method comprises the following steps.

[0050] Obtaining a plug-in from a plug-in warehouse of a low-code platform;

[0051] Converting the plug-in source code into an abstract syntax tree through static code analysis, extracting the interface contract of the plug-in from the abstract syntax tree and verifying the interface compatibility through type deduction, performing deadlock detection by analyzing the interaction behavior between the plug-ins, converting the interface compatibility and the deadlock detection result into a dependency constraint condition, recursively traversing the plug-in warehouse, screening the plug-ins satisfying the dependency constraint condition and extracting the dependency declaration and version identification of the plug-ins, constructing a directed dependency graph according to the dependency declaration, eliminating the circular dependency through topological sorting in the directed dependency graph, determining the compatible version of each plug-in based on the version identification through depth-first traversal, and generating a plug-in dependency relationship chain based on the directed dependency graph and the compatible version;

[0052] Recording the calling relationship and the influence range between the plug-ins during the plug-in runtime to obtain a plug-in calling index table, calculating the minimum influence surface based on the plug-in calling index table, constructing a function extension registration center based on the minimum influence surface and the plug-in dependency relationship chain, registering the plug-in extension point interface to the function extension registration center to form an interface directory and perform function classification, realizing the loose coupling calling between the plug-ins of the same function type based on the interface directory, and realizing the dynamic extension of the plug-in architecture.

[0053] In an alternative embodiment, the plugin source code is converted into an abstract syntax tree by static code analysis, the interface contract of the plugin is extracted from the abstract syntax tree and the interface compatibility is verified by type inference, and the deadlock detection by analyzing the interaction behavior between plugins includes:

[0054] The plugin source code is subjected to lexical analysis to obtain a sequence of morphemes, syntax analysis is performed based on the sequence of morphemes, the recognized declarations, expressions and control flows are respectively constructed into declaration nodes, expression nodes and control flow nodes, and an abstract syntax tree is assembled and constructed, the interface contract of the plugin is obtained based on the declaration nodes of the abstract syntax tree;

[0055] Based on the interface contract, a type constraint set is constructed by a type inference algorithm, a type unification result is obtained by performing a recursive unification operation on the type constraint set, the interface contract is subjected to type inference based on the type unification result, and the structural compatibility result is obtained by judging the covariant relationship of the return type in the interface contract; the calling relationship of the interface contract is analyzed based on the expression nodes to obtain the preconditions, the execution path of the interface contract is analyzed based on the control flow nodes to obtain the postconditions, and the structural compatibility result, the preconditions and the postconditions are combined to generate an interface compatibility verification result;

[0056] Based on the control flow nodes, the resource acquisition sequence and the resource release sequence of the plugin are extracted, the resource acquisition sequence and the resource release sequence are combined to construct a resource dependency graph, strongly connected components are detected in the resource dependency graph, and it is judged whether there is a deadlock between plugins based on the strongly connected components and a deadlock detection result is generated.

[0057] The plugin source code is subjected to lexical analysis, and the source code is decomposed into a sequence of morphemes. A finite automaton is used to scan the source code character stream to identify basic morpheme units such as keywords, identifiers, operators and separators. For example, for the plugin source code "function getData(id) { return cache[id];}", the lexical analyzer will convert it into the morpheme sequence ["function", "getData", "(", "id", ")", "{", "return", "cache", "[", "id", "]", ";", "}"].

[0058] The grammar analyzer uses the recursive descent analysis method to identify declarations, expressions, and control flow structures based on predefined grammar rules. When a function declaration is identified, a function declaration node is created, containing the function name, parameter list, and function body. When a variable declaration is identified, a variable declaration node is created, containing the variable name and initialization expression. When an expression is identified, the corresponding expression node is created, such as a method call expression node or a binary operation expression node. When a control flow structure is identified, the corresponding control flow node is created, such as a conditional statement node or a loop statement node. These nodes are assembled into an abstract syntax tree according to the grammar rules.

[0059] All exported function declaration nodes are traversed to extract function signature information, including function name, parameter types, and return type. For example, from the declaration "export function processData(data: Array): Promise", the interface name is extracted as "processData", the parameter type is "Array", and the return type is "Promise". For class declarations, their public methods are extracted as part of the interface contract. At the same time, the inheritance relationship of the class and the implemented interfaces are analyzed, and these information is integrated into the interface contract.

[0060] For each interface function, the parameter types and return types are analyzed, type variables are created, and constraint relationships are set. For example, for the function "function transform<T, R>(input: T, converter: (item: T) => R):R", type variables T and R are created, and constraints are added according to the use of parameters and return values. For complex types such as generics and union types, they are recursively decomposed into basic type constraints.

[0061] Starting from the entry type variable, recursively replace type variables in type constraints until no further replacement is possible. For example, if there are constraints "α = Array" and "β = string", the result of "α = Array" is obtained by recursive unification. When processing type inheritance relationships, verify whether the child type satisfies all the constraints of the parent type. When there is a constraint conflict, record the type incompatibility error.

[0062] Based on the type unification result, type deduction is performed on the interface contract to judge the covariant relationship of the return type. According to the Liskov Substitution Principle, verify whether the return type of the derived interface is a subtype of the return type of the base interface. For example, if the base interface method returns "Animal" and the derived interface method returns "Dog", since Dog is a subtype of Animal, the covariant relationship is satisfied and the interfaces are compatible. Conversely, if the base interface returns "Dog" and the derived interface returns "Animal", the covariant relationship is not satisfied and the interfaces are not compatible.

[0063] Traverse the expression nodes within the method body to identify parameter usage and parameter validation code. For example, when a validation expression such as "if(!param)" or "if(param === null)" is detected, extract "param non-null" as a precondition for the interface. Similarly, when "if(param.length > 0)" is found, extract "param is a non-null array" as a precondition.

[0064] Construct a control flow graph for the method and analyze the return value characteristics for each execution path. For example, for the code "function findUser(id) { if(id < 0) return null; return database.getUser(id);}", extract the postcondition "returns null when id < 0, otherwise returns a database user object". Through path-sensitive analysis, determine the behavior characteristics of the method under different conditions.

[0065] Combine the structural compatibility results, preconditions, and postconditions to generate interface compatibility verification results. If the structure is compatible and the preconditions are not stricter than the base interface and the postconditions are not wider than the base interface, the interface is compatible; otherwise, mark the interface as incompatible and provide specific reasons.

[0066] By identifying resource acquisition function calls (such as "lock()", "acquire()") and resource release function calls (such as "unlock()", "release()"), record the resource operation sequence. For example, from the code snippet "mutex1.lock(); data.process(); mutex1.unlock();", extract the resource operation sequence "acquire mutex1 -> release mutex1".

[0067] Combine the extracted resource acquisition and release sequences to construct a resource dependency graph, in which nodes represent plugins and edges represent resource acquisition relationships. For example, if plugin A holds resource R1 and waits to acquire R2, and plugin B holds resource R2 and waits to acquire R1, add edges A->B and B->A in the dependency graph.

[0068] Detect strongly connected components in the resource dependency graph and identify circular dependencies through Tarjan's algorithm. Traverse all nodes in the graph and perform a depth-first search for each unvisited node, maintaining the index and low-link value of the node. When the low-link value of a node is found to be equal to its index value, it indicates that a strongly connected component has been found. If the strongly connected component contains multiple nodes, it indicates the existence of a circular resource dependency, and further analysis is required to confirm whether it is a deadlock.

[0069] For each strongly connected component, analyze the resource acquisition mode in it, verify whether the four conditions of deadlock are met: mutual exclusion, holding and waiting, non-preemption and circular waiting. If these conditions are met, it is confirmed that there is a risk of deadlock, and a deadlock detection result is generated, including the plug-in and resource information involved, and the resource acquisition path that forms the deadlock.

[0070] In an optional implementation, based on the interface contract, a type constraint set is constructed by a type inference algorithm, a recursive unification operation is performed on the type constraint set to obtain a type unification result, type inference is performed on the interface contract based on the type unification result, and a structural compatibility result is obtained by judging the covariance relationship of the return type in the interface contract, including:

[0071] Type variable annotation is performed on the formal parameters and return values in the interface contract to construct a type environment; based on the type environment, expressions in the interface contract are traversed, variable reference expressions, function application expressions and state type expressions in the expressions are constructed into variable reference constraints, function application constraints and polymorphic instance constraints respectively, and the variable reference constraints, the function application constraints and the polymorphic instance constraints are combined to form a type constraint set;

[0072] Recursive unification operation is performed on the type constraint set to decompose the type constraints in the type constraint set into atomic constraints, and a type substitution mapping is constructed by detecting the circular reference relationship in the atomic constraints; based on the type substitution mapping, type substitution is iteratively performed by substitution combination operation until no further substitution is possible or a type conflict is found, and a type unification result is generated;

[0073] The type unification result is applied to the type variables of the interface contract, type generalization is performed on the type variables that are not constrained to obtain polymorphic type variables, the polymorphic type variables are added to the type environment to obtain an updated type environment, the subtyping relationship of the return type in the interface contract is analyzed based on the type unification result and the updated type environment, the covariance characteristic is determined according to the subtyping relationship, and the structural compatibility of the interface is verified based on the covariance characteristic.

[0074] Type variable annotation is performed on the formal parameters and return values in the interface contract using a type inference algorithm. For example, for the interface contract "interface IDataService { getUser(id: number): User;}", the parameter "id" is annotated as the known type "number", and the return value is annotated as a type variable "α", indicating that the return type is not yet determined and needs to be determined through subsequent derivation. The constructed type environment can be represented as "{getUser: number → α, id: number}", where "→" represents a function type constructor.

[0075] Traverse the expressions in the interface contract, build a set of type constraints, for variable reference expressions, such as the variable "id" in the function body, generate a variable reference constraint "τ1 = number", where "τ1" is the type variable assigned to the expression. For function application expressions, such as "fetchData(id)", generate function application constraints "τ2 → τ3 = number→ τ4" and "τ5 = τ4", where "τ2" is the parameter type, "τ3" is the return value type, "τ4" is the return type of the function "fetchData", and "τ5" is the type of the entire function application expression. For polymorphic type expressions, such as "Option", generate polymorphic instance constraints "τ6 = Option<τ7>" and "τ7 = User". By combining these constraints, a complete set of type constraints is formed.

[0076] For example, for the interface method "getUser(id: number): Promise", the constraint set generated after expression analysis is "{τ1 = number, τ2 → τ3 = τ1 → τ4, τ5 = τ4, τ5 = Promise<τ6>, τ6 = User}".

[0077] Decompose the type constraint set into atomic constraints, such as decomposing "τ2 → τ3 = number → τ4" into "τ2 = number" and "τ3 = τ4", detect circular reference relationships in atomic constraints, such as the existence of a circular reference in "τ1 = List<τ1>", which requires special handling to avoid infinite expansion, construct a type replacement mapping, such as "{τ1 → number, τ2 → number, τ3 → τ4, τ5 → Promise, τ6 → User}", and perform type replacement iteratively through replacement combination operations until no further replacement is possible or a type conflict is found.

[0078] If there is a type conflict such as "τ1 = number" and "τ1 = string", report a type incompatibility error. Otherwise, generate the final type unification result.

[0079] Taking the interface method as an example, the type unification result after the unification operation is "{α → Promise}", indicating that the return type of the method is derived as "Promise".

[0080] After applying the type unification results to the type variables of the interface contract, type generalization is performed on the type variables that are not constrained. For example, if a type variable "β" does not appear on the right side of any constraint during the constraint solving process, it can be generalized to a polymorphic type variable β.β". These polymorphic type variables are added to the type environment, generating an updated type environment.

[0081] Based on the type unification results and the updated type environment, the subtyping relationship of return types in the interface contract is analyzed to determine the covariance property. The covariance determination follows the following rules: if type A is a subtype of type B, then an interface method with return type A can replace an interface method with return type B, and this relationship is called covariance. For example, "Cat" is a subtype of "Animal", then a method returning "Cat" is structurally compatible with a method returning "Animal".

[0082] In a specific example, it is determined whether "Promise" is a subtype of "Promise". If "DetailedUser" inherits from "User" and the "Promise" type is covariant on its type argument, then "Promise" can replace "Promise" and the interface structures are compatible.

[0083] A specific case of determining structural compatibility: for two interfaces "interface A { getData():Result;}" and "interface B { getData(): Result;}", if "DetailedInfo" contains all the fields of "BasicInfo" and has additional fields, and the "Result" type is covariant on its type argument, then the B interface is structurally compatible with the A interface, and an instance of the B type can be assigned to a variable of the A type.

[0084] Through the above detailed type derivation and structural compatibility determination process, the structural compatibility relationship between interfaces can be accurately verified, the type safety of the code is improved, the runtime errors are reduced, and sufficient flexibility is maintained to support advanced type system features such as polymorphism and subtyping polymorphism.

[0085] In an optional implementation, a directed dependency graph is constructed according to the dependency declaration, a circular dependency is eliminated by topological sorting in the directed dependency graph, a compatible version of each plug-in is determined based on the version identifier using depth-first traversal, and a plug-in dependency relationship chain is generated based on the directed dependency graph and the compatible version, including:

[0086] Based on the dependency declaration, dependencies between plugins are extracted, plugins are mapped as vertices, and the dependencies are mapped as directed edges to obtain a directed dependency graph representing the dependencies between plugins, strongly connected components in the directed dependency graph are identified, based on the strongly connected components, the directed dependency graph is decomposed into a set of strongly connected subgraphs, and a topological sorting loop dependency elimination is performed on each strongly connected subgraph in the set to generate an acyclic dependency sequence;

[0087] Based on the acyclic dependency sequence, a depth-first traversal strategy is used to traverse the directed dependency graph from a node with no outgoing edges, and in the traversal process, version compatibility of adjacent plugins is calculated based on the version identifier, the version identifier includes a major version number and a minor version number, a compatible version set containing all compatible versions is generated for each plugin, the major version number of the compatible version is the same as that of the corresponding plugin and the minor version number is greater than or equal to that of the corresponding plugin;

[0088] Based on the acyclic dependency sequence, a dependency transitive relationship is determined, the dependency transitive relationship is combined with the compatible version set, a plugin node identifier is associated with the compatible version set, a dependency transitive closure is calculated based on the dependency transitive relationship and the compatible version set, and a plugin dependency relationship chain is obtained.

[0089] As shown in Figure 2 the method comprises:

[0090] The dependency declaration usually contains a plugin identifier, version information, and a list of other plugins that the plugin depends on. For example, plugin A (v1.2) depends on plugin B (v2.0) and plugin C (v1.5), and this dependency relationship can be represented as A(1.2) →{B(2.0), C(1.5)}. Each plugin is mapped as a vertex in the directed dependency graph, and the dependency relationship is mapped as a directed edge from the dependent to the dependent, thereby constructing a directed dependency graph representing the dependency relationship between plugins.

[0091] Cyclic dependencies in the graph are identified, and a method based on Tarjan's algorithm is used to identify strongly connected components in the directed dependency graph. A strongly connected component is a maximum subset of vertices in which any two vertices are mutually reachable. For example, if plugin A depends on B, B depends on C, and C depends on A, then A, B, and C form a strongly connected component, indicating that they have a cyclic dependency.

[0092] For a strongly connected subgraph containing multiple vertices, it is necessary to eliminate the cyclic dependency therein, perform a topological sort on each strongly connected subgraph, determine the optimal dependency direction based on the importance or update time of the plug-ins, and thus break the cyclic dependency. For example, for a cyclic dependency of A→B→C→A, it is determined to remove the dependency of C→A based on the importance score of the plug-ins, and a loop-free dependency sequence of A→B→C is generated. In an actual scenario, if plug-ins A (v1.2), B (v2.3), and C (v1.0) form a cyclic dependency, and the importance scores of A, B, and C are 85, 72, and 63 respectively, the dependency to the plug-in with the highest importance is preferentially retained, and the dependency of C→A is removed, thereby forming a loop-free dependency path.

[0093] Based on the loop-free dependency sequence, a depth-first traversal strategy is adopted to start from a node with no out-degree and traverse the directed dependency graph upwards. In the traversal process, the version compatibility of adjacent plug-ins is calculated based on the version identifier. The version identifier usually contains a major version number and a minor version number, for example, in v2.3, 2 is the major version number and 3 is the minor version number. The version compatibility rule is defined as follows: The major version number of the compatible version must be the same as that of the original plug-in, and the minor version number must be greater than or equal to that of the original plug-in.

[0094] For example, if plug-in A declares a dependency on plug-in B version v2.0, plug-in B versions v2.0, v2.1, v2.2, and the like are all considered as compatible versions, while v1.9 or v3.0 is considered as an incompatible version. A set containing all compatible versions is generated for each plug-in. For example, if the current latest version of plug-in B is v2.5, the compatible version set of plug-in B is {v2.0, v2.1, v2.2, v2.3, v2.4, v2.5}.

[0095] In the version compatibility analysis process, the version constraints of the transitive dependencies are considered. For example, if plug-in A depends on plug-in B (v2.0+), plug-in B depends on plug-in C (v1.5+), then plug-in A indirectly depends on plug-in C (v1.5+). When there are multiple dependency paths, the intersection of the version constraints is calculated to ensure that the selected version meets the requirements of all dependency paths. If plug-in A also depends on plug-in C (v1.8+) through another path, the effective version constraint of A to C is v1.8+, that is, {v1.8, v1.9, v2.0...}.

[0096] The plug-in node identifier is associated with the compatible version set, the transitive dependency closure is calculated based on the dependency transitive relationship, and thus a complete plug-in dependency relationship chain is generated. The transitive dependency closure contains direct dependencies and all indirect dependencies, ensuring that all cascading dependency relationships can be correctly resolved.

[0097] Suppose there is a plug-in system containing plug-ins P(v1.0), Q(v2.1), R(v1.5), S(v3.0) and T(v2.2), where P depends on Q and R, Q depends on S, R depends on T and S, T depends on S, a directed dependency graph is constructed: P→{Q, R}, Q→S, R→{T, S}, T→S, which does not have a circular dependency, so there is no need to perform strong connected component decomposition and topological sorting, starting from the node with no out-degree S, a depth-first traversal is performed to determine the compatible version set of each plug-in: S={v3.0+}, T={v2.2+}, R={v1.5+}, Q={v2.1+}, P={v1.0+}. The final generated dependency relationship chain is: P depends on {Q(v2.1+), R(v1.5+), S(v3.0+), T(v2.2+)}, Q depends on {S(v3.0+)}, R depends on {S(v3.0+), T(v2.2+)}, T depends on {S(v3.0+)}, S has no dependency.

[0098] Through the above method, the complex dependency relationship between plug-ins can be effectively managed, the plug-in version compatibility is ensured, and a clear dependency relationship chain is provided, which provides strong support for the stable operation and version management of the plug-in system.

[0099] In an optional implementation, the calling relationship and the influence range between the plug-ins are recorded during the plug-in runtime to obtain a plug-in calling index table, the minimum influence surface is calculated based on the plug-in calling index table, and the function extension registration center is constructed based on the minimum influence surface and the plug-in dependency relationship chain, including:

[0100] The method calling between the plug-ins is tracked through dynamic proxying and bytecode enhancement technology, the calling event and the functional influence range of the calling are obtained, the calling event sequence is generated by arranging the calling event in time sequence, the plug-in calling index table is constructed based on the calling event sequence and the functional influence range;

[0101] The calling path information between the plug-ins is extracted from the plug-in calling index table, for any two plug-ins, when there is a calling path from a source plug-in to a target plug-in and the functional set of the two plug-ins has an intersection, the target plug-in is added to the initial influence surface of the source plug-in, the initial influence surface is iteratively processed by using a forward slicing analysis method, redundant influence items are identified and removed, and the minimum influence surface is obtained;

[0102] The functional identifier and the corresponding implementation plug-in set are extracted from the minimum influence surface, the functional registration table is constructed based on the functional identifier and the implementation plug-in set, the compatible version set is extracted from the plug-in dependency relationship chain, the compatible version set is mapped into the functional registration table to generate version constraint information and add it to the corresponding functional item, and the function extension registration center is constructed.

[0103] During the plugin runtime, dynamic proxy and bytecode enhancement techniques are used to track method calls between plugins. Specifically, for a Java-based plugin system, AspectJ, Javassist, or ByteBuddy can be used to insert monitoring code before and after the execution of plugin methods. For example, for the scenario where the method methodA in plugin A calls the method methodB in plugin B, the call initiation time, source plugin identifier, target plugin identifier, call method signature, and related context information are recorded. When the method methodA in plugin A calls the method methodB in plugin B, a call event record is generated: {"timestamp": "2023-07-15 10:30:22", "sourcePlugin": "PluginA", "targetPlugin": "PluginB", "method": "methodB", "context": {"functionId": "dataProcessing"}}. At the same time, the functional impact range involved in this call is analyzed, for example, the method methodB affects the data processing and data display two functional domains, and the functional impact range is recorded as {"functions": ["dataProcessing", "dataVisualization"]}.

[0104] The collected call events are sorted in chronological order to generate call event sequences. For repeated calls between the same plugins, the call count is merged and the earliest and latest call timestamps are retained. For example, multiple records of plugin A calling plugin B are merged as: {"sourcePlugin": "PluginA", "targetPlugin": "PluginB", "callCount":15, "firstCall": "2023-07-15 10:30:22", "lastCall": "2023-07-15 11:45:36", "methods": ["methodB", "methodC"], "affectedFunctions": ["dataProcessing", "dataVisualization"]}. Based on these call event sequences and functional impact range information, a plugin call index table is constructed, which contains information on source plugins, target plugins, call frequency, and affected functional domains.

[0105] From the plugin call index table, the call path information between plugins is extracted. For any two plugins P1 and P2, it is checked whether there is a call path from P1 to P2. For example, if plugin A calls plugin B, and plugin B calls plugin C, there is a call path from A to C. It is checked whether the function sets of the two plugins have an intersection. If there is a call path from the source plugin to the target plugin, and the function sets of the two plugins have an intersection, the target plugin is added to the initial influence scope of the source plugin.

[0106] Suppose there are plugins P1, P2, and P3, and their function sets are {F1, F2}, {F2, F3}, and {F3, F4}, respectively. If there is a path from P1 to P2, and the intersection of the function sets of P1 and P2 is {F2}, then P2 is added to the initial influence scope of P1. Similarly, if there is a path from P2 to P3, and the intersection of the function sets of P2 and P3 is {F3}, then P3 is added to the initial influence scope of P2. At this time, the initial influence scope of P1 is {P2}, and the initial influence scope of P2 is {P3}.

[0107] The initial influence scope is iteratively processed using the forward slicing analysis method. Starting from the source plugin, the set of directly affected plugins is analyzed, and then the downstream plugins affected by these plugins are recursively analyzed. In each iteration, it is checked whether the newly added influence item is already included in the current influence scope. If yes, it is skipped; otherwise, it is added to the influence scope and its downstream influence is continued to be analyzed. In this way, redundant influence items can be identified and removed, and the minimum influence scope is finally obtained.

[0108] Taking the above example as an example, when analyzing the minimum influence scope of P1, P2 is added to the influence scope, and then the downstream influence of P2 is analyzed. It is found that P3 is affected by P2 and the function sets have an intersection, so P3 is also added to the influence scope of P1. After iterative processing, the minimum influence scope of P1 is {P2, P3}.

[0109] From the minimum influence, the function identifier and the corresponding implementation plugin set are extracted. For example, for function F2, its implementation plugin set is {P1, P2}; for function F3, its implementation plugin set is {P2, P3}. Based on this information, a function registry is constructed, which takes the function identifier as the key and the implementation plugin set as the value.

[0110] From the plugin dependency chain, the compatible version set is extracted, assuming that the version range of plugin P1 is [1.0.0, 2.0.0), indicating compatibility with versions from 1.0.0 (inclusive) to 2.0.0 (exclusive). Map these compatible version sets to the function registry to generate version constraint information. For example, for function F2, the version constraint is: {"P1": "[1.0.0, 2.0.0)", "P2": "[1.5.0, 3.0.0)"}}, indicating that function F2 is available in P1 versions 1.0.0 to 2.0.0 and P2 versions 1.5.0 to 3.0.0. Add these version constraint information to the corresponding function item, and finally build the function extension registry.

[0111] The function extension registry is a structured data storage containing function identification, implementation plugin set, version constraint, etc. When an application needs to use a certain function, it can query the registry to obtain the list of plugins supporting the function and their version requirements, thereby achieving flexible function extension and version management. For example, querying the support of function F2, the registry returns: {"function": "F2", "implementations": [{"plugin": "P1", "versionRange": "[1.0.0, 2.0.0)"}}, {"plugin": "P2", "versionRange": "[1.5.0,3.0.0)"}]}.

[0112] The function extension registry constructed by the above method can effectively manage the calling relationship and function dependency between plugins, support the dynamic selection of appropriate plugins by the application to implement specific functions, and improve scalability and flexibility.

[0113] In an optional implementation, the plugin extension point interface is registered to the function extension registry to form an interface directory and perform function classification, and the loose coupling calls between plugins of the same function type are realized based on the interface directory, including:

[0114] The plugin extension point interface is submitted to the function extension registry for registration, generating an interface directory, obtaining the registration identifier of the plugin extension point interface and adding it to the interface directory; the annotation information of the plugin extension point interface is analyzed through the reflection mechanism and the function classification similarity is calculated, and the plugin extension point interface is classified to form a function classification tree based on the function classification similarity;

[0115] The interface directory is hierarchically organized based on the function classification tree, a multi-level index directory node is constructed, the compatible version set is added to the multi-level index directory node, and the version constraint information is generated based on the multi-level index directory node and the registration identifier.

[0116] Obtaining a function descriptor of the calling plug-in, matching a target function type in the interface directory according to the function descriptor, obtaining a set of implementation plug-ins corresponding to the target function type, and filtering the set of implementation plug-ins based on the version constraint information;

[0117] Calculating a plug-in adaptation degree for the filtered implementation plug-ins, selecting an implementation plug-in with the highest plug-in adaptation degree, implementing runtime binding of the calling plug-in and the implementation plug-in by using a dynamic proxy technology, and completing loose coupling calling between plug-ins.

[0118] Submitting a plug-in extension point interface to a function extension registration center, the registration center receiving an interface definition of the plug-in extension point interface submitted by a plug-in developer, the interface definition including an interface name, a method signature, a parameter type, and annotation information, the registration center generating a globally unique registration identifier (such as "com.plugin.payment.PaymentInterface-v1.2.0"), associating the identifier with the interface information, and storing the interface information in an interface directory database. For example, interface information of a payment plug-in includes an interface fully qualified name "com.plugin.payment.PaymentInterface", a version number "1.2.0", and function description "online payment processing" and the like metadata.

[0119] Extracting @FunctionCategory, @PluginCapability, and the like custom annotation content on the interface class through a reflection mechanism, for example, a payment interface is marked with @FunctionCategory({"payment", "transaction"}) and @PluginCapability({"online", "secure"}), based on the annotation information, a feature vector is constructed to represent the function attributes of each interface, and when calculating the function classification similarity, a term frequency-inverse document frequency (TF-IDF) method is used to analyze the annotation text and extract keyword weights. The similarity value between two interfaces ranges from 0 to 1, when the function annotations of two interfaces are completely matched, the similarity is 1, and when they are completely irrelevant, the similarity is 0. For example, the "payment interface" has a similarity of 0.85 with the "online payment interface", and only a similarity of 0.12 with the "log recording interface".

[0120] Based on the calculated similarity matrix, a hierarchical clustering algorithm is used to group interfaces with similarity higher than a threshold (e.g. 0.7) into the same functional category, and a functional classification tree is constructed. The functional classification tree adopts a multi-level structure, and the top level includes main functional domains such as "payment processing", "data storage", "user interface", etc. Each main functional domain can be further divided into multiple sub-categories. For example, "payment processing" includes sub-categories such as "online payment", "offline payment", "payment verification", etc.

[0121] According to the functional classification tree, a multi-level index directory node is constructed, which is hierarchically organized. Each directory node includes a node ID, a parent node ID, a functional classification name, an interface list, and a compatible version set. The compatible version set records the compatibility relationship between different version interfaces in the functional category. The version range representation method is used, such as "[1.0.0, 2.0.0)" to represent all versions compatible between 1.0.0 (inclusive) and 2.0.0 (exclusive). For example, payment interface v1.2.0 is compatible with all callers of v1.0.0 to v1.5.0. According to the interface version information and compatibility declaration, version constraint information is generated and stored as a mapping relationship of "interface ID-version range".

[0122] The caller plugin provides its own functional descriptor, including the type of function to be called, the expected version, and the functional keywords. According to this information, matching is performed in the interface directory to locate the directory node of the target functional type, and the implementation plugin set under the node is obtained. Assuming that the caller needs the "online payment" function with version requirement "v1.1.0", the "payment processing / online payment" directory node is found, and all implementation plugins under the node are obtained, such as "standard payment plugin", "fast payment plugin", and "secure payment plugin".

[0123] Based on the version constraint information, the implementation plugin set is filtered to remove incompatible plugins. For example, if the "fast payment plugin" version is v2.1.0, and the caller needs v1.1.0, and they are not in the same compatible version range, then this plugin will be filtered out. For the remaining plugins, the plugin adaptation degree is calculated, considering factors such as functional matching degree, version compatibility, performance indicators, etc. The adaptation degree calculation result is a score between 0 and 100, and the higher the value, the better the adaptation degree. For example, the adaptation degree of "standard payment plugin" is 85, and the adaptation degree of "secure payment plugin" is 92.

[0124] The implementation plug-in with the highest adaptability (in this case, the "safe payment plug-in") is selected, and a Java dynamic proxy technology is used to realize the runtime binding of the calling plug-in and the implementation plug-in, to create a proxy object, intercept the calling of the interface by the calling plug-in, and forward to the specific implementation class of the implementation plug-in, while processing parameter conversion, exception handling and result return. This dynamic binding mechanism makes the calling plug-in not directly dependent on the specific class of the implementation plug-in, and realizes the loose coupling calling. When a more suitable implementation plug-in appears, the new implementation plug-in can be dynamically switched without modifying the calling plug-in code, improving the scalability and flexibility.

[0125] Through the above technical means, the application realizes the registration classification of the plug-in extension point interface and the loose coupling calling based on the function type, can dynamically select the most suitable plug-in implementation at runtime, reduces the coupling degree between plug-ins, and improves the scalability and maintainability.

[0126] The embodiment of the application is a plug-in dependency analysis and architecture extension system for a low-code platform, and the system comprises:

[0127] A first unit is configured to obtain plug-ins from a plug-in warehouse of the low-code platform.

[0128] A second unit is configured to convert plug-in source code into an abstract syntax tree through static code analysis, extract an interface contract of the plug-in from the abstract syntax tree, and verify interface compatibility through type derivation; perform deadlock detection by analyzing the interaction behavior between plug-ins; convert the interface compatibility and the deadlock detection result into a dependency constraint condition; recursively traverse the plug-in warehouse, filter plug-ins that meet the dependency constraint condition, and extract dependency declarations and version identifiers of the plug-ins; construct a directed dependency graph according to the dependency declarations; eliminate circular dependencies by performing topological sorting in the directed dependency graph; determine compatible versions of the plug-ins based on the version identifiers using depth-first traversal; and generate a plug-in dependency relationship chain based on the directed dependency graph and the compatible versions.

[0129] A third unit is configured to record the calling relationship and the influence range between plug-ins during plug-in runtime, obtain a plug-in calling index table, calculate a minimum influence surface based on the plug-in calling index table, construct a function extension registration center based on the minimum influence surface and the plug-in dependency relationship chain, register plug-in extension point interfaces to the function extension registration center to form an interface directory and perform function classification, realize loose coupling calling between plug-ins of the same function type based on the interface directory, and realize dynamic extension of the plug-in architecture.

[0130] In a third aspect, the embodiment of the application provides an electronic device, comprising:

[0131] a processor;

[0132] a memory for storing processor-executable instructions.

[0133] The processor is configured to invoke instructions stored in the memory to perform the method described above.

[0134] In a fourth aspect, the present application provides a computer readable storage medium, having stored thereon computer program instructions, which when executed by a processor implement the method described above.

[0135] The present application can be a method, apparatus, system, and / or computer program product. Computer program products can include computer readable storage media having computer readable program instructions thereon for performing various aspects of the present application.

[0136] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for plug-in dependency resolution and architecture extension for low-code platforms, characterized in that, Comprise: Obtaining a plugin from a plugin warehouse of a low-code platform; Converting plugin source code into an abstract syntax tree through static code analysis, extracting an interface contract of the plugin from the abstract syntax tree and verifying interface compatibility through type inference, performing deadlock detection by analyzing interaction behavior between plugins, converting interface compatibility and deadlock detection results into dependency constraint conditions, recursively traversing the plugin warehouse, screening plugins that meet the dependency constraint conditions and extracting dependency declarations and version identifiers of the plugins, constructing a directed dependency graph according to the dependency declarations, eliminating circular dependencies by topological sorting in the directed dependency graph, determining compatible versions of each plugin based on the version identifiers using depth-first traversal, and generating a plugin dependency relationship chain based on the directed dependency graph and the compatible versions; Recording calling relationships and influence ranges between plugins during plugin runtime to obtain a plugin calling index table, calculating a minimum influence surface based on the plugin calling index table, constructing a function extension registration center based on the minimum influence surface and the plugin dependency relationship chain, registering plugin extension point interfaces to the function extension registration center to form an interface directory and perform function classification, realizing loosely coupled calling between plugins of the same function type based on the interface directory, and realizing dynamic extension of a plugin architecture.

2. The method of claim 1, wherein, Converting plugin source code into an abstract syntax tree through static code analysis, extracting an interface contract of the plugin from the abstract syntax tree and verifying interface compatibility through type inference, performing deadlock detection by analyzing interaction behavior between plugins includes: Performing lexical analysis on the plugin source code to obtain a morpheme sequence, performing syntax analysis based on the morpheme sequence, respectively constructing declaration nodes, expression nodes and control flow nodes from recognized declarations, expressions and control flows, and assembling and constructing an abstract syntax tree, obtaining the interface contract of the plugin based on the declaration nodes of the abstract syntax tree; Based on the interface contract, constructing a type constraint set through a type inference algorithm, performing a recursive unification operation on the type constraint set to obtain a type unification result, performing type inference on the interface contract based on the type unification result, determining the covariance relationship of return types in the interface contract to obtain structural compatibility results; based on the expression nodes, analyzing the calling relationship of the interface contract to obtain preconditions, based on the control flow nodes, analyzing the execution path of the interface contract to obtain postconditions, combining the structural compatibility results, the preconditions and the postconditions to generate interface compatibility verification results; Based on the control flow nodes, extracting resource acquisition sequences and resource release sequences of the plugin, combining the resource acquisition sequences and the resource release sequences to construct a resource dependency graph, detecting strongly connected components in the resource dependency graph, and determining whether there is a deadlock between plugins based on the strongly connected components and generating a deadlock detection result.

3. The method of claim 2, wherein, Based on the interface contract, constructing a type constraint set through a type inference algorithm, performing a recursive unification operation on the type constraint set to obtain a type unification result, performing type inference on the interface contract based on the type unification result, determining the covariance relationship of return types in the interface contract to obtain structural compatibility results includes: annotating type variables to formal parameters and return values in the interface contract to build a type environment; based on the type environment, traversing expressions in the interface contract, constructing variable reference expressions, function application expressions and state type expressions in the expressions into variable reference constraints, function application constraints and polymorphic instance constraints respectively, and combining the variable reference constraints, the function application constraints and the polymorphic instance constraints to form a type constraint set; performing a recursive unification operation on the type constraint set to decompose type constraints in the type constraint set into atomic constraints, detecting a circular reference relationship in the atomic constraints to construct a type substitution mapping, based on the type substitution mapping, iteratively performing type substitution through a substitution combination operation until no further substitution is possible or a type conflict is found, and generating a type unification result; applying the type unification result to type variables of the interface contract, performing type generalization on type variables that are not constrained to obtain polymorphic type variables, adding the polymorphic type variables to the type environment to obtain an updated type environment, analyzing a subtyping relationship of a return type in the interface contract based on the type unification result and the updated type environment, judging a covariance property according to the subtyping relationship, and verifying structural compatibility of the interface based on the covariance property.

4. The method of claim 1, wherein, constructing a directed dependency graph based on the dependency declaration, eliminating circular dependencies by topological sorting in the directed dependency graph, determining compatible versions of each plugin based on the version identifier using a depth-first traversal, and generating a plugin dependency relationship chain based on the directed dependency graph and the compatible versions, including: extracting dependency relationships between plugins based on the dependency declaration, mapping plugins to vertices and the dependency relationships to directed edges to obtain a directed dependency graph representing the dependency relationships between the plugins, identifying strongly connected components in the directed dependency graph, decomposing the directed dependency graph into a set of strongly connected subgraphs based on the strongly connected components, and eliminating circular dependencies by topological sorting for each strongly connected subgraph in the set of strongly connected subgraphs to generate an acyclic dependency sequence; based on the acyclic dependency sequence, traversing the directed dependency graph upwards from vertices with no outgoing edges using a depth-first traversal strategy, calculating version compatibility of adjacent plugins based on the version identifier during the traversal, the version identifier including a major version number and a minor version number, and generating a compatible version set including all compatible versions for each plugin, the compatible versions having the same major version number as the corresponding plugin and a minor version number greater than or equal to the minor version number of the corresponding plugin; determining a dependency transitive relationship based on the acyclic dependency sequence, combining the dependency transitive relationship with the compatible version set, associating plugin node identifiers with the compatible version set, and calculating a dependency transitive closure based on the dependency transitive relationship and the compatible version set to obtain a plugin dependency relationship chain.

5. The method of claim 1, wherein, recording calling relationships and impact scopes between plugins during plugin runtime to obtain a plugin calling index table, calculating a minimum impact surface based on the plugin calling index table, and building a functional extension registration center based on the minimum impact surface and the plugin dependency relationship chain, including: The method call between the plugins is tracked through dynamic proxy and bytecode enhancement technology, the call event and the function influence range of the call are acquired, the call event sequence is generated by arranging the call event according to time sequence, and the plugin call index table is constructed based on the call event sequence and the function influence range; The call path information between the plugins is extracted from the plugin call index table, for any two plugins, when there is a call path from a source plugin to a target plugin and the function sets of the two plugins have an intersection, the target plugin is added to the initial influence face of the source plugin, the initial influence face is iteratively processed by using a forward slice analysis method, redundant influence items are identified and removed, and a minimum influence face is obtained; The function identifier and the corresponding implementation plugin set are extracted from the minimum influence face, the function registry is constructed based on the function identifier and the implementation plugin set, the compatible version set is extracted from the plugin dependency relationship chain, the compatible version set is mapped into the function registry to generate version constraint information and add it to the corresponding function item, and the function extension registry center is constructed.

6. The method of claim 1, wherein, The plugin extension point interface is registered into the function extension registry center to form an interface directory and perform function classification, and the loose coupling call between the plugins of the same function type is realized based on the interface directory, including: The plugin extension point interface is submitted to the function extension registry center for registration, the interface directory is generated, the registration identifier of the plugin extension point interface is acquired and added to the interface directory, the annotation information of the plugin extension point interface is analyzed through a reflection mechanism and the function classification similarity is calculated, the plugin extension point interface is classified to form a function classification tree based on the function classification similarity; The interface directory is hierarchically organized based on the function classification tree, a multi-level index directory node is constructed, the compatible version set is added to the multi-level index directory node, and the version constraint information is generated based on the multi-level index directory node and the registration identifier; The function descriptor of the calling plugin is acquired, the target function type is matched in the interface directory according to the function descriptor, the implementation plugin set corresponding to the target function type is acquired, and the implementation plugin set is filtered based on the version constraint information; The plugin adaptation degree of the filtered implementation plugin is calculated, the implementation plugin with the highest plugin adaptation degree is selected, the run-time binding of the calling plugin and the implementation plugin is realized by using a dynamic proxy technology, and the loose coupling call between the plugins is completed.

7. A plugin dependency resolution and architecture extension system for low-code platforms for implementing the method of any of claims 1-6, characterized in that, The first unit is configured to acquire a plugin from a plugin warehouse of a low-code platform. ​ The second unit is configured to convert the plugin source code into an abstract syntax tree through static code analysis, extract the interface contract of the plugin from the abstract syntax tree, and verify the interface compatibility through type inference; perform deadlock detection by analyzing the interaction behavior between the plugins; convert the interface compatibility and the deadlock detection result into a dependency constraint condition; recursively traverse the plugin repository; filter the plugins that meet the dependency constraint condition, and extract the dependency declaration and version identification of the plugins; construct a directed dependency graph according to the dependency declaration; eliminate the circular dependency by performing topological sorting in the directed dependency graph; determine the compatible version of each plugin based on the version identification by using depth-first traversal; and generate a plugin dependency relationship chain based on the directed dependency graph and the compatible version. The third unit is configured to record the calling relationship and the influence range between the plugins during the runtime of the plugins, obtain a plugin calling index table, calculate a minimum influence surface based on the plugin calling index table, construct a function extension registration center based on the minimum influence surface and the plugin dependency relationship chain, register the plugin extension point interface to the function extension registration center to form an interface directory and perform function classification, realize the loose coupling between the plugins of the same function type based on the interface directory, and realize the dynamic extension of the plugin architecture.

8. An electronic device, comprising: The computer program instructions are executed by the processor to implement the method in any one of claims 1 to 6. The computer program instructions are executed by the processor to implement the method in any one of claims 1 to 6. ​ ​ 9. A computer-readable storage medium having stored thereon computer program instructions, wherein, ​

Images