The UML standard defines over a dozen different diagram types, as shown in this handy chart:
See also Figure A.5 The taxonomy of structure and behavior diagrams in the UML 2.5 spec.
Note that this is an example of a class diagram, with is-a subtyping relationships between diagram types, and abstract diagram types in italics.
While these diagram types actually are classes within the UML metamodel, this class diagram is still useful to illustrate a hierarchy, without any connection to OOP.
There are a couple of types that clearly only apply to OOP, for example the class diagram or the object diagram. But the rest is more widely applicable than just for object-oriented systems.
State Machine Diagrams – FP does not avoid states, it merely makes them explicit. A State Machine Diagram can be useful to explain the control flow, or the various state transitions in the program.
Activity Diagrams – are useful in similar cases as for the State Machine Diagram, but on a higher level. They can be used to explain the flow of data between various subsystems, or to model external business processes.
Interaction Diagrams – model the interactions between multiple stateful processes. Clearly, this is not useful for modeling the internals of a pure functional program. However, UML is not only about modelling the structure of code, but primarily about providing an universal modelling language. With an interaction diagram, I could e.g. use interaction diagrams to model the external behaviour between systems, e.g. between a browser and a web server – even when those are written using FP techniques.
Use Case Diagrams – Use cases and requirements are independent of the technology used to satisfy them. OOP or FP is absolutely irrelevant here.
Deployment Diagrams – This diagram type is used to describe the relation between runnable software and hardware resources. Whether that software was written in an FP language does not matter.
Component Diagrams – Most functional languages have explicit support for modular programming these days. A Component Diagram describes components/modules, and their offered and required interfaces. This reminds me a lot of OCaml's Functor modules.
Profile Diagrams – describe extensions to UML itself and are as such never actually used.
Composite Structure Diagrams – describe the structure of composites. It can be used to describe data structures, or even the interaction points of a function. Wikipedia shows a diagram for the Fibonacci function as an example:
In a sense, this would be the functional programmers choice rather than a class diagram, but this seems horribly overengineered….
Package Diagrams – Packages are the UML equivalent of namespaces. This diagram type is more part of the UML language infrastructure than a separate diagram type. For example, you could use packages to categorize a large Use Case Diagram.
So as we have seen, various UML diagram types can still be useful when doing functional programming.
I have rarely felt the desire to use UML when designing a system, and primarily use UML to do my assigned homework, or to communicate the outline of an architecture with a quick sketch. Even for an OOP system, UML does not provide enough value to use it all the time – actual code says more than a thousand diagrams. I could imagine using UML-like diagrams to explain the dependencies between various functions and data structures in an FP program, but have yet to do so – my personal style prefers a blend of OOP and FP where FP techniques are used at a local scale, but do not influence the overall architecture.