Graphviz/DOT Diagrams

Activate a GitPitch Paid Plan to unlock Graphviz/Dot Diagrams.

The UML Widget powered by PlantUML makes use of Graphviz/DOT Visualization Software for rendering under the hood. This guide describes how you can leverage Graphviz/Dot support directly to generate sophisticated graphs on any slide.


Graphviz/Dot Widget Usage Conventions

The conventions required to use Graphviz/Dot diagrams are as follows:

  1. Graphviz/Dot diagram descriptions must be defined in a file within your local repository.
  2. These Graphviz/Dot diagram description files must have a .puml extension.
  3. Diagram descriptions must adhere to valid PlantUML Dot syntax.

If you follow these conventions you can then use the following @uml syntax to render a Graphviz/Dot diagram on any slide:


The CSS style… list can make use of any custom styles you define. It can also make use of the built-in span styles giving you control over the rendering width and height of your Graphviz/Dot diagrams.

Note, if you are developing your slide decks using GitPitch Desktop then be aware of the current caching policy for your Graphviz/Dot diagrams.

Learn By Example - A


This sample diagram was generated using the following PUML/Dot syntax:

digraph foo {
  node [style=rounded, width=1, margin="0,0"];
  Supervisory [shape=house, width=1];
  Workstation [label="Engineering/\nTechnician\nWorkstation", style=dotted, color=red, fontcolor=red];
  Controller [fillcolor=yellow, style="rounded,filled", shape=diamond, height=1];
  Actuators [shape=box];
  cl [label="Control\nLoop", shape=none, fontcolor=forestgreen, style=bold, fontsize=18];
  Sensors [shape=box];
  Process [shape=doublecircle, width=1];

  {rank=same; Supervisory; Workstation};
  Supervisory:s -> Controller:n [dir=both, weight=9];
  Controller -> cl -> Process [weight=9, style=invis];
  Controller -> Actuators:n [taillabel="output", labeldistance=3];
  {rank=same; Actuators; cl; Sensors};
  Actuators:s -> Process [headlabel="changes", labeldistance=3, labelangle=35];
  Process -> Sensors:s [weight=5, taillabel="measures", labeldistance=3.2, labelangle=-35];
  Sensors:n -> Controller [weight=5, headlabel="input", labeldistance=3, labelangle=25];

  Supervisory -> Workstation [dir=back, style=dotted, minlen=5, color=red];
  Controller -> Workstation [dir=back, style=dotted, color=red];
  Actuators:nw -> Workstation [weight=0, dir=back, style=dotted, color=red];
  cl -> Workstation [weight=2, style=invis];
  Sensors:ne -> Workstation [weight=3, dir=back, style=dotted, color=red];



Learn By Example - B


This sample diagram was generated using the following PUML/Dot syntax:

digraph G {
  node [shape=record, fillcolor=lightgrey, style="filled,rounded"]
  capture [label="Traffic Capture"]
  capture -> analyze

  subgraph cluster0 {
    label = "Same as\nNetwork Capture Assessment"
    labeljust = left
    style = "filled,rounded"
    color = deepskyblue
    analyze [label="Endpoint and Flow Analysis"]
    analyze:0 -> known:n
    analyze:1 -> unknown:n
    known [label="Known Protocol Analysis"]
    unknown [label="Unknown Protocol Decode"]

  known:s -> enum:0
  unknown:s -> enum:1
  enum [label="Protocol Enumeration"]
  enum -> fuzz
  fuzz [label="Protocol Fuzzing"]
  fuzz -> exploit
  exploit [label="Protocol Exploitation"]

Learn By Example - C


This sample diagram was generated using the following PUML/Dot syntax:

digraph structs {
  node [shape=record];
  write [label="\> | <0>0xA0 | <1>0x00 | <2>0xBE | <3>0xEF | <4>...", fillcolor=lightgrey, style=filled];

  write:0 -> command:4;
    command [label="<0>1|<1>0|<2>1|<3>0|<4>0|<5>0|<6>0|<7>0", fillcolor=whitesmoke, style=filled];
    command:0 -> chip:0;
    command:1 -> chip:1;
    command:2 -> chip:2;
    command:3 -> chip:3;
      chip [label="Chip\nAddress"];
    command:4 -> memblock:0;
    command:5 -> memblock:1;
    command:6 -> memblock:2;
      memblock [label="{Memory Blocks | 000 = Block 0\n001 = Block 1\n010 = Block 2\n011 = Block 3\n100 = Block 4\n101 = Block 5\n110 = Block 6\n111 = Block 7}"];
    command:7 -> rw;
      rw [label="Write = 0\nRead = 1"];

  write:1 -> address;
    address [label="Memory\nLocation"];

  write:2 -> data:0;
  write:3 -> data:1;
  write:4 -> data:2;
    data [label="Bytes to Write\n(max of write buffer)\n(none to move pointer)"];


Learn By Example - D


This sample diagram was generated using the following PUML/Dot syntax:

skinparam monochrome true
skinparam shadowing false
skinparam sequenceArrowThickness 2
skinparam roundcorner 10
skinparam sequenceReferenceAlign center

participant "ModbusTCP Client" as TcpClient
participant "ModbusTCP Server" as TcpServer
participant "vs"
participant "ModbusTCP Client" as UdpClient
participant "ModbusTCP Server" as UdpServer

group ModbusTCP Connection Establishment
  TcpClient o-> TcpServer: TCP SYN (Synchronize)
  TcpServer -> TcpClient: TCP SYN ACK (Acknowledge)
  TcpClient -> TcpServer: TCP ACK

group ModbusTCP vs ModbusUDP Payload
  TcpClient -> TcpServer : ModbusTCP Request
  TcpClient <- TcpServer : TCP ACK
  UdpClient -> UdpServer : ModbusUDP Request
  TcpServer -> TcpClient : ModbusTCP Response
  TcpServer <- TcpClient : TCP ACK
  UdpClient <- UdpServer : ModubsUDP Response

group ModbusTCP Connection Teardown
  TcpClient -> TcpServer: TCP FIN (Finalize)
  TcpClient <- TcpServer: TCP FIN or FIN ACK
  TcpClient <-- TcpServer: TCP ACK
  TcpClient ->x TcpServer: TCP ACK

Graphviz/Dot Diagrams GitPitch Caching Policy

Test-based Graphviz/Dot diagram descriptions maintained within local repository files are converted to SVG images at runtime. This means whether you are developing or sharing a slide deck there can be a small rendering overhead due to the time taken to convert the text-based description to an image.

To ensure this processing overhead does not unduly interfere with smooth development workflows, in particular within GitPitch Desktop , each generated SVG image is cached for up to 60 seconds.

This means if you make changes to any Graphviz/Dot description file you may not see those changes reflected on your slides for up to 60 seconds.