Norwegian University of Science and Technology

Global navigation

Diamodl language

The Diamodl language is a diagram-based language for dialog modelling. The modelling constructs are either data-oriented or state-oriented. The basic data-oriented constructs are the variable, computation, widget and connection (data flow). In addition, gates and interactors provide means for abstraction and composition.


A variable is used for holding a data value, either a simple value like an integer or a string, or a reference to an object and its contained structure. A variable has a name and a type. The type is typically a class defined in a data model (outside the scope of Diamodl) and may indicate by means of brackets and dots ([..]) that the variable is multi-valued (as opposed to single-valued). The symbols for variables are shown below. The left one shows a single-valued variable named 'uri' of type URI, and the right one shows a multi-valued variable named 'bookmarks', also of type URI.


Computations are used to transform values, and may perform simple data conversions, get or set properties or compute simple or complex functions. The function definition defines the computation's arity, from zero (meaning the computation generates values from nothing) and upwards. The syntax for the function definitions are as follows:

  • data conversion: Data conversion <from type>→<to type>, e.g. String→Integer (note that the type name must start with an upper case character)
  • get property: the property name, e.g. name (note that the property name must start with a lower case character)
  • set property/association: the property name followed by a '=', e.g. name= (note that the property name must start with a lower case character)
  • compute functions: <language>:<argument type list>→<result type>|<function body>, e.g. js:Integer,Integer→Integer|function plus(n1, n2) { return n1 + n2;}

The last form uses a specific scripting language, like Javascript, and includes a type signature and a function body. A shorthand form is provided for javascript: omit the 'function' keyword and the argument list, use $1, $2, … $n to refer to arguments (the argument list is derived) and omit the braces around the body and return statement. E.g. 'js:Integer,Integer→Integer|$1 + $2' is shorthand for 'js:Integer,Integer→Integer|function plus(n1, n2) { return n1 + n2;}'.

The symbol for computations is a triangle with a smaller triangle as the tip (the rest is called the base) and is shown below. The computation may point in any direction (the graphical editor limits the direction to the four main directions. The arity defines the number of connection points on the base (one on the left and two on the right computation).


Widgets are similar to variables, in that they refer to an underlying object. However, a widget refers to a single, constant object that is hosted by the user interface toolkit of the client. There is no direct support for defining the object class, instead a widget type and style names are used. This type and style names have meaning only in the context of a specific toolkit (or widget renderer). Although this makes the model more some platform dependent, it is necessary to support rapid prototyping. By using a standardized set of widget types and styles, the model will be less dependent on the specific toolkit (e.g. SWT vs. Swing).

The widget symbol is shown below. It includes the name and type (there is no style in this example). It will render as a text widget using the default runtime and toolkit.

An important aspect of widgets are that it may deliver events, either as property changes or as interaction specific events.


Connections are used to model data flow and may be used to connect variables, computations and widgets. A connection may include a definition of a unary function that is invoked to transform all values flowing along the connection. This function is defined as for computations, but will typically be fairly simple, e.g. convert a value or get a property.

Each source and target ends of the connection may include a key which is used to refer to a particular feature of the source or target, the meaning of which depends on what kind of object the connection's end is attached to:

  • A source or target end attached to a variable or widget interprets a simple name key as a property name, and binds the connection to that particular property, either getting or setting that property.
  • A source end attached to a widget may include an event key, a simple name followed by a '!', to indicate that flow is triggered by that event. If the '!' is followed by a property name, the property value flows into the connection, otherwise it is the event object itself.
  • A source end attached to a computation supports no key, as it may only read the result value of the function.
  • A target end attached to a computation supports integer keys or the 'control' keyword. If the key is an integer (0 and up), it refers to the argument with that number). If the key is control, it is used to open or close the flow through that computation.

An important aspect of connections is how the flow is triggered. In general this happens whenever the source end changes, whether it is a variable value, variable or widget property or the result of a computation. When flow is triggered, the value is transmitted to the target, after being transformed by the connection's function (if it has one). This may of course trigger the flow into other connections downstream.

Connections are drawn as lines, usually with Manhatten style router.

Interactors and gates

Interactors and gates provide the means for abstraction and composition of structures of Diamodl language elements. As an abstraction, an interactor is an abstract interaction object (AIO) with specific information (types) that it may output (present) to the user and/or input from the user. As an abstraction, it hides the specific widget type user for interaction and details of how input devices are used. E.g. an interactor for outputting and inputting text (strings) may utilize simple text fields or complex text editors in its implementation. However, from the outside, only the (type of) flow of information into (received by) and out of (sent by) the interactor is visible.

The flow into and out of interactors is mediated through gates, which are classified based on the direction of flow. The most common ones are output-receive and input-send, mediating flow from the application towards the user as output and into the interactor and from the user to the application out of the interactor, respectively.

An interactor with String output-receive (upper one) and input-send (lower one) can be seen below. In this case, the implementation of the abstract interaction is by means of a 'text' type of widget.

Interactors can be composed into a hierarchy and may contain the basic variable, computation and widget elements with connections, as well as other interactors.

2007/11/05 20:29, Hallvard Trætteberg
NTNU, NO-7491 Trondheim. Telephone: +47 73 59 50 00. Contact us
Editorial responsibility: