A wisdom fusion development platform requirement understanding and framework automatic generation method

Abstract

The application belongs to the technical field of software engineering, and discloses a wisdom fusion development platform requirement understanding and framework automatic generation method; the method comprises the following steps: collecting requirement information of a target software framework by a user; intelligently analyzing the requirement information, extracting requirement elements of the target software framework, and establishing the correlation relationship and priority among the requirement elements; systematically arranging and standardizing the requirement elements to form a formal model; based on the correlation relationship and priority among the requirement elements, performing system structure design on the formal model, and converting the formal model into an architecture model; performing a software skeleton automatic construction process on the architecture model, and generating the target software framework according to the constructed software skeleton; the application can realize intelligent automatic conversion from user requirements to a software framework, significantly improve software development efficiency and quality, reduce requirement understanding deviation, and thus enhance the rationality and maintainability of the software architecture.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and more specifically, to a method for understanding requirements and automatically generating a framework for an intelligent integrated development platform. Background Technology

[0002] With the rapid increase in the scale and complexity of software systems, and the ever-increasing demands of digital transformation on enterprise information systems, traditional software development methods are facing enormous challenges. Modern software development has evolved from single-function modules to complex engineering projects involving cross-domain and multi-system integration, making requirements analysis and system design key bottlenecks in the entire development process. In particular, in the development of enterprise applications, cloud-native architectures, and microservice systems, the process of converting requirements into frameworks is often time-consuming and error-prone, seriously affecting system delivery efficiency and quality.

[0003] There are two main types of existing methods for solving the problems of requirement understanding and framework generation: one is to use traditional requirement engineering methods, which transform requirements into system architecture through manual analysis and design. However, this type of method relies on the experience and skills of professionals and has problems such as strong subjectivity, poor consistency, and difficulty in scaling. The other is to use low-code or code generation tools. However, such tools are usually based on predefined templates and fixed architectures, lacking a deep understanding of business requirements and the ability to adapt flexibly. They cannot dynamically adjust the architecture design according to the business characteristics of different domains, resulting in a lack of specificity in the generated framework, making it difficult to meet the needs of complex business scenarios. Consequently, there is a large gap between the system implementation and business expectations, and maintainability and scalability are difficult to guarantee.

[0004] In view of this, the present invention proposes a method for understanding the requirements and automatically generating the framework of a smart integrated development platform to solve the above problems. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the existing technology and achieve the above objectives, the present invention provides the following technical solution: a method for automatically generating requirements and framework for a smart fusion development platform, comprising:

[0006] Step S1: Collect user requirements for the target software framework;

[0007] Step S2: Perform intelligent analysis on the requirement information, extract the requirement elements of the target software framework, and establish the relationship and priority between each requirement element;

[0008] Step S3: Systematically organize and standardize the various requirements to form a formal model;

[0009] Step S4: Based on the relationships and priorities among the various requirements, design the system structure of the formal model and transform it into an architecture model;

[0010] Step S5: Perform an automatic software skeleton construction process on the architecture model and generate the target software framework based on the constructed software skeleton.

[0011] Furthermore, methods for extracting the requirement elements of the target software framework include:

[0012] The system intelligently analyzes the demand information to extract the demand entities. Each demand entity undergoes vectorization and normalization to obtain a standard vector. All standard vectors are then clustered to obtain... There are several demand clusters, and the demand type for each demand cluster is determined sequentially; among them, This refers to the number of requirement types, which are the types of requirement information, including functional requirements, non-functional requirements, constraints, and business scenarios.

[0013] Based on the standard vector corresponding to each demand cluster, calculate the similarity threshold for each demand cluster; for each demand cluster, calculate the similarity of each standard vector in turn and compare it with the corresponding similarity threshold, marking the standard vectors with similarity less than or equal to the corresponding similarity threshold as deviation vectors; determine the demand clusters that match each deviation vector and mark them as matching clusters; reallocate each deviation vector according to the matching clusters corresponding to each deviation vector; after the reallocation is completed, determine the demand type of each demand entity according to the demand clusters corresponding to each standard vector; combine each demand entity with the corresponding demand type in turn to form demand elements.

[0014] Furthermore, methods for determining the demand cluster that matches the deviation vector include:

[0015] Based on the standard vector corresponding to each demand cluster, calculate the center vector corresponding to each demand cluster; mark all demand clusters that the deviation vector does not currently correspond to as candidate clusters, and calculate the similarity between the deviation vector and the center vector corresponding to each candidate cluster in turn, and mark them as matching; mark the matching with the largest value as maximum, and mark the matching not marked as maximum as analytical; calculate the difference between each analytical and maximum value in turn to obtain the difference; compare each difference with a preset difference threshold, and mark the analytical with the difference less than the difference threshold as maximum.

[0016] Each candidate cluster corresponding to the maximum is marked as a potential cluster, and the deviation vector is sequentially assigned to each potential cluster. The center vector corresponding to each potential cluster is recalculated and marked as a potential vector. The similarity between the deviation vector and each potential vector is calculated sequentially and marked as the rematch. The difference between the rematch and the matching for the same potential cluster is calculated to obtain the matching gain, and the potential cluster with the largest matching gain is taken as the demand cluster that matches the deviation vector.

[0017] Furthermore, methods for establishing relationships between various demand elements include:

[0018] A pre-built domain knowledge base is constructed, which includes dependency patterns between different requirement elements. The dependency patterns include prerequisite dependencies and optional dependencies. Based on the dependency patterns between different requirement elements, directed edges are established between corresponding requirement elements.

[0019] Each directed edge is treated as a set of two demand elements. For each set of elements, the similarity between the standard vectors of the two demand elements is calculated and used as the basic strength of the corresponding set of elements. For the pre-dependency and optional dependency, the corresponding dependency weights are set respectively. The product between the basic strength of each set of elements and the corresponding dependency weight is calculated to obtain the dependency strength of each set of elements and used as the association strength of the corresponding directed edge.

[0020] Based on the demand elements, directed edges, and correlation strength, a correlation graph is constructed to establish the correlation relationships between the various demand elements.

[0021] Furthermore, methods for prioritizing various demand elements include:

[0022] Based on the demand type and demand entity corresponding to each demand element, obtain the type score and entity score corresponding to each demand element; reverse the direction of all directed edges in the relationship graph, and divide the directed edge corresponding to each demand element into outgoing edges and incoming edges; construct the pointing set corresponding to each demand element based on the demand element corresponding to the incoming edge of each demand element.

[0023] The number of outgoing edges corresponding to each demand element is counted to obtain the influence degree of each demand element. A corresponding influence score is set for each demand element in sequence. Based on the influence score, the set of pointing edges, and the influence degree of each demand element, the influence score of each demand element is iteratively optimized until the convergence criterion is reached and the iterative optimization is stopped. The iterative optimization results are then normalized to obtain the final influence score of each demand element.

[0024] The priority of each demand element is calculated based on its type score, entity score, and final influence score.

[0025] Furthermore, methods for forming formal models include:

[0026] A terminology dictionary is established, which includes different normative entities; each normative entity is then subjected to vectorization and normalization processes to obtain the normative vector corresponding to each normative entity.

[0027] Calculate the similarity between the standard vector and the normative vector corresponding to each demand element in turn, and mark it as normative; compare the normatives corresponding to the same demand element separately, and take the normative vector corresponding to the normative with the largest value as the matching vector of the corresponding demand element; replace the demand entity corresponding to each demand element with the normative entity corresponding to the matching vector in turn.

[0028] The specification entities, requirement types, priorities, dependency patterns, and association strengths corresponding to each requirement element are systematically organized to obtain the requirement specifications corresponding to each requirement element; all requirement specifications are integrated to form a formal model.

[0029] Furthermore, the steps to transform the formal model into an architectural model include:

[0030] Step S401: Mark all the specification entities corresponding to non-functional requirements as non-functional entities. Based on the priority of each non-functional entity, determine the key entities among the non-functional entities, and select the corresponding architectural style based on the key entities.

[0031] Step S402: Mark all the specification entities corresponding to the functional requirements as functional entities, and according to the dependency pattern corresponding to each functional entity, divide each functional entity into different architectural layers under the selected architectural style in sequence.

[0032] Step S403: Classify the functional entities within the same architectural level to obtain multiple functional modules corresponding to each architectural level;

[0033] Step S404: Analyze the functional entities in each functional module, identify the calling patterns between different functional modules, and define the interaction interfaces between different functional modules by combining the constraints and the standard entities corresponding to the business scenarios.

[0034] Step S405: Integrate the architectural style, architectural hierarchy, functional patterns, and interaction interfaces to form an architectural model.

[0035] Furthermore, in step S402, the method for sequentially assigning each functional entity to different architectural layers under the selected architectural style includes:

[0036] Count the number of incoming edges corresponding to each functional entity to obtain the degree of influence of each functional entity; integrate the degree of influence and the degree of influence of each functional entity to obtain the influence vector; concatenate the influence vector of each functional entity with the corresponding normalization vector to obtain the enhancement vector of each functional entity.

[0037] Clustering is performed on the augmentation vector of each functional entity to obtain Each architecture cluster is identified, and the corresponding architecture layer for each architecture cluster is determined sequentially.

[0038] Furthermore, in step S403, the method for classifying functional entities within the same architectural layer includes:

[0039] Calculate the similarity between every two functional entities within the same architectural layer and mark it as functional strength; preset a weight set, which includes the weight coefficients corresponding to functional strength and association strength; based on the weight set, perform a weighted summation of the functional strength and association strength between every two functional entities to obtain the comprehensive strength between every two functional entities.

[0040] Each functional entity is treated as a node, and the combined strength between any two functional entities is used as the edge weight between the corresponding two nodes. A hierarchical graph is constructed based on the nodes and edge weights. A graph partitioning algorithm is applied to the hierarchical graph to divide the nodes in the hierarchical graph into multiple module clusters, and each module cluster corresponds to a functional module.

[0041] Furthermore, in step S404, the method for identifying the calling patterns between different functional modules includes:

[0042] The two functional modules for call pattern recognition are labeled as the first module and the second module, respectively. The out-degree and in-degree of each functional entity in the first module are obtained in turn. The average value of the association strength of all directed edges between the first module and the second module is calculated to obtain the module association strength.

[0043] Out-degree, in-degree, and module association strength are collectively referred to as identification data. Multiple attribute sets are constructed for each piece of identification data. Each piece of identification data is converted into a membership degree corresponding to each attribute set using attribute interval mapping technology. Attribute inference rules are defined. The attribute interval mapped identification data are matched with the attribute inference rules, and attribute inference methods are used to perform attribute inference to obtain the corresponding attribute inference results. The attribute inference results include the membership degree of each calling mode. The calling mode with the highest membership degree in the attribute inference results is used as the calling mode between the first module and the second module.

[0044] The technical effects and advantages of the present invention, a method for automatically generating requirements and frameworks for a smart converged development platform, are as follows:

[0045] By comprehensively collecting user requirements, a rich and structured information source is provided for subsequent requirement analysis, effectively avoiding omissions and misunderstandings, and ensuring that the software framework development direction is highly consistent with user expectations. Intelligent parsing methods based on natural language processing and vectorization enable accurate extraction and classification of requirement elements. Simultaneously, by constructing relationship graphs and prioritizing, the logical dependencies and importance differences between requirement elements are accurately captured, providing a scientific basis for system architecture design. Through a terminology dictionary and standardized vector matching mechanism, non-standardized requirement expressions are transformed into standardized formal models, significantly improving the consistency and accuracy of requirement expression and eliminating ambiguity. Based on the formal model-based architecture design process, an architecture model conforming to the characteristics of the requirements is systematically constructed, ensuring the rationality and scalability of the system structure. Model-driven engineering, template filling, and code generation technologies are used to efficiently generate the target software framework, reducing manual coding workload and accelerating framework development. Intelligent and automatic conversion from user requirements to software framework is achieved, significantly improving software development efficiency and quality, reducing requirement misunderstanding biases, enhancing the rationality and maintainability of the software architecture, and providing efficient and accurate technical support for enterprise-level application development. Attached Figure Description

[0046] Figure 1 This is a flowchart of a method for automatically generating requirements and framework for a smart integrated development platform according to Embodiment 1 of the present invention. Detailed Implementation

[0047] 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. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example 1:

[0048] Please see Figure 1 As shown in this embodiment, a method for automatically generating requirements and framework for a smart converged development platform includes:

[0049] Step S1: Collect user requirements for the target software framework.

[0050] Requirements information refers to the various descriptions, expectations, and constraints that users have for the target software framework they require, including but not limited to functional requirements, non-functional requirements, constraints, and business scenarios.

[0051] Functional requirements refer to the functions that the target software framework must implement, such as user authentication, data storage, and API calls; non-functional requirements refer to the performance, scalability, and security requirements of the target software framework, such as response time and the number of concurrent users; constraints refer to the limitations on the target software framework in terms of development environment, technical specifications, and legal standards, such as compatibility with a certain database and adherence to internal enterprise interface specifications; business scenarios refer to the application scenarios of the target software framework, such as e-commerce, healthcare, and education.

[0052] For example, the requirements are as follows: I need a software framework for e-commerce that supports user registration and login, shopping cart, and order management. It must maintain a response time of less than 300ms under high concurrency (≥10,000 users), and the payment module must comply with the PCI-DSS security standard. The database used is PostgreSQL. Therefore, the functional requirements are: user registration and login, shopping cart functionality, and order management functionality. The non-functional requirements are: high concurrency support: ≥10,000 users, response time: ≤300ms, and compliance with the PCI-DSS security standard. Constraints: Must be compatible with the PostgreSQL database. Business scenario: e-commerce.

[0053] The target software framework refers to the software framework that users expect to obtain from the intelligent converged development platform.

[0054] Step S2: Perform intelligent analysis of the requirement information, extract the requirement elements of the target software framework, and establish the relationship and priority between the requirement elements.

[0055] Methods for extracting the requirements elements of a target software framework include:

[0056] Natural Language Processing (NLP) methods are used to intelligently parse the requirement information and extract the requirement entities. The requirement entities refer to the specific entity content in the requirement information, namely functional requirements, non-functional requirements, constraints, and specific entity content in business scenarios, such as user authentication, response time, e-commerce, etc. It should be noted that the natural language processing method is an existing technology, and the specific process will not be described in detail here.

[0057] Each demand entity is vectorized sequentially to obtain a demand vector corresponding to each demand entity; the vectorization is implemented using a word embedding model (such as FastText, GloVe, Word2Vec, etc.); each demand vector is normalized sequentially (i.e., each demand vector is divided by its corresponding modulus) to obtain a standard vector corresponding to each demand entity; all standard vectors are then clustered to obtain... The system identifies several demand clusters and determines the demand type for each cluster. The clustering process uses the K-means clustering method, which is an existing technology. The specific process will not be elaborated here. The number of requirement types refers to the type of requirement information, including but not limited to functional requirements, non-functional requirements, constraints, business scenarios, etc.; the requirement type corresponding to each requirement cluster is determined by those skilled in the art based on the requirement entities corresponding to all standard vectors within each requirement cluster.

[0058] The mean of the standard vector corresponding to each demand cluster is calculated to obtain the mean vector of each demand cluster. Each mean vector is then normalized to obtain the center vector of each demand cluster. For each demand cluster, the similarity between each standard vector and its corresponding center vector is calculated sequentially, using cosine similarity. The mean and standard deviation of the similarity for each demand cluster are calculated to obtain the similarity mean and similarity standard deviation for each demand cluster. The product of each similarity standard deviation and a preset adjustment coefficient is calculated sequentially to obtain the similarity adjustment amount for each demand cluster. The difference between the similarity mean and the similarity adjustment amount for each demand cluster is calculated sequentially to obtain the similarity threshold for each demand cluster. The adjustment coefficient is preset by those skilled in the art based on actual conditions.

[0059] For each demand cluster, the similarity of each standard vector is compared with the corresponding similarity threshold. Standard vectors with similarity less than or equal to the corresponding similarity threshold are marked as deviation vectors, while standard vectors with similarity greater than the corresponding similarity threshold are not marked. Demand clusters that match each deviation vector are identified and marked as matching clusters. Based on the matching clusters corresponding to each deviation vector, each deviation vector is reassigned, that is, each deviation vector is assigned to the corresponding matching cluster. After the reassignment is completed, the demand type corresponding to each demand entity is determined based on the demand clusters corresponding to each standard vector. Each demand entity is then combined with its corresponding demand type to form demand elements.

[0060] Methods for determining the demand cluster that matches the deviation vector include:

[0061] The deviation vector that is not currently corresponding Each demand cluster is labeled as a candidate cluster. The similarity between the deviation vector and the corresponding center vector of each candidate cluster is calculated sequentially and labeled as a matching property. The matching property with the largest value is labeled as the maximum property, and the matching properties not labeled as the maximum property are labeled as analytical properties. The difference between each analytical property and the maximum property is calculated sequentially to obtain the difference property. Each difference property is compared with a preset difference threshold, which is preset by those skilled in the art according to the actual situation. Analytical properties with a difference property less than the difference threshold are labeled as the maximum property, and analytical properties with a difference property greater than or equal to the difference threshold are not labeled.

[0062] Each candidate cluster corresponding to the maximum is marked as a potential cluster, and the deviation vector is sequentially assigned to each potential cluster. The center vector corresponding to each potential cluster is recalculated and marked as a potential vector. The similarity between the deviation vector and each potential vector is calculated sequentially and marked as the rematch. The difference between the rematch and the matching for the same potential cluster is calculated to obtain the matching gain. Each matching gain is compared sequentially, and the potential cluster with the largest matching gain is taken as the demand cluster that matches the deviation vector.

[0063] It should be understood that by calculating the similarity between the deviation vector and the potential vector and performing matching gain analysis, demand entities that have significant semantic deviations from the original corresponding demand clusters can be reassigned to the most suitable demand clusters. This optimizes the semantic consistency of each demand cluster, ensuring that each demand entity ultimately belongs to the demand type that best matches its content, thereby improving the internal semantic aggregation degree and classification accuracy of each demand cluster.

[0064] Methods for establishing relationships between various demand elements include:

[0065] A pre-built domain knowledge base is constructed, which includes dependency patterns between different requirement elements. This domain knowledge base is constructed in advance by those skilled in the art based on factors such as historical projects (i.e., experience and rules summarized from the order of requirement implementation in previous actual development projects), framework experience (i.e. dependency pattern experience summarized from specific software frameworks and implementation constraints), and industry standards (i.e. constraints on functional dependencies and implementation order based on industry norms, laws and regulations, or compliance requirements).

[0066] Dependency patterns include prerequisite dependencies and optional dependencies. Prerequisite dependencies mean that a certain requirement element must be implemented before subsequent requirement elements can be executed or take effect. For example, if the requirement elements are user authentication and order management, since users must complete authentication before an order can be created, the dependency pattern between user authentication and order management is a prerequisite dependency. Optional dependencies mean that the implementation of a certain requirement element can enhance or support subsequent requirement elements, but is not mandatory. For example, if the requirement elements are user behavior analysis and product recommendation, since product recommendation can be implemented based on basic rules (such as popular products, new product launches, etc.) and does not necessarily depend on user behavior analysis, the role of user behavior analysis is to provide personalized recommendations and improve accuracy. Therefore, the dependency pattern between user behavior analysis and product recommendation is an optional dependency.

[0067] Based on the dependency patterns between different demand elements, a directed edge is established between two corresponding demand elements; the direction of the directed edge is from the dependent to the dependent; for example, in the dependency pattern between user authentication and order management, the direction of the directed edge is from user authentication to order management; in the dependency pattern between user behavior analysis and product recommendation, the direction of the directed edge is from user behavior analysis to product recommendation.

[0068] Each directed edge corresponds to two demand elements as a set of elements, with each set corresponding to a directed edge. For each set of elements, the similarity between the standard vectors of the two demand elements is calculated and used as the base strength of the set. Dependency weights are assigned to both pre-dependent and optional dependencies, pre-set by those skilled in the art based on actual conditions. All dependency weights are greater than 0, with pre-dependent dependencies having a greater dependency weight than optional dependencies. The product of the base strength and the corresponding dependency weight is calculated to obtain the dependency strength of each set of elements, which is used as the association strength of the corresponding directed edge.

[0069] Based on the demand elements, directed edges, and correlation strength, a correlation graph is constructed to establish the correlation relationships between the various demand elements.

[0070] Methods for prioritizing various demand elements include:

[0071] Different type scores are assigned to different requirement types. These type scores reflect the importance of the corresponding requirement type within the target software framework and are pre-set by those skilled in the art based on the actual situation. An entity score is obtained for each requirement entity. This entity score reflects the importance of the corresponding requirement entity within the target software framework and is assigned by the user when uploading requirement information. Based on the requirement type and requirement entity corresponding to each requirement element, the type score and entity score for each requirement element are obtained. It should be noted that the value range for both type and entity scores is [not specified in the original text]. ;

[0072] The preset random redirect probability has a range of values. In this embodiment, the preferred random jump probability is 0.85, which can be preset by those skilled in the art according to the actual situation. All directed edges in the relationship graph are reversed, meaning the direction of each directed edge is from the dependent to the dependent. For each demand element, the directed edges originating from the corresponding demand element are marked as outgoing edges, and all unmarked directed edges are marked as incoming edges. Based on the demand elements corresponding to the incoming edges of each demand element, a pointing set corresponding to each demand element is constructed. The number of outgoing edges corresponding to each demand element is counted to obtain the influence degree of each demand element. A corresponding influence score is sequentially set for each demand element, and the influence score of each demand element is iteratively optimized based on its influence score, pointing set, influence degree, and random jump probability until the convergence criterion is reached. The iterative optimization results are then normalized (i.e., the influence score obtained after each iterative optimization is normalized) to obtain the final influence score of each demand element.

[0073] The priority of each demand element is obtained by multiplying its type score, entity score, and final influence score in sequence.

[0074] The expression for optimizing the influence score of each demand element:

[0075] ;

[0076] In the formula, For the first Each demand element corresponds to an optimized influence score. This represents the probability of a random jump. For the first A set of points to demand elements. For the first The influence score of each demand element. For the first The impact of each demand factor.

[0077] The method for determining whether the convergence criterion has been met is as follows: When the influence score of each demand element has been optimized once, calculate the difference between the optimized influence score and the unoptimized influence score for each demand element, and take the absolute value to obtain the optimization variable for each demand element; sum the optimization variables of each demand element sequentially to obtain the comprehensive optimization variable; compare the comprehensive optimization variable with a preset variable threshold, which is preset by those skilled in the art based on the actual situation; if the comprehensive optimization variable is greater than the variable threshold, it is determined that the convergence criterion has not been met; if the comprehensive optimization variable is less than or equal to the variable threshold, it is determined that the convergence criterion has been met.

[0078] For example, in the relationship graph, there are demand element A, demand element B, and demand element C, and demand element A points to demand element B and demand element C respectively, and demand element B points to demand element C. Since the direction of all directed edges in the relationship graph is reversed, demand element A has two incoming edges, demand element B has one incoming edge and one outgoing edge, and demand element C has two outgoing edges. That is, the influence degree corresponding to demand element A is 2, the influence degree corresponding to demand element B is 1, and the influence degree corresponding to demand element C is 0.

[0079] It should be understood that the purpose of reversing the direction of all directed edges in the relationship graph is to transform the relationship into an influence transfer relationship by reversing the direction (from the dependent to the dependent). The core requirement that is depended on by multiple requirement elements will get more incoming edges, thereby accumulating a higher influence score in the process of iterative optimization, and thus more accurately reflecting the importance of each requirement element in the target software framework.

[0080] Step S3: Systematically organize and standardize the various requirements to form a formal model.

[0081] Methods for forming formal models include:

[0082] A terminology dictionary is established, which includes different normative entities. This dictionary is created by those skilled in the art based on factors such as technical standards (i.e., definitions of standard terms published by recognized technical specifications and standardization organizations in the software engineering field, such as IEEE and ISO) and framework documents (i.e., the normative terms used in the official documentation of mainstream software frameworks, such as Spring, React, and Django). A normative entity refers to the standardized representation of a requirement entity. For example, requirement entities such as user registration and login, and user authentication correspond to the normative entity "user authentication"; requirement entities such as fast response and short loading time correspond to the normative entity "low-latency response."

[0083] For each standardized entity, perform vectorization and normalization processing sequentially to obtain the standardized vector corresponding to each standardized entity; calculate the similarity between the standard vector corresponding to each demand element and each standardized vector sequentially, and mark it as standardized; compare the standardized values ​​corresponding to the same demand element separately, and take the standardized vector corresponding to the standardized value with the largest value as the matching vector of the corresponding demand element; replace the demand entity corresponding to each demand element with the standardized entity corresponding to the corresponding matching vector sequentially.

[0084] The specification entities, requirement types, priorities, dependency patterns, and association strengths corresponding to each requirement element are systematically organized to obtain the requirement specifications corresponding to each requirement element; all requirement specifications are integrated to form a formal model.

[0085] Step S4: Based on the relationships and priorities among the various requirements, design the system structure of the formal model and transform it into an architecture model.

[0086] The steps to transform a formal model into an architectural model include:

[0087] Step S401: Mark all the specification entities corresponding to non-functional requirements as non-functional entities. Based on the priority of each non-functional entity, determine the key entities among the non-functional entities, and select the corresponding architectural style based on the key entities.

[0088] Step S402: Mark all the specification entities corresponding to the functional requirements as functional entities, and according to the dependency pattern corresponding to each functional entity, divide each functional entity into different architectural layers under the selected architectural style in sequence.

[0089] Step S403: Classify the functional entities within the same architectural level to obtain multiple functional modules corresponding to each architectural level;

[0090] Step S404: Analyze the functional entities in each functional module, identify the calling patterns between different functional modules, and define the interaction interfaces between different functional modules by combining the constraints and the standard entities corresponding to the business scenarios.

[0091] Step S405: Integrate the architectural style, architectural hierarchy, functional patterns, and interaction interfaces to form an architectural model.

[0092] In step S401 above, the method for selecting the corresponding architectural style based on the key entity includes:

[0093] The priority of each non-functional entity is compared with a preset priority threshold. Non-functional entities with a priority greater than the priority threshold are marked as key entities, while those with a priority less than or equal to the priority threshold are not marked. The priority threshold is preset by a person skilled in the art based on the actual situation. Based on all key entities, the corresponding architectural style is obtained from a pre-established decision table. The decision table includes key entities corresponding to different architectural styles, which are pre-established by a person skilled in the art by comprehensively considering factors such as architectural style characteristics (i.e., the inherent characteristics, advantages, and limitations of different architectural styles) and industry best practices (i.e., architectural design experience that has been verified and widely recognized in a specific field). Architectural styles include, for example, layered architecture and microservice architecture.

[0094] In step S402 above, the method for sequentially assigning each functional entity to different architectural layers under the selected architectural style includes:

[0095] Count the number of incoming edges corresponding to each functional entity to obtain the degree of influence of each functional entity; integrate the degree of influence and the degree of influence of each functional entity to obtain the influence vector; concatenate the influence vector of each functional entity with the corresponding normalization vector to obtain the enhancement vector of each functional entity.

[0096] Clustering is performed on the augmentation vector of each functional entity to obtain There are several architecture clusters, and the corresponding architecture hierarchy for each architecture cluster is determined sequentially; among them, The value is an integer greater than 1; the architecture layer corresponding to each architecture cluster is determined by those skilled in the art based on the functional entities and architecture style corresponding to all enhancement vectors within each architecture cluster; the architecture layer is, for example, the presentation layer, application layer, business layer, data layer, etc. corresponding to a layered architecture, and the API gateway layer, service layer, infrastructure layer, etc. corresponding to a microservice architecture.

[0097] In step S403 above, the method for classifying functional entities within the same architectural layer includes:

[0098] The similarity between each pair of functional entities within the same architectural layer is calculated sequentially and marked as functional strength. A weight set is preset, which includes weight coefficients corresponding to functional strength and association strength, and is preset by those skilled in the art according to the actual situation. Based on the weight set, the functional strength and association strength between each pair of functional entities are weighted and summed to obtain the comprehensive strength between each pair of functional entities.

[0099] Each functional entity is treated as a node, and the combined strength between any two functional entities is used as the edge weight between the corresponding two nodes. Based on the nodes and edge weights, a hierarchical graph is constructed. A graph partitioning algorithm (such as METIS, Louvain, etc.) is applied to the hierarchical graph to divide the nodes in the hierarchical graph into multiple module clusters. Each module cluster corresponds to a functional module, thereby obtaining multiple functional modules corresponding to the architecture hierarchy. Functional modules include, for example, user management modules, product management modules, etc.

[0100] In step S404 above, the method for identifying the calling patterns between different functional modules includes:

[0101] The two functional modules for call pattern recognition are labeled as the first module and the second module, respectively. The out-degree and in-degree of each functional entity in the first module are obtained in turn. The out-degree refers to the number of outgoing edges between the corresponding functional entity and each functional entity in the second module, and the in-degree refers to the number of incoming edges between the corresponding functional entity and each functional entity in the second module. The average value of the association strength of all directed edges between the first module and the second module is calculated to obtain the module association strength.

[0102] Out-degree, in-degree, and module association strength are collectively referred to as identification data. Multiple attribute sets are constructed for each piece of identification data; for example, the attribute set corresponding to out-degree is low out-degree, medium out-degree, and high out-degree. Each piece of identification data is converted into a membership degree corresponding to each attribute set using attribute interval mapping technology. Attribute interval mapping technology is the process of converting precise numerical values ​​into membership degrees corresponding to attribute sets. Examples of attribute interval mapping technologies include triangular membership functions and trapezoidal membership functions. For example, if the out-degree value is high, the membership degree for high out-degree is inferred to be 0.9, for medium out-degree to be 0.3, and for low out-degree to be 0.

[0103] Define attribute inference rules based on expert knowledge or relevant literature; for example: if the attribute set corresponding to the identified data is low out-degree and high in-degree, and the module association strength is high, then it is inferred that the corresponding calling pattern belongs to a strong pre-dependency with high membership degree.

[0104] The identified data after attribute interval mapping is matched with the attribute inference rules, and attribute inference methods (such as Mamdani inference model, Sugeno inference model, etc.) are used to perform attribute inference to obtain the corresponding attribute inference results. The attribute inference results include the membership degree of each calling mode, such as strong pre-dependency, medium pre-dependency, weak pre-dependency, strong optional dependency, medium optional dependency, weak optional dependency, etc. The calling mode with the highest membership degree in the attribute inference results is used as the calling mode between the first module and the second module.

[0105] Methods for defining interaction interfaces between different functional modules include:

[0106] Different numerical labels are set for different calling modes and marked as mode labels; the two functional modules that define the interaction interface are both marked as the current module; the normative vectors corresponding to the normative entities of the constraints and business scenarios, as well as the mode labels between the two current modules, are used as the analysis set; the analysis set is input into the trained interface definition model to predict the corresponding interaction interface information.

[0107] The interaction interface information includes, but is not limited to, type labels, input parameters, and output parameters. Type labels are numeric labels corresponding to different interface types, such as synchronous interfaces, asynchronous interfaces, and event-driven interfaces. Input parameters refer to the data or information required when calling the interface, such as resource identifiers (numerical values ​​that uniquely identify the resource to be accessed) and request data bodies (information carriers containing complete operation data). Output parameters refer to the data or status information returned to the caller after the interface execution is complete, such as response status (status information of the interface call result) and returned data (actual result data of the interface operation). It should be noted that all data in the interaction interface information is represented numerically.

[0108] The interface defines the model as a deep neural network model, which includes an input layer, hidden layers, and an output layer. Each hidden layer contains multiple neurons, and each neuron is connected to neurons in the next layer. These connections contain weights that determine the importance and influence of data transmitted within the neural network. An activation function is applied to each neuron between the hidden and output layers. This activation function introduces non-linearity, allowing the network to learn more complex patterns and features. The training process of the interface-defined model includes:

[0109] Pre-collection For each of the different analysis sets, set the corresponding interactive interface information sequentially. The integer is greater than 1; the analysis set and the corresponding interaction interface information are converted into a set of feature vectors; the interaction interface information corresponding to the analysis set is collected by those skilled in the art during the historical definition of interaction interfaces. Different analysis sets are created, and each set is analyzed sequentially. Appropriate type labels, input parameters, and output parameters are selected and used as corresponding interactive interface information. Set the corresponding interactive interface information for each different analysis set in sequence;

[0110] Each set of feature vectors is used as input to the interface definition model. The interface definition model outputs a set of predicted interaction interface information corresponding to each set of analysis, and uses the actual interaction interface information corresponding to each set of analysis as the prediction target. The actual interaction interface information is the pre-set interaction interface information corresponding to the analysis set. The training objective is to minimize the sum of prediction errors for all analysis sets. The formula for calculating the prediction error is as follows: ,in For prediction error, To analyze the group number of the eigenvector corresponding to the set, For the first Group analysis sets correspond to the prediction interaction interface information. For the first The analysis group identifies the actual interaction interface information corresponding to the set; the interface definition model is trained until the sum of prediction errors converges, at which point training stops.

[0111] Step S5: Perform an automatic software skeleton construction process on the architecture model and generate the target software framework based on the constructed software skeleton.

[0112] The Model-Driven Engineering (MDE) approach is used to map the architecture model into a software skeleton. The software skeleton includes a predefined directory hierarchy, module placeholder code (i.e., the basic code template automatically generated for each functional module), interface definition files (i.e., the interaction interface contracts between different functional modules), and basic configuration files (i.e., the configuration files required for software startup and runtime, such as databases, dependency libraries, etc.). The software skeleton is the basic code structure of the target software framework, used to carry subsequent functional implementation and configuration expansion.

[0113] Based on the software skeleton, and combining template filling and code generation methods, the requirement elements are injected into the software skeleton to generate the target software framework;

[0114] It should be noted that model-driven engineering, template filling, and code generation methods are all existing technologies, and the specific processes will not be elaborated on here.

[0115] This embodiment comprehensively collects user requirements, establishing a complete requirement system encompassing functional and non-functional requirements, constraints, and business scenarios. This provides a rich and structured information source for subsequent requirement analysis, effectively avoiding omissions and misunderstandings, and ensuring that the software framework development direction is highly consistent with user expectations. Based on intelligent parsing methods using natural language processing and vectorization, it achieves accurate extraction and classification of requirement elements. Simultaneously, by constructing a relational graph and prioritizing calculations, it accurately captures the logical dependencies and importance differences between requirement elements, providing a scientific basis for system architecture design. Through a terminology dictionary and a matching mechanism using standardized vectors, non-standardized requirement expressions are transformed into standardized formal models, significantly improving the consistency and accuracy of requirement expression and eliminating ambiguity. Based on the formal model-driven architecture design process, through key entity identification, architectural style selection, functional entity hierarchy division, and module classification, it systematically constructs an architecture model that conforms to the characteristics of the requirements. Attribute reasoning methods accurately define the interaction interfaces between modules, ensuring the rationality and scalability of the system structure. A model-driven engineering approach is used to automatically construct the software skeleton, and template filling and code generation technologies are used to inject requirement elements into the software skeleton, efficiently generating the target software framework, reducing manual coding workload, and accelerating framework development.

[0116] This embodiment comprehensively utilizes technologies such as natural language processing, vector space models, relational graphs, formal modeling, architectural style selection, module partitioning, and automatic code generation to achieve intelligent and automatic conversion from user requirements to software frameworks. This significantly improves software development efficiency and quality, reduces misunderstandings of requirements, enhances the rationality and maintainability of software architecture, and provides efficient and accurate technical support for enterprise application development. Example 2:

[0117] This application also provides an electronic device. The electronic device may include one or more processors and one or more memories. The memories store computer-readable code, which, when executed by the one or more processors, can perform the aforementioned method for automatically generating requirements and frameworks for a smart converged development platform.

[0118] The methods or systems according to embodiments of this application can also be implemented using the architecture of the electronic device shown in this application. The electronic device may include a bus, one or more CPUs, ROM, RAM, a communication port connected to a network, input / output, a hard disk, etc. Storage devices in the electronic device, such as ROM or hard disk, may store a method for automatically generating a smart converged development platform requirement understanding and framework provided in this application. Furthermore, the electronic device may also include a user interface. Of course, the architecture shown in this application is merely exemplary; when implementing different devices, one or more components in the electronic device shown in this application may be omitted according to actual needs. Example 3:

[0119] Please refer to the accompanying drawings. One embodiment of this application discloses a computer-readable storage medium. The computer-readable storage medium stores computer-readable instructions. When executed by a processor, the computer-readable instructions can perform a method for automatically generating requirements understanding and frameworks for a smart fusion development platform according to an embodiment of this application, as described above. The storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc.

[0120] Furthermore, according to embodiments of this application, the processes described in the above-referenced flowcharts can be implemented as computer software programs. For example, this application provides a non-transitory machine-readable storage medium storing machine-readable instructions that can be executed by a processor to perform instructions corresponding to the method steps provided in this application, such as a method for automatically generating requirements understanding and framework for a smart fusion development platform. When this computer program is executed by a central processing unit (CPU), it performs the functions defined in the method of this application.

[0121] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0122] It should be noted that, in this document, 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. Unless otherwise specified, 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.

[0123] In the description of this invention, it should be understood that the terms "first," "second," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0124] In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0125] In the description of this invention, "several" means one or more, and "a large number" means two or more.

[0126] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0127] All formulas in this manual are dimensionless and calculated numerically. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0128] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A method for automatically generating requirements understanding and framework for a smart integrated development platform, characterized in that, include: Step S1: Collect user requirements for the target software framework; Step S2: Intelligently analyze the requirement information, extract the requirement elements of the target software framework, and establish the relationship and priority between each requirement element; among them, the requirement elements include requirement entities and corresponding requirement types; the requirement types include functional requirements, non-functional requirements, constraints, and business scenarios. Step S3: Systematically organize and standardize the various requirements to form a formal model; Methods for forming formal models include: A terminology dictionary is established, which includes different normative entities. Each normative entity is then subjected to vectorization and normalization processes to obtain a normative vector corresponding to each entity. Here, a normative entity refers to the normalized representation of a demand entity. Calculate the similarity between the standard vector and the normative vector corresponding to each demand element in turn, and mark it as normative; compare the normatives corresponding to the same demand element separately, and take the normative vector corresponding to the normative with the largest value as the matching vector of the corresponding demand element; replace the demand entity corresponding to each demand element with the normative entity corresponding to the matching vector in turn. The specification entities, requirement types, priorities, dependency patterns, and relationship strengths corresponding to each requirement element are systematically organized to obtain the requirement specifications corresponding to each requirement element; all requirement specifications are integrated to form a formal model. Step S4: Based on the relationships and priorities among the various requirements, design the system structure of the formal model and transform it into an architecture model; The steps to transform a formal model into an architectural model include: Step S401: Mark all the specification entities corresponding to non-functional requirements as non-functional entities. Based on the priority of each non-functional entity, determine the key entities among the non-functional entities, and select the corresponding architectural style based on the key entities. Step S402: Mark all the specification entities corresponding to the functional requirements as functional entities. Based on the dependency pattern corresponding to each functional entity, classify each functional entity into different architectural layers under the selected architectural style. The dependency pattern is determined by a pre-built domain knowledge base. Step S403: Classify the functional entities within the same architecture layer to obtain multiple functional modules corresponding to each architecture layer; Step S404: Analyze the functional entities in each functional module, identify the calling patterns between different functional modules, and define the interaction interfaces between different functional modules by combining the constraints and the standard entities corresponding to the business scenarios. Step S405: Integrate the architectural style, architectural hierarchy, functional patterns, and interaction interfaces to form an architectural model; Step S5: Perform an automatic software skeleton construction process on the architecture model and generate the target software framework based on the constructed software skeleton.

2. The method for automatically generating requirements understanding and framework of a smart integrated development platform according to claim 1, characterized in that, Methods for extracting the requirements elements of a target software framework include: The system intelligently analyzes the demand information to extract the demand entities. Each demand entity undergoes vectorization and normalization to obtain a standard vector. All standard vectors are then clustered to obtain... There are several demand clusters, and the demand type for each demand cluster is determined sequentially; among them, This represents the number of demand types, where each demand type is the type of demand information. The process involves: calculating the mean of the standard vectors corresponding to each demand cluster; normalizing each mean vector to obtain the center vector for each demand cluster; calculating the similarity between each standard vector and its corresponding center vector for each demand cluster; calculating the mean and standard deviation of the similarity for each demand cluster to obtain the similarity mean and standard deviation for each demand cluster; multiplying each similarity standard deviation by a preset adjustment coefficient to obtain the similarity adjustment amount for each demand cluster; calculating the difference between the similarity mean and the similarity adjustment amount for each demand cluster to obtain the similarity threshold for each demand cluster; comparing the similarity of each standard vector with its corresponding similarity threshold for each demand cluster, and marking standard vectors with similarity less than or equal to the corresponding similarity threshold as deviation vectors; identifying demand clusters that match each deviation vector and marking them as matching clusters; reallocating each deviation vector based on its matching cluster; determining the demand type for each demand entity based on the demand clusters corresponding to each standard vector; and combining each demand entity with its corresponding demand type to form demand elements.

3. The method for automatically generating requirements understanding and framework of a smart integrated development platform according to claim 2, characterized in that, Methods for determining the demand cluster that matches the deviation vector include: Based on the standard vector corresponding to each demand cluster, calculate the center vector corresponding to each demand cluster; mark all demand clusters that the deviation vector does not currently correspond to as candidate clusters, and calculate the similarity between the deviation vector and the center vector corresponding to each candidate cluster in turn, and mark them as matching; mark the matching with the largest value as maximum, and mark the matching not marked as maximum as analytical; calculate the difference between each analytical and maximum value in turn to obtain the difference; compare each difference with a preset difference threshold, and mark the analytical with the difference less than the difference threshold as maximum. Each candidate cluster corresponding to the maximum is marked as a potential cluster, and the deviation vector is sequentially assigned to each potential cluster. The center vector corresponding to each potential cluster is recalculated and marked as a potential vector. The similarity between the deviation vector and each potential vector is calculated sequentially and marked as the rematch. The difference between the rematch and the matching for the same potential cluster is calculated to obtain the matching gain, and the potential cluster with the largest matching gain is taken as the demand cluster that matches the deviation vector.

4. The method for automatically generating requirements understanding and framework of a smart integrated development platform according to claim 3, characterized in that, Methods for establishing relationships between various demand elements include: A pre-built domain knowledge base is constructed, which includes dependency patterns between different requirement elements. The dependency patterns include prerequisite dependencies and optional dependencies. Based on the dependency patterns between different requirement elements, directed edges are established between corresponding requirement elements. Each directed edge is treated as a set of two demand elements. For each set of elements, the similarity between the standard vectors of the two demand elements is calculated and used as the basic strength of the corresponding set of elements. For the pre-dependency and optional dependency, the corresponding dependency weights are set respectively. The product between the basic strength of each set of elements and the corresponding dependency weight is calculated to obtain the dependency strength of each set of elements and used as the association strength of the corresponding directed edge. Based on the demand elements, directed edges, and correlation strength, a correlation graph is constructed to establish the correlation relationships between the various demand elements.

5. The method for automatically generating requirements understanding and framework of a smart integrated development platform according to claim 4, characterized in that, Methods for prioritizing various demand elements include: Based on the demand type and demand entity corresponding to each demand element, obtain the type score and entity score corresponding to each demand element; reverse the direction of all directed edges in the relationship graph, and divide the directed edge corresponding to each demand element into outgoing edges and incoming edges; construct the pointing set corresponding to each demand element based on the demand element corresponding to the incoming edge of each demand element. The number of outgoing edges corresponding to each demand element is counted to obtain the influence degree of each demand element. A corresponding influence score is set for each demand element in sequence. Based on the influence score, the set of pointing edges, and the influence degree of each demand element, the influence score of each demand element is iteratively optimized until the convergence criterion is reached and the iterative optimization is stopped. The iterative optimization results are then normalized to obtain the final influence score of each demand element. The priority of each demand element is obtained by multiplying its type score, entity score, and final influence score in sequence.

6. The method for automatically generating requirements understanding and framework of a smart integrated development platform according to claim 5, characterized in that, In step S402, the method for sequentially assigning each functional entity to different architectural layers under the selected architectural style includes: Count the number of incoming edges corresponding to each functional entity to obtain the degree of influence of each functional entity; integrate the degree of influence and the degree of influence of each functional entity to obtain the influence vector; concatenate the influence vector of each functional entity with the corresponding normalization vector to obtain the enhancement vector of each functional entity. Clustering is performed on the augmentation vector of each functional entity to obtain Each architecture cluster is identified, and the corresponding architecture layer for each architecture cluster is determined sequentially.

7. The method for automatically generating requirements understanding and framework of a smart integrated development platform according to claim 6, characterized in that, In step S403, the method for classifying functional entities within the same architectural layer includes: Calculate the similarity between every two functional entities within the same architectural layer and mark it as functional strength; preset a weight set, which includes the weight coefficients corresponding to functional strength and association strength; based on the weight set, perform a weighted summation of the functional strength and association strength between every two functional entities to obtain the comprehensive strength between every two functional entities. Each functional entity is treated as a node, and the combined strength between any two functional entities is used as the edge weight between the corresponding two nodes. A hierarchical graph is constructed based on the nodes and edge weights. A graph partitioning algorithm is applied to the hierarchical graph to divide the nodes in the hierarchical graph into multiple module clusters, and each module cluster corresponds to a functional module.

8. The method for automatically generating requirements understanding and framework of a smart integrated development platform according to claim 7, characterized in that, In step S404, the method for identifying the calling patterns between different functional modules includes: The two functional modules for call pattern recognition are labeled as the first module and the second module, respectively. The out-degree and in-degree of each functional entity in the first module are obtained in turn. The average value of the association strength of all directed edges between the first module and the second module is calculated to obtain the module association strength. Out-degree, in-degree, and module association strength are collectively referred to as identification data. Multiple attribute sets are constructed for each piece of identification data. Each piece of identification data is converted into a membership degree corresponding to each attribute set using attribute interval mapping technology. Attribute inference rules are defined. The attribute interval mapped identification data are matched with the attribute inference rules, and attribute inference methods are used to perform attribute inference to obtain the corresponding attribute inference results. The attribute inference results include the membership degree of each calling mode. The calling mode with the highest membership degree in the attribute inference results is used as the calling mode between the first module and the second module.

Images