Method for determining influence range of function change of service system and related device

Abstract

The invention discloses a method for determining the influence range of function change of a business system and a related device, and relates to the field of computers.The method comprises the steps that firstly, influence analysis assets of the business system are constructed, and then the direct influence range of a change item is determined based on the change item of the business system; and determining the association influence range of the change item through the external interface associated with the change item, and finally determining the global influence range of the change item. According to the embodiment, the multi-dimensional analysis assets which are mutually associated through the external interfaces provide a comprehensive analysis basis for influence analysis, on the basis, the influence range of changes is analyzed from four dimensions of codes, data, interfaces and businesses, a global influence analysis task caused by changes of the codes, the library tables, the interfaces or the businesses is achieved, and the overall influence analysis efficiency is improved. And the comprehensiveness and accuracy of influence analysis are ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and related apparatus for determining the scope of impact of changes to the functions of a business system. Background Technology

[0002] Functional changes are an unavoidable part of business system development and maintenance. To ensure the normal operation of business systems, impact analysis is often required when making functional changes to determine the scope of the impact.

[0003] For example, when developers are tasked with analyzing the impact of code changes in a business system, they can use the Java (an object-oriented programming language) abstract syntax tree to determine the code call relationships and analyze the scope of the impact of the code changes. However, due to the limitations of the developers' perspective, the determined scope of impact is relatively limited. Summary of the Invention

[0004] In view of the above problems, this application provides a method and related apparatus for determining the impact scope of changes to business system functions, so as to improve the quality of impact analysis. The specific solution is as follows:

[0005] The first aspect of this application provides a method for determining the scope of impact of changes to the functionality of a business system, including:

[0006] Construct impact analysis assets for the business system, which include code-layer analysis assets, data-layer analysis assets, interface-layer analysis assets, and business-layer analysis assets that are interconnected through external interfaces;

[0007] Based on the changes to the business system, the direct impact scope of the changes to the business system is determined from the target layer analysis assets; the target layer analysis assets are the layer analysis assets in the impact analysis assets that directly correspond to the changes to the business system, and the changes include software function changes and business function changes;

[0008] External interfaces affected by changes to the business system are designated as target external interfaces, and the scope of the associated impact of the changes to the business system is determined from non-target layer analysis assets based on the target external interfaces; the non-target layer analysis assets include analysis assets at each layer that do not directly correspond to the changes to the business system in the impact analysis assets.

[0009] The global impact scope of the change item in the business system is obtained, and the global impact scope includes the direct impact scope and the related impact scope.

[0010] A second aspect of this application provides an apparatus for determining the scope of impact of a change in the functionality of a business system, comprising:

[0011] An analysis asset construction unit is used to construct impact analysis assets for a business system. The impact analysis assets include code-layer analysis assets, data-layer analysis assets, interface-layer analysis assets, and business-layer analysis assets that are interconnected through external interfaces.

[0012] The impact analysis unit is used to determine the direct impact scope of the changes to the business system from the target layer analysis assets based on the changes to the business system; the target layer analysis assets are the layer analysis assets in the impact analysis assets that directly correspond to the changes to the business system, and the changes include software function changes and business function changes;

[0013] The impact analysis unit is further configured to use external interfaces affected by changes to the business system as target external interfaces, and determine the associated impact range of the business system changes from non-target layer analysis assets based on the target external interfaces; the non-target layer analysis assets include analysis assets at each layer that do not directly correspond to the changes to the business system in the impact analysis assets; and to obtain the global impact range of the business system changes, the global impact range including the direct impact range and the associated impact range.

[0014] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the method for determining the scope of impact of changes to business system functions as described in the first aspect.

[0015] By employing the above technical solution, this application first constructs an impact analysis asset for the business system, then determines the direct impact scope of the change based on the change item in the business system, and determines the associated impact scope of the change item through the external interfaces associated with the change item, ultimately determining the global impact scope of the change item. The multi-dimensional analysis asset provided in this embodiment, interconnected through external interfaces, provides a comprehensive analytical basis for impact analysis. Based on this, this embodiment analyzes the impact scope of changes from four dimensions: code, data, interfaces, and business, realizing the global impact analysis task caused by changes in code, database tables, interfaces, or business processes, thus improving the quality of impact analysis. Attached Figure Description

[0016] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0017] Figure 1A flowchart illustrating a method for determining the scope of impact of a change in the functionality of a business system, provided in an embodiment of this application;

[0018] Figure 2 A schematic diagram illustrating the structure of asset analysis at the code level is provided.

[0019] Figure 3 A schematic diagram illustrating the structure of data layer analysis assets is provided.

[0020] Figure 4 A schematic diagram illustrating the structure of the interface layer for asset analysis is provided.

[0021] Figure 5 This example illustrates the structure of assets analyzed at the business layer.

[0022] Figure 6 This example illustrates the scope of impact of the changes to the wealth management product purchase function;

[0023] Figure 7 A structural diagram of a device for determining the scope of impact of a change in the functionality of a business system, as provided in this application. Detailed Implementation

[0024] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments and is not intended to limit the application. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0025] The terms "first," "second," etc., used in 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 terms can be used interchangeably where appropriate; this is merely a distinguishing method used when describing objects with the same attributes in embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed, or other units inherent to those processes, methods, products, or apparatus.

[0026] This application provides a method and related apparatus for determining the scope of impact of changes to business system functions, in order to solve the analysis quality problem caused by insufficient comprehensiveness of impact analysis.

[0027] Figure 1 This is a flowchart illustrating a method for determining the scope of impact of a business system function change, provided in an embodiment of this application. (Combined with...) Figure 1 As shown, the method may include the following steps S101-S104:

[0028] Step S101: Construct impact analysis assets for the business system.

[0029] The business system described in this application can refer to a system used to implement business in a certain field; for example, the field could be the banking and financial sector. Furthermore, the business system can consist of at least one business subsystem. When the business system includes at least two business subsystems, to implement a specific business function, different business subsystems may need to work together through interfaces. That is, a change in the function of a single business subsystem may affect other business subsystems. The interfaces of any system involved in this application can include internal interfaces and external interfaces. Internal interfaces refer to interfaces used to enable interaction between modules within the system, also known as system-internal interfaces. External interfaces refer to interfaces used to enable interaction between systems, also known as system-internal interfaces. Unless otherwise specified, the system described in this specification refers to the system unit constituting the business system, i.e., a business subsystem. In other words, "within the system" refers to within a single subsystem, and "between the systems" refers to between two subsystems. This application does not limit the field to which the business system belongs or its composition.

[0030] The applicant's analysis revealed that, due to the often independent nature of the source code and data of different business subsystems, existing impact analysis solutions relying on Java abstract syntax trees and code call relationships can only determine the scope of impact within a single subsystem, failing to achieve cross-system and cross-transaction impact analysis tasks. To address this issue, this application constructs an impact analysis asset for business systems, enabling impact analysis from the perspectives of code, data, inter-subsystem relationships, and business system functions, thereby improving the comprehensiveness and quality of the analysis.

[0031] The impact analysis assets may include: code-layer analysis assets, data-layer analysis assets, interface-layer analysis assets, and business-layer analysis assets that are interconnected through external interfaces. For a business system consisting of at least two subsystems, the code-layer analysis assets of the business system refer to the sum of the code-layer analysis assets of each subsystem, and the data-layer analysis assets of the business system refer to the sum of the data-layer analysis assets of each subsystem. The following provides illustrative examples of each layer of analysis assets.

[0032] Code layer analysis assets are used to characterize the calling relationships between code layer resources. Code layer resources can include at least one level of resources. Taking a business system based on the Java technology stack as an example, code layer resources can include method-level, class-level, component-level, and interface-level resources. Methods refer to methods within the system, and interfaces can include internal interfaces and external interfaces, that is, interfaces that implement the interaction between modules within a subsystem and interfaces that implement the interaction between different subsystems.

[0033] Data layer analysis assets are used to characterize the calling relationships between data layer resources. Data layer resources can include at least one level of resources, such as method-level, database table-level, and field-level resources, where "method" refers to methods within the system. Code layer analysis assets and data layer analysis assets can be collectively referred to as in-system analysis assets.

[0034] Interface layer analysis assets can represent the calling relationship between interface-level resources. Here, the interface refers to the external interface, that is, interface layer analysis assets belong to the inter-system analysis assets.

[0035] Business layer analysis assets mainly include business assets, which involve various business functions of the business system. To accomplish the tasks of determining the software scope affected by changes in business functions and the business scope affected by changes in software functions, interfaces can be established to associate with business assets, thus constructing business layer analysis assets.

[0036] It should be noted that both code-level and interface-level resources directly contain external interfaces. Data-level resources may not contain interfaces, but they can be associated with external interfaces through their contained method-level resources, and the implementation of business functions also depends on interface calls. Based on this, different dimensions of analytical assets can be associated through external interfaces, thereby constructing a global, impactful analytical asset.

[0037] Step S102: Based on the changes to the business system, determine the direct impact scope of the changes to the business system from the target layer analysis assets.

[0038] It should be noted that the functional changes applicable to this application can refer to software functional changes or business functional changes; that is, the changes can include both software functional changes and business functional changes. Specifically, software functional changes can be reflected in at least one of code changes, data changes, and interface changes, while data changes refer to changes related to database table fields.

[0039] The target layer analysis asset is the layer analysis asset in the impact analysis assets that directly corresponds to the change item in the business system. Specifically, business changes directly correspond to business layer analysis assets, code changes directly correspond to code layer analysis assets, data changes directly correspond to data layer analysis assets, and interface changes directly correspond to interface layer analysis assets. Correspondingly, non-target layer analysis assets may include the layers analysis assets in the impact analysis assets that do not directly correspond to the change item in the business system, that is, other layers analysis assets in the impact analysis assets besides the target layer analysis assets.

[0040] Step S103: Take the external interface affected by the change item of the business system as the target external interface, and determine the scope of the associated impact of the change item of the business system from the non-target layer analysis assets based on the target external interface.

[0041] Step S104: Obtain the global impact scope of the change items in the business system.

[0042] The global scope of influence may include the direct scope of influence and the associated scope of influence.

[0043] This embodiment first constructs impact analysis assets for the business system, then determines the direct impact scope of each change based on the changes made to the business system, and further determines the associated impact scope of the change through the external interfaces associated with it, ultimately determining the global impact scope of the change. The multi-dimensional analysis assets provided in this embodiment, interconnected through external interfaces, offer comprehensive analytical support for impact analysis. Based on this, this embodiment analyzes the impact scope of changes from four dimensions: code, data, interfaces, and business processes. It achieves global impact analysis tasks caused by changes in code, databases, interfaces, or business processes, ensuring the comprehensiveness and accuracy of the impact analysis and improving its quality and efficiency.

[0044] In one possible implementation, the aforementioned construction of impact analysis assets may refer to acquiring analysis assets in four dimensions: code, data, interfaces, and business. Based on this, the aforementioned impact analysis assets are configured by associating these four dimensions of analysis assets.

[0045] The term "acquisition" can refer to either extraction or generation. That is, the aforementioned analysis assets in the code / data / interface / business dimensions can be existing assets that have been extracted or newly generated assets, such as assets generated before or during the determination of the scope of impact of the business system function change.

[0046] The following detailed explanation of step S101 will be provided using the asset generation process as an example.

[0047] In one or more embodiments provided in this application, step S101, constructing the impact analysis assets of the business system, may include the following steps S201-S203:

[0048] Step S201: Analyze the business system to obtain the call relationship chain of the non-business layer.

[0049] The non-business layer call relationship chain can include: the code layer call relationship chain, the interface layer call relationship chain, and the data layer call relationship chain.

[0050] Step S202: Based on the association between business assets and external interfaces, generate the call relationship chain of the business layer.

[0051] In addition, the generated call relationship links of each dimension can be uniformly stored in the database for subsequent asset interconnection calculations of each dimension.

[0052] Step S203: Through an external interface, connect the call relationship links of the code layer, the interface layer, the data layer, and the business layer to generate the impact analysis asset.

[0053] When connecting link assets across different dimensions, a pairwise connection approach can be adopted. It should be noted that, to construct standardized and structured impact analysis assets, if the call relationship links at different layers meet the data standardization conditions, the call relationship links at each layer can be directly connected, and the connected call relationship links at each layer can be used as impact analysis assets; otherwise, data standardization processing should be performed first, and then the standardized call relationship links at each layer should be connected to obtain the impact analysis assets. In other words, the aforementioned code / data / interface / business layer analysis assets can refer to the call relationship links at the code / data / interface / business layer that meet the data standardization conditions.

[0054] This embodiment, based on the ability to characterize the call relationship links of assets at each layer in each dimension, connects and links the assets in each dimension through external interfaces, constructing a global view of impact analysis, and providing comprehensive and reliable analytical basis for the impact analysis of business system function changes.

[0055] In one or more embodiments provided in this application, step S201, parsing the business system to obtain the non-business layer call relationship chain, may include the following steps S301-S304:

[0056] Step S301: Obtain the Java source code of the business system and the dynamic objects generated during the operation of the business system.

[0057] Optionally, when obtaining the source code of the business system, the current version of the source code can be cached on the local server using the Git operation module for subsequent operations, such as parsing. The aforementioned dynamic object is an object that can reflect the running status of the business system.

[0058] Furthermore, this application uses a business system built on Java as an example for illustration. When the business system adopts other technology stacks, corresponding code parsing methods can be used to obtain the preliminary call relationship chain of the non-business layer.

[0059] Step S302: Call the Java source code parsing tool to perform static parsing on the Java source code to obtain the call relationship chain of the code layer, the call relationship chain of the data layer, and the first call relationship chain of the interface layer.

[0060] Based on the Java technology stack, the aforementioned Java source code parsing tools can, for example, include: the parsing tool JavaParser and the parsing tool QDox. JavaParser can transform Java source code files into an abstract syntax tree, providing accurate and powerful code analysis capabilities. QDox is a high-performance, low-memory Java source code parsing tool that can quickly extract Java class, interface, and method definitions, including annotations, parameters, and parameter names. The foregoing is merely an example of source code parsing tools; other parsing tools can also be used, and this application does not limit their application.

[0061] Step S303: Parse the dynamic object to obtain the second call relationship chain of the interface layer;

[0062] It should be noted that in certain scenarios based on specific code call patterns, such as partial reflection or overloading, static parsing may not be able to obtain all interface call relationships, leading to inaccurate parsing. Therefore, this application employs a dynamic approach to complete the call relationships obtained from static parsing. Furthermore, the aforementioned steps S302 and S303 can be executed in parallel or sequentially; for example, step S303 can be executed first, followed by step S302. This application does not impose any restrictions on this.

[0063] Step S304: Generate the call relationship chain of the interface layer based on the first call relationship chain and the second call relationship chain of the interface layer.

[0064] Based on the above, this application first obtains the source code of the business system, such as by pulling the code to the local machine, and then uses a static source code parsing algorithm to determine the calling relationships of resources in each non-business layer, thus initially obtaining analytical assets in the code, data, and interface layers. On this basis, a dynamic approach is then used to further parse the inter-system interface calling relationships in dynamic scenarios, as a supplement to the analytical assets obtained through static source code parsing. Finally, a more comprehensive non-business dimension analytical asset matching the actual operation of the business system is obtained, providing a foundation for improving the quality of subsequent impact analysis.

[0065] The following section provides an illustrative example of the process for generating the call relationship chains for each non-business layer.

[0066] In one or more embodiments provided in this application, the aforementioned process of calling a Java source code analysis tool to perform static analysis on the Java source code to obtain the call relationship chain of the code layer may include:

[0067] Step S401: Call the Java source code parsing tool to identify the method relationships within the system based on the Java source code parsing, and generate the method call chain within the system.

[0068] The aforementioned intra-system method call chain can include call chains corresponding to the system backend. Furthermore, since business systems often have interfaces for user interaction, the aforementioned intra-system method call chain can also include call chains corresponding to the system frontend. In other words, the intra-system method call chain can include: a frontend page-method-interface call chain and a backend method-class-component-interface call chain.

[0069] Step S402: Determine the external interface associated with the method involved in the method call chain within the system, and generate the call relationship chain of the code layer based on the method call chain within the system and the determined external interface.

[0070] For example, Figure 2 A schematic diagram of the code-layer analysis assets is shown. Based on front-end and back-end, code-layer analysis assets can include method call chains within the back-end system and method call chains within the front-end system, which are interconnected through external interfaces. The method call chains within the back-end system reflect the internal method call relationships of various subsystems corresponding to the back-end. Taking a method within a system as an example, the analysis assets related to that method can include components, classes, method names, and code tags, and further include the external interface corresponding to that method. The external interfaces in the analysis assets involved in this application embodiment can be represented using interfaces, interface business meanings, interface method names, and interface tags. The method call chains within the front-end system reflect the internal call relationships of various subsystems corresponding to the front-end (i.e., front-end pages). Taking a front-end page as an example, the analysis assets related to that page can include the page's function menus and language representations, where the language representation can be represented by Hypertext Markup Language (HTML) or JavaScript (JS). In addition, corresponding external interfaces are also included; the description of the external interfaces can be found above.

[0071] The above solution obtains the code call relationship chain within the system through static source code analysis, forming a multi-level call chain view including the system front-end from page to method to interface, and the system back-end from method to class to component and finally to interface. The resulting code-level chain assets can be used to identify methods, classes, components, interfaces, and pages affected by software function changes (specifically, code changes).

[0072] In one or more embodiments provided in this application, the aforementioned invocation of a Java source code analysis tool to perform static analysis on the Java source code to obtain the call relationship chain of the data layer may include:

[0073] Step S501: Based on the parsing and identification results of the method relationships within the system, parse and identify the relationship between the identification methods and the operation functions of the database tables, and generate the call chain of method-database table-field.

[0074] It should be noted that the relationship between methods and database tables typically follows fixed rules. For example, database tables may use annotations such as @Table or @Column, or there may be other fixed rules governing the relationship between methods and database tables. Based on this, by further analyzing the relationship between methods and database table operation functions after parsing the relationships within the system, we can obtain the call relationships between methods and the database tables and their fields, thus revealing the call chain at the data dimension.

[0075] The aforementioned parsing and identification results of intra-system method relationships can refer to intra-system method call chains, or they can be unorganized parsing and identification results. Intra-system method call chains can be obtained by organizing the parsing and identification results of intra-system method relationships.

[0076] Step S502: Determine the external interface associated with the method involved in the method-database table-field call chain, and generate the call relationship chain of the data layer based on the method-database table-field call chain and the determined external interface.

[0077] For example, Figure 3 The diagram illustrates the structure of data layer analytics assets, which reflect the relationship between data and interfaces. Taking a database table field as an example, the analytics assets related to that field can include the database name, table name, field name, and field label. In addition, it also includes the corresponding external interface, which can be described in the preceding text.

[0078] The above approach obtains a call chain view from methods to database tables and then to fields through static source code analysis, forming a data-dimensional analysis asset. This data-dimensional call chain asset can be used to identify database tables and fields affected by software function changes (specifically, interface changes, method changes, and data changes).

[0079] In one or more embodiments provided in this application, the aforementioned invocation of a Java source code parsing tool to perform static parsing of the Java source code to obtain the first call relationship chain of the interface layer may include:

[0080] Step S601: Based on the parsing and identification results of the method relationships within the system, parse and identify the information of the service provider system that each subsystem needs to call when acting as a consumer system.

[0081] The aforementioned information may include outgoing functions, configuration files, and other information.

[0082] Step S602: Match the identified information with the service provider's system interface information to determine the external interface call relationship, which serves as the first call relationship link of the interface layer;

[0083] The external interface call relationship may include the interface call relationship between the consumer system and the service system.

[0084] Based on the above, the code-dimensional analysis asset construction scheme provides a foundation for subsequent non-business-dimensional analysis asset construction schemes. To avoid redundant processing, code-dimensional analysis assets can be constructed first, followed by data / interface-dimensional analysis assets.

[0085] Based on the first call relationship chain of the interface layer obtained by the above static parsing, further dynamic parsing can solve the problem of inaccurate and incomplete parsing caused by special code call forms.

[0086] In one possible implementation, step S303, parsing the dynamic object to obtain the second call relationship chain of the interface layer, may include:

[0087] The application performance monitoring tool parses the request identifier configured when performing full-link tracing on the running business system, identifies the external interface pair, and generates the second call relationship link of the interface layer.

[0088] Each external interface pair consists of the interface of the current subsystem and the interface of the downstream subsystem. For example, the application performance monitoring tool mentioned above could be the dynamic data collection tool SkyWalking, and the aforementioned request identifier could be represented as a traceID. Furthermore, for better compatibility with application performance monitoring tools, the aforementioned dynamic solution (also known as the dynamic tracing solution) can be applied to business systems within a microservice framework.

[0089] In another possible implementation, step S303, parsing the dynamic object to obtain the second call chain of the interface layer, may include:

[0090] Step S701: For each selected transaction, obtain all logs of the current transaction in each subsystem based on the transaction serial number, parse the obtained logs, and determine the cross-subsystem interface call chain of the current transaction.

[0091] The acquired dynamic object can refer to system operation logs, and the selected transaction refers to each transaction contained in the acquired logs. In one possible implementation, log data can be generated by a business system running within a virtual machine deployed on the server; that is, the virtual machine serves as the carrier of the log source. Based on this, a shell operation module can be used to view and analyze the log data of the log source, such as performing regular expression parsing, for subsequent log chain tracing processing. The shell operation module can be a tool used for operation or management on the virtual machine deployed on the server. Furthermore, it should be noted that the serial number is generated at the entry point of the current transaction, transmitted to the downstream service provider system, and recorded in the logs of each subsystem involved in the current transaction.

[0092] Step S702: Generate the second call relationship link of the interface layer based on the cross-subsystem interface call link of each transaction.

[0093] Optionally, the dynamic solution described above can be applied to business systems with traditional architectures. For example, a log tracing solution may specifically include: establishing system flow rules based on block processing of log modules; parsing the unique serial number transmitted by a transaction to the service provider; obtaining all logs of the transaction in each subsystem based on the serial number; then obtaining the service provider system and interfaces through parsing; and finally establishing the cross-system full interface call relationship of a transaction.

[0094] This embodiment utilizes dynamic linking to supplement and improve the complete linking structure that static solutions cannot parse, ultimately forming a complete and accurate interface call linking structure that is not limited by any particular scenario. Furthermore, the dynamic solution corresponds to the actual linking scenarios that occur in testing or production environments. Based on this, link importance can be marked, and by using the interface-level analysis assets generated based on the dynamic solution, the scope of specific scenarios can be determined during impact analysis.

[0095] For example, Figure 4 The diagram illustrates the structure of the interface layer analysis assets, which reflect the calling relationships between system interfaces. Taking an external interface as an example, the analysis assets related to this external interface may include: the external interface itself, and the associated system external interfaces; any external interface can be represented as an interface, its business meaning, its method name, and its label, etc.

[0096] Based on the foregoing, this application adopts an interface asset generation scheme that primarily uses static source code parsing and secondarily uses dynamic link tracing. This scheme automatically constructs the interface call links of upstream and downstream systems, forming a call link view between systems from interface to interface. The resulting link assets at the interface level can be used to identify upstream and downstream systems / services and interfaces affected by software function changes (such as interface changes).

[0097] When constructing non-business layer analysis assets, this application can first generate code layer link assets, data layer link assets, and preliminary interface layer link assets based on the relationships between interfaces, classes, methods, and library table fields obtained by static parsing, and then obtain further interface layer link assets based on dynamic parsing.

[0098] The following describes the generation scheme for business dimension analysis assets. The business assets mentioned in step S202 can include sequence diagrams, business process instantiations, etc. A sequence diagram is a structured flowchart asset describing all business scenarios of an interface or function within a subsystem. Business process instantiation is a business process link that includes both within and across subsystems. It achieves the structured and standardized connection of business transactions and scenario processes, forming a uniformly formatted cross-system business transaction link asset. In other words, the business assets mentioned can be structured assets.

[0099] It's important to note that for existing business functions (i.e., the set of existing business functions in a business system that is already online and running), the mapping relationship between business function, interface, sequence diagram, and business process instantiation assets is usually established in advance and maintained throughout the project implementation process. This ensures that there are always structured assets available for mapping and interpretation. Based on this, by extracting structured assets related to the business scenario, such as sequence diagram-interface and business process instantiation-interface, we can obtain business-dimensional analysis assets. These assets can then be associated with the interface layer, data layer, and code layer through external interfaces, thereby constructing a global network of assets.

[0100] Optionally, the constructed impact analysis assets can be continuously updated and kept fresh through online version management. For example, online version management can include real-time management of pulling and parsing data through the master branch and code branches, as well as management of versions based on the scheduled test environment. In addition, the constructed impact analysis assets and the determined global impact scope can be visualized through a visualization module, thereby providing different roles with a basis for querying and analyzing the impact scope from various dimensions at different stages such as requirements analysis, development design, and test analysis. This solves the problems in traditional division of labor scenarios, such as incomplete analysis, easy omissions, or the need for repeated communication and confirmation among multiple parties, which are time-consuming due to different perspectives and limited understanding of assets among different roles.

[0101] For example, Figure 5 The diagram illustrates the structure of business layer analytics assets, which reflect the relationships between business processes and interfaces. Taking any business scenario as an example, the analytics assets related to that scenario may include the business scenario name, sequence diagram, and business process instantiation. In addition, they may include corresponding external interfaces, the description of which can be found above.

[0102] This application establishes a mapping relationship between business function requirements and structured assets, forming a call chain view from interfaces to functional scenarios within the system and then to business scenarios between systems. Combined with the ability to analyze the impact of code, data, and interface layers, it forms a complete business and business scenario analysis capability.

[0103] The following describes the apparatus for determining the impact range of changes in business system functions provided in the embodiments of this application. The apparatus for determining the impact range of changes in business system functions described below and the method for determining the impact range of changes in business system functions described above can be referred to in correspondence with each other.

[0104] The device for determining the scope of impact of changes to business system functions provided in this application embodiment may include: an asset analysis unit and an impact analysis unit.

[0105] The analysis asset construction unit can be used to construct impact analysis assets for business systems. These impact analysis assets include code-layer analysis assets, data-layer analysis assets, interface-layer analysis assets, and business-layer analysis assets that are interconnected through external interfaces.

[0106] The impact analysis unit can be used to determine the direct impact scope of the changes to the business system from the target layer analysis assets based on the changes to the business system; the target layer analysis assets are the layer analysis assets in the impact analysis assets that directly correspond to the changes to the business system, and the changes include software function changes and business function changes;

[0107] The impact analysis unit can also be used to identify external interfaces affected by changes to the business system as target external interfaces, and determine the associated impact range of the business system changes from non-target layer analysis assets based on the target external interfaces; the non-target layer analysis assets include analysis assets at each layer that do not directly correspond to the changes to the business system in the impact analysis assets; and obtain the global impact range of the business system changes, the global impact range including the direct impact range and the associated impact range.

[0108] In one or more embodiments provided in this application, the analysis asset construction unit may include: a non-business layer asset construction unit, a business layer asset construction unit, and an asset association unit.

[0109] The non-business layer asset construction unit can be used to: parse the business system to obtain the non-business layer call relationship chain; the non-business layer call relationship chain includes: the code layer call relationship chain, the interface layer call relationship chain and the data layer call relationship chain;

[0110] The business layer asset construction unit can be used to: generate a business layer call relationship chain based on the association between business assets and external interfaces;

[0111] The asset association unit can be used to: connect the call relationship links of the code layer, the interface layer, the data layer, and the business layer through an external interface to generate the impact analysis asset.

[0112] In one or more embodiments provided in this application, the non-business layer asset construction unit may include a first construction unit and a second construction unit.

[0113] Specifically, the first building unit can be used to: obtain the Java source code of the business system, and call a Java source code parsing tool to perform static parsing processing on the Java source code to obtain the call relationship chain of the code layer, the call relationship chain of the data layer, and the first call relationship chain of the interface layer.

[0114] The second construction unit can be used to: obtain dynamic objects generated by the business system during operation, parse the dynamic objects to obtain the second call relationship chain of the interface layer, and generate the call relationship chain of the interface layer based on the first call relationship chain of the interface layer and the second call relationship chain of the interface layer.

[0115] In one or more embodiments provided in this application, the process by which the first building unit calls a Java source code analysis tool to perform static analysis on the Java source code to obtain the call relationship chain of the code layer may include:

[0116] The Java source code analysis tool is invoked to identify the method relationships within the system based on the Java source code analysis, generate the method call chain within the system, and determine the external interfaces associated with the methods involved in the method call chain within the system. Based on the method call chain within the system and the determined external interfaces, the call relationship chain of the code layer is generated. The method call chain within the system includes: the call chain of front-end page-method-interface and the call chain of back-end method-class-component-interface.

[0117] In one or more embodiments provided in this application, the process by which the first building unit calls a Java source code parsing tool to perform static parsing on the Java source code to obtain the first call relationship chain of the interface layer may include:

[0118] Based on the parsing and identification results of the method relationships within the system, the information of the service provider system that each subsystem needs to call when acting as a consumer system is parsed and identified, and matched with the interface information of the service provider system to determine the external interface call relationship, which serves as the first call relationship link of the interface layer; the external interface call relationship includes the interface call relationship between the consumer system and the service provider system.

[0119] In one or more embodiments provided in this application, the process by which the second construction unit parses the dynamic object to obtain the second call relationship chain of the interface layer may include:

[0120] The application performance monitoring tool analyzes the request identifier configured when performing full-link tracing on the running business system, identifies external interface pairs, and generates the second call relationship chain of the interface layer; wherein, each external interface pair consists of the interface of the current subsystem and the interface of the downstream subsystem.

[0121] In one or more embodiments provided in this application, the process by which the second construction unit parses the dynamic object to obtain the second call relationship chain of the interface layer may include:

[0122] For each selected transaction, based on the transaction's serial number, all logs of the current transaction in each subsystem are obtained, the obtained logs are parsed, and the cross-subsystem interface call chain of the current transaction is determined; wherein, the serial number is generated at the entry point of the current transaction, transmitted to the downstream service system, and recorded in the logs of each subsystem involved in the current transaction;

[0123] Based on the cross-subsystem interface call chain of each transaction, a second call relationship chain of the interface layer is generated.

[0124] In one or more embodiments provided in this application, the process by which the first building unit calls a Java source code parsing tool to perform static parsing of the Java source code to obtain the call relationship chain of the data layer may include:

[0125] Based on the parsing and identification results of the method relationships within the system, the relationships between the identified methods and the operation functions of the database tables are parsed and identified respectively, generating a method-database table-field call chain, and determining the external interfaces associated with the methods involved in the method-database table-field call chain. Based on the method-database table-field call chain and the determined external interfaces, the call relationship chain of the data layer is generated.

[0126] The following examples, using business scenarios, illustrate the solution proposed in this application.

[0127] For example, Figure 6 Based on an impact analysis example of changes to the wealth management product purchase business, a schematic diagram illustrating the scope of impact of these changes is presented. It should be noted that in the business scenario of purchasing wealth management products for retail customers, the process begins with responding to the customer's purchase request, logging into the business system, and entering the wealth management business process, which may include steps such as wealth management contract signing, risk assessment, wealth management purchase, and wealth management redemption. The following section combines... Figure 6 This paper analyzes the impact of the change to the financial purchase function from different stages of project implementation, including requirement design, development design, development coding, and test design. The scope of impact may vary at different stages.

[0128] For example, during the requirements design phase, when the wealth management purchase function changes, such as changes to related systems, transactions, or scenarios involved in this business, the technical call path from channel to private business partner to new exchange to wealth management platform can be used to determine that the main subsystem affected by this change is the wealth management platform's accounting service system. By analyzing the scope of impact based on the functional keywords representing the change items, the scope of impact can be determined, such as the range of interfaces that will be affected. Based on this, the requirements designers can select the interfaces that need to be modified based on their business experience.

[0129] During the development and design phase, system designers can apply an impact analysis scheme based on the interface to be changed to obtain the scope of impact of the interface change, such as the class scope. Based on this, system designers can determine the class to be modified, and then perform an impact analysis scheme based on the class to be changed to obtain the scope of impact of the class change, such as the method scope. The methods that need to be modified are determined manually. For example, when manually identifying the PubTransService public function class to be modified, the scope of methods affected by the PubTransService class change can be obtained based on this application.

[0130] During the coding development phase, developers will modify the code. Afterward, impact analysis schemes can be applied to determine the scope of impact based on code changes (such as method changes). For example, when manually identifying changes to the `checkNewCustProduct` method, this application can obtain the scope of code and data affected by the change, such as the transaction amount field `AMT` and transaction status `TRANS_STATUS` in the transaction request log table `TBTRANSREQ`, the `checkNewCust` and `isNewProduct` methods in the method chain, and related fields in the update share table `TBSHARE` for the `checkNewCust` method.

[0131] During the test analysis phase, testers can apply the impact analysis scheme based on the business asset "Customer Pre-Transaction Inquiry" and use the related asset "Wealth Management Integrated Sales Platform System / Online Transaction / 980316-Customer Pre-Transaction Inquiry" to determine the scope of business scenarios affected by the existing time-series assets.

[0132] The device for determining the scope of impact of changes to business system functions provided in this application embodiment can be applied to devices for determining the scope of impact of changes to business system functions, such as terminals with data processing capabilities: mobile phones, computers, servers, etc. Optionally, Figure 7 The diagram shows the hardware structure of the device used to determine the scope of impact of changes to the business system's functions. (Refer to...) Figure 7The hardware structure of the device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;

[0133] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4;

[0134] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0135] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0136] The memory is used to store computer programs, and the processor is used to execute the computer programs so that the device for determining the scope of impact of changes to business system functions can implement any of the above-mentioned methods for determining the scope of impact of changes to business system functions.

[0137] This application also provides a storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the methods for determining the scope of impact of changes in business system functions provided in this application.

[0138] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, enable the electronic device to implement any of the business system function change impact scope determination methods provided in this application.

[0139] It should also be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0140] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for determining the scope of impact of a change in the functionality of a business system, characterized in that, include: Construct impact analysis assets for the business system, which include code-layer analysis assets, data-layer analysis assets, interface-layer analysis assets, and business-layer analysis assets that are interconnected through external interfaces; Based on the changes to the business system, the direct impact scope of the changes to the business system is determined from the target layer analysis assets; the target layer analysis assets are the layer analysis assets in the impact analysis assets that directly correspond to the changes to the business system, and the changes include software function changes and business function changes; External interfaces affected by changes to the business system are designated as target external interfaces, and the scope of the associated impact of the changes to the business system is determined from non-target layer analysis assets based on the target external interfaces; the non-target layer analysis assets include analysis assets at each layer that do not directly correspond to the changes to the business system in the impact analysis assets. The global impact scope of the change item in the business system is obtained, and the global impact scope includes the direct impact scope and the related impact scope.

2. The method for determining the scope of impact of business system function changes according to claim 1, characterized in that, The assets for impact analysis of building business systems include: The business system is analyzed to obtain the call relationship chain of the non-business layer; the call relationship chain of the non-business layer includes: the call relationship chain of the code layer, the call relationship chain of the interface layer, and the call relationship chain of the data layer; Based on the relationship between business assets and external interfaces, a call relationship chain for the business layer is generated; By connecting the call relationship chains of the code layer, the interface layer, the data layer, and the business layer through external interfaces, the impact analysis asset is generated.

3. The method for determining the scope of impact of business system function changes according to claim 2, characterized in that, Analyzing the business system yields the call relationship chain outside the business layer, including: Obtain the Java source code of the business system and the dynamic objects generated during the operation of the business system; The Java source code is statically analyzed using a Java source code analysis tool to obtain the call relationship chain of the code layer, the call relationship chain of the data layer, and the first call relationship chain of the interface layer. The dynamic object is parsed to obtain the second call relationship chain of the interface layer; Based on the first call relationship chain and the second call relationship chain of the interface layer, the call relationship chain of the interface layer is generated.

4. The method for determining the scope of impact of business system function changes according to claim 3, characterized in that, The Java source code is statically analyzed using a Java source code analysis tool to obtain the call relationship chain of the code layer, including: The Java source code analysis tool is invoked to identify the method relationships within the system based on the Java source code analysis, generate the method call chain within the system, and determine the external interfaces associated with the methods involved in the method call chain within the system. Based on the method call chain within the system and the determined external interfaces, the call relationship chain of the code layer is generated. The method call chain within the system includes: the call chain of front-end page-method-interface and the call chain of back-end method-class-component-interface.

5. The method for determining the scope of impact of business system function changes according to claim 4, characterized in that, The Java source code is statically analyzed using a Java source code analysis tool to obtain the first call relationship chain of the interface layer, including: Based on the parsing and identification results of the method relationships within the system, the information of the service provider system that each subsystem needs to call when acting as a consumer system is parsed and identified, and matched with the interface information of the service provider system to determine the external interface call relationship, which serves as the first call relationship link of the interface layer; the external interface call relationship includes the interface call relationship between the consumer system and the service provider system.

6. The method for determining the scope of impact of business system function changes according to claim 3, characterized in that, The dynamic object is parsed to obtain the second call chain of the interface layer, including: The application performance monitoring tool analyzes the request identifier configured when performing full-link tracing on the running business system, identifies external interface pairs, and generates the second call relationship chain of the interface layer; wherein, each external interface pair consists of the interface of the current subsystem and the interface of the downstream subsystem.

7. The method for determining the scope of impact of business system function changes according to claim 3, characterized in that, The dynamic object is parsed to obtain the second call chain of the interface layer, including: For each selected transaction, based on the transaction's serial number, all logs of the current transaction in each subsystem are obtained, the obtained logs are parsed, and the cross-subsystem interface call chain of the current transaction is determined; wherein, the serial number is generated at the entry point of the current transaction, transmitted to the downstream service system, and recorded in the logs of each subsystem involved in the current transaction; Based on the cross-subsystem interface call chain of each transaction, a second call relationship chain of the interface layer is generated.

8. The method for determining the scope of impact of business system function changes according to claim 4, characterized in that, The Java source code is statically analyzed using a Java source code analysis tool to obtain the call relationship chain of the data layer, including: Based on the parsing and identification results of the method relationships within the system, the relationships between the identified methods and the operation functions of the database tables are parsed and identified respectively, generating a method-database table-field call chain, and determining the external interfaces associated with the methods involved in the method-database table-field call chain. Based on the method-database table-field call chain and the determined external interfaces, the call relationship chain of the data layer is generated.

9. A device for determining the scope of impact of a change in the function of a business system, characterized in that, include: An analysis asset construction unit is used to construct impact analysis assets for a business system. The impact analysis assets include code-layer analysis assets, data-layer analysis assets, interface-layer analysis assets, and business-layer analysis assets that are interconnected through external interfaces. The impact analysis unit is used to determine the direct impact scope of the changes to the business system from the target layer analysis assets based on the changes to the business system; the target layer analysis assets are the layer analysis assets in the impact analysis assets that directly correspond to the changes to the business system, and the changes include software function changes and business function changes; The impact analysis unit is further configured to identify external interfaces affected by changes to the business system as target external interfaces, and determine the associated impact scope of the changes to the business system from non-target layer analysis assets based on the target external interfaces; the non-target layer analysis assets include analysis assets at each layer that do not directly correspond to the changes to the business system in the impact analysis assets. In addition, the global impact scope of the change item in the business system is obtained, the global impact scope including the direct impact scope and the related impact scope.

10. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the method for determining the scope of impact of a change in a business system function as described in any one of claims 1 to 8.

Images