What's the analogue of UML in Mathematica land?

Question

What's the analogue of Unified Modeling Language (UML) in Mathematica land? Mathematica has elements of object-orientation, but most Mathematica programs or applications aren't of object-oriented architecture. But, don't people need any representation of the data structure and information architecture, to plan, visualize, and manage the design? Is there an analogue of UML in Mathematica land?

Answer 1

I think the simple answer is, there isn't one, but you could always just use UML itself, particularly for behavioral diagrams, even if the code isn't object oriented. You wouldn't use class or object diagrams, but there is nothing to stop you from using, say, a component diagram.

You may find the tutorial and white paper on building large software systems in Mathematica to be useful.

I suspect the reason why this topic doesn't get a lot of discussion in the Mathematica community is that most of us aren't building large systems. But see this question.

It should be noted that, because Workbench is a branded version of Eclipse, you can install one of the many UML tools into it. The screenshot below shows an example of a UML model file inside a Mathematica project in the Eclipse workbench, which I created using the UML2 Extender package. As an added bonus, the other files shown in the tab are Mylyn local tasks that I've been using to track things to do to finish this particular project. In this particular instance, I’ve used the instructions in this excellent question and answer to install the Mathematica development environment into a standard Eclipse Kepler installation.

Answer 2

The answer to the more general question of how necessary "software architecturizationing" is in Mathematica is, in short: Not that necessary.

The reason is basically 1) lists 2) dynamic typing and 3) lists + dynamic typing. For example, Mathematica doesn't need classes/OO because lists allow you to represent a huge swath of data structures. You would gain little on top of this through OO.

---

The design philosophy of the Mathematica API takes full advantage of this. Let's say you want to get the current date. In a static language, say C#, you would write:

DateTime.Now

This returns a DateTime object. To get information out of this object, your program has to know the signature of the object.

In Mathematica, you would write:

Date[]

This returns a list. Just a regular everyday normal list. To get information out of it, your program doesn't have to know its signature, and since the entire Mathematica API uses lists as the lingua franca, you can feed the output of Date[] directly into other functions without having to manually pull out any data. Example:

Row[Framed /@ Date[]]

---

I don't know of any static languages that have a lingua franca like this. There are a lot of poor approximations though.

Of course in large projects you absolutely do have to worry about architecture, but I would suggest keeping in mind the power and straightforwardness-of-design that is enabled by lists and the general philosophy of Mathematica.