Asset list generation method, device, equipment and storage medium

Abstract

Embodiments of the present application relate to the technical field of artificial intelligence, in particular to an asset list generation method and device, equipment and a storage medium. The present application first acquires a compiled code package and asset element configuration parameters, then directly parses the code package to identify a plurality of asset elements and a plurality of calling relationships between the asset elements, then identifies asset relationships between the plurality of asset elements using the asset element configuration parameters and the calling relationships, and finally generates an asset list according to the plurality of asset elements and the asset relationships. The present application can directly parse the compiled code using a parsing tool to reversely generate an asset list, identify new asset elements appearing in each development iteration in the code, and reflect these asset elements and their relationships in the asset list, greatly reducing the cost of manual maintenance, improving the efficiency of iterative updating of the asset list, and also avoiding data loss and data errors caused by human error.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of artificial intelligence, and in particular to an asset list generation method and device, equipment and a storage medium. BACKGROUND

[0002] As software becomes more and more complex, in actual development, a large number of business logics are often accumulated in a huge class, and the reusability and extensibility of the code cannot be guaranteed.

[0003] In order to solve such problems, DDD (Domain Drive Design) proposes a clear layered architecture and the concept of domain objects, which brings object-oriented analysis and design into a new stage and plays a huge role in promoting enterprise-level software development.

[0004] With the rise of DDD, the landing effect of the DDD architecture methodology also needs to be measured by data, which will be updated continuously with the evolution of iterations. In the channel middle platform, a set of DDD construction effect measurement standards based on asset list is defined. The calculation of the asset list needs to identify the asset elements of the domain construction, the relationship between the elements, and the number of reused domain service elements according to the relationship. Each development iteration may produce new elements and new element relationships, and these changes need to be reflected in the list, and each update of the asset list is a time-consuming and energy-consuming process. At present, asset elements are mainly identified manually and filled into Excel files manually, which not only wastes time and effort, but also is prone to errors in manual maintenance. SUMMARY

[0005] The following is a summary of the subject matter described in detail herein. This summary is not intended to limit the scope of the claims.

[0006] The main purpose of the embodiments of the present disclosure is to propose an asset list generation method, device, equipment and storage medium, which can greatly reduce the cost of manual maintenance, improve the efficiency of iterative update of the asset list, and also avoid data loss and data errors caused by human errors.

[0007] To achieve the above purpose, a first aspect of the embodiments of the present disclosure proposes an asset list generation method, which comprises:

[0008] Obtaining a code package and asset element configuration parameters, the code package comprising compiled code, the code complying with a DDD architecture specification;

[0009] Parsing the code package to identify a plurality of asset elements in the code and determine the calling relationship between the plurality of asset elements;

[0010] Based on the asset element configuration parameters and the invocation relationship, identify the asset relationship between multiple asset elements;

[0011] An asset list is generated based on the multiple asset elements and the asset relationships.

[0012] In some embodiments, parsing the code package to identify multiple asset elements in the code and determining the calling relationships between the multiple asset elements includes:

[0013] Obtain the BCEL library;

[0014] The code package is input into the BCEL library so that the BCEL library parses the code in the code package to obtain multiple asset elements in the code and the calling relationships between the multiple asset elements.

[0015] In some embodiments, the asset element configuration parameters include the package name of the configured asset element; identifying the asset relationship between multiple asset elements based on the asset element configuration parameters and the invocation relationship includes:

[0016] Based on the package name of the configured asset element, identify the category to which each asset element in the code belongs;

[0017] Based on the category to which each asset element belongs and the calling relationship, identify the asset relationships between multiple asset elements.

[0018] In some embodiments, the asset element includes classes and methods; the calling relationships between the multiple asset elements include calling relationships between multiple methods and calling relationships between multiple classes.

[0019] In some embodiments, generating an asset list based on the plurality of asset elements and the asset relationships includes:

[0020] Based on the asset relationships, calculate the reused asset elements;

[0021] The reuse rate of the asset element is calculated based on the number of reused asset elements and the number of multiple asset elements.

[0022] An asset list is generated using the multiple asset elements, the asset relationships, the reused asset elements, and the reuse rate.

[0023] In some embodiments, calculating the reused asset elements based on the asset relationships includes:

[0024] Based on the asset relationships between the asset elements, functional elements that are called by multiple business scenarios are identified as the reused asset elements.

[0025] In some embodiments, the reuse rate of the asset element is the reuse rate of the functional element; calculating the reuse rate of the asset element based on the number of reused asset elements and the number of the plurality of asset elements includes:

[0026] Count the first number of the functional elements that are called by multiple business scenarios;

[0027] Count the second number of the functional elements among the multiple asset elements;

[0028] The reuse rate of the functional element is calculated based on the first quantity and the second quantity.

[0029] To achieve the above objectives, a second aspect of this disclosure provides an asset inventory generation apparatus, the asset inventory generation apparatus comprising:

[0030] The code package acquisition unit is used to acquire code packages and asset element configuration parameters. The code package includes compiled code that conforms to the DDD architecture specification.

[0031] A code package parsing unit is used to parse the code package to identify multiple asset elements in the code and determine the calling relationship between the multiple asset elements;

[0032] An asset relationship identification unit is used to identify the asset relationship between multiple asset elements based on the asset element configuration parameters and the calling relationship;

[0033] The asset list generation unit is used to generate an asset list based on the multiple asset elements and the asset relationships.

[0034] To achieve the above objectives, a third aspect of the present disclosure provides an electronic device including at least one memory;

[0035] At least one processor;

[0036] At least one computer program;

[0037] The computer program is stored in the memory, and the processor executes the at least one computer program to achieve:

[0038] The asset list generation method as described in any of the first aspect embodiments.

[0039] To achieve the above objectives, a fourth aspect of this disclosure also provides a computer-readable storage medium storing computer-executable instructions for causing a computer to perform:

[0040] The asset list generation method as described in any of the first aspect embodiments.

[0041] The first aspect of this application provides a method for generating an asset list. This method first obtains the compiled code package and asset element configuration parameters, then directly parses the code package to identify multiple asset elements and the calling relationships between them. Next, it uses the asset element configuration parameters and calling relationships to identify the asset relationships between the multiple asset elements. Finally, it generates an asset list based on the multiple asset elements and their relationships. Compared to the current mainstream approach of manually identifying asset elements and manually filling them into an Excel file, this method can directly use a parsing tool to parse the compiled code to generate the asset list from scratch. This allows for the identification of new asset elements that appear in each development iteration of the code, and the inclusion of these asset elements and their relationships in the asset list. This greatly reduces the cost of manual maintenance and improves the efficiency of asset list iteration updates. It also avoids data loss or errors caused by human error.

[0042] It is understood that the beneficial effects of the second to fourth aspects compared with the related technologies are the same as the beneficial effects of the first aspect compared with the related technologies. Please refer to the relevant description in the first aspect above, which will not be repeated here. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a flowchart illustrating an asset list generation method provided in one embodiment of this application;

[0045] Figure 2 This is a schematic diagram of an asset element configuration parameter provided in one embodiment of this application;

[0046] Figure 3 yes Figure 1 A flowchart illustrating the specific method of step S200;

[0047] Figure 4 yes Figure 1 A flowchart illustrating the specific method of step S300;

[0048] Figure 5 yes Figure 1 A flowchart illustrating the specific method of step S400;

[0049] Figure 6 yes Figure 5 A flowchart illustrating the specific method of step S402;

[0050] Figure 7 This is a block diagram of an asset inventory generation apparatus provided in one embodiment of this application;

[0051] Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0053] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0054] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0055] First, let's analyze some of the terms used in this application:

[0056] Artificial Intelligence (AI) is a new branch of computer science that studies, develops, and applies theories, methods, technologies, and systems to simulate, extend, and expand human intelligence. It aims to understand the essence of intelligence and produce intelligent machines that can react in a way similar to human intelligence. Research in this field includes robotics, speech recognition, image recognition, natural language processing, and expert systems. AI can simulate the information processes of human consciousness and thought. Furthermore, AI utilizes digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceiving the environment, acquiring knowledge, and using that knowledge to achieve optimal results.

[0057] Object-Oriented Analysis and Design (OOAD) is an effective technique widely adopted by modern software companies. OOAD requires mapping objects and entities from a specified problem domain in the real world to the design, such as customers, cars, and salespeople. This necessitates that the design closely resemble the real world, representing entities in the most natural way. Therefore, the advantage of object-oriented technology lies in its ability to construct problem models that correspond to the real world, preserving their structure, relationships, and behaviors as patterns.

[0058] DDD (Domain Driven Design): DDD is a good idea for business refactoring. When writing code, first write the domain service layer (domain layer), define the interface in the domain layer, implement the interface in the infrastructure layer, and simply orchestrate the interface in the application service layer.

[0059] As OOAD software becomes increasingly complex, it's common to see massive amounts of business logic crammed into a single giant class, compromising code reusability and extensibility. To address this, Domain-Driven Design (DDD) introduced a clear layered architecture and the concept of domain objects, ushering in a new era for object-oriented analysis and design, significantly advancing enterprise software development. Implementing DDD generally involves three stages: business analysis, strategic design, and tactical design. The outputs of each stage serve as inputs for the next. The business analysis stage outputs business events, business logic, and business classifications described in a unified language to the strategic design stage. Conversely, the strategic design stage provides the domain model and boundary context to the tactical design stage, facilitating microservice decomposition and model mapping. Each stage is detailed below:

[0060] Business Analysis: At this stage, it is necessary to gather the project team members, including domain experts, designers, and developers, to comprehensively sort out the business problem domain and business expectations, clarify the unified language in the business, discover domain events, domain objects and their corresponding domain behaviors in the business domain, and understand their respective relationships.

[0061] Strategic Design: Using Domain-Driven Design (DDD) theory, business domains are divided and domain models are constructed. Corresponding bounded contexts are identified, and a unified domain language is used to perform domain division and model construction at the strategic level. During the construction of the domain model, the corresponding aggregates, entities, and value objects need to be identified.

[0062] Tactical Design: Using the domain model as input for tactical design, and the bounded context as the boundary for microservice partitioning, microservices are split. Domain layering is performed in each microservice to realize the mapping of the domain model to the code, thereby realizing the true implementation of DDD.

[0063] The asset inventory is primarily introduced as a metric for measuring the effectiveness of DDD (Domain-Driven Development) implementation. It defines four layers of elements: business elements, functional elements, business processes, and business scenarios. Business elements are business objects within the domain; functional elements are the functions provided by these domain objects; business processes are complete business interaction flows; and business scenarios are the scenario services provided externally. These four layers are called layer by layer, creating relationships between them. By observing the degree of reuse of core functions in different scenarios, we can see the rate of core domain decay and the responsiveness to business changes. Therefore, the asset inventory can demonstrate the quality of DDD domain construction. Simultaneously, the four layers of the asset inventory, when implemented at the code level, correspond to the aggregate root entity class, domain service layer methods, application service layer methods, and interface service layer methods.

[0064] The channel middle platform, or middle platform technical framework, is the technical support for the implementation of the channel middle platform. Its core is a framework that includes a capability model, a configuration model, and configuration data to support various configuration implementations. The middle platform technical framework achieves self-interpretation of configurations through extension points, and establishes the relationship and scope of application and configuration by utilizing business identities and horizontal / vertical overlays, effectively solving the development and maintenance problems of complex businesses.

[0065] The BCEL (Byte Code Engineering Library) is part of the Apache Software Foundation's Jakarta project. BCEL is one of the most widely used frameworks for Java class working, allowing for in-depth manipulation of class details within the JVM assembly language. BCEL differs from Javassist in its approach to bytecode processing; BCEL operates at the actual JVM instruction level (BCEL has rich JVM instruction-level support), while Javassist emphasizes source code-level work.

[0066] As software becomes increasingly complex, it's common in real-world development to see massive amounts of business logic crammed into a single giant class, compromising code reusability and extensibility. To address this issue, Domain-Driven Design (DDD) introduced clear layered architecture and the concept of domain objects, ushering in a new era of object-oriented analysis and design and significantly advancing enterprise software development.

[0067] With the rise of Domain-Driven Design (DDD), the effectiveness of DDD architecture methodologies needs to be measured by data, and this data will be continuously updated with iterative evolution. Addressing the lack of a standardized measurement method for DDD implementation effectiveness, the channel platform proposed the concept of an asset inventory. The asset inventory defines four layers of elements: business elements, functional elements, business processes, and business scenarios. Business elements are business objects within the domain; functional elements are the functions provided by these domain objects; business processes are a complete business interaction flow; and business scenarios are the scenario services provided externally. These four layers are called layer by layer, creating relationships between them. By observing the degree of reuse of core functions in different scenarios, we can see the rate of decay of the core domain and the responsiveness to business changes. Therefore, the asset inventory can demonstrate the effectiveness of DDD domain construction.

[0068] Currently, calculating the asset inventory requires identifying the asset elements in the domain construction, the relationships between these elements, and determining the number of reused domain service elements based on these relationships. However, updating the asset inventory is a time-consuming and labor-intensive process. Currently, asset elements are identified manually and entered into an Excel file, which is not only time-consuming and labor-intensive but also prone to errors. Therefore, a tool for updating and maintaining the asset inventory is needed.

[0069] Based on this, the present disclosure provides an asset list generation method, apparatus, device, and storage medium, which can greatly reduce the cost of manual maintenance, improve the efficiency of asset list iteration and updating, and also avoid data loss or incorrect data caused by human error.

[0070] This application provides an asset list generation method, apparatus, device, and storage medium, which are specifically described through the following embodiments. First, the asset list generation method in the embodiments of this disclosure is described.

[0071] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0072] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0073] The asset inventory generation method provided in this application relates to the field of artificial intelligence technology, and particularly to the field of software design technology. The asset inventory generation method provided in this application can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, or smartwatch, etc.; the server can be an independent server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms; the software can be an application implementing the asset inventory generation method, but is not limited to the above forms.

[0074] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0075] Firstly, please refer to Figure 1 , Figure 1 This application provides an asset list generation method according to one embodiment. The asset list generation method includes steps S100, S200, S300, and S400. It should be understood that the asset list generation method of this application embodiment includes, but is not limited to, steps S100 to S400. The following describes the method in conjunction with… Figure 1 These four steps will be explained in detail.

[0076] Step S100: Obtain the code package and asset element configuration parameters. The code package includes the compiled code, which conforms to the DDD architecture specification.

[0077] Specifically, in step S100 of this embodiment, the code package includes compiled code. To conform to the asset inventory generation of the DDD project, the code in the code package needs to comply with the DDD architecture specification. After the code is generated, it is compiled to form the compiled code package. It should be noted that this application does not impose specific restrictions on the code generation process and its specific form.

[0078] Asset element configuration parameters are pre-configured by the user and serve as the basis for identifying asset elements. Since the structure of each project's code design may differ, without configuring asset element configuration parameters, it's impossible to know the location of each type of element. Therefore, in step S100 of this embodiment, the asset element configuration parameters primarily assist in identifying the various element lists in the code (i.e., identifying the type and location of the asset elements), thereby further utilizing the various asset element lists in the code to clarify the asset relationships between asset elements at each level.

[0079] In step S100 of some embodiments, the code in the code package includes four types of asset elements: business elements, functional elements, business processes, and business scenarios; the asset element configuration parameters configure the package names of the four layers of asset elements. The asset element list of the four types of asset elements can be identified based on the package names of the four layers of asset elements.

[0080] like Figure 2 As shown, an asset element configuration parameter is provided:

[0081] The Adapter package name is the package name of the element corresponding to the business scenario.

[0082] The package names APP-API and APP-Impl correspond to the package names of the business process elements;

[0083] The Domain-Service package name corresponds to the package name of the functional element;

[0084] The package names Aggregate, Entity, ValObj, and Event serve two purposes: classes under these package names act as business elements, and methods act as functional elements. It is important to note that the package names Adapter, APP-API, APP-Impl, Domain-Service, Aggregate, Entity, ValObj, and Event all support regular expressions, and multiple packages should be separated by commas.

[0085] The "Ignore Keyword Name" configuration option specifies classes or methods within these packages. If you do not want them to be recognized as asset listing elements, you can configure the "Ignore Keyword" option. Classes or methods that match the "Ignore Keyword" option will no longer appear as asset elements in the asset listing file. Note that multiple keywords in the "Ignore Keyword Name" option should be separated by commas.

[0086] Domains and systems are project divisions within the channel platform, similar to a categorization function.

[0087] Asset element configuration parameters are the basis for identifying asset elements. These parameters include the package names of the asset elements pre-configured by the user; that is, a code package contains multiple packages, each with a corresponding package name. Then, by matching the package names, a list of various asset elements (i.e., the category to which the asset element belongs) can be identified.

[0088] The code structure includes: a package contains multiple Java classes, and each Java class contains multiple methods. Asset elements are represented in the code as either a class or a method. Based on the package name where the asset element is located, the class and method within that package can be identified as belonging to a specific asset element category. It's important to note that Java is an object-oriented programming language; besides primitive data types, Java requires that every data type must be a class. Methods include class methods and object methods. Class methods are also called static methods, while object methods are also called instance methods (non-static methods). Accessing an object method requires the existence of an object; accessing a class method does not require an object and is directly accessible.

[0089] For example, if there is a package named com.test.controller, and a class named TestController is contained in the package, and the TestController class has two methods, method1 and method2, then we can configure the package name of the business scenario as com.test.controller. By comparing the configured package name with the package name in the code, we can identify the two business scenario elements, method1 and method2.

[0090] Step S200: Parse the code package to identify multiple asset elements in the code and determine the calling relationships between the multiple asset elements.

[0091] The code includes four types of asset elements: business elements, functional elements, business processes, and business scenarios. In step S200 of this embodiment, the compiled code package is parsed by a parsing tool. After parsing the compiled code package, the parsing tool can identify the compiled code in the code package, and further identify the four types of asset elements (business elements, functional elements, business processes, and business scenarios) in the compiled code. It can also identify the calling relationships between multiple asset elements.

[0092] In step S200 of some embodiments, the code package can be parsed using parsing tools such as Javassist and BCEL.

[0093] Reference Figure 3 In step S200 of some embodiments, the parsing tool uses the BCEL library. The code package is parsed to identify multiple asset elements within the code and to determine the calling relationships between these asset elements. This is specifically achieved through the following steps:

[0094] Step S201: Obtain the BCEL library.

[0095] Step S202: Input the code package into the BCEL library so that the BCEL library can parse the code in the code package and obtain multiple asset elements and the calling relationships between the multiple asset elements.

[0096] The BCEL library is one of the most widely used libraries for Java class working, allowing for in-depth manipulation of class details within the JVM assembly language. BCEL and Javassist employ different bytecode processing methods: BCEL operates at the actual JVM instruction level (BCEL boasts rich JVM instruction-level support), while Javassist emphasizes source code-level work.

[0097] First, in step S201, the BCEL library to be used is obtained. Then, in step S202, the code package is loaded into the BCEL library. The code in the code package is directly parsed using the BCEL library. The BCEL library can easily parse out which packages, classes, and methods are in the code (asset elements are represented as classes and methods in the code).

[0098] Here is a set of examples:

[0099] A code package is named TestClass.class, located at "D:\\codepackage\\TestClass.class", and its absolute path is stored in the string targetClassfile. The implementation code for loading this code package is as follows:

[0100] String targetClassfile = "D:\\code package\\TestClass.class";

[0101] The BCEL library's ClassParser is used to parse the loaded code package in order to obtain information such as class file names, constant pools, and methods. The relevant implementation code is as follows:

[0102] JavaClass jc=new ClassParser(targetClassfile).parse();

[0103] The parsed class file object (jc) is wrapped and transformed into an object of the ClassGen class from the BCEL library, so that methods of the ClassGen class can be called to obtain relevant information about the class file. The relevant implementation code is as follows:

[0104] ClassGen cg = new ClassGen(jc); cg is the converted Java class file object;

[0105] The class name file is obtained through the cg object, and the class name file is obtained by calling the getClassName() method of the ClassGen class:

[0106] String cname=cg.getClassName();

[0107] Methods in a class are accessed through a `jc` object. The code to retrieve all methods in a class from a `jc` object is as follows:

[0108] Method[]methods=jc.getMethods().

[0109] Compared to the current mainstream approach of manually identifying asset elements and filling them into Excel files, scanning code packages using the BCEL library is more reliable and can avoid human error.

[0110] Step S300: Identify the asset relationships between multiple asset elements based on the asset element configuration parameters and calling relationships.

[0111] Reference Figure 4 In step S300 of some embodiments, the asset relationships between multiple asset elements are identified based on the asset element configuration parameters and calling relationships. This is specifically achieved through the following steps:

[0112] Step S301: Identify the category of each asset element in the code based on the package name of the configured asset element.

[0113] Step S302: Identify the asset relationships between multiple asset elements based on the category and calling relationship of each asset element.

[0114] In step S301 of this embodiment, the package name of the configured asset element is compared with the package name of the code to identify the category to which the corresponding asset element belongs.

[0115] In step S302 of this embodiment, there is a calling relationship between the asset elements in the code. For example, the first method in the first code calls the first method in the second code, and the second method in the first code calls the second method in the second code. Both the first and second methods in the first code belong to business scenario elements, and both the first and second methods in the second code belong to business process elements. Therefore, there is an asset relationship between the first method in the first code and the first method in the second code; there is also an asset relationship between the second method in the first code and the second method in the second code.

[0116] Here is a set of examples:

[0117] (1) Identify the category of the asset element in the code by the package name of the configured asset element: There is a package name com.test.controller, and there is a class TestController in the package com.test.controller. The TestController class has two methods, method1 and method2. The package name of the configured business scenario is com.test.controller. By comparing the configured package name with the package name of the code, the two business scenario elements method1 and method2 can be identified.

[0118] (2) Identify asset relationships between multiple asset elements based on their category and calling relationships: First, there is a package named com.test.service. This package contains a class named TestService, which has two methods: method3 and method4. The package name for configuring the business process is com.test.service. By comparing the configured package name with the package name in the code, we can identify the two business scenario elements, method3 and method4. Then, there are calling relationships between the methods in the code. For example, method1 calls method3, and method2 calls method4. Correspondingly, we can see that there is an asset relationship between the business scenario element method1 and the business process element method3, and another asset relationship between the business scenario element method2 and the business process element method4.

[0119] Step S400: Generate an asset list based on multiple asset elements and asset relationships.

[0120] Reference Figure 5 In some embodiments, S400 generates an asset list based on multiple asset elements and asset relationships, specifically including the following steps:

[0121] Step S401: Calculate the reused asset elements based on asset relationships.

[0122] The asset list mainly consists of asset elements, relationships between various asset elements, reused asset elements, and reuse rates. There are many asset elements in the code; for example, a package may contain multiple Java classes, and a Java class may contain multiple methods. As mentioned above, there are asset relationships between methods (e.g., there is an asset relationship between business scenario element method1 and business process element method3, and an asset relationship between business scenario element method2 and business process element method4). Therefore, in step S401 of this embodiment, reused asset elements are calculated based on the asset relationships between multiple asset elements. Here, reused asset elements refer to asset elements with two or more asset relationships, such as functional elements called by two or more business scenarios.

[0123] In step S401 of some embodiments, the reused asset elements are calculated based on the asset relationships between multiple asset elements, specifically including the following steps:

[0124] Step S4011: Based on the asset relationships between asset elements, determine the functional elements that are called by multiple business scenarios as reusable asset elements.

[0125] For example: find functional elements that are called by two or more business scenarios based on asset relationships.

[0126] Step S402: Calculate the reuse rate of asset elements based on the number of reused asset elements and the number of multiple asset elements.

[0127] The reuse rate refers to the probability of a reused asset element. Therefore, after finding the number of reused asset elements in step S401 of this embodiment, the reuse rate of asset elements can be obtained by using the ratio between the number of reused asset elements and the total number of asset elements.

[0128] Reference Figure 6 In step S402 of some embodiments, calculating the reuse rate of asset elements based on the number of reused asset elements and the number of multiple asset elements specifically includes the following steps:

[0129] Step S4021: Count the first number of functional elements called by multiple business scenarios.

[0130] Step S4022: Count the second number of functional elements among multiple asset elements.

[0131] Step S4023: Calculate the reuse rate of functional elements based on the first quantity and the second quantity.

[0132] In step S402 of this embodiment, the reuse rate of asset elements refers to the reuse rate of functional elements. After the reused functional elements are determined in step S4011, the corresponding quantity of reused functional elements (i.e., the first quantity) is counted in step S4021. Then, the quantity of all functional elements in the code package (i.e., the second quantity) is counted in step S4022. Finally, the ratio of the first quantity to the second quantity is calculated in step S4023 (by performing a division operation) to obtain the reuse rate of functional elements.

[0133] Currently, the asset inventory serves as a benchmark for measuring the effectiveness of DDD (Data Dependency Injection). The asset inventory is constantly updated as the code evolves. New asset elements and relationships between them may emerge during each development iteration, and these changes need to be reflected in the asset inventory. Updating the asset inventory is a time-consuming and labor-intensive process. Currently, asset elements are mainly identified manually and entered into an Excel file. For example, the number of classes and methods in the code, which are asset elements, and the relationships between them are all identified manually by reading the code. This is not only time-consuming and labor-intensive, but manual maintenance is also prone to errors. In this method embodiment, the compiled code package and asset element configuration parameters are first obtained. Then, the code package is directly parsed to identify multiple asset elements and the calling relationships between them. Next, the asset element configuration parameters and calling relationships are used to identify the asset relationships between the multiple asset elements. Finally, an asset list is generated based on the multiple asset elements and their relationships. This method can directly generate an asset list by parsing the compiled code through the BCEL library, so as to identify new asset elements that appear in each development iteration of the code and reflect these asset elements and their relationships in the asset list. This greatly reduces the cost of manual maintenance, improves the efficiency of asset list iteration and update, and can also avoid data loss or incorrect data caused by human error.

[0134] Please refer to Figure 7 , Figure 7 This is a block diagram of an asset inventory generation apparatus provided in some embodiments of this application. In some embodiments, the asset inventory generation apparatus 1000 includes a code package acquisition unit 1100, a code package parsing unit 1200, an asset relationship identification unit 1300, and an asset inventory generation unit 1400, wherein:

[0135] The code package acquisition unit 1100 is used to acquire code packages and asset element configuration parameters. The code package includes compiled code that conforms to the DDD architecture specification.

[0136] The code package parsing unit 1200 is used to parse the code package to identify multiple asset elements in the code and determine the calling relationships between the multiple asset elements.

[0137] The asset relationship identification unit 1300 is used to identify the asset relationship between multiple asset elements based on the asset element configuration parameters and calling relationships.

[0138] The asset list generation unit 1400 is used to generate an asset list based on multiple asset elements and asset relationships.

[0139] Currently, the asset inventory serves as a benchmark for measuring the effectiveness of DDD (Data-Driven Design). The asset inventory is continuously updated as the code iterates. New asset elements and relationships may emerge during each development iteration, and these changes need to be reflected in the asset inventory. Updating the asset inventory is a time-consuming and labor-intensive process. Currently, asset elements are manually identified and entered into an Excel file. For example, the number of classes and methods in the code, which are asset elements, and the relationships between them are all determined by manually reading the code. This is not only time-consuming and labor-intensive, but also prone to errors. The asset inventory generation device of this application first obtains the compiled code package and asset element configuration parameters through the code package acquisition unit 1100. Then, the code package parsing unit 1200 directly parses the code package to identify multiple asset elements and their calling relationships. Next, the asset relationship identification unit 1300 uses the asset element configuration parameters and calling relationships to identify the asset relationships between multiple asset elements. Finally, the asset inventory generation unit 1400 generates an asset inventory based on the multiple asset elements and their relationships. This asset list generation device can directly use BCEL to parse and compile code to generate an asset list in reverse. It can identify new asset elements that appear in each development iteration of the code and reflect these asset elements and their relationships in the asset list, which greatly reduces the cost of manual maintenance, improves the efficiency of asset list iteration and update, and can also avoid data loss or errors caused by human error.

[0140] It should be noted that the asset list generation device of this application embodiment and the aforementioned asset list generation method are based on the same inventive concept. Therefore, the asset list generation device of this application embodiment corresponds to the aforementioned asset list generation method. For the specific implementation process, please refer to the aforementioned asset list generation method, which will not be repeated here.

[0141] This application also provides an electronic device, which includes:

[0142] At least one memory;

[0143] At least one processor;

[0144] At least one program;

[0145] The program is stored in memory, and the processor executes at least one program to implement the asset list generation method described above in this disclosure.

[0146] This electronic device can be any smart terminal, including mobile phones, tablets, personal digital assistants (PDAs), and in-vehicle computers.

[0147] The electronic device in this application embodiment is used to execute the above-described asset list generation method. First, it obtains the compiled code package and asset element configuration parameters. Then, it directly parses the code package to identify multiple asset elements and the calling relationships between them. Next, it uses the asset element configuration parameters and calling relationships to identify the asset relationships between the multiple asset elements. Finally, it generates an asset list based on the multiple asset elements and their relationships. This asset list generation device can directly use the BCEL library to parse the compiled code and reverse-generate the asset list to identify new asset elements that appear in each development iteration of the code and reflect these asset elements and their relationships in the asset list. This greatly reduces the cost of manual maintenance, improves the efficiency of asset list iteration and updates, and can also avoid data loss or errors caused by human error.

[0148] The following is combined with Figure 8 The electronic devices described in the embodiments of this application will be described in detail.

[0149] like Figure 8 , Figure 8 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0150] The processor 1600 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this disclosure.

[0151] The memory 1700 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1700 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1700 and is called and executed by the processor 1600 to execute the asset inventory generation method of the embodiments of this disclosure.

[0152] The input / output interface 1800 is used to implement information input and output.

[0153] The communication interface 1900 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0154] Bus 2000 transmits information between various components of the device (e.g., processor 1600, memory 1700, input / output interface 1800, and communication interface 1900);

[0155] The processor 1600, memory 1700, input / output interface 1800 and communication interface 1900 are connected to each other within the device via bus 2000.

[0156] This disclosure also provides a storage medium, which is a computer-readable storage medium storing computer-executable instructions for causing a computer to perform the above-described asset list generation method.

[0157] The storage medium of this application embodiment is used to execute the above-described asset list generation method. First, it obtains the compiled code package and asset element configuration parameters. Then, it directly parses the code package to identify multiple asset elements and the calling relationships between them. Next, it uses the asset element configuration parameters and calling relationships to identify the asset relationships between the multiple asset elements. Finally, it generates an asset list based on the multiple asset elements and their relationships. This asset list generation device can directly use the BCEL library to parse the compiled code to generate an asset list in reverse, so as to identify new asset elements that appear in each development iteration of the code and reflect these asset elements and their relationships in the asset list. This greatly reduces the cost of manual maintenance, improves the efficiency of asset list iteration and updates, and can also avoid data loss or errors caused by human error.

[0158] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0159] The embodiments described in this disclosure are for the purpose of more clearly illustrating the technical solutions of this disclosure and do not constitute a limitation on the technical solutions provided by this disclosure. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by this disclosure are also applicable to similar technical problems.

[0160] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this disclosure, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0161] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0162] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0163] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification 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. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover 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.

[0164] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

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

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

[0167] 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 as a software functional unit.

[0168] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0169] The above is a detailed description of the preferred embodiments of this application. However, the embodiments of this application are not limited to the above-described implementation methods. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the embodiments of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of the embodiments of this application.

Claims

1. A method for generating an asset list, characterized in that, The method for generating the asset list includes: Obtain the code package and asset element configuration parameters, wherein the code package includes compiled code that conforms to the DDD architecture specification; Parsing the code package to identify multiple asset elements within the code and determining the calling relationships between the multiple asset elements; the parsing of the code package to identify multiple asset elements within the code and determining the calling relationships between the multiple asset elements includes: Obtain the BCEL library; The code package is input into the BCEL library so that the BCEL library parses the code in the code package to obtain multiple asset elements in the code and the calling relationships between the multiple asset elements; Based on the asset element configuration parameters and the invocation relationship, identify the asset relationship between multiple asset elements; An asset list is generated based on the multiple asset elements and the asset relationships; the generation of the asset list based on the multiple asset elements and the asset relationships includes: Based on the asset relationships, calculate the reused asset elements; The reuse rate of the asset element is calculated based on the number of reused asset elements and the number of multiple asset elements. An asset list is generated using the multiple asset elements, the asset relationships, the reused asset elements, and the reuse rate.

2. The asset list generation method according to claim 1, characterized in that, The asset element configuration parameters include the package name of the configured asset element; identifying the asset relationship between multiple asset elements based on the asset element configuration parameters and the invocation relationship includes: Based on the package name of the configured asset element, identify the category to which each asset element in the code belongs; Based on the category to which each asset element belongs and the calling relationship, identify the asset relationships between multiple asset elements.

3. The asset list generation method according to any one of claims 1 to 2, characterized in that, The asset elements include classes and methods; the calling relationships between the multiple asset elements include calling relationships between multiple methods and calling relationships between multiple classes.

4. The asset list generation method according to claim 1, characterized in that, The step of calculating the reused asset elements based on the asset relationships includes: Based on the asset relationships between the asset elements, functional elements that are called by multiple business scenarios are identified as the reused asset elements.

5. The asset list generation method according to claim 4, characterized in that, The reuse rate of the asset element is the reuse rate of the functional element; calculating the reuse rate of the asset element based on the number of reused asset elements and the number of multiple asset elements includes: Count the first number of the functional elements that are called by multiple business scenarios; Count the second number of the functional elements among the multiple asset elements; The reuse rate of the functional element is calculated based on the first quantity and the second quantity.

6. An asset list generation device, characterized in that, The asset list generation device includes: The code package acquisition unit is used to acquire code packages and asset element configuration parameters. The code package includes compiled code that conforms to the DDD architecture specification. A code package parsing unit is used to parse the code package to identify multiple asset elements in the code and determine the calling relationships between the multiple asset elements; the parsing of the code package to identify multiple asset elements in the code and determine the calling relationships between the multiple asset elements includes: Obtain the BCEL library; The code package is input into the BCEL library so that the BCEL library parses the code in the code package to obtain multiple asset elements in the code and the calling relationships between the multiple asset elements; An asset relationship identification unit is used to identify the asset relationship between multiple asset elements based on the asset element configuration parameters and the calling relationship; An asset list generation unit is configured to generate an asset list based on the plurality of asset elements and the asset relationships; the generation of the asset list based on the plurality of asset elements and the asset relationships includes: Based on the asset relationships, calculate the reused asset elements; The reuse rate of the asset element is calculated based on the number of reused asset elements and the number of multiple asset elements. An asset list is generated using the multiple asset elements, the asset relationships, the reused asset elements, and the reuse rate.

7. An electronic device, characterized in that, include: At least one memory; At least one processor; At least one computer program; The computer program is stored in the memory, and the processor executes the at least one computer program to implement the asset list generation method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform: The asset list generation method as described in any one of claims 1 to 5 shall be implemented.

Images