Introduction

In UML, a signal is an asynchronous communication concept, not just a decorative arrow in a class diagram. The tricky part is that class diagrams are primarily structural, while signals are behavioral. So the correct design is usually to model the signal as a Signal classifier and show which classes can send or receive it, but to describe the actual interaction flow in a behavioral diagram such as a sequence, communication, or state-machine diagram.

What A UML Signal Actually Is

A signal in UML represents an asynchronous message instance that may carry data. Unlike a normal operation call, the sender does not wait for a synchronous return from the receiver.

That difference matters because a class diagram is not mainly about message timing. It is about static structure.

So the first design rule is: do not force a dynamic interaction problem entirely into a structural diagram.

How Signals Appear Structurally

If you want to show signals in a class-oriented view, UML lets you model a Signal similarly to a classifier with attributes.

For example, conceptually:

• 'AlarmRaised is a signal,'
• it may carry fields such as severity or timestamp,
• some class sends it,
• another class receives it.

In a class-diagram-like representation, the signal itself can be shown as a separate modeling element, not as a method on the sender.

Receiving Classes Can Show Receptions

A class can indicate that it handles a particular signal through a reception. A reception is structurally similar to saying “this class is prepared to react to signal X.”

That is different from defining an ordinary synchronous operation, because the semantics are about asynchronous arrival rather than direct method invocation.

So if you are trying to show “class A can receive signal AlarmRaised,” a reception is closer to UML intent than inventing a fake method call just to make the class diagram look complete.

Do Not Overload The Class Diagram With Behavior

This is where many UML designs go wrong. Designers try to show:

• who emits the signal,
• when it is emitted,
• which object receives it,
• what happens afterward,
• in what order multiple signals occur.

That is too much behavioral meaning for a class diagram. Once timing, ordering, or event flow matters, use a sequence diagram or state machine.

A class diagram can show that the types and relationships exist. It is not the best diagram for the runtime story.

A Reasonable Structural Pattern

A good structural design often looks like this conceptually:

• define a Signal classifier such as DoorOpened or AlarmRaised,
• show which classes may send it through dependencies or general architecture notes,
• show receptions on classes that handle it,
• use a sequence or state diagram to explain the actual event flow.

This keeps structure and behavior separated instead of cramming one into the other.

Example Modeling Approach

Imagine a home security system.

• 'DoorSensor sends DoorOpened,'
• 'AlarmController receives DoorOpened,'
• 'AlarmRaised may later be emitted to another subsystem.'

In the class diagram, you might model:

• classes such as DoorSensor and AlarmController,
• signal classifiers such as DoorOpened and AlarmRaised,
• receptions on AlarmController.

In a sequence diagram, you would then show the actual runtime ordering of signal emission and handling.

Why This Matters Architecturally

Good UML is about communication, not just notation correctness. If someone reading the model cannot tell whether a relationship is synchronous, asynchronous, structural, or temporal, the diagram has failed even if the notation is technically arguable.

Signals deserve explicit treatment because they imply loose coupling, event-driven behavior, and asynchronous semantics. Those are architectural properties, not just visual arrows.

Common Pitfalls

• Modeling asynchronous signals as ordinary class operations without acknowledging the semantic difference.
• Forcing event timing and ordering details into a class diagram.
• Omitting the signal classifier and leaving only vague dependencies between classes.
• Using only a class diagram when the real design question is behavioral.
• Treating UML notation as the goal instead of clear communication of the architecture.

Summary

• Signals in UML represent asynchronous communication, which is primarily behavioral rather than structural.
• In a class-oriented view, model signals as Signal classifiers and receiving capability as receptions.
• Use class diagrams to show structure and type relationships.
• Use sequence or state-machine diagrams to show runtime signal flow and ordering.
• The correct design is usually a combination of structural and behavioral modeling, not a class diagram alone.