Automated code activity graph generation system and method

Abstract

The invention relates to an automatic code activity graph generation system and method, and the system comprises a plurality of modules. The source code analysis module extracts source codes from the code file and generates an abstract syntax tree corresponding to the source codes. The model conversion engine is based on query view conversion specification operation, analyzes a method calling relation and an execution sequence in the abstract syntax tree by utilizing a group of analysis rules, and converts the source code into a programming language abstract model. And the model warehouse is used for storing the abstract model, identifying the language type through the extension name of the source code file, and matching the corresponding programming language model. The activity graph generator then generates an activity graph according to the abstract model, including an activity graph reflecting code logic and an activity graph generated based on code annotations. The layout module determines the position, the size and the shape of each node in the activity graph through an analysis method calling relation and an execution path, and generates a connecting line between the nodes. The system can visually display the code process and improve the efficiency of developers.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an automatic code activity diagram generation system and method. Background Art

[0002] In the prior art, activity diagrams are an important tool in system development and are usually used to display the internal operation process of the system. In order to help designers and developers clarify the logical relationship of the system, special drawing tools are often used to manually draw activity diagrams during the development process. This method is widely used in various software development projects, especially in the system design stage. Activity diagrams help to display the logical structure and method call relationship of the system, and help the development team and project managers intuitively understand the business and technical processes of the system.

[0003] However, the method of manually drawing activity diagrams used in the prior art has some obvious shortcomings. First, activity diagrams are usually drawn before development, and after the system development is completed, the activity diagrams are often not updated in a timely manner, resulting in differences between the design drawings and the actual implemented codes, and unable to accurately reflect the actual operating logic of the current system. Secondly, manually drawing activity diagrams requires a lot of time and effort, especially for systems with complex functions or frequent iterations, manual maintenance of activity diagrams becomes very cumbersome. In addition, the activity diagrams generated by existing tools are usually only for technical personnel, it is difficult to take into account the needs of business personnel, and it is impossible to provide multi-angle process display.

[0004] In view of the above problems, there is an urgent need to develop a new code activity diagram generation system. Summary of the invention

[0005] The present application provides a system and method for automatically generating code activity diagrams to improve the efficiency of developers.

[0006] The automatic code activity diagram generation system provided by this application includes: A source code parsing module, used to extract source code from a code file and generate an abstract syntax tree corresponding to the source code; A model conversion engine, based on a query view conversion specification operation, is configured with a set of parsing rules for parsing the method call relationship and statement execution order in the abstract syntax tree, and converting the source code into a programming language abstract model; A model warehouse, used to store the programming language abstract model and identify the programming language type according to the extension of the source code file to match the corresponding programming language abstract model; An activity diagram generator, connected to the model warehouse, for generating an activity diagram according to the programming language abstract model, wherein the activity diagram includes an activity diagram generated based on logic code and an activity diagram generated based on code comments; The layout module is used to determine the position, size and shape of each node in the activity diagram by parsing the method call relationship and code execution path in the programming language abstract model, and generate connection lines between the nodes.

[0007] Furthermore, the source code parsing module performs lexical analysis on the source code through the cooperation of a lexical analyzer and a syntax analyzer, extracts keywords, identifiers and symbols in the source code, and constructs an abstract syntax tree through syntax analysis.

[0008] Furthermore, the source code parsing module is used to parse source code of multiple programming languages, including Java, Python and C++, and dynamically adjust the parsing process according to the grammatical rules of the programming language.

[0009] Furthermore, the model repository stores programming language abstract models via a hash table; and uses the extension and unique identifier of the source code file as a hash key to quickly retrieve abstract models of different programming languages.

[0010] Furthermore, the model repository includes a version management unit for storing and retrieving multiple versions of programming language abstract models of the same source code file and comparing differences between different versions.

[0011] Furthermore, the activity diagram generator includes a multi-perspective activity diagram generating unit, and the multi-perspective activity diagram generating unit is used to generate an activity diagram from multiple perspectives according to different user needs, wherein the perspectives include: Developer perspective, used to show detailed code execution logic; Business personnel perspective, used to generate simplified business logic activity diagrams based on code comments; The historical version perspective is used to display the system's functional iteration or code modification history.

[0012] Furthermore, the activity diagram generator converts each logic node in the programming language abstract model into a visual activity diagram node through a graphic rendering engine, and draws the connection lines between the nodes according to the function call relationship.

[0013] Furthermore, the layout module includes a graph optimization unit, which adjusts the node layout of the activity graph based on a multi-objective optimization algorithm to reduce the distance deviation between nodes, reduce the number of crossings of connection lines, and optimize the alignment of nodes. The multi-objective optimization algorithm is solved by a constraint optimization model provided by the following formula (1):

[0014] in, Indicates and The logical connection weight between nodes is determined based on the calling relationship and dependency degree of the nodes; Indicates and The Euclidean distance between nodes; is the ideal distance determined based on logical relationships; Indicates The length of the connecting line; is the length of the longest connecting line in the figure; Indicates The number of crossings of the connecting lines; Indicates The alignment deviation of nodes; is the number of lines with the most crossing times in the graph; is the maximum alignment deviation in the current graph; Represents the energy value in the node layout; Indicates The distance between a node and the activity graph boundary; is the minimum boundary distance among all nodes; Indicates the number of nodes; Indicates the number of connection lines; , , and is a trade-off parameter; An adjustment parameter to balance the effect of connection line length and number of crossovers.

[0015] Furthermore, the automatic code activity diagram generation system further includes a code processing flow complexity adjustment unit, which is used to calculate the complexity of the code processing flow according to the abstract syntax tree generated by the source code, and adjust the number of nodes of the activity diagram according to the code processing complexity, wherein the calculation formula of the code processing complexity is calculated using the following formula (2):

[0016] in, Indicates the complexity of the code processing flow; Indicates The number of executed statements in a code snippet; Indicates The branch depth in a code snippet; Indicates The length of the function call chain; Indicates The dependency depth of a function; Indicates The number of parameters of the function; and Represents the number of code snippets and functions respectively; The code processing flow complexity adjustment unit adjusts the number of nodes and detail of the activity diagram based on the following rules: When the calculated code processing complexity When the preset first threshold is exceeded, the details inside the function are merged into a single node in the activity diagram, and only the high-level logic of the function call sequence is retained; When the calculated code processing complexity When a preset second threshold is exceeded, multiple related code snippets are merged into a single node in the activity graph; wherein the second threshold is greater than the first threshold; When the calculated code processing complexity When the value is lower than the preset third threshold, the detailed execution logic within the function is displayed in the activity diagram, including branches, loops, and specific operation steps.

[0017] The present application provides a method for automatically generating a code activity diagram, comprising: Extracting source code from a code file and generating an abstract syntax tree corresponding to the source code; Based on the query view conversion specification operation, a set of configured parsing rules are used to parse the method call relationship and statement execution order in the abstract syntax tree, and convert the source code into a programming language abstract model; The programming language abstract model is stored in a model repository, and the programming language type is identified according to the extension of the source code file to match the corresponding programming language abstract model; Generate an activity diagram based on the programming language abstract model through the model warehouse, wherein the activity diagram includes an activity diagram generated based on logic code and an activity diagram generated based on code comments; By parsing the method call relationship and code execution path in the programming language abstract model, the position, size and shape of each node in the activity diagram are determined, and connecting lines between the nodes are generated.

[0018] The beneficial effects of this application mainly include: (1) Through source code parsing and model conversion, the system can automatically generate activity diagrams that match the actual code logic, avoiding the deviations that may occur when manually drawing activity diagrams. The system can reflect the actual processing flow of the code in real time, helping developers and related personnel to more accurately understand the operating logic of the system and perform effective process optimization. (2) The system reduces the time and manpower required for manual drawing of activity diagrams by automatically generating activity diagrams. Developers can focus on writing code, and the system automatically generates activity diagrams after development is completed, quickly and accurately displaying the code flow, greatly improving development efficiency, especially for systems with complex functions or long-term iterations. (3) The system can generate two different types of activity diagrams at the same time, meeting the needs of technical personnel and business personnel respectively. The activity diagram generated based on logical code helps developers understand the code flow, while the activity diagram generated based on code comments helps business personnel master the business logic of the system, improving the visibility and understanding of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a schematic diagram of an automatic code activity diagram generation system provided in the first embodiment of the present application.

[0020] Figure 2 This is a flowchart of an automated code activity diagram generation method provided in the second embodiment of the present application. DETAILED DESCRIPTION

[0021] Many specific details are described in the following description to facilitate a full understanding of the present application. However, the present application can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of the present application, so the present application is not limited by the specific implementation disclosed below.

[0022] The first embodiment of the present application provides an automated code activity diagram generation system. Figure 1 , which is a schematic diagram of the first embodiment of the present application. Figure 1 The first embodiment of the present application provides an automated code activity diagram generation system for a detailed description.

[0023] The automatic code activity diagram generation system includes a source code parsing module 101 , a model conversion engine 102 , a model repository 103 , an activity diagram generator 104 and a layout module 105 .

[0024] The source code parsing module 101 is used to extract source code from a code file and generate an abstract syntax tree corresponding to the source code.

[0025] The source code parsing module 101 plays a key role in the automatic code activity diagram generation system. The main function of this module is to extract the code content from the source code file and generate an abstract syntax tree (AST) corresponding to the source code structure through a series of analysis processes. The workflow of this module usually includes the following steps.

[0026] First, the source code parsing module 101 can support the parsing of multiple programming languages, including but not limited to Java, Python, C++, etc. In order to achieve support for multiple languages, the source code parsing module 101 includes a language recognition unit, which automatically determines the programming language type of the parsed code by analyzing the extension or file header information of the source code file. This multi-language adaptability provides great flexibility for the system and can be widely used in code parsing and activity diagram generation in different language environments.

[0027] Next, the source code parsing module 101 starts to perform lexical analysis and syntax analysis on the source code. In the lexical analysis stage, the parsing module 101 breaks down the source code into basic language units, called lexical symbols (Tokens), which include keywords, operators, identifiers, constants, etc. Through lexical analysis, the basic structure of the source code is extracted and further processed.

[0028] Subsequently, the source code parsing module 101 parses the lexical symbol sequence through a syntax analyzer to construct an abstract syntax tree (AST). AST is a tree-like data structure that can reflect the hierarchical structure and grammatical relationship of the source code. Each node represents a structure in the source code, such as a variable declaration, function definition, conditional judgment or loop. The syntax analyzer uses a rule set based on context-free grammar to ensure the accuracy of parsing and the integrity of the code structure. Specifically, the syntax analyzer checks the grammatical correctness of the code and parses the code step by step according to the preset grammatical rules. If an error is detected during the syntax analysis process, the source code parsing module 101 also has an error reporting function that can output detailed error information to help developers quickly locate and correct problems in the code.

[0029] After generating the abstract syntax tree, the source code parsing module 101 further optimizes the structure of the AST. This process involves simplifying and standardizing the AST, such as removing irrelevant syntax elements (such as blank lines or invalid comments), merging certain redundant structures, and keeping the logical structure of the code unchanged. This optimization step not only helps to improve the efficiency of subsequent model conversion, but also ensures that the generation process of the activity diagram is more efficient and accurate.

[0030] In order to improve the speed of code parsing, the source code parsing module 101 adopts a parallel parsing mechanism. For larger code files or multi-file projects, the parsing module can process multiple source code files at the same time and allocate multiple threads or processes to perform lexical analysis and syntax analysis. This parallel processing mechanism greatly improves the parsing efficiency and is particularly suitable for the parsing process of large projects or complex code bases.

[0031] In addition to parsing the structure of the code, the source code parsing module 101 can also extract relevant annotation information from the source code. The annotation information often contains instructions related to the business logic or additional developer annotations, which can provide auxiliary basis for the subsequent generation of activity diagrams. The source code parsing module 101 can identify different types of comments in the code (such as single-line comments, multi-line comments, and document comments), and combine this information with the abstract syntax tree of the code to ensure that the mapping relationship between the comments and the code logic is reflected when the activity diagram is generated.

[0032] In actual applications, the source code parsing module 101 works closely with other modules of the system. For example, the abstract syntax tree generated by the parsing module is directly passed to the model conversion engine 102, which further converts the AST into an abstract model of the programming language according to predefined rules. This process is highly dependent on the structured data provided by the source code parsing module 101 to ensure that the logical relationship of the code is accurately reflected in the subsequent steps.

[0033] In general, the source code parsing module 101 is not only one of the basic modules of the system, but also ensures accurate extraction and optimization of the source code structure through its support for multiple languages, parallel parsing mechanism, comment extraction and error reporting functions. This module provides a stable and efficient foundation for subsequent model conversion and activity diagram generation, can adapt to different development environments and code sizes, and is the core component for realizing automatic generation of code activity diagrams.

[0034] Furthermore, the source code parsing module performs lexical analysis on the source code through the cooperation of a lexical analyzer and a syntax analyzer, extracts keywords, identifiers and symbols in the source code, and constructs an abstract syntax tree through syntax analysis.

[0035] First of all, the main task of the lexical analyzer is to decompose the character sequence in the source code into lexical units, which are the basic elements in the programming language, such as keywords, identifiers, operators, constants, and separators. The lexical analyzer identifies these basic lexical elements by scanning the source code file and assigns a corresponding category to each element. For example, 'if' is identified as a keyword for conditional judgment, 'x' is identified as an identifier, and '+' is identified as an operator. The result of the lexical analysis is a list of lexical units, which retains the logical order of the source code and provides structured data input for the subsequent syntax analyzer.

[0036] The process of lexical analysis is not just a simple character segmentation of the source code. The lexical analyzer must be able to recognize the grammatical rules of the programming language to ensure that identifiers and keywords can be accurately distinguished. In addition, the lexical analyzer needs to handle comments and whitespace characters in the source code. Normally, comments do not affect the execution of the code, so the lexical analyzer will identify and mark the comments as ignorable elements, and process whitespace symbols in the code (such as spaces, line breaks, etc.) to ensure the integrity of the code structure. In this process, the lexical analyzer also has a certain fault tolerance. If illegal characters or format errors are found in the source code during the parsing process, the system will generate error prompts in time to facilitate developers to correct them.

[0037] Next, the list of lexical units generated by the lexical analyzer will be passed to the syntax analyzer. The syntax analyzer performs structured analysis on the lexical units according to the syntax rules of the programming language and constructs an abstract syntax tree (AST) corresponding to the source code. The abstract syntax tree is a tree structure, and each node represents a grammatical structure unit in the code, such as an expression, statement, function definition, or control structure. The syntax analyzer gradually builds this tree by analyzing the order and nesting relationship of lexical units so that it can reflect the hierarchical structure of the source code. For example, the conditional judgment and execution body of the 'if' statement will be parsed as child nodes of the 'if' node, while the control condition and loop body of the loop statement will form an independent loop structure node.

[0038] The role of a parser is not only to convert source code into an abstract syntax tree, but also to ensure the syntactic correctness of the code. By defining and following the context-free grammar rules of a programming language, a parser is able to check for syntax errors in the code. For example, it can identify problems such as unmatched brackets, incomplete statement structures, or undefined function calls. If the parser finds an error in the code, it generates a corresponding error message and indicates the location and type of the error, helping developers quickly locate and fix the problem.

[0039] During the construction of the abstract syntax tree, the parser can also optimize and simplify the code structure. For example, for some redundant expressions or unnecessary nested structures, the parser can optimize when building the tree, thereby simplifying the structure of the code and providing a more efficient data foundation for subsequent model conversion. This optimization process does not change the logic of the source code, but improves the parsing efficiency of the system by streamlining the code structure.

[0040] Finally, the lexical analyzer and the syntax analyzer work together to generate a complete abstract syntax tree. This tree not only retains the logical structure of the source code, but also presents elements such as keywords, identifiers, and operators in the code in a structured form, providing the necessary basic data for the next step of the system (such as the generation of the abstract model of the programming language and the creation of the activity diagram). According to the above detailed description, those skilled in the art can easily implement the specific functions of the source code parsing module through the existing lexical analysis and syntax analysis technologies.

[0041] Furthermore, the source code parsing module is used to parse source code of multiple programming languages, including Java, Python and C++, and dynamically adjust the parsing process according to the grammatical rules of the programming language.

[0042] When the source code parsing module receives a source code file, the system first automatically identifies the programming language type of the file through the file extension or feature information in the file header. For example, the extension of a Java file is usually ".java", a Python file is ".py", and a C++ file may be ".cpp" or ".h". Through this file type identification mechanism, the system can quickly determine which type of parsing rules need to be applied. Next, the source code parsing module will dynamically load the lexical analysis and syntax analysis rule sets corresponding to the language based on the identified programming language type.

[0043] For each programming language, the syntax and structure of the source code will be different. Take Java as an example. Java is an object-oriented programming language, and its source code structure includes classes, interfaces, methods, fields, and access modifiers. Therefore, when parsing Java code, the source code parsing module needs to identify and process these specific language elements and build an abstract syntax tree that conforms to the characteristics of the Java language. On the contrary, for an interpreted language such as Python, because its syntax is more flexible and dynamic, the source code parsing module needs to pay attention to the indentation hierarchy and dynamic type variable definition when processing Python code.

[0044] As a more complex compiled language, C++ not only includes object-oriented features, but also supports advanced language features such as multiple inheritance and template metaprogramming. Therefore, when the source code parsing module processes C++ code, it must not only parse basic class, function and variable definitions, but also must process templates, macro definitions and grammar rules related to memory management. To this end, the system will adjust the parsing depth according to the complexity of C++ to ensure that all language features can be correctly identified and parsed.

[0045] Another feature of the source code parsing module is its ability to dynamically adjust the parsing process. There are differences in the code structure of different programming languages. When dealing with these differences, the parsing module can automatically adjust the parsing strategy according to the specific rules of the language. For example, function and method calls in Java and C++ are based on static types, so the lexical analyzer and syntax analyzer can parse based on a clear type system. Python is a dynamically typed language, and its variable types are determined at runtime. Therefore, when parsing Python code, the source code parsing module needs to adopt a more flexible strategy to handle the dynamic binding of variables and function calls. By dynamically adjusting the parsing strategy, the system can accurately parse various types of programming languages ​​without affecting efficiency.

[0046] In addition, the source code parsing module also supports cross-language code parsing. In modern software development, projects are often composed of a mixture of multiple programming languages, such as using Java and Python simultaneously in a system to handle different business logics. In order to adapt to this multi-language development environment, the source code parsing module has multi-language collaborative parsing capabilities. It can automatically switch language rule sets when processing different code files of the same project, and uniformly manage the parsing results of each language. This multi-language support provides great convenience for developers and ensures the compatibility and scalability of the system in complex environments.

[0047] Through this dynamic adjustment of the parsing process based on the characteristics of the programming language, the source code parsing module can accurately handle multiple programming languages ​​and generate an abstract syntax tree that conforms to the characteristics of each language, laying the foundation for subsequent activity diagram generation. The design of this module is not only suitable for common programming languages, but also extensible, and can easily add support for other languages.

[0048] The model conversion engine 102 is configured with a set of parsing rules based on the query view conversion specification operation, and is used to parse the method call relationship and statement execution order in the abstract syntax tree, and convert the source code into a programming language abstract model.

[0049] The model conversion engine 102 is a key component in the automatic code activity diagram generation system of the present invention, and its function is to convert the abstract syntax tree (AST) generated by the source code parsing module 101 into an abstract model of a programming language so as to further generate an activity diagram. The engine is based on the query view transformation specification (QVT, Query / View / Transformation), which is a standardized framework for model conversion, and can realize the conversion between different models, especially playing an important role in the conversion process from the abstract syntax tree to the abstract model.

[0050] The core of the model conversion engine 102 lies in a set of parsing rules configured therein, which define how to extract structural information related to method call relationships and statement execution order from the abstract syntax tree. Each parsing rule operates on a specific programming language structure, such as class definition, function call, control flow statement (such as conditional judgment, loop), etc. Through these rules, the model conversion engine 102 can identify key elements in the source code and map them to the abstract model of the programming language. The engine not only supports basic language structures, but also can handle complex nested calls, recursive calls and other advanced language features, thereby ensuring the integrity and accuracy of the code structure.

[0051] In the specific operation process, the model conversion engine 102 first receives the abstract syntax tree generated by the source code parsing module. The nodes in the abstract syntax tree represent the various language structures in the source code. These nodes are organized according to the grammatical rules to form a hierarchical structure of the code. The model conversion engine first identifies the root node in the abstract syntax tree and processes each child node in turn. For each node, the model conversion engine extracts the information in the node according to the corresponding parsing rules. For example, if a node represents a function call, the conversion engine extracts the name, parameters and return value type of the function, and generates a corresponding function call object in the programming language abstract model. In this way, the abstract syntax tree is gradually converted into an abstract model of the programming language.

[0052] The model conversion engine 102 can handle multiple programming languages, so its parsing rules can be adjusted according to the grammatical characteristics of different languages. For example, for object-oriented languages ​​(such as Java or C++), the engine will focus on class inheritance, interface implementation, and polymorphism processing; while for scripting languages ​​(such as Python), it pays more attention to functional programming features and dynamic type parsing. Therefore, the model conversion engine is configured with a language adaptation module, which can identify the language type of the source code and select the corresponding parsing rule set according to the specific syntax and structure of the language, thereby ensuring that each programming language can be accurately processed.

[0053] In addition to syntax parsing, the model conversion engine 102 also has a semantic analysis function. Semantic analysis is a deeper understanding of the code logic, beyond the superficial grammatical rules. For example, when dealing with variable scope, the conversion engine needs to determine the life cycle of the variable and its scope in different functions and classes to ensure the logical consistency when the activity diagram is generated. Through semantic analysis, the model conversion engine can understand the dependencies in the code, the call chain between methods, and the interaction between global variables and local variables. This process is crucial to ensure that the generated activity diagram can accurately reflect the code logic.

[0054] In addition, the model conversion engine 102 takes full account of the dynamic characteristics of the code. For example, in some cases, the source code may contain characteristics such as conditional compilation, dynamic type binding, or runtime reflection, which are difficult to statically analyze during compilation. In order to solve this problem, the model conversion engine is equipped with a dynamic analysis module that can obtain the actual execution path of the code under different conditions by simulating the running environment of the code when necessary. In this way, the conversion engine can generate a more complete abstract model, thereby ensuring the accuracy of the activity diagram.

[0055] The model conversion engine also supports incremental conversion. In the actual development process, the source code may be frequently updated or modified, and re-parsing the entire code from scratch and generating activity diagrams may consume a lot of time. To this end, the model conversion engine can identify the changed parts of the source code and re-parse and convert only the modified code fragments without fully parsing the entire code base. This incremental conversion mechanism greatly improves the efficiency of the system, especially for large code bases and complex systems.

[0056] After the abstract model is generated, the model conversion engine 102 will store the generated model in the model warehouse 103 for further use by the activity diagram generator 104. In order to ensure the efficiency of data transmission and storage, the model conversion engine also has model compression and optimization functions, which can reduce the size of the abstract model by eliminating redundant nodes and simplifying the data structure, thereby accelerating the generation process of the activity diagram.

[0057] In general, the model conversion engine 102 is one of the core components of the system for realizing automatic code activity diagram generation. Through flexible parsing rules, multi-language support, semantic analysis and incremental conversion, it ensures that the complex structure of the source code can be accurately converted into an abstract model of the programming language, providing a solid foundation for subsequent activity diagram generation.

[0058] The model warehouse 103 is used to store the programming language abstract model and identify the programming language type according to the extension of the source code file to match the corresponding programming language abstract model.

[0059] The model warehouse 103 is an important component responsible for storing and managing the programming language abstract models generated by the model conversion engine 102. Its role is not just a simple storage function, but also includes classification, indexing, retrieval and version management of the stored models. The model warehouse plays a key role in connecting the upper and lower parts of the entire system, because the activity diagram generator 104 relies on extracting abstract model data from the model warehouse to generate the corresponding activity diagram.

[0060] First, the model warehouse 103 has the ability to automatically identify and match programming language types. The source code files in the system may use different programming languages ​​(such as Java, Python, C++, etc.), and each language has a unique syntax and structure. In order to ensure that the model warehouse can correctly process and store abstract models generated by different programming languages, the model warehouse uses the extension of the source code file to automatically identify the programming language type. For example, a file with an extension of ".java" corresponds to the Java language, and a file with an extension of ".py" corresponds to the Python language. In this way, the model warehouse can store the corresponding abstract model under the corresponding language classification according to the identified language type.

[0061] During the storage process, the model warehouse 103 not only stores the abstract models in categories, but also improves the efficiency of data retrieval by establishing an index structure. For each abstract model of a programming language, the warehouse generates a unique identifier (ID) for quickly locating the model. This identifier is not only related to the source code file name, but also contains the version information and other metadata of the source code, such as creation time, modification time, etc. Through these indexes, the warehouse can support fast query and retrieval of model data, especially when processing a large number of code files. This index mechanism can significantly improve the response speed of the system.

[0062] In addition, the model warehouse 103 supports version management. In the actual software development process, the source code will be continuously updated and iterated over time. In order to track different versions of source code and their corresponding abstract models, the model warehouse can generate historical version records for each abstract model. Whenever the source code is changed, the warehouse will store the new abstract model as a new version and keep the record of the old version. This version management function allows developers to easily view the status of the code at different time points or compare the changes of different versions. At the same time, if the activity diagram generator needs to generate a historical version of the activity diagram, the model warehouse can provide the corresponding historical abstract model data to ensure that the activity diagram reflects the code logic of a specific version.

[0063] The model warehouse 103 also has data compression and optimization functions. In large projects, source code files may be very large, and the corresponding abstract models will also take up a lot of storage space. In order to optimize storage efficiency, the model warehouse can compress the abstract model. This compression is not a simple file compression, but an optimization for the model structure, such as merging redundant nodes, removing useless intermediate data, simplifying repeated code segments, etc. Through these optimization measures, the model warehouse can minimize the use of storage space without affecting data integrity. At the same time, the compressed model data is also more efficient when it is retrieved and transmitted, thereby improving the performance of the entire system.

[0064] During the operation of the system, the model warehouse 103 maintains close interaction with the activity diagram generator 104. When the activity diagram generator needs to generate an activity diagram for a certain code segment, it sends a request to the model warehouse. Based on the information in the request, such as the source code file name, programming language type, version number, etc., the model warehouse quickly retrieves the corresponding programming language abstract model and passes it to the activity diagram generator for subsequent processing. The efficient retrieval mechanism of the model warehouse ensures that the system can quickly respond to the needs of developers and generate real-time and accurate activity diagrams.

[0065] In order to ensure data consistency and integrity, the model warehouse also has concurrency control and access rights management functions. In a multi-person collaborative development environment, multiple developers may modify the same code base at the same time. The model warehouse uses a concurrency control mechanism to ensure that data will not conflict or be lost when multiple users access and modify abstract models at the same time. At the same time, the model warehouse can limit the access or modification operations of specific models to different users based on their permissions to ensure the security and stability of the system.

[0066] In general, the model warehouse 103 is not just a storage module, it is the core data management center of the entire system. Through a series of functions such as automatic recognition of programming languages, classified storage, version management, data compression optimization, and concurrency control, the model warehouse provides strong support for efficient management and fast retrieval of abstract models.

[0067] Furthermore, the model repository stores programming language abstract models via a hash table; and uses the extension and unique identifier of the source code file as a hash key to quickly retrieve abstract models of different programming languages.

[0068] A hash table is an efficient data structure whose main feature is to map data directly to storage locations by calculating hash keys to achieve fast retrieval. In this system, the model warehouse generates a unique storage location for each abstract model of a programming language through a hash table, which greatly improves the efficiency of data retrieval.

[0069] The hash key is generated by combining the source code file extension and a unique identifier. The source code file extension is used to identify the programming language type of the code, such as ".java" for Java and ".py" for Python. The unique identifier is used to ensure that the hash key of each file is unique, avoiding conflicts caused by different source code files that may have the same extension. This combination ensures that the system can quickly and accurately find the corresponding data when storing and retrieving programming language abstract models, whether in multiple files of the same programming language or in projects of multiple different programming languages.

[0070] Furthermore, the model repository includes a version management unit for storing and retrieving multiple versions of programming language abstract models of the same source code file and comparing differences between different versions.

[0071] The version management unit in the model repository plays a key role in version control of the abstract model of programming languages. The version management unit allows the system to store multiple versions of the abstract model of programming languages ​​for the same source code file, and ensures that each version can be stored and retrieved independently based on the modification and iteration of the source code. In this way, when the source code changes, the system can not only save the latest version, but also retain the historical version for subsequent viewing and use.

[0072] In actual operation, when a source code file is modified, the version management unit will store the updated programming language abstract model as a new version and generate a unique identifier for each version. These identifiers ensure that each version can be accurately traced and located. Users can use the version management unit to retrieve the source code version at a specific point in time and generate the corresponding activity diagram to facilitate the tracing and review of code history.

[0073] In addition, the version management unit also has a comparison function that can analyze and display the differences between different versions. The system compares multiple versions of the programming language abstract model to identify the added, deleted or modified parts. This function is extremely useful for developers when performing code maintenance, updating or debugging, because it can intuitively display the specific changes in the source code between different versions, helping developers better understand and manage the evolution of the code.

[0074] The activity diagram generator 104 is connected to the model warehouse and is used to generate an activity diagram according to the programming language abstract model. The activity diagram includes an activity diagram generated based on logic code and an activity diagram generated based on code comments.

[0075] The activity diagram generator 104 is a key component in the system. Its main function is to extract the abstract model of the programming language from the model warehouse 103 and generate an accurate activity diagram based on the model. The operation process of this component is complex and involves a variety of technical details. Its work is not only to simply convert the abstract model into a graphical representation, but also to ensure the accuracy, readability and logical consistency of the activity diagram with the source code through multiple steps.

[0076] First, the activity diagram generator 104 extracts the required programming language abstract model from the model warehouse 103. The model is generated by the model conversion engine 102 and contains the core structural information of the source code, such as method call relations, statement execution order and other logical flows. The first step of the activity diagram generator is to parse this information and establish a relationship network between various logical units, especially the hierarchical relationship and dependency relationship between function calls. This parsing process requires detailed analysis of each node and connection in the abstract model to ensure that the generated activity diagram can reflect the actual code execution process.

[0077] One of the core features of the activity diagram generator is its ability to generate two types of activity diagrams: logic code-based activity diagrams and code comment-based activity diagrams. For logic code activity diagrams, the generator needs to directly extract the method call chain in the code and display information such as the calling order, conditional judgment, and loop structure between each method. This process requires the activity diagram generator to accurately identify the control flow in the code, such as 'if-else' branches, 'for' and 'while' loops, exception handling, etc. Each control flow structure is represented differently in the activity diagram, and the activity diagram generator needs to convert them into corresponding graphic elements, such as branch nodes, loop nodes, etc., to ensure that the activity diagram accurately presents the logical relationship in the code.

[0078] For activity diagrams based on code comments, the activity diagram generator 104 focuses on displaying business logic. Comment information is usually added by developers in the code to explain the function or business process of a certain code segment. This type of activity diagram mainly serves non-technical personnel, so the generator needs to extract the comments related to the business logic in the code, ignore the technical details, and only retain the high-level business process reflected in the comments. The generator matches the comments with the corresponding code segments and displays the business logic expressed by these comments in a graphical way, so that business personnel can quickly understand the business operation of the system through the activity diagram.

[0079] Another key function of the activity diagram generator 104 is the optimized generation of graphic elements. The activity diagram not only needs to accurately reflect the code logic, but also needs to be easy to understand and beautiful. To this end, the activity diagram generator must automatically adjust the graphic layout according to the logical hierarchy in the abstract model so that the graphics are clear and intuitive. The generator adjusts the size and position of the nodes according to the role of each node and its importance in code execution. Important nodes (e.g., main functions or key logic control points) are usually displayed in an enlarged manner and placed in the center of the graph, while minor nodes are displayed in a smaller form. Through this dynamic adjustment, the activity diagram generator can generate activity diagrams with good readability, reduce the complexity of the graph, and avoid overcrowding between nodes.

[0080] In addition, the activity diagram generator 104 also has the ability to generate interactive activity diagrams. In modern software development environments, static activity diagrams may not fully meet the needs of developers and business personnel. In order to solve this problem, the activity diagram generator can generate an interactive graphical interface, and the user can click on a node in the activity diagram to view the source code fragment corresponding to the node, or click on the connection line to view the specific call relationship or execution path. This interactive function can not only improve the practicality of the activity diagram, but also provide developers with a convenient means to quickly locate and understand the code.

[0081] The efficiency of the activity diagram generator is particularly important when dealing with large code bases. To this end, the generator supports parallel processing and incremental generation. For large code bases, the activity diagram generator is able to generate activity diagrams in parallel by assigning multiple threads or processes to process different code modules separately. For incremental updates to the code, the activity diagram generator can regenerate activity diagrams only for the modified code parts, without completely re-parsing and regenerating activity diagrams for the entire system. This parallel and incremental generation mechanism greatly improves the performance of the system, especially when facing complex, frequently iterated projects, which can greatly save time and computing resources.

[0082] The activity diagram generator 104 can also adapt to a variety of different graphic output formats. The generator can not only generate static image files (such as PNG, SVG, etc.), but also support the generation of embeddable HTML pages, PDF documents and other formats, so that users can output and share according to different needs. This multi-format support ensures that the activity diagram can be applied to different scenarios, whether it is internal code review or external customer presentation, the generator can meet the needs.

[0083] In general, the activity diagram generator 104 plays a core role in the system to transform the abstract model into a specific visual graph. Through efficient model parsing, logically accurate graph generation, graph layout optimization, interactive function support and multi-format output, the activity diagram generator ensures that the code logic and business process can be presented to the user in the most intuitive and clear way.

[0084] Furthermore, the activity diagram generator includes a multi-perspective activity diagram generating unit, and the multi-perspective activity diagram generating unit is used to generate an activity diagram from multiple perspectives according to different user needs, wherein the perspectives include: Developer perspective, used to show detailed code execution logic; Business personnel perspective, used to generate simplified business logic activity diagrams based on code comments; The historical version perspective is used to display the system's functional iteration or code modification history.

[0085] This multi-perspective generation mechanism ensures that the activity diagram not only meets the needs of technical developers, but also provides a simplified business process display for business personnel and project managers, and can even help developers trace historical code modifications.

[0086] From the developer's perspective, the activity diagram generated by the multi-perspective activity diagram generation unit focuses on showing the detailed execution logic of the code. The activity diagram from this perspective contains all key code paths, function calls, conditional judgments, loops and other structures, helping developers understand the overall logical flow of the system and providing visual support for debugging, optimization and function expansion. This perspective helps technicians quickly locate problems and understand complex code interactions.

[0087] The business perspective focuses on generating simplified business logic activity diagrams. By analyzing the annotation information in the code, the multi-perspective activity diagram generation unit can extract content related to the business process and ignore the specific technical implementation details. This type of activity diagram is designed to help non-technical personnel, such as project managers, product managers, or customers, quickly understand the business logic process of the system and facilitate communication and decision-making. This simplified graphical display makes complex technical details intuitive and clear, promoting efficient connection between business needs and technical implementation.

[0088] In addition, the historical version perspective allows users to view the process of system function iteration or code modification. The multi-perspective activity diagram generation unit obtains different historical versions of code through the version management unit and generates activity diagrams showing their functional changes. In this way, users can intuitively see the functions and code structures that are added, deleted or modified between different versions, helping the development team to trace problems or understand how a certain function has evolved. This function is particularly important in code review, system upgrade or project handover.

[0089] By combining different perspectives, the activity diagram generator provides users with flexible visualization support, allowing users of different roles to quickly obtain system information related to their needs.

[0090] Furthermore, the activity diagram generator converts each logic node in the programming language abstract model into a visual activity diagram node through a graphic rendering engine, and draws the connection lines between the nodes according to the function call relationship.

[0091] The activity diagram generator relies on a graphics rendering engine to convert the logic nodes in the abstract model of the programming language into visual activity diagram nodes. This conversion process not only involves accurate analysis of the code logic, but also requires the abstract program structure to be presented in a graphical way so that users can intuitively understand the logical flow of the system.

[0092] In this system, the programming language abstract model has abstracted the basic structure of the code, function call relationships, conditional judgments, etc. into nodes and relationships in the model through the aforementioned parsing and conversion. On this basis, the task of the graphics rendering engine is to convert these nodes into specific graphic elements, usually in the form of geometric shapes (such as rectangles, circles, or diamonds). Each logical node (such as function, method, class) will be converted into a corresponding activity diagram node, and the shape, size, and position of these nodes are dynamically calculated and drawn by the rendering engine.

[0093] In addition to node generation, the graphics rendering engine is also responsible for drawing lines between nodes based on function call relationships. The purpose of lines is to show the calls, dependencies, and data flow between logical modules in the program. The rendering engine not only needs to consider the starting and ending points of the lines, but also needs to optimize the paths of the connecting lines based on the node layout to avoid too many crossings, thereby keeping the graphics neat and readable. In some complex code structures, the rendering engine may need to use curves or polylines to ensure that the lines can bypass other nodes without obstructing the main structure of the graphics.

[0094] In addition, the graphics rendering engine can adjust the styles of nodes and lines according to user needs. For example, developers can choose to highlight certain key function nodes, or adjust the color or size of nodes according to the frequency and importance of function calls. This flexible graphics rendering method ensures that the generated activity diagram not only accurately displays the logical relationship of the code, but also provides personalized graphics presentation based on the different concerns of users.

[0095] Through the graphics rendering engine, the activity diagram generator can transform the abstract programming model into an intuitive and clear activity diagram, enabling users to better understand the system's operating logic and the relationships between modules.

[0096] Furthermore, the layout module includes a graph optimization unit, which adjusts the node layout of the activity graph based on a multi-objective optimization algorithm to reduce the distance deviation between nodes, reduce the number of crossings of connection lines, and optimize the alignment of nodes. The multi-objective optimization algorithm is solved by a constraint optimization model provided by the following formula (1):

[0097] in, Indicates and The logical connection weight between nodes is determined based on the calling relationship and dependency degree of the nodes; Indicates and The Euclidean distance between nodes; is the ideal distance determined based on logical relationships; Indicates The length of the connecting line; is the length of the longest connecting line in the figure; Indicates The number of crossings of the connecting lines; Indicates The alignment deviation of nodes; is the number of lines with the most crossing times in the graph; is the maximum alignment deviation in the current graph; Represents the energy value in the node layout; Indicates The distance between a node and the activity graph boundary; is the minimum boundary distance among all nodes; Indicates the number of nodes; Indicates the number of connection lines; , , and is a trade-off parameter; An adjustment parameter to balance the effect of connection line length and number of crossovers.

[0098] The graph optimization unit adjusts the node layout in the activity graph based on a multi-objective optimization algorithm so that the distance between nodes, the intersection of connecting lines, the alignment of nodes, and the distance between nodes and the graph boundary can all reach the optimal state. To achieve this goal, the system solves the constrained optimization model defined by formula (1).

[0099] The core of formula (1) is a multi-objective optimization function, whose goal is to minimize multiple parameters related to graph layout at the same time. First, the first term in the formula: Represents the balance between the logical connection and physical distance between each pair of nodes in the activity diagram. Specifically, Indicates Nodes and The logical connection weight between nodes. The weight is calculated based on the call relationship and dependency between nodes. The higher the weight, the closer the logical relationship between the two nodes, so the system will try to place them close together in the graph.

[0100] Logical connection weight The calculation process is based on two nodes (i.e. Nodes and The weight is determined by the calling relationship and dependency between nodes, reflecting the closeness of their interaction in the code logic. The higher the weight, the closer their logical relationship is, so when laying out the activity diagram, the system tends to place them closer. The following is a simple example to illustrate how the weight is calculated.

[0101] Suppose there is a program with four functions: A, B, C, and D. The calling relationship between these functions is as follows: 1. A calls B and C.

[0102] 2. B calls D.

[0103] 3. C depends on the result of D.

[0104] According to this example, the calculation of logical connection weight can be based on the following factors: 1. Direct call relationship: If one node directly calls another node, it means there is a direct logical connection between the two. The system will give a higher weight to this direct call relationship.

[0105] 2. Indirect call relationship: If two nodes do not call each other directly, but they are indirectly connected through other nodes, their logical connection is relatively weak, but still exists. The system can assign appropriate weights to indirect calls based on the length and frequency of the call chain.

[0106] Dependency: If the execution of one node depends on the result of another node, then their logical connection is also close.

[0107] Numerical weights can be assigned to the above logical relationships: Direct call relationship: Assume that the weight of direct call is 1.0.

[0108] Indirect call relationship: Assume that the weight of indirect call is 0.5.

[0109] Dependencies: Assume that the weight of a dependency is 0.8.

[0110] Calculate the logical connection weight between each pair of nodes based on these weights : (A calls B directly); (A calls C, directly); (A calls D indirectly, through B); (B calls D, directly); (C depends on the result of D).

[0111] Therefore, according to these weights, when generating an activity diagram, the system will tend to place A close to B and C, and B close to D, and C close to D, but relatively speaking, the distance between A and D will be slightly farther because their logical connection is weaker.

[0112] In this way, the system can reasonably layout the nodes in the activity diagram according to the logical connection between each node, ensure that the nodes that are closely connected logically are close to each other in the diagram, and enhance the readability and logical coherence of the activity diagram.

[0113] Indicates Nodes and The Euclidean distance between nodes is calculated by the difference in the physical positions of the nodes on a two-dimensional plane.

[0114] The second term of the formula: Involves optimization of connecting lines. Indicates The length of the connecting line, Indicates Minimizing the length of connecting lines can reduce visual clutter and make the diagram more compact. At the same time, reducing the number of crossings of connecting lines can prevent lines from overlapping each other in the diagram, thereby enhancing the neatness and readability of the activity diagram. By adjusting the trade-off parameters ,The system can flexibly weigh the impact of connection line length and number of crossings on the layout.

[0115] Item 3: Used to focus on the alignment of nodes. Indicates The alignment deviation of each node is a measure of how far the node deviates from the ideal alignment position. For some activity diagrams, keeping the nodes aligned horizontally or vertically helps to structure and clarify the diagram. The ideal alignment position can be obtained through experimental data or set based on expert knowledge.

[0116] Item 4: Used to control the distance between nodes and the border of the graph. Indicates By minimizing the distance between each node and the border of the activity graph, the system can ensure that the node is not too close to the edge of the graph, avoiding the situation where the graph layout is too compact or nodes appear outside the border. This optimization plays a key role in ensuring the overall aesthetics and visual balance of the activity graph.

[0117] In the optimization formula, Indicates the number of nodes, Indicates the number of connection lines. , , , are trade-off parameters, which are used to adjust the priority of different optimization objectives. By adjusting the values ​​of these parameters, the system can find a balance between maintaining node distance, reducing line crossing, optimizing alignment, and maintaining boundary distance. In formula (1), , , , and The recommended values ​​are 0.2, 0.3, 0.5, 0.6 and 0.4 respectively.

[0118] The layout module 105 is used to determine the position, size and shape of each node in the activity diagram by parsing the method call relationship and code execution path in the programming language abstract model, and generate connection lines between nodes.

[0119] The layout module 10 plays a vital role in the system. Its task is to determine the position, size and shape of each node in the activity diagram based on the information in the abstract model of the programming language, and generate the connection lines between the nodes. This process not only involves the analysis and restoration of the code logic, but also requires intelligent optimization of the graphic layout to ensure the readability and aesthetics of the activity diagram.

[0120] The layout module 105 first needs to parse the programming language abstract model generated from the model conversion engine 102, which includes detailed information on method call relationships, code execution order, and control structures (such as conditional branches and loops) in the source code. The layout module identifies the logical nodes in the activity diagram by analyzing this information, and each node usually represents a method, function, or control structure in the source code. In this process, the layout module must accurately capture the hierarchical structure of the code logic, such as the parent-child function call relationship, the nested logic in the loop, the branch structure of the conditional judgment, etc. By parsing these structures, the layout module can ensure that the placement of each node is consistent with its logical hierarchy in the code.

[0121] In order to ensure that the generated activity diagram has a good visualization effect, the layout module 105 uses a set of complex algorithms to dynamically adjust the position and size of the nodes. For a complex code structure, the number of nodes may be very large. If there is no reasonable layout algorithm, the activity diagram can easily become confusing and difficult to read. Therefore, the layout module adjusts the size and position of each node according to its importance and frequency in code execution. For example, the main function or the frequently called function will be enlarged and placed in the center or prominent position of the diagram, while the secondary nodes will be reduced and placed in a relatively secondary position. This dynamic adjustment of the node size helps users quickly identify the key nodes in the activity diagram and helps improve the overall readability of the diagram.

[0122] In terms of node layout, the layout module 105 reduces the problem of crossing connection lines between nodes through optimization algorithms. Crossing of connection lines is a major problem that affects the readability of activity diagrams, especially when there are many nodes and complex logic. Too many crossing connection lines will make the activity diagram difficult to understand. In order to solve this problem, the layout module uses force-directed algorithms, hierarchical layout algorithms and other technologies to reasonably arrange the layout of nodes, so that logically related nodes are as close as possible, avoid long-distance connections, and minimize the crossing of connection lines. The force-directed algorithm simulates the gravitational and repulsive forces in physics to ensure that related nodes are close and unrelated nodes are separated, thereby forming a clear graph structure. The hierarchical layout algorithm is used to process code logic with a clear hierarchical structure, such as function call chains and recursive calls. These logics are usually expressed in a tree structure. The layout module arranges these nodes in layers to ensure a clear presentation of the call chain.

[0123] In addition to optimizing the position and size, the layout module 105 also needs to intelligently adjust the shape of each node. The shape of the node should not only match its logical function, but also maintain uniformity and beauty in the graph. For example, function call nodes are usually represented by rectangles, while conditional judgment nodes may be represented by diamonds or circles. Such shape distinction helps users to quickly understand the function of each node visually. The layout module automatically selects appropriate graphic elements for display by parsing the type of each node to ensure the simplicity and consistency of the graph.

[0124] The layout module 105 is also responsible for generating connecting lines between nodes, which represent method calls or control flow transfers in the code. The layout module not only needs to determine the starting and ending points of each connecting line, but also needs to optimize the path of the connecting line to ensure that the connecting line does not overlap with the node and avoids crossing with other connecting lines as much as possible. The optimization of the connecting line usually uses Bezier curves or broken lines, so that the lines can flexibly adjust the path in a limited space and maintain the logical relationship with the nodes. For some complex code logic, the connecting line may need to be bent multiple times to avoid interference from other nodes or lines. The layout module can dynamically adjust these paths according to the complexity of the graphics, so that the activity diagram as a whole looks more concise and clear.

[0125] In some advanced applications, the layout module 105 can also implement dynamic layout adjustment functions. For very complex systems, users may want to interactively operate the activity diagram, such as manually moving nodes, adjusting node sizes, or viewing the detailed logic of a certain part of the code. The layout module supports these interactive functions, allowing users to freely adjust the graphic layout after the activity diagram is generated while maintaining the overall consistency of the graphic structure. In order to support this interaction, the layout module also provides the ability to update in real time. When the user manually modifies the graphic layout, the system will automatically recalculate the layout of other nodes and lines to ensure that the entire graphic is always in the optimal state.

[0126] The design of the layout module 105 also takes into account the adaptability of different screen sizes and output devices. Whether the activity diagram is displayed on a large screen or printed out, the layout module can automatically adjust the scaling and layout structure of the diagram according to the resolution and size of the output device. In this way, no matter what platform it is displayed on, the activity diagram can maintain clear readability and adapt to different display environments.

[0127] In general, the layout module 105 is not just a simple graphics generation tool. It uses complex algorithms and intelligent optimization techniques to ensure that the generated activity diagram is visually clear and beautiful, while accurately reflecting the logical structure of the code.

[0128] Furthermore, the automatic code activity diagram generation system further includes a code processing flow complexity adjustment unit, which is used to calculate the complexity of the code processing flow according to the abstract syntax tree generated by the source code, and adjust the number of nodes of the activity diagram according to the code processing complexity, wherein the calculation formula of the code processing complexity is calculated using the following formula (2):

[0129] in, Indicates the complexity of the code processing flow; Indicates The number of executed statements in a code snippet; Indicates The branch depth in a code snippet; Indicates The length of the function call chain; Indicates The dependency depth of a function; Indicates The number of parameters of the function; and Represents the number of code snippets and functions respectively; The code processing flow complexity adjustment unit adjusts the number of nodes and detail of the activity diagram based on the following rules: When the calculated code processing complexity When the preset first threshold is exceeded, the details inside the function are merged into a single node in the activity diagram, and only the high-level logic of the function call sequence is retained; When the calculated code processing complexity When a preset second threshold is exceeded, multiple related code snippets are merged into a single node in the activity graph; wherein the second threshold is greater than the first threshold; When the calculated code processing complexity When the value is lower than the preset third threshold, the detailed execution logic within the function is displayed in the activity diagram, including branches, loops, and specific operation steps.

[0130] The automatic code activity diagram generation system also includes a code processing flow complexity adjustment unit. The function of this unit is to calculate the complexity of the processing flow based on the code structure after the source code generates the abstract syntax tree, and dynamically adjust the number of nodes and detail of the activity diagram according to the calculated complexity value. The purpose of this design is to ensure that when the code structure is relatively complex, the readability of the activity diagram will not be affected by too many details, and when the code is relatively simple, it can show more detailed execution logic.

[0131] The code processing flow complexity adjustment unit uses formula (2) to calculate the complexity of the code processing flow, where: Represents the overall complexity of the code, and the specific calculation includes two parts. Part 1: Used to evaluate the complexity of code snippets, Indicates The number of executed statements in a code snippet, and It indicates the branch depth of the code snippet. Branch depth usually refers to the nesting level of conditional judgment or loop structure. The deeper the nesting, the higher the branch depth. Divide by ,Complexity calculation can reasonably reflect the impact of branch structure on the logic complexity of the code.

[0132] Part II: Used to measure the complexity of function calls. Indicates The length of the call chain of a function, that is, how many other functions are called by this function. Indicates the dependency depth of the function, which refers to the level of function calls or the degree of nesting of dependencies. Indicates the number of parameters of the function. The more parameters, the higher the complexity of the function. Therefore, the length and dependency depth of the function call chain increase the complexity exponentially.

[0133] Based on this formula, the system can dynamically adjust the number of nodes and detail of the generated activity diagram. Specifically, when the code handles the complexity When the preset first threshold is exceeded, the system determines that the code structure is relatively complex, so the details inside the function will be merged into a single node in the activity diagram, retaining only the high-level logic of the function call sequence. This helps to simplify the diagram and avoid showing too many details that make the diagram too complicated. If the second threshold is further exceeded (the value is greater than the first threshold), the system will take more radical measures to merge multiple related code snippets into one node to reduce the number of nodes in the activity diagram, making the activity diagram more concise and clear.

[0134] On the contrary, if the code handles the complexity Below the preset third threshold, the system determines that the code structure is relatively simple, so it will show more details in the activity diagram. In this case, the activity diagram will include the detailed execution logic within the function, showing each branch, loop and specific operation steps, helping users to deeply understand the specific process of code execution.

[0135] In the above embodiment, an automatic code activity diagram generation system is provided. Correspondingly, the present application also provides an automatic code activity diagram generation method. Figure 2 , which is a flow chart of an embodiment of an automatic code activity diagram generation method of the present application. Since this embodiment, i.e., the second embodiment, is basically similar to the first embodiment, the description is relatively simple, and the relevant parts can refer to the partial description of the first embodiment. The method embodiment described below is only illustrative.

[0136] The second embodiment of the present application provides an automatic code activity diagram generation method, comprising: Step S201: extracting source code from a code file, and generating an abstract syntax tree corresponding to the source code; Step S202: based on the query view conversion specification operation, using a set of configured parsing rules, parsing the method call relationship and statement execution order in the abstract syntax tree, and converting the source code into a programming language abstract model; Step S203: storing the programming language abstract model in a model repository, and identifying the programming language type according to the extension of the source code file to match the corresponding programming language abstract model; Step S204: Generate an activity diagram based on the programming language abstract model through the model warehouse, wherein the activity diagram includes an activity diagram generated based on logic code and an activity diagram generated based on code comments; Step S205: by parsing the method call relationship and the code execution path in the programming language abstract model, the position, size and shape of each node in the activity diagram are determined, and connecting lines between the nodes are generated.

[0137] Although the present application is disclosed as above in the form of a preferred embodiment, it is not intended to limit the present application. Any technical personnel in this field may make possible changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims of the present application.

Claims

1. An automatic code activity diagram generation system, characterized in that: include: A source code parsing module, used to extract source code from a code file and generate an abstract syntax tree corresponding to the source code; A model conversion engine, based on a query view conversion specification operation, is configured with a set of parsing rules for parsing the method call relationship and statement execution order in the abstract syntax tree, and converting the source code into a programming language abstract model; A model warehouse, used to store the programming language abstract model and identify the programming language type according to the extension of the source code file to match the corresponding programming language abstract model; An activity diagram generator, connected to the model warehouse, for generating an activity diagram according to the programming language abstract model, wherein the activity diagram includes an activity diagram generated based on logic code and an activity diagram generated based on code comments; The layout module is used to determine the position, size and shape of each node in the activity diagram by parsing the method call relationship and code execution path in the programming language abstract model, and generate connection lines between the nodes.

2. The automatic code activity diagram generation system according to claim 1, characterized in that: The source code parsing module performs lexical analysis on the source code through the cooperation of the lexical analyzer and the syntax analyzer, and extracts keywords, identifiers and symbols in the source code; And build an abstract syntax tree through grammatical analysis.

3. The automatic code activity diagram generation system according to claim 1, characterized in that: The source code parsing module is used to parse source code of multiple programming languages, including Java, Python and C++, and dynamically adjust the parsing process according to the grammatical rules of the programming languages.

4. The automatic code activity diagram generation system according to claim 1, characterized in that: The model warehouse stores programming language abstract models through a hash table, and uses the extension name and unique identifier of the source code file as a hash key to quickly retrieve abstract models of different programming languages.

5. The automatic code activity diagram generation system according to claim 1, characterized in that: The model repository includes a version management unit for storing and retrieving multiple versions of programming language abstract models of the same source code file and comparing the differences between different versions.

6. The automatic code activity diagram generation system according to claim 1, characterized in that: The activity diagram generator includes a multi-perspective activity diagram generating unit, and the multi-perspective activity diagram generating unit is used to generate an activity diagram from multiple perspectives according to different user requirements, wherein the perspectives include: The first perspective is used to show the detailed code execution logic; The second perspective is used to generate simplified business logic activity diagrams based on code comments; The historical version perspective is used to display the system's functional iteration or code modification history.

7. The automatic code activity diagram generation system according to claim 1, characterized in that: The activity diagram generator converts each logic node in the programming language abstract model into a visual activity diagram node through a graphics rendering engine, and draws the connection lines between the nodes according to the function call relationship.

8. The automatic code activity diagram generation system according to claim 1, characterized in that: The layout module includes a graph optimization unit, which adjusts the node layout of the activity graph based on a multi-objective optimization algorithm to reduce the distance deviation between nodes, reduce the number of crossings of connection lines, and optimize the alignment of nodes. The multi-objective optimization algorithm is solved by a constraint optimization model provided by the following formula (1): in, Indicates and The logical connection weight between nodes is determined based on the calling relationship and dependency degree of the nodes; Indicates and The Euclidean distance between nodes; is the ideal distance determined based on logical relationships; Indicates The length of the connecting line; is the length of the longest connecting line in the figure; Indicates The number of crossings of the connecting lines; Indicates The alignment deviation of nodes; is the number of lines with the most crossing times in the graph; is the maximum alignment deviation in the current graph; Represents the energy value in the node layout; Indicates The distance between a node and the activity graph boundary; is the minimum boundary distance among all nodes; Indicates the number of nodes; Indicates the number of connection lines; , , and is a trade-off parameter; An adjustment parameter to balance the effect of connection line length and number of crossovers.

9. The automatic code activity diagram generation system according to claim 1, characterized in that: The system further comprises a code processing flow complexity adjustment unit, which is used to calculate the complexity of the code processing flow according to the abstract syntax tree generated by the source code, and adjust the number of nodes of the activity diagram according to the code processing complexity, wherein the calculation formula of the code processing complexity is calculated using the following formula (2): in, Indicates the complexity of the code processing flow; Indicates The number of executed statements in a code snippet; Indicates The branch depth in a code snippet; Indicates The length of the function call chain; Indicates The dependency depth of a function; Indicates The number of parameters of the function; and Represents the number of code snippets and functions respectively; The code processing flow complexity adjustment unit adjusts the number of nodes and detail of the activity diagram based on the following rules: When the calculated code processing complexity When the preset first threshold is exceeded, the details inside the function are merged into a single node in the activity diagram, and only the high-level logic of the function call sequence is retained; When the calculated code processing complexity When a preset second threshold is exceeded, multiple related code snippets are merged into a single node in the activity graph; wherein the second threshold is greater than the first threshold; When the calculated code processing complexity When the value is lower than the preset third threshold, the detailed execution logic within the function is displayed in the activity diagram, including branches, loops, and specific operation steps.

10. A method for generating an automated code activity diagram, characterized in that: include: Extracting source code from a code file and generating an abstract syntax tree corresponding to the source code; Based on the query view conversion specification operation, a set of configured parsing rules are used to parse the method call relationship and statement execution order in the abstract syntax tree, and convert the source code into a programming language abstract model; The programming language abstract model is stored in a model repository, and the programming language type is identified according to the extension of the source code file to match the corresponding programming language abstract model; Generate an activity diagram based on the programming language abstract model through the model warehouse, wherein the activity diagram includes an activity diagram generated based on logic code and an activity diagram generated based on code comments; By parsing the method call relationship and code execution path in the programming language abstract model, the position, size and shape of each node in the activity diagram are determined, and connecting lines between the nodes are generated.

Images