函数式程序员使用什么代替UML？

我是CS学生。我目前正在参加讲座，在那里我们将学习目标分析和设计。它主要由编写用例，分析我们为客户编写一些应用程序时可能遇到的问题以及如何设计项目以使其既可扩展，对开发人员清晰又不会在客户争论某些问题时产生问题而组成特征。由于它是“客观的”，因此我们是从OOP（类等）的角度来学习它的。

现在，我们使用UML作为帮助工具。我相信我对OOP有很好的了解，但是我也学习了功能范例，并在我的一些较小的项目中成功使用了它。

我们的老师面对“功能范式有什么意义”？问题，他回答他没有使用功能语言编写任何更大的项目，并且他不知道功能程序可以使用哪种工具。

那么，他们将使用什么呢？有一些方法吗？或者也许不需要这种东西？

我不能代表所有的函数程序员，但是我所知道的都是从编写顶级函数的类型签名开始的，然后，由于他们需要更多的细节，因此他们编写了辅助函数的类型签名，依此类推。

之所以可行，是因为函数编程中没有副作用，因此所有函数都仅根据其输入和输出来指定。这使得它们的类型签名作为一种设计工具比在命令式编程中更加有用。这就是即使编译器可以推断出它们也看到它们使用的原因之一。

就制图工具而言，在充分尊重您的教授的前提下，自从我离开学校以来，我从未在任何范式中使用过这些工具。

UML标准定义了十几种不同的图表类型，如以下便捷图表所示：

来源：https : //en.wikipedia.org/wiki/File : UML_diagrams_overview.svg

另请参阅图A.5 UML 2.5规范中的结构图和行为图分类法。

^{请注意，这是一个类图的示例，在图类型和抽象图类型之间以is-a子斜体表示。尽管这些图类型实际上是UML元模型中的类，但是该类图对于说明层次结构仍然很有用，而无需与OOP进行任何连接。}

有两种类型显然仅适用于OOP，例如类图或对象图。但是其余的内容不仅仅适用于面向对象的系统，还更广泛地适用。

• 状态机图 – FP不会避免状态，而只是使状态明确。状态机图可能有助于解释控制流或程序中的各种状态转换。

• 活动图 –在与状态机图类似的情况下很有用，但在更高层次上。它们可用于解释各个子系统之间的数据流，或为外部业务流程建模。

• 交互图 –为多个有状态流程之间的交互建模。显然，这对于建模纯功能程序的内部没有用。但是，UML不仅涉及对代码结构进行建模，而且主要涉及提供通用的建模语言。通过交互图，我可以使用交互图来建模系统之间（例如，浏览器和Web服务器之间）的外部行为，即使这些行为是使用FP技术编写的。

• 用例图 –用例和需求独立于用于满足它们的技术。OOP或FP在这里绝对无关紧要。

• 部署图 –此图类型用于描述可运行软件和硬件资源之间的关系。该软件是否以FP语言编写并不重要。

• 组件图 – 如今，大多数功能语言都明确支持模块化编程。组件图描述了组件/模块及其提供的和所需的接口。这使我想起了许多OCaml的Functor模块。

• 概要图 –描述对UML本身的扩展，因此从未实际使用过。

• 复合结构图 –描述复合材料的结构。它可以用于描述数据结构，甚至功能的交互点。维基百科以斐波那契函数图为例：

  

  资料来源：https : //commons.wikimedia.org/wiki/File : Composite_Structure_Diagram.png

  从某种意义上讲，这将是函数程序员的选择，而不是类图，但这似乎太过工程化了……。

• 包图 –包与名称空间的UML等效。这种图类型比单独的图类型更多地是UML语言基础结构的一部分。例如，您可以使用包对大型用例图进行分类。

因此，正如我们已经看到的那样，进行函数式编程时，各种UML图类型仍然有用。

我很少有在设计系统时使用UML，主要使用UML来完成分配的作业或用快速草图传达体系结构轮廓的愿望。即使对于OOP系统，UML也无法提供足够的价值来始终使用它-实际代码显示了超过一千个图表。我可以想象使用类似UML的图表来解释FP程序中各种功能和数据结构之间的依赖关系，但至今尚未做到–我的个人风格更喜欢将OOP和FP融合在一起，其中在本地范围内使用FP技术，但不会影响整体架构。