UML (Unified Modeling Language) model-oriented event-driven behavior code automatic generation method and system
By using an event-driven behavior code automatic generation method for UML models, the problem of connecting UML models with executable code is solved, and the automatic conversion between activities and state machines is realized. This improves the executability and engineering implementation capability of UML models and is applicable to fields such as aerospace, industrial control and embedded systems.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHEJIANG UNIV
- Filing Date
- 2026-01-30
- Publication Date
- 2026-05-15
AI Technical Summary
Existing technologies struggle to directly link behavioral models such as activity diagrams and state machine diagrams with executable code within UML models, leading to inconsistencies between the model and implementation. This increases verification and maintenance costs, and existing tools are ill-suited to support the performance, maintainability, and deployment flexibility requirements of complex systems.
It adopts an event-driven behavior code automatic generation method based on UML model, constructs a document tree through DOM parsing, generates Java code, realizes automatic conversion of control flow, object flow and event response of activities and state machines, uses a unified semantic framework to generate the attributes and methods of the main class and related classes, supports automatic mapping of sequential, branching, parallel and loop structures, and introduces task dependency graph and StateMachineRunner runtime management class to realize hybrid event-driven execution.
It achieves semantic preservation and event-driven execution of UML behavioral models, improves engineering implementation capabilities, reduces the risk of human coding errors, supports rapid prototype verification and simulation verification of complex systems, and is applicable to fields such as aerospace, industrial control and embedded systems.
Smart Images
Figure CN122044697A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the technical field of software modeling and model-driven engineering (MDE), and relates to a method and system for automatically generating event-driven behavior code for Unified Modeling Language (UML) models. Background Technology
[0002] The Unified Modeling Language (UML), as a widely adopted standard modeling language in the current software engineering field, is extensively used in requirements analysis, architecture design, and system verification. Activity diagrams and state machine diagrams are core modeling tools in UML used to describe system behavior logic, control flow, and event response mechanisms. They are commonly used to represent business processes, protocol interactions, embedded control logic, and the operational state changes of complex reactive systems.
[0003] However, in current engineering practice, UML models are mainly used at the document and design levels, making it difficult to establish a direct connection with executable code. On the one hand, existing tools have relatively mature support for code generation of class diagrams, but for behavioral models such as activity diagrams and state machine diagrams, they often only provide static displays or simple simulation functions, lacking the ability to automatically generate code for engineering purposes. On the other hand, behavioral models contain complex semantics such as sequence, branching, looping, concurrency (Fork / Join), object flow, and event triggering. These semantics are prone to deviation during manual coding, leading to inconsistencies between the model and the implementation, and increasing verification and maintenance costs.
[0004] In fields such as embedded systems, industrial control, and aerospace, where reliability and verifiability are paramount, engineers generally desire to use UML behavioral models as a unified specification to automatically generate executable code for rapid prototyping and functional simulation. However, existing code generation solutions typically suffer from the following problems: First, activity diagrams are only roughly mapped to sequential function calls, failing to support precise control flow and concurrent execution. Second, object flows lack a unified data management mechanism, failing to guarantee consistency in data dependencies and execution conditions. Third, event-driven, signal-triggered, and time-based events in state machines are difficult to fully represent in automatically generated code, leading to simplification or even loss of event response mechanisms in the model during implementation.
[0005] Most existing model execution tools employ interpreted execution, which limits model size, execution efficiency, and engineering integration capabilities, making it difficult to meet the performance, maintainability, and deployment flexibility requirements of large-scale complex systems. Therefore, there is an urgent need for an automated code generation method and system capable of handling control flow, object flow, and event-driven semantics of UML behavioral models within a unified framework. This would achieve high-fidelity conversion from model to executable code, shorten development cycles, and enhance the model's applicability in engineering practice. Summary of the Invention
[0006] To address the aforementioned challenges of inconsistent models and code, difficulty in preserving behavioral semantics, and the challenge of automatically implementing event-driven mechanisms, this invention proposes a method and system for automatically generating event-driven behavioral code for UML models. Under a unified semantic framework, it models the control flow, object flow, state transitions, and event responses of activities and state machines, and automatically generates executable Java code, achieving semantic preservation and event-driven execution of the UML behavioral model. This method significantly improves the executability and engineering feasibility of UML behavioral models, and is applicable to fields such as aerospace, industrial control, and embedded systems, where high model consistency and rapid verification are required.
[0007] The technical solution adopted in this invention is as follows: An automatic event-driven behavior code generation method for UML models is proposed. It exports an XMI file containing classes, activities, and state machines from a UML modeling tool, constructs a document tree through DOM parsing, and extracts metamodel elements and their relationships. Based on the parsing results, it generates Java source code for the main class and related classes, including attributes, methods, and main methods. The main method of the main class serves as the simulation / running entry point, and the main methods of related classes are called at runtime. For classifier behavior types: when it is an Activity, it traverses from the InitialNode to identify the order, branching / merging, parallelism / synchronization, and looping, constructing a behavior control flow graph, decomposing the behavior into SimpleTask and LoopTask, and generating Java code containing the execute method and scheduling statements; when it is a StateMachine, it reconstructs the state transition graph and generates state machine instances and StateMachineRunner runtime management class instance code, enabling signal-driven and time-driven transition execution and mixed triggering with activities.
[0008] The method for automatically generating event-driven behavior code for UML models specifically includes the following steps: S1. Export the UML model XMI file containing classes, activities and state machines from the UML modeling tool, read the XMI through the DOM parser, construct the corresponding document tree structure, and extract DOM elements and their relationships from the document tree structure; S2. Generate the corresponding Java source code of the attributes and methods of the main class and its associated classes in the UML model based on the DOM elements and their relationships, and generate the main method in the main class and its associated classes. Use the main method of the main class as the simulation / run entry point. The main method of the main class calls the main method of the associated class at runtime. S3. Determine the classifier behavior type of the main class and its associated classes in the UML model; if the classifier behavior type is Activity, then the main method of the main class or associated class enters the activity code generation path; if the classifier behavior type is StateMachine, then the main method of the main class or associated class enters the state machine code generation path.
[0009] In the above technical solution, the activity code generation path is further defined as follows: starting from the InitialNode of the classifier behavior of the main method of the main class or associated class, traversal is performed to identify the activity sequence, branching / merging, parallelism / synchronization, and loops; a behavior control flow graph is constructed based on the identified activity sequence, branching / merging, parallelism / synchronization, and loops; based on the behavior control flow graph, the classifier behavior of the main method of the main class or associated class is decomposed into a series of SimpleTasks and LoopTasks, and the task dependencies of SimpleTasks and LoopTasks are extracted according to the sequence and synchronization relationships of the control structure, and a task dependency graph is constructed; Java source code containing the execute method and execution scheduling statements is generated according to the task dependency graph to achieve automatic mapping of activity sequence, branching, parallelism, and loop structures; the loop identification method is specifically defined as identifying the strongly connected components of the activity graph based on the Tarjan algorithm to obtain the loop region, and recording the entry, exit, and iteration path of each node in the loop; the SimpleTask is specifically defined as any task other than the LoopTask; the LoopTask is specifically defined as any task located within the loop structure.
[0010] Furthermore, based on the behavior control flow graph, the classifier behavior of the main method of the main class or associated class is decomposed into a series of SimpleTasks and LoopTasks. Specifically, the method is as follows: When encountering a combined structure consisting of Decision nodes and Merge nodes, the branch conditions and loop markers are used to determine whether the task path related to the structure is inside the loop. For task paths inside the loop, LoopTask subtasks are generated, and for task paths outside the loop, ordinary SimpleTasks are generated.
[0011] Furthermore, the method for extracting the task dependencies of SimpleTask and LoopTask based on the sequence and synchronization relationships of the control structure is as follows: When a Fork node is encountered, a new independent subtask path is created for each outgoing branch, and the dependency relationship between the starting task of the subtask path and the parent task before the Fork node is recorded. When a Join node is encountered, the dependencies between all tasks that end at the Join node and the tasks following the Join node are recorded.
[0012] Furthermore, the state machine code generation path specifically involves: for the classifier behavior of the main method of the main class or associated class, reconstructing the state transition graph based on DOM elements, and generating Java source code containing a state machine class instance and a StateMachineRunner runtime management class instance based on the state transition graph. The StateMachineRunner runtime management class instance is used to maintain the current state of the state machine, pending events, and synchronization locks. The state machine class instance executes the exit(), entry(), and doActivity() methods of the state sequentially by waiting for external signals or timed events, and supports starting activity execution within the exit(), entry(), and doActivity() methods of the state, achieving mixed event-driven execution of activities and the state machine. The pending events are specifically signal events or time events that determine the transition of the state machine from the current state to the next state. The synchronization lock is used to prevent other threads from concurrently modifying the state or events while the current thread is judging the current state of the state machine and deciding whether to wait for a trigger or retrieve a pending event, thereby avoiding race conditions.
[0013] This invention also provides an automatic event-driven behavior code generation system for UML models, used to execute the aforementioned automatic event-driven behavior code generation method for UML models. The system includes: Model parsing module: Used to export UML model XMI files containing classes, activities and state machines from UML modeling tools, read the XMI through the DOM parser, construct the corresponding document tree structure, and extract DOM elements and their relationships from the document tree structure; Class code generation module: used to generate the corresponding Java source code of the attributes and methods of the main class and its associated classes in the UML model based on the DOM elements and their relationships, and generate the main method in the main class and its associated classes. The main method of the main class is used as the simulation / run entry point. The main method of the main class calls the main method of the associated class at runtime. The behavior code generation module is used to determine the classifier behavior type of the main class and its associated classes in the UML model. If the classifier behavior type is Activity, the main method of the main class or associated class enters the activity code generation path; if the classifier behavior type is StateMachine, the main method of the main class or associated class enters the state machine code generation path.
[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention proposes an automatic event-driven behavior code generation method and system for UML models. Under a unified semantic framework, it integrates control flow, object flow, and event-driven mechanisms, enabling automatic conversion of activity and state machine UML models into executable Java code. This solves the technical problems of lost behavioral semantics, difficulty in preserving event response mechanisms, and challenges in achieving concurrent execution found in existing solutions. By introducing a scheduling mechanism based on task dependency graphs, this invention can accurately restore the execution semantics of concurrent structures such as Fork / Join; through mapping, it can maintain data dependencies and execution conditions in the object flow; and through the StateMachineRunner runtime management class execution framework, it can seamlessly support signal-driven and time-driven execution.
[0015] This invention boasts advantages such as strong semantic preservation, high automation, high execution efficiency, and convenient engineering integration. It provides a direct path from model to code for complex systems without altering UML modeling habits, significantly shortening development cycles and reducing the risk of human coding errors. The system supports outputting complete execution logs and a visual debugging interface, facilitating simulation verification and problem localization of behavioral logic. It significantly improves the executability and engineering feasibility of UML behavioral models, making it suitable for behavioral modeling and rapid prototyping in multiple fields such as aerospace, industrial control, embedded devices, and information systems. It has broad engineering application value and promising prospects for widespread adoption.
[0016] The Java code generated by the method of this invention has advantages such as strong runnability, consistent control and data semantics, and support for hybrid activity / state machine execution. It can be used for rapid prototyping of complex reactive systems, early software logic simulation, and automated execution of behavioral models. Attached Figure Description
[0017] Figure 1 This is a flowchart of a code generation method for a UML model that considers event-driven behavior in an embodiment of the present invention. Detailed Implementation
[0018] The technical solution of the invention will be further explained clearly and in detail below with reference to the accompanying drawings.
[0019] The event-driven behavior code automatic generation method for UML models provided in this invention relies on an event-driven behavior code automatic generation system for UML models, which includes a model parsing module, a class code generation module, and a behavior code generation module.
[0020] like Figure 1 As shown, this embodiment provides a method for automatically generating event-driven behavior code for UML models, specifically including the following steps: S1. The model parsing module exports a UML model XMI file containing classes, activities, and state machines from a UML modeling tool (such as MagicDraw, EA, etc.). It reads the XMI through a DOM parser, constructs the corresponding document tree structure, and extracts DOM elements such as Class, Activity, StateMachine, Transition, and ActionNode and their relationships (such as association relationships, relationships between source nodes and target nodes, and relationships between source states and target states) from the document tree structure. This provides a basic data structure for subsequent unified behavior extraction and code generation. S2. The class code generation module generates the corresponding Java source code of the attributes and methods of the main class and its associated classes in the UML model based on the DOM elements and their relationships, and generates the main method in the main class and its associated classes. The main method of the main class is used as the simulation / run entry point. The main method of the main class calls the main method of the associated class at runtime. S3. The behavior code generation module determines the classifier behavior type of the main class and its associated classes in the UML model; if the classifier behavior type is Activity, the main method of the main class or associated class enters the activity code generation path; if the classifier behavior type is StateMachine, the main method of the main class or associated class enters the state machine code generation path.
[0021] The specific activity code generation path is as follows: starting from the InitialNode of the classifier behavior of the main method of the main class or associated class, traverse to identify activity sequence, branching / merging, parallelism / synchronization, and loops; construct a behavior control flow graph based on the identified activity sequence, branching / merging, parallelism / synchronization, and loops; based on the behavior control flow graph, decompose the classifier behavior of the main method of the main class or associated class into a series of SimpleTasks and LoopTasks, and extract the task dependencies of SimpleTasks and LoopTasks according to the sequence and synchronization relationships of the control structure and construct a task dependency graph; generate Java source code containing the execute method and execution scheduling statements according to the task dependency graph to achieve automatic mapping of activity sequence, branching, parallelism, and loop structures; the loop identification method is as follows: based on the Tarjan algorithm, identify the strongly connected components of the activity graph to obtain the loop region, and record the entry, exit, and iteration path of each node in the loop; the SimpleTask is specifically a task other than the LoopTask; the LoopTask is specifically a task located within the loop structure.
[0022] The specific path for generating the state machine code is as follows: For the classifier behavior of the main method of the main class or related classes, a state transition graph is reconstructed based on DOM elements. Based on the state transition graph, Java source code containing a state machine class instance and a StateMachineRunner instance is generated. The StateMachineRunner instance maintains the current state of the state machine, pending events, and a synchronization lock. The state machine instance executes the `exit()`, `entry()`, and `doActivity()` methods of the state sequentially by waiting for external signals or timed events. It also supports starting activity execution within the `exit()`, `entry()`, and `doActivity()` methods of the state, achieving mixed event-driven execution of activities and the state machine. The pending events are specifically signal events or time events that determine the transition of the state machine from its current state to the next state. The synchronization lock prevents other threads from concurrently modifying the state or events while the current thread is judging the current state of the state machine and deciding whether to wait for a trigger or retrieve a pending event, thereby avoiding race conditions.
[0023] After generating the source code for an activity or state machine, the system automatically generates a user interface description for configuring initialization parameters and triggering signal events. The system generates a unified event entry point for all generated activities and state machines. For activity behaviors, different signal names are mapped to corresponding trigger methods; for state machine behaviors, signals are encapsulated as SignalEvent objects and forwarded to the StateMachineRunner instance. All generated Java source code files are automatically compiled to obtain the executable program.
[0024] In the activity code generation path, specifically, the system first uses InitialNode and input parameter node as the starting point for traversal, and performs a structure traversal of the activity graph in a depth-first manner. During the traversal, it identifies control structures such as sequence, branch / merge, parallel / synchronous and loop, and uses the Tarjan algorithm to identify strongly connected components and mark nodes and edges located in the loop structure to obtain loop marking information.
[0025] The behavior control flow graph-based decomposition of the classifier behavior of the main method of the main class or associated class into a series of SimpleTasks and LoopTasks is as follows: When encountering a combined structure consisting of Decision and Merge nodes, the system determines whether the task path associated with this structure is inside a loop based on the branch conditions and loop markers. For task paths inside the loop, it generates LoopTask subtasks; for task paths outside the loop, it generates ordinary SimpleTasks. Specifically, when processing a combined structure consisting of Decision and Merge nodes, the system uses the loop marker information to determine whether each outgoing edge of the Decision node is an inner edge of the loop. If only one outgoing edge of a Decision node is marked as an inner edge of the loop, and at least one outgoing edge is not marked as an inner edge of the loop (serving as a loop exit path), the system determines that the Decision-Merge combination corresponds to a loop control structure. The guard condition associated with the outgoing edge marked as an inner edge of the loop is identified as the control condition for the loop to continue execution, while the outgoing edge not marked as an inner edge of the loop corresponds to a loop exit branch. Based on this, the system encapsulates the task paths within the loop into a set of inner subtasks of LoopTask, while generating ordinary SimpleTasks for task paths outside the loop, so as to accurately restore the execution semantics of the loop during code generation.
[0026] The method for extracting the task dependencies of SimpleTask and LoopTask based on the sequence and synchronization relationships of the control structure is as follows: When a Fork node is encountered, the system creates an independent subtask path for each outgoing branch and records the dependency relationship between the starting task of the subtask path and the parent task before the Fork node. When a Join node is encountered, the system collects all the preceding branch tasks leading to that Join node and records the dependencies between all tasks ending at the Join node and the tasks following the Join node.
[0027] After completing the traversal of the activity structure and the division of local tasks, the system constructs a task dependency graph based on the parent-child relationship and dependency count information of SimpleTask and LoopTask.
[0028] Subsequently, an instance of the ActivityRunner class is automatically generated for each Activity. All task objects are registered uniformly within this class, and a suitable data structure is established based on task dependencies to schedule task execution in the order of dependencies at runtime.
[0029] ActivityRunner provides the runAll() method as a startup interface. When generating the execute(...) method, the behavior code generation module will embed task registration, dependency initialization, and the call to runAll() together, so that external callers only need to execute execute(...) once to drive the entire activity to run automatically according to the established control flow, without the need to manually write thread scheduling and task coordination code.
[0030] In terms of object streams and data-driven execution, the system maintains a centralized token mapping for each output pin to record currently available data tokens and their sources.
[0031] When a behavior node is ready to execute, the system queries the upstream output pins corresponding to all its input pins according to the object flow relationship, and searches the token map to see if a complete set of input tokens exists. Only when all the input tokens required by the node are ready is the node considered to be activated and enter the execution phase. After the execution is completed, the output result will be written back to the token map of the corresponding output pin.
[0032] In a parallel architecture, tokens on different branches propagate independently with the control flow. The system waits for all necessary tokens to arrive at the Join node before continuing execution, thus ensuring the synchronization of parallel branches and data consistency.
[0033] In the loop structure, the tokens initially injected and the tokens generated inside the loop are managed at the Merge node using a strategy of separate buffering or iterative overwriting to ensure that the input and output data of each loop round are not accidentally confused, thereby achieving accurate restoration of the semantics of UML object flow.
[0034] To ensure that executable behavior remains consistent with the semantics in the UML specification, the system also performs specialized mapping for multiple types of executable actions: For the AcceptEventAction node, the generated Java code contains event listener registration logic and onSignalReceived internal triggering logic, so that external signals can wake up waiting behavior nodes at runtime; For CallBehaviorAction or CallOperationAction nodes, the system-generated code will call the corresponding ActivityRunner or StateMachineRunner according to the configuration during modeling, and use token mapping to complete the automatic passing of input and output parameters; For nodes such as ReadSelfAction, ReadExtentAction, and SendSignalAction, the behavior code generation module maps them to specific implementation code such as context acquisition, object collection traversal, and signal sending. In this way, the high-level modeling elements in UML can be completely implemented into an executable Java program without changing the model structure.
[0035] In the state machine code generation path, firstly, the behavior code generation module reconstructs the corresponding directed state transition graph based on DOM elements, and parses out the entry, exit, doActivity behaviors of each state, as well as the triggering conditions and guard expressions on the transition, and organizes them into data members of the state machine structure class.
[0036] Based on this, the system generates a StateMachineRunner instance for each state machine. This class maintains the current state of the state machine, pending events, and synchronization locks, and is bound to the specific state machine instance, thus forming a complete integrated execution unit for state data and operation control.
[0037] At runtime, the StateMachineRunner instance of the management class runs the event loop logic in a separate thread. When there are no events to process or no state transitions to trigger, the event loop enters a waiting state, releases the synchronization lock, and suspends the current thread to avoid unnecessarily occupying computing resources.
[0038] When an external environment injects a new signal through the onSignalReceived method, the runtime environment will encapsulate the signal as an event object, write it to the pendingEvent or event queue inside the StateMachineRunner instance, and wake up the waiting thread when necessary through the notification mechanism of condition variables.
[0039] After the awakened event loop obtains the current state and the events to be processed, it will traverse the outgoing migrations of the state according to the pre-built state transition table and check whether the trigger event type matches the guard condition. Once a suitable transition is found, the execution logic sequentially calls the exit method of the source state and the entry and doActivity methods of the target state to complete a complete state transition and behavior execution. At the end, it updates the current state pointer and enters the next round of event waiting or processing.
[0040] When the doActivity behavior of a certain state in the state machine is modeled as calling a certain Activity, the system will start the ActivityRunner of the corresponding Activity when the state is activated, so that the activity can execute complex control flow and object flow logic asynchronously during the life cycle of the state.
[0041] At the same time, the activity can still receive signal events from the outside or the state machine through nodes such as AcceptEventAction, thus forming a hybrid event-driven execution framework in which "the state machine is responsible for macro-level state transitions and the activity is responsible for micro-level behavior execution".
[0042] In this architecture, the state machine and activities work together: the state machine controls the behavioral phases and mode switching through the event loop, and the activities implement specific business logic and concurrent data processing within each phase. The entire system can be run directly after the code is generated, realizing end-to-end verification and engineering implementation of the behavioral semantics of the UML model.
[0043] In summary, the event-driven behavioral code generation method and system proposed in this invention for UML models can automatically complete the structural analysis of activities and state machines, control flow and object flow modeling, and event-driven execution code generation without changing existing modeling processes and tool usage habits. This is achieved by utilizing existing XMI model information and unified behavioral semantic representation, realizing a high-fidelity mapping from UML behavioral models to executable Java programs. This method not only maintains the consistency of control structures such as sequence, branching, parallelism, and looping, as well as complex semantics such as object flow data dependencies and signal event triggering, but also constructs a unified runtime execution framework through ActivityRunner and StateMachineRunner, allowing the model to be directly run and interactively verified after code generation. Compared to traditional manual coding methods, this invention significantly reduces the manual translation cost and error risk from model to implementation, supports rapid prototyping and iterative simulation verification of complex system behaviors, and provides key technical support for model-based design, verification, and delivery in fields such as aerospace, industrial control, and embedded software.
Claims
1. A method for automatically generating event-driven behavior code for UML models, characterized in that, Includes the following steps: S1. Export the UML model XMI file containing classes, activities, and state machines from the UML modeling tool, read the XMI through the DOM parser, construct the corresponding document tree structure, and extract DOM elements and their relationships from the document tree structure; S2. Generate the corresponding Java source code of the attributes and methods of the main class and its associated classes in the UML model based on the DOM elements and their relationships, and generate the main method in the main class and its associated classes. Use the main method of the main class as the simulation / run entry point. The main method of the main class calls the main method of the associated class at runtime. S3. Determine the classifier behavior type of the main class and its associated classes in the UML model; if the classifier behavior type is Activity, then the main method of the main class or associated class enters the activity code generation path; if the classifier behavior type is StateMachine, then the main method of the main class or associated class enters the state machine code generation path.
2. The method for automatically generating event-driven behavior code for UML models according to claim 1, characterized in that, The specific activity code generation path is as follows: starting from the InitialNode of the classifier behavior of the main method of the main class or associated class, traverse to identify activity sequence, branching / merging, parallelism / synchronization, and loops; construct a behavior control flow graph based on the identified activity sequence, branching / merging, parallelism / synchronization, and loops; based on the behavior control flow graph, decompose the classifier behavior of the main method of the main class or associated class into a series of SimpleTasks and LoopTasks, and extract the task dependencies of SimpleTasks and LoopTasks according to the sequence and synchronization relationships of the control structure and construct a task dependency graph; generate Java source code containing the execute method and execution scheduling statements according to the task dependency graph to achieve automatic mapping of activity sequence, branching, parallelism, and loop structures; the loop identification method is as follows: based on the Tarjan algorithm, identify the strongly connected components of the activity graph to obtain the loop region, and record the entry, exit, and iteration path of each node in the loop; the SimpleTask is specifically a task other than the LoopTask; the LoopTask is specifically a task located within the loop structure.
3. The method for automatically generating event-driven behavior code for UML models according to claim 2, characterized in that, The behavior control flow graph-based decomposition of the classifier behavior of the main method of the main class or associated class into a series of SimpleTasks and LoopTasks is as follows: When encountering a combined structure consisting of Decision nodes and Merge nodes, the branch conditions and loop markers are used to determine whether the task path related to the structure is inside the loop. For task paths inside the loop, LoopTask subtasks are generated, and for task paths outside the loop, ordinary SimpleTasks are generated.
4. The method for automatically generating event-driven behavior code for UML models according to claim 2, characterized in that, The method for extracting the task dependencies of SimpleTask and LoopTask based on the sequence and synchronization relationships of the control structure is as follows: When a Fork node is encountered, a new independent subtask path is created for each outgoing branch, and the dependency relationship between the starting task of the subtask path and the parent task before the Fork node is recorded. When a Join node is encountered, the dependencies between all tasks that end at the Join node and the tasks following the Join node are recorded.
5. The method for automatically generating event-driven behavior code for UML models according to claim 1, characterized in that, The specific path for generating the state machine code is as follows: For the classifier behavior of the main method of the main class or related classes, a state transition graph is reconstructed based on DOM elements. Based on the state transition graph, Java source code containing a state machine class instance and a StateMachineRunner instance is generated. The StateMachineRunner instance maintains the current state of the state machine, pending events, and a synchronization lock. The state machine instance executes the `exit()`, `entry()`, and `doActivity()` methods of the state sequentially by waiting for external signals or timed events. It also supports starting activity execution within the `exit()`, `entry()`, and `doActivity()` methods of the state, achieving mixed event-driven execution of activities and the state machine. The pending events are specifically signal events or time events that determine the transition of the state machine from its current state to the next state. The synchronization lock prevents other threads from concurrently modifying the state or events while the current thread is judging the current state of the state machine and deciding whether to wait for a trigger or retrieve a pending event, thereby avoiding race conditions.
6. A system for automatically generating event-driven behavior code for UML models, used to execute the method for automatically generating event-driven behavior code for UML models as described in any one of claims 1-5, characterized in that, The system includes a model parsing module, a class code generation module, and a behavior code generation module, which are connected in sequence. Model parsing module: Used to export UML model XMI files containing classes, activities and state machines from UML modeling tools, read the XMI through the DOM parser, construct the corresponding document tree structure, and extract DOM elements and their relationships from the document tree structure; Class code generation module: used to generate the corresponding Java source code of the attributes and methods of the main class and its associated classes in the UML model based on the DOM elements and their relationships, and generate the main method in the main class and its associated classes. The main method of the main class is used as the simulation / run entry point. The main method of the main class calls the main method of the associated class at runtime. The behavior code generation module is used to determine the classifier behavior type of the main class and its associated classes in the UML model. If the classifier behavior type is Activity, the main method of the main class or associated class enters the activity code generation path; if the classifier behavior type is StateMachine, the main method of the main class or associated class enters the state machine code generation path.
7. The event-driven behavior code automatic generation system for UML models according to claim 6, characterized in that, The specific activity code generation path is as follows: starting from the InitialNode of the classifier behavior of the main method of the main class or associated class, traverse to identify activity sequence, branching / merging, parallelism / synchronization, and loops; construct a behavior control flow graph based on the identified activity sequence, branching / merging, parallelism / synchronization, and loops; based on the behavior control flow graph, decompose the classifier behavior of the main method of the main class or associated class into a series of SimpleTasks and LoopTasks, and extract the task dependencies of SimpleTasks and LoopTasks according to the sequence and synchronization relationships of the control structure and construct a task dependency graph; generate Java source code containing the execute method and execution scheduling statements according to the task dependency graph to achieve automatic mapping of activity sequence, branching, parallelism, and loop structures; the loop identification method is as follows: based on the Tarjan algorithm, identify the strongly connected components of the activity graph to obtain the loop region, and record the entry, exit, and iteration path of each node in the loop; the SimpleTask is specifically a task other than the LoopTask; the LoopTask is specifically a task located within the loop structure.
8. The event-driven behavior code automatic generation system for UML models according to claim 7, characterized in that, The behavior control flow graph-based decomposition of the classifier behavior of the main method of the main class or associated class into a series of SimpleTasks and LoopTasks is as follows: When encountering a combined structure consisting of Decision nodes and Merge nodes, the branch conditions and loop markers are used to determine whether the task path related to the structure is inside the loop. For task paths inside the loop, LoopTask subtasks are generated, and for task paths outside the loop, ordinary SimpleTasks are generated.
9. The event-driven behavior code automatic generation system for UML models according to claim 7, characterized in that, The method for extracting the task dependencies of SimpleTask and LoopTask based on the sequence and synchronization relationships of the control structure is as follows: When a Fork node is encountered, a new independent subtask path is created for each outgoing branch, and the dependency relationship between the starting task of the subtask path and the parent task before the Fork node is recorded. When a Join node is encountered, the dependencies between all tasks that end at the Join node and the tasks following the Join node are recorded.
10. The event-driven behavior code automatic generation system for UML models according to claim 6, characterized in that, The specific path for generating the state machine code is as follows: For the classifier behavior of the main method of the main class or related classes, a state transition graph is reconstructed based on DOM elements. Based on the state transition graph, Java source code containing a state machine class instance and a StateMachineRunner instance is generated. The StateMachineRunner instance maintains the current state of the state machine, pending events, and a synchronization lock. The state machine instance executes the `exit()`, `entry()`, and `doActivity()` methods of the state sequentially by waiting for external signals or timed events. It also supports starting activity execution within the `exit()`, `entry()`, and `doActivity()` methods of the state, achieving mixed event-driven execution of activities and the state machine. The pending events are specifically signal events or time events that determine the transition of the state machine from its current state to the next state. The synchronization lock prevents other threads from concurrently modifying the state or events while the current thread is judging the current state of the state machine and deciding whether to wait for a trigger or retrieve a pending event, thereby avoiding race conditions.