First: thanks for the question. This place can definitely use a bit more UML discussions!
And I really enjoyed going over your diagram by the way, I definitely like the general structure.
So to answer your questionā¦ The syntax is correct, but Iād still suggest that you donāt use the DataStoreNode ObjectNode (or input pin) all the time. Ask yourself this: what kind of data would the exception provide? When looking at the āCash machine not workingā all which happens is that the process gets aborted. No data is sent because no data is needed. Cause and effect. So Iād suggest to remove the DataStoreNode ObjectNode there (top left corner).
Same applies to āCard reader not workingā. No information is being sent, it only needs to take one extra step as described in your ExecutableNode. Therefore: drop the DataStoreNode ObjectNode, itās not required.
I can understand why you used it. Without the InterruptableActivityRegion the DataStoreNode ObjectNode would be required, because in that case youād ādeliverā an ExceptionType. Butā¦ In this case that doesnāt fully apply because of the InterruptableActivityRegion usage.
Note: Iām basing myself on the official UML specification. If you check 15.6.5.2 youāll see exactly what I mean. Also check 15.7.13.4 for the official specification. The Association End can easily be a handlerBody.
Also noteworthy: itās not fully wrong, so donāt feel bad. Itās simply that it will look ācleanerā this way.
I hope you donāt mind me sharing, but here are some other things I spotted which you might want to look into:
- Donāt point ActivityConnectors to the side of a JoinNode. See the bottom of the diagram with āEject Cashā and āEject Cardā. Also on the bottom right: āNotify bank staffā. It is not wrong. The specification doesnāt forbid this (see 15.7.20.6, āConstraintsā) but I still think you should consider making more room in your diagram to keep this 2 sided: incoming and outgoing and nothing more.
- Add a little more space between your activities. On the left and right some of the activities only consist of an arrow and thatās it. Once again: it is not āwrongā. Absolutely not! But I still would like to suggest to add a little more space to make the arrow more visible.
- Try to make arrows enter the middle of an activity. Iām only mentioning this because I know youāre using Visual Paradigm
But it looks cleaner. - Use decision nodes! āAttempt to read cardā (left / middle) has 2 outputs. Thatās not in compliance with the UML syntax, you need a decision node there. I see this done multiple times, you may need to redo some of those sections. A decision (and Join) node can handle multiple flows, but not an activity, not like this anyway.
But it looks cleaner.And there you goā¦ As said, I like your diagram and thanks for sharing it. I hope you can find some use for my tips.
Wow.
Thank you so much for all the great feedback! As someone starting a university course and just learning UML, this is incredible. I think Iām going to frequent this site for UML advice in the future!
This brings up more questions however. 
The only way I could get Visual Paradigm to allow an ExceptionHandler was to have it connect to said DataStoreNode. It did strike me as odd that Iād have no data passed but that being the only way to do it. Are there any other ways to connect an ExceptionHandler, or is what Iām trying to do there better done with a standard control flow out of the Region? Is this partly what you mean by āThe Association End can easily be a handlerBodyā?
EDIT: As Iāve just realized, a DataStoreNode is different to what I used, which are InputPins to connect the ExceptionHandlers. Does this change the answer to my question or your comments in any way?
Thanks for the link to the specification as well, this is going straight in the handy files folder!
Regarding the Decision Nodes and Action point: Am I correct in assuming from what you say that anything having more than 1 Control Flows away from it requires a Decision node?
Everything else I think I can fix with little problems.
Iām going to try and fix all of these errors tomorrow and re-upload the revised diagram. Would you mind taking a look at it again when itās done? Your comments are really helpful!
uh oh 
Hmm, we might have a little miscommunication here, Iām specifically referring to the input put on āAbort Processā. That part isnāt required, and can be omitted. I just tried this for myself and it should work:
So hereās what I did: I simply drew the major activity steps, then drew the InteruptableActivityRegion and after that I added the accept event action and dragged it into the region.
Then all you have to do is use the resource catalog. Click on the event action to select it, find the resource catalog now shown in the upper left corner, drag it to the new location and select the connection you need. In this case: āException handler ā Actionā.
You could also simply add both models (action and accept event action) and then simply draw the connection, that should also work.
A bit That was me mixing up his classes 
Youāre right of course, Iām referring to the Input pin, aka the ObjectNode. I mixed it up with a DataNode somehow and that resulted in the small mess above.
So Iām specifically hinting at the input pin aka ObjectNode or in this case also considered the exceptionInput node.
No problem at all. I canāt guarantee Iāll always have time (or the mood) to go over it, but one way to find out
Heya, thanks for getting back to me again!
So, I donāt require any action thatās simply āAbort processā, I can just link it back to the terminate node?
The resource catalog seems pretty useful, albeit a little hard to find!
Do the images in the previous 2 posts show up for you? I have them set to hidden so Iām not sure if others can see them or not.
Thanks! 
NP 
It helps that I really enjoy working with these modeling standards and Visual Paradigm itself. However, please do keep in mind that Iām a professional hobbyist at best, I most definitely donāt consider myself an expert (think about certifications and such).
But this looks pretty good to me! The only comment I have is that Iād change the connector between āSystem not workingā and āAbort processā from a control flow into an exception handler. You should be able to do this by removing the connection, clicking on the āSystem not workingā model and then using the resource catalog. Just drag it onto the āAbort procesā action and select the exception handles instead of the control flow (āCFā).
Other than that I think it looks quite good. Even used the arc line jumps which I think look pretty nice (I hardly use those myself, but I definitely think thereās a good use for them!).
Yeah, these forums use a āreputation systemā as I tend to call it; you slowly unlock more user options the longer you participate. But all good!
It looks good to me, but I do have a few comments.
The first comment I have, as with the previous diagram, is that I think you should use exception handlers. It shouldnāt be too hard to change that. But other than that I think this looks a lot better than before. See; those arrows on the left is but a detail, but it makes the control flow stand out a bit, itās easier on the eyes.
The same applies to those JoinNodes: this makes it a lot easier to follow; you donāt have to worry too much: incoming is on one side, outgoing on the other. No wondering what those lines on the sides are doing there.
Howeverā¦ Iām probably being annoying now: you need to replace some of those with a MergeNode. I should have spotted that sooner (blame the weekend), but even so hereās the deal:
A JoinNode (the black line) doesnāt merely group incoming flows together, it also synchronizes them. This is why itās often used to bring together so called concurrent flows; processes which run in parallel. In other words: processing will only continue after all incoming processes have ended.
In your diagram thatās not going to happen, after all: the user can only withdraw their cash once.
So those really need to be replaced by MergeNodes.
Speaking of which: āAsk for desired amountā is used as both a decision and join node, that also doesnāt work.
You have several optionsā¦ Hmm, lemme fire up VP 
This is roughly how Iād approach this:
Thing isā¦ exceptions are just that: more or less unforeseen events which interrupt your flow. The user not taking out their card could account for that, but it might be useful to specify how long the system will wait. So instead of treating it as an exception Iād make this a part of the actual process. Make the system wait for an x amount of time for the user to take action, and if not take action on their behalf.
Hope this can give you some ideas!
