A method and apparatus for software asset management

Abstract

The application discloses a kind of software asset management method and device. The original software assets from multi-source data carrier are split into multiple standard objects, and the heterogeneous software asset data format and granularity are unified to provide uniform comparison benchmark for similarity calculation. Based on the multiple standard objects, the comprehensive similarity of each original software asset is calculated, and the coincidence degree between different assets is objectively and accurately obtained in multiple dimensions. The original software asset that satisfies the preset requirement is determined as the same software asset, the de-duplication and normalization of asset are completed, and the redundant asset data is simplified. After forming the standardized software asset of standard and uniform, the knowledge graph is built, the correlation logic and level between different assets are clearly sorted out, and the scattered and isolated asset data is constructed into a structured data system with correlation. In the knowledge graph, asset information can be quickly and accurately located, the asset query efficiency and information integrity are greatly improved, and the reliability of enterprise asset management is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and apparatus for software asset management. Background Technology

[0002] Enterprises' software assets are typically stored in various data sources such as code repositories, artifact repositories, and configuration centers. Asset management platforms can complete the registration of basic asset information by relying on catalog classification and tag entry.

[0003] In existing technologies, traditional asset management platforms only record asset names and ownership information. The naming of the same component is inconsistent across different data sources, and management relies solely on manual tagging. This leads to low query efficiency and accuracy when retrieving asset information. Furthermore, when an asset is ready for upgrades or decommissioning, it is difficult to accurately and quickly identify the associated business, which can easily result in missed notifications and compatibility issues. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a method and apparatus for software asset management, which constructs a software asset knowledge graph to improve the reliability of enterprise software asset management, while also enhancing the efficiency and accuracy of asset information retrieval.

[0005] This application discloses a method for software asset management, the method comprising: The original software assets from multiple data carriers are broken down into multiple standard objects; Based on the various types of standard objects, calculate the comprehensive similarity of each of the original software assets; The original software assets whose comprehensive similarity meets the preset requirements are identified as the same software asset, thus obtaining standardized software assets; A knowledge graph is built based on the standardized software assets mentioned above; Based on the target software asset query request, the knowledge graph is searched to obtain information about the target standardized software asset.

[0006] Optionally, the types of the standard objects include components, interface capabilities, data objects, and evidence fragments. The calculation of the comprehensive similarity of each of the original software assets based on multiple types of the standard objects includes: Based on the various standard objects, calculate the name similarity, functional description similarity, interface parameter similarity, data object overlap, and person in charge overlap of each original software asset; The overall similarity of each original software asset is obtained by combining the name similarity, function description similarity, interface parameter similarity, data object overlap, and person in charge overlap of each original software asset.

[0007] Optionally, the step of calculating the name similarity, functional description similarity, interface parameter similarity, data object overlap, and responsible person overlap of each of the original software assets based on multiple types of standard objects includes: The name similarity is calculated based on the name field in the component; Calculate the functional description similarity based on the functional description text in the evidence fragment; Calculate the similarity of the interface parameters based on the interface parameters in the interface capabilities; Calculate the overlap of the data objects based on the data objects; Based on the responsible person field in any of the standard objects described, obtain the overlap of the responsible persons.

[0008] Optionally, calculating the interface parameter similarity based on the interface parameters in the interface capabilities includes: Extract the set of interface parameters from the interface capabilities of each of the original software assets; The similarity of the interface parameters is calculated for the set of interface parameters to obtain the similarity of the interface parameters for each of the original software assets.

[0009] Optionally, calculating the overlap of the data objects based on the data objects includes: Extract the set of data object elements of the data objects of each of the original software assets; The similarity of the data object elements is calculated to obtain the overlap of the data objects of each original software asset.

[0010] Optionally, determining that the original software assets whose comprehensive similarity meets the preset requirements are the same software asset includes: The name similarity, function description similarity, data object overlap, and person in charge overlap are weighted and calculated to obtain the multi-factor similarity of each original software asset. Two original software assets are determined to be the same software asset if the multi-factor similarity is greater than or equal to a first multi-factor threshold, the data object overlap is greater than or equal to a first object overlap threshold, and the interface parameter similarity is greater than or equal to a first interface parameter threshold.

[0011] Optionally, after determining that two original software assets have the same software asset, and that the multi-factor similarity is greater than or equal to a first multi-factor threshold, the data object overlap is greater than or equal to a first object overlap threshold, and the interface parameter similarity is greater than or equal to a first interface parameter threshold, the method further includes: Two original software assets are determined to be not the same software asset if the multi-factor similarity is less than a second multi-factor threshold, the data object overlap is less than a second object overlap threshold, or the interface parameter similarity is less than a first interface parameter threshold; the second multi-factor threshold is less than the first multi-factor threshold, and the second object overlap threshold is less than the first object overlap threshold.

[0012] Optionally, the construction of the knowledge graph based on the standardized software assets includes: An initial knowledge graph is constructed using the business domains, services, and components of the standardized software assets as nodes and the relationships between the nodes as edges. The confidence level of each edge is calculated based on the number of evidence items corresponding to each edge in the initial knowledge graph and the reliability of the source of each piece of evidence; the reliability of the source is related to the method of obtaining the evidence. By traversing each edge in the initial knowledge graph, multiple query paths are obtained; The path confidence of each query path is obtained based on the confidence of each edge; The query paths whose confidence level is lower than the preset confidence level are marked as low-association paths, thus obtaining the knowledge graph.

[0013] Optionally, each edge in the knowledge graph has a corresponding set of evidence, and the search based on the target software asset query request in the knowledge graph to obtain information about the target standardized software asset includes: Based on the target software asset query request, a search is performed on the knowledge graph to obtain the target search results; Obtain the target evidence set corresponding to the edge of the target retrieval result; If all fields in the target retrieval result are included in the target evidence set, the target retrieval result is determined to be information of the target standardized software asset. If there are unsubstantiated fields in the target search results that are not included in the target evidence set, the target search results are determined to be information of the target standardized software asset with an unsubstantiated label, and the unsubstantiated fields are marked as unsubstantiated content.

[0014] Based on the above-mentioned method for software asset management, this application also discloses an apparatus for software asset management, including: a splitting unit, an acquisition unit, a determination unit, a construction unit, and a retrieval unit; The splitting unit is used to split the original software assets from multiple data carriers into multiple types of standard objects; The acquisition unit is used to calculate the comprehensive similarity of each of the original software assets based on multiple types of standard objects. The determining unit is used to determine that the original software assets whose comprehensive similarity meets the preset requirements are the same software assets, thereby obtaining standardized software assets. The building unit is used to build a knowledge graph based on the standardized software assets; The retrieval unit is used to search the knowledge graph based on the target software asset query request to obtain information about the target standardized software asset.

[0015] Optionally, the types of the standard objects include components, interface capabilities, data objects, and evidence fragments, and the acquisition unit includes: The calculation subunit is used to calculate the name similarity, functional description similarity, interface parameter similarity, data object overlap, and person in charge overlap of each of the original software assets based on the multiple types of standard objects. The combined sub-unit is used to combine the name similarity, function description similarity, interface parameter similarity, data object overlap, and person in charge overlap of each original software asset to obtain the comprehensive similarity of each original software asset.

[0016] Optionally, the computing subunit includes: A name similarity calculation subunit is used to calculate the name similarity based on the name field in the component; The functional description similarity calculation subunit is used to calculate the functional description similarity based on the functional description text in the evidence fragment; The interface parameter similarity calculation subunit is used to calculate the interface parameter similarity based on the interface parameters in the interface capabilities. An object overlap calculation subunit is used to calculate the overlap of the data objects based on the data objects; The responsible person overlap calculation subunit is used to obtain the responsible person overlap based on the responsible person field in any of the standard objects.

[0017] Optionally, the interface parameter similarity calculation subunit includes: The interface parameter extraction subunit is used to extract the set of interface parameters from the interface capabilities of each of the original software assets. The interface parameter calculation subunit is used to perform similarity calculation on the interface parameter set to obtain the interface parameter similarity of each of the original software assets.

[0018] Optionally, the object overlap calculation subunit includes: The data object extraction subunit is used to extract the set of data object elements of the data objects of each of the original software assets; The data object calculation subunit is used to perform similarity calculation on the data object elements to obtain the overlap degree of the data objects of each original software asset.

[0019] Optionally, the determining unit includes: The weighted calculation subunit is used to perform weighted calculations on the name similarity, the function description similarity, the data object overlap, and the person in charge overlap to obtain the multi-factor similarity of each of the original software assets; The merged sub-unit is used to determine that two original software assets with the multi-factor similarity greater than or equal to the first multi-factor threshold, the data object overlap greater than or equal to the first object overlap threshold, and the interface parameter similarity greater than or equal to the first interface parameter threshold are the same software asset.

[0020] Optionally, the device further includes: The distinction determination unit is used to determine that two original software assets whose multi-factor similarity is less than a second multi-factor threshold, whose data object overlap is less than a second object overlap threshold, or whose interface parameter similarity is less than a first interface parameter threshold are not the same software assets; the second multi-factor threshold is less than the first multi-factor threshold, and the second object overlap threshold is less than the first object overlap threshold.

[0021] Optionally, the assembly unit includes: The initial construction subunit is used to build an initial knowledge graph using the business domains, services and components of the standardized software assets as nodes and the relationships between the nodes as edges. The confidence calculation subunit is used to calculate the confidence of each edge based on the number of evidence items corresponding to each edge in the initial knowledge graph and the source reliability of each piece of evidence; the source reliability is related to the method of obtaining the evidence; Traverse the sub-units to traverse each edge in the initial knowledge graph and obtain multiple query paths; The path confidence calculation subunit is used to obtain the path confidence of each query path based on the confidence of each edge; The path labeling subunit is used to label query paths with a path confidence level lower than a preset confidence level as low-association paths, thereby obtaining the knowledge graph.

[0022] Optionally, each edge in the knowledge graph has a corresponding set of evidence, and the retrieval unit includes: The initial retrieval subunit is used to perform a retrieval in the knowledge graph based on the target software asset query request to obtain the target retrieval result; The evidence acquisition subunit is used to acquire the target evidence set corresponding to the edge of the target retrieval result; An evidence verification subunit is used to determine that the target retrieval result is information of the target standardized software asset when all fields in the target retrieval result are included in the target evidence set. The unsubstantiated determination subunit is used to determine, when there is an unsubstantiated field in the target retrieval result that is not included in the target evidence set, that the target retrieval result is information of the target standardized software asset with an unsubstantiated label, and to mark the unsubstantiated field as unsubstantiated content.

[0023] This application discloses a method and apparatus for software asset management. Original software assets from multiple data carriers are broken down into multiple standard objects, unifying the data format and granularity of various heterogeneous software assets, eliminating data barriers between different data sources, and providing a unified comparison benchmark for similarity calculation. The comprehensive similarity of each original software asset is calculated based on multiple standard objects, avoiding misjudgments caused by a single comparison dimension, and more objectively and accurately obtaining the degree of overlap between different software assets. Original software assets whose comprehensive similarity meets preset requirements are identified as the same software asset. Asset deduplication and normalization are completed, simplifying redundant asset data and forming standardized software assets. A knowledge graph is built based on the standardized software assets, clearly outlining the logical relationships and hierarchical relationships between different assets, constructing a structured data system with interconnected relationships from scattered and isolated asset data. Based on the target software asset query request, the knowledge graph is searched, enabling rapid and accurate location of information on the target standardized software asset, significantly improving asset query efficiency and information completeness, facilitating asset management, reuse, and maintenance, and improving the reliability of enterprise software asset management. Attached Figure Description

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

[0025] Figure 1 This is a flowchart illustrating a software asset management method disclosed in an embodiment of this application; Figure 2 This is a flowchart illustrating another software asset management method disclosed in an embodiment of this application; Figure 3 This is a flowchart illustrating another software asset management method disclosed in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a software asset management device disclosed in an embodiment of this application. Detailed Implementation

[0026] Traditional software asset management platforms rely on catalog classification and manual tag entry to complete basic asset records. This only retains basic asset names and ownership information, failing to present asset business capabilities, dependency chains, reusability, and the scope of business impact from changes. Specifically, the existing asset management model suffers from three main problems: First, it suffers from fragmented multi-source software asset information, inconsistent semantic expressions and tagging standards, resulting in disorganized and redundant search results. Asset inventory requires manual verification, leading to high costs. Second, it cannot fully track dependencies between assets, lacking information on cross-service calls and multi-layer component linkages. In asset upgrades and decommissioning scenarios, it cannot quickly locate affected businesses, easily causing compatibility issues, missed business notifications, and redundant development. Third, the asset analysis conclusions generated by large models lack traceability support, relying solely on name similarity for judgment. This fails to link corresponding code, interfaces, versions, and original documentation evidence, resulting in low confidence levels in architecture reviews and compliance audits.

[0027] To address the various shortcomings of existing technologies, the software asset management method proposed in this application first collects original software assets from various dispersed asset carriers. The complete data package of each asset is then broken down into four categories of standard objects: components, interface capabilities, data objects, and evidence fragments. Source path, version, hash identifier, and other traceability information for each standard object are simultaneously retained. Next, the comprehensive similarity between two original software assets is calculated using multi-dimensional indicators such as name, function, data object, and responsible person. Based on preset thresholds, identical software assets are merged, and conflicting software assets are marked, achieving semantic unification and standardization of all original software assets. A knowledge graph carrying calls and dependencies is constructed based on the standardized software assets, along with a complete evidence index. Subsequent searches can be performed within the knowledge graph based on asset query needs. Verifiable and traceable asset Q&A results are generated based on the retrieved standardized software assets and corresponding evidence. Simultaneously, the graph can automatically identify redundant, inefficient, and high-risk assets and output a feasible governance list. The entire process is based on the evidence index, avoiding the problem of large models outputting unfounded conclusions, and fundamentally solving problems such as semantic confusion, unclear dependencies, and unreliable analysis results in software assets.

[0028] 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 some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] Example 1: This application discloses a method for software asset management.

[0030] For details, please refer to Figure 1 The software asset management method disclosed in this embodiment includes the following steps: Step 101: Break down the original software assets from multiple data carriers into multiple standard objects.

[0031] In this embodiment, the method first collects scattered data (data packages) of the original software assets from multiple data carriers, including code repositories, artifact repositories, interface documents, database scripts, configuration centers, testing platforms, and operation and maintenance documents, to prepare for the splitting of the original software assets. Specifically, this can involve extracting the directory structure, build files, module dependency declarations, entry classes, and recent commit records from the code repository; extracting the interface paths, request methods, input parameter fields, output parameter fields, and authentication requirements from the interface documents; extracting the table structure, field types, index definitions, and integrity constraints from the database scripts; extracting configuration key-value pairs, environment identifiers (such as dev / staging / production), and scope of application (such as global / service-level / instance-level) from the configuration center; extracting the artifact name, version number, build time, and dependency list from the artifact repository; extracting the coverage mapping relationship between test cases and the interface under test from the testing platform; and extracting service descriptions, deployment requirements, and known fault records from the operation and maintenance documents.

[0032] In the method of this embodiment, after collecting the data of each original software asset, the data of each original software asset can be divided into four categories of standard objects: components, interface capabilities, data objects, and document evidence. A component represents a software component in the original software asset that can be independently deployed and reused; an interface capability represents the specific interface capability of the original software asset; a data object represents a data structure such as a database table or message payload; and a document evidence represents evidence fragments used for tracing the source.

[0033] Subsequently, for each standard object, the source path (sourceUri), version number (version), owner (owner), update time (updateTime), and hash value can be recorded. The hash value can be used to determine whether the file has been changed, thus avoiding duplicate parsing.

[0034] It should be noted that the seven types of multi-source data carriers and four types of standard objects mentioned above are merely illustrative descriptions of the method in this embodiment, and do not constitute a specific limitation on the types and numbers of data carriers and standard objects. In actual working conditions, these can be flexibly adjusted according to the original software asset storage channels, management needs, etc. The specific categories and quantities of data source carriers and standard objects in this embodiment can be freely customized in different business scenarios and are not constrained by the numerical values ​​exemplified in this embodiment.

[0035] Step 102: Calculate the overall similarity of each of the original software assets based on the various types of standard objects.

[0036] In the method of this embodiment, based on multiple standard objects, multi-dimensional feature extraction is performed on each pair of original software assets to calculate the comprehensive similarity between the pairs of original software assets, which is used to characterize their matching degree. Specifically, the similarity of the names, functional descriptions, interface parameters, data objects, and responsible persons of each original software asset can be calculated first.

[0037] As a feasible solution, we can first perform standardized terminology processing on the name field of the standard object "component". Specifically, this involves removing common suffixes such as "service", "api", and "module" from the name field and converting camelCase, underscore, and Chinese naming formats to obtain unified terms. This standardized terminology processing is shown in the table below: Table 1. Comparison of Standardized Lexical Unit Processing

[0038] Subsequently, the similarity of the names of every two original software assets, i.e., the core terms in the components, is calculated to obtain the name similarity between the two original software assets. It should be noted that the number and type of common suffixes in this embodiment are only illustrative examples. In actual working conditions, the number and type of common suffixes can be flexibly adjusted according to actual needs. This embodiment does not impose specific limitations here.

[0039] As a feasible approach, the functional description text stored in the standard object of "evidence fragments" can be extracted. A pre-trained semantic vector model is used to encode the functional description texts of the two original software assets to generate feature vectors. Then, the similarity between the two feature vectors is quantified by cosine similarity or Euclidean distance to obtain the functional description similarity.

[0040] As a feasible approach, interface parameter similarity can be calculated based on the interface parameter information carried by the standard object "interface capability". Specifically, the input and output parameter fields of the interface capability corresponding to each original software asset can be extracted to construct an interface parameter set. Then, the Jaccard similarity algorithm can be used to calculate the similarity between the two sets of interface parameter sets to obtain the interface parameter similarity between the two original software assets.

[0041] As a feasible approach, the overlap of data objects is calculated based on the table structure, fields, indexes, and entity structure information stored in the standard object "data object". Specifically, this can be achieved by extracting the data object element sets corresponding to the data objects of the two original software assets, and then using the Jaccard similarity algorithm to calculate the similarity between the two sets of data object element sets to obtain the overlap of data objects between the two original software assets.

[0042] It should be noted that the semantic vector model, cosine similarity, Euclidean distance and Jaccard similarity algorithm in this embodiment are all exemplary. In actual working conditions, the model and algorithm can be adaptively selected according to actual needs. This embodiment does not make specific limitations here.

[0043] As a feasible solution, since the owners of the original software assets typically remain unchanged, the overlap of owners between two original software assets can be calculated based on the owner field in any type of standard object. Specifically, this can be achieved by reading the owner field carried by any type of standard object in the component or interface capabilities, comparing the owner (or team) information corresponding to the two original software assets, calculating the similarity of the owners (or teams), and obtaining the owner overlap.

[0044] In the method of this embodiment, by combining the name similarity, functional description similarity, interface parameter similarity, data object overlap, and responsible person overlap of the two original software assets calculated above, a comprehensive similarity between the two original software assets can be obtained. As an feasible solution, the name similarity, functional description similarity, data object overlap, and responsible person overlap can be weighted to obtain a multi-factor similarity for each original software asset. The formula for calculating this multi-factor similarity is as follows: M=0.35×N+0.35×F+0.2×D+0.1×O (1) In the formula, M represents multi-factor similarity, N represents name similarity, F represents functional description similarity, D represents data object overlap, and O represents person in charge overlap. The weights 0.35, 0.2, and 0.1 in the formula are weight values ​​that can be adjusted according to actual needs and are not specifically limited here.

[0045] In the method of this embodiment, the interface parameter similarity is not involved in the calculation of multi-factor similarity, but exists together with the multi-factor similarity as part of the comprehensive similarity, in preparation for asset merging and verification in subsequent steps.

[0046] Step 103: Determine that the original software assets whose comprehensive similarity meets the preset requirements are the same software assets, and obtain standardized software assets.

[0047] In the method of this embodiment, three indicators in comprehensive similarity—multi-factor similarity, data object overlap, and interface parameter similarity—are used as the basis for asset merging verification to distinguish whether different original software assets are the same software asset, realize the merging and standardization of redundant and duplicate assets, and finally generate standardized software assets with unified identification and complete association information.

[0048] As an feasible solution, when the multi-factor similarity calculated for any two original software assets is greater than or equal to the first multi-factor threshold (e.g., 0.82), and the data object overlap of these two original software assets is greater than or equal to the first object overlap threshold (e.g., 0.6), and the interface parameter similarity of these two original software assets is also greater than or equal to the first interface parameter threshold (e.g., 0.4), the two original software assets are determined to have consistent business functions and are considered the same software asset. Subsequently, the metadata, associated documents, interface information, data table structures, and other content of these two original software assets can be integrated and deduplicated to generate a standardized and complete software asset.

[0049] Accordingly, when the multi-factor similarity calculated for any two original software assets is less than the second multi-factor threshold (0.65), the data object overlap is less than the second object overlap threshold (0.2), or the interface parameter similarity is less than the first interface parameter threshold, it can be determined that these two original software assets have essential differences in business functions, data structures, or interface call logic, and the two cannot be identified as the same software asset. Subsequently, they need to be stored independently, and the differences or reasons for conflicts between them should be recorded. Asset merging should not be performed to avoid erroneous merging of assets with different functions, ensuring that the final output of standardized software assets is accurately divided and has clear boundaries.

[0050] Correspondingly, there are also cases where the multi-factor similarity of two original software assets is greater than or equal to the second multi-factor threshold, but less than the first multi-factor threshold. In this case, as long as the data object overlap of the two original software assets is greater than or equal to the second object overlap threshold, and the interface parameter similarity is also greater than or equal to the first interface parameter threshold, they will proceed to the manual confirmation stage. At the same time, these two original software assets can be marked as "pending confirmation" for differentiation.

[0051] Step 104: Build a knowledge graph based on the standardized software assets.

[0052] In the method of this embodiment, this step builds a knowledge graph based on the merged and deduplicated standardized software assets, transforming the discrete and fragmented standardized software asset information into structured graph data with hierarchical associations and searchable traversal capabilities, thereby achieving efficient asset management and facilitating the rapid location and traceability query of target software assets based on subsequent search instructions.

[0053] As a feasible approach, the initial knowledge graph framework is constructed first. Three core entities—business domains, services, and components—of standardized software assets are extracted as nodes in the initial knowledge graph. The various business relationships between business domains, services, and components, including inclusion, subordination, invocation, dependency, and data interaction, are fully analyzed. The one-to-one relationships between nodes are defined as edges connecting different nodes within the initial knowledge graph. The initial knowledge graph is then built using all nodes and their corresponding edges. Configuration items can be used as auxiliary asset information for scalable generation. This initial knowledge graph fully preserves the original hierarchical relationships and cross-entity business connections of standardized software assets, forming a preliminary, traversable, and queryable basic graph architecture.

[0054] In this embodiment, after constructing the initial knowledge graph, a confidence score is calculated for each edge of the initial knowledge graph. This score quantifies the credibility and strength of the relationships between corresponding nodes. The confidence score calculation relies primarily on two factors: the total number of pieces of evidence that can substantiate the true nature of the relationship corresponding to that edge, and the reliability of the source of each piece of supporting evidence. The formula for calculating the confidence score is as follows: (2) In the formula, C is the confidence level, and R is the confidence level. max The highest source reliability value among all evidence on that side, where n is the number of pieces of evidence (3 or more can be considered saturated). The 0.6 and 0.4 in the formula are weight values ​​that can be adjusted according to actual needs, and are not specifically limited here.

[0055] The reliability value of the source is related to the specific acquisition method of each piece of evidence. Specifically, different reliability assignment standards can be pre-configured for different acquisition methods. For example, link tracing (actual runtime call) can be set to 1.0, gateway routing records to 0.9, build dependency declarations to 0.8, and static scanning (code inference) to 0.6. Static scanning has the lowest source reliability value because the scan results may contain false positives such as dead code, unexecuted conditional branches, or obfuscated package names.

[0056] In the method of this embodiment, after the confidence of all edges is calculated, a full graph traversal is performed on the overall initial knowledge graph. Along the topological links where nodes and edges are connected, multiple complete query paths that can be used for subsequent asset retrieval and location are decomposed and sorted out. Each query path is composed of multiple edges with connectivity, which can be used to trace the target software asset information downward from any entry node.

[0057] Subsequently, the product of the edge confidence scores of all edges constituting a single query path is obtained as the path confidence score for that single query path. The path confidence score comprehensively reflects the overall credibility level of multi-level relationships in the entire retrieval chain, intuitively demonstrating the reference value of the query path. Then, the path confidence score of each query path is compared with a preset confidence score (e.g., 0.6). Query paths with a path confidence score lower than this preset confidence score are marked as low-relevance paths and listed separately for manual review. This completes the simplification and optimization of the initial knowledge graph, ultimately generating a knowledge graph with a rigorous structure, controllable credibility of relationships, and efficient and accurate retrieval paths.

[0058] Step 105: Based on the target software asset query request, search the knowledge graph to obtain information about the target standardized software asset.

[0059] In the method of this embodiment, based on the knowledge graph built and optimized through the above steps, a large model can respond to query requests, perform retrieval and consistency verification on the knowledge graph, and finally output credible and traceable information related to the target standardized software assets. This ensures that the query results are complete, accurate, and based on evidence, avoiding the problems of low efficiency and low accuracy in asset management caused by the large model outputting illusory content without evidence support.

[0060] As a feasible solution, in response to a target software asset query request, the large model can employ a retrieval enhancement generation algorithm to extract search conditions such as keywords, scope, and search dimensions from the query request and convert them into vectors. Then, a search is performed in the knowledge graph, retrieving the most relevant fragments with the highest matching degree from the evidence index. These fragments are then weighted according to the node hierarchy of the knowledge graph and incorporated into the context to obtain the target retrieval results.

[0061] Subsequently, consistency verification can be performed using a validator. Specifically, regular expressions can be used to extract the asset name, version number, and interface path from the target retrieval results, and then search for each element in the evidence index of the knowledge graph to obtain the target evidence set corresponding to the target retrieval result. It is then verified whether all fields in the target retrieval result can be found in the target evidence set. If all fields in the target retrieval result are included in the target evidence set, the target retrieval result is determined to be information of the target standardized software asset, and can be directly output by the large model. Conversely, if the target retrieval result contains unsubstantiated fields not included in the target evidence set, the target retrieval result is determined to be information of the target standardized software asset labeled "unsubstantiated," and the unsubstantiated fields that cannot be traced within the target retrieval result are marked as unsubstantiated content. This clearly distinguishes between traceable and valid content and unsubstantiated inferences within the retrieval result, facilitating an intuitive differentiation of the asset information credibility level.

[0062] In the method of this embodiment, in the subsequent use of the knowledge graph, the knowledge graph can also be subjected to full-domain automated scanning and inspection work according to a preset cycle. During the traversal of nodes and related links, asset items that need intervention and governance are screened in batches. These include assets with redundant functions, idle and low-usage assets that have been in a low-frequency call state for a long time, ownerless assets with missing ownership information and no corresponding responsible persons, expired assets with outdated supporting documentation, and high-risk dependent assets with high-risk upstream and downstream dependencies.

[0063] For assets with duplicate capabilities, semantic normalization scores, interface parameter overlap data, and upstream / downstream caller overlap data retained from the previous asset normalization process can be retrieved as the basis for judgment. Assets are classified as duplicate capabilities when all three indicators simultaneously reach a preset threshold. For assets with low utilization, the entire historical call log from the gateway side and the reference statistics of code files within the project can be retrieved. Utilization levels are determined based on call frequency and code reference frequency to identify idle assets with no long-term business calls or code dependencies. For assets with expired documents, the last update timestamp of the asset-bound document can be compared. Simultaneously, the interface definition content recorded in the document is verified to fully match the hash value of the current online interface parameters. If the hash verification is inconsistent, the document content is deemed out of sync with the actual interface specifications and marked as an expired asset.

[0064] Subsequently, for each governance anomaly identified through screening, standardized handling suggestions tailored to the specific issue scenario can be automatically generated. Multiple rectification plans can be selected based on the actual asset situation. For assets with duplicate capabilities, suggestions can be provided to merge interfaces and remove redundant items. For assets with expired documents, rectification guidelines can be provided to supplement and revise supporting documentation. For low-usage assets with no value, obsolescence marking and process archiving can be implemented. For duplicate assets with multiple dependencies, a comprehensive migration plan for the calling party's business chain can be proposed. For high-risk dependent assets, supplementary special test cases and optimization plans to expand test coverage can be generated. Each generated formal governance list item fully specifies the business impact scope of the problematic asset and the source of original evidence supporting the issue determination. Simultaneously, based on the asset's original ownership information, the system automatically recommends the appropriate responsible person for handling the issue, ensuring that the information elements of each governance task are complete, traceable, and that the responsible party is clearly identified and accountable.

[0065] Once the responsible person completes the rectification operation for this governance item according to the handling suggestions, the system will synchronously write back the handling result, the latest asset status, and the rectification completion time to the corresponding node and related edges of the knowledge graph, update the asset status identifier, ownership information, document version, dependency relationship and other related data in the graph, complete the closed-loop archiving of this governance matter, and enable the knowledge graph to continuously synchronize the real operation and maintenance status of assets. Relying on the periodic scanning and closed-loop writing mechanism, the system continuously reduces asset redundancy, fills in information gaps, and mitigates link risks, thereby continuously improving the standardization, accuracy and operation and maintenance security of the entire software asset management system.

[0066] The method described in this embodiment standardizes and semantically unifies heterogeneous software asset carriers scattered across multiple channels, transforming fragmented and disordered code, scripts, and documents into a structured, reasonable, and queryable knowledge graph. This effectively improves the accuracy of asset retrieval and solves the problem of chaotic retrieval caused by synonyms and homonyms among multi-source assets. By calculating the confidence level of asset calls and dependencies using quantitative formulas, only suspected associations with low confidence are pushed to manual review, reducing the workload of ineffective verification by architecture and operations personnel. Simultaneously, it significantly reduces the cost of asset reuse review, providing interface definitions, version information, upstream and downstream dependencies, and supporting materials for asset differences when outputting reuse recommendations, eliminating the tedious operation of reviewers verifying data across multiple platforms. Before service upgrades and offline modifications, it identifies all affected business links, distinguishes between high-confidence core associations and low-confidence associations awaiting review, avoids online risks such as missed changes and compatibility failures, and can also identify high-risk dependencies, providing early warnings of chain business risks caused by changes in underlying components.

[0067] To address the illusion problem in large-scale question answering, the method in this embodiment employs a retrieval enhancement generation algorithm to automatically verify the retrieval content of large-scale models and mark unsubstantiated information. All asset-related conclusions, reuse plans, and scope of impact of changes in the output results can be verified against the original evidence, fully meeting the compliance requirements of enterprise architecture control and information security auditing.

[0068] Example 2: This application discloses another method for software asset management; please refer to [link / reference]. Figure 2 This embodiment describes the judgment process for asset consolidation.

[0069] Step 201: Collect data packages of original software assets from multiple data carriers, including code repositories, artifact repositories, interface documents, database scripts, configuration centers, testing platforms, and operation and maintenance documents.

[0070] Step 202: Decompose the data packet into four standard objects: components, interface capabilities, data objects, and evidence fragments.

[0071] Step 203: Based on standard objects, calculate the similarity of the names, functional descriptions, interface parameters, data objects, and responsible persons of the two original software assets.

[0072] Step 204: Perform a weighted calculation on name similarity, functional description similarity, data object overlap, and responsible person overlap to obtain the multi-factor similarity of the two original software assets.

[0073] Step 205: Determine if the multi-factor similarity is greater than or equal to 0.82, the data object overlap is greater than or equal to 0.6, and the interface parameter similarity is greater than or equal to 0.4. If yes, proceed to step 206. If no, proceed to step 207.

[0074] Step 206: Determine that the two original software assets are combined into one software asset and perform asset merging.

[0075] Step 207: Determine if there are any data objects with a similarity of less than 0.65, an overlap of less than 0.2, or an interface parameter similarity of less than 0.4. If yes, proceed to step 208. If no, proceed to step 209.

[0076] Step 208: Determine that the two original software assets are not a single software asset.

[0077] Step 209: Mark the two original software assets as pending manual confirmation.

[0078] Example 3: This application discloses another method for software asset management; please refer to [link / reference]. Figure 3 This embodiment describes the method for large-scale model retrieval and response processes.

[0079] Step 301: Respond to the target software asset query request from the user.

[0080] Step 302: Based on the target software asset query request, perform a search in the knowledge graph to obtain the target search results.

[0081] Step 303: Obtain the target evidence set corresponding to the edge of the target retrieval result.

[0082] Step 304: Determine whether all fields in the target search results are included in the target evidence set. If yes, proceed to step 305. If no, proceed to step 306.

[0083] Step 305: Output the target retrieval results as information on the target standardized software assets.

[0084] Step 306: Assign the "no basis" label to the target search results, and mark the fields in the target search results that are not included in the target evidence set as "no basis" content, and output the labeled target search results.

[0085] Based on the software asset management method disclosed in the above embodiments, this embodiment correspondingly discloses a software asset management apparatus. Please refer to... Figure 4 The software asset management device includes: a splitting unit 401, an acquisition unit 402, a determination unit 403, a construction unit 404, and a retrieval unit 405; The splitting unit 401 is used to split the original software assets from the multi-source data carrier into multiple types of standard objects; The acquisition unit 402 is used to calculate the comprehensive similarity of each of the original software assets based on multiple types of standard objects. The determining unit 403 is used to determine that the original software assets whose comprehensive similarity meets the preset requirements are the same software assets, and to obtain standardized software assets. The building unit 404 is used to build a knowledge graph based on the standardized software assets; The retrieval unit 405 is used to search the knowledge graph based on the target software asset query request to obtain information about the target standardized software asset.

[0086] Optionally, the types of the standard objects include components, interface capabilities, data objects, and evidence fragments, and the acquisition unit 402 includes: The calculation subunit is used to calculate the name similarity, functional description similarity, interface parameter similarity, data object overlap, and person in charge overlap of each of the original software assets based on the multiple types of standard objects. The combined sub-unit is used to combine the name similarity, function description similarity, interface parameter similarity, data object overlap, and person in charge overlap of each original software asset to obtain the comprehensive similarity of each original software asset.

[0087] Optionally, the computing subunit includes: A name similarity calculation subunit is used to calculate the name similarity based on the name field in the component; The functional description similarity calculation subunit is used to calculate the functional description similarity based on the functional description text in the evidence fragment; The interface parameter similarity calculation subunit is used to calculate the interface parameter similarity based on the interface parameters in the interface capabilities. An object overlap calculation subunit is used to calculate the overlap of the data objects based on the data objects; The responsible person overlap calculation subunit is used to obtain the responsible person overlap based on the responsible person field in any of the standard objects.

[0088] Optionally, the interface parameter similarity calculation subunit includes: The interface parameter extraction subunit is used to extract the set of interface parameters from the interface capabilities of each of the original software assets. The interface parameter calculation subunit is used to perform similarity calculation on the interface parameter set to obtain the interface parameter similarity of each of the original software assets.

[0089] Optionally, the object overlap calculation subunit includes: The data object extraction subunit is used to extract the set of data object elements of the data objects of each of the original software assets; The data object calculation subunit is used to perform similarity calculation on the data object elements to obtain the overlap degree of the data objects of each original software asset.

[0090] Optionally, the determining unit 403 includes: The weighted calculation subunit is used to perform weighted calculations on the name similarity, the function description similarity, the data object overlap, and the person in charge overlap to obtain the multi-factor similarity of each of the original software assets; The merged sub-unit is used to determine that two original software assets with the multi-factor similarity greater than or equal to the first multi-factor threshold, the data object overlap greater than or equal to the first object overlap threshold, and the interface parameter similarity greater than or equal to the first interface parameter threshold are the same software asset.

[0091] Optionally, the device further includes: The distinction determination unit is used to determine that two original software assets whose multi-factor similarity is less than a second multi-factor threshold, whose data object overlap is less than a second object overlap threshold, or whose interface parameter similarity is less than a first interface parameter threshold are not the same software assets; the second multi-factor threshold is less than the first multi-factor threshold, and the second object overlap threshold is less than the first object overlap threshold.

[0092] Optionally, the assembly unit 404 includes: The initial construction subunit is used to build an initial knowledge graph using the business domains, services and components of the standardized software assets as nodes and the relationships between the nodes as edges. The confidence calculation subunit is used to calculate the confidence of each edge based on the number of evidence items corresponding to each edge in the initial knowledge graph and the source reliability of each piece of evidence; the source reliability is related to the method of obtaining the evidence; Traverse the sub-units to traverse each edge in the initial knowledge graph and obtain multiple query paths; The path confidence calculation subunit is used to obtain the path confidence of each query path based on the confidence of each edge; The path labeling subunit is used to label query paths with a path confidence level lower than a preset confidence level as low-association paths, thereby obtaining the knowledge graph.

[0093] Optionally, each edge in the knowledge graph has a corresponding set of evidence, and the retrieval unit 405 includes: The initial retrieval subunit is used to perform a retrieval in the knowledge graph based on the target software asset query request to obtain the target retrieval result; The evidence acquisition subunit is used to acquire the target evidence set corresponding to the edge of the target retrieval result; An evidence verification subunit is used to determine that the target retrieval result is information of the target standardized software asset when all fields in the target retrieval result are included in the target evidence set. The unsubstantiated determination subunit is used to determine, when there is an unsubstantiated field in the target retrieval result that is not included in the target evidence set, that the target retrieval result is information of the target standardized software asset with an unsubstantiated label, and to mark the unsubstantiated field as unsubstantiated content.

[0094] The embodiments in this specification are described in a progressive manner. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant details can be found in the method section.

[0095] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0096] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main 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.

[0097] The features described in the embodiments of this specification can be substituted for or combined with each other, so that those skilled in the art can implement or use this application.

[0098] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for software asset management, characterized in that, include: The original software assets from multiple data carriers are broken down into multiple standard objects; Based on the various types of standard objects, calculate the comprehensive similarity of each of the original software assets; The original software assets whose comprehensive similarity meets the preset requirements are identified as the same software asset, thus obtaining standardized software assets; A knowledge graph is built based on the standardized software assets mentioned above; Based on the target software asset query request, the knowledge graph is searched to obtain information about the target standardized software asset.

2. The method according to claim 1, characterized in that, The types of the standard objects include components, interface capabilities, data objects, and evidence fragments. The calculation of the comprehensive similarity of each of the original software assets based on multiple types of standard objects includes: Based on the various standard objects, calculate the name similarity, functional description similarity, interface parameter similarity, data object overlap, and person in charge overlap of each original software asset; The overall similarity of each original software asset is obtained by combining the name similarity, function description similarity, interface parameter similarity, data object overlap, and person in charge overlap of each original software asset.

3. The method according to claim 2, characterized in that, The calculation of name similarity, functional description similarity, interface parameter similarity, data object overlap, and responsible person overlap for each of the original software assets based on multiple types of standard objects includes: The name similarity is calculated based on the name field in the component; Calculate the functional description similarity based on the functional description text in the evidence fragment; Calculate the similarity of the interface parameters based on the interface parameters in the interface capabilities; Calculate the overlap of the data objects based on the data objects; Based on the responsible person field in any of the standard objects described, obtain the overlap of the responsible persons.

4. The method according to claim 3, characterized in that, The calculation of interface parameter similarity based on the interface parameters in the interface capabilities includes: Extract the set of interface parameters from the interface capabilities of each of the original software assets; The similarity of the interface parameters is calculated for the set of interface parameters to obtain the similarity of the interface parameters for each of the original software assets.

5. The method according to claim 3, characterized in that, The calculation of the overlap degree of the data objects based on the data objects includes: Extract the set of data object elements of the data objects of each of the original software assets; The similarity of the data object elements is calculated to obtain the overlap of the data objects of each original software asset.

6. The method according to claim 2, characterized in that, The determination that the original software assets whose comprehensive similarity meets the preset requirements are the same software assets includes: The name similarity, function description similarity, data object overlap, and person in charge overlap are weighted and calculated to obtain the multi-factor similarity of each original software asset. Two original software assets are determined to be the same software asset if the multi-factor similarity is greater than or equal to a first multi-factor threshold, the data object overlap is greater than or equal to a first object overlap threshold, and the interface parameter similarity is greater than or equal to a first interface parameter threshold.

7. The method according to claim 6, characterized in that, After determining that two original software assets have the same software asset, and that the multi-factor similarity is greater than or equal to a first multi-factor threshold, the data object overlap is greater than or equal to a first object overlap threshold, and the interface parameter similarity is greater than or equal to a first interface parameter threshold, the method further includes: Two original software assets are determined to be not the same software asset if the multi-factor similarity is less than a second multi-factor threshold, the data object overlap is less than a second object overlap threshold, or the interface parameter similarity is less than a first interface parameter threshold; the second multi-factor threshold is less than the first multi-factor threshold, and the second object overlap threshold is less than the first object overlap threshold.

8. The method according to claim 1, characterized in that, The construction of the knowledge graph based on the standardized software assets includes: An initial knowledge graph is constructed using the business domains, services, and components of the standardized software assets as nodes and the relationships between the nodes as edges. The confidence level of each edge is calculated based on the number of evidence items corresponding to each edge in the initial knowledge graph and the reliability of the source of each piece of evidence; the reliability of the source is related to the method of obtaining the evidence. By traversing each edge in the initial knowledge graph, multiple query paths are obtained; The path confidence of each query path is obtained based on the confidence of each edge; The query paths whose confidence level is lower than the preset confidence level are marked as low-association paths, thus obtaining the knowledge graph.

9. The method according to claim 1, characterized in that, Each edge in the knowledge graph has a corresponding set of evidence. The search for the target software asset based on the query request in the knowledge graph to obtain information about the target standardized software asset includes: Based on the target software asset query request, a search is performed on the knowledge graph to obtain the target search results; Obtain the target evidence set corresponding to the edge of the target retrieval result; If all fields in the target retrieval result are included in the target evidence set, the target retrieval result is determined to be information of the target standardized software asset. If there are unsubstantiated fields in the target search results that are not included in the target evidence set, the target search results are determined to be information of the target standardized software asset with an unsubstantiated label, and the unsubstantiated fields are marked as unsubstantiated content.

10. A device for software asset management, characterized in that, include: Unit splitting, unit acquisition, unit determination, unit construction, and retrieval; The splitting unit is used to split the original software assets from multiple data carriers into multiple types of standard objects; The acquisition unit is used to calculate the comprehensive similarity of each of the original software assets based on multiple types of standard objects. The determining unit is used to determine that the original software assets whose comprehensive similarity meets the preset requirements are the same software assets, thereby obtaining standardized software assets. The building unit is used to build a knowledge graph based on the standardized software assets; The retrieval unit is used to search the knowledge graph based on the target software asset query request to obtain information about the target standardized software asset.

Images