Structured processing method and device of software engineering elements, electronic equipment and medium

By generating an engineering element table and constructing an element reference chain, the problem of difficulty in uniformly analyzing different objects in software development is solved, enabling rapid location of affected elements and improving the efficiency of software development and version release.

CN121455449BActive Publication Date: 2026-05-05YUDONGYUAN (BEIJING) INFORMATION TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
YUDONGYUAN (BEIJING) INFORMATION TECH CO LTD
Filing Date
2026-01-07
Publication Date
2026-05-05

AI Technical Summary

Technical Problem

In the software development process, different software engineering objects are distributed across different tools and models, making it difficult to conduct horizontal analysis within a unified structure. This makes it difficult to generate change impact chains, reducing the efficiency of software development and version release.

Method used

Generate an engineering element table and construct an element reference chain. Identify the affected engineering elements through element identifiers and relationships, and generate a verification checklist for verification.

Benefits of technology

It enables rapid location of affected elements when engineering elements change, reduces the rate of omission in identification and the amount of manual work, and ensures consistent governance across domains and tools, as well as evidence-based tracking of delivery and acceptance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121455449B_ABST
    Figure CN121455449B_ABST
Patent Text Reader

Abstract

This application provides a structured processing method, apparatus, electronic device, and medium for software engineering elements, relating to the field of software development technology. The method includes: generating an engineering element table for multiple types of software engineering objects for a preset software engineering project; each engineering element in the table records an element identifier and basic attribute information of the engineering element in the software engineering object; constructing an element reference chain based on the relationships between multiple engineering elements and element identifiers; the element reference chain consisting of at least a source element identifier, a target element identifier, and a relationship type; responding to a change event for a first engineering element, determining the affected engineering element based on the element identifier and element reference chain of the first engineering element; and verifying the affected engineering element based on a verification list generated for the affected engineering element. This application can determine affected engineering elements based on unified engineering elements and element reference chains, improving the efficiency of software development and version release.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of software development technology, and more specifically, to a method, apparatus, electronic device, and medium for the structured processing of software engineering elements. Background Technology

[0002] In the software development process, different software engineering objects, such as requirements documents, use case documents, interface models, constraint rules, and test cases, are usually distributed in different tools and models. Even if they are interconnected or exchanged through Open Services for Lifecycle Collaboration (OSLC) or ReqIF, the underlying data structures are still separate, making it difficult to perform horizontal analysis in a unified structure.

[0003] Furthermore, it is difficult to automatically generate change impact chains in this situation. During the software development process, it is impossible to quickly locate other engineering elements that may be affected by the update of one engineering element, which reduces the efficiency of software development and version release. Summary of the Invention

[0004] The purpose of this application is to address the shortcomings of the prior art by providing a method, apparatus, electronic device, and medium for the structured processing of software engineering elements, so as to identify affected engineering elements based on unified engineering elements and element reference chains, thereby improving the efficiency of software development and version release.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0006] In a first aspect, embodiments of this application provide a method for structuring software engineering elements, the method comprising:

[0007] Generate engineering element tables for various types of software engineering objects for a preset software engineering project. Each item in the engineering element table records an element identifier and basic attribute information of the engineering elements in the software engineering object.

[0008] Based on the relationships between multiple engineering elements and the element identifiers of the multiple engineering elements, at least one element reference chain is constructed, wherein the element reference chain consists of at least a source element identifier, a target element identifier, and a relationship type;

[0009] In response to a change event for a first engineering element, the affected engineering element is determined based on the element identifier of the first engineering element and the element reference chain;

[0010] The affected engineering elements are verified based on the verification checklist generated for them.

[0011] Optionally, the feature reference chain further includes: a valid version range, wherein in response to a change event for the first engineering feature, determining the affected engineering feature based on the feature identifier of the first engineering feature and the feature reference chain includes:

[0012] In response to a change event for the first engineering element at a target version update point, a second engineering element in the first element reference chain corresponding to the first engineering element is determined based on the element identifier of the first engineering element.

[0013] Based on the current version of the first engineering element, the current version of the second engineering element, and the valid version range of the first element reference chain in the engineering element table, determine whether the first element reference chain is effective;

[0014] If the first element reference chain is effective, the second engineering element of the current version is determined to be the affected engineering element.

[0015] Optionally, if the current versions of the first engineering element and the second engineering element are not within the valid version range of the first element reference chain, the step of determining the affected engineering element based on the element identifier of the first engineering element and the element reference chain further includes:

[0016] Obtain the version change diagram of the preset software project. The multiple nodes of the version change diagram are multiple version update points of the preset software project. The connection relationship between the multiple nodes is the relationship between the multiple version update points. Each node records the version change of the project elements in the corresponding version update point.

[0017] Based on the version update point of the current version of the first engineering element and the version update point of the current version of the second engineering element, the version change diagram is used to determine whether the first engineering element and the second engineering element have historical versions within the effective version range.

[0018] If so, determine the second engineering element of the current version as the affected engineering element.

[0019] Optionally, determining the second engineering element of the current version as the affected engineering element includes:

[0020] Generate attribute extension tables for various types of software engineering objects for the preset software engineering. Each extension element in the attribute extension table records the extension attribute information of the corresponding engineering element. Each extension element is associated with each engineering element through an element identifier.

[0021] Determine the version change events of the second engineering element between the historical version and the current version from the extended attribute information of the second engineering element;

[0022] If the version change event is a non-destructive change event, the second engineering element of the current version is determined to be the affected engineering element.

[0023] Optionally, the method further includes:

[0024] Based on the propagation depth of the aforementioned relationship type, determine the multi-level engineering elements starting from the second engineering element;

[0025] Based on the current version of the second engineering element, the current version of the multi-level engineering element, and the valid version range of the corresponding second element reference chain, determine whether the second element reference chain is effective;

[0026] If the second element reference chain is effective, the corresponding level of the engineering element is determined to be the affected engineering element.

[0027] Optionally, the extended attribute information includes: importance information; before verifying the affected engineering elements based on the verification list generated for the affected engineering elements, the method further includes:

[0028] Based on the relationship type between the affected engineering element and other engineering elements, and the importance information, calculate the impact score of the affected engineering element;

[0029] Based on the impact score of the affected engineering elements, the regression verification method for the affected engineering elements is determined, and the verification list includes at least the regression verification method.

[0030] Optionally, before verifying the affected engineering elements based on the verification checklist generated for the affected engineering elements, the method further includes:

[0031] If the affected engineering element is an interface engineering element, and the interface engineering element has predefined machine-verifiable rules, a verification list for the interface engineering element is generated according to the machine-verifiable rules.

[0032] Secondly, embodiments of this application also provide a structured processing apparatus for software engineering elements, the apparatus comprising:

[0033] The element table generation module is used to generate engineering element tables for various types of software engineering objects for a preset software engineering project. Each item in the engineering element table records an element identifier and basic attribute information of the engineering elements in the software engineering object.

[0034] The reference chain generation module is used to construct at least one element reference chain based on the association between multiple engineering elements and the element identifiers of the multiple engineering elements. The element reference chain consists of at least a source element identifier, a target element identifier, and an association relationship type.

[0035] The engineering element determination module is used to determine the affected engineering element in response to a change event for a first engineering element, based on the element identifier of the first engineering element and the element reference chain.

[0036] The engineering element verification module is used to verify the affected engineering elements based on the verification list generated for the affected engineering elements.

[0037] Optionally, the element reference chain further includes: a valid version range. The engineering element determination module is specifically configured to, in response to a change event of the first engineering element at a target version update point, determine a second engineering element in the first element reference chain corresponding to the first engineering element based on the element identifier of the first engineering element; determine whether the first element reference chain is effective based on the current version of the first engineering element in the engineering element table, the current version of the second engineering element, and the valid version range of the first element reference chain; if the first element reference chain is effective, determine the second engineering element of the current version as the affected engineering element.

[0038] Optionally, if the current versions of the first engineering element and the second engineering element are not within the valid version range of the first element reference chain, the engineering element determination module is further configured to obtain a version change map of the preset software project, wherein multiple nodes of the version change map are multiple version update points of the preset software project, the connection relationship between the multiple nodes is the relationship between the multiple version update points, and each node records the version change of the engineering element in the corresponding version update point; based on the version update point of the current version of the first engineering element and the version update point of the current version of the second engineering element, the version change map is used to determine whether the first engineering element and the second engineering element have historical versions within the valid version range; if so, the second engineering element of the current version is determined to be the affected engineering element.

[0039] Optionally, the engineering element determination module is further configured to generate an attribute extension table for multiple types of software engineering objects for the preset software engineering, wherein each extension element in the attribute extension table records the extension attribute information of the corresponding engineering element, and each extension element is associated with each engineering element through an element identifier; determine the version change event of the second engineering element between the historical version and the current version from the extension attribute information of the second engineering element; if the version change event is a non-destructive change event, determine the second engineering element of the current version as the affected engineering element.

[0040] Optionally, the engineering element determination module is further configured to determine multi-level engineering elements starting from the second engineering element based on the propagation depth of the association type; determine whether the second element reference chain is effective based on the current version of the second engineering element, the current version of the multi-level engineering elements, and the effective version range of the corresponding second element reference chain; if the second element reference chain is effective, determine the corresponding level of engineering element as the affected engineering element.

[0041] Optionally, the extended attribute information includes importance information, and the device further includes:

[0042] The verification list generation module is used to calculate the impact score of the affected engineering element based on the relationship type between the affected engineering element and other engineering elements and the importance information;

[0043] Based on the impact score of the affected engineering elements, the regression verification method for the affected engineering elements is determined, and the verification list includes at least the regression verification method.

[0044] Optionally, the verification list generation module is further configured to generate a verification list for the interface engineering element according to the machine-verifiable rules if the affected engineering element is an interface engineering element and the interface engineering element has predefined machine-verifiable rules.

[0045] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium records program instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the program instructions to perform the steps of the structured processing method for software engineering elements as described in any of the first aspects.

[0046] Fourthly, embodiments of this application also provide a computer-readable storage medium on which a computer program is recorded, the computer program being executed by a processor to perform the steps of the structured processing method for software engineering elements as described in any of the first aspects.

[0047] The beneficial effects of this application are:

[0048] The structured processing method, apparatus, electronic device, and storage medium for software engineering elements provided in this application create unified engineering elements for engineering elements in different software engineering objects and generate element reference chains. This allows the affected engineering elements to be identified through the element reference chains when any engineering element changes, thereby verifying the affected engineering elements and preventing changes to any engineering element from affecting other engineering elements. This ensures that the impact of changes to engineering elements can be comprehensively investigated, reduces the omission rate and manual workload, and achieves consistent governance across domains and tools, as well as evidence-based tracking required for delivery and acceptance. Attached Figure Description

[0049] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 1 ;

[0051] Figure 2 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 2 ;

[0052] Figure 3 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 3 ;

[0053] Figure 4 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 4 ;

[0054] Figure 5 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 5 ;

[0055] Figure 6 A schematic diagram of the structure of the software engineering element structuring device provided in the embodiments of this application;

[0056] Figure 7 A schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of this application, but not all embodiments.

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

[0059] Furthermore, the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Additionally, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0060] It should be noted that, where there is no conflict, the features in the embodiments of this application can be combined with each other.

[0061] Figure 1 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 1 ,like Figure 1 As shown, the method may include:

[0062] S101. Generate engineering element tables for various types of software engineering objects for a preset software engineering project. Each record in the engineering element table contains an element identifier and basic attribute information of the engineering elements in the software engineering object.

[0063] In this embodiment, various types of software engineering objects are generated during the development process of the preset software engineering, such as requirement documents generated by requirement engineers, test plans generated by test engineers, and interface files generated by interface engineers. Each type of software engineering object contains at least one engineering element. For example, a requirement document contains multiple functional requirements, a test plan contains multiple test cases, and an interface file contains multiple interfaces.

[0064] Different engineering elements have their own IDs and models in their respective external tools, but because they are not in a unified system, they cannot be directly used for tracking and analysis. They need to be converted into our custom primary key system.

[0065] By breaking down various types of software engineering objects, the engineering elements contained in each type of software engineering object are determined. An engineering element is generated for each engineering element in a preset engineering element table. Each engineering element has a unique element identifier (element_id) and basic attribute information of the engineering element.

[0066] In some embodiments, basic attribute information may include the type of the engineering element, title, description, status, criticality, source_ref, version, owner, and creation time / update_at.

[0067] The types can include requirements, use cases, interfaces, test cases, and risks; the status can include draft, published, and obsolete, used to track the lifecycle stages of engineering elements, and the importance can determine the verification priority of engineering elements; the reference source is used to indicate the source of engineering elements, such as ReqIF items, URIs in OSLC, and path+methods in OpenAPI; the version number is used to manage the change history of engineering elements, and a new version should be generated for each major modification to the engineering element.

[0068] In some embodiments, a ReqIF adapter is used to import requirement items and their attributes and relationships from ReqIF XML, and to establish a mapping between element_id and reqif:item.

[0069] The OSLC adapter is used to batch retrieve the sets of requirements and resources through the OSLC RM / Query interface, generate the corresponding engineering elements, and retain the resource UPI as the reference source.

[0070] The OpenAPI adapter is used to map path+method+schema to project elements of type Interface.

[0071] For example, for objects from three external sources: (1) a requirement imported by a requirement management tool via ReqIF, with itemId REQ-7788; (2) a requirement resource exposed by an ALM platform via OSLC, with URI https: / / alm.example.com / oslc / rm / 12345; (3) an interface operation in an interface specification (OpenAPI 3.1), with path / orders and method GET. When the system accesses the system, corresponding engineering elements are created in the engineering element table for each of these three objects, with the following content:

[0072] Element#1: element_id = E-10001, type = Requirement, source_ref = REQ-7788;

[0073] Element#2: element_id = E-10002, type = Requirement, source_ref = https: / / alm.example.com / oslc / rm / 12345;

[0074] Element#3: element_id = E-10003, type = Interface, source_ref = / orders#GET.

[0075] Furthermore, for requirement documents, use case templates, etc. generated using natural language, document parsers or NLP parsers can be used to identify engineering elements in order to generate engineering elements.

[0076] S102. Based on the relationships between multiple engineering elements and the element identifiers of multiple engineering elements, construct at least one element reference chain. The element reference chain consists of at least the source element identifier, the target element identifier, and the relationship type.

[0077] In this embodiment, the element reference chain is used to describe the association between different engineering elements. This relationship is directed. Each element reference chain is a directed edge from the source engineering element to the target engineering element, represented by the element identifier from_id of the source engineering element and the element identifier to_id of the target engineering element. from_id and to_id are the element identifiers (element_id) of the source engineering element and the target engineering element, respectively.

[0078] Based on the relationships between source and target engineering elements, determine the relationship type rel_type of the element reference chain. The relationship type can include: satisfies, verifies, implements, depends_on, blocks, derivers, and covers. For example, requirement E1 is satisfied by use case E2, test E4 is used to verify whether interface E3 is correct, use case E2 is implemented through interface E3, function A depends on basic service B, and bug E5 blocks the completion of requirement E1, etc.

[0079] In some embodiments, a feature reference chain can be generated based on the relationships between engineering elements recorded in the software engineering object. For example, the inter-requirement references already established in OSLC / ReqIF and the interface-requirement relationships established through the interface management tool can be converted into a feature reference chain during access to maintain the external semantics.

[0080] In other embodiments, element reference chains can be established based on the identified engineering elements and preset configuration rules. For example, after identifying interface elements from the OpenAPI, satisfies / verifies edges for "requirement → interface" and "use case → interface" can be automatically established according to the configuration rules.

[0081] In other embodiments, manual linking can be used to establish element references, that is, the user manually establishes a relationship between two engineering elements in a unified structure layer, and the system also saves it as a link from_id→to_id.

[0082] The element reference chains generated in the above manner all end up in the same Link table, which facilitates subsequent multi-hop closure and impact analysis.

[0083] S103. In response to a change event for the first engineering element, determine the affected engineering element based on the element identifier and element reference chain of the first engineering element.

[0084] In this embodiment, the change event for an engineering element can be an addition event for adding an engineering element, a modification event for modifying an engineering element, or an abandonment event for discarding an engineering element.

[0085] Based on the change event for the first engineering element, the element identifier of the first engineering element is determined through the engineering element table. Based on the element identifier of the first engineering element, a target element reference chain containing the element identifier of the first engineering element is determined from at least one element reference chain. From the target element reference chain, another engineering element corresponding to the element identifier is determined as the affected engineering element.

[0086] For example, if the feature identifier of the first engineering element is the source feature identifier in the target feature reference chain, then the engineering element corresponding to the target feature identifier in the target feature reference chain is determined to be the affected engineering element.

[0087] If the element identifier of the first engineering element is the target element identifier in the target element reference chain, then the engineering element corresponding to the source element identifier in the target element reference chain is determined to be the affected engineering element.

[0088] In some embodiments, a change to a first engineering element may affect its upstream engineering elements or its downstream engineering elements. Based on the type of association in the target element reference chain, it is determined whether the first engineering element affects the upstream or downstream engineering elements. Based on the position of the element identifier of the first engineering element in the target element reference chain, it is determined whether the engineering element corresponding to another element identifier in the target element reference chain is an affected engineering element.

[0089] For example, under a certain relationship, the first engineering element will only affect its downstream engineering elements, but will not affect its upstream engineering elements. However, in the target element reference chain, the element identifier of the first engineering element is to_id. Therefore, the engineering element corresponding to from_id is not the affected engineering element.

[0090] S104. Verify the affected engineering elements based on the verification checklist generated for the affected engineering elements.

[0091] In this embodiment, after determining the affected engineering elements, it is necessary to verify the affected engineering elements. The verification content of the affected engineering elements can be determined based on the changes of the first engineering element, so as to generate a verification list for the affected engineering elements.

[0092] Based on the verification list of affected engineering elements, the affected engineering elements are verified. Based on the verification results, it is determined whether the change event of the first engineering element can be published. If the verification result indicates that the verification is successful, the changed first engineering element can be published.

[0093] The structured processing method for software engineering elements provided in the above embodiments creates unified engineering elements for engineering elements in different software engineering objects and generates element reference chains. This allows the affected engineering elements to be identified through the element reference chains when any engineering element changes, thereby verifying the affected engineering elements and avoiding the impact of changes to any engineering element on other engineering elements. This ensures that the impact of changes to engineering elements can be comprehensively investigated, reduces the omission rate and manual workload, and achieves consistent governance across domains and tools, as well as evidence-based tracking required for delivery and acceptance.

[0094] In one possible implementation, the element reference chain may also include: a valid version range, Figure 2 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 2 ,like Figure 2 As shown, the process of determining the affected engineering element based on the element identifier and element reference chain of the first engineering element in response to a change event for the first engineering element S103 may include:

[0095] S201. In response to a change event for the first engineering element at a target version update point, determine the second engineering element in the first element reference chain corresponding to the first engineering element based on the element identifier of the first engineering element.

[0096] In this embodiment, during software development, multiple version update points are generated to improve development efficiency and avoid affecting the use of the current version. The development content of each version update point is different. For example, the software is developed into version main1.0 at the main version update point (main). All engineering elements in this main line are at version 1.0, such as R_101@1.0, I_301@1.0, and T_401@1.0. Then, in order to develop a new function, a branch version update point is generated on the main version update point (main). The branch version is release / 1.1. On this branch, I_301 is modified for the new function, and the version of I_301 on this branch evolves to I_301@1.1. In addition, in order to fix a bug in the main line, T_401 is modified. The main version update point is updated to main1.1, and the version of T_401 in main1.1 evolves to T_401@1.1.

[0097] When an engineer makes a change to the first engineering element at the target version update point, the element identifier of the first engineering element is determined through the engineering element table. Based on the element identifier of the first engineering element, a first element reference chain containing the element identifier of the first engineering element is determined from at least one element reference chain. The engineering element corresponding to another element identifier is determined as the second engineering element from the first element reference chain.

[0098] S202. Determine whether the first element reference chain is effective based on the current version of the first engineering element in the engineering element table, the current version of the second engineering element, and the valid version range of the first element reference chain.

[0099] In this embodiment, the element reference chain includes a valid version range, meaning that the association is only effective within the valid version range. If the current version of the engineering element is not within the valid version range, the reference relationship will not be effective for the current version of the engineering element, and it is necessary to redetermine the version that can be effective.

[0100] Specifically, the engineering element table records the version information for each engineering element. This version information represents the current version, or latest version, of the corresponding engineering element. In response to a change event affecting the first engineering element, the version of the changed first engineering element becomes the current version. It should be noted that for a discarded first engineering element, no new version is generated after discarding; the discarded version becomes the current version.

[0101] After determining the current version of the first engineering element and the current version of the second engineering element through the engineering element table, it is determined whether both versions are within the valid version range of the first element reference chain, so as to determine whether the influence relationship of the first element reference chain still applies to the first engineering element and the second engineering element.

[0102] In some embodiments, the effective version range can be a range, and the current version of the first engineering element and the current version of the second engineering element are both determined using this range.

[0103] In other embodiments, the effective version range is divided into an effective version range for the source element identifier and an effective version range for the target element identifier, and the current version of the first engineering element and the current version of the second engineering element are determined using their respective ranges.

[0104] Furthermore, the effective version range can change as engineering elements are updated, and the engineer declares the effective version range of the updated version when updating the engineering elements.

[0105] S203. If the first element reference chain is effective, determine the second engineering element of the current version as the affected engineering element.

[0106] In this embodiment, if the current version of the first engineering element and the current version of the second engineering element are both within the valid version range of the first element reference chain, it is determined that the influence relationship of the first element reference chain still applies to the first engineering element and the second engineering element, and it can be determined that the current version of the second engineering element is the affected engineering element.

[0107] The structured processing method for software engineering elements provided in the above embodiments determines whether the reference relationship is still valid for the current version of the engineering element based on the current version of the engineering element and the effective version range of the element reference chain. This allows for the identification of the actually affected engineering elements for verification, avoiding the verification of irrelevant versions of the engineering elements and reducing the verification workload.

[0108] In one possible implementation, if the current version of the first engineering element and the current version of the second engineering element are not within the valid version range of the first element's reference chain, it does not mean that changes to the first engineering element will not affect other versions of the second engineering element. This is because there may be situations where the valid version range has not been updated, or where the relationship between some functions is overlooked by engineers during the unit update process. In order to avoid software anomalies or even crashes caused by directly releasing the changed first engineering element due to omissions, it is necessary to find cases where the first engineering element and the second engineering element were related in historical versions, so as to remind users that these two engineering elements were once related, but now this relationship no longer exists. It is best to verify the potentially affected unit.

[0109] Figure 3 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 3 ,like Figure 3 As shown, the process of determining the affected engineering elements based on the element identifier and element reference chain of the first engineering element in S103 may include:

[0110] S301. Obtain the version change diagram of the preset software project. The multiple nodes of the version change diagram are the multiple version update points of the preset software project. The connection relationship between the multiple nodes is the relationship between the multiple version update points. Each node records the version change of the project elements in the corresponding version update point.

[0111] In this embodiment, the version change diagram of the preset software project records the relationship between multiple version update points of the preset software project and the version changes of the project elements at each version update point.

[0112] The relationship between multiple version update points is the relationship between software program version changes. For example, the initial version of the main version update point is main1.0. On main1.0, main2.0 is developed as a version update point. A branch version update point is generated from the main line to develop release / 1.1.

[0113] Once a branch is developed, it will be merged with the main line, causing changes to the project elements on the main line. Therefore, changes to project elements can also be caused by the merging of the branch and the main line.

[0114] Each node records the version information of the engineering elements that have changed at that version development point. For example, the mainline version development point changes from main1.0 to main2.0 and then to main3.0. The versions of requirement unit E1 are E1@1.0, E1@2.0 and E1@3.0 respectively. At the mainline version development point main2.0, a branch fix is ​​generated. The versions of interface unit E3 are E3@1.0 and E3@1.1-fix respectively.

[0115] S302. Based on the version update point of the current version of the first engineering element and the version update point of the current version of the second engineering element, determine whether the first engineering element and the second engineering element have historical versions within the effective version range through the version change diagram.

[0116] In this embodiment, when the current versions of the first engineering element and the second engineering element are not within the valid version range of the first element reference chain, it is necessary to determine from the version change diagram whether there are cases where the historical versions of both the first and second engineering elements are within the valid version range during the historical update process. If so, it means that the association of the first element reference chain is valid under the historical versions of the first and second engineering elements. If not, it means that the association of the first element reference chain has never been effective for the first and second engineering elements, i.e., the reference relationship written in the original software engineering object may be incorrect. An association relationship error message is generated for the engineer to check the association relationship.

[0117] S303. If so, determine the second engineering element of the current version as the affected engineering element.

[0118] In this embodiment, if both historical versions are within the valid version range, it is determined that the first engineering element of the current version is invalid for the second engineering element of the current version. A verification list is generated to verify whether a new first engineering element needs to be provided for the second engineering element of the current version, or whether the association between the first engineering element and the second engineering element needs to be broken.

[0119] In some embodiments, the verification checklist needs to declare that there is a relationship between the historical versions of the first engineering element and the historical versions of the second engineering element.

[0120] The structured processing method for software engineering elements provided in the above embodiments searches for the version evolution of engineering elements based on the version change map, so as to ensure that all potentially affected engineering elements can be identified and reduce the identification omission rate.

[0121] In one possible implementation, Figure 4 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 4 ,like Figure 4 As shown, the process of determining the second engineering element of the current version as the affected engineering element in S303 above may include:

[0122] S401. Generate attribute extension tables for various types of software engineering objects for preset software engineering. Each extension element in the attribute extension table records the extension attribute information of the corresponding engineering element. Each extension element is associated with each engineering element through an element identifier.

[0123] In this embodiment, for each engineering element, at least one extended attribute information of each engineering element is recorded through an attribute extension table. Each extended element records one extended attribute information. The extended elements and engineering elements are associated through element identifiers. Each extended element may include: element_id, attribute key (attr_key), attribute value (attr_value), and attribute type (attr_type).

[0124] Since different types of software engineering objects focus on different details in business, the attribute extension table can be used to record the exclusive extended attribute information of each engineering element, while the engineering element table records the basic attribute information common to engineering elements.

[0125] For example, requirement-related engineering elements can include fields such as obiz_scope (business scope / applicable scope), priority (priority, for easy alignment with the original requirement system), oacceptance_criteria (acceptance criteria, which can be directly used when generating verification checklists later), oprecondition (preconditions), and source_doc (original source or chapter number). Test-related engineering elements can include fields such as otest_steps (test steps, text or structured list), oexpected_result (expected result), otest_level (classification such as smoke / regression / interface automation), obind_interface (related interface element ID, used to reverse lookup the test for change impact), and auto_flag (whether it can be automated). Interface-related engineering elements can include fields such as ooperation_id (operation identifier mapped from OpenAPI), oreq_schema_summary, etc. Fields such as resp_schema_summary (request / response structure summary) and breaking_change (whether it is a potentially destructive change) can be used for risk-related engineering elements. Fields such as orisk_level (risk level), omitigation (mitigation measures), and related_req (related requirement element ID) can be used for these fields.

[0126] S402. Determine the version change events of the second engineering element from the historical version to the current version from the extended attribute information of the second engineering element.

[0127] In this embodiment, the version change event is used to indicate whether a destructive change event has occurred in the engineering element. A destructive change event is used to indicate that the actual content of the engineering element has been changed, which may include the deletion of interface parameters, adjustment of return value structure, change of exception type, etc. Non-destructive change events may include performance optimization, log enhancement, comment modification, variable renaming, etc.

[0128] Determine whether a disruptive change event has occurred between the previous and current versions of the second engineering element. If no disruptive change event has occurred, it means that the influence between the second engineering element and the first engineering element can still propagate. If a disruptive change event has occurred, the influence of the change to the first engineering element cannot be propagated even if the reference chain is still valid.

[0129] S403. If the version change event is a non-destructive change event, determine the second engineering element of the current version as the affected engineering element.

[0130] In this embodiment, if the version change event is determined to be a non-destructive change event, meaning that the influence between it and the first engineering element can still continue to propagate, then the second engineering element of the current version is determined to be the affected engineering element.

[0131] The structured processing method for software engineering elements provided in the above embodiments determines whether the association relationship still holds based on the version change event of the smallest engineering unit, thereby identifying the affected engineering elements. When there are no changes in the code or configuration that affect external behavior, the ability to pass the reference chain is still preserved, avoiding interruption of propagation due to simple version number changes.

[0132] In one possible implementation, Figure 5 A flowchart illustrating the structured processing method for software engineering elements provided in this application embodiment. Figure 5 ,like Figure 5 As shown, the method may further include:

[0133] S501. Based on the propagation depth of the association type, determine the multi-level engineering elements starting from the second engineering element.

[0134] S502. Determine whether the second element reference chain is effective based on the current version of the second engineering element, the current version of the multi-level engineering element, and the effective version range of the corresponding second element reference chain.

[0135] S503. If the second element reference chain is effective, determine the corresponding level of engineering element as the affected engineering element.

[0136] In this embodiment, after completing the analysis of the first element reference chain, a multi-level influence propagation analysis can be initiated based on the propagation depth corresponding to the association relationship type of the first element reference chain.

[0137] For example, the verifies type requires completing the downlink closure, that is, analyzing all the way up to the test project elements along the "interface-test" path.

[0138] The second element reference chain is determined based on the element identifier corresponding to the second engineering element. The third engineering element is determined based on the second element reference chain. Propagation is carried out according to the propagation depth. For example, the fourth engineering element is determined based on the second element reference chain of the third engineering element. The method is the same as the method of determining the second engineering element in S201 above, and will not be repeated here.

[0139] After determining the multi-level engineering elements, the same method as S202-S203 above is used to determine whether the multi-level engineering elements are affected engineering elements, which will not be elaborated here.

[0140] The structured processing method for software engineering elements provided in the above embodiments uses the propagation depth mechanism of association type to perform multi-level impact propagation analysis, which can improve the coverage of impact analysis and avoid the impact explosion problem caused by infinite expansion, thus realizing controllable hierarchical propagation analysis of change impact.

[0141] In one possible implementation, the extended attribute information may include: importance information. Prior to verifying the affected engineering elements based on the verification list generated for the affected engineering elements in S104 above, the method may further include:

[0142] Based on the relationship type and importance information between the affected engineering elements and other engineering elements, calculate the impact score of the affected engineering elements; based on the impact score of the affected engineering elements, determine the regression verification method of the affected engineering elements, and the verification list shall include at least the regression verification method.

[0143] In this embodiment, other engineering elements are engineering elements that correspond to the same reference chain as the affected engineering element when the affected engineering element is determined. For example, if the affected engineering element is the second engineering element, then the other engineering elements are the first engineering elements; if the affected engineering element is the third engineering element, then the other engineering elements are the second engineering elements.

[0144] Based on the relationship type between the affected engineering element and other engineering elements, the influence weight between the affected engineering element and other engineering elements is determined. Based on the importance information and influence weight of the affected engineering element recorded in the extended attribute information, the influence score of the affected engineering element is calculated.

[0145] In some embodiments, the impact score of the affected engineering element can be calculated based on the distance between the current version and a determined historical version of the affected engineering element, the type of association, and the importance information.

[0146] Based on the correspondence between the impact score and various regression verification methods, the regression verification method for the affected engineering elements is determined. The regression verification method can be mandatory regression, recommended regression, or only recording. Among them, mandatory regression requires preventing publication if the verification fails, recommended regression allows publication if the verification fails, and only recording the risk is required. Only recording does not require verification.

[0147] In some embodiments, the steps to be performed for regression or recommended regression can be determined from the extended attribute table.

[0148] The structured processing method for software engineering elements provided in the above embodiments determines the regression verification method of affected engineering elements based on the impact score of affected engineering elements, realizes differentiated configuration of engineering elements, avoids over-testing of low-risk units while ensuring the stability of key business, and improves software development efficiency.

[0149] In one possible implementation, before verifying the affected engineering elements according to the verification list generated for the affected engineering elements in the above-described S104, the method may further include:

[0150] If the affected engineering element is an interface engineering element, and the interface engineering element has predefined machine-verifiable rules, a verification list for the interface engineering element is generated based on the machine-verifiable rules.

[0151] In this embodiment, when it is determined that an interface engineering element becomes an affected engineering element due to an upstream change, a rule matching process is triggered to detect whether the interface engineering element has machine-verifiable rules, i.e., interface contract assertions. Test cases are generated based on machine-verifiable rules and written into the verification list to verify the interface engineering element.

[0152] The structured processing method for software engineering elements provided in the above embodiments transforms interface contract rules into executable verification instructions, realizing a closed-loop governance mechanism of "verification upon change" after interface changes. Standardized quality checks can be completed without manual intervention, significantly reducing the risk of joint debugging failures and online faults caused by interface incompatibility, and improving the system's autonomy and delivery security.

[0153] In one possible implementation, in addition to identifying the affected engineering elements when a change event occurs, a replay impact analysis can also be performed based on the engineering element table, extended attribute table, element reference chain, and version change graph. By querying the version information of an engineering element to be replayed in the manner described above for identifying the affected engineering elements, the affected engineering elements of the engineering element to be replayed can also be identified for auditing and review.

[0154] Based on the above method embodiments, this application also provides a structured processing apparatus for software engineering elements. Figure 6 A schematic diagram of the structure of the software engineering element structure processing device provided in the embodiments of this application is shown below. Figure 6 As shown, the device may include:

[0155] The element table generation module 601 is used to generate engineering element tables for various types of software engineering objects for a preset software engineering project. Each engineering element in the engineering element table records the element identifier and the basic attribute information of the engineering elements in the software engineering object.

[0156] The reference chain generation module 602 is used to construct at least one element reference chain based on the relationship between multiple engineering elements and the element identifiers of multiple engineering elements. The element reference chain consists of at least a source element identifier, a target element identifier, and a relationship type.

[0157] The engineering element determination module 603 is used to determine the affected engineering elements in response to a change event for the first engineering element, based on the element identifier and element reference chain of the first engineering element.

[0158] The engineering element verification module 604 is used to verify the affected engineering elements based on the verification list generated for the affected engineering elements.

[0159] Optionally, the element reference chain further includes: a valid version range, and an engineering element determination module 603, specifically used to respond to a change event for the first engineering element at a target version update point, determine the second engineering element in the first element reference chain corresponding to the first engineering element based on the element identifier of the first engineering element; determine whether the first element reference chain is effective based on the current version of the first engineering element in the engineering element table, the current version of the second engineering element, and the valid version range of the first element reference chain; if the first element reference chain is effective, determine that the second engineering element of the current version is the affected engineering element.

[0160] Optionally, if the current versions of the first engineering element and the second engineering element are not within the valid version range of the first element reference chain, the engineering element determination module 603 is further used to obtain a version change map of a preset software engineering project. The multiple nodes of the version change map are multiple version update points of the preset software engineering project, and the connection relationship between the multiple nodes is the relationship between the multiple version update points. Each node records the version change of the engineering element in the corresponding version update point. Based on the version update point of the current version of the first engineering element and the version update point of the current version of the second engineering element, the version change map is used to determine whether the first engineering element and the second engineering element have historical versions within the valid version range. If so, the current version of the second engineering element is determined to be the affected engineering element.

[0161] Optionally, the engineering element determination module 603 is also used to generate an attribute extension table for various types of software engineering objects for a preset software engineering project. Each extension element in the attribute extension table records the extension attribute information of the corresponding engineering element, and each extension element is associated with each engineering element through an element identifier. The version change event of the second engineering element between the historical version and the current version is determined from the extension attribute information of the second engineering element. If the version change event is a non-destructive change event, the second engineering element of the current version is determined to be the affected engineering element.

[0162] Optionally, the engineering element determination module 603 is also used to determine the multi-level engineering elements starting from the second engineering element based on the propagation depth of the association relationship type; determine whether the second element reference chain is effective based on the current version of the second engineering element, the current version of the multi-level engineering elements, and the effective version range of the corresponding second element reference chain; if the second element reference chain is effective, determine the engineering elements at the corresponding level as the affected engineering elements.

[0163] Optionally, the extended attribute information includes: importance information, and the device may further include:

[0164] The verification list generation module is used to calculate the impact score of the affected engineering elements based on the relationship type and importance information between the affected engineering elements and other engineering elements.

[0165] Based on the impact scores of the affected engineering elements, determine the regression verification method for the affected engineering elements. The verification list should include at least the regression verification method.

[0166] Optionally, the verification list generation module is also used to generate a verification list for the interface engineering element based on the machine-verifiable rules if the affected engineering element is an interface engineering element and the interface engineering element has predefined machine-verifiable rules.

[0167] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.

[0168] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0169] Figure 7 A schematic diagram of the electronic device provided in the embodiments of this application, such as... Figure 7 As shown, the electronic device 700 may include a processor 701, a storage medium 702, and a bus. The storage medium 702 records program instructions executable by the processor 701. When the electronic device 700 is running, the processor 701 communicates with the storage medium 702 via the bus, and the processor 701 executes the program instructions to perform the above-described method embodiment. The specific implementation and technical effects are similar and will not be described in detail here.

[0170] Optionally, this application also provides a computer-readable storage medium on which a computer program is recorded, and the computer program is executed by a processor to perform the above-described method embodiments.

[0171] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0172] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0173] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0174] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0175] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for structuring software engineering elements, characterized in that, The method includes: Generate an engineering element table for multiple types of software engineering objects for a preset software engineering project. Each item in the engineering element table records an element identifier and basic attribute information of the engineering elements in the software engineering object. The engineering elements of the multiple types of software engineering objects include at least some or all of the functional requirements, use cases, interfaces, and test cases. Based on the relationships between multiple engineering elements and the element identifiers of the multiple engineering elements, at least one element reference chain is constructed, wherein the element reference chain consists of at least a source element identifier, a target element identifier, and a relationship type; In response to a change event for a first engineering element, the affected engineering element is determined based on the element identifier of the first engineering element and the element reference chain; The affected engineering elements are verified based on the verification checklist generated for them. The element reference chain further includes: a valid version range, wherein in response to a change event for the first engineering element, determining the affected engineering element based on the element identifier of the first engineering element and the element reference chain includes: In response to a change event for the first engineering element at a target version update point, a second engineering element in the first element reference chain corresponding to the first engineering element is determined based on the element identifier of the first engineering element. Based on the current version of the first engineering element, the current version of the second engineering element, and the valid version range of the first element reference chain in the engineering element table, determine whether the first element reference chain is effective; If the first element reference chain is effective, the second engineering element of the current version is determined to be the affected engineering element; If the current versions of the first engineering element and the second engineering element are not within the valid version range of the first element reference chain, the step of determining the affected engineering element based on the element identifier of the first engineering element and the element reference chain further includes: Obtain the version change diagram of the preset software project. The multiple nodes of the version change diagram are multiple version update points of the preset software project. The connection relationship between the multiple nodes is the relationship between the multiple version update points. Each node records the version change of the project elements in the corresponding version update point. Based on the version update point of the current version of the first engineering element and the version update point of the current version of the second engineering element, the version change diagram is used to determine whether the first engineering element and the second engineering element have historical versions within the effective version range. If so, determine the second engineering element of the current version as the affected engineering element.

2. The method as described in claim 1, characterized in that, The step of determining the second engineering element of the current version as the affected engineering element includes: Generate attribute extension tables for various types of software engineering objects for the preset software engineering. Each extension element in the attribute extension table records the extension attribute information of the corresponding engineering element. Each extension element is associated with each engineering element through an element identifier. Determine the version change events of the second engineering element between the historical version and the current version from the extended attribute information of the second engineering element; If the version change event is a non-destructive change event, the second engineering element of the current version is determined to be the affected engineering element.

3. The method as described in claim 1, characterized in that, The method further includes: Based on the propagation depth of the aforementioned relationship type, determine the multi-level engineering elements starting from the second engineering element; Based on the current version of the second engineering element, the current version of the multi-level engineering element, and the valid version range of the corresponding second element reference chain, determine whether the second element reference chain is effective; If the second element reference chain is effective, the corresponding level of the engineering element is determined to be the affected engineering element.

4. The method as described in claim 2, characterized in that, The extended attribute information includes importance information. Before verifying the affected engineering elements based on the verification list generated for the affected engineering elements, the method further includes: Based on the relationship type between the affected engineering element and other engineering elements, and the importance information, calculate the impact score of the affected engineering element; Based on the impact score of the affected engineering elements, the regression verification method for the affected engineering elements is determined, and the verification list includes at least the regression verification method.

5. The method as described in claim 1, characterized in that, Before verifying the affected engineering elements based on the verification checklist generated for the affected engineering elements, the method further includes: If the affected engineering element is an interface engineering element, and the interface engineering element has predefined machine-verifiable rules, a verification list for the interface engineering element is generated according to the machine-verifiable rules.

6. A structured processing device for software engineering elements, characterized in that, The device includes: The element table generation module is used to generate an engineering element table for multiple types of software engineering objects for a preset software engineering project. Each item in the engineering element table records an element identifier and basic attribute information of the engineering elements in the software engineering object. The engineering elements of the multiple types of software engineering objects include at least some or all of the functional requirements, use cases, interfaces, and test cases. The reference chain generation module is used to construct at least one element reference chain based on the association between multiple engineering elements and the element identifiers of the multiple engineering elements. The element reference chain consists of at least a source element identifier, a target element identifier, and an association relationship type. The engineering element determination module is used to determine the affected engineering element in response to a change event for a first engineering element, based on the element identifier of the first engineering element and the element reference chain. The engineering element verification module is used to verify the affected engineering elements according to the verification list generated for the affected engineering elements; The element reference chain further includes: a valid version range. The engineering element determination module is specifically used to respond to a change event of the first engineering element at a target version update point, determine the second engineering element in the first element reference chain corresponding to the first engineering element based on the element identifier of the first engineering element; determine whether the first element reference chain is effective based on the current version of the first engineering element in the engineering element table, the current version of the second engineering element, and the valid version range of the first element reference chain; if the first element reference chain is effective, determine the second engineering element of the current version as the affected engineering element. If the current versions of the first engineering element and the second engineering element are not within the valid version range of the first element reference chain, the engineering element determination module is further configured to obtain a version change diagram of the preset software project, wherein multiple nodes of the version change diagram are multiple version update points of the preset software project, the connection relationship between the multiple nodes is the relationship between the multiple version update points, and each node records the version change of the engineering element in the corresponding version update point; based on the version update point of the current version of the first engineering element and the version update point of the current version of the second engineering element, the module determines whether the first engineering element and the second engineering element have historical versions within the valid version range through the version change diagram; if so, the module determines the second engineering element of the current version as the affected engineering element.

7. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium records program instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the program instructions to perform the steps of the structured processing method for software engineering elements as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The storage medium contains a computer program that, when executed by a processor, performs the steps of the structured processing method for software engineering elements as described in any one of claims 1 to 5.

Citation Information

Patent Citations

  • Method and system for analyzing association relation of element files in software system

    CN104765787A

  • Source code change analysis method, system and equipment

    CN119597657A