A semantic perception-based software architecture evolution intention classification method
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-03
- Publication Date
- 2026-07-03
Smart Images
Figure CN122331941A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software evolution monitoring and architecture measurement technology, specifically to a semantically aware method for classifying software architecture evolution intentions. Background Technology
[0002] As software systems continuously iterate, their architecture undergoes constant adjustments during version evolution. To support version governance, quality assessment, and maintenance decisions, it is typically necessary to identify, summarize, and interpret code changes between different versions to determine whether these changes affect system functionality, component organization, or the overall evolutionary direction. Therefore, how to continuously monitor and quantify architectural changes during version evolution has become a crucial research area in software engineering.
[0003] Existing solutions mostly identify changes based on textual, syntactic, or static structural differences. While these can reflect surface-level code modifications, they often lack effective mechanisms to distinguish between renaming, relocation, and refactoring that maintain behavior, as well as modifications that truly alter functional semantics. Due to the lack of measurement tools that can simultaneously combine structural and semantic change information, existing methods struggle to classify evolutionary activities in accordance with engineering semantics, thus failing to provide stable and quantifiable data for architecture governance.
[0004] Therefore, existing technologies have shortcomings and need to be improved and developed. Summary of the Invention
[0005] The present invention provides a semantically aware software architecture evolution intent classification method to address the problem that existing methods are unable to make classification judgments on evolution activities that conform to engineering semantics due to the lack of measurement means that can simultaneously combine structural change information and semantic change information, thus making it difficult to provide a stable and quantifiable basis for architecture governance.
[0006] This invention provides a semantically aware method for classifying software architecture evolution intent, comprising:
[0007] Retrieve historical and current version codes of the software system;
[0008] Based on the historical version code and the current version code, a multi-level architecture tree containing project layer, component layer, class layer and method layer is constructed. Cross-version structure alignment is performed according to node structure hash, the changed architecture components are identified, and the corresponding code block update pair set is generated.
[0009] Semantic features are extracted from the historical version code blocks and the current version code blocks in the update pair set to obtain corresponding semantic vector pairs;
[0010] The semantic displacement intensity of the corresponding update pair is calculated based on the Euclidean distance of each semantic vector pair in the normalized space.
[0011] Based on the semantic displacement strength of each update pair within the target architecture component and the structural change strength of the target architecture component, a dual-index matrix is constructed. The evolution intention of the target architecture component is divided into trivial maintenance, code refactoring, substantial evolution, or component replacement according to a preset classification threshold. The proportion of update method pairs with semantic displacement strength not lower than the semantic change threshold within the target architecture component is defined as follows:
[0012] Furthermore, the construction of a multi-level architecture tree based on the historical and current version code, comprising project, component, class, and method layers, performs cross-version structure alignment based on node structure hashes, identifies changed architecture components, and generates a corresponding set of code block update pairs, including:
[0013] Abstract the software architecture into a tree-like topology consisting of projects, components, classes, and methods;
[0014] For each node Generate stable identifiers The stability identifier At least include nodes The syntax signature, control flow digest features, data flow digest features, and child node structure distribution vector are combined; where the syntax signature... Represented in a standardized string format, including node name, parameter list, and return type; control flow summary features. Used to represent path features extracted from the control flow graph; data flow summary features. Represented as Set of binary pairs The node that represents the definition of the variable. Represents nodes using variables; child node structure distribution vector Count the number of child nodes of different types and form a vector;
[0015] The above features are sorted, deduplicated, and standardized to ensure consistent representation across versions;
[0016] Assemble according to the preset order: ,in, Indicates string concatenation;
[0017] Based on the stability identifier Based on the node structure hash, establish a candidate matching relationship between historical version nodes and current version nodes.
[0018] Furthermore, the node structure hash is defined as follows: ,in, Indicates the node type; Represents a node The Number of child nodes; Represents the set of child node hashes; This represents a string obtained by sorting and concatenating the hash sets of child nodes according to a preset order rule. This represents a hash function used to map an input to a fixed-length output, including but not limited to SHA-1, SHA-256, and MurmurHash.
[0019] Furthermore, the method based on the stability identifier Based on the node structure hash, establish candidate matching relationships between historical version nodes and current version nodes, including:
[0020] When historical version nodes With the current version node satisfy At that time, establish a one-to-one update pair ;
[0021] when And satisfy or When it is determined to be a structural relocation or nested adjustment, a relocation-nested update pair is established;
[0022] when and When this occurs, it is determined to be a node position migration, and a cross-parent node update pair is established;
[0023] When historical version nodes exist With at least two current version nodes satisfy When a node split is detected, a one-to-many update pair is generated. ;
[0024] When multiple old version nodes exist With new version nodes satisfy When a node merge is detected, a many-to-one update pair is generated. ;
[0025] when and When this occurs, it is determined to be a node renaming, and a rename-update pair is established;
[0026] When a node fails to match, the unmatched node in the current version is considered a newly added node, and the unmatched node in the historical version is considered a deleted node.
[0027] When a node satisfies several of the above rules, it is executed in the following priority order: establish a one-to-one update pair, establish a rename update pair, establish a move nested update pair, establish a cross-parent node update pair, generate a one-to-many update pair or generate a many-to-one update pair, determine whether it is a new node or a deleted node; once a node completes the matching, it is removed.
[0028] in, Represents the set of hashes of a node's child nodes; Indicates the hierarchical path of the node; This represents the structure hash after removing the name field; This represents a union-coverage matching relationship. The coverage ratio is equal to the number of elements in the intersection divided by the number of elements in the target set. When the coverage ratio is greater than a coverage threshold... At that time, it is assumed that the set is covered. The value range is [0.8, 1].
[0029] Furthermore, the step of extracting semantic features from the historical version code blocks and the current version code blocks in the update pair set to obtain corresponding semantic vector pairs includes:
[0030] A pre-trained code representation model with data flow awareness is used as the encoder;
[0031] The code block to be analyzed is parsed into a data flow graph consisting of variable definition relationships and variable reference relationships;
[0032] The code sequence and the data flow graph are input together into the pre-trained code representation model;
[0033] By fusing code structure and semantic information using a self-attention mechanism, and performing vector aggregation on the last hidden state of the model, semantic vectors for historical versions are generated. and the current version semantic vector .
[0034] Furthermore, the semantic displacement intensity The calculation formula is: ,in, It represents the semantic shift intensity, used to quantify the degree of logical shift of a code block before and after evolution; Represents the semantic vector dimension; Represents the semantic vector of the current version The Each component value; Represents the semantic vector of historical versions The Each component value; Represents the semantic vector of the current version The second norm; Represents the semantic vector of historical versions The second norm; and These represent the component values after normalization of the semantic vectors before and after evolution, respectively, to eliminate the impact of changes in code block size on the vector magnitude.
[0035] Furthermore, the current version semantic vector The L2 norm and the historical version semantic vector The 2-norm of each of them satisfies: , .
[0036] Furthermore, based on the semantic displacement intensity of each update pair within the target architecture component and the structural change intensity of the target architecture component, a dual-index matrix is constructed. The evolutionary intent of the target architecture component is then categorized into trivial maintenance, code refactoring, substantive evolution, or component replacement according to a preset classification threshold. The proportion of update method pairs with semantic displacement intensity not lower than the semantic change threshold within the target architecture component out of the total number of update method pairs includes:
[0037] For target architecture components All update methods within the corresponding semantic displacement strength The average is taken to obtain the target architecture component. average semantic displacement intensity ;
[0038] Take the average semantic displacement strength of all target architecture components The median is used as the semantic displacement intensity threshold. ;
[0039] Take the structural change intensity of all target architecture components The median is used as the threshold for structural change intensity. ;
[0040] Based on average semantic displacement intensity Structural change strength Semantic displacement intensity threshold Structural change intensity threshold The evolutionary intent of the target architecture components can be categorized into trivial maintenance, code refactoring, substantive evolution, or component replacement.
[0041] Furthermore, the structural change strength The calculation formula is: ,in, Indicates the target architecture component; Indicates target architecture components The structural change strength is denoted by [0,1]; Indicates target architecture components The set of all update method pairs in the set; Represents the set Any update method pair in; This indicates the update method for... The calculated semantic displacement intensity; Represents the 75th quantile of the set of semantic displacement intensities for all update method pairs; Indicates target architecture components The total number of update method pairs.
[0042] Furthermore, the statement based on average semantic displacement intensity Structural change strength Semantic displacement intensity threshold Structural change intensity threshold The evolutionary intent of the target architecture components is divided into trivial maintenance, code refactoring, substantial evolution, or component replacement, including:
[0043] when and When the target architecture component is identified as trivial maintenance, trivial maintenance is defined as code modification behavior that does not change the semantics of system function and has a small structural change, including at least comment adjustment and format modification.
[0044] when and When the target architecture component is identified as a code refactoring, code refactoring is defined as the behavior of adjusting the code structure without changing the external behavior of the system.
[0045] when When the target architecture component is determined to be substantially evolved, the definition of substantial evolution is the evolutionary behavior of introducing new functions or changing the original functional logic.
[0046] when When the target architecture component is identified as a component replacement, the definition of component replacement is the act of replacing a component in the system as a whole or refactoring a major function.
[0047] in, This represents the 90th percentile of the set of semantic displacement strengths in historical versions.
[0048] Beneficial effects:
[0049] As can be seen from the above technical solutions, the present invention provides a semantically aware software architecture evolution intent classification method, which has the following beneficial effects:
[0050] 1. Improves the accuracy of cross-version node matching: By using a multi-level architecture tree representation of the project layer, component layer, class layer, and method layer, and combining stable identifiers with structural hashes for alignment, it can more stably identify corresponding nodes between versions and reduce mismatches caused by comparing only by name or text.
[0051] 2. Reduces false alarms for behavior-preserving modifications: By introducing semantic vectors and semantic displacement strength calculations after structural alignment, renaming, formatting adjustments, annotation modifications, and partial structural reconstructions can be distinguished from genuine functional semantic changes, thereby reducing noise interference.
[0052] 3. It can quantify the depth of code logic changes: By constructing a semantic displacement intensity index through normalized semantic vector distance, the degree of logical change that is originally difficult to express intuitively can be transformed into a comparable and sortable numerical quantity, which is beneficial for subsequent classification and statistics.
[0053] 4. It can elevate discrete updates to component-level evolution judgment: By calculating the average semantic displacement intensity and structural change intensity, and performing classification at the component level, the results can be elevated from the local perspective of a single code block to the perspective of software architecture governance, which is more suitable for version analysis in engineering practice.
[0054] 5. Capable of outputting interpretable evolutionary intent results: By dividing evolutionary activities into four categories—trivial maintenance, code refactoring, substantive evolution, and component replacement—the analysis results can have clear engineering implications, facilitating the formation of maintenance strategies, governance reports, and risk identification conclusions.
[0055] 6. It has a scalable data processing and decision-making framework: The overall framework, from structural alignment and semantic encoding to threshold classification, has strong modularity, which makes it easy to extend its application in different programming languages, different project sizes and different measurement scenarios.
[0056] It should be understood that all combinations of the foregoing concepts and the additional concepts described in more detail below can be considered part of the inventive subject matter of this disclosure, provided that such concepts do not contradict each other.
[0057] The foregoing and other aspects, embodiments, and features of the teachings of the present invention will be more fully understood from the following description in conjunction with the accompanying drawings. Other additional aspects of the invention, such as features and / or beneficial effects of exemplary embodiments, will become apparent from the following description or may be learned through practice of specific embodiments according to the teachings of the present invention. Attached Figure Description
[0058] The accompanying drawings are not drawn to scale. In the drawings, each identical or nearly identical component shown in the various figures may be denoted by the same reference numeral. For clarity, not every component is labeled in each figure. Embodiments of various aspects of the invention will now be described by way of example and with reference to the accompanying drawings, wherein:
[0059] Figure 1 This is a flowchart illustrating a semantically aware software architecture evolution intent classification method in an embodiment of this application.
[0060] Figure 2 This is a flowchart of step S104 of a semantically aware software architecture evolution intent classification method in an embodiment of this application.
[0061] Figure 3 This is a flowchart of step S106 of a semantically aware software architecture evolution intent classification method in an embodiment of this application.
[0062] Figure 4 This is a flowchart of step S110 of a semantically aware software architecture evolution intent classification method in an embodiment of this application.
[0063] Figure 5 This is a table showing the experimental results of a semantically aware software architecture evolution intent classification method in the embodiments of this application.
[0064] Figure 6 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation
[0065] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention without creative effort are within the scope of protection of the present invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art to which this invention pertains.
[0066] The terms "first," "second," and similar words used in the specification and claims of this patent application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, unless the context clearly indicates otherwise, the singular forms of "an," "a," or "the," etc., do not indicate a quantity limitation, but rather indicate the presence of at least one. Terms such as "comprising" or "including" mean that the element or object preceding "comprising" encompasses the features, integrals, steps, operations, elements, and / or components listed following "comprising" or "including," and do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; these relative positional relationships may change accordingly when the absolute position of the described object changes.
[0067] As the core blueprint of a software system, the continuous monitoring of its evolution is crucial for ensuring system quality and guiding version iterations. Throughout the software lifecycle, the architecture evolves in response to changing business requirements. Accurately identifying and quantifying the intensity of this architectural evolution helps architects assess system stability and pinpoint truly impactful logical changes.
[0068] However, existing methods for classifying the intent of software architecture evolution have the following shortcomings in practical applications:
[0069] (1) Over-reliance on syntax differences leads to a high false positive rate. Most existing change detection methods are based on syntax or text differences in the code, ignoring the deep semantic logic behind the code. This results in a large number of behavior-preserving refactoring operations being misjudged as significant architectural evolution, generating a lot of noise and making it difficult for architects to identify the real implementation evolution from complex syntax changes.
[0070] (2) It is difficult to accurately distinguish between evolution patterns and intentions. Existing measurement methods often treat all code updates as changes with equal weight, lacking in-depth analysis of evolution motivations. In actual development, maintenance-oriented refactoring and functional evolution have drastically different impacts on system quality and architectural stability. Currently, there is a lack of an effective method that can combine structural change dimensions and semantic logic dimensions and automatically classify and identify component evolution intentions.
[0071] (3) Lack of effective metrics for quantifying the depth of logical changes. Traditional measurement methods are difficult to accurately characterize the degree of code displacement at the logical level. Due to the lack of means to use advanced pre-trained code representation models to capture high-dimensional semantic features, it is impossible to quantify the depth of code logical changes. As a result, the existing evolution intention results often deviate significantly from the subjective judgment of human experts, making it difficult to support high-precision architecture monitoring tasks.
[0072] Therefore, embodiments of the present invention provide a semantically aware software architecture evolution intent classification method, referring to... Figure 1 To address the technical problem that existing architecture evolution detection methods primarily rely on syntactic differences, leading to an inability to distinguish between code refactoring and substantive functional evolution and generating significant false positives, this paper first constructs a multi-level architecture tree and performs structural alignment to locate cross-version change nodes and form a set of code block update pairs. Then, a pre-trained code representation model is used to extract deep semantic features from the code blocks in the update pairs and map them into high-dimensional semantic vectors. The depth of code logic changes is quantified by calculating the Euclidean distance between the semantic vectors before and after the update in a normalized space. Finally, a dual-index matrix combining the intensity of structural changes and the intensity of semantic shifts is constructed to automatically classify and identify the intent of software architecture evolution. This includes:
[0073] Step S102: Obtain the historical version code and the current version code of the software system.
[0074] Step S104: Construct a multi-level architecture tree containing project layer, component layer, class layer and method layer based on historical version code and current version code, perform cross-version structure alignment according to node structure hash, identify the changed architecture components, and generate the corresponding code block update pair set.
[0075] In the subsequent classification stage, code block update pairs are preferred to be method-level update pairs, and class-level and component-level results are obtained by aggregating their subordinate method-level update pairs.
[0076] Step S106: Extract semantic features from the historical version code blocks and the current version code blocks in the update pair set to obtain the corresponding semantic vector pairs;
[0077] Step S108: Calculate the semantic displacement intensity of the corresponding update pair based on the Euclidean distance of each semantic vector pair in the normalized space.
[0078] Step S110: Based on the semantic displacement strength of each update pair within the target architecture component and the structural change strength of the target architecture component, construct a dual index matrix, and classify the evolution intention of the target architecture component into trivial maintenance, code refactoring, substantial evolution, or component replacement according to a preset classification threshold. Among them, the proportion of update method pairs with semantic displacement strength not lower than the semantic change threshold within the target architecture component to the total number of update method pairs.
[0079] By incorporating structural alignment results and semantic displacement quantization results into the component-level classification process, a closed loop is established for cross-version node identification, semantic change quantification, and intent classification output. This allows for the differentiation between local adjustments that maintain behavior and changes in functional logic, making the architecture evolution monitoring results closer to the true semantics of version evolution.
[0080] In some embodiments, a multi-level architecture tree, including project, component, class, and method layers, is constructed based on historical and current version code. Cross-version structure alignment is performed based on node structure hashes to identify changed architecture components and generate corresponding code block update pairs. Figure 2 ,include:
[0081] Step S1041: Abstract the software architecture into a tree-like topology consisting of projects, components, classes, and methods.
[0082] Step S1042: For each node Generate stable identifiers Stability indicator At least include nodes The syntax signature, control flow digest features, data flow digest features, and child node structure distribution vector are combined; where the syntax signature... Represented in a standardized string format, including node name, parameter list, and return type; control flow summary features. Used to represent path features extracted from the control flow graph; data flow summary features. Represented as Set of binary pairs The node that represents the definition of the variable. Represents nodes using variables; child node structure distribution vector Count the number of child nodes of different types and form a vector.
[0083] Step S1043: Sort, deduplicate, and standardize the above features to ensure consistent representation across versions.
[0084] Step S1044: Assemble the parts in a preset order: ,in, This indicates string concatenation.
[0085] Step S1045: Based on the stability indicator Based on the node structure hash, establish a candidate matching relationship between historical version nodes and current version nodes.
[0086] By refining the architecture tree construction and candidate matching relationship establishment, the software architecture is clearly abstracted into a tree structure composed of project layer, component layer, class layer, and method layer. A stable identifier is generated for each node, consisting of a syntax signature, control flow digest, data flow digest, and child node structure distribution vector. Nodes are described using multi-source structural features, rather than relying solely on name or a single signature, thereby improving the stability of cross-version matching. Even when nodes undergo name changes, partial relocation, or minor refactoring, high node correspondence is maintained, reducing erroneous deletions and additions.
[0087] In some embodiments, the node structure hash is defined as: ,in, Indicates the node type; Represents a node The Number of child nodes; Represents the set of child node hashes; This represents a string obtained by sorting and concatenating the hash sets of child nodes according to a preset order rule. This represents a hash function used to map an input to a fixed-length output, including but not limited to SHA-1, SHA-256, and MurmurHash.
[0088] By incorporating node type, syntax signature, child node hash set, and data stream digest into a unified hash calculation process, and using recursive structural hashing to uniformly encode node local information and hierarchical structure information, cross-version structural alignment has strong computability and repeatability. It can quickly complete node-level feature alignment in large-scale codebases, providing a stable foundation for subsequent update identification.
[0089] In some embodiments, based on stability identifiers Based on the node structure hash, establish candidate matching relationships between historical version nodes and current version nodes, including:
[0090] When historical version nodes With the current version node satisfy At that time, establish a one-to-one update pair .
[0091] when And satisfy or When the condition is determined to be a structural relocation or nested adjustment, a relocation / nested update pair is established.
[0092] when and When this occurs, it is determined to be a node position migration, and a cross-parent node update pair is established.
[0093] When historical version nodes exist With at least two current version nodes satisfy When a node split is detected, a one-to-many update pair is generated. .
[0094] When multiple old version nodes exist With new version nodes satisfy When a node merge is detected, a many-to-one update pair is generated. .
[0095] when and When this occurs, it is determined to be a node renaming, and a renaming update pair is established.
[0096] When a node fails to match, unmatched nodes in the current version are identified as newly added nodes, and unmatched nodes in historical versions are identified as deleted nodes.
[0097] When a node satisfies several of the above rules simultaneously, it is executed in the following priority order: establish a one-to-one update pair, establish a rename update pair, establish a move nested update pair, establish a cross-parent node update pair, generate a one-to-many update pair or generate a many-to-one update pair, determine whether it is a new node or a deleted node; once a node completes the matching, it is removed.
[0098] in, Represents the set of hashes of a node's child nodes; Indicates the hierarchical path of the node; This represents the structure hash after removing the name field; This represents a union-coverage matching relationship. The coverage ratio is equal to the number of elements in the intersection divided by the number of elements in the target set. When the coverage ratio is greater than a coverage threshold... At that time, it is assumed that the set is covered. The value range is [0.8, 1].
[0099] By clarifying the rules for determining candidate matching relationships and introducing priority rules, instead of judging all nodes that are not completely identical as changes, we establish differentiated matching rules for different architectural evolution forms. This can more accurately distinguish the types of structural adjustments in code evolution and reduce the probability of misjudgment caused by simple text comparison.
[0100] In some embodiments, semantic features are extracted from historical and current version code blocks in the update pair set to obtain corresponding semantic vector pairs, which are then referred to... Figure 3 include:
[0101] Step S1061: Use a pre-trained code representation model with data flow awareness as the encoder.
[0102] Step S1062: Parse the code block to be analyzed into a data flow graph consisting of variable definition relationships and variable reference relationships.
[0103] Step S1063: Input the code sequence and data flow graph together into the pre-trained code representation model.
[0104] Step S1064: Utilize a self-attention mechanism to fuse code structure information and code semantic information, and perform vector aggregation processing on the hidden states of the last layer of the model to generate semantic vectors for historical versions. and the current version semantic vector .
[0105] The semantic feature extraction process is defined by parsing code blocks into code sequences and data flow graphs, which are then input into a pre-trained code representation model to generate semantic vectors for historical and current versions. By incorporating code text information and data flow relationships into the encoding process, the vector representation reflects not only lexical information but also program logic relationships, making the semantic vectors better represent the code implementation logic and thus improving the effectiveness of subsequent semantic shift measurements.
[0106] In some embodiments, semantic displacement intensity The calculation formula is: ,in, It represents the semantic shift intensity, used to quantify the degree of logical shift of a code block before and after evolution; Represents the semantic vector dimension; Represents the semantic vector of the current version The Each component value; Represents the semantic vector of historical versions The Each component value; Represents the semantic vector of the current version The second norm; Represents the semantic vector of historical versions The second norm; and These represent the component values after normalization of the semantic vectors before and after evolution, respectively, to eliminate the impact of changes in code block size on the vector magnitude.
[0107] First, the semantic vectors before and after the evolution are normalized, and then the distance is calculated to reduce the influence of code size, name length or surface expansion on the module length, so that the measurement results are more biased towards changes in the logical direction, and can more stably quantify the depth of code logic offset, providing numerical basis for distinguishing between refactoring and functional evolution.
[0108] In some embodiments, the current version semantic vector The 2-norm and historical version semantic vectors The 2-norm of each of them satisfies: , .
[0109] In some embodiments, a dual-index matrix is constructed based on the semantic displacement strength of each update pair within the target architecture component and the structural change strength of the target architecture component. The evolutionary intent of the target architecture component is then categorized into trivial maintenance, code refactoring, substantial evolution, or component replacement according to a preset classification threshold. The proportion of update method pairs with semantic displacement strength not lower than the semantic change threshold within the target architecture component is defined as follows: Figure 4 ,include:
[0110] Step S1101: For the target architecture components All update methods within the corresponding semantic displacement strength Take the average to obtain the target architecture components. average semantic displacement intensity .
[0111] Step S1102: Obtain the average semantic displacement strength of all target architecture components. The median is used as the semantic displacement intensity threshold. .
[0112] Step S1103: Obtain the structural change intensity of all target architecture components The median is used as the threshold for structural change intensity. .
[0113] Step S1104: Based on the average semantic displacement intensity Structural change strength Semantic displacement intensity threshold Structural change intensity threshold The evolutionary intent of the target architecture components can be categorized into trivial maintenance, code refactoring, substantive evolution, or component replacement.
[0114] This approach elevates semantic displacement intensity from individual update pairs to the component level. By calculating the average semantic displacement intensity of update method pairs within a component and combining it with the median of the overall component distribution, a classification threshold is obtained. Semantic changes in individual updates are integrated into component-level statistics, which are then combined with structural change intensity to construct the basis for classification decisions. This allows discrete code changes to be viewed from a component governance perspective, facilitating the identification of architectural evolution units requiring focused attention.
[0115] In some embodiments, structural change strength The calculation formula is: ,in, Indicates the target architecture component; Indicates target architecture components The structural change strength is denoted by [0,1]; Indicates target architecture components The set of all update method pairs in the set; Represents a set Any update method pair in; This indicates the update method for... The calculated semantic displacement intensity; Represents the 75th quantile of the set of semantic displacement intensities for all update method pairs; Indicates target architecture components The total number of update method pairs.
[0116] The structural change intensity is defined by a formula, which essentially reflects the proportion of high semantic displacement updates within the target component. The structural change intensity is not simply represented by the number of modifications, but rather by introducing a semantic threshold to filter updates that truly exhibit logical change tendencies from all updates. This avoids treating a large number of low-value changes as equivalent to truly important ones, making the classification process more consistent with engineering practice.
[0117] In some embodiments, based on the average semantic displacement intensity Structural change strength Semantic displacement intensity threshold Structural change intensity threshold The evolutionary intent of the target architecture components can be categorized into trivial maintenance, code refactoring, substantial evolution, or component replacement, including:
[0118] when and When the target architecture component is identified as trivial maintenance, trivial maintenance is defined as code modification behavior that does not change the semantics of system function and has a small structural change, including at least comment adjustment and format modification.
[0119] when and When a target architecture component is identified as a code refactoring component, code refactoring is defined as the behavior of adjusting the code structure without changing the external behavior of the system.
[0120] when When the target architecture component is determined to be undergoing substantial evolution, the definition of substantial evolution is the evolutionary behavior of introducing new functions or changing the original functional logic.
[0121] when When the target architecture component is identified as a component replacement, the definition of component replacement is the act of replacing a component in the system as a whole or refactoring a major function.
[0122] in, This represents the 90th percentile of the set of semantic displacement strengths in historical versions.
[0123] By directly mapping quantitative indicators to interpretable engineering semantic labels, the model output no longer remains at the level of distance values or scores, but is transformed into classification conclusions that can be used for maintenance decisions. This makes it easier for project managers, architects, and maintenance personnel to classify and differentiate the handling of different types of version evolution activities.
[0124] The following is a specific implementation of a semantically aware software architecture evolution intent classification method:
[0125] Six large-scale open-source distributed systems with industrial-grade impact were selected as test cases, covering multiple areas such as message middleware, stream computing, distributed storage, resource scheduling, and parallel computing. Specific projects include Kafka, Flink, Hadoop-Common, Hadoop-HDFS, Hadoop-MapReduce, and Hadoop-YARN. These systems not only have massive codebases exceeding millions of lines, but are also undergoing long-term maintenance and rapid evolution, encompassing extensive refactoring activities and substantial functional advancements. This provides a solid data foundation for verifying the effectiveness of the methods in this invention's embodiments within complex software ecosystems.
[0126] The experiment uses a comparative analysis method to quantitatively compare the semantic representation framework provided by this invention with existing syntactic benchmark methods.
[0127] The data acquisition process is as follows: First, source code analysis is performed on two consecutive versions of the above six projects, and all method-level update pairs are located using the multi-level architecture tree proposed in this invention. Second, the total number of methods that still have source code differences after cleanup (removing spaces, line breaks, and comments) is counted and denoted as the baseline N. Then, a semantically aware software architecture evolution intent classification method proposed in this invention is used to extract method-level update pairs classified into substantial evolution and component replacement, denoted as S, and their proportion relative to the baseline N is calculated.
[0128] Through empirical analysis of six large-scale projects, the method of this invention demonstrates extremely high consistency in identifying and filtering code modifications unrelated to functional logic. This method can reliably separate refactoring operations that do not alter system behavior from massive code changes, proving its reliable signal filtering capability across different software ecosystems. Specific experimental results are as follows: Figure 5 As shown, the following conclusions are drawn:
[0129] (1) This invention can efficiently identify and filter code updates unrelated to functional logic, significantly reducing the number of change signals requiring manual intervention in architecture analysis. Experimental results show that in all tested large-scale systems, this invention filters out more than 90% of code modifications unrelated to functional logic. This technical effect allows architecture analysts to avoid reviewing more than 90% of code modifications that do not affect the architectural intent, such as variable renaming, code formatting adjustments, and API adaptations, thereby focusing their limited professional energy on the less than 10% of substantive logical evolution, solving the problem of manual review overload in the evolution analysis of large-scale systems.
[0130] (2) The method of the present invention has cross-project adaptability and versatility. The experiment covered six business areas and distributed systems with different architecture designs. The average classification accuracy of the method of the present invention reached 91.7% in all projects, and the filtering ratio was stable. This proves that the method of the present invention can effectively shield the interference of different developers' programming habits and implementation paradigms, and truly reflect the essential logical differences in code evolution. It has wide applicability in complex software industrial scenarios.
[0131] Another embodiment of the present invention also provides a semantically aware software architecture evolution intent classification device, comprising:
[0132] The data acquisition module is used to obtain the historical and current version code of the software system.
[0133] The identification module is used to construct a multi-level architecture tree containing project, component, class, and method layers based on historical and current version code. It performs cross-version structure alignment based on node structure hash, identifies changed architecture components, and generates a corresponding set of updated code blocks.
[0134] The extraction module is used to extract semantic features from historical version code blocks and current version code blocks in the update pair set to obtain corresponding semantic vector pairs.
[0135] The computation module is used to calculate the semantic displacement intensity of the corresponding update pair based on the Euclidean distance of each semantic vector pair in the normalized space.
[0136] A module is created to construct a dual-index matrix based on the semantic displacement strength of each update pair within the target architecture component and the structural change strength of the target architecture component. The evolution intention of the target architecture component is divided into trivial maintenance, code refactoring, substantial evolution, or component replacement according to a preset classification threshold. The proportion of update method pairs with semantic displacement strength not lower than the semantic change threshold within the target architecture component is defined as the proportion of the total number of update method pairs.
[0137] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.
[0138] Based on the same inventive concept as the above method embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it enables the electronic device to implement the control method described in the above embodiments.
[0139] In one embodiment, the electronic device may be a server, and in this embodiment, the structure of the electronic device may be as follows: Figure 6 As shown, it includes a memory, a communication module, and one or more processors.
[0140] Memory is used to store computer programs executed by the processor. Memory can be mainly divided into a program storage area and a data storage area. The program storage area can store the operating system and programs required to run instant messaging functions, etc.; the data storage area can store various instant messaging information and operation instruction sets, etc.
[0141] Memory can be volatile memory, such as random access memory (RAM); memory can also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory can be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory can be a combination of the above-mentioned types of memory.
[0142] A processor may include one or more central processing units (CPUs) or digital processing units, etc. The processor is used to implement the aforementioned audio data processing methods when it invokes computer programs stored in memory.
[0143] The communication module is used to communicate with terminal devices and other servers.
[0144] This application embodiment does not limit the specific connection medium between the above-described memory, communication module, and processor. This application embodiment... Figure 6 The memory and processor are connected via a bus, and the bus is in... Figure 6 The connections between other components are illustrated with arrows and are for illustrative purposes only, not as limiting information. Buses can be categorized as address buses, data buses, control buses, etc. For ease of description, Figure 6 The text uses only one arrow to describe it, but does not indicate that there is only one bus or one type of bus.
[0145] Based on the same inventive concept as the above-described method embodiments, embodiments of the present invention also provide a computer-readable storage medium for storing a computer program. When the computer program is run on a computer, it enables an electronic device to implement the control methods described in the above embodiments. The computer-readable storage medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.
[0146] Based on the same inventive concept as the above-described method embodiments, embodiments of the present invention also provide a computer program product. The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of the control methods described above according to various exemplary embodiments of this application. The program product may take the form of any combination of one or more readable media. These computer program commands can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the commands executed by the processor of the computer or other programmable data processing device generate a process for implementing... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0147] While the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the invention. Those skilled in the art can make various modifications and refinements without departing from the spirit and scope of the invention. Therefore, the scope of protection of the present invention shall be determined by the claims.
Claims
1. A semantic-aware based software architecture evolution intention classification method, characterized in that, include: Retrieve historical and current version codes of the software system; Based on the historical version code and the current version code, a multi-level architecture tree containing project layer, component layer, class layer and method layer is constructed. Cross-version structure alignment is performed according to node structure hash, the changed architecture components are identified, and the corresponding code block update pair set is generated. Semantic features are extracted from the historical version code blocks and the current version code blocks in the update pair set to obtain corresponding semantic vector pairs; The semantic displacement intensity of the corresponding update pair is calculated based on the Euclidean distance of each semantic vector pair in the normalized space. Based on the semantic displacement strength of each update pair within the target architecture component and the structural change strength of the target architecture component, a dual-index matrix is constructed. The evolution intention of the target architecture component is divided into trivial maintenance, code refactoring, substantial evolution, or component replacement according to a preset classification threshold. The proportion of update method pairs with semantic displacement strength not lower than the semantic change threshold within the target architecture component is defined as follows:
2. The method of claim 1, wherein the software architecture evolution intention classification method based on semantic perception is characterized in that, The process involves constructing a multi-level architecture tree based on the historical and current code versions, comprising project, component, class, and method layers. Cross-version structure alignment is performed using node structure hashes to identify changed architecture components and generate corresponding code block update pairs, including: Abstract the software architecture into a tree-like topology consisting of projects, components, classes, and methods; For each node Generate stable identifiers The stability identifier At least include nodes The syntax signature, control flow digest features, data flow digest features, and child node structure distribution vector are combined; where the syntax signature... Represented in a standardized string format, including node name, parameter list, and return type; control flow summary features. Used to represent path features extracted from the control flow graph; data flow summary features. Represented as Set of binary pairs The node that represents the definition of the variable. Represents nodes using variables; child node structure distribution vector Count the number of child nodes of different types and form a vector; The above features are sorted, deduplicated, and standardized to ensure consistent representation across versions; concatenation in a predetermined order: wherein, represents string concatenation; Based on the stability identifier Based on the node structure hash, establish a candidate matching relationship between historical version nodes and current version nodes.
3. The semantically aware software architecture evolution intent classification method according to claim 2, characterized in that, The node structure hash is defined as follows: ,in, Indicates the node type; Represents a node The Number of child nodes; Represents the set of child node hashes; This represents a string obtained by sorting and concatenating the hash sets of child nodes according to a preset order rule. This represents a hash function used to map an input to a fixed-length output, including but not limited to SHA-1, SHA-256, and MurmurHash.
4. The semantically aware software architecture evolution intent classification method according to claim 3, characterized in that, The stable identifier is determined according to the stable identifier of the current version node And the node structure hash, the candidate matching relationship between the historical version node and the current version node is established, including: When the historical version node meets the current version node , a one-to-one update pair is established. when And satisfy or When it is determined to be a structural relocation or nested adjustment, a relocation-nested update pair is established; When and the node position migration is determined, and a cross-parent node update pair is established. When there is a historical version node with at least two current version nodes satisfied , the node split is determined, and a one-to-many update pair is generated ; When multiple old version nodes exist With new version nodes satisfy When a node merge is detected, a many-to-one update pair is generated. ; When and the node rename is determined and a rename update pair is established. When a node fails to match, the unmatched node in the current version is considered a newly added node, and the unmatched node in the historical version is considered a deleted node. When a node satisfies several of the above rules, it is executed in the following priority order: establish a one-to-one update pair, establish a rename update pair, establish a move nested update pair, establish a cross-parent node update pair, generate a one-to-many update pair or generate a many-to-one update pair, determine whether it is a new node or a deleted node; once a node completes the matching, it is removed. in, Represents the set of hashes of a node's child nodes; Indicates the hierarchical path of the node; This represents the structure hash after removing the name field; This represents a union-coverage matching relationship. The coverage ratio is equal to the number of elements in the intersection divided by the number of elements in the target set. When the coverage ratio is greater than a coverage threshold... At that time, it is assumed that the set is covered. The value range is [0.8, 1].
5. The method of claim 1, wherein the software architecture evolution intention classification method based on semantic perception is characterized in that, The step of extracting semantic features from historical and current version code blocks in the update pair set to obtain corresponding semantic vector pairs includes: A pre-trained code representation model with data flow awareness is used as the encoder; The code block to be analyzed is parsed into a data flow graph consisting of variable definition relationships and variable reference relationships; The code sequence and the data flow graph are input together into the pre-trained code representation model; The code structure information and the code semantic information are fused by using a self-attention mechanism, and vector aggregation processing is performed on the last layer hidden state of the model to generate a historical version semantic vector and a current version semantic vector .
6. The semantically aware software architecture evolution intent classification method according to claim 5, characterized in that, The semantic displacement intensity The calculation formula is: ,in, It represents the semantic shift intensity, used to quantify the degree of logical shift of a code block before and after evolution; Represents the semantic vector dimension; Represents the semantic vector of the current version The Each component value; Represents the semantic vector of historical versions The Each component value; Represents the semantic vector of the current version The second norm; Represents the semantic vector of historical versions The second norm; and These represent the component values after normalization of the semantic vectors before and after evolution, respectively, to eliminate the impact of changes in code block size on the vector magnitude.
7. The semantically aware software architecture evolution intent classification method according to claim 6, characterized in that, The current version semantic vector The L2 norm and the historical version semantic vector The 2-norm of each of them satisfies: , .
8. The semantically aware software architecture evolution intent classification method according to claim 1, characterized in that, The method constructs a dual-index matrix based on the semantic displacement intensity of each update pair within the target architecture component and the structural change intensity of the target architecture component. Then, according to a preset classification threshold, the evolutionary intent of the target architecture component is categorized into trivial maintenance, code refactoring, substantial evolution, or component replacement. The proportion of update method pairs with semantic displacement intensity not lower than the semantic change threshold within the target architecture component out of the total number of update method pairs includes: For target architecture components All update methods within the corresponding semantic displacement strength The average is taken to obtain the target architecture component. average semantic displacement intensity ; Take the average semantic displacement strength of all target architecture components The median is used as the semantic displacement intensity threshold. ; Take the structural change intensity of all target architecture components The median is used as the threshold for structural change intensity. ; Based on average semantic displacement intensity Structural change strength Semantic displacement intensity threshold Structural change intensity threshold The evolutionary intent of the target architecture components can be categorized into trivial maintenance, code refactoring, substantive evolution, or component replacement.
9. The semantically aware software architecture evolution intent classification method according to claim 8, characterized in that, The structural change intensity The calculation formula is: ,in, Indicates the target architecture component; Indicates target architecture components The structural change strength is denoted by [0,1]; Indicates target architecture components The set of all update method pairs in the set; Represents the set Any update method pair in; This indicates the update method for... The calculated semantic displacement intensity; Represents the 75th quantile of the set of semantic displacement intensities for all update method pairs; Indicates target architecture components The total number of update method pairs.
10. A method for classifying software architecture evolution intent based on semantic awareness according to claim 8, characterized in that, The average semantic displacement intensity Structural change strength Semantic displacement intensity threshold Structural change intensity threshold The evolutionary intent of the target architecture components is divided into trivial maintenance, code refactoring, substantial evolution, or component replacement, including: when and When the target architecture component is identified as trivial maintenance, trivial maintenance is defined as code modification behavior that does not change the semantics of system function and has a small structural change, including at least comment adjustment and format modification. when and When the target architecture component is identified as a code refactoring, code refactoring is defined as the behavior of adjusting the code structure without changing the external behavior of the system. when When the target architecture component is determined to be substantially evolved, the definition of substantial evolution is the evolutionary behavior of introducing new functions or changing the original functional logic. when When the target architecture component is identified as a component replacement, the definition of component replacement is the act of replacing a component in the system as a whole or refactoring a major function. in, This represents the 90th percentile of the set of semantic displacement strengths in historical versions.