The UML standard defines over a dozen different diagram types, as shown in this handy chart:

Source: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

See also Figure A.5 The taxonomy of structure and behavior diagrams in the UML 2.5 spec.

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:

  

  Source: https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png

  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.