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 220.127.116.11 you’ll see exactly what I mean. Also check 18.104.22.168 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 22.214.171.124, ‘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.
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.
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!
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:
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.
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!