Hermes/dl Designe Tool Documentation

Author:

Matthew Knowles

Screen Shot

Introduction

The Hermes/DL Design Tool Project was started as a program that could be used for designing software projects using the Hermes Design Language (Heremes/dl for short). This design language was created by Alexandre R. J. Francois as design language that could be intuitively used for developing projects with significant interactive components that require a high level of concurrency. The other major goal of the language was that it should be simple enough that it is accessible by multiple disciplines.

The Design Tool Project

At the present time, although this design language exists, there wasn't a tool that could be used to properly create the graphs used for Hermes/dl in an interactive, collaborative way. As a result, this project was initialized to create such a tool.

GraphML File Format

In order to save and load data, I decided to use a standard XML based graph file format called GraphML.

The data file is broken up into four sections:

The first section contains the generic GraphML header.

<?xml version="1.0" encoding="UTF-8"?>
<graphml xmlns="http://graphml.graphdrawing.org/xmlns"
        xmlns:svg="http://www.w3.org/2000/svg"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns
        graphml+svg.xsd">

This is followed by a list of all of the extra data types that we will be storing with each node. Using this allows us to comply with the GraphML standard while still incorporating the extra parts of our Hermes/dl graph. These will be explained in detail soon.

  <key id="type" for="node" attr.name="type" attr.type="string">
    <default>N_REPOS</default>
  </key>
  <key id="label" for="node" attr.name="label" attr.type="string">
    <default>Label</default>
  </key>
  <key id="x" for="node" attr.name="x" attr.type="double">
    <default>0.0</default>
  </key>
  <key id="y" for="node" attr.name="y" attr.type="double">
    <default>0.0</default>
  </key>
  <key id="isEnabled" for="node" attr.name="isEnabled" attr.type="boolean">
    <default>true</default>
  </key>
  <key id="parentID" for="node" attr.name="parentID" attr.type="int">
    <default>-1</default>
  </key>
  <key id="level" for="node" attr.name="level" attr.type="int">
    <default>0</default>
  </key>
  <key id="factoryMappingKey" for="node" attr.name="factoryMappingKey" attr.type="string">
    <default>N_REPOS_0</default>
  </key>
  <key id="description" for="node" attr.name="description" attr.type="string">
    <default></default>
  </key>
  <key id="passiveFilters" for="node" attr.name="passiveFilters" attr.type="string">
    <default></default>
  </key>
  <key id="activeFilters" for="node" attr.name="activeFilters" attr.type="string">
    <default></default>
  </key>

At this point, we begin the definition of the graph itself. There is only one graph in any file used by this application. As a result, the graph tag is mostly ignored but is there to be consistent with the GraphML format.

  <graph id="Test Graph" edgedefault="undirected">
    <node id="n0">
      <data key="type">N_CELL</data>
      <data key="label">label</data>
      <data key="x">298</data>
      <data key="y">411</data>
      <data key="isEnabled">true</data>
      <data key="parentID">-1</data>
      <data key="level">0</data>
      <data key="factoryMappingKey">FSF_CELL_0</data>
      <data key="description"></data>
      <data key="passiveFilters">FSF_INT64_NODE myPassive1</data>
      <data key="activeFilters">FSF_STRING_NODE myActiveString</data>
    </node>
    <node id="n1">
      <data key="type">N_CELL</data>
      <data key="label">label</data>
      <data key="x">260</data>
      <data key="y">210</data>
      <data key="isEnabled">true</data>
      <data key="parentID">-1</data>
      <data key="level">0</data>
      <data key="factoryMappingKey">FSF_CELL_5</data>
      <data key="description"></data>
      <data key="passiveFilters">FSF_FLOAT64_NODE myFloat1</data>
      <data key="activeFilters">FSF_BOOL_NODE myActiveBool</data>
    </node>

As can be seen here, every node in the graph is described by a "node" tag. Each "node" tag has an ID of the form "n*" where the "*" represents a unique number for the node starting with 0. Inside the XML node tag is then a list of "data" entries corresponding to the "key" tags shown above. Here is a detailed description of each tag:

• type - Can be either N_CELL or N_REPOS currently and corresponds to the Cells and Repositories in a Hermes/dl graph. This can potentially be extended to support more types of nodes in the graph.
• label - This is the label that is displayed for the node in the graph.
• x - The x position in the graph scene.
• y - The y position in the graph scene.
• isEnabled - This is set to true if the node in the graph should be shown. Values are either "true" or "false".
• parentID - This is used to keep track of the node hierarchy for the different levels of detail that the graph can show. When two nodes are collapsed into one node, the new node that is created is the parent. NOTE: at any given time, only two nodes may have the same parent.
• level - This is also used for the heirarcy. When a node is created by the user, it starts with an level of 0. When a new parent node is created in the hierarchy, its level is set to be one more than the highest level of its two children. This feature is used to allow for the automatic showing and hiding of nodes at different levels.
• factoryMappingKey - This is a data entry that is only used for N_CELL type nodes. This is the factory mapping key that is used as a unique identifier for the Cell type in a Hermes/dl graph.
• description - This is a space for the graph designer to put a more detailed description of the actual function of a Cell in the graph. Again this is only used for a N_CELL type node.
• passiveFilters - This holds the list of passive filter pairs for N_CELL type nodes. The filter pair consists of a FSF_NODE type followed by its handle name. As described in the literature on Hermes/dl, a Node in Hermes/dl terms is a data structure used to encapsulate atomic data on a Passive Pulse. For example, "FSF_INT64_NODE myInt64" would refer to a 64 bit integer that resides in the repository connected to the passive pulse. Each pair is separated by a space
• activeFilters - This is exactly the same as the description for passiveFilters except that it is used for Active Pulses.

Following the list of nodes in the graph, the final part of the Hermes/dl file is a list of the connections between nodes in the graph and the ending GraphML tag.

    <edge source="n0" target="n1"/>
  </graph>
</graphml>

The "edge" tag indicates an edge between two nodes in a graph. Since there is a combination of directed and undirected edges in a Hermes/dl graph, the source and destination indicate direction of the connection when the two connecting nodes are of the type N_CELL. Otherwise they are just two endpoints on an undirected graph. The "graph" and "graphml" tag are then used to close the "graph" tag and the "graphml" tag respectively.

Controls

The basic means of creating and manipulating the graph is by using the mouse in conjunction with the current input mode that is set using the keyboard.

Keyboard Input

• ESC - QUIT
• F1 - Print the help menu.
• TAB - Change Renderer
• t - Change Node Type to Add
• a - Set Mode to Add Node
• r - Set Mode to Remove Node
• c - Set Mode to Connect Nodes
• n - Set Mode to No Input Mode
• s - Save to Test.xml
• l - Load from Test.xml
• j - Set Mode to Join two Cells or Repositories
• p - Set Mode to Split two cells (used to show whats inside a layer)
• e - Set Mode to Contract a cell (shows the upper level layer of a cell)
• z - Zoom Out to the original window view
• - - Expand all nodes to next lowest level of detail.
• + - Contract all nodes to next highest level of abstraction.
• v - Toggle node label visibility.

Mouse Input

• CTRL+drag - Create a zoomed view
• Click and Drag - Used to join cells and connect cells as well as to move nodes and the view window.
• Click - Used to add, remove, split and contract nodes in the graph.

Project Features

• Interactive interface with multiple rendering modes to provode users with both simple and more complex symbol structures.
• Object Oriented Design based off of the Model-View-Controller paradigm.
• Ability to save and load Hermes/dl graphs in a GraphML formatted file.
• Support for layering a graph so that it has different levels of detail that can be easily navigated.
• Support for multiple rendering styles and an easily extensible rendering interface.

Future Work

• More full featured GUI instead of using key-strokes for all commands.
• Revision control of Hermes/dl files so that
• Undo functionality.
• Currently it isn't possible to edit the features of a cell (mustly useful for Cells as opposed to Repositories).
• Currently lacks a context display for showing graph node information.
• Joining nodes into a layer must be done manually.
• Automatic layer uncollapsing using a zoom like tool.
• Can't switch to global view temporarily then back.
• For a more visually pleasing experience transitions between layers should be gradual.

Architecture Model

The design of the software follows the Model View Controller paradigm. In this context, the GLUT callbacks in main.cpp act as the Controller and are used to update the Model (the Graph instance) and the View state (Renderer type and Camera state). Aside from this, there is a separate part of the paradigm used for saving and loading the file which is encapsulated in the GraphReader class. This can all be seen in the Architectural Diagram:

Architectural Diagram

Each of these then breaks down further as follows:

Model

• Graph - This class encapsulates the whole graph model and contains all the node and edge information and provides functionality for updating the graph and how it is viewed (the Renderer).
• Node - This class represents the nodes in the graph and is subclassed for the different types of nodes.
• FSFCell - An extension of Node, this is used to represent Cells in the graph and include their extra features.
• Edge - This class represents connections between two nodes.

View

• Renderer - This is the base class used for all rendering.
• BezierEdge - This is the renderer used for drawing bezier curved edges.
• QBezierEdge - This renderer is used for drawing quadratic bezier curved edges.
• StraightEdge - This renderer is used for drawing straight edges.

Controller

• main.cpp - This contains all of the code for handing input from the window and telling the View/Model to update.

As mentioned before, the only other part that doesn't quite fit into the model is the GraphReader. In some ways this is a type of "View" as it is used to save a textual view of the graph. However, due to the distinct location of the output and the fact that it is used for saving and loading data, I've kept in separate in the model.

---