A software architecture evaluation method based on dependency structure matrix

Abstract

This invention discloses a software architecture evaluation method based on a dependency structure matrix (DSM), aiming to comprehensively evaluate the quality of software architecture, identify potential problems, and provide effective optimization strategies. The method first constructs a dependency structure matrix; then extracts multi-scale features based on the constructed DSM; next, it standardizes software architecture evaluation metrics; then, it trains a multilayer perceptron model (MLP) by fusing the standardized multi-scale features. After training, the trained MLP is used to score or classify the software architecture to be evaluated; finally, based on the evaluation results of the MLP, the contribution of each feature to the final score or classification result is analyzed to determine the key factors affecting the quality of the software architecture. This invention can help developers improve the quality, maintainability, and scalability of software architecture, reduce technical debt, and ensure the long-term stability of software systems, possessing strong adaptability and practical value.

Description

Technical Field

[0001] This invention belongs to the field of software engineering and relates to a software architecture evaluation method based on the Dependency Structure Matrix (DSM). Background Technology

[0002] The concept of a "software crisis" has existed almost since the birth of computers and remains one of the major challenges facing the software development field. Its core manifestations include: software performance often failing to keep pace with the rapid development of hardware technology; a significant gap between research progress in software development and actual application needs; and developers often feeling overwhelmed when facing large-scale software projects, leading to budget overruns and repeated delays in delivery. Furthermore, from a software quality perspective, as software systems grow in scale, especially with the development of large-scale software, maintenance becomes more difficult, and software portability and reusability decrease, further exacerbating this problem.

[0003] With the rapid development of internet and big data technologies, the scale and complexity of software systems are constantly increasing. To cope with these changes, the importance of software architecture is becoming increasingly prominent. Software architecture is the skeleton and basic structure of a system; it determines many aspects of the system, including performance, reliability, and scalability, and directly affects its maintainability and long-term stability. Therefore, evaluating software architecture, especially in complex systems, to assess the existence of technical debt and potential problems, has become a critical task in the software development and maintenance process.

[0004] Currently, many software metrics methods based on programs and source code have emerged, and these methods have been successfully applied to software development, optimization, and maintenance. However, research on system metrics from a software architecture perspective is still in the exploratory stage. Existing architectural metrics methods often fail to comprehensively cover the quality attributes of a system, especially when dealing with large-scale and complex systems, where related research and applications remain insufficient. Therefore, designing a method that can comprehensively evaluate software architecture quality, locate potential problems, and provide effective optimization strategies has become an urgent challenge.

[0005] Ensuring the quality, maintainability, and security of software systems is one of the most critical tasks in modern software development. In current software development, to meet ever-increasing user demands, 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 typically focus on functional and performance testing; however, when faced with complex software architectures, these methods often fail to identify potential risks at the architectural level, especially when the architecture is poorly designed, which can lead to 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 the software architecture without the aid of specialized architecture analysis tools. The rationality of the architecture design directly affects the efficiency and quality of software development. A chaotic and unreasonable architecture not only affects system performance but also increases the difficulty of development, maintenance, and expansion, and may even lead to project failure. Therefore, a comprehensive and systematic evaluation of the software architecture is particularly important. Summary of the Invention

[0007] To address the aforementioned problems, this invention provides a software architecture evaluation method based on a dependency structure matrix. This method comprehensively evaluates the quality of the software architecture by analyzing the modules in the software system and their dependencies, and provides potential problem location and optimization suggestions through machine learning algorithms.

[0008] The above objectives are achieved through the following technical solutions:

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

[0010] Step 1: Construct 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 each software entity based on the parsing results, including but not limited to inter-module dependencies, inter-class call relationships, and method call relationships; construct the Dependency Structure Matrix (DSM) based on the above dependency relationships, 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;

[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 four dimensions: basic features, architectural complexity, coupling cohesion, and system balance.

[0012] Step 3: Standardization of software architecture evaluation metrics: 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 uniform numerical range to ensure that each feature is evaluated on the same scale in subsequent evaluations.

[0013] Step 4: Architecture Evaluation Based on Multilayer Perceptron: The Multilayer Perceptron (MLP) model is trained by fusing the standardized multi-scale features from Step 3 to learn the mapping relationship between each feature index and the architecture evaluation label. The standardized evaluation features from Step 3 are used as input and undergo nonlinear feature fusion and pattern learning through multiple hidden layers of the MLP model to capture the complex relationships between features. Supervised learning methods are used to optimize the model parameters using the labeled architecture evaluation labels. After training, the trained MLP model is used 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 multilayer perceptron model in Step 4, analyze the contribution of each feature to the final score or classification result, and identify 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 lines of code L, header file count H, and total number of elements N by directly counting the source code; obtain the number of edges E by summing the non-zero elements in the DSM; obtain the number of outgoing edges of the module's dependencies O by summing all non-zero elements in the row where the module is located in the DSM; and obtain the number of incoming edges of the module's dependencies I by summing all non-zero elements in the column where the module is located in the DSM.

[0017] Step 2.2: Calculate architectural complexity metrics: Architectural complexity metrics include architectural complexity (CA), path complexity (CP), cyclomatic complexity (CC), and system loop count (SL), where:

[0018] Complexity CA = V × E;

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

[0020] Cyclic 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 loop quantity SL is obtained by counting the number of loops 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), with module Mo as the unit. i For example, in the following calculation:

[0023] cohesion N(Mo i ) represents module Mo i The number of methods and classes included. μ(A) represents the total number of classes and methods in the module. j ) indicates that the module contains a method or class A. j The total number of methods or classes with dependencies;

[0024] Coupling strength N(Mo i ) represents module Mo i The number of methods and classes included, lsc(Mo i Mo j ) indicates that it contains module Mo i and module Mo j The length of the shortest loop between them. This represents 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 desired coupling degree, module Mo i Coupling degree This represents the number of reachable paths between methods and classes within a module. The total number of classes and methods in the module is given. The expected coupling degree is the actual coupling degree calculated after the dependencies between classes and methods in the module are shuffled and reconnected.

[0026] Connectivity enrichment CONN(Mo i ECONN(Mo) represents actual connectivity. i () represents the desired connectivity. The formula for calculating actual connectivity is: The number of edges in the module. The total number of classes and methods in the module is given. The expected connectivity is the actual connectivity calculated after shuffling and reconnecting the dependencies between classes and methods in the module.

[0027] Step 2.4: Calculate system balance indices: System balance indices include path proportion (PR), balance factor (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 a module calculated using the PageRank algorithm.

[0030] Balance KL(Mo i) represents module Mo i The degree distribution and average distribution of classes and methods in the dependency structure matrix are represented by the JS divergence values, where 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 the various features extracted from the Dependency Structure Matrix (DSM) in Step 2, including basic features, architectural complexity features, coupling cohesion features, and system balance features; perform integrity checks on the feature data, remove outliers, missing values, or redundant data, and ensure data quality.

[0033] Step 3.2: Based on the numerical range and distribution characteristics of different features, select the Z-score standardization method to map the feature values ​​to a uniform numerical range, thereby eliminating the influence of different features' dimensions. The calculation formula for the Z-score standardization method is as follows:

[0034]

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

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

[0037] Step 4.1: Model Input Preparation: Use the standardized multidimensional evaluation metrics from Step 3 as input features to construct the input vector X = [x1, x2, ..., x...]. |X| ], where |X| is the number of features; each input feature x i This corresponds to a feature extracted from a certain dimension of 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] Where sigmod(·) is the activation function, W (l) Let h be the weight matrix between the (l-1)th layer and the lth layer of the multilayer perceptron. (l-1) ×h (l) , h (l) b is the number of neurons in the l-th layer. (l) H is the bias term for the l-th layer.(l) H is the output of the l-th layer. (0) =X; After passing through an l-layer neural network, the predicted evaluation value of the software architecture is obtained.

[0041] Step 4.3: Model Training: Calculate the loss function using mean squared error. Calculate the predicted value With actual label y i Differences between them:

[0042]

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

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

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

[0046] Step 5.1: Model Result Analysis: Using the evaluation results of the multilayer perceptron model in Step 4, the contribution of each feature is quantified. The SHAP value is used to analyze the impact of each input feature on the final architecture score, and the importance of each feature in the model output is calculated.

[0047]

[0048] Where, φ 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: Software Architecture Weakness Identification: Based on the calculated SHAP value and corresponding feature indicators, identify the features that have the greatest impact on architecture quality; at the same time, using the dependency strength that shows high performance in the standardized DSM in Step 3, identify highly coupled modules and components; using the features of architectural complexity, identify modules and components with high complexity; using the system balance features, identify unbalanced modules and components in the system.

[0050] Step 5.3: Evaluation Reference of Similar Software Architectures: By comparing the architecture characteristics, module coupling, complexity, and system balance indicators of the software architecture to be evaluated with those of similar (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;

[0051] Step 5.4: Generating the 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] This invention employs a multi-dimensional evaluation model to comprehensively assess various quality attributes of software architecture from multiple perspectives, including performance, maintainability, security, and scalability. Through detailed analysis of the software architecture, this invention can effectively identify potential problems, particularly issues such as excessive coupling, poor cohesion, and system imbalance, and propose optimization suggestions. This helps developers improve the quality and maintainability of software architecture, reduce technical debt, and ensure the long-term stable operation of the software system. This approach will provide new theoretical basis and practical guidance for the design and optimization of software architecture, and has broad application prospects. Attached Figure Description

[0054] Figure 1 This is a flowchart of the software architecture evaluation method based on the dependency structure matrix of this invention.

[0055] Figure 2 is The Dependency Structure Matrix (DSM) of the MySQL embodiment tested in this invention.

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

[0057] Figure 4 is In this invention, the dependency structure matrix and basic information of the Storage module in the MySQL embodiment are tested.

[0058] Figure 5 is The code line count distribution diagram of the MySQL embodiment tested in this invention.

[0059] Figure 6 is This invention presents a header file count distribution diagram for each folder in the MySQL test implementation.

[0060] Figure 7 This is a graph showing the relationship between the number of lines of code and path complexity in the MySQL test implementation of this invention and similar projects.

[0061] Figure 8 This is a graph showing the relationship between the number of lines of code and complexity in the MySQL test instance and similar projects in this invention. Detailed Implementation

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

[0063] The following is only one embodiment of the present invention. The present invention has many other embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding changes and modifications according to the present invention. All such corresponding changes and modifications should fall within the protection scope of the appended claims.

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

[0065] Step 1: Construct the Dependency Structure Matrix. Obtain the source code of the software to be evaluated, and parse the source code to identify the modules, classes, and methods in the software system; extract the dependencies between each software entity based on the parsing results, including but not limited to inter-module dependencies, inter-class call relationships, and method call relationships; construct a Dependency Structure Matrix (DSM) based on the above dependencies, where each row and column of the DSM represents a module in the software, and the values ​​of the elements in the DSM represent 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 four dimensions: basic features, architectural complexity, coupling cohesion, and system balance. In this invention, modules and components in the software source code are collectively referred to as atoms. Regarding basic features, the calculation includes the number of lines of code, number of interfaces, number of atoms, number of edges between atoms, header file count, source file count, total number of atoms (including the entire hierarchy and element counts at each level), number of outgoing edges of each atom, and number of incoming edges of each atom. Regarding architectural complexity, the calculation includes the depth (number of modules traversed by the longest dependency path) and breadth (number of different modules involved in the dependency path), system loop volume (number of loop structures existing in the system), and inter-component loop volume (number of loop structures formed between components). Regarding coupling cohesion, the metrics include the distribution of dependency strength between modules, cohesion, coupling (measuring the tightness of coupling between modules), coupling richness (reflecting the richness of coupling relationships in the system), coupling strength (considering the tightness of dependencies between modules), internal dependency (dependencies within a module), connectivity (the degree of connection between modules), connectivity richness (the richness of connections between modules in the system), and connectivity strength (the strength of connections between modules). Regarding system balance, the metrics include the evenness of dependency distribution (e.g., path ratio, i.e., the proportion of dependencies in the upper triangle of the DSM to the total dependencies), resource utilization ratio (e.g., functional balance, measuring the evenness of functional distribution 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 a module in the system).

[0067] Step 3: Standardize software architecture evaluation metrics. 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 uniform numerical range to ensure that each feature is evaluated on the same scale in subsequent evaluations.

[0068] Step 4: Architecture Evaluation Based on Multilayer Perceptron. The multilayer perceptron (MLP) model is trained by fusing the normalized multidimensional evaluation metrics from Step 3, learning the mapping relationship between each feature metric and the architecture evaluation label. The normalized evaluation features are used as input, undergoing nonlinear feature fusion and pattern learning through multiple hidden layers of the MLP to capture the complex relationships between features. Supervised learning methods are employed to optimize the model parameters using the labeled architecture evaluation labels. After training, the trained model is used to score or classify the software architecture to be evaluated.

[0069] Step 5: Architecture Evaluation Result Analysis and Optimization Suggestion Generation. Based on the evaluation results of the multilayer perceptron model in Step 4, analyze the contribution of each feature to the final score or classification result to identify key factors affecting software architecture quality. Through feature importance analysis, identify weak points in the architecture, such as highly coupled modules, excessively complex components, or system imbalances. Combining the analysis results, generate targeted improvement suggestions, including module decomposition optimization, reducing coupling, and adjusting the hierarchical structure, to help developers improve the quality, maintainability, and scalability of the software architecture.

[0070] Step 2 in this embodiment specifically includes the following steps:

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

[0072] Step 2.2: Calculate architectural complexity metrics: Architectural complexity metrics include architectural complexity (CA), path complexity (CP), cyclomatic complexity (CC), and system loop count (SL), where:

[0073] Complexity CA = V × E;

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

[0075] Cyclic 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 loop quantity SL is obtained by counting the number of loops 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), with module Mo as the unit. i For example, in the calculation:

[0078] cohesion N(Mo i ) represents module Mo i The number of methods and classes included. μ(A) represents the total number of classes and methods in the module. j ) indicates that the module contains a method or class A. j The total number of methods or classes with dependencies;

[0079] Coupling strength N(Mo i ) represents module Mo i The number of methods and classes included, lsc(Mo i Mo j ) indicates that it contains module Mo i and module Mo j The length of the shortest loop between them. This represents the total number of classes and methods in the module.

[0080] Coupling enrichment CO(MO i ECO(MO) represents the module coupling degree. i ) represents the desired coupling degree, module MO i Coupling degree This represents the number of reachable paths between methods and classes within a module. The total number of classes and methods in the module is given. The expected coupling degree is the actual coupling degree calculated after the dependencies between classes and methods in the module are shuffled and reconnected.

[0081] Connectivity enrichment CONN(Mo i ECONN(Mo) represents actual connectivity. i () represents the desired connectivity. The formula for calculating actual connectivity is: The number of edges in the module. The total number of classes and methods in the module is given. The expected connectivity is the actual connectivity calculated after shuffling and reconnecting the dependencies between classes and methods in the module.

[0082] Step 2.4: Calculate system balance indices: System balance indices include path proportion (PR), balance factor (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 a module calculated using the PageRank algorithm.

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

[0086] Step 3 in this embodiment specifically includes the following steps:

[0087] Step 3.1: Obtain the various features extracted from the Dependency Structure Matrix (DSM) in Step 2, including basic features, architectural complexity features, coupling cohesion features, and system balance features; perform integrity checks on the feature data, remove outliers, missing values, or redundant data, and ensure data quality;

[0088] Step 3.2: Based on the numerical range and distribution characteristics of different features, select the Z-score normalization method to map the feature values ​​to a uniform numerical range, thereby eliminating the influence of different features' dimensions. The calculation formula for the Z-score normalization method is as follows:

[0089]

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

[0091] Step 4 in this embodiment specifically includes the following steps:

[0092] Step 4.1: Model Input Preparation. The standardized multidimensional evaluation metrics from Step 3 are used as input features to construct the input vector X = [x1, x2, ..., x...]. |X| ], where |X| is the number of features. Each input feature x i This corresponds to a feature extracted from a certain dimension of the dependency structure matrix, such as basic features, 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] Where sigmod(·) is the activation function, W (l) Let h be the weight matrix between the (l-1)th layer and the lth layer of the multilayer perceptron. (l-1) ×h (l) h (l) b is the number of neurons in the l-th layer. (l) H is the bias term for the l-th layer. (l) H is the output of the l-th layer. (0) =X; After passing through an l-layer neural network, the predicted evaluation value of the software architecture is obtained.

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

[0097]

[0098] in, Let y be the predicted value of the i-th sample. i Let be the actual label of the i-th sample, and m be the number of samples. Using the training dataset, the model parameters are optimized using backpropagation and stochastic gradient descent (SGD) to minimize the loss function.

[0099] Step 5 of this embodiment specifically includes the following steps:

[0100] Step 5.1: Model Result Analysis: Using the evaluation results of the multilayer perceptron model in Step 4, the contribution of each feature is quantified. The SHAP value is used to analyze the impact of each input feature on the final architecture score, and the importance of each feature in the model output is calculated.

[0101]

[0102] Where, φ 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: Software Architecture Weakness Identification: Based on the calculated SHAP value and corresponding feature indicators, identify the features that have the greatest impact on architecture quality; at the same time, using the dependency strength that is higher in the standardized DSM in Step 3, identify highly coupled modules and components; using the features of architectural complexity, identify modules and components with high complexity; and using the system balance features, identify unbalanced modules and components in the system.

[0104] Step 5.3: Evaluation Reference of Similar Software Architectures: By comparing the software architecture to be evaluated with similar (open source) products in the industry in terms of architectural characteristics, module coupling, complexity, and system balance, the relative position of the software architecture to be evaluated among similar products is highlighted.

[0105] Step 5.4: Software Architecture Assessment Report Generation: The software architecture assessment report consists of four parts: architecture overview, feature analysis, weakness identification, and optimization suggestions. The specific content of each part is as follows:

[0106] Architecture Overview: Briefly describe the architecture of the software being evaluated, listing the main modules, components, and their dependency matrix (e.g., ...). Figure 2) And provide explanations. Statistically analyze the distribution of lines of code in each module of the software source code (e.g., ...). Figure 5) and the distribution of the number of header files in each module (e.g.) Figure 6) Based on expert experience, the rationality of the distribution is judged, and the problems of the software architecture are reflected in the indirect reflection.

[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 architecture quality.

[0108] Vulnerability identification: Based on the identified highly coupled modules, overly complex components, and unbalanced modules, describe in detail the potential impact of each vulnerability on the quality of the software architecture.

[0109] Optimization Recommendations: For identified weaknesses, propose targeted improvement measures. For example, for highly coupled modules, suggest module splitting or refactoring; for components with excessive complexity, suggest simplifying the design or reducing inter-module dependencies; for system imbalance issues, suggest adjusting inter-module dependencies or reallocating tasks. For example, for highly coupled modules, introduce an interface abstraction mechanism to transform direct dependencies between modules into interactions through interfaces, thereby reducing the degree of coupling between modules; for low-cohesion modules, based on functional analysis, split the parts with weak functional correlation within the module, forming multiple sub-modules with single responsibilities and high cohesion. In specific implementation, a detailed analysis of module functions can be conducted to clarify the relationships between functions. Based on the principle of high cohesion and low coupling, the originally highly coupled module dependencies can be redesigned into interface-based calling methods, and low-cohesion modules can be divided into different sub-modules according to function, thereby optimizing the software architecture. Comparison Charts with Similar Software: Bar charts are used for single-dimensional indicator comparisons (such as circular dependencies), clearly showing the differences between the current system and industry benchmarks in a certain indicator; scatter plot matrices are used for multi-dimensional correlation analysis (such as... Figure 7 Path complexity – number of lines of code Figure 8 Complexity (lines of code) intuitively presents the interrelationships between multiple dimensions of metrics, helping users gain a deeper understanding of the characteristics of software architecture.

[0110] Based on the feature set of the four dimensions obtained in step 2 and the weak modules identified in step 5.2, combined with the prompts from the large language model, an evaluation report for each part is generated. Finally, through expert verification and review, a final software architecture evaluation report is formed.

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

[0112] Step 1: Construct the dependency structure matrix

[0113] By parsing the MySQL 8.0 source code, the modules, classes, and methods in the software system are identified. Based on this, the calling relationships between them are extracted, and a dependency structure matrix (DSM) is constructed (e.g., ...). Figure 2 Show). Figure 4 This diagram shows the DSM and basic information of the Storage module, a major core module of the MySQL database. The rows and columns of the matrix correspond to sub-modules (such as CMake, Utilities, Scripts, Unittest, and Storage). The element values ​​represent the dependency strength between modules. For example, the Storage module and the Unittest module have 134 dependencies, which intuitively reflects the tightness of the dependency between these two modules. The "21%" means that the number of dependencies in the Storage module accounts for 21% of the total number of dependencies in the entire system.

[0114] Step 2: Multidimensional Feature Calculation

[0115] Regarding basic features, the total number of lines of code in the source code is 5,511,594. From... Figure 3 is available. The Storage module, written in C / C++ (Clang), has 1,370 header files and 1,266 source files, totaling 2,636 files. Architectural complexity calculations show 7,642 independent paths and a complexity index of 154.064 (normalized to 10,000,000). Coupling cohesion is 0.94%, with a coupling strength of 4.51, reflecting a tight dependency. System balance is 50.00%, representing the proportion of dependencies in the upper triangle of the matrix. The functional balance index is 0.28, indicating a relatively balanced distribution of system functions.

[0116] Step 3: Standardize software architecture evaluation metrics

[0117] The extracted features were standardized using the Z-score method. For example, the original path complexity of 7,642 was standardized to 2.1, coupling strength from 4.51 to 1.8, system loop count from 22.10% to 0.9, internal dependency from 121,799 to 1.5, many-to-many strength from 13.14 to 0.7, and weighted influence from 61.06% to 1.2. This standardization process eliminated the influence of different feature dimensions, allowing each feature to be evaluated on the same scale.

[0118] Step 4: MLP-based architecture evaluation

[0119] The standardized features were used as input and fed into an MLP model (with 64-32-16 hidden layers). After training, the model output an architecture quality score of 82 out of 100 for the MySQL database system, with a classification label of "medium risk". The model training loss curve shows stable convergence, and the mean squared error (MSE) on the validation set is 0.15, indicating good training performance.

[0120] Step 5: Results Analysis and Optimization Suggestions

[0121] Comparison with similar systems (SQLite, PostgreSQL, MongoDB) reveals 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. Furthermore, its ratio to lines of code significantly deviates from industry trends (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 vulnerability propagation. Regarding system loop 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's resource consumption of 35% far exceeds the average of 22% for similar modules, and coupled with the many-to-many strength (13.14 compared to MongoDB's 13.552), this further exacerbates the performance bottleneck.

[0122] To address these issues, the proposed optimization suggestions include: decoupling modules by splitting Storage into StorageEngine and Transaction Manager, and isolating the Storage-Parser dependency through interfaces; managing circular dependencies by replacing bidirectional calls between Lock Manager and Storage with an event bus, aiming to reduce the circular dependency rate between components from 16.78% to below 10%; and optimizing resource scheduling by introducing a dynamic load balancing algorithm in the Query module, referencing MongoDB strategies to compress resource consumption to below 25%. Similar data shows that the optimized path complexity is expected to be reduced to below 3,200 (a 58% reduction), coupling strength to 2.0 (the industry safety threshold), and the architecture score is expected to improve to 90 points, reaching a "low-risk" level. The final report will provide a schematic diagram of module dependency refactoring and a phased implementation roadmap.

Claims

1. A software architecture evaluation method based on a dependency structure matrix, characterized in that, This method is implemented according to the following steps: Step 1: Construct 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 each software entity based on the parsing results, including but not limited to inter-module dependencies, inter-class call relationships, and method call relationships; construct the Dependency Structure Matrix (DSM) based on the above dependency relationships, 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; 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 four dimensions: basic features, architectural complexity, coupling cohesion, and system balance. Step 3: Standardization of software architecture evaluation metrics: 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 uniform numerical range to ensure that each feature is evaluated on the same scale in subsequent evaluations. Step 4: Architecture Evaluation Based on Multilayer Perceptron: The Multilayer Perceptron (MLP) model is trained by fusing the standardized multi-scale features from Step 3 to learn the mapping relationship between each feature index and the architecture evaluation label. The standardized evaluation features from Step 3 are used as input and undergo nonlinear feature fusion and pattern learning through multiple hidden layers of the MLP model to capture the complex relationships between features. Supervised learning methods are used to optimize the model parameters using the labeled architecture evaluation labels. After training, the trained MLP model is used 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 multilayer perceptron model in Step 4, analyze the contribution of each feature to the final score or classification result, and identify the key factors affecting the quality of the software architecture.

2. The 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 lines of code L, header file count H, and total number of elements N by directly counting the source code; obtain the number of edges E by summing the non-zero elements in the DSM; obtain the number of outgoing edges of the module's dependencies O by summing all non-zero elements in the row where the module is located in the DSM; and obtain the number of incoming edges of the module's dependencies I by summing all non-zero elements in the column where the module is located in the DSM. Step 2.2: Calculate architectural complexity metrics: Architectural complexity metrics include architectural complexity (CA), path complexity (CP), cyclomatic complexity (CC), and system loop count (SL), where: Complexity CA = V × E; Path complexity CP is obtained by counting the number of independent paths in the control flow graph; Cyclic 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 loop quantity SL is obtained by counting the number of loops 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), with module Mo as the unit. i For example, in the following calculation: cohesion N(Mo i ) represents module Mo i The number of methods and classes included. μ(A) represents the total number of classes and methods in the module. j ) indicates that the module contains a method or class A. j The total number of methods or classes with dependencies; Coupling strength N(Mo i ) represents module Mo i The number of methods and classes included, lsc(Mo i Mo j ) indicates that it contains module Mo i and module Mo j The length of the shortest loop between them. This represents 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 desired coupling degree, module Mo i Coupling degree This represents the number of reachable paths between methods and classes within a module. The total number of classes and methods in the module is given. The expected coupling degree is the actual coupling degree calculated after the dependencies between classes and methods in the module are shuffled and reconnected. Connectivity enrichment CONN(Mo i ECONN(Mo) represents actual connectivity. i () represents the desired connectivity. The formula for calculating actual connectivity is: The number of edges in the module. The total number of classes and methods in the module is given. The expected connectivity is the actual connectivity calculated after shuffling and reconnecting the dependencies between classes and methods in the module. Step 2.4: Calculate system balance indices: System balance indices include path proportion (PR), balance factor (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 a module calculated using the PageRank algorithm. Balance KL(Mo i ) represents module Mo i The degree distribution and average distribution of classes and methods in the dependency structure matrix are represented by the JS divergence values, where N represents the total number of modules and components in the project.

3. The 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 the various features extracted from the Dependency Structure Matrix (DSM) in Step 2, including basic features, architectural complexity features, coupling cohesion features, and system balance features; perform integrity checks on the feature data, remove outliers, missing values, or redundant data, and ensure data quality. Step 3.2: Based on the numerical range and distribution characteristics of different features, select the Z-score standardization method to map the feature values ​​to a uniform numerical range, thereby eliminating the influence of different features' dimensions. The calculation formula for the Z-score standardization method is as follows: Where x is the original feature value, μ is the mean of the feature, σ is the standard deviation of the feature value, and x′ is the standardized feature value.

4. The 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 metrics from Step 3 as input features to construct the input vector X = [x1, x2, ..., x...]. |X| ], where |X| is the number of features; each input feature x i This corresponds to a feature extracted from a certain dimension of 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) ) Where sigmod(·) is the activation function, W (l) Let h be the weight matrix between the (l-1)th layer and the lth layer of the multilayer perceptron. (l-1) ×h (l) h (l) b is the number of neurons in the l-th layer. (l) H is the bias term for the l-th layer. (l) H is the output of the l-th layer. (0) =X; After passing through an l-layer neural network, the predicted evaluation value of the software architecture is obtained. Step 4.3: Model Training: Calculate the loss function using mean squared error. Calculate the predicted value With actual label y i Differences between them: in, Let y be the predicted value of the i-th sample. i Let be the actual label of the i-th sample, and d be the number of samples; Using the training dataset, the model parameters are optimized through backpropagation and stochastic gradient descent (SGD) to minimize the loss function.

5. The software architecture evaluation method based on a dependency structure matrix according to claim 4, characterized in that, Step 5 specifically includes the following steps: Step 5.1: Model Result Analysis: Using the evaluation results of the multilayer perceptron model in Step 4, the contribution of each feature is quantified. The SHAP value is used to analyze the impact of each input feature on the final architecture score, and the importance of each feature in the model output is calculated. Where, φ 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: Software Architecture Weakness Identification: Based on the calculated SHAP value and corresponding feature indicators, identify the features that have the greatest impact on architecture quality; at the same time, using the dependency strength that shows high performance in the standardized DSM in Step 3, identify highly coupled modules and components; using the features of architectural complexity, identify modules and components with high complexity; using the system balance features, identify unbalanced modules and components in the system. Step 5.3: Evaluation Reference of Similar Software Architectures: By comparing the architecture characteristics, module coupling, complexity, and system balance indicators of the software architecture to be evaluated with those of similar 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: Generating the software architecture assessment report.

Images