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!
Hey again.
Iâve also composed a separate Activity Diagram for Registering to Use a Computer System.
If you wouldnât mind, of course, Iâd love your feedback and thoughts on it.
I would have put this in an edit but Iâm not allowed more than 1 image.
I also re-did the Cash Machine example:
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!
