Method and system for automatic identification and transformation of software requirements based on semantic modeling

Abstract

The application provides a software requirement automatic recognition and conversion method and system based on semantic modeling, relates to the technical field of software development, and comprises the following steps: obtaining multiple versions of requirement documents and constructing a time sequence semantic representation; inferring a dependency relationship between requirement entities and resolving conflicts to construct a dependency relationship graph; generating software components for the requirement entities and performing semantic verification, locating a root cause and repairing; establishing a component interaction relationship to form a software architecture; and verifying time sequence consistency and optimizing dependency inference rules. The application can automatically track requirement evolution, recognize dependency conflicts, realize accurate conversion from requirements to a software architecture, and improve software development efficiency and quality.

Description

Technical Field

[0001] This invention relates to software development technology, and more particularly to a method and system for automatic identification and transformation of software requirements based on semantic modeling. Background Technology

[0002] As software systems grow in size and complexity, software requirements management has become a crucial aspect of software engineering. Software requirements documents, typically describing user-expected system functions and characteristics in natural language, need to be accurately translated into software components and architectural designs. During software development, requirements frequently change, making the management of multi-version requirements documents and the analysis of requirements evolution essential for maintaining the consistency and stability of the software system. Existing methods struggle to automatically identify and resolve conflicting dependencies, particularly in distinguishing between cross-version and same-version conflicts, often requiring manual intervention from developers, increasing development costs and the risk of errors. Summary of the Invention

[0003] This invention provides a method and system for automatic identification and transformation of software requirements based on semantic modeling, which can solve the problems in the prior art.

[0004] A first aspect of this invention provides a method for automatic identification and transformation of software requirements based on semantic modeling, comprising:

[0005] 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;

[0006] 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.

[0007] 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.

[0008] Based on the dependency relationship types in the dependency graph, component interaction relationships are established in the component set to obtain the software architecture;

[0009] 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.

[0010] 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:

[0011] 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.

[0012] 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.

[0013] Based on the associated demand entity identifier, establish semantic associations between demand entities, including function call associations, data flow associations, and state constraint associations;

[0014] 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.

[0015] 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:

[0016] 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.

[0017] 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.

[0018] 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.

[0019] 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:

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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:

[0025] 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;

[0026] 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;

[0027] 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.

[0028] 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.

[0029] 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:

[0030] 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;

[0031] 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.

[0032] 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.

[0033] 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:

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] A second aspect of this invention provides a system for automatic identification and transformation of software requirements based on semantic modeling, comprising:

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] A third aspect of the present invention provides an electronic device, comprising:

[0045] processor;

[0046] Memory used to store processor-executable instructions;

[0047] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0048] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0049] This invention infers different types of dependencies based on temporal semantic representation and innovatively distinguishes between cross-version conflicts and intra-version conflicts, employing differentiated conflict resolution strategies to effectively improve the accuracy and consistency of requirement dependency analysis. It establishes corresponding component interaction relationships according to different dependency types and verifies the temporal consistency of the software architecture based on requirement evolution events, thus realizing the dynamic adaptability of the software architecture to requirement changes. Attached Figure Description

[0050] Figure 1 This is a flowchart illustrating the automatic identification and transformation method for software requirements based on semantic modeling, as described in an embodiment of the present invention.

[0051] Figure 2 This is a flowchart for two-way verification and backtracking repair of software components. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0054] Figure 1This is a flowchart illustrating the automatic identification and transformation method for software requirements based on semantic modeling, as described in an embodiment of the present invention. Figure 1 As shown, the method includes:

[0055] 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;

[0056] 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.

[0057] 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.

[0058] Based on the dependency relationship types in the dependency graph, component interaction relationships are established in the component set to obtain the software architecture;

[0059] 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.

[0060] In one optional implementation, the steps of obtaining multiple versions of requirement documents, extracting the semantic change time points and semantic change content of requirement entities in different versions, and constructing a temporal semantic representation include:

[0061] 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.

[0062] 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.

[0063] Based on the associated demand entity identifier, establish semantic associations between demand entities, including function call associations, data flow associations, and state constraint associations;

[0064] 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.

[0065] For example, during the evolution of requirements, building a temporal semantic representation first requires obtaining multiple versions of requirement documents. These documents are typically stored in text format, and each version contains a certain number of requirement entities and the relationships between them. Each version of the document has a corresponding timestamp, identifying the time when that version was released.

[0066] When establishing a cross-version traceability chain for each demand entity, a composite traceability method based on ID matching and content similarity calculation can be adopted. In the specific implementation, a preliminary mapping relationship is first established between different versions using the demand ID. For cases where the ID changes, a text similarity calculation method is used to determine potential matches. TF-IDF vectors and cosine similarity are used to calculate the similarity of the demand text. If the similarity exceeds a preset threshold, such as 0.85, it is determined to be different versions of the same demand entity.

[0067] After the traceability chain is constructed, 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, a payment function requirement REQ-001 is described in version V1.0 (2023-01-15) as "The system should support users to complete payments via bank cards," with associated requirements including REQ-002 (account verification) and REQ-003 (transaction records); in version V2.0 (2023-03-20), the description is updated to "The system should support users to complete transactions via bank cards and mobile payments."

[0068] A combination of rule-based and deep learning methods is used to perform semantic parsing on text descriptions to extract three types of semantic elements. Functional intent is determined by identifying verb phrases and target objects in the text, such as "support payment" and "verify user". Interface constraints are extracted by identifying input / output parameters, preconditions, and invocation methods, such as "receive user ID and amount as input". State constraints identify the state of entities and transition conditions, such as "transaction states include initialization, processing, completion, and failure".

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

[0070] Based on the explicitly marked associated requirement entity identifiers in the requirements document and combined with the semantic analysis results, establish semantic relationships between requirement entities. Function call relationship indicates that a function of one requirement entity calls a function provided by another requirement entity, such as "user authentication" calling "password verification"; data flow relationship indicates that there is data transfer between requirement entities, such as "payment processing" transferring transaction data to "transaction records"; state constraint relationship indicates that a change in the state of one requirement entity will affect another requirement entity, such as the state of "inventory check" determining whether "place an order" can be executed.

[0071] These relationships can be identified by analyzing verb-object structures, data object references, and conditional statements in the requirement text. For example, "The system generates a transaction record after payment is completed" indicates a functional call relationship and a data flow relationship between "payment" and "transaction record".

[0072] When organizing the acquired semantic change time points, change content, and relationships into a temporal directed graph structure, a graph data structure is used for representation. Each node in the graph represents the semantic state of a requirement entity in a specific version, containing three attributes: functional intent, interface constraints, and state constraints. Nodes are connected by two types of edges: evolutionary edges and association edges. Evolutionary edges connect nodes of the same requirement entity across different versions, with the change time and content marked on the edge; association edges connect nodes of different requirement entities, with the association type marked on the edge, such as function call, data flow, or state constraint.

[0073] In practical applications, taking software product requirements management as an example, let's assume we're tracking the evolution of the "user authentication module" from V1.0 to V3.0. V1.0 only supported password login, V2.0 added SMS verification code login, and V3.0 added biometric login. By constructing a temporal semantic representation, we can clearly show the evolution of this function: the semantic change from V1.0 to V2.0 is "functional intent expansion (adding verification code login)," and the semantic change from V2.0 to V3.0 is "functional intent expansion (adding biometrics)" and "interface constraint change (adding a biometric feature collection interface)."

[0074] Once the temporal semantic representation is constructed, it can be further applied to demand change impact analysis, demand conflict detection, and demand evolution trend prediction. By analyzing the path and node attributes in the temporal directed graph, the chain effects caused by a demand change can be identified, potential inconsistencies can be predicted, and a basis for demand management decisions can be provided.

[0075] This invention constructs a temporal directed graph structure, which enables accurate tracking of the demand evolution process and complete expression of semantic relationships, providing an accurate semantic foundation for subsequent dependency inference.

[0076] In one optional implementation, the pre-dependencies, triggering dependencies, or constraint dependencies between demand entities are inferred based on the temporal semantic representation. When contradictory dependencies exist 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:

[0077] 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.

[0078] 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.

[0079] 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.

[0080] For example, in the process of constructing a demand dependency graph based on temporal semantic representation, it is first necessary to extract demand entity pairs and their semantic relationships from the temporal semantic representation, then infer the dependency relationship based on specific rules, and finally handle the existing contradictory dependencies and construct the dependency graph.

[0081] The process iterates through all requirement entity nodes in the temporal semantic representation. For each pair of entity nodes, it analyzes their semantic change time points and semantic relationships. Semantic change time points typically exist in the temporal semantic representation as timestamps, while semantic relationships include types such as function call relationships, state change response relationships, and state constraint relationships. For example, in the requirement description of a smart home system, there are two requirement entities: "door lock status detection" and "security alarm triggering." Analysis reveals a state change response relationship between them.

[0082] Based on the extracted semantic relationships and time information, the dependency type is inferred. When the semantic change time of the first requirement entity is earlier than that of the second requirement entity and there is a function call association, it is inferred to be a prerequisite dependency. For example, in the "user authentication" and "personal profile access" requirements in mobile application development, the semantic change time of "user authentication" is T1, and the semantic change time of "personal profile access" is T2, and T1 is earlier than T2. ​​At the same time, there is a function call association from "personal profile access" to "user authentication", so it is inferred that "user authentication" is a prerequisite dependency of "personal profile access".

[0083] 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 that state change, a trigger dependency relationship is inferred. Taking a banking transaction system as an example, the state change of the "account balance change" demand entity (i.e., the balance is lower than the threshold) triggers the execution of the "insufficient balance notification" demand entity, and the two form a trigger dependency relationship.

[0084] When a state constraint relationship exists 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. For example, in a permission management system, the state of the "user role definition" demand entity, such as a regular user role, will restrict the execution scope of the "system function access" demand entity (restricting access to administrator functions), thus forming a constraint dependency relationship.

[0085] After dependency inference is completed, conflicting dependencies are checked. All inferred dependencies are traversed, and pairs of dependencies with opposite directions are checked. When a bidirectional dependency exists between the first and second requirement entities, it is marked as a conflicting dependency, and the version identifier of each dependency is recorded. Version identifiers are typically obtained from version control information in the requirements document or version metadata in the temporal semantic representation.

[0086] For detected conflicting dependencies, they are categorized and processed according to the version they belong to. When two dependencies in a conflicting dependency reside in different versions, it is determined to be a cross-version conflict. When handling cross-version conflicts, the version timestamps of the dependencies are compared. Dependencies with the newer version timestamp are retained, while older version dependencies are deleted from the dependency set. Simultaneously, resolution information is recorded in the metadata of the dependency graph, including the source entity, target entity, dependency type, and version number of the deleted dependency. For example, if version V1.0 has a prerequisite dependency from requirement A to requirement B, while version V2.0 has a prerequisite dependency from requirement B to requirement A, then the dependency in V1.0 is deleted, and only the dependency edges from version V2.0 are retained in the dependency graph.

[0087] When two dependencies in a conflicting dependency exist in the same version, they are considered version-incompatible. Instead of deleting the dependencies, a "circular dependency" marker is added to the involved dependency edges. The circular dependency marker typically includes the dependency type, the involved requirement entities, and version information. A circular dependency report is also generated for requirements analysts to further analyze and resolve. Marked circular dependency edges are stored in the graph structure with special attributes, allowing for identification and appropriate handling strategies during subsequent component generation. For example, in version V1.0, if there are dependencies from requirement C to requirement D and from requirement D to requirement C, this is marked as a circular dependency, detailed information is recorded, and a warning is issued or manual intervention is required.

[0088] After resolving contradictory dependencies, the remaining valid dependencies are organized into a directed graph structure, constructing a dependency graph. In the dependency graph, nodes represent demand entities, directed edges represent dependencies, and the edge type represents one of the three dependency types. The dependency graph can be stored using data structures such as adjacency matrices or adjacency lists, facilitating subsequent analysis and visualization.

[0089] Once the dependency graph is constructed, further graph analysis can be performed, such as computational graph transitive closure to discover indirect dependencies, or topological sorting to determine the order in which requirements are implemented. For marked circular dependencies, the specific location and scope of influence of the circular dependencies can be identified through strongly connected component analysis of the graph.

[0090] This invention effectively solves the problem of contradictory dependencies and ensures the logical consistency of the dependency graph.

[0091] In one optional implementation, the steps of generating software components for each requirement entity in the dependency graph and performing bidirectional semantic verification, and backtracking the dependency graph to locate the root cause and generate remediation suggestions when verification fails, to obtain a set of verified components, include:

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] Combination Figure 2 The flowchart for two-way verification and backtracking repair of software components is illustrated. For example, semantic decomposition is performed on each requirement entity in the dependency graph to extract three types of core information: functional intent, interface constraints, and state constraints. Functional intent describes the business logic that the component should implement; interface constraints define the specifications for the component's interaction with external systems; and state constraints specify the component's behavioral changes under different conditions. The extraction method employs semantic analysis technology, segmenting the requirement text into functional description sentences, interface definition sentences, and state rule sentences, and constructing a semantic tree to extract key information.

[0097] Taking user authentication requirements as an example, from the requirement that "the system should verify user credentials, return a token when successful, return an error code when unsuccessful, and lock the account after three consecutive failures", the functional intent can be extracted as "verify user credentials", the interface constraint is "input credentials, output token or error code", and the state constraint is "lock the account after three consecutive failures".

[0098] Based on the three types of extracted information, three core components of the software component are generated. According to the functional intent, component code implementing the business logic is generated using a preset code template and domain-specific language conversion rules. According to interface constraints, interface specifications such as input parameters, return values, and exception handling mechanisms are defined. According to state constraints, state machines or conditional branching logic are designed to implement state transitions and maintenance. Finally, these three parts are combined to form a complete software component.

[0099] In the user authentication example, the generated component includes core functions for verifying credentials, interfaces for defining username and password inputs and token outputs, and state management code for tracking the number of failures and triggering a lock.

[0100] After a component is generated, forward semantic verification is performed to ensure that the component fully meets the original requirements. Forward verification consists of three dimensions: functional verification, interface verification, and state verification. Functional verification uses semantic similarity calculation to match the component logic with the functional intent, determining whether the component implements all the functional points described in the requirements. Specifically, a semantic feature vector is extracted for each functional point in the functional intent, and the corresponding semantic feature vector is extracted for the functional implementation in the component logic. The cosine similarity between the two is calculated. When the similarity is lower than a preset functional matching threshold, such as 0.85, the functional point is determined to be unimplemented. At the same time, the functional coverage rate is calculated, which is the ratio of the number of implemented functional points to the total number of functional points. When the coverage rate is lower than a preset coverage rate threshold, such as 0.95, the functional verification is marked as failed. Interface verification checks whether the parameter types, quantities, and names defined in the interface conform to the interface constraints. State verification tests whether the state management mechanism correctly implements all state transition rules defined in the state constraints. If any verification item is not satisfied, the forward verification is marked as failed.

[0101] Simultaneously, reverse semantic verification is performed to detect redundant elements in the component. Reverse verification also consists of three dimensions: extracting actual functional characteristics from the component logic and comparing them with the original functional intent to identify additional functions; extracting the parameter list from the interface definition and comparing it with interface constraints to find redundant parameters; and extracting state rules from the state management mechanism and comparing them with state constraints to detect redundant states. When any redundant item is found, the reverse verification is marked as failed.

[0102] When validation fails, the root cause of the problem is located by tracing back through the dependency graph. Forward validation failure indicates a missing function; in this case, trace upwards along the preceding dependencies to find the entity responsible for the incomplete functionality of the current component. For example, a payment processing component lacking transaction validation functionality might be due to a misunderstanding of its dependent security validation requirements. Reverse validation failure indicates redundancy; in this case, trace along triggering and constraint dependencies to find the related entity that introduced the redundancy. For example, a user management component containing unrequired permission validation functionality might be due to incorrectly inheriting constraints from permission management requirements.

[0103] Based on the location results, remediation suggestions are generated. For missing functionality, suggestions include adding specific functional modules, adjusting logic implementation, or re-parsering prerequisite dependencies; for redundant functionality, suggestions include removing unnecessary functions, separating concerns, or clarifying dependencies between requirements. Remediation suggestions utilize natural language generation technology to provide targeted guidance.

[0104] The software components are adjusted based on the repair recommendations, which may involve modifying component logic, redefining interfaces, or adjusting the state management mechanism. The adjusted components then re-enter the bidirectional semantic verification process until verification is successful, at which point the verified components are added to the final component set.

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

[0106] In one optional implementation, the steps of tracing back the preceding dependencies in the dependency graph to locate the root cause requirement entity with missing functionality when forward verification fails, and tracing back the associated requirement entities that introduce redundancy by locating the triggering and constraining dependencies when reverse verification fails, include:

[0107] 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;

[0108] 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;

[0109] 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.

[0110] 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.

[0111] For example, after a two-way semantic verification fails, the root cause of the problem is located by tracing back through the dependency graph and remediation suggestions are generated. When forward verification fails, it indicates that the component has a missing function, an incomplete interface, or an unimplemented state constraint, and it is necessary to trace the preceding dependencies to find the root cause requirement entity. When reverse verification fails, it indicates that the component contains redundant functions, extra interface parameters, or additional state rules, and it is necessary to trace the triggering dependencies and constraint dependencies to find the source of the redundancy.

[0112] When forward validation fails, extract the validation items marked as unmet and determine the corresponding semantic element type. Functional validation failure corresponds to a missing functional intent, interface validation failure corresponds to a missing interface constraint, and state validation failure corresponds to a missing state constraint. Locate the current requirement entity node in the dependency graph and backtrack along the preceding dependencies. Backtracking uses a breadth-first search strategy, prioritizing direct preceding dependencies and then expanding to indirect preceding dependencies, with a maximum backtracking depth of 3 to 5 levels.

[0113] For each preceding requirement entity on the backtracking path, corresponding semantic elements are extracted from the temporal semantic representation, including functional intent description, interface parameter types and return value types, state constraints, and transformation rules. The semantic elements of the preceding requirement entity are matched with the missing semantic elements of the current requirement entity. Semantic matching converts the two semantic elements into high-dimensional vectors and calculates the cosine similarity. The matching threshold is set between 0.7 and 0.85. When the matching score exceeds the threshold, the preceding requirement entity is marked as the root cause requirement entity, and the backtracking depth is recorded. If multiple successfully matched preceding requirement entities exist, the one with the highest matching score and the smallest backtracking depth is selected as the primary root cause.

[0114] Taking the order confirmation component as an example, forward validation revealed a missing inventory verification function. Tracing back from the order confirmation requirement entity, direct forward dependencies included the inventory management requirement entity and the payment processing requirement entity. The functional intent of the inventory management requirement entity was extracted, containing "check the quantity of goods in stock and return an availability status." Matching this semantic element with the missing inventory verification logic yielded a matching degree of 0.92, exceeding the threshold of 0.85. Therefore, the inventory management requirement entity was marked as the root cause, with a backtracking depth of 1 level.

[0115] When reverse verification fails, the detected redundancies are extracted, and the corresponding functional characteristics, interface parameters, or state rules are determined. In the dependency graph, the system traces forward from the current requirement entity along triggering and constraining dependencies. A depth-first search strategy is used, tracing deeply along a single dependency link until the source of redundancy is found or the path length limit is reached (set to 4 to 6 layers).

[0116] For each associated requirement entity along the tracing path, extract its semantic changes, including descriptions of new functions, modified interface definitions, and adjusted state constraints. Trace the semantic changes against redundant items, extracting the semantic feature vectors of the redundant items and calculating their similarity with the feature vectors of the semantic changes. When the similarity exceeds a tracing threshold of 0.75, the tracing is considered successful, the associated requirement entity is marked as the source of redundancy, and the tracing path length is recorded. If multiple associated requirement entities are successfully traced, the one with the shortest path length and the highest similarity is selected as the primary source of redundancy.

[0117] Taking the user management component as an example, reverse verification revealed the inclusion of an unrequired multi-factor authentication function. Tracing back along the dependency relationships from the user management requirement entity, it was found to be constrained by the state of the security policy requirement entity. Extracting the semantic changes in the latest version of the security policy requirement entity revealed a newly added state constraint of "forced multi-factor authentication". Matching this semantic change with the redundant function yielded a similarity of 0.88, exceeding the threshold of 0.75. Therefore, the security policy requirement entity was identified as the source of the redundancy, with a tracing path length of one level.

[0118] Based on the root cause requirement entity and backtracking depth identified through backtracking, repair suggestions for supplementing semantic elements are generated. These suggestions are generated using a template-based approach, selecting the appropriate template based on the type of missing element. When a functional intent is missing, it is recommended to extract business logic from the root cause requirement entity and integrate it into the current component; when an interface constraint is missing, it is recommended to supplement the interface parameter definition or return value specification; when a state constraint is missing, it is recommended to introduce state transition rules. Each repair suggestion includes the root cause requirement entity identifier, the content of the missing semantic element, the method of supplementation, and the backtracking depth. For backtracking depths of 1 to 2 levels, direct references or inheritance are used; for backtracking depths of 3 levels or more, redesigning the component logic or adjusting dependencies should be considered.

[0119] Based on the source of redundancy and the length of the tracing path, remediation suggestions for deleting redundant items are generated. The remediation suggestions select a deletion strategy based on the type of redundant item. When redundant functional characteristics originate from semantic changes, it is recommended to remove the functional module or separate it into an independent component; when redundant interface parameters originate from excessive constraints, it is recommended to delete redundant parameters or adjust the interface definition; when redundant state rules originate from error propagation, it is recommended to remove redundant states or correct the conversion logic. The remediation suggestions include the redundancy source identifier, redundant item description, deletion method, and tracing path length. If the tracing path length is short, the redundant item is deleted directly; if the path length is long, dependencies are reassessed or requirement boundaries are clarified.

[0120] This invention locates the root cause of functional defects by tracing back along preceding dependencies, and traces the source of redundant introduction along triggering and constraint dependencies. It generates targeted repair suggestions by combining backtracking depth and tracing path length, thereby achieving accurate root cause location and effective repair guidance for verification failures, and improving component quality and requirement consistency.

[0121] In one optional implementation, the step of establishing component interaction relationships in the component set according to the dependency relationship types in the dependency graph to obtain the software architecture includes:

[0122] 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;

[0123] 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.

[0124] 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.

[0125] For example, an interface definition typically includes elements such as method name, input parameter type, output parameter type, and exception handling mechanism. The state management mechanism includes the component's state set, state change events, state response rules, and state constraints. For instance, for a requirement entity in order management, the corresponding order management component can be retrieved from the component set. Its interface definition includes methods for creating an order and updating the order status, and its state management mechanism includes states such as "pending," "paid," "shipped," and "completed," along with corresponding state change events and response rules.

[0126] Based on different types of dependencies, corresponding interaction relationships are established. When the dependency type is a pre-dependency, the call interaction relationship is established by analyzing the input parameter types and output parameter types in the interface definition. Specifically, it checks whether the output parameter type of the first software component matches the input parameter type of the second software component. If they match, a call relationship is established, specifying the output of the first software component as the input of the second software component. In a pre-dependency, the first software component is the component that is depended upon, and the second software component is the component that depends on the first software component. For example, in an e-commerce platform, the payment processing component is the first software component, and its processing result can be used as the input parameter for the update order status method of the order management component (the second software component), thereby establishing a call interaction relationship from the payment processing component to the order management component.

[0127] When the dependency type is trigger dependency, an event interaction relationship is established based on the state change events and state response rules in the state management mechanism. The state change event generated by the first software component is identified, and then it is checked whether a corresponding state response rule exists in the second software component. If a matching event and response rule exist, an event interaction relationship is established, specifying that the state change of the first software component triggers the state response of the second software component. In a trigger dependency relationship, the first software component generates a state change, and the second software component responds to that state change. For example, the inventory management component (the first software component) can trigger the automatic replenishment response rule of the purchasing management component (the second software component) when its inventory level falls below a threshold, forming an event interaction relationship from the inventory management component to the purchasing management component.

[0128] When the dependency type is a constraint dependency, a constraint interaction relationship is established based on the state constraints in the state management mechanism. Specifically, this involves analyzing how the state constraints of the first software component restrict the execution conditions of the second software component, and then establishing a constraint interaction relationship between the two components. In a constraint dependency, the first software component provides state constraints, and the execution of the second software component is restricted by these constraints. For example, the user permission component, as the first software component, has user permission states that constrain the file read and write operations of the file operation component, i.e., the second software component. File operations can only be executed when the user has the corresponding permissions, thus forming a constraint interaction relationship from the user permission component to the file operation component.

[0129] The call interaction relationships, event interaction relationships, and constraint interaction relationships are organized into a hierarchical structure. The component hierarchy is determined based on the pre-dependencies in the dependency graph. Software components without pre-dependencies are classified as the base layer; these components do not depend on other components and typically provide basic services. Software components with pre-dependencies are classified into intermediate and application layers according to their dependency depth. Dependency depth is calculated by starting from the base layer components and proceeding along the forward path of the pre-dependencies. Components with a dependency depth of 1 are classified as intermediate layers, and components with a dependency depth of 2 or higher are classified as application layers. Intermediate layer components depend on base layer components, providing business logic and service composition; application layer components depend on intermediate or base layer components, implementing specific application functions. This hierarchical organization results in a clear software architecture, clarifying the dependencies and interaction methods between components, facilitating the understanding, maintenance, and expansion of the architecture.

[0130] For example, a web application might consist of a data access component as the base layer, a business logic component as the middle layer, and a user interface component as the application layer. The data access component provides data access interfaces without depending on other components, with a dependency depth of 0. The business logic component depends on the data access component, using its data services to implement business logic, with a dependency depth of 1. The user interface component depends on the business logic component, implementing user interaction functions by calling the business logic, with a dependency depth of 2. This hierarchical structure clearly expresses the dependencies and interactions between software components, resulting in a complete software architecture.

[0131] This invention establishes three types of interaction relationships based on dependency types and divides the structure into hierarchical structures according to dependency depth, ensuring the accuracy of the mapping between software architecture and requirement dependencies and generating an executable architecture that conforms to the actual dependency logic.

[0132] In one optional implementation, the steps of 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:

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] For example, after completing the software architecture construction, it is necessary to verify the temporal consistency of the architecture during the requirement evolution process and dynamically adjust the interaction relationships of components. Simultaneously, the verification results are fed back to optimize dependency inference rules. Requirement evolution events are extracted from the temporal directed graph structure represented by temporal semantics. Each requirement evolution event contains three core elements: the semantic change time point is recorded in the form of a version timestamp; the semantic change content includes the differences before and after changes in functional intent, interface constraints, or state constraints; and semantic relationships include functional call relationships, data flow relationships, and state constraint relationships. The extraction method traverses the evolution edges of the temporal directed graph. Evolution edges connect nodes of the same requirement entity in different versions. The timestamps marked on the edges are the semantic change time points, and the changes recorded on the edges are the semantic change content. Simultaneously, the semantic relationship types are obtained by extracting the associated edges between nodes.

[0138] In the software architecture, locate the software components affected by requirement evolution events. Retrieve the corresponding software components from the component set based on the requirement entity identifiers involved in the requirement evolution event. If the semantic change involves a change in functional intent, the affected components include the component corresponding to that requirement entity and all subsequent components in its dependency graph. If it involves a change in interface constraints, the affected components include all components with which it has a call interaction relationship. If it involves a change in state constraints, the affected components include all components with which it has an event interaction relationship or a constraint interaction relationship. Extract the call interaction relationships, event interaction relationships, and constraint interaction relationships between the affected components, and arrange them chronologically into an interaction sequence chain based on the logical order of the interactions and the dependency depth. The interaction occurrence time is determined by analyzing the execution sequence of the components: the occurrence time of a call interaction relationship is the time when the called component completes execution; the occurrence time of an event interaction relationship is the time when the triggering event occurs; and the occurrence time of a constraint interaction relationship is the time when constraint checks are performed.

[0139] The semantic change time points of demand evolution events are compared one by one with the interaction occurrence times in the interaction sequence chain to detect timing conflicts and interaction interruptions. Timing conflict detection traverses the interaction sequence chain, extracting the semantic elements dependent on each interaction relationship, and searching for the most recent change time point of that semantic element in the temporal semantic representation. When the semantic change time point is later than the interaction occurrence time, it is marked as a timing conflict, and the components involved, interaction types, and time difference are recorded. The time difference is calculated by subtracting the interaction occurrence time from the semantic change time point; a larger time difference indicates a more severe timing conflict. Interaction interruption detection analyzes the impact of semantic changes on data flow and control flow. When semantic changes lead to interface parameter type mismatches, missing required parameters, changes in return value types, interrupted state transition paths, or invalid constraints, it is marked as an interaction interruption. Data flow interruption detection compares the interface definitions before and after the change, checking the compatibility of the input parameter list and output parameter list. Changes in the number of parameters, incompatible types, or deletion of required parameters are all considered interruptions. The control flow interruption detection and analysis system analyzes changes in the state management mechanism and checks whether state transition rules and constraints prevent the original control path from being executed.

[0140] When a timing conflict is detected, the component hierarchy of the affected software components is adjusted based on the severity and scope of the conflict. The severity of the timing conflict is assessed using the time difference and the number of affected interactions. A time difference exceeding 30 days or the number of affected interactions exceeding 5 is considered high severity, requiring recalculation of the dependency depth of the affected components and adjustment of the component hierarchy. The dependency depth recalculation starts from the base layer components and traverses along the forward path of the preceding dependencies. The dependency depth of the components affected by the timing conflict is increased by 1 to ensure that the semantically changed dependencies are correctly reflected in the hierarchical structure.

[0141] When an interaction interruption is detected, the interface definitions or state management mechanisms of the affected software components are regenerated based on the semantic changes, and the component interaction relationships are updated. Interface definition regeneration extracts interface constraint changes from the semantic changes, including added parameters, deleted parameters, parameter type changes, and return value changes. The input parameter types, output parameter types, and exception handling mechanisms of the interface are redefined based on the changed interface constraints. Parameter adaptation strategies include providing default values ​​for newly added required parameters, marking deleted parameters as obsolete while maintaining compatibility, and adding type conversion logic for parameters with type changes. State management mechanism regeneration extracts state constraint changes from the semantic changes, and the state set, state change events, state response rules, and state constraint conditions are redesigned based on the changed state constraints. Component interaction relationship updates include modifying the interface mapping of call interaction relationships, adjusting the event subscription rules of event interaction relationships, and updating the constraint checking logic of constraint interaction relationships. Update operations employ a transaction mechanism to ensure consistency.

[0142] The inference error rate for dependency types corresponding to timing conflicts and interaction interruptions is calculated by dividing the number of conflicts or interruptions of a specific dependency type by the total number of dependencies of that type. The error rates for preceding dependencies, triggering dependencies, and constraining dependencies are calculated separately. An inference error rate threshold of 15% is set. When the inference error rate for a certain type of dependency exceeds this threshold, a dependency inference rule adjustment suggestion is generated. The adjustment suggestion includes the semantic relationship types that need to be strengthened and the semantic change timing conditions that need to be weakened. The semantic relationship types that need to be strengthened are determined based on the error distribution. If the preceding dependency error rate is high, the recognition weight of function call associations is strengthened, increasing the matching degree threshold from 0.7 to 0.8; if the triggering dependency error rate is high, the recognition of data flow associations and state constraint associations is strengthened; if the constraining dependency error rate is high, the extraction of constraint conditions for state constraint associations is strengthened. To address scenarios with frequent temporal conflicts, the sensitivity of semantic change judgment criteria needs to be weakened. A threshold for the magnitude of change is set, and changes are only marked as significant when the semantic similarity of the functional intent is below 0.9, the interface parameter change exceeds 20%, or the number of states changes by more than two. The dependency inference rules are updated by applying the proposed adjustments to the dependency inference process. This involves modifying the parameters of the semantic association recognition algorithm, adjusting the threshold configuration for semantic change detection, and optimizing the inference logic for dependency types. A new version of the dependency inference rules is then created, and the version number and the basis for the adjustments are recorded.

[0143] This invention uses demand evolution event-driven temporal consistency verification to dynamically adjust the software architecture and continuously optimize dependency inference rules, significantly improving the architecture's responsiveness to demand evolution and the accuracy of dependency inference.

[0144] A second aspect of this invention provides a system for automatic identification and transformation of software requirements based on semantic modeling, comprising:

[0145] 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.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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.

[0150] A third aspect of the present invention provides an electronic device, comprising:

[0151] processor;

[0152] Memory used to store processor-executable instructions;

[0153] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0154] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0155] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0156] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for automatic identification and transformation of software requirements based on semantic modeling, characterized in that, The method comprises the following steps: acquiring 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; inferred pre-dependence relationships, trigger dependence relationships or constraint dependence relationships between requirement entities based on the time sequence semantic representation, when there are contradictory dependencies between the same pair of requirement entities, distinguishing cross-version conflicts from same-version conflicts according to the versions of the dependencies, and performing a resolution operation of retaining the latest dependence or marking a circular dependence respectively, and constructing a dependence relationship graph; generating software components for each requirement entity in the dependence relationship graph and performing bidirectional semantic verification, locating the root cause by backtracking the dependence relationship graph when the verification fails, and generating repair suggestions to obtain a component set that passes the verification; establishing component interaction relationships in the component set according to the dependence relationship types in the dependence relationship graph to obtain a software architecture; verifying the time sequence consistency of the software architecture based on requirement evolution events and adjusting the component interaction relationships, and feeding back the verification results and repair suggestions to adjust the dependence inference rules; the step of inferring pre-dependence relationships, trigger dependence relationships or constraint dependence relationships between requirement entities based on the time sequence semantic representation, when there are contradictory dependencies between the same pair of requirement entities, distinguishing cross-version conflicts from same-version conflicts according to the versions of the dependencies, and performing a resolution operation of retaining the latest dependence or marking a circular dependence respectively, and constructing a dependence relationship graph comprises: extracting requirement entity pairs and semantic association relationships from the time sequence semantic representation, inferring dependence relationships according to the chronological relationship of the semantic change time points and the type of the semantic association relationships, inferring a pre-dependence relationship 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, 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 the state constraint of the first requirement entity restricts the functional intention of the second requirement entity; detecting opposite direction dependencies in the inferred dependence relationships, marking contradictory dependencies and recording the version identifiers of each dependence relationship when there are bidirectional dependencies between the first requirement entity and the second requirement entity; determining a cross-version conflict when the two dependence relationships in the contradictory dependencies are located in different versions and retaining the dependence relationship with a newer version timestamp, and determining a same-version conflict when the two dependence relationships in the contradictory dependencies are located in the same version and marking a circular dependence; organizing the resolved dependence relationships into a directed graph structure to obtain a dependence relationship graph.

2. The method of claim 1, wherein, The step of acquiring 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 traceability chain for each requirement entity in the multi-version requirement documents, the cross-version traceability chain recording the text description, associated requirement entity identifier and 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., functional intent, interface constraint and state constraint, marking a version timestamp as a semantic change time point when any semantic element of a same requirement entity changes between adjacent versions, 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 identification, the semantic association relationship including functional call association, data flow association and 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 time-sequential semantic representation.

3. The method of claim 1, wherein, generating software components for each requirement entity in the dependency relationship graph and performing bidirectional semantic verification, backtracking the dependency relationship graph to locate a root cause and generating a repair suggestion when verification fails, the step of obtaining a component set that passes verification including: extracting functional intent, interface constraint and state constraint for each requirement entity in the dependency relationship graph, generating component logic according to the functional intent, generating interface definition according to the interface constraint, and generating state management mechanism according to the state constraint, and combining the same into a software component; performing forward verification on the software component, matching the component logic with the functional intent, comparing the interface definition with the interface constraint, and checking the state management mechanism with the state constraint, and marking as forward verification failure when any of the above does not meet the requirement; performing reverse verification on the software component, extracting functional features in the component logic, interface parameters in the interface definition and state rules in the state management mechanism, and comparing the same with the functional intent, the interface constraint and the state constraint respectively to identify redundant functions, redundant interfaces and redundant constraints, and marking as reverse verification failure when a redundant item is detected; backtracking a preceding dependency relationship in the dependency relationship graph to locate a root cause requirement entity of functional absence when forward verification fails, and backtracking a trigger dependency relationship and a constraint dependency relationship to locate an associated requirement entity that introduces redundancy when reverse verification fails; generating a repair suggestion based on the locating result and adjusting the software component, and then re-performing bidirectional semantic verification, and adding the software component to a component set when the verification passes.

4. The method of claim 3, wherein the steps of backtracking a preceding dependency relationship in the dependency relationship graph to locate a root cause requirement entity of functional absence when forward verification fails, and backtracking a trigger dependency relationship and a constraint dependency relationship to locate an associated requirement entity that introduces redundancy when reverse verification fails including: when forward verification fails, extracting a semantic element type corresponding to a verification item marked as not meeting the requirement, and backtracking from a current requirement entity along a reverse path of the preceding dependency relationship in the dependency relationship graph; extracting a corresponding semantic element for each preceding requirement entity on the backtracking path, and performing semantic matching between the semantic element of the preceding requirement entity and the missing semantic element of the current requirement entity, and marking the preceding requirement entity as a root cause requirement entity when a matching degree exceeds a preset matching degree threshold, and calculating a backtracking depth; When the reverse verification fails, the functional characteristics, interface parameters or state rules corresponding to the detected redundancy are extracted, the current requirement entity is traced along the forward path of trigger dependency and constraint dependency in the dependency graph, the semantic change content of each associated requirement entity on the tracing path is extracted and the semantic provenance of the redundancy is traced, when the provenance is successful, the associated requirement entity is marked as a redundancy introduction source and the tracing path length is recorded; Based on the backtracking depth, a repair suggestion containing supplementary semantic elements is generated, and based on the tracing path length, a repair suggestion containing redundant item deletion is generated.

5. The method of claim 1, wherein, The step of establishing component interaction relationships in the component set according to the dependency relationship types in the dependency 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 state management mechanism of the software component are extracted; When the dependency relationship type is pre-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 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 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 pre-dependency relationship in the dependency 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.

6. The method of claim 1, wherein, The step of verifying the timing consistency of the software architecture based on the 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: Requirement evolution events are extracted from the timing 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 relationships are extracted and arranged in time sequence into interaction timing chains; The semantic change time points are compared with the interaction occurrence time in the interaction timing chain, when the semantic change time point is later than the interaction occurrence time depending on the semantics, it is marked as a timing conflict, and when the semantic change content causes data flow transfer or control flow transfer interruption, it is marked as an interaction interruption; When a timing 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.

7. A system for automatic recognition and transformation of software requirements based on semantic modeling for implementing the method according to any of the preceding claims 1-6, characterized in that, The method comprises the following steps: 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 in which the dependencies exist, and perform a keep-latest-dependency or a circular-dependency-marking operation respectively to 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 the time sequence consistency of the software architecture based on a requirement evolution event and adjust the component interaction relationships, and feed back the verification result and the repair suggestion to adjust the dependency inference rule.

8. An electronic device, comprising: The method comprises the following steps: A processor; A memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to execute the method in any one of claims 1 to 6.

9. A computer-readable storage medium having stored thereon computer program instructions, wherein, The computer program instructions are executed by the processor to implement the method in any one of claims 1 to 6.

Images