View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide

Developing with the Unified Modeling Language (UML)

Home   How To   Code Pool   Public Library   Theory   Events
This page describes how to use the Unified Modeling Language (UML) for developing object-oriented SuperCollider programs.

Integration into UML-modeling tool

The UML-integration is done on top of the UML-modeling tool Poseidon for UML, which is a commercial product shown in the screenshot below.

Uploaded Image: SimpleExamplePoseidonScreenshotSmall.png

A free-of-charge “Community Edition” of Poseidon is available for non-commercial use. It will be necessary to register the Community Edition with a real email-address in order to receive long-term license key. However, the registration procedure can be skipped manually every time the program starts, which allows testing for at least some time without registration.



The free-of-charge Community Edition of Poseidon knows about Java code generation only. Installing additional languages besides Java is possible with the commercial editions only. In order to let the Community Edition generate SuperCollider code, the original Java code generation templates have to be replaced with new ones. The application will still label all items related to code generation with "Java", and even the template files to install are still called "JavaClass.vm", "JavaOperation.vm" etc. But despite the "Java"-labels everywhere: with the new templates, SuperCollider source-code will be generated. (Note that this method of customizing Poseidon's code generation process is not as hacky as it sounds. It is officially documented under

A little more on templates...

To create the "/templates"-subfolder in the "/lib"-directory, either unpack the archive "" into the "/lib"-folder (inside the archive, the files are stored in a "/templates"-subfolder, so "/templates" will be created on unpacking). Alternatively, unpack the archive anywhere you like, and create a filesystem soft-link to the "/templates"-directory inside ../lib (using "ln -s /here/is/my/location/templates" inside the "/lib"-folder).
The original installation reads its templates from the compressed archive file "templates.jar" in the "/lib"-folder. This file needs not to be removed, it will be ignored once a "/lib/templates"-folder exists.

Developing SuperCollider classes

The general sequence of steps is as follows (of course, each step will be repeated over and over to change something or add more, this is not a fixed sequence!):

These above steps are done using the UML only. They can all be performed directly inside the diagram. Now, the actual programming instructions which implement the methods need to be entered:
The figure below shows this situation.

Uploaded Image: poseidon_screenshot_sourcecodetab.png

The code-generation dialog allows to specify a target location where to generate the classes. This should be a location that is included in your “.sclang.cfg”, so that the generated classes will be compiled next time the SuperCollider language starts up.
The figure below shows the code generation dialog.

Uploaded Image: poseidon_screenshot_codegen.png
The code generation dialog. (Again, don't be worried about the label “Java” appearing everwhere.)

Mapping from UML elements to SuperCollider constructs

- UML - - SC -
Class Class
Package None, UML-packages are ignored for SuperCollider code-generation. They can be useful inside the UML model to organize classes.
Attribute Variable
Static Attributes Class-Variables
Methods Methods ('messages'/'functions')
Static Methods Class-Methods
0..1 / 1..1 - Relationships Variable (to be used as reference to one instance)
0..* / 1..* - Relationships Variable (to be used as List, continaing references to instances). (User-code must take care of initialization with an empty list.)
Type decalarations of attributes, function-arguments and return-values. None except comments, the SuperCollider language in untyped. But including type declarations in the UML model will automatically generate comments in the code-skeletons which strongly increase readability of the code.
Public (+) visibility of attributes Variable plus automatic getter and setter declaration (“”).
Package (~), Protected (#), Private (-) visibility of attributes None, normal variable is used. Although visibility is not reflected in the SuperCollider language, it may be useful to distinguigh different levels of visibility in the model.
Public (+), Package (~), Protected (#), Private (-) visibility of functions None. Although visibility is not reflected in the SuperCollider language, it may be useful to distinguigh different levels of visibility in the model.

Handling SuperCollider's built-in classes

When using language-internal classes or datatypes, such as 'Object', 'List' or 'int', Poseidon will at first automatically sort those classes into the corresponding packages known from Java. E.g., when using 'List' in a new, previously empty, UML model, the Java packages 'java' and 'java.util' will automatically be created and 'List' will be sorted into there. This does not do much harm, because classes in the 'java.*'-packages will be excluded from code generation anyway.

However, other SuperCollider-classes do not coincidentally match in name with Java classes. As with any class completely new to Poseidon, those classes will automatially be created in the current package when used for the first time. E.g., if a method gets declared, and one parameter is marked as being of type 'Dictionary', a new entry “Dictionary” will show up in the current package. Of course, this class should not be there.

In those cases, DO NOT DELETE the automatically created class which appears to be there in error. (Your declarations in the model would lose their references to this class, too.) Instead, MOVE the class to a "neutral" package which does not belong to the model you are working on. Later, when generating the code, disable code generation for this "neutral" package.
It would be possible to just use the 'java.lang'-package as neutral package, because it gets excluded from code genration anyway. However, it is ugly to keep a 'java'-package in the model. Instead, create a package 'sc-lang' and move the declarations of used SuperCollider-classes like 'Dictionary' there (this is done by selecting the class to move in the element-tree on the left (or somewhere in a diagram), and then change the “Namespace”-entry in the “Properties”-panel to the target package where to move the class). Move also those classes to the 'sc-lang'-package that had automatically been sorted into a 'java.*'-package because of coincidentally Java-like names. Afterwards the 'java'-package of the model can be deleted.


An example of model-based development with SuperCollider is the class-library for XML parsing and formatting, an implementation of the Document Object Model (DOM) DOM-Level-1. The file 'sc-xml-dom.zuml' from XML parsing and formatting - Download contains the parser classes loadable as a UML-model in Poseidon.

See also Unified Modeling Language (UML), XML parsing and formatting, Document Object Model (DOM).


Links to this Page