Software demand automatic identification and conversion method and system based on semantic modeling

Abstract

The invention provides a semantic modeling-based software demand automatic identification and conversion method and system, and relates to the technical field of software development, and the method comprises the following steps: obtaining a multi-version demand document, and constructing a time sequence semantic representation; deducing a dependency relationship between demand entities and resolving conflicts, and constructing a dependency relationship graph; software components are generated for the demand entities, semantic verification is executed, and root causes are positioned and repaired; establishing a component interaction relationship to form a software architecture; the timing consistency is verified and the dependency inference rule is optimized. According to the method, demand evolution can be automatically tracked, dependency conflicts can be identified, accurate conversion from demands to software architecture is realized, and the software development efficiency and quality are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to software development technology, and in particular to a software requirement automatic identification and conversion method and system based on semantic modeling. BACKGROUND

[0002] With the growing size and complexity of software systems, software requirement management has become an important part of software engineering. Software requirement documents usually describe the user's desired system functions and features in natural language form, which need to be accurately converted into software components and architecture design. In the software development process, requirements often change, and the management of multi-version requirement documents and the analysis of requirement evolution are crucial to maintaining the consistency and stability of software systems. Existing methods have difficulty in automatically identifying and resolving contradictory dependencies between requirement entities, especially in distinguishing cross-version conflicts and same-version conflicts, often requiring manual intervention by developers, increasing development costs and error risks. SUMMARY

[0003] The embodiments of the present application provide a software requirement automatic identification and conversion method and system based on semantic modeling, which can solve the problems in the prior art.

[0004] In a first aspect, the embodiments of the present application provide a software requirement automatic identification and conversion method based on semantic modeling, comprising: Obtaining multi-version requirement documents, extracting semantic change time points and semantic change contents of requirement entities in different versions, and constructing a time sequence semantic representation; Based on the time sequence semantic representation, inferring the pre-dependence relationship, trigger dependence relationship or constraint dependence relationship between requirement entities. When there is a contradictory dependence between the same pair of requirement entities, distinguish cross-version conflicts and same-version conflicts according to the version where the dependence is located and perform the elimination operation of retaining the latest dependence or marking the circular dependence respectively, and construct a dependence relationship graph; Generating software components for each requirement entity in the dependence relationship graph and performing bidirectional semantic verification, when the verification fails, backtracking the dependence relationship graph to locate the root cause and generating repair suggestions, obtaining a component set that passes the verification; According to the dependence relationship type in the dependence relationship graph, establishing component interaction relationship in the component set, and obtaining software architecture; Verifying the time sequence consistency of the software architecture based on requirement evolution events and adjusting the component interaction relationship, and feeding back the verification results and repair suggestions to adjust the dependence inference rules.

[0005] The step of obtaining multi-version requirement documents, extracting semantic change time points and semantic change contents of requirement entities in different versions, and constructing a time sequence semantic representation comprises: establishing a cross-version trace chain for each requirement entity in the multi-version requirement document, the cross-version trace chain recording a text description, an associated requirement entity identifier, and a version timestamp of the requirement entity in each version; performing semantic parsing on the text description to extract three types of semantic elements, i.e., a functional intent, an interface constraint, and a state constraint, and when any semantic element of the same requirement entity changes between adjacent versions, marking the version timestamp as a semantic change time point and marking a difference before and after the change as semantic change content; establishing a semantic association relationship between requirement entities according to the associated requirement entity identifier, the semantic association relationship including a functional call association, a data flow association, and a state constraint association; organizing the semantic change time point, the semantic change content, and the semantic association relationship into a time-sequential directed graph structure, a node of the time-sequential directed graph structure representing a semantic state of a requirement entity in a corresponding version, and an edge representing a semantic association relationship or an evolution relationship, to obtain a time-sequential semantic representation.

[0006] inferring a pre-dependence relationship, a trigger-dependence relationship, or a constraint-dependence relationship between requirement entities based on the time-sequential semantic representation, when there is a contradictory dependence between the same pair of requirement entities, distinguishing a cross-version conflict from a same-version conflict according to a version in which the dependence is located and performing a retaining-latest-dependence or a marking-circular-dependence operation, respectively, and the step of constructing a dependence relationship graph includes: extracting a pair of requirement entities and a semantic association relationship from the time-sequential semantic representation, inferring a dependence relationship according to a chronological relationship of the semantic change time point and a type of the semantic association relationship, inferring a pre-dependence relationship when a semantic change time point of a first requirement entity is earlier than that of a second requirement entity and there is a functional call association, inferring a trigger-dependence relationship when the semantic change content of the first requirement entity contains a state change and the semantic change content of the second requirement entity contains a response to the state change, and inferring a constraint-dependence relationship when there is a state constraint association and a state constraint of the first requirement entity restricts a functional intent of the second requirement entity; detecting opposite-direction dependences in the inferred dependence relationships, and when there are bidirectional dependences between the first requirement entity and the second requirement entity, marking the contradictory dependences and recording version identifiers of the dependence relationships; when the two dependence relationships in the contradictory dependences are located in different versions, determining that there is a cross-version conflict and retaining a dependence relationship with a newer version timestamp, and when the two dependence relationships in the contradictory dependences are located in the same version, determining that there is a same-version conflict and marking a circular dependence; and organizing the resolved dependence relationships into a directed graph structure to obtain a dependence relationship graph.

[0007] The step of generating software components for each requirement entity in the dependency graph and performing bidirectional semantic verification, backtracking the dependency graph to locate root causes and generating repair suggestions when verification fails, obtaining a set of verified components, comprises: Extracting functional intent, interface constraint and state constraint for each requirement entity in the dependency graph, generating component logic according to functional intent, generating interface definition according to interface constraint, and generating state management mechanism according to state constraint, and combining them into software components; Performing forward verification on the software components, matching component logic with functional intent, comparing interface definition with interface constraint, and checking state management mechanism with state constraint, and marking as forward verification failure when any of them does not meet the requirements; Performing reverse verification on the software components, extracting functional features in component logic, interface parameters in interface definition, and state rules in state management mechanism, and comparing them with functional intent, interface constraint and state constraint respectively to identify redundant functions, redundant interfaces and redundant constraints, and marking as reverse verification failure when redundant items are detected; When forward verification fails, trace back the prerequisite dependencies in the dependency graph to locate the root cause requirement entity of functional deficiency, and when reverse verification fails, trace back the trigger dependencies and constraint dependencies to locate the associated requirement entity that introduces redundancy; based on the positioning results, generate repair suggestions and adjust the software components, and then perform bidirectional semantic verification again, and when the verification is passed, add the software components to the component set.

[0008] When forward verification fails, trace back the prerequisite dependencies in the dependency graph to locate the root cause requirement entity of functional deficiency, and when reverse verification fails, trace back the trigger dependencies and constraint dependencies to locate the associated requirement entity that introduces redundancy; based on the positioning results, generate repair suggestions and adjust the software components, and then perform bidirectional semantic verification again, and when the verification is passed, add the software components to the component set. When forward verification fails, extract the semantic element type corresponding to the verification item marked as not meeting the requirements, and trace back from the current requirement entity along the reverse path of the prerequisite dependency in the dependency graph; Extracting the semantic elements of each prerequisite requirement entity on the trace back path, and performing semantic matching between the semantic elements of the prerequisite requirement entity and the missing semantic elements of the current requirement entity, and marking the prerequisite requirement entity as the root cause requirement entity when the matching degree exceeds the preset matching degree threshold, and calculating the trace back depth; When reverse verification fails, extract the functional features, interface parameters or state rules corresponding to the detected redundant items, and trace back from the current requirement entity along the forward path of the trigger dependencies and constraint dependencies in the dependency graph, extract the semantic change content of each associated requirement entity on the trace back path, and perform semantic tracing with the redundant items, and mark the associated requirement entity as the redundancy introduction source when the tracing is successful, and record the trace back path length; generate a repair suggestion containing a supplementary semantic element based on the trace depth, and generate a repair suggestion containing a redundant item based on the trace path length.

[0009] The step of establishing a component interaction relationship in the component set according to the dependency relationship type in the dependency relationship graph to obtain the software architecture comprises: According to the dependency relationship type, the interface definition and the state management mechanism of the software component corresponding to the requirement entity are retrieved in the component set; When the dependency relationship type is a pre-dependency relationship, an invocation interaction relationship is established according to the input parameter type and the output parameter type in the interface definition, and the output of the first software component is specified as the input of the second software component; when the dependency relationship type is a trigger dependency relationship, an event interaction relationship is established according to the state change event and the state response rule in the state management mechanism, and the state change of the first software component triggers the state response of the second software component; when the dependency relationship type is a constraint dependency relationship, a constraint interaction relationship is established according to the state constraint condition in the state management mechanism, and the state constraint of the first software component limits the execution condition of the second software component; The invocation interaction relationship, the event interaction relationship and the constraint interaction relationship are organized into a hierarchical structure, the component hierarchy is determined according to the pre-dependency relationship in the dependency relationship graph, the software components without pre-dependency relationship are divided into a basic layer, and the software components with pre-dependency relationship are divided into an intermediate layer and an application layer according to the dependency depth, to obtain the software architecture.

[0010] The step of verifying the temporal consistency of the software architecture based on a requirement evolution event and adjusting the component interaction relationship, and feeding back the verification result and the repair suggestion to adjust the dependency inference rule comprises: A requirement evolution event is extracted from the temporal semantic representation, the requirement evolution event contains a semantic change time point, a semantic change content and a semantic association relationship, the affected software component is located in the software architecture, and the component interaction relationship is extracted and arranged in time sequence into an interaction time sequence chain; The semantic change time point is compared with the interaction occurrence time in the interaction time sequence chain, when the semantic change time point is later than the interaction occurrence time dependent on the semantic, it is marked as a temporal conflict, and when the semantic change content causes the interruption of data flow conversion or control flow conversion, it is marked as an interaction interruption; When a temporal conflict is detected, the component hierarchy of the affected software component is adjusted, and when an interaction interruption is detected, the interface definition or the state management mechanism of the affected software component is regenerated according to the semantic change content and the component interaction relationship is updated; Infer an error rate of a dependency relationship type corresponding to a statistical time sequence conflict and an interaction interruption, generate a dependency inference rule adjustment suggestion and update a dependency inference rule when the error rate exceeds a preset error rate threshold, and the dependency inference rule adjustment suggestion includes a semantic association relationship type that needs to be strengthened and a semantic change time point determination condition that needs to be weakened.

[0011] In a second aspect of the embodiment of the application, a software requirement automatic recognition and conversion system based on semantic modeling is provided, which comprises: A time sequence semantic construction module is configured to acquire multi-version requirement documents, extract semantic change time points and semantic change contents of requirement entities in different versions, and construct a time sequence semantic representation. A dependency relationship inference module is configured to infer preposition dependency relationships, trigger dependency relationships or constraint dependency relationships between requirement entities based on the time sequence semantic representation, when there are contradictory dependencies between the same pair of requirement entities, distinguish cross-version conflicts and same-version conflicts according to the versions where the dependencies are located, and perform a latest dependency reservation or a circular dependency elimination operation for marking respectively, and construct a dependency relationship graph. A component generation and verification module is configured to generate software components for each requirement entity in the dependency relationship graph and perform bidirectional semantic verification, backtrack the dependency relationship graph to locate a root cause and generate a repair suggestion when the verification fails, and obtain a component set that passes the verification. An architecture construction module is configured to establish component interaction relationships in the component set according to dependency relationship types in the dependency relationship graph, and obtain a software architecture. A time sequence verification and feedback module is configured to verify time sequence consistency of the software architecture based on a requirement evolution event and adjust component interaction relationships, and feed back verification results and repair suggestions to adjust dependency inference rules.

[0012] In a third aspect of the embodiment of the application, an electronic device is provided, which comprises: A processor; A memory for storing processor-executable instructions; The processor is configured to invoke the instructions stored in the memory to execute the method described above.

[0013] In a fourth aspect of the embodiment of the application, a computer readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method described above.

[0014] The application infers different types of dependency relationships based on time sequence semantic representation, innovatively distinguishes cross-version conflicts from same-version conflicts, adopts differentiated conflict resolution strategies, and effectively improves the accuracy and consistency of requirement dependency analysis. According to different dependency relationship types, the component interaction relationship is established, and the time sequence consistency of the software architecture is verified based on the requirement evolution event, realizing the dynamic adaptation capability of the software architecture to the requirement change. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 A flowchart of a software requirement automatic recognition and conversion method based on semantic modeling of an embodiment of the application is shown in Figure 2 A software component bidirectional verification and backtracking repair flowchart. DETAILED DESCRIPTION

[0016] To make the purpose, technical scheme and advantages of the embodiments of the application clearer, the technical scheme in the embodiments of the application will be described clearly and completely below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the application.

[0017] The technical scheme of the application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes can not be described in some embodiments.

[0018] Figure 1 A flowchart of a software requirement automatic recognition and conversion method based on semantic modeling of an embodiment of the application is shown in Figure 1 The method comprises the following steps: Obtaining multiple versions of requirement documents, extracting the semantic change time points and semantic change contents of requirement entities in different versions, and constructing a time sequence semantic representation; Based on the time sequence semantic representation, inferring the pre-dependence relationship, trigger dependence relationship or constraint dependence relationship between requirement entities. When there are contradictory dependencies between the same pair of requirement entities, distinguishing cross-version conflicts from same-version conflicts according to the version of the dependence and performing the resolution operation of retaining the latest dependence or marking the circular dependence respectively, and constructing a dependency relationship graph; Generating software components for each requirement entity in the dependency relationship graph and performing bidirectional semantic verification. When the verification fails, backtracking the dependency relationship graph to locate the root cause and generating a repair suggestion, and obtaining a component set that passes the verification; According to the dependency relationship type in the dependency relationship graph, establishing a component interaction relationship in the component set, and obtaining a software architecture; The temporal consistency of the software architecture is verified based on the demand evolution events, and the component interaction relationship is adjusted, and the verification result is fed back to adjust the dependency inference rule together with the repair suggestion.

[0019] In an optional implementation, multi-version requirement documents are acquired, and semantic change time points and semantic change contents of requirement entities in different versions are extracted, and the step of constructing the temporal semantic representation includes: A cross-version trace chain is established for each requirement entity in the multi-version requirement documents, and the cross-version trace chain records text descriptions, associated requirement entity identifiers, and version time stamps of the requirement entities in the versions; Semantic parsing is performed on the text descriptions, and three types of semantic elements, including functional intent, interface constraint, and state constraint, are extracted, when any semantic element of the same requirement entity changes between adjacent versions, the version time stamp is marked as a semantic change time point, and the difference before and after the change is marked as semantic change content; According to the associated requirement entity identifiers, a semantic association relationship between the requirement entities is established, and the semantic association relationship includes functional call association, data flow association, and state constraint association; The semantic change time points, semantic change contents, and semantic association relationship are organized into a temporal directed graph structure, the nodes of the temporal directed graph structure represent the semantic states of the requirement entities in the corresponding versions, and the edges represent the semantic association relationship or evolution relationship, and a temporal semantic representation is obtained.

[0020] For example, in the demand evolution process, the construction of the temporal semantic representation first needs to acquire multi-version requirement documents. These documents are usually stored in text form, and each version contains a certain number of requirement entities and their association relationships. Each version of the document has a corresponding time stamp, which identifies the time point of publishing the version.

[0021] When establishing a cross-version trace chain for each requirement entity, a composite tracing method based on ID matching and content similarity calculation can be used. In a specific implementation, first, a preliminary mapping relationship is established between different versions through the requirement ID, and for the case where the ID changes, a text similarity calculation method is used to determine the potential match. TF-IDF vector and cosine similarity are used to calculate the similarity of the requirement text, and when the similarity exceeds a preset threshold, such as 0.85, it is determined that it is different version expression of the same requirement entity.

[0022] After the construction of the traceability chain, three key pieces of information are recorded for each requirement entity in each version: the original text description, a list of other requirement entity IDs associated with it, and the timestamp of the version it belongs to. For example, the payment function requirement REQ-001 is described as "The system should support users to complete payment through bank cards" in V1.0 (2023-01-15), and the associated requirements include REQ-002 (account verification) and REQ-003 (transaction record); in V2.0 (2023-03-20), the description is updated to "The system should support users to complete transactions through bank cards and mobile payments."

[0023] A rule-based and deep learning combined method is used to perform semantic analysis on the text description to extract three types of semantic elements. The functional intent is determined by identifying verb phrases and target objects in the text, such as "support payment" and "verify user"; the interface constraint is extracted by identifying input / output parameters, preconditions, and calling methods, such as "receive user ID and amount as input"; and the state constraint identifies the state of the entity and the transition condition, such as "transaction status includes initialization, processing, completion, and failure."

[0024] After extracting the semantic elements, the differences between the same requirement entity in adjacent versions are compared. When any of the functional intent, interface constraint, or state constraint elements changes, the corresponding version timestamp is marked as the semantic change point. At the same time, the change content is recorded, such as the functional intent expanding from "support bank card payment" to "support bank card and mobile payment", and the interface constraint changing from "need to input card number and password" to "need to input card number / phone number and verification code".

[0025] According to the explicitly labeled associated requirement entity identifiers in the requirement document, combined with the semantic analysis results, the semantic association relationship between the requirement entities is established. The functional call association indicates that the function of one requirement entity calls the function provided by another requirement entity, such as "user authentication" calling "password verification"; the data flow association indicates that there is data transmission between the requirement entities, such as "payment processing" transmitting transaction data to "transaction record"; and the state constraint association indicates that the state change of one requirement entity will affect another requirement entity, such as "inventory check" determining whether "order placement" can be executed.

[0026] These association relationships can be identified by analyzing the verb-object structure, data object reference, and conditional statements in the requirement text. For example, "After payment is completed, the system generates a transaction record" indicates that there is a functional call association and a data flow association between "payment" and "transaction record".

[0027] When the acquired semantic change time points, change contents and association relationships are organized into a time-sequential directed graph structure, a graph data structure is adopted for representation. Each node in the graph represents a semantic state of a requirement entity in a specific version, including three attributes of functional intent, interface constraint and state constraint. Two types of edges are connected between nodes: evolution edges and association edges. Evolution edges connect nodes of the same requirement entity in different versions, with change time and change content marked on the edges; association edges connect nodes of different requirement entities, with association type marked on the edges, such as functional call, data flow or state constraint.

[0028] In actual application, taking software product requirement management as an example, it is assumed that the evolution of a "user authentication module" from V1.0 to V3.0 is tracked. In V1.0, only password login is supported, V2.0 adds short message verification code login, and V3.0 adds biological recognition login. Through construction of the time-sequential semantic representation, the evolution history of the function can be clearly shown: the semantic change from V1.0 to V2.0 is "functional intent extension (adding verification code login)", and the semantic change from V2.0 to V3.0 is "functional intent extension (adding biological recognition)" and "interface constraint change (adding biological feature collection interface)".

[0029] After the time-sequential semantic representation is constructed, it can be further applied to requirement change impact analysis, requirement conflict detection and requirement evolution trend prediction. By analyzing the paths and node attributes in the time-sequential directed graph, the chain effect caused by a certain requirement change can be identified, potential inconsistencies can be predicted, and a basis for requirement management decision-making can be provided.

[0030] The present application constructs a time-sequential directed graph structure, realizes accurate tracking of the requirement evolution process and complete expression of semantic association relationships, and provides an accurate semantic basis for subsequent dependency inference.

[0031] In an optional implementation, based on the time-sequential semantic representation, a preposition dependency relationship, a trigger dependency relationship or a constraint dependency relationship between requirement entities is inferred, when there is a contradictory dependency between the same pair of requirement entities, a cross-version conflict or a same-version conflict is distinguished according to the version where the dependency is located, and a latest dependency is retained or a circular dependency is marked for elimination operation, and the step of constructing a dependency relationship graph comprises: Requirement entity pairs and semantic association relationships are extracted from the time-sequential semantic representation, dependency relationships are inferred according to the chronological relationship of semantic change time points and the type of semantic association relationships, a preposition dependency relationship is inferred when the semantic change time point of a first requirement entity is earlier than that of a second requirement entity and there is a functional call association, a trigger dependency relationship is inferred when the semantic change content of the first requirement entity contains state change and the semantic change content of the second requirement entity contains response to the state change, and a constraint dependency relationship is inferred when there is a state constraint association and the state constraint of the first requirement entity restricts the functional intent of the second requirement entity; detecting opposite direction dependencies existing in the inferred dependencies, marking as contradictory dependencies and recording the version identification of each dependency when there are bidirectional dependencies between the first requirement entity and the second requirement entity; determining as cross-version conflict when the two dependencies in the contradictory dependencies are in different versions and keeping the dependency with newer version timestamp, determining as same-version conflict when the two dependencies in the contradictory dependencies are in the same version and marking as circular dependency; organizing the resolved dependencies into a directed graph structure to obtain a dependency graph.

[0032] Exemplarily, in the process of constructing a requirement dependency graph based on a time sequence semantic representation, first, requirement entity pairs and their semantic association relationships need to be extracted from the time sequence semantic representation, then dependency relationships are inferred based on specific rules, and finally contradictory dependencies are processed and a dependency graph is constructed.

[0033] All requirement entity nodes in the time sequence semantic representation are traversed, and for each pair of entity nodes, the semantic change time point and the semantic association relationship are analyzed. The semantic change time point usually exists in the time sequence semantic representation in the form of a timestamp, and the semantic association relationship includes functional call association, state change response association, and state constraint association, etc. For example, in the requirement description of a smart home system, there are two requirement entities "door lock state detection" and "security alarm triggering", and it is found through analysis that there is a state change response association between them.

[0034] Based on the extracted semantic association relationship and time point information, the dependency relationship type is inferred. When the semantic change time point of the first requirement entity is earlier than that of the second requirement entity and there is a functional call association, it is inferred as a preposition dependency. For example, in the "user authentication" and "personal information access" requirements in mobile application development, the semantic change time point of "user authentication" is T1, the semantic change time point of "personal information access" is T2, and T1 is earlier than T2, and there is a functional call association from "personal information access" to "user authentication", then it is inferred that "user authentication" is a preposition dependency of "personal information access".

[0035] When the semantic change content of the first requirement entity contains a state change and the semantic change content of the second requirement entity contains a response to the state change, it is inferred as a trigger dependency. For example, in a bank transaction system, the state change of the "account balance change" requirement entity, i.e. the balance being lower than a threshold, triggers the execution of the "balance insufficient notification" requirement entity, at which time the two form a trigger dependency.

[0036] When there exists a state constraint association and the state constraint of the first requirement entity restricts the functional intent of the second requirement entity, it is inferred as a constraint dependency relationship. For example, in a permission management system, the state of the "user role definition" requirement entity, such as a common user role, will restrict the execution scope of the "system function access" requirement entity (limiting access to administrator functions), forming a constraint dependency relationship.

[0037] After completing the dependency relationship inference, it is detected whether there is a contradictory dependency. All inferred dependency relationships are traversed to check whether there is a dependency pair in the opposite direction. When there is a bidirectional dependency between the first requirement entity and the second requirement entity, it is marked as a contradictory dependency and the version identifier of each dependency relationship is recorded. The version identifier is usually obtained from the version control information of the requirement document or the version metadata in the temporal semantic representation.

[0038] For the detected contradictory dependency, classification processing is performed according to the version of the dependency. When the two dependency relationships in the contradictory dependency are located in different versions, it is determined as a cross-version conflict. In processing the cross-version conflict, the version time stamps of the dependency relationships are compared, the dependency relationship with the newer version time stamp is retained, the dependency relationship of the older version is deleted from the dependency relationship set, and the resolution information is recorded in the metadata of the dependency relationship graph, including the source entity, the target entity, the dependency type, and the version number to which the deleted dependency belongs. For example, there is a precedent dependency from requirement A to requirement B in V1.0 version, and there is a precedent dependency from requirement B to requirement A in V2.0 version, then the dependency relationship in V1.0 is deleted, and only the dependency edge in V2.0 version is retained in the dependency relationship graph.

[0039] When the two dependency relationships in the contradictory dependency are located in the same version, it is determined as a same-version conflict, in which case the dependency relationship is not deleted, but a "circular dependency" marked attribute is added to the involved dependency edge. The circular dependency mark usually includes the dependency type, the involved requirement entity, and the version information, and a circular dependency report document is generated for further analysis and solution by the requirement analyst. The marked circular dependency edge is stored in the graph structure with special attributes, and the subsequent component generation stage can identify and take appropriate processing strategies. For example, there are a dependency from requirement C to requirement D and a dependency from requirement D to requirement C in V1.0 version, in which case the circular dependency is marked and detailed information is recorded, and a warning or manual intervention is required.

[0040] After resolving the contradictory dependency, the remaining valid dependency relationships are organized into a directed graph structure to build a dependency relationship graph. In the dependency relationship graph, the nodes represent the requirement entities, the directed edges represent the dependency relationships, and the types of the edges represent the three dependency types. The dependency relationship graph can be stored through data structures such as adjacency matrix or adjacency list, which is convenient for subsequent analysis and visual presentation.

[0041] After the dependency graph is constructed, further graph analysis can be performed, such as calculating the transitive closure of the graph to discover indirect dependencies, or performing a topological sort to determine the order of requirement implementation. For marked circular dependencies, the specific location and impact range of the circular dependency can be identified through strong connected component analysis of the graph.

[0042] The present application effectively solves the problem of contradictory dependencies and ensures the logical consistency of the dependency graph.

[0043] In an optional embodiment, the steps of generating software components for each requirement entity in the dependency graph and performing bidirectional semantic verification, backtracking the dependency graph to locate the root cause and generating repair suggestions when the verification fails, and obtaining a set of verified components include: Extracting the functional intent, interface constraint, and state constraint for each requirement entity in the dependency graph, generating component logic according to the functional intent, generating interface definitions according to the interface constraint, and generating state management mechanisms according to the state constraint, and combining them into software components; Performing forward verification on the software components, matching component logic with functional intent, comparing interface definitions with interface constraints, and checking state management mechanisms with state constraints, and marking as forward verification failed when any of them does not meet the requirements; Performing reverse verification on the software components, extracting functional features from component logic, interface parameters from interface definitions, and state rules from state management mechanisms, and comparing them with functional intent, interface constraint, and state constraint respectively to identify redundant functions, redundant interfaces, and redundant constraints, and marking as reverse verification failed when a redundant item is detected; When the forward verification fails, backtrack the prerequisite dependencies in the dependency graph to locate the root cause requirement entity of the missing function, and when the reverse verification fails, backtrack the triggering dependencies and constraint dependencies to locate the associated requirement entity that introduced the redundancy; generate repair suggestions based on the positioning results and adjust the software components, and then perform bidirectional semantic verification again, and when the verification passes, add the software components to the component set.

[0044] In combination Figure 2 The software component bidirectional verification and backtracking repair process is illustrated in the following figure. As an example, semantic decomposition is performed on each requirement entity in the dependency graph, and three types of core information are extracted: functional intent, interface constraint, and state constraint. Functional intent describes the business logic that the component should implement; interface constraint defines the specifications for the component to interact with external systems; and state constraint specifies the behavior changes of the component under different conditions. The extraction method uses semantic analysis techniques to segment the requirement text into functional description sentences, interface definition sentences, and state rule sentences, and constructs a semantic tree to extract key information.

[0045] Taking the user authentication requirement as an example, from the requirement "the system should verify the user's credentials, return a token on success, return an error code on failure, and lock the account after three consecutive failures", the functional intent can be extracted as "verify user credentials", the interface constraint as "input credentials, output token or error code", and the state constraint as "lock account after three consecutive failures".

[0046] Based on the extracted three types of information, three core parts of the software component are generated. According to the functional intent, the component code implementing the business logic is generated using preset code templates and domain-specific language conversion rules; according to the interface constraint, the interface specification such as input parameters, return value, and exception handling mechanism is defined; and according to the state constraint, the state machine or conditional branching logic is designed to achieve state transition and maintenance. Finally, the three parts are combined to form a complete software component.

[0047] In the user authentication example, the generated component includes the core function of verifying credentials, the interface defining the input of username and password and the output of token, and the state management code tracking the number of failures and triggering the lock.

[0048] After the component is generated, forward semantic verification is performed to ensure that the component fully meets the original requirement. Forward verification is divided into three dimensions: functional verification, interface verification, and state verification. Functional verification matches the component logic with the functional intent through semantic similarity calculation to determine whether the component has implemented all the functional points described in the requirement. Specifically, for each functional point in the functional intent, a semantic feature vector is extracted, and for the functional implementation in the component logic, a corresponding semantic feature vector is extracted, and the cosine similarity between the two is calculated. When the similarity is lower than a preset functional matching threshold such as 0.85, it is determined that the functional point has not been implemented; at the same time, the functional coverage is calculated, i.e. the ratio of the number of implemented functional points to the total number of functional points, and when the coverage is lower than a preset coverage threshold such as 0.95, it is marked as functional verification failure; interface verification checks whether the parameter type, number, and naming of the interface definition meet the interface constraint; state verification tests whether the state management mechanism correctly implements all the state transition rules defined in the state constraint. When any of the verification items does not meet the requirement, the forward verification is marked as failed.

[0049] At the same time, reverse semantic verification is performed to detect redundant elements in the component. Reverse verification is also divided into three dimensions: the actual functional characteristics are extracted from the component logic and compared with the original functional intent to identify additional functions; the parameter list is extracted from the interface definition and compared with the interface constraint to find redundant parameters; the state rules are extracted from the state management mechanism and compared with the state constraint to detect redundant states. When any redundant item is found, it is marked as reverse verification failure.

[0050] When a verification fails, the root cause is located by backtracking the dependency graph. A forward verification failure indicates a missing functionality, in which case the dependency graph is backtracked along the pre-dependency to find the requirement entity that leads to the incomplete functionality of the current component. For example, the payment processing component lacks the transaction verification functionality because the security verification requirement it depends on is not properly understood. A reverse verification failure indicates a redundancy, in which case the dependency graph is backtracked along the trigger dependency and the constraint dependency to find the associated requirement entity that introduces the redundancy. For example, the user management component contains an unrequired permission verification functionality because it mistakenly inherits the constraint from the permission management requirement.

[0051] Repair suggestions are generated according to the location results. For a missing functionality, the suggestions include adding a specific functionality module, adjusting the logic implementation, or reanalyzing the pre-dependency requirement; for a redundant functionality, the suggestions include removing the redundant functionality, separating the concerns, or clarifying the dependency between requirements. The repair suggestions are generated using natural language generation techniques to provide targeted guidance.

[0052] The software components are adjusted according to the repair suggestions, involving modifying the component logic, redefining the interface, or adjusting the state management mechanism. The adjusted components are again subjected to the bidirectional semantic verification process until they pass the verification, and the verified components are added to the final component set.

[0053] This iterative verification and repair process ensures that all components not only meet their respective requirements but also remain consistent with other components that depend on them, thereby building a high-quality, semantically consistent software system.

[0054] In an optional implementation, the step of locating the root cause requirement entity of the missing functionality when a forward verification fails, and locating the associated requirement entity that introduces the redundancy when a reverse verification fails, includes: When a forward verification fails, the semantic element type corresponding to the verification item marked as not met is extracted, and the dependency graph is backtracked from the current requirement entity along the reverse path of the pre-dependency; The semantic element of each pre-dependency requirement entity on the backtracking path is extracted, and the semantic elements of the pre-dependency requirement entity and the missing semantic elements of the current requirement entity are semantically matched. When the matching degree exceeds a preset matching degree threshold, the pre-dependency requirement entity is marked as the root cause requirement entity and the backtracking depth is calculated; When a reverse verification fails, the functional feature, interface parameter, or state rule corresponding to the detected redundant item is extracted, and the dependency graph is backtracked from the current requirement entity along the forward path of the trigger dependency and the constraint dependency. The semantic change content of each associated requirement entity on the backtracking path is extracted and semantically traced back to the redundant item. When the tracing back is successful, the associated requirement entity is marked as the redundancy introduction source and the backtracking path length is recorded; generate a repair suggestion containing a supplemental semantic element based on the trace depth, and generate a repair suggestion containing a redundant item deletion based on the trace path length.

[0055] For example, after a bidirectional semantic verification fails, the problem root cause is located through dependency graph backtracking and repair suggestions are generated. When forward verification fails, it indicates that the component has problems such as missing functionality, incomplete interface, or unimplemented state constraints, and the root cause requirement entity needs to be traced back to the preposition dependency. When reverse verification fails, it indicates that the component contains redundant functionality, redundant interface parameters, or additional state rules, and the redundant introduction source needs to be traced back to the trigger dependency and the constraint dependency.

[0056] When forward verification fails, the verification items marked as not met are extracted, and the corresponding semantic element type is determined. Functionality verification failure corresponds to missing functionality intent, interface verification failure corresponds to missing interface constraints, and state verification failure corresponds to missing state constraints. The current requirement entity node is located in the dependency graph, and backtracking is performed along the preposition dependency. Backtracking uses a breadth-first search strategy, which first checks direct preposition dependencies and then extends to indirect preposition dependencies. The upper limit of the backtracking depth is set to 3 to 5 layers.

[0057] For each preposition requirement entity on the backtracking path, the corresponding semantic elements are extracted from the temporal semantic representation, including functionality intent description, interface parameter type and return value type, state constraint condition and conversion rule. The semantic elements of the preposition requirement entity are matched with the missing semantic elements of the current requirement entity. Semantic matching converts two semantic elements into high-dimensional vectors and calculates the cosine similarity. The matching degree threshold is set to 0.7 to 0.85. When the matching degree exceeds the threshold, the preposition requirement entity is marked as the root cause requirement entity, and the backtracking depth is recorded. If there are multiple preposition requirement entities that match successfully, the one with the highest matching degree and the smallest backtracking depth is selected as the main root cause.

[0058] Taking the order confirmation component as an example, forward verification finds that the inventory check functionality is missing. Backtracking from the order confirmation requirement entity, it is found that the direct preposition dependencies include the inventory management requirement entity and the payment processing requirement entity. The functionality intent of the inventory management requirement entity is extracted, which includes "checking the inventory quantity of the goods and returning the available status". This semantic element is matched with the missing inventory verification logic, and the matching degree is calculated to be 0.92, which exceeds the threshold of 0.85, and the inventory management requirement entity is marked as the root cause with a backtracking depth of 1 layer.

[0059] When reverse verification fails, the detected redundant items are extracted, and the corresponding functionality characteristics, interface parameters, or state rules are determined. In the dependency graph, the trigger dependency and the constraint dependency are traced forward from the current requirement entity. Tracing uses a depth-first search strategy, which traces along a single dependency link until it finds the redundant introduction source or reaches the path length upper limit, which is set to 4 to 6 layers.

[0060] For each associated requirement entity on the trace path, extract its semantic change content, including newly added function description, modified interface definition, and adjusted state constraint. Trace the semantic change content with the redundancy item, and extract the semantic feature vector of the redundancy item and the feature vector of the semantic change content to calculate the similarity. When the similarity exceeds the trace threshold of 0.75, it is determined that the trace is successful, the associated requirement entity is marked as a redundancy introduction source, and the trace path length is recorded. If there are multiple associated requirement entities that are successfully traced, the one with the shortest path length and the highest similarity is selected as the main redundancy introduction source.

[0061] Take the user management component as an example, the reverse verification finds that it contains an unrequired multi-factor authentication function. Tracing from the user management requirement entity along the constraint dependency relationship, the state constraint of the security policy requirement entity is found. Extract the semantic change content of the latest version of the security policy requirement entity, and find that a new state constraint "mandatory enable multi-factor authentication" is added. Trace and match the semantic change content with the redundant function, and calculate the similarity to be 0.88, which exceeds the threshold 0.75. Mark the security policy requirement entity as a redundancy introduction source, and the trace path length is 1 layer.

[0062] Based on the root cause requirement entity and the trace depth located by backtracking, a repair suggestion for supplementing semantic elements is generated. The repair suggestion is generated in a templated manner, and a corresponding template is selected according to the type of the missing. When the function intent is missing, it is suggested to extract the business logic from the root cause requirement entity and integrate it into the current component; when the interface constraint is missing, it is suggested to supplement the interface parameter definition or return value specification; when the state constraint is missing, it is suggested to introduce a state transition rule. The repair suggestion includes the root cause requirement entity identifier, the missing semantic element content, the supplementing method, and the trace depth. When the trace depth is 1 to 2 layers, direct reference or inheritance is used, and when the trace depth is 3 layers or more, the component logic is redesigned or the dependency relationship is adjusted.

[0063] Based on the redundancy introduction source and the trace path length located by tracing, a repair suggestion for deleting the redundancy item is generated. The repair suggestion selects a deletion strategy according to the type of the redundancy item. When the redundant function feature is derived from semantic change, it is suggested to remove the function module or separate it into an independent component; when the redundant interface parameter is derived from excessive constraint, it is suggested to delete the redundant parameter or adjust the interface definition; when the redundant state rule is derived from error propagation, it is suggested to remove the redundant state or correct the transition logic. The repair suggestion includes the redundancy introduction source identifier, the redundancy item description, the deletion method, and the trace path length. When the trace path length is short, the redundancy item is directly deleted, and when the trace path length is long, the dependency relationship is re-evaluated or the requirement boundary is clarified.

[0064] The application locates the root cause of function loss along the preposition dependency relationship, locates the source of redundancy introduction along the trigger and constraint dependency relationship, generates targeted repair suggestions combining the backtracking depth and the length of the backtracking path, realizes accurate root cause positioning and effective repair guidance of verification failure, and improves the component quality and requirement consistency.

[0065] In an optional embodiment, the step of establishing component interaction relationship in the component set according to the dependency relationship type in the dependency relationship graph to obtain the software architecture comprises: According to the dependency relationship type, the software component corresponding to the requirement entity is retrieved in the component set, and the interface definition and the state management mechanism of the software component are extracted; When the dependency relationship type is the preposition dependency relationship, the calling interaction relationship is established according to the input parameter type and the output parameter type in the interface definition, and the output of the first software component is specified as the input of the second software component; when the dependency relationship type is the trigger dependency relationship, the event interaction relationship is established according to the state change event and the state response rule in the state management mechanism, and the state change of the first software component triggers the state response of the second software component; when the dependency relationship type is the constraint dependency relationship, the constraint interaction relationship is established according to the state constraint condition in the state management mechanism, and the state constraint of the first software component limits the execution condition of the second software component; The calling interaction relationship, the event interaction relationship and the constraint interaction relationship are organized into a hierarchical structure, the component hierarchy is determined according to the preposition dependency relationship in the dependency relationship graph, the software components without preposition dependency relationship are divided into a basic layer, and the software components with preposition dependency relationship are divided into an intermediate layer and an application layer according to the dependency depth to obtain the software architecture.

[0066] For example, the interface definition usually includes method name, input parameter type, output parameter type and exception handling mechanism and other elements. The state management mechanism includes the state set of the component, the state change event, the state response rule and the state constraint condition and other contents. For example, for a requirement entity of order management, the corresponding order management component can be retrieved in the component set, the interface definition of the component includes the create order method, the update order state method and the like, and the state management mechanism includes the "to be processed", "paid", "shipped", "completed" and the like states and the corresponding state change event and response rule.

[0067] According to different types of dependency relationships, corresponding interaction relationships are established. When the dependency relationship type is preposition dependency relationship, the calling interaction relationship is established by analyzing the input parameter type and the output parameter type in the interface definition. The specific operation is to check whether the output parameter type of the first software component matches the input parameter type of the second software component, and if it matches, the calling relationship is established, and the output of the first software component is specified as the input of the second software component. In the preposition dependency relationship, the first software component is the depended component, and the second software component is the component that depends on the first software component. For example, in the e-commerce platform, the payment processing component is the first software component, and its processing result can be used as the input parameter of the update order state method of the order management component, i.e. the second software component, thereby establishing the calling interaction relationship from the payment processing component to the order management component.

[0068] When the dependency relationship type is trigger dependency relationship, the event interaction relationship is established according to the state change event and the state response rule in the state management mechanism. The state change event generated by the first software component is identified, and then it is checked whether the second software component has a corresponding state response rule. If there is a matching event and response rule, the event interaction relationship is established, and the state change of the first software component triggers the state response of the second software component. In the trigger dependency relationship, the first software component generates a state change, and the second software component responds to the state change. For example, the inventory management component is the first software component, and the state change event that the commodity inventory quantity of the inventory management component is lower than the threshold value can trigger the automatic replenishment response rule of the procurement management component, i.e. the second software component, forming the event interaction relationship from the inventory management component to the procurement management component.

[0069] When the dependency relationship type is constraint dependency relationship, the constraint interaction relationship is established according to the state constraint condition in the state management mechanism. The specific implementation is to analyze how the state constraint of the first software component limits the execution condition of the second software component, and then establish the constraint interaction relationship between the two components. In the constraint dependency relationship, the first software component provides a state constraint condition, and the execution of the second software component is limited by the constraint condition. For example, the user permission component is the first software component, and the user permission state of the user permission component constitutes a constraint condition for the file operation component, i.e. the second software component. Only when the user has the corresponding permission, the file operation can be executed, which forms the constraint interaction relationship from the user permission component to the file operation component.

[0070] The calling interaction relationship, the event interaction relationship and the constraint interaction relationship are organized into a hierarchical structure. According to the pre-dependence relationship in the dependence relationship diagram, the component hierarchy is determined, and the software components without pre-dependence relationship are divided into a basic layer, which do not depend on other components and usually provide basic services. The software components with pre-dependence relationship are divided into an intermediate layer and an application layer according to the dependence depth. The dependence depth is calculated by starting from the basic layer component and along the forward path of the pre-dependence relationship. The components with a dependence depth of 1 are divided into the intermediate layer, and the components with a dependence depth of 2 and above are divided into the application layer. The intermediate layer components depend on the basic layer components and provide business logic and service combination. The application layer components depend on the intermediate layer or basic layer components and implement specific application functions. Through this hierarchical organization, a clear software architecture is obtained, and the dependence and interaction mode between the components are determined, which facilitates the understanding, maintenance and expansion of the architecture.

[0071] For example, a Web application includes data access components as a basic layer, business logic components as an intermediate layer, and user interface components as an application layer. The data access components provide data access interfaces and do not depend on other components, with a dependence depth of 0. The business logic components depend on the data access components and use the data services provided by the data access components to implement business logic, with a dependence depth of 1. The user interface components depend on the business logic components and implement user interaction functions through calling the business logic, with a dependence depth of 2. This hierarchical structure clearly expresses the dependence and interaction relationship between the software components and obtains a complete software architecture.

[0072] The present application establishes three types of interaction relationships according to the dependence relationship type and divides the hierarchical structure according to the dependence depth, ensuring the mapping accuracy of the software architecture and the requirement dependence and generating an executable architecture that conforms to the actual dependence logic.

[0073] In an optional embodiment, the time sequence consistency of the software architecture is verified based on a requirement evolution event, and the component interaction relationship is adjusted. The step of feeding back the verification result and the repair suggestion to adjust the dependence inference rule comprises: Requirement evolution events are extracted from the time sequence semantic representation, the requirement evolution events include semantic change time points, semantic change contents and semantic association relationships, affected software components are located in the software architecture, and the component interaction relationship is extracted and arranged in time sequence as an interaction time sequence chain; The semantic change time points are compared with the interaction occurrence time points in the interaction time sequence chain. When the semantic change time point is later than the interaction occurrence time point depending on the semantic, it is marked as a time sequence conflict. When the semantic change content causes interruption of data flow conversion or control flow conversion, it is marked as an interaction interruption. adjusting the component hierarchy of the affected software component when a timing conflict is detected, and regenerating the interface definition or state management mechanism of the affected software component according to the semantic change content and updating the component interaction relationship when an interaction interruption is detected; estimating an error rate of a dependency type corresponding to the timing conflict and the interaction interruption, generating a dependency estimation rule adjustment suggestion and updating the dependency estimation rule when the error rate exceeds a preset error rate threshold, the dependency estimation rule adjustment suggestion including a semantic association relationship type that needs to be strengthened and a semantic change time point determination condition that needs to be weakened.

[0074] Exemplarily, after the software architecture construction is completed, the timing consistency of the architecture in the requirement evolution process needs to be verified and the component interaction relationship needs to be dynamically adjusted, and the verification result is fed back to optimize the dependency estimation rule. Requirement evolution events are extracted from the timing directed graph structure of the timing semantic representation, each requirement evolution event including three core elements: a semantic change time point recorded in the form of a version timestamp, a semantic change content including the difference before and after the change of a functional intent, an interface constraint or a state constraint, and a semantic association relationship including a functional call association, a data flow conversion association and a state constraint association. The extraction method traverses the evolution edges of the timing directed graph. The evolution edges connect the nodes of the same requirement entity in different versions, and the timestamp marked on the edge is the semantic change time point, and the change content recorded on the edge is the semantic change content, and the association edges between the nodes are extracted to obtain the semantic association relationship type.

[0075] The software components affected by the requirement evolution events are located in the software architecture, and the corresponding software components are retrieved in the component set according to the requirement entity involved in the requirement evolution event. If the semantic change content involves a functional intent change, the affected components include the component corresponding to the requirement entity and all successor components in the dependency relationship graph; if it involves an interface constraint change, the affected components include all components that have a call interaction relationship with the component; if it involves a state constraint change, the affected components include all components that have an event interaction relationship or a constraint interaction relationship with the component. The call interaction relationship, the event interaction relationship and the constraint interaction relationship between the affected components are extracted, and the interaction timing chain is arranged in time sequence according to the logical order and the dependency depth of the interaction occurrence. The interaction occurrence time is determined by analyzing the execution timing of the component, the occurrence time of the call interaction relationship is the time point when the called component execution is completed, the occurrence time of the event interaction relationship is the time point when the triggering event is generated, and the occurrence time of the constraint interaction relationship is the time point when the execution constraint check is performed.

[0076] The semantic change time points of the requirement evolution events are compared with the interaction occurrence time in the interaction time sequence chain one by one to detect the time sequence conflicts and interaction interruptions. The time sequence conflict detection traverses the interaction time sequence chain, extracts the semantic elements relied on by each interaction relationship, finds the latest change time point of the semantic elements in the time sequence semantic representation, and marks a time sequence conflict and records the components, interaction types and time difference involved in the conflict when the semantic change time point is later than the interaction occurrence time. The time difference calculation method is the semantic change time point minus the interaction occurrence time, and the larger the time difference, the more serious the time sequence conflict. The interaction interruption detection analyzes the influence of the semantic change content on the data flow transfer and the control flow transfer, and marks an interaction interruption when the semantic change content causes the interface parameter type mismatch, the missing of the required parameter, the change of the return value type, the interruption of the state transition path or the invalidation of the constraint condition. The data flow interruption detection compares the interface definitions before and after the change, checks the compatibility of the input parameter list and the output parameter list, and determines the interruption when the parameter quantity changes, the types are incompatible or the required parameters are deleted. The control flow interruption detection analyzes the change of the state management mechanism, and checks whether the state transition rules and the constraint conditions cause the original control path to be unable to execute.

[0077] When a time sequence conflict is detected, the component hierarchy of the affected software component is adjusted according to the severity and the influence range of the conflict. The severity of the time sequence conflict is evaluated by the time difference and the number of affected interactions, and the time difference exceeding 30 days or the number of affected interactions exceeding 5 is determined as high severity, requiring the re-calculation of the dependency depth of the affected component and the adjustment of the component hierarchy. The dependency depth re-calculation starts from the base layer component, traverses along the forward path of the preposition dependency relationship, and increases the dependency depth of the component affected by the time sequence conflict by 1, ensuring that the dependency relationship after the semantic change is correctly reflected in the hierarchy structure.

[0078] When an interaction interruption is detected, the interface definition or the state management mechanism of the affected software component is regenerated according to the semantic change content and the component interaction relationship is updated. The interface definition regeneration extracts the interface constraint changes in the semantic change content, including the addition of parameters, the deletion of parameters, the change of parameter types and the change of return values, and redefines the input parameter type, the output parameter type and the exception handling mechanism of the interface according to the changed interface constraint. The parameter adaptation strategy includes providing a default value for the added required parameter, marking the deleted parameter as obsolete but retaining compatibility, and adding type conversion logic for the type-changed parameter. The state management mechanism regeneration extracts the state constraint changes in the semantic change content, redesigns the state set, the state change event, the state response rule and the state constraint condition according to the changed state constraint. The component interaction relationship update includes modifying the interface mapping of the calling interaction relationship, adjusting the event subscription rule of the event interaction relationship, and updating the constraint checking logic of the constraint interaction relationship. The update operation uses a transaction mechanism to ensure consistency.

[0079] The error rate calculation method of the inference of the dependency relationship type corresponding to the time sequence conflict and interaction interruption is the number of conflicts or interruptions of a specific dependency relationship type divided by the total number of the dependency relationship type, and the error rates of the preceding dependency relationship, the trigger dependency relationship and the constraint dependency relationship are respectively counted. The inference error rate threshold is set to 15%, and when the inference error rate of a certain type of dependency relationship exceeds the threshold, an adjustment suggestion of dependency inference rule is generated. The adjustment suggestion includes the semantic association relationship type that needs to be strengthened and the semantic change time point judgment condition that needs to be weakened. The semantic association relationship type that needs to be strengthened is determined according to the error distribution, if the preceding dependency error rate is high, the recognition weight of the function call association is strengthened, and the matching degree threshold is increased from 0.7 to 0.8; if the trigger dependency error rate is high, the recognition of the data flow conversion association and the state constraint association is strengthened; if the constraint dependency error rate is high, the constraint condition extraction of the state constraint association is strengthened. The semantic change time point judgment condition that needs to be weakened relaxes the sensitivity of the semantic change judgment for the scene where the time sequence conflict frequently occurs, sets the change range threshold, and only when the semantic similarity of the function intent is lower than 0.9, the interface parameter change is more than 20% or the state number change is more than 2, it is marked as significant change. The update dependency inference rule applies the adjustment suggestion to the dependency inference process, modifies the algorithm parameter of the semantic association relationship, adjusts the threshold configuration of the semantic change detection, optimizes the inference logic of the dependency relationship type, forms a new version of the dependency inference rule and records the version number and the adjustment basis.

[0080] The present application dynamically adjusts the software architecture and continuously optimizes the dependency inference rule through the demand evolution event driven time sequence consistency verification, and significantly improves the response ability of the architecture to demand evolution and the accuracy of dependency relationship inference.

[0081] In a second aspect of the embodiments of the present application, a software demand automatic recognition and transformation system based on semantic modeling is provided, comprising: A time sequence semantic construction module is configured to acquire multiple versions of demand documents, extract semantic change time points and semantic change contents of demand entities in different versions, and construct a time sequence semantic representation; A dependency relationship inference module is configured to infer preceding dependency relationships, trigger dependency relationships or constraint dependency relationships between demand entities based on the time sequence semantic representation, when there are contradictory dependencies between the same pair of demand entities, distinguish cross-version conflicts and same-version conflicts according to the versions of the dependencies, and perform a preserving latest dependency or a marking circular dependency elimination operation respectively, and construct a dependency relationship graph; A component generation and verification module is configured to generate software components for each demand entity in the dependency relationship graph and perform bidirectional semantic verification, when the verification fails, backtrack the dependency relationship graph to locate the root cause and generate a repair suggestion, and obtain a set of verified components; An architecture construction module is configured to establish component interaction relationships in the set of components according to the dependency relationship types in the dependency relationship graph, and obtain a software architecture. a timing verification and feedback module configured to verify timing consistency of the software architecture based on the requirement evolution event and adjust component interaction relationship, and feed back verification result and repair suggestion to adjust dependency inference rule.

[0082] In a third aspect, the present application provides an electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to perform the method described above.

[0083] In a fourth aspect, the present application provides a computer-readable storage medium having stored thereon computer program instructions, which when executed by a processor, implement the method described above.

[0084] The present application can be a method, apparatus, system and / or computer program product. The computer program product can include a computer-readable storage medium having computer-readable program instructions stored therein, which are used to perform various aspects of the present application.

[0085] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for automatic identification and transformation of software requirements based on semantic modeling, characterized in that, include: Obtain multiple versions of requirement documents, extract the semantic change time points and semantic change content of requirement entities in different versions, and construct a temporal semantic representation; Based on the temporal semantic representation, the preceding dependencies, triggering dependencies, or constraint dependencies between demand entities are inferred. When there are contradictory dependencies between the same pair of demand entities, cross-version conflicts and same-version conflicts are distinguished according to the version of the dependency and the resolution operations of retaining the latest dependency or marking the circular dependency are performed respectively to construct a dependency graph. For each requirement entity in the dependency graph, a software component is generated and bidirectional semantic verification is performed. When the verification fails, the dependency graph is backtracked to locate the root cause and a repair suggestion is generated to obtain a set of components that have passed the verification. Based on the dependency relationship types in the dependency graph, component interaction relationships are established in the component set to obtain the software architecture; Verify the temporal consistency of the software architecture based on demand evolution events and adjust the interaction relationships of components. Feedback the verification results and repair suggestions to adjust the dependency inference rules.

2. The method according to claim 1, characterized in that, The steps to obtain multiple versions of requirements documents, extract the semantic change time points and semantic change content of requirement entities in different versions, and construct a temporal semantic representation include: Establish a cross-version traceability chain for each requirement entity in a multi-version requirement document. The cross-version traceability chain records the text description of the requirement entity in each version, the associated requirement entity identifier, and the version timestamp. Semantic parsing is performed on the text description to extract three types of semantic elements: functional intent, interface constraints, and state constraints. When any semantic element of the same requirement entity changes between adjacent versions, the version timestamp is marked as the semantic change time point, and the difference before and after the change is marked as the semantic change content. Based on the associated demand entity identifier, establish semantic associations between demand entities, including function call associations, data flow associations, and state constraint associations; The semantic change time points, semantic change content, and semantic relationships are organized into a temporal directed graph structure. The nodes of the temporal directed graph structure represent the semantic state of the demand entity in the corresponding version, and the edges represent semantic relationships or evolutionary relationships, thus obtaining a temporal semantic representation.

3. The method according to claim 1, characterized in that, Based on the temporal semantic representation, the pre-dependent relationships, triggering dependencies, or constraint dependencies between demand entities are inferred. When there are conflicting dependencies between the same pair of demand entities, cross-version conflicts and intra-version conflicts are distinguished according to the version of the dependency, and the resolution operations of retaining the latest dependency or marking circular dependencies are performed respectively. The steps of constructing the dependency graph include: Extract demand entity pairs and semantic relationships from the temporal semantic representation. Infer dependency relationships based on the order of semantic change times and the type of semantic relationship. When the semantic change time of the first demand entity is earlier than that of the second demand entity and there is a function call relationship, it is inferred to be a pre-dependency relationship. When the semantic change content of the first demand entity includes a state change and the semantic change content of the second demand entity includes a response to the state change, it is inferred to be a trigger dependency relationship. When there is a state constraint relationship and the state constraint of the first demand entity restricts the functional intent of the second demand entity, it is inferred to be a constraint dependency relationship. The system detects and infers the existence of opposing dependencies in the inferred dependencies. When there is a bidirectional dependency between the first and second demand entities, it is marked as a contradictory dependency and the version identifier of each dependency is recorded. When two dependencies in a contradictory dependency are in different versions, it is determined to be a cross-version conflict and the dependency with the newer version timestamp is retained. When two dependencies in a contradictory dependency are in the same version, it is determined to be a same-version conflict and is marked as a circular dependency. The resolved dependencies are organized into a directed graph structure to obtain the dependency graph.

4. The method according to claim 1, characterized in that, The steps of generating software components for each requirement entity in the dependency graph and performing bidirectional semantic verification, backtracking the dependency graph to locate the root cause and generating remediation suggestions when verification fails, and obtaining a set of verified components include: For each requirement entity in the dependency graph, extract functional intent, interface constraints, and state constraints. Generate component logic based on functional intent, generate interface definitions based on interface constraints, and generate state management mechanisms based on state constraints. Combine these into software components. Forward verification is performed on the software component, matching the component logic with the functional intent, comparing the interface definition with the interface constraint, and verifying the state management mechanism with the state constraint. If any one of these conditions is not met, the forward verification is marked as failed. Reverse verification is performed on the software component to extract the functional characteristics in the component logic, the interface parameters in the interface definition, and the state rules in the state management mechanism. These are then compared with the functional intent, interface constraints, and state constraints to identify redundant functions, redundant interfaces, and redundant constraints. When a redundant item is detected, it is marked as a reverse verification failure. When forward verification fails, trace back the preceding dependencies in the dependency graph to locate the root cause requirement entity with missing functionality. When reverse verification fails, trace back the triggering dependencies and constraint dependencies to locate redundant associated requirement entities. Based on the location results, generate repair suggestions and adjust the software component before re-executing bidirectional semantic verification. When the verification passes, add the software component to the component set.

5. The method according to claim 4, characterized in that... When forward verification fails, the steps of tracing the preceding dependencies in the dependency graph to locate the root cause requirement entity with missing functionality, and tracing the triggering and constraining dependencies to locate redundant associated requirement entities when reverse verification fails, include: When forward verification fails, extract the semantic element type corresponding to the verification item marked as not satisfied, and backtrack from the current requirement entity along the reverse path of the preceding dependency in the dependency graph; For each preceding demand entity on the backtracking path, extract the corresponding semantic elements, perform semantic matching between the semantic elements of the preceding demand entity and the missing semantic elements of the current demand entity, and mark the preceding demand entity as the root cause demand entity and calculate the backtracking depth when the matching degree exceeds the preset matching degree threshold; When reverse verification fails, extract the functional characteristics, interface parameters, or state rules corresponding to the detected redundant items. In the dependency graph, trace back from the current requirement entity along the forward path of triggering and constraining dependencies. Extract the semantic change content of each associated requirement entity on the tracing path and perform semantic source tracing with the redundant items. When the source tracing is successful, mark the associated requirement entity as the source of redundancy and record the length of the tracing path. Based on the backtracking depth, a repair suggestion containing supplementary semantic elements is generated; based on the tracing path length, a repair suggestion containing the deletion of redundant items is generated.

6. The method according to claim 1, characterized in that, The steps to establish component interaction relationships in the component set based on the dependency relationship types in the dependency graph to obtain the software architecture include: Based on the dependency type, retrieve the software component corresponding to the requirement entity from the component set, and extract the interface definition and state management mechanism of the software component; When the dependency type is a pre-dependency, a call interaction relationship is established based on the input parameter type and output parameter type in the interface definition, specifying the output of the first software component as the input of the second software component; when the dependency type is a trigger dependency, an event interaction relationship is established based on the state change event and state response rules in the state management mechanism, specifying that the state change of the first software component triggers the state response of the second software component; when the dependency type is a constraint dependency, a constraint interaction relationship is established based on the state constraint conditions in the state management mechanism, specifying that the state constraints of the first software component restrict the execution conditions of the second software component. The call interaction relationship, event interaction relationship and constraint interaction relationship are organized into a hierarchical structure. The component level is determined according to the pre-dependency relationship in the dependency relationship graph. Software components without pre-dependency relationships are divided into the basic layer. Software components with pre-dependency relationships are divided into the intermediate layer and the application layer according to the dependency depth, thus obtaining the software architecture.

7. The method according to claim 1, characterized in that, The steps for verifying the temporal consistency of the software architecture based on requirement evolution events and adjusting component interaction relationships, and feeding back the verification results and remediation suggestions to adjust dependency inference rules, include: Demand evolution events are extracted from the temporal semantic representation. Each demand evolution event includes a semantic change time point, semantic change content, and semantic association. Affected software components are located in the software architecture, and the interaction relationships of the components are extracted and arranged in temporal order as an interaction temporal chain. The semantic change time point is compared with the interaction occurrence time in the interaction time sequence chain. When the semantic change time point is later than the interaction occurrence time that depends on the semantic, it is marked as a timing conflict. When the semantic change content causes the interruption of data flow or control flow, it is marked as an interaction interruption. When a timing conflict is detected, the component hierarchy of the affected software component is adjusted. When an interaction interruption is detected, the interface definition or state management mechanism of the affected software component is regenerated based on the semantic changes, and the component interaction relationships are updated. The system calculates the inference error rate of dependency relationship types corresponding to time-series conflicts and interaction interruptions. When the inference error rate exceeds a preset error rate threshold, it generates a dependency inference rule adjustment suggestion and updates the dependency inference rule. The dependency inference rule adjustment suggestion includes the semantic relationship types that need to be strengthened and the semantic change time point judgment conditions that need to be weakened.

8. A software requirement automatic identification and transformation system based on semantic modeling, used to implement the method of any one of claims 1-7, characterized in that, include: The temporal semantic construction module is used to obtain multiple versions of requirement documents, extract the time points and content of semantic changes of requirement entities in different versions, and construct a temporal semantic representation. The dependency inference module is used to infer the pre-dependencies, triggering dependencies, or constraint dependencies between demand entities based on the temporal semantic representation. When there are contradictory dependencies between the same pair of demand entities, it distinguishes between cross-version conflicts and same-version conflicts according to the version of the dependency and performs the resolution operation of retaining the latest dependency or marking the circular dependency respectively, and constructs a dependency graph. The component generation and verification module is used to generate software components for each requirement entity in the dependency graph and perform bidirectional semantic verification. When the verification fails, the module backtracks the dependency graph to locate the root cause and generates a repair suggestion to obtain a set of verified components. An architecture building module is used to establish component interaction relationships in the component set according to the dependency relationship types in the dependency graph, thereby obtaining the software architecture. The timing verification and feedback module is used to verify the timing consistency of the software architecture based on requirement evolution events and adjust the interaction relationship of components. The verification results and repair suggestions are fed back to adjust the dependency inference rules.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images