Software asset reusing method and system

Abstract

The invention discloses a software asset reuse method and system, and relates to the technical field of data processing, and the method comprises the steps: receiving the demand information of software assets of a target project input by a user, and extracting the attribute characteristics of the demand information; retrieving and matching candidate assets in a pre-constructed software asset library through a preset similarity matching algorithm based on the attribute features; performing compatibility verification on the matched candidate assets, if the verification is passed, outputting the candidate assets and deploying the candidate assets to a user target environment, and if the verification fails, generating an adaptive adjustment scheme; and performing parameter optimization and code adaptation on the candidate assets according to the adaptation adjustment scheme, forming deployable reused assets, and deploying the reused assets to a user target environment. The method has the advantages of accurate software asset analysis, dynamic compatibility verification and adaptive optimization.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a method and system for reusing software assets. Background Technology

[0002] In software development, reusing code, modules, or components (i.e., software asset reuse) is a core means to improve development efficiency and reduce R&D costs. However, existing technologies have significant shortcomings in practical applications. First, the accuracy of matching requirements with assets is low. Existing asset retrieval is mostly based on keyword or simple metadata matching, ignoring functional semantic understanding and fine-grained compatibility analysis of the technology stack. For example, when a user needs to reuse a "payment interface component based on Java 11," existing methods may only match the development language tag while ignoring interface protocols (such as differences between REST and gRPC) or dependency version conflicts (such as SpringBoot 2.7 and JDK). Firstly, the compatibility issues (17) lead to poor usability of search results, requiring extensive manual screening. Secondly, compatibility verification is inefficient. Existing technologies rely on manual testing or static code scanning to detect interface parameter types and runtime dependency conflicts, failing to dynamically capture type inference errors (such as the target system requiring Long parameters while the asset interface passes Integer) and implicit symbolic reference issues (such as dynamically loaded undefined JNI libraries), resulting in long verification times and high false negative rates. Finally, existing technologies mostly fix incompatible assets through local code modifications or dependency downgrading, lacking a systematic strategy for adaptation and adjustment. For example, dependency conflicts often require manual adjustment of the Maven dependency tree or modification of compilation configuration, which can easily introduce new errors. Performance tuning relies on developer experience and lacks quantifiable goals (such as response time constraints) and optimization algorithm drivers, making it difficult for reused assets to meet the performance requirements of the target environment.

[0003] The aforementioned shortcomings result in low software asset reuse rates and high adaptation costs, particularly in large-scale distributed systems and microservice architectures, thus hindering software development efficiency. Therefore, an asset reuse solution that deeply integrates semantic understanding, dynamic compatibility verification, and automated adaptation is needed. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a method and system for reusing software assets.

[0005] A method for reusing software assets includes: receiving user-inputted requirement information for software assets of a target project, and extracting attribute features from the requirement information; based on the attribute features, retrieving and matching candidate assets in a pre-built software asset library using a preset similarity matching algorithm; performing compatibility verification on the matched candidate assets, and if the verification passes, outputting the candidate assets and deploying them to the user's target environment, and if the verification fails, generating an adaptation and adjustment scheme; optimizing parameters and adapting code for the candidate assets according to the adaptation and adjustment scheme to form deployable reusable assets, and deploying the reusable assets to the user's target environment.

[0006] Optionally, extracting the attribute features of the requirement information includes: parsing and identifying the functional entities and operational constraints in the requirement information, and generating a structured intermediate representation containing functional semantics; based on the structured intermediate representation, extracting technology stack identifiers, wherein the technology stack identifiers include programming language version, dependent library name, and minimum version number; associating and mapping the functional semantics with the technology stack identifiers and constructing a feature matrix to form the attribute features of the requirement information.

[0007] Optionally, retrieving and matching candidate assets in a pre-built software asset library using a preset similarity matching algorithm includes: obtaining a demand feature vector based on the feature matrix of attribute features, and obtaining the asset feature vector of each software asset in the software asset library; obtaining the similarity between the demand feature vector and the asset feature vector; and selecting the software assets with the highest similarity that exceed a preset threshold as candidate assets for matching.

[0008] Optionally, compatibility verification of the matched candidate assets includes: determining whether the parameter types passed in the candidate asset interface match the types required by the target project context; if a type conflict exists, it is recorded as a first type of incompatibility; loading the candidate asset in the sandbox environment and monitoring the runtime dependency loading status and undefined symbolic references; if there are abnormal dependency loading statuses or undefined symbolic references, they are recorded as second type of incompatibility; if either the first type of incompatibility or the second type of incompatibility exists or both exist, the verification fails; otherwise, the verification passes.

[0009] Optionally, if verification fails, the adaptation adjustment scheme is generated as follows: for the first type of incompatibility, type casting wrapper layer code is generated, wherein the type casting wrapper layer code includes input parameter type conversion and return value format adaptation; for the second type of incompatibility, a virtual environment configuration script is generated, wherein the virtual environment configuration script isolates conflicting dependencies by creating an independent namespace; and the type casting wrapper layer code and the virtual environment configuration script are integrated to form an adaptation adjustment scheme.

[0010] Optionally, optimizing the parameters and adapting the code of candidate assets to form deployable reusable assets according to the adaptation and adjustment scheme includes: adjusting the candidate assets according to the adaptation and adjustment scheme, obtaining the objective function, and obtaining the constraint that the response time does not exceed the threshold specified by the requirements; optimizing the adjusted candidate assets using a genetic algorithm based on the objective function and constraint adjustment; and testing the optimized candidate assets with actual response time. If the actual response time is less than the threshold of the requirements, the candidate asset is recorded as a deployable reusable asset.

[0011] Optional, the objective function includes: ;in, For memory weighting coefficients, This is the load weighting coefficient. This is the weighting coefficient for technology debt. This represents the current memory usage. Total system memory This represents the current load. For the number of system cores, For code duplication rate, For cyclomatic complexity, This represents the number of times the device can be reused.

[0012] A software asset reuse system is also provided, comprising: a feature acquisition module for receiving user-inputted software asset requirement information for a target project and extracting attribute features from the requirement information; a matching module for retrieving and matching candidate assets in a pre-built software asset library based on the attribute features using a preset similarity matching algorithm; a verification and adjustment module for performing compatibility verification on the matched candidate assets, outputting the candidate assets and deploying them to the user's target environment if the verification passes, and generating an adaptation and adjustment scheme if the verification fails; and a reuse decision module for optimizing parameters and adapting code for the candidate assets according to the adaptation and adjustment scheme to form deployable reusable assets, and deploying the reusable assets to the user's target environment.

[0013] Optionally, the feature acquisition module is also used to: parse and identify the functional entities and operational constraints in the requirement information, and generate a structured intermediate representation containing functional semantics; extract technology stack identifiers based on the structured intermediate representation, wherein the technology stack identifiers include programming language version, dependent library name and minimum version number; associate and map the functional semantics with the technology stack identifiers and construct a feature matrix to form the attribute features of the requirement information.

[0014] Optionally, the matching module is also used to: obtain the requirement feature vector based on the feature matrix of the attribute features, and obtain the asset feature vector of each software asset in the software asset library; obtain the similarity between the requirement feature vector and the asset feature vector; and filter out the software assets with the highest similarity that exceed a preset threshold as candidate assets for matching.

[0015] The beneficial effects of this invention are reflected in: In the entire software asset reuse methodology, firstly, an intelligent feature extraction mechanism based on natural language processing and regular expressions is used to accurately analyze the functional semantics and technology stack constraints in the requirement text, constructing a multi-dimensional feature matrix. This solves the problem of traditional keyword matching neglecting interface protocol differences and dependency version conflicts. For example, it accurately identifies the distributed transaction characteristics and Spring in the requirement of "Java microservice components". Cloud version requirements are in place to avoid functional mismatches. Furthermore, multi-dimensional feature vector similarity calculations comprehensively evaluate functional matching, technology stack compatibility, and performance metrics, prioritizing globally optimal candidate assets. For example, in NoSQL middleware selection, connection pool functionality and Redis version compatibility are considered, reducing manual screening costs. Further, compatibility verification combining static type inference and dynamic sandbox testing comprehensively detects parameter type conflicts and runtime dependency anomalies, such as identifying Java time API differences and log4j version conflicts, reducing the false negative rate to less than 5% compared to traditional static scanning. Furthermore, through genetic algorithm-driven parameter optimization and system adaptation, resource utilization and technical debt risks are automatically balanced under hard constraints. For example, when optimizing database middleware thread pool configuration, memory usage is reduced by 30% while ensuring response time meets standards, and code complexity monitoring suppresses the increase in maintenance costs. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0017] Figure 1 This is a schematic diagram illustrating the steps of one implementation of the software asset reuse method of the present invention; Figure 2 This is a schematic diagram of a portion of steps S1 in the software asset reuse method of the present invention; Figure 3 This is a schematic diagram of a portion of steps S2 in the software asset reuse method of the present invention; Figure 4 This is a schematic diagram of a portion of steps S3 in the software asset reuse method of the present invention; Figure 5 This is a schematic diagram of another part of the steps in S3 of the software asset reuse method of the present invention; Figure 6 This is a schematic diagram of a portion of step S4 in the software asset reuse method of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0019] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0020] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0021] like Figure 1 As shown, a method for reusing software assets is provided, including: S1. Receive the software asset requirement information of the target project input by the user, and extract the attribute features of the requirement information; S2. Based on the attribute features, candidate assets are retrieved and matched in the pre-built software asset library using a preset similarity matching algorithm; S3. Perform compatibility verification on the matched candidate assets. If the verification passes, output the candidate assets and deploy them to the user's target environment. If the verification fails, generate an adaptation and adjustment plan. S4. Optimize the parameters and adapt the code of the candidate assets according to the adaptation and adjustment scheme to form deployable reusable assets, and deploy the reusable assets to the user's target environment.

[0022] In this embodiment, it should be noted that in S1, intelligent feature extraction technology is used to transform the user-inputted software asset requirements into structured and quantifiable attribute features. First, the system uses natural language processing technology to parse the requirement text, identifying core functional entities (such as "payment interface" and "image recognition engine") and operational constraints (such as "response time ≤ 200ms, support for concurrent requests ≥ 1000 QPS"), generating an intermediate representation containing semantic relationships. For example, when a user describes "requiring Java microservice components that support distributed transactions," the system will extract "distributed transactions" and "microservice architecture" as functional entities, and identify "Java" as a core element of the technology stack. Next, based on regular expression matching of technology stack identifiers, the system accurately extracts programming language versions (such as "Java 11"), dependency library names, and version constraints (such as "Spring Cloud 2021.0.3"), ensuring fine-grained feature capture of the technology stack. Finally, the functional semantics and technology stack identifiers are integrated into a multi-dimensional feature matrix through an association mapping mechanism. The functional requirement dimension evaluates the semantic matching degree (such as interface protocol consistency), the technology stack dimension quantifies version compatibility (such as dependency conflict detection), and the performance dimension verifies the constraint satisfaction capability (such as throughput threshold), forming a computable feature system that comprehensively describes the requirements.

[0023] Furthermore, taking the user requirement of "developing a real-time log analysis module based on machine learning, requiring a Python 3.9+ environment and relying on TensorFlow 2.8 or higher" as an example: the system first parses the requirement text, identifies "machine learning" and "real-time log analysis" as core functions, and extracts "real-time processing latency <50ms" as a performance constraint; then, it extracts the technology stack identifiers "Python 3.9" and "TensorFlow ≥ 2.8" through regular expressions, and detects implicit dependencies (such as the NumPy version needing to be compatible with TensorFlow); finally, it constructs a feature matrix, where the functional dimension evaluates whether the asset contains supervised learning algorithms and streaming data processing interfaces, the technology stack dimension verifies the Python interpreter version and CUDA driver compatibility, and the performance dimension matches memory usage and computation latency indicators, thus providing accurate input for subsequent intelligent matching and verification.

[0024] In S2, a multi-dimensional feature matching mechanism intelligently filters candidate assets from the software asset library that highly match user needs. The system first transforms the feature matrix generated in S1 into numerical feature vectors, where each dimension corresponds to a quantitative indicator of functional matching degree, technology stack compatibility, and performance satisfaction. For example, the functional matching degree dimension is weighted based on interface protocol consistency (e.g., the conversion cost between RESTful API and gRPC) and algorithm logic similarity (e.g., the matching degree of machine learning model architecture); technology stack compatibility assesses programming language version adaptability (e.g., the backward compatibility of Java 11 and Java 8) and dependency conflict risks (e.g., the binding relationship between Spring Boot version and JDK). Subsequently, a similarity algorithm is used to comprehensively calculate the global matching degree between the requirement vector and the asset vector, prioritizing assets with comprehensive functional coverage, seamless technology stack compatibility, and satisfactory performance, avoiding misselection due to single-dimensional matching.

[0025] Furthermore, assuming the user needs to reuse a "NoSQL database middleware that supports high-concurrency queries, requires compatibility with Go 1.18 and depends on Redis 6.2 or later," the system matches the requirement feature vector with the middleware features in the asset repository: in terms of functionality, assets supporting connection pool management and distributed caching are filtered; in terms of technology stack, components supporting only Go 1.16 or Redis 5.0 are excluded; and in terms of performance, throughput metrics are verified to meet concurrency requirements. The final recommended candidate assets not only implement query optimization interfaces but also ensure Redis 6.2 compatibility with the target environment through dependency isolation strategies, thus achieving an optimal balance between functionality, compatibility, and performance.

[0026] In S3, a combined static and dynamic verification mechanism ensures deep compatibility between candidate assets and the target project. First, the system uses a type inference algorithm to statically analyze the candidate asset interfaces, constructing a parameter type dependency graph, deriving the input and output type constraints of the interface methods, and verifying consistency with the actual parameter types in the target project's call context. For example, when an asset interface declares that it accepts string type parameters while the target project passes integer variables, the algorithm traces the variable assignment path through data flow analysis, identifies the feasibility of implicit type conversion (e.g., whether automatic conversion from integer to string is supported), and marks any non-conversion scenarios as the first type of incompatibility. Second, candidate assets are dynamically loaded in a sandbox environment, and the dependency loading process is monitored in real time. Class loading exceptions (e.g., NoSuchMethodError) and undefined symbolic references (e.g., missing JNI libraries) caused by version conflicts are captured. Simultaneously, test case sets are injected to verify the stability of cross-component call chains, and any runtime exceptions are recorded as the second type of incompatibility.

[0027] Furthermore, taking the example of the target project using Java 17 to call a historical asset: Static analysis revealed that the asset's interface requires a java.util.Date type parameter, while the target project's context passes a java.time.Local DateTime type. Since the Java 8 time API lacks automatic conversion logic with older date classes, the type inference algorithm classifies it as a first-category incompatibility. During the dynamic verification phase, the sandbox environment detected that the asset depends on log4j 1.x, while the target project has been upgraded to log4j 2.17. This triggers a Class Not Found Exception during loading, and the system marks it as a second-category incompatibility. After verification failure, the system generates type adaptation layer code to convert Local DateTime to Date and creates an independent class loader to isolate the log4j 1.x dependency, ensuring the asset runs safely in an isolated environment.

[0028] In S4, dynamic optimization and testing ensure that adapted assets run stably and efficiently in the target environment. The system first refactors the candidate assets' code based on the adaptation and adjustment plan, such as inserting type conversion wrapper layers or configuring dependency isolation environments. Then, it globally optimizes key parameters based on multi-dimensional optimization goals (such as memory usage, response latency, and code maintainability). A genetic algorithm iteratively adjusts configuration parameters such as thread pool size and caching strategies, prioritizing solutions with high resource utilization and low risk of technical debt accumulation while meeting hard constraints on response time. For example, for database middleware in high-concurrency scenarios, the algorithm balances connection pool size and transaction timeout thresholds to avoid memory overflow while ensuring query throughput meets targets, while also constraining code complexity growth to no more than 20% of the original version.

[0029] Furthermore, taking the adapted real-time log analysis component as an example: the system optimized parameters such as the number of stream processing threads and batch write intervals to ensure that the requirement of "processing latency <50ms" could still be met under resource-constrained environments. During the optimization process, the algorithm selected a configuration combination with a moderate number of threads and asynchronous refresh enabled, which reduced peak CPU load and improved stability by reducing synchronization lock contention. Finally, in simulated log flood tests, the optimized component successfully handled sudden traffic surges without data loss, and the response time remained within the threshold. The system marked it as a deployable asset and integrated it into the target project's microservice cluster.

[0030] In summary, the entire software asset reuse methodology firstly utilizes an intelligent feature extraction mechanism based on natural language processing and regular expressions to accurately analyze the functional semantics and technology stack constraints in the requirement text, constructing a multi-dimensional feature matrix. This solves the problem of traditional keyword matching neglecting interface protocol differences and dependency version conflicts. For example, it accurately identifies the distributed transaction characteristics and Spring Cloud in the requirement of "Java microservice components". Version requirements are addressed to avoid functional mismatches. Furthermore, multi-dimensional feature vector similarity calculations comprehensively evaluate functional matching, technology stack compatibility, and performance metrics, prioritizing globally optimal candidate assets. For example, in NoSQL middleware selection, connection pool functionality and Redis version compatibility are considered, reducing manual screening costs. Further, compatibility verification combining static type inference and dynamic sandbox testing comprehensively detects parameter type conflicts and runtime dependency anomalies, such as identifying Java time API differences and log4j version conflicts, reducing the false negative rate to less than 5% compared to traditional static scanning. Moreover, through genetic algorithm-driven parameter optimization and system adaptation, resource utilization and technical debt risks are automatically balanced under hard constraints. For example, when optimizing database middleware thread pool configuration, memory usage is reduced by 30% while ensuring response time meets standards, and code complexity monitoring suppresses the increase in maintenance costs. In summary, the entire solution achieves end-to-end automation from requirements analysis, intelligent recommendation, compatibility verification to adaptive optimization, improving asset matching accuracy to over 90% and shortening the adaptation cycle by 70%. Especially in large-scale microservice architectures, it effectively solves the problem of mesh dependencies among components through dependency isolation and dynamic tuning, increasing asset reuse rate by more than 3 times and providing efficient and reliable technical support for agile development.

[0031] like Figure 2 As shown, in one embodiment, the attribute features for extracting the demand information in S1 include: S11. Parse and identify the functional entities and operational constraints in the requirements information, and generate a structured intermediate representation containing functional semantics; S12. Based on the structured intermediate representation, extract the technology stack identifier, wherein the technology stack identifier includes the programming language version, the name of the dependent library, and the minimum version number; S13. Associate and map functional semantics with technology stack identifiers and construct a feature matrix to form attribute features of requirement information.

[0032] In this implementation, it should be noted that in S11, Natural Language Processing (NLP) technology is used to transform the user's input text requirements into a structured semantic representation, accurately capturing functional entities and operational constraints. The system first performs word segmentation, dependency parsing, and semantic role labeling on the requirement text to identify core functional entities (such as "distributed transaction" and "log analysis engine") and their associated operational constraints (such as "response time ≤ 200ms" and "supports high concurrency"), while simultaneously resolving the logical relationships between functions (such as the dependency relationship between "real-time processing" and "streaming data input"). For example, when a user describes "requiring an order processing module based on a microservice architecture, supporting transaction rollback and asynchronous communication," the system extracts "order processing module" as the core functional entity, associates "transaction rollback" and "asynchronous communication" as sub-functions, and identifies "microservice architecture" as a deployment constraint. Furthermore, by mapping functional entities to domain concepts through an ontology knowledge base (such as associating "transaction rollback" with ACID properties), a tree-like semantic structure is constructed, where the root node represents the main function, and child nodes refine functional attributes and constraints, forming a machine-parseable intermediate representation.

[0033] Furthermore, taking the user requirement of "developing an image processing service that supports multilingual recognition, integrating an OCR engine and ensuring low latency" as an example: The NLP model first segments the functional entities "multilingual recognition," "image processing service," and "OCR engine," and parses out the operational constraint "low latency." Through semantic role labeling, "integration" is identified as the action, and "OCR engine" is bound as the recipient. Simultaneously, "low latency" acts as an adverb modifying the core service. The generated intermediate representation has "image processing service" as the root node, with the "multilingual recognition" functional branch attached to it, and "OCR engine integration" as a dependent component. A performance constraint node of "maximum latency ≤ 100ms" is also added. This structured representation clearly defines the functional hierarchy and constraints, providing accurate input for subsequent technology stack extraction and compatibility verification.

[0034] In S12, regular expression matching is used to accurately extract technology stack identifiers from the structured intermediate representation generated in S11. The system predefines multiple sets of regular expression rules, targeting programming language versions (e.g., matching major and minor version numbers in "Python 3.9+"), dependency library names, and version constraints (e.g., recognizing library names and version operators in "SpringBoot>=2.7"). For example, for version identifiers, the rule set covers common version formats (e.g., semantic version "major version.minor version.revision number" and the abbreviation "v1.x") and parses version operators (e.g., "~" for compatible versions, "^" for locking the major version). The system traverses the text nodes of the structured intermediate representation, performing pattern matching on each technology stack-related description (e.g., "requires JDK17" or "depends on Redis≥6.2") to extract standardized technology stack elements, while filtering out irrelevant noise words (e.g., "recommended use" "suggested configuration") to ensure the purity of the extracted results. In addition, for complex dependencies (such as "TensorFlow 2.8 requires CUDA 11.2"), the system identifies implicit dependencies through dependency analysis and supplements the version constraints of related libraries.

[0035] Furthermore, taking the user requirement of "building a web application based on React 18.2, compatible with TypeScript 4.8 and above" as an example: The system first locates the technology stack description node in the structured intermediate representation and uses regular expression rules to match library names and versions. For "React 18.2", the rule extracts the library name as "React" and the version as "18.2", with the default constraint being an exact match; for "TypeScript 4.8 and above", the rule recognizes the version operator "≥" and records the minimum version "4.8". Simultaneously, the system detects that React 18.2 depends on a specific Babel plugin version and supplements the dependency "@babel / preset-react^7.18.6" through context association. Finally, the technology stack identifier set contains the exact version of React, the minimum version of TypeScript, and the compatibility range of the associated toolchain, providing structured input for subsequent compatibility verification.

[0036] In S13, an association mapping mechanism integrates functional semantics and technology stack identifiers into a multi-dimensional feature matrix, achieving a structured and quantitative expression of requirement attributes. The system first defines three core dimensions of the matrix: interface matching degree, technology stack compatibility, and performance satisfaction. The interface matching degree dimension calculates the protocol consistency of functional entities (e.g., the conversion cost between REST and gRPC) and the alignment of interface parameters (e.g., the matching of input and output data structures) based on semantic similarity. The technology stack compatibility dimension quantifies the compatibility of programming language versions (e.g., the syntax differences between Python 3.9 and 3.8) and the risk of dependency library version conflicts (e.g., the compatibility matrix between Spring Boot and JDK). The performance satisfaction dimension evaluates the degree of matching between asset operation indicators (e.g., throughput, latency) and requirement constraints. Each dimension is further subdivided into sub-indicators; for example, interface matching degree includes sub-items such as protocol type, parameter type, and return format, while technology stack compatibility covers sub-items such as language version, dependency version, and platform constraints, forming a hierarchical evaluation system.

[0037] Furthermore, taking the user requirement of "developing a real-time video stream analysis service, requiring support for H.265 encoding and relying on FFmpeg 5.0+" as an example: the system maps "real-time video stream analysis" in the functional semantics to the interface matching dimension, evaluating whether candidate assets support the H.265 encoding / decoding interface and streaming media transmission protocol; the technology stack identifier "FFmpeg≥5.0" is mapped to the technology stack compatibility dimension, detecting whether the FFmpeg version relied upon by the asset meets the requirements, and analyzing its compatibility with the target project's audio library (such as libavcodec); the performance dimension quantifies whether video processing latency and concurrent stream processing capabilities meet the required thresholds. In the final generated feature matrix, the interface matching weight reflects the protocol adaptation cost, the technology stack compatibility marks the version conflict risk level, and the performance satisfaction indicates whether resource consumption and response time meet the standards, thus providing multi-dimensional quantitative basis for accurate matching.

[0038] like Figure 3 As shown, in one embodiment, step S2, retrieving and matching candidate assets in a pre-built software asset library using a preset similarity matching algorithm, includes: S21. Obtain the requirement feature vector based on the feature matrix of attribute features, and obtain the asset feature vector of each software asset in the software asset library. S22. Obtain the similarity between the demand feature vector and the asset feature vector; S23. Select the software assets with the highest similarity that exceed the preset threshold and use them as candidate assets for matching.

[0039] In this implementation, it should be noted that in S21, a quantization conversion mechanism is used to transform the multi-dimensional feature matrix generated in S1 into a numerical feature vector, achieving a computable match between requirements and assets. The system defines scoring rules for sub-indicators for each dimension (functionality matching, technology stack compatibility, and performance satisfaction). For example, functionality matching is weighted based on interface protocol consistency (e.g., the difficulty of converting between REST and gRPC) and algorithm logic similarity (e.g., the matching degree of machine learning model architecture); technology stack compatibility is calculated based on programming language version adaptability (e.g., differences in major version numbers) and dependency library conflict risks (e.g., overlapping version ranges); performance satisfaction is scored based on the degree of deviation between indicators such as throughput and latency and the requirement constraints. After normalization, each sub-indicator is aggregated into the numerical values ​​of each dimension of the feature vector according to preset weights. For example, functionality matching accounts for the first 30% of the vector elements, technology stack compatibility accounts for the middle 40%, and performance satisfaction accounts for the last 30%, forming a unified dimension of the requirement feature vector. Simultaneously, the feature matrix of each asset in the asset library is converted into an asset feature vector using the same rules, ensuring vector space alignment.

[0040] Furthermore, taking the user requirement of "high-availability message queue service, supporting the AMQP protocol and compatible with Erlang / OTP25" as an example: the system converts the AMQP protocol support and message persistence mechanism matching degree in the functional dimension into a functional matching degree score; in the technology stack dimension, a score is generated based on the compatibility of Erlang version and OTP dependency; and in the performance dimension, throughput and fault recovery time compliance rate are evaluated. In the requirement feature vector, the first part reflects the protocol and architecture matching, the middle part marks Erlang version adaptability, and the last part quantifies performance indicators. In the feature vector of a message queue asset in the asset library, the functional part shows that it supports AMQP 1.0 but lacks specific extended protocols, the technology stack part marks the major version difference between Erlang / OTP24, and the performance part shows high throughput but long recovery time. By calculating the distance in the vector space, the overall matching degree between the asset and the requirement can be quantified.

[0041] In S22, the cosine similarity algorithm quantifies the matching degree between demand feature vectors and asset feature vectors, enabling a multi-dimensional comprehensive evaluation. Cosine similarity measures the consistency of overall trends by calculating the directional proximity of two vectors, rather than simple numerical differences. Specifically, the system normalizes the demand and asset vectors to unit length and calculates the cosine of their angle. The closer this value is to 1, the more consistent their directions are in multi-dimensional space, and the higher the matching degree. For example, if the demand vector has a high weight in the functional matching dimension, and an asset scores highly in this dimension, even if its technology stack compatibility is slightly lower, it may still obtain a high similarity score due to directional consistency and thus be prioritized for recommendation.

[0042] Furthermore, taking the user requirement of "high-concurrency message middleware must support the AMQP protocol" as an example: in the requirement vector, functional matching degree (AMQP protocol support, message persistence) is dominant, followed by technology stack compatibility (Erlang version) and performance (throughput). A certain message middleware in the asset library fully matches AMQP 1.0 in terms of functionality, and its score in the technology stack dimension is slightly lower due to a slightly lower Erlang version, but its performance significantly exceeds the requirement threshold. When calculating cosine similarity, because the strong consistency in the functional dimension dominates the convergence of directions, even if there are slight deviations in other dimensions, this asset is still selected as a candidate due to its high overall directional matching degree, reflecting the algorithm's priority response to core requirements.

[0043] In S23, a ranking and threshold filtering mechanism selects high-quality assets that highly match user needs from the candidate assets. The system first sorts all assets by similarity score in descending order, ensuring that the highest-scoring assets are presented first. Then, a preset similarity threshold (e.g., 0.7) is applied to remove assets with scores below the threshold, avoiding the recommendation of low-quality or partially matched components. For example, if an asset scores extremely high in a functional dimension but has a slight conflict in its technology stack, it is retained as a candidate if its overall similarity still exceeds the threshold; conversely, if an asset matches the functionality but has an incompatible technology stack causing its score to fall below the threshold, it is filtered out. This mechanism ensures that the recommendation results are both highly relevant and usable.

[0044] Furthermore, taking the user requirement of "a distributed caching component that is compatible with Java 11 and supports automatic cluster scaling" as an example: Component A in the asset library fully supports cluster scaling, but its reliance on Java 8 results in low technology stack compatibility, with a similarity score of 0.68; Component B partially supports scaling but is fully compatible with Java 11, scoring 0.72. If the threshold is set to 0.7, the system will select Component B as a candidate, even though its functionality is slightly lacking, because its technology stack is fully compatible and its total score meets the requirement, while Component A is excluded because it does not meet the threshold. This process balances functionality and compatibility, ensuring that the recommended results meet the minimum quality requirements.

[0045] like Figure 4 As shown, in one implementation, the compatibility verification of the matched candidate assets in S3 includes: S31. Determine whether the parameter type passed in the candidate asset interface matches the type required by the target project context. If there is a type conflict, record it as the first type of incompatible item. S32. Load candidate assets in the sandbox environment and monitor the runtime dependency loading status and undefined symbol references. If there are abnormal dependency loading status or undefined symbol references, record them as the second type of incompatible items. S33. If either the first type of incompatibility or the second type of incompatibility exists, or both exist simultaneously, the verification fails; otherwise, the verification passes.

[0046] In this implementation, it should be noted that in S31, a static type deduction algorithm is used to systematically verify the type compatibility between the candidate asset interface parameters and the target project context. The system constructs a parameter type dependency graph, tracing variable assignments, function return values, and type conversion operations in the target project's call chain to deduce the specific types of the actually passed parameters (such as the runtime type of variables or generic instantiation types in dynamic languages). The constraint solver then compares the types of the formal parameters declared in the asset interface (such as the declared interface requirement List) with these parameters. <string>If a type constraint conflict is detected (e.g., the actual List is passed), <object>If a type lacks covariance support, it is marked as a first-class incompatible item. The algorithm covers implicit type conversion rules (such as automatic promotion from integer to long integer) and custom type adaptation logic to ensure that only safe conversions are allowed, avoiding data loss or logical errors.

[0047] Furthermore, taking the example of the target project using the Java New Time API (Local Date Time) to call the historical asset interface (declaring that it accepts the java.util.Date parameter): the type inference algorithm analyzes the call context and finds that the passed parameter is of type LocalDateTime, while the asset interface has no automatic conversion logic (because LocalDateTime is not a subclass of Date). After confirming through data flow analysis that there is no explicit conversion code, the system determines that it is a type mismatch and records it as the first type of incompatibility. Similarly, if the asset interface requires Optional... <t>If the target item is passed a null raw object, the algorithm will identify type safety risks and mark it as incompatible.

[0048] In S32, a sandbox environment is used to simulate the runtime ecosystem of the target project, dynamically verifying the deep compatibility between candidate assets and the host environment. The sandbox environment uses containerization technology to build an isolated virtual execution space, completely replicating the target project's operating system kernel version, runtime dependency tree, and dynamic link library configuration. When loading candidate assets, the system uses bytecode instrumentation technology to monitor the behavior of the class loader in real time, tracking the loading path and version information of third-party dependency libraries, and intercepting query requests to the system symbol table during dynamic linking. For implicit dependencies not explicitly declared (such as local shared libraries called via JNI), the sandbox environment verifies them using a pre-defined symbol whitelist mechanism: if an asset attempts to load a local library not registered in the target environment's manifest (such as a missing CUDA driver library or a custom JNI module), the system will trigger an undefined symbol reference exception and record the call stack. Simultaneously, the sandbox environment injects test case sets covering multi-threaded, high-load boundaries to simulate resource contention in real business scenarios, proactively exposing runtime errors caused by dependency version differences (such as dynamic proxy class generation failures or thread pool resource leaks).

[0049] Furthermore, taking a certain image processing asset as an example, its runtime relies on a proprietary GPU acceleration library, but the target production environment is only equipped with CPU computing nodes. When the sandbox environment loads this asset, it is monitored that it calls the cudnnGetConvolutionForwardAlgorithm_v7 function through the JNI interface, while the host environment's symbol table does not define this CUDA-specific symbol. The system immediately catches the "UnsatisfiedLinkError" exception during the dynamic linking phase, and, combined with stack trace analysis, determines the missing cudnn64_7.dll dynamic library dependency, marking it as a second type of incompatibility. In addition, the sandbox discovered during stress testing that the asset relies on the nested parallel region feature of OpenMP 3.0 during concurrent processing, while the OpenMP 4.5 configured in the target environment caused thread scheduling deadlock due to parallel model reconstruction. Such implicit behavioral differences were also accurately identified and included in the compatibility report, providing a basis for subsequent dependency isolation solutions.

[0050] In S33, a logical aggregation mechanism is used to comprehensively evaluate the static and dynamic verification results to determine whether candidate assets meet the target environment compatibility requirements. If either the first type of incompatibility (type conflict) or the second type of incompatibility (runtime dependency anomaly) has at least one unresolved conflict point, the system determines that the verification has failed; conversely, if neither type of detection has anomaly records, the verification has passed. During the determination process, the system constructs an incompatibility association graph, analyzes the causal relationships between conflicts (such as dependency version conflicts may indirectly lead to type inference errors), avoids repeatedly marking the same root cause problem, and generates a visual report annotating the specific conflict location and severity level, providing priority guidance for subsequent adaptation solutions.

[0051] Furthermore, taking a candidate asset that supports asynchronous task scheduling as an example: static verification reveals that its interface requires the return of a Future. <t>The type, and the target project context, uses a reactive programming framework to return Mono. <t>The type, lacking implicit conversion logic, was marked as a first-category incompatibility item. During dynamic verification, the sandbox environment detected that the asset depended on an older version of Netty 4.1, which conflicted with the thread model of the Netty 5.0 already integrated in the target project, triggering an "EventLoopGroup undefined method" exception and being marked as a second-category incompatibility item. The system determined that both types of incompatibility items coexisted, verification failed, and the adaptation process was triggered. Conversely, if the interface parameter types of a logging component were completely matched and there were no exceptions in dependency loading during sandbox testing, verification passed and deployment was initiated directly.

[0052] like Figure 5 As shown, in one implementation, if verification fails in step S3, the generation of an adaptation adjustment scheme includes: S34. For the first type of incompatible item, generate type casting wrapper layer code, wherein the type casting wrapper layer code includes input parameter type conversion and return value format adaptation; S35. For the second type of incompatible items, generate a virtual environment configuration script, wherein the virtual environment configuration script isolates conflicting dependencies by creating an independent namespace; S36. Integrate the type casting wrapper layer code and virtual environment configuration script to form an adaptation and adjustment scheme.

[0053] In this implementation, it should be noted that in S34, a type adaptation intermediate layer is created through a code generation engine for the first type of incompatible items to resolve the structural conflict between interface parameters and return values. This engine reverse-engineers the interface contracts of candidate assets based on type inference results, analyzes the data flow type characteristics of the target project's call context, and automatically designs conversion logic: For input parameters, a type mapping function is generated to convert the data type passed by the target project (e.g., Java 8's LocalDateTime) into a compatible type declared by the asset interface (e.g., java.util.Date), achieving seamless conversion by injecting a serializer or bridging adapter (e.g., calling LocalDateTime.toInstant() combined with Date.from()); for return values, a reverse conversion chain is constructed to map the data type output by the asset (e.g., the JsonNode tree structure generated by the old JSON parser) to the target project's expected data model (e.g., the deserialization result based on POJO), ensuring semantic consistency of data during cross-component transmission. The conversion layer code is embedded into the call chain through compile-time weaving or dynamic proxy mechanisms, avoiding intrusive modifications to the original asset code.

[0054] Furthermore, taking a scenario compatible with reactive programming frameworks as an example: when the candidate asset interface returns a Future... <order>The target project requires Mono <order>At this time, the system generates asynchronous adapter code, which encapsulates the Future as a reactive stream using the Mono.fromFuture() method. Simultaneously, the Scheduler thread scheduler on the input side converts blocking calls to non-blocking mode. For collection type parameters (such as the asset interface requiring a List...), ... <string>The target project conveys Flux <string>The adapter automatically performs real-time conversion from reactive streams to batch processing containers. Through a buffered subscription mechanism, it triggers batch processing when the streaming data reaches a threshold, maintaining the calling conventions of asset interfaces while adapting to the target project's streaming programming model. This type of conversion layer ensures type safety while eliminating the performance overhead caused by additional abstractions through compiler optimizations.

[0055] In S35, a lightweight virtualized isolation environment is built to resolve the second type of incompatibility, enabling the parallel coexistence of conflicting dependencies. Customized environment configuration scripts are generated based on container orchestration technology to create independent dependency namespaces for candidate assets. Through a layered image building strategy, specific versions of dependency libraries required by the asset (such as log4j1.x) are encapsulated in an independent container layer, while the main dependency stack of the target project in the base image (such as log4j2.x) is preserved. File system overlay mechanisms are used to achieve path isolation of dependency files. For JVM ecosystem assets, a class loader isolation strategy script is dynamically generated, limiting the dependency loading scope through a custom ClassLoader to prevent low-version libraries from polluting the global classpath. The environment configuration script integrates a resource access proxy module to redirect asset requests for system resources (such as ports and storage volumes) to the virtual namespace, ensuring transparent isolation in case of conflicts with host environment resources.

[0056] Furthermore, taking database driver conflicts in a microservices scenario as an example: when a candidate asset depends on MySQLConnector 5.x while the target project has been upgraded to 8.x, the virtual environment script creates an independent container instance, deploys the 5.x driver internally, and exposes standardized data interfaces externally through a JDBC connection proxy. The proxy module automatically converts differing interfaces such as ResultSet cursor management and transaction isolation levels, while injecting a connection pool monitoring thread to prevent memory leaks. For scenarios requiring calls to the host environment's gRPC services, the script configures a bidirectional protocol conversion gateway to convert the HTTP / 1.1 interface used by the asset into gRPC streaming calls, maintaining the integrity of the asset's internal dependencies while achieving protocol-level integration with the existing microservices architecture.

[0057] In S36, a modular assembly technique is used to deeply integrate the type adaptation layer with the virtualized isolation environment, constructing a full-link adaptation solution. First, based on dependency graph analysis, the interaction interface between the type conversion layer and the isolation environment is analyzed, automatically generating bridging code to achieve bidirectional protocol compatibility: for scenarios where the type conversion layer needs to access services in the host environment, a service proxy gateway is injected to convert the calling protocol (e.g., converting REST calls to gRPC messages); for data streams output from assets within the isolation environment, a serialization interceptor unifies their format to the host environment standard (e.g., dynamic mapping between Protobuf and JSONSchema). Simultaneously, the configuration management module generates multi-environment deployment description files, defining resource quota allocation rules and cross-namespace communication strategies to ensure the horizontal scalability of the adaptation solution in a distributed architecture.

[0058] Furthermore, taking the adaptation of distributed transaction components as an example: the type conversion layer will convert the host environment's reactive transaction ID (ReactiveX's Singleton ID) into a singleton. <t>Future required to convert ) into assets <t>The system uses a different type of virtual environment, which encapsulates the older ZooKeeper election algorithm. During integration, the system creates a cross-container transaction coordination gateway, which encapsulates the election results generated within the virtual environment into a reactive event stream recognizable by the host environment via a gRPC streaming interface, while injecting a transaction ID conversion identifier into the protocol header. During deployment, the Kubernetes Operator automatically allocates independent Pod groups and configures network policies based on the description file, ensuring that the adapted components maintain strong internal consistency dependencies while non-intrusively accessing the service mesh.

[0059] like Figure 6 As shown, in one implementation, step S4 involves optimizing the parameters and adapting the code of the candidate assets according to the adaptation and adjustment scheme to form deployable reusable assets, including: S41. Adjust the candidate assets according to the adaptation and adjustment scheme, obtain the objective function, and obtain the constraint that the response time does not exceed the threshold specified by the requirements. Optimize the adjusted candidate assets using a genetic algorithm based on the objective function and constraint adjustment. S42. Perform actual response time tests on the optimized candidate assets. If the actual response time is less than the required threshold, the candidate asset is recorded as a deployable reusable asset.

[0060] In this implementation, it should be noted that in S41, a genetic algorithm is used to globally optimize the key operating parameters of the adapted assets, achieving a balance between resource efficiency and technical debt while meeting performance hard constraints. The algorithm constructs an initial population using adjustable parameters such as thread pool size, cache eviction policy, and batch processing threshold as gene sequences. The fitness of each individual is evaluated through simulated stress testing: in terms of memory usage, peak memory usage inside and outside the heap and garbage collection frequency are monitored; in terms of load, thread contention rate and task queue saturation are statistically analyzed; and in terms of technical debt, code duplication rate and module coupling are analyzed. In each iteration, the algorithm generates new parameter combinations through crossover mutation and prioritizes retaining individuals that meet the response time requirements and have the lowest overall cost, ultimately converging to the Pareto optimal solution set.

[0061] Furthermore, taking message queue middleware optimization as an example: when adjusting the number of consumer threads, message prefetch batch size, and disk flushing interval, the algorithm needs to maintain the end-to-end latency threshold under burst traffic. One generation of the algorithm used a large-batch prefetching combined with asynchronous flushing, which reduced CPU context switching overhead, but caused latency jitter due to Full GC triggered by memory cache bloat. After identifying this defect through the fitness function, the algorithm introduced a dynamic batch adjustment mechanism in the next generation, elastically scaling the prefetch amount according to the load level and adding a memory compression step before flushing. Ultimately, while increasing throughput by 30%, the GC pause time was controlled to the millisecond level, satisfying stability constraints.

[0062] In S42, end-to-end stress testing verifies the performance compliance of optimized assets, ensuring the effectiveness of parameter tuning results in real-world business scenarios. A distributed load testing cluster is built to simulate real user traffic patterns, injecting progressively increasing concurrent requests and collecting response latency, error rate, and resource consumption metrics in real time. Steady-state performance is dynamically evaluated using a sliding window algorithm. During testing, the system simultaneously monitors the collaborative stability of the adaptation layer and the isolation environment. For example, it verifies whether the circuit breaker mechanism of the type conversion wrapper layer is triggered and whether resource isolation in the virtual environment causes sudden changes in inter-process communication latency, ensuring the robustness of the optimization scheme under boundary conditions.

[0063] Furthermore, taking the optimized distributed lock service as an example: the test cluster simulated lock contention scenarios across geographically distributed nodes, gradually increasing the global lock request frequency to three times the designed peak. When the system detected that concurrency exceeded the threshold, the optimized heartbeat detection algorithm automatically shortened the lock lease time, sacrificing some availability for overall system survival, ensuring the average response time remained within the required constraints. Simultaneously, the resource monitoring module detected a local timeout on a worker node due to hardware performance bottlenecks. The adaptive load balancer immediately switched traffic to a backup instance. The final test report confirmed that the asset still met the SLA under fault-tolerant scenarios, and the system marked it as deployable.

[0064] In one implementation, the objective function in S41 includes: ;in, For memory weighting coefficients, This is the load weighting coefficient. This is the weighting coefficient for technology debt. This represents the current memory usage. Total system memory This represents the current load. For the number of system cores, For code duplication rate, For cyclomatic complexity, This represents the number of times the device can be reused.

[0065] In this embodiment, it should be noted that the memory usage item This embodies a non-linear penalty mechanism, which is applied when memory usage... Approximately the total system memory hour, The penalty coefficient approaches 1. Doubling this significantly increases the cost of the risk of memory overload. For example, if =80% If = 100%, then the coefficient is 1.8, and When the percentage is 90%, the coefficient is 1.9, strengthening the protection against memory overflow. Simply multiply by... This design achieves absolute usage constraints, suppressing high memory consumption configurations even if their proportion does not reach a threshold. In summary, traditional dependency degradation can lead to system crashes due to memory leaks or inappropriate caching strategies. This design, through a dynamic weighting mechanism, prioritizes configurations with low memory consumption and far from system limits, improving runtime stability.

[0066] Furthermore, load pressure item In the middle, when the load number More than the number of cores , 1. Penalty coefficient Linear growth reflects the scheduling latency caused by thread contention; for example, the coefficient is 3 when a 4-core system runs 8 threads, while it is 2 when running 4 threads. Furthermore, in high-concurrency scenarios, the algorithm tends to choose a configuration where the thread pool size matches the number of cores to avoid context switching overhead. In summary, human experience is insufficient to quantify the relationship between load and hardware; this formula automatically identifies resource overload risks, ensuring a balance between throughput and latency.

[0067] Furthermore, For technical debt, code quality was quantified; (Repetition rate) and Cyclic complexity directly measures code maintainability; for example, code with a 10% duplication rate and a cyclomatic complexity of 20 has a technical debt cost of 30. In China, asset reuse is encouraged, and the number of times assets can be reused is limited. The higher the value, the closer this item approaches 0, reducing the overall cost. For example, initial reuse ( =1) Contribute 0.5, 5th reuse ( =5) Contributed 0.166. In summary, traditional fixes (such as dependency degradation) can lead to bloated code and accumulated technical debt. This design incorporates code health into the optimization goal, promoting a concise and maintainable adaptation solution.

[0068] Furthermore, The memory weight coefficient determines the importance of memory usage in optimization; increasing it... In such cases, the algorithm will prioritize configurations with lower memory usage, even if the load or technical debt increases slightly; for example, in embedded systems, where memory resources are limited, higher memory settings are required. (like =0.6), forcing the algorithm to avoid the risk of memory overflow. This is the load weighting coefficient, used to optimize concurrent processing capabilities; it needs to be increased in high-concurrency scenarios (such as e-commerce flash sales). Ensure that parameters such as thread pool size and number of connections are adapted to peak load, even if memory usage is slightly high. This serves as a weighting factor for technical debt, reducing code complexity and redundancy; in long-term maintenance projects, it improves... (like =0.5) can drive the generation of concise and readable adaptation code, reducing subsequent maintenance costs.

[0069] Furthermore, "min" operates under hard constraints (such as response time ≤ threshold); the algorithm discards solutions that do not meet the constraints and optimizes only within the feasible region; for example, if a combination of parameters causes the response time to exceed the limit, it will be eliminated even if its weighted sum is extremely low. In summary, heuristic algorithms such as genetic algorithms and particle swarm optimization search the parameter space (such as thread pool size and caching strategy) to find the solution that minimizes the weighted sum; for example, increasing the number of threads from 10 to 20 may reduce load pressure (load term ↓), but increase memory usage (memory term ↑). The algorithm needs to weigh these factors and select the number of threads with the lowest total cost. Through iterative genetic algorithms, the optimal configuration with low memory usage, reasonable load, and controllable technical debt can be automatically selected, significantly reducing manual tuning costs and improving the quality and performance of reusable assets.

[0070] A software asset reuse system is also provided, which includes: The feature acquisition module is used to receive the software asset requirement information of the target project input by the user and extract the attribute features of the requirement information; The matching module is used to retrieve and match candidate assets in a pre-built software asset library based on the attribute features and using a preset similarity matching algorithm. The verification and adjustment module is used to perform compatibility verification on the matched candidate assets. If the verification passes, the candidate assets are output and deployed to the user's target environment. If the verification fails, an adaptation and adjustment plan is generated. The reuse decision module is used to optimize the parameters and adapt the code of candidate assets according to the adaptation and adjustment scheme, form deployable reusable assets, and deploy the reusable assets to the user's target environment.

[0071] In one implementation, the feature acquisition module is further configured to: parse and identify functional entities and operational constraints in the requirement information, and generate a structured intermediate representation containing functional semantics; extract technology stack identifiers based on the structured intermediate representation, wherein the technology stack identifiers include programming language version, dependent library name and minimum version number; associate and map the functional semantics with the technology stack identifiers and construct a feature matrix to form attribute features of the requirement information.

[0072] In one implementation, the matching module is further configured to: obtain the demand feature vector based on the feature matrix of the attribute features, and obtain the asset feature vector of each software asset in the software asset library; obtain the similarity between the demand feature vector and the asset feature vector; and filter out the software assets with the highest similarity that exceed a preset threshold as candidate assets for matching.

[0073] In this embodiment, it should be noted that the specific method of performing the operation in the above-mentioned software asset reuse system has been described in detail in the embodiments of the relevant software asset reuse method, and will not be elaborated here.

[0074] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0075] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0076] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

[0077] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.< / t> < / t> < / string> < / string> < / order> < / order> < / t> < / t> < / t> < / object> < / string>

Claims

1. A software asset reuse method characterized by, The method comprises the following steps: Receiving user input of target project software asset requirement information, extracting attribute features of the requirement information; Based on the attribute features, candidate assets are retrieved and matched in the pre-constructed software asset library through a pre-set similarity matching algorithm; Compatibility verification is performed on the matched candidate assets, if the verification is passed, the candidate assets are output and deployed to the user target environment, if the verification fails, an adaptation adjustment scheme is generated; According to the adaptation adjustment scheme, parameter optimization and code adaptation are performed on the candidate assets to form a deployable reusable asset, and the reusable asset is deployed to the user target environment.

2. The software asset reuse method of claim 1, wherein, The extraction of the attribute features of the requirement information comprises: Parsing and identifying functional entities and operation constraints in the requirement information, and generating a structured intermediate representation containing functional semantics; Based on the structured intermediate representation, technical stack identifiers are extracted, wherein the technical stack identifiers include programming language versions, dependent library names and minimum version numbers; The functional semantics are associated and mapped with the technical stack identifiers to construct a feature matrix to form the attribute features of the requirement information.

3. The software asset reuse method of claim 2, wherein, The retrieval and matching of candidate assets in the pre-constructed software asset library through a pre-set similarity matching algorithm comprises: According to the feature matrix of the attribute features, a requirement feature vector is obtained, and asset feature vectors of each software asset in the software asset library are obtained; The similarity of the requirement feature vector and the asset feature vector is obtained; The software assets with the maximum similarity and exceeding the pre-set threshold are screened out as the matched candidate assets.

4. The software asset reuse method of claim 3, wherein, The compatibility verification of the matched candidate assets comprises: Judging whether the parameter types passed in the candidate asset interface match the types required by the target project context, if there is a type conflict, it is recorded as a first type of incompatible item; Loading the candidate asset in a sandbox environment and monitoring the runtime dependent item loading state and undefined symbol reference, if there is a dependent item loading state exception or an undefined symbol reference exception, it is recorded as a second type of incompatible item; If there is any one of the first type of incompatible item and the second type of incompatible item or both exist, the verification fails, otherwise the verification passes.

5. The software asset reuse method of claim 4, wherein, If the verification fails, an adaptation adjustment scheme is generated, which comprises: For the first type of incompatible item, a type coercion wrapper layer code is generated, wherein the type coercion wrapper layer code includes input parameter type conversion and return value format adaptation; For the second type of incompatible item, a virtual environment configuration script is generated, wherein the virtual environment configuration script isolates the conflict dependent item by creating an independent namespace; Integrating the type coercion wrapper layer code and the virtual environment configuration script to form the adaptation adjustment scheme.

6. The software asset reuse method of claim 5, wherein, According to the adaptation adjustment scheme, parameter optimization and code adaptation are performed on the candidate assets to form a deployable reusable asset, which comprises: According to the adaptation adjustment scheme, the candidate assets are adjusted, a target function is obtained, and a constraint condition is obtained as the response time is less than the threshold specified by the requirement, and the adjusted candidate assets are optimized by genetic algorithm according to the target function and the constraint adjustment; The actual response time of the optimized candidate assets is tested, if the actual response time is less than the requirement threshold, the candidate assets are recorded as a deployable reusable asset.

7. The software asset reuse method of claim 6, wherein, The target function comprises: ; wherein, is a memory weight coefficient, is a load weight coefficient, is a technical debt weight coefficient, is a current memory usage rate, is a total system memory, is a current load number, is a system core number, is a code duplication rate, is a cyclomatic complexity, is a reuse frequency.

8. A software asset reuse system, characterized by, The system comprises: a feature acquisition module configured to receive requirement information of a software asset of a target project input by a user, and extract attribute features of the requirement information; a matching module configured to search and match candidate assets in a pre-constructed software asset library based on the attribute features through a preset similarity matching algorithm; a verification and adjustment module configured to perform compatibility verification on the matched candidate assets, output the candidate assets and deploy them to a target environment of the user if the verification is passed, and generate an adaptation adjustment scheme if the verification fails; a reuse decision module configured to perform parameter optimization and code adaptation on the candidate assets according to the adaptation adjustment scheme, form deployable reuse assets, and deploy the reuse assets to the target environment of the user.

9. The software asset reuse system of claim 8, wherein, The feature acquisition module is further configured to: analyze and identify functional entities and operation constraints in the requirement information, and generate a structured intermediate representation containing functional semantics; extract a technology stack identifier based on the structured intermediate representation, wherein the technology stack identifier includes a programming language version, a dependent library name, and a minimum version number; associate and map the functional semantics and the technology stack identifier, and construct a feature matrix to form the attribute features of the requirement information.

10. The software asset reuse system of claim 9, wherein, The matching module is further configured to: obtain a requirement feature vector according to the feature matrix of the attribute features, and obtain asset feature vectors of each software asset in the software asset library; obtain a similarity of the requirement feature vector and the asset feature vector; screen out software assets with the maximum similarity and exceeding a preset threshold as the matched candidate assets.

Images