A software architecture optimization method, device and storage medium

Abstract

The present invention provides a software architecture optimization method, device and storage medium. Starting from the entire process from the development to the operation of the software architecture, a static call relationship network representing the call relationship between components, a team division structure representing the collaborative relationship between developers, a service linkage modification relationship network representing the modification relationship between services, and a communication structure representing the closeness of communication between developers are sequentially constructed. Then, the static call relationship network, the team division structure, the service linkage modification relationship network and the communication structure are used as reference information for software architecture optimization to optimize the software architecture. Compared with traditional architecture governance, it is more comprehensive and reliable, and because it is modeled by the data generated by the architecture itself, modeling and governance can be performed throughout the entire life cycle of the architecture, and will not be affected by non-technical factors such as personnel changes and experience, making the optimization and governance of the architecture more objective and reliable.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to a software architecture optimization method, device and storage medium. Background Art

[0002] With the continuous development of Internet technology, the traditional monolithic application architecture model can no longer meet the explosive growth of network access traffic. The distributed microservice architecture with higher throughput solves the problems of low throughput of monolithic application architecture, overly large single applications, and large interference between team work.

[0003] In order to ensure that the software system can maintain continuous and stable operation and update capabilities as the complexity of the software architecture continues to increase, there is an urgent need for optimization methods that can adjust the software architecture more quickly and objectively. Summary of the Invention

[0004] In order to solve the problems of slow optimization speed and low capability in the existing technology, the present invention provides a software architecture optimization method, device and storage medium, which have the characteristics of stronger optimization capability, faster speed and no reliance on manual experience.

[0005] A software architecture optimization method provided according to a specific embodiment of the present invention includes:

[0006] Based on the call relationship between each service component and other service components in the distributed architecture, a static call relationship network is constructed;

[0007] Build the first bipartite network based on the code commit records of the code repository;

[0008] Performing a single-mode mapping on the first bipartite network toward the developer, thereby obtaining a team division of labor structure representing the collaborative relationship between the developers;

[0009] Performing single-mode mapping on the first bipartite network toward the code base to obtain a service linkage modification relationship network representing modification relationships between services;

[0010] Building a second bipartite network between the developers and the communication mode corresponding to the communication information based on the communication information between the developers;

[0011] Performing single-mode mapping on the second bipartite network toward the developer to obtain a communication structure for characterizing the closeness of communication between the developers;

[0012] Generate reference information for architecture optimization, which is the basis for software architecture optimization. The reference information at least includes: the static call relationship network, the service linkage modification relationship network, the team division of labor structure, and the communication structure.

[0013] Furthermore, the reference information further includes: a dynamic call relationship network, and the construction process of the dynamic call relationship network includes:

[0014] Obtain call chain tracing data when the distributed architecture is running;

[0015] A dynamic call relationship network of the service component at runtime is constructed based on the call chain tracking data.

[0016] Furthermore, the static call relationship network is constructed based on the call relationship between each service component and other service components in the distributed architecture, including:

[0017] Construct a syntax tree for the source code of the distributed architecture;

[0018] Parsing the syntax tree to obtain the interface resources provided by the service component and the calling relationship with other service components;

[0019] The interface resources of each service component are connected to other service components through the calling relationship to form the static calling relationship network.

[0020] Furthermore, the constructing of the dynamic call relationship network of the service component based on the call chain tracing data includes:

[0021] Determine the type of trace tag in the call chain trace data;

[0022] determining a caller and a callee of a call relationship based on the type of the tracking tag;

[0023] The caller and the callee are taken as nodes, the tracking tag is taken as an association relationship, and the identifier of the corresponding call chain tracking data is taken as an attribute of the association relationship to form a call relationship graph.

[0024] Furthermore, the constructing of the dynamic call relationship network of the service component based on the call chain tracing data further includes:

[0025] Aggregate the call chains involved in implementing microservice functions. If the identifiers of the tracking data of two call chains are different, but they both have the same microservice participating nodes and the calling order of the participating nodes is the same, then merge the two call chains into one path.

[0026] Furthermore, the first bipartite network is single-mode mapped toward the developer to obtain a team division structure representing the collaborative relationship between the developers, including:

[0027] If the first bipartite network is a connected graph, performing a single-mode mapping on the obtained connected graph in the direction of the developer to obtain a single-mode mapping graph of the connected graph;

[0028] If the first bipartite network is a non-connected graph, all subgraphs of the non-connected graph are obtained, and a single-mode mapping in the developer direction is performed on each subgraph;

[0029] Merging the unimodal mapping graphs generated by the non-connected subgraphs to obtain the unimodal mapping graph of the non-connected graph;

[0030] The single-mode mapping graph of the connected graph and the single-mode mapping graph of the disconnected graph are clustered based on a preset community discovery algorithm to obtain the team division of labor structure.

[0031] Furthermore, the reference information also includes: similarities between the static call relationship network, the service linkage modification relationship network, the team division of labor structure, and the communication structure.

[0032] A software architecture optimization device provided according to a specific embodiment of the present invention includes:

[0033] Static call relationship network module, which is used to build a static call relationship network based on the call relationship between each service component and other service components in the distributed architecture;

[0034] A first bipartite network construction module, used to construct a first bipartite network based on the code commit records of the code library;

[0035] A team division structure module is used to perform single-mode mapping on the first bipartite network toward the developer to obtain a team division structure that represents the collaborative relationship between the developers;

[0036] A service linkage modification relationship network module is used to perform single-mode mapping on the first bipartite network toward the code base to obtain a service linkage modification relationship network representing the modification relationship between services;

[0037] A second bipartite network construction module is configured to construct, based on the communication information between the developers, a communication method corresponding to the communication information and a second bipartite network between the developers;

[0038] a communication structure module, configured to perform single-mode mapping on the second bipartite network toward the developer to obtain a communication structure for representing the interaction mode between the developers; and

[0039] The reference information generation module is used to generate reference information for architecture optimization. The reference information is the basis for software architecture optimization. The reference information at least includes: the static call relationship network, the service linkage modification relationship network, the team division structure and the communication structure.

[0040] Furthermore, the software architecture optimization device further includes:

[0041] The dynamic call relationship network module is used to build a dynamic call relationship network of the service component based on the call chain tracking data during the runtime of the distributed architecture.

[0042] According to a specific embodiment of the present invention, a storage medium is provided, on which a computer program is stored. It is characterized in that when the computer program is executed by a processor, each step of the software architecture optimization method described above is implemented.

[0043] The software architecture optimization method provided by the present invention starts from the entire process of software architecture from development to operation, and constructs a static call relationship network based on the call relationship between each service component and other service components in the distributed architecture. A first bipartite network is constructed based on the code submission record of the code base, and then the first bipartite network is single-mode mapped in the direction of the developer to obtain a team division structure that characterizes the collaborative relationship between the developers. The first bipartite network is single-mode mapped in the direction of the code base to obtain a service linkage modification relationship network that characterizes the modification relationship between the services. Then, based on the communication information between the developers, a communication method corresponding to the communication information and a second bipartite network between the developers are constructed. The second bipartite network is single-mode mapped in the direction of the developer to obtain a communication structure that characterizes the closeness of communication between the developers. Finally, the static call relationship network, the service linkage modification relationship network, the team division structure and the communication structure are used as the basis for software architecture optimization to optimize the software architecture. The software architecture optimization method provided by the present invention constructs a topological map of the software architecture itself based on multi-dimensional data sources and graph theory modeling. Compared with traditional architecture governance, it is more comprehensive and reliable. Moreover, because it models the data generated by the architecture itself, modeling and governance can be performed throughout the entire life cycle of the architecture, and will not be affected by non-technical factors such as personnel changes and experience, making the optimization and governance of the architecture more objective and reliable. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0045] Figure 1 is a flowchart of a software architecture optimization method provided according to an exemplary embodiment;

[0046] Figure 2 is a diagram of a construction process of a dynamic call relationship network provided according to an exemplary embodiment;

[0047] Figure 3 is a diagram of a construction process of a static call relationship network provided according to an exemplary embodiment;

[0048] Figure 4 is another specific construction process diagram of a dynamic call relationship network provided according to an exemplary embodiment;

[0049] Figure 5 is a diagram of a process of constructing a team division of labor structure according to an exemplary embodiment;

[0050] Figure 6 is a diagram of a construction process of a communication structure provided according to an exemplary embodiment;

[0051] Figure 7 It is a structural diagram of a software architecture optimization device provided according to an exemplary embodiment. DETAILED DESCRIPTION

[0052] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0053] Reference Figure 1 As shown, an embodiment of the present invention provides a software architecture optimization method, which may include the following steps:

[0054] 101. Based on the calling relationship between each service component and other service components in the distributed architecture, a static calling relationship network is constructed.

[0055] The static call network model models the software architecture from the perspective of the dependencies formed by code calls. The primary data sources for this model are the source code of all code repositories within the distributed architecture. The code within the code repositories complies with code specifications at the interface and external call layers, making it easier to parse. By constructing syntax trees for the interface exposure and external call layers within the code, we determine the resources (connection interfaces) exposed by each service component and the dependencies each service component creates on other service components through calls. This process is repeated for each service component in the distributed architecture, connecting them to form a static call network based on interface calls. By extracting the service density of modifications from development commit records, we can identify the closely connected relationships that emerge during actual requirement implementation. By projecting the resulting bipartite network of developers onto the service components, we can form a service aggregation interface based on the requirement implementation perspective. This forms a static call relationship network that represents the static structure of the distributed architecture. By modeling the code level of the software architecture, the architecture is analyzed from the perspective of code structure. It does not rely on the operating environment and operating data, and can be modeled at the code level. As long as a call relationship change occurs at the code level, it can be reflected in the static call relationship network.

[0056] 102. Build the first bipartite network based on the code commit records of the code library.

[0057] Software system development teams are typically composed of members with diverse roles and skills. When software requirements change, task orchestration or division of labor can create smaller, more cohesive groups within the team. This refers to the interdependencies and constraints between different combinations of team members at the system development level. Using the code commit records of all developers on the team, we can build a topological structure between developers and code repositories. This bipartite network consists of only two types of nodes: one representing developers and the other representing code repositories. Associations exist only between different types of nodes.

[0058] 103. Perform single-mode mapping on the first bipartite network toward the developer to obtain a team division structure that represents the collaborative relationship between the developers.

[0059] Projecting the resulting bipartite network onto the developers in the developer direction yields an undirected graph of the codebase relative to the developers. Based on the graph's basic eigenvalues, such as degree and degree distribution, operational relationships within the codebase can be identified. This can be used to help team managers divide and collaborate on codebase operations.

[0060] 104. Perform single-mode mapping on the first bipartite network toward the code base to obtain a service linkage modification relationship network representing the modification relationship between services.

[0061] Projecting the resulting bipartite network onto the developers in the direction of code submissions yields an undirected graph of developers relative to code submitters. Based on the graph's basic eigenvalues, such as degree and degree distribution, the importance of developers can be determined. This can be used to help team managers redefine team structures and adjust division of labor.

[0062] 105. Based on the communication information between developers, a communication method corresponding to the communication information and a second bipartite network between developers are constructed.

[0063] The communication efficiency of a software development team largely determines the timeliness of its work. For developers, meetings, emails, and instant messaging, outside of coding, take up the vast majority of their time. Extracting data that reflects communication information and structure allows for a visual analysis of the team's communication structure. This helps determine the team's communication structure.

[0064] 106. Perform single-mode mapping on the second bipartite network toward the developer to obtain a communication structure for characterizing the closeness of communication between the developers.

[0065] By projecting the data in the direction of the team members involved in the development, we can get a schematic diagram that represents the communication relationship between the team members. By applying the clustering algorithm to the schematic diagram, we can get groups related to the work content, which can assist managers in managing the small groups formed.

[0066] 107. Generate reference information for architecture optimization. Reference information is the basis for software architecture optimization. Reference information at least includes: static call relationship network, service linkage modification relationship network, team division of labor structure and communication structure.

[0067] Using this reference information as a guide, the architectural characteristics of the software architecture, as represented by the properties of the four graph structures, enable more objective and scientific management of the software architecture. In specific implementations, this can be based on Conway's Law and Conway's Inverse Law. Inconsistencies in the boundaries between a software system's team structure, communication structure, and the software's static architecture lead to increased ineffective communication and information transfer errors. Therefore, software optimization can be achieved by measuring the similarity of the four topological structures. Referring to the basic theory of graph isomorphism, similarity can be determined by comparing the number of nodes, node in-degree, and other factors within the four topological structures. For example, by judging whether the number of clustered topological structures is consistent; whether the clustering of team structure and the clustering of communication structure, and whether the clustering of team structure and the clustering of communication structure contain the same nodes representing the submitter; the clustering of team structure and the clustering of software architecture, and whether there is a correspondence between the clustering of team structure and the clustering of software architecture. For example, the team structure is divided into three clusters A, B, and C, and the static architecture of the software architecture is also divided into three clusters D, E, and F. If the code base that A is responsible for happens to appear in D, then the authority and responsibility relationship is satisfied. When the three clusters correspond to each other, the structural similarity is high, which means that the software architecture is more reasonable.

[0068] The software architecture optimization method provided by the present invention solves the problems of traditional architecture's strong reliance on individual ability and lack of unified architectural design principles and methods by performing graph-theoretic modeling, analysis, and visualization of the code structure and the data generated during the research and development process. It also provides a more objective and scientific judgment of the architecture's excellent indicators, and makes the optimization of the software architecture more reasonable and accurate.

[0069] In order to further optimize the technical solution, in another specific embodiment of the present invention, the reference information also includes: dynamic call relationship network, reference Figure 2 As shown, the process of constructing a dynamic call relationship network may include the following steps:

[0070] 201. Obtain call chain tracing data during the runtime of the distributed architecture.

[0071] 202. Build a dynamic call relationship network of service components based on call chain tracking data.

[0072] Among them, reference Figure 4 As shown, building a dynamic call relationship network of service components based on call chain tracing data may include the following steps:

[0073] 401. Determine the type of the tracing tag in the call chain tracing data.

[0074] 402. Determine the caller and the callee of the call relationship based on the type of the tracing tag.

[0075] 403. A call relationship graph is constructed by taking the caller and the callee as nodes, the tracking tag as the association relationship, and the identifier of the corresponding call chain tracking data as an attribute of the association relationship.

[0076] Among them, the call chains involved in implementing the microservice function are aggregated. If the identifiers of the tracking data of two call chains are different, but they both have the same microservice participating nodes and the calling order of the participating nodes is the same, the two call chains are merged into one path.

[0077] Specifically, the dynamic call relationship network diagram of a software architecture is a distributed component relationship diagram formed by call chain tracing data collected during the software system's runtime. The most common way to obtain call chain tracing data for distributed architectures is through the output of the Jaeger tool, whose data format complies with the OpenTracing protocol. First, based on the information recorded in each span (tracing tag) in the call chain tracing data, the tag type is determined, such as database query, HTTP call, asynchronous call, RPC call, etc. Then, based on the different tag types, the caller and callee of the call relationship are determined. Finally, the caller and callee are mapped into a dynamic call relationship network using the caller and callee as nodes, the corresponding tags as associations, and the corresponding traceids (tracing identifiers) as attributes on the relationships.

[0078] The node attributes in the network diagram are supplemented based on tag information such as core fields, instance counts, and instance IP addresses from the logs. References between call relationships are constructed using the reference information carried by each tag. For example, if SpanB carries the reference information ChildOf: SpanA, a SpanB.upStream: SpanA relationship is constructed, mapping the topology into a topology of associations.

[0079] The call relationships between nodes are aggregated to form a call chain. For any two requests with different tracking identifiers, if they have exactly the same microservice participating nodes and the same call sequence between microservices, the two call relationships are considered to belong to the same call chain.

[0080] Specifically, for each call in the system, only the core call sequence number, caller, and callee are retained to build a call sequence model. The call sequence model can be described as:

[0081] <Calling order>: (caller), (callee);

[0082] Create a model pool to store all call sequence models. The model pool is a hash key-value dictionary with the model string as the key and the model specific information as the value. Use the string for matching search. If the corresponding model does not exist in the model pool, add a new model key-value pair to the model pool, otherwise merge the models.

[0083] If the call sequence models constructed by any two call links are exactly the same, they are considered to belong to the same call aggregation and are merged in the following order: merge the call links, increase the call count of the call link as a weight, and add the tracking identifier of the original data as a reference. This is done until all the calls are processed. Then, with the starting point as the caller and the end point as the callee, the thickness of the connecting line between the caller and the callee represents the number of calls (the thicker the line, the more calls), and the two are connected to form a dynamic call relationship network diagram. The architecture can then be optimized based on the indicators of the diagram, where:

[0084] Degree: This parameter describes the most important node parameter in the network. The higher the node's degree, the more important its position in the architecture. For service nodes of different degrees, combined with other local metrics, all distributed services appearing in the network are classified and differentiated operations and maintenance strategies and architecture governance plans are developed. Nodes can also be rationally split to reduce the degree of services, thereby eliminating architectural bottlenecks.

[0085] Degree distribution: Degree distribution can be used to define the characteristics of a network. Degree distribution characterizes the connectivity, reuse, and complexity of nodes in the network, and can also be used to measure the uneven structure of the system.

[0086] Modularity: Evaluates the degree of structure of clustering algorithms.

[0087] Edge Count: A summary of the number of edges in a graph network.

[0088] Average path length: The effective size of a graph network. This is used to evaluate and optimize system message passing, assess and control inter-object communication costs, and improve system responsiveness. A network with a very long average path length indicates excessive call depth in a distributed architecture. Long links can lead to excessively long response times, and each node on a link can potentially affect the stability of the architecture. Adjustments to the network structure can be made to reduce path length.

[0089] Centrality: reflects the relative importance of each node in the network.

[0090] Betweenness: The importance of being "passed." Betweenness can analyze the impact of the deletion or failure of any component and its relationships on the entire system, providing a quantitative basis for identifying single-point bottlenecks in the system and guiding improvements. For networks with highly variable node load distribution, the bottleneck restricting stability is the node's maximum betweenness.

[0091] For service nodes with large betweenness, the betweenness value of core nodes can be reduced by splitting services and transferring responsibilities to achieve global optimization.

[0092] Clustering coefficient: How "tight" the network is. It reflects the degree of cohesion of different components in the system and the tendency of the system to be organized in layers (hierarchy).

[0093] Degree correlation: In real graph networks, the degree of a node is correlated with the degrees of its adjacent nodes. This is used to determine whether the network structure is homogeneous or heterogeneous.

[0094] Connectivity: used to evaluate the connectivity of a network. The greater the connectivity, the better the connectivity.

[0095] The above indicators can be used to accurately measure the dynamic structural performance of the software architecture, divide business boundaries, and be used for subsequent structural comparison of multiple diagrams for architecture governance.

[0096] As a feasible implementation of the above embodiment, refer to Figure 3 The construction process of the static call relationship network shown may include the following steps:

[0097] 301. Construct a syntax tree for the source code of the distributed architecture.

[0098] Parse the input code file list to obtain Java code, convert the code into a DST syntax tree, identify the code in the tree structure that provides external interfaces and calls third-party service interfaces, then find the service address as the service identifier in the obtained Class class annotation, find the caller domain object, establish an external call correspondence relationship model, and write the external call correspondence relationship model into Neo4j (graph database).

[0099] 302. Parse the syntax tree to obtain the interface resources provided by the service component and the calling relationship with other service components.

[0100] The above-identified codes are associated with each other in the graphic database through unique identifiers.

[0101] 303. Connect the interface resources of each service component with other service components through call relationships to form a static call relationship network.

[0102] The service components are connected through unique identifiers to obtain a network diagram of the calling relationship.

[0103] In specific implementations, the data source for the static call relationship network is primarily code submission records. Submission records must at least include the submitter's name, email address, time, and the submitted codebase. All code submission records are segmented according to time windows. High-frequency submissions can be set as time windows in days. Because developers need to submit between different services, the implicit knowledge they carry contributes to the complexity of the system and also forms relationships between subsystems. With services and developers as nodes, a relationship representing the submission is constructed from the developer to the codebase based on the submission record information. Development teams working simultaneously on multiple services within a distributed architecture form connections between projects. The constructed network, consisting of both developer and service nodes—the bipartite network—is projected onto the service node type to obtain an association graph based on modification relationships.

[0104] Optimization based on the static call relationship network mainly includes:

[0105] Service scope: This describes the specific resources exposed by each service component or the functionality provided through its interfaces. By analyzing the service scope of each service node, we can identify overlapping service scopes between service nodes and eliminate these overlaps. This ensures that each service node has a highly cohesive service scope that doesn't overlap with other nodes, improving architectural cohesion and reducing the need for "shotgun" code modifications when new requirements are added.

[0106] Degree of coupling between services: By analyzing the number of API calls between services, we can determine the coupling relationship between different microservices to a certain extent and identify the closely related service node groups. At this time, we can consider both business and technical aspects.

[0107] Service merging: By merging services, the architecture call structure can be simplified and the coupling between services can be reduced.

[0108] Functional boundaries: Extract service nodes from the resulting service component dependency network and filter out resource nodes. Apply a clustering algorithm to this new network of service component nodes to form community divisions. This determines the boundaries of the static model. Different operations and development approaches can be adopted for different communities. Furthermore, specific interaction strategies can be specified within the boundaries between communities to standardize communication patterns.

[0109] Service degree: The importance of the service in the architecture. The higher the service degree, the more important the service is in the architecture.

[0110] For services with high degrees, we can further analyze the reasons and split the nodes if business and technology allow.

[0111] Reduce the degree of service nodes to eliminate architectural bottlenecks; for service nodes that cannot be split, specify testing strategies to ensure the high availability of the node in the architecture.

[0112] Reference Figure 5 As shown, the process of performing single-mode mapping on the first bipartite network toward the developer direction to obtain a team division structure representing the collaborative relationship between developers may include the following steps:

[0113] 501. If the first bipartite network is a connected graph, single-mode mapping is performed on the obtained connected graph in the direction of the developer to obtain a single-mode mapping graph of the connected graph.

[0114] 502. If the first bipartite network is a non-connected graph, obtain all subgraphs of the non-connected graph, and perform single-mode mapping in the developer direction on each subgraph.

[0115] 503. Merge the unimodal mapping graphs generated by the non-connected subgraphs to obtain a unimodal mapping graph of the non-connected graph.

[0116] 504. Clustering the single-mode mapping graph of the connected graph and the single-mode mapping graph of the disconnected graph based on a preset community discovery algorithm to obtain a team division of labor structure.

[0117] Specifically, after obtaining a CSV file of code commit records, the data is split according to the configured iteration period, and an array is prepared for each iteration to store them. Data with a code commit date less than the configured end period is processed and its position in the iteration is calculated. The target code repository information and developer name are then extracted. A node representing the developer and a code repository node are created in the corresponding positions of the array, along with the commit relationship between the two nodes. A bisection network and a connected graph are then determined for the graph array. All subgraphs of the disconnected graph are obtained, and all subgraphs are traversed, performing a single-mode mapping on each subgraph. The single-mode mapping graphs generated by the disconnected subgraphs are then merged. Finally, all single-mode mapping graphs in the graph array are merged, and the Louvain algorithm is applied to form clustering results for developers and code repositories, respectively. The degree, average degree, and cumulative degree distribution of the developer and code repository graphs are calculated.

[0118] The graph formed in the projected developer direction is an undirected graph. The relationships between nodes representing developers have no directional meaning, making the entire graph undirected. A modularity-based community discovery algorithm from graph theory is used on this undirected graph. This algorithm has the advantage of quickly partitioning large networks into communities of varying granularity without requiring a specific number of communities. The maximum modularity value within the computing power is returned. Modularity values ​​range from [-0.5 to 1]. Modularity values ​​between 0.3 and 0.7 indicate a strong team structure with clear division of labor.

[0119] Based on an undirected graph of developer relationships, we can calculate the graph's basic eigenvalues. We primarily focus on degree and degree distribution. The higher a developer's degree, the more important they are considered to be within the team. Importance can mean two things: first, they shoulder core responsibilities and are the most capable members of the team. Second, their work is fragmented and unfocused, with a high percentage of miscellaneous tasks. This scenario is often accompanied by a low modularity value in the community discovery algorithm. This can be used to help team managers redefine team structure and adjust division of labor.

[0120] Reference Figure 6 As shown, in some specific embodiments of the present invention, performing a single-mode mapping on the second bipartite network toward the developer direction to obtain a communication structure for characterizing the closeness of communication between developers may include the following steps:

[0121] 601. If the second bipartite network is a connected graph, perform single-mode mapping on the developers to obtain a communication structure.

[0122] 602. If the second bipartite network is a non-connected graph, perform single-mode mapping on the developers in the subgraph of the non-connected graph.

[0123] 603. Merge the unimodal mapping graphs of the subgraphs of the non-connected graph, and cluster the merged unimodal mapping graphs based on a preset community discovery algorithm to obtain a communication structure.

[0124] Specifically, taking meetings attended as an example, we extract the number of records from a CSV file containing meeting information, extract the current meeting topic, date, and attendees, treat the attendees as an array, create nodes named after the topic and date, traverse the attendee array, create attendee nodes, and determine the relationships between nodes based on the topic. If the resulting graph is bipartite or connected, we obtain all subgraphs of the disconnected graph, traverse all subgraphs, and perform a single-mode mapping of the attendees on each subgraph. The disconnected subgraphs are then merged to generate a single-mode mapping graph. The Louvain algorithm is then applied for clustering to determine the communication structure.

[0125] Based on the same design ideas Figure 7 As shown, an embodiment of the present invention further provides a software architecture optimization device, which can execute each step of the software architecture optimization method described in the above embodiment, and the device may include the following modules:

[0126] The static call relationship network module 701 is used to build a static call relationship network based on the call relationship between each service component and other service components in the distributed architecture.

[0127] The first bipartite network module 702 is configured to construct a first bipartite network based on the code submission records of the code repository.

[0128] The team division structure module 703 is used to perform single-mode mapping on the first bipartite network toward the developer, so as to obtain a team division structure representing the collaborative relationship between the developers.

[0129] The service linkage modification relationship network module 704 is configured to perform single-mode mapping on the first bipartite network toward the code base to obtain a service linkage modification relationship network representing the modification relationship between services.

[0130] The second bipartite network module 705 is configured to construct a communication method corresponding to the communication information and a second bipartite network between the developers based on the communication information between the developers.

[0131] The communication structure module 706 is used to perform single-mode mapping on the second bipartite network toward the developer to obtain a communication structure for characterizing the closeness of communication between developers.

[0132] Reference information generation module 707 is used to generate reference information for architecture optimization, wherein the reference information is the basis for software architecture optimization, and the reference information at least includes: static call relationship network, service linkage modification relationship network, team division structure and communication structure.

[0133] Dynamic call relationship network module 708, used to obtain call chain tracking data when the distributed architecture is running;

[0134] And build a dynamic call relationship network of the service components based on the call chain tracking data.

[0135] When the software architecture optimization device is running, it has the same beneficial effects as the above-mentioned software optimization method. Its specific implementation method can refer to the software optimization method described in the above embodiment, and the present invention will not repeat it here.

[0136] An embodiment of the present invention further provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the software architecture optimization method described in the above embodiment are implemented.

[0137] The software architecture optimization method, device, and storage medium provided by the aforementioned embodiments of the present invention provide more comprehensive and extensive software architecture optimization and governance than traditional architecture governance, and can assist in solving problem domains that traditional architecture governance cannot cover, such as architecture simulation and intelligent architecture prediction. Furthermore, because the data source required for processing by the present invention originates from the software development process itself, architecture modeling, diagnosis, and governance can be performed throughout the entire software iteration lifecycle, unaffected by non-technical factors such as personnel changes, personnel experience, and team relationships.

[0138] For simplicity of description, the aforementioned method embodiments are described as a series of actions. However, those skilled in the art should be aware that the present invention is not limited by the order of the actions described, as certain steps can be performed in other orders or simultaneously according to the present invention. Furthermore, those skilled in the art should also be aware that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily required for the present invention.

[0139] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similarities between the various embodiments can be referred to in conjunction with each other. For device embodiments, since they are generally similar to method embodiments, their description is relatively simple, and for relevant details, reference can be made to the description of the method embodiments.

[0140] The steps in the methods of the various embodiments of the present invention can be adjusted in sequence, combined, and deleted according to actual needs, and the technical features recorded in the various embodiments can be replaced or combined.

[0141] The modules and submodules in the devices and terminals of various embodiments of the present invention may be combined, divided, or deleted according to actual needs.

[0142] In the several embodiments provided herein, it should be understood that the disclosed terminals, devices, and methods can be implemented in other ways. For example, the terminal embodiments described above are merely illustrative. For example, the division of modules or submodules is merely a logical functional division. In actual implementation, other division methods may be used, such as combining or integrating multiple submodules or modules into another module, or omitting or not implementing certain features. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or modules via some interface, which may be electrical, mechanical, or other forms.

[0143] The modules or submodules described as separate components may or may not be physically separate, and the components of the modules or submodules may or may not be physical modules or submodules, that is, they may be located in one place or distributed across multiple network modules or submodules. Some or all of the modules or submodules may be selected to achieve the purpose of this embodiment according to actual needs.

[0144] In addition, the functional modules or submodules in the various embodiments of the present invention may be integrated into a single processing module, or each module or submodule may exist physically separately, or two or more modules or submodules may be integrated into a single module. The aforementioned integrated modules or submodules may be implemented in the form of hardware or software functional modules or submodules.

[0145] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0146] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, software units executed by a processor, or a combination of the two. The software units may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0147] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0148] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A software architecture optimization method, characterized in that: include: Based on the calling relationship between each service component and other service components in the distributed architecture, a static calling relationship network is constructed, including: constructing a syntax tree for the source code of the distributed architecture; parsing the syntax tree to obtain the interface resources provided by the service component and the calling relationship with other service components; connecting the interface resources of each service component with other service components through the calling relationship to form the static calling relationship network; Build the first bipartite network based on the code commit records of the code repository; The first bipartite network is single-mode mapped in the direction of developers to obtain a team division of labor structure that characterizes the collaborative relationship between developers, including: if the first bipartite network is a connected graph, the obtained connected graph is single-mode mapped in the direction of the developers to obtain a single-mode mapping graph of the connected graph; if the first bipartite network is a non-connected graph, all subgraphs of the non-connected graph are obtained, and each subgraph is single-mode mapped in the direction of the developers; the single-mode mapping graphs generated by the non-connected subgraphs are merged to obtain a single-mode mapping graph of the non-connected graph; the single-mode mapping graph of the connected graph and the single-mode mapping graph of the non-connected graph are clustered based on a preset community discovery algorithm to obtain the team division of labor structure; Performing single-mode mapping on the first bipartite network in the direction of the code base to obtain a service linkage modification relationship network representing the modification relationship between services; Building a second bipartite network between the developers and the communication mode corresponding to the communication information based on the communication information between the developers; Performing single-mode mapping on the second bipartite network in the direction of the developer to obtain a communication structure for characterizing the closeness of communication between the developers; Generate reference information for architecture optimization, which is the basis for software architecture optimization. The reference information at least includes: the static call relationship network, the service linkage modification relationship network, the team division of labor structure and the communication structure; wherein the optimization of the static call relationship network includes: optimization of service scope, coupling degree between services, service merging, service degree and reducing the degree of service nodes.

2. The method according to claim 1, characterized in that: The reference information also includes: a dynamic call relationship network, and the construction process of the dynamic call relationship network includes: Get call chain tracing data when the distributed architecture is running; A dynamic call relationship network of the service component at runtime is constructed based on the call chain tracking data.

3. The method according to claim 2, characterized in that The step of constructing the dynamic call relationship network of the service component based on the call chain tracking data includes: Determine the type of trace tag in the call chain trace data; Determine the caller and the callee of the call relationship based on the type of the tracking tag; The caller and the callee are taken as nodes, the tracking tags are taken as association relationships, and the identifiers of the corresponding call chain tracking data are taken as attributes of the association relationships to form a call relationship graph.

4. The method according to claim 3, characterized in that: The step of constructing the dynamic call relationship network of the service component based on the call chain tracking data further includes: Aggregate the call chains involved in implementing the microservice function. If the identifiers of the tracking data of two call chains are different, but they both have the same microservice participating nodes and the calling order of the participating nodes is the same, then merge the two call chains into one path.

5. The method according to any one of claims 1 to 3, characterized in that: The reference information also includes: the similarity between the static call relationship network, the service linkage modification relationship network, the team division of labor structure and the communication structure.

6. A software architecture optimization device, characterized in that: include: The static call relationship network module is used to construct a static call relationship network based on the call relationship between each service component and other service components in the distributed architecture, including: constructing a syntax tree for the source code of the distributed architecture; parsing the syntax tree to obtain the interface resources provided by the service component and the call relationship with other service components; connecting the interface resources of each service component with other service components through the call relationship to form the static call relationship network; A first bipartite network construction module, used to construct a first bipartite network based on the code submission record of the code library; A team division of labor structure module is used to perform single-mode mapping on the first bipartite network in the direction of developers to obtain a team division of labor structure that characterizes the collaborative relationship between developers, including: if the first bipartite network is a connected graph, then single-mode mapping is performed on the obtained connected graph in the direction of the developers to obtain a single-mode mapping graph of the connected graph; if the first bipartite network is a non-connected graph, then all subgraphs of the non-connected graph are obtained, and single-mode mapping is performed on each subgraph in the direction of the developers; the single-mode mapping graphs generated by the non-connected subgraphs are merged to obtain a single-mode mapping graph of the non-connected graph; the single-mode mapping graph of the connected graph and the single-mode mapping graph of the non-connected graph are clustered based on a preset community discovery algorithm to obtain the team division of labor structure; A service linkage modification relationship network module, used for single-mode mapping the first bisection network to the code base direction to obtain a service linkage modification relationship network representing the modification relationship between each service; A second bipartite network construction module, used for constructing a communication method corresponding to the communication information and a second bipartite network between the developers based on the communication information between the developers; a communication structure module, used for performing single-mode mapping on the second bipartite network toward the developer to obtain a communication structure for characterizing the interaction mode between the developers; and A reference information generation module is used to generate reference information for architecture optimization. The reference information is the basis for software architecture optimization. The reference information at least includes: the static call relationship network, the service linkage modification relationship network, the team division of labor structure and the communication structure; wherein the optimization of the static call relationship network includes: optimization of service scope, coupling degree between services, service merging, service degree and reducing the degree of service nodes.

7. The device according to claim 6, characterized in that Also includes: The dynamic call relationship network module is used to build the dynamic call relationship network of the service component based on the call chain tracking data when the distributed architecture is running.

8. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, each step of the software architecture optimization method according to any one of claims 1 to 5 is implemented.

Images