Drawing diagrams with PlantUML

Custom Images

In addition to the integrated icons, you can also create custom images. Listing 9 shows the source for embedding a custom image, and Figure 8 shows its output.

Listing 9

Embedding Images

01 @startuml
02 sprite tux linuxtux.png
03 Linux->World : I am here <$tux>, where are you?
04 Linux<-World : I am SO glad to see you!
05 @enduml
Figure 8: You can easily embed any image you want in your diagrams.

To do this, define a sprite (a graphical element) with a label (tux in my example) and associate it with an actual image on your hard drive. Next, you can place the image where you want by calling its label with the syntax shown in line 3 of Listing 8. In addition to regular images, you may define and embed custom sprites [7], which are monochrome images that are defined similarly to traditional ASCII art right inside your UML code:

sprite $foo1 {

This format is less esoteric than it may seem. Each hexadecimal digit inside the curly braces corresponds to one pixel of the image, and its value corresponds to the gray level of that pixel, with   being white, and F being black. For further details on embedded sprites, see the PlantUML guide [5].

UML Programming

UML's creators have given it several capabilities of a real programming language.

You can include comments in your UML files to make them more readable. Single line comments start with one simple quote ('), and multiline comments are enclosed by /' and '/ tags.

Lines that start with exclamation marks (!) are preprocessing directives, with which you can give PlantUML general instructions or make it interact with your system. The following

!log Now generating a Gantt Diagram

tells PlantUML to log a message, by writing it to its standard output.

PlantUML also uses variables and functions. PlantUML variables can only contain strings or integer numbers; it is good practice to give them names starting with a dollar sign ($), like Perl. Besides storing values for later use, variables can also be used for simple flow control, to decide what to draw where:

Alice -> Bob : Are you free tonight?
!if ($day == "Saturday")
Alice <- Bob : yes
Alice -> Bob : no, I'm sorry

PlantUML supports three different types of functions: built-in, void, and return functions. Built-in functions, which have names starting with %, include operators like %strlen (string length) or %substr (substring extraction). Other built-in functions give access to system information, like file location or the current date.

Void and return functions are recognizable, because, like variables, their names must start with a dollar sign ($). The difference is simple between void and return functions and summarized in Listing 10.

Listing 10

Void and Return Functions

01 !function $warning($source, $recipient)
02 $source --> $recipient : Warning! You have been hacked!
03 !endfunction
04 !function $halfvalue($a)
05 !return $a/2
06 !endfunction

Void functions directly insert something (normally one statement) into the UML diagram description. In Listing 10, the $warning function (line 1) will print a warning from user $source to user $recipient whenever it is called, obviously replacing $source and $recipient with the current values of those variables. Return functions perform a calculation or string processing and return the result (lines 4 and 5); they are often called from other functions.

In both void and return functions, you can define local variables, which are not visible from outside the function, and set default values for the arguments.

Code Management

In UML, as in software in general, reuse is almost always good, and duplication is almost always bad. You can put all the configuration and formatting functions that you regularly use in one file and make PlantUML load it as follows:

java -jar /path/to/plantuml.jar -config "./config.cfg" dir1

To do the same thing with the actual drawing code (e.g., the initial part of a sequence exchange or flow diagram) that you want to duplicate in other diagrams, you can write the corresponding code once (maybe packaging it as a function) in one file. Then !include that file in other files every time you need it as follows:

!include common-diagrams-section.iuml
.. your other UML code here

By doing this, any change in that single file will be seen and reloaded by all the files that include it the next time you run PlantUML, just as if you had copied and pasted common-diagrams-section in each file. The !include directive supports URLs, so you may even load code directly from the Internet or your company network. By default, a file can only be included once. You may include the same file several times in your code with the !include_many directive, but think twice before doing it: It may make your code unmanageable.

Syntax-wise, you may also put several independent blocks of common code in the same file, each within its own @startuml/@enduml statements, and identify each of those blocks by their number. A directive like !include myuml.txt!1 will then load only the second (numbering starts from  ) block within myuml.txt. To improve code readability, you can assign names to a block


and then include only that block with this statement

!include foo.txt!SOME_IDENTIFIER

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More