UML可以用来模拟function程序吗?

更具体地说,你如何build立一个function程序的模型,或者使用函数式(没有类)使用图来开发,而不是使用文本表示,是否有可能,有人可以指引我到最近的应用程序来做到这一点(开放源代码,免费,如啤酒,如果你愿意)

function程序员通常没有很多用于图表。 许多function程序员(但不是全部)发现,写入types是封装OO程序员放入UML图表的devise关系的好方法。

因为可变状态在函数式程序中是罕见的,所以没有可变的“对象”,所以通常不需要绘制它们之间的关系。 虽然一个函数可能会调用另一个函数,但是这个属性对于系统的总体devise通常并不重要,而仅仅是执行调用的函数。

如果我强烈地需要绘制一个function程序,我可能会使用一个概念图 ,其中types或function扮演着概念的angular色。

UML不仅是类图,你知道吗?

大多数其他图types(用例图,活动图,顺序图…)完全适用于纯函数式编程风格。 即使是类图也可能是有用的,如果你只是不使用属性和关联,并将“类”解释为“相关函数的集合”。

UML是不同typesbuild模的汇编。 如果你正在谈论对象图(类图),那么你不会find任何适合你的用途的东西。 但是,如果您正在讨论交互图(活动图)或需求图(用例图),当然他们会帮助您,并成为UML基础的一部分。

function程序员有自己的UML版本,所以叫做分类理论 。

(这是有一定的道理的,但是它的意思是用幽默来阅读)。

UML是一种对象方法,因为在graphics层面上,你不能定义functionbuild模。 一个窍门是在模型中直接添加约束和注释,而不是在图层中添加。 我的意思是,你可以在元模型中直接编写每个模型元素的完整function文档,并且只使用UML编辑器显示一个对象视图。 这可能是愚蠢的,但我发现这个法语语言完全相同的主题,并使用EclipseUML Omondo:OCL和UML 2.2(法语3mn演示): http : //www.download-omondo.com/regle_ocl.swf

本演示解释了如何直接在元模型级别的方法上添加约束。 这个演示的有趣之处在于,对整个项目使用单一模型可以足够灵活地扩展传统UML,避免使用SysML,BPMN,DSL加法模型,因为所有信息都build立在UML 2.2元模型的顶部。 我不知道这是否会取得成功,但这个举措是非常有趣的,因为降低build模的复杂性,开辟新的领域!

为了build立一个function程序的模型,使用图表,而不是文本表示,你可以使用象Viskell或Luna编程的符号

在这里输入图像说明

我想你可以创build一个名为noclass的类,并把函数作为方法。 另外,你可能想把noclass分成多个类别的函数。

我没有真正尝试在UML中build模一个大系统,然后去实现一个function,但是我不明白为什么它不能工作。

假设实现将是Haskell,我将首先使用类图来定义types及其关系。 根据主要参数将类分配给类,但要记住,这只是UML的一个假象。 如果为了保存所有的function而创build一个虚构的单例对象更容易,那也可以。 如果应用程序需要状态,那么在状态图或时序图中build模时就没有问题。 如果我需要一个自定义monad来实现应用程序特定的sorting语义,那么这可能会成为一个刻板印象; 目标是描述应用程序在领域中的作用。

主要的一点是UML 可以用来模拟function实现的程序。 你必须记住一个到实现的映射(logging它并不会有什么坏处),而且这个拟合是非常不恰当的。 但是可以做到,甚至可以增加价值。

我意识到这是一个古老的线程,但我不了解这个问题。

一个类仅仅是一个概念的抽象,它把它的方法的function以更人性化的方式联系在一起。 例如,类WaveGenerator可能包含Sine,Sawtooth和SquareWave方法。 所有三种方法都与类Generator相关。 但是,三者都是无国籍的。 如果devise正确,则不需要在方法外存储状态信息。 这使得他们成为无状态的对象 – 如果我理解正确的话 – 使它们成为function范式中一个核心概念的不变函数。

从概念的angular度来看,我没有看到任何区别

让信封正弦= …

让Envelope Generator.Sine = …

除了后者可以更好地洞察function的目的之外。