建模/记录功能程序 [英] Modelling / documenting functional programs

问题描述

我发现UML可用于记录OO系统的各个方面，特别是用于整体架构的类图和用于说明特定例程的序列图。我想为我的clojure应用程序做同样的事情。我目前不感兴趣的模型驱动开发，只是在沟通如何应用程序的工作。

I've found UML useful for documenting various aspects of OO systems, particularly class diagrams for overall architecture and sequence diagrams to illustrate particular routines. I'd like to do the same kind of thing for my clojure applications. I'm not currently interested in Model Driven Development, simply on communicating how applications work.

UML是一种常见/合理的建模函数式编程方法吗？是否有更好的替代UML的FP？

Is UML a common / reasonable approach to modelling functional programming? Is there a better alternative to UML for FP?

推荐答案

大多数函数式程序员喜欢类型的图。 （我的意思是类型非常宽泛，包括诸如Caml模块类型，SML签名和PLT方案单位之类的东西。）为了传达大型应用程序的工作原理，我建议三件事：

Most functional programmers prefer types to diagrams. (I mean types very broadly speaking, to include such things as Caml "module types", SML "signatures", and PLT Scheme "units".) To communicate how a large application works, I suggest three things:

• 提供每个模块的类型。因为你使用Clojure，你可能想要检查由Matthew Flatt和Matthias Felleisen发明的Units语言。

• Give the type of each module. Since you are using Clojure you may want to check out the "Units" language invented by Matthew Flatt and Matthias Felleisen. The idea is to document the types and the operations that the module depends on and that the module provides.

提供接口的导入依赖关系。这里的图可能是有用的;在许多情况下，您可以使用 dot 。

Give the import dependencies of the interfaces. Here a diagram can be useful; in many cases you can create a diagram automatically using dot. This has the advantage that the diagram always accurately reflects the code.

对于某些系统，你可能想谈谈实现的重要依赖。但通常不是—将接口与实现分离的点是，只能根据它们依赖的接口来理解实现。

For some systems you may want to talk about important dependencies of implementations. But usually not—the point of separating interfaces from implementations is that the implementations can be understood only in terms of the interfaces they depend on.

最近出现了相关问题 on 功能语言的建筑思维。

这篇关于建模/记录功能程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！