A few days ago, Tatiana Fesenko asked me my opinion on how to use UML to model functional code. My honest answer that I had no f*** idea but that we could ask you to give your view on this. So, this is her question:
Unified Modeling Language (UML) is probably the first language which comes to our minds when we are talking about modeling, but it is tightly related to the object-related paradigm. Is it really applicable to functional languages? Some people suggest using state-machine, activity or sequence for functional languages, but they only describe behaviour, not structure. Maybe, UML is not the best choice for functional languages then. How can we model the structure of programs written in functional style?
This question was asked on StackOverFlow more than three years ago, but no “good” answer was given at that time. In the modern world of distributed teams successful communication is essential. Visualizing code is one of the ways of communication between developers. Which techniques do you, readers of the Software Modeling Blog, use to visualize functional code?
So, can you help? Anybody has any experience on this?
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
“Is UML really applicable to functional languages?”
No.
There are however some graphical languages for functional programming (based on a few minutes of searching for ‘functional programming visual’):
DRAKON-Erlang doesn’t look like a particularly successful attempt:
http://drakon-editor.sourceforge.net/drakon-erlang/seq.html
I think control flowcharts aren’t a good basis for an FP language – I’d suggest focusing on dataflow instead.
Sifflet focuses on data flow, and makes more sense to me:
http://mypage.iu.edu/~gdweber/software/sifflet/doc/tutorial.html
It is however an example of another kind of “U.M.L.”, what I call a “Unitype Modelling Language” – there’s only one visual type of object you can place in the diagram!
The most useful thing I can see on my short trip through this field is VFPE:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.1317&rep=rep1&type=pdf
I wouldn’t say the resulting language is the best possible, particularly not graphically, but the author of the thesis has made a good attempt at examining the various factors, tradeoffs and alternatives of a visual language for FP, and the thinking is explained in the thesis. It goes beyond a static language to offer a visual programming environment. An appendix 11.4 analyses VFPE according to Green’s Cognitive Dimensions. Nowadays I think I’d use Daniel L. Moody’s work [1], but that wasn’t available then.
Of course there are also things like Ptolemy and LabVIEW, that are sufficiently successful in their own fields that I won’t attempt to critique them here.
In a sense I think the problem with the idea of a “visual language for functional programming” is that it’s often an attempt to turn a general purpose textual language into a visual programming language. This results in the same kind of problems that killed the attempt to create a visual programming language based on 3GLs. The concepts that result are simply too low-level to make drawing the diagrams worthwhile, so practitioners prefer to stick with the textual format. Indeed, functional programming languages often have fewer concepts than 3GLs, and to be less verbose in their textual representations, so the resulting visual FP language has too few concepts to be a good language, and it’s being compared with a textual format that isn’t suffering from the incidental complexity of something like Java.
It’s interesting to note that the problems I see in these languages are the same as problems identified in non-FP visual DSLs [2]. It looks like there’s nothing particular to FP here, which also gives hope for a good, useful, visual language for FP – admittedly probably one focused on a particular domain. It would just take someone who knows FP, a domain, and takes the time to learn from others’ research and experiences in what works and doesn’t work in visual languages. At least for the language design and code generation a language workbench would make creating such a language and its editor support much easier – again, there doesn’t seem to be anything specific about FP that would mean it needs anything special in that respect.
[1] http://www.slideshare.net/stevekmcc/concrete-syntax-matters, based on
http://www.dama.org.au/wp-content/uploads/2013/02/IEEE-TSE-35-5-November-December-2009-The-Physics-of-Notations-D.L.Moody_.pdf The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering, D. Moody, IEEE Transactions on Software Engineering 01/2010; DOI:10.1109/TSE.2009.67
[2] S. Kelly and R. Pohjonen, “Worst Practices for Domain-Specific Modeling”, IEEE Software, vol. 26, no. 4, pp. 22-29, July/Aug. 2009, doi:10.1109/MS.2009.109, http://www.metacase.com/papers/WorstPracticesForDomain-SpecificModeling.html
Thank you for sharing your ideas with us, Steven.
I like your idea to go domain specific and share your love to domain-specific languages in general. By the way, I enjoyed reading the slides of the “Concrete Syntax Matters” which motivates to watch the video on infoq.
Interesting to notice that most of visualisation attempts for FL focus on *behaviour* of a system (e.g. flowcharts or data flow) rather than on its *structure*. While the most popular types of UML diagrams are structural, use case and sequence (interaction) IMHO. Functional programs don’t have classes, but they still have the structure, because we can identify logical parts of code and how they *relate* to each other. Their structure still deserve some high-level visual documentation which highlights important details. This documentation can be informal. It’s particularly helpful for reverse-engineering of already existing code. Graphical or textual? Based on the slide 34 of your “Concrete Syntax Matters” the graphical notation is preferential. I agree with it. In many cases we don’t need to generate any artifacts out of diagrams so we can keep them high-level and avoid going deeply into details.
To sum-up, since there is no widely known general solution, one can improvise and create a graphical DSL for the documented system. If there are resources to implement tooling – great! Otherwise this DSL can be unofficial and used to sketch the diagram on a whiteboard.
Rob Vens also gives his opinion on this topic here: > http://www.robvens.com/en/uml-functional-programming/
That’s an interesting perspective.
I will just paste a summarising quote from this article:
> So UML is not so different from OO. It is just a view on the same thing: a complex system. Object orientation, and UML as a domain-independent language, can be used to describe any problem domain efficiently, and help with the complexities in those domains. And you are free to implement your solution in an object-oriented language like Smalltalk, or a functional language like Haskell. OO is domain-agnostic, and implementation-agnostic.
IMO a sequence diagram would a good starting point–it’s easy to determine if all elements have only constructors and returns; if you are using functions you’re probably dealing with concurrency too. I’m not sure what sort of convention would help identify unintentional side effects.
I can’t believe Structured Analysis and Structured Design never made it into this conversation. The context diagram and data flow diagram provided visual functional decomposition. (and made it evident why we needed object technology)
I’ll be looking into Lean Sigma 6 for how to apply it to FP modeling.