It depends on what you want to describe in your program.
Dependencies
Use class diagrams to model the dependencies between namespaces; in this case, it's more clear if you use packages instead of classes in a diagram.
You can also use class diagrams to model dependencies between actors
Data flow
You can also use Communication Diagrams to model the flow of data in your program. In this case, depict each namespace as an entity and each function as a method of that entity.
Or, in the case of actors, depict each actor as an entity and each message as a method.
In any case, it's not useful to try and describe the algorithm of your program in UML. In my experience, they are better described in comments in the source file.
I think its less about the language and more about your conceptual model. If you are taking a "stream processing" approach then a data-flow network diagram might be the right approach as in some of the Scheme diagrams in SICP. If you are taking a more object oriented approach (which is well supported in Lisp) then UML activity diagrams might make more sense.
My personal thought is to model the flow of the data and not the structure of the code because from what i'v seen of large(not really that large) Clojure projects the code layout tends to be really boring, with a huge pile of composeable utilities and one class that threads them together with map, redure, and STM transactions.
Clojure is very flexible in the model you choose and so you may want to go the other way around this. make the diagram first then choose the parts and patterns of the language that cleanly express the model you built.
Well, UML is deeply rooted in OO design (with C++!), so it will be very difficult to map a functional approach with UML. I don't know Clojure that well but you may be able to represent the things that resemble Java classes and interfaces (protocols?), for all the others it will be really hard. FP is more like a series of transformations from input to output, there's no clear UML diagram for that (maybe activity diagrams?). The most common diagrams are for the static structure and the interaction between objects, but they aren't really useful for the FP paradigm. Depending on your goal the component and deployment diagrams can be applicable.
I don't think something like UML would be a good fit for Clojure - UML is rather focused on the object oriented paradigm which is usually discouraged in Clojure.
When I'm doing functional programming I tend to think much more in terms of data and functions:
What data structures do I need? In Clojure this usually boils down to defining a map structure for each important entity I am dealing with. A simple list of fields is often enough in simple cases. In more complex cases with many different entities you will probably want to draw a tree showing the structure of your data (where each node in the tree represents a map or record type)
How do these data structures flow through different transformation functions to get the right result? Ideally these are pure functions that take an immutable value as input and produce an immutable value as output. Typically I sketch these as a pipeline / flowchart.
If you've thought through the above well enough, then converting to Clojure code is pretty easy.
Define one or more constructor functions for your data structures, and a write a couple of tests to prove they are working
Write the transformation functions bottom up (i.e. get the most basic operations working and tested first, then compose these together to define the larger functions). Write tests for every function.
If you need utility functions for GUI or IO etc., write them on demand as they are needed.
Glue it all together, testing at the REPL to make sure everything is working.
Note that you source files will typically also be structured in the sequence listed above, with more elementary functions at the top and the higher level composed functions towards the bottom. You shouldn't need any circular dependencies (that's a bad design smell in Clojure). Tests are critical - IMHO much more important in a dynamic language like Clojure than in a statically typed OOP language.
The overall logic of my code is usually the last few lines of my main source code file.
I have been wrestling with this as well. I find flow charts work great for basic functions and data. It's easy to show the data and data flow that way. Conditionals and recursion are straightforward. UML sequence/collaboration diagrams can capture some of the same info pretty well.
However, once you start using HOF, this does not work well at all.
Normal UML diagrams for packages work ok for namespaces, not that that does much.
发布评论
评论（6）
这取决于您想在程序中描述的内容。
依赖关系
使用类图对命名空间之间的依赖关系进行建模；在这种情况下，如果在图中使用包而不是类会更清楚。
您还可以使用类图来建模参与者之间的依赖关系
数据流
您还可以使用通信用于对程序中的数据流进行建模的图表。在这种情况下，将每个名称空间描述为一个实体，将每个函数描述为该实体的一个方法。
或者，对于参与者，将每个参与者描述为一个实体，将每条消息描述为一个方法。
无论如何，尝试用 UML 描述程序的算法是没有用的。根据我的经验，源文件中的注释可以更好地描述它们。
It depends on what you want to describe in your program.
Dependencies
Use class diagrams to model the dependencies between namespaces; in this case, it's more clear if you use packages instead of classes in a diagram.
You can also use class diagrams to model dependencies between actors
Data flow
You can also use Communication Diagrams to model the flow of data in your program. In this case, depict each namespace as an entity and each function as a method of that entity.
Or, in the case of actors, depict each actor as an entity and each message as a method.
In any case, it's not useful to try and describe the algorithm of your program in UML. In my experience, they are better described in comments in the source file.
我认为这与语言无关，而与概念模型有关。如果您采用“流处理”方法，那么数据流网络图可能是正确的方法，如某些SICP 中的方案图。如果您采用更加面向对象的方法（Lisp 对此提供了很好的支持），那么 UML 活动图可能更有意义。
I think its less about the language and more about your conceptual model. If you are taking a "stream processing" approach then a data-flow network diagram might be the right approach as in some of the Scheme diagrams in SICP. If you are taking a more object oriented approach (which is well supported in Lisp) then UML activity diagrams might make more sense.
我个人的想法是对数据流而不是代码结构进行建模，因为从我所看到的大型（不是那么大）Clojure 项目来看，代码布局往往非常无聊，具有一大堆可组合实用程序和一个将它们与映射、redure 和 STM 事务线程在一起的类。
Clojure 在您选择的模型中非常灵活，因此您可能想采取相反的方式。首先绘制图表，然后选择能够清晰表达您构建的模型的语言部分和模式。
My personal thought is to model the flow of the data and not the structure of the code because from what i'v seen of large(not really that large) Clojure projects the code layout tends to be really boring, with a huge pile of composeable utilities and one class that threads them together with map, redure, and STM transactions.
Clojure is very flexible in the model you choose and so you may want to go the other way around this. make the diagram first then choose the parts and patterns of the language that cleanly express the model you built.
嗯，UML 深深植根于 OO 设计（使用 C++！），因此用 UML 映射功能方法将非常困难。我不太了解 Clojure，但你也许能够表示类似于 Java 类和接口（协议？）的东西，而对于所有其他东西来说，这将非常困难。
FP 更像是一系列从输入到输出的转换，没有明确的 UML 图（也许是活动图？）。最常见的图用于静态结构和对象之间的交互，但它们对于 FP 范式并不是真正有用。
根据您的目标，组件和部署图可能适用。
Well, UML is deeply rooted in OO design (with C++!), so it will be very difficult to map a functional approach with UML. I don't know Clojure that well but you may be able to represent the things that resemble Java classes and interfaces (protocols?), for all the others it will be really hard.
FP is more like a series of transformations from input to output, there's no clear UML diagram for that (maybe activity diagrams?). The most common diagrams are for the static structure and the interaction between objects, but they aren't really useful for the FP paradigm.
Depending on your goal the component and deployment diagrams can be applicable.
我认为像 UML 这样的东西不太适合 Clojure - UML 更注重面向对象的范例，而这在 Clojure 中通常是不鼓励的。
当我进行函数式编程时，我倾向于更多地考虑数据和函数：
如果您已经充分考虑了上述内容，那么转换为 Clojure 代码就非常容易了。
请注意，您的源文件通常也会按照上面列出的顺序构建，更基本的函数位于顶部，更高级别的组合函数位于底部。您不应该需要任何循环依赖（这在 Clojure 中是一种糟糕的设计味道）。测试至关重要 - 恕我直言，在像 Clojure 这样的动态语言中比在静态类型的 OOP 语言中更重要。
我的代码的整体逻辑通常是我的主源代码文件的最后几行。
I don't think something like UML would be a good fit for Clojure - UML is rather focused on the object oriented paradigm which is usually discouraged in Clojure.
When I'm doing functional programming I tend to think much more in terms of data and functions:
If you've thought through the above well enough, then converting to Clojure code is pretty easy.
Note that you source files will typically also be structured in the sequence listed above, with more elementary functions at the top and the higher level composed functions towards the bottom. You shouldn't need any circular dependencies (that's a bad design smell in Clojure). Tests are critical - IMHO much more important in a dynamic language like Clojure than in a statically typed OOP language.
The overall logic of my code is usually the last few lines of my main source code file.
我也一直在努力解决这个问题。我发现流程图非常适合基本功能和数据。以这种方式显示数据和数据流很容易。条件和递归很简单。 UML 序列/协作图可以很好地捕获一些相同的信息。
然而，一旦你开始使用 HOF，这根本就不起作用。
包的普通 UML 图对于名称空间来说可以正常工作，但作用不大。
I have been wrestling with this as well. I find flow charts work great for basic functions and data. It's easy to show the data and data flow that way. Conditionals and recursion are straightforward. UML sequence/collaboration diagrams can capture some of the same info pretty well.
However, once you start using HOF, this does not work well at all.
Normal UML diagrams for packages work ok for namespaces, not that that does much.