Software architecture evaluation method based on dependency structure matrix

Abstract

The invention discloses a software architecture evaluation method based on a dependency structure matrix, and aims to comprehensively evaluate the quality of a software architecture, identify potential problems and provide an effective optimization strategy. The method comprises the steps of firstly constructing a dependency structure matrix; extracting multi-scale features based on the constructed dependent structure matrix DSM; standardization of software architecture evaluation indexes is carried out; a multi-level perceptron model MLP is used for fusing the standardized multi-scale features for training, and after training is completed, the trained multi-level perceptron model MLP is used for scoring or classifying the software architecture to be evaluated; and finally, based on an evaluation result of the multi-layer perceptron model, analyzing the contribution degree of each feature to a final score or classification result, and determining key factors influencing the quality of the software architecture. According to the method, a developer can be helped to improve the quality, maintainability and expandability of a software architecture, technical debts are reduced, long-term stability of a software system is ensured, and high adaptability and practical value are achieved.

Description

Technical Field

[0001] The present invention belongs to the field of software engineering and relates to a software architecture evaluation method based on a dependency structure matrix (Dependency Structure Matrix, DSM). Background Art

[0002] The concept of "software crisis" has appeared almost since the birth of computers, and it is still one of the main challenges facing the field of software development. Its core manifestations are that software performance often fails to keep up with the rapid development of hardware technology; there is a significant gap between the research progress of software development and the actual application needs; when faced with the development of large-scale software projects, developers are often unable to cope with it, resulting in project budget overruns and repeated delays in delivery time. In addition, from the perspective of software quality, with the expansion of the scale of software systems, especially the development of large-scale software, the difficulty of maintenance increases, and the portability and reusability of software become poor, further exacerbating this problem.

[0003] With the rapid development of the Internet and big data technologies, the scale and complexity of software systems are also increasing. In order to cope with these changes, the importance of software architecture has become increasingly prominent. Software architecture is the skeleton and basic structure of the system. It determines the performance, reliability, scalability and other aspects of the system, and directly affects the maintainability and long-term stability of the system. Therefore, how to evaluate the software architecture, especially in complex systems, and evaluate whether the architecture has technical debt and potential problems, has become a key task in the software development and maintenance process.

[0004] At present, many software measurement methods based on programs and source code have emerged, and these methods have been successfully applied to software development, optimization and maintenance. However, the research on system measurement from the perspective of software architecture is still in the exploratory stage. Existing architecture measurement methods often fail to fully cover the quality attributes of the system, especially when dealing with large-scale and complex systems. Related research and application are still insufficient. Therefore, how to design a method that can comprehensively evaluate the quality of software architecture, locate potential problems and provide effective optimization strategies has become a challenge that needs to be solved urgently.

[0005] Ensuring the quality, maintainability and security of software systems is one of the most critical tasks in the field of modern software development. In current software development, in order to meet the growing needs of users, improve development efficiency and ensure the long-term stability of software systems, software testing and evaluation have become an indispensable part of the project development process. Traditional testing methods usually focus on functional testing and performance testing, but when faced with complex software architectures, simple testing methods often fail to identify potential risks at the architectural level, especially when the architectural design is unreasonable, which may cause long-term maintenance problems and technical debt.

[0006] Due to the complexity and large scale of system software, it is often difficult to comprehensively manage and optimize software architecture without the help of specialized architecture analysis tools. The rationality of architecture design is directly related to the efficiency and quality of software development. Chaotic and unreasonable architecture not only affects the performance of the system, but also increases the difficulty of development, maintenance and expansion, and may even lead to project failure. Therefore, it is particularly important to conduct a comprehensive and systematic evaluation of software architecture. Summary of the invention

[0007] In response to the above-mentioned problems, the present invention provides a software architecture evaluation method based on a dependency structure matrix. The method comprehensively evaluates the quality of the software architecture by analyzing the modules in the software system and the dependencies between them, and provides location of potential problems and optimization suggestions through a machine learning algorithm.

[0008] The above purpose is achieved through the following technical solutions:

[0009] A software architecture evaluation method based on a dependency structure matrix is ​​implemented in the following steps:

[0010] Step 1: Construct a dependency structure matrix: obtain the source code of the software to be evaluated, parse the source code to identify the modules, classes and methods in the software system; extract the dependency relationships between the software entities based on the parsing results, including but not limited to the dependencies between modules, the calling relationships between classes, and the calling relationships between methods; construct a dependency structure matrix DSM based on the above dependencies, where each row and column in the DSM represents a module in the software, and the value of the element in the DSM represents the dependency strength between the modules;

[0011] Step 2: Multi-dimensional feature calculation based on DSM: Extract multi-scale features based on the constructed dependency structure matrix DSM. The multi-scale features cover features in four dimensions: basic features, architecture complexity, coupling cohesion, and system balance.

[0012] Step 3: Standardization of software architecture evaluation indicators: The multi-scale features extracted from the dependency structure matrix are standardized using the Z-score standardization method to eliminate the influence of different feature dimensions. The standardization process maps each feature value to a unified numerical range to ensure that each feature is evaluated at the same scale in the subsequent evaluation.

[0013] Step 4: Architecture evaluation based on multi-layer perceptron: Use the multi-layer perceptron model MLP to fuse the standardized multi-scale features in step 3 for training, learn the mapping relationship between each feature index and the architecture evaluation label, use the standardized evaluation features in step 3 as input, and perform nonlinear feature fusion and pattern learning through multiple hidden layers of the multi-layer perceptron model MLP to capture the complex relationship between features; use supervised learning methods to optimize model parameters through labeled architecture evaluation labels; after training, use the trained multi-layer perceptron model MLP to score or classify the software architecture to be evaluated;

[0014] Step 5: Analysis of architecture evaluation results and generation of optimization suggestions: Based on the evaluation results of the multi-layer perceptron model in step 4, analyze the contribution of each feature to the final score or classification result, and determine the key factors affecting the quality of the software architecture.

[0015] Furthermore, step 2 specifically includes the following steps:

[0016] Step 2.1. Calculate basic feature indicators: obtain the number of code lines L, header file count H, and total element number N by directly counting the source code, obtain the number of edges E by counting the sum of non-zero elements in the DSM, obtain the number of module dependency out-edges O by counting the sum of all non-zero elements in the row where the module is located in the DSM, and obtain the number of module dependency in-edges I by counting all non-zero elements in the column where the module is located in the DSM;

[0017] Step 2.2: Calculate the architecture complexity index: The architecture complexity index includes architecture complexity CA, path complexity CP, cyclomatic complexity CC, and system loop volume SL, where:

[0018] Complexity CA = V × E;

[0019] The path complexity CP is obtained by counting the number of independent paths in the control flow graph;

[0020] Cyclomatic complexity CC = E-N+2, where N represents the number of nodes, i.e. the total number of modules and components in the source code;

[0021] The system circulation volume SL is obtained by counting the number of cycles in the system;

[0022] Step 2.3: Calculate the coupling cohesion index: The coupling cohesion index includes cohesion CH, coupling strength CS, coupling enrichment CE, and connectivity enrichment CNE. i For example, where:

[0023] Cohesion N(Mo i ) indicates module Mo i The number of methods and classes contained, is the total number of classes and methods in the module, μ(A j ) indicates that the module is related to method or class A j The total number of methods or classes with dependencies;

[0024] Coupling strength N(Mo i ) indicates module Mo i The number of methods and classes contained, lsc(Mo i ,Mo j ) indicates that the module Mo is included i and module Mo j The length of the shortest loop between is the total number of classes and methods in the module;

[0025] Coupling enrichment CO(Mo i ) represents the module coupling degree, ECO(Mo i ) represents the expected coupling degree, module Mo i Coupling is the number of reachable paths between methods and classes in the module, is the total number of classes and methods in the module, and the expected coupling degree is the actual coupling degree calculated after disrupting and reconnecting the dependencies between the classes and methods in the module;

[0026] Connectivity Richness CONN(Mo i ) indicates the actual connectivity, ECONN(Mo i ) represents the expected connectivity. The actual connectivity calculation formula is is the number of edges in the module, is the total number of classes and methods in the module, and the expected connectivity is the actual connectivity calculated after disrupting and reconnecting the dependencies between the classes and methods in the module;

[0027] Step 2.4: Calculate system balance index: The system balance index includes path ratio PR, balance FB, and module importance IM, among which:

[0028] The path ratio PR is the ratio of the number of dependencies in the upper triangle of the dependency structure matrix to the total number of dependencies;

[0029] Module importance IM is the PageRank value of the module calculated by PageRank algorithm;

[0030] Balance KL(Mo i) indicates module Mo i The JS divergence value between the degree distribution of classes and methods in the dependency structure matrix and the average distribution, and N represents the total number of modules and components in the project.

[0031] Furthermore, step 3 specifically includes the following steps:

[0032] Step 3.1: Obtain various features extracted from the dependency structure matrix DSM in step 2, including basic features, architecture complexity features, coupling cohesion features, and system balance features; perform integrity check on feature data, remove outliers, missing values, or redundant data, and ensure data quality;

[0033] Step 3.2: According to the numerical range and distribution characteristics of different features, select the Z-score standardization method to map the feature values ​​to a unified numerical range to eliminate the dimensional influence of different features. The calculation formula of the Z-score standardization method is as follows:

[0034]

[0035] Among them, x is the original eigenvalue, μ is the mean value of the feature, σ is the standard deviation of the eigenvalue, and x′ is the standardized eigenvalue.

[0036] Furthermore, step 4 specifically includes the following steps:

[0037] Step 4.1: Model input preparation: Use the standardized multidimensional evaluation indicators in step 3 as input features to form an input vector X = [x1, x2, ..., x |X| ], where |X| is the number of features; each input feature x i Corresponds to a feature extracted from a certain dimension in the dependency structure matrix, such as basic features, architectural complexity, coupling cohesion, or system balance;

[0038] Step 4.2: Multilayer Perceptron Model Construction: Construct a multilayer perceptron MLP model with l hidden layers. The MLP model structure is as follows:

[0039] H (l) =sigmod(H (l-1) W (l) +b (l) )

[0040] Among them, sigmod(·) is the activation function, W (l) is the weight matrix between the l-1th layer and the lth layer of the multilayer perceptron, with a dimension of h (l-1) ×h (l) ,h (l) is the number of neurons in layer l, b (l) is the bias term of the lth layer, H(l) is the output of the lth layer, H (0) =X; after passing through the l-layer neural network, the evaluation prediction value of the software architecture is

[0041] Step 4.3: Model training: Calculate the loss function using mean square error Calculate predicted values With the actual label y i The difference between:

[0042]

[0043] in, is the predicted value of the i-th sample, y i is the actual label of the i-th sample, and d is the number of samples;

[0044] Using the training dataset, the model parameters are optimized through the back-propagation algorithm and stochastic gradient descent (SGD) to minimize the loss function.

[0045] Furthermore, the step 5 specifically includes the following steps:

[0046] Step 5.1: Model result analysis: Using the evaluation results of the multi-layer perceptron model in step 4, quantify the contribution of each feature, use SHAP values ​​to analyze the impact of each input feature on the final architecture score, and calculate the importance of each feature in the model output:

[0047]

[0048] Among them, φ i (f) represents the Shapley value of the feature, f(·) represents the output of the model trained on the feature set, |S| represents the size of the feature set, and |X| is the number of features;

[0049] Step 5.2: Identification of weak links in software architecture: Based on the calculated SHAP values ​​and corresponding characteristic indicators, identify the features that have the greatest impact on the quality of the architecture; at the same time, use the high dependency strength in the standardized DSM in step 3 to identify highly coupled modules and components; use the features of architectural complexity to identify modules and components with high complexity; use the system balance features to identify unbalanced modules and components in the system;

[0050] Step 5.3: Evaluation reference for similar software architectures: By comparing the architecture features, module coupling, complexity, and system balance indicators of the software architecture to be evaluated with the same category (open source) products in the evaluation database, the relative position of the software architecture to be evaluated among similar products is highlighted;

[0051] Step 5.4: Generate software architecture assessment report.

[0052] Beneficial effects: Compared with the prior art, the present invention adopts the above technical solution and has the following advantages:

[0053] The present invention adopts a multi-dimensional evaluation model to comprehensively evaluate the quality attributes of the software architecture from multiple perspectives, including performance, maintainability, security, scalability, etc. Through detailed analysis of the software architecture, the present invention can effectively identify potential problems in the architecture, especially problems such as excessive coupling, poor cohesion, and system imbalance, and put forward optimization suggestions, thereby helping developers improve the quality and maintainability of the software architecture, reduce technical debt, and ensure the long-term stable operation of the software system. The introduction of this method will provide a new theoretical basis and practical guidance for the design and optimization of software architecture, and has broad application prospects. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 It is a flow chart of the software architecture evaluation method based on the dependency structure matrix of the present invention.

[0055] Figure 2 is The dependency structure matrix (DSM) of the MYSQL embodiment tested in the present invention.

[0056] Figure 3 is A framework diagram of a software architecture evaluation method based on a dependency structure matrix of the present invention.

[0057] Figure 4 is The present invention tests the dependency structure matrix and basic information of the Storage module in the MYSQL embodiment.

[0058] Figure 5 is The distribution diagram of the number of lines of code for testing the MYSQL implementation example in the present invention.

[0059] Figure 6 is The header file count distribution diagram of each folder in the MYSQL embodiment tested in the present invention.

[0060] Figure 7 It is a relationship diagram between the number of lines of code and path complexity of the MYSQL embodiment tested in the present invention and similar projects.

[0061] Figure 8 It is a relationship diagram between the number of lines of code and complexity of the MYSQL embodiment tested in the present invention and similar projects. DETAILED DESCRIPTION

[0062] The technical solution of the present invention is described in detail below.

[0063] The following is only one embodiment of the present invention. The present invention may have other embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art may make various corresponding changes and modifications based on the present invention. These corresponding changes and modifications should all fall within the scope of protection of the claims attached to the present invention.

[0064] The present invention provides a software architecture evaluation method based on a dependency structure matrix, which aims to comprehensively evaluate the quality of the software architecture, locate potential problems, and provide effective optimization strategies. The method is implemented according to the following steps:

[0065] Step 1: Construct a dependency structure matrix. Obtain the source code of the software to be evaluated, parse the source code to identify the modules, classes, and methods in the software system; extract the dependency relationships between the software entities based on the parsing results, including but not limited to the dependencies between modules, the calling relationships between classes, and the calling relationships between methods; construct a dependency structure matrix (DSM) based on the above dependencies, where each row and column in the DSM represents a module in the software, and the value of the element in the DSM represents the dependency strength between modules.

[0066] Step 2: Multi-dimensional feature calculation based on DSM. Multi-scale features are extracted from the constructed dependency structure matrix (DSM), covering features in four dimensions: basic features, architectural complexity, coupling cohesion, and system balance. In the present invention, modules, components, etc. in the software source code are collectively referred to as atoms. In terms of basic features, the number of code lines, the number of interfaces, the number of atoms and the number of edges between atoms, the header file count, the source file count, the total number of atoms (including the element count of the entire hierarchy and each level), the number of dependent outgoing edges and the number of dependent incoming edges of each atom are calculated. In terms of architectural complexity, the depth (the number of modules passed by the longest dependency path) and breadth (the number of different modules involved in the dependency path) of the dependency path between modules are calculated, and factors such as the system loop volume (the number of loop structures existing in the system) and the loop volume between components (the number of loop structures formed between components) are calculated. In terms of coupling cohesion, we calculate the distribution of inter-module dependency strength, cohesion, coupling (measure the tightness of inter-module coupling), coupling richness (reflect the enrichment of coupling relationships in the system), coupling strength (considering the tightness of inter-module dependencies), internal dependencies (inter-module dependencies), connectivity (degree of connection between modules), connectivity richness (the richness of connections between modules in the system), and connectivity strength (strength of connections between modules). In terms of system balance, we calculate the distribution balance of dependency relationships (such as path proportion, i.e. the proportion of dependencies in the upper triangle of the DSM to total dependencies) and resource occupancy ratio (such as functional balance, measuring the distribution balance of functions in the system), many-to-many strength (the strength of complex relationships between multiple modules in the system), and module importance (measuring the criticality of modules in the system).

[0067] Step 3: Standardization of software architecture evaluation indicators. The various features extracted from the dependency structure matrix are standardized using the Z-score standardization method to eliminate the influence of different feature dimensions. The standardization process maps each feature value to a unified numerical range to ensure that each feature is evaluated at the same scale in the subsequent evaluation.

[0068] Step 4: Architecture evaluation based on multi-layer perceptron. Use the multi-layer perceptron model (MLP) to fuse the normalized multi-dimensional evaluation indicators in step 3 for training, and learn the mapping relationship between each feature indicator and the architecture evaluation label. The normalized evaluation features are used as input, and nonlinear feature fusion and pattern learning are performed through multiple hidden layers of the multi-layer perceptron to capture the complex relationship between features. Use supervised learning methods to optimize model parameters through labeled architecture evaluation labels. After training, use the trained model to score or classify the software architecture to be evaluated.

[0069] Step 5: Analysis of architecture evaluation results and generation of optimization suggestions. Based on the evaluation results of the multi-layer perceptron model in step 4, analyze the contribution of each feature to the final score or classification result, and determine the key factors affecting the quality of the software architecture. Through feature importance analysis, identify weak links in the architecture, such as highly coupled modules, components with excessive complexity, or system imbalance. Combined with the analysis results, generate targeted improvement suggestions, including optimization measures such as module split optimization, reducing coupling, and adjusting the hierarchy, to help developers improve the quality, maintainability, and scalability of the software architecture.

[0070] The process of step 2 in this embodiment specifically includes the following steps:

[0071] Step 2.1. Calculate basic feature indicators: obtain the number of code lines L, header file count H, and total element number N by directly counting the source code, obtain the number of edges E by counting the sum of non-zero elements in the DSM, obtain the number of module dependency out-edges O by counting the sum of all non-zero elements in the row where the module is located in the DSM, and obtain the number of module dependency in-edges I by counting all non-zero elements in the column where the module is located in the DSM;

[0072] Step 2.2: Calculate the architecture complexity index: The architecture complexity index includes architecture complexity CA, path complexity CP, cyclomatic complexity CC, and system loop volume SL, where:

[0073] Complexity CA = V × E;

[0074] The path complexity CP is obtained by counting the number of independent paths in the control flow graph;

[0075] Cyclomatic complexity CC = E-N+2, where N represents the number of nodes, i.e. the total number of modules and components in the source code;

[0076] The system circulation volume SL is obtained by counting the number of cycles in the system;

[0077] Step 2.3: Calculate the coupling cohesion index: The coupling cohesion index includes cohesion CH, coupling strength CS, coupling enrichment CE, and connectivity enrichment CNE. i For example, where:

[0078] Cohesion N(Mo i ) indicates module Mo i The number of methods and classes contained, is the total number of classes and methods in the module, μ(A j ) indicates that the module is related to method or class A j The total number of methods or classes with dependencies;

[0079] Coupling strength N(Mo i ) indicates module Mo i The number of methods and classes contained, lsc(Mo i ,Mo j ) indicates that the module Mo is included i and module Mo j The length of the shortest loop between is the total number of classes and methods in the module;

[0080] Coupling enrichment CO(MO i ) represents the module coupling degree, ECO(MO i ) represents the expected coupling degree, module MO i Coupling is the number of reachable paths between methods and classes in the module, is the total number of classes and methods in the module, and the expected coupling degree is the actual coupling degree calculated after disrupting and reconnecting the dependencies between the classes and methods in the module;

[0081] Connectivity Richness CONN(Mo i ) indicates the actual connectivity, ECONN(Mo i ) represents the expected connectivity. The actual connectivity calculation formula is is the number of edges in the module, is the total number of classes and methods in the module, and the expected connectivity is the actual connectivity calculated after disrupting and reconnecting the dependencies between the classes and methods in the module;

[0082] Step 2.4: Calculate system balance index: The system balance index includes path ratio PR, balance FB, and module importance IM, among which:

[0083] The path ratio PR is the ratio of the number of dependencies in the upper triangle of the dependency structure matrix to the total number of dependencies;

[0084] Module importance IM is the PageRank value of the module calculated by PageRank algorithm;

[0085] Balance KL(Mo i ) indicates module Mo i The JS divergence value between the degree distribution of classes and methods in the dependency structure matrix and the average distribution, and N represents the total number of modules and components in the project.

[0086] The process of step 3 in this embodiment specifically includes the following steps:

[0087] Step 3.1: Obtain various features extracted from the dependency structure matrix (DSM) in step 2, including basic features, architecture complexity features, coupling cohesion features, and system balance features; perform integrity check on feature data, remove outliers, missing values, or redundant data, and ensure data quality;

[0088] Step 3.2: According to the numerical range and distribution characteristics of different features, select the Z-score standardization method to map the feature values ​​to a unified numerical range to eliminate the dimensional effects of different features. The calculation formula of the Z-score standardization method is as follows:

[0089]

[0090] Among them, x is the original eigenvalue, μ is the mean value of the feature, σ is the standard deviation of the eigenvalue, and x′ is the standardized eigenvalue.

[0091] The process of step 4 in this embodiment specifically includes the following steps:

[0092] Step 4.1: Model input preparation. The standardized multi-dimensional evaluation index in step 3 is used as the input feature to form the input vector X = [x1, x2, ..., x |X| ], where |X| is the number of features. Each input feature x i Corresponds to a feature extracted from a certain dimension in the dependency structure matrix, such as basic characteristics, architectural complexity, coupling cohesion, or system balance.

[0093] Step 4.2: Multilayer Perceptron Model Construction. Construct a multilayer perceptron (MLP) model with l hidden layers. The model structure is as follows:

[0094] H (l) =sigmod(H (l-1) W (l) +b (l) )

[0095] Among them, sigmod(·) is the activation function, W (l) is the weight matrix between the l-1th layer and the lth layer of the multilayer perceptron, with a dimension of h (l-1) ×h (l) ,h (l) is the number of neurons in layer l, b (l) is the bias term of the lth layer, H (l) is the output of the lth layer, H (0) =X; after passing through the l-layer neural network, the evaluation prediction value of the software architecture is

[0096] Step 4.3: Model training. The loss function is calculated using Mean Squared Error (MSE) Calculate predicted values With the actual label y i The difference between:

[0097]

[0098] in, is the predicted value of the i-th sample, y i is the actual label of the i-th sample, and m is the number of samples. Using the training data set, the model parameters are optimized through the back propagation algorithm and stochastic gradient descent (SGD) to minimize the loss function.

[0099] The process of step 5 in this embodiment specifically includes the following steps:

[0100] Step 5.1: Model result analysis: Using the evaluation results of the multi-layer perceptron model in step 4, quantify the contribution of each feature, use SHAP values ​​to analyze the impact of each input feature on the final architecture score, and calculate the importance of each feature in the model output:

[0101]

[0102] Among them, φ i (f) represents the Shapley value of the feature, f(·) represents the output of the model trained on the feature set, |S| represents the size of the feature set, and |X| is the number of features.

[0103] Step 5.2: Identification of weak links in the software architecture: Based on the calculated SHAP value and the corresponding characteristic indicators, identify the features that have the greatest impact on the quality of the architecture; at the same time, use the higher dependency strength in the standardized DSM in step 3 to identify highly coupled modules and components; use the characteristics of architectural complexity to identify modules and components with high complexity; use the system balance characteristics to identify unbalanced modules and components in the system.

[0104] Step 5.3: Evaluation reference for similar software architectures: By comparing the software architecture to be evaluated with the architectural features, module coupling, complexity, system balance and other indicators of the same category (open source) products in the industry in the evaluation database, the relative position of the software architecture to be evaluated among similar products is highlighted.

[0105] Step 5.4: Generating software architecture assessment report: The software architecture assessment report is divided into four aspects: architecture overview, feature analysis, weak link identification, and optimization suggestions. The specific contents of each aspect are as follows:

[0106] Architecture Overview: Briefly introduce the architecture structure of the evaluation software, list the main modules, components and the dependency structure matrix between them (such as Figure 2) , and explain it. The distribution of the number of code lines in each module in the statistical software source code (such as Figure 5) And the number of header files in each module (such as Figure 6) , based on expert experience, make a judgment on the rationality of the distribution and reflect the problems existing in the software architecture.

[0107] Feature analysis: List the values ​​of each key feature (such as coupling, complexity, system balance, etc.) in detail and analyze their specific impact on the quality of the architecture.

[0108] Weak link identification: Based on the identified highly coupled modules, components with excessive complexity, and unbalanced modules, describe in detail the potential impact of each weak link on the quality of the software architecture.

[0109] Optimization suggestions: Propose targeted improvement measures for the identified weak links. For example, for highly coupled modules, it is recommended to split or reconstruct the modules; for components with excessive complexity, it is recommended to simplify the design or reduce the dependencies between modules; for system imbalance problems, it is recommended to adjust the dependencies between modules or redistribute tasks. For example: for highly coupled modules, by introducing an interface abstraction mechanism, the direct dependencies between modules are converted into interactions through interfaces, thereby reducing the degree of coupling between modules; for low cohesion modules, based on functional analysis, the parts of the modules with weak functional correlation are split to form multiple sub-modules with single responsibilities and high cohesion. In specific implementation, the functions of the modules can be sorted out in detail to clarify the relationship between the functions. According to the principle of high cohesion and low coupling, the original highly coupled module dependencies can be redesigned into an interface-based calling method, and the low cohesion modules can be divided into different sub-modules according to their functions, thereby optimizing the software architecture. Comparison chart of similar software: The bar chart is used for single-dimensional indicator comparison (such as circular dependency) to clearly show the difference between the current system and the industry benchmark in a certain indicator; the scatter plot matrix is ​​used for multi-dimensional correlation analysis (such as Figure 7 Path complexity – number of lines of code, Figure 8 Complexity-number of lines of code), intuitively presents the relationship between multiple dimensional indicators, and helps users gain a deeper understanding of the characteristics of software architecture.

[0110] Based on the feature sets of the four dimensions of the software to be evaluated obtained in step 2, as well as the weak modules analyzed and identified in step 5.2, combined with the prompt statements of the large language model, an evaluation report for each part is generated separately. Finally, through expert verification and review, the final software architecture evaluation report is formed.

[0111] Test example: Take the MySQL database system as an example:

[0112] Step 1: Construct the dependency structure matrix

[0113] By parsing the MySQL 8.0 source code, we identify the modules, classes, and methods in the software system, extract the calling relationships between them, and then construct a dependency structure matrix (DSM) (such as Figure 2 Show). Figure 4 Exhibition The DSM and basic information of the Storage module, the main core module of the MYSQL database, are shown. The rows and columns of the matrix correspond to sub-modules (such as Cmake, Utilities, Scripts, Unittest, and Storage, etc.), where the element values ​​represent the dependency strength between modules. For example, there are 134 dependencies between the Storage module and the Unittest module, which intuitively reflects the closeness of the dependency between the two modules. The meaning of "21%" means that the number of dependencies in the module Storage accounts for 21% of the total number of dependencies in the entire system.

[0114] Step 2: Multi-dimensional feature calculation

[0115] In terms of basic features, the number of source code lines is 5,511,594. Figure 3 It can be seen that the Storage module is written in C / C++ (Clang), with 1,370 header files and 1,266 source files, for a total of 2,636 files. The calculation of the architectural complexity shows that the path complexity is reflected in the number of independent paths, which is 7,642, and the complexity index is 154.064 (this value is the result of standardization based on 10,000,000). In terms of coupling cohesion, the coupling is 0.94%, and the coupling strength reaches 4.51, reflecting the closeness of the dependency. In terms of system balance, the path ratio is 50.00%, that is, the proportion of dependencies in the upper triangle of the matrix to the total dependencies. The functional balance index is 0.28, showing that the functional distribution of the system is relatively balanced.

[0116] Step 3: Standardize software architecture evaluation metrics

[0117] The Z-score method was used to standardize the extracted features. For example, the original value of path complexity 7,642 was standardized to 2.1, the coupling strength changed from 4.51 to 1.8, the system cycle amount changed from 22.10% to 0.9, the internal dependency changed from 121,799 to 1.5, the many-to-many strength changed from 13.14 to 0.7, and the weighted influence changed from 61.06% to 1.2. Through this standardization operation, the influence of different feature dimensions was eliminated, so that each feature could be evaluated at the same scale in the subsequent evaluation.

[0118] Step 4: MLP-based architecture evaluation

[0119] The standardized features are used as input to the MLP model (the hidden layer of the model is set to 64-32-16). After the model is trained, the output architecture quality score of the MySQL database system is 82 points (out of 100) and the classification label is "medium risk". From the model training loss curve, its convergence is stable, and the mean square error (MSE) of the validation set is 0.15, which shows that the training effect of the model is good.

[0120] Step 5: Result analysis and optimization suggestions

[0121] By comparing with similar systems (Sqlite, PostgreSQL, MongoDB), we found that in terms of path complexity, MySQL's 7,642 is 9.7 times that of Sqlite's 789 and 4 times that of MongoDB's 1,901, and its ratio to the number of lines of code deviates significantly from the industry trend (see Figure 7 ). In terms of coupling strength, 4.51 is higher than Sqlite's 0.94 and MongoDB's 2.32, and close to 50% of PostgreSQL's 9.24, which increases the risk of security vulnerabilities spreading. In terms of system cycle volume, 22.10% is higher than MongoDB's 13.64%, but lower than PostgreSQL's 32.60%. In terms of resource allocation, the Query module resource usage of 35% is far higher than the average of 22% in the same category, plus the many-to-many strength (13.14 compared to MongoDB's 13.552), which together aggravates the performance bottleneck.

[0122] In response to these problems, the optimization suggestions proposed include: decoupling modules, splitting Storage into StorageEngine and Transaction Manager, and isolating Storage-Parser dependencies through interfaces; managing circular dependencies, using event bus to replace the two-way call between Lock Manager and Storage, with the goal of reducing the amount of loops between components from 16.78% to below 10%; optimizing resource scheduling, introducing a dynamic load balancing algorithm in the Query module, and referring to the MongoDB strategy to reduce the resource usage ratio to less than 25%. Similar data show that the expected optimized path complexity can be reduced to below 3,200 (a decrease of 58%), the coupling strength can be reduced to 2.0 (industry security threshold), and the architecture score is expected to increase to 90 points, reaching the "low risk" level. The final report will provide a schematic diagram of the module dependency reconstruction and a phased implementation route.

Claims

1. A software architecture evaluation method based on dependency structure matrix, characterized in that: The method is implemented as follows: Step 1: Construct a dependency structure matrix: obtain the source code of the software to be evaluated, parse the source code to identify the modules, classes and methods in the software system; extract the dependency relationships between the software entities based on the parsing results, including but not limited to the dependencies between modules, the calling relationships between classes, and the calling relationships between methods; construct a dependency structure matrix DSM based on the above dependencies, where each row and column in the DSM represents a module in the software, and the value of the element in the DSM represents the dependency strength between the modules; Step 2: Multi-dimensional feature calculation based on DSM: Extract multi-scale features based on the constructed dependency structure matrix DSM. The multi-scale features cover features in four dimensions: basic features, architecture complexity, coupling cohesion, and system balance. Step 3: Standardization of software architecture evaluation indicators: The multi-scale features extracted from the dependency structure matrix are standardized using the Z-score standardization method to eliminate the influence of different feature dimensions. The standardization process maps each feature value to a unified numerical range to ensure that each feature is evaluated at the same scale in the subsequent evaluation. Step 4: Architecture evaluation based on multi-layer perceptron: Use the multi-layer perceptron model MLP to fuse the standardized multi-scale features in step 3 for training, learn the mapping relationship between each feature index and the architecture evaluation label, use the standardized evaluation features in step 3 as input, and perform nonlinear feature fusion and pattern learning through multiple hidden layers of the multi-layer perceptron model MLP to capture the complex relationship between features; use supervised learning methods to optimize model parameters through labeled architecture evaluation labels; after training, use the trained multi-layer perceptron model MLP to score or classify the software architecture to be evaluated; Step 5: Analysis of architecture evaluation results and generation of optimization suggestions: Based on the evaluation results of the multi-layer perceptron model in step 4, analyze the contribution of each feature to the final score or classification result, and determine the key factors affecting the quality of the software architecture.

2. A software architecture evaluation method based on dependency structure matrix according to claim 1, characterized in that: Step 2 specifically includes the following steps: Step 2.

1. Calculate basic feature indicators: obtain the number of code lines L, header file count H, and total element number N by directly counting the source code, obtain the number of edges E by counting the sum of non-zero elements in the DSM, obtain the number of module dependency out-edges O by counting the sum of all non-zero elements in the row where the module is located in the DSM, and obtain the number of module dependency in-edges I by counting all non-zero elements in the column where the module is located in the DSM; Step 2.2: Calculate the architecture complexity index: The architecture complexity index includes architecture complexity CA, path complexity CP, cyclomatic complexity CC, and system loop volume SL, where: Complexity CA = V × E; The path complexity CP is obtained by counting the number of independent paths in the control flow graph; Cyclomatic complexity CC = E-N+2, where N represents the number of nodes, i.e. the total number of modules and components in the source code; The system circulation volume SL is obtained by counting the number of cycles in the system; Step 2.3: Calculate the coupling cohesion index: The coupling cohesion index includes cohesion CH, coupling strength CS, coupling enrichment CE, and connectivity enrichment CNE. i For example, where: Cohesion N(Mo i ) indicates module Mo i The number of methods and classes contained, is the total number of classes and methods in the module, μ(A j ) indicates that the module is related to method or class A j The total number of methods or classes with dependencies; Coupling strength N(Mo i ) indicates module Mo i The number of methods and classes contained, lsc(Mo i ,Mo j ) indicates that the module Mo is included i and module Mo j The length of the shortest loop between is the total number of classes and methods in the module; Coupling enrichment CO(Mo i ) represents the module coupling degree, ECO(Mo i ) represents the expected coupling degree, module Mo i Coupling is the number of reachable paths between methods and classes in the module, is the total number of classes and methods in the module, and the expected coupling degree is the actual coupling degree calculated after disrupting and reconnecting the dependencies between the classes and methods in the module; Connectivity Richness CONN(Mo i ) indicates the actual connectivity, ECONN(Mo i ) represents the expected connectivity. The actual connectivity calculation formula is is the number of edges in the module, is the total number of classes and methods in the module, and the expected connectivity is the actual connectivity calculated after disrupting and reconnecting the dependencies between the classes and methods in the module; Step 2.4: Calculate system balance index: The system balance index includes path ratio PR, balance FB, and module importance IM, among which: The path ratio PR is the ratio of the number of dependencies in the upper triangle of the dependency structure matrix to the total number of dependencies; Module importance IM is the PageRank value of the module calculated by PageRank algorithm; Balance KL(Mo i ) indicates module Mo i The JS divergence value between the degree distribution of classes and methods in the dependency structure matrix and the average distribution, and N represents the total number of modules and components in the project.

3. A software architecture evaluation method based on dependency structure matrix according to claim 2, characterized in that: Step 3 specifically includes the following steps: Step 3.1: Obtain various features extracted from the dependency structure matrix DSM in step 2, including basic features, architecture complexity features, coupling cohesion features, and system balance features; perform integrity check on feature data, remove outliers, missing values, or redundant data, and ensure data quality; Step 3.2: According to the numerical range and distribution characteristics of different features, select the Z-score standardization method to map the feature values ​​to a unified numerical range to eliminate the dimensional influence of different features. The calculation formula of the Z-score standardization method is as follows: Among them, x is the original eigenvalue, μ is the mean value of the feature, σ is the standard deviation of the eigenvalue, and x′ is the standardized eigenvalue.

4. A software architecture evaluation method based on dependency structure matrix according to claim 3, characterized in that: Step 4 specifically includes the following steps: Step 4.1: Model input preparation: Use the standardized multidimensional evaluation indicators in step 3 as input features to form an input vector X = [x1, x2, ..., x |X| ], where |X| is the number of features; each input feature x i Corresponds to a feature extracted from a certain dimension in the dependency structure matrix, such as basic features, architectural complexity, coupling cohesion, or system balance; Step 4.2: Multilayer Perceptron Model Construction: Construct a multilayer perceptron MLP model with l hidden layers. The MLP model structure is as follows: H (l) =sigmod(H (l-1) W (l) +b (l) ) Among them, sigmod(·) is the activation function, W (l) is the weight matrix between the l-1th layer and the lth layer of the multilayer perceptron, with a dimension of h (l-1) ×h (l) ,h (l) is the number of neurons in layer l, b (l) is the bias term of the lth layer, H (l) is the output of the lth layer, H (0) =X; after passing through the l-layer neural network, the evaluation prediction value of the software architecture is Step 4.3: Model training: Calculate the loss function using mean square error Calculate predicted values With the actual label y i The difference between: in, is the predicted value of the i-th sample, y i is the actual label of the i-th sample, and d is the number of samples; Using the training dataset, the model parameters are optimized through the back-propagation algorithm and stochastic gradient descent (SGD) to minimize the loss function.

5. A software architecture evaluation method based on dependency structure matrix according to claim 4, characterized in that: The step 5 specifically comprises the following steps: Step 5.1: Model result analysis: Using the evaluation results of the multi-layer perceptron model in step 4, quantify the contribution of each feature, use SHAP values ​​to analyze the impact of each input feature on the final architecture score, and calculate the importance of each feature in the model output: Among them, φ i (f) represents the Shapley value of the feature, f(·) represents the output of the model trained on the feature set, |S| represents the size of the feature set, and |X| is the number of features; Step 5.2: Identification of weak links in software architecture: Based on the calculated SHAP values ​​and corresponding characteristic indicators, identify the features that have the greatest impact on the quality of the architecture; at the same time, use the high dependency strength in the standardized DSM in step 3 to identify highly coupled modules and components; use the features of architectural complexity to identify modules and components with high complexity; use the system balance features to identify unbalanced modules and components in the system; Step 5.3: Similar software architecture evaluation reference: By comparing the architecture characteristics, module coupling, complexity and system balance indicators of the software architecture to be evaluated with the same category of products in the industry in the evaluation database, the relative position of the software architecture to be evaluated among similar products is highlighted; Step 5.4: Generate software architecture assessment report.

Images