How are clojure/lisp programs modeled as a diagram? [closed]

Question

I've tried wedging my clojure diagrams into what's available in UML, using class-blocks as the file-level namespaces and dependency links to show relationships, but it's awkward and tends to discourage functional patterns. I've also tried developing ad-hoc solutions, but I can't discover a solution that works as well as UML with, say, Java (simple directed graphs seem to work in a vague manner, but this the results aren't detailed enough). Furthermore, I'm not finding anything on the web about this.

Just to be clear, I'm not trying to do anything fancy like code generation; I'm just talking about pen-and-paper diagrams mostly for my own benefit. I'm assuming I'm not the first person to have ever considered this for a lisp language.

What solutions have been proposed? Are there any commonly-used standards? What do you recommend? What tools do you use?

Answer 1

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.

Answer 2

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.