The Unified Modeling Language is not so much unifying programming paradigms. It is dramatically focused towards object-oriented programming (hence, f.ex. its most popular diagram being the class diagram). In contrast, sum types are typically a feature of functional languages (like F#, Haskell, etc.).

I’m afraid to inform you that UML is probably not a good choice to model programs that will be developed with a functional language. A huge bag of their features do not have direct correspondences in UML unfortunately. Features that form the bread-and-butter of FP, like first-class functions, type constructors, etc., are troublesome to represent in UML, or flat out impossible.

If you must represent sum types, then you could model a representation that is close to their implementation in Scala, where you actually define a base class/trait/interface and derive the individual sum types. Something like this (simplified):

sealed trait Option[+A]
case object None extends Option[Nothing]
case class Some(value : T) extends Option[T]

Of course, you will fall short of modelling this in several aspects (trait? case class? covariance? sealed?), but that is my general experience when you try to model non-OOP features in UML.

A classifier in UML can encompass multiple subclassifiers that form something they call a “generalization set” which can be a complete partitioning of the instances of a superclass. There’s a graphical notation for this in class diagrams. So, you can have a classifier C that has subclasses P Q R … with the property that any instance of C must be an instance of exactly one of P Q R … That is the closest I’ve been able to come to a UML visualization of union. OOP folk seem to think of the superclass “coming first” and then deriving the subclasses, which is not quite the same “feel” as the union perspective which is about defining C in terms of P Q R. But if you think of the UML class diagram as describing possible run-time object graphs rather than picturing source code, the generalization set with a superclass that has no attributes or operations may be close to what you want.

UML class diagrams are really inadequate to visually depict basic logical relationships like disjunction, etc

A sum type could be constructed by multiple {xor} compositions. The xor is part of the UML standard.

Example: Optional type

Composition could likely be used to denote tagged unions in a UML class diagram. Composition is the “has a” relationship and a tagged union has a tag and a value. You can use multiplicity and role names or ownership indicators.

However, something to consider is that class diagrams are typically geared toward representing class relationships in an object-oriented language. Other diagram types may be less specific to object-orientation, such as deployment diagrams or component diagrams. You may want to consider other notations beyond just using UML and emphasize clearly communicating a design over sticking to one standard.