A multi-mode architecture reverse analysis method based on cloud service source code

Abstract

The application relates to a cloud service source code-based multi-mode architecture reverse analysis method, which comprises the following steps: acquiring program source code on a warehouse on a cloud server through a tool, and then completing reverse analysis of the architecture of the whole program through source code analysis. The method can call an analysis tool, acquire an abstract syntax tree of all source code files, construct a program analysis tree of a source code project according to abstract syntax tree information, analyze element (file, class, function and variable) coupling information of the program analysis tree, construct a dependency relationship between tree nodes, integrate element coupling information of the program analysis tree, and construct a dependency relationship graph of all source code files. The generated source code file dependency graph can be used to aggregate a dependency relationship graph of a source code module and a relationship dependency graph of a component according to a classical mode, a Maven project single-module mode and a Maven project multi-module mode.

Description

Technical Field

[0001] This invention relates to a parsing method, specifically a multi-mode architecture reverse parsing method based on cloud service source code, belonging to the technical field of multi-mode architecture reverse parsing in software maintenance. Background Technology

[0002] Reverse engineering is defined as the process of analyzing a system to abstract it from low to high levels, describing the structure, logic, and interactions between components. It typically begins by collecting system information in an easily understandable and analyzable form, then reverse-engineers it to a higher level of abstraction (such as a component diagram). This data can be further used for reverse analysis to obtain a higher level of system representation, such as for reconstructing design patterns and system architectures. The "Architectural Layered Structure Information Recovery Method" actually falls under the research and practice scope of "reverse engineering," specifically within the field of software architecture recovery technology. Its primary purpose is to obtain the necessary architectural information from engineering projects.

[0003] In today's era of rapid software development, the complexity of software systems continues to increase with software evolution; for example, Android's codebase has now exceeded 100 million lines. Simultaneously, the quality of software systems gradually declines with evolution, making maintenance increasingly difficult and costly. In this context, the importance of software architecture in software engineering has become increasingly recognized. Software architecture provides users with a design-level view, making it easier for them to understand the system and accurately locate the code requiring maintenance and the scope of its impact. Software architecture helps developers improve software quality by changing its internal structure while maintaining its external behavior, thereby increasing its understandability, scalability, and reusability.

[0004] While some methods exist for reverse engineering architecture, they suffer from several drawbacks, such as incomplete automation, long recovery times, inability to recover very large projects, and a lack of hierarchical understanding of the recovered architecture. This invention addresses these issues by starting with the project source code and using reverse engineering techniques to obtain file dependency graphs, module dependency graphs, and component dependency graphs. It can then provide architecture recovery services for very large projects. Summary of the Invention

[0005] This invention addresses the problems existing in the prior art by providing a method for reverse analysis of a multi-mode architecture based on cloud service source code. This technical solution provides a method for reverse analysis of a multi-mode architecture based on cloud service source code. By analyzing the coupling information of elements (files, classes, functions, variables) in the cloud service source code analysis tree, it extracts information between entities at different granular levels of the program and further extracts the coupling relationship at the architecture level, thereby completing the reverse analysis of the entire cloud service program.

[0006] To achieve the above objectives, the technical solution of the present invention is as follows: a method for reverse analysis of a multi-mode architecture based on cloud service source code, the method comprising the following steps:

[0007] Step 1: Obtain the cloud service source code, configure the tool to obtain the source code of the cloud server, and obtain the source code and related code information of the project that needs to be reverse-analyzed.

[0008] Step 2: Based on the parsed source code, extract the source code information and generate a dependency graph of the source code files:

[0009] Step 3: Based on the dependency graph of the generated source code files, further construct the module dependency graph:

[0010] Step 4: Based on the dependency graph of the generated source code module, further construct the dependency graph of the component to complete the reverse parsing.

[0011] Step 2 is as follows:

[0012] 1) Write a source code parser to obtain the abstract syntax tree of all source code files;

[0013] 2) Construct the program analysis tree of the source code project based on the abstract syntax tree information, analyze the coupling information of the elements (files, classes, functions, variables) of the program analysis tree, and construct the dependency relationships between tree nodes;

[0014] 3) Integrate the element coupling information of the program analysis tree and construct the dependency graph of all source code files.

[0015] Step 3 is as follows:

[0016] 1) Perform modular preprocessing: aggregate the file dependency graph based on file dependencies and directory structure information, eliminate noisy files, and make the granularity of the aggregated modules between files and directories.

[0017] 2) Modular process:

[0018] a) Modularization of classic project patterns: By judging whether two nodes have inheritance, implementation, declaration definition, and whether two nodes have bidirectional dependency, closed-loop dependency, etc., strong dependency types and structures are removed from the file dependency graph, thus completing modularization;

[0019] b) Modularization in Maven single-module mode: During the modularization process, Maven single-module searches for directory names in the project that conform to the naming rules of controller, dao, and service, and completes the modularization process.

[0020] c) Modularization in Maven's multi-module mode: Maven is a project object model that uses POM files as its core. It manages the project build by using a small piece of descriptive information. It obtains the POM dependency tree of the source code by parsing the POM file, finds the leaf nodes in the POM dependency tree, and completes the modularization process.

[0021] 3) Integrate the information generated during the modularization process to generate a dependency graph of the source code modules.

[0022] Step 4: Based on the dependency graph of the generated source code modules, further construct the dependency graph of the components to complete the reverse parsing, which is divided into three different componentization rules:

[0023] 1) Componentization of classic project patterns

[0024] a) Calculate the numerical value of the strength of the dependency relationship between two entities using the dependency graph of the modules, i.e. the dependency strength between modules.

[0025] b) Sort all dependency-dense pairs according to the strength of their dependencies, and aggregate entities with strong dependencies first. Iterate continuously to finally obtain the component dependency graph.

[0026] 2) Componentization of Maven single-module projects

[0027] In the process of componentizing a single module in a Maven project, since the POM dependency tree only has a single node, therefore...

[0028] The project name serves as the component name, and there is only one component.

[0029] 3) Componentization of Maven multi-module projects

[0030] Traverse the POM dependency tree and use the name of the first-level POM file node under the POM root node as the component name to complete the Maven multi-module componentization process.

[0031] The method of this invention obtains program source code from a cloud server, extracts information between entities at different granular levels in the program source code, and further extracts the coupling relationship at the architecture level to complete the reverse analysis of the entire cloud service program.

[0032] Compared to existing technologies, this invention has the following advantages: The method of this invention extracts the syntax tree of the program source code obtained from a cloud server, and then extracts the dependencies between entities at different levels of granularity in the source code, thereby reverse-engineering the system architecture. Compared with existing reverse engineering methods, this invention mainly has the following advantages:

[0033] 1. This invention employs a reverse engineering method specifically for programs deployed on cloud servers. It can automatically obtain the program source code, effectively shortening the time required for reverse engineering cloud service programs. Traditional reverse engineering methods require manually downloading the project from the cloud service to the local machine. With the rapid development of software, increasing system complexity, and a growing number of developers, cloud server programs are often deployed on GitLab during development, making it difficult to import the program into reverse engineering tools. The reverse engineering method used in this invention integrates cloud server code management tools, automating the manipulation of program source code deployed on cloud servers. This overcomes the difficulty of obtaining cloud service source code in traditional reverse engineering methods, effectively reducing the time required for reverse engineering cloud service programs.

[0034] 2. Compared to traditional reverse engineering methods, this method is based on multi-information architecture extraction from source code. It automatically analyzes the source code to extract relevant information about each logical entity, such as file references, generalization relationships (inheritance, implementation), associations (composition, aggregation, and other associations), dependencies (parameter type dependencies, return type dependencies, variable declaration type dependencies), and function call relationships. This method parses all relevant information between entities in the source code and simplifies all entity-related information to further extract the file dependency graph of the cloud service program.

[0035] 3. Compared with traditional reverse analysis methods, this method adopts a combination of bottom-up and top-down approaches. It has both the bottom-up approach to grasp the underlying information of the project source code and the top-down approach to understand the project architecture information. This solves the problems of accuracy and efficiency of bottom-up clustering algorithms and the difficulty in obtaining complete design documents of project architecture information in top-down approaches.

[0036] 4. Compared to traditional reverse engineering methods, this method improves the comprehensibility of the architecture diagram, enables multi-layered architecture reconstruction, extracts the program's module dependency graph and component dependency graph, generates abstractions of different granularities, and supports mapping relationships between different layers. This allows relevant personnel to gain both a macro-level understanding of the software architecture and a deeper, more in-depth understanding of the relationship between architecture and implementation. This method reconstructs the multi-layered architecture of the software implementation, controls the granularity of components, and adopts a layer-by-layer approach to avoid generating overly complex architecture diagrams, resulting in multi-layered architecture diagrams that are accessible to both developers and managers. Attached Figure Description

[0037] Figure 1 This is a flowchart of the present invention;

[0038] Figure 2 This is a schematic diagram of the system architecture of the present invention, illustrating the data processing components involved in the present invention and the relationships between them;

[0039] Figure 3 This is a flowchart of the present invention;

[0040] Figure 4 This is a flowchart of the interface combination in a specific implementation embodiment. Detailed Implementation

[0041] To enhance understanding of the present invention, the embodiments will be described in detail below with reference to the accompanying drawings.

[0042] Example 1: See Figures 1-4 A method for reverse engineering a multi-mode architecture based on cloud service source code. Figure 1 The specific execution steps of the method we adopted are given below, in conjunction with the appendix. Figure 1 Each step in the technical solution of the invention shall be described in detail:

[0043] 1. Retrieve source code from the server. This method uses the JGit tool to automate the retrieval of source code deployed on a cloud server. This automated retrieval service records the cloud service's creator, creation time, branch pulled, puller, pull time, pull results, and log entries. After automatically retrieving the cloud service's source code, the records are saved to MySQL for subsequent reverse engineering.

[0044] 2. Reverse engineer the source code to obtain the program's file dependency graph. By analyzing the program's abstract syntax tree, extract dependency information between entities at various levels, such as file references, generalization relationships (inheritance, implementation), association relationships (composition, aggregation, and other associations) and dependency relationships (parameter type dependency, return type dependency, variable declaration type dependency), and function call relationships. Integrate the coupling relationships between elements to construct a dependency graph for all source code files.

[0045] 3. Integrate file dependency graph information to obtain a module dependency graph. Perform modular preprocessing: based on file dependencies and directory structure information, aggregate the file dependency graph, eliminate noisy files, and ensure the granularity of the aggregated modules is between that of files and directories. Then, for the classic mode (projects not built with Maven), check whether two nodes have inheritance, implementation, or declaration definitions, and determine whether two nodes have bidirectional dependencies.

[0046] Rules such as closed-loop dependencies remove strong dependency types and structures from the file dependency graph, thus achieving modularization. For Maven single-module projects, which often use a three-tier MVC architecture, modularization is achieved by finding directory names that conform to the naming rules of controller, dao, and service within the project.

[0047] For multi-module projects, Maven uses a POM file as the project object model, managing project builds through a short descriptive description. It parses the POM file to obtain the source code's POM dependency tree, finds the leaf nodes in the POM dependency tree, and completes modular processing.

[0048] 4. Componentize the module dependency graph information to obtain the component dependency graph. Aggregate the module dependency graph to obtain the component dependency graph. The specific steps are as follows: For the classic mode (projects not built with Maven), use the module dependency graph to calculate the strength of the dependency relationship between two entities, sort all dense dependency pairs according to the strength of the dependency between entities, and aggregate entities with stronger dependencies first. Iterate continuously to finally obtain the component dependency graph; for Maven single-module projects, use the file name as a unique component; for Maven multi-module projects, parse the project's PoM dependency tree and use the ID name of the first-level tree node as the component.

[0049] Example 2:

[0050] For ease of description, we assume the following simplified application example:

[0051] The target software cloud service program has multiple files such as a1, a2, a3, a4, b1, b2, b3, b4, c1, c2, c3, c4.

[0052] 1. Design an interface to obtain cloud service source code.

[0053] The required parameters for this interface are the username and password for the cloud server, both in String format. Using the obtained username and password, the source code of the program on the cloud service is pulled, and the creation time, creator, branch pulled, pull time, code pull results, and logs of the cloud service program are recorded in the database.

[0054] 2. Reverse engineer the source code to obtain the program's file dependency graph.

[0055] The JDT parser is invoked to obtain the abstract syntax tree (AST) of all source code files (a1, a2, a3, a4, b1, b2, b3, b4, c1, c2, c3, c4). Various coupling information of the source code elements is analyzed. By analyzing class member variables, composition and association information between classes is obtained. The coupling information of the elements in the program analysis tree is integrated to construct a dependency graph of all source code files (a1, a2, a3, a4, b1, b2, b3, b4, c1, c2, c3, c4), such as... Figure 2 As shown.

[0056] 3. Integrate the file dependency graph information to obtain the module dependency graph.

[0057] Modular preprocessing is performed. After forming the file dependency graph, it is aggregated based on file dependencies and directory structure information. Noisy files are eliminated, and the granularity of the aggregated modules is between that of files and directories. Finally, dependency graphs of multiple modules (a1, a2), (a3, a4), (b1, b2), (b3, b4), (c1, c2), and (c3, c4) are obtained according to the classic mode, Maven single-module mode, and Maven multi-module mode, as follows. Figure 3 As shown;

[0058] 4. Perform componentization processing on the module dependency graph information to obtain the component dependency graph.

[0059] The obtained module dependency graph is then componentized. Considering the dependency strength of all modules {a1, a2}, {a3, a4}, {b1, b2}, {b3, b4}, {c1, c2}, {c3, c4}, the component-level hierarchical structure is extracted according to the classic pattern, Maven single-module pattern, and Maven multi-module pattern, such as A{(a1, a2), (a3, a4)}, B{(b1, b2), (b3, b4)}, C{c1, c2), (c3, c4)}, etc. Figure 4As shown.

[0060] Using the method of this invention, cloud service source code can be automatically obtained, improving the automated reverse analysis process. Then, by reverse analyzing the source code, the coupling information of elements in the source code is extracted. The complete element coupling information is huge and difficult to understand. We will simplify this information and further integrate it to obtain the file dependency graph of the source code. The module dependency graph and component dependency graph of the program are extracted to realize multi-level architecture recovery, thereby making the system architecture easier to understand.

[0061] It should be noted that the above embodiments are not intended to limit the scope of protection of the present invention. Equivalent transformations or substitutions made based on the above technical solutions all fall within the scope of protection of the claims of the present invention.

Claims

1.A method for reverse analysis of a multi-mode architecture based on a cloud service source code, characterized in that, The method comprises the following steps: Step 1: Obtain cloud service source code: Step 2: According to the parsed source code, extract the source code information, and generate the dependency graph of the source code file: Step 3: According to the generated dependency graph of the source code file, further construct the relationship dependency graph of the source code module: Step 4: According to the generated dependency graph of the source code module, further construct the dependency graph of the component, and complete the reverse analysis; Wherein, step 1: obtaining cloud service source code, configuring the tool for obtaining source code on the cloud server, obtaining the source code and related code information required for reverse analysis project; Step 2 is as follows: 1) Write a source code parser to obtain the abstract syntax tree of all source code files; 2) According to the abstract syntax tree information, construct the program analysis tree of the source code project, analyze the element coupling information of the program analysis tree, and construct the dependency relationship between the tree nodes; 3) Integrate the element coupling information of the program analysis tree to construct the dependency graph of all source code files; Step 3 is as follows: 1) Modularization preprocessing: according to the file dependency relationship and directory structure information, the file dependency graph is aggregated, noise files are eliminated, and the granularity of the aggregated module is between the file and the directory; 2) Modularization process: a) Modularization of classic project mode: by judging whether two nodes exist inheritance, implementation, declaration definition, whether two nodes exist bidirectional dependency rule, closed loop dependency rule, and removing strong dependency type and structure based on file dependency graph, the modularization is completed; b) Modularization of Maven single module mode: in the modularization process, the directory name of the Maven single module that meets the controller, dao and service naming rules is found, and the modularization is completed; c) Modularization of Maven multi-module mode: Maven is a project object model based on POM file, which manages the construction of the project through a small amount of description information, the POM dependency tree of the source code is obtained by parsing the POM file, the leaf nodes in the POM dependency tree are found, and the modularization is completed; 3) Integrate the information generated in the modularization process to generate the dependency graph of the source code module; Step 4: According to the generated dependency graph of the source code module, further construct the dependency graph of the component, and complete the reverse analysis, which is divided into three different componentization rules: 1) Componentization of classic project mode, a) Calculate the value of the strength of the dependency relationship between two entities by means of the dependency relationship graph of the module, that is, the dependency strength between modules; b) Sort all dependent dense pairs according to the dependency strength between entities, and the entity with strong dependency strength is preferentially aggregated, and the iteration is continuously performed to finally obtain the component dependency graph; 2) Componentization of Maven single module project, In the componentization process of Maven single module project, since the POM dependency tree has only a single node, the project name is taken as the component name, and there is only one component, 3) Componentization of Maven multi-module project, Traverse the POM dependency tree, and take the name of the first layer POM file node under the POM root node as the component name to complete the Maven multi-module componentization process.

Images