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?


3 Answers 3


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


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.

  • $\begingroup$ You can argue that this is an advantage in some cases, but disadvantage in some other. $\endgroup$
    – user13253
    Jan 27, 2013 at 1:04
  • 4
    $\begingroup$ @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. $\endgroup$
    – amr
    Jan 27, 2013 at 1:31
  • 5
    $\begingroup$ 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. $\endgroup$ Jan 27, 2013 at 8:47
  • 3
    $\begingroup$ 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. $\endgroup$ Jan 27, 2013 at 8:49

This answer shows how to create UML diagrams in Mathematica. It is related to programming in Mathematica using Object-Oriented Design Patterns as discussed in my answer to the question General strategies to write big code in Mathematica?.

Package functions

This command imports the package UMLDiagramGeneration.m :


The package provides the functions UMLClassNode and UMLClassGraph.

The function UMLClassNode has the signature

UMLClassNode[classSymbol, opts]

UMLClassNode creates a Grid object with a class name and its methods for the specified class symbol. The option "Abstact" can be used to specify abstract class names and methods. The option "EntityColumn" can be used to turn on and off the explanations column.

The function UMLClassGraph that has the signature:

UMLClassGraph[symbols, abstractMethodsPerSymbol, symbolAssociations, symbolAggregations, opts] 

UMLClassGraph creates an UML graph diagram for the specified symbols (representing classes) and their relationships. It takes as options the options of UMLClassNode and Graph.

UML diagram creation

Let us visualize a simple relationship between buildings, people, books, and a client program.

UMLClassGraph[{Library \[DirectedEdge] Building, 
  Museum \[DirectedEdge] Building, 
  Member \[DirectedEdge] Person}, {}, {Library <-> Member, 
  Museum \[DirectedEdge] Member, Client \[DirectedEdge] Building, 
  Client \[DirectedEdge] Person}, {Library \[DirectedEdge] Book},
 "Abstract" -> {Building, Person},
 "EntityColumn" -> False, VertexLabelStyle -> "Text", 
 ImageSize -> Large, GraphLayout -> "LayeredDigraphEmbedding"]

enter image description here

In the diagram above the classes Person and Building are abstract (that is why are in italic). Member inherits Person, Library and Museum inherit Building. Library can contain (many) Book objects and it is associated with Member. Client associates with Building and Person.

Examples of UML generation

Since I mentioned Design Patterns here is a diagram generated over the code of a Mathematica implementation of Decorator:

enter image description here

And here is a diagram for a concrete implementation of Interpreter for Boolean expressions:

enter image description here

(Interpreter is my favorite Design Pattern and I have made several Mathematica implementations that facilitate and extend its application. See these blog posts of mine: "Functional parsers" category in MathematicaForPrediction at WordPress).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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