Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Well UML isn't language oriented ... – Dr. belisarius Jan 26 '13 at 21:53
up vote 15 down vote accepted

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.

enter image description here

share|improve this answer

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:


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:


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.

share|improve this answer
You can argue that this is an advantage in some cases, but disadvantage in some other. – qazwsx Jan 27 '13 at 1:04
@Problemania This is a tricky discussion in general (eg static vs dynamic typing) and it often boils down to how people are wired (eg introverted/abstract intuition vs extroverted/grounded intuition). But I think it's important to point out this lingua franca aspect of Mathematica because it's almost entirely non-existent in standard software engineering. Most people haven't used a language that has this and don't recognize its power. The closest thing in mainstream software development would probably be Javascript's object literals, a.k.a. JSON. – amr Jan 27 '13 at 1:31
I can tell from experience that lists are not enough to build larger systems, since what is convenient for smaller pieces (and indeed, leads to ultra-rapid development) starts getting in the way when your code base gets larger. The biggest problem with lists is that interface is not separated from implementation. The code may still be short, but won't be very readable and / or maintainable. It is deceptively easy to go through several complex/nontrivial data transformations in a single line, using lists, but this quickly becomes a write-only code. – Leonid Shifrin Jan 27 '13 at 8:47
In fact, I've encountered quite a few problems where OO is very beneficial for code organization / readability/ ease of refactoring, even though I am aware of at least some of other programming techniques offered by Mathematica. – Leonid Shifrin Jan 27 '13 at 8:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.