Object architecture restoration method and device, electronic equipment and storage medium

Abstract

Embodiments of the invention disclose an object architecture restoration method and apparatus, an electronic device and a storage medium. The method comprises the steps of determining a current preset time range; obtaining target code submission log data of the object in the current preset time range; performing structured processing on the target code submission log data to obtain structured target code submission log data; performing classification processing on the structured target code submission log data to obtain a modular classification result of the target code submission log data; based on the modular classification result, generating a target modular log file corresponding to the target code submission log data; and obtaining a target architecture in the current preset time range according to the target modular log file. According to the architecture restoration method provided by the invention, the modular log file is generated by performing module classification processing on the log data, so that the architecture is restored, the evolution process of the software architecture is understood, and the quality of the software architecture is improved.

Description

Technical Field

[0001] This invention relates to the field of software development, and in particular to a method, apparatus, electronic device, and storage medium for object architecture reconstruction. Background Technology

[0002] As hardware computing power continues to increase, software becomes increasingly complex and massive. This is especially true in the automotive field, where assisted driving and autonomous driving are constantly being introduced. The amount of software code on in-vehicle system-on-a-chip (SOC) and microcontroller unit (MCU) is increasing, and their architecture is becoming extremely complex. As time goes by and versions are iterated, the software architecture deteriorates and maintainability decreases.

[0003] Currently, developers typically use architecture reconstruction methods by studying and analyzing code and documentation to try to understand and reconstruct the code's architecture, thereby correcting and improving the software architecture and reducing maintenance and time costs. However, documentation reliance has significant limitations. In real-world development scenarios, many projects suffer from missing documentation, documentation updates lagging behind code iterations, or incomplete documentation. When effective documentation is lacking, developers can only directly sift through the massive source code to understand the architectural logic, which is not only time-consuming and labor-intensive but also prone to errors in understanding the overall architecture due to code details. Furthermore, it is impossible to trace the architectural evolution; traditional methods can only analyze the software architecture state at the current point in time and cannot reconstruct the form and changes of the architecture at different historical stages. Architectural deterioration and defects are often the result of gradual accumulation over long-term iterations. Without understanding the evolutionary process, developers struggle to pinpoint the root cause of architectural problems, leading to limitations in architecture correction and optimization efforts and an inability to fundamentally resolve architectural vulnerabilities.

[0004] Therefore, it is particularly important to develop an architecture reconstruction method, device, electronic device, and storage medium that can help developers reconstruct the architecture, understand the software architecture evolution process, improve the quality of the software architecture, and reduce the development and maintenance costs of objects. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a method, apparatus, electronic device, and storage medium for object architecture reconstruction. By classifying log data into modules and generating modular log files, the architecture can be reconstructed. This addresses the current lack of methods, apparatus, electronic devices, and storage media for object architecture reconstruction that can help developers reconstruct the architecture, understand the software architecture evolution process, improve the quality of the software architecture, and reduce development and maintenance costs.

[0006] The technical solution provided in this application is as follows: On the one hand, this application provides a method for restoring the architecture of an object, the method comprising: Determine the current preset time range; Obtain the target code commit log data of the object within the current preset time range; The target code commit log data is processed into a structured form to obtain structured target code commit log data. The structured target code commit log data is classified to obtain a modular classification result of the target code commit log data; Based on the modular classification results, generate the target modular log file corresponding to the target code commit log data; Based on the target modular log file, the target architecture within the current preset time range is obtained.

[0007] In some optional implementations, the classification process of the structured target code commit log data to obtain a modular classification result of the target code commit log data includes: Obtain sample code commit log data and preset models; The sample code submission log data is processed into a structured form to obtain structured sample code submission log data. The sample code submission log data is input into the preset model for modular classification prediction to obtain the predicted modular classification result. The difference between the predicted modular classification result and the modular classification label corresponding to the sample code submission log data is calculated to obtain the loss data; The parameters of the preset model are adjusted based on the loss data until the preset model converges, thus obtaining a classification model. The structured target code submission log data is input into the classification model to obtain the modular classification result of the target code submission log data.

[0008] In some optional implementations, generating the target modular log file corresponding to the target code commit log data based on the modular classification result includes: The modular classification results are analyzed to obtain the target features of the target code submission log data; Construct a mapping relationship between the target code commit log data and the target features to obtain the target modular log file corresponding to the target code commit log data.

[0009] In some optional implementations, the target features include at least the target class name, target module, and target log content of the target code commit log data; the step of constructing the mapping relationship between the target code commit log data and the target features to obtain the target modular log file corresponding to the target code commit log data includes: Construct a first mapping relationship between the target code commit log data and the target class name; Construct a second mapping relationship between the target code commit log data and the target's home module; Construct a third mapping relationship between the target code commit log data and the target log content; The first mapping relationship, the second mapping relationship, and the third mapping relationship are used as the target modular log file corresponding to the target code commit log data.

[0010] In some optional implementations, obtaining the target architecture within the current preset time range based on the target modular log file includes: Build an architectural feature set; Construct a fourth mapping relationship between the target class name, the target module, and the target log content; The first mapping relationship, the second mapping relationship, the third mapping relationship, and the fourth mapping relationship are added to the architecture feature set to obtain an updated architecture feature set; Based on the updated set of architectural features, the target architecture within the current preset time range is obtained.

[0011] In some alternative implementations, after obtaining the target architecture based on the target modular log file, the method further includes: Define a new preset time range as the current preset time range; Repeat the steps of obtaining the target code commit log data of the object within the current preset time range, and obtaining the target architecture within the current preset time range based on the target modular log file, until the architecture of all time ranges of the object is obtained.

[0012] In some optional implementations, before inputting the sample code submission log data into the preset model for modular classification prediction to obtain the predicted modular classification result, the method further includes: The sample code submission log data is preprocessed to form a data structure that matches the preset model.

[0013] On the other hand, this application provides an object architecture restoration apparatus, the object architecture restoration apparatus comprising: The data collection module is used to determine the current preset time range; and to acquire the target code commit log data of the object within the current preset time range; The data processing module is used to perform structured processing on the target code commit log data to obtain structured target code commit log data. The classification module is used to classify the structured target code submission log data to obtain a modular classification result of the target code submission log data. The architecture restoration module is used to generate a target modular log file corresponding to the target code commit log data based on the modular classification results; and to obtain the target architecture within the current preset time range based on the target modular log file.

[0014] On the other hand, this application provides an electronic device including a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or at least one program is loaded and executed by the processor to implement the architecture restoration method of the object as described in any of the above embodiments.

[0015] On the other hand, this application provides a computer-readable storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to implement the architecture reconstruction method of an object as described in any of the above embodiments.

[0016] The object architecture reconstruction method provided in this application includes: determining a current preset time range; obtaining target code commit log data of the object within the current preset time range; performing structured processing on the target code commit log data to obtain structured target code commit log data; classifying the structured target code commit log data to obtain modular classification results; generating a target modular log file corresponding to the target code commit log data based on the modular classification results; and obtaining the target architecture within the current preset time range based on the target modular log file. By classifying log data into modules and generating modular log files, the architecture can be reconstructed, which can solve the current lack of methods to help developers reconstruct the architecture, understand the software architecture evolution process, improve the quality of software architecture, and reduce development and maintenance costs. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the object architecture reconstruction method proposed according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of an object architecture restoration device according to an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0020] The term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of this application. In the description of this application, it should be understood that the terms "upper," "lower," "top," "bottom," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. Moreover, the terms "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein.

[0021] When a numerical range is disclosed herein, the range is considered continuous and includes the minimum and maximum values ​​of the range, as well as every value between the minimum and maximum values. Furthermore, when the range refers to an integer, it includes every integer between the minimum and maximum values ​​of the range. Additionally, when multiple ranges are provided to describe a feature or characteristic, the ranges may be combined. In other words, unless otherwise specified, all ranges disclosed herein should be understood to include any and all subranges to which they are included. For example, a specified range from “1 to 10” should be considered to include any and all subranges between the minimum value 1 and the maximum value 10. Exemplary subranges of the range 1 to 10 include, but are not limited to, 1 to 6.1, 3.5 to 7.8, 5.5 to 10, etc.

[0022] Current architecture reconstruction methods used by developers suffer from numerous problems, including missing documentation, documentation updates lagging behind code iterations, and incomplete documentation. Furthermore, they cannot trace the evolution of the architecture; traditional methods can only analyze the software architecture state at the current point in time, failing to reconstruct the architecture's form and changes at different historical stages. Therefore, to help developers reconstruct the architecture, understand the software architecture evolution process, improve software architecture quality, and reduce development and maintenance costs, this application provides an object architecture reconstruction method, apparatus, electronic device, and storage medium, which is of paramount importance.

[0023] Please see Figure 1 , Figure 1 This is a flowchart of a traffic light recognition method according to an embodiment of the present invention. In one aspect, this application provides a method for reconstructing the architecture of an object, the method comprising: S101. Determine the current preset time range.

[0024] Optionally, the object is a software system that needs to be reconstructed and analyzed for its architecture. Due to its complex functions and frequent iterations, the evolution of its architecture needs to be traced through log analysis.

[0025] Optionally, the current preset time range is determined based on the software architecture analysis requirements, combined with key nodes or development phases in the software lifecycle. It requires collecting logs at various points in time and selecting time points for architecture reconstruction at certain time intervals to connect and form the architecture evolution process. Therefore, the determination of the current preset time range must prioritize covering key nodes where the software architecture may change, ensuring that log data within this range is available and complete. For example, the current preset time range could be a quarter, a month, etc. Only logs whose submission time falls within this range will be considered target log data; logs whose submission time exceeds this range will be excluded, ensuring that the logs processed subsequently fully match the goals of the current stage of architecture analysis. By determining different current preset time ranges multiple times, target architectures at multiple stages can be obtained, and then connected to form the architecture evolution process.

[0026] If no time range is set and logs from the entire software lifecycle are extracted directly, the efficiency of subsequent structured processing and classification model calculations will be greatly reduced, and data redundancy may even interfere with the analysis results. By determining the current preset time range, the focus can be on logs from a specific stage, reducing data processing pressure, improving analysis efficiency, and avoiding log data overload. At the same time, by setting a time range, it can be ensured that the extracted logs correspond only to code changes in a certain stage, thereby restoring the unique architectural features of that stage.

[0027] S102. Obtain the target code commit log data of the object within the current preset time range.

[0028] Optionally, within the current preset time frame, log data generated by developers when committing code to the software system, recording key information about code changes. According to the application scenario description of the logs in the handover document, this type of data should include basic information to support subsequent architecture analysis, such as the code committer, commit time, path of the changed code file, a summary of the code modifications, and the purpose of the commit. This information is the basis for subsequent structured processing and modular classification, and is also a key data source for reconstructing the architecture.

[0029] Optionally, the target code commit log data can be obtained from Git and SVN, the two code version management platforms corresponding to the software system, to confirm whether the software's code is stored in a Git repository or an SVN repository, ensuring that subsequent log extraction can accurately connect to the data source. Using the version control system's built-in commands or visual tools, all code commit logs within the current preset time range are filtered. The extraction process must ensure the integrity of the log data, avoiding the loss of logs for certain time points due to incorrect command parameters or network issues. Logs related to code format optimization, spelling error correction, etc., that do not affect the architectural structure can be excluded to avoid invalid data increasing the processing pressure later. Invalid logs generated by abnormal operations in the version control system are also excluded, retaining only valid logs generated during the formal development process that are related to changes in the core code of the object.

[0030] S103. Perform structured processing on the target code commit log data to obtain structured target code commit log data.

[0031] Optionally, raw code commit logs are usually described in natural language, and the information format is chaotic. For example, some logs record the code modification path, there are no uniform fields, and they cannot be directly input into the model for classification. Through structured processing, the disordered information can be sorted into fixed fields and the format differences can be eliminated.

[0032] Optionally, the target code commit logs obtained within the current preset time range are first preprocessed to remove invalid data and ensure data quality. Specific cleaning actions may include: deleting empty commit logs without any modification descriptions or changed file paths, as well as invalid commit logs; filtering duplicate logs to exclude duplicate commit logs caused by version control system anomalies; and correcting format errors by standardizing the time format and file path format in the logs to eliminate inconsistencies. Next, a structured field system is defined, breaking down the cleaned log data into fixed fields and supplementing basic identification fields. These may include: commit time (indicating the specific time of code commit), changed file path (indicating the storage path of the modified code file), target class name (indicating the class name corresponding to the changed code), target module (indicating the module to which the changed code belongs), and target log content (indicating the purpose and content overview of the code change). Finally, the cleaned original log information is mapped one by one to the above structured fields. Each original log is transformed into structured target code commit log data containing all the above fields, forming a standardized dataset.

[0033] Through the above structuring process, each structured log contains all defined fields without any missing fields. The data format of the fields must be consistent to ensure that the classification model can directly read the data without additional format conversion. The original unstructured logs are transformed into structured data, ensuring the integrity and availability of the fields in the structured data.

[0034] S104. Classify the structured target code submission log data to obtain a modular classification result of the target code submission log data.

[0035] In an optional embodiment, the step of classifying the structured target code commit log data to obtain a modular classification result of the target code commit log data includes: Obtain sample code commit log data and preset models; The sample code submission log data is processed into a structured form to obtain structured sample code submission log data. The sample code submission log data is input into the preset model for modular classification prediction to obtain the predicted modular classification result. The difference between the predicted modular classification result and the modular classification label corresponding to the sample code submission log data is calculated to obtain the loss data; The parameters of the preset model are adjusted based on the loss data until the preset model converges, thus obtaining a classification model. The structured target code submission log data is input into the classification model to obtain the modular classification result of the target code submission log data.

[0036] In an optional embodiment, before inputting the sample code submission log data into the preset model for modular classification prediction and obtaining the predicted modular classification result, the method further includes: The sample code submission log data is preprocessed to form a data structure that matches the preset model.

[0037] Optionally, the sample data needs to be extracted from the historical code repository of the software to be analyzed. The preset model is an initial deep learning model framework for modular log classification. The model is trained by deep learning classification training. Based on the attributes of the log data, the preset model usually selects an architecture that can process both structured data and text information. The initial model needs to be pre-configured with basic parameters to provide a starting point for subsequent training and optimization.

[0038] Optionally, the acquired raw sample code submission log data is first preprocessed to remove invalid sample code submission log data, ensuring the validity of the sample data. The cleaned sample logs are then transformed into a specific data structure. The final structured sample log data must ensure that each sample has no missing fields, a consistent format, and meets the model input requirements. The adapted sample data is then batch-input into a preset model. The model uses its built-in feature extraction and classification decision logic to predict the modular category of each sample. For example, if the log content of a sample code submission log is the addition of the LiDAR data parsing function to the sensor data processing module, the model predicts its modular classification result as the "new function of the sensor data processing module," forming the predicted modular classification result.

[0039] Optionally, log data for structured sample code should first be labeled with true modular classification labels. These labels must be based on rules defined by established classification standards, such as combining the actual module divisions and change types of the software to form a label system. Labeling should be completed by developers familiar with the software architecture to ensure the authenticity and accuracy of the labels, providing a benchmark reference for error calculation. The difference between the predicted modular classification result and the true label is calculated using a loss function commonly used in classification tasks, yielding the loss value for that sample. The average of the loss values ​​for all samples is then taken as the loss data for the current model training epoch. A larger loss value indicates a greater deviation between the model's prediction and the true classification.

[0040] Optionally, based on the calculated loss data, the parameters of the preset model can be adjusted using the backpropagation algorithm. The parameters are iteratively updated along the direction of loss reduction, gradually lowering the model's prediction error. This process of prediction, loss calculation, and parameter adjustment is repeated until the model meets convergence conditions. For example, the loss data from multiple consecutive training epochs stabilizes at an extremely low level without significant fluctuations; or the model's classification accuracy on the validation set reaches a preset threshold, indicating that the model has a stable modular classification capability, at which point iteration stops. The model at this point is the trained classification model, which can be used for subsequent classification of target logs.

[0041] Optionally, referring to the logic for adapting sample code submission log data, the structured target code submission log data is format-converted to ensure that the target data is completely consistent with the input format of the classification model, avoiding classification errors due to format mismatch. The adapted target data is then input into the trained classification model. The model, through optimized feature extraction and classification logic, quickly outputs modular classification results for each target log. The final output modular classification results must correspond to the actual module system of the software, with each target code submission log data clearly belonging to a specific module and a specific change type, providing a direct basis for subsequent generation of target modular log files and reconstruction of the software architecture.

[0042] The classification model can receive structured target log data in batches and quickly classify the log data through preset feature extraction and classification logic, significantly reducing the time cost of log processing. The model classifies based on modular classification standards learned during the training phase, avoiding classification bias caused by experience differences and fatigue during manual classification, ensuring the objectivity and consistency of classification results. Furthermore, the classification model categorizes target code submission log data by their respective modules, essentially associating scattered code change logs with specific software modules. Developers can quickly locate the code changes of each module within the current preset time range based on this classification result, thereby modularizing the code and providing accurate module-dimensional data for subsequent target architecture construction. In addition, the classification model's results have already organized the logs by module, allowing developers to quickly grasp the core changes and current architecture of each module without having to read the code one by one, significantly shortening the architecture understanding time. Simultaneously, architecture optimization based on the classification results is more targeted, avoiding ineffective development caused by blind refactoring, ultimately reducing overall development and maintenance costs and improving architecture quality.

[0043] S105. Based on the modular classification results, generate the target modular log file corresponding to the target code commit log data.

[0044] In an optional embodiment, generating the target modular log file corresponding to the target code commit log data based on the modular classification result includes: The modular classification results are analyzed to obtain the target features of the target code submission log data; Construct a mapping relationship between the target code commit log data and the target features to obtain the target modular log file corresponding to the target code commit log data.

[0045] Optionally, the target class name can be obtained by associating the modified file path and code modification content in the structured target code commit log data with the modular classification results. The classification results clearly identify the module to which the target belongs. Further, the modified code file within that module can be located, and the modified class name can be identified from the file's code content as a characteristic of the target class name. The target log content can be extracted from the commit description field of the structured target code commit log data, and then supplemented with the change attribute information from the modular classification results. For example, if the commit description in the structured log is "Fixing a brake signal delay issue," and the classification result is "bug fix," then the target log content would be "Driving control module - Fixing brake signal delay issue," preserving the original commit information while supplementing the classified change attributes, providing a complete change background for subsequent architecture analysis. The change scope can also be extracted by combining the modular classification results with the number of changed lines of code in the structured log. This feature can help developers determine the scale of the changes to the architecture.

[0046] In an optional embodiment, the target features include at least the target class name, target module, and target log content of the target code commit log data; the step of constructing the mapping relationship between the target code commit log data and the target features to obtain the target modular log file corresponding to the target code commit log data includes: Construct a first mapping relationship between the target code commit log data and the target class name; Construct a second mapping relationship between the target code commit log data and the target's home module; Construct a third mapping relationship between the target code commit log data and the target log content; The first mapping relationship, the second mapping relationship, and the third mapping relationship are used as the target modular log file corresponding to the target code commit log data.

[0047] Optionally, constructing the mapping relationship involves associating target code commit log data with extracted target features using a fixed format to form a structured, modular target log file that can be directly used for architecture reconstruction. For example, the mapping relationship information can be in the form of a mapping relationship table. Each target code commit log data entry must be associated with all extracted target features; log entries cannot be associated with only a subset of features to ensure the completeness of the mapping relationship and support the multi-dimensional needs of subsequent architecture analysis. Based on the mapping rules, the core information of the target code commit log data is integrated with the target features to construct a structured mapping relationship table. The table structure must cover the key dimensions required for architecture reconstruction. The core information of the target code commit log data can be a unique log ID, serving as a unique identifier to ensure that each log entry is associated with only one set of target features, avoiding duplication or omission.

[0048] Optionally, the above mapping table is output in a preset format to form a target modular log file. A format that is easy for developers to read and easy to import into analysis tools is selected, and the fields in the corresponding table are listed, separated by commas, to ensure that the file can be directly parsed by the subsequent architecture restoration tool. The file name includes the target preset time range and the target module information, which makes it easy for developers to quickly locate the log file of a specific time range and a specific module. After the file is generated, it needs to be verified to ensure that the file data is error-free.

[0049] Optionally, the unique log ID in the structured target code commit log data is used as the primary key for the first mapping relationship. For each log entry, its corresponding structured log data is associated with the unique log ID, and the class name of the changed code file in that log is extracted as the target class name, forming the first mapping relationship. The modular classification result is associated with the unique log ID, and the module name corresponding to that log in the classification result is extracted as the target module, forming the second mapping relationship between the unique log ID and the target module. The commit description field is extracted from the structured log data, and information is supplemented by combining it with the change type of the modular classification result to form the complete target log content, finally establishing the third mapping relationship between the unique log ID and the target log content.

[0050] Optionally, using the unique log ID as the core index, the information of the three types of mapping relationships is merged into a complete log record. Each record contains four core fields: unique log ID, target class name, target module, and target log content, forming structured data.

[0051] Modular classification results represent the correspondence between scattered logs and modules. Target modular log files, through mapping relationships, integrate logs, features, and modules to form a structured architecture analysis dataset, transforming the classification results into usable architecture data. The target module and target class name features directly correspond to the module and class hierarchy of the software architecture. The target log content and change impact scope features reflect the architecture change process. Developers can quickly sort out the composition, class relationships, and changes of each module within the current preset time range based on this file, making it a key data carrier for reconstructing the architecture evolution.

[0052] S106. Based on the target modular log file, obtain the target architecture within the current preset time range.

[0053] In an optional embodiment, obtaining the target architecture within the current preset time range based on the target modular log file includes: Build an architectural feature set; Construct a fourth mapping relationship between the target class name, the target module, and the target log content; The first mapping relationship, the second mapping relationship, the third mapping relationship, and the fourth mapping relationship are added to the architecture feature set to obtain an updated architecture feature set; Based on the updated set of architectural features, the target architecture within the current preset time range is obtained.

[0054] Optionally, the architecture feature set is a data framework used to carry architecture information. It may include: a module basic information dimension, used to record the core module units of the software architecture, including module name and module function description; a class module association dimension, used to record the core code classes under the module, including module name and class name; and a module change dimension, used to record the changes of the module within the current preset time range, including module name, change type, and change impact scope, which is the key basis for judging whether the current architecture is stable. First, all unique target belonging modules are extracted from the target modular log file as the initial module list of the architecture feature set; then, the module function description is filled in for each module to form the initial framework of the architecture feature set. This framework is the basis for subsequent integration of various mapping relationships, ensuring that all architecture information revolves around modules.

[0055] Optionally, the records of the target modular log files are first grouped according to the target module to ensure that the classes and change records under the same module are associated together; within each group, all unique target class names are extracted to identify the core classes contained in the module; for each target class name in each group, all target log contents corresponding to the class are summarized to extract the change information of the class; the above association logic is integrated to form a complete fourth mapping relationship.

[0056] Optionally, the information of the four types of mapping relationships is filled into the corresponding dimensions respectively. The non-repeating target belonging modules and corresponding module function descriptions in the second mapping relationship are added to the module basic information dimension of the architecture feature set. The target class names and class function descriptions in the fourth mapping relationship are added to the class module association dimension of the architecture feature set by module grouping, clarifying the class composition and class function under each module. The change type and change impact scope extracted from the third mapping relationship are added to the module change dimension of the architecture feature set by module grouping, recording the change status of each module. The first mapping relationship is used as the verification basis to ensure that each target class name in the class module association dimension can correspond to a unique target belonging module, avoiding errors in the association between classes and modules, and ensuring the accuracy of the architecture feature set.

[0057] Optionally, based on the updated architectural feature set, relationships are clarified to form a structured architectural description document. The target architecture must clearly indicate the corresponding time range to ensure that it only reflects the architectural state within that time range and avoids confusion with other stages. The information of each module and class in the architecture must be traceable to the updated architectural feature set, and each change state must correspond to a specific record in the target modular log file to ensure the authenticity and verifiability of the architecture. The target architecture should present core information to facilitate developers in quickly judging the rationality of the current architecture and provide a basis for subsequent architecture optimization. The scattered processes of log acquisition, structuring, classification, and generation of modular log files are transformed into a closed loop through the steps of architectural feature set construction, mapping relationship integration, and architecture generation. Ultimately, unstructured log data is transformed into a structured and visualized software architecture, solving the problem that traditional methods cannot reconstruct the current architecture or understand the architectural state.

[0058] In an optional embodiment, after obtaining the target architecture based on the target modular log file, the method further includes: Define a new preset time range as the current preset time range; Repeat the steps of obtaining the target code commit log data of the object within the current preset time range, and obtaining the target architecture within the current preset time range based on the target modular log file, until the architecture of all time ranges of the object is obtained.

[0059] Optionally, since the deterioration and evolution of an object's architecture are often accompanied by version iterations and feature changes, the new time frame should prioritize covering key nodes in the software lifecycle to ensure that core architectural changes are captured. The new time frame must also ensure that logs are available and complete within that timeframe. For example, if logs are lost due to system failure during a certain period in the object's version control system (Git / SVN), that period should be excluded, or it should be used as the new time frame only after the log data is recovered. The time points for restoring the architecture can be selected at certain time intervals. The new time frame must maintain the same time granularity as the previous time frame to avoid distortion of the architecture evolution analysis due to inconsistent intervals. For example, if the initial time frame is a one-month cycle, the new time frame should continue this interval. If it is for a key version iteration, the time interval can be adjusted, but the interval of subsequent new time frames must be kept consistent.

[0060] Optionally, the preset time range is dynamically adjusted based on the training effect. Using the training effect of the classification model as feedback, the size of the preset time range is optimized in reverse. The higher the difference loss value between the modular classification result predicted by the model and the true label of the sample, the lower the model's classification accuracy, reflecting a potential lack of key features in the current log samples. The model parameters are adjusted until the loss value stabilizes at a low level without significant fluctuations. If the model fails to converge after multiple training rounds, it indicates that the current log sample size is insufficient or has poor representativeness. In cases of poor training performance, the preset time range is narrowed to increase sample density, making the sample features more comprehensive and the time distribution more even. In cases of good training performance, the preset time range is appropriately widened within the capacity of hardware computing power and software processing power, balancing efficiency and cost, and reducing the repetitive workload of log collection and structured processing.

[0061] Determining the new preset time range in the repetitive steps ensures coverage of key stages throughout the software lifecycle, preventing architectural changes of new modules from going uncollected due to incomplete time range coverage. By covering all time stages, fragmented architectural information is integrated into a continuous target architecture, ensuring that developers can analyze architectural change patterns from a global perspective, identify critical time points of architectural deterioration, and, based on the located deterioration nodes, developers can trace back the architectural state before that node, correct and improve the existing architecture, improve software architecture quality, and reduce development and maintenance costs.

[0062] Please see Figure 2 , Figure 2 This is a schematic diagram of an object architecture reconstruction apparatus according to an embodiment of the present invention. On the other hand, this application provides an object architecture reconstruction apparatus, which includes: Data collection module 201 is used to determine the current preset time range; and to obtain the target code submission log data of the object within the current preset time range; Data processing module 202 is used to perform structured processing on the target code submission log data to obtain structured target code submission log data; The classification module 203 is used to classify the structured target code submission log data to obtain a modular classification result of the target code submission log data. The architecture restoration module 204 is used to generate a target modular log file corresponding to the target code commit log data based on the modular classification result; and to obtain the target architecture within the current preset time range based on the target modular log file.

[0063] In an optional embodiment, the classification module 203 includes: The model training submodule is used to acquire sample code submission log data and a preset model; to perform structured processing on the sample code submission log data to obtain structured sample code submission log data; to input the sample code submission log data into the preset model for modular classification prediction to obtain predicted modular classification results; to calculate the difference between the predicted modular classification results and the modular classification labels corresponding to the sample code submission log data to obtain loss data; and to adjust the parameters of the preset model according to the loss data until the preset model converges to obtain a classification model. The modular classification result determination submodule is used to input the structured target code submission log data into the classification model to obtain the modular classification result of the target code submission log data.

[0064] In an optional embodiment, the restoration architecture module 204 includes: The classification result parsing submodule is used to parse the modular classification result and obtain the target features of the target code submission log data. The target modular log file construction submodule is used to construct the mapping relationship between the target code commit log data and the target features, so as to obtain the target modular log file corresponding to the target code commit log data.

[0065] In an optional embodiment, the target modular log file construction submodule includes: A mapping relationship construction unit is used to construct a first mapping relationship between the target code commit log data and the target class name; and to construct a second mapping relationship between the target code commit log data and the target module; and to construct a third mapping relationship between the target code commit log data and the target log content; and to construct a fourth mapping relationship between the target class name, the target module, and the target log content. The target modular log file integration unit is used to take the first mapping relationship, the second mapping relationship, and the third mapping relationship as the target modular log file corresponding to the target code commit log data; Architecture feature set construction unit, used to construct architecture feature sets; The architecture feature set update unit adds the first mapping relationship, the second mapping relationship, the third mapping relationship, and the fourth mapping relationship to the architecture feature set to obtain an updated architecture feature set; The target architecture generation unit obtains the target architecture within the current preset time range based on the updated architecture feature set.

[0066] In an optional embodiment, the object architecture reconstruction apparatus further includes: An iterative module is used to redetermine a new preset time range as the current preset time range; and to repeatedly obtain the target code commit log data of the object within the current preset time range, until the target architecture within the current preset time range is obtained based on the target modular log file, until the architecture of all time ranges of the object is obtained.

[0067] The object architecture restoration method provided in this application includes: determining a current preset time range; obtaining target code commit log data of the object within the current preset time range; performing structured processing on the target code commit log data to obtain structured target code commit log data; classifying the structured target code commit log data to obtain a modular classification result of the target code commit log data; generating a target modular log file corresponding to the target code commit log data based on the modular classification result; and obtaining the target architecture within the current preset time range based on the target modular log file. The object architecture restoration method provided in this application has the following beneficial effects: (1) Using code commit logs as the data source, log information is extracted, cleaned and structured through natural language processing technology. Even if there is no documentation or the documentation is incomplete, key architectural information can be parsed from the logs. Developers do not need to blindly sort through the massive code. The architecture of multiple time ranges throughout the software life cycle is obtained to form a complete architectural evolution chain. Developers can clearly trace the time, reasons and impact of each architectural adjustment, accurately correct and improve the existing architecture, improve the quality of software architecture and reduce development and maintenance costs.

[0068] (2) By training the classification model, the structured logs can be processed in batches and the modular classification results can be automatically output, which improves efficiency, avoids deviations caused by experience differences when classifying manually, and ensures that the restored architecture is highly consistent with the actual form of the software.

[0069] In an optional embodiment, this application provides an electronic device including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or at least one program being loaded and executed by the processor to implement the architecture reconstruction method of the object as described in any of the above embodiments.

[0070] In an optional embodiment, this application provides a computer-readable storage medium storing at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the architecture reconstruction method of an object as described in any of the above embodiments.

[0071] The above description is only an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for reconstructing the architecture of an object, characterized in that, The method for restoring the architecture of the object includes: Determine the current preset time range; Obtain the target code commit log data of the object within the current preset time range; The target code commit log data is processed into a structured form to obtain structured target code commit log data. The structured target code commit log data is classified to obtain a modular classification result of the target code commit log data; Based on the modular classification results, generate the target modular log file corresponding to the target code commit log data; Based on the target modular log file, the target architecture within the current preset time range is obtained.

2. The object architecture reconstruction method according to claim 1, characterized in that, The process of classifying the structured target code commit log data to obtain a modular classification result of the target code commit log data includes: Obtain sample code commit log data and preset models; The sample code submission log data is processed into a structured form to obtain structured sample code submission log data. The sample code submission log data is input into the preset model for modular classification prediction to obtain the predicted modular classification result. The difference between the predicted modular classification result and the modular classification label corresponding to the sample code submission log data is calculated to obtain the loss data; The parameters of the preset model are adjusted based on the loss data until the preset model converges, thus obtaining a classification model. The structured target code submission log data is input into the classification model to obtain the modular classification result of the target code submission log data.

3. The object architecture reconstruction method according to claim 1, characterized in that, The step of generating the target modular log file corresponding to the target code commit log data based on the modular classification result includes: The modular classification results are analyzed to obtain the target features of the target code submission log data; Construct a mapping relationship between the target code commit log data and the target features to obtain the target modular log file corresponding to the target code commit log data.

4. The object architecture reconstruction method according to claim 3, characterized in that, The target characteristics include at least the target class name, the target module to which the target code commit log data belongs, and the target log content. The step of constructing the mapping relationship between the target code commit log data and the target features to obtain the target modular log file corresponding to the target code commit log data includes: Construct a first mapping relationship between the target code commit log data and the target class name; Construct a second mapping relationship between the target code commit log data and the target's home module; Construct a third mapping relationship between the target code commit log data and the target log content; The first mapping relationship, the second mapping relationship, and the third mapping relationship are used as the target modular log file corresponding to the target code commit log data.

5. The object architecture reconstruction method according to claim 4, characterized in that, The step of obtaining the target architecture within the current preset time range based on the target modular log file includes: Build an architectural feature set; Construct a fourth mapping relationship between the target class name, the target module, and the target log content; The first mapping relationship, the second mapping relationship, the third mapping relationship, and the fourth mapping relationship are added to the architecture feature set to obtain an updated architecture feature set; Based on the updated set of architectural features, the target architecture within the current preset time range is obtained.

6. The object architecture reconstruction method according to claim 1, characterized in that, After obtaining the target architecture based on the target modular log file, the method further includes: Define a new preset time range as the current preset time range; Repeat the steps of obtaining the target code commit log data of the object within the current preset time range, and obtaining the target architecture within the current preset time range based on the target modular log file, until the architecture of all time ranges of the object is obtained.

7. The object architecture reconstruction method according to claim 2, characterized in that, Before inputting the sample code submission log data into the preset model for modular classification prediction and obtaining the predicted modular classification result, the method further includes: The sample code submission log data is preprocessed to form a data structure that matches the preset model.

8. An apparatus for reconstructing the architecture of an object, characterized in that, The architecture reconstruction device for the object includes: The data collection module is used to determine the current preset time range; and to acquire the target code commit log data of the object within the current preset time range. The data processing module is used to perform structured processing on the target code commit log data to obtain structured target code commit log data. The classification module is used to classify the structured target code submission log data to obtain a modular classification result of the target code submission log data. The architecture restoration module is used to generate a target modular log file corresponding to the target code commit log data based on the modular classification results; and to obtain the target architecture within the current preset time range based on the target modular log file.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or at least one program being loaded and executed by the processor to implement the architecture reconstruction method of the object as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement the architecture reconstruction method of the object as described in any one of claims 1-7.

Images