UML 是一个旨在用 OO 语言编写的软件建模的标准，与 Java 齐头并进。尽管如此，它是否可以用于对以函数式编程范例编写的软件进行建模？考虑到嵌入的视觉元素，哪些图表会变得有用？
是否有一种针对函数式编程的建模语言，更具体地说是 Haskell？您推荐哪些用于组合图表的工具？
由 OP 于 2009 年 9 月 2 日编辑：
我正在寻找的是代码中所发生内容的最直观、最简单的表示。易于理解的图表、可视化模型不一定针对其他程序员。我很快就会在 Haskell 中开发一个游戏，但因为这个项目是我的毕业总结工作，所以我需要引入某种形式化的提议解决方案。我想知道是否有一个相当于 UML+Java 标准的东西，但是对于 Haskell。
我应该只坚持故事板、书面描述、非形式化图表（一些浅层流程图式图像）、非形式化用例描述吗？
由 jcolebrand 于 2012 年 6 月 21 日编辑：
请注意，提问者最初想要一个视觉隐喻，现在我们已经有了三年的时间，我们正在寻找更多/更好的工具。原始答案都没有真正解决“视觉隐喻设计工具”的概念，所以......这就是新赏金所寻求提供的。
UML is a standard aimed at the modeling of software which will be written in OO languages, and goes hand in hand with Java. Still, could it possibly be used to model software meant to be written in the functional programming paradigm? Which diagrams would be rendered useful given the embedded visual elements?
Is there a modeling language aimed at functional programming, more specifically Haskell? What tools for putting together diagrams would you recommend?
Edited by OP Sept 02, 2009:
What I'm looking for is the most visual, lightest representation of what goes on in the code. Easy to follow diagrams, visual models not necessarily aimed at other programmers. I'll be developing a game in Haskell very soon but because this project is for my graduation conclusion work I need to introduce some sort of formalization of the proposed solution. I was wondering if there is an equivalent to the UML+Java standard, but for Haskell.
Should I just stick to storyboards, written descriptions, non-formalized diagrams (some shallow flow-chart-like images), non-formalized use case descriptions?
Edited by jcolebrand June 21, 2012:
Note that the asker originally wanted a visual metphor, and now that we've had three years, we're looking for more/better tools. None of the original answers really addressed the concept of "visual metaphor design tool" so ... that's what the new bounty is looking to provide for.
发布评论
评论（11）
查看带有外链的存档版本此处。
截至 2023 年 5 月 26 日，尚无标准建模语言纯函数式编程，但还有其他选择：
1. UML
UML 传统上与面向对象编程 (OOP) 联系在一起，主要是因为它的历史根源1，2，但是人们当然可以尝试将它用于不同的编程范例（或者用于除了建模软件之外的东西） ，就此而言，例如 用例图，本体工程、制造等系统&流程等）。
话虽如此，这个用例似乎没有很多例子。值得注意的一些：
上面的答案提到除了类图之外还有 UML 图类型，它们的使用将使任何程序受益，而与范例无关。请参阅 1 和 使用 UML 的应用 维基百科页面，以及图表：
来源
[1]: < a href="https://www.guru99.com/uml-diagrams.html" rel="nofollow noreferrer">UML 图：历史、类型、特征、版本、工具
[2]：https://stackoverflow.com/a/27861475/1498178
1.1 状态图
来自状态图：复杂系统的视觉形式主义论文：
如果程序不处理状态，那么这不是很有用，但它似乎是一个值得注意的工具。
更多信息和讨论：
2. 图表
2.1 接线图
来自组合性的七个草图：应用范畴论的邀请， 2.2.2 接线图介绍：
示例：
2.2 字符串图
组合性中的七个草图： 《应用范畴论邀请函》提到了弦图，但它们似乎与接线图不同。来自论文使用字符串图的范畴论：
2.3 数据流图
本节扩展了这个答案。
2.3.1“亨德森图”
“这些显示了各个功能如何“插入在一起”” 。来自 3.5.2 无限流 部分“https://sarabander.github.io/sicp/”rel =“nofollow noreferrer”>SICP：
2.3.2 使用的图表在 箭头 文档中
2.4 哈斯图 (维基百科)
"范畴论就是关于组织和分层结构"3 所以 哈斯图可能有用。 UML 类图是“哈斯图的一种形式 ”，因此可以在更一般的意义上使用它来传达依赖关系。
[3] 组合性的七个草图：应用范畴论的邀请，部分
"1.1.2 排序系统"
2.5 交换图 (wikipedia)
示例：
User:Michiexile/MATH198/Lecture 7 Haskell Wiki 中的文章展示了图表及其在 Haskell 中的实现。
范畴论：
3. 形式化方法
3.1 通用系统语言 (USL)（专有？）
请参阅 Hamilton Technologies, Inc. 上的文章 .的主页。
3.2 TLA+
在这里提及 TLA+ 也是明智之举。
4. 工具
4.1
ghc-vis与 Python Tutor 类似，
4.2 Visual Haskell
来自 4.2 Visual Haskell 简介：
4.3 Viskell（工具；最后一次提交：2017 年）
4.4
graphmodHaskell 包4.5 HOPS：高级对象编程系统
看起来没有维护，但看起来很有趣。
在此处查看更多图像/动画。
其他有趣的资源：
“函数建模方法”
DRAKON 视觉语言：“DRAKON 是俄罗斯太空计划规范的视觉语言。”
Yusuf Moosa Motara 的论文：< /p>
编程（请参阅配套视频）
See archived version with outlinks here.
As of May 26, 2023, there is no standard modeling language for pure functional programming, but there are alternatives:
1. UML
UML has traditionally been associated with object-oriented programming (OOP), mostly because of its historical roots1, 2, but one can certainly attempt to use it for different programming paradigms (or for something other than modeling software, for that matter, such as use-case diagrams, ontology engineering, manufacture and other systems & processes, etc.).
With that said, there don't seem to be many examples around for this use case. A noteworthy few:
The answers above mention that there are UML diagram types other than class diagrams, whose use would benefit any program, independent of paradigm. See 1 and the Modeling applications of UML using various diagrams section of the Applications of UML wikipedia page, along with a diagram:
source
[1]: UML Diagrams: History, Types, Characteristics, Versions, Tools
[2]: https://stackoverflow.com/a/27861475/1498178
1.1 Statecharts
From the Statecharts: a visual formalism for complex systems paper:
If the program doesn't deal with state, then this is not very useful but it seems to be a noteworthy tool otherwise.
More info and discussions:
2. Diagrams
2.1 Wiring diagram
From Seven Sketches in Compositionality: An Invitation to Applied Category Theory, section 2.2.2 Introducing wiring diagrams:
Examples:
2.2 String diagram
Seven Sketches in Compositionality: An Invitation to Applied Category Theory mentions string diagrams, but they seem to be different from wiring diagrams. From the paper Category Theory Using String Diagrams:
2.3 Data flow diagrams
This section expands on this answer.
2.3.1 "Henderson diagram"
"These show how individual functions are "plugged together"". From section 3.5.2 Infinite Streams of SICP:
2.3.2 Diagrams used in the Arrows documentation
2.4 Hasse diagram (wikipedia)
"Category theory is all about organizing and layering structures"3 so Hasse diagrams may be useful. A UML class diagram is "a form of Hasse diagram", so it can be used in a more general sense to convey dependency relations.
[3] Seven Sketches in Compositionality: An Invitation to Applied Category Theory, section
"1.1.2 Ordering systems"
2.5 Commutative diagram (wikipedia)
Examples:
User:Michiexile/MATH198/Lecture 7 article in the Haskell Wiki shows diagrams and their implementation in Haskell.
category theory:
3. Formal methods
3.1 Universal Systems Language (USL) (proprietary?)
See articles on Hamilton Technologies, Inc.'s homepage.
3.2 TLA+
It felt prudent to mention TLA+ here as well.
4. Tools
4.1
ghc-visSimilar to Python Tutor,
4.2 Visual Haskell
From section 4.2 An introduction to Visual Haskell:
4.3 Viskell (tool; last commit: 2017)
4.4
graphmodHaskell package4.5 HOPS: The Higher Object Programming System
Seems unmaintained, but looked interesting.
See more images / animations here.
Other interesting resources:
"Functional modeling methods"" on the Function model wikipedia page
DRAKON visual language: "DRAKON is a visual language for specifications from the Russian space program."
Papers by Yusuf Moosa Motara:
programming (see companion video)
是的，Haskell 有广泛使用的建模/规范语言/技术。
它们不是视觉的。
在 Haskell 中，类型给出了部分规范。
有时，该规范完全确定了含义/结果，同时留下了各种实现选择。
超越 Haskell 到具有依赖类型的语言，例如 Agda 和 Agda 。 Coq（以及其他），类型作为完整规范通常更有用。
如果类型不够，请添加正式规范，通常采用简单的函数形式。
（因此，我相信，Haskell 选择的建模语言的答案是 Haskell 本身或“数学”。）
在这种形式中，您给出了一个功能定义，该定义为了清晰和简单而优化，而不是全部为了效率。
该定义甚至可能涉及不可计算的操作，例如无限域上的函数相等。
然后，逐步将规范转换为高效可计算的函数程序的形式。
每个步骤都保留语义（表示），因此最终形式（“实现”）在语义上保证与原始形式（“规范”）等效。
您会看到这个过程有各种名称，包括“程序转换”、“程序推导”和“程序计算”。
典型推导的步骤主要是“方程推理”的应用，并辅以一些数学归纳法（和共归纳法）的应用。
能够执行如此简单而有用的推理是函数式编程语言的主要动机，它们的有效性归功于“真正的函数式编程”的“外延”性质。
（术语“外延”和“真正功能”来自 Peter Landin 的开创性论文 接下来的 700 种编程语言。）
因此，纯函数式编程的口号曾经是“有利于等式推理”，尽管现在我很少听到这种描述。
在 Haskell 中，外延对应于
IO之外的类型以及依赖于IO的类型（例如STM）。虽然指示/非 IO 类型有利于正确的等式推理，但 IO/非指示类型被设计为不利于错误的等式推理。
我在 Haskell 工作中尽可能频繁地使用的从规范派生的一个特定版本就是我所说的“语义类型类态射”(TCM)。
这里的想法是给出数据类型的语义/解释，然后使用 TCM 原理通过类型类实例来确定（通常是唯一的）大多数或全部类型功能的含义。
例如，我说
Image类型的含义是作为 2D 空间的函数。然后中医原理告诉我Monoid、Functor、Applicative、Monad、Contrafunctor的含义 和
Comonad实例，与函数的这些实例相对应。对于具有非常简洁和引人注目的规范的图像来说，这是很多有用的功能！
（规范是语义函数加上语义 TCM 原则必须成立的标准类型类列表。）
然而，我在如何表示图像方面拥有巨大的自由，并且语义 TCM 原则消除了抽象泄漏。
如果您想了解该原理的一些实际示例，请查看论文 具有类型类态射的指称设计。
Yes, there are widely used modeling/specification languages/techniques for Haskell.
They're not visual.
In Haskell, types give a partial specification.
Sometimes, this specification fully determines the meaning/outcome while leaving various implementation choices.
Going beyond Haskell to languages with dependent types, as in Agda & Coq (among others), types are much more often useful as a complete specification.
Where types aren't enough, add formal specifications, which often take a simple functional form.
(Hence, I believe, the answers that the modeling language of choice for Haskell is Haskell itself or "math".)
In such a form, you give a functional definition that is optimized for clarity and simplicity and not all for efficiency.
The definition might even involve uncomputable operations such as function equality over infinite domains.
Then, step by step, you transform the specification into the form of an efficiently computable functional program.
Every step preserves the semantics (denotation), and so the final form ("implementation") is guaranteed to be semantically equivalent to the original form ("specification").
You'll see this process referred to by various names, including "program transformation", "program derivation", and "program calculation".
The steps in a typical derivation are mostly applications of "equational reasoning", augmented with a few applications of mathematical induction (and co-induction).
Being able to perform such simple and useful reasoning was a primary motivation for functional programming languages in the first place, and they owe their validity to the "denotative" nature of "genuinely functional programming".
(The terms "denotative" and "genuinely functional" are from Peter Landin's seminal paper The Next 700 Programming languages.)
Thus the rallying cry for pure functional programming used to be "good for equational reasoning", though I don't hear that description nearly as often these days.
In Haskell, denotative corresponds to types other than
IOand types that rely onIO(such asSTM).While the denotative/non-
IOtypes are good for correct equational reasoning, theIO/non-denotative types are designed to be bad for incorrect equational reasoning.A specific version of derivation-from-specification that I use as often as possible in my Haskell work is what I call "semantic type class morphisms" (TCMs).
The idea there is to give a semantics/interpretation for a data type, and then use the TCM principle to determine (often uniquely) the meaning of most or all of the type's functionality via type class instances.
For instance, I say that the meaning of an
Imagetype is as a function from 2D space.The TCM principle then tells me the meaning of the
Monoid,Functor,Applicative,Monad,Contrafunctor, andComonadinstances, as corresponding to those instances for functions.That's a lot of useful functionality on images with very succinct and compelling specifications!
(The specification is the semantic function plus a list of standard type classes for which the semantic TCM principle must hold.)
And yet I have tremendous freedom of how to represent images, and the semantic TCM principle eliminates abstraction leaks.
If you're curious to see some examples of this principle in action, check out the paper Denotational design with type class morphisms.
我们使用定理证明器进行形式化建模（带验证），例如 Isabelle 或 Coq。有时，我们在推导“低级”Haskell 实现之前，使用特定于领域的语言（例如 Cryptol）进行高级设计。
通常我们只是使用 Haskell 作为建模语言，并通过重写得出实际的实现。
QuickCheck 属性以及类型和模块分解也在设计文档中发挥作用。
We use theorem provers to do formal modelling (with verification), such as Isabelle or Coq. Sometimes we use domain specific languages (e.g. Cryptol) to do the high level design, before deriving the "low level" Haskell implementation.
Often we just use Haskell as the modelling language, and derive the actual implementation via rewriting.
QuickCheck properties also play a part in the design document, along with type and module decompositions.
是的，哈斯克尔。
我的印象是，使用函数式语言的程序员在考虑他们的设计时并不觉得需要简化他们选择的语言，这是查看 UML 为您所做的事情的一种（相当圆滑的）方式。
Yes, Haskell.
I get the impression that programmers using functional languages don't feel the need to simplify their language of choice away when thinking about their design, which is one (rather glib) way of viewing what UML does for you.
我观看了一些视频采访，并阅读了一些对埃里克·梅耶尔和西蒙·佩顿·琼斯等人的采访。似乎在建模和理解问题域时，他们使用类型签名，尤其是函数签名。
序列图（UML）可以与函数的组合相关。
静态类图 (UML) 可能与类型签名相关。
I have watched a few video interviews, and read some interviews, with the likes of erik meijer and simon peyton-jones. It seems as when it comes to modelling and understanding ones problem domain, they use type signatures, especially function signatures.
Sequence diagrams (UML) could be related to the composition of functions.
A static class diagram (UML) could be related to type signatures.
虽然不建议使用（因为它似乎无法下载），但是 HOPS系统可视化术语图，这通常是功能程序的方便表示。
它也可以被视为一种设计工具，因为它支持记录程序以及构建程序；我相信，如果您愿意的话，它也可以逐步重写术语，以便您可以看到它们展开。
不幸的是，我相信它不再被积极开发。
Although not a recommendation to use (as it appears to be not available for download), but the HOPS system visualizes term graphs, which are often a convenient representation of functional programs.
It may be also considered a design tool as it supports documenting the programs as well as constructing them; I believe it can also step through the rewriting of the terms if you want it to so you can see them unfold.
Unfortunately, I believe it is no longer actively developed though.
在 Haskell 中，您可以按类型建模。
只需从编写函数、类和数据签名开始，无需任何实现，并尝试使类型适合。下一步是快速检查。
例如，对排序进行建模：
然后测试
，最后实现......
In Haskell, you model by types.
Just begin with writing your function-, class- and data signatures without any implementation and try to make the types fit. Next step is QuickCheck.
E.g. to model a sort:
then tests
and finally the implementation ...
我意识到我参加聚会迟到了，但我仍然会给出我的答案，以防有人发现它有用。
我想我会选择 SADT/IDEF0 等系统方法。
可以使用 Linux 上可用的 Dia 程序制作此类图表， Windows 和 MacOS。
I realize I'm late to the party, but I'll still give my answer in case someone would find it useful.
I think I'd go for systemic methodologies of the likes of SADT/IDEF0.
Such diagrams can be made with the Dia program that is available on both Linux, Windows and MacOS.
您可以按照实时信号处理：数据流中所述创建数据流处理网络模型，视觉和函数式编程 作者：Hideki John Reekie
例如，对于像 (Haskell) 这样的代码：
视觉表示为：
You can a data flow process network model as described in Realtime Signal Processing: Dataflow, Visual, and Functional Programming by Hideki John Reekie
For example for code like (Haskell):
The visual representation would be:
用数学建模 Haskell 有什么意义？我认为 Haskell 的全部意义在于它与数学密切相关，以至于数学家可以拿起它并运行它。为什么要将一种语言翻译成它本身？
当使用另一种函数式编程语言 (f#) 时，我在白板上使用图表来描述大块，然后使用 UML 和类以 OO 方式对系统进行建模。 f# 中的构建块存在轻微的不匹配（将类分为数据结构和作用于它们的函数）。但从商业角度来看，这是一种享受。我想补充一点，问题是面向业务/网络的，并且不知道该技术对于更财务的东西是否有效。我想我可能会将函数捕获为没有状态的对象，并且它们应该很好地适应。
这完全取决于您工作的领域。
What would be the point in modelling Haskell with Maths? I thought the whole point of Haskell was that it related so closely to Maths that Mathematicians could pick it up and run with it. Why would you translate a language into itself?
When working with another functional programming language (f#) I used diagrams on a white board describing the large blocks and then modelled the system in an OO way using UML, using classes. There was a slight miss match in the building blocks in f# (split the classes up into data structures and functions that acted upon them). But for the understanding from a business perspective it worked a treat. I would add mind that the problem was business/Web oriented and don't know how well the technique would work for something a bit more financial. I think I would probably capture the functions as objects without state and they should fit in nicely.
It all depends on the domain your working in.
我使用 USL - 通用系统语言。我正在学习 Erlang，我认为它非常适合。
可惜文档非常有限，没有人使用它。
更多信息此处。
I use USL - Universal Systems Language. I'm learning Erlang and I think it's a perfect fit.
Too bad the documentation is very limited and nobody uses it.
More information here.