I’m drawing a UML activity diagram and can’t seem to be able to drag an exception handler from an interruptible activity region to any action. However, it works fine from one action to another or if I drag a constraint or containment line from the region.
Is this a bug or by design? I’m using VP 6.1.
I’ve seen quite a few UML activity diagrams with the so-called “interruptible edge” from an interruptible region to an action. I’m guessing that this type of edge is supposed to be represented by the exception handler in Visual Paradigm?
According to uml specification, exception handler is for connecting between 2 executable node. But since interruptible activity region is not kind of executable node therefore it is not possible to be connected via exception handler. And in specification, there is only a term interruptible edge exist, but didn’t have any model call interruptible edge. If you require any further information, please do not hesitate to contact me again.
According to UML specification the exception handler cannot directly connect to an action. It require to connect via a pin. Please create a pin to your action to accept the exception flow.
Thanks a lot, Rain.
An ExceptionHandler and an InterruptingEdge have the same contcrete syntax – “zig-zag”, but they are different elements of abstract syntax.
There is no ExceptionHandler on my diagram. “Zig-zag” is InterruptingEdge. UML 2.5 specs does not require a pin for an InterruptingEdge, I hope.
See Figure 15.73 from page 409.
Thanks for replying and you are correct that the Fig 15.73 in UML 2.5 spec showing exception directly link to the action node. But according to section “15.5.4.2 Exception Handlers” it do mentioned “from the boundary of the protectedNode to a small square on the boundary of the ExceptionHandler. Also the example in 15.5.5 do 100% follow to this description. We consider the Fig 15.73 could be caused by inconsistent in the document and our implementation decided to follow the formal textual version. Hope this can help.
Hi, Rain, You are right. It is second situation in which “zig-zag” is used, But there are no interruptible regions on these figures (15.62 & 15.63).
On figure 15.73 you see an interruptible region and in this case pin is not required. I hope.
You could see other exmples at site by Kirill Fakhroutdinov https://www.uml-diagrams.org/activity-diagrams.html#interrupting-edge
You could also see the textual descriptions for InterruptingEdge:
__
15.7.19.4 Association Ends
• interruptingEdge : ActivityEdge [0..] (opposite ActivityEdge::interrupts)
The ActivityEdges leaving the InterruptibleActivityRegion on which a traversing token will result in the termination of other tokens flowing in the InterruptibleActivityRegion.
• node : ActivityNode [0..]{subsets ActivityGroup::containedNode} (opposite
ActivityNode::inInterruptibleRegion)
ActivityNodes immediately contained in the InterruptibleActivityRegion.
15.7.19.5 Constraints
• interrupting_edges
The interruptingEdges of an InterruptibleActivityRegion must have their source in the region and their target
outside the region, but within the same Activity containing the region.
inv: interruptingEdge->forAll(edge |
node->includes(edge.source) and node->excludes(edge.target) and
edge.target.containingActivity() = inActivity)
__
^^^ This is only one constraint for InterruptingEdges.
You could read description of ExceptionHandler:
__
15.7.13.1 Description
An ExceptionHandler is an Element that specifies a handlerBody ExecutableNode to execute in case the specified
exception occurs during the execution of the protected ExecutableNode.
__
It says: ExceptionHandler is not “zig-zag“ edge, but it is ExecutableNode. And this node has no outgoing edges:
______
15.7.13.5 Constraints
• handler_body_edges
The handlerBody has no incoming or outgoing ActivityEdges and the exceptionInput has no incoming
ActivityEdges.
inv: handlerBody.incoming->isEmpty() and handlerBody.outgoing->isEmpty() and
exceptionInput.incoming->isEmpty()
______
On Figure 15.73 the “Cancel Order“ Action Node has an outgoing edge. So it is not an ExceptionHandler, it does not specify a handlerBody.
