A method, system, device, and medium for open source component oriented code comparison
By parsing the code and extracting the dependencies of open-source components, and combining graph converters and large language models for deep semantic analysis, the problem of not being able to accurately identify the complex dependencies of open-source components in existing technologies has been solved, and more accurate code comparison and difference identification have been achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA ELECTRIC POWER RESEARCH INSTITUTE CO LTD
- Filing Date
- 2025-08-08
- Publication Date
- 2026-07-24
Smart Images

Figure CN120994231B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer software technology, and more specifically to a method, system, device, and medium for code comparison of open-source components. Background Technology
[0002] Currently, with the booming development of the software development industry, open-source components are widely used in various software projects. Many developers use open-source components to accelerate the development process, reduce costs, and reuse existing excellent code implementations. However, when using open-source components, many problems are often encountered. For example, different versions of open-source components have different functions and code structures, or the same open-source component may have compatibility and security risks after being modified in different projects. At present, most existing code comparison methods focus on basic operations such as simple text comparison between general code files. For open-source components, which have complex dependencies, diverse version systems, and rich code features, there is a lack of specialized and efficient comparison technologies. It is difficult to accurately identify changes in code under different scenarios, potential risks, and functional differences, which makes it difficult for developers and maintainers to manage and use open-source components and to quickly and accurately locate the actual differences at the code level. Summary of the Invention
[0003] To address the problem that existing technologies only perform simple text comparisons on general code files, failing to compare code objects with complex dependencies and thus unable to accurately pinpoint the actual differences between open-source components, this invention proposes a code comparison method for open-source components, comprising:
[0004] Based on the open-source components to be compared, the code of the open-source components is parsed to obtain the dependency relationships between the source codes of the open-source components;
[0005] Based on the dependencies between the source codes in the open-source components, a pre-built similarity calculation model is used to calculate the code similarity between the open-source components to obtain comprehensive similarity information between the open-source components.
[0006] Based on the comprehensive similarity information between the open-source components, code comparison is performed between the open-source components to obtain the difference information between them.
[0007] Optionally, the step of parsing the code of the open-source component to obtain the dependencies between the source codes in the open-source component includes:
[0008] The open-source component is represented by a graph converter to obtain its graph representation information.
[0009] The open-source component is subjected to text semantic analysis using a large language model to obtain its text semantic information.
[0010] Based on the graph representation information and text semantic information of the open-source component, the dependency relationships between the source codes in the open-source component are generated.
[0011] Optionally, the step of using a graph converter to perform graph behavioral representation on the open-source component to obtain the graph representation information of the open-source component includes:
[0012] Structural elements are extracted from the open-source component to construct a preliminary graph structure for the open-source component;
[0013] The initial graph structure of the open-source component is processed using a multi-layer attention mechanism of the graph converter to obtain a graph embedding representation of the open-source component.
[0014] Based on the graph embedding representation of the open-source component, output the graph representation information of the open-source component.
[0015] Optionally, the step of using a large language model to perform text semantic analysis on the open-source component to obtain the text semantic information of the open-source component includes:
[0016] The text data in the open-source component is encoded using a large language model to obtain the text representation of the open-source component;
[0017] The text representation of the open-source component is semantically enhanced by an unsupervised contrastive learning algorithm, and the text semantic information of the open-source component is output.
[0018] Optionally, the graph representation information includes one or more of the following: program dependency graph and function call graph;
[0019] The dependencies between the source codes include one or more of the following: class relationships, function relationships, and variable definition relationships.
[0020] Optionally, based on the dependencies between the source codes in the open-source components, a pre-built similarity calculation model is used to calculate the code similarity between the open-source components to obtain comprehensive similarity information between the open-source components, including:
[0021] Based on the dependencies between the source codes in the open-source components, feature extraction is performed on the open-source components to obtain the feature information of the open-source components;
[0022] Based on the feature information of each open source component, a pre-built similarity calculation model is used to calculate the code similarity between the open source components, thereby obtaining the comprehensive similarity information between the open source components.
[0023] Optionally, the step of extracting features from the open-source components based on the dependencies between their source codes to obtain feature information includes:
[0024] Based on the dependencies between the source codes in the open-source components, the syntax features of the open-source components are extracted to obtain the syntax feature information of the open-source components;
[0025] Based on the dependencies between the source codes in the open-source components, semantic features are extracted from the open-source components to obtain the semantic feature information of the open-source components;
[0026] The syntactic feature information and the semantic feature information are used as the feature information of the open source component.
[0027] Optionally, the step of calculating code similarity between the open-source components based on their feature information using a pre-built similarity calculation model to obtain comprehensive similarity information between the open-source components includes:
[0028] Based on the feature information of each open-source component, a pre-built similarity calculation model is used to perform text similarity calculation, structural similarity calculation, and semantic similarity calculation between each open-source component to obtain comprehensive similarity information between the open-source components.
[0029] Optionally, based on the feature information of each open-source component, a pre-built similarity calculation model is used to perform text similarity calculation, structural similarity calculation, and semantic similarity calculation between each open-source component to obtain comprehensive similarity information between the open-source components, including:
[0030] Based on the feature information of each open source component, a pre-built similarity calculation model is used to calculate the text similarity between the open source components, thereby obtaining the text similarity information between the open source components.
[0031] Based on the feature information of each open source component, the structural similarity between the open source components is calculated using the similarity calculation model to obtain the structural similarity information between the open source components.
[0032] Based on the feature information of each open-source component, the semantic similarity between the open-source components is calculated using the similarity calculation model to obtain the semantic similarity information between the open-source components.
[0033] The weighted similarity information, structural similarity information, and semantic similarity information are used to calculate the overall similarity information between the open-source components.
[0034] Optionally, the step of comparing the code of the open-source components based on the comprehensive similarity information between the open-source components to obtain the difference information between the open-source components, and visually displaying the difference information, includes:
[0035] Based on the comprehensive similarity information between the open-source components, all open-source components are sorted to obtain a sorted list of open-source component pairs; the list of open-source component pairs stores different open-source component pairs.
[0036] By comparing the code of different open-source component pairs using a difference metric, the difference information between the different open-source component pairs can be obtained.
[0037] Based on the same inventive concept, this invention also provides a code comparison system for open-source components, comprising:
[0038] The code parsing module is used to parse the code of each open source component to be compared, and to obtain the dependency relationships between the source codes of the open source components.
[0039] The similarity calculation module is used to calculate the code similarity between the open source components based on the dependency relationship between the source code in the open source components and using a pre-built similarity calculation model to obtain the comprehensive similarity information between the open source components.
[0040] The code comparison module is used to compare the code between the open source components based on the comprehensive similarity information between the open source components, and to obtain the difference information between the open source components.
[0041] Optionally, the code parsing module includes:
[0042] The graph representation submodule is used to perform graph behavior representation on the open source component using a graph converter to obtain the graph representation information of the open source component;
[0043] The text representation submodule is used to perform text semantic analysis on the open-source component using a large language model to obtain the text semantic information of the open-source component;
[0044] The relationship generation submodule is used to generate the dependency relationships between the source codes in the open source components based on the graph representation information and the text semantic information of the open source components.
[0045] Optionally, the diagram representation submodule includes:
[0046] The structure extraction unit is used to extract structural elements from the open-source component and construct a preliminary graph structure of the open-source component.
[0047] The graph embedding unit is used to perform multi-granularity path processing on the initial graph structure of the open source component through the multi-layer attention mechanism of the graph converter to obtain the graph embedding representation of the open source component.
[0048] The graph representation generation unit is used to output the graph representation information of the open source component based on the graph embedding representation of the open source component.
[0049] Optionally, the text representation submodule includes:
[0050] A text encoding unit is used to encode the text data in the open-source component using a large language model to obtain the text representation of the open-source component.
[0051] The semantic enhancement unit is used to semantically enhance the text representation of the open-source component through an unsupervised contrastive learning algorithm and output the text semantic information of the open-source component.
[0052] Optionally, the graph representation information includes one or more of the following: program dependency graph and function call graph;
[0053] The dependencies between the source codes include one or more of the following: class relationships, function relationships, and variable definition relationships. Optionally, the similarity calculation module includes:
[0054] The feature extraction submodule is used to extract features from the open-source components based on the dependencies between the source code in the open-source components, and obtain the feature information of the open-source components;
[0055] The comprehensive similarity calculation submodule is used to calculate the code similarity between the open source components based on the feature information of each open source component and using a pre-built similarity calculation model to obtain the comprehensive similarity information between the open source components.
[0056] Optionally, the feature extraction submodule includes:
[0057] The syntax extraction unit is used to extract syntax features from the open source component based on the dependency relationships between the source codes in the open source component, and obtain the syntax feature information of the open source component.
[0058] The semantic extraction unit is used to extract semantic features from the open source component based on the dependency relationships between the source codes in the open source component, and obtain the semantic feature information of the open source component.
[0059] A feature combination unit is used to use the syntactic feature information and the semantic feature information as feature information of the open-source component.
[0060] Optionally, the comprehensive similarity calculation submodule includes:
[0061] The multidimensional similarity calculation unit is used to perform text similarity calculation, structural similarity calculation, and semantic similarity calculation on each open source component based on the feature information of each open source component and using a pre-built similarity calculation model to obtain the comprehensive similarity information between each open source component.
[0062] Optionally, the multidimensional similarity calculation unit includes:
[0063] The text similarity calculation subunit is used to calculate the text similarity between the open source components based on the feature information of each open source component and using a pre-built similarity calculation model to obtain the text similarity information between the open source components.
[0064] The structural similarity calculation subunit is used to calculate the structural similarity between the open source components based on the feature information of each open source component and using the similarity calculation model to obtain the structural similarity information between the open source components.
[0065] The semantic similarity calculation subunit is used to calculate the semantic similarity between the open source components based on the feature information of each open source component and using the similarity calculation model to obtain the semantic similarity information between the open source components.
[0066] The multidimensional similarity calculation subunit is used to perform weighted comprehensive calculation based on the text similarity information, the structural similarity information and the semantic similarity information to obtain the comprehensive similarity information between the open source components.
[0067] Optionally, the code comparison module includes:
[0068] The sorting submodule is used to sort all the open-source components according to the comprehensive similarity information between the open-source components, and obtain a sorted list of open-source component pairs; the list of open-source component pairs stores different open-source component pairs;
[0069] The difference analysis submodule is used to compare the code of different open source component pairs using the difference measurement method to obtain the difference information between the different open source component pairs.
[0070] In another aspect, the present invention also provides an electronic device, comprising: at least one processor and a memory; the memory and the processor are connected via a bus;
[0071] The memory is used to store one or more programs;
[0072] When the one or more programs are executed by the at least one processor, a code comparison method for open-source components as described above is implemented.
[0073] In another aspect, the present invention also provides a computer device readable storage medium having an executable program stored thereon, wherein when the executable program is executed, it implements the code comparison method for open source components as described above.
[0074] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0075] This invention provides a method, system, device, and medium for code comparison of open-source components, comprising: parsing the code of each open-source component to be compared, obtaining the dependencies between the source codes of the open-source components; calculating the code similarity between the open-source components using a pre-built similarity calculation model based on the dependencies between the source codes of the open-source components, obtaining comprehensive similarity information between the open-source components; and comparing the code between the open-source components based on the comprehensive similarity information, obtaining the difference information between the open-source components. This invention, by extracting the dependencies between source codes, can identify the actual calls, references, and other relationships between code objects. Based on this, it uses a similarity calculation model for code comparison, enabling similarity analysis to extend beyond the surface syntactic dimension to the semantic level, such as function call chains and module coupling, thereby improving the accuracy and comprehensiveness of the comparison. Attached Figure Description
[0076] Figure 1 A flowchart illustrating a code comparison method for open-source components provided by this invention;
[0077] Figure 2 A schematic diagram of the structural composition of a code comparison system for open-source components provided by the present invention;
[0078] Figure 3 This is a schematic diagram of the structure of an electronic device provided by the present invention. Detailed Implementation
[0079] This invention proposes a code comparison method, system, device, and medium for open-source components. The specific embodiments of this invention will be further described in detail below with reference to the accompanying drawings.
[0080] Example 1:
[0081] This invention provides a code comparison method for open-source components, the flowchart of which is shown below. Figure 1 As shown, it includes:
[0082] Step 1: Based on the open-source components to be compared, perform code parsing on the open-source components to obtain the dependency relationships between the source code of the open-source components;
[0083] Step 2: Based on the dependencies between the source codes in the open-source components, use a pre-built similarity calculation model to calculate the code similarity between the open-source components to obtain the comprehensive similarity information between the open-source components;
[0084] Step 3: Based on the comprehensive similarity information between the open source components, perform code comparison between the open source components to obtain the difference information between the open source components.
[0085] Generally, source code comparison of open-source components relies heavily on surface-level text similarity matching, primarily employing simple comparison methods based on strings or syntactic structures. This approach struggles to effectively analyze source code containing complex dependencies within open-source components. This technical limitation makes it difficult to identify deep semantic changes caused by refactoring, renaming, or implementation differences when comparing open-source components from different versions or sources. This is especially true when code snippets differ significantly in form but remain highly similar in function; existing comparison techniques often fail to accurately identify these differences, impacting the accuracy and completeness of code reuse analysis, vulnerability tracking, and security risk assessment. To address these issues, this invention considers extracting the dependencies between internal source code within open-source components as a key entry point. It establishes a more comprehensive comparison model from both structural and semantic dimensions, moving beyond solely relying on surface-level textual features. Instead, it delves into function call relationships, inheritance or composition relationships between classes, variable definition and reference relationships, and other aspects to form an in-depth analysis of the source code's organizational structure and internal logic. Specifically:
[0086] In one implementation, the process of parsing the code of the open-source component in step 1 above to obtain the dependencies between the source codes of the open-source component may include:
[0087] The open-source component is represented by a graph converter to obtain its graph representation information.
[0088] The open-source component is subjected to text semantic analysis using a large language model to obtain its text semantic information.
[0089] Based on the graph representation information and text semantic information between the open-source components, the dependency relationships between the source codes in the open-source components are generated.
[0090] The graph representation information may include one or more of the following: Program Dependency Graph (PDG) and Function Call Graph (FCG);
[0091] The dependencies between the source codes may include one or more of the following: class relationships, function relationships, and variable definition relationships;
[0092] For example, the graph converter described above can use 1×1 convolution to soft-select two different graph structures, as shown in the following expression:
[0093]
[0094] Where Q represents graph representation information (i.e., graph rows represent the generated adjacency matrix); Con represents convolution; A represents open-source components; A i W represents a slice of component of type i; W represents the parameters of the convolution operation; W i Component A of type i i Weights; i = 1…|T e |;T e Indicates the total number of component types;
[0095] For example, when using a large language model to perform text semantic analysis on open-source components, bidirectional attention can be used to enable the model to pay attention to all positions (including past and future) in the code snippet simultaneously. This addresses the issue that the interaction between control tags in traditional large language models is a unidirectional mechanism, which limits the model's attention to the current and previous time steps and explicitly prevents access to future information. Although this architecture is effective for autoregression tasks that require sequential output generation, its inherent time constraints are not suitable for text embedding tasks. Bidirectional attention enables the model to capture global contextual information, which is beneficial for text embedding tasks.
[0096] In this implementation, by utilizing a graph converter to construct a program dependency graph or function call graph, the structured relationships of the code during execution can be accurately restored, making the calls and data flow between different modules, functions, and variables clearly identifiable. Such graph structures are difficult to represent in traditional text comparison. Simultaneously, a large language model is used to extract semantic information from the source code, possessing the ability to understand code intent across languages and styles. This compensates for semantic relationships that structural analysis alone cannot capture, especially between code segments with diverse naming conventions, different syntactic structures, but similar functions; semantic analysis becomes a key means to accurately identify their inherent connections. By combining graph structure information with semantic information to generate multi-level dependencies such as class relationships, function relationships, and variable definition relationships, a more expressive code dependency model than traditional static analysis is constructed. This enables comprehensive identification of structural and semantic compatibility in complex component comparisons, directly resulting in more accurate code similarity calculations and more targeted difference identification. This implementation, combining a graph converter with a large language model for code dependency extraction, not only involves the synergistic integration of graph computation and natural language understanding but also requires designing a reasonable mechanism at the data representation layer to achieve effective alignment between structure and semantics. In practical engineering scenarios, graph structures are often extracted statically, while large language models are more suitable for processing unstructured semantics. The combination of the two can not only solve the differences in information granularity and representation, but also ensure the contextual consistency and integrity of the dependencies after fusion. Furthermore, in open-source component comparison tasks, when faced with interference from differences in code style, naming habits, and module division, it is often difficult to achieve high-quality matching if only structural or semantic methods are used. This implementation method, through joint modeling of "structure + semantics", effectively breaks through the accuracy bottleneck faced by existing comparison methods. Furthermore, to enhance the generalization and intelligence of the source code parsing process, a dynamic dependency adjustment mechanism based on historical version evolution information can be added as a new technical feature. By introducing the code change history recorded in version control systems (such as Git), combined with the change location, frequency, and developer comments, the source code dependencies can be modeled and dynamically updated in a temporal manner. This can help the system identify which dependencies are superficial changes brought about by structural refactoring and which are substantial differences caused by functional evolution. This is conducive to further reducing the false positive rate of comparison, improving the pertinence of version difference analysis, and providing data support for security backtracking and vulnerability propagation path identification in the software evolution process.
[0097] The above implementation method enables the parsing of source code in open-source components. To further improve the expressive power and structural accuracy of graph representation information, more detailed modeling and optimization of the graph behavior representation process of open-source components can be considered. Especially in code scenarios with complex structures or close cross-module relationships, relying solely on basic graph construction methods is insufficient to fully capture the multi-level relationships implicit in the code. Specifically:
[0098] In one implementation, the process of using a graph converter to perform graph behavioral representation on the open-source component to obtain the graph representation information of the open-source component may include:
[0099] Structural elements are extracted from the open-source component to construct a preliminary graph structure of the open-source component;
[0100] The initial graph structure of the open-source component is processed using a multi-layer attention mechanism of the graph converter to obtain a graph embedding representation of the open-source component.
[0101] Based on the graph embedding representation of the open-source component, output the graph representation information of the open-source component.
[0102] In this implementation, by introducing a graph converter to represent open-source components as graph behaviors, the accuracy and depth of code structure modeling can be effectively improved. By extracting structural elements, functions, classes, variables, and their relationships in the original source code are explicitly transformed into preliminary graph structures. The multi-layer attention mechanism of the graph converter is then used to process the preliminary graph structure at multiple granularities, which can capture complex structural features such as long-distance dependencies and implicit call chains in the code, giving the model a stronger ability to understand structures. This path-level attention mechanism not only improves the semantic distinguishability of graph embedding representations but also enhances the ability to characterize the contextual relationships between different code segments. Finally, the graph representation information generated by the graph embedding serves as the core expression carrier of structural features, possessing characteristics such as high-dimensional compression, relationship preservation, and semantic fusion. This enables this implementation to achieve better recognition results and performance when handling large-scale, structurally complex open-source component comparison tasks. While the graph neural networks and attention mechanisms used in this implementation are existing research directions in the field of machine learning, their specific combination in the source code comparison scenario can form a deep structural modeling path oriented towards source code. This path, based on an understanding of the characteristics of code structure and the modeling capabilities of graph neural networks, selectively introduces suitable attention mechanisms to solve the problems of information loss and dependency masking in actual comparisons, demonstrating adaptability to specific technical scenarios and systematicity for complex structural feature extraction. Furthermore, after the graph representation is generated, this implementation can also consider introducing a structural alignment algorithm to match and map the graph structures of multiple open-source components, automatically identifying structurally similar and dissimilar regions. This enhances the contextual consistency of subsequent similarity calculations, especially in scenarios such as function renaming, module splitting, or reconstruction. Structural alignment can effectively reduce misjudgments caused by semantic drift and improve the accuracy and stability of difference detection.
[0103] The above implementation method yields graph representation information with structural expressive capabilities. To comprehensively characterize the code features of open-source components, deeper semantic information can be extracted. Considering the presence of a large amount of natural language description mixed with programming language in the source code, relying solely on structural analysis is insufficient to capture the developer's true intent and functional logic. Therefore, a large language model can be combined to semantically model the textual information in open-source components, leveraging deep language understanding capabilities to uncover the semantic relationships behind the code. Specifically:
[0104] In one implementation, the process of performing text semantic analysis on the open-source component using a large language model to obtain the text semantic information of the open-source component may include:
[0105] The text data in the open-source component is encoded using a large language model to obtain the text representation of the open-source component;
[0106] The text representation of the open-source component is semantically enhanced by an unsupervised contrastive learning algorithm, and the text semantic information of the open-source component is output.
[0107] For example, when performing semantic enhancement on the text representation of open-source components using unsupervised contrastive learning, in order to improve the modeling ability of text information, the contrastive loss SimCSE can be used as the non-penetrating loss function, as shown in the following expression:
[0108]
[0109] Among them, L cl The loss function is represented by e; the exponential function by sim; the cosine value by τ; and the temperature parameter by S. S represents a code snippet. + This indicates that the code snippet S is directly opposite; This represents the negative pair of code snippet S corresponding to mask j; j = 1…N; N represents the total number of masks;
[0110] In this implementation, a large language model is introduced to encode text data in open-source components, and unsupervised contrastive learning is used to semantically enhance the encoding results. This significantly improves the depth and accuracy of code semantic modeling. In source code, function names, variable names, comments, and inter-module call statements usually contain rich semantic information, but this information is often ignored in traditional structural analysis or lexical processing. The large language model has context awareness and semantic understanding capabilities, enabling it to construct high-dimensional, context-related representations of these text fragments. This allows the model to not only recognize the "writing style" of the code but also understand its "intention." Furthermore, through unsupervised contrastive learning, the model can automatically enhance its semantic discrimination ability for code fragments with similar functions but large formal differences by constructing positive and negative samples, even in the absence of explicit annotations. This solves the semantic bias problem caused by different variable naming styles and comment language differences. This information modeling method based on semantic enhancement can improve the accuracy of code comparison while also enhancing the system's adaptability and robustness to multi-language and multi-version components. In real-world scenarios, different versions of components often undergo large-scale refactoring or cross-language migration, making it difficult to identify their inherent functional consistency using only lexical analysis or shallow semantic matching. Using large language models for source code semantic modeling enhances the model's ability to handle mixed structures of natural and programming languages. Contrastive learning effectively overcomes performance bottlenecks caused by missing annotations in code scenarios lacking explicit labels. Combining these two approaches for code representation learning, and improving discriminative and convergent properties through contrastive constraints during training, demonstrates a deep adaptation between task objectives, data characteristics, and model capabilities. Furthermore, this implementation can consider adding a code context window control mechanism as a new technical feature. This dynamically determines the input range and granularity of the language model based on the call scope of functions or classes, adapting to the semantic analysis needs of code fragments of different sizes. This feature effectively controls the encoding boundaries of large language models, avoiding context dilution caused by excessively long inputs and semantic loss caused by excessively short inputs, thereby further improving the focus and semantic expression accuracy of text representation. It exhibits stronger robustness and consistency in expression when facing loosely structured, poorly annotated, or complexly nested code.
[0111] The above implementation method enables joint modeling of the structural and semantic features of open-source components. To further measure the similarity between different open-source components, a similarity calculation mechanism can be introduced on this basis. Specifically:
[0112] In one implementation, step 2 above, which involves calculating code similarity between the open-source components based on the dependencies between their source codes and using a pre-built similarity calculation model to obtain comprehensive similarity information, may include:
[0113] Based on the dependencies between the source codes in the open-source components, feature extraction is performed on the open-source components to obtain the feature information of the open-source components;
[0114] Based on the feature information of each open source component, a pre-built similarity calculation model is used to calculate the code similarity between the open source components, so as to obtain the comprehensive similarity information between the open source components.
[0115] This implementation introduces a feature extraction mechanism based on dependencies between source code elements, and uses these features as input to build a similarity calculation model. This allows for the full characterization and quantification of the structural and semantic differences between different open-source components. Dependencies themselves are high-dimensional, highly correlated structural information. Compared to traditional code-text-based comparisons, they reflect the logical connections and coupling strength between functions, classes, variables, and other elements within a component. Therefore, introducing this relationship during feature extraction greatly improves the completeness and accuracy of feature representation. After mapping these dependencies into structured feature vectors, a pre-trained similarity model (such as a graph neural network model or a distance-based learning model) can effectively model the overall similarity between multiple components. This ensures that even if components have subtle differences in their implementation, they can be identified as similar components as long as their internal structural logic is consistent or their functions are similar. Using dependencies as the core perspective not only covers multi-level structural features but also captures dynamic behavioral features such as function call chains, variable flow, and inter-class inheritance.
[0116] In this implementation, the process of extracting features from the open-source component based on the dependencies between its source codes to obtain the feature information of the open-source component may specifically include:
[0117] Based on the dependencies between the source codes in the open-source components, the syntax features of the open-source components are extracted to obtain the syntax feature information of the open-source components;
[0118] Based on the dependencies between the source codes in the open-source components, semantic features are extracted from the open-source components to obtain the semantic feature information of the open-source components;
[0119] The syntactic and semantic features are used as the feature information of the open-source component. This specific implementation combines syntactic and semantic feature extraction to form the overall feature information of the open-source component, which can significantly improve the comprehensiveness and accuracy of code similarity analysis. Syntactic feature extraction relies on the static structural information of the source code, such as function definitions, variable scope, and class hierarchy, providing clear and regular formal support when encoding the component structure. Semantic feature extraction, on the other hand, relies more on the understanding of the logical meaning and contextual intent of the code, and can identify functionally equivalent or similar code segments under different syntactic implementations. In particular, the extraction of syntactic and semantic features under the guidance of dependency relationships allows feature construction to focus on the core structure and key interaction paths within the component, avoiding redundancy and noise interference. The fusion of these two types of features for subsequent similarity modeling can not only cover the structural comparison at the formal level, but also identify code behaviors that are superficially different but substantially consistent due to style differences or naming diversity. This improves the ability to identify cross-version, heterogeneous implementations, and even obfuscated code, and has strong adaptability and practicality. Syntax analysis in the general sense is often based on AST (Abstract Syntax Tree), but this implementation does not extract the structure from the AST in isolation. Instead, it combines the actual call and data flow relationships between code shown in the dependency graph to map the abstract syntactic structure to specific logical paths. The semantic modeling part also uses the dependency graph to focus on the critical path, so that the semantic vector is not only expressed based on the fragment context, but also associated with the global call logic, reflecting "semantic co-occurrence under structural constraints".
[0120] The above implementation method can extract syntactic and semantic features from open-source components. However, since different components may have structural changes, differences in expression, or semantic substitutions in practical applications, relying solely on a single-dimensional feature is insufficient to cover the actual similarity judgment requirements. Therefore, based on the extracted multi-dimensional feature information, a similarity calculation model can be further introduced to quantify the similarity relationship between components, realizing the calculation of comprehensive similarity between open-source components. Specifically:
[0121] In one implementation, the process of calculating code similarity between the open-source components based on their feature information using a pre-built similarity calculation model to obtain comprehensive similarity information between the open-source components may specifically include:
[0122] Based on the feature information of each open-source component, a pre-built similarity calculation model is used to perform text similarity calculation, structural similarity calculation, and semantic similarity calculation between each open-source component to obtain comprehensive similarity information between the open-source components.
[0123] In this implementation, the process of calculating text similarity, structural similarity, and semantic similarity between the open-source components based on their feature information and using a pre-built similarity calculation model to obtain comprehensive similarity information between the open-source components may specifically include:
[0124] Based on the feature information of each open source component, a pre-built similarity calculation model is used to calculate the text similarity between the open source components, thereby obtaining the text similarity information between the open source components.
[0125] Based on the feature information of each open source component, the structural similarity between the open source components is calculated using the similarity calculation model to obtain the structural similarity information between the open source components.
[0126] Based on the feature information of each open-source component, the semantic similarity between the open-source components is calculated using the similarity calculation model to obtain the semantic similarity information between the open-source components.
[0127] The comprehensive similarity information between the open-source components is obtained by weighted calculation based on the text similarity information, the structural similarity information, and the semantic similarity information.
[0128] In this specific implementation, detailed calculations of text similarity, structural similarity, and semantic similarity are performed on open-source components separately. A weighted summation is then used to obtain the final comprehensive similarity information, demonstrating strong discriminative and expressive capabilities. The "text similarity calculation" (e.g., comparing the intersection and union of word sets in two code snippets using Jaccard similarity calculation, or using a SimHash function to detect similarity) captures the similarity of components in naming, annotation, and expression style, suitable for recognizing intuitive code reuse. The "structural similarity calculation" (e.g., comparing abstract syntax trees, control flow graphs, data flow graphs, or using code clone detection tools) leverages extracted... Structured features such as dependencies between functions, classes, and variables identify the similarity in module organization, thus supporting reasonable comparison results even when the structure changes but the logic remains the same. "Semantic similarity calculation" (e.g., through code vectorization models, function summary comparison, dynamic execution path analysis, etc.) further explores the inherent logical consistency at the functional implementation level. It is particularly suitable for judging cases where semantics are maintained but syntactic morphology differs significantly, such as variable renaming, syntax replacement, and cross-language porting. By weightedly fusing the above three types of similarity information, a good balance can be achieved between information comprehensiveness and comparison accuracy, effectively reducing misjudgments or omissions caused by a single feature dimension, thereby improving the accuracy and applicability of code similarity recognition results.
[0129] The above implementation method enables the fusion calculation of textual, structural, and semantic similarity among various open-source components to obtain comprehensive similarity information. Based on this comprehensive similarity information, more targeted inter-component comparison analysis can be conducted to identify specific differences and assist downstream decision-making. Specifically:
[0130] In one implementation, step 3 above, which involves comparing the code of the open-source components based on the comprehensive similarity information between them to obtain the difference information, and then visualizing the difference information, may include:
[0131] Based on the comprehensive similarity information between the open-source components, all open-source components are sorted to obtain a sorted list of open-source component pairs; the list of open-source component pairs stores different open-source component pairs.
[0132] The code of different open source component pairs is compared by using a difference measurement method to obtain the difference information between the different open source component pairs.
[0133] Visualization tools are used to display the differences between the various open-source component pairs.
[0134] For example, the difference information may include: structural differences, functional differences, and textual differences;
[0135] In practice, the process of "sorting all open-source components to obtain a sorted list of open-source component pairs" can be implemented using a sorting method based on comprehensive similarity scores. This involves using a database of multiple versions or functionally similar components stored in the open-source component database to perform multi-dimensional feature comparisons (text, structure, and semantics) between each pair of components using a similarity calculation model. The components are then sorted from highest to lowest score, with higher similarity pairs prioritized for analysis, generating the "sorted list of open-source component pairs." For example, in a given analysis task, open-source component A (v1.0) has a comprehensive similarity of 82% with A (v1.1), while A (v1.0) has a comprehensive similarity of only 43% with component B. Therefore, the former is prioritized in the component pair list and placed at the forefront of the comparison analysis. The purpose of comparing differences in "open-source component pairs" is to specifically identify the differences at the implementation level between two versions or two open-source components with similar implementation logic. Compared to comparing the entire codebase, this approach, using component pairs as the basic unit of analysis, is more controllable and targeted. It can accurately pinpoint fine-grained differences such as evolution, functional modifications, and structural changes between specific components, avoiding irrelevant information interference caused by large-scale multi-component comparisons, thereby improving the accuracy and efficiency of difference identification. At the same time, this method also facilitates layer-by-layer tracing by combining component dependencies or version evolution paths, helping developers, operations personnel, or compliance analysts quickly understand the nature and scope of code changes, and improving technical support capabilities in scenarios such as code maintenance, version management, and open-source component replacement assessment.
[0136] Therefore, this implementation effectively avoids blind or inefficient full-code comparison by combining comprehensive similarity information to sort and filter open-source components. Furthermore, the application of difference measurement methods for targeted analysis of the sorted component pairs not only improves comparison accuracy but also reduces system resource consumption. One key feature is the adoption of a multi-dimensional comparison strategy encompassing structural, functional, and textual differences, resulting in more comprehensive acquisition of difference information. Additionally, visualization tools can be introduced to display the comparison results, presenting abstract difference results intuitively in graphical, color, or modular form, thereby lowering the user's understanding threshold, improving the efficiency of manual review, and providing more operational support in scenarios such as open-source compliance auditing, risk assessment, and version evolution tracking.
[0137] In summary, this invention addresses the problem that existing technologies only perform simple text comparisons on general code files, failing to compare code objects with complex dependencies, thus making it impossible to accurately locate the actual differences between open-source components. It proposes a code comparison method for open-source components. This method parses the code of the open-source components to be compared, extracts the dependencies between their source codes, and then uses a pre-built similarity calculation model based on these dependencies to perform multi-dimensional similarity analysis between the open-source components, obtaining comprehensive similarity information. Based on this, code comparison is performed, extracting differences and displaying the results visually.
[0138] Therefore, the technical solution of the present invention can bring about the following technical effects:
[0139] (1) High accuracy: Through multi-dimensional feature extraction and comparison, it can accurately analyze the similarities and differences of open source component code at various levels, avoid misjudgment caused by relying solely on text comparison, and more accurately locate the actual changes in the code;
[0140] (2) Comprehensiveness: Taking into account factors such as syntax, semantics, and dependencies, it can not only discover surface modifications to the code, but also gain insight into deeper issues such as potential functional changes and compatibility risks, providing a comprehensive reference for the reasonable use and management of open source components.
[0141] (3) High efficiency and convenience: The automated parsing, comparison and visualization process greatly reduces the workload and time cost of manual analysis of code differences. Developers and maintenance personnel can quickly obtain the comparison results and make decisions accordingly, thereby improving the overall efficiency of software development and maintenance.
[0142] Example 2:
[0143] The implementation process of the code comparison method for open-source components proposed in this invention is illustrated by a specific embodiment, including:
[0144] 1. Example scenario setting:
[0145] Suppose there are two open-source components, version 1.0 and version 1.1 of open-source project A, both developed in Java and used to implement similar network data transmission functions. However, in practical applications, certain compatibility issues may be found. The comparison method of this invention is used to analyze their code differences.
[0146] 2. Code parsing phase:
[0147] The code of these two versions of open-source components was parsed by combining a graph converter and a large language model. For Java code files, the various classes (such as network connection classes, data processing classes, etc.), functions (such as data sending functions, data receiving functions, etc.), and variable definitions were identified. At the same time, the dependencies of the code on other open-source libraries (such as logging libraries, encryption libraries, etc.) were sorted out, and the parsing results were stored in a structured manner for easy feature extraction later.
[0148] 3. Feature extraction stage:
[0149] The feature extraction phase focuses on the parsed code content. For syntactic features, it counts the number of functions, the number of parameters, and the indentation level in each class, reflecting the syntactic structure. For semantic feature extraction, it uses lexical analysis combined with code logic comments to abstract the general functional semantics of functions; for example, the main semantics of a data sending function is to send data in a specific format to a specified target according to a given protocol. Dependency features explicitly record the various external libraries that the component depends on and their version ranges. These features are then processed according to predetermined quantization and encoding rules to generate feature vector representations for comparison.
[0150] 4. Algorithm execution phase:
[0151] The feature vectors corresponding to the two versions of the open-source component code are aligned in a unified space using a comparison algorithm. Then, according to a predefined similarity calculation model, similarity scores are calculated for syntax, semantics, and dependency dimensions. For example, the calculation shows a syntax similarity of 80% (indicating that most of the code structure remains consistent, but some function structures have been adjusted), a semantic similarity of 70% (meaning that the functional logic of some functions has been modified), and a dependency similarity of 90% (indicating that the external libraries used for dependency remain largely unchanged, but the version ranges of some libraries have been slightly adjusted). Based on preset weights (assuming syntax, semantics, and dependency weights are 0.3, 0.4, and 0.3 respectively), the overall code similarity score is calculated to be 77%. This indicates that there are significant differences between the two versions of the code, and further analysis of the specific changes is needed.
[0152] 5. Difference Analysis and Visualization Stage:
[0153] Based on the similarity calculation results, combined with difference analysis and visualization, we can delve deeper into the differences between the codes, precisely pinpointing specific code changes in version 1.1 compared to version 1.0, such as the addition of a data encryption function to enhance transmission security and modifications to parameter validation logic in some data sending functions. Simultaneously, these comparison results and difference details are displayed through a visualization interface. For example, newly added code can be highlighted in green, deleted code in red, and modified code in yellow, and changes in dependencies are shown in chart form. This allows developers to clearly grasp the overall changes in the code, analyze the root causes of potential compatibility issues, and take corresponding improvement measures.
[0154] As can be seen from the above specific embodiments, the code comparison method for open-source components proposed in this invention can achieve structured parsing, multi-dimensional feature modeling, and refined difference analysis when dealing with code objects containing complex dependencies, significantly improving the accuracy and depth of code comparison. Compared with traditional coarse-grained comparison methods based solely on text content, this method can not only accurately depict the actual code differences between different versions from the dimensions of syntax, semantics, and dependencies, but also visualize the comparison results, enabling developers to intuitively grasp the details of changes and potential risks in component evolution. This approach not only improves the accuracy of difference identification but also significantly reduces the burden of manual analysis, thereby improving the controllability and maintenance efficiency of open-source components during version iteration, and providing reliable technical support for practical application scenarios such as software upgrades, risk assessments, and compliance management.
[0155] Example 3:
[0156] Based on the same inventive concept, this invention also provides a code comparison system for open-source components, the structural composition of which is shown in the schematic diagram below. Figure 2 As shown, it includes:
[0157] The code parsing module is used to parse the code of each open source component to be compared, and to obtain the dependency relationships between the source codes of the open source components.
[0158] The similarity calculation module is used to calculate the code similarity between the open source components based on the dependency relationship between the source code in the open source components and using a pre-built similarity calculation model to obtain the comprehensive similarity information between the open source components.
[0159] The code comparison module is used to compare the code between the open source components based on the comprehensive similarity information between the open source components, and to obtain the difference information between the open source components.
[0160] In one implementation, the code parsing module described above may include:
[0161] The graph representation submodule is used to perform graph behavior representation on the open source component using a graph converter to obtain the graph representation information of the open source component;
[0162] The text representation submodule is used to perform text semantic analysis on the open-source component using a large language model to obtain the text semantic information of the open-source component;
[0163] The relationship generation submodule is used to generate the dependency relationships between the source codes of the open source components based on the graph representation information between the open source components and the text semantic information;
[0164] The graph representation information may include one or more of the following: program dependency graph, function call graph;
[0165] The dependencies between the source codes can include one or more of the following: class relationships, function relationships, and variable definition relationships.
[0166] In this implementation, the aforementioned graph representation submodule may include:
[0167] The structure extraction unit is used to extract structural elements from the open-source component and construct a preliminary graph structure of the open-source component.
[0168] The graph embedding unit is used to perform multi-granularity path processing on the initial graph structure of the open source component through the multi-layer attention mechanism of the graph converter to obtain the graph embedding representation of the open source component.
[0169] The graph representation generation unit is used to output the graph representation information of the open source component based on the graph embedding representation of the open source component.
[0170] In this implementation, the text representation submodule described above may include:
[0171] A text encoding unit is used to encode the text data in the open-source component using a large language model to obtain the text representation of the open-source component.
[0172] The semantic enhancement unit is used to semantically enhance the text representation of the open-source component through an unsupervised contrastive learning algorithm and output the text semantic information of the open-source component.
[0173] In one implementation, the similarity calculation module described above may include:
[0174] The feature extraction submodule is used to extract features from the open-source components based on the dependencies between the source code in the open-source components, and obtain the feature information of the open-source components;
[0175] The comprehensive similarity calculation submodule is used to calculate the code similarity between the open source components based on the feature information of each open source component and using a pre-built similarity calculation model to obtain the comprehensive similarity information between the open source components.
[0176] In this implementation, the feature extraction submodule described above may include:
[0177] The syntax extraction unit is used to extract syntax features from the open source component based on the dependency relationships between the source codes in the open source component, and obtain the syntax feature information of the open source component.
[0178] The semantic extraction unit is used to extract semantic features from the open source component based on the dependency relationships between the source codes in the open source component, and obtain the semantic feature information of the open source component.
[0179] A feature combination unit is used to use the syntactic feature information and the semantic feature information as feature information of the open-source component.
[0180] In this implementation, the aforementioned comprehensive similarity calculation submodule may include:
[0181] The multidimensional similarity calculation unit is used to perform text similarity calculation, structural similarity calculation, and semantic similarity calculation on each open source component based on the feature information of each open source component and using a pre-built similarity calculation model to obtain the comprehensive similarity information between each open source component.
[0182] In this implementation, the aforementioned multidimensional similarity calculation unit may include:
[0183] The text similarity calculation subunit is used to calculate the text similarity between the open source components based on the feature information of each open source component and using a pre-built similarity calculation model to obtain the text similarity information between the open source components.
[0184] The structural similarity calculation subunit is used to calculate the structural similarity between the open source components based on the feature information of each open source component and using the similarity calculation model to obtain the structural similarity information between the open source components.
[0185] The semantic similarity calculation subunit is used to calculate the semantic similarity between the open source components based on the feature information of each open source component and using the similarity calculation model to obtain the semantic similarity information between the open source components.
[0186] The multidimensional similarity calculation subunit is used to perform weighted comprehensive calculation based on the text similarity information, the structural similarity information and the semantic similarity information to obtain the comprehensive similarity information between the open source components.
[0187] In one implementation, the code comparison module described above may include:
[0188] The sorting submodule is used to sort all the open-source components according to the comprehensive similarity information between the open-source components, and obtain a sorted list of open-source component pairs; the list of open-source component pairs stores different open-source component pairs;
[0189] The difference analysis submodule is used to compare the code of different open source component pairs using the difference measurement method to obtain the difference information between the different open source component pairs.
[0190] The visualization submodule is used to display the differences between the different open-source component pairs using visualization tools;
[0191] The difference information may include: structural differences, functional differences, and textual differences.
[0192] Example 4:
[0193] like Figure 3 As shown, the present invention also provides an electronic device, which may be a computer device, a microcontroller device, a smart mobile device, etc. The electronic device in this embodiment may include a processor, a memory, a transceiver component, etc. The memory, processor, and transceiver component are connected via a bus; the memory can be used to store executable programs, and an exemplary executable program may include instructions; the processor is used to execute the instructions stored in the memory. The memory can also be used to store data, which can be accessed and / or modified when instructions are executed.
[0194] The processor may be a Central Processing Unit (CPU), or it may be 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. It is the computing and control core of the terminal, and it is suitable for implementing one or more instructions. Specifically, it is suitable for loading and executing one or more instructions in the storage medium to implement the corresponding method flow or corresponding function, so as to implement the steps of the code comparison method for open source components in the above embodiments.
[0195] Example 5:
[0196] Based on the same inventive concept, this invention also provides a readable storage medium, specifically an electronic device readable storage medium (Memory). This readable storage medium is a memory device within an electronic device used to store programs and data. It is understood that the storage medium here can include both built-in storage media within the electronic device and extended storage media supported by the electronic device. The storage medium provides storage space, which stores the terminal's operating system. Furthermore, this storage space also stores one or more instructions suitable for loading and execution by a processor. These instructions can be one or more executable programs (including program code). It should be noted that the storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device. Loading and executing one or more instructions stored in the storage medium by the processor can implement the steps of the code comparison method for open-source components described in the above embodiments.
[0197] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0198] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0199] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0200] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0201] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit its scope of protection. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that after reading the present invention, they can still make various changes, modifications or equivalent substitutions to the specific implementation methods of the application, but these changes, modifications or equivalent substitutions are all within the scope of protection of the claims pending approval.
Claims
1. A code comparison method for open-source components, characterized in that, include: Based on the open-source components to be compared, structural elements are extracted from the open-source components to construct a preliminary graph structure of the open-source components. The initial graph structure of the open-source component is processed using a multi-layer attention mechanism of the graph converter to obtain a graph embedding representation of the open-source component. Based on the graph embedding representation of the open-source component, output the graph representation information of the open-source component; The open-source component is subjected to text semantic analysis using a large language model to obtain its text semantic information. Based on the graph representation information and text semantic information of the open-source component, the dependency relationships between the source codes in the open-source component are generated; Based on the dependencies between the source codes in the open-source components, the syntax features of the open-source components are extracted to obtain the syntax feature information of the open-source components; Based on the dependencies between the source codes in the open-source components, semantic features are extracted from the open-source components to obtain the semantic feature information of the open-source components; The syntactic feature information and the semantic feature information are used as the feature information of the open-source component; Based on the feature information of each open source component, a pre-built similarity calculation model is used to calculate the code similarity between the open source components, so as to obtain the comprehensive similarity information between the open source components. Based on the comprehensive similarity information between the open-source components, code comparison is performed between the open-source components to obtain the difference information between them.
2. The method as described in claim 1, characterized in that, The step of using a large language model to perform text semantic analysis on the open-source component to obtain the text semantic information of the open-source component includes: The text data in the open-source component is encoded using a large language model to obtain the text representation of the open-source component; The text representation of the open-source component is semantically enhanced by an unsupervised contrastive learning algorithm, and the text semantic information of the open-source component is output.
3. The method as described in claim 1, characterized in that, The graph representation information includes one or more of the following: program dependency graph and function call graph; The dependencies between the source codes include one or more of the following: class relationships, function relationships, and variable definition relationships.
4. The method as described in claim 1, characterized in that, The step involves calculating code similarity between the open-source components based on their feature information using a pre-built similarity calculation model to obtain comprehensive similarity information between them, including: Based on the feature information of each open-source component, a pre-built similarity calculation model is used to perform text similarity calculation, structural similarity calculation, and semantic similarity calculation between each open-source component to obtain comprehensive similarity information between the open-source components.
5. The method as described in claim 4, characterized in that, The step involves calculating text similarity, structural similarity, and semantic similarity between the open-source components based on their feature information and using a pre-built similarity calculation model to obtain comprehensive similarity information between the open-source components, including: Based on the feature information of each open source component, a pre-built similarity calculation model is used to calculate the text similarity between the open source components, thereby obtaining the text similarity information between the open source components. Based on the feature information of each open source component, the structural similarity between the open source components is calculated using the similarity calculation model to obtain the structural similarity information between the open source components. Based on the feature information of each open-source component, the semantic similarity between the open-source components is calculated using the similarity calculation model to obtain the semantic similarity information between the open-source components. The weighted similarity information, structural similarity information, and semantic similarity information are used to calculate the overall similarity information between the open-source components.
6. The method as described in claim 1, characterized in that, The step of comparing the code of each open-source component based on the comprehensive similarity information between the components to obtain the difference information between the components includes: Based on the comprehensive similarity information between the open-source components, all open-source components are sorted to obtain a sorted list of open-source component pairs; the list of open-source component pairs stores different open-source component pairs. By comparing the code of different open-source component pairs using a difference metric, the difference information between the different open-source component pairs can be obtained.
7. A code comparison system for open-source components, characterized in that, include: The code parsing module is used to parse the code of each open source component to be compared, and to obtain the dependency relationships between the source codes of the open source components. The similarity calculation module is used to calculate the code similarity between the open source components based on the dependency relationship between the source code in the open source components and using a pre-built similarity calculation model to obtain the comprehensive similarity information between the open source components. The code comparison module is used to compare the code between the open source components based on the comprehensive similarity information between the open source components, and to obtain the difference information between the open source components. The code parsing module includes: The graph representation submodule is used to perform graph behavior representation on the open source component using a graph converter to obtain the graph representation information of the open source component; The text representation submodule is used to perform text semantic analysis on the open-source component using a large language model to obtain the text semantic information of the open-source component; The relationship generation submodule is used to generate the dependency relationships between the source codes in the open source components based on the graph representation information and the text semantic information of the open source components; The diagram representation submodule includes: The structure extraction unit is used to extract structural elements from the open-source component and construct a preliminary graph structure of the open-source component. The graph embedding unit is used to perform multi-granularity path processing on the initial graph structure of the open source component through the multi-layer attention mechanism of the graph converter to obtain the graph embedding representation of the open source component. The graph representation generation unit is used to output the graph representation information of the open source component based on the graph embedding representation of the open source component; The similarity calculation module includes: The feature extraction submodule is used to extract features from the open-source components based on the dependencies between the source codes in the open-source components, and obtain the feature information of the open-source components; The comprehensive similarity calculation submodule is used to calculate the code similarity between the open source components based on the feature information of each open source component and using a pre-built similarity calculation model to obtain the comprehensive similarity information between the open source components. The feature extraction submodule includes: The syntax extraction unit is used to extract syntax features from the open source component based on the dependency relationships between the source codes in the open source component, and obtain the syntax feature information of the open source component. The semantic extraction unit is used to extract semantic features from the open source component based on the dependency relationships between the source codes in the open source component, and obtain the semantic feature information of the open source component. A feature combination unit is used to use the syntactic feature information and the semantic feature information as feature information of the open-source component.
8. The system as described in claim 7, characterized in that, The text representation submodule includes: A text encoding unit is used to encode the text data in the open-source component using a large language model to obtain the text representation of the open-source component. The semantic enhancement unit is used to semantically enhance the text representation of the open-source component through an unsupervised contrastive learning algorithm and output the text semantic information of the open-source component.
9. The system as described in claim 7, characterized in that, The graph representation information includes one or more of the following: program dependency graph and function call graph; The dependencies between the source codes include one or more of the following: class relationships, function relationships, and variable definition relationships.
10. The system as described in claim 7, characterized in that, The comprehensive similarity calculation submodule includes: The multidimensional similarity calculation unit is used to perform text similarity calculation, structural similarity calculation, and semantic similarity calculation on each open source component based on the feature information of each open source component and using a pre-built similarity calculation model to obtain the comprehensive similarity information between each open source component.
11. The system as claimed in claim 10, characterized in that, The multidimensional similarity calculation unit includes: The text similarity calculation subunit is used to calculate the text similarity between the open source components based on the feature information of each open source component and using a pre-built similarity calculation model to obtain the text similarity information between the open source components. The structural similarity calculation subunit is used to calculate the structural similarity between the open source components based on the feature information of each open source component and using the similarity calculation model to obtain the structural similarity information between the open source components. The semantic similarity calculation subunit is used to calculate the semantic similarity between the open source components based on the feature information of each open source component and using the similarity calculation model to obtain the semantic similarity information between the open source components. The multidimensional similarity calculation subunit is used to perform weighted comprehensive calculation based on the text similarity information, the structural similarity information and the semantic similarity information to obtain the comprehensive similarity information between the open source components.
12. The system as described in claim 7, characterized in that, The code comparison module includes: The sorting submodule is used to sort all the open-source components according to the comprehensive similarity information between the open-source components, and obtain a sorted list of open-source component pairs; the list of open-source component pairs stores different open-source component pairs; The difference analysis submodule is used to compare the code of different open source component pairs using the difference measurement method to obtain the difference information between the different open source component pairs.
13. An electronic device, characterized in that, include: At least one processor and memory; The memory and processor are connected via a bus; The memory is used to store one or more programs; When the one or more programs are executed by the at least one processor, a code comparison method for open-source components as described in any one of claims 1 to 6 is implemented.
14. A computing device readable storage medium, characterized in that, It contains an executable program, which, when executed, implements a code comparison method for open-source components as described in any one of claims 1 to 6.