One option would be to extend UML. That's what Schärli et al did when they invented traits, which are close relatives to mixins. The simply invented an addition to UML that allowed them to represent traits. Of course, such mixin-extended UML can no longer be produced or processed by existing UML tools, you would have to extend those tools, too.
An alternative is to look at what a mixin really is at its core: a mixin is a class that is parameterized over its superclass. (Think:
class MyMixin<T> extends T.) In Ruby, that's even how it's actually implemented:
include creates a new class which shares its method, constant and module/class variable tables with the mixin, gets the current superclass of the class it is included into as its superclass and then becomes the mixed-into classes' superclass.
Compared to multiple inheritance: with multiple inheritance, a class may have multiple superclasses but only appears once in the inheritance graph. With mixins, a mixin class may appear multiple times in the inheritance tree but at each occurrence has only one superclass (which may be different from the other occurrences).
So, you could represent a mixin as a superclass in the inheritance chain of every class it is being mixed into, with some additional relationship between those classes to indicate that those are actually the same mixin, just with different superclasses. For example, represent them as template instantiations (
<<bind>>) of a
MyMixin<T> template which has
T as its superclass (if that's possible). Or just make up your own relation, such as
<<same mixin>> or something.