Domain Specific Language (DSL)

Table of Contents

• Programming Paradigms
• Type System
• Programming with OTX
  • XML Code Editor
  • Graphical Designer
  • ASCII Code - OTL Editor
• Main Components
• Analogies

A programming language is a formal language used to formulate data structures and algorithms that can be executed by a computer. A domain-specific programming language (DSL) is a programming language for a specific problem area (domain). It consist of of instructions according to a given pattern (syntax) and their meaning (semantics). OTX must be compiled (Compiler) or interpreted (Interpreter) for execution.

Programming Paradigms

• Imperative programming
  Imperative programming (Latin imperare "to arrange", "command") is a programming paradigm according to which a program consists of a sequence of instructions that specify the order in which what should be done by the computer.
• Structured programming (procedural)
  Structured programming is a programming paradigm that also became popular in the early 1970s. On the one hand, it contains the tree-like breakdown of a program into partial programs (procedures) and thus contains the paradigm of procedural programming. In addition, the structured programming on the lowest level requires the restriction to only three control structures: Sequence (program instructions to be executed one after the other), branching, loops and no goto.

Type System

In computer science, the term type system describes a component that can be used in programming languages to limit the range of values of declarations. Programming languages that have a type system are called typed. Depending on the characteristics of the type system, one sometimes speaks of strongly typed, dynamically or weakly typed languages. The typing is intended to ensure that no operations are carried out on the contents of variables that are syntactically or semantically incorrect.

• Strongly typed
  This means that the data types must match for operations. There is no implicit type conversion. The only exception with OTX is the implicit type conversion from Integer to Float.
• Statically typed
  This means that the data types of the declaration cannot change at runtime. In this way, data types can be checked at compile time.
• Explicitly typed
  This means that data types must be declared explicitly. There is therefore no type inference.

Note

The type system from OTX was selected based on the requirements of data and process security. In OTX, security is more important than convenience when creating code.

Programming with OTX

The OTX standard is based at a XML schema and to be standard compliant OTX must be stored inside a document as XML, see PTX file.

XML Code Editor

A normal XML editor or a simple text editor could be used to program OTX. However, the data integrity cannot really be guaranteed in this way. The following OTX XML code shows a simple "Hello World" procedure. The procedure consists of two actions. At first the value "Hello World" is assigned to a local variable MyStringVariable1. After than the value of the variable is displayed inside a dialog, see picture. For data integrity it must be ensured, that inside the Assignment action the variable MyStringVariable1 was declared and has the right data type String.

<?xml version="1.0" encoding="utf-8"?>
<otx xmlns="http://iso.org/OTX/1.0.0" xmlns:hmi="http://iso.org/OTX/1.0.0/HMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="id_689cf05253914c06a337b7fa774cb709" name="Document1" package="SimpleOtxSamplePackage1" version="1.0.0.0" timestamp="2021-01-09T14:48:04.7353838+01:00">
  <metaData>
    <data key="MadeWith">Created by emotive Open Test Framework - www.emotive.de</data>
    <data key="OtfVersion">6.3.0.38777</data>
  </metaData>
  <procedures>
    <procedure id="id_1b2a1183895a4f0797f7b1514920d8b4" name="main" visibility="PUBLIC">
      <realisation>
        <declarations>
          <variable name="MyStringVariable1" id="VariableDeclaration_67f2d6f48995434f8f3570629dab9645">
            <realisation>
              <dataType xsi:type="String" />
            </realisation>
          </variable>
        </declarations>
        <flow>
          <action name="Assignment1" id="Assignment_b2d38a38afae420cb57eb1b93edd64f1">
            <realisation xsi:type="Assignment">
              <result xsi:type="StringVariable" name="MyStringVariable1" />
              <term xsi:type="StringLiteral" value="Hello World" />
            </realisation>
          </action>
          <action name="ConfirmDialog1" id="ConfirmDialog_c95df0db43cc4630873249035c4e4245">
            <realisation xsi:type="hmi:ConfirmDialog">
              <hmi:message xsi:type="StringValue" valueOf="MyStringVariable1" />
            </realisation>
          </action>
        </flow>
      </realisation>
    </procedure>
  </procedures>
</otx>

Graphical Designer

To ensure data integrity, the data model was designed in such a way that OTX can also be represented graphically and edited inside a graphical designer, see picture below for the same "Hello World" procedure. Design time support to ensure data integrity helps the author to program procedures quickly and easily and to keep track of things.

ASCII Code - OTL Editor

In the same way like the data model can be represented graphically it can also be represented as text code. Within a code editor, OTX can program in the same way like any other programming language (Java, C ++ or DotNet). The following OTL code shows the same "Hello World" procedure.

namespace SimpleOtxSamplePackage1
{
    public procedure main()
    {
        // Local Declaration
        String MyStringVariable1;
 
        // Flow
        MyStringVariable1 = "Hello World";
        HMI.ConfirmDialog(MyStringVariable1);
    }
}

In the OTX development environment, the user can choose whether he prefers to program graphically, textually or both.

Main Components

OTX mainly consists of the following elements. Detailed information about the data model please see OTX Classes.

• Document
• Procedures
• Declarations
  • Global
    • Variables, constants, context and status variables, signatures, validities
    • Visibilities (public, package, private) to define usability
  • Local
    • Variables and constants
• Control structures (CompoundNode)
  • Sequences
    • Loops (while, do-while, for, for-each)
    • Branches (if-then-else)
    • Parallel
• Actions and Terms
• End nodes (EndNode)
• Variable binding
• Simple, complex, generic and user-defined data types
  • Boolean, Integer, Float, String, ByteField, ...
  • List & Map
  • Structure & enumeration
• Arbitrarily nestable expressions
• Error / exception handling
• Specification field in each node as well as free comments
• Basic concepts for process and variant management
  • Reduction of the sequences to the actual test logic
• Version information (ADMIN-DATA)
• References to other OTX documents (imports)
  • Namespace management
• Extension points for the connection of new functions (META-DATA)

Analogies

For a better understanding, the following table compares the terminologies of OTX with other programming languages like DotNet and Java. For example, in Java, the solution is called a workspace. A PTX file corresponds to a DLL in DotNet and to a JAR file in Java. An OTX document is a class in DotNet and Java, and an OTX procedure is a method.

OTX	DotNet	Java
Solution	Solution	Workspace
Project	Project	Project
PTX	DLL	JAR
Package	Namespace	Package
Document	Class	Class
File (*.otx)	File (*.cs)	File (*.java)
Procedure	Method	Method