What are functional programmers using in place of UML?

Question

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?

Answer 1

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.

Answer 2

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.

^{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:

  

  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.