What is a UML fragment is using in a case representing a check operation that either stops the further execution on a failed check or lets it go, kind of a programming statement if role != 'admin': break:?
I found the assert fragment seems to fit the case.
The idea on a diagram:
Is the fragment used properly to represent that operation change_sensetive_settings() is executing only if a user has admin role?
I'm not a big fan of assert, which seems to be meant for visual procedureal programming rather than clean design of valid behavior. There is not much information on assert fragment in the standard:
The interactionOperator assert designates that the CombinedFragment represents an assertion. The sequences of the operand of the assertion are the only valid continuations. All other continuations result in an invalid trace.
But the way assert is used here, seems confusing in this regard: you just show a constraint { user.role == 'admin } on the server lifeline, whereas the continuation will result in a message being initiated on the client side.
To disambiguate this diagram, I'd recommend to enclose in the assert fragment the sequence made of the register_user() message, followed by the return message and your constraint. This would clearly relate the outcome regarding the user role constraint to the registration.
But this only tells a part of the story. Because, what does it mean in pratice that "All other continuations result in an invalid trace" ? Assert, just tells an assumption. Is there anything ahead of this interaction that makes this assumption realistic? If not what should happen if the user has insufficient authorisations?
For all these reasons, I'd rather recommend to use here and alt to show the normal flow, but also suggest that if the user does not have the right authorisation, something should happen (and on which side: client or server).
No, I think assert is not used correctly. Here is why:
The specification defines:
The interactionOperator assert designates that the CombinedFragment represents an assertion. The sequences of the operand of the assertion are the only valid continuations. All other continuations result in an invalid trace.
That means, the state invariant {user.role='admin'} is the only valid continuation after the reply to the register_user() message. This would rule out other outcomes. I don't think, this is what you had in mind.
So, simply remove the assert fragment. Since the sequence diagram only shows one possible scenario, it doesn't mean, that other scenarios are not valid. You could have another sequence diagram, where the state invariant is {user.role='student'}.
If you want to show more scenarios in one diagram, you could use an alt fragment. However, as others have pointed out, the purpose of the sequence diagram is not visual programming. Therefore, striving for a complete description of all possible scenarios is not appropriate.
There are some minor mistakes in the diagram. Most of them have been pointed out by others, but to make this a complete answer:
change_sensitive_settings because the user could still try to change them. Only the server can decide to reject this request. Or it must move to the client lifeline, if you want to specify that the client only sends the message, if s/he is an admin.