我发现UML对于记录OO系统的各个方面很有用，特别是整体架构和序列图的类图，以说明特定的例程。我想为我的clojure应用程序做同样的事情。我目前对模型驱动开发不感兴趣，只是简单地介绍应用程序的工作方式。
UML是一种常用/合理的函数式编程建模方法吗？是否有更好的替代UML for FP？
答案 0 :(得分：6)
“单一数据结构上的许多函数”惯用Clojure代码的方法降低了典型的“这使用”UML图，因为许多函数最终指向map / reduce / filter。 我得到的印象是，因为Clojure是一种更加以数据为中心的语言，可视化数据流的方式可能有助于提供一种在懒惰时可视化控制流的方法评估考虑在内。获得构建序列的函数的“管道”图非常有用 map和reduce等将把它们变成树
答案 1 :(得分：4)
大多数功能程序员更喜欢类型到图表。 （我的意思是类型很广泛，包括Caml“模块类型”，SML“签名”和PLT Scheme“单元”等。）为了传达大型应用程序的工作原理，我建议三件事：
给出每个模块的类型。由于您使用的是Clojure，您可能需要查看由Matthew Flatt和Matthias Felleisen发明的“单元”语言。我们的想法是记录模块所依赖的类型和操作以及模块提供的内容。
提供接口的导入依赖项。这里的图表很有用;在许多情况下，您可以使用dot自动创建图表。这样做的优点是图表始终能准确反映代码。
对于某些系统，您可能希望讨论实现的重要依赖关系。但通常不是 - 将接口与实现分离的关键是，只能根据它们所依赖的接口来理解这些实现。
related question上最近有architectural thinking in functional languages。
答案 2 :(得分：3)
这是一个有趣的问题（我已经投了赞成票），我希望你能获得至少与你做出回应一样多的意见。这是我的贡献：
您希望在图表上表示什么？在OO中，对该问题的一个答案可能是，考虑类图，状态（或者您喜欢的属性）和方法。因此，显然我建议，类图不是正确的开始，因为函数没有状态，并且通常实现一个函数（aka方法）。任何其他UML图表是否为您的思考提供了更好的起点？答案可能是是，但你需要考虑你想要展示的内容并自己找到起点。
一旦你用函数式语言编写（子）系统，那么你就有了一个（UML）组件来表示标准的图表类型，但也许这对你来说太高级，太抽象了
当我编写功能程序时，我承认，我倾向于记录函数，因为我会记录数学函数（我从事科学计算工作，大量的数学运算，所以这对我来说很自然）。对于我写的每个函数：
一个ID;
有时，描述;
域名规范;
共域的规范;
规则声明，即函数执行的操作;
有时我也会写后期条件，尽管这些条件通常由共同域和规则充分指定。
我使用LaTeX，这对于数学符号很有用，但任何其他相当灵活的文本或文字处理器都可以。至于图表，没有那么多。但这可能反映了我在功能上编程的系统设计的原始状态。我的大部分计算都是在浮点数的数组上完成的，因此我的大多数函数都很容易组成 ad-hoc ，并且系统的结构非常松散。我想象一个图表显示节点和输入/输出的功能作为节点之间的边缘 - 在我的情况下，在大多数情况下，每对节点之间会有边缘。我不确定绘制这样的图表会对我有所帮助。
我似乎是在告诉你不这样做，UML不是一种合理的功能系统建模方法。它是否会普遍告诉我们。
答案 3 :(得分：1)
这也是我一直试图尝试的东西，经过几年的Ruby编程后，我习惯了类/对象建模。最后，我认为我为Clojure库创建的设计类型实际上与我对大型C程序所做的非常相似。
首先概述域模型。列出围绕正在对此数据执行的主要功能移动的主要数据。我在笔记本上写这些，很多时候它只是一个名称，下面有3-5个子弹点。这个大纲可能是你初始命名空间的一个很好的近似，它应该指出一些关键的高级接口。
如果看起来非常简单，那么我将为高级接口创建空函数，并开始填充它们。通常每个高级函数都需要一些支持函数，并且当你构建整个界面时会找到分享更多代码的机会，所以你可以随时重构。
如果这似乎是一个更难的问题，那么我将开始绘制数据结构和关键功能的流程。通常情况下，最有意义的图表和概念模型将取决于您选择在特定设计中使用的抽象类型。例如，如果您将数据流库用于Swing GUI，则使用依赖关系图是有意义的，但如果您正在编写服务器来处理关系数据库查询，那么您可能希望绘制代理和管道池以处理元组。我认为这些类型的模型和图表在向另一个开发人员传达如何构建程序方面也更具描述性。它们显示了系统各方面之间的功能连接，而不是UML之类的非特定信息。