Method and apparatus for automatically generating Python scripts based on recording user operations by CAX software

Abstract

The present invention relates to a method and apparatus for automatically generating Python scripts by recording user operations based on CAX software. A script processing engine is set between the GUI presentation layer and the core business logic layer to implement the function of translating CAX software user operations into Python scripts. The script engine processing includes an event-driven component, a script generator, and a rule metadata-driven component. The rule metadata-driven component implements the functions of reading, traversing, and querying the rule metadata information itself, and at the same time provides C++ and Python language access interfaces. The present invention designs a script processing engine that records high-level events and is tightly coupled. This engine can translate CAX software user operations into Python scripts. Moreover, in the process of implementing the translation from simple events to high-level events, hybrid programming of C++ and Python is used, and the core code for translation and recording is implemented using the Python language.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a method and device for automatically generating a Python script by recording user operations based on CAX software. Background Art

[0002] CAX is a general term for various technologies such as CAD (Computer Aided Design), CAM (Computer Aided Manufacturing), and CAE (Computer Aided Engineering). CAX actually integrates diversified computer-aided technologies to work in a composite and coordinated manner. Besides the work of the design department during product design, other departments can also intervene in advance without waiting for the previous operation to be completed before starting the next operation, shortening the development time. At the same time, in the early stage of product design, various factors in the product life cycle can be well considered, design errors and inaccuracies can be discovered in advance, corrected in a timely manner, and during the design process, multiple comparable design schemes can be continuously proposed according to market demands, thereby obtaining the optimal design results and benefits. At this time, CAX software users mainly perform computer simulations on the production and design processes through the software, and the simulation process includes links such as preprocessing, solving, postprocessing, optimization, and reporting. In order to find the optimal result, this simulation process may need to be executed multiple times repeatedly, consuming a large amount of time of CAX software users.

[0003] By executing the script obtained through recording, the operations of CAX software users can be simulated to directly control the CAX software, and this solution has been widely applied in various CAX software. The solution for recording scripts can be summarized as a software system integrating script recording, editing, and playback. At this time, the system can be abstracted into three core modules: a script generator, a script editor, and a script interpreter.

[0004] According to different implementation mechanisms, the script generator can be divided into two types: implemented by the CAX software itself (tight coupling) and implemented by a third-party software (loose coupling).

[0005] The loose coupling method mainly uses a hook program or is based on the open operating system interface to intercept the messages sent by the operating system to other applications, and then obtains the script through the parsing and translation of the intercepted messages. The message mechanism under the Windows operating system provides a means of communication between applications and between applications and the operating system. There are two types of message queues in the Windows system, one is the system message queue and the other is the application message queue. Applications interact with Windows users by processing or forwarding the messages in the application message queue. The Windows operating system monitors all input devices (such as mice and keyboards). When the user presses a key or moves the mouse, a "simple event" (generating a message) will be triggered. Windows first puts the input message into the system message queue and then copies the input message to the corresponding application queue. The message loop in the application retrieves each message from its message queue and sends it to the corresponding window function. By using a hook program or relying on the WinSocket protocol, it is possible to monitor the Windows message queue, thereby capturing the user's input. The recording of user operations can be achieved through steps such as monitoring, filtering, and translation.

[0006] The tight coupling method is directly implemented inside the CAX software, bypassing the limitations of the operating system, and can be further divided into two categories: recording simple events and recording advanced events. Inside the CAX software, in theory, all operations of users at the GUI presentation layer can be broken down into several simple events (mainly Qt events, such as: pressing the mouse button, releasing the mouse button, mouse movement, pressing the keyboard button, and releasing the keyboard button). A simple way to record user operations is to first record all simple events and their parameters when recording the script, and then merge the same events, which can ensure that the application enters the same state during playback. By translating these simple events into specific script language statements and recording them, the script recording function can be achieved.

[0007] Another implementation of tight coupling is the way of recording "high-level events". At this time, instead of simply recording simple events such as the user pressing and releasing the mouse button at a certain coordinate, a mapping from simple events triggered by the user in the GUI interface to high-level events should be completed. For example, a single "button activation" high-level event should be recorded so that the correct button can be activated during playback, regardless of its screen coordinates. Similarly, all mouse clicks and scrolling operations in the file dialog should be replaced by a single "select file" event, which takes the file name as a parameter. During playback, the script can specify the correct file without making any changes to the underlying file system. When recording the interaction with the spin button, a series of mouse clicks and keyboard inputs can be replaced by a single "set integer" event, which takes the value finally assigned to the integer as a parameter. A core process of recording high-level events is how to escape a series of simple events into a high-level event. Usually, this process needs to be implemented through the cooperation of three components: the Qt event translator, the widget event translator, and the event observer. Among them, the Qt event translator, as a top-level, global Qt event filter, is mounted to the Qt event handling loop. It filters each Qt event generated by the application, receives the recorded event signals from Qt widgets, and sends them to the corresponding event observer. The widget event translator is an abstract interface that realizes the conversion from simple events to high-level events through the translate event method. Its derived classes may be specific to a certain widget, such as ComboBoxEventTranslator; or it can represent a class of related widgets, such as AbstractSliderEventTranslator, which can convert the events of any widget derived from QAbstractSlider, including QDial, QScrollBar, and QSlider. The event observer is an abstract interface. Its instance will receive messages from the widget translator instance by configuring a certain Qt message slot, serialize the high-level events, and write them to the script file or system log file in a streaming manner.

[0008] Due to differences in user interface skins, platforms, hardware, and operating environments, the script recording function of the loose coupling implementation and the tight coupling implementation of recording simple events may fail when the recorded scripts are executed on different user computers and different operating systems. Both face the following deficiencies:

[0009] 1. Only recording user operations makes it difficult to record the results of user operations. This shortcoming is particularly prominent in loose-coupling implementations. Since the state changes of CAX software cannot be obtained through the message mechanism of the operating system (the state changes of CAX software itself will not be directly reflected by system messages or software messages), when performing script playback, the correctness of the execution results cannot be verified, or the intermediate state of CAX software cannot be obtained based on the user's operations as the input for the next user operation. The script cannot implement all the functions of CAX software, and its generality and flexibility are restricted.

[0010] 2. Differences in window managers between different platforms (even on the same platform due to user choices) may cause differences in the size and arrangement of windows between recording and playing back scripts. This may lead to script playback failures in certain specific situations.

[0011] 3. Due to the appearance of the user interface or platform-specific appearances, even if the size of the top-level window remains consistent, the size of widgets may vary significantly. For example, the width of a separator bar may differ by several pixels between two platforms. During the playback of a script where the user adjusts the size of a splitter, this may cause the mouse to "miss" the splitter, sending subsequent mouse movement events to adjacent controls instead of the splitter they belong to. In addition, differences in font size affect the size of menus, and internationalization can fundamentally change the size and layout of widgets.

[0012] 4. When recording typical user interactions with file dialogs, playback will include some combination of scroll bar movement and double-clicking as the user navigates through their file system. Unfortunately, this recording depends to a large extent on the content of the file system. Between recording and playback, almost any change in the file system content will cause the test to fail because the file names are in different positions relative to the mouse.

[0013] 5. If, due to a GUI interface upgrade, the CAX software replaces a spin button with a slider in the user interface, during playback, the user's interaction with the spin button will fail, even though both represent integers.

[0014] The above deficiencies will lead to playback failures or restricted script functionality.

[0015] For the tight-coupling method of recording advanced events, there are mainly the following two deficiencies:

[0016] 1. The script languages obtained by recording do not have universality. Script languages such as Tcl / Tk, APDL, and Scheme generated by recording software of Ansys Corporation are restricted by historical reasons and face problems such as few learning materials, high learning costs, and insufficient flexibility and generality.

[0017] 2. The implementation mechanism is not flexible enough, and users need to recompile for extension. In the existing implementation, the three components responsible for event translation are all implemented in C++. When users conduct secondary development and hope to record the operations of the functional modules, components, and plugins for user extension, they need to send the secondary development code to the original factory for compilation to obtain executable binary code. The system implementation is not flexible enough, and the intellectual property rights of secondary development users cannot be protected. Summary of the Invention

[0018] In view of the deficiencies of the prior art, the present invention proposes a method for automatically generating Python scripts by recording user operations based on CAX software. A script processing engine is set between the GUI presentation layer and the core business logic layer to implement the function of translating CAX software user operations into Python scripts. The script engine processing includes an event-driven component, a script generator, and a rule metadata-driven component. The rule metadata-driven component realizes the functions of reading, traversing, and querying the rule metadata information itself, and at the same time provides access interfaces for C++ and Python languages. The specific script translation method includes:

[0019] Step 1: Start the CAX software, and load the rule metadata from the XML file into the memory during the initialization process of the CAX software;

[0020] Step 2: The user triggers a Qt simple event through keyboard and mouse operations on the GUI presentation layer, and notifies the event-driven component through the response mechanism of the Qt simple event;

[0021] Step 3: The event-driven component stores the Qt simple event in the historical event queue, and determines whether the events in the historical event queue constitute a complete high-level event, that is, complete an action, according to the rule metadata information. If it is completed, clear the historical event queue and execute Step 4; otherwise, jump to Step 2;

[0022] Step 4: The event-driven component triggers a high-level event, and notifies the core business logic layer through the message mechanism to complete the business logic operation corresponding to the high-level event. Based on different types of high-level events, the communication between the event-driven component and the core business logic can be synchronous or asynchronous;

[0023] Step 5: The core business logic layer executes the business logic operation corresponding to the high-level event, and notifies the event-driven component through the message mechanism after the execution ends;

[0024] Step 6: The event-driven component judges the execution result of the core business logic layer. If the execution is successful, execute Step 7; otherwise, jump to Step 15, end the program execution, and exit abnormally;

[0025] Step 7: The event-driven component determines whether a script is being recorded. If so, proceed to Step 8; otherwise, jump to Step 14.

[0026] Step 8: The event-driven component reads rule metadata from memory, converts a high-level event into a trace item, and calls a macro defined in the C++ code to notify the script generator to start recording a trace item.

[0027] Step 9: The script generator initializes the trace item at the C++ end based on the received trace item information and calls the Python code.

[0028] Step 10: Instantiate a Python object based on the incoming trace item. The script generator instantiates a Python object corresponding to the user operation based on the incoming trace item information and the rule metadata information. This step is executed on the Python side.

[0029] Step 11: Record the Python statement for generating the trace item. The script generator calls the logging method of the Python object to append the trace item information to a cache list in the form of a Python statement. This step is executed on the Python side.

[0030] Step 12: The script generator obtains a reference to the Python object created in Step 10 at the C++ end and feeds it back to the event-driven component.

[0031] Step 13: The event-driven component obtains a reference to the Python object for subsequent business code use; usually, this reference is only used by the C++ code to determine whether the script generator has executed successfully.

[0032] Step 14: Determine whether the CAX program has ended. If so, proceed to Step 15; otherwise, jump to Step 2.

[0033] Step 15: End the execution of the CAX program and exit normally.

[0034] According to a preferred embodiment, the rule metadata information records the metadata information of each functional point of the CAX software. One piece of metadata is a rule, and the rule links the GUI presentation layer, the core business logic layer, the event-driven component, and the script generator together.

[0035] According to a preferred embodiment, the rules in step 3 include the implementation interface corresponding to the core business logic layer of a certain function point, the event-driven component calling the implementation interface with relevant attribute parameters and return values, the relevant text information and control logic that need to be presented on the GUI layer corresponding to a certain function point, and the relevant information required by the script generator when recording this function point.

[0036] An apparatus for automatically generating Python scripts by recording user operations based on CAX software. The apparatus includes a GUI presentation layer and core business logic. The apparatus further includes a script processing engine disposed between the GUI presentation layer and the core business logic. The script processing engine includes:

[0037] An event-driven component, configured to collect and filter user operations on the GUI presentation layer, convert simple events triggered on the GUI presentation layer into high-level events, i.e., action semantics, by reading rule metadata, and send the action semantics to the script generator;

[0038] A script generator, configured to read rule metadata, translate the action semantics into a set of script instructions, and implement the function of recording action semantics in the syntax of a specific programming language; that is, the function of recording scripts in different programming languages can be implemented through different script generators;

[0039] The script generator is further configured to implement semantic analysis and realize the automatic definition and invocation of variables;

[0040] A rule metadata-driven component, configured to record the metadata information of each function point of the CAX software, implement the functions of reading, traversing, and querying the rule metadata information itself, and provide C++ and Python language access interfaces.

[0041] The present invention aims to design a script processing engine that records high-level events and is tightly coupled. This engine can translate the user operations of CAX software into Python scripts. Moreover, in the process of implementing the translation from simple events to high-level events, hybrid programming of C++ and Python is used, and the core code for translation and recording is implemented in Python language.

[0042] Aiming at the deficiencies of the prior art, the beneficial effects of the present invention are as follows:

[0043] 1. It can record the user operations of CAX software and automatically generate Python scripts. By editing the recorded scripts, the repetitive work of users can be reduced. By adding statements such as conditions, branches, and loops to the Python scripts, the user operations can be extended and executed offline, improving the work efficiency of CAX users.

[0044] 2. The Python language reduces the learning cost for CAX software users. Currently, the Python language has a good user base. In this invention, the Python language is used to record user operations, and it is relatively easier for CAX software users to learn, understand, and edit the generated Python scripts compared to other scripting languages.

[0045] 3. Adopting a mixed programming model of C++ and Python, encoding the widget event translator and observer in Python language can facilitate the program update for CAX software developers. At the same time, secondary development users of CAX software can separately implement Python scripting language extensions for extended functions locally, improving the flexibility of secondary development. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is a diagram showing the relationship among the GUI presentation layer, the script processing engine, and the core business logic;

[0047] Figure 2 It is a schematic diagram of the event, semantics, and statement conversion process;

[0048] Figure 3 It is a flowchart of the Python script automatically generated by the CAX software proposed in this invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0049] To make the objectives, technical solutions, and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below in conjunction with the specific embodiments and with reference to the accompanying drawings. It should be understood that these descriptions are exemplary and are not intended to limit the scope of the present invention. In addition, in the following descriptions, the descriptions of well-known structures and technologies are omitted to avoid unnecessarily confusing the concepts of the present invention.

[0050] The following is a detailed description with reference to the accompanying drawings.

[0051] Figure 1 It is a diagram showing the relationship among the GUI presentation layer, the script processing engine, and the core business logic. The present invention proposes a method for automatically generating Python scripts based on recording user operations of CAX software. A script processing engine is set between the GUI presentation layer and the core business logic layer to implement the function of translating CAX software user operations into Python scripts, as Figure 1 shown. The script engine processing includes an event-driven component, a script generator, and a rule metadata-driven component. The rule metadata-driven component realizes the functions of reading, traversing, and querying the rule metadata information itself, and at the same time provides access interfaces for C++ and Python languages. Figure 2 It is a schematic diagram of the event, semantics, and statement conversion process. Figure 3This is the flowchart of the Python script automatically generated by the CAX software proposed by the present invention. Specifically, as shown in Figure 2 and Figure 3 shown below.

[0052] The specific method for translating the script includes:

[0053] Step 1: Start the CAX software, and load the rule metadata from the XML file into the memory during the initialization process of the CAX software; the XML file is stored in the installation directory of the CAX file and is part of the configuration file of the CAX software.

[0054] The rule metadata information records the metadata information of each function point of the CAX software. The function point is the business function that the CAX software itself needs to implement, such as the graphic definitions (cones, spheres, cubes, irregular graphics, etc.), graphic drawing, mesh import, mesh format conversion, operations, residual analysis, result display, etc. mentioned above. Usually, a CAX software may have dozens or even hundreds of function points. A metadata is a rule, and the rule links the GUI presentation layer, the core business logic layer, the event-driven components, and the script generator together.

[0055] Step 2: The user triggers a Qt simple event through keyboard and mouse operations on the GUI presentation layer, and notifies the event-driven components through the response mechanism of the Qt simple event.

[0056] Figure 2 This is the schematic diagram of the event, semantics, and statement conversion process. Figure 3 This is the flowchart of the Python script automatically generated by the CAX software proposed by the present invention. Specifically, as shown in Figure 2 and Figure 3 shown below.

[0057] Step 3: The event-driven component stores the Qt simple event in the historical event queue, and according to the rule metadata information, determines whether the events in the historical event queue constitute a complete high-level event, that is, complete an action. If it has been completed, clear the historical event queue and execute Step 4; otherwise, jump to Step 2.

[0058] The rule metadata here refers to the data information contained in the XML file loaded into the memory in Step 1. Taking the drawing of a cone as an example, it is necessary to specify the number of faces, height, side length, color and other attribute information of the cone. These attribute information need to be input by the user through multiple text boxes in the GUI interface, and multiple simple events will be generated when inputting. Only when all the attribute information is complete can a cone be drawn and a high-level event be generated. By reading the "rule metadata information", it is possible to know whether all the attribute information is complete and to judge when to generate a corresponding high-level event.

[0059] The rules in step 3 include the implementation interface corresponding to the core business logic layer of a certain function point, the event-driven component calling the implementation interface with relevant attribute parameters and return values, the relevant text information and control logic that a certain function point needs to display in the GUI layer, and the relevant information required by the script generator when recording this function point.

[0060] Any structured method can be used to record the rule information, such as an XML file.

[0061] Step 4: The event-driven component triggers a high-level event and notifies the core business logic layer through the message mechanism to complete the business logic operation corresponding to the high-level event. For example, when drawing a cone, based on different types of high-level events, the communication between the event-driven component and the core business logic can adopt synchronous or asynchronous methods.

[0062] Step 5: The core business logic layer executes the business logic operation corresponding to the high-level event and notifies the event-driven component through the message mechanism after the execution is completed.

[0063] The message mechanism is provided by the message system of the Windows or Linux operating system, or a third-party message middleware. CAX software on different platforms and different developers may choose different message mechanisms.

[0064] Step 6: The event-driven component judges the execution result of the core business logic layer. If the execution is successful, step 7 is executed; otherwise, it jumps to step 15, ends the program execution, and exits abnormally.

[0065] Step 8: The event-driven component judges whether a script is being recorded currently. If a script is being recorded, step 9 is continued; otherwise, it jumps to step 14.

[0066] Step 9: The event-driven component reads the rule metadata from the memory, converts a high-level event into a trace item, and calls the macro defined in the C++ code to notify the script generator to start recording a trace item; a trace item is an abstraction of a high-level event in the present invention and is reflected as a C++ object. This C++ object will ultimately be converted into a Python object.

[0067] Step 10: The script generator initializes the trace item at the C++ end according to the received trace item information and calls the Python code.

[0068] Step 11: Instantiate a Python object according to the incoming trace item. The script generator instantiates a Python object corresponding to this user operation according to the incoming trace item information and based on the rule metadata information. This step is executed at the Python end.

[0069] Step 11: Record the generated Python statements for the tracking item. The script generator calls the logging method of the Python object and appends the tracking item information to a cached list in the form of Python statements. This step is executed on the Python side.

[0070] Step 12: The script generator obtains a reference to the Python object created in Step 10 on the C++ side and feeds it back to the event-driven component.

[0071] Step 13: The event-driven component obtains a reference to the Python object for subsequent business code to use; usually, this reference is only used by C++ code to determine whether the script generator has executed successfully.

[0072] Step 14: Check whether the CAX program has finished execution. If it has, continue to Step 15; otherwise, jump to Step 2.

[0073] Step 15: End the execution of the CAX program and exit normally.

[0074] Regarding starting to record the script: During the user's use of the CAX software, if the user clicks the start recording button on the GUI presentation layer, the option to determine whether a script is being recorded in Step 7 is set to true.

[0075] Regarding ending the recording of the script: When the user clicks the stop recording button on the GUI presentation layer, the event-driven component obtains the data in the cached list described in Step 11 from the script generator, forms all the Python statements automatically generated for this recorded script, and presents them to the user in the form of a Python script.

[0076] The present invention also proposes a device for automatically generating Python scripts based on recording user operations in the CAX software. The device includes a GUI presentation layer and core business logic. The device also includes a script processing engine disposed between the GUI presentation layer and the core business logic. The script processing engine includes:

[0077] An event-driven component configured to collect and filter user operations on the GUI presentation layer, convert simple events triggered on the GUI presentation layer into high-level events, i.e., action semantics, by reading rule metadata, and send the action semantics to the script generator.

[0078] A script generator configured to read rule metadata, translate the action semantics into a set of script instructions, and implement the function of recording action semantics in the syntax of a specific programming language; that is, the function of recording scripts in different programming languages can be achieved through different script generators.

[0079] The script generator is also configured to implement semantic analysis and achieve automatic definition and invocation of variables.

[0080] The rule metadata-driven component is configured to record the metadata information of each functional point of the CAX software, implement the functions of reading, traversing, and querying the rule metadata information itself, and at the same time provide access interfaces in C++ and Python languages.

[0081] It should be noted that the above specific embodiments are exemplary. Those skilled in the art can come up with various solutions inspired by the disclosure of the present invention, and these solutions also belong to the disclosure scope of the present invention and fall within the protection scope of the present invention. Those skilled in the art should understand that the description and drawings of the present invention are illustrative and do not constitute a limitation on the claims. The protection scope of the present invention is defined by the claims and their equivalents.

Claims

1. Method for automatically generating Python script by recording user operations based on CAX software, characterized in that, a script processing engine is set between the GUI presentation layer and the core business logic layer to implement the function of translating CAX software user operations into Python scripts. The script processing engine includes an event-driven component, a script generator, and a rule metadata-driven component. The rule metadata-driven component realizes the functions of reading, traversing, and querying the rule metadata information itself, and at the same time provides C++ and Python language access interfaces. The specific script translation method includes: Step 1: Start the CAX software, and load the rule metadata from the XML file into the memory during the initialization process of the CAX software; Step 2: The user triggers a Qt simple event through keyboard and mouse operations on the GUI presentation layer, and notifies the event-driven component through the response mechanism of the Qt simple event; Step 3: The event-driven component stores the Qt simple event in the historical event queue, and judges whether the events in the historical event queue constitute a complete high-level event according to the rule metadata information, that is, complete an action. If it has been completed, clear the historical event queue and execute Step 4, otherwise jump to Step 2; Step 4: The event-driven component triggers a high-level event, and notifies the core business logic layer through the message mechanism to complete the business logic operation corresponding to the high-level event. Based on different types of high-level events, the communication between the event-driven component and the core business logic can adopt synchronous or asynchronous methods; Step 5: The core business logic layer executes the business logic operation corresponding to the high-level event, and notifies the event-driven component through the message mechanism after the execution is completed; Step 6: The event-driven component judges the execution result of the core business logic layer. If the execution is successful, execute Step 7, otherwise jump to Step 15, end the program execution, and exit abnormally; Step 7: The event-driven component judges whether a script is being recorded currently. If a script is being recorded, continue to execute Step 8, otherwise jump to Step 14; Step 8: The event-driven reads the rule metadata from the memory, converts a high-level event into a trace item, and calls the macro defined in the C++ code to notify the script generator to start recording a trace item; Step 9: The script generator initializes the trace item at the C++ end according to the received trace item information, and calls the Python code; Step 10: Instantiate a Python object according to the incoming trace item. The script generator instantiates a Python object corresponding to the user operation according to the incoming trace item information and the rule metadata information. This step is executed on the Python side; Step 11: Record the trace item to generate Python statements. The script generator calls the record log method of the Python object to append the trace item information to a cache list in the form of Python statements. This step is executed on the Python side; Step 12: The script generator obtains a reference to the Python object created in Step 10 at the C++ end and feeds it back to the event-driven component; Step 13: The event-driven component obtains a reference to the Python object for subsequent business code to use. The reference is only used by the C++ code to determine whether the script generator has executed successfully; Step 14: Check whether the CAX program has finished execution. If it has, continue to Step 15; otherwise, jump to Step 2; Step 15: End the execution of the CAX program and exit normally.

2. The method for automatically generating Python scripts as claimed in claim 1, wherein, the rule metadata information records the metadata information of each functional point of the CAX software. One metadata is a rule, and the rule links the GUI presentation layer, the core business logic layer, the event-driven component, and the script generator together.

3. The method for automatically generating Python scripts as claimed in claim 1, wherein, the rules in Step 3 include the implementation interface of the core business logic layer corresponding to a certain functional point, the relevant attribute parameters and return values when the event-driven component calls the implementation interface, the relevant text information and control logic to be presented on the GUI layer corresponding to a certain functional point, and the relevant information required by the script generator to record this functional point.

4. An apparatus for applying the method for automatically generating Python scripts based on recording user operations of CAX software as claimed in any one of claims 1 - 3. The apparatus includes a GUI presentation layer and a core business logic, wherein, the apparatus further includes a script processing engine disposed between the GUI presentation layer and the core business logic. The script processing engine includes: An event-driven component, configured to collect and filter user operations on the GUI presentation layer, convert simple events triggered on the GUI presentation layer into advanced events, i.e., action semantics, by reading the rule metadata, and send the action semantics to the script generator; A script generator, configured to read the rule metadata and translate the action semantics into a set of script instructions, realizing the function of recording action semantics in the syntax of a certain programming language; that is, the function of recording scripts in different programming languages can be realized through different script generators; The script generator is further configured to implement semantic analysis and realize the automatic definition and call of variables; A rule metadata-driven component, configured to record the metadata information of each functional point of the CAX software, realize the functions of reading, traversing, and querying the rule metadata information itself, and provide access interfaces for C++ and Python languages.

Images