MP-WS13-02

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Problemstellung

Zielsetzung

In klassischen Ingenieursdisziplinen spielt die Verwendung von Modellen in allen Phasen eines Projekts eine entscheidende Rolle. Adäquate Modelle werden zum Entwurf, zur Durchführung des Projektes und auch zur Beurteilung der Projektergebnisse verwendet. Überträgt man dieses Vorgehen auf die Informatik, wird man besonders im Bereich der Beurteilung der Ergebnisse vor Probleme gestellt, da zu diesen Bereichen keine entsprechenden Modelle vorliegen. Beurteilungen und Tests von erstellter Software werden in erster Linie auf Basis von nicht-formalen Spezifikationen manuell durchgeführt. Dieser Problemstellung widmet sich das modellbasierte Testen. Das Ziel dieser Herangehensweise ist es, auf der Basis von präzisen Modellen Softwaresysteme automatisiert zu testen und somit ihre Qualität prüfen zu können.

Dieses Projekt soll eine Domänen-spezifische Sprache zum Testen von verteilten Automaten in ein zu erstellendes Testframework integrieren. Dabei soll so vorgegangen werden, dass herstellerspezifische Systemmodelle in die DSL eingebunden werden und Aussagen über diese Modellen getroffen werden können. Auf der anderen Seite soll eine Möglichkeit geschaffen werden, in der DSL modellierte Testfälle ausführen zu können. Wenn diese Aufgaben erfüllt sind, soll versucht werden, zeitliche Bedingungen an diesem System zu untersuchen, um auch Quality-Of--Service-Eigenschaften testen zu können.

Projektkontext

Das Masterprojekt findet im Projekt Testframework für Automatisierungsanwendungen [1] im Labor für Verteilte Systeme an der Hochschule RheinMain statt. Dieses Projekt wird in Kooperation mit der Eckelmann AG, einem Hersteller für Automatisierungstechnologie aus Wiesbaden, durchgeführt. Das Ziel des Projekts ist die Erstellung eines Testframeworks, dass in kleinen und mittelständischen Unternehmen (KMUs) eingesetzt werden kann. Das Master-Projekt knüpft an eine Master-Thesis [2] aus diesem Projekt an.

Grundlagen

Modellbasiertes Testen

Motivation

Modellbasiertes testen versucht, das in MP-WS13-02#Zielsetzung angesprochene Problem so zu lösen, dass für die Beurteilung von Projektergebnissen Modelle verwendet werden. Im Idealfall sind unter den verwendeten Modellen auch solche, die beim Entwurf verwendet werden, um das Verhalten des Systems zu beschreiben. Aus den Modellen wird dann ein Großteil des benötigten Test-Codes generiert. Dieser Ansatz wird üblicherweise mit automatisiertem Testen kombiniert, auf diese Weise können Test-Designer und Entwickler entlastet werden, da sie sich auf den inhaltlichen Teil ihrer Arbeit beschränken können und sich weniger mit technischen Details beschäftigen müssen.

Grundlegendes Vorgehen

In [3] wird das grundsätzliche Vorgehen wie folgt beschrieben:

  1. Ein Testdesigner entwickelt ein von der Zielplattform unabhängiges Testmodell.
  2. Der Test Case Generator erzeugt aus diesem Testmodell abstrakte Testfälle, auch diese sind von einer konkreten Form eines System under Test (SUT) unabhängig.
  3. Ein Test Script Generator erzeugt mithilfe der abstrakten Testfälle Test Scripts.
  4. Diese können dann durch einen Adaptor, der ein SUT anbindet, getestet werden.

Für unterschiedliche Versionen des SUT müssten also nur der Test Script Generator und der Adaptor angepasst werden. So können die abstrakten Testfälle für andere Implementierungen des SUT wiederverwendet werden.

UTP

Das UML Testing Profile(UTP)[4] ist ein UML-Profil zur Modellierung und Organisation von Tests. Dazu werden Stereotypen für einen Test-Kontext, eine Konfiguration sowie das System Under Test(SUT) definiert. Das zentrale Element einer UTP-Testbeschreibung ist eine Test-Suite, eine Sammlung von Testfällen.

Wichtige Konzepte (aus[4])

  • Auf jeder Ebene benötigt:
    • SUT: System under Test
    • Test Context: Klasse, die Tests als Methoden enthält
    • Test Objective: Beschreibt das Ziel eines Tests
    • Test Case: Methode eines Test Context, interagiert mit dem SUT, gibt ein Test Verdict zurück.
  • Wichtig für Integration:
    • Test Verdict: Ergebnis eines Test Cases, also Erfolg, Fehlschlag, unconclusive und Error.
    • Test Configuration: Definiert Test Components und Verbindungen zwischen diesen und dem SUT
  • System level testing
    • Timers: Generieren Timeouts nach einer bestimmten Zeitspanne
    • Timezones: Gruppieren Test Components nach Zeit, alle Test Components in einer Time Zone verwenden die gleiche Zeit.
    • Defaults: Definieren das default-Verhalten bei nicht spezifiziertem Verhalten des Subsystems. Ähnlich zu Exception-handling.

TTCN-3

Die Testing and Test Control Notation(TTCN-3) [5] ist ein Standard, der vor allem für Tests von Kommunikationssystemen ausgelegt ist. Die Ursprüngliche Aufgabe war conformance testing zu verschiedenen Protokollen, in der dritten Version können Systeme verschiedenster Art getestet werden.

Es werden verschiedene Darstellungen zur Beschreibung von Testfällen definiert, darunter die Core Language, eine textuelle Repräsentierung sowie Graphical Format(GFT), eine graphische Variante. Daneben existiert noch eine Darstellung in Tabellenform, das Tabular Presentation Format.

Die TTCN-3-Spezifikation beinhaltet nicht nur mehrere Sprachen zur Beschreibung von Tests, sondern auch ein Interface, mit dem eine Interaktion zwischen Test-System und SUT stattfinden kann. Dadurch wird eine Anbindung verschiedenster Test-Systeme an ein SUT bzw. verschiedener SUTs an ein Testsystem ermöglicht.

Ein Zentrales Konzept bei TTCN-3 sind die sogenannten Ports. Die Interaktion mit dem SUT findet nur über diese Kommunikationsobjekte statt. Ein Testfall besteht also im wesentlichen daraus, eingaben als Anregung des Testsystems zu verwenden und zu spezifizieren, welche Art Von Ausgabe erwartet wird. TTCN-3 ist also ein reiner Black-Box-Ansatz.

Es gibt eine Abbildung zwischen UTP und TTCN-3, diese wird in [6] beschrieben.

Eclipse Modeling Framework

Überblick

Das Eclipse Modeling Framework ist ein Teil des Eclipse Projekts. Ziel dieses Frameworks ist es, Modellierung und Programmierung in einen Aufgabenbereich zusammenzuführen. Dieses Ziel folgt aus der Beobachtung, das zu einem Modell häufig ein XML-Schema, Java-Klassen und ein Datenbank-Schema erstellt werden muss.

Stattdessen sollen alle diese Informationen aus dem Modell generiert werden. Dazu stellt das Eclipse Modeling Framework eine Modellierungsumgebung bereit.

EMF Meta-Metamodell

Zur Modellierung wird das ecore Metamodell verwendet. ecore ist die Implementierung von EMOF, einer Untermenge von Meta Object Facility[7], dem Metamodell von UML.

Die folgende Abbildung[8] zeigt die wesentlichen Klassen und Beziehungen von ecore: Ecore.png

Metamodellierung mit dem Eclipse Modeling Framework

Um EMF zu benutzen, kann ein entsprechendes Eclipse Plugin genutzt werden. Es bietet die Möglichkeit in einem bereitgestellten Editor Modelle im ecore-Format zu erstellen. Um daraus Code generieren zu können wird ein Generator-Modell benötigt, dass auch automatisch erzeugt werden kann. Sind diese beiden Modelle vorhanden, kann der eigentliche Code erzeugt werden. Dabei wird nicht nur der Sourcecode für die definierten Klassen erzeugt, zusätzlich wird ein Mechanismus zur XMI-Serialisierung und ein Eclipse-Editor für das beschrieben Modell generiert. An dieser Stelle sei auf ein Einstiegstutorial zu EMF hingewiesen: [9]

QVT Operational

Mit QVT[10] wurde von der OMG ein Standard zur Transformation zwischen in MOF definierten Modellen vorgesehen. Dabei werden zwei Sprachen zur Beschreibung dieser Transformationen definiert:

  1. Relational: hier wird der Zusammenhang zwischen verschiedenen Modellaspekten deklariert. Daraufhin kann eine Modelltransfomration zwischen verschiedenen Modellen durchgeführt werden.
  2. Operational: hier wird das Verfahren zur Transformation detailliert beschrieben. Dem entsprechend ist auch nur die Transformation in einer Richtung möglich.

Es existiert ein QVT-Plugin für Eclipse, es ist aber lediglich QVT Operational implementiert. Das Eclipse QVT-Plugin kann zwischen in ecore definierten Modellen Transformationen ausführen.

Domain-Specific Languages und EMF

XText[11] ist ein Framework aus dem Eclipse Modeling Project. Dieses Framework soll das Erstellen von Domain Specific Languages erleichtern. Der Benutzer muss dazu lediglich eine abstrakte Beschreibung der Grammatik angeben, aus der dann ein Eclipse-Editor und ein Parser generiert werden können. Der Parser kann dabei genutzt werden, um Modelle in eine EMF-Repräsentierung zu überführen, da zu jeder angegebenen Grammatik ein ecore-Modell bestehen muss. Dieses Modell kann entweder automatisch aus der Grammatik generiert, oder beim Erstellen der Grammatik angegeben werden.

Mithilfe der Sprache xtend[12] kann aus den in der DSL beschriebenen Modellen direkt ausführbarer Code generiert werden. Dazu muss in einer automatisch erzeugten Generator-Klasse die Methode doGenerate() implementiert werden, in der der Code generiert wird. Ein Beispiel zur schnellen Erzeugung von Java-Klassen aus einem Modell wird in einem Eclipse-Tutorial[13] beschrieben.

Problemanalyse

Aktuelle Projektsituation

StateCase

Zur Modellierung von verteilten Automaten wird bei Eckelmann die Software StateCase eingesetzt. Sie ermöglicht die Modellierung von Automaten in einer Tabellarischen Darstellung zur besseren Übersichtlichkeit. Ein Beispiel für eine solche Darstellung ist in der folgenden Abbildung[2] zu sehen: Automatenbeispiel.png

Die Zeilen beschreiben Events, die eintreten können. Zustände werden durch Spalten dargestellt. Ein Übergang wird durch einen Pfeil repräsentiert, wobei der Anfang des Pfeils den Ursprungszustand und die Spitze des Pfeils den Zielzustand darstellt. An den Pfeilen kann noch eine auszuführende Aktion und die Priorität des Übergangs stehen. Aus den mit StateCase modellierten Modellen kann Code in verschiedenen Sprachen erzeugt werden. Der Entwickler muss lediglich Auswertungsfunktionen für die Events der Statemachine implementieren. In tatsächlichen Anwendungen werden mehrere dieser Automaten verteilt verwendet, die Kommunikationskanäle zwischen den verschiedenen Automaten werden dabei nicht in StateCase modelliert, sondern von den Entwicklern "von Hand" implementiert.

Testframework

Das Testframework TPTP[14] soll für das Projekt Testframework für Automatisierungsanwendungen die Grundlage liefern. Die Testmodelle von TPTP orientieren sich dabei an UTP. Intern werden die Testmodelle mithilfe des Eclipse Modeling Framework verarbeitet. Um die in StateCase erstellten Systemmodelle verarbeiten und in ein eigenes Systemmodell integrieren zu können, wurden EMF-Modelle erstellt, die eine abstraktere Form der StateCase-Automatenmodelle darstellen. Dazu wurde ein abstraktes Statemachine-Modell entworfen, das sich an den UML Statemachines orientiert. Diese sind in ein Modell zur Teststrukturierung integriert, dass sich an UTP orientiert, dabei aber auf die speziellen Wünsche von Eckelmann eingeht.

Anbindung SUT

Zur Anbindung an das System under Test existiert ein Adapter, der in der Lage ist, aus einem Ablauf von verteilten Automaten über eine WCF-Schnittstelle[15] einen Trace zusammenzustellen. Diese können dann in einem EMF-XMI-Modell gespeichert werden, das zum Teststrukturierungsmodell passt.

Diese Schnittstelle erzeugt Traces im XMI-Format, die über die Klasse ReadTrace eingelesen werden können. Die Funktion getTrace() gibt dann ein TraceList-Objekt zurück, das eine Liste von StateMachineTraceEvent-Instanzen aus dem Testframework-Metamodell enthält. Diese Liste wird durch das Testorakel komplett betrachtet, also ist die Auswertung erst möglich, wenn ein kompletter Trace vorliegt.

Ein Objekt der Klasse StateMachineTraceEvent enthält dabei alle relevanten Informationen zum Eintritt einer Statemachine in einen neuen Zustand. Dazu gehören insbesondere der neue Zustand der Betreten wird, zu welcher Zustandsmaschine dieses Event gehört sowie ein Zeitstempel.

DSL

In der Master-Thesis von Michael Pötz[2] wurde eine DSL umgesetzt, die das Soll-Verhalten von verteilten Automaten beschreiben und diese Beschreibungen mithilfe eines implementierten Test-Orakels gegen einen Testlauf überprüfen kann. Dabei wurde der Aspekt von Zustandsfolgen verschiedener Automaten betrachtet. Außerdem wurden Sprachmittel zur Definition von Zeitdauern von Zustandsübergängen entworfen. Die DSL kann ebenfalls beschreiben, wie oft bestimmte Zustände betreten werden dürfen.

Diese verschiedenen Aspekte des Sollverhaltens der Automaten werden derzeit getrennt betrachtet. Die Auswertung eines Pfades hat also keinerlei Auswirkungen auf die Auswertung eines zeitlichen Ausdrucks oder einer Angabe über die Anzahl der Zustände. Diese Aspekte lassen sich auch nicht kombinieren.

Im folgenden wird ein kurzer Überblick über die existierenden Sprachmittel gegeben.



Pfade

Einfache Pfade
es können einfache Folgen von Zuständen eines Automaten beschrieben werden. Der Testlauf wird dann gültig, wenn die Zustände in genau dieser Reihenfolge eingenommen werden. Beispiel:
Tuersteuerung_1.Oeffnen->Tuersteuerung_1.Offen
Globale Pfade
Pfade können sich auch über mehrere Automaten erstrecken, so kann ausgedrückt werden, dass bestimmte Zustände eines Automaten auf die Zustände eines anderen Automaten folgen können. Beispiel:
Schalter_1.Gedrueckt -> Tuersteuerung_1.Oeffnend -> Tuersteuerung_1.Offen
Wildcards
Mit diesem Sprachmittel kann ausgedrückt werden, dass eine beliebige Folge von Zuständen akzeptiert wird. Beispiel:
Schalter_1.Gedrueckt -> * Tuersteuerung_1.Offen
Verzweigungen
In einigen Fällen kann es nützlich sein, mehrere Alternativen für gültige Pfade anzugeben. Dazu wird das Sprachmittel der Verzweigung genutzt. Beispiel:
Schalter_1.Gedrueckt -> ( Tuersteuerung_1.Oeffnend or Tuersteuerung_1.Schliessend )

Zeit

Zur Modellierung von Zeitbedingungen existieren zwei Ausdrücke:

Verweildauer in einem Zustand
Darüber kann angegeben werden, wie lange ein Automat in einem Zustand bleiben darf. Beispiel:
in Tuersteuerung_1.Schliessend max 3000
Spanne zwischen dem Betreten zweier Zustände
Mit diesem Sprachmittel kann angegeben werden, wie lange zwischen dem Betreten eines Zustands und dem Betreten eines anderen vergehen darf Beispiel:
from Tuersteuerung_1.Schliessend to Tuersteuerung_1.Geschlossen within 3000

Zählen von Zuständen

Es ist möglich, Ausdrücke über die Häufigkeit des Betretens verschiedener Zustände zu formulieren. Ein einfaches Beispiel könnte so aussehen:

Tuersteuerung_1.schliessend exactly 1

Es sind allerdings auch komplexere Ausdrücke denkbar:

Tuersteuerung_1.schliessend - Tuersteuerung_1.oeffnend more or equal 0

Testorakel

Die Testentscheidung wird mithilfe eines Testorakels getroffen, das ebenfalls im Rahmen der Arbeit erstellt wurde. Dazu werden aus der in der DSL geschriebenen Testbeschreibung mithilfe von in Xtend[12] geschriebenen Generatoren JUnit-Testcases generiert. Die Generierung der Testcases wird automatisch durch Xtext angestoßen. Die JUnit-Tests greifen auf die Module PathCheck, TimeCheck und CountCheck zurück, die die Überprüfung der Testausdrücke durchführen. PathCheck muss dazu ebenfalls mithilfe von Xtend generierte Test-Statemachines nutzen.

Aktueller Workflow

Der Workflow für die Durchführung der Tests ist also:

  1. Erstellung des Deployment-Modells, dabei müssen auch strukturelle Eigenschaften der beteiligten SFTs angegeben werden (zum Beispiel Zustände etc.)
  2. Beschreibung der Tests in der DSL durch einen Testdesigner
  3. Automatische Generierung der Tests und Test-Statemachines durch Xtext beim Speichern der Testdatei
  4. Ausführen eines Durchlaufs auf dem SUT, Speichern des Ablaufs als Trace im EMF-XMI
  5. Ausführen der JUnit-Tests auf den Traces

Einbindung der Vorstellungen des Projektpartners

In einem Meeting mit den am Testframework beteiligten Mitarbeitern von Eckelmann im SFT-Kontext wurden einige kleine Änderungen gewünscht. Viele waren lediglich syntaktischer Natur, so wurde zum Beispiel festgestellt, dass die Verwendung der Ausdrücke Precondition und Condition verwirrend ist und anstatt Condition Assert verwendet werden sollte. Weiterhin sollen die Ausdrücke TimeCondition und PathCondition durch DurationAssert und PathAssert ersetzt werden.

Neben diesen rein syntaktischen Änderungswünschen wurde gewünscht, dass es möglich ist, in den Pfadausdrücken auch Zeitliches Verhalten testen zu können, so soll es beispielsweise möglich sein, an einen Pfad anzuhängen, dass dieser innerhalb einer bestimmten Zeit durchlaufen werden soll.

Weiteres Vorgehen

Die vier beschriebenen Komponenten sind alle voneinander isoliert. Die ersten Arbeitspakete dieses Master-Projekts beschäftigen sich damit, sie zu integrieren.

Der erste Schritt wird dabei sein, die EMF-Systemmodelle in der DSL aus der Masterarbeit referenzierbar zu machen. Dazu muss ein eigenes Deployment-Modell des Systems entwickelt werden, das abbildet, welche Statemachine-Instanzen in einem System existieren, von welchem Typ diese sind. Zusätzlich könnte möglicherweise festgehalten werden, auf welchen Rechnern die Statemachines ausgeführt werden. Zu den Rechnern könnte angegeben werden, welche Zeitbasis die verwendeten Uhren verwenden.

Außerdem sind einige Komponenten der DSL noch nicht fertig implementiert. So können bisher nur Tests für einfache Pfade generiert werden, nicht jedoch für Wildcards und or-conditions. Das Orakel ist aber bereits in der Lage, diese Konzepte auszuwerten. Hier bestehen Arbeitspakete darin, den Generator für diese Fälle fertigzustellen. Dazu müssen möglicherweise auch Umstrukturierungen an der DSL vorgenommen werden.

Aus den Änderungswünschen des Projektpartners ergeben sich ebenfalls mehrere Arbeitspakete. So müssen

  1. die syntaktischen Änderungswünsche abgearbeitet werden,
  2. ein Design zur Integration der zeitlichen Ausdrücke in die DSL gefunden werden,
  3. dieses Design umgesetzt werden und
  4. der Generator sowie das Testorakel entsprechend angepasst werden.

Neben diesen Vorgaben des Projektpartners muss die Implementierung des Orakels angepasst werden, um zu erreichen, dass das Orakel auf einem Strom von TraceEvents arbeiten kann und nicht nur auf einem vorliegenden Trace arbeitet.

Entwurf und Umsetzung

Überblick über die Grobarchitektur

Im wesentlichen soll der hier betrachtete Teil der Anwendung aus folgenden Komponenten bestehen:

  1. Eclipse-Plugin mit DSL-Editor und integrierter Codegenerierung zur Modellierung von Testfällen
  2. Eclipse-Plugin mit TEFA-Modellen, dass die Modellklassen bereitstellt, damit auf diese zugegriffen werden kann.
  3. Eine Transformation, die aus DSl-Dateien ein TEFA-Modell erstellen kann.
  4. Testausführungsmodul, das Tests, die im TEFA-Modell beschrieben werden ausführen kann.

Zwischen 1 und 2 soll eine Integration erfolgen, damit aus der DSL auf Elemente des Systemmodells zugreifbar sind. Außerdem muss dafür gesorgt werden, dass der Code, der zur Istverhaltensvalidierung genutzt wird, in der Lage ist ströme von Zustandsübergängen des SUT zu verarbeiten und nicht eine Liste aller Übergänge besitzen muss, um eine Auswertung durchführen zu können. 3 muss im Rahmen des Projekts implementiert werden, 4 ist nicht mehr Teil dieses Projekts.

Vervollständigen der Code-Generierung

In der übergebenen Version der DSL war die Codegenerierung noch nicht vollständig umgesetzt. Wildcards und Or-Conditions waren noch nicht vollständig. Bei der Generierung wurde aus dem Syntax-Baum eine einfache Liste von Zuständen erstellt und diese als Folge von Zuständen interpretiert.

Um für eine korrekte Codegenerierung zu sorgen, wurde dieses Vorgehen durch ein neues ersetzt, in dem der Syntax-Baum tatsächlich als solcher betrachtet wurde. Aus diesem Baum wurde dann für die Automaten ein Baum erstellt, der direkt in das Testautomtenmodell der ersten Version umgewandelt wurde.

Einbindung der EMF-Modelle

Obwohl Xtext als Framework zur Repräsentierung der DSL-Elemente das Eclipse Modeling Framework einsetzt und die Sprache zur DSL-Beschreibung ein import-Statement für Ecore-Modelle besitzt, müssen einige Schritte unternommen werden, um Instanzen der EMF-Modelle referenzieren zu können.

Zunächst muss der MWE2-Workflow, der aus der Xtext-Grammatik ein Eclipse-Plugin mit entsprechendem Source-Code erstellt, angepasst werden. Das Generator-Modell zum Ecore-Modell sowie die erzeugten Pakete müssen hier registriert werden. Daraufhin kann über das import-Statement in der Grammatik das Metamodell referenziert werden.

In dem Eclipse-Projekt für das Ecore-Modell müssen ebenfalls einige Änderungen vorgenommen werden. Damit das ecore-Modell gefunden werden kann, wird dem Projekt die Xtext-Nature hinzugefügt. (Man kann zwar alle Schritte auch ausführen, ohne dass die Xtext-Nature hinzugefügt wird, allerdings findet der Grammatik-Editor dann das Ecore-Modell nicht und zeigt eine Fehlermeldung an. Das Projekt kann aber trotzdem gebaut werden und funktioniert.)

Weiterhin muss für die Dateien, die Instanzen des Ecore-Modells enthalten, ein ResourceServiceProvider[16] erstellt werden. Diese Klasse wird von Xtext benötigt, um auf Informationen über eine Ressource sowie deren Inhalt zugreifen zu können. Diese Klasse wird über den extension point org.eclipse.xtext.extension_resourceServiceProvider als Eclipse-Plugin registriert. Dies dient im wesentlichen dazu, für für Objekte in den referenzierten EMF-Modellen IEObjectDescriptions[17] anzulegen und zu verwalten. Diese enthalten des Feld qname dass den Namen repräsentiert, über den die Objekte in der DSL referenziert werden können.

Neues Deployment-Modell

Da die Statemachines jetzt referenziert werden können, ist eine Anpassung des Deployment-Modells möglich. Diese Modell erlaubt es jetzt, auf Statemachine-Modelle zuzugreifen, damit nicht für jede Statemachine-Instanz alle Eigenschaften neu angegeben werden müssen. Ein erster Entwurf für die Syntax des Deployment-Modells wird hier dargestellt:

name Tuer_Deployment
version 1.0 

deploymentModel tuerDeployment
computeNode node1

statemachineInstance Schalter_1
on node1
statemachine Schalter

statemachineInstance Tuersteuerung_1
on node1
statemachine Tuersteuerung_1

Der deploymnetModel Ausdruck gibt den Anfang eines Deployment-Modells an. Danach können Rechnerknoten (computeNodes und Instanzen von Statemachines (stateMachineInstance angegeben werden. Bei Instanzen von Statemachines muss angegeben werden, auf welchem Knoten sie ausgeführt werden (über das Schlüsselwort on und welche Statemachine ausgeführt wird (mithilfe des Schlüsselworts statemachine).

Durch die Verwendung von Qualified Names in Verbindung mit imports lässt sich so auch ein Deployment-Modell referenzieren und leicht wiederverwenden. Es ist außerdem einfacher möglich, die Deployment-Modelle in andere Dateien auszulagern.


Anpassung des Orakels

Konzept

Um eine Live-Auswertung möglich zu machen muss das Testorakel angepasst werden, da es derzeit seine Daten aus einer Liste von Trace-Objekten bezieht. Dazu wurde zunächst das Orakel für globale Pfade neu geschrieben, da der bisherige Auswertungsansatz für dieses Vorgehen nicht praktikabel ist.

Der Alte Ansatz führt Pattern Matching auf den Ausgaben des Systems über ein Backtracking-Verfahren durch, ähnlich dem Verfahren, dass zum Beispiel Perl für reguläre Ausdrücke[18] verwendet. Dazu muss permanent die Liste aller Zustandsänderungen bereit gehalten werden und zusätzlich muss sich gemerkt werden, welche Abzweigungen genommen wurden und welche noch zu betrachten sind sowie an welcher Stelle im Trace diese Abzweigungen genommen werden müssen.

Der neue Ansatz verwendet ein anderes Verfahren für das Verifizieren der Traces, eine modifizierte Variante des von Ken Thompson vorgestellten Algorithmus[19] zum übersetzen von Regulären Ausdrücken in Maschinencode. Dabei wird so vorgegangen, dass der Ausdruck zunächst in einen nichtdeterministischen, endlichen Automat (NFA) übersetzt wird und dieser dann über der Eingabe ausgeführt wird. Der NFA wird dabei so ausgeführt, dass alle Zustände, in denen sich der NFA derzeit befinden könnte, gespeichert werden. In jedem Schritt werden dann alle mit der Eingabe möglichen Folgezustände berechnet.

Dieses Verfahren muss nur minimal angepasst werden, damit auch der nicht-Operator berücksichtigt wird. Außerdem muss beachtet werden, das einige Statemachine-Events ignoriert werden können, wenn die Instanz der Statemachine nicht zum Spezifizierten Soll-Verhalten passt.

Um dieses Verfahren durchführen zu können, müssen aus den Ausdrücken der DSL Automaten generiert werden. Dieses Verfahren lässt sich am besten an einem Beispiel illustrieren. Betrachten wir das folgende Codebeispiel eines Ausdrucks in der DSL:

PathAssert t1 {
	sft1:Init_SFTState -> sft2:Init_SFTState 
	-> (sft1:Finished_SFTState or sft1:Error_SFTState)
	-> * -> sft1:Init_SFTState 
}

Aus diesem Beispiel würde der folgende Automat generiert:

Testautomatenbeispiel.png

Die spezifizierten States sind die Bedingungen für die Zustandsübergänge des Automaten. Ist der nächste Ausdruck nach einem -> ein einfacher State, wird einfach ein neuer Zustandsübergang mit diesem Zustand als Übergangsbedingung hinzugefügt. Ist der nächste Ausdruck eine or-Bedingung, müssen mehrere Übergänge hinzugefügt werden, wie das im eben gezeigten Beispiel geschehen ist. Bei Wildcards (ausgedrückt mit *) wird ein Übergang mit einer alles akzeptierenden Bedingung in den bisherigen Zustand hinzugefügt.

Implementierung

Um die beschriebenen NFAs spezifizieren zu Können, wird die Klasse TestNFASpecification genutzt, ein UML-Diagramm dazu ist in der folgenden Abbildung zu sehen. Diese Klasse besitzt zwei TestStates, Start und End, die die Anfangs- beziehungsweise Endzustände des NFAs repräsentieren. TestStates enthalten Referenzen auf TestTransition Objekte, die die möglichen Zustandsübergänge eines NFAs aus diesem Zustand darstellen. Eine TestTransition besitzt eine TraceEventSpecifcation, die angibt, unter welchen Bedingungen dieser Zustandsübergang durchgeführt wird, sowie eine Spezifikation, in welchen Zustand übergegangen wird. Um zu Überprüfen, ob in einen neuen Zustand gewechselt wird, wird die Methode givesNewState() verwendet. Da es auch TracEvents gibt, die ignoriert werden, kann mit der Methode willIgnore() überprüft werden, ob ein TraceEvent ignoriert wird. Die TimedTestNFASpecification beschreibt NFAs, die mit einer Deadline versehen wurden, dieses Konzept wird in MP-WS13-02#Integration_von_Zeitausdr.C3.BCcken_mit_Pfadausdr.C3.BCcken näher erläutert.

TestNFASpecification.png

TraceEventSpecification wird als Spezifikation für Trace Events verwendet, zu den Unterklassen ist in der folgenden Abbildung ein UML-Diagramm zu sehen. Dieses Interface bietet lediglich die Funktionen fits(TraceEvent) und isIgnored(TraceEvent). fits() gibt zurück, ob ein Event zu dieser TraceEventSpecification passt. isIgnored() dient zur Überprüfung, ob ein Event ignoriert wird. Dieses Interface wurde bewusst so klein gehalten, um alle denkbaren Arten von Trace-Events abbilden zu können.

Die einfachste Implementierung dieses Interfaces ist die Klasse WildCard. Die Funktion fits() gibt immer true zurück, während isIgnored() immer false zurück gibt. StateChangeSpecification bildet eine Spezifikation des Betretens eines Zustands ab. Diese Klasse benötigt dazu eine StateMachineInstanceSpecification sowie einen State aus dem TEFA-Metamodell. isIgnored() gibt hier true zurück, wenn der gelesene Zustandsübergang nicht auf der spezifizierten StateMachineInstance stattgefunden hat. fits() gibt true zurück, wenn sowohl die StateMachineInstanceSpecification als auch der State zum TraceEvent passen. NotStateChangeSpecification verhält sich wie StateChangeSpecification, nur das sie die Antwort von fits() negiert. StringBasedStateChangeSpecification und StringBasedNotChangeSpecification arbeiten genau wie die Klassen ohne StringBased-Präfix, nur das hier die Instanz der Statemachine und der State lediglich über einen String identifiziert werden.

TraceEventSpecification.png

Um einen TestNFA zu Erzeugen, kann die Factoryklasse TestNFAFactory verwendet werden. Der Methode createTestNFA() muss eine TestNFASpecifation übergeben werden, daraus erzeugt diese dann einen dazu passenden TestNFA. Dieser kann dann über die Methode feedTraceEvent() TraceEvents des Systems erhalten. Wenn die bisher gelesenen Trace-Events den Automaten in einen akzeptierenden Zustand gebracht haben können, wird true zurückgegeben, der Test ist also erfolgreich. Wird nicht true zurückgegeben, kann über die Methode isSuccessfullTerminationPossible() überprüft werden, ob es noch möglich ist, den Automaten in einen solchen zustand zu bringen. Gilt das nicht, kann der Test in jedem Fall abgebrochen werden.

Integration von Zeitausdrücken mit Pfadausdrücken

Darstellung in der DSL

Um komplexe Bedingungen kompakter ausdrücken zu können, wurde vom Projektpartner gewünscht, in Pfadausdrücken auch zeitliche Beschränkungen angeben zu können. Zunächst wurde dazu die Möglichkeit gegeben, zu einem PathAssert eine deadline anzugeben. Diese beschreibt, wie viel Zeit das SUT zum Erfüllen der angegebenen Bedingung maximal benötigen darf. Damit lassen sich ausdrücke folgender Art formulieren:

PathAssert pa1 {
	Schalter_1:Gedrueckt -> Tuersteuerung_1:Offen	
} deadline 5000

Damit wird ausgedrückt, dass

  1. der Pfad Schalter_1:Gedrueckt -> Tuersteuerung_1:Offen durchlaufen werden muss und
  2. Tuersteuerung_1:Offen nicht mehr als 5000 Millisekunden später als Schalter_1:Gedrueckt auftreten darf.

Zusätzlich wurde in der DSL das Schlüsselwort within hinzugefügt. Dieses Schlüsselwort gibt zu einem Teil des Pfadausdrucks eine Maximaldauer an, die zum durchlaufen dieses Pfades benötigt werden darf.


Damit sind unter anderem solche Ausdrücke denkbar:

Schalter_1:Gedrueckt -> (Tuersteuerung_1:Oeffnend -> Tuersteuerung_1:Offen) within 5000

Diese Darstellung bedeutet, dass

  1. der Pfad Schalter_1:Gedrueckt -> Tuersteuerung_1:Oeffnend -> Tuersteuerung_1:Offen durchlaufen werden und
  2. nachdem Tuersteuerung_1:Oeffnend aufgetreten ist, innerhalb von 5000 ms Tuersteuerung_1:Offen auftreten muss..


Bei beiden Ansätzen muss davon ausgegangen werden, dass alle Zeitstempel die gleiche Zeitbasis besitzen. Dies wird im weitern Verlauf angenommen.

Auswertung im Orakel

Deadline-Ausdruck

Um den deadline-Ausdruck umzusetzen wird die Klasse DeadlinedTestNFA verwendet. Diese funktioniert wie die in MP-WS13-02#Implementierung beschriebene Klasse TestNFA, mit dem kleinen Unterschied, dass zusätzlich noch die deadline angegeben wird.

Bei der Auswertung wird so vorgegangen, dass sobald der erste Zustandsübergang im TestNFA genommen wird, der Zeitstempel des gelesenen TraceEvents Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle t_0} gespeichert wird. Zusätzlich wird in diesem Moment Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle c} auf den gleichen Wert gesetzt und aus Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle t_0} und der angegebenen deadline die Zeitschranke Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle d} berechnet.

Wird ein weiterer TraceEvent eingelesen, wird dessen Zeitstempel als Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle c} festgelegt. Sobald Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle c > d} geben feedTraceEvent() und isTerminationPossible() immer false zurück; das Ist-Verhalten entspricht also nicht dem spezifizierten Soll-Verhalten.

Within-Ausdruck

Da die Automaten sich nur über Zustände Ereignisse speichern können, sind sie eigentlich für die Auswertung von zeitlichen Bedingungen ungeeignet. Es ist jedoch möglich, einem Automat eine deadline zu geben, bis zu der der Automat einen Akzeptierenden Zustand erreicht haben muss.

Aus mehreren Automaten mit deadlines lassen sich dadurch zeitliche Bedingungen in Pfadausdrücken überprüfen. Dazu werden die Automaten verkettet. Das Beispiel aus MP-WS13-02#Darstellung_in_der_DSL würde in die folgenden Automaten umgesetzt. Automaten, generiert aus dem Beispiel in MP-WS13-02#Darstellung_in_der_DSL.

Bei der Überprüfung eines Istverhaltens würde zunächst der Automat auf der linken Seite ausgeführt. Jedes mal, wenn der linke Automat seinen Endzustand erreicht, wird die Zeitmarke Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle t} des gelesenen Übergangs gespeichert und als deadline für den rechten Automaten Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle d=t+5000} gewählt. Daraufhin wird der rechte Automat ausgeführt. Das Istverhalten wird nur als gültig betrachtet, solange kein Übergang mit Zeitstempel Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle d < t} gelesen wird und der Automat den Endzustand betritt.

Dies kann dazu führen, dass möglicherweise mehrere Automaten gleichzeitig ausgeführt werden, was allerdings kein Problem darstellt, solange die Zahl der Automaten nicht überhand nimmt. Davon ist allerdings in praktischen Anwendungen auszugehen, da Automaten, deren deadline Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle d} bereits überschritten wurde nicht mehr weiter ausgewertet werden müssen.

Integration der DSL mit dem Metamodell durch Modelltransformation

Der aus der DSL generiert Testcode enthält keine Logik zur Testausführung. In der DSL sind allerdings Konstrukte vorhanden, um einen Testablauf beschreiben zu können. Grundsätzlich ist es möglich, diese Informationen in das Metamodell des Testframeworks zu Übertragen. Dazu müssen allerdings mehrere Schritte unternommen werden:

  1. Die Informationen müssen in eine EMF-Repräsentierung überführt werden
  2. Aus dieser Repräsentierung muss eine Transformation in das Testframework-Metamodell erfolgen

Extrahieren von EMF-Modellen aus Xtext

In älteren Versionen der Xtext-Dokumentation[20] existieren Angaben zum Parsen eines Xtext-DSL-Files als EMF-Modell. Dieses Vorgehen funktioniert allerdings nicht, wenn die benötigten Inhalte aus mehreren Dateien stammen, ohne das diese angegeben werden.

Es besteht aber die Möglichkeit, mithilfe der Codegenerierung durch Xtend und dem in [21] beschriebenen Vorgehen ein EMF Modell zu erzeugen. Damit dieses EMF-Modell vollständig ist, muss das Resource-Konzept des Eclipse Modeling Frameworks beachtet werden. Im EMF müssen Modellelemente, wenn sie persistiert werden sollen, eine zugehörige Resource besitzen. Beim Aufruf der Funktion save() auf diesem Objekt werden alle Modellobjekte gespeichert. Wird ein Modellobjekt von einer Resource in eine andere verschoben, verschieben sich alle Elemente, die Teil dieses Modellobjekts sind, mit. Dies gilt allerdings nicht für sogenannte non-containment-References. Für Objekte, die lediglich referenziert werden und nicht teil eines anderen Objekts sind, werden lediglich Querverweise in der neuen Resource angelegt. Um die Querverweise zu verhindern, müssen die Referenzierten Objekte ebenfalls der neuen Resource hinzugefügt werden. Auf diese Weise kann ein einzelnes XMI-File erzeugt werden, dass das komplette Modell eines Testfalls in einer EMF-Repräsentierung enthält.

Transformation ins Testframework-spezifische Modell

Die Erzeugte EMF-Repräsentierung kann als Eingabe für eine QVT- Transformation genutzt werden. Zur Transformation wird QVT-Operational verwendet. Das erzeugt Modell kann als Eingabe für einen Interpreter dienen, der das SUT ansteuert und die Tests Auswertet. Da noch keine Spezifikation des Soll-Verhaltens in der Spezifikation vorhanden ist, wird an dieser Stelle die neue Klasse BehaviourDefinition im Metamodell Eingeführt. Die Klasse wird dann als Referenz auf den generierten Soll-Verhaltens-Automat genutzt. Die Vererbungshierarchie dieser Klass ist in der folgenden Abbildung zu sehen.

BehaviourDefinition.png

Zum Treiben der Tests wird ebenfalls die Klasse ApplyEventAction verwendet. Sie beschreibt, was zu tun ist, um einen Event einer SFT zu setzen. Dazu besitzt die Klasse eine Referenz auf ein Event, das gesetzt werden soll. Zusätzlich ist eine Referenz auf die Spezifikation einer Instanz gegeben, damit klar ist, welche Instanz das Event erhalten soll. Als Unterklassen sind ApplyEventActionSwitch (zum permanenten Setzen von Events) und ApplyEventActionTrigger (zum kurzen anstoßen des Events für einen Zyklus) vorhanden. Die Klasse ApplyEventSet stellt dabei eine Sammlung von Events dar, die gleichzeitig angewendet werden sollen. Ein Diagramm der Beziehungen zwischen diesen Klassen wird in der Folgenden Abbildung dargestellt.


ApplyEventAction.png


Architektur mit Anpassungen

In der folgenden Abbildung ist die Gesamtarchitektur nach den beschriebenen Schritten zu sehen. Alle Komponenten, die in dem Masterprojekt erstellt oder an denen erhebliche Veränderungen vorgenommen wurden sind blau hinterlegt. Um SFTs zu Testen müssen diese über die Transformationen Transformationen as StateCase zunächst in das interne TEFA-SFT-Format umgewandelt werden. Danach können sie in dem Deployment-Modell(siehe MP-WS13-02#Neues_Deployment-Modell) über das in MP-WS13-02#Einbindung_der_EMF-Modelle beschriebene Eclipse-Plugin eingebunden werden. Dieses Modell kann in den Testmodell-Dateien Referenziert werden. Durch das DSL-Modul werden diese Modelle in die in MP-WS13-02#Anpassung_des_Orakels beschriebenen Automaten als Java-Klassen umgewandelt. Zusätzlich wird ein DSL-ecore-Modell erzeugt(MP-WS13-02#Extrahieren_von_EMF-Modellen_aus_Xtext). Mit dem Verfahren aus MP-WS13-02#Transformation_ins_Testframework-spezifische_Modell wird daraus ein TEFA-ecore-Modell erstellt. Diese Modell enthält Referenzen auf die Test-Automaten. Das TEFA-ecore-Modell wird dann vom TEFA-Interpreter, der außerhalb dieser Arbeit erstellt wurde, verarbeitet. Hier wird das Modell interpretiert und die Events des SUT über die Anbindung SUT an die Testautomaten weitergeleitet. Damit kann ein Testergebnis erzeugt werden.

Gesamtarch.png

Fazit

Ergebnisse und Ausblick

Die erstellte DSL wurde durch mehrere Arbeiten mit der Umgebung integriert. Dazu mussten zunächst die Systemmodelle in die DSL eingebunden werden, indem ein Eclipse-Plugin erstellt wurde, dass diese Modelle aus einer Xtext-Grammatik referenzierbar macht. In diesem Kontext wurde ein einfaches Deployment-Modell erstellt, dass die Zuordnung von Instanzen von Zustandsmaschinen zu ihren Verhaltensmodellen ermöglicht.

Um das Testorakel nicht nur auf vollständigen Trace-Dateien ausführbar zu machen, wurde das Automatenkonzept aus der DSL verändert und durch Automaten ersetzt, die einzelne Trace-Events verarbeiten können. Dabei wurde ein Algorithmus zum verarbeiten von regulären Ausdrücken verwendet.

Diese Ergebnisse sollen im Testframework wiederverwendet werden. Dazu musste zunächst ein EMF-Modell der in der DSL erstellten Testmodelle erzeugt werden. Danach wurde eine Transformation in das Metamodell des Testframeworks durchgeführt.

Weiterhin wurde um die Ausdrucksmöglichkeiten der DSL zu verbessern, eine Deadline für Pfadausdrücke eingeführt. Diese ermöglicht die Einbindung von zeitlichen Einschränkungen. Ein weiteres Konzept zur tieferen Einbindung von Zeitausdrücken in de Pfadausdrücke wurde vorgestellt, aber noch keine Codegenerierung umgesetzt. Eine tiefere Betrachtung von Echtzeitaspekten war aus Zeitgründen leider nicht möglich.

Die Ergebnisse dieses Masterprojekts werden innerhalb des Testframework-Projekts an den Projektpartner weitergegeben. Dieser wird damit Tests durchführen, die Ergebnisse dieser Evaluation werden in das Testframework eingearbeitet werden. Parallel zu diesem Vorgang soll die Basis des Testframeworks auf TPTP zur Testverwaltung und Steuerung umgearbeitet werden.

Im Herbst 2014 wird eine Master-Thesis in diesem Projekt durchgeführt werden, dass sich mit dem Test von Echtzeiteigenschaften und ähnlichen QoS-Eigenschaften beschäftigt.

Weitere erfolgte Arbeiten

Neben den hier beschrieben Arbeiten wurde zu den Ergebnissen des Masterprojekts und der Masterarbeit von Herr Pötz eine kurze Veröffentlichung für die Informatiktage 2014 [22] mit dem Titel Eine DSL zur Modellierung von Tests für Automatisierungsanwendungen gemeinsam mit Michael Pötz verfasst.

Arbeitsaufwand

Im folgenden ist eine Übersicht über die geleisteten Stunden zu sehen.

Tätigkeitsfeld Vorgabe Tatsächlich geleistete Stunden
Projekt- und Zeitmanagement 30 h 25 h
Praktische Tätigkeit 240 h 275,5 h
Ausarbeitung und Präsentation 90 h 84,5 h
Literaturstudium, Einarbeitung 90 h 70 h
Summe 450 h 455 h


Die Abweichungen von den Vorgaben sind teilweise dadurch zu erklären, dass die Arbeit an der Veröffentlichung vollständig als praktische Arbeit aufgeführt ist und nicht weiter in die Bereiche Literaturarbeit etc. aufgegliedert ist.

Die folgende Datei enthält eine detailliertere Aufschlüsselung der geleisteten Stunden: Medium:TimeSheet.pdf

Quellen

  1. Labor für Verteilte Systeme, Hochschule RheinMain Testframework für Automatisierungsanwendungen, [1]
  2. 2,0 2,1 2,2 Poetz, M. (2013) Entwicklung einer DSL zur Testmodellierung sowie Realisierung eines entsprechenden Testorakels für ein proprietäres verteiltes Automatenmodell [Master-Thesis]
  3. Utting, M. & Legeard, B. (2007), Practical Model-Based Testing: A Tools Approach , Morgan Kaufmann .
  4. 4,0 4,1 Baker, P.; Dai, Z. R.; Grabowski, J.; Haugen, Ø.; Schieferdecker, I. & Williams, C. (2007), Model-Driven Testing: Using the UML Testing Profile , Springer, Berlin .
  5. ETSI (2013) ES 201 873-1 The Testing and Test Control Notation version 3
  6. Schieferdecker, I., & Dai, Z. (2003). The UML 2.0 testing profile and its relation to TTCN-3. Testing of Communicating Systems.
  7. OMG: Meta Object Facility [[2]]
  8. Eclipse Foundation. Xtext Documentation [3]
  9. Vogel, Lars. (2013) Eclipse Modeling Framework (EMF) - Tutorial [4]
  10. Object Management Group. (2008) Meta Object Facility (MOF) 2.0 Query/View/Transformation, v1.0
  11. Eclipse Foundation. Xtext homepage [5]
  12. 12,0 12,1 Eclipse Foundation. Xtend-Homepage [6]
  13. Eclipse Foundation. Xtext - 15 Minutes Tutorial[7]
  14. Eclipse Foundation Eclipse Test & Performance Platform[8]
  15. Chapell, D. (2007) Introducing Windows Communication Foundation [Whitepaper] [9]
  16. Eclipse Foundation. IResourceServiceProvider [JavaDoc] [10]
  17. Eclipse Foundation IEObjectDescription JavaDoc[11]
  18. Kleene, S. (1951). Representation of events in nerve nets and finite automata. Automata Studies. Retrieved from [12]
  19. Thompson, K. (1968). Programming Techniques: Regular expression search algorithm. Communications of the ACM, 11(6), 419–422. doi:10.1145/363347.363387
  20. Eclipse Foundation Processing Xtext Models [13]
  21. Lars Vogel Eclipse Modeling Framework (EMF) - Persisting models via XMI [14]
  22. Gesellschaft für Informatik (2014). Informatiktage 2014[15]