What is an association class?
When looking at the graphical notation of an association class, we could be mislead to think that an association-class is simply a class that is attached to an association.
But the association class is in reality an association AND AT THE SAME TIME a class:
UML 2.5.1 / Section 11.5.3.2: An AssociationClass is a declaration of an Association that has a set of Features of its own. An AssociationClass is both an Association and a Class, and preserves the static and dynamic semantics of both.
So in the modelling semantic, beyond the notation, you cannot separate the association class from the corresponding association. If you're not convinced yet, here the next sentence in the specifications:
An AssociationClass describes a set of objects that each share the same specifications of Features, Constraints, and semantics entailed by the AssociationClass as a kind of Class, and correspond to a unique link instantiating the AssociationClass as a kind of Association.
(links are instances of an association and correspond to tuples with "one value for each memberEnd of the Association")
What are the consequence of the association-class duality?
The consequence is that the same association-class cannot exist in multiple flavors that would each associate different sets of classes.
While nothing in the notation prevents you from adding a doted line to seemngly "attach" the same class to two different associations as Bruno explains, this notation would not correspond to a valid UML semantic.
Alternatives
Your question underlines an interesting design issue. And fortunately, there are plenty of ways to solve it. For example:
User
class is associated to an abstract Destination
class. Message
would be the association-class. Destination
would be specialized into Group
and Chanel
that would both inherit the association (no need to duplicate the association graphically). (Edit: as underlined by Axel Scheithauer in the comments, the association and the association class being one and the same, they must have the same name)

- Forget about the association class. Make
Message
a normal class, associated with User
. Associate it also with Group
and Chanel
. If necessary, add an {xor}
constraint between these two associations if they are mutually exclusive.

The fact that you currently have a many-to-many association only with Group
and not with Channel
, suggest that there are some significant differences and would speak in favor of (2) rather than (1).
Not related: Something weird in your current model?
Regardless of the association-classtopic, you current model raises some questions regarding the many-to-many association with Group
:
- do you meant that several users can send a same message to several groups?
- or do you mean that a user can send messages to a group and the group is made of several users?
In the latter case, you should go for 2 distinct associations: one for the sending association, and one for the group membership association (see the red association in the diagrams above).