Don’t: Create an fUML loop without any Action Activation
When the fUML model has a loop without any Action Activation in the loop as shown in the figure below, the code stack continually increases until StackOverflowError occurs, causing the execution to be unexpectedly terminated. You can see StackOverflowError in the magicdraw.log file.
The model runs an infinite loop until StackOverflowError occurs, and the execution is terminated.
Do: Add an Action Activation in the loop
To avoid StackOverflowError, you must add at least an Action Activation, e.g., CallBehaviorAction in the loop as shown in the figure below. The code stack will not increase continually without StackOverflowError because Simulation has code to cut the stack loop and recall the Action at ActivityNodeActivation.receiveOffer() and ActionActivation.fire() according to fUML v1.3 specification. The execution will be continuously run without unexpected termination.
The model runs an infinite loop without StackOverflowError, and the execution is not terminated.
Don't: Send multiple signals and multiple AcceptEventActions at the same time without synchronization at all
When the fUML model has multiple threads of sending signal and multiple threads of PREPARING TO READ the signal at the same time, with no synchronization at all, it may send a signal before other thread starts AcceptEventAction to listen for it in the event pool.
According to fUML semantics, an event is lost and removed if such is a case: According to fUML semantics, once an event occurrence is selected for dispatch, it is matched against the list of waiting event accepters for the active object. If a match is found, the event occurrence is passed to the event accepter using its accept operation. If no matching event acceptor is found, the event occurrence is not returned to the event pool and is lost.
AcceptEventAction did not receive the Signal from the SendSignalAction
Do: Send signals only when all AcceptEventActions are activated
To avoid off-synchronization, you must synchronize sending and receiving activities, to make sure that you start sending only when all AcceptEventActions are activated. For example, you may send "Ready" signals after they are all activated to the sender.
All AcceptEventActions are activated for receiving the Signal from the SendSignalAction
Don't: Create fUML loops with Fork nodes
When the fUML model has loops with Fork nodes as shown in the figure below, execution threads continually increase until the internal error occurs, causing the execution to be unexpectedly terminated.
The model has loops with Fork nodes
Do: Use a CallBehaviorAction to encapsulate Fork nodes
To avoid the internal error, you must add an activity with CallBehaviorAction to encapsulate Fork nodes in the loops as shown in the figure below. The thread will not increase continually because Simulation can clear the memory after finishing the activity that contains the CallBehaviorAction.
The model uses an activity to encapsulate a fork node
