The "Publisher-Subscriber" pair pattern (a.k.a "Observer"), may be implemented different in each programming (language) framework, therefore, designed different, in U.M.L.
Any way, conceptually, when an event ("signal" or "message") is sent, from a publisher (a.k.a "server") to any subscriber ("client"), sometimes, an "id" to identify a particular event, from other events, its provided, and some additional parameters or data its also sent.
As other answers already mention, you may require a (class) diagram to describe the static model. (Note that there is a "aggregation", not "composition", "association" can be used):
..............................
+--------------------------+..
| <<Publisher>> |..
| VectorDrawApp |..
+--------------------------+..
| [+] create() |..
+--------------------------+..
| [+] send(EventArgs e) |..
+------------+-------------+..
............/ \...............
............\ /...............
.............|................
.............|................
+------------+-------------+..
| <<Subscriber>> |..
| Figure |..
+--------------------------+..
| [+] create() |..
+--------------------------+..
| [+] receive(EventArgs e) |..
+--------------------------+..
..............................
+--------------------------+..
| <<Event>> |..
| EventArgs |..
+--------------------------+..
| [+] Sender: TObject |..
+--------------------------+..
| [+] receive(EventArgs e) |..
+------------+-------------+..
.............|................
.............+................
............/ \...............
...........+---+..............
.............|................
+------------+-------------+..
| <<Event>> |..
| FillEventArgs: EventArgs|..
+--------------------------+..
| [+] ForeColor |..
| [+] BackColor |..
| [+] FillStyle |..
+--------------------------+..
..............................
And also, you may require a diagram to describe the dynamic model:
.........................................
+----------------+..+----------------+...
| <<Publisher>> |..| <<Subscriber>> |...
| VectorDrawApp |..| Figure |...
+--------+-------+..+--------+-------+...
.........|...................|...........
.......+-+-+...............+-+-+.........
.......| |...send(fill)..| |..Fill().
.......| +==============>+ +---+.....
.......| |...............| |...|.....
.......| |...<<return>>..| |...|.....
.......| |<--------------+ +<--+.....
.......| |...............| |.........
.......+-+-+...............+-+-+.........
.........|...................|...........
.........X...................X...........
.........................................
Stereotypes, in U.M.L., are your "drinking buddies",
and allow you to describe or restrict what an actor, object, class,
trait, or interface does.
When you use them, highlight when an object or class,
are subclasses of a class, or implement,
an interface that is relevant to the activities,
that are been model, even if there are other parent classes,
or interfaces.
Cheers.