Un'opzione potrebbe essere l'estensione di UML. Questo è ciò che Schärli e altri hanno fatto quando hanno inventato i tratti, che sono parenti stretti dei mixin. Semplicemente ha inventato un'aggiunta a UML che ha permesso loro di rappresentare i tratti. Ovviamente, tale UML non può più essere prodotto o elaborato da strumenti UML esistenti, è necessario estendere anche questi strumenti.
Un'alternativa è guardare a ciò che un mixin è veramente al centro: un mixin è una classe parametrizzata rispetto alla sua superclasse. (Pensa: class MyMixin<T> extends T .) In Ruby, questo è anche il modo in cui è effettivamente implementato: include crea una nuova classe che condivide il suo metodo, la costante e le tabelle di variabili modulo / classe con il mixin, ottiene la superclasse corrente della classe che è incluso nella sua superclasse e quindi diventa la superclasse di classi miste.
Confrontato con l'ereditarietà multipla: con ereditarietà multipla, una classe può avere più superclassi, ma appare solo una volta nel grafico dell'ereditarietà. Con i mixin, una classe di mixin può apparire più volte nell'albero ereditario, ma ad ogni occorrenza ha solo una superclasse (che potrebbe essere diversa dalle altre occorrenze).
Quindi potresti rappresentare un mixin come una superclasse nella catena di ereditarietà di ogni classe in cui viene mescolato, con qualche relazione aggiuntiva tra quelle classi per indicare che quelle sono in realtà lo stesso mixin, solo con diverse superclassi. Ad esempio, li rappresentano come istanze di modello ( <<bind>> ) di un modello MyMixin<T> che ha T come superclasse (se possibile). Oppure crea la tua relazione, ad esempio <<same mixin>> o qualcosa di simile.