How to show repeatable activities in UML diagram

Question

I'm working on a project and trying to show one of the Use Cases in a UML activity diagram.

I'd like to use it in order to show that the requirements for this particular use case are met.

I'd also like to use it to develop the test cases that will need to be written for this use case.

I've ordered the "UML 2.0 In A Nutshell" book but until that arrives I'm trying my best from articles and youtube clips so the diagram may not conform to the proper standards.

Question 1:

I've tried to show that the ExecuteInThread function as a whole has a try catch block to stop any exception bubbling up and crashing the app but I'm not sure if I've shown that correctly?

Question 2:

I'd also like to show is that updating the task status to Failed / In Progress / Completed is done on the database and if the database is unavailable it retries 10 times to connect before it fails.

Is it possible to have a repeatable block on the side I could refer to for each Update activity to show this?

Question 3:

I've read that at the level of the use case I should not be showing any implementation details.

I'm guessing this means avoid showing there's a database involved at all and not to show any try / catch logic unless it impacts the user's actions. Am I doing completely the wrong thing here?

The retry logic is a requirement for this use case though so my first attempt was to include it given it would help with writing the test cases and showing application resilience.

Diagram:

Answer 1

Question 1:

Any action can be protected by an exception handler. This is the zigzag-line in your diagram. The action at the other end is the handler body. I must not have incoming or outgoing control or object flows. When the exception handler finishes, the protected action produces tokens on its outgoing flows, as if it has ended normally. The handler body should also have an input pin typed by the exception. This way it can distinguish different exceptions and the protected action can tranfer information about the problem.

Structured activity nodes are also actions and can be protected by an exception handler. In your diagram I guess Execute Task in Thread is such an action. The official notation uses a dashed border and the keyword «structured».

Edit: After discussion with @bruno. If you want to use Exceptions, you should probably rethink how you group the actions. A protected action will always finish successfully, if its exception handler body doesn't raise a new exception. That means the body must try to recover from the exception and potentially retry the behavior of the protected action (there is no UML element for retrying, you will have to do it on foot). If that doesn't work, the handler body must reraise the exception (after having made sure that everything is in good order, i.e. that the class invariant is still holding).

This might seem a bit over complicated. Why not simply use a decision node after the action execute task with the guard [successfull]. I would use ReceiveSignalActions in use case flows only to model interactions from outside of the system, that can influence the flow of the use case.

Question 2:

You can create an activity update task status and call it from all the update actions. The status itself could be a value pin on this call action. Inside the update activity you can show a loop with decision and merge nodes that counts the trials. However, it will probably be easier to just write in the description, that it can be Irepeated 10 times.

This is the way how a repeatable set of actions can be modeled. It is not possible to do that in the same diagram. I would however be allowed to expand one of the call actions, so that the called activity is shown there. You have to try, whether your tool does offer this possiblity. Some tools only offer to show any diagram embedded in another diagram. This is not standard and will not be interchangable between tools.

Question 3:

I agree that the database and the number of retries are technical details that are not the focus of the use case analysis.

It could be interesting, though, if the system would not just display an error message, but would need to offer alternative ways to achieve the desired result. If for example the system shall then offer to save the update to an usb stick. Since this requires additional interaction with the user and gives rise to a new functional requirement for the system, it makes sense to analyse it within the use case. If it is just an occasional technical problem, I would not cover it.

If you need a way to capture this requirement in your model, I would just add a user defined extension for textual requirements. Not all requirements are coming from use cases. Many tools already have their own extension for this.