What's the difference between a signal and asynchronous operation in UML?

Making sequence diagrams my tool allows for communication that is either synchronous operation, asynchronous operation, and signal.

What's the difference between the last two regarding program flow?

Solution

Signals are meant for asynchronous event driven communication. The signals are classifiers, that describe the attributes of their occurence. Classes themselves and indicate in the reception section which signals they are able to process, and in interaction diagrams you can then use these signals.

In a sequence diagram, the communication between two lifelines is achieved using Messages:

The signature of a Message refers to either an Operation or a Signal. The name of the Message must be the same as the name of the referenced Operation or Signal.

The graphical notation for operation and signals in sequence diagrams is the same; it's just that signals are necessarily always asynchronous. The good news is that you can start with one, and decide to switch to the other without fundamentally changing your sequence diagram.

There is no rule to use the one or the other. You could model very similar designs using the one or the other. Typcially, you may prefer signals over asynchronous operations:

if you're designing an event-driven system,
if you're designing a distributed system, with many intermediaries relaying your message
if the message is meaningful for the sender regardless of the receiver. One symptom of this situation is that potentially unrelated classes (having different operations) could be interested in receiving and processing such message.
if the content of the message is complex: instead of an operation with many arguments, and instead of an operation using a class argument where the class was solely created for simplifying the call arguments, the signal could allow to model the content of the message.