Software architecture recovery method and apparatus

Abstract

The application provides a software architecture recovery method and device. By introducing a phrase-level architecture topic semantic, the significance of semantic distinction between files is improved. By constructing a semantic prototype and reasoning a cluster-level semantic representation, hierarchical improvement from a file-level semantic to a cluster-level semantic is realized. By identifying cross-language interaction relationships and introducing a cross-language topology completion mechanism, the structural vulnerability of a cross-language boundary in a graph model is compensated. Finally, structural dependence, semantic association and cross-language topology information are fused to improve the accuracy and structural consistency of cross-language software system architecture recovery.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a software architecture recovery method and device. Background Technology

[0002] With the increasing scale of software systems and the widespread application of multilingual development models, software architecture recovery has become a key technology in software maintenance, evolutionary analysis, and system understanding. Recovering the system's architecture from source code helps developers understand its organization, module division, and interactions between different parts. However, because software systems are prone to architectural drift and structural degradation during long-term evolution, significant deviations can occur between the actual implementation and the original design, making architecture recovery a highly complex task.

[0003] Existing software architecture recovery methods primarily rely on structural dependencies and semantic information for modeling. Based on the type of information used, these methods can be broadly categorized into structural dependency-based methods and semantic enhancement-based methods. Structural dependency-based methods construct dependency graphs by analyzing call and reference relationships between files and then partition modules using clustering algorithms. However, structural dependency information is often incomplete, especially in complex systems where dependencies may be missing or noisy, affecting the accuracy of architecture recovery. Semantic enhancement-based methods compensate for the deficiencies of structural dependencies by introducing code semantic information. In recent years, with the development of large language models, researchers have begun to use models to generate file-level semantic descriptions and construct auxiliary relationships based on semantic similarity. These methods have improved architecture recovery to some extent. However, existing methods typically use sentence-level semantic descriptions to represent file functions. Different files often generate structurally similar descriptive texts under the same prompts, resulting in low semantic representation discriminability. This leads to a large number of redundant connections when constructing semantic relationships, making the graph structure overly dense and weakening the identifiability of architecture boundaries. Furthermore, most existing methods only model pairwise semantic relationships between files, ignoring the higher-level organizational characteristics of software architecture. Software systems are typically organized in the form of modules or clusters, with multiple files working together to perform the same functional responsibilities. Relying solely on file-level semantics is insufficient to accurately reflect this structural characteristic, leading to ambiguity in clustering results and making it difficult to align with the actual architecture.

[0004] On the other hand, with the widespread application of multilingual software systems, the interaction between different programming languages ​​has become an important part of the system architecture. However, most existing architecture recovery methods rely on single-language static analysis tools, which cannot effectively capture cross-language call relationships. This results in recovery results that are often divided according to language boundaries rather than the true functional structure, thus affecting the accuracy and completeness of architecture recovery.

[0005] Despite advancements in structural dependency analysis and semantic modeling, existing technologies still face several challenges: First, sentence-level semantic representations lack sufficient discriminative power, easily introducing redundant semantic relationships. Second, the lack of a semantic modeling mechanism from the file level to the cluster level makes it difficult to reflect the overall organizational structure of the software architecture. Third, the failure to effectively model cross-language interaction relationships leads to inaccurate architecture recovery results for multilingual systems. Therefore, constructing a cross-language software architecture recovery method that enhances semantic discriminative power, characterizes the file-cluster two-layer semantic structure, and effectively completes cross-language topological relationships has become an urgent problem to solve. Summary of the Invention

[0006] This application proposes a software architecture recovery method and device, which can solve one of the problems existing in the background art.

[0007] To achieve the above objectives, this application adopts the following technical solution:

[0008] Firstly, a software architecture recovery method is provided, characterized by comprising:

[0009] For a software code repository consisting of several code files, extract the structural dependencies between the code files to obtain a dependency graph with the code files as nodes and the structural dependencies as edges;

[0010] The code file is semantically analyzed using a large language model to obtain architectural theme semantics composed of words that characterize the responsibilities of the code file in the software architecture.

[0011] Based on the semantic similarity of the architectural themes between the code files, several semantic centers are determined from each of the code files to represent different semantic regions;

[0012] Select several code files that meet the similarity requirements with the corresponding semantic center as non-semantic centers, and construct a semantic cluster prototype;

[0013] Based on the aforementioned architectural theme semantics and the directory of the software code repository, a system-level semantic overview is generated;

[0014] Using the semantic cluster prototype and the system-level semantic overview as input, semantic reasoning is performed on the semantic cluster prototype using a large language model to obtain a cluster semantic representation that characterizes the overall architectural responsibilities of the semantic cluster prototype.

[0015] Based on the similarity between the cluster semantic representation and the architectural theme semantics of each of the code files, a file-cluster association relationship is established from the code files to the semantic cluster prototype;

[0016] A unified graph model is established based on the dependency graph and the file-cluster associations.

[0017] Furthermore, the unified graph model is processed to obtain several cluster structures with high cohesion and low coupling, which are used to represent the results of software architecture module partitioning.

[0018] In one possible design approach of the first aspect, the software architecture recovery method further includes: enhancing the dependency graph by employing a preset enhancement strategy based on the semantic similarity of the architectural theme semantics between the code files.

[0019] In one possible design approach of the first aspect, the preset enhancement strategy is:

[0020] For code file pairs that already have structural dependencies, the edge weights of the code file pairs are enhanced based on semantic similarity;

[0021] For code file pairs that do not have structural dependencies but have semantic similarity higher than a preset threshold, new edges are introduced into the dependency graph, and corresponding edge weights are assigned based on semantic similarity.

[0022] In one possible design of the first aspect, the software code repository is a multi-programming language hybrid software code repository, and the software architecture recovery method further includes:

[0023] The software code repository is parsed to identify the interaction relationships between code files in different programming languages ​​and obtain cross-language associations;

[0024] For code file pairs that are identified to have cross-language relationships, cross-language connection edges are established in the dependency graph and weights are assigned to the cross-language connection edges.

[0025] Furthermore, based on the identified first and second code files with cross-language relationships, the first code file is programmed in a first programming language and the second code file is programmed in a second programming language, a set of structural neighbor code files of the second code in the second programming language environment is obtained, and cross-language topological completion edges are established between the first code file and each code file in the set of structural neighbor code files in the dependency graph and weights are assigned to the cross-language topological completion edges.

[0026] In one possible design approach of the first aspect, based on the semantic similarity of the architectural themes between the code files, several semantic centers representing different semantic regions are determined from each of the code files, specifically including:

[0027] Initialize semantic center set , Let C be an empty set. For any code file i, the degree to which the code file i is covered by the current semantic center set C. Initialize to 0;

[0028] in, Cov(i) represents the semantic similarity between code file i and semantic center c, and cov(i) represents the degree to which file i is currently covered by the set of semantic centers C.

[0029] Then, new candidate semantic centers are selected iteratively until the iterative convergence condition is met. In each iteration, for each candidate code file that has not yet been selected as a semantic center... ,calculate The coverage gain that a new semantic center can bring :

[0030] in, Indicates code file i and Semantic similarity between them;

[0031] After calculating the coverage gain of all candidate code files, select the candidate file with the largest coverage gain. As a new semantic center, After adding the semantic center set C, update the coverage of each code file i: .

[0032] In one possible design approach of the first aspect, the software architecture recovery method further includes:

[0033] The overlap between different semantic cluster prototypes is calculated using Jaccard similarity.

[0034] Additionally, a merging operation is performed on semantic cluster prototypes with an overlap exceeding a preset merging threshold to eliminate redundant semantic regions and reselect the semantic center after the merging operation.

[0035] In one possible design approach of the first aspect, a system-level semantic overview is generated based on the architectural theme semantics and the directory of the software code repository, specifically including:

[0036] Traverse each code directory in the software code repository, collect the architectural theme semantics of all code files in that directory, use these architectural theme semantics as input, and generate a semantic description of the directory using a large language model.

[0037] Additionally, the semantic descriptions and directory names of all code directories are used as input to generate a system-level semantic overview using a large language model.

[0038] In one possible design approach of the first aspect, a file-cluster association relationship is established from the code file to the semantic cluster prototype based on the similarity between the cluster semantic representation and the architectural theme semantics of each of the code files, specifically including:

[0039] For any code file, calculate the similarity between the code file and the semantic representation of each cluster, and assign the code file to the prototype of the semantic cluster with the highest similarity;

[0040] Additionally, enhance the edges between code files belonging to the same semantic cluster prototype.

[0041] In one possible design approach of the first aspect, the structural dependency relationship is: a calling relationship, a referencing relationship, or an inclusion relationship between files; the edge weights in the dependency graph are determined comprehensively based on the type and frequency of the structural dependency relationship; the term is used to describe the functional role, scope of responsibility, and / or core operations involved in the code file.

[0042] In a second aspect, an electronic device is provided, comprising: a processor, and a memory coupled to the processor, the memory for storing a computer program; the processor for executing the computer program stored in the memory to cause the electronic device to perform the software architecture recovery method as described in any possible implementation of the first aspect.

[0043] Beneficial effects:

[0044] Based on the above technical solutions, the saliency of semantic distinction between files is improved by introducing phrase-level architectural topic semantics; a hierarchical improvement from file-level semantics to cluster-level semantics is achieved by constructing semantic prototypes and reasoning about cluster-level semantic representations; and the structural fragility of cross-language boundaries in graph models is compensated by identifying cross-language interaction relationships and introducing a cross-language topological completion mechanism. Finally, by integrating structural dependencies, semantic associations, and cross-language topological information, the accuracy and structural consistency of cross-language software system architecture recovery are improved. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart of a cross-language software architecture recovery method based on file-cluster dual-layer semantics and topology completion provided in an embodiment of this application;

[0047] Figure 2 This is a schematic diagram showing the similarity distribution of different semantic representation methods provided in the embodiments of this application;

[0048] Figure 3 These are schematic diagrams of cross-language relationship modeling provided in the embodiments of this application, wherein (a) is a schematic diagram of cross-language relationship modeling using traditional methods, and (b) is a schematic diagram of cross-language relationship modeling using the method of this embodiment. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0050] It should be noted that although functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification and the above-mentioned figures are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0051] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0052] With the continuous expansion of software system scale and the widespread application of multilingual development models, software architecture recovery is becoming increasingly important in software maintenance and system understanding. However, existing methods mainly rely on structural dependency information and sentence-level semantic descriptions, which suffer from insufficient semantic discrimination capabilities, difficulty in characterizing high-level module structures, and inability to effectively model cross-language relationships. This leads to deviations between the recovery results and the actual architecture, especially in cross-language software systems, where the recovery results are often incorrectly divided according to language boundaries. Therefore, this embodiment aims to propose a cross-language software architecture recovery method based on file-cluster dual-layer semantics and topology completion. By introducing phrase-level architectural topic semantics, the saliency of semantic distinctions between files is improved; by constructing semantic prototypes and reasoning cluster-level semantic representations, a hierarchical improvement from file-level semantics to cluster-level semantics is achieved; and by identifying cross-language interaction relationships and introducing a cross-language topology completion mechanism, the structural fragility of cross-language boundaries in graph models is compensated for. Finally, by integrating structural dependencies, semantic associations, and cross-language topology information, the accuracy and structural consistency of cross-language software system architecture recovery are improved.

[0053] The specific implementation flowchart of the method in this embodiment is as follows: Figure 1 As shown, the process is as follows:

[0054] Step 1) Process the software code repository, extract the single-language structural dependencies and file-level semantic representations of each code file, and construct a semantically enhanced graph. This specifically includes the following process: First, extraction of single-language structural dependencies. The software system's code repository is parsed to identify the structural dependencies between files, including call relationships, reference relationships, and inclusion relationships. First, the source code files in the code repository are traversed, and the corresponding programming language is identified based on the file type. Then, static syntax analysis is performed on each source code file to extract program entity information such as functions, classes, interfaces, variables, modules, and header files. Further analysis of the structural relationships between different program entities is conducted. By analyzing call relationships, reference relationships, inheritance relationships, implementation relationships, parameter passing relationships, return relationships, creation relationships, import relationships, and inclusion relationships between program entities, the dependencies between program entities are identified. When a program entity accesses, calls, references, or depends on another program entity during its implementation, a structural dependency is considered to exist between them. A dependency graph containing weighted nodes and weighted edges is constructed using the above method. Nodes represent code files, and the weights of the edges characterize the strength of the structural dependencies between files. In one implementation, the weight of structural dependency edges can be determined comprehensively based on the type and frequency of dependency relationships. Second, file-level semantic relations are extracted. Semantic analysis is performed on code files, using Large Language Models (LLMs) to analyze each file and generate an LLM-based code summary. From the code summary, thematic semantic information characterizing the file's architectural responsibilities within the software system is extracted. This thematic semantics is composed of multiple phrases or keyword combinations, each phrase describing the file's functional role, scope of responsibility, or core operations involved. Furthermore, the semantic representation does not employ complete sentence structures, thus avoiding the problem of semantic convergence across different files. Figure 2 As shown, this method extracts the architectural theme semantics of code files. Compared with other semantic perspectives, such as functional semantics, interaction semantics, responsibility semantics, and architectural semantics, the semantic similarity distribution between files obtained by this method exhibits a significant dispersion characteristic, effectively improving the distinguishing ability. The file-level semantic representations obtained through the above method have higher distinguishing ability, providing a foundation for subsequent semantic relationship construction and architecture recovery. Third, graph augmentation based on semantic similarity. Based on the file-level semantic representations obtained above, the architectural theme words extracted from each file are input into the Word2Vec model, converted into a fixed-dimensional semantic vector space, and then the semantic similarity between files is calculated. In one implementation, semantic similarity can be calculated through the similarity between vector representations, for example, by measuring cosine similarity:

[0055] in, and Let i and j represent the semantic representations of file i and file j, respectively. This represents the semantic similarity between two files. After obtaining the semantic similarity, the dependency graph constructed in step 1, consisting of weighted nodes and weighted edges, is enhanced: In one scenario, for file pairs with existing structural dependencies, their connections are enhanced based on semantic similarity. In one implementation, the weights of the enhanced edges are... It can be calculated using the following formula:

[0056] in, The original structure depends on the edge weights. For semantic similarity between files, The preset semantic enhancement coefficient is used. Through the above method, file pairs that are structurally and semantically similar receive higher connection weights. Scenario two involves introducing semantic edges for file pairs with high semantic similarity but no structural dependency. For file pairs without structural dependency but with semantic similarity exceeding a preset threshold, new semantic connections are introduced into the graph, and corresponding connection weights are assigned based on the degree of semantic similarity. In one implementation, the weight of the newly added semantic edge... Values ​​can be assigned using the following formula:

[0057] in, These are preset semantic edge weight coefficients. The above method supplements functional associations that may have been missed in structural dependency analysis. Through the processing of the above two scenarios, the dependency graph that originally only contained structural dependency information is transformed into a semantically enhanced graph that integrates structural dependency information and semantic similarity information. This semantically enhanced graph also consists of weighted nodes and weighted edges.

[0058] Step 2) This step targets multi-language hybrid software systems, explicitly identifying cross-language interaction relationships and resolving topological fragility at cross-language boundaries through a cross-language topology completion mechanism. Specifically, this includes: First, identifying cross-language relationships. During code repository parsing, the interaction relationships between files in different programming languages ​​are identified to obtain cross-language associations. These cross-language associations originate from one or more of the following interoperability mechanisms, used to describe functional connections between modules across language boundaries:

[0059] (1) Function calls and interface binding. Direct calling mechanisms between different programming languages, such as function calls, interface binding (e.g., Java Native Interface, i.e., JNI), and native method mapping (e.g., Python C extensions).

[0060] (2) External function interface binding. Cross-language calls implemented through external function interface libraries, such as the Java ForeignFunction & Memory API, Python ctypes / CFFI, Node.js node-ffi, and other dynamic library loading and symbol resolution mechanisms. This type of binding is usually manifested as a loading declaration of the dynamic link library and a runtime description of the function signature.

[0061] (3) Serialization and Interface Definition Language Binding. Indirect interaction is achieved through cross-language interface definition languages ​​or serialization protocols, such as Protocol Buffer definition files, Thrift interface files, Apache Avro Schema, cross-language IDL files, etc. The message structure and service interface declared in such files define the contractual relationship between the server and the client in different languages.

[0062] (4) Web services are bound to RESTful APIs. Cross-language interaction is achieved through HTTP interfaces, such as OpenAPI / Swagger specification files, GraphQL Schema definitions, and gRPC service definitions. Clients and servers implemented in different languages ​​establish connections through shared API definition files.

[0063] (5) Message queue and event bus binding. Cross-language asynchronous communication is achieved through message middleware, such as message queue topic names, event bus channel identifiers, and publish-subscribe topic definitions shared by different language modules. Such associations can be identified through hard-coded topic name constants and message serialization format definitions in the code.

[0064] (6) Database shared access binding. Implicit coupling between different language modules through shared databases, such as shared data table structure definitions, ORM mapping files, SQL scripts, etc. When code files from different languages ​​operate on the same data tables or share the same ORM entity definitions, it indicates that there is an implicit functional relationship between them.

[0065] (7) Cross-language dependency declarations in the build script. Parse the build configuration files in the code repository, such as CMakeLists.txt, Makefile, setup.py, pyproject.toml, pom.xml, build.gradle, etc., and extract the declared cross-language module dependencies, link library dependencies, and mixed compilation configurations.

[0066] like Figure 3As shown, compared to (a) the traditional cross-language relationship modeling diagram, (b) is the cross-language relationship modeling diagram of this embodiment. In one implementation, cross-language relationship modeling involves the association between files implemented in different languages. The example in the figure shows the cross-language interaction relationship established between Java language files (such as VMLangAccess.java, VM.java, AnnotationParser.java, Access.java) and C / C++ language files (such as jcl.h, annparser.c, Jclprotos.h, java_lang_Access.c, sun_reflect_ConstantPool.c, jnidcacheinit.c) through mechanisms such as JNI. Figure 3 The dashed lines schematically represent the relationships between the aforementioned cross-language file pairs. It is important to emphasize that such cross-language relationships are typically not captured by traditional monolingual static analysis tools, leading to structural breaks in the dependency graph of cross-language functional modules—that is, only single-point connections exist between cross-language modules, with each end connected to a dense monolingual dependency subgraph. During the subsequent module degree optimization process of the community detection algorithm, these single-point connections are easily severed due to insufficient weights to offset the slicing gain, resulting in the systematic fragmentation of cross-language functional modules. This is the fundamental reason for the inaccurate architecture recovery when existing methods are applied to cross-language systems. The second step is cross-language relationship modeling. For the identified file pairs with cross-language relationships, cross-language connection edges are directly established in the semantic enhancement graph constructed in step 1, connecting the various monolingual semantic enhancement subgraphs into a unified cross-language semantic enhancement graph. In one implementation, the weights of the cross-language connection edges... It can be determined by the following formula:

[0067] in, The average weight of all edges in the semantically augmented graph constructed in step 1. The first step involves setting pre-defined cross-language edge weights to reflect the importance of cross-language associations at the architectural level. The second step introduces a cross-language topology completion mechanism. Addressing the aforementioned vulnerability of cross-language boundary topology, this step further introduces a cross-language topology completion mechanism to structurally complete cross-language boundaries without relying on semantic similarity thresholds. For the first file with cross-language associations... (Belongs to the first programming language) and the second file (Belongs to a second programming language), recognize the second file. A collection of neighboring files within its own programming language environment The structured neighbor file set can be connected to a single-language dependency graph. Files with strong dependencies (such as edge weights greater than a preset threshold, or dependencies of strongly related types like call relationships) are used to determine this. In the first file... With the structure neighbor file set Cross-language topological completion edges are established between the various files in the document. In one implementation, the weights of the cross-language topological completion edges are... Calculate using the following formula:

[0068] in, For the first document With the second document Cross-language connection edge weights, For the second document Its structural neighbor files The dependency tightness coefficient between the two files is determined based on the structural dependency type (such as call, inheritance, inclusion) and dependency frequency. The tighter the dependency relationship, the closer the coefficient is to 1. Through the above cross-language topology completion mechanism, an auxiliary connection path is established between the cross-language associated file and the strongly dependent file on the second programming language side. In one implementation, the weight of the cross-language topology completion edge is reduced relative to the original cross-language connection edge. This increases the connection density of cross-language boundaries in the graph model without introducing false strong dependencies, making cross-language functional modules easier to identify as a whole in subsequent community detection.

[0069] Step 3) Constructing semantic prototypes and inferring cluster-level semantics based on file-level semantic representations, specifically including the following process: First, initial center selection. In the file-level semantic vector space obtained in Step 1, files that can represent different semantic regions are selected as semantic centers based on the semantic similarity between files. In one implementation, a coverage gain maximization strategy is used for iterative selection of semantic centers, specifically as follows: For any file i, the degree to which it is covered by the current semantic center set C can be expressed as:

[0070] in, Let `cov(i)` represent the semantic similarity between file `i` and semantic center `c`, and `cov(i)` represent the degree to which file `i` is currently covered by the set of semantic centers. The set of semantic centers `C` is initialized to be empty, i.e., ... For any file i, the degree to which it is covered by the current semantic center set C. Initialize to 0. Then iteratively select new candidate semantic centers. In each iteration, for each candidate file that has not yet been selected as a semantic center... Calculate the coverage gain that it can bring as a new semantic center. :

[0071] After calculating the coverage gain of all candidate files, select the candidate file with the maximum coverage gain. As the new semantic center, add it to the semantic center set C. Then, update the coverage of each file i:

[0072] Repeat the above iterative process. In one implementation, the iteration stops when any of the following termination conditions are met: (1) the current maximum coverage gain. Decrease to a preset percentage of the coverage gain in the first iteration The following; (2) The size of the semantic center set reaches the preset upper limit. Through the above iteration, the file with the largest coverage gain is selected as the semantic center, and the semantic center set is gradually constructed so that different semantic regions can be covered by at least one semantic center. Second, prototype construction. After determining the semantic center C, for each semantic center, from the non-semantic center files in the code repository, several files with the highest semantic similarity to the semantic center are selected according to the size of the code repository and included in the prototype. Third, prototype refinement. After obtaining the initial semantic prototype set, different semantic prototypes P are further calculated. a With P b The degree of overlap between them is determined in one implementation using Jaccard similarity. Perform measurement:

[0073] For semantic prototypes with an overlap exceeding a preset merging threshold, a merging operation is performed to eliminate redundant semantic regions. After merging, a semantic center that can represent the merged set is reselected (e.g., the file with the highest average similarity to other files in the set). Through the above prototype refinement process, a final refined prototype set is obtained. Fourth, generation of system-level semantic overview. In one implementation, the generation of semantic overview adopts a hierarchical aggregation strategy. First, each code directory in the code repository is traversed, and the architectural keywords of all files in that directory are collected. These keywords are used as input, and a large language model is used to generate a semantic description of the directory, summarizing the architectural responsibilities and functional scope shared by the files in that directory. Second, the semantic descriptions and directory names of all directories are collected, and these are used as input, and a large language model is used to generate a system-level semantic overview to describe the overall functional positioning and high-level design intent of the code repository. Fifth, reasoning of cluster-level semantic representation. The system-level semantic overview and each semantic prototype are jointly input. A large language model is then used to perform semantic reasoning on the file set corresponding to the semantic prototype. Based on the input content, the large language model combines the global system context and the local semantic information of the files within the prototype to generate a corresponding cluster-level semantic representation. This representation describes the overall function and architectural responsibilities of the file set represented by the prototype. This approach achieves an improvement from file-level semantics to cluster-level semantics, making the semantic representation more consistent with the overall architecture of the software system.

[0074] Step 4) Further optimize the semantic enhancement graph based on the association between files and cluster-level semantics, specifically including the following process: First, establish the association between files and clusters based on the similarity between file-level semantic representations and cluster-level semantic representations. In one implementation, for any file i, calculate its similarity to the semantic representations of each cluster, and assign the file to the cluster with the highest similarity. The assignment relationship can be expressed as:

[0075] Among them, f i The semantic representation of file i. This represents the semantic representation of the k-th cluster. This represents the cluster number to which file i belongs. After the file is assigned to a cluster, the connections between file nodes belonging to the same cluster (different files within the same cluster) are strengthened. In one implementation, the association strength between files within a cluster can be enhanced by increasing their connection weights or adding more connections, thereby improving the cohesion of the cluster structure. It is worth noting that the above-mentioned cluster-level semantic enhancement mechanism plays a particularly important role in cross-language code repositories. In multi-language mixed-development software systems, the same functional module is often implemented by files in different programming languages ​​(such as Java layer interface files and C++ layer native implementation files). Such cross-language files usually only have sparse cross-language interaction edges (such as single-point JNI calls), while each has dense structural dependencies with files in the same language. Without cluster-level semantic guidance, community detection algorithms are prone to cutting cross-language modules into multiple sub-modules divided by language boundaries.

[0076] Step 5) Perform architecture partitioning on a unified graph model that integrates structural dependencies, semantic relationships, and cross-language relationships. Specifically, this includes the following process: First, based on the dependency graph model constructed in Step 1, the nodes in the dependency graph model represent source files, and the edges represent structural dependencies, semantic relationships, and cross-language relationships between files. The semantic relationships and cross-language relationships have been integrated into the graph in Step 2 through semantic and cross-language relationship enhancement processing, and the connection relationships between files in the same cluster have been strengthened in Step 4 through file-cluster relationship enhancement processing. Edge weights are used to characterize the strength of the association between connected files. The weights of structurally dependent edges are determined by the dependency type and frequency, the weights of semantically related edges are determined by semantic similarity, the weights of cross-language related edges are determined as described in step 2, and the weights of cluster-enhancing edges are determined as described in step 4. Then, the unified graph model can be processed using graph partitioning or community detection algorithms to obtain multiple cluster structures with high cohesion and low coupling. By analyzing the tightness of connections between nodes and the distribution of edge weights, files with strong connections and high semantic association are grouped into the same module, while reducing connections between different modules. This results in high cohesion within the same module and low coupling between different modules. In one implementation, a module-degree optimization approach is used to partition the unified graph model into modules, with the optimization objective being... It can be represented as:

[0077] in, This represents the final edge weight between node i and node j in the unified graph model. The edge weight comprehensively considers structural dependencies, semantic associations, cross-language associations, and file-cluster enhancement relationships; k i and kj represents the weighted degree of node i and node j respectively; m represents the sum of the weights of all edges in the graph; γ is a resolution adjustment parameter used to control the granularity of module partitioning; For indicator functions, and The values ​​represent the modules to which node i and node j belong, respectively. A value of 1 indicates that node i and node j belong to the same module, and a value of 0 indicates otherwise. Finally, the cluster structure is used as the architectural module partitioning result of the software system to represent the overall architecture of the software system. It is worth noting that for cross-language code repositories developed using multiple languages, this embodiment explicitly introduces cross-language associations and cross-language topology completion mechanisms (i.e., semantic and cross-language relationship enhancement) in step 2. In steps 3 and 4, cluster-level semantics is used to strengthen the connections between cross-language files within the same cluster (i.e., file-cluster relationship enhancement), resulting in cross-language functional modules having a complete topological structure and enhanced cohesive connections in the dependency graph. Therefore, during community detection, cross-language functional modules are no longer incorrectly segmented due to structural breaks at language boundaries. The community detection algorithm can correctly classify different language files belonging to the same functional module into the same community.

[0078] Several advantages of this embodiment:

[0079] 1) This embodiment proposes a semantic modeling method based on phrase-level architecture topic semantics. Compared with traditional sentence-level semantic description, it can effectively reduce semantic redundancy, improve the distinguishability of semantic representations between documents, and thus avoid the problem of excessively dense semantic relationships. For example... Figure 2 As shown, the semantic similarity distribution between files obtained by this method exhibits a significant dispersion feature, laying the foundation for accurate identification of subsequent architectural boundaries.

[0080] 2) This embodiment proposes a cluster-level semantic reasoning mechanism based on cluster prototypes and system-level semantic overview. By selecting semantic centers through a coverage gain maximization strategy, a set of semantic prototypes is constructed, and cluster-level semantic representations are inferred in conjunction with system-level semantic overviews, thus achieving an improvement in semantic modeling from the file level to the cluster level. This mechanism makes semantic representations more consistent with the organization of software architecture in units of modules or subsystems, effectively suppressing semantic noise in individual files and improving the accuracy and interpretability of architecture recovery.

[0081] 3) This embodiment introduces a cross-language topology completion mechanism, specifically addressing the issue of fragile cross-language boundary topology in cross-language software systems. Based on explicit identification of cross-language interaction relationships, auxiliary connections are established between cross-language related files and their structural neighbor files within their respective programming language environments using decaying weights. This compensates for the sparse structural dependencies of cross-language modules in the graph model. This mechanism effectively avoids the problem of existing methods incorrectly separating cross-language functional modules according to language boundaries, significantly improving the architecture recovery quality of multi-language hybrid development systems.

[0082] 4) This embodiment constructs a unified graph model by integrating structural dependency information, semantic information, and cross-language information, which can more comprehensively depict the structural and semantic features of the software system, thereby obtaining more stable and accurate architecture partitioning results.

[0083] This application also provides an electronic device, including: a processor, and a memory coupled to the processor, the memory being used to store a computer program; the processor being used to execute the computer program stored in the memory, so that the electronic device performs the method as described in any of the above embodiments.

[0084] Electronic devices can be computing devices such as desktop computers, laptops, handheld computers, and cloud servers. These electronic devices may include, but are not limited to, processors and memory.

[0085] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the electronic device, connecting various parts of the device via various interfaces and lines.

[0086] The memory can be used to store the computer program, and the processor implements various functions of the electronic device by running or executing the computer program stored in the memory and calling the data stored in the memory.

[0087] The memory may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, etc.; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0088] This application also provides a storage medium, which is a computer-readable storage medium. The computer program is stored in the computer-readable storage medium, and when executed by a processor, the computer program can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0089] This application also provides a computer program product, including: a computer program or instructions that, when the computer program or instructions are run on a computer, cause the computer to perform any of the above possible implementation methods.

[0090] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications are also considered to be within the scope of protection of this application.

Claims

1. A software architecture recovery method, characterized in that, include: For a software code repository consisting of several code files, extract the structural dependencies between the code files to obtain a dependency graph with the code files as nodes and the structural dependencies as edges; The code file is semantically analyzed using a large language model to obtain architectural theme semantics composed of words that characterize the responsibilities of the code file in the software architecture. Based on the semantic similarity of the architectural themes between the code files, several semantic centers are determined from each of the code files to represent different semantic regions; Select several code files that meet the similarity requirements with the corresponding semantic center as code files without semantic centers, and construct a semantic cluster prototype; Based on the aforementioned architectural theme semantics and the directory of the software code repository, a system-level semantic overview is generated; Using the semantic cluster prototype and the system-level semantic overview as input, semantic reasoning is performed on the semantic cluster prototype using a large language model to obtain a cluster semantic representation that characterizes the overall architectural responsibilities of the semantic cluster prototype. Based on the similarity between the cluster semantic representation and the architectural theme semantics of each of the code files, a file-cluster association relationship is established from the code files to the semantic cluster prototype; A unified graph model is established based on the dependency graph and the file-cluster associations. Furthermore, the unified graph model is processed to obtain several cluster structures with high cohesion and low coupling, which are used to represent the results of software architecture module partitioning.

2. The software architecture recovery method as described in claim 1, characterized in that, The software architecture recovery method further includes: enhancing the dependency graph by adopting a preset enhancement strategy based on the semantic similarity of the architecture theme semantics between the code files.

3. The software architecture recovery method as described in claim 2, characterized in that, The preset enhancement strategy is as follows: For code file pairs that already have structural dependencies, the edge weights of the code file pairs are enhanced based on semantic similarity; For code file pairs that do not have structural dependencies but have semantic similarity higher than a preset threshold, new edges are introduced into the dependency graph, and corresponding edge weights are assigned based on semantic similarity.

4. The software architecture recovery method as described in claim 1, characterized in that, The software code repository is a multi-programming language hybrid software code repository, and the software architecture recovery method further includes: The software code repository is parsed to identify the interaction relationships between code files in different programming languages ​​and obtain cross-language associations; For code file pairs that are identified to have cross-language relationships, cross-language connection edges are established in the dependency graph and weights are assigned to the cross-language connection edges. Furthermore, based on the identified first and second code files with cross-language relationships, the first code file is programmed in a first programming language and the second code file is programmed in a second programming language, a set of structural neighbor code files of the second code in the second programming language environment is obtained, and cross-language topological completion edges are established between the first code file and each code file in the set of structural neighbor code files in the dependency graph and weights are assigned to the cross-language topological completion edges.

5. The software architecture recovery method as described in claim 1, characterized in that, Based on the semantic similarity of the architectural themes among the code files, several semantic centers representing different semantic regions are determined from each of the code files, specifically including: Initialize semantic center set , Let C be an empty set. For any code file i, the degree to which the code file i is covered by the current semantic center set C. Initialize to 0, in, Let cov(i) represent the semantic similarity between code file i and semantic center c, where cov(i) represents the degree to which file i is currently covered by the set of semantic centers C. Then, new candidate semantic centers are selected iteratively until the iterative convergence condition is met. In each iteration, for each candidate code file that has not yet been selected as a semantic center... ,calculate The coverage gain that a new semantic center can bring : in, Indicates code file i and Semantic similarity between them After calculating the coverage gain of all candidate code files, select the candidate file with the largest coverage gain. As a new semantic center, After adding the semantic center set C, update the coverage of each code file i: .

6. The software architecture recovery method as described in claim 1, characterized in that, The software architecture recovery method also includes: The overlap between different semantic cluster prototypes is calculated using Jaccard similarity. Additionally, a merging operation is performed on semantic cluster prototypes with an overlap exceeding a preset merging threshold to eliminate redundant semantic regions and reselect the semantic center after the merging operation.

7. The software architecture recovery method as described in claim 1, characterized in that, Based on the aforementioned architectural theme semantics and the directory structure of the software code repository, a system-level semantic overview is generated, specifically including: Traverse each code directory in the software code repository, collect the architectural theme semantics of all code files in that directory, use these architectural theme semantics as input, and generate a semantic description of the directory using a large language model. Additionally, the semantic descriptions and directory names of all code directories are used as input to generate a system-level semantic overview using a large language model.

8. The software architecture recovery method as described in claim 1, characterized in that, Based on the similarity between the cluster semantic representation and the architectural theme semantics of each of the code files, a file-cluster association relationship is established from the code files to the semantic cluster prototype, specifically including: For any code file, calculate the similarity between the code file and the semantic representation of each cluster, and assign the code file to the prototype of the semantic cluster with the highest similarity; Additionally, enhance the edges between code files belonging to the same semantic cluster prototype.

9. The software architecture recovery method as described in claim 1, characterized in that, The structural dependencies are: calling relationships, referencing relationships, or inclusion relationships between files; the edge weights in the dependency graph are determined comprehensively based on the type and frequency of the structural dependencies; the terms are used to describe the functional roles, scope of responsibility, and / or core operations involved in the code files.

10. An electronic device, characterized in that, The electronic device includes: a processor, and a memory coupled to the processor. The memory is used to store computer programs; The processor is configured to execute the computer program stored in the memory, so that the electronic device performs the software architecture recovery method as described in any one of claims 1-9.

Images