Page 1 of 1

The "opposite" of ExceptionHandler

PostPosted: Fri Feb 09, 2018 4:47 am
by jahennum
Hi,

I am using SysML to model various forms of systems functionality at the moment, and I am struggling with something. In a few instances, the entire diagram can be interrupted at any point by an outside request. This then has to be handled, and the normal flow can continue as planned. Since this can happen at any time, and interrupt everywhere in the flow, I am struggling with how to actually draw it. It is kind of the opposite of an ExceptionHandler. Instead of something happens that stops the flow and exits, I want something to happen "anywhere" and then continue with normal flow (albeit with a few altered parameters). Any ideas on how to model this would be much appreciated!

Re: The "opposite" of ExceptionHandler

PostPosted: Wed Feb 14, 2018 7:56 am
by donatas.mazeika@nomagic.com
Hello,

I'm not familiar with your example but maybe Innterruptable Activity Region may be a solution. Please take a look at the image below:
Interruptable_Activity_Region.png


Some more questions: do you want to model such situation or do you want to execute it? Do you have a concrete scenario that you would like to model?

Best regards,
Donatas Mazeika

Re: The "opposite" of ExceptionHandler

PostPosted: Fri Feb 16, 2018 2:06 am
by jahennum
Hi Donatas, thanks for the suggestion. However, that is what I was trying to describe (poorly, obviously), that what I want is in essence the opposite of this. In this example, some action (cancel request) happens, which in turn interrupts (stops) all ongoing activities inside the interruptable activity region. What I am facing is something (in line with this example, it could be an order update instead of a cancellation) happening which then simply "jumps in" wherever the flow currently is, updates a data set, and the rest of the flow goes normally with the updated data, but then guards etc. respond to the new data instead of the old. This can happen at any time during the flow, and the flow itself is not altered, only the data used, and therefore also the flow may be affected because other guards are triggered (but the overall flow, i.e. the layout of the activity diagram, doesn't change).