I'm CS student. I am currently attending lectures, where we're taught Objective Analysis and Design. It consists mostly of writing use cases, analysing the problem that we can face when writing some application for the client, and how to design the project so that it's both extensible, clear to developers, and doesn't spawn problems when client argues about some features. Since it's 'objective', we're learning it from OOP point of view(classes and such).

Now we're using UML as a helper tool. I believe I have a good grasp on OOP, but I have also learned functional paradigm and used it successfully in some of my smaller projects.

Our teacher, when confronted with "what about functional paradigm?" question, answered that he wasn't programming any larger project in functional languages, and he doesn't know what tool may functional programs be using.

So, what would they use? Is there some methodology for this? Or maybe there's no need for such thing?

  • 9
    Since FP puts more emphasis on data, a data flow diagram can probably elucidate an FP program, the way a flowchart or sequence diagram elucidates imperative code.
    – 9000
    Commented Nov 17, 2015 at 15:49
  • 10
    I've been a software developer for many years. Never in my life have I used UML of my own accord, nor have I met a single person who is familiar with the entire language. diagrams are great though....
    – AK_
    Commented Nov 17, 2015 at 18:31
  • 2
    @9000: indeed, data flow diagrams are IMHO one of the most useful type of diagrams for describing software design on a higher abstraction level - mabe more useful than class diagrams. This applies to FP and OOP as well. Unfortunately, the UML inventors choose to add lots of unnecessary diagram types to the modeling language, but refused to add data flow diagrams (yes, this is a rant!).
    – Doc Brown
    Commented Nov 17, 2015 at 22:02
  • For me and likely many other people, the answer is nothing. Outside of university I have never seen anyone ever use UML or even mention it.
    – Qwertie
    Commented May 22, 2019 at 4:19

2 Answers 2


I can't speak for all functional programmers, but those I know all start out by writing the type signatures of the top-level functions, then as they need more detail, they write the type signatures of the helper functions, and so forth.

This works because of the lack of side effects in functional programming, so functions are all specified in terms of only their inputs and outputs. This makes their type signatures much more useful as a design tool than in imperative programming. That's one reason you see them used even when the compiler could infer them.

As far as diagramming tools go, with all due respect to your professor, I haven't used those to any significant degree in any paradigm since I left school.


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

UML diagram types

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.

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:

    Composite Structure Diagram for a Fibonacci funciton

    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.

  • I think the use of Category theory will help,
    – ndotie
    Commented Dec 18, 2021 at 9:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.